BR122022009823B1 - METHOD IMPLEMENTED BY A FIRST NODE IN A NETWORK, METHOD IMPLEMENTED BY A SECOND NODE IN A NETWORK, FIRST NODE IN A NETWORK, SECOND NODE IN A NETWORK, AND SYSTEM IN A NETWORK - Google Patents

Abstract

The present invention relates to a mechanism for implementing connection state flooding reduction (LSFR) in an Interior Gateway Protocol (IGP) network. The mechanism includes receiving (1901) data that indicates a connectivity of a plurality of nodes in the network. A flood topology is built based on connectivity. This includes selecting (1903) one of the nodes as a root node, and building (1903) a tree of connections connecting the root node to the nodes in the network. The flood topology is stored in a memory. The flooding topology might not be for the remaining nodes in the network. Connection status messages can then be flooded (1909) over the flooding topology.

Description

CROSS REFERENCE TO RELATED REQUESTS

[001] This patent application claims the benefit of Provisional Patent Application Number 62/616,499, filed on January 12, 2018 by Huaimo Chen, and entitled "Open Shortest Path First (OSPF) Flood Minimization", for the Provisional Patent Application Number 62/624986, filed on February 1, 2018 by Huaimo Chen, and entitled "Intermediate System-Intermediate System (IS-IS) Flooding Minimization", for Provisional Patent Application Number 62/750,677, filed on October 25, 2018 by Huaimo Chen, and entitled "Minimization of Interior Gateway Protocol Flooding", all of which are hereby incorporated by reference.

FIELD OF TECHNIQUE

[002] The present description generally relates to Interior Gateway Protocol (IGP) based networks, and specifically relates to a mechanism for creating a separate flooding topology to support minimizing packet flooding in a network based in IGP.

FUNDAMENTALS

[003] Certain networks employ connection state information to route packets. In such networks, each node transmits the node's connection state information across the network in connection state messages as part of a synchronization process. Node connection state information includes data identifying the node, indicating the node's neighbors, and indicating distance and/or routing costs for contacting such neighbors. Each node receives connection state messages from other nodes, and uses the connection state information to populate a connection state database. Each node can then use a corresponding connection state database to determine shortest paths for communicating data packets with other nodes. Such networks suffer from certain scalability problems. Specifically, each node periodically broadcasts a connection status message to every other node on the network. As more nodes are added to the network, more connection status messages are transmitted, which results in ever-increasing signaling overhead that competes with data traffic for bandwidth.

SUMMARY

[004] In one embodiment, the description includes a method implemented at a first node in a network. The method comprises receiving, at a receiver of the first node, data indicating a connectivity of a plurality of nodes in the network including the first node. Method o further comprises constructing, by a processor of the first node, a connectivity-based flooding topology. The flooding topology is built by selecting one of the nodes as a root node, and building a tree of connections that connect the root node to the nodes in the network. The flooding topology is stored in a memory without transmitting the flooding topology to the plurality of nodes in the network. The method further comprises flooding, by a transmitter of the first node, connection status messages into the flooding topology. Employing a flooding topology allows list state messages to reach all nodes on the network without requiring connection state messages to be flooded over all connections. This reduces traffic from redundant connection status messages, and thereby reduces network traffic congestion. Such a reduction also provides increased network scalability, as the flooding topology reduces network traffic congestion in a way that is proportional to the number of network nodes. Also, allowing each node separately to calculate the flood topology without transmitting the flood topology over the network additionally reduces network traffic congestion.

[005] Optionally, in any of the foregoing aspects, another implementation of the aspect includes, further comprising receiving, at the receiver, a request that specifies a number of leaf connections to add to the tree, and add to the flooding topology, by the processor, number of leaf connections between nodes in the network. Adding leaf connections to the flood topology adds redundancy but also stability. Additional leaf connections reduce the number of potential sources of equipment failure that could disrupt the flood topology.

[006] Optionally, in any of the foregoing aspects, another implementation of the aspect includes, in which, before adding the leaf connections, the connection tree in the flood topology contains a minimum number of connections to connect all nodes in the network in the root node.

[007] Optionally, in any of the foregoing aspects, another implementation of the aspect includes, further comprising establishing, by the processor, an adjacency with a newly connected node. The newly connected node is directly connected to the first node through a connection. The method further comprises adding, by the processor, the newly connected node in the connection tree in the flooding topology until the flooding topology is recomputed. This allows new nodes to be added to the flood topology without requiring the flood topology to be immediately recomputed across the entire network.

[008] Optionally, in any of the foregoing aspects, another implementation of the aspect includes, further comprising receiving, at the receiver, a first connection status message over a connection that is excluded from the flooding topology; and flooding, by the sender, the first connection state message through connections in the flooding topology. This allows connection status messages received from outside the flooding topology to be transferred across the network without flooding across all interfaces. This can be used to allow backwards compatibility with devices that are not capable of employing a flooding topology.

[009] Optionally, in any of the foregoing aspects, another implementation of the aspect includes, further comprising: receiving, at the receiver, a second connection status message indicating that a second node in the network is down; and flooding, by the sender, the second connection status message for connections connecting between the first node and neighbors of the second node. This allows communication around a faulty node while maintaining the flooding topology for portions of the network that are not directly connected at the fault.

[0010] Optionally, in any of the foregoing aspects, another implementation of the aspect includes, further comprising receiving, at the receiver, a third connection status message that indicates that a first connection in the network is disconnected. Method o further comprises determining that the first connection is a critical element. The method further comprises based on the determination, sending the third connection status message to connections that connect to neighbors which also connect adjacent nodes to a node attached in the first connection. This allows communication around a faulty connection while maintaining the flood topology for portions of the network that are not directly connected at the fault.

[0011] Optionally, in any of the foregoing aspects, another implementation of the aspect includes, further comprising: determining, by the processor, critical elements, wherein a critical element is a connection or node whose failure splits the flooding topology; and discontinue use of the flooding topology when a critical interface fails. A failure of a critical element breaks the flooding topology into multiple topologies. With this, the failure of a critical element can prevent connection state messages in the flood topology from reaching all nodes in the network. Keeping awareness of this potential problem allows the network to revert to general flooding until another flooding technology can be generated that omits the critical interface.

[0012] Optionally, in any of the foregoing aspects, another implementation of the aspect includes, where the connection state messages are Open Shortest Path First (OSPF) Connection State Advertisements (LSAs).

[0013] Optionally, in any of the foregoing aspects, another implementation of the aspect includes, wherein the connection state messages are Intermediate System to Intermediate System (IS-IS) Connection State Protocol (LSPs) data units.

[0014] Optionally, in any of the foregoing aspects, another implementation of the aspect includes, wherein connection state messages contain Flood reduction flags (F) set to indicate nodes in the network that support connection state flood reduction through the flood topology. The F flags allow for backwards compatibility.

[0015] Optionally, in any of the foregoing aspects, another implementation of the aspect includes, wherein the connection state messages contain a mode-set field to indicate a centralized connection state flood reduction, connection state flood reduction distributed, or statically configured connection state flood mitigation.

[0016] Optionally, in any of the foregoing aspects, another implementation of the aspect includes, wherein the connection status messages contain an algorithm field set to indicate an algorithm for building the connection tree in the flooding topology.

[0017] Optionally, in any of the foregoing aspects, another implementation of the aspect includes, wherein the connection state messages contain an operation field (OP) set to switch to connection state flood reduction from total network flooding.

[0018] In one embodiment, the description includes a first node in a network. The first node comprises a receiver configured to receive data indicating connectivity from a plurality of nodes in the network including the first node. The first node also comprises a processor coupled to the receiver. The processor is configured to build a flooding topology based on connectivity. This occurs by selecting one of the nodes as a root node, and building a tree of connections that connect the root node to the nodes in the network. The first node also comprises memory coupled to the processor, the memory configured to store the flooding topology. The first node also comprises a transmitter coupled to the processor, the transmitter configured to flood connection status messages into the flooding topology without transmitting the flooding topology to the remaining nodes in the network. Employing a flooding topology allows list state messages to reach all nodes on the network without requiring connection state messages to be flooded over all connections. This reduces traffic from redundant connection status messages, and thereby reduces network traffic congestion. Such a reduction also provides for increased network scalability, as the flooding topology reduces network traffic congestion in a way that is proportional to the number of network nodes. Also, allowing each node separately to calculate the flood topology without transmitting the flood topology over the network additionally reduces network traffic congestion.

[0019] Optionally, in any of the preceding aspects, another implementation of the aspect includes, where the receiver is further configured to receive a request that specifies a number of leaf connections to add to the tree, and where the processor is further configured to add to the flooding topology the number of leaf connections between the nodes in the network. Adding leaf connections in the flood topology adds redundancy but also stability. Additional leaf connections reduce the number of potential sources of equipment failure that could disrupt the flood topology.

[0020] Optionally, in any of the foregoing aspects, another implementation of the aspect includes, in which, before adding the leaf connections, the connection tree in the flood topology contains a minimum number of connections to connect all nodes in the network in the root node.

[0021] Optionally, in any of the foregoing aspects, another implementation of the aspect includes, wherein the processor is further configured to establish an adjacency with a newly connected node, wherein the newly connected node is directly connected to the first node via a connection , and wherein the processor is further configured to add the newly connected node into the connection tree in the flooding topology until the flooding topology is recomputed. This allows new nodes to be added to the flood topology without requiring the flood topology to be immediately recomputed across the entire network.

[0022] Optionally, in any of the foregoing aspects, another implementation of the aspect includes, wherein the receiver is further configured to receive a first connection status message over a connection that is excluded from the flooding topology, and wherein the transmitter is still configured to flood the first connection status message across connections in the flooding topology. This allows connection status messages received from outside the flooding topology to be transferred across the network without flooding across all interfaces. This can be used to allow backwards compatibility with devices that are not capable of employing a flooding topology.

[0023] Optionally, in any of the foregoing aspects, another implementation of the aspect includes, wherein the receiver is further configured to receive a second connection status message indicating that a second node in the network is down, and wherein the transmitter is still configured to flood the second connection state message for connections that connect between the first node and the second node's neighbors. This allows communication around a faulty node while maintaining the flooding topology for portions of the network that are not directly connected at the fault.

[0024] Optionally, in any of the foregoing aspects, another implementation of the aspect includes, wherein the receiver is further configured to receive a third connection status message indicating that a first connection on the network is disconnected, wherein the processor is still configured to determine that the first connection is a critical element, and where the sender is further configured to, based on the determination, send the third connection status message for connections that connect to neighbors which also connect to nodes adjacent to a node attached on first connection. This allows communication around a faulty connection while maintaining the flood topology for portions of the network that are not directly connected at the fault.

[0025] Optionally, in any of the foregoing aspects, another implementation of the aspect includes, wherein the processor is further configured to determine critical elements, wherein a critical element is a connection or node whose failure splits the flooding topology; and discontinue use of the flooding topology when a critical element fails. Failure of a critical element breaks the flooding topology into multiple topologies. With this, the failure of a critical element can prevent connection state messages in the flood topology from reaching all nodes in the network. Maintaining awareness of this potential problem allows one to revert to general flooding until another flooding topology can be generated that omits the critical interface.

[0026] Optionally, in any of the foregoing aspects, another implementation of the aspect includes, where the connection state messages are Open Shortest Path First (OSPF) Connection State Advertisements (LSAs).

[0027] Optionally, in any of the foregoing aspects, another implementation of the aspect includes, wherein the connection state messages are Intermediate System to Intermediate System (IS-IS) Connection State Protocol (LSPs) data units.

