Micro-loop avoidance in networks

Systems and methods for micro-loop avoidance include detecting a remote link failure in a network and identifying an associated Point of Local Repair (PLR); determining destinations in the network that are impacted due to the remote link failure; and installing of a temporary tunnel to the PLR. The steps can further include sending traffic destined for nodes impacted by the remote link failure via the temporary tunnel to the PLR. The temporary tunnel can be implemented by a node Segment Identifier (SID) for the PLR.

FIELD OF THE DISCLOSURE

The present disclosure generally relates to networking. More particularly, the present disclosure relates to systems and methods for micro-loop avoidance in networks that utilize tunneling mechanism, for e.g., in Multiprotocol Label Switching (MPLS) networks.

BACKGROUND OF THE DISCLOSURE

Micro-loops are a standard problem in network topologies, there are IETF RFCs and drafts that address this problem. RFC 5715, A Framework for Loop-Free Convergence, January 2010, the contents of which are incorporated by reference, defines micro-loops, namely a micro-loop is a packet forwarding loop that may occur transiently among two or more routers in a hop-by-hop packet forwarding paradigm. RFC 8333, Micro-loop Prevention by Introducing a Local Convergence Delay, March 2018, the contents of which are incorporated by reference, is an IETF standard that provide a simple solution to solve micro-loops caused by local link failures. Of note, RFC 8333 can only address micro loops caused due to local link failures. The IETF draft tools.ietf.org/pdf/draft-bashandy-rtgwg-segment-routing-uloop-11.pdf does have solutions for remote link faults, however it involves P & Q space calculations which has high complexity.

BRIEF SUMMARY OF THE DISCLOSURE

The present disclosure relates to systems and methods for micro-loop avoidance in networks that utilize tunneling mechanism, e.g., in Multiprotocol Label Switching (MPLS) networks. Specifically, the present disclosure addresses micro-loops due to remote link failures. This approach utilizes a simplified tunneling mechanisms with minimal overhead. The ingenuity of the proposed solution lies in its efficiency—the overhead/footprint of the solution is small while we gain much from it in terms of traffic loss seen during convergence. This helps to meet customers Service Layer Agreement (SLA) requirements, and cleverly utilizes local micro-loop avoidance solutions at the Point of Local Repair (PLR) to handle micro-loops caused due to remote link faults also. Through this solution, if a remote link fails, traffic can leverage existing loop-free backups at the PLR nodes and tunnel its way to reach the destination in a loop-free manner during convergence, thus resulting in minimal to no traffic loss due to micro-loops.

In various embodiments, the present disclosure includes a method having steps, a node including a plurality of ports, switching circuitry, and a controller configured to implement the steps, and a non-transitory computer-readable medium having instructions stored thereon for programming a node to perform the steps.

The steps can include detecting a remote link failure in a network and identify an associated Point of Local Repair (PLR), determining destinations in the network that are impacted due to the remote link failure, and causing installation of a temporary tunnel to the PLR. The steps can further include sending traffic destined for nodes impacted by the remote link failure via the temporary tunnel to the PLR. The temporary tunnel can be implemented by a node Segment Identifier (SID) for the PLR. The temporary tunnel can be implemented for a predetermined time period, and wherein the steps further include deleting the temporary tunnel upon expiry of the predetermined time, wherein the predetermined time is selected to ensure convergence at nodes in the network. A delay timer can be used for updating its routing table and the delay timer is less than any delay timer at the PLR. The PLR can implement RFC 8333 micro-loop avoidance on packets received via the temporary tunnel. The remote link failure can be identified by Interior Gateway Protocol (IGP) flooding and the PLR is identified as closest to the remote link failure. The steps can further include implementing a heuristic to identify which traffic was impacted by the remote link failure.

DETAILED DESCRIPTION OF THE DISCLOSURE

The present disclosure relates to systems and methods for micro-loop avoidance in networks that utilize tunneling mechanism, e.g., in Multiprotocol Label Switching (MPLS) networks. Specifically, the present disclosure addresses micro-loops due to remote link failures. This approach utilizes a simplified tunneling mechanisms with minimal overhead. The ingenuity of the proposed solution lies in its efficiency—the overhead/footprint of the solution is small while we gain much from it in terms of traffic loss seen during convergence. This helps to meet customers Service Layer Agreement (SLA) requirements, and cleverly utilizes local micro-loop avoidance solutions at the Point of Local Repair (PLR) to handle micro-loops caused due to remote link faults also. Through this solution, if a remote link fails, traffic can leverage existing loop-free backups at the PLR nodes and tunnel its way to reach the destination in a loop-free manner during convergence, thus resulting in minimal to no traffic loss due to micro-loops.

