SYSTEM AND METHOD FOR MAINTAINING A DISTRIBUTED AND FAULT-TOLERANT STATE OVER AN INFORMATION CENTRIC NETWORK

[0001] 1. Field

[0002] This disclosure is generally related to Information Centric Networking. More specifically, this disclosure is related replicating a variable over an Information Centric Network (ICN) and maintaining a distributed and fault-tolerant state for the variable.

[0003] 2. Related Art

[0004] In an information centric network (ICN), a client device can obtain data by disseminating a request or Interest message that includes a name for this data. Intermediate routers in ICN propagate this Interest toward any content producer associated with the Interest's name prefix. The content producer that receives the Interest can generate and return a Content Object that satisfies the Interest (e.g., the name of the Content Object exactly matches the name in the Interest packet). The routers then forward the Content Object to the client device along the reverse path traversed by the Interest message, leveraging reverse-path information left in the routers by the Interest message.

[0005] ICN architectures are designed to allow a client to obtain data efficiently and securely without regard to where the data comes from. However, a typical ICN network typically returns one Content Object to satisfy one Interest. If an ICN node that hosts the data fails or becomes compromised, other ICN nodes that consume the data are at risk of using outdated (cached) information or malicious values.

[0006] One embodiment provides a replica management system that facilitates maintaining a distributed and fault-tolerant state for a variable over an Information Centric Network (ICN) by replicating a variable across a set of ICN nodes. During operation, a variable-hosting ICN node can receive an Interest that includes a value-updating command for a variable, current values for a set of replicas of the variable, and a new value for the variable. The ICN node can determine, based on the current values for the set of replica variables, whether the current local value for the variable is an authoritative value. If the current local value is the authoritative value, the ICN node can update a local replica of the variable to the new value. However, if the current local value is not the authoritative value, the ICN node can roll back a state of the local replica of the variable to a previous state, and updates the local replica of the variable to the new value.

[0007] In information centric networks (ICN), each piece of content is individually named, and each piece of data is bound to a unique name that distinguishes the data from any other piece of data, such as other versions of the same data or data from other sources. This unique name allows a network device to request the data by disseminating a request or an Interest that indicates the unique name, and can obtain the data independent from the data's storage location, network location, application, and means of transportation. Named-data networks (NDN) or content-centric networks (CCN) are examples of an ICN architecture; the following terms describe elements of an NDN or CCN architecture:

[0008] Content Object: A single piece of named data, which is bound to a unique name. Content Objects are “persistent,” which means that a Content Object can move around within a computing device, or across different computing devices, but does not change. If any component of the Content Object changes, the entity that made the change creates a new Content Object that includes the updated content, and binds the new Content Object to a new unique name.

[0009] Unique Names: A name in an CCN is typically location independent and uniquely identifies a Content Object. A data-forwarding device can use the name or name prefix to forward a packet toward a network node that generates or stores the Content Object, regardless of a network address or physical location for the Content Object. In some embodiments, the name may be a hierarchically structured variable-length identifier (HSVLI). The HSVLI can be divided into several hierarchical components, which can be structured in various ways. For example, the individual name components parc, home, ccn, and test.txt can be structured in a left-oriented prefix-major fashion to form the name “/parc/home/ccn/test.txt.” Thus, the name “/parc/home/ccn” can be a “parent” or “prefix” of “/parc/home/ccn/test.txt.” Additional components can be used to distinguish between different versions of the content item, such as a collaborative document.

[0010] In some embodiments, the name can include an identifier, such as a hash value that is derived from the Content Object's data (e.g., a checksum value) and/or from elements of the Content Object's name. A description of a hash-based name is described in U.S. patent application Ser. No. 13/847,814 (entitled “ORDERED-ELEMENT NAMING FOR NAME-BASED PACKET FORWARDING,” by inventor Ignacio Solis, filed 20 Mar. 2013), which is hereby incorporated by reference. A name can also be a flat label. Hereinafter, “name” is used to refer to any name for a piece of data in a name-data network, such as a hierarchical name or name prefix, a flat name, a fixed-length name, an arbitrary-length name, or a label (e.g., a Multiprotocol Label Switching (MPLS) label).