[0028] Optionally, in any of the foregoing aspects, another implementation of the aspect includes, wherein connection state messages contain Flood reduction flags (F) set to indicate nodes in the network that support connection state flood reduction through the flood topology. The F flags allow for backwards compatibility.

[0029] Optionally, in any of the foregoing aspects, another implementation of the aspect includes, wherein the connection state messages contain a mode-set field to indicate a centralized connection state flood reduction, connection state flood reduction distributed, or statically configured connection state flood mitigation.

[0030] Optionally, in any of the foregoing aspects, another implementation of the aspect includes, wherein the connection status messages contain an algorithm field set to indicate an algorithm for building the connection tree in the flooding topology.

[0031] Optionally, in any of the foregoing aspects, another implementation of the aspect includes, wherein the connection state messages contain an operation field (OP) set to switch to connection state flood reduction from total network flooding.

[0032] In one embodiment, the description includes a non-transient computer-readable medium comprising a computer program product for use by a first node in a network, the computer program product comprising computer-executable instructions stored on the readable medium per computer non-transient so that when executed by a processor causes the first node to perform any of the preceding aspects.

[0033] In one embodiment, the description includes a first node in a network. The first node comprises receiving means for receiving data indicating a connectivity of a plurality of nodes in the network including the first node. The first node also comprises processing means for building a flooding topology based on connectivity. This occurs by selecting one of the nodes as a root node, and building a tree of connections that connect the root node to the nodes in the network. The first node also comprises memory storage means for storing the flood topology. The first also comprises a transmission means for flooding connection status messages into the flooding topology without transmitting the flooding topology to the remaining nodes in the network.

[0034] Optionally, in any of the foregoing aspects, another implementation of the aspect includes, wherein the receiving means, processing means, memory storage means, and transmission means are configured to perform any of the foregoing aspects.

[0035] For the purpose of clarity, any one of the above embodiments may be combined with any one or more of the other embodiments above to create a new embodiment within the scope of the present description.

[0036] These and other features will be more clearly understood from the following detailed description taken in conjunction with the drawings and embodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

[0037] For a more complete understanding of this description, reference is now made to the following brief description, taken in connection with the accompanying drawings and the detailed description, in which like reference numerals represent like parts.

[0038] Figure 1 is a schematic diagram of an exemplary IGP network.

[0039] Figure 2 is a schematic diagram of an exemplary IGP network with a flooding topology to support Distributed Connection State Flooding Reduction (LSFR).

[0040] Figure 3 is a schematic diagram of an exemplary IGP network with a flooding topology that employs a leaf.

[0041] Figure 4 is a schematic diagram of an exemplary network node for operation in an IGP network.

[0042] Figure 5 is a flowchart of an exemplary method of building a flood topology.

[0043] Figure 6 is a flowchart of another exemplary method of building a flood topology.

[0044] Figure 7 is a flow chart of another exemplary method of building a flood topology.

[0045] Figure 8 is a schematic diagram of an exemplary flood mechanism.

[0046] Figure 9 is a schematic diagram of an exemplary flooding mechanism employed when discovering a new node.

[0047] Figure 10 is a schematic diagram of an exemplary flooding mechanism employed when discovering that a node is down.

[0048] Figure 11 is a schematic diagram of another exemplary flooding mechanism employed when discovering that a node is down.

[0049] Figure 12 is a schematic diagram of an exemplary flooding mechanism employed when discovering that a connection is down.

[0050] Figure 13 is a schematic diagram of an exemplary IGP network with a critical interface in the flooding topology.

[0051] Figure 14 is a schematic diagram of an exemplary Open Shortest Path First (OSPF) version two (v2) encoding to indicate node support for LSFR.

[0052] Figure 15 is a schematic diagram of an exemplary OSPF version three (v3) encoding to indicate node support for LSFR.

[0053] Figure 16 is a schematic diagram of an exemplary Intermediate System-Intermediate System (IS-IS) encoding to indicate node support for LSFR.

[0054] Figure 17 is a schematic diagram of an exemplary LSFR control type length value (TLV) encoding for managing LSFR in an IGP network.

[0055] Figure 18 is a schematic diagram of an exemplary TLV encoding for integrating centralized LSFR with distributed LSFR.

[0056] Figure 19 is a flowchart of an exemplary method of operating LSFR mechanisms in an IGP network.

[0057] Figure 20 is an embodiment of a device for operating LSFR mechanisms in an IGP network.

DETAILED DESCRIPTION

[0058] It should be understood at the outset that although an illustrative implementation of one or more embodiments is provided below, the systems and/or methods described may be implemented using any number of techniques currently known or in existence. The description shall in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the designs and exemplary implementations illustrated and described herein, but may be modified within the scope of the embodiments together with their full scope of equivalents.

[0059] Described here are various mechanisms for reducing signaling overhead relating to connection status messages in IGP networks, such as OSPF and/or IS-IS networks. Communicating connection state messages from one node to all other nodes in a network domain is referred to as flooding. The described mechanisms, collectively referred to as LSFR, reduce the impact of connection state message flooding by generating a flooding topology that is a subset of the actual network topology. In general, each node floods the network by transmitting connection state messages in the flooding topology without transmitting such messages across network connections that are excluded from the flooding topology. This allows the message to reach all other nodes on the network, while minimizing the number of redundant copies of the message received at each node. For example, the flooding topology can be generated as a connection tree (eg a spanning tree) that connects the nodes. Such a connection tree allows a connection state message to be flooded to all nodes while ensuring that each node receives a single copy of the flooded message. For increased reliability leaves can be added to the connection tree as directed by a network administrator. This adds back some message redundancy but increases network reliability by providing alternative message path(s) through the flooding topology in the event that a connection or node fails. In distributed mode, each node determines the flooding tree using a common algorithm, which can be selected by the administrator. This allows each node to maintain a copy of the flooding topology without flooding a copy of the flooding topology over the network, which would increase network congestion. A Flood reduction flag (F) is also described. The F flag allows each node to communicate support of LSFR, and thereby allows nodes to employ the flooding topology while maintaining backwards compatibility with nodes that do not support LSFR. The F flag also allows non-LSFR nodes to be connected farther from the root of the flood topology tree. Also described are mechanisms for managing flooding of connection state messages in the event of network changes. For example, when a new node enters the network and communicates with a neighboring node already in the flooding topology, the neighboring node can add the new node to the flooding topology until a recalculation of a flooding topology occurs, and a new flooding topology flood is built. Also, when a connection or node fails, a node adjacent to the fault can communicate connection status messages to other nodes that are adjacent to the fault through connections that are excluded from the flooding topology to ensure that such nodes continue to receive messages from the fault. connection state until the defect is resolved. Furthermore, managers can each retain knowledge of critical elements. A critical element is a flood topology connection/interface or node that, upon failure, splits the flood topology into two or more disjoint parts. Upon notification of the failure of a critical element, nodes can revert to flooding connection status messages over all connections in order to maintain network functionality until the connection/node is repaired or until a new flooding topology can be be computed that does not include the failed element. When a critical element is a flood topology connection (or interface), the critical element is called a critical interface or a critical connection. When a critical element is a flooding topology node, the critical element is called a critical node.

[0060] Figure 1 is a schematic diagram of an exemplary IGP network 100. An IGP network 100 is a network configured to exchange routing and/or switching information based on an IGP protocol, such as OSPF and/or IS-IS. The IGP network 100 includes a plurality of nodes 111 interconnected by connections 115. A node 111 is a network device capable of receiving a data packet from a source over a first interface, determining a destination the data packet can reach through a second interface, and transfer the data packet towards the destination through the second interface. For clarity of discussion, the term data packet as used herein includes both data packet and data frames. A connection 115 is a means capable of propagating a signal from an interface of a first node 111 to an interface of a second node 111.

[0061] The nodes 111 are interconnected to form a network domain 110. As used herein, a network domain 110 is a group of interconnected nodes 111 that share network addressing schemes, policies and/or protocols. Specifically, nodes 111 of network domain 110 employ a connection state routing protocol. When employing a connection state routing protocol, each node 111 in network domain 110 maintains a complete network topology (e.g., a routing table) and independently determines next hops for data packets employing locally stored information relating to the topology. network. The network topology includes data indicating the structure of the IGP 100 network, such as 111 node and 115 connection connections, 111 node adjacencies, 111 node interface information, and/or other 115 connection/node relationship information 111.

[0062] Nodes 111 share connection state information across the domain of network 110. Connection state information for a node 111 includes data that identifies the node 111 (for example, the address of the node 111), a list of neighbors of node 111 and costs/delays between node 111 and neighbors of node 111. Nodes 111 are neighbors when separated by a single connection 115. In order to share connection state information, node 111 floods connection status messages connection through network domain 110. In OSPF, connection state messages are known as Connection State Advertisements (LSAs). In IS-IS, connection state messages are known as connection state protocol units (LSPs). In some examples, each node 111 floods connection state messages over all interfaces. As used herein, flooding denotes a simultaneous transmission of a packet/frame over a predefined set of network interfaces. Such a proposal can create problems as the size of the IGP 100 network increases. For example, when each node 111 periodically sends a connection state message to all other nodes 111 across all interfaces, network traffic relating to connection state data can increase dramatically as more nodes 111 are added to the host network. IGP 100. Further, each node 111 may receive a connection status message for every other node 111 over all interfaces. This can result in each node 111 receiving multiple redundant connection status messages.

[0063] The present description modifies the protocols employed by the nodes 111 in the network domain 110 in order to reduce redundant connection status messages. The process of reducing the communication of redundant connection status messages is referred to herein as list state flooding reduction (LSFR). Specifically, the nodes 111 are modified to generate and maintain a flooding topology that is a subset of the topology of the IGP network 100. Connection status messages are flooded into the flooding topology rather than the entire IGP network topology 100 . This proposal reduces the communication of redundant connection status messages, which increases the scalability of the IGP 100 network. Furthermore, reducing the traffic of connection status messages reduces the maintenance signaling of the total network, and with this increases the capacity node 111 communication port for data traffic.

[0064] Figure 2 is a schematic diagram of an exemplary IGP network 200 with a flooding topology 219 to support distributed LSFR. For example, the IGP network 200 can be employed to implement LSFR over an IGP network 100. The IGP network 200 includes nodes 211, a root node 212, and a first node 213, which may be substantially similar to the nodes 111 in the IGP network 100. A root node 212 is a node 211 selected as a root for a spanning tree employed as a flooding topology 219. A first node 213 is a node 211, and is differentiated to support clarity of discussion when describing the LSFR scheme discussed here. The IGP network 200 includes flood topology connections 216 and connections 217, which are substantially similar to the connections 115. The flood topology connections 216, shown in bold, are connections included in the flood topology 219, and are thereby employs to transmit connection status messages. The connections 217, shown without bold, are not included in the flood topology 219, and only carry connection state messages in certain specific cases, as discussed with reference to the Figures below.

[0065] The network of IGP 200 can operate in a distributed mode. In the distributed mode, each node 211, 212, and 213 generates a flood topology 219 after a network change is detected. Flood topology 219 is a connection tree of flood topology 216 employed to transmit connection status messages. Nodes 211, 212, and 213 employ the same algorithm to generate the flood topology 219. Accordingly, each node 211, 212, and 213 stores the flood topology 219 in local memory without transmitting the flood data indicating the flood topology. flooding 219 to the remaining nodes in the IGP network 200. In this mode, data indicating the flooding topology 219 is not sent to all nodes 211. The flooding topology 219 can be generated according to various algorithms as discussed in connection with to the Figures below.

