TECHNICAL FIELD

[0001] Various embodiments described herein relate to methods and devices and more particularly to methods and devices providing packet buffering in telecommunications networks.

BACKGROUND

[0002] Growing amounts of data, voice, and/or video traffic in telecommunications networks make efficient routing of packets by packet routing switches of significant importance. Packet routing switches perform various operations to forward packets to destinations in a network based on flow rules. Instances where packets are forwarded based on flow rules by the packet routing switch handles the packets in the data plane. In cases where the packet routing switch is not able to determine an appropriate rule governing forwarding of a packet, the packet routing switch forwards the packet to a controller node in the control plane. Large amounts of traffic in the control plane may reduce performance of the controller node and overall

performance of the network by increasing packet latency, increasing packet processing times, etc. Accordingly, there is a need for methods and devices to handle more of the packets in the data plane and/or at the packet routing switch, thereby reducing processing load on the network controller.

SUMMARY

[0003] Some embodiments disclosed herein are directed to a method performed by a network node that operates as a packet routing switch for routing packets in a telecommunications network. The method includes receiving a buffer creation message from a controller node to create a first buffer in memory associated with the network node and to install a first buffer flow rule associated with the first buffer. The first buffer flow rule includes a set of one or more header fields. The method includes receiving a packet including a packet header, and storing the packet in the first buffer associated with the first buffer flow rule responsive to one or more fields of the packet header being among the set of the one or more header fields of the first buffer flow rule. The method includes determining that the packet is an unmatched packet if no combination of fields of the packet header satisfy any of one or more flow rules currently associated with the network node. The one or more flow rules currently associated with the network node include the first buffer flow rule. The method includes storing the packet in a second buffer associated with unmatched packets, responsive to the determining that the packet is an unmatched packet, and transmitting the packet if the combination of fields of the packet header satisfy any of the one or more flow rules currently associated with the network node other than the first buffer flow rule.

[0004] A potential advantage of this approach is that it can provide control of buffer creation and/or buffer management to the controller node. Buffer creation and/or management functions in legacy systems are mainly controlled by the network node/packet routing switch itself. Providing buffer creation and/or buffer management capability to the controller node allows flow rules to be installed at the packet routing switch such that more of the packets in the data plane are buffered at the packet routing switch, and are not forwarded to the controller node for processing. This reduces control plane traffic, thereby improving performance in the network. Furthermore, when a flow of packets is received with similar characteristics for which a flow rule is not installed at the packet routing switch, the present solution provides mechanisms for every such packet to not be sent to the controller node. Additionally, the packet routing switch may provide intelligent handling of unmatched packets.

[0005] Some other related embodiments are directed to receiving, from the controller node, a buffer unmatched message comprising a set of one or more group fields, each group field indicating a header field to be matched with the packet header of the packet that is received or indicating an interface through which the packet is received.

[0006] Some other embodiments of the present invention are directed to a method performed by a controller node in communication with a network node that operates as a controller of a packet routing switch for routing packets in a telecommunications network. The method includes transmitting a buffer creation message to the network node to create a first buffer for storing packets according to matching of a buffer flow rule.

[0007] Some other embodiments of the present invention are directed to a method performed by a controller node in communication with a network node that operates as a controller of a packet routing switch for routing packets in a telecommunications network. The method includes transmitting, to the network node, an unmatched group flow rule to apply to an unmatched packet that does not match any of one or more flow rules currently associated with the network node. The unmatched group fiow rule indicates at least one field of a packet header of the unmatched packet for associating the unmatched packet with an unmatched group flow rule buffer.

[0008] Some other embodiments of the present invention are directed to a network node that is configured to operate as a packet routing switch for routing packets in a

telecommunications network. The network node includes a transceiver, a memory storing computer readable program code, and a processor connected to the transceiver and the memory, the processor configured to perform operations including receiving a buffer creation message from a controller node to create a first buffer in memory associated with the network node and to install a first buffer flow rule associated with the first buffer. The first buffer fiow rule includes a set of one or more header fields. The processor is configured to perform operations including receiving a packet including a packet header, storing the packet in the first buffer associated with the first buffer flow rule, responsive to one or more fields of the packet header being among the set of the one or more header fields of the first buffer flow rule, determining that the packet is an unmatched packet if no combination of fields of the packet header satisfy any of one or more flow rules currently associated with the network node. The one or more fiow rules currently associated with the network node include the first buffer flow rule. The processor is configured to perform operations including storing the packet in a second buffer associated with unmatched packets, responsive to the determining that the packet is an unmatched packet, and transmitting the packet if the combination of fields of the packet header satisfy any of the one or more flow rules currently associated with the network node.

[0009] Some other embodiments of the present invention are directed to a controller node in communication with a network node that operates as a packet routing switch for routing packets in a telecommunications network, the controller node including a transceiver, a memory storing computer readable program code, and a processor connected to the transceiver and the memory, the processor configured to perform operations including transmitting a buffer creation message to the network node to create a first buffer for storing packets according to matching of a buffer flow rule.

[0010] Some other embodiments of the present invention are directed to a controller node in communication with a network node that operates as a packet routing switch for routing packets in a telecommunications network, the controller node including a transceiver, a memory storing computer readable program code, and a processor connected to the transceiver and the memory. The processor is configured to perform operations including transmitting, to the network node, an unmatched group flow rule to apply to an unmatched packet that does not match any of one or more flow rules currently associated with the network node. The unmatched group flow rule indicates at least one field of a packet header of the unmatched packet for associating the unmatched packet with an unmatched group flow rule buffer.

[001 1 ] Other methods and systems according to embodiments of the invention will be or become apparent to one with skill in the art upon review of the following drawings and detailed description. It is intended that all such additional methods and systems be included within this description, be within the scope of the present invention, and be protected by the accompanying claims. Moreover, it is intended that all embodiments disclosed herein can be implemented separately or combined in any way and/or combination.

BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Aspects of the present disclosure are illustrated by way of example and are not limited by the accompanying drawings. In the drawings:

[0013] Figure 1 is a block diagram of traffic flow in a telecommunications network, in accordance with some embodiments of the present disclosure.

[0014] Figure 2 is a block diagram of a SDN (Software Defined Networking) architecture, in accordance with some embodiments of the present disclosure.

