Failure protection for software defined networks using multi-topology routing based fast reroute

A software defined networking (SDN) controller and methods for protecting against failure of a network element in a forwarding plane are provided. A multi-topology routing based IP fast re-route (MTR-IPFRR) process is configured to: if a new traffic flow is detected in the forwarding plane, determine a primary path for relaying network traffic to a destination node using primary forwarding tables; for each network element along the primary path, determine and associate a virtual topology (VT) which protects the network element from relaying network traffic; determine a protecting path for each protected network element along the primary path using an associated VT; and program each node along the primary path to be switchable to a protecting path associated with an adjacent network element to reroute network traffic from an anticipated failed network element.

CROSS-REFERENCE TO RELATED U.S. APPLICATIONS

Not applicable.

Not applicable.

NAMES OF PARTIES TO A JOINT RESEARCH AGREEMENT

Not applicable.

REFERENCE TO AN APPENDIX SUBMITTED ON COMPACT DISC

Not applicable.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates generally to failure protection and recovery in networks, and more particularly to fast recovery from single failures in software defined networks using multi-topology routing based fast reroute.

The rapid growth in networking devices and the data they use, along with server virtualization, the use of cloud services, as well as many other changes, have caused many in the telecommunications industry to re-examine the network architectures that have been previously used.

Traditional communication networks incorporate a plurality of networking hardware each of which is responsible for performing both control and data forwarding tasks. Since this form of architecture requires the individual configuration of each hardware component in order to enforce a network-wide policy, it is challenging to dynamically adapt the operation of the traditional networks for the changing needs that have evolved around new computer usage scenarios. If a dynamic re-configuration capability can be incorporated into the communication networks, the limited network resources can be used more efficiently as the network conditions change. For this purpose, a more efficient, flexible, and agile network architecture is needed.

As a result of the above-mentioned drawbacks and the insufficiencies of previous solutions, improvements are required to be made in the related technical field.

BRIEF SUMMARY OF THE INVENTION

To address challenges and requirements in data forwarding, the present disclosure presents new methods and systems for failure protection in software defined networks using multi-topology routing based fast reroute. Existing techniques are not well-established to be deployed in a real network to carry out failure recovery or failure protection, and are not easily extensible to balance the link loads in the network during the recovery or protection process. They are either computationally complex, do not provide full failure coverage, or work under restricted scenarios requiring the intervention by the network operator for the configuration of the forwarding devices.

Software defined networking (SDN) is an approach to computer networking that allows network administrators to manage network services through abstraction of lower-level functionality. This is done by decoupling or disassociating the system that makes decisions about where traffic is sent (the control plane) from the underlying systems that forward traffic to the selected destination (the forwarding plane or the data plane). In other words, using software defined networking, the network control is detached from the elements of the network that provide the data forwarding.

With software providing a means by which much functionality can be provided, its adoption into networking enables many features to be run using software rather than hardware. By structuring the network architecture in this way into accessible computing devices, the underlying infrastructure can be abstracted for applications and network services to treat the network as a logical or virtual entity rather than a large number of tightly bound devices. The intelligence for the network is typically included within an SDN controller(s) which is able to control the complete network. In this way, the whole network can be treated by the applications and policy entities as a single large logical switch.

By adopting this SDN approach, the whole network can be controlled from a single point. This greatly simplifies the design, operation and updates for the network. SDN also simplifies the network devices themselves as they only need to interface with a single control standard and not the many protocol standards they would otherwise need to process.

The Quality of Service (QoS) requirements of real-time services in SDN necessitate the fast replacement of the primary paths for the traffic flows disrupted by a single inter-switch link or switch failure in the forwarding plane by loop-free alternate paths.

Fast recovery from network failures in the forwarding plane can be accomplished using two different approaches: restoration and protection. In the restoration approach, alternate routing tables are pro-actively computed by the controller in advance of the failure while the switch resources for the alternate paths are allocated upon the detection of the failure. On the other hand, in the protection approach, both the computation of the alternate paths and the allocation of the resources are performed in advance of the failure. The protection approach provides a shorter failure recovery time compared to the restoration approach since the pro-active computation and establishment of the alternate paths shortens the time required to activate the new paths.

The present invention provides a novel failure protection mechanism for SDN relying on multi-topology routing based IP fast re-route (MTR-IPFRR). It leads to a self-recovering SDN against failures by not requiring any manual operation by the network operator. The present invention considerably reduces the failure recovery time compared to a reactive recovery process in SDN. The present invention provides a full definition of the stages to be performed in an automatic recovery process beginning from the detection of the network failure to the replacement of the disrupted primary paths.