1) When a router learns of a remote link failure, it identifies the PLR closer to itself. 2) It identifies the destinations whose path has changed due to this remote link failure. 3) The router calculates and installs a temporary tunnel for “N” seconds/milliseconds in data plane to steer the traffic destined for the impacted prefixes towards the PLR. This tunneling is achieved by adding on the Node Segment Identifier (SID) of the PLR and sending it via the right interface to the PLR. Once “N” expires, the temporary tunnel is deleted, and post converged paths are installed in data plane. By this time, all the nodes have converged and traffic loss due to micro-loops are avoided. In this manner, the RFC 8333 solution on the PLR is leveraged from remote nodes in the topology to avoid micro-loops around the ring. 4) We also ensure that on the PLR where RFC 8333 is applied, the timers run longer than the timers running on the other nodes—this is to account for the additional time required for tunneling.

Background and Problem Statement

In network topologies, different routers will converge at different times, and we cannot assume ordered convergence. This is because there are various factors that impact when Shortest Path First (SPF) runs trigger—such as the system capabilities, scale on the device, SPF timers, timing of received Label Switched Paths (LSPs)/Link State Advertisements (LSAs), etc. Due to this, micro-loops will occur at convergence time which lead to traffic loss.

When a link fails in a network there are two phases:

Traffic loss due to micro-loops occurs at the convergence phase. Hence, in addition to deploying effective solutions for fast switchover (such as using protocols like BFD and/or other lower layer mechanisms), we also need to implement solutions to address micro-loops. Only then can we effectively achieve a stable, no-to-minimal traffic loss in MPLS networks with Fast Reroute (FRR) capabilities.

IETF RFC 8333 Solution for Local Micro-Loop Avoidance

FIG.1is a network diagram of an example network10for illustrating local micro-loop avoidance. The network10includes a topology with Segment Routing and Topology-Independent Loop-Free Alternate (TI-LFA) enabled. The network10includes a plurality of nodes12(labeled nodes12-1to12-6). The nodes12can be referred to as network elements, routers, etc. In this example, the node12-3is a source and the node12-4is a destination with a primary path14and a backup path16. For illustration purposes, each link18has a default metric, e.g.,10, except for a link18-1between the nodes12-4,12-5whose metric is 100. The primary path14is Node12-3→Node12-2→Node12-1→Node12-4. The backup path16is Node12-3→Node12-6→Node12-5→Node12-4. Those skilled in the art will recognize other topologies and network configurations are contemplated. Also, the high link metric is shown on the link18-1to make the example easier to illustrate.

Since the link18-1has a high metric, a TILFA backup will be calculated at Node12-3for Destination Node12-4. There are TILFA backups calculated on Node12-2and Node12-1as well for destination Node12-4.

InFIG.1, if a link18-2between the Nodes12-3,12-2goes down, the routers can converge in different order and can cause micro-loops20. This is because in the original closed ring topology, prior to the link fault, the primary path from the Node12-6to Node12-4is clockwise via Node12-3. Similarly, the pre-fault primary path from Node12-5to Node12-4is via Node12-6. This is due to the high metric link18-1. When the Node12-3-Node12-2link18-2fails, Node12-3may converge soon after SPF and start sending traffic to Node12-6to reach Node12-4. If Node12-6is slow to run SPF, it will send the traffic back to Node12-3for destination Node12-4. Once Node12-6converges, it will send traffic to Node12-5for destination Node12-4. If Node12-5is slower, traffic is routed back to Node12-6for destination Node12-4. In this manner transient micro-loops20can occur throughout the ring until all the routers are converged.

The solution illustrated in RFC 8333 is thus: When a node12identifies a local link fault scenario, as part of the switchover phase, lower layers/protocols (such as Bidirectional Forwarding Detection (BFD)) identify the fault and trigger a fast switchover.

In this example, we consider Node12-3-Node12-2link18-2failure. With RFC 8333 solution enabled on Node12-3, even after it runs SPF due to the Node12-3-Node12-2fault, it will not program it's post converged route into the data plane for “N” seconds. (N is a configurable value we call rib-update-delay). Node12-3may update the control plane tables with the post converged paths, but it will hold off on pushing the update to data plane. Thus, the traffic will run on the loop-free backup path from Node12-3to Node12-4for a longer period of time. Once “N” seconds/milliseconds have elapsed, Node12-3will program the new converged path into data plane: which is Node12-3→Node12-6→Node12-5→Node12-4. At this point there is no more backup on the ring.