[0015] Figure 3 is a flow rule for forwarding packets, in accordance with some embodiments of the present disclosure.

[0016] Figure 4 is a flowchart of operations for processing a packet by matching flow rules associated with buffers, in accordance with some embodiments of the present disclosure.

[0017] Figure 5 is a flowchart of operations and methods by a network node operating as a packet routing switch, in accordance with some embodiments of the present disclosure.

[0018] Figures 6 and 7 are flowcharts of operations and methods by a controller node, in accordance with some embodiments of the present disclosure.

[0019] Figure 8 is a data flow diagram of communication between a network node and a controller node, in accordance with some embodiments of the present disclosure. [0020] Figure 9 is a flowchart of operations and methods by a network node operating as a packet routing switch, in accordance with some embodiments of the present disclosure.

[0021] Figure 10 illustrates the format of a buffer unmatched message, in accordance with some embodiments of the present disclosure.

[0022] Figure 1 1 is a flowchart of operations for grouping unmatched packets, in accordance with some embodiments of the present disclosure.

[0023] Figures 12-18 are flowcharts of operations and methods by a network node operating as a packet routing switch, in accordance with some embodiments of the present disclosure.

[0024] Figure 19 is a flowchart of operations for grouping unmatched packets, in accordance with some embodiments of the present disclosure.

[0025] Figures 20 and 21 are flowcharts of operations and methods by a controller node for controlling a packet routing switch, in accordance with some embodiments of the present disclosure.

[0026] Figure 22 is a flowchart of operations for self-learning by a network node, in accordance with some embodiments of the present disclosure.

[0027] Figures 23 and 24 are flowcharts of operations and methods by a network node operating as a packet routing switch, in accordance with some embodiments of the present disclosure.

[0028] Figure 25 is a block diagram of a network node that is configured according to some embodiments of the present disclosure.

[0029] Figure 26 is a block diagram of modules forming a network node that is configured according to some embodiments of the present disclosure.

[0030] Figure 27 is a block diagram of a controller node that is configured according to some embodiments of the present disclosure.

[0031 ] Figures 28 and 29 are block diagrams of modules forming a controller node that is configured according to some embodiments of the present disclosure.

DETAILED DESCRIPTION

[0032] Inventive concepts will now be described more fully hereinafter with reference to the accompanying drawings, in which examples of embodiments of inventive concepts are shown. Inventive concepts may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of various present inventive concepts to those skilled in the art. It should also be noted that these embodiments are not mutually exclusive. Components from one embodiment may be tacitly assumed to be present/used in another embodiment.

[0033] Packet routing switches perform various operations to forward packets to destinations in a network based on flow rules. If an incoming packet does not match a flow rule, the packet routing switch forwards the packet to a controller node via the control plane. Large amounts of traffic in the control plane may reduce performance of the controller node and overall performance of the network. Legacy networks send every unmatched packet received at the packet routing switch to the controller node, until the controller receives a corresponding flow rule. Furthermore, buffering at the packet routing switch is triggered by unmatched packets.

[0034] Embodiments of the present disclosure arise from the recognition of a need for improved handling of packets at the network node operating as a packet routing switch, thereby reducing traffic in the control plane and/or reducing processing load on the network controller. More specifically, the network controller may create a buffer and an associated flow rule at the network node such that packets are stored in this buffer created by the network controller, instead of forwarding the packets to the network controller. In some embodiments, the network controller may send a message to the network node indicating how to group unmatched packets. In some embodiments, the network node may perform self-learning functions to determine grouping of packets.

[0035] Various embodiments described herein provide methods and devices related to handling of packets at the network node. Figure 1 is a block diagram of traffic flow in a telecommunications network. Referring now to Figure 1 , network nodes 110 receive data packets and forward the data packets to another network node 110 or user node 130 or forward the data packets to the controller node 120. Packets that arrive at the network node 110 that are not forwarded to the controller node 120 stay in the data plane. Some packets arrive at the network node 110 and are forwarded to the controller node 120 via the control plane. Control traffic from the controller node 120 to the network node 110 may include messages and instructions to the network node 120 regarding buffer creation and/or flow rule installation. [0036] Embodiments described herein may be applied to OpenFlow interfaces for a SDN (Software Defined Networking) architecture. OpenFlow is the first standard communications interface defined between the control and forwarding layers of an SDN architecture. OpenFlow allows direct access to and manipulation of the forwarding plane of network devices such as switches and routers, both physical and virtual (hypervisor-based). Figure 2 is a block diagram of a SDN (Software Defined Networking) architecture. SDN logically separates a software portion and a hardware portion in network elements such as routers and switches in order to simplify the network maintenance and accelerate the development of new network

applications.

[0037] As used herein, the terms "network node", "SDN switch", "packet routing switch", and/or "switch" may be used interchangeably in relation to network elements 1 10. The terms "controller node", "SDN controller", "network controller", "controller", and/or "control plane node" may be used interchangeably in relation to controller node 120. The SDN controller 120 usually has knowledge of the configurations and physical connections of the SDN switches 1 10, as well as some internal status of the SDN switches 110. The SDN switches 1 10 need flow rules from the SDN controller 120. Flow rules are installed on the SDN switch 1 10 via exchanging messages between the SDN controller 120 and the SDN switch 110 through the SDN southbound interface 220 using a southbound protocol, such as, for example, Openfiow.

[0038] Referring to Figure 2, a SDN architecture may include network elements 110 in an infrastructure layer that transport data traffic in the data plane. A SDN architecture may include SDN controller 120 in a control layer that transports packets in a control plane. A SDN southbound interface 220 may be defined between the infrastructure layer and the control layer. The SDN southbound interface 220 may be an Data-Controller Plane Interface (D-CPI). A SDN architecture may include SDN applications 210 in an application layer that transport relevant traffic in an application plane. SDN applications 210 interface the control layer through SDN northbound interfaces 230. The SDN northbound interface 230 may be an Application-Controller Plane Interface (A-CPI). Inventive concepts discussed herein mostly refer to the southbound interface 220 between network elements 110 and SDN controller 120. In a SDN architecture, network elements 1 10 such as network nodes and/or packet routing switches may not implement specific routing protocols (e.g. BGP, OSPF, RIP) or specific layer 2 protocols. Instead, switches in a SDN architecture may forward packets according to the flow rules set by the SDN controller 120. For example, a simple rule from the SDN controller to a specific network element 110 may indicate that all TCP packets received from interface A at network element 110 should be sent out through interface B. In such a case, when the network element 1 10 receives a TCP packet from its network interface A, it will forward the packets to network interface B.