Prior to a failure detection, MTR-IPFRR uses virtual topologies (VTs) to pro-actively compute alternate paths for the traffic flows affected from the anticipated failure of a network element. A router which actually detects a failure immediately starts to reroute the affected traffic over a pre-calculated VT where the failed component is isolated. MTR-IPFRR can also be extended for traffic engineering applications and operations on the data plane due to its flexibility to freely choose the link weights in VTs. This capability of MTR-IPFRR allows for fast failure recovery while balancing the link loads during the recovery process. Furthermore, MTR-IPFRR does not require the identification of the failure cause, namely, the knowledge of whether the failed component is an inter-switch link or a switch itself.

In accordance with an embodiment of the present invention, a software defined networking (SDN) controller for protecting against failure of a network element in a forwarding plane is provided. The SDN controller comprises a processor configured to execute software processes, and a memory configured to store a multi-topology routing based IP fast re-route (MTR-IPFRR) process executable by the processor. The MTR-IPFRR process is configured to: discover a physical topology of the forwarding plane; determine a primary forwarding table for each node of the forwarding plane based upon the discovered physical topology; and if a new traffic flow is detected in the forwarding plane, determine a primary path for relaying network traffic to a destination node using the primary forwarding tables. The MTR-IPFRR process is further configured to: for each network element along the primary path, determine and associate a virtual topology (VT) which protects the network element from relaying network traffic; determine a protecting path for each protected network element along the primary path using an associated VT; and program each node along the primary path to be switchable to a protecting path associated with an adjacent network element to reroute network traffic from the failed network element.

In accordance with another embodiment of the present invention, another SDN controller for protecting against failure of a network element in a forwarding plane is provided. The SDN controller comprises: a processor configured to execute software processes; and a memory configured to store a plurality of MTR databases, each MTR database for an independent network topology among a plurality of network elements of the forwarding plane. The memory is further configured to store an MTR-IPFRR process executable by the processor, the MTR-IPFRR process configured to: discover a physical topology of the forwarding plane via a link discovery protocol; determine a primary forwarding table for each node of the forwarding plane based upon the discovered physical topology; determine a plurality of virtual topologies (VTs) based upon the topology of the forwarding plane, wherein each VT includes the same nodes and links as in the physical topology of the forwarding plane, and further wherein each VT has different link weights from each other; and if a new traffic flow is detected in the forwarding plane, determine a primary path for relaying network traffic to a destination node using the primary forwarding tables. The MTR-IPFRR process is further configured to: for each network element along the primary path, determine and associate a VT which protects the network element from relaying network traffic by isolation; determine a protecting path for each protected network element along the primary path using an associated VT; and prior to detecting failure of a network element, program each node along the primary path to be switchable to a protecting path associated with an adjacent network element to reroute network traffic from the failed network element. In other words, the MTR-IPFRR process is configured to establish each protecting path, in advance of any failure, by programming each switch along the primary path to be switchable to a protecting path associated with its adjacent network element (the network element prior to or before the potentially failed network element) to reroute network traffic in case of the failure of the network element.

In accordance with yet another embodiment of the present invention, a method for protecting against failure of a network element in a forwarding plane is provided. The method comprises: discovering a physical topology of the forwarding plane via a link discovery protocol; determining a primary forwarding table for each node of the forwarding plane based upon the discovered physical topology; if a new traffic flow is detected in the forwarding plane, determining a primary path for relaying network traffic to a destination node using the primary forwarding tables; for each network element along the primary path, determining and associating a VT which protects the network element from relaying network traffic; determining a protecting path for each protected network element along the primary path using an associated VT; and programming each node along the primary path to be switchable to a protecting path associated with an adjacent network element to reroute traffic from the failed network element.

Advantageously, the systems and methods of the present disclosure provide highly adaptive protocols resulting in significantly enhanced system performance and efficiencies.

DETAILED DESCRIPTION OF THE INVENTION

Referring now toFIG. 1, a system100including a forwarding plane102(also “data plane” or “computer network”) and a software defined networking (SDN) controller104for enhanced computer network routing is illustrated in accordance with some embodiments of the present invention. Forwarding plane102includes a plurality of network elements including a plurality of nodes (e.g., shown by boxed numbers 0 through 31) (e.g., nodes110,112) with links between pairs of nodes (e.g., link111). A client computer HA is coupled to a server computer HB by the plurality of network elements, and a primary path120for data flow from client computer HA to server computer HB through the nodes and links is illustrated by arrows.