[0011] Interest: A packet that indicates a request for a piece of data, and includes a name (or a name prefix) for the piece of data. A data consumer can disseminate a request or Interest across an information-centric network, which CCN/NDN routers can propagate toward a storage device (e.g., a cache server) or a data producer that can provide the requested data to satisfy the request or Interest.

[0012] In some embodiments, the ICN system can include a content-centric networking (CCN) architecture. However, the methods disclosed herein are also applicable to other ICN architectures as well. A description of a CCN architecture is described in U.S. patent application Ser. No. 12/338,175 (entitled “CONTROLLING THE SPREAD OF INTERESTS AND CONTENT IN A CONTENT CENTRIC NETWORK,” by inventors Van L. Jacobson and Diana K. Smetters, filed 18 Dec. 2008), which is hereby incorporated by reference.

[0013] In some embodiments, while determining whether the current local value for the variable is an authoritative value, the ICN node determines whether an authoritative value exists, and determining whether the current local value matches the authoritative value.

[0014] In some variations on these embodiments, while determining whether an authoritative value exists, the ICN node determines, based on the current values for the set of replica variables, a largest set of matching values, and determines whether the number of matching values in the largest set is greater than or equal to a minimum quorum threshold.

[0015] In some variations on these embodiments, if the ICN node determines that an authoritative value does not exist, the ICN node can roll back a state of the local replica of the variable to a previous state.

[0016] In some embodiments, the Interest comprises the value-updating command appended to the Interest's name.

[0017] In some embodiments, the Interest comprises a payload that includes the value-updating command.

[0018] One embodiment provides a client ICN node that can read and update a distributed variable that is replicated across a set of ICN nodes. During operation, a client ICN node can read a distributed variable's value by disseminating at least one Interest for reading a set of replicas of the variable. A respective Interest can include a value-reading command for reading a corresponding replica of the variable, and a name that includes a routable name prefix associated with a replica variable and any replica server that hosts the replica variable. After disseminating the at least one Interest, the ICN node can receive a set of Content Objects that satisfy the at least one Interest, such that a respective Content Object can include a current value for a respective replica variable. The ICN node can then determine whether an authoritative value exists for the variable based on the current values in the set of Content Objects. If an authoritative value does not exist, the ICN node can roll back a state for a local copy of the variable to a previous state.

[0019] In some embodiments, the ICN node can roll back the state of the local copy of the variable without informing a replica server of the non-authoritative values across the replica variables.

[0020] In some embodiments, responsive to determining that an authoritative value does exist, the ICN node can set the local copy of the variable to the authoritative value.

[0021] In some embodiments, while determining whether an authoritative value exists, the ICN node determines, from the set of Content Objects that satisfy the Interest, a largest set of similar values for the variable. The ICN node then determines whether the number of similar values in the largest set is greater than or equal to a minimum quorum threshold. If so, the value from this largest set of similar values is used as the authoritative value.

[0022] In some embodiments, the ICN node can update the set of replicas of the variable. In doing so, the ICN node selects at least a subset of replica variables to update. The ICN node then generates an Interest comprising a value-updating command for a respective replica variable in the subset of replica variables, the current values received for the set of replica variables, and a new value for the variable, and disseminates the Interest for the respective replica variable.

[0023] In some embodiments, the number of replica variables in the selected subset of replica variables is greater than or equal to a minimum quorum threshold.

[0024] In some variations on these embodiments, the Interest for the respective replica variable includes a name comprising the routable name prefix associated with the variable, followed by a name component associated with the respective replica of the variable.

[0033] In the figures, like reference numerals refer to the same figure elements.

[0034] The following description is presented to enable any person skilled in the art to make and use the embodiments, and is provided in the context of a particular application and its requirements. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the present disclosure. Thus, the present invention is not limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.

[0035] Embodiments of the present invention provide a replica management system that solves the problem of maintaining a distributed and fault-tolerant state for a variable over an Information Centric Network (ICN) by replicating a variable across a set of ICN nodes. Other ICN nodes can access the variable by disseminating an Interest for each replica of the variable, which they can obtain from any ICN nodes that host the replica variables. The ICN nodes that host or consume the replica variables can independently verify the integrity of the variable's state by determining whether an acceptable or unacceptable number of inconsistencies exist across the set of replica variables.