[0039] Packet forwarding is an important function of a packet routing switch 1 10. A packet routing switch 110 has a set of flow rules that govern the forwarding of packets. When the packet routing switch 110 receives a packet, it checks whether the packet matches one of the flow rules. If there is a match to a flow rule, the packet will be processed according to the flow rule. An Openfiow example will now be discussed. A flow rule is illustrated in Figure 3.

Referring now to Figure 3, a flow rule 310 may include one or more match fields 320 that are used to match against incoming packets. These match fields 320 include headers of L2 and L3 layers, an ingress port from which interface the packet is received, and/or optional metadata. A counter 330 associated with flow rule 310 may keep the number of packets matching the flow rule 310. Instructions 340 associated with the flow rule are executed when a packet matches the flow rule 310. The instructions 340 may include a set of actions to be applied to the matching packets, such as, for example, decreasing the time -to-live (TTL) of the packet, setting header fields of the packets, and/or forwarding the packets to a specific output port.

[0040] The flow rules may match a packet in a priority order. The matched flow rule with the highest priority is used to determine the actions to apply to the packet. Setting the priority of the flow rules and handling of multiple flow rules with the same priority matching a packet will not be addressed here. If a packet does not match any of the flow rules, it is an unmatched packet. For an unmatched packet, the SDN switch may drop it, check the next flow table if the flow rules are divided into a set of flow tables, or send the packet to the controller for further processing. The action applied to the unmatched packets may be referred to as a default rule.

[0041] Some southbound protocols, such as the Openfiow specification, handle unmatched packets by applying a default rule of sending to the controller node. All unmatched packets may be sent to the controller node. If only the packet header of the packet is sent to the controller node, the packet would need to be buffered in the packet routing switch. If all unmatched packets are sent to the controller node, the controller node may respond to every packet from the packet routing switch by sending a flow rule or a set of actions only for that packet to the packet routing switch. This solution is not efficient in the case where some of the unmatched packets belong to the same flow. For example, the switch may not have rules for packets for some device which is identified by the destination IP address. When the packet routing switch receives packets with that particular destination IP address, only one such packet needs to be sent to the controller. Furthermore, the controller would only have to send back the corresponding flow rule once to the packet routing switch. However, in some Openfiow implementations, every such packet received by the switch is sent to the SDN controller until it receives the corresponding flow rule. This creates a large volume of control plane traffic, reducing the overall performance of the controller node and/or network.

Additionally, the buffering function in the SDN switch may be only triggered by unmatched packets. There may not be a generic buffer action that can be used in the flow rules to trigger placing the packets in the buffer. For example, the controller may want the switch to hold some specific packets until the controller is able to send further commands or rules to apply to them. Since legacy SDN switch implementations may not have a generic buffer action in the southbound protocol, packets matching specific match fields do not have a legacy mechanism to buffer the packets without sending the packets to the controller. Moreover, legacy systems do not relate different types of unmatched packets together to improve processing.

[0042] Embodiments described herein may be implemented in current SDN southbound protocols such as OpenFlow and/or may reduce the number of redundant packets from the same flow sent to the controller node from the network node. Furthermore, additional buffer actions described herein may extend the ability of the packet routing switch for use in congestion control, firewalls for intruder detection, etc. For example, the controller node may perform deep packet inspection of a packet and send an appropriate flow rule to the network node. This additional flow rule may be used by the network node for intruder detection and/or virus detection. The controller node's workload may be reduced since packets are grouped at the network node. The network node's functionality may be of increased complexity but the resulting reduced workload at the controller node may be advantageous in improving overall network performance. In some embodiments, rules for packet buffering may be pre-installed to provide a more efficient forwarding process for buffered packets. [0043] Network nodes have the ability to create buffers for storing packets. Each buffer may have attributes such as an ID, size, lifetime, etc. and may store one or more packets. The information in the buffers in the network node may be queried by the controller node. Figure 4 is a flowchart of operations for processing a packet by matching flow rules associated with buffers. Referring now to Figure 4, at block 410, a buffer creation command may be received at the network node from the controller node to create a first buffer and/or to install a first buffer flow rule associated with the first buffer. The controller node can ask the network node to create a buffer with a specific ID, or the switch may assign an ID to the buffer. A packet may be received, at block 420. The packet may be parsed to determine if it matches the first buffer flow rule, at block 430. If the first buffer flow rule is matched, then the packet is stored in the first buffer that was created by the controller node, at block 460. If the first buffer flow rule is not matched, then the packet is checked to see if other flow rules that are installed at the network node are matched, at block 440. If other flow rules are matched, then the packet is processed according to the other matched flow rules, at block 470. If the other flow rules are not matched, then the packet is an unmatched packet and is stored in a second packet buffer associated with unmatched packets, at block 450.

[0044] Figure 5 is a flowchart of operations and methods by a network node operating as a packet routing switch. Referring to Figure 5, the network node 1 10 of Figures 1 and 2 is configured to process data traffic, at block 510. A buffer creation message is received from a controller node 120 of Figure 1 to create a first buffer in memory associated with the network node 110 of Figure 1 and to install a first buffer flow rule associated with the first buffer, at block 520. The first buffer flow rule includes a set of one or more header fields. A packet including a packet header is received by the network node, at block 530. The packet is stored in the first buffer associated with the first buffer flow rule, responsive to one or more fields of the packet header being a subset of the first buffer flow rule or being among the set of the one or more header fields of the first buffer flow rule, at block 540. For example, the first buffer flow rule may have dstIP = 10.10.10.10 and srcIP = 12.12.12.12. For various embodiments, the subset of the first buffer flow rule may include any and all combinations of the set of header fields such as, for example, {dstIP}, {srcIP}, or {dstIP, srcIP} . In some embodiments, all data packets with dstIP = 10.10.10.10, regardless of srcIP may be consider to be a match. In some embodiments, all field specified in the first buffer flow rule would been to be matched such that only packets with dstIP = 10.10.10.10 and srcIP = 12.12.12.12 would be considered as a match to the flow rule. In this case, the network operator may only want to filter out packets with dstIP = 10.10.10.10 and srcIP = 12.12.12.12. As used herein, one or more fields of the packet header being a subset of the first buffer flow rule or being among the set of the one or more header fields of the first buffer flow rule may include matching the fields, such as, for example, determining that the packet is a TCP packet, or may include matching the content/value of the field, such as the actual IP address = 12.12.12.12 value of the field.