[0066] Each node 211, 212, and 213 can generate a flood topology 219 after receiving data indicating the connectivity of the nodes 212, 211, and/or 213 in the IGP network 200 at each node 211, 212, and 213. Receiving/sending data can occur over a pre-existing flooding topology 219 and/or through general flooding if no pre-existing topology 219 exists. Each node 211, 212, and 213 may build a copy of the flood topology 219 employing a selected algorithm. For example, one of the IGP network nodes 200 is selected as a root node 212. A root node 212 can be selected from nodes 211/213 by many mechanisms. For example, root node 212 can be selected from nodes 211/213 as the node with the highest or lowest identifier (ID), internet protocol (IP) address, media access control (MAC) address, etc. . Once the root node 212 is selected, a flood topology connection tree 216 is constructed such that the flood topology connection tree 216 connects the root node 212 to the nodes in the network. For example, the flood topology 219 can be constructed as a spanning tree and/or a minimal weight spanning tree. A spanning tree is a subset of a graph, where all vertices (nodes 211, 212 and 213) are connected through a minimum number of edges (connections 216). A minimal weight spanning tree is a subset of a graph, where all vertices (nodes 211, 212, and 213) are connected through minimal edge weight (eg connection cost in terms of latency). A flooding topology tree 219 with a root node 212 can be computed in O(N), where O(N) is a big-O notation that indicates a linear computation time based on input (e.g., number of us).

[0067] A flood topology 219 is a subnet topology of the IGP network topology 200 that meets several criteria. First, the flood topology 219 provides equivalent reachability for all nodes in the subnet as in the real network (eg, IGP network 200). Second, when n (n > 0) 216 connections fail, the reachability for all nodes (for example, nodes 211, 212, and 213) in the subnet must be the same as in the real network. Third, when m (m > 0) node fails, the reachability for all living nodes in the subnet must be the same as in the real network. Fourth, the number of flood topology connections 216 in the flood topology 219 should be minimized in order to reduce list state flooding.

[0068] Once the flood topology 219 is generated, the nodes 211, 212 and 213 can flood connection state messages such as OSPF LSAs and/or IS-IS LSPs, into the flood topology 219. The topology flooding method 219 is designed to interact with the IGP network 200 employing various criteria when flooding connection state messages. For example, the connection state messages use both the 219 flood topology and the 200 real IGP network topology. In addition, the flooding topology 219 and associated flooding mechanisms must support flooding connection status messages (e.g., connection status message 221) to each node 211, 212, and/or 213 in the IGP network 200 in many cases, which are discussed in more detail with reference to the Figures below. For example, flooding mechanisms should allow connection status messages to reach all nodes, nodes 211, 212, and/or 213 when n (n > 1) nodes go down (eg, node failure). As another example, flooding mechanisms should allow connection state messages to reach all nodes 211, 212, and/or 213 when m (m > 1) connections are down (eg, connection / interface failure). Flooding mechanisms must meet such criteria while reducing (eg, nearly minimizing) the flooding of connection state messages. Also the flooding mechanisms must be backward compatible to operate with a flooding topology 219 comprising nodes 211, 212, and/or 213 that support LSFR and nodes that are not capable of LSFR. Compatibility is discussed in more detail with reference to the Figures below. Generally, disabled nodes are positioned in the flooding topology 219, but distant from the root node 212. The disabled nodes can then receive connection state messages from the flooding topology 219 and flood them over all interfaces.

[0069] For purposes of illustration, a connection status message flooding mechanism in the flooding topology 219 is discussed from the perspective of the first node 213. As used herein, the term first node 213 denotes an arbitrarily selected node 211 from the network of IGP 200 for clarity of discussion. A first node 213 may receive a connection status message 221, for example, from the root node 212 about one or more connections 216. The connection status message 221 may be an LSA, an LSP or another packet/frame you carry connection state information. Connection status message 221 may contain connectivity data such as source node ID 211/212, node 211/212 adjacency, connection IDs 216/217, interface information (e.g. gateway data), and/or connection / node status information such as connection cost 216/217 (eg latency).

[0070] The first node 213 receives the connection status message 221 about a flood topology connection 216. The first node 213 analyzes and stores data from the connection status message 221 when such information is newer than the locally stored data . The first node 213 then transfers the connection state message 221 over the flood topology connections 216 of the flood topology 219 towards neighboring nodes 211. The connection state message 221 is not flooded back through the interface from which connection status message 221 was received (eg, back towards root node 212). As shown, the status message of 221 is generally not flooded through connections 217 that are outside the flood topology 219 unless particular cases as discussed in more detail with respect to the figures below. With this, connection state flooding is performed according to the flooding topology 219. As the flooding topology 219 connects all nodes 211, 212 and 213, each node in the IGP network 200 receives a copy of the status message 221 and updates local connection state information (for example, in a routing table). However, since the connection status message 221 is generally not flooded through the connections 217, the nodes 211, 212, and 213 generally do not receive redundant copies of the connection status message 221. connection status message 221 is reduced so that each node 211, 212, and 213 receives a single copy of the connection status message 221 rather than one copy on each interface.

[0071] Generally limiting the flooding of connection state messages 221 to the flooding topology 219 results in several advantages. For example, the flooding mechanism discussed here reduces the total network traffic, and thereby improves network performance. Furthermore, the flooding mechanisms discussed here improve network convergence as the flooding topology 219 is computed at each node in distributed mode. Also, the flooding mechanisms discussed here can reduce configuration requirements when compared to other connection state flooding mechanisms.

[0072] It should be noted that some redundancy can be designed into the IGP 200 network to protect against equipment failure. Specifically, extra connections 216 can be added to the flooding topology 219 in order to mitigate potential IGP network communication problems 200. In such a case, some nodes 211, 212, 213 may receive more than one connection state message 221. Consequently, the LSFR can be more reliably balanced based on redundant connection state messages. A mechanism for increasing the reliability of the flood topology 219 is discussed below.

[0073] Figure 3 is a schematic diagram of an exemplary IGP network 300 with a flooding topology 319 employing a leaf connection 318, which may be employed to increase network reliability. The IGP network 300 is substantially similar to the IGP network 200, but contains an extra leaf connection 318 in the flood topology 319. As such, the IGP network 300 contains a root node 312, nodes 311, connections 317, and a flood topology 319 containing flood topology connections 316 which are substantially similar to root node 212, nodes 211/213, connections 217, flood topology 219 and flood topology connections 216, respectively.

[0074] A 318 leaf connection is a connection added to the 319 flood topology to support network reliability of IGP 300. The 318 leaf connection is shown as a bold dashed line. With the leaf connection 318 added to the flood topology 319 (e.g., creating a circle), some of the connections 316/317 to nodes 311/312 could fail without causing other nodes 311/312 to be severed from the tree. 316 flood topology connections. However, adding a 318 leaf connection may cause one of the endpoint nodes 311/312 of the 318 leaf connection to receive a redundant connection status message. As such, the reliability of the IGP 300 network is increased at the cost of slightly increased signal overhead.

[0075] Adding a 318 leaf connection can occur during the process of building the 319 flood topology. For example, a system administrator can select a number of 318 leaf connections to add to the 319 flood topology. be transmitted to all nodes 311/312 in the IGP network 300. Consequently, each node 311/312 receives the request, which specifies the number of leaf connections 318 to add to the flood topology connection tree 316 in the topology of flooding 319. Each node 311/312 may construct the flooding topology 319 based on the connectivity information as discussed above. Before adding the leaf connections 318, the connection tree 316 in the flood topology 319 may contain a minimum number of connections to connect all the nodes 311 in the IGP network 300 at the root node 312. After generating the flood topology 319 , nodes 311/312 add to the flood topology 319 a number of leaf connections 318k (k >= 0) as specified in the system administrator request. Leaf connection(s) 318 are added between nodes 311/312 in the IGP network 300 to increase reliability. The 318 sheet connections can be placed based on a variety of mechanisms. For example, any flood topology connection 316 or node 311/312 that would split the flood topology 319 into multiple trees/parts upon failure can be designated as a critical element. The 318 leaf connections can be placed in selected positions so as to minimize the number of critical elements in the IGP network 300. Additional 318 leaf connection placement mechanisms are discussed below.

[0076] For example, the flood topology 319, designated Ft, can be constructed by one of the mechanisms described with respect to the Figures. 5-7. In such a case, the flood topology 319 may take the form of a tree. An integer number of leaf connections 318k (k >=0) can then be added to the tree to create an improved flood topology 319 with increased connectivity. For example, there may be m (m > 0) connections 317 directly connected to a node X in the flood topology 319. A number k of leaf connections 318 may be selected, where k < = m, for example, using a deterministic algorithm or rule. An algorithm or rule may include selecting k 318 leaf connections that have the smallest or largest IDs of the 317 connections not currently connected in the 319 flood topology. (For example, the IDs of these k non-leaf ends of the connection are smaller/greater than than the IDs of the other connections directly connected to node X). Each node can have a unique ID. With this, selecting k leaf connections with smaller or larger IDs from these non-leaf ends of these connections is deterministic. As a specific example, if k = 1 under this algorithm, the selected leaf connection 318 has the smallest / largest ID among the IDs of all non-leaf ends of the directly connected connection at node X.

[0077] In another exemplary mechanism, the first node L may be directly connected to a second node N in the 319 Ft flood topology. A connection / adjacency to a third node can be selected from the first node L as a leaf connection 318 in Ft using a deterministic algorithm or rule. For example, a first node L can be directly connected to third nodes Ni (i = 1, 2, ..., s) in the 319 Ft flood topology through adjacencies. Also, the third nodes Ni are not the second node N, IDi is the ID of the third nodes Ni, and Hi (i = 1, 2, ., s) is the number of hops from the first node L to the third nodes Ni na flood topology 319 Ft. An algorithm or rule is to select the connection for the third node Nj (1 < = j < = s) as a leaf connection 318 such that Hj is the largest among H1, H2, ., Hs. If there is another third node Na (1 < = a < = s) and Hj = Ha then select the third node with the smallest (or largest) node ID. Specifically, if Hj equals Ha and IDj < IDa, then select the connection to the third node Nj by selecting the connection with the lowest ID (or if Hj = Ha and IDj < IDa, then select the connection to Na to select the one with the highest ID). node ID).

[0078] For purposes of illustration, the number of connections in total between selected L nodes and the nodes in the 319 Ft flood topology to be added as 318 leaf connections can be denoted as NLc. The number of NLc 318 sheet connections can be limited programmatically. In one example, the NLc is set to a specified number such as ten, which indicates that a maximum of ten connections between a leaf node L and nodes in the 319 Ft flood topology can be selected and added to the 319 Ft flood topology to generate an improved flood topology 319 Ft. In another example, NLc is set to a specified percentage of the number of 311/312 nodes in the network (for example, five percent), which indicates that the number of connections between leaf nodes and Ft nodes to be selected and added in Ft is at most five percent of the number of 311/312 nodes in the IGP 300 network. For example, for a network with a thousand 311/312 nodes, five percent of a thousand is fifty. Thus at most fifty 318 leaf connections between the L leaf nodes and nodes in the 319 Ft flood topology are selected and added in the 319 Ft flood topology.