FIG. 2illustrates an SDN architecture200including a data plane202(also “forwarding plane” or “computer network”), a control plane204, and an application plane206in accordance with some embodiments of the present invention. A physical topology may be discovered from the forwarding plane202, a controller in the control plane204may be used to control the network elements of the forwarding plane202, and an MTR-IPFRR module208in the application plane206may be used to determine virtual topologies for alternate routing of traffic flows affected from a network element failure. The MTR-IPFRR module208can be implemented as an application module in the application plane of the SDN architecture.

FIG. 3demonstrates the general principle of MTR-IPFRR for link protection by illustrating an example physical topology and example virtual topologies in accordance with some embodiments of the present invention. In MTR-IPFRR, each node and link is prevented from carrying transit traffic in exactly one of the VTs. InFIG. 3, part (a) illustrates a physical topology of a forwarding plane, with nodes shown by circles (e.g., nodes310,312), and links shown by lines (e.g., link311) connecting the circles. Example virtual topologies 1-3 are shown in parts (b), (c), and (d), respectively, based upon the physical topology of (a). The links shown by dashed lines are assigned a very high weight, and, hence, are prevented from carrying transit traffic.

FIG. 4illustrates another set of example virtual topologies (VT1-VT4) based upon a different physical topology than that shown inFIG. 3. The virtual topologies VT1-VT4are computed by the MTR-IPFRR module shown inFIG. 2using the Multiple Routing Configurations (MRC) VT construction method. A normal node is shown by a solid circle and an isolated node is shown by an open circle. A normal link is shown by a solid line, an isolated link is shown by vertically-segmented lines, and a restricted link is shown by dashed lines. A normal node or link can be used to relay transit traffic while an isolated node or link cannot be used to forward any transit traffic. A restricted link can only be used to forward traffic sourced at or destined to one of its end-point switches.

FIG. 5illustrates a primary route and a protecting route for failure protection in the physical topology of a forwarding plane ofFIG. 4in accordance with some embodiments of the present invention. Both the primary and protecting routes are computed by the MTR-IPFRR module inFIG. 2following the discovery of the physical topology of the forwarding plane. A link between node502(S4) and node504(S7) along a primary path (shown by thick lines) is shown to fail by an “X”, and an alternate route or protecting path from node510to node512to node514to node516to node504is illustrated by segmented lines. This protecting path is pro-actively computed by the MTR-IPFRR module using VT3inFIG. 4where the link between node502(S4) and node504(S7) is isolated, and is established by the MTR-IPFRR module along with the establishment of the primary path.

Referring now toFIG. 6, a method600for performing MTR-IPFRR in software defined networks is illustrated in accordance with some embodiments of the present invention.

Method600includes, at block602, discovering the topology of the forwarding plane and determining or computing primary forwarding tables for each node in the forwarding plane. In one example, the physical topology of the data plane is discovered through a link discovery protocol such as Link Layer Discovery Protocol (LLDP), and the primary forwarding table for each switch (or node) in the network is computed based on the discovered topology. The method continues to block604.

Method600further includes, at block604, determining or computing a plurality of VTs (e.g., at least two) and each corresponding forwarding table based on the topology of the forwarding plane (computation of alternate forwarding tables). For this purpose, a VT computation technique, such as Multiple Routing Configurations (MRC) or Maximally Redundant Trees (MRT), can be used. These techniques construct VTs with the same nodes and links as in the physical topology, but with different link weights. The MRC technique requires a sufficiently large number of VTs (?2) to be configured as an input to its algorithm while the MRT technique computes two VTs. Therefore, if the MRC technique is used, the number of VTs should be incrementally configured starting from 2 until the MRC successfully terminates for the first time. The method continues to decision block606.

Method600further includes, at decision block606, identifying a message, advertisement, and/or announcement (e.g., OpenFlow messages) coming from the nodes of the forwarding plane to decide if a new traffic flow is initiated in the forwarding plane. If no message is detected and/or received (N), the method loops to the start of decision block606. If a message is detected and/or received (Y), the method continues to decision block608.