[0045] Still referring to Figure 5, the packet may be determined as being an unmatched packet if no combination of fields of the packet header satisfy any of one or more flow rules currently associated with the network node, at block 550. The one or more flow rules currently associated with the network node may include the first buffer flow rule that was used for buffer creation by the controller node. The packet may be stored in a second buffer associated with unmatched packets, responsive to determining that the packet is an unmatched packet, at block 560. If the combination of fields of the packet header satisfy any of the one or more flow rules other than the first buffer flow rule currently associated with the network node, the packet may be transmitted by the network node, at block 570. The packet is transmitted in accordance with the action associated with the flow rule that was matched.

[0046] Figures 6 and 7 are flowcharts of operations and methods by a controller node in communication with a network node that operates as a controller of a packet routing switch for routing packets in a telecommunications network. SDN switches have the ability to create buffers for storing packets. Each buffer may have attributes such as ID, sizes, lifetime, etc. A buffer can store one or more packets. Referring to Figure 6, a controller node may operate to control a packet routing switch, at block 610. A buffer creation message may be transmitted from the controller node to the network node to create a first buffer for storing packets according to matching of a buffer flow rule, at block 620. The network node may receive a packet that matches the buffer flow rule corresponding to the first buffer created by the controller node. The matched packet may be stored at the network node in the first buffer created by the controller node and may also be forwarded to the controller node. The entire packet or a portion of the packet, such as the header portion of the packet may be forwarded to the controller node.

Referring to Figure 7, the packet may be received by the controller node, from the network node, at block 710. The packet may include a packet header with one or more fields that are among a set of header fields of the buffer flow rule associated with the first buffer created by the controller node. The controller node may transmit to the network node, based on content of the packet that is received, a buffer action to apply to one or more packets in the first buffer, at block 720.

[0047] Figure 8 is a data flow diagram of communication between the network node and the controller node. Referring to Figure 8, the controller node 120 sends a message 1 to create a buffer at the network node including an identification (ID) associated with the buffer.

Optionally, parameters such as size of the buffer, lifetime for existence of the buffer, etc. may be specified in the same buffer creation message or in a separate message from the controller node 120. The controller node 120 may request the switch 110 to create a buffer with a specific ID, or the switch 1 10 can assign an ID to the buffer during or after creation. The switch 110 may respond with message 2 as an acknowledgement (ACK). The ACK message may indicate success or failure and, in the case of successful buffer creation, the ACK message may include attributes associated with the buffer that has been created. The controller node 120 may send a message 3 that includes a flow rule indicating match fields, a buffer action, and/or a buffer ID to identify the buffer. When the switch 110 installs this flow rule received in message 3, packets that match the match fields will be buffered in the associated buffer. If the buffer ID is given in message 3, then the packets will be buffered in the buffer with that ID. If the buffer ID is not provided in message 3, the switch 110 may decide the buffer in which packets are stored.

[0048] Information related to the buffers in the switch 1 10 can be queried by the controller node 120. Still referring to Figure 8, the controller node 120 may send message 4, a query requesting information from the switch 1 10. The query message may include a buffer ID identifying the buffer from which information is to be obtained. In some embodiments, associated with the buffer action, the controller node 120 may also query the status of the buffers. The controller may 120 may either ask the switch 1 10 for a buffer list, or query a specific buffer. This query procedure may be implemented using, for example the read state message in the Openflow. The switch 110 may send message 5, a reply message indicating information that was requested by the controller node 120, such as the number of packets in the buffer. The controller node 120 can later indicate to the switch 1 10 what to do with the buffered packets. As shown in message 6 of Figure 8, the controller node 120 can send a message including a flow rule with match fields and actions. The buffer ID in the message may be a specific ID or some unspecific one. An unspecific buffer ID may refer to a group of buffers or may include a special value indicating all the buffered packets at the switch 1 10. The flow rule may be applied to the packets in the buffer with the specific ID or the flow rule may be applied to all the buffered packets in the unspecified buffer ID case. The action indicated in flow rule message 6, could instruct the switch 1 10 to drop, forward to a port, access a flow table, etc.

Therefore, when the switch 1 10 receives the flow rule in message 6, the switch 110 will check all the buffered packets or check the packets in a specific buffer. The packets are treated according to the actions specified if they match the match fields. The packets failing to match the match fields will be dropped or may be kept in the buffer for further processing. In some embodiments, the packets failing to match the match fields may be sent to the controller node 120.

[0049] If some unmatched packets belong to the same flow, then only the first packet of this flow needs to be sent to the controller node. In this case, the controller node would need to send the corresponding flow rule once, such that all buffered packets belonging to the same flow can be treated based on the actions in this corresponding flow rule. However, before receiving the flow rule, the switch may not know how to group the unmatched packets, so that packets belonging to the same flow can be buffered together. Two methods for handling unmatched packets in SDN switches will now be discussed. The methods may applied when a default rule is sent to the controller. First, a new type of message may be used by the controller to indicate to the SDN switch how to buffer the unmatched packets. Second, the SDN switch may learn by itself about how to group the unmatched packets. These methods will now be discussed in detail.

[0050] Figure 9 is a flowchart of operations by a network node operating as a packet routing switch to handle unmatched packets. A new type of message referred to as a buffer unmatched message, may be defined. The buffer unmatched message may sent from the controller to the SDN switch. The buffer unmatched message may include packet fields that may be used for grouping the unmatched packets. The packet fields include header fields in the data- link layer, the network layer, and/or the transport layer. The buffer unmatched message may include an ingress port where the packets are received by the switch. Referring to Figure 9, the network node may receive, from the controller node, a buffer unmatched message indicating a set of one more group fields, at block 910. The buffer unmatched message may indicate from the controller to the switch that it should buffer the packets according to some fields, such as, for example, <srcIP, dstIP>. These fields indicated in the buffer unmatched message may be referred to as group fields. In this example, buffered packets that have the same source IP address and destination IP address would belong to the same group. A group may be a buffer with specific amount of space in the memory. The term "group" is used herein to avoid confusion with the general term "buffer".