[0079] Figure 4 is a schematic diagram of an exemplary network node 400 for operation in an IGP network, such as a node in IGP network 100, 200, and/or 300. For example, network node 400 may be employed to implement nodes 111, 211, 212, 213, 311, and/or 312. Further, network node 400 may be employed to compute a network topology 219 and/or 319. Network node 400 may also receive, process, and transfer connection state messages, such as LSAs or LSPs (e.g., 221 connection state messages), over such flooding topologies to implement LSFR. With this, the network node 400 is suitable for implementing the described examples/embodiments as described herein. Network node 400 comprises downstream gateways 420, upstream gateways 450, and/or transceiver (Tx/Rx) units 410, including transmitters and/or receivers for communicating data upstream and/or downstream over a network. Network node 400 also includes a processor 430, which includes a logic unit and/or central processing unit (CPU) for processing the data and a memory 432 for storing the data. Network node 400 may also comprise optical-to-electrical (OE) components, electrical-to-optical (EO) components, and/or wireless communication components coupled to upstream gateways 450 and/or downstream gateways 420 for data communication over of optical or wireless communication networks. Network node 400 may also include input and/or output (I/O) devices for communicating data to and from a user in some cases.

[0080] The 430 processor is implemented by hardware and software. Processor 430 may be implemented as one or more CPU chips, cores (e.g., as a multi-core processor), field-programmable gateway networks (FPGAs), application-specific integrated circuits (ASICs), and digital signal processors. (DSPs). Processor 430 is in communication with downstream gateways 420, Tx/Rx 410, upstream gateways 450, and memory 432. Processor 430 comprises an LSFR module 414. The LSFR module 414 implements the embodiments described herein. Specifically, the LSFR module 414 can construct a flood topology based on connectivity information. LSFR module 414 may construct the flooding topology employing various mechanisms, such as by methods 500, 600, and/or 700, as discussed below. The LSFR 414 module can also add a number of leaf connections into the flood topology as directed by a user/system administrator. LSFR module 414 may store the flooding topology in memory 432. LSFR module 414 may then receive and/or flood connection status messages, such as OSPF LSAs and/or IS-IS LSPs, over a network of IGP through the flood topology employing the downstream gateways 420, Tx/Rx 410, and/or the upstream gateways 450. The LSFR module 414 may also employ case specific handling of connection status messages as discussed with in relation to the Figures below. For example, the LSFR module 414 can add new nodes into the flood topology upon startup as well as transfer connection state messages out of the flood topology in case of connection/node failures. The LSFR module 414 may also maintain awareness of critical elements and revert to general flooding of connection state messages in the event of a critical element failure. These and other mechanisms implemented by the LSFR module 414 are discussed in more detail with reference to the Figures below. Furthermore, the LSFR module 414 performs a transformation of the network node 400 to a different state. Alternatively, LSFR module 414 may be implemented as instructions stored in memory 432 and executed by processor 430 (e.g., as a computer program product stored on a non-transient medium).

[0081] Memory 432 comprises one or more types of memory such as disks, tape drives, solid state drives, read-only memory (ROM), random access memory (RAM), flash memory, content-addressable ternary memory (TCAM), static random access memory (SRAM), etc. Memory 432 can be used as an overflow 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.

[0082] Figures 5, 6, and 7 show exemplary methods of constructing a flood topology. Generally, building a flood topology includes 1) selecting a node R according to a rule, such as the node with the highest / lowest node ID; 2) build a tree using R as the root of the tree; and 3) connect k (k > = 0) leaves in the tree as desired to add equipment failure mitigation in the flood topology. In distributed mode, each of the nodes in the network uses the algorithm to generate a flooding topology, and thus the flooding topology is not distributed/flooded in the IGP network. Two exemplary types of mechanisms are discussed below. One type of mechanism builds a tree for the flooding topology without checking whether the nodes support LSFR. Such a mechanism assumes that all routers in the domain support LSFR. A second type of mechanism considers whether each node supports LSFR while building a tree for the flood topology. Such mechanisms place the nodes that support LSFR closer to the root node in order to allow the nodes that support LSFR to be continuously connected in the flooding topology. Support for LSFR can be signaled in an F flag, which can be included in an IS-IS Router Capability Type Length (TLV) value and/or an OSPF LSA. For example, the F flag can be set to one to indicate that the node/router supports LSFR and set to zero to indicate that the node/router does not support LSFR. The root node can then be selected according to a matching rule, eg as the node with the highest / lowest node ID which also supports LSFR (e.g. between nodes with the F flag set to one).

[0083] Figure 5 is a flowchart of an exemplary method 500 of constructing a flood topology, such as the flood topology 219 and/or 319. Accordingly, the method 500 can be employed by a node 111, 211, 212, 213, 311, 312, and/or 400. Method 500 is a mechanism for building a tree from a root node R with a candidate queue (Cq) initially containing node R and initially an empty flood topology Ft.

[0084] In block 501, the flood topology generation is started. For example, the flooding topology can be recalculated when there are changes in the network. As another example, a flood topology can be recalculated when an event occurs. Specifically, the flooding topology can be recalculated when a critical element fails. As another example, a flood topology can be recalculated when receiving a message from a user / system administrator requesting a recalculation. As noted above, in the distributed mode, method 500 is substantially simultaneously initiated on every node in the network that is capable of LSFR.

[0085] In block 503, a root node for the flood topology is selected, eg based on ID number. The selected root node is added to an empty candidate queue. Also, a flooding topology may be initialized empty at block 503. Method 500 then proceeds to block 505, which forms an iterative loop with blocks 507, 511, and 513.

[0086] Block 505 varies depending on whether method 500 considers which nodes support LSFR. If method 500 does not consider which nodes support LSFR, block 505 removes the first node from the candidate queue and adds the removed node into the flooding topology. If the removed node is not the root node (for example, the flood topology is not empty before adding the removed node), a connection between the removed node and the last added node in the flood topology is also added to the root topology. inundation. As such, block 505 iterates through the candidate queue in root node order and positions the nodes in the flood topology.

[0087] If method 500 considers which nodes support LSFR, block 505 removes the first node from the candidate queue that also supports LSFR. When no node in the candidate queue supports LSFR, the first node in the candidate queue (which does not support LSFR) is removed from the candidate queue. The removed node, and a corresponding connection to the previous node in the flood topology if applicable, is then added to the flood topology. In this way, block 505 can position nodes that support LSFR at positions in the flood topology that are closer to the root node. This results in placing nodes that do not support LSFR farther away from the root node and thereby reduces the reliance on such nodes to communicate connection status data across the flooding topology.

[0088] In block 507, the list of nodes in the network is compared with the list of nodes in the flood topology. When all nodes have been added to the flood topology, method 500 proceeds to block 509 and returns a completed flood topology FT. When at least one node is not included in the FT flood topology, method 500 proceeds to block 511.

[0089] In block 511 varies depending on whether method 500 considers which nodes support LSFR. If method 500 does not consider which nodes support LSFR, block 511 determines a list of nodes Xi (i = 1, 2, 3, ... n) connected to the last node added to the flooding topology, where such nodes are not yet in the flood topology. Such Xi nodes can then be sorted by connection cost and/or connection ID / node / interface. Connection cost may indicate latency, connection length, or maximum connection bandwidth and/or other connection capabilities. Also, the connection cost can indicate a cost between the last node added to the flood topology and a corresponding node Xi. Such a proposal can be employed to position Xi nodes with lower cost connections higher in the candidate queue. With this, such lower cost connections are more likely to be added closer to the root node and are more heavily used in the flood topology. When the cost is identical, the connection/node/interface ID can be used to determine the order. If method 500 considers which nodes support LSFR, block 511 can consider LSFR support when determining the cost. For example, a real metric can be employed to determine costs for nodes that support LSFR. Also, the actual metric for node(s) that do not support LSFR can be scaled by a factor such that the lowest cost non-LSFR metric is higher than the highest cost LSFR metric. By employing costs in this mode, nodes that do not support LSFR are positioned at the end of the candidate queue. This still supports placing nodes that do not support LSFR as far away from the root node as possible.

[0090] At block 513, the Xi nodes from block 511 are added to the end of the candidate queue in order as sorted in block 511. Method 500 may then return to block 505 to add the next candidate queue node over the flood topology.

[0091] Employing the aforementioned proposal, the flood topology grows as a balanced tree starting at the root node. The root node is added to the flood topology first. Then, each of the nodes connected at the root node (eg, first-degree nodes) is added to the flood tree. Then each node connected to the nodes connected at the root node (for example, second-degree nodes connected to a first-degree node) is added to the flood tree. This process continues until all nodes are added in the flooding topology along with corresponding connections.

[0092] Figure 6 is a flowchart of another exemplary method 600 of constructing a flood topology, such as the flood topology 219 and/or 319. Accordingly, the method 600 can be employed by a node 111, 211, 212, 213, 311, 312, and/or 400. Method 600 is a mechanism for building a tree from a root node R with a candidate queue initially containing node R and initially an empty flood topology Ft. Method 600 employs blocks 601, 603, 605, 607, 609 and 611, which are substantially similar to blocks 501, 503, 505, 507, 509 and 511, respectively. Method 600 also employs block 613, which is similar to block 513. However, block 613 adds Xi nodes from block 611 to the end of the candidate queue instead of to the beginning of the candidate queue. Method 600 may consider whether such nodes are LSFR capable when classifying nodes Xi, or method 600 may operate without consideration of LSFR capability (e.g., in a substantially similar manner to method 500).

[0093] Consequently, method 600 is substantially similar to method 500, but the flood tree grows differently. Specifically, the tree grows along the first branch from the root node until all nodes connected to the first branch are added to the flooding topology. Then the nodes attached to the second branch of the root node (which have not yet been added) are added to the flood topology, etc. If LSFR capability is considered, nodes that are not LSFR capable may still be placed later in sequence due to classification in block 611.

[0094] Figure 7 is a flowchart of another exemplary method 700 of constructing a flood topology such as the flood topology 219 and/or 319. Accordingly, the method 700 can be employed by a node 111, 211, 212, 213 , 311, 312, and/or 400. Method 700 is a mechanism for building a tree from a root node R with a candidate queue initially containing node R and initially an empty flood topology Ft. Method 700 employs blocks 701, 703, 705, 707, and 709, which are substantially similar to blocks 501, 503, 505, 507, and 509, respectively. Method 700 also includes blocks 711 and 713, which are similar to blocks 511 and 513, respectively. However, blocks 711 and 713 order the Xi nodes in the candidate queue based on cost back to the root node rather than based on ID or cost back to the previous node in the flooding topology.

[0095] Specifically, block 711 determines the lowest cost to the root node for each node Xi coupled at the last node added to the flooding topology of block 705. In examples that consider LSFR capability, the routes that traverse the nodes that that do not support LSFR increased costs can be assigned to ensure that such routes are excluded and/or only employed in the flood topology when no path that supports full LSFR is available. Xi nodes coupled to the last node added to the flooding topology are added to the candidate queue along with the associated shorter costs back to the root node. In the case where a node Xi was previously added to the candidate queue during a previous iteration due to connecting to another node already in the flooding topology, the new cost for the root node is compared with the previous cost for the root node. The cost is then updated if the new cost is less than the old cost. This proposal causes each node to be considered in a queue of candidates based on the lowest cost back to the root node during each iteration. The queue of candidates is then sorted by costs back to the root node and/or based on interface/node/connection id.

[0096] Consequently, method 700 is substantially similar to method 500, but the flood tree grows differently. For example, the method 700 flood topology grows by adding nodes in order of lowest cost back to the root node. This proposal causes the flood topology to be primarily populated with lower cost paths. Also, the lowest cost paths are positioned in the flooding topology such that such paths are employed with the greatest amount of connection state traffic. Consequently, the highest cost paths are either excluded or only included in the flood topology as a last resort to ensure full connectivity. With this, the use of such higher cost paths and/or the use of paths traversing an LSFR not capable device are employed for the least amount of link state traffic.