Limitations of RFC 8333

RFC 8333 only addresses micro-loops caused by local link down failures. Remote link failures can also cause micro-loops as seen inFIG.2. Here, link18-3between Nodes12-1,12-4link has gone down, and Node12-1will kick off its RFC 8333/Local Micro-loop solution which will help traffic running from Node12-1to Node12-4.

However, for traffic streams running from Node12-3to Node12-4, this does not help, since micro-loops can occur round the ring topology based on convergence. Once again, this is because for routers at the Nodes12-2,12-3,12-6and12-5, the pre-fault path to reach Node12-4is clockwise, and it takes time for all the routers to learn of and run SPF in response to the link18-3failure.

Other Approaches with Consideration of Micro-Loops at Remote Nodes.

A draft of Micro-loop avoidance using SPRING available online at datatracker.ietf.org/doc/html/draft-hegde-rtgwg-microloop-avoidance-using-spring/ (“draft”) (Jul. 3, 2017), the contents of which are incorporated by reference in their entirety, discusses an approach of shipping traffic to the PLR node in link down and link up scenarios. For link down, the above draft re-directs to the near-end PLR. For Link up, the above draft redirects to the near-end PLR, but without using the adjacency SID of the link that's coming up. Additionally, the draft appears to use a simple next-hop change check to screen for impacted prefixes. Also, the draft appears to use a single timer value at both PLR nodes and remote nodes.

The present disclosure builds upon the draft as described as follows.

In our new proposed solution, the following stages can occur:

1) Identification of Link Down and Detection of Nearer End: A router detects that a remote link has gone down and runs logic to identify the closer end of the link and the farther end of the link by measuring the distance to the nearer and farther end of the link. InFIG.3A, Node12-3will detect the Node12-1-Node12-4Link18-3down (via Interior Gateway Protocol (IGP) flooding) and will deduce that Node12-1is the closer endpoint to itself. Node12-1is identified as the PLR. In the event that both ends of the link are seen to be equidistant from this router, no action is taken by this proposal.

2) Identification of Impacted Prefixes: Node12-3runs SPF and identifies all the routes that have changed as a result of the link fault between Node12-1-Node12-4. Running Djikstra's algorithm on Node12-3(with itself as root) during SPF calculation reveals that next-hops to Node12-2, Node12-1, Node12-6, Node12-5have not changed, since the most optimal path to reach these nodes have not changed, even without the Node12-1-Node12-4link. Dijkstra's run in the SPF reveals that the new path to reach Node12-4is through Node12-6and Node12-5, and hence only the route towards Node12-4has changed with a new next hop of Node12-6.

It is to be noted that only prefixes that are impacted by the single link failure and those that will converge to a different path post SPF will apply this tunneling mechanism. No tunnel over-ride will be applied for prefixes that did not change their next-hop or path metric post SPF. For link-down scenarios, we check that the pre-SPF next-hop to reach the destination is the same as post-SPF next-hop to reach the PLR. Consequently, only the route to Node12-4will be identified as eligible for a Micro-loop Avoidance Protection tunnel. It is to be noted that all links and networks behind node12-4will also see a next-hop change and hence any prefixes behind (reachable through) Node12-4will also be eligible for a Micro-loop Avoidance Tunnel Protection. Consequently, network 8.8.64.0/24, which is reachable behind node4will also be protected with a Micro-loop avoidance tunnel.

3) Generation of Tunnel Labels and Installation of Tunnel Route: For impacted prefixes, Node12-3tunnels the traffic to the identified PLR for “N” seconds—a tunable rib-update-delay (Routing Information Block) timer. The rib-update-delay time is from RFC 8333 and is a delay to wait before updating the node's forwarding table and stop using RFC 8333 micro-loop avoidance. This tunneling is achieved by adding the Node SID of the PLR and using the right interface to reach it and installing this temporary path in data plane. (Penultimate Hop Popping (PHP) cases are special cases where we do not push a Node SID, however the traffic is steered by using the right interface towards the PLR). In our example here, Node12-3identifies that its path to Node12-4has changed due to the Node12-1-Node12-4fault, and the PLR is Node12-1, so Node12-3tunnels this traffic (with destination of Node12-4) to Node12-1. In this case Node12-3will push the Node-SID of Node12-1(on traffic destined to Node12-4) and sends it over the Node12-3-Node12-2link. This tunneling lasts “N” seconds. We can note that all the nodes in the topology who have determined that the path to the destination (Node12-4here) has changed due to this link failure will do the same—i.e., Nodes12-2,12-3,12-6, and12-5will tunnel their packets to Node12-1.