[0051 ] Figure 10 illustrates the message format of a buffer unmatched message.

Referring to Figure 10, the buffer unmatched message 1010 may include a message type field 1020. The message type 1020 may be "buffer unmatched". Group fields 1030 indicating which header fields should be used for grouping the packets may be included in the buffer unmatched message. The controller may further instruct the switch how to buffer the packets by providing additional parameters 1040. Parameters 1040 may include, for example, a maximum number of packets buffered for each group, lifetime of a group, etc. In some embodiments, the group fields 1030 in the buffer unmatched message 1010 may be more specific, thus avoiding buffering of unwanted packets. For example, the controller may indicate to the switch to buffer unmatched TCP packets, and the buffered packets may be grouped according to the destination IP address. In this example, the group fields 1030 in the buffer unwanted message 1010 may be <dstIP, protocol=TCP>. Thus, unmatched packet that are not TCP packets will be dropped. The buffer unmatched message 1010 may be sent to the switch after the switch receives unmatched packets. In this case, the unmatched packets received before the buffer unmatched message 1010 are buffered individually and also sent to the controller as described previously. When the switch receives the buffer unmatched message 1010, the currently buffered packets are grouped according to the group fields 1030 in the buffer unmatched message 1010.

[0052] Figure 11 is a flowchart of operations for grouping unmatched packets. After receiving the buffer unmatched message from the controller node, the SDN switch knows how to group the unmatched packets. In particular, when the switch receives an unmatched packet at block 1110, a check of the fields of the packet is conducted to determine if the packet should be buffered, at block 1 120. If the unmatched packet should not be buffered it may be dropped, at block 1 140. If the unmatched packet needs to be buffered, the group ID may be determined, at block 1130. Upon successfully determining the group ID, a check for the existence of the group will be conducted, at block 1160. If the group does not exist, the unmatched packet is sent to the controller, at block 1 150. In some embodiments, if the group does not exit, the group is created, the packet or a portion of the packet such as the headers is sent to the controller, and the packet is inserted in the group. If the group exists, a check in the memory for space associated with the buffer indicated by the ID is made, at block 1170. If there is not space in the group, the packet is dropped, at block 1 140. If there is space in the group, the unmatched packet is appended to the buffer, at block 1180.

[0053] Figures 12 and 13 are flowcharts of operations and methods by a network node operating as a packet routing switch related to grouping of packets at the network node.

Referring to Figure 12, a group associated with the set of group fields received in the buffer unmatched message is created, responsive to all of the group fields in the set of group fields matching the one or more fields of the packet header of the unmatched packet, and responsive to determining that the group associated with the set of group fields does not exist, at block 1210. The packet may be transmitted to the controller node, responsive to the creating the group, at block 1220. The group associated with the set of group fields received in the buffer unmatched message may be identified, responsive to all of the group fields in the set of group fields matching the one or more fields of the packet header of the unmatched packet, at block 1230. Then the packet may be associated with the group, at block 1240. The group is associated with the second buffer such that the packet associated with the group is stored in the second buffer, which is for unmatched packets. Referring to Figure 13, the network node may refrain from transmitting the packet to the controller node, responsive to determining that the packet matches the one or more fields of the packet header of the unmatched packet in the group which exists before receiving the packet, at block 1310. Referring to Figure 14, the packet is stored in the second buffer for unmatched packets if the second buffer is identified as having enough memory for storing the packet, at block 1410. The packet is dropped if the second buffer is identified as not having enough memory for storing the packet, at block 1420.

[0054] Referring to Figure 15, the network node receives, from the controller, a group flow rule for processing packets in the group, at block 1510. Packets associated with the group are processed based on the group flow rule, at block 1520. Referring to Figure 16, the network node may delete the group from memory responsive to determining that the second buffer associated with the group, is empty, at block 1610. In some embodiments, referring to Figure 17, the group may be deleted from memory responsive to determining that a time limit is exceeded since a creation time of the group, at block 1710. Any packets left in the group will be dropped when the group reaches its lifetime. [0055] Referring to Figure 18, various techniques may be used to determine that the packet is an unmatched packet, at block 550. It may be determined that the packet is an unmatched packet if no combination of fields of the packet header match a subset of the header fields of any of one or more flow rules currently associated with the network node, at block 1810.

[0056] As previously discussed with respect to Figure 15, the group flow rule is received by the network node from the controller. Regarding sending a packet to the controller, the SDN switch may also optionally send the group ID with the packet to the controller. For

implementation purposes, a message type of an existing southbound protocol may be used. For example, the Packetln message in Openfiow may be used to send the group ID. In a Packetln message, the buffer ID field may be used to indicate the group ID.

[0057] The controller will send back a flow rule corresponding to the packet it received from the SDN switch. The controller may send back the flow rule with the group ID or without it. In the former case, the SDN switch will check all the packets in that group. Packets matching the rule will be treated according to the actions in the flow rule. Otherwise, the packets will be dropped or kept in the buffer for further processing such as sending the packets to the controller such that additional flow rules from the controller can be applied. In the latter case, the SDN switch will compute the group ID based on the match fields in the flow rule and the fields taken into the computation are the group fields defined in the buffer unmatched message. The match fields in the flow rule may include all the fields defined in the group fields. Otherwise, the group ID may not be correctly computed. Therefore, if the match fields do not completely include group fields, then the flow rule will be applied to all of the buffered packets.

[0058] The group ID is used to distinguish packets that have different values in the group fields. In other words, packets that have the same values in the group fields belong to the same group. Basically, the values in the group fields may be used as the group ID. For example, the group fields may include dstIP and srcPort. If there is an unmatched packet with

dstIP= 10.0.0.10, srcPort=1024, then the group ID for this packet may be " 10.0.0.10|| 1024", where || indicates concatenation of fields. In the byte format, there may be 6 bytes for this concatenated group ID (4 bytes for the IP address, 2 bytes for port number). The group ID format may not have fixed length, since it depends on the group fields. If the switch sends the group ID with the unmatched packet, then the group ID may be sent in a TLV (Type Length Value) format.