[0036] For example, a set of distributed ICN nodes may together host N replicas of a variable for which there is no authoritative entity that controls a master copy of the variable. Each replica of the variable maintains current and historical states (values) for the local instance of the variable, which are together referred to as a Variable History. The full collection of N replicas of the variable is referred to as a Variable History Set (VHS). The responsibility of hosting the VHS can be safely distributed across the set of distributed ICN nodes, such that an authoritative value exists for a variable when at least a majority of its replicas have a matching value. This largest set of matching replicas that produces an authoritative value is hereinafter referred to as a quorum, Q, and has a size IQI. Also, when a client updates the variable, the client needs to successfully update at least |Q| replica variables to maintain the integrity of the variable.

[0037] A Variable History can include a current state (e.g., current values for a collection of variables), as well has historical states that can be used to roll back an erroneous state to a previous good state. Also, a variable can generally store any piece of information, and can be realized using a Content Object or any other data structure now known or later developed. For example, a variable can include a system state comprising a multitude of data elements (e.g., a collection of variables) that together represent the system's state. This way, the system's state can be replicated using a VHS to safeguard the state information against tampering and failover events.

[0038] An ICN node that hosts a Variable History can obtain the current values of the VHS, or a subset of the VHS, from a client device that issues an update to the VHS. The ICN node can analyze the current values to determine whether |Q| replica variables have a matching value, and if so, uses this value as the authoritative value. If the local replica variable does not match this authoritative value, the ICN node can update its replica variable to store the authoritative value.

[0039] On the other hand, if an authoritative value does not exist, the ICN node may use the local Variable History to migrate the local replica variable to a previous good state (e.g., a previous authoritative state). Also, it's possible for the ICN node to use the current values to repair the local replica variable's sate. For example, if the largest set of matching values is just large enough to provide a repair value, the ICN node may use this repair value to repair the broken state without having to migrate to a previous state.

[0040] In some embodiments, a system administrator can configure the size of the VHS, and the required number of matching replica variables to produce an authoritative value or a repair value. For example, the total number of state replicas, N, that need to host the state information to guarantee fault tolerance and security can depend on a maximum expected number of replicas, f, that may be offline during an operation, and a maximum number of replicas, b, that may be maintained at a malicious ICN node or may not be up to date. In some embodiments, the total number of replicas for the state information needs to be:

N=3f+2b+1  (1)

Also, to be able to determine an authoritative value, the number of minimum number of replicas with matching values needs to be the minimum quorum size:

|Q|=2f+2b+1  (2)

If the minimum quorum size, |Q| is not met, then the set of replicas for the state information do not provide an authoritative value. However, it is possible for a system administrator or a fault-correction service to repair the replica variable at an ICN node if the largest number of replica variables with matching values is at least:

|R|=f+b+1  (3)

This number of replica variables |R| needs to be large enough to disambiguate the authoritative value from erroneous or malicious values in the set.

[0041] FIG. 1 illustrates an exemplary computing environment 100 that facilitates managing data replicated across a plurality of replica servers in accordance with an embodiment. Specifically, ICN 102 can include a number of devices, such as replica hosts 104, client devices 106 and 108, and any other type of ICN node that can forward requests (e.g., Interests) and named data objects (e.g., Content Objects) across ICN 102. Devices 104, 106, and 108 can be any type of a computing device, including a mobile computing device, such as a laptop computer, a tablet or slate computer, a smartphone, or a personal digital assistant (PDA), or a stationary computing device, such as a server computer or desktop computer. In addition, each device may include various resources for forwarding the requests and/or returning the matching named data objects, such as a pending Interest table (PIT), a forwarding information base (FIB), a Content Store (CS).

[0042] Replica hosts 104.1-104.n can each host one or more Variable Histories, such that a complete VHS is distributed across replica hosts 104. Each variable history stores a current replica value for the VHS variable, as well as a set of historical replica values for the VHS variable. For example, replica host 104.n can include a storage device 110 that stores a plurality of variable histories 112. In some embodiments, variable histories 112 can correspond multiple replicas of one variable (e.g., they can correspond to one VHS), or can correspond to replicas of multiple different variables that together make up a state set (e.g., they can correspond to multiple VHSs).