4) Route Handling at the PLR: Now the packets that reach Node12-1will be routed via the loop-free backup path on Node12-1towards Node12-4, thus avoiding micro-loops during convergence. (This is the RFC 8333 solution as explained in the previous section). Thus, we are leveraging the RFC 8333 solution from remote nodes also.

5) We also ensure that the rib-update-delay timer on the PLR (Here, Node12-1) runs at a longer duration than the rib-update-delay (N) on Nodes12-2,12-3,12-6,12-5in order to account for the incoming tunneling from remote nodes and thus, keep the backup on Node12-1alive for longer.

Solution—Link Up

In the case of link up, we take a similar approach, whereby, the near end of the link is located, impacted prefixes are identified and then, a Micro-loop Avoidance Tunnel is installed as the forwarding entry for such prefixes. The forwarding entry points to the near end of the link and redirects traffic over the newly brought up link at the near end of the link for a configurable timer duration of N seconds. A few salient steps are detailed below:

1) Identification of Impacted Prefixes. Node12-3runs SPF and identifies all the routes that have changed as a result of the new link up between Node12-1-Node12-4. Running Djikstra's algorithm (seeFIG.3B) on Node12-3(with itself as root) during SPF calculation reveals that next-hops to Node12-2, Node12-1, Node12-6, Node12-5have not changed, since the most optimal path to reach these nodes have not changed, even with the new Node12-1-Node12-4link. Dijkstra's run in the SPF reveals that the new path to reach Node12-4is through Node12-2and Node12-1, and hence only the route towards Node12-4has changed with a new next hop of Node12-2.

It is to be noted that only prefixes that are impacted by the link coming up and those will converge to a different path post SPF will apply this tunneling mechanism. No tunnel over-ride will be applied for prefixes that did not change their next-hop or path metric post SPF. For link-up scenarios, we ensure that the post-SPF next-hop to reach the destination is the same as the post-SPF next-hop to reach the nearer end of the link-up endpoints before installing an appropriate temporary micro=loop avoidance tunnel over-ride.

Consequently, only the route to Node12-4will be identified as eligible for a Micro-loop Avoidance Protection tunnel. It is to be noted that all links and networks behind node12-4will also see a next-hop changed and hence any prefixes behind (reachable through) Node12-4will also be eligible for a Micro-loop Avoidance Tunnel Protection—for example, network 8.8.64.0/24 behind node12-4will be protected with a micro-loop avoidance tunnel as well.

2) Route Handling at the PLR: Now the packets that reach Node12-1will be routed via the new link on Node12-1towards Node12-4, thus avoiding micro-loops during convergence. Remote nodes apply the tunnel labels for a total duration of N seconds.

Identification of Impacted Prefixes

Again, the present disclosure builds upon the approach of shipping affected traffic to the PLR node12-1in order to leverage the link switchover at the PLR node12-1and uses the following heuristic to identify which traffic was impacted by the link down event.

It is to be noted that only prefixes that are impacted by the single link failure and those that will converge to a different path post SPF will apply this tunneling mechanism. No tunnel over-ride will be applied for prefixes that did not change their next-hop or path metric post SPF.

Additionally, for link-down scenarios, we check that the pre-SPF next-hop to reach the destination is the same as post-SPF next-hop to reach the PLR.

Consequently, only the route to Node4will be identified as eligible for a Micro-loop Avoidance Protection tunnel.

It is to be noted that all links and networks behind node4will also see a next-hop change and hence any prefixes behind (reachable through) Node4will also be eligible for a Micro-loop Avoidance Tunnel Protection. Consequently, network 8.8.64.0/24, which is reachable behind node4will also be protected with a Micro-loop avoidance tunnel.

Separately Configurable Timers for Remote Nodes and PLR Nodes

Again, the present disclosure uses the general approach of shipping affected traffic to the PLR node i12-1norder to leverage the link switchover at the PLR node12-1and uses the following heuristic to identify which traffic was impacted by the link down event.