[0059] In some cases, the switch may send group IDs with fixed length, if for example, the existing Packetln message in Openflow is used. In this case, a hash value of the group ID may be sent to the controller. The hash value may have a fixed length such as, for example, 32 bits or 64b its. Well known hash functions such as CRC32 or CRC64 may be used. In the switch, there may be a hash table. A table entry in the hash table may be identified by a hash value. The keys in the hash table entry may be the group IDs which have that hash value.

Different keys may have the same hash values. The value for each key in the entry may be a pointer to the buffer of the corresponding group. When the controller sends a flow rule with a hash value, the switch can quickly locate the table entry using the hash value. If there are more than one group IDs in the entry, the switch may generate a group ID based on the match fields in the flow rule. The fields taken into the computation may be the group fields defined in the buffer unmatched message. The switch may get the pointer of the buffer for that group and apply the flow rule to the corresponding packets in the group. If there is only one group ID in the entry, then the switch may apply the flow rule to the packets in that group.

[0060] According to some embodiments, the network node may autonomously self-learn rules for grouping unmatched packets. A candidate set flow rule including a candidate set of match fields may be determined by the network node. As used herein, a "candidate set" may be a set of fields that the switch uses to group the unmatched packets. This candidate set is similar to the group fields that were described earlier with respect to Figure 10. If the default rule in a flow table for the unmatched packets is to send the unmatched packets to the controller, then the switch may study other rules in the flow table, to determine the most common header fields used in the other rules. These most common header fields will be used for grouping the unmatched packets.

[0061] Examples for deriving the candidate set will now be discussed. The candidate set may be derived from the existing flow rules in the switch or from new flow rules from the controller. The candidate set may be initially generated based on the flow rules that are already in the switch. Several criteria may be used to decide whether a field is important and should be included in the candidate set. Two non-limiting example criteria will be discussed in detail, but the criteria is not limited to these examples in various implementations. [0062] As a first example, if a header field is used in x% of the flow rules in the switch, where x is a parameter, then this header field will be included in the candidate set. As an example, if x is set to 90, then the switch scans all of the existing rules. If a field such as "dstIP", is used in more than 90% of the rules, than "dstIP" is included in the candidate set. The switch may have different actions for packets with different destination IP addresses. In this case, multiple flow rules may be populated in the flow table that each have the format

<dstIP=something, actions= do something>. Thus, the switch can learn that the destination IP address is an important field and may group the unmatched packets according to the destination IP address.

[0063] In the first example, every existing flow rule is treated equally. However, the number of incoming packets that match a specific rule may vary for different flow rules. As a second example, two flow rules may be defined:

flow rule 1 : protocol=TCP, srcPort= some port number, actions = do something flow rule 2: protocol= UDP, srcIP = some IP, actions = do something

For example, more than 10% of the incoming packets may match flow rulel, while less than 0.1% of the incoming packets may match flow rule 2. In this case, flow rule 1 is determined to be more important than flow rule 2. A flow rule may be designated as a "critical rule", if it matches more y% of the incoming packets. In this example, flow rule 2 may be designated as a critical rule.

[0064] Based on the critical rules that are determined, the candidate set can be derived in at least two ways. In some embodiments, if a header field is used in x% of the critical rules, then this field will be included in the candidate set. In some embodiments, a union of all the fields used in the critical rules may be included in the candidate set. For example, in the ongoing example, if both flow rule 1 and flow rule 2 are critical rules, then the candidate set may include <protocol, srcIP, srcPort>. In some embodiments, the switch may generate the candidate set based on the new flow rules received from the controller. For example, after the switch receives a number of flow rules from the controller, it may use criteria 1 to find important fields in these new flow rules, and put them into the candidate set. In this way, the candidate set may be updated after receiving additional flow rules. The switch may generate multiple candidate sets with different criteria, but at a given time, the switch uses one candidate set for buffering the unmatched packets. If the switch is unable to deduce important header fields that can be included in the candidate set, then the switch may not activate the self-learning function of grouping the unmatched packets.

[0065] Figure 19 is a flowchart of operations for grouping unmatched packets using self- learning at the network node. Referring to Figure 19, an unmatched packet is received at the network node, at block 1910. The group ID of the unmatched packet is determined, at block 1920. The unmatched packet is checked to see if it belongs to an existing group that already has packets, according to the values in the fields which belong to the candidate set, at block 1950. If the group does not already exist, than the unmatched packet or a portion of the unmatched packet such as the headers, is sent to the controller node, at block 1940, and then placed in the buffer, at block 1970. If the group does already exist, then the associated buffer is checked for enough space for the packet, at block 1960. If there is not enough space in the buffer, the packet is dropped, at block 1930. If the buffer has enough space for the unmatched packet, it is placed in the buffer and/or appended to the group, at block 1970.

[0066] The network node may send to the controller node an unmatched packet for which a group does not already exist at the network node. Figures 20 and 21 are flowcharts of operations and methods by a controller node for controlling a packet routing switch for handling unmatched packets. Referring to Figure 20, the controller node may transmit, to the network node, an unmatched group flow rule to apply to an unmatched packet that does not match any of one or more flow rules currently associated with the network node, at block 2020. The unmatched group flow rule indicates at least one field of a packet header of the unmatched packet for associating the unmatched packet with an unmatched group flow rule buffer.

Referring to Figure 21 , the controller node may receive, from the network node, a packet with a packet header including one or more fields that are among a set of header fields of the unmatched group flow rule, at block 21 10. The controller may transmit, to the network node, based on the packet that is received, a buffer action to apply to packets in the unmatched group flow rule buffer, at block 2120.

[0067] Figure 22 is a flowchart of operations for self-learning by a network node.

