Systems and methods for loop-free multi-path routing

Abstract

There is provided a system and method of maintaining loop-free paths between source and destination nodes in a computer network. The method is based on an ordering reference condition in combination with a spreading computation to when the ordering reference condition is not satisfied. When the ordering reference condition is satisfied, a node may independently change its successor node for a destination node without creating a routing loop. The spreading computation includes sending a probe containing a probing reference value to neighbor nodes, and receiving responses containing anchoring reference values from neighbours with shorter neighbor-to-destination distances. New routing paths may be established prior to receiving a response to a probe from one or all neighbor nodes.

Description

SYSTEMS AND METHODS FOR LOOP-FREE MULTI-PATH ROUTING CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This claims the benefit of, and priority to, U.S. Provisional Patent Application No. 63 / 720,989, filed November 15, 2024, the entire contents of which are incorporated herein by reference.FIELD

[0002] This disclosure relates to the design of computer communication networks. More specifically, this disclosure relates to a method, a system, processes and devices for facilitating loop-free routing in a computer communication network using distance information.BACKGROUND

[0003] In a computer network and / or the internet, data packets are routed between a source node and a destination node. The performance of a network may depend on the route selected for routing data packets from source to destination, and on the speed with which loop-free routes are established and re-established as network conditions change. The most common routing protocols used in today’s internet are based on the exchange of vectors of distances, such as Routing Information Protocol (RIP), RIP version 2 (RIPv2), and Enhanced Interior Gateway Routing Protocol (EIGRP), or topology maps, such as Open Shortest Path First (OSPF).

[0004] RIP, RIPv2 and a number of other similar routing protocols are based on the Distributed Bellman-Ford (DBF) algorithm for shortest-path computation, which suffers from the occurrence of undesirable temporary routing table loops, as well as the so-called “counting to infinity” problem, which limit their applicability to smaller scale computer networks that are required to use hop counts as the metric to measure distances to destinations.

[0005] Contrastingly, OSPF and other algorithms and protocols based on topology broadcasting are limited by the excessive communication overhead incurred inreplicating the network topology at each routing node in the network. This forces network administrators to partition the network in which the routing protocol operates into areas or clusters interconnected by a backbone area or cluster. As a result OSPF and other topology-broadcasting-based approaches involve complex solutions, in terms of the required routing configurations.

[0006] To address the above-noted limitations of DBF and topology broadcasting approaches, some routing algorithms may emphasize the determination of a shortest possible loop-free route. Some loop-free routing techniques may use destination sequence numbers to validate distances to destinations, or require routers to coordinate the updating of their distances to destinations on a multi-hop basis using diffusing computations.

[0007] There is a need for routing protocols which are scalable, efficient, and quick to respond to changes in network conditions.SUMMARY

[0008] According to an aspect, there is provided a method of maintaining loop-free paths between a source node and a destination node in a computer network, the method comprising: maintaining, in a link weight table stored in memory of said source node, a list of neighbor nodes directly connected to said source node, and a respective link weight associated with transmitting data from said source node to each of said respective neighbor nodes; maintaining, in a neighbor table stored in memory of said source node, for one or more of said neighbor nodes, a respective neighbor-to-destination distance associated with transmitting data from said respective neighbor node to said destination node; storing, in a routing table in said memory of said source node, a current source-to-destination distance associated with transmitting data from said source node to said destination node via a current loop-free routing path; storing, in said routing table of said source node, a probing reference value for said destination; storing, in said routing table of said source node, a set of successor nodes from among said neighbor nodes; determining, by said source node, whether to enter an active state based on whether an ordering reference condition is satisfied; upon entering said activestate, initiating a distributed computation to determine an ordering for said neighbor nodes and said source node with respect to said destination node; and transmitting data packets via an updated loop-free routing path after initiating said distributed computation.

[0009] According to another aspect, there is provided a non-transitory computer-readable storage medium having stored thereon computer-executable instructions that, when executed by one or more processors, cause the one or more processors to perform a method of maintaining loop-free paths between a source node and a destination node in a computer network, the method comprising: maintaining, in a link weight table stored in memory of said source node, a list of neighbor nodes directly connected to said source node, and a respective link weight associated with transmitting data from said source node to each of said respective neighbor nodes; maintaining, in a neighbor table stored in said memory of said source node, for one or more of said neighbor nodes, a respective neighbor-to-destination distance associated with transmitting data from said respective neighbor node to said destination node; storing, in a routing table in said memory of said source node, a current source-to-destination distance associated with transmitting data from said source node to said destination node via a current loop-free routing path; storing, in said routing table of said source node, a probing reference value for said destination; storing, in said routing table of said source node, a set of successor nodes from among said neighbor nodes; determining, by said source node, whether to enter an active state based on whether an ordering reference condition is satisfied; upon entering said active state, initiating a distributed computation to determine an ordering for said neighbor nodes and said source node with respect to said destination node; and transmitting data packets via an updated loop-free routing path after initiating said distributed computation.

[0010] According to still another aspect, there is provided a system for maintaining loop-free paths in a computer network, the system comprising: a source node; a destination node; said source node comprising a memory having stored thereon computer-executable instructions that, when executed by a processor of said source node, causes said source node to perform a method comprising: maintaining, in a linkweight table stored in memory of said source node, a list of neighbor nodes directly connected to said source node, and a respective link weight associated with transmitting data from said source node to each of said respective neighbor nodes; maintaining, in a neighbor table stored in said memory of said source node, for one or more of said neighbor nodes, a respective neighbor-to-destination distance associated with transmitting data from said respective neighbor node to said destination node; storing, in a routing table in said memory of said source node, a current source-to-destination distance associated with transmitting data from said source node to said destination node via a current loop-free routing path; storing, in said routing table of said source node, a probing reference value for said destination; storing, in said routing table of said source node, a set of successor nodes from among said neighbor nodes; determining, by said source node, whether to enter an active state based on whether an ordering reference condition is satisfied; upon entering said active state, initiating a distributed computation to determine an ordering for said neighbor nodes and said source node with respect to said destination node; and transmitting data packets via an updated loop-free routing path after initiating said distributed computation.

[0011] Other features will become apparent from the drawings in conjunction with the following description.BRIEF DESCRIPTION OF DRAWINGS

[0012] In the figures which illustrate example embodiments,

[0013] FIG. 1 depicts an example network in which data packets are routed from a source node to a destination node via intermediary nodes, in accordance with some embodiments;

[0014] FIG. 2 depicts example operations performed in an example network in accordance with an Ordering Reference Condition Algorithm (ORCA) routing protocol in response to a link weight changing, in accordance with some embodiments;

[0015] FIG. 3 depicts an example network topology in which one or more links fail;

[0016] FIG. 4 is a table providing simulation results for networks using OSPF, DSDV, RIPv2, and some embodiments of the ORCA protocol;

[0017] FIG. 5 is a block diagram depicting components of an example computing device, in accordance with some embodiments;

[0018] FIG. 6 is pseudocode describing example operations of a router or node incorporating the ORCA protocol, in accordance with some embodiments;

[0019] FIG. 7 is pseudocode describing example operations performed during initialization of a router or node using the ORCA protocol, in accordance with some embodiments;

[0020] FIG. 8 is pseudocode describing example operations relating to sending a “hello” message to neighboring nodes using the ORCA protocol, in accordance with some embodiments;

[0021] FIG. 9 is pseudocode describing example operations relating to processing a change in link weight using the ORCA protocol, in accordance with some embodiments;

[0022] FIG. 10 is pseudocode describing example operations relating to processing a neighbor node timeout event using the ORCA protocol, in accordance with some embodiments;

[0023] FIG. 11 is pseudocode describing example operations relating to processing a message received from a neighbor using the ORCA protocol, in accordance with some embodiments;

[0024] FIG. 12 is pseudocode describing example operations relating to processing an update using the ORCA protocol, in accordance with some embodiments;

[0025] FIG. 13 is pseudocode describing example operations relating to processing a probe using the ORCA protocol, in accordance with some embodiments;

[0026] FIG. 14 is pseudocode describing example operations relating to processing an update when in the passive state using the ORCA protocol, in accordance with some embodiments;

[0027] FIG. 15 is pseudocode depicting example operations relating to processing an update when in the active state using the ORCA protocol, in accordance with some embodiments;

[0028] FIG. 16 is pseudocode depicting example operations relating to processing a probe when in the passive state using the ORCA protocol, in accordance with some embodiments; and

[0029] FIG. 17 is pseudocode depicting example operations relating to processing a probe when in the active state using the ORCA protocol, in accordance with some embodiments.DETAILED DESCRIPTION