Method600further includes, at decision block608, deciding if a new traffic flow is initiated in the forwarding plane, or if a network element has been added to, modified, or failed in the forwarding plane/network. For this purpose, OFPT_PACKET_IN and OFPT_PORT_STATUS messages from the switches are listened for, which signal the events of the initiation of a new flow in the data plane and the addition/modification/failure of a network element, respectively. If a new traffic flow is detected at decision block608, the method continues to decision block612, and if an addition/modification/failure is detected in the forwarding plane at decision block608, the method continues to block610.

Method600further includes, at block610, updating the topology information regarding the forwarding plane, recomputing the primary forwarding tables, and recomputing the VTs and their corresponding forwarding tables, based upon the addition/modification/failure detected in the network (recomputation of primary and alternate forwarding tables). In other words, if a network element is detected to be added/modified/failed in the data plane, the topology information is updated, and the corresponding primary and alternate forwarding tables are re-computed. The method then continues by looping to the start of decision block606.

Method600further includes, at decision block612, deciding if the detected new flow is a broadcast and multicast flow (handling of broadcast and multicast flows). If the new flow is a broadcast and multicast flow (Y), the method continues to block614, and if the new flow is not a broadcast and multicast flow (N), the method continues to block616.

Method600further includes, at block614, flooding the broadcast and multicast flows in the forwarding plane. Thus, the broadcast and multicast flows can be delivered to their recipients by flooding them in the data plane using OFPT_PACKET_OUT messages. The method continues by looping to the start of decision block606.

Method600further includes, at block616, determining or computing the primary path for the current flow using the pre-computed primary forwarding tables. The method continues to decision block618.

Method600further includes, at decision block618, block620, and block622the determination of the protecting paths.

Decision block618includes deciding if a protecting path is found for each network element on the primary path. If a protecting path is not found for each network element on the primary path (N), the method continues to block620. If a protecting path is found for each network element on the primary path (Y), the method continues to block624.

Method600further includes, at block620, determining the MTR-IPFRR database isolating the next network element on the primary path (i.e., determining the VT where the network element is isolated). The method continues to block622.

Method600further includes, at block622, using the selected MTR-IPFRR database to compute and store the protecting path between the node adjacent to the protected network element and the destination of the flow (i.e., determining the protecting path of the network element using the selected VT). Thus, for each network element on the primary path, the pre-computed VT, where the network element is isolated from relaying any network traffic, is determined (block620), and the protecting path of the network element is computed using the selected VT (block622). A protecting path is computed between the switch adjacent to the protected network element and the destination switch of the flow. This is due to the fact that, in the case that a network element in the data plane fails, the traffic flows affected from the failure are continued to be routed over the same network elements as in the primary path up to the switch adjacent to the failure while the switch adjacent to the failure changes over the protecting path to forward the affected traffic to its destination. Note that, in the case that the MRC technique is used for the VT construction, a protecting path can protect both an inter-switch link on the primary path and the remote end-point switch of the same link as long as the protecting path is computed using the VT where the remote end-point switch is isolated from transiting any traffic. The method then loops to the start of decision block618.

Method600further includes, at blocks624,626, and628, the establishment of the primary and protecting paths.

Block624includes installing the proper flow and group table entries to the nodes of the primary path excluding the destination node. The establishment of the primary path in the data plane is prioritized in order to start forwarding the flow as soon as possible. This is accomplished by installing proper flow and fast-failover group table entries into the switches on the primary path. The method continues to block626.

Method600further includes, at block626, programming the flow table of the destination node. It is possible to compute duplicate flow entries since the same incoming interface of a destination switch may be included in multiple paths including the primary and protecting ones, but the duplicate installation of the flow entries into the destination switch can be easily eliminated. An example of a fast-failover group table is shown inFIG. 7. The method continues to block628.

Method600further includes, at block628, installing the proper flow table entries to the remaining nodes on the protecting paths. The establishment of the protecting paths is completed by installing the proper flow entries into the remaining switches on the protecting paths. The method then loops to the start of decision block606.

FIG. 7illustrates a data structure700of a fast-failover group table700including a plurality of buckets in accordance with some embodiments of the present invention. A fast-failover group table is composed of one or more buckets, each of which contains a watch port702to be acted upon and a set of actions704. As long as the watch port in the first bucket is up, its corresponding actions are performed. Otherwise, the actions of the next bucket with an up watch port are performed.

FIGS. 8 and 9illustrate a method800and a method900for the establishment of the primary and protecting paths in accordance with some embodiments of the present invention.