[0043] Devices 106 and 108 can correspond to client devices that query replica hosts 104 to obtain replica values from at least |Q| of replica hosts 104.1-104.n, and decide for themselves whether the variable's state needs to be rolled back. For example, devices 106 and 108 can also store a Variable History for the authoritative values of the VHS. If device 106 queries replica hosts 104 and receives |Q| matching replica values, device 106 can use this matching value as the authoritative value for the VHS. On the other hand, if device 106 determines that an authoritative value does not exist across the VHS (which is distributed across replica hosts 104), device 106 can roll back the variable's state to a previous state that stores a known authoritative value, and device 106 does not need to inform any of replica hosts 104 of the broken VHS state. In some embodiments, it is the client device that generates a new value for the variable that inform replica hosts 104 of the broken VHS state (e.g., to fix the broken state). Device 106 can safely use the previous state as the authoritative value, given that replica hosts 104 will each roll back to this same previous state at a future time when a client intends to update the variable's value.

[0044] For example, a newspaper company “Gotham Gazette” may use a collection of Content Objects with name prefix “/GothamGazette” to store their newspaper content that is to be accessed by their consumers, as well as to host their statistics on their subscriptions. The content collection with name prefix “/GothamGazette” may include a VHS of n replicas, distributed across replica hosts 104, and so each variable (Content Object) in the collection also has n replicas distributed across replica hosts 104. A replica host 104.i that hosts a replica of the collection advertises the name prefix for each variable in the collection, appended by a unique identifier associated with the replica being hosted:

/{name_prefix_for_variable}/{replica identifier}  (4)

Note that an Interest for “/{name_prefix_for_variable}” can return a value from any replica of the variable, such as from any of replica hosts 104. However, an Interest for “/{name_prefix_for_variable}/{replica identifier}” can return a value only from a replica variable associated with the unique identifier {replica identifier}.

[0045] The unique identifier may be a numeric or logical value that identifies the replica variable, or may include a logical identifier associated with replica host 104.i. This causes network nodes across ICN 102 to forward any request or Interest that includes the name for this given replica to network node 104.i. For example, client 106 or 108 can access a replica with identifier “3” of a variable “/GothamGazette/subscriber_size” by disseminating an Interest for “/GothamGazette/subscriber_size/3.” If replica host 104.3 is associated with a replica identifier “3,” the network nodes across ICN 102 will forward this request or Interest to replica host 104.3.

[0046] Hence, the replica variable associated with the ID “3” and replica server 104.3 is accessible via the same name: “/{name_prefix_for_variable}/3.” However, the replica variable can still move around replica hosts 104, or even to a different network device in ICN 102, such as to migrate the replica to a new host or to move the replica to a new network location. As the replica variable moves to a new host, this new host can advertise the presence of the replica variable to allow ICN 102 to forward all new requests to this host.

[0047] FIG. 2 illustrates an exemplary Interest message 200 for updating a replica variable in accordance with an embodiment. Interest message 200 includes a name 202 and a payload 204. Name 202 is associated with a replica variable that is to be updated. Payload 204 can include a new value 206 for the variable, and includes a value-updating command 208 which causes a replica host to update the replica variable to new value 206. Payload can also include current replica values 210 for at least a subset of replicas across the VHS, which the replica host can use to determine whether its local value for the variable is the authoritative value.

[0048] FIG. 3 presents a flow chart illustrating a method 300 for processing a data-accessing command at a replica server in accordance with an embodiment. During operation, the replica server can receive an Interest that includes a data-accessing command (operation 302), and analyzes the command from the Interest to determine which variable is to be operated on (operation 304).

[0049] The replica server then determines whether the command performs a read operation or a value-updating operation (operation 306). If the command is a read operation, the replica server obtains a local value for this variable (operation 308), and generates a Content Object with a name that includes the Interest's name and a payload that includes the local value for the variable (operation 310). The replica server then returns the Content Object to satisfy the Interest (operation 312).

[0050] However, if the command is a value-updating command, the replica server analyzes the Interest to obtain current values for other replica variables (e.g., for the variable from other replica servers) (operation 314). The replica server then determines an authoritative value for the variable (operation 316), and determines whether the local value is an authoritative value (operation 318). If the local value is the authoritative value, the replica server can proceed to update the local variable to have the updated value (operation 322).

[0051] On the other hand, if the local value is not an authoritative value, the replica server has detected an issue either locally or among the collection of replica servers. For example, the local replica's state may be inconsistent with that of other replicas, or possibly a client was not able to update data at enough replicas to reach a new authoritative state. In either case, the local replica server proceeds to roll back the replica variable's state to a previous state (operation 320), and then updates the local replica of the variable to have the updated value specified in the Interest (operation 322).