[0097] Employing a flooding topology, for example, as generated according to methods 500, 600, and 700, can result in certain problems. For example, certain mechanisms can be employed to ensure that each node in the network obtains a complete flooding topology in a short time when changes occur in the network, specifically when multiple connection or node failures occur. A proposal to mitigate such problems is to make the nodes maintain / compute a redundant flooding topology. Such a redundant flooding topology may include a basic flooding topology for flooding changes that delete connections or dead nodes. Furthermore, the redundant flooding topology can comprise information (such as floodpaths) for one connection or node failure, as well as for multiple connection or node failures. Another mechanism that can be employed is a mechanism to account for changes in the root node. For example, when a node X discovers that the root node R used to compute a flood tree is down or unreachable, node X selects a new root node R according to some rule such as the node with the smallest / largest ID of knot. Node X then computes a flood tree as discussed above and builds the flood topology based on the flood tree (eg immediately). Also, when a new node is added to the existing topology and is reachable, node X can check to determine whether the new node is a new root for a flood tree according to a root node selection rule, such as the new node ID is the new minor / major node ID. If the new node is the new root node, node X computes a flood tree using the new node R as the root and builds the flood topology based on the flood tree after a predefined time interval, such as five seconds .

[0098] Figure 8 is a schematic diagram of an exemplary flooding mechanism 800 which may be employed in an IGP network, such as the IGP network 100, 200, and/or 300. The flooding mechanism 800 is employed with respect to a first node 813, which may be any node in an IGP network (e.g., node 111, 211, 212, 213, 311, 312, and/or 400) that employs a flooding topology, such as the flood topology 219 and/or 319. Such a flood topology may be generated, for example, according to method 500, 600, and/or 700.

[0099] As shown for purposes of illustration, node 813 is coupled to connections 817 that are excluded from the flood topology and connections 816 that are included in the flood topology. As noted above, a node 813 generally receives connection state information from a flooding topology and floods such connection state information over other interfaces coupled in the flooding topology. However, certain cases may occur where an 813 node receives connection state information from an 817 connection that is not included in the flood topology. For example, a node 813 may receive an 821 connection state message from a node that is not capable of LSFR, and thereby flood the 821 connection state message over all interfaces. As another example, node 813 may receive a connection state message 821 from outside the flood topology when a node/connection is faulty. Consequently, the 813 node can take various actions depending on the example. In one example, if the 821 connection status message is received from an 817 connection that is not in the flooding topology, the 813 node sends an 823 and 822 connection status message to the neighbors of the 813 node over all other connections 816 and 817 that are attached to node 813 excluding the connection 817 from which the connection state message 821 is received (for example, the connection state flood follows the actual network topology). Note that messages 822 and 823 are copies of message 821. In another example, if the connection status message 821 is received from a connection 817 that is not in the flooding topology, node 813 sends a connection status message 823 to neighbors of node 813 over all connections 816 that are attached to node 813 and are included in the flooding topology. With this, node 813 can be configured to receive a connection status message 821 over a connection 817 that is excluded from the flooding topology and floods the connection status message 822 outside the flooding topology.

[00100] Figure 9 is a schematic diagram of an exemplary flooding mechanism 900 employed by a first node 913 when discovering a second new node 914. The flooding mechanism 900 may be employed in an IGP network, such as an IGP network 100, 200, and/or 300. Flooding mechanism 900 is employed with respect to a node 913, which can be any node in an IGP network (e.g., node 111, 211, 212, 213, 311, 312 , and/or 400) which employs a flood topology, such as flood topology 219 and/or 319. Such a flood topology may be generated, for example, according to method 500, 600, and/or 700. The flood mechanism 900 may be employed with a flood mechanism 800 when the new node 914 is discovered.

[00101] The mechanism 900 illustrates a proposal to adjust a connection state flood when a new node 914 is connected to a node 913, denoted as a first node 913, which is already operating in the network. The mechanism 900 may be triggered when the first node 913 establishes an adjacency with the newly connected new node 914. As shown, the newly connected new node 914 is directly connected to the first node 913 through a connection 919. The first node 913 assumes that the new node 914 is coupled in the flood topology through the corresponding connection 919 until the flood topology can be rebuilt (for example, after there is a change in the network). As such, connection 919 is temporarily labeled as a flood topology connection in the memory of the first node 913. Consequently, connection 919 is employed to add the newly connected node 914 into the connection tree in the flood topology until the topology of flooding is recomputed. After the new node 914 is added to the flood topology, the first node 913 may receive a connection status message 921 about a connection 916 in the flood topology. The first node 913 may then transfer the connection status message 922 (a copy of the message 921) through either the flood topology connections 916 or the connection 919 to the new node 914. The connection status message 921 may not be transferred to connections 917 that are otherwise excluded from the flooding topology.

[00102] Figure 10 is a schematic diagram of an exemplary flooding mechanism 1000 employed when discovering that a node is faulty (eg, is down). Flooding mechanism 1000 operates over an IGP network, such as IGP network 100, 200, and/or 300. Flooding mechanism 1000 is illustrated with respect to a first node 1013, which can be any node in a network. IGP network (e.g., node 111, 211, 212, 213, 311, 312, and/or 400) that employs a flooding topology, such as flooding topology 219 and/or 319. Such a flooding topology may be generated, for example, according to method 500, 600, and/or 700. Flood mechanism 1000 may be employed with flood mechanisms 800 and/or 900 when a dead node 1031 is faulty.

[00103] As shown, the mechanism 1000 operates over an IGP network with nodes 1011, a root node 1012, and a first node 1013 connected by connections 1017 and flood topology connections 1016, which are substantially similar to nodes 211 , root node 212, first node 213, connections 217 and flood topology connections 216, respectively. Mechanism 1000 can operate on any node, and is illustrated from the perspective of the first node 1013 for clarity of discussion. The mechanism 1000 may be started when the first node 1013 receives a new connection status message 1021 from a neighboring node 1033 over a flooding topology connection 1016. The connection status message 1021 indicates that the dead node 1031 is not functioning . Dead node 1031 is a neighbor with nodes 1033, which are also neighbors of first node 1013. Dead node 1031 is a neighbor with node 1034, which is not a neighbor of first node 1013.

[00104] When the connection status message 1021 is received from the flood topology connection 1016, the first node 1013 sends the connection status message 1022 (a copy of the message 1021) to the neighbors of the first 1013 over the connections of flood topology 1016, excluding the flood topology connections 1016 from which the connection status message 1021 was received. This ensures that the new connection status message 1021 is properly transferred over the flooding topology. The first node 1013 also sends the connection status message 1023 (another copy of the message 1021) to the nodes 1033 that are neighbors of both the first node 1013 and the dead node 1031. Such connection status messages 1023 are sent over the connections 1017 that attach the first node 1013 to the nodes 1033, even though such connections 1017 are not included in the flood topology. This mechanism 1000 considers that neighboring nodes 1033 can rely on the down node 1031 for connection status messages 1021. Thereby, the first node 1013 notifies the neighboring nodes 1033 of the down node 1031 to ensure that the connection status message 1021 be propagated to such nodes 1033. The first node 1013 may not transfer the connection state message 1021 to the remaining neighbor node 1034 of the dead node 1031, because the node 1034 is not a neighbor of the first node 1013. The mechanism relies on a neighbor of node 1034 to inform node 1034 that the dead node 1031 is not operational. This proposal prevents every node in the network from contacting every other node when a dead node 1031 fails.

[00105] As such, the first node 1013 may receive a connection status message 1021 (e.g., a third connection status message to distinguish it from other connection status messages discussed herein) that indicates that a second node is down 1031 on the network is dead. The first node 1013 can then flood the connection status message 1021 to the connections 1017 that are excluded from the flooding topology and connect between the first node 1013 and the neighboring nodes 1033 of the dead node 1031.

[00106] Figure 11 is a schematic diagram of another exemplary flooding mechanism 1100 employed when discovering that a node is defective (eg, is down). Flooding mechanism 1100 operates over an IGP network, such as IGP network 100, 200, and/or 300. Flooding mechanism 1100 is illustrated with respect to a first node 1113, which can be any node in a network. IGP network (e.g., node 111, 211, 212, 213, 311, 312, and/or 400) that employs a flooding topology, such as flooding topology 219 and/or 319. Such a flooding topology may be generated, for example, according to method 500, 600, and/or 700. Flood mechanism 1100 may be employed with flood mechanisms 800 and/or 900 when an inoperative node 1131 fails.

[00107] As shown, the mechanism 1100 operates over an IGP network with nodes 1111, a root node 1112, and a first node 1113 connected by connections 1117 and flood topology connections 1116, which are substantially similar to the nodes 1011 , root node 1012, first node 1013, connections 1017 and flood topology connections 1016, respectively. Further, a dead node 1131 fails, which is similar to the dead node 1031. Also, the network contains nodes 1133 that are neighbors of the first node 1113 and the dead node 1131, and a node 1134 that is a neighbor of the dead node 1031 and not a neighbor of the first node 1113.

[00108] Mechanism 1100 is similar to mechanism 1000, but is employed when a first node 1113 receives a new connection status message 1121 from a neighboring node over a connection 1117 that is not in the flooding topology. Connection status message 1121 contains information indicating that dead node 1131 is down/defective. In an example, first node 1113 sends connection status message 1121 to all neighboring nodes over all connections 1116 and 1117 that are connected at first node 1113, excluding connection 1117 from which connection status message 1121 was received. Such a response is substantially similar to the mechanism 800 and allows the connection status message 1121 to flood following the actual network topology. Such an example assumes that the first node 1113 is not properly receiving connection state messages over the flooding topology and takes action to ensure that the connection state message 1121 is transmitted as widely as possible.

[00109] In another example, the first node 1113 floods the connection state message 1122 (a copy of the message 1121) over the flood topology connections 1116. The first node 1113 also floods the connection state message 1122 to the nodes 1133 that are neighbors to both the first node 1113 and the dead node 1131 over connections 1117 that are not in the flooding topology. The connection status message 1122 need not be transferred back over the connection 1117 from which the connection status message 1121 was received. Further, the first node 1113 may not transfer the connection status message 1121 to the remaining neighbor node 1134 of the dead node 1131, because the node 1134 is not a neighbor of the first node 1113. connection along the flooding topology and informing the neighbors of the dead node 1131 of the failure.

[00110] In either example, the first node 1113 receives a connection state message 1121 (e.g., a third connection state message to distinguish it from the other connection state messages discussed herein) indicating that an inoperable second node 1131 on the network it's dead. The first node 1113 then floods the connection status message 1122 for the connections 1117 that are excluded from the flooding topology and connect between the first node 1113 and the neighboring nodes 1133 of the dead node 1131.

[00111] Figure 12 is a schematic diagram of an exemplary 1200 flooding mechanism employed when discovering that a 1231 connection has malfunctioned (eg, is down). Flooding mechanism 1200 operates over an IGP network, such as IGP network 100, 200, and/or 300. Flooding mechanism 1200 is illustrated with respect to a first node 1213, which can be any node in a network. IGP network (e.g., node 111, 211, 212, 213, 311, 312, and/or 400) that employs a flooding topology, such as flooding topology 219 and/or 319. Such a flooding topology may be generated, for example, according to method 500, 600, and/or 700. Flood mechanism 1200 may be employed with flood mechanisms 800, 900, 1000, and/or 1100 when a connection 1231 becomes inoperative/faulty .