[0030] Many routing protocols have been proposed for digital communications networks, and in particular for wireless networks. The basic algorithms used to achieve eventual convergence to the shortest routing paths, and ensuring that routers do not create routing-table loops at any instant, are based on one or more of a) using network topology or path information, b) using destination-based sequence numbers, and / or c) using multi-hop router coordination.

[0031] Some routing protocols are based on the dissemination of partial or complete topology information, or the use of complete path information in routing updates. Such approaches are intended to avoid the non-convergence problem associated with the DBF algorithm, which can make protocols such as RIP and RIPv2 unsuitable as the scale of a network increases. Some protocols may share path information incrementally to accomplish a similar result as conveying complete path information in every update (with less overhead), and some protocols may combine the use of topology or path information with inter-neighbor coordination to prevent routing table loops from occurring.

[0032] The use of topology or path information in routing is a widely used approach at present, and can ensure eventual convergence. However, conventional topology-based techniques do not guarantee loop-free routes at every instant. As a result, some routing protocols use destination sequence numbers in an effort to ensure loop-free operation. Examples of such protocols may include Destination-Sequenced Distance-Vector (DSDV) routing, Ad-hoc On-Demand Distance Vector (AODV) routing, and Lightweight On-Demand Ad-hoc Distance Vector (LOADng) routing.

[0033] Some approaches may require routers or nodes to coordinate the updating of routing tables on a multi-hop basis (such as the Diffusing Update Algorithm (DUAL), which is the basis of EIGRP).

[0034] One approach to avoiding routing loops is the use of destination sequence numbers, which may establish a total ordering between a node and its neighbor notes with respect to each destination. In some embodiments, distributed routing algorithms which are based on distance information can be guaranteed to be loop-free through a combination of a Local Ordering Condition (LOC) and a Distributed Reordering Computation (DRC), which may be triggered when the LOC is not satisfied.

[0035] Prior loop-free distance-based routing algorithms and protocols have functioned by having each node (e.g., a router) use the LOC to determine whether the node can select a successor node (or a ‘next-hop’) independently of other nodes without creating a routing-table loop. When the LOC is not satisfied at a given node (a source node) for a given destination, the source node may initiate a DRC to re-order itself relative to its neighbor nodes while ensuring that a routing-table loop is not created. Once the DRC has been completed (or partially completed) at the source node, the LOC is satisfied and the source node may change its successor nodes independently from other nodes.

[0036] The use of Local Ordering Conditions (LOC) by nodes in a loop-free routing protocol may allow the establishment of a total ordering between a source node (e.g. a router, a switch, a network device, and the like) and its neighbor nodes (e.g.other routers, switches, network devices, and the like) with respect to each destination node known to the source router.

[0037] LOC implementations may rely on the use of an ordering reference, which is a value for a given destination which determines whether the source node may use a neighbor node as a successor node to the destination. Several different types of LOCs may be defined based on the information used to establish an ordering among network nodes. As such, ordering reference values need not be distances, and all that is required is that ordering references be consistently comparable so as to establish a ranking among nodes.

[0038] As described herein, the operator denotes the total order relation “better than," which is defined for any three values a, b, and c, such that a*£a, if acb and bcc then acc, and acb or bca or a=b. In relation to routing distances to a destination, a distance from a node a to a destination d is “better than” a distance from node b to destination d if the distance from node a to destination d is lower than the distance from node b to destination d.

[0039] Throughout this disclosure, many example embodiments refer to routers. It should be appreciated that this is not intended to be limiting, and that principles described herein may be similarly applicable to nodes, switches, network devices, and network elements more generally.

[0040] As used herein, the value of the distance from a router k to destination d is denoted by 6. The value of the distance from router q to destination d reported by router q to router k is denoted by 6^q. The value of the ordering reference at router k for destination d is denoted by 0. O’qdenotes the value of the ordering reference reported by neighbor q for destination d. The shortest-distance value from router k to destination d, taking all neighbors of router k into account, is denoted by 8^in. The weight or cost of a link from router k to neighbor q is denoted by w.

[0041] An example LOC used in a prior loop-free routing protocol is:

[0042] £OCr-. (Odkq< Ok) V ([Okq= Ok] A [8kq< 5*]) (1)

[0043] Using the notation above, a router k can select a neighbor q as a next hop for destination d only if the neighbor reports an ordering reference value Odqthat is better than router k’s own ordering reference value Od, or if the neighbor q has the same routing reference value for destination d as router q, and neighbor q has a smaller distance to destination d, 8dq, than the distance from router k to destination d, 8d.

[0044] LOC1 may apply to the use of valid destination sequence numbers by using sequence numbers created at the destination as the ordering reference values, and by defining a larger sequence number to be ‘better’ than a smaller sequence number. However, to ensure that only valid sequence numbers are used, each router must have non-volatile memory to ensure that LOC1 can be applied correctly. An LOC such as LOC1 may also apply to the user of any comparable distance-metric values (such as ordering reference values), and by defining smaller distance value to be ‘better’ than a larger distance value.

[0045] A second example LOC used in a prior loop-free routing protocol is:

[0046] £OC2: (Okq< Ok) A (8kq+ wk= 8kin) (2)

[0047] According to example LOC2, a router k can select a given neighbor q as a next hop for destination d if the neighbor q has an ordering reference value for destination d, Odq, that is better than than the router k’s own ordering reference value for destination d, Od, and if a routing path from router k to destination d via router q, is the shortest distance to the destination. LOC2 may be a valid sufficient condition to ensure loop-free routing in the context of the Diffusing Update Algorithm (DUAL) system, where Odq= 8dqand Od= fd, where fdis the feasible distance at router k for destination d.

[0048] In some embodiments, when an LOC is used with a given system, a Distributed Reordering Computation (DRC) may be initiated if any when one or more routers or nodes in a network does not satisfy the LOC. A DRC may update the orderingreference values used at each node. It may be necessary to initiate a DRC, for example, when an input event prevents one or more routers from satisfying the LOC.

[0049] A prior DRC technique may incorporate destination sequence numbers. Destination sequence numbers may be created by the destinations themselves, and can be used as ordering references that validate distance values.