[0052] In some embodiments, the local replica server can correct the variable's state by rolling back the replica variable's state to a last known good state, and in some variations, may even roll back the server's state (e.g., a state comprising a collection of replica variables) to a last known good state.

[0053] In some other embodiments, if enough replica variables have matching values (e.g., at least IRI variables in the VHS have matching values), the local replica server can correct the variable's state by using this matching value to restore the VHS's authoritative value. For example, one or more replica servers and/or their administrator(s) can update a corresponding replica variable to store this restore value, if the replica variable doesn't hold this value already.

[0054] FIG. 4 presents a flow chart illustrating a method 400 for detecting an authoritative value in a VHS in accordance with an embodiment. During operation, a network node (e.g., a replica server or a client device) can obtain current values for multiple replicas of the variable (e.g., for the variable across a set of replica servers) (operation 402). For example, a client may obtain these current values by disseminating an Interest that reads each instance of the variable across the set of replica servers. A replica server, on the other hand, can obtain these current values from an Interest that performs a value-updating operation on the variable.

[0055] Recall that not all of these current values may be the same. A replica server may have an outdated value if a client updated the variable's value at the other replica servers without updating the local replica server, or if a malicious entity managed to change the variable's value to an erroneous value. The server or client then determine a largest set of matching values among the set (operation 404), and determines whether the size of this largest set is greater than or equal to a minimum quorum threshold, |Q| (operation 406). If so, the device determines that an authoritative value exists, and selects the variable's value from this set as the authoritative value (operation 408). On the other hand, if the size is less than the quorum threshold, the device determines that an authoritative value does not exist (operation 410).

[0056] FIG. 5 presents a flow chart illustrating a method 500 for reading a variable that is replicated over a set of replica servers in accordance with an embodiment. During operation, the client can disseminate Interests for at least a subset of a variable's replicas (operation 502), such that each Interest includes a request for a different replica of the variable. The client receives a set of Content Objects that correspond to the subset of replica variables (operation 504), which the client analyzes determine whether an authoritative value exists (operation 506). If an authoritative value exists, the client updates the local variable to the updated value (operation 508).

[0057] In some embodiments, subset of replica variables being read needs to be at least equal to the minimum quorum threshold, |Q|, to be able to detect an authoritative value from |Q| matching values. If the client does not detect an authoritative value from this subset of replica variables, the client can disseminate additional Interests for other replica variables until either an authoritative value is detected, or there are no more replica variables in the VHS to query. For example, the client can determine whether additional replicas exist in the VHS (operation 510). If so, the client disseminates additional Interests for the other replicas (operation 512), and returns to operation 504 to receive and process the replica values it receives for these other replicas. On the other hand, if no more replicas exist in the VHS, the client rolls back the variable's value to a previous state (operation 514).

[0058] FIG. 6 presents a flow chart illustrating a method 600 for updating a variable's value across a set of replica servers in accordance with an embodiment. During operation, the client reads the current values for the variable's replicas (operation 602), such as by disseminate Interests for at least a subset of a variable's replicas. The client can use the variable's authoritative value locally (operation 604), such as to present data to a user, to generate other new data, or even to update the variable's value.

[0059] If the client does update the variable's value (operation 606), the client selects at least a subset of the variable's replicas to update (operation 608), and updates this subset of replica variables to hold the new value (operation 610). The size of this subset needs to be at least equal to the minimum quorum threshold, |Q|.

[0060] In some embodiments, the client can update the replica variables using a push protocol or a pull protocol. For example, the client can push the new value by generating an Interest comprising a value-updating command for the selected replica variables, and disseminates the Interests over the ICN. These Interests include the current values for the replica variables in the VHS, and also include the new value for the variable. The current variable values and the new value can be included as part of the value-updating command, or can be included as separate data elements in the Interest. Also, the Interest can include the value-updating command and the current and updated values in the Interest's name (e.g., in a marshalled object), or within a payload segment of the Interest that is separate from the Interest's name.

[0061] As another example, in a pull protocol, each replica host can disseminate an Interest that queries the client for an updated value. If the client does generate a new value, the client can return a Content Object for each Interest it receives from a replica host for the variable. This Content Object can include the current values for the replica variables in the VHS, along with the new value for the variable.