[00112] As shown, the mechanism 1200 operates over an IGP network with nodes 1211, a root node 1212, and a first node 1213 connected by connections 1217 and flood topology connections 1216, which are substantially similar to nodes 1011 , root node 1012, first node 1013, connections 1017 and flood topology connections 1016, respectively. Also, a dead connection 1231 fails. A node 1232 is coupled to the first node 1213 across the dead connection 1231. The nodes 1233 are neighbors of both the first node 1213 and the node 1232 adjacent to the dead connection 1231. The node 1234 is a neighbor of the node 1232 (adjacent to the dead connection) , but is not a neighbor of the first node 1213.

[00113] The first node 1213 discovers that a connection 1231 is down when receiving a newest connection status message 1221 from a neighboring node, in this case a root node 1212, about a connection, in this case a flood topology connection 1216. The first node 1213 first checks to determine if the dead connection 1231 is in the flooding topology. If the 1231 dead connection is not in the flooding topology, the 1231 dead connection does not affect connection state flooding and no action needs to be taken other than transferring the 1222 connection state message (a copy of the 1221 message) through the topology of flood. In the example shown, the dead connection 1231 is in the flooding topology, so the first node 1213 proceeds to check whether the dead connection 1231 is over a neighbor interface to the first 1213. If the dead connection 1231 is not over a neighbor interface, the first node 1213 may allow nodes that are adjacent to dead connection 1231 to process any signaling, and thereby may take no action other than transferring the connection status message 1222 through the flooding topology. This proposal prevents all nodes in the network from signaling when discovering a dead connection 1231. In the example shown, the dead connection 1231 is adjacent to the first node 1213, so that the first node 1213 assumes the reasonableness of signaling to ensure that the nodes that could rely on the dead connection 1231 to continue to receive connection state information until the flooding topology can be recalculated. In this case, the first node 1213 sends the connection status message 1222 through the flood topology for each flood topology connection 1216, except for the flood topology connection 1216 from which the connection status message 1221 was received. Further, the first node 1213 sends the connection status message 1223 (another copy of the message 1221) over connections 1217 that are excluded from the flooding topology as necessary to contact the nodes 1233 that are neighbors of both the first node 1313 and the first node 1232 adjacent to dead connection 1231. Further, the first node 1213 may not transfer the connection status message 1221 to the remaining neighbor node 1234 of node 1232, because node 1234 is not a neighbor of first node 1213. This proposal allows us to 1233 that potentially rely on the connection down 1231 receive the connection state information to continue to receive such connection state information despite the broken flooding topology.

[00114] With this the first node 1213, employing the mechanism 1200, may receive a connection status message 1221 (for example, a fourth connection status message to distinguish it from other connection status messages discussed herein) which indicates that a 1231 connection (for example, a first connection) on the network is down. The first node 1213 may determine that the first connection 1213 is in the flooding topology and that the first connection 1231 is connected to the first node 1213. Based on the determination, the first node 1213 may then send the connection status message 1221 to the connections 1216 and/or 1217 that connect to neighbors which also connect to a node 1232 adjacent to the first connection.

[00115] It should be noted that when a 1231 connection over an existing/old flood topology is down or a node is down (eg as discussed in mechanisms 1000 and 1100), a new flood topology is generated shortly thereafter. Mechanisms 1000, 1100, and/or 1200 allow the existing flood topology to continue to operate until a new flood topology can be computed and employed by the nodes. The aforementioned mechanisms 1000, 1100, and 1200 allow the network to continue to function when a connection or node is down, as long as the network topology is not split into multiple fault-isolated flood topologies. Critical interfaces can be saved in memory to handle such scenarios as discussed below.

[00116] Figure 13 is a schematic diagram of an exemplary IGP network 1300 with a critical interface 1335 in the flood topology 1319. The IGP network 1300 is substantially similar to the IGP network 100, 200, and/or 300. IGP network 1300 includes nodes 1311 and a root node 1312, which may be similar to nodes 111, 211, 212, 213, 311, 312, and/or 400. The flood topology 1319 of the IGP network 1300 may be similar to flood topology 219 and/or 319. Such a flood topology 1319 may be generated, for example, according to a method 500, 600, and/or 700. Node 1311 and root node 1312 may employ the mechanisms of flood 800, 900, 1000, 1100, and/or 1200.

[00117] When computing the flood topology 1319, the nodes 1311 and root node 1312 maintain awareness of any critical interface 1335 in the flood topology 1319. A critical interface 1335 is any interface (eg, connection or node) on the topology flood 1319 which, if removed, would split the flood topology 1319 into two or more unconnected connection topologies. In the example shown, flood topology 1319 contains multiple loops of flood topology connections. When a flood topology connection in a loop is removed, the flood topology 1319 can still transfer connection state information to all nodes in the loop through the undamaged portion of the loop. With this, such connections are not critical interfaces. However, if a critical interface 1335 is removed from the flooding topology 1319, the flooding topology 1319 is split into a first tree 1341 and a second tree 1342. In the absence of the critical interface 1335, the first tree 1341 and the second tree 1342 cannot communicate connection state information since no 1319 flood topology connection would connect the two trees.

[00118] The critical interface(s) 1335 may be determined on each node 1311/1312 during/after the flood topology computation 1319 and may be saved in memory. The number of critical interfaces 1335 can be reduced by adding more leaf connections as discussed above. When a connection or node associated with a critical interface 1335 fails, nodes 1311/1312 (upon notification of the failure via connection status messages) may revert to flooding connection status messages over all interfaces until a new 1319 flood topology can be generated to resolve the critical interface failure and reconnect all 1311/1312 nodes.

[00119] With this, the nodes 1312/1311 can determine critical interfaces 1335, where an interface 1335 is a connection or node whose failure splits the flooding topology 1319. The nodes 1312/1311 can discontinue the use of the flooding topology 1319 when a critical interface 1335 fails.

[00120] Figure 14 is a schematic diagram of an exemplary OSPF v2 encoding 1400 to indicate node support for LSFR. For example, a node, such as node 111, 211, 212, 213, 311, 312, 400, 1311, 1312, and/or 1333, in an IGP network, such as IGP network 100, 200, 300, and/or 1300, it may employ the 1400 encoding to indicate whether the node supports LSFR. Such information may be employed by other nodes when building a flooding topology, for example, based on methods 500, 600, and/or 700. OSPF v2 nodes employing LSFR, and thereby employing 1400 encoding, may also employ flood mechanisms 800, 900, 1000, 1100, and/or 1200.

[00121] The 1400 encoding can be employed to incorporate LSFR into an IGP network that is OSPF v2 compliant. Specifically, the 1400 encoding can be included in an OSPF v2 LSA. Encoding 1400 includes an LS age field 1401 adjusted to indicate a time (eg, in seconds) since the LSA originated. The age field of LSA 1401 can be sixteen bits in length and can extend from bit zero to bit fifteen. Encoding 1400 also includes an options field 1402 which may contain data indicating optional capabilities supported in a portion of a routing domain in an IGP network as described by the LSA. Options field 1402 may be eight bits long and may extend from bit sixteen through bit twenty-three. Encoding 1400 also includes an LS Type field 1403 which may be set to indicate a type of the LSA. For example, the type field of LS 1403 can be set to one to indicate that the LSA is an LSA router (eg node). The type field of LS 1403 can be eight bits long and can extend from bit twenty-four to bit thirty-one. Encoding 1400 also includes a connection state ID field 1404 which includes data identifying the portion of the Internet environment being described by the LSA. For example, the connection state ID field 1404 can be set to indicate that the LSA describes the states collected from a router's interfaces. The connection state ID field 1404 can be thirty-two bits long and can extend from bit zero to bit thirty-one. Encoding 1400 also includes an advertisement router field 1405 which contains the router ID of the router originating the LSA. Router Advertisement field 1405 may be thirty-two bits long and may extend from bit zero to bit thirty-one. Encoding 1400 also includes an LS sequence number field 1406 which contains data for identifying the LSA. The LS sequence number field data 1406 can be used to detect old or duplicate LSAs. The sequence number field of LS 1406 can be thirty-two bits long and can extend from bit zero to bit thirty-one. Encoding 1400 also includes an LS checksum field 1407 which contains checksum data to support error checking. The checksum field of LS 1407 can be sixteen bits long and can extend from bit zero to bit fifteen. Encoding 1400 also includes an LS length field 1408 which contains data indicating the length of the LSA in bytes. The length field of LS 1408 can be sixteen bits long and can extend from bit sixteen to bit thirty-one.

[00122] The 1400 encoding also includes several flags employed to indicate various characteristics to the router initiating the LSA. The encoding may include a virtual flag (V) 1421 at bit position five, which may be set to indicate when the router is at an endpoint for one or more adjacent virtual connections. The encoding may also include an external flag (E) 1422 at bit position six, which may be set to indicate when the router is an autonomous system boundary router. The encoding may also include a border flag (B) 1423 at bit position seven, which may be set to indicate when the router is a border area router.

[00123] Encoding 1400 also includes an F flag 1431. The F flag 1431 may be one bit and may be positioned at bit position eight. Flag F 1431 can be set (eg, set to one) to indicate that the router initiating the LSA supports flood mitigation (eg, in accordance with the LSFR mechanisms discussed here). The bit position of the F flag 1431 can also be unset (eg, set to zero) by default so that routers that do not support LSFR can be identified by routers that receive the LSA. As such, the 1400 encoding allows connection state messages that contain F flags set to indicate nodes on the network that support connection state flooding reduction across a flooding topology.

[00124] The encoding 1400 also includes a number of connections fields 1409 that indicate the number of connections described by the LSA. The number of connection fields 1409 can be sixteen bits in length and can extend from bit position sixteen to bit position thirty-one. Encoding 1400 also includes a Connection ID field 1410 for each connection described by the LSA. Connection ID field 1410 includes an ID that identifies the object (eg node) to which the corresponding connection is connected. Connection ID field 1410 can be thirty-two bits long and can extend from bit zero to bit thirty-one. Encoding 1400 also includes a connection data field 1411 for each connection described by the LSA. Connection data field 1411 includes address information (eg IP address information) relating to the corresponding connection/interface. Connection data field 1411 may be thirty-two bits long and may extend from bit zero to bit thirty-one.

[00125] The 1400 encoding also includes a 1412 type field for each connection described by the LSA. Type field 1412 contains data describing the router connection. The type 1412 field can be eight bits long and can extend from bit zero to bit seven. The encoding 1400 also includes a number of Type of Service (ToS) fields 1413 for each connection described by the LSA. ToS field number 1413 indicates a number of ToS metrics for the corresponding connections that are included in the LSA. ToS field number 1413 can be eight bits long and can span from bit eight to bit fifteen. Encoding 1400 also includes a metric field 1414 that includes the cost (e.g., routing cost/latency, etc.) of utilizing the corresponding connection. Metric field 1414 can be sixteen bits long and can extend from bit sixteen through bit thirty-one. Encoding 1400 may also include ToS fields 1415 and ToS metric fields 1416 that indicate ToS information associated with the corresponding connection. The ToS field 1415 indicates the type of service referred to by the ToS metric field 1416 may be eight bits long and may extend from bit position zero to bit position seven. ToS metric field 1416 may indicate specific ToS information for the connection, may be sixteen bits in length, and may extend from bit sixteen to bit thirty-one.