[0050] The sequence number reported by router k for destination d, sn^, may be set as the ordering reference value for router k for destination d (sn') = 0%). The sequence number for destination d for neighbor q reported to router k, sn^q, may be set as the ordering reference value for neighbor q to destination d (sn’^q= O^q). Using this notation, L0Crmay be stated as:

[0051] (sn^ > sn'j) V ([sn^ = sn^] A [8%q< <?£]) (3)

[0052] Protocols such as DSDV, AODV, and other similar distance vector routing protocols may use equation (3) together with a DRC which floods the most recent sequence number created by destination d for itself. Using this system, a router that does not satisfy the LOC given by equation (3) may increase its sequence number by one, and then send an update, without changing its current choice of next hop node. However, if no next hop exists (e.g., due to a hardware failure), the distance from router k to destination d may be set to infinity. The destination d may increase its sequence number by two each time it sends a new update periodically.

[0053] Such an approach suffers from two main limitations. First, the flooding of new sequence numbers by destinations is necessary, because only the destinations can ensure that all routers receive the most recent sequence numbers over time.Second, in DSDV and AODV systems, the focus is on minimum-hop routing, and the format of equation (3) is only sufficient to ensure convergence to minimum-hop routes, but does not ensure optimal distance when link weights can vary, in the absence of additional measures.

[0054] Another known example DRC is known as a Diffusing Computation. For example, the DUAL approach is based on diffusing computations which make use of the notion of a feasible distance. The feasible distance at router k for destination d may be denoted asand is defined as the smaller value of 8 since the router k was last initialized or completed a diffusing computation for destination d. Setting Oq= 8^ and ° = f results in the following form for LOC2, which corresponds to the Source Node Condition (SNC) which is used for the DUAL approach:

[0055] ^ < ^)A^ + < = CJ (4)

[0056] While equation (4) is satisfied by at least one neighbor q, router k sends updates with router k’s distance to destination d, and router k continually updates its feasible distance to be the minimum value obtain for its own distance to destination d. When the SNC (equation (4)) is not satisfied by any neighbor of node k, router k will maintain its current next hop (if any), and updates its distance accordingly. Router k will then initiate a DRC (a diffusing computation, in the context of DUAL) by sending a query that states router k’s current distance value for destination d, and waits for all of its neighbor nodes to send replies before router k is able to change its next hop for destination d and set router k’s feasible distance to the new shortest-path distance to d.

[0057] The use of diffusing computations suffers from numerous limitations. First, establishing local ordering at the same time that new shortest paths are established may prevent routers from using loop-free paths which, although not necessarily the shortest path, could be nevertheless used for transmission while the shortest paths are being determined (which negatively impacts throughput). Second, a router that sends a query is barred from selecting a new next hop node until it has received replies from all of its neighbor nodes, irrespective of whether one or more neighbors have replied with valid loop-free routes. Third, handling multiple concurrent diffusing computations can be computationally complex, because although an active router can participate in a single computation at a time, it must also account for diffusing computations initiated by other routers, changes in link costs, and updates received from neighbors.

[0058] Some embodiments described herein relate to a design framework for loop-free routing protocols that are based on distance information, which use an LOG referred to herein as the Ordering Reference Condition (ORC) to ensure loop-free routing, and which incorporate a type of distributed reordering computation (DRC) referred to herein as a spreading computation. Embodiments of a system incorporating ORC and spreading computations may be referred to herein as an ORCA system, or a system incorporating the ORCA protocol.

[0059] In some embodiments, ORCA may be loop-free at every instant, converges to the shortest routing paths, and may use spreading computations for routing which, advantageously, do not rely on periodic signaling and thus can respond to changes in network conditions more quickly and efficiently than other prior routing protocols and strategies.

[0060] In some embodiments, a system implementing the ORC may allow router k to use a neighbor q as a successor (or next hop) for destination d if the ordering reference value for neighbor q is better than the ordering reference value for router k itself, (pdq< Ok).

[0061] Defining a set of neighbor nodes of node k as Nk, the LOG for some embodiments of ORC may be stated as:

[0062] O52C: (O^ < C$) A (v e Nk) (5)

[0063] As is proven further below, the ORC LOG is a valid sufficient condition for ensuring loop-free routing when routers or nodes change successors (or next hops) independently of other routers.

[0064] As noted above, when ORC is not satisfied, a DRC must be used to reestablish ordering reference values. In some embodiments, the DRC (referred to herein as a spreading computation) allows routers to maintain and communicate ordering reference values to establish their total ordering with respect to a destination (or each of multiple destinations) when the ORC LOG (equation (5)) is not satisfied.

[0065] In some embodiments, a router may be said to be passive, or in a passive state, if there exists at least one neighbor node that satisfies the ORC LOC. While a router k is in the passive state, the router k may select neighbor nodes that satisfy the ORC LOC as successors (or next hops) for a destination. In some embodiments, the selection of successor nodes may be performed independently from other nodes. In some embodiments, the neighbor nodes which satisfy the ORC LOC may be stored in a successor set. In some embodiments, a preferred successor node may be defined as the node in the successor set which has the shortest distance to destination d.

[0066] In some embodiments, when the ORC LOC is not satisfied at router k for destination d, router k may enter an active state (also referred to as becoming active in a spreading computation for destination d). In some embodiments, router k may begin the spreading computation be transmitting a probe which contains a probing reference 7’^, and solicits its neighbor nodes r to send a response if any of neighbor nodes r reports an anchoring reference < Adwhich is better than the probing reference (i.e. < Ad

[0067] In some embodiments, router k may maintain the value of probing reference Pdused in the probe, and router k may reorder itself relative to its neighbor nodes r after processing each response received from neighbor nodes r. In some embodiments, router k may re-enter the passive state once router k has received responses with anchoring references from all of router k’s neighbors.

[0068] In some embodiments, while router k is active in a spreading computation for destination d, router k may nevertheless use any node v as a successor (or next hop) for destination d which has either a) sent a response to the probe and reported an ordering reference that is better than router k’s own ordering reference (i.e. Odv< 0 ), or b) not sent a response to the probe from router k, but has previously reported an ordering reference value which is smaller than the probing reference value contained in the probe from router k (i.e. Od< Pd).

[0069] Thus, advantageously, a spreading computation may function more efficiently than other types of DRCs, as the spreading computation allows for a router k in the active state to nevertheless use as a successor any node which has either sent a response to the probe with a better anchoring reference value, or even use as a successor a node which has not yet responded but previously reported an ordering reference value which is better than the probing reference value. As such, in some embodiments, an active router k can independently switch to a successor node potentially without having to wait for any responses from neighbor nodes, or may independently switch to a successor node without having to wait for responses from all neighbor nodes to router k’s probe. Thus, a new routing path to destination d from router k may be established more quickly than with other protocols.

[0070] Moreover, in a DUAL system, the query message from an active router will be sent to all of router k’s neighbor nodes, and will then be propagated to the neighbors of those neighbor nodes, and so on. Contrastingly, some embodiments of the ORC system allow for active router k to send a probe to its neighbor nodes, with the intent that router k will be able to change its next hop more quickly.

[0071] Some embodiments of systems and methods for loop-free routing which make use of the ORC local ordering condition together with spreading computations as the DRC are referred to herein as ORCA systems. FIG. 1 depicts an example computer network 100 in which a source node 110 is transmitting data to destination node 120. As depicted, numerous routing paths exist between source node 110 and destination node 120, via a plurality of different intermediary nodes 112.

[0072] The following notation is used to describe some embodiments of an ORCA system:Variable Name ValueRouter and destination of interest k, dSet of neighbors of k NkLink from k to n e Nk(k, n)Weight and lifetime of link (k,n) wk, LTkLink-weight table LWTkContent of LWTkfor link (k, q) wk, LTkDistance reported by v e NksdkvCoordination flag assigned to v e Nkc^v(value of T or F) Content of neighbor table (NTk) for v e Nk udv’ r '■'dkvDistance obtained through v e Nk8dv + wkCurrent distance for d °dProbing and anchoring reference for d rpk nkSuccessor set and preferred successor for d Sd, SdNeighbor that should process update or probe nkd(0 = all)Content of routing table (RTk) for d < < S%, skUpdate or response for d U[d,6k,^k,nk]Probe for d P[d,8^,^,n^]

[0073] In some embodiments, the ordering reference value for a neighbor q of router k 110 for destination d 120, O’q, may be set to the distance reported by neighbor q to destination d 120 (i.e., O’q= 8aq). Likewise, the ordering reference value for router k 110 for destination d 120 may be set to the current distance from router k to destination d (i.e, 0 = 8^).

[0074] In some embodiments, router k may remain in a passive state for destination d 120 provided that the following ordering reference condition is satisfied by at least one neighbor node of router k:?>: (3 v e W'< < ^ ) A (^ = MI)n (9) MDj = Min{8^v+ wk\ v e Nk}6k= Min 6kv+ wk| (v e Nk) A « < 5k)}

[0075] That is, router k may select a successor node (or next hop) independently from other nodes in network 100 if router k has at least one neighbor node v which has reported a smaller distance to destination d than router k’s own distance to destination d, and one of such neighbor nodes v has a total distance from router k to destination d via neighbor v (i.e. 8^v+ w ) which is the minimum value for all neighbor nodes.

[0076] In some embodiments, while in the passive state (i.e. while equation (9) is satisfied), router k may select successor nodes for a loop-free routing path to destination d independently of other nodes.

[0077] In some embodiments, when router k is not awaiting responses to a probe message from any of its neighbor nodes (i.e., router k is in the passive state), router k may use any neighbor node vas a successor (or next hop) for destination d if the neighbor node v has reported a distance that is smaller than the distance from router k to destination d (i.e., 8^v< 8^). This is depicted, for example, in FIG. 1, which depicts that nodes in group 130 may satisfy the conditions that a) the coordination flag for the node s is False (meaning no response to a probe is required from router k), and b) the distance from node s to destination d is less than the distance from router k to destination d.

[0078] In some embodiments, if router k is in the active state and has sent a probe to neighbor nodes and is waiting for responses from at least one of its neighbor nodes, router k can nevertheless select successor nodes for destination d independently of other nodes provided the reported distance for neighbor node v to destination d is lower than the probing reference value contained in the probe (i.e. 8^v< 5’^). This is depicted, for example, in FIG. 1, which depicts that nodes in group 130 may satisfy the conditions that a) the coordination flag for the node s is true (meaning a response to a probe from router k is expected by router k), and b) the distance from node s to destination d is less than the probing reference value contained in the probe sent by router k to node s.

[0079] As depicted in FIG. 1, some nodes 140 might not satisfy the criteria for being used as successors or next hops. For example, some nodes 114 might have acoordination flag set to true (meaning router k is expecting a response to a probe), and have a distance to destination d which is greater than or equal to the probing reference value in the probe from router k. Still other nodes might have a coordination flag set to false (meaning no response is required), and have a distance to destination d which is greater than or equal to router k’s current distance to destination d.