Our proposal offers separately configurable timers at remote and local PLR nodes. Using a static linear or multiplicative relationship between timers at remote nodes and at the PLR nodes can lead to a one-size-fits-all type of situation, where the timer values may not fit all situations in terms of route scale and network size. Having separately configurable timers at remote and local PLR nodes, subject to the caveat that the timer at local PLR needs to be higher than the timer at remote nodes, provides more flexibility with regard to route scale and network size.

Having separate timers at the PLR node, and remote nodes allows RFC 8333 to be implemented and enabled independent of any remote micro-loop avoidance solutions.

Identification of Network Events

When the following events occur in the network: Link up, Link down, Metric increase or decrease, LSPs or LSAs are flooded by both end-points undergoing that change. When a remote node receives these LSPs, or a local node is notified of the local event via platform notifications, we allocate a buffer of 2 to store the changes. The following logic is implemented:

1. If the cache is full with 2 LSPs or LSAs, a comparison check is run to validate that both LSPs speak of the same event.

2. If the outcome of the comparison logic in cache is different, the rib-update-delay is not started or stopped if running.

3. If another LSP or LSA is received when the cache buffer is full, the rib-update-delay is not started or stopped if running.

Using the above logic, we can identify the need to apply micro-loop-avoidance mechanisms in a simple and efficient manner.

Benefits of the Proposed Solution

The ingenuity of the proposed solution lies in how simple it is—the overhead/footprint of the solution is small while we gain much from it in terms of traffic loss seen during convergence. This helps us meet our customers SLA requirements, and cleverly utilizes local micro-loop avoidance solutions at the PLR to handle micro-loops caused due to remote link faults also. For link down, the proposal leverages the backup path installed for affected prefixes at the PLR and we recommend that this proposal be used in conjunction with TI-LFA backup generation enabled on all nodes, along with the RFC 8333 solution being enabled on all nodes.

Example Node

FIG.4is a block diagram of an example implementation of a node100, such as for any of the nodes12in the network10. Those of ordinary skill in the art will recognizeFIG.4is a functional diagram in an oversimplified manner, and a practical embodiment may include additional components and suitably configured processing logic to support known or conventional operating features that are not described in detail herein.

In an embodiment, the node100is a packet switch, but those of ordinary skill in the art will recognize the systems and methods described herein can operate with other types of network elements and other implementations that support SR networking. In this embodiment, the node100includes a plurality of modules102,104interconnected via an interface106. The modules102,104are also known as blades, line cards, line modules, circuit packs, pluggable modules, etc. and generally refer to components mounted on a chassis, shelf, etc. of a data switching device, i.e., the node100. Each of the modules102,104can include numerous electronic devices and/or optical devices mounted on a circuit board along with various interconnects, including interfaces to the chassis, shelf, etc.

Two example modules are illustrated with line modules102and a control module104. The line modules102include ports108, such as a plurality of Ethernet ports. For example, the line module102can include a plurality of physical ports disposed on an exterior of the module102for receiving ingress/egress connections. Additionally, the line modules102can include switching components to form a switching fabric via the interface106between all of the ports108, allowing data traffic to be switched/forwarded between the ports108on the various line modules102. The switching fabric is a combination of hardware, software, firmware, etc. that moves data coming into the node100out by the correct port108to the next node100. “Switching fabric” includes switching units in a node; integrated circuits contained in the switching units; and programming that allows switching paths to be controlled. Note, the switching fabric can be distributed on the modules102,104, in a separate module (not shown), integrated on the line module102, or a combination thereof.

The control module104can include a microprocessor, memory, software, and a network interface. Specifically, the microprocessor, the memory, and the software can collectively control, configure, provision, monitor, etc. the node100. The network interface may be utilized to communicate with an element manager, a network management system, the PCE 20, etc. Additionally, the control module104can include a database that tracks and maintains provisioning, configuration, operational data, and the like.

Again, those of ordinary skill in the art will recognize the node100can include other components which are omitted for illustration purposes, and that the systems and methods described herein are contemplated for use with a plurality of different network elements with the node100presented as an example type of network element. For example, in another embodiment, the node100may include corresponding functionality in a distributed fashion. In a further embodiment, the chassis and modules may be a single integrated unit, namely a rack-mounted shelf where the functionality of the modules102,104is built-in, i.e., a “pizza-box” configuration. That is,FIG.4is meant to provide a functional view, and those of ordinary skill in the art will recognize actual hardware implementations may vary.

Example Controller