Method800includes, at decision block802, deciding if all switches on the primary path have been programmed beginning from the source switch. If yes (Y), the method continues to method900ofFIG. 9. If no (N), the method continues to decision block804.

At decision block804, method800includes deciding if the next switch is the destination switch. If yes (Y), the method continues to decision block816. If no (N), the method continues to block806.

At block806, method800includes determining the outgoing interface IF1of the next switch on the primary path. The method continues to block808.

At block808, method800includes determining the outgoing interface IF2of the next switch on the path protecting IF1. The method continues to block810.

At block810, method800includes installing a fast-failover group table G with a plurality of buckets (e.g., 2 buckets) into the next switch: Bucket1includes Watch Port: IF1, Action: Forward to IF1; and Bucket2includes Watch Port: IF2, Action: Forward to IF2. The method continues to block812.

At block812, method800includes determining the incoming interface IF_IN of the next switch on the primary path. The method continues to block814.

At block814, method800includes installing a flow table entry into the next switch: Incoming Port: IF_IN, Action: Direct to the group G. The method then loops to the start of decision block802.

At block816, method800includes deciding if primary and all protecting paths are processed. If yes (Y), the method loops to the start of decision block802. If no (N), the method continues to block818.

At block818, method800includes determining the incoming interface IF_IN of the destination switch on the next path. The method continues to block820.

At block820, method800includes installing a flow table entry into the destination switch: Incoming Port: IF_IN, Action: Forward to the destination host. The method then loops to the start of decision block816.

Referring now toFIG. 9, method900includes at decision block902, deciding if all protecting paths have been processed. If yes (Y), the method ends. If no (N), the method continues to decision block904.

At block904, method900includes deciding if all switches on the next protecting path are programmed, excluding the first and last switches. If yes (Y), the method loops to the start of decision block902. If no (N), the method continues to block906.

At block906, method900includes determining the incoming and outgoing interfaces, IF_IN and IF_OUT, of the next switch on the protecting path. The method continues to block908.

At block908, method900includes installing a flow table entry into the next switch: Incoming Port: IF_IN, Action: Forward to IF_OUT. The method then loops to the start of decision block904.

It is noted that the first and last switches of a protecting path are ignored in method900ofFIG. 9since these switches are part of the primary path, and, hence, are already programmed prior to this stage.

Referring now toFIG. 10, a network diagram depicts an example system1000for performing MTR-IPFRR processing according to some embodiments of the present invention. A networked system1002forms a network-based control system that provides server-side functionality, via a network1004(e.g., the Internet or Wide Area Network (WAN)), to one or more clients and devices.FIG. 10further illustrates, for example, one or both of a web client1006(e.g., a web browser) and a programmatic client1008executing on a device machine1010according to any of the embodiments noted above. In one embodiment, the system1000comprises a network control system.

Device machine1010may comprise a computing device that includes at least communication capabilities with the network1004to access the networked system1002. Device machine1010may connect with the network1004via a wired or wireless connection. For example, one or more portions of network1004may be an ad hoc network, an intranet, an extranet, a virtual private network (VPN), a local area network (LAN), a wireless LAN (WLAN), a wide area network (WAN), a wireless WAN (WWAN), a metropolitan area network (MAN), a portion of the Internet, a portion of the Public Switched Telephone Network (PSTN), a cellular telephone network, a wireless network, a WiFi network, a WiMax network, another type of network, or a combination of two or more such networks.

An Application Program Interface (API) server1012and a web server1014are coupled to, and provide programmatic and web interfaces respectively to, one or more application servers1016. The application servers1016may host one or more applications (e.g., MTR-IPFRR service application1018) in accordance with an embodiment of the present invention. Application servers1016may further include payment applications and other applications that support a recovery routing service. The application servers1016are, in turn, shown to be coupled to one or more databases servers1022that facilitate access to one or more databases1024.

While the MTR-IPFRR service application1018is shown inFIG. 10to form part of the networked system1002, it will be appreciated that, in alternative embodiments, the service application may form part of a network recovery application service that is separate and distinct from the networked system1002or separate and distinct from one another.

Further, while the system1000shown inFIG. 10employs a client-server architecture, embodiments of the present disclosure is not limited to such an architecture, and may equally well find application in, for example, a distributed or peer-to-peer architecture system. The various service applications1018may also be implemented as standalone software programs, which do not necessarily have networking capabilities.

The web client1006accesses the various network routing/recovery applications1018via the web interface supported by the web server1014. Similarly, the programmatic client1008accesses the various services and functions provided by the applications1018via the programmatic interface provided by the API server1012.