Referring to Figure 22, a flow rule is received from the controller node by the network node, at block 2210. If the match fields used in the flow rule correspond to the fields in the candidate set, at block 2220, then the group ID is computed at block 2230. The buffered packets belonging to that group are processed accordingly, by applying the flow rule to the group, at block 2250. If the match fields used in the flow rule include the fields in the candidate set and have at least one more field (i.e. match fields > candidate set), the group ID is computed, at block 2230, based on the flow rule and the fields taken into the computation are the fields defined in the candidate set. The packets that match the flow rule will be processed according to the actions in the flow rule by applying the flow rule to the buffered packets, at block 2240. Packets that do not match the flow rule may be regrouped according to the fields used in the flow rule, at block 2260. If there are multiple candidate sets, packets that do not match the flow rule may be regrouped according to another candidate set. The network node may send one packet of each new group to the controller after regrouping, at block 2270. The candidate set may be updated according to the match fields in the flow rule. If the match fields match the candidate set at block 2280, processing is complete at block 2290. If the match fields do not match the candidate set at block 2280, the remaining packets may be regrouped according to the fields used in the flow rule, at block 2260. If the match fields used in the flow rule do not include all the fields in the candidate set, then the buffered unmatched packets will be checked against the flow rule. Packets that match the flow rule will be processed according to the actions in the flow rule. Packets that are not match the flow rule will be regrouped according to the fields used in the flow rule. The switch will send one packet of each new group to the controller. The candidate set will be updated according to the match fields in the flow rule. In this case, the group ID is not computed because the groups generated by the candidate set may not be useful. The candidate set can be recomputed when new flow rules are installed in the switch. Each group may have lifetime after which the group is removed, deleted, and/or destroyed.

[0068] For the case of grouping by the network node, the controller node is unaware of the groups formed by the network node. The network node performs application of flow rules received from the controller node, based on the grouping. For example, assuming that the candidate set is <srcIP, dstIP>, before the new flow rule arrives, there are two groups at the switch:

Group 1 : srcIP=10.0.0.10, dstIP=88.192.10.16

Group 2: srcIP=10.0.0.10, dstIP=90.178.10.10

The controller may send new flow rule with fields: dstPort=80, action= do something. The existing groups may each contain packets that match the flow rule. Therefore, all the buffered packets will be checked against the flow rule for this case. However, the flow rule may have fields:

srcIP=10.0.0.10, dstIP=88.192.10.16, dstPort=80, action= do something.

For this case, the group ID is computed to include group 1. Therefore the switch only needs to check the packets in group 1 against the flow rule.

[0069] Another example will be discussed to aide in understanding the formation of groups and deriving of the candidate set. The candidate set may only include <dstIP>.

Therefore, the switch groups the unmatched the packets according to the <dstIP>. The switch may receive a new flow rule from the controller which is:

<dstIP=10.0.0.10, actions= do something>

In this case, the match fields of the flow rule only include dstIP which is the same as the candidate set. Then the switch applies the rule to the group which buffers the unmatched packets with dstIP 10.0.0.10. As another example, the flow rule may be:

<dstIP=10.0.0.10, srcIP=80.0.0.10, actions= do something> In this case, the switch can still apply the rule to the group which buffers the unmatched packets with dstIP 10.0.0.10. But after that, the switch regroups the buffered packets according to <dstIP, srcIP>, and sends a packet of each new group to the controller. The candidate set is updated to <dstIP, srcIP>. As yet another example, the flow rule may be:

<srcPort=4040, dstPort=80, actions = do something>

In this case, the switch will apply the flow rule to all the buffered packets. After applying the flow rule to all the buffered packets, the switch may regroup the buffered packets according to <srcPort, dstPort>, and sends a packet of each new group to the controller. The candidate set may be then updated to <srcPort, dstPort>.

[0070] Figures 23 and 24 are flowcharts of operations and methods by a network node operating as a packet routing switch using a candidate set. Referring to Figure 23, storing the packet in the second buffer associated with unmatched packets, at block 560 will be described further. A candidate set flow rule may be derived, at block 2310. The candidate set flow rule may include a candidate set of match fields based on one or more fields in the one of more flow rules currently associated with the network node. The network node may determine if one or more fields of the packet header of the packet are a subset of the candidate set, at block 2320. The packet may be associated to the candidate set flow rule responsive to the determining that the one or more fields of the packet header of the packet are the subset of the candidate set, at block 2330. The packet that was associated to the candidate set fiow rule is stored in the second buffer, if one or more fields of the packet header of the packet are the subset of the candidate set, at block 2340. Referring to Figure 24, in some embodiments, the network node may receive from the controller node, a candidate action to be associated with the candidate set flow rule for handling packets associated with the candidate set flow rule, at block 2410. The flow rules currently associated with the network node may take precedence over the candidate set flow rule that was derived.

[0071] Figure 25 is a block diagram of a network node 2510 that is configured according to some embodiments of the present disclosure. Referring to Figure 25, the network node 2510 may correspond to the network node HO of Figure 1 and/or Figure 2. The network node 2510 includes a processor 2520, a memory 2540, and a transceiver circuit 2530 that interfaces to the control plane and/or the data plane. The transceiver circuit 2530 may include, but is not limited to, a LTE or other cellular transceiver, WIFI transceiver (IEEE 802.11), Bluetooth, WiMax transceiver, or other wireless communication transceiver configured to communicate with the controller node 120 of Figure 1 and/or Figure 2.

[0072] The processor 2520 may include one or more data processing circuits, such as a general purpose and/or special purpose processor (e.g., microprocessor and/or digital signal processor) that may be collocated or distributed across one or more networks. The processor 2520 is configured to execute computer program code 2550 in the memory 2540, described below as a non-transitory computer readable medium, to perform at least some of the operations described herein as being performed by a network node. The memory 2540 may further include the first buffer 2560 and/or the second buffer 2570.

[0073] Figure 26 is a block diagram of modules forming a network node 2610 that is configured according to some embodiments of the present disclosure. Referring to Figure 26, the network node 2610 may correspond to the network node 110 of Figure 1 and/or Figure 2, and/or network node 2510 of Figure 25. The modules of network node 2610 include buffer creation module 2620, packet reception module 2630, a first package storage module 2640, determination module 2650, a second packet storage module 2660, and a transmission module 2670. The buffer creation module 2620 is for receiving a buffer creation message from a controller node to create a first buffer in memory and/or to install a first buffer flow rule associated with the first buffer. The packet reception module 2630 is for receiving a packet. The first package storage module 2640 is for storing the packet in the first buffer associated with the first buffer flow rule, responsive to one or more fields of the packet header being among the set of the one or more header fields of the first buffer flow rule. The determination module 2650, determining that the packet is an unmatched packet if no combination of fields of the packet header satisfy any of one or more flow rules currently associated with the network node 2610. The second packet storage module 2660 is for storing the packet in a second buffer associated with unmatched packets, responsive to the determining that the packet is an unmatched packet. The transmission module 2670 is for transmitting the packet if the combination of fields of the packet header satisfy any of the one or more flow rules currently associated with the network node 2610, other than the first buffer flow rule.