FIG.5is a block diagram of an example processing device200, which can form a control module for a network element, the PCE 20, etc. The processing device200can be part of the network element, or a stand-alone device communicatively coupled to the network element. Also, the processing device200can be referred to in implementations as a control module, a shelf controller, a shelf processor, a system controller, etc. The processing device200can include a processor202which is a hardware device for executing software instructions. The processor202can be any custom made or commercially available processor, a central processing unit (CPU), an auxiliary processor among several processors associated with the processing device200, a semiconductor-based microprocessor (in the form of a microchip or chipset), or generally any device for executing software instructions. When the processing device200is in operation, the processor202is configured to execute software stored within the memory, to communicate data to and from the memory, and to generally control operations of the processing device200pursuant to the software instructions. The processing device200can also include a network interface204, a data store206, memory208, an I/O interface210, and the like, all of which are communicatively coupled to one another and to the processor202.

The network interface204can be used to enable the processing device200to communicate on a data communication network, such as to communicate to a management system, to the nodes12, the like. The network interface204can include, for example, an Ethernet module. The network interface204can include address, control, and/or data connections to enable appropriate communications on the network. The data store206can be used to store data, such as control plane information, provisioning data, Operations, Administration, Maintenance, and Provisioning (OAM&P) data, etc. The data store206can include any of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, and the like)), nonvolatile memory elements (e.g., ROM, hard drive, flash drive, CDROM, and the like), and combinations thereof. Moreover, the data store206can incorporate electronic, magnetic, optical, and/or other types of storage media. The memory208can include any of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, etc.)), nonvolatile memory elements (e.g., ROM, hard drive, flash drive, CDROM, etc.), and combinations thereof. Moreover, the memory208may incorporate electronic, magnetic, optical, and/or other types of storage media. Note that the memory208can have a distributed architecture, where various components are situated remotely from one another, but may be accessed by the processor202. The I/O interface210includes components for the processing device200to communicate with other devices.

Process

FIG.6is a flowchart of a process300implemented by a node for micro-loop avoidance. The process300contemplates implementation as a method having steps; a node including a plurality of ports, switching circuitry, and a controller configured to implement the steps; and a non-transitory computer-readable medium having instructions stored thereon for programming a node to perform the steps.

The steps include detecting a remote link failure in a network and identifying an associated Point of Local Repair (PLR) (step302); determining destinations in the network that are impacted due to the remote link failure (step304); and installing a temporary tunnel to the PLR (step306). The steps can further include sending traffic destined for nodes impacted by the remote link failure via the temporary tunnel to the PLR (step308).

The temporary tunnel can be implemented by a node Segment Identifier (SID) for the PLR. The temporary tunnel can be implemented for a predetermined time period, and wherein the steps can further include deleting the temporary tunnel upon expiry of the predetermined time, wherein the predetermined time is selected to ensure convergence at nodes in the network.

The node can have a delay timer for updating its routing table and the delay timer is less than any delay timer at the PLR. The PLR implements RFC 8333 micro-loop avoidance on packets received via the temporary tunnel. The remote link failure can be identified by Interior Gateway Protocol (IGP) flooding and the PLR is identified as closest to the remote link failure.

CONCLUSION

Moreover, some embodiments may include a non-transitory computer-readable medium having instructions stored thereon for programming a computer, server, appliance, device, at least one processor, circuit/circuitry, etc. to perform functions as described and claimed herein. Examples of such non-transitory computer-readable medium include, but are not limited to, a hard disk, an optical storage device, a magnetic storage device, a Read-Only Memory (ROM), a Programmable ROM (PROM), an Erasable PROM (EPROM), an Electrically EPROM (EEPROM), Flash memory, and the like. When stored in the non-transitory computer-readable medium, software can include instructions executable by one or more processors (e.g., any type of programmable circuitry or logic) that, in response to such execution, cause the one or more processors to perform a set of operations, steps, methods, processes, algorithms, functions, techniques, etc. as described herein for the various embodiments.

Although the present disclosure has been illustrated and described herein with reference to preferred embodiments and specific examples thereof, it will be readily apparent to those of ordinary skill in the art that other embodiments and examples may perform similar functions and/or achieve like results. All such equivalent embodiments and examples are within the spirit and scope of the present disclosure, are contemplated thereby, and are intended to be covered by the following claims. Moreover, it is noted that the various elements, operations, steps, methods, processes, algorithms, functions, techniques, etc. described herein can be used in any and all combinations with each other.