The systems, apparatus, and methods according to example embodiments of the present invention may be implemented through one or more processors, servers, and/or client computers in operable communication with one another.

FIG. 11illustrates a diagrammatic representation of a machine1100in the example form of a computer system, within which a set of instructions may be carried out for causing an SDN controller or MTR-IPFRR module to perform any one or more of the methods according to some embodiments of the present invention.

The computer system1100or parts thereof may comprise, for example, all or part of the device machine1010, applications servers1016, API server1012, web server1014, database servers1022, or third party server1026. In alternative embodiments, the machine operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server or a device machine in server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a server computer, a client computer, a personal computer (PC), a tablet, a set-top box (STB), a Personal Digital Assistant (PDA), a smart phone, a cellular telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

The example computer system1100includes a processor1102(e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both), a main memory1104and a static memory1106, which communicate with each other via a bus1108. The computer system1100may further include a video display unit1110(e.g., liquid crystal display (LCD), inorganic/organic light emitting diode (LED/OLED), touch screen, or a cathode ray tube (CRT)). The computer system1100also includes an alphanumeric input device1112(e.g., a physical or virtual keyboard), a cursor control device1114(e.g., a mouse, a touch screen, a touchpad, a trackball, a trackpad), a disk drive unit1116, a signal generation device1118(e.g., a speaker) and a network interface device1120.

The disk drive unit1116includes a machine-readable medium1122on which is stored one or more sets of instructions1124(e.g., software) embodying any one or more of the methodologies or functions described herein. The instructions1124may also reside, completely or at least partially, within the main memory1104and/or within the processor1102during execution thereof by the computer system1100, the main memory1104and the processor1102also constituting machine-readable media.

The instructions1124may further be transmitted or received over a network1126via the network interface device1120.

Certain embodiments described herein may be implemented as logic or a number of modules, engines, components, or mechanisms. A module, engine, logic, component, or mechanism (collectively referred to as a “module”) may be a tangible unit capable of performing certain operations and configured or arranged in a certain manner. In certain example embodiments, one or more computer systems (e.g., a standalone, client, or server computer system) or one or more components of a computer system (e.g., a processor or a group of processors) may be configured by software (e.g., an application or application portion) or firmware (note that software and firmware can generally be used interchangeably herein as is known by a skilled artisan) as a module that operates to perform certain operations described herein.

In various embodiments, a module may be implemented mechanically or electronically. For example, a module may comprise dedicated circuitry or logic that is permanently configured (e.g., within a special-purpose processor, application specific integrated circuit (ASIC), or array) to perform certain operations. A module may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software or firmware to perform certain operations. It will be appreciated that a decision to implement a module mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by, for example, cost, time, energy-usage, and package size considerations.

Although the present invention has been described in connection with some embodiments, it is not intended to be limited to the specific form set forth herein. One skilled in the art would recognize that various features of the described embodiments may be combined in accordance with the invention. Moreover, it will be appreciated that various modifications and alterations may be made by those skilled in the art without departing from the scope of the invention.

Embodiments of the present invention may be embodied as a system, method, or computer program product (e.g., embodiments directed toward a MTR-IPFRR system, method, or computer program product). Accordingly, aspects of the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit”, “module”, or “system”. For example, an MTR-IPFRR method may be embodied in a software and hardware system that can be housed in a portable device such as a tablet, laptop, camera, phone, and the like. In another example, a client and server computer in operable communication and combination, may be in its entirety said to be embodied in a system. Furthermore, aspects of the present embodiments of the disclosure may take the form of a computer program product embodied in one or more computer readable medium/media having computer readable program code embodied thereon. Methods may be implemented in a special-purpose computer or a suitably programmed general-purpose computer.

Although the invention has been described in detail in connection with only a limited number of embodiments, it should be readily understood that the invention is not limited to such disclosed embodiments. Rather, the invention can be modified to incorporate a number of variations, alterations, substitutions, combinations or equivalent arrangements not heretofore described, but which are commensurate with the spirit and scope of the invention. Furthermore, the various components of the system, apparatus, and methods disclosed above can be alternatives which may be combined in various applicable and functioning combinations within the scope of the present invention. Additionally, while various embodiments of the invention have been described, it is to be understood that aspects of the invention may include only some of the described embodiments. Accordingly, the invention is not to be seen as limited by the foregoing description but is only limited by the scope of the appended claims.