[0080] In some embodiments, router k may send messages to neighbor nodes. For example, router k might send messages to neighbor nodes after updating the routing table of router k. In some embodiments, a message may include one or more probes and / or updates. In some embodiments, a probe from router k for destination d may include a tuple P[d,where J’j; is a probing reference value, and nktdenotes the neighbor(s) that should process the probe. In some embodiments, an update from router k for destination d may include a tuple U[d, 8%,^, no], where is an anchoring reference value.

[0081] In some embodiments, probes and updates may interact with and modify parameters within nodes 110, 112, 114, 120 of a network 100. In some embodiments, a router k 110 (or more generally, a node or network device) may include a link weight table, a routing table, and a neighbor table.

[0082] The Link Weight Table (LWTk) of router k may contain the weight (w ) and lifetime (LTk) of the link (k, q) with each neighbor q. The maximum lifetime of a neighbor entry may be a constant LT which is defined for the network 100.

[0083] The Routing Table (RTk) of router k may contain an entry for each destination d. In some embodiments, the entry for each d in RTkstates a) a distance (<5 ), b) a probing reference (7’^), c) the set of successor nodes (S^), and d) the preferred successor node (s£) in S^. In some embodiments,may be initialized as = oo at startup. If router k is in the passive state,may be set to equal the smallest anchoring-reference valuethat router k has sent in a response. If router k is active, may be set to the smallest probing-reference valuethat router k has sent in a probe.

[0084] The Neighbor Table (NTk) of router k may contain an entry for each neighbor q e Nk. In some embodiments, for each destination d, the entry for neighbor q may include 8^qand the value of a coordination flag, c^q. In some embodiments, the value of c^vis true (T) if router k requires a response from neighbor v, and is false (F) otherwise. In some embodiments, if a neighbor v has not reported any distance for d to router k, then router k may set 8^v= oo and c^v= F.

[0085] FIG. 6 is pseudocode for an example process of operating a router or node in accordance with some embodiments of the ORCA protocol. As depicted, the operational logic underlying a node or router is to be configured to handle one or more of an initialization signal being received, the transmission of a routing message when an update timer reaches 0 (UTk) (described below), a change in link weight for neighbor q, the expiry of an entry lifetime for neighbor q, and receiving a message from neighbor q.

[0086] FIG. 7 depicts example pseudocode for initializing an example router k, in accordance with some embodiments of the ORCA protocol. In some embodiments, a router k 110 may be configured to process input events once an initialization time has elapsed that is sufficiently long to ensure that all neighbor nodes have processed any previously sent routing messages from router k, and for neighbor nodes to have determined that it is not possible to communicate with router k directly (e.g., in the event of a restart after a failure). As described in the pseudocode examples provided herein, the notation ak= T is used to denote that router k can process messages, and ak= F is used to denote that router k cannot process messages.

[0087] As depicted in FIG. 7, router k may be initialized in a passive state for itself and all destinations by setting crk=T, 8k= 0, = 0, = k, and = {k}. In some embodiments, link entries and neighbor entries are set for neighbors of router k assuming infinite distances. In some embodiments, an infinite distance and an empty successor set may be set for a destination which does not have a routing table entry. In some embodiments, router k may create a ‘hello’ message to announce router k’s presence to neighbors. In some embodiments, the hello message may include anupdate about router k. As depicted in FIG. 8, the ‘hello’ message may be sent to each neighbor of router k.

[0088] In the example embodiments described herein, it is assumed that routers and / or nodes may reliably exchange messages between one another to update routing information. A routing message from router k may contain an identifier identifying the source of the routing message (i.e. ), and a list of updates and / or probes.

[0089] In some embodiments, when router k receives a routing message from a neighbor q, router k updates the lifetime of the entry for that neighbor (LTk) and processes each update and probe included in the message. FIG. 11 depicts example steps taken by router k when router k receives a message Mqfrom neighbor node q, and FIGs. 12 and 13 describe the example steps taken by router k when processing each update or probe entry in a routing message. FIG. 8 depicts example steps taken by router k for the transmission of routing messages.

[0090] In some embodiments, router k maintains an update timer UTkto ensure that router k sends a routing message soon after router k has updated its routing table, decides to forward or respond to a query, and sends routing messages often enough to inform its neighbors of its presence. If a router k needs to send a routing message with updates, it may do so quickly using the update timer.

[0091] In some embodiments, in the absence of any changes to the routing table of router k, router k may send a ‘hello’ routing message. In some embodiments, the hello routing message may have the effect of updating the lifetime entries maintained for router k by router k’s neighbors. In some embodiments, the hello routing message may be sent no later than tmaxseconds from the time router k sent its last message. The timer tmaxmay be shorter than a maximum lifetime LT. Router k may set UTkequal to tmaxafter sending a routing message, and may set UTk= 0 after preparing updates or queries to be sent in response to an input event. In some embodiments, router k may maintain an Update Buffer (Uk) and a Probe Buffer (Pk) to store all the updates and probes to be transmitted in the next routing message when UTkequals 0.

[0092] FIG. 9 depicts example operations performed in some embodiments of an ORCA system when link-weight changes occur. As depicted, router k may update the link weight wqafter the link-weight change event, and updates its routing table RTkfor each destination d, assuming that U[d, 8dq, Jldq= 8dq,0] is received from neighbor q with the updated values in neighbor table NTkand link weight table LWTk.

[0093] In some embodiments, a link failure may be detected as a local hardware event, or through the absence of routing messages from a neighbor at the other end of the link, and a router failure may be perceived by the router’s neighbors as the absence of routing messages from the failed router. FIG. 10 depicts example operations performed by router k in the event of a link timeout with a neighbor q. As shown, the use of a lifetime LTqfor a neighbor node q may be sufficient for detecting and addressing the failure of a link caused by the neighbor q not being able to send routing messages across the link. When no routing messages have been received for LT seconds from neighbor q, the link with neighbor node q is determined to be down. When link k, q) fails, then the link weight table of router k is updated to set wq«- lm, and the routing table for router k is updated for each destination d, setting cdq«- F and dq00■

[0094] As depicted in FIG. 1, in some embodiments, an ORCA system may allow router k to use, as successor nodes 130 for destination d, the neighbor nodes from which no response is needed (i.e. the coordination flag is False) and have reported distances to destination d which are smaller than the current distance from router k to destination d. Router k may also use, as successor nodes 130 for destination d, neighbors from which a response is needed (i.e. the coordination flag is True), and have reported distances to destination d that are smaller than the probing reference value of router k (J’jf). In this manner, the response from any neighbor node is guaranteed to originate at a router / node r that offers an anchoring reference value that is smaller than the probing reference value (< Ad< J>d').

[0095] FIGs. 14-17 depict example operations which may be performed to update the routing table RTkof router k and enact the proper signaling, depending on whether router k is passive or active in a spreading computation. As depicted in FIGs. 14 and 16,router k may remain in a passive state as long as router k can obtain the shortest distance to the destination through a neighbor node that satisfies the ORC local ordering condition.

[0096] As shown in the example passive update process depicted in FIG. 14, router k may forward a response as long as the response carries an anchoring reference value that is smaller than the last anchoring reference value that was propagated by router k.

[0097] As shown in the example passive probe process depicted in FIG. 16, if router k can remain passive after receiving a probe from neighbor node v, router k sends a response if the distance reported by router k’s preferred successor is smaller than the probing reference value in the probe received from neighbor node v.Otherwise, router k forwards the probe with the same probing reference value to router k’s preferred successor.

[0098] As depicted in the example passive update and passive probe processes of FIGs. 14 and 16, if router k has to enter an active state, router k must transmit a probe to all of router k’s neighbors to search for a router / node that satisfies the ORC local ordering condition.

[0099] FIGs. 15 and 17 depict example active update and active probe processes, in accordance with some embodiments, and describe how an active router k may continue to update its distance and successor set while router k waits for pending responses to router k’s probe. As depicted, router k forwards a response it receives as long as the response states an anchoring reference value that is smaller than the value of the probing reference value in router k’s probe. In some embodiments, this may help to expediate the dissemination of responses to other active routers / nodes.

[0100] As depicted in the example active probe process of FIG. 17, an active router k may forward a probe router k has received to all of router k’s neighbor nodes, if the probing reference value is smaller than router k’s own probing reference value, and active router k updates its probing reference value to that smaller value. In essence, theactive router effectively restarts its coordination with its neighbor nodes if router k has to reduce its probing reference value.

[0101] After active router k has received the last response from router k’s neighbor nodes, router k can enter the passive state. When this happens, router k may its probing value to infinity= oo), and obtains router k’s shortest distance 8, and selects the neighbor node with the smallest distance through which router k obtains 8das the preferred successor sd. In some embodiments, an active router k may become passive when the link to the last neighbor node with a pending response fails, or when router k detects that all of its neighbor nodes have reported infinite distances (as noted in the operations of FIGs. 14 and 16).