[00126] Figure 15 is a schematic diagram of an exemplary OSPF v3 encoding 1500 to indicate node support for LSFR. For example, a node, such as node 111, 211, 212, 213, 311, 312, 400, 1311, 1312, and/or 1333, in an IGP network, such as IGP network 100, 200, 300, and/or 1300, you can use the 1500 encoding to indicate whether the node supports LSFR. Such information may be employed by other nodes when building a flooding topology, for example, based on methods 500, 600, and/or 700. OSPF v3 nodes employing LSFR and thereby employing 1500 encoding, may also employ flood mechanisms 800, 900, 1000, 1100, and/or 1200.

[00127] The 1500 encoding can be employed to incorporate LSFR into an IGP network that is OSPF v3 compliant. Specifically, the 1500 encoding can be included in an OSPF v3 LSA. Encoding 1500 may include an LS age field 1501, an LS type field 1503, a connection state ID field 1504, an advertisement router field 1505, an LS sequence number field 1506, a LS Checksum field 1507, and a Length field of LS 1508, which may be substantially similar to the Age field of LS 1401, Type field of LS 1403, Connection Status ID field 1404, Router Advertisement field 1405, LS sequence number field 1406, LS checksum field 1407, and LS length field 1408, respectively. Unlike the type field of LS 1403, the type field of LS 1503 is sixteen bits long and extends from bit position sixteen to bit position thirty-one.

[00128] Encoding 1500 also includes an options field 1509 that can be set to indicate optional capabilities supported by the router that initiated the LSA. Options field 1509 can be thirty-two bits long and can extend from bit zero to bit thirty-one. Options field 1509 includes various flags employed to indicate various characteristics to the router initiating the LSA. Options field 1509 may include a V flag 1521, an E flag 1522, and a B flag 1523, which may be substantially similar to V flag 1421, E flag 1422, and B flag 1423, respectively. Options field 1509 may also include a wildcard (W) flag 1524 which may be set to indicate the router initiating the LSA is a wildcard multicast receiver. W flag 1524 can be one bit long and can be positioned at bit position four.

[00129] Options field 1509 also includes an F flag 1531. The F flag 1531 may be one bit and may be positioned at bit position eight. Flag F 1531 can be set (eg, set to one) to indicate that the router initiating the LSA supports flood mitigation (eg, in accordance with the LSFR mechanisms discussed here). The bit position of the F flag 1531 can also be unset (eg, set to zero) by default so that routers that do not support LSFR can be identified by routers that receive the LSA. As such, encoding 1500 allows connection state messages to contain F flags set to indicate nodes on the network that support connection state flood mitigation through a flooding topology.

[00130] Coding 1500 may also include a type field 1512 and a metric field 1514 for each connection described by the LSA. Type field 1512 and metric field 1514 may be substantially similar to type field 1412 and metric field 1414, respectively. Encoding 1500 may also include an Interface ID field 1510, a Neighbor Interface ID field 1515, and a Neighbor Router ID field 1516 for each connection described in the LSA. Interface ID field 1510, Neighbor Interface ID field 1515, and Neighbor Router ID field 1516 may each be thirty-two bits in length and extend from bit position zero to bit position thirty-one. . Interface ID field 1510 indicates an assigned ID for the interface (eg connection) being described. The neighbor interface ID field 1515 indicates an interface ID of the neighbor router coupled on the connection being described. The neighbor router ID field 1516 indicates the router ID of the neighbor router coupled in the connection being described.

[00131] Figure 16 is a schematic diagram of an exemplary IS-IS encoding 1600 to indicate node support for LSFR. For example, a node, such as node 111, 211, 212, 213, 311, 312, 400, 1311, 1312, and/or 1333, in an IGP network, such as IGP network 100, 200, 300 , and/or 1300, may employ IS-IS encoding 1600 to indicate whether the node supports LSFR. Such information may be employed by others when constructing a flooding topology, for example, based on methods 500, 600, and/or 700. IS-IS nodes employing LSFR and thereby employing 1600 encoding, may also employ flood mechanisms 800, 900, 1000, 1100, and/or 1200.

[00132] The 1600 encoding can be employed to incorporate LSFR into an IGP network that is IS-IS compliant. Specifically, the 1600 encoding can be included as a TLV in an IS-IS LSP. The encoding 1600 includes a type field 1601 adjusted to indicate that the encoding is an IS-IS router capable TLV. For example, the type 1601 field can be eight bits long, can extend from bit position zero to bit position seven, and can be set to two hundred and forty-two. Encoding 1600 includes a length field 1602, which can be eight bits long, can extend from bit position eight to bit position fifteen, and can be set to indicate the length of the TLV. Length field 1602 may be set to a value between five and two hundred and fifty-five inclusive. Encoding 1600 also includes a Router ID field 1603, which is thirty-two or forty-eight bits in length, may extend from bit position sixteen to bit position fifteen or thirty-one, and contains a Router ID. router that initiates the connection status message. Encoding 1600 also includes a set of flags 1605 that indicate capabilities of the router initiating the connection status message. Flags 1605 can be eight bits long and can span from bit sixteen through bit twenty-three. Flags 1605 include a loop (D) flag 1621 which may be positioned at bit position twenty-two, and may be set to indicate whether the TLV may be leaked between levels in the IS-IS system. Flags 1605 also include a set(S) flag 1622 which may be positioned at bit position twenty-three, and may be set to indicate whether the TLV is flooding across the entire IS-IS network domain or contained within a level specific IS-IS network.

[00133] Flags 1605 also include an F flag 1631, which may be positioned at bit position twenty-one. Flag F 1631 can be set (eg, set to one) to indicate that the router initiating the LSP supports flood reduction (eg, in accordance with the LSFR mechanisms discussed here). The bit position of the F flag 1631 can also be unset (eg, set to zero) by default so that routers that do not support LSFR can be identified by routers that receive the LSP. As such, the 1600 encoding allows control connection state messages to contain F flags set to indicate the nodes on the network that support connection state flood reduction across a flooding topology.

[00134] The encoding 1600 may also include one or more optional sub-TLVs 1606 that contain additional information relevant to the LSP.

[00135] Figure 17 is a schematic diagram of an exemplary LSFR Control TLV encoding 1700 for managing LSFR in an IGP network. For example, a node, such as node 111, 211, 212, 213, 311, 312, 400, 1311, 1312, and/or 1333, in an IGP network, such as IGP network 100, 200, 300 , and/or 1300, may receive the LSFR control TLV encoding 1700 to control the implementation of LSFR in the network. Specifically, the 1700 LSFR control TLV encoding can allow a user / system administrator to select and/or switch modes of operation for LSFR and associated flood topologies. The LSFR control TLV encoding 1700 may be employed as part of a connection status message, such as encoding 1400, 1500, and/or 1600. Such information may be employed by nodes when building a flooding topology, for for example, based on methods 500, 600, and/or 700. The LSFR control TLV encoding 1700 may also indicate to nodes when to employ LSFR flooding mechanisms 800, 900, 1000, 1100, and/or 1200.

[00136] The LSFR Control TLV encoding employing an Information TLV Type field 1701 may include data that identifies the TLV as an LSFR Control TLV. TLV type field 1701 can be sixteen bits long and can extend from bit position zero to bit position fifteen. The LSFR Control TLV encoding 1700 also employs a TLV Length field 1702 that includes data indicating the length of the LSFR Control TLV. The length field of TLV 1702 can be sixteen bits long and can extend from bit position sixteen to bit position thirty-one.

[00137] The LSFR control TLV encoding 1700 also employs an operation field (OP) 1731, which may be three bits long and may extend from bit position zero to bit position two. OP field 1731 may be used to select and/or change the LSFR mode of operation for nodes that are LSFR capable. OP field 1731 can contain data to indicate that the nodes should perform flood mitigation or it can contain data to indicate that the nodes should return to normal flooding without using a flooding topology. With this, LSFR control TLV encoding 1700 allows connection state messages to contain an OP field set to switch to full network flood connection state flood reduction. For example, a user / system administrator can employ OP field 1731 to turn LSFR on and/or off as desired.

[00138] The LSFR control TLV encoding 1700 also employs a mode (MOD) field 1732, which can be three bits in length and can extend from bit position three to bit position five. The LSFR can include three modes, including core mode, distributed mode, and static configuration mode, and MOD field 1732 can be used to signal a switch between modes. For example, MOD field 1732 can be set to central mode, which directs the IGP network to select a leader and/or backup leader. The leader then computes the flooding topology and floods the flooding topology to the other nodes. Each node receives and uses the leader's flooding topology. MOD field 1732 may also be set to distributed mode, which directs all nodes in the IGP network to compute a flood topology employing a common algorithm, as discussed above. MOD field 1732 may also be set to a static configuration mode, which directs nodes in the IGP network to employ a configured flooding topology. With this, the LSFR control TLV encoding 1700 allows connection state messages to contain a MOD field 1732 set to indicate centralized connection state flood reduction, distributed connection state flood reduction, or flood reduction statically configured connection state.

[00139] The LSFR control TLV encoding 1700 also employs an algorithm field 1733, which may be eight bits in length and may extend from bit position six to bit position thirteen. Algorithm field 1733 may contain data that indicates an algorithm for computing a flooding topology (e.g., method 500, 600, and/or 700) that is to be used by nodes in central and/or distributed mode. With this, the LSFR control TLV encoding 1700 allows connection status messages to contain an algorithm field 1733 set to indicate an algorithm for building the connection tree in the flooding topology.

[00140] The encoding 1700 may also include one or more optional sub-TLVs 1706 that contain additional information relevant to the implementation of LSFR.

[00141] Figure 18 is a schematic diagram of an exemplary TLV encoding 1800 for integrating centralized LSFR with distributed LSFR. Specifically, TLV encoding 1800 may be used in conjunction with LSFR control TLV encoding 1700, for example, when MOD field 1732 is set to center mode. The TLV encoding 1800 includes an information TLV type field 1801 and a TLV length field 1802 that are substantially similar to the information TLV type field 1701 and the TLV length field 1702, respectively. TLV encoding 1800 also includes a priority field 1803, which can be eight bits long and can extend from bit position zero to bit position seven. Priority field 1803 may be used to indicate a priority of a node originating a TLV to become a leader in the core mode. Encoding 1800 may also include one or more optional sub-TLVs 1806 that contain additional information relevant to the LSFR implementation. Such sub-TLVs 1806 may include a leader sub-TLV and/or a backup leader sub-TLV, which include a method/algorithm for selecting the leader and/or backup leader, respectively.

[00142] Figure 19 is a flowchart of an exemplary method 1900 of operating LSFR mechanisms in an IGP network. For example, method 1900 may be employed by a node, such as node 111, 211, 212, 213, 311, 312, 400, 1311, 1312, and/or 1333, in an IGP network, such as IGP 100, 200, 300, and/or 1300. Method 1900 may be employed in OSPF and/or IGP networks, and thus may be employed in conjunction with encoding 1400, 1500, and/or 1600. Method 1900 may be employed to construct a flooding topology, for example, employing methods 500, 600, and/or 700. Method 1900 may also employ flooding mechanisms, such as flooding mechanisms 800, 900, 1000, 1100, and /or 1200. Method 1800 may also be initiated by receiving an LSFR control TLV encoding 1700.

[00143] Method 1900 may be implemented over any node in an IGP network, which is denoted as a first node for purposes of clarity of discussion. At block 1901, data is received at the first node that indicates connectivity of a plurality of nodes on the network. Such data includes connection state data, and may be received, for example, in accordance with the general flood of connection state messages, such as OSPF LSAs or IS-IS LSPs.