[0074] Figure 27 is a block diagram of a controller node 2710 that is configured according to some embodiments of the present disclosure. Referring to Figure 27, the controller node 2710 may correspond to the controller node 120 of Figure 1 and/or Figure 2. The controller node 2710 includes a processor 2720, a memory 2740, and a transceiver circuit 2730 that interfaces to the control plane and/or the data plane. The transceiver circuit 2730 can include, but is not limited to, a LTE or other cellular transceiver, WIFI transceiver (IEEE 802.11), Bluetooth, WiMax transceiver, or other wireless communication transceiver configured to communicate with the network node 1 10 of Figure 1 and/or Figure 2.

[0075] The processor 2720 may include one or more data processing circuits, such as a general purpose and/or special purpose processor (e.g., microprocessor and/or digital signal processor) that may be collocated or distributed across one or more networks. The processor 2720 is configured to execute computer program code 2750 in the memory 2740, described below as a non-transitory computer readable medium, to perform at least some of the operations described herein as being performed by a controller node.

[0076] Figures 28 and 29 are block diagrams of modules forming a controller node that is configured according to some embodiments of the present disclosure. Referring to Figure 28, the controller node 2810 may correspond to the controller node 120 of Figure 1 and/or Figure 2, and/or controller node 2710 of Figure 27. The modules of controller node 2810 include buffer creation module 2820 that is configured for transmitting a buffer creation message to the network node 2610 to create a first buffer for storing packets according to matching of a buffer flow rule. [0077] Referring to Figure 29, the controller node 2910 may correspond to the controller node 120 of Figure 1 and/or Figure 2, controller node 2710 of Figure 27, and/or controller node 2810 of Figure 28. The modules of controller node 2910 include rule transmission module 2920 that is configured for transmitting, to the network node 2610, an unmatched group flow rule to apply to an unmatched packet that does not match any of one or more flow rules currently associated with the network node 2610.

Further Definitions and Embodiments:

[0078] In the above-description of various embodiments of present inventive concepts, it is to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of present inventive concepts. Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which present inventive concepts belongs. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of this specification and the relevant art and will not be interpreted in an idealized or overly formal sense expressly so defined herein.

[0079] When an element is referred to as being "connected", "coupled", "responsive", or variants thereof to another element, it can be directly connected, coupled, or responsive to the other element or intervening elements may be present. In contrast, when an element is referred to as being "directly connected", "directly coupled", "directly responsive", or variants thereof to another element, there are no intervening elements present. Like numbers refer to like elements throughout. Furthermore, "coupled", "connected", "responsive", or variants thereof as used herein may include wirelessly coupled, connected, or responsive. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. Well-known functions or constructions may not be described in detail for brevity and/or clarity. The term "and/or" includes any and all combinations of one or more of the associated listed items.

[0080] It will be understood that although the terms first, second, third, etc. may be used herein to describe various elements/operations, these elements/operations should not be limited by these terms. These terms are only used to distinguish one element/operation from another element/operation. Thus a first element/operation in some embodiments could be termed a second element/operation in other embodiments without departing from the teachings of present inventive concepts. The same reference numerals or the same reference designators denote the same or similar elements throughout the specification.

[0081] As used herein, the terms "comprise", "comprising", "comprises", "include", "including", "includes", "have", '¾as", "having", or variants thereof are open-ended, and include one or more stated features, integers, elements, steps, components or functions but does not preclude the presence or addition of one or more other features, integers, elements, steps, components, functions or groups thereof. Furthermore, as used herein, the common abbreviation "e.g.", which derives from the Latin phrase "exempli gratia," may be used to introduce or specify a general example or examples of a previously mentioned item, and is not intended to be limiting of such item. The common abbreviation "i.e.", which derives from the Latin phrase "id est," may be used to specify a particular item from a more general recitation.

[0082] Example embodiments are described herein with reference to block diagrams and/or flowchart illustrations of computer-implemented methods, apparatus (systems and/or devices) and/or computer program products. It is understood that a block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, can be implemented by computer program instructions that are performed by one or more computer circuits. These computer program instructions may be provided to a processor circuit of a general purpose computer circuit, special purpose computer circuit, and/or other programmable data processing circuit to produce a machine, such that the instructions, which execute via the processor of the computer and/or other programmable data processing apparatus, transform and control transistors, values stored in memory locations, and other hardware components within such circuitry to implement the functions/acts specified in the block diagrams and/or flowchart block or blocks, and thereby create means (functionality) and/or structure for implementing the functions/acts specified in the block diagrams and/or flowchart block(s).

[0083] These computer program instructions may also be stored in a tangible computer- readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instructions which implement the functions/acts specified in the block diagrams and/or flowchart block or blocks. Accordingly, embodiments of present inventive concepts may be embodied in hardware and/or in software (including firmware, resident software, micro-code, etc.) that runs on a processor such as a digital signal processor, which may collectively be referred to as "circuitry," "a module" or variants thereof.

[0084] It should also be noted that in some alternate implementations, the functions/acts noted in the blocks may occur out of the order noted in the flowcharts. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality/acts involved. Moreover, the functionality of a given block of the flowcharts and/or block diagrams may be separated into multiple blocks and/or the functionality of two or more blocks of the flowcharts and/or block diagrams may be at least partially integrated. Finally, other blocks may be added/inserted between the blocks that are illustrated, and/or blocks/operations may be omitted without departing from the scope of inventive concepts. Moreover, although some of the diagrams include arrows on communication paths to show a primary direction of

communication, it is to be understood that communication may occur in the opposite direction to the depicted arrows.

[0085] Many variations and modifications can be made to the embodiments without substantially departing from the principles of the present inventive concepts. All such variations and modifications are intended to be included herein within the scope of present inventive concepts. Accordingly, the above disclosed subject matter is to be considered illustrative, and not restrictive, and the appended examples of embodiments are intended to cover all such modifications, enhancements, and other embodiments, which fall within the spirit and scope of present inventive concepts. Thus, to the maximum extent allowed by law, the scope of present inventive concepts are to be determined by the broadest permissible interpretation of the present disclosure including the following examples of embodiments and their equivalents, and shall not be restricted or limited by the foregoing detailed description.