[0062] FIG. 7 illustrates an exemplary apparatus 700 that facilitates managing data replicated across a plurality of replica servers in accordance with an embodiment. Apparatus 700 can comprise a plurality of modules which may communicate with one another via a wired or wireless communication channel. Apparatus 700 may be realized using one or more integrated circuits, and may include fewer or more modules than those shown in FIG. 7. Further, apparatus 700 may be integrated in a computer system, or realized as a separate device which is capable of communicating with other computer systems and/or devices. Specifically, apparatus 700 can comprise a communication module 702, a request-processing module 704, an authoritative value detection module 706, and a state-management module 708.

[0063] In some embodiments, communication module 702 can send and/or receive Interests for accessing a replica of a distributed variable. Request-processing module 704 can process a variable-accessing Interest to return a Content Object that includes a current value for the variable's replica, or can process a variable-updating Interest that includes a new value for the variable. Authoritative value detection module 706 can process values from a set of replica variables to determine whether an authoritative value exists. State-management module 708 can roll back the variable's state to a previous state if the local replica variable's value does not match the authoritative value or if an authoritative value does not exist, and can update the local variable's value to include the new value if the local value matches the authoritative value.

[0064] FIG. 8 illustrates an exemplary computer system 802 that facilitates managing data replicated across a plurality of replica servers in accordance with an embodiment. Computer system 802 includes a processor 804, a memory 806, and a storage device 808. Memory 806 can include a volatile memory (e.g., RAM) that serves as a managed memory, and can be used to store one or more memory pools. Furthermore, computer system 802 can be coupled to a display device 810, a keyboard 812, and a pointing device 814. Storage device 808 can store operating system 816, replica management system 818, and data 828.

[0065] Replica management system 818 can include instructions, which when executed by computer system 802, can cause computer system 802 to perform methods and/or processes described in this disclosure. Specifically, replica management system 818 may include instructions for sending and/or receiving Interests for accessing a replica of a distributed variable (communication module 820). Further, replica management system 818 can include instructions for processing a variable-accessing Interest to return a Content Object that includes a current value for the variable's replica, and for processing a variable-updating Interest that includes a new value for the variable (request-processing module 822).

[0066] Replica management system 818 can also include instructions for processing values from a set of replica variables to determine whether an authoritative value exists (authoritative value detection module 824). Further, replica management system 818 can include instructions for rolling back the variable's state to a previous state if the local replica variable's value does not match the authoritative value or if an authoritative value does not exist, and for updating the local variable's value to include the new value if the local value matches the authoritative value state-management module 826).

[0067] Data 828 can include any data that is required as input or that is generated as output by the methods and/or processes described in this disclosure. Specifically, data 828 can store at least variable histories for a local instance of a variable, and/or recent and/or historical variable values from a plurality of replica instances of the variable.

[0068] The data structures and code described in this detailed description are typically stored on a computer-readable storage medium, which may be any device or medium that can store code and/or data for use by a computer system. The computer-readable storage medium includes, but is not limited to, volatile memory, non-volatile memory, magnetic and optical storage devices such as disk drives, magnetic tape, CDs (compact discs), DVDs (digital versatile discs or digital video discs), or other media capable of storing computer-readable media now known or later developed.

[0069] The methods and processes described in the detailed description section can be embodied as code and/or data, which can be stored in a computer-readable storage medium as described above. When a computer system reads and executes the code and/or data stored on the computer-readable storage medium, the computer system performs the methods and processes embodied as data structures and code and stored within the computer-readable storage medium.

[0070] Furthermore, the methods and processes described above can be included in hardware modules. For example, the hardware modules can include, but are not limited to, application-specific integrated circuit (ASIC) chips, field-programmable gate arrays (FPGAs), and other programmable-logic devices now known or later developed. When the hardware modules are activated, the hardware modules perform the methods and processes included within the hardware modules.

[0071] The foregoing descriptions of embodiments of the present invention have been presented for purposes of illustration and description only. They are not intended to be exhaustive or to limit the present invention to the forms disclosed. Accordingly, many modifications and variations will be apparent to practitioners skilled in the art. Additionally, the above disclosure is not intended to limit the present invention. The scope of the present invention is defined by the appended claims.