[00144] In block 1903, the first node (and all nodes in the network) builds a flooding topology based on connectivity. The flood topology can be built by selecting one of the networks nodes as a root node, and building a tree of flood topology connections that connect the root node to the other nodes in the network. For example, block 1903 may construct a flood topology employing methods 500, 600, and/or 700. Construction of a flood topology may occur periodically and/or upon the occurrence of a condition, such as a connection failure. / node, the failure of a critical interface, etc. As discussed above, the flooding topology can be built based on the LSFR capability of the nodes, for example, as advertised in connection status messages employing the F flag. Also, the first node (and all nodes) can build the flooding topology according to an algorithm indicated in an LSFR control TLV encoding 1700 (for example, in a connection status message).

[00145] In optional block 1905, the first node may receive a request that specifies a number of leaf connections to add to the tree. The request can be a TLV included in a connection status message, for example as initiated by a user / network administrator. If a request is received, the first node (and all nodes on the network) adds the number of leaf connections to the flood topology as specified in the request. Such leaf connections are added between nodes in the network, for example, as discussed with reference to Figure 3 above. For example, leaf connections can be added to reduce the number of critical interfaces, can be added based on Connection ID / Interface ID / Node ID, etc. Before adding such leaf connections, the connection tree in the flood topology can contain a minimum number of connections to connect all nodes in the network to the root node. Leaf connections can increase the reliability of the flooding topology at the expense of slightly increasing the communication of redundant connection status messages.

[00146] In block 1907, the first node stores the flooding topology in a memory without transmitting the flooding topology to the other nodes in the network. This proposal ensures that the flooding topology is created in each node according to a pre-selected algorithm, which in turn reduces the flooding of connection state messages relative to the flooding topology.

[00147] At block 1909 the first node floods connection status messages over the flooding topology. Also, the first node does not flood connection status messages outside the flooding topology.

[00148] In option block 1911, the first node can change the flooding procedure based on changes in connection/node status. For example, the first node may employ flood mechanisms 800, 900, 1000, 1100, and/or 1200 depending on the type of changes occurring in the network. As specific examples, the first node may receive a first connection status message from a newly connected node, where the newly connected node is directly connected to the first node via a connection. The first node can then add the newly connected node into the connection tree in the flood topology until the flood topology is recomputed. As another example, the first node may receive a second connection status message over a connection that is excluded from the flooding topology. The first node can then flood the second connection status message out of the flooding topology. As another example, the first node may receive a third connection status message that indicates that a second node on the network is down. The first node can then flood the third connection state message to connections that are excluded from the flooding topology and connected between the first node and neighbors of the second node. As another example, the first node may receive a fourth connection status message that indicates that a first connection in the network is down. The first node can determine that the first connection is in the flood topology and the first connection is connected on the first node. Based on the determination, the first node can send the fourth connection state message for connections that connect to neighbors which also connect nodes adjacent to the first connection. As another example, the first node can determine critical interfaces in the network, where a critical interface is a connection or node whose failure splits the flooding topology. The first node can discontinue using the flooding topology when a critical interface fails.

[00149] Fig. 20 is an embodiment of a device 2000 for operating LSFR mechanisms in an IGP network. For example, device 2000 can be employed to implement method 1900. Further, device 2000 can be employed as a node, such as nodes 111, 211, 212, 213, 311, 312, 400, 1311, 1312, and /or 1333 in an IGP network, such as IGP network 100, 200, 300, and/or 1300. The device 2000 can be employed in OSPF and/or IGP networks, and thereby can be employed in conjunction with the encoding 1400, 1500, and/or 1600. Appliance 2000 may be employed to construct a flooding topology, for example, employing methods 500, 600, and/or 700. Appliance 2000 may also employ flooding mechanisms, such as flooding mechanisms 800, 900, 1000, 1100, and/or 1200. Device 2000 may also be controlled by receiving an LSFR control TLV encoding 1700.

[00150] The device 2000 includes a receiver module 2001, which is a means for receiving data indicating the connectivity of a plurality of nodes in the network that includes the first node. The device 2000 includes a flood topology building module 2003, which is a means for building a flood topology based on connectivity by selecting one of the nodes as a root node, and building a tree of connections connecting the node from root on the nodes in the network. The device 2000 includes a storage module 2005 which is a means for storing the flood topology without transmitting the flood topology to the plurality of nodes in the network. Device 2000 also includes a flooding module 2007 which is a means for flooding connection state messages over the flooding topology.

[00151] In one embodiment, a first node in a network includes receiving means for receiving data indicating connectivity to a plurality of nodes in the network including the first node. The first node further includes a construct means for constructing, by means of processing the first node, a flooding topology based on connectivity by selecting one of the nodes as a root node, building a tree of connections connecting the node from root at the nodes in the network, storing the flooding topology in a memory without transmitting the flooding topology to the plurality of nodes in the network, and flooding connection state messages about the flooding topology.

[00152] A first component is directly coupled to a second component when there are no intervening components, except for a line, a trail, or other means between the first component and the second component. The first component is indirectly coupled to the second component when there are intervening components other than a line, track, or other means between the first component and the second component. The term "coupled" and its variants include both directly coupled and indirectly coupled. The use of the term "approximately" means a range that includes ±10% of the subsequent number unless otherwise stated.

[00153] Although several embodiments have been provided in the present description, it can be understood that the systems and methods described could be incorporated in many other specific ways without departing from the spirit or scope of the present description. The present examples are to be considered as illustrative and not restrictive, and are not intended to be limited to the details provided herein. For example, the various elements or components may be combined or integrated into another system or certain features may be omitted or not implemented.

[00154] In addition, techniques, systems, subsystems, and methods described and illustrated in various modalities as discrete or separate may be combined or integrated with other systems, components, techniques, or methods without departing from the scope of this description. Other examples of changes, substitutions, and alterations are determinable by one skilled in the art and may be made without departing from the spirit and scope described herein.

Claims (34)

1. Method implemented by a first node in a network, characterized in that the method comprises: obtaining data indicating connectivity of a plurality of nodes in the network; computing a flooding topology according to the data indicating connectivity of the plurality of nodes, wherein the first node is selected as a leader node; sending the flooding topology, such that the flooding topology is used by nodes receiving the flooding topology to transmit a link status message about the flooding topology. 2. Method according to claim 1, characterized in that the flooding topology is a subset of a physical network topology of the network. 3. Method according to claim 1, characterized in that each node of the nodes received the flooding topology does not transmit the link status message through network connections that are excluded from the flooding topology. 4. Method according to claim 1, characterized in that the network comprises a leaf-herringbone network or a spine-leaf network. 5. Method according to claim 1, characterized in that the flood topology comprises one or more flood paths, wherein each path of the one or more flood paths comprises node information of a flood path. 6. Method according to claim 1, characterized in that the first node is selected as the leader node based on the identifier (ID) of the first node. 7. Method according to claim 1, characterized in that the first node is selected as the leader node in an Intermediate System to Intermediate System (IS-IS) area or an Open Shortest Path First (OSPF) area , where the leader node is used to compute the flooding topology for the IS-IS area or the OSPF area. 8. Method according to claim 1, characterized in that the flood topology is computed according to an algorithm. 9. Method according to claim 8, characterized in that the algorithm is obtained from an algorithm field of a received message. 10. The method of claim 1, further comprising: receiving a request specifying a number of leaf links to add to the flood topology; and adding the number of leaf links to the flood topology. 11. Method according to claim 1, characterized by the fact that links in the flood topology contain a minimum number of links to connect the plurality of network nodes to the leader node. A method according to claim 1, further comprising: receiving a first link status message over a link that is excluded from the flooding topology; and flooding the first connection status message across connections according to the flooding topology. 13. The method of claim 1, characterized in that it further comprises: receiving a second link status message indicating that a second node in the network is down; and flooding the second link status message to links connecting between the first node and neighbors of the second node. 14. Method according to claim 1, characterized in that it further comprises: receiving a third connection status message indicating that a first connection in the network is inactive; send the third link status message to links that connect to neighbors that also connect adjacent nodes to a node attached to the first link. 15. Method according to claim 1, characterized in that the connection status message is an OSPF Connection Status Announcement (LSA), or an IS Connection Status Protocol (LSP) data unit -IS. 16. Method implemented by a second node in a network, characterized in that the method comprises: receiving a flooding topology from a first node, wherein the first node is selected as a leader node in the network, wherein the flooding topology is computed by the first node; store the flood topology; transmit a link status message over the flooding topology. 17. Method according to claim 16, characterized in that the flooding topology is a subset of a physical network topology of the network. 18. Method according to claim 16, characterized in that the second node does not transmit the link status message over network links that are excluded from the flooding topology. 19. Method according to claim 16, characterized in that the net comprises a leaf-herringbone net or a herringbone-leaf net. 20. Method according to claim 16, characterized in that the flood topology comprises one or more flood paths, wherein each path of the one or more flood paths comprises node information of a flood path. 21. Method according to claim 16, characterized in that the first node is selected as the leader node based on the identifier (ID) of the first node. 22. Method according to claim 16, characterized in that the node is selected as the leader node in an Intermediate System to Intermediate System (ISIS) area or an Open Shortest Path First (OSPF) area, in which the leader node is used to compute the flooding topology for the IS-IS area or the OSPF area. 23. First node in a network, characterized in that the first node comprises: at least one processor (430); and one or more memories (432) coupled to the at least one processor (430) and storing instructions for execution by the at least one processor (430), the instructions instruct the at least one processor (430) to cause the first node to: obtain data indicating connectivity of a plurality of nodes on the network; computing a flooding topology according to the data indicating connectivity of the plurality of nodes, wherein the first node is selected as a leader node; sending the flooding topology, such that the flooding topology is used by nodes receiving the flooding topology to transmit a link status message about the flooding topology. 24. First node according to claim 23, characterized in that the flooding topology is a subset of a physical network topology of the network. 25. First node according to claim 23, characterized in that each node of the nodes received the flooding topology does not transmit the link status message over network connections that are excluded from the flooding topology. 26. First node according to claim 23, characterized in that the network comprises a leaf-herringbone network or a spine-leaf network. 27. First node according to claim 23, characterized in that the flood topology comprises one or more flood paths, wherein each path of the one or more flood paths comprises node information of a flood path. 28. Second node in a network, characterized in that the node comprises: at least one processor (430); and one or more memories (432) coupled to the at least one processor (430) and storing instructions for execution by the at least one processor (430), the instructions instruct the at least one processor (430) to cause the second node to: receive a flooding topology from a first node, wherein the first node is selected as a leader node in the network, wherein the flooding topology is computed by the first node; storing the flood topology in the one or more memories (432); transmit a link status message over the flooding topology. 29. Second node according to claim 28, characterized in that the flooding topology is a subset of a physical network topology of the network. 30. Second node according to claim 28, characterized in that the second node does not transmit the link status message over network links that are excluded from the flooding topology. 31. Second node according to claim 28, characterized in that the network comprises a leaf-herringbone network or a spine-leaf network. 32. Second node according to claim 28, characterized in that the flood topology comprises one or more flood paths, wherein each path of one or more flood paths comprises node information of a flood path. 33. System on a network, characterized in that the system comprises: a first node and a second node: wherein the first node is configured to: obtain data indicating connectivity from a plurality of nodes on the network; computing a flooding topology according to the data indicating connectivity of the plurality of nodes, wherein the first node is selected as a leader node; send the flood topology to the second node; wherein the second node is configured to: receive the flood topology from the first node; store the flood topology; transmit a link status message over the flooding topology. 34. System according to claim 33, characterized in that the node is selected as the leader node in an Intermediate System to Intermediate System (ISIS) area or an Open Shortest Path First (OSPF) area, in which the leader node is used to compute the flooding topology for the IS-IS area or the OSPF area.