[0102] As noted above, some embodiments of ORCA systems may ensure loop-free routing when a router changes successors or next hops independently of other routers / nodes, provided the LOC defined for ORC (i.e. equation (5)) is satisfied, as is proven below.

[0103] Let L be a routing-table loop at time t, and L =v2vhvh+1, where vh+1=For the sake of contradiction, assume that ORC is true at every router (or node) in L when at least one router in L changes its successor when it becomes part of the loop. Each router e L informs its neighbors of its distance to d at a time denoted by, where < t, and its neighbors in L use that value at a subsequent time prior to time t to determine whether ORC is satisfied. The successor (next hop) for destination d at router vtis denoted by nvdl, and the time when router vte L makes router vi+1e L a next hop to destination d is denoted by t* and t* < t. This implies that

[00104] Vv, e L([n^(t) = n^)] A [C^(t) = 0^(0) (6A)

[0105] Given that ORC is satisfied at every instant at every router or node, equation (6A) implies that:

[0106] e L(0M+) = ^(0 > = C+1(^)

[00107] = o^(ti+1) = c>^(t) ) (7A)

[0108] It can be seen that equations (6A) and (7A) are true only if

[00109] Vv,- e L(C#(t) > O^+1(t)) (8A)

[0110] However, equation (8A) must be a contradiction, because it implies thate > O^(t)), which cannot be possible. Therefore, the ORC LOC must ensure loop-free routing.

[0111] Furthermore, it can be shown that some embodiments of ORCA systems can be used to design routing protocols that ensure loop-free routing at every instant, as well as convergence to the shortest path.

[0112] It follows from the above-noted proof that no path can be a loop if every router in the path remains passive when selecting a successor along the path using probes, which follows from the ORC local ordering condition. Therefore, the remainder of this proof establishes that active routers and / or routers transitioning from active to passive state cannot create a loop.

[0113] According to algorithms 8 and 10 in FIGs. 13 and 15, respectively, a passive router that becomes active for destination d can keep, as a successor, a neighbor node v for which 8^v< 8which is router k’s distance just before becoming active. It therefore follows from the proof above that this cannot create a loop.

[0114] Once router k is active, router k’s successor setmay include neighbor nodes that have not sent responses, as well as neighbor nodes that have sent responses.

[0115] If a neighbor v has not sent a response to the probe from active router k, then c’v= T. It then follows from Algorithms 9 and 11 (shown in FIGs. 14 and 16) that neighbor v can be in successor setonly if 8^v< J’d, with J’j; being the value of 8 just before router k became active, and from the proof above, it follows that no loop can be formed in this case.

[0116] If neighbor v sends a response, then router k sets cdv= F. According to Algorithm 9 in FIG. 14, v can be addedto only if 8^v< 8d, and so it must then be shown that this condition cannot cause a loop.

[0117] If a router v is asked to process a probe and router v cannot send a response, then router v must forward the probe to its preferred successor (if router v remains passive), or to all of its neighbors if router v is active and v has not sent a probe with a smaller probing reference. Hence, a router that receives a probe and cannot send a response to the probe must forward the probe, or has forwarded a prior probe with a smaller probing reference.

[0118] For a router r to originate a response to the probe from router k, router r must remain passive when it processes the probe, and must have a successor s such that 8ds< min, where< J’j; because the probe from any router v forwarding the probe from router k must state< J’j;. Therefore, the response originated by any router r must state

[00119] = 8ds< Pmin< < (10)

[0120] If router q is passive and receives a response from its successor s stating Jld< Pd, then router q sets Pd= < Adand forwards the response stating < Ad= < Adeven if 8ddoes not change. If router q is active and receives a response from neighbor n stating < Ad< Pd, then it must forward the response stating Jld= < Ad. Hence, it follows from Equation (10) above that, when router k receives a response from v e Nk, the response results from the forwarding of the response originated by some passive router r, and it must be true that Jlvd= Jlrd< < J>d.

[0121] The path traversed by the response received from neighbor v and originated by a router r is loop-free, and the anchoring reference < Adequals a distance corresponding to a loop-free path that exists or existed from router r to destination d. Accordingly, the distance 8dvreported in the response from router v to router k corresponds to a loop-free path Pvdthat exists, or existed from router v to destination d.

[0122] Therefore, it has been shown that active router k cannot create a loop if it includes in Sda neighbor v that has sent a response, and hence an active router cannot create a loop by selecting successors according to Algorithm 10 in FIG. 15. Given that an active router becomes passive when all of its neighbors have sent a response to its probe, it follows that routers using ORCA cannot create routing-table loops.

[0123] Next, it can be shown that routers using ORCA protocols may converge to finite distance for all reachable destinations within a finite time after network changes stop occurring in a finite network.

[0124] Assuming that all routers in a network execute ORCA correctly, and that network changes stop occurring at time t.

[0125] Given that ORCA is loop-free (as shown above), any probe originated by a router located in the connected component C containing destination d must traverse loop-free paths, as the probe is either forwarded to all neighbors, or the preferred successor in the successor set of a router forwarding probe. Furthermore, the loop-free paths traversed by probes are finite because the connected component in which d resides is finite.

[0126] It can be shown that every router n e Ndwill learn that d is one of its neighbors within a finite time because of the underlying service assumed and the signaling of ORCA. Given that link costs are positive, 8dd= 0 < 8dand hence n must have d e Sdand d satisfies J’ at its neighbor n. Therefore, within a finite time tn> t,

[00127] Vn e ^([c^ = F] A [<5^ = 0]) (11)

[0128] Therefore, every router n e Ndcan answer any probe that it receives with a response U[d, 8d, Jld= 0,all]. It then follows that a probe P[d,8d, Pd,nd] originated at any router k e C - Ndmust reach an ordered router o that can generate a response with

[0129] The value of Jldmust percolate back to router k along a finite loop-free path Pokbecause Vn(- e Pok(Jld< PdHence, any router k e C that becomes activemust become passive within a finite time; furthermore, 8d< o° because < A°d< o° and all link weights are positive and finite. Hence, within a finite time t0.

[0130] V / c 6 £([<? < oo] A [Vv e Nk(cdv= F)]) for to> t (12)

[0131] Therefore, it has been shown that that routers using ORCA protocols may converge to finite distance for all reachable destinations within a finite time after network changes stop occurring in a finite network.

[0132] It may be further shown that each router using ORCA converges to the shortest distances for all reachable destinations within a finite time after network changes stop occurring in a finite network.

[0133] This may be shown by assuming that network changes stop occurring at time t, C is the connected component that includes destination d after time t, and that ORCA executes correctly. Let <5^[o] denote the optimum distance from router v to destination d according to the network topology.

[0134] It has been shown above that each router in C is passive and has a finite distance to d within a finite time t0> t. Assume that all routers stop making changes to their routing tables after time te> t0. It follows from Algorithms 9 and 11 in FIGs. 14 and 16 that

[00135] Vv e + w- = Min{6dq+ w- \ q E for te> t0(13)

[0136] Assume that router k e C has obtained its final distance 8d> 8d[o] at time te. From Equation (13), it follows that

[0137] 3V e Nk- Sk([< > <5k] A [8kv+ wk< 8k]). (14)

[0138] From Equation (14), it must be the case that 8dv= 8d+ e, with e > 0. This is a contradiction to the fact that all link costs are positive, because then 8dv+ wk=sa + (e+wv ) <sdw>th e + wk> 0, which implies that 6d< 6d.

[0139] Assume now that router k e C has obtained its final distance 8d<5()'[o] at time te. Given Equation (13), the neighbor v that offers the optimum distance for k cannot be in Sd. Hence,

[0140] 3V e Nk- Sk([8kv> 8k] 8 [8kv+ wk> 8k]). (15)

[0141] From Equation (15), it must be true that 8dv= 8d+ e, with e > 0. This is also a contradiction to the fact that all link costs are positive, because then 8dv+ wk= 8d+ (e+wv ) >sdw>th e + wk> 0, which implies that 8d> 8d.

[0142] It therefore follows from the above that every router in C converges to its optimum distance to d within a finite time.

[0143] It may further be shown that systems using the ORCA protocol converge to infinity for all unreachable destinations within a finite time after network changes stop occurring in a finite network.

[0144] Let U be a connected component of the finite network that does not include destination d starting at time t0. Assume that ORCA is executed correctly and that no network changes occur after time t > t0.

[0145] For the sake of contradiction, assume that all routers are passive, router nke U becomes passive and converges to 8dk< oo at time tk> t, and no routers make any routing-table changes after that time. Because 8dk(tk) < oo, nkis passive, and no routers make any routing-table changes after time tk, there is a router nk-e N'lksuch that 6^ = 8dnk^ and 8dnk~> < 8dnk<

[0146] Given that ORCA is loop-free and routers are passive and stop making routing-table changes after time tk, all routers in the loop-free path Pnknohave finite distances to d and 8d° < oo is the smallest finite distance to d reported along the path. This is a contradiction to the assumption that ORCA is executed correctly, because n0must know its neighbors within a finite time and no router in U can perceive d as its neighbor after time t.

[0147] Therefore, it has been shown that systems using ORCA protocols converge to infinity for all unreachable destinations within a finite time after network changes stop occurring in a finite network.

[0148] It should be appreciated that although certain example embodiments described herein make reference to routers, principles described herein are applicable to other types of network nodes other than routers.

[0149] In some embodiments, use of the ORCA protocol may offer performance advantages over existing techniques, such as DUAL and Ideal Link-State Routing. The following examples provide simplified illustrations of some of the benefits associated with the ORCA protocol relative to the DUAL protocol.

[0150] FIG. 2 depicts the simplified operation of the ORCA protocol through an example network containing 5 nodes (depicted as nodes a, b, c, d and e). In this simplified example, the weights of each link between nodes is assumed to be equal in both directions (e.g. the weight for (a, b) is equal to the weight for (b, a)).

[0151] In the example depicted in FIG. 2, the link weight of link (a, d) increases from 2 to 10. The distance and probing reference value for destination d are indicated as a tuple next to each node, and arrowheads on links indicate whether a node is a successor (or next hop) for destination d. In contrast to a system such as DUAL which uses a diffusing algorithm, it can be seen that an example ORCA system may allow for multiple successors for a destination. As depicted in FIG. 2, probes and updates are expressed as P[8, J’] and U[8, Jl], respectively, with the destination being node d, and the nodes that should process an update or probe are indicated by dashed arrowheads. In FIG. 2, nodes in the passive state are indicated with a solid circle, whereas active nodes are indicated by nodes with an outline. It should be noted that for the sake of simplicity, nodes are assumed to operate asynchronously, and process all input events received in a given step and send the resulting messages to neighbors after processing all the inputs.

[0152] As depicted in FIG. 2, block 200a shows the state of network routing tables when the weight of link (a, d) increases to 10. Initially, each node k has a probing reference value of infinity J’j; = oo. Because none of node a’s neighbors satisfies the ORC local order condition, node a enters the active state at block 200b and sends a probe P[10,2] to each of its neighbor nodes.

[0153] Block 200c depicts nodes d and e remaining passive and sending responses stating Jl = 0 and set J’ * = 3^ = 0 accordingly. As depicted, node b remains passive, but must forward the probe from node a to its successor (node c), and node c becomes active and forwards the probe to all of node c’s neighbors.

[0154] Blocks 200d through 200f depict each of active nodes a, b and c receiving all the necessary responses from their neighbor nodes, and all nodes returning to the passive state and converging to their shortest distances in five steps, with the final state being depicted in block 200g. Contrastingly, a conventional DUAL system using diffusing computations requires nine steps before convergence for this same network topology and change in condition.

[0155] Advantageously, it can be seen that spreading computations may result in shorter convergence times than diffusing computations because responses quickly follow the same paths traversed by the probes requesting responses, rather than replies having to traverse the reverse paths traversed by queries, as in the DUAL system. This is further emphasis in the example of FIG. 3 below.

[0156] FIG. 3 depicts a network topology scenario which illustrates further performance advantages which the ORCA protocol may provide relative to the DUAL protocol. As depicted in the network of FIG. 4, distances to destination d are shown for all nodesand nodes mLhave the same distances. With an ORCA system, if link (n cZ) fails, nodemust send a probe with a probing reference of 1 to all of its neighbors, and node m1sends a response thatand m2in turn forward upstream up to routers nhand mh. These replies may allow each nodes(j = 1,.,,h) to become passive. Hence, nodes using ORCA in this example may converge to shortest paths in h + 2 steps. In the same scenario, a DUAL system would require a query fromtopropagate h - 1 hops to nh, and the replies would have to flow all the way back tobefore all routers become passive obtain shortest paths, which would take 2h steps.

[0157] A similar result may be observed when link (nk,nk_i) fails, with ORCA systems requiring 2 + (7i - / c) steps, and DUAL systems requiring 2( / i - / c) steps.Similarly, the ideal link-state algorithm would require h steps to propagate the failure of link (nt, cZ), and max{ / c + 1, h - k + 1} steps to propagate the failure of link (nk, nk-1) in the same example. In general, ORCA may be expected to converge at least as fast as the ideal link-state protocol, because probes and responses propagate along the same paths and updates are sent only if distances change.

[0158] Performance of some example implementations of ORCA systems has been simulated and compared with various known protocols such as OSPF, RIPv2, and DSDV. In these simulations, the ns-3 network simulator was used for ORCA, off-the-shelf implementations of DSDV and RIPv2 were used in ns-3, and the Quagga implementation of OSPF was integrated into ns-3 using the ns-3 direct code execution framework. In these simulations, DSDV, RIPv2, and OSPF were run using their default, RFC-compliant configurations.

[0159] In the simulations, OSPF takes up to 40 sec to detect a failed link. RIPv2 takes 180 seconds to detect a failed link; however, an expired route remains in the RIPv2 routing table for a hold-down time of 120 seconds, and this makes the results for RIPv2 appear somewhat faster than they really are. DSDV uses a periodic update interval of 15 seconds. By contrast, a router in an ORCA system was found to detect the failure of a local link almost immediately (Algorithm 4 in FIG. 9) in addition to detecting that a neighbor is not responding after a few timeouts (Algorithm 5 in FIG. 10). There was no latency in detecting a new link in any of the protocols.

[0160] Results for two ORCA configurations (denoted as ORCA-1 and ORCA-2) are presented herein. The ORCA-1 implementation assumes timers that are comparable to EIGRP timers (e.g., LT = 15s, tmax= 5s), and the ORCA-2 implementation assumes timers that are comparable to OSPF timers (e.g., LT = 40s, = 10s). Although it will be appreciated that any set of parameters may be usedwith ORCA, the ORCA-1 and ORCA-2 implementations are provided as examples for comparative purposes.

[0161] The comparison focuses on the average time and overhead required by routers to obtain minimum-hop paths after a link failure, a link recovery, a router failure, and a router recovery. The time needed for routers to obtain shortest paths is measured from the time the input event is injected, to the first time when the routing table at each router reflects its true shortest paths. Overhead is defined as the sum of the bytes of all routing messages sent between the time when a network event occurs and the instant when shortest paths are obtained at every router.

[0162] In the link-failure experiment, a single random link is removed from the topology once it is operating in steady state, and the link-failure time includes the time to detect and recover from the link failure. In the link-recovery experiment, the network is initialized with a random missing link that is re-introduced to the network after its initial convergence. A router event corresponds to the failure or recovery of all the links adjacent to the router.

[0163] FIG. 4 provides a table presenting the results for link and router events, and each table entry represents the mean and standard deviations of 20 trials. Due to space limitations, results are presented only for the ARPANET topology of 47 routers; however, the same relative differences in performance may apply to smaller or larger random topologies, and as the network size increases, OSPF requires the topology to be organized into areas. ARPANET was used as the test topology because it is not too large for DSDV and RIPv2 to complete, and does not favor the signaling of protocols based on distances. The results in FIG. 4 may be compared with those reported for DUAL and the ideal link-state algorithm in other publications. In these simulations, all network links are equal cost with a data rate of 1 Gbps and propagation delay of 1ms.

[0164] As can be seen from FIG. 4, OSPF performs much better than RIPv2 and DSDV. The poor convergence results for RIPv2 stem from the fact that some link failures result in the “counting-to-infinity” problem, and the need for RIPv2 to use timers for the transmission of updates in order to limit route flapping. The results show that theflooding of destination sequence numbers is not efficient, because flooding relies on the periodic dissemination of new sequence numbers, and the rate with which new sequence numbers are flooded must be controlled to avoid excessive signaling traffic.

[0165] As can be seen from FIG. 4, both ORCA-1 and ORCA-2 converge faster than all of the other protocols considered in these simulations. Thhat both configurations achieve the same superior performance results in each simulation is a consequence of the routers in ORCA systems detecting failed links locally, and processing input events as soon as they are received, rather than sending updates periodically.

[0166] Thus, some embodiments of ORCA systems may be significantly faster than OSPF and the other routing protocols considered in these simulations. The reason for ORCA’s fast convergence is that ORCA does not have to wait to send routing messages periodically (as with the other protocols considered), and ORCA is loop-free at every instant. The latter fact implies that routers are allowed to send routing messages as quickly as possible, without the risk of overwhelming the network with signaling overhead.

[0167] The convergence of OSPF systems is dominated by the time needed by routers to detect link failures after routers have not received messages from neighbors for a period of time. An ideal link-state algorithm operating on an event-driven basis could result in faster convergence speeds. However, after recoveries, ORCA nevertheless incurs less signaling overhead than OSPF.

[0168] Various embodiments described herein make use of computing devices to perform various operations. FIG. 5 is a block diagram depicting components of an example computing device 502. As depicted, computing device 502 includes processor 514, memory 516, persistent storage 518, network interface 520. It will be appreciated by a person skilled in the art that a computing device 502 may include additional or fewer components than those depicted in FIG. 5, and that the example computing device 502 is merely an example.

[0169] Processor 514 may be an Intel or AMD x86 or x64, PowerPC, ARM processor, microcontroller, or the like. Processor 514 may operate under control of processor-executable software instructions stored in storage 518, and executed by processor 514 in memory 516. Memory 516 may be any suitable type of random access memory accessible by processor 514. Storage 518 may be, for example, one or more modules of memory, hard drive, or other persistent computer storage devices. Software executing on computing device 502 may include, for example, an operating system and application software configured to implement and perform various operations associated with the ORCA protocol as described herein.

[0170] Network interface 520 is capable of connecting computing devices 502 to one or more communication network and / or to one or more computing devices 502. In some embodiments, network interface 520 may include one or more wired interfaces (e.g. wired ethernet) and / or wireless radios, such as WiFi, Bluetooth, or cellular networks (e.g., GPRS, GSM, EDGE, CDME, LTE, 5G, or the like). Network interface 520 may also be used to establish virtual network interfaces, such as Virtual Private Networks (VPNs).

[0171] Various embodiments described herein may be performed by routers, network nodes, and other computing devices 502 under control of computer-executable instructions. It will be appreciated that the computer-executable instructions may take many different forms and be implemented in many different possible programming languages.

[0172] Of course, the above described embodiments are intended to be illustrative only and in no way limiting. The described embodiments are susceptible to many modifications of form, arrangement of parts, details and order of operation.Moreover, combinations of various embodiments are contemplated and within the scope of the invention. The invention is intended to encompass all such modification within its scope, as defined by the claims.

[0173] References

[0174] [1] B. Albrightson, et al., “EIGRP - A Fast Routing Protocol based on Distance Vectors," Proc. Interop ‘94, 1994.

[0175] [2] A. Arora and H. Zhang, “LSRP: Local Stabilization in Shortest Path Routing," IEEE / ACM Trans. on Networking, June 2006.

[0176] [3] J. Behrens and J. J. Garcia-Luna-Aceves, “Hierarchical Routing Using Link Vectors,” Proc. IEEE INFOCOM ’98, 1998.

[0177] [4] K. Bhargavan et al., “Formal Verification of Standards for Distance Vector Routing Protocols," Journal of the ACM, July 2002.

[0178] [5] C. Cheng et al., “A Loop-Free Extended Bellman-Ford Routing Protocol without Bouncing Effect," Proc. ACM SIGCOMM ‘89, Aug. 1989.

[0179] [6] J. Chroboczek and D. Schinazi, “The Babel Routing Protocol," 8966, IETF, Jan. 2021.

[0180] [7] S. Cicerone et al., “A New Fully Dynamic Algorithm for Distributed Shortest Paths and Its Experimental Evaluation," Proc. SEA ‘10, 2010.

[0181] [8] S. Cicerone et al., “Engineering a New Algorithm for Distributed Shortest Paths on Dynamic Networks, Algorithmica, May 2013.

[0182] [9] T. Clausen and P. Jacquet, “Optimized Link State Routing Protocol (OLSR)," RFC 3626, IETF, 2003.

[0183]

[0010] T. Clausen, U. Herberg, and M. Philipp, “A Critical Evaluation of the IPv6 Routing Protocol for Low Power and Lossy Networks (RPL),” Proc. IEEE WiMob ‘11, Oct. 2011.

[0184]

[0011] T. Clausen, J. Yi, and Ulrich Herber, “Lightweight On-demand Ad hoc Distance-vector Routing - Next Generation (LOADng): Protocol, Extension, and Applicability," Computer Networks, 2017.

[0185]

[0012] J. A. Cobb, “Convergent Multi-Path Routing," Proc. IEEE ICNP 2000, Nov. 2000.

[0186]

[0013] G. D’Angelo et al., “Engineering a New Loop-Free Shortest Path Routing Algorithm," Proc. SEA ‘12, Sep. 2012.

[0187]

[0014] E. Gafni and D. Bertsekas, “Distributed Algorithms for Generating Loop-Free Routes in Networks with Frequently Changing Topologies," IEEE Trans. Communications, Jan. 1981.

[0188]

[0015] J. J. Garcia-Luna-Aceves, “Loop-Free Routing Using Diffusing Computations," IEEE / ACM Trans. Networking, 1993.

[0189]

[0016] J. J. Garcia-Luna-Aceves and J. Behrens, “Distributed, Scalable Routing based on Vectors of Link States," IEEE JSAC, Oct. 1995.

[0190]

[0017] J. J. Garcia-Luna-Aceves and S. Murthy, “A Path-Finding Algorithm for Loop-Free Routing,” IEEE / ACM Trans. Networking, Feb. 1997.

[0191]

[0018] J. J. Garcia-Luna-Aceves and M. Spohn, “Scalable Link-State Internet Routing," Proc. IEEE ICNP ‘98, Oct. 1998.

[0192]

[0019] J. J. Garcia-Luna-Aceves, “RIPPLE: Loop-Free Multi-Path Routing with Minimum Blocking during Convergence," 2022 IEEE Future Networks World Forum (FNWF) Symposium on Next-Generation Networking & Internet, Oct. 2022.

[0193]

[0020] C. L. Hedrick, “Routing Information Protocol" RFC 1058, 1988.

[0194]

[0021] International Organization for Standardization, International Standard ISO / IEC 10589:2002(E), 2002.

[0195]

[0022] J. M. Jaffe and F. M. Moss, “A Responsive Routing Algorithm for Computer Networks,” IEEE Trans, on Communications, July 1982.

[0196]

[0023] D. B. Johnson and D. A. Maltz, “Dynamic Source Routing in Ad Hoc Wireless Networks," Mobile Computing, Chapters, Kluwer Academic Publishers, 1996.

[0197]

[0024] M. Kamali, M. Merro, and A. Dal Corso, “AODVv2-16: Performance vs. Loop Freedom," Proc. SOFSEM 2018 (LNCS, volume 10706), 2018.

[0198]

[0025] Y. Liao et al., “ Reliable Interdomain Routing Through Multiple Complementary Routing Processes,” Proc. ACM CoNEXT ‘08, 2008.

[0199]

[0026] G. Malkin, “RIP Version 2" RFC 2453, 1998.

[0200]

[0027] J. M. McQuillan, I. Richer, and E. C. Rosen, “The New Routing Algorithm for the ARPANET," IEEE Trans. Communications, 1980.

[0201]

[0028] P. M. Merlin and A. Segall, “A Failsafe Distributed Routing Protocol,” IEEE Trans, on Communications, Sept. 1979.

[0202]

[0029] J. Moy, “OSPF Version 2" RFC 2328, 1998.

[0203]

[0030] K. S. Namjoshi and R. J. Trefler, “Loop Freedom in AODVv2," Proc. FORTE ‘15, June 2015.

[0204]

[0031] A. Nasipuri and S. R. Das, “On-Demand Multipath Routing for Mobile Ad Hoc Networks," Proc. IEEE ICCCN ‘99, Oct. 1999.

[0205]

[0032] V. Park and M. S. Corson, “A Highly Adaptive Distributed Routing Algorithm, Proc. IEEE INFOCOM ‘97, April 1997.

[0206]

[0033] C. E. Perkins and P. Bhagwat, “Routing over Multihop Wireless Network of Mobile Computers," Proc. ACM SIGCOMM ‘94, 1994.

[0207]

[0034] C. E. Perkins and E. M. Royer, “Ad-Hoc On-Demand Distance Vector Routing," Proc. IEEE WMCSA ‘99, 1999.

[0208]

[0035] B. Rajagopalan and M. Faiman, “A New Responsive Distributed Shortest-Path Routing Algorithm," Proc. ACM SIGCOMM ‘89, Aug. 1989.

[0209]

[0036] S. Ray, R. Guerin, K.-W. Kwong, and R. Sofia, “Always Acyclic Distributed Path Computation," IEEE / ACM Trans, on Networking, 2010.

[0210]

[0037] Y. Rekhter and T. Li, “A Border Gateway Protocol 4 (BGP-4),” RFC 1771, March 1995.

[0211]

[0038] D. Savage et al., “Cisco’s Enhanced Interior Gateway Routing Protocol (EIGRP)" RFC 7868, 2016.

[0212]

[0039] H. Tazaki et al., “Direct code execution: revisiting library OS architecture for reproducible network experiments,” Proc. CoNEXT ‘13, Dec. 2013.

[0213]

[0040] R. Van Glabbeek et al., “Sequence Numbers Do Not Guarantee Loop Freedom-AODV Can Yield Routing Loops," Proc. ACM MSWiM ‘13, Nov. 2013.

[0214]

[0041] S. Vutukury and J. J. Garcia-Luna-Aceves, “A Simple Approximation to Minimum-Delay Routing,” Proc. ACM SIGCOMM ‘99, Aug. 1999.

[0215]

[0042] S. Vutukury and J. J. Garcia-Luna-Aceves, “MDVA: A Distance-Vector Multipath Routing Protocol,” Proc. IEEE INFOCOM ‘01, April 2001.

[0216]

[0043] T. Winter, et al., “RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks," RFC 6550, IETF, March 2012.

[0217]

[0044] W. T. Zaumen and J. J. Garcia-Luna-Aceves, “Dynamics of Distributed Shortest-Path Routing Algorithms," Proc. ACM SIGCOMM ‘91, Sept. 1991.

[0218]

[0045] W. T. Zaumen and J. J. Garcia-Luna-Aceves, “System for Maintaining Multiple Loop-Free Paths between Source Node and Destination Node in Computer Network," U. S. Patent 5,881,243, March 9, 1999.

Claims

WHAT IS CLAIMED IS:

1. A method of maintaining loop-free paths between a source node and a destination node in a computer network, the method comprising:maintaining, in a link weight table stored in memory of said source node, a list of neighbor nodes directly connected to said source node, and a respective link weight associated with transmitting data from said source node to each of said respective neighbor nodes;maintaining, in a neighbor table stored in said memory of said source node, for one or more of said neighbor nodes, a respective neighbor-to-destination distance associated with transmitting data from said respective neighbor node to said destination node;storing, in a routing table in said memory of said source node, a current source-to-destination distance associated with transmitting data from said source node to said destination node via a current loop-free routing path;storing, in said routing table of said source node, a probing reference value for said destination;storing, in said routing table of said source node, a set of successor nodes from among said neighbor nodes;determining, by said source node, whether to enter an active state based on whether an ordering reference condition is satisfied;upon entering said active state, initiating a distributed computation to determine an ordering for said neighbor nodes and said source node with respect to said destination node; andtransmitting data packets via an updated loop-free routing path after initiating said distributed computation.

2. The method of claim 1, wherein said ordering reference condition is based on at least one of said neighbor nodes having a neighbor-to-destination distance which is less than said current source-to-destination distance, and based on a value of a sum of said link weight to said one of said neighbor nodes and said neighbor-to-destination distance.

3. The method of claim 2, wherein said value of said sum of said link weight to said one of said neighbor nodes and said neighbor-to-destination distance is the lowest among said neighbor nodes.

4. The method of claim 1, wherein said distributed computation comprises a spreading computation, said spreading computation comprising sending a probe to said neighbor nodes of said source node, said probe comprising a probing reference value for said source node to said destination.

5. The method of claim 4, wherein said one of said successor nodes in said routing table has a neighbor-to-destination distance that is lower than said current source-to-destination distance, wherein said updated loop-free routing path includes said one of said successor nodes, and wherein said transmitting said data packets via said updated loop-free routing path comprises transmitting said data packets prior to receiving responses to said probe from any of said neighbor nodes.

6. The method of claim 4, wherein said distributed computation further comprises receiving, at said source node, a response from at least one of said neighbor nodes, said response including an anchoring value that is less than said probing value.

7. The method of claim 6, wherein a response from one of said neighbor nodes contains an anchoring value that is less than said probing value, and wherein said updated loop-free routing path includes said one of said neighbor nodes having said anchoring value that is less than said probing value.

8. The method of claim 7, wherein said transmitting data packets via said updated loop-free routing path begins without having received a response to said probe from all of said of said neighbor nodes.

9. The method of claim 1, wherein said source node enters a passive state upon receiving responses to said probe from each of said neighbor nodes.

10. The method of claim 1, wherein said source node is configured to participate in multiple distributed computations simultaneously.

11. The method of claim 1, wherein said source node is configured to transmit a routing message to said neighbor nodes, said message comprising at least one or more probes and / or updates.

12. The method of claim 1, further comprising setting a coordination flag for each of said neighbor nodes at said source node upon entering said active state, each of said coordination flags indicative of whether a response to a probe is required from a respective neighbor node.

13. The method of claim 1, further comprising receiving an input event at said source node.

14. The method of claim 13, wherein said input event is one of a probe or an update from one of said neighbor nodes.

15. The method of claim 13, wherein said input event represents a change to a link weight value of a neighbor node, and said method further comprises said source node responding to said input event by:setting said link weight for said neighbor node to an updated value in said link weight table; anddetermining whether to enter said active state based on whether said ordering reference condition is satisfied.

16. The method of claim 1, wherein when said ordering reference condition is satisfied, selecting, by said source node, one or more successor nodes independently of said neighbor nodes.

17. A non-transitory computer-readable storage medium having stored thereon computer-executable instructions that, when executed by one or more processors, cause the one or more processors to perform a method of maintaining loop-free paths between a source node and a destination node in a computer network, the method comprising:maintaining, in a link weight table stored in memory of said source node, a list of neighbor nodes directly connected to said source node, and a respective link weight associated with transmitting data from said source node to each of said respective neighbor nodes;maintaining, in a neighbor table stored in said memory of said source node, for one or more of said neighbor nodes, a respective neighbor-to-destination distance associated with transmitting data from said respective neighbor node to said destination node;storing, in a routing table in said memory of said source node, a current source-to-destination distance associated with transmitting data from said source node to said destination node via a current loop-free path;storing, in said routing table of said source node, a probing reference value for said destination;storing, in said routing table of said source node, a set of successor nodes from among said neighbor nodes;determining, by said source node, whether to enter an active state based on whether an ordering reference condition is satisfied;upon entering said active state, initiating a distributed computation to determine an ordering for said neighbor nodes and said source node with respect to said destination node; andtransmitting data packets via an updated loop-free routing path after initiating said distributed computation.

18. A system for maintaining loop-free paths in a computer network, the system comprising:a source node;a destination node;said source node comprising a memory having stored thereon computerexecutable instructions that, when executed by a processor of said source node, causes said source node to perform a method comprising:maintaining, in a link weight table stored in said memory of said source node, a list of neighbor nodes directly connected to said source node, and a respective link weight associated with transmitting data from said source node to each of said respective neighbor nodes;maintaining, in a neighbor table stored in said memory of said source node, for one or more of said neighbor nodes, a respective neighbor-to- destination distance associated with transmitting data from said respective neighbor node to said destination node;storing, in a routing table in said memory of said source node, a current source-to-destination distance associated with transmitting data from said source node to said destination node via a current loop-free path;storing, in said routing table of said source node, a probing reference value for said destination;storing, in said routing table of said source node, a set of successor nodes from among said neighbor nodes;determining, by said source node, whether to enter an active state based on whether an ordering reference condition is satisfied;upon entering said active state, initiating a distributed computation to determine an ordering for said neighbor nodes and said source node with respect to said destination node; andtransmitting data packets via an updated loop-free routing path after initiating said distributed computation.

Images