Abstract:
Presented are methods for performing a constant time flow lookup utilizing parallel processing technology. The methods are suitable for multiprocessor and/or multi-core processor computing environments. The method generates hash table driven tables of exact flow matching patterns and then provides the generated tables to parallel processing based flow selection procedure that iteratively finds the highest priority flow from the exact flow matching patterns. The method is scalable based on the linear relationship between the number of processors and/or processor cores and the time required to perform the lookup. The method is also portable because it does not require any special or custom hardware typically associated with this type of lookup.

Description:
RELATED APPLICATION 
     The present application is related to, and claims priority from, U.S. Provisional Patent Application No. 61/348,038, filed May 25, 2010, entitled “Method for Enhancing Table Lookups with Exact and Wildcards Matching for Parallel Environments”, to Rerngvit Yanggratoke and Hareesh Puthalath, the disclosure of which is incorporated herein by reference. 
    
    
     TECHNICAL FIELD 
     The present invention relates generally to table lookups and more specifically to performing deterministic lookups tuned for parallel or multi-core processor systems utilizing single instruction multiple data (SIMD) instructions. 
     BACKGROUND 
     A lookup operation on the table with one or more columns with fields consisting of exact and wildcard values is important for many network technologies. The technologies include, but are not limited to, flow lookup in an OpenFlow switch, forwarding table lookups, policy tables, etc. The flow lookup in an OpenFlow switch will be described in this document as an exemplary embodiment. It should be noted that the described method is applicable to other technologies using both exact and/or wildcard table lookup techniques. 
     OpenFlow is an open standard for decoupling the control path and data path in a switch. OpenFlow aims to provide a highly configurable and flexible switch. OpenFlow works with two separate components including a controller and an OpenFlow switch as shown in  FIG. 1 . The controller can be located in the same device or on another device on the network. The controller controls the OpenFlow switch via a secure channel using the OpenFlow protocol. The basic concept in an OpenFlow switch lies in the notion of a flow. The flows are stored in a table called a flow table. Each flow is associated with a flow action, executed by the switch if the packet is matched against the flow. Example actions include, but are not limited to dropping a packet or forwarding a packet to a predefined port associated with the action. 
     The flow table consists of the flow entries with each entry made up of the 12 fields shown in Table 1 and not every field is applicable for every packet. The applicability of each field depends on the packet type as noted in the last column of the table. Each field inside the flow can be specified with exact or any value. If the flow contains at least one any value, the row is a wildcard matching flow, otherwise, the flow is an exact matching flow. 
     
       
         
               
             
               
               
               
             
               
               
               
             
           
               
                 TABLE 1 
               
             
             
               
                   
               
               
                 Flow fields in OpenFlow flow table 
               
             
          
           
               
                 No. 
                 Field 
                 When applicable 
               
               
                   
               
             
          
           
               
                 1 
                 Ingress port 
                 Every packet 
               
               
                 2 
                 Ethernet source address 
                 Every packet on enabled-ports 
               
               
                 3 
                 Ethernet destination address 
                 Every packet on enabled-ports 
               
               
                 4 
                 Ethernet type 
                 Every packet on enabled-ports 
               
               
                 5 
                 VLAN id 
                 Every packet with Ethernet type 
               
               
                   
                   
                 equal to 0x8100 
               
               
                 6 
                 VLAN priority 
                 Every packet with Ethernet type 
               
               
                   
                   
                 equal to 0x8100 
               
               
                 7 
                 IP source address 
                 Every packet with Ethernet type 
               
               
                   
                   
                 equal to 0x0800 (IP) and 
               
               
                   
                   
                 0x0806 (ARP) 
               
               
                 8 
                 IP destination address 
                 Every packet with Ethernet type 
               
               
                   
                   
                 equal to 0x0800 (IP) and 
               
               
                   
                   
                 0x0806 (ARP) 
               
               
                 9 
                 IP protocol 
                 Every IP, IP over Ethernet, and 
               
               
                   
                   
                 ARP packet 
               
               
                 10 
                 IP ToS bits 
                 Every packet with Ethernet type 
               
               
                   
                   
                 equal to 0x0800 (IP) 
               
               
                 11 
                 Transport source port/ICMP 
                 Every TCP, UDP, and ICMP 
               
               
                   
                 type 
                 packet 
               
               
                 12 
                 Transport destination port/ICMP 
                 Every TCP, UDP, and ICMP 
               
               
                   
                 code 
                 packet 
               
               
                   
               
             
          
         
       
     
     A packet arriving at the OpenFlow switch will be looked up in the flow table. If the packet matches a flow, either exact or wildcard matching flow, the specified action associated with the flow will be executed on the packet. Each wildcard matching flow has a priority assigned and if a packet matches multiple wildcard flows, the highest priority wildcard flow will be selected. An exact matching flow is always given higher priority than a wildcard matching flow. If the packet could not be matched with any flows then it will be sent to the controller for further instruction. The flow lookup is a computation-intensive task for an OpenFlow switch because the lookup must be performed on every packet. 
     Single Instruction Multiple Data (SIMD) is a type of parallel computing where multiple processing units process several data items concurrently. A SIMD style of processing is utilized in vector processing when the same instruction is executed on independent data items. This style of processing architecture is highly efficient for data parallel style of computing. An example of a vector processor using SIMD style of parallel computing is a graphical processing unit (GPU). The processor operates on multiple data concurrently with the condition that the instruction has to be the same for every processing unit. As a result, to fully exploit this architecture, the problem or algorithm has to be designed for data parallel processing. Because the flow lookup operation for a packet is computation intensive, as explained in the previous section, a SIMD processor is a cost effective solution for improving the lookup performance. By improving the lookup algorithm to utilize a data parallel style, several entries could be concurrently processed with a SIMD processor. 
     The existing solutions consist of both software and hardware based implementations. The software implementation is used in the Openflow switch reference implementation. An example of the hardware implementation is the NetFPGA OpenFlow switch reference implementation. 
     The software implementation lookups the flows in the flow table with the hash-then-linear lookup shown in  FIG. 2 . The lookup consists of two consecutive phases including hashing lookup and linear lookup phase. In the hashing lookup phase, the headers of a packet arriving to the switch will be extracted and then the hashing lookup will be performed on all of the 12 fields. If the hashing lookup found the exact matching flow, the search ends immediately. Otherwise, the search will continue to the linear lookup for wildcard matching flow. In the linear lookup phase, the search will start on the highest priority flow and go on until the end of the wildcard matching flow table as shown in  FIG. 3 . 
     The hardware implementation looks up the flow with several stages as shown in  FIG. 4 . The header parser component will extract fields from the packet and pack them together. Then, the packed fields will be sent to the Wildcard Lookup and the Exact Match Lookup modules. Both the Wildcard Lookup and Exact Match Lookup modules will operate simultaneously. The Exact Match Lookup module uses a hashing lookup into an off-chip static random access memory (SRAM) while the Wildcard Lookup performs its operation with on-chip ternary content addressable memory (TCAM). The result of both lookups will go into the arbiter to select the highest priority result. The arbiter will control the Packet Editor, modifying the packet according to the matched flow. 
     Existing solutions suffer from various drawbacks. The software based hash-then-linear lookup has a problem with the linear lookup operation for the wildcard matching flow. The processing complexity (P c ) of the linear lookup is function of the number of wildcard matching flows (n), i.e. P c (n). In other words, the required computation steps will grow based on the number of wildcard matching flows in the flow table and therefore is not a scalable solution because of the reduction in lookup speed. 
     The hardware solution offers the line rate packet lookup and forwarding for both exact and wildcard matching flows. However, the hardware solution demands special and expensive hardware including SRAM for exact matching lookup and TCAM for wildcard matching lookup. Accordingly, the hardware solution will have a limited size of the flow table. The limitations for current implementations are 32000 and 32 entries for the exact matching flows and wildcard matching flows respectively. Additionally, there are limitations in space and power utilization and the need for custom chips. 
     Accordingly, market pressure is building for a method and system capable of providing a deterministic table lookup without requiring expensive and/or custom hardware. It is desirable that the method and system be scalable in a multi-processor and/or a multi-core computing environment. 
     SUMMARY 
     Methods address the market needs described above by providing the capability lookup a highest priority flow based on an arriving packet. The methods generate flow exact patterns and utilize the flow exact patterns to perform a parallel processed flow selection based on determining the highest priority flow. The methods store the flow exact patterns in a table of hash tables for efficient selection. The methods further iterate through the table of hash tables until the highest priority flow is determined. 
     In one exemplary method embodiment, a plurality of flow exact patterns is generated, based on an associated flow table, for grouping flows based on similar exact value fields. In another aspect of the exemplary method embodiment, a parallel flow selection, based on the previously generated flow exact patterns, is performed for selecting the highest priority flow from the flow exact patterns. 
     In another exemplary method embodiment, flows are grouped together for efficient processing. In another aspect of the exemplary method embodiment, a plurality of flows are compared and the indexes of all flows wherein all fields of the flows have the same exact value are grouped together. In another aspect of the exemplary method embodiment, a table is generated for each generated group of matching flows. In a further aspect of the exemplary embodiment, a predetermined flow priority is stored in the table with each flow index. 
     In yet another exemplary method embodiment, the highest priority flow from a group of flows is selected. In one aspect of the exemplary embodiment, the plurality of flows is distributed equally among a plurality of processors and/or processor cores. In another aspect of the exemplary embodiment, a first iteration by each processor and/or processor core through the assigned flows compares priorities to determine the flow with the highest priority. In another aspect of the exemplary embodiment, a second iteration of comparing the output from each processor and/or processor core is performed to determine the flow with the highest priority. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The accompanying drawings illustrate exemplary embodiments, wherein: 
         FIG. 1  depicts a prior art system of an OpenFlow system providing a lookup capability using the OpenFlow protocol between an OpenFlow switch and a controller; 
         FIG. 2  depicts a prior art method of providing a lookup based on a hashing lookup and a linear lookup; 
         FIG. 3  depicts a prior art software-based lookup method for a wildcard matching flow of an OpenFlow switch; 
         FIG. 4  depicts a prior art hardware-based lookup method of an OpenFlow switch; 
         FIG. 5  depicts an SIMD exact and wildcard lookup method for a parallel processing environment; 
         FIG. 6  depicts a flow exact pattern hash table generation method for a parallel processing environment; 
         FIG. 7  depicts a parallel flow selection method for a parallel processing environment; 
         FIG. 8  depicts a method for enhancing table lookups with flow exact and wildcard matching for parallel environments; 
         FIG. 9  depicts an exemplary computing device for implementing a method for enhancing table lookups with flow exact and wildcard matching for parallel environments. 
     
    
    
     DETAILED DESCRIPTION 
     The following detailed description of the exemplary embodiments refers to the accompanying drawings. The same reference numbers in different drawings identify the same or similar elements. Also, the following detailed description does not limit the invention. Instead, the scope of the invention is defined by the appended claims. 
     The flow lookup in an OpenFlow switch will be described in this document as an exemplary embodiment. It should be noted that the described method is applicable to other technologies using both exact and/or wildcard table lookup techniques. 
     Looking first to  FIG. 1 , a diagram  100  of a prior art system of providing a lookup operation is illustrated and will provide a context for describing the exemplary embodiments provided herein. The prior art system includes an OpenFlow switch  102  communicating with a controller  104  using the OpenFlow protocol  110 . Further, the prior art method depicts a secure channel  106  and a flow table  108  as components of the OpenFlow switch  102 . A detailed description of this prior art is presented in the above described background section. 
     Looking now to  FIG. 2  and another prior art embodiment, is a software method for providing a lookup operation. The prior art method begins with a packet  202  arrival and a hashing lookup  204  based on the fields included in the packet  202 . If an exact matching flow  206  is found then the lookup is complete. If an exact matching flow  206  is not found, then the lookup method proceeds with a linear lookup  208 . If a wildcard matching flow  210  is found then the lookup is complete. If a wildcard matching flow  210  is not found  212  then the packet is forwarded to the controller for further processing. It should be noted, as described in the background section that the linear lookup  208  step is a non-deterministic step and can therefore take a significant amount of time based on the processing capabilities of the computing environment. 
     Looking now to  FIG. 3 , a further prior art exemplary method embodiment  300  of the software based linear lookup in an OpenFlow switch is illustrated. As described previously in the background section, the linear lookup  318  begins on the highest priority  316  flows  302 ,  304 ,  306 ,  308 ,  310  in the wildcard matching flow table  320  and proceeds until a match is found or the end of the wildcard matching flow table  320  is reached. 
     Turning now to  FIG. 4 , another prior art exemplary embodiment  400  of a hardware based linear lookup in an OpenFlow switch is illustrated. As described previously in the background section, the header parser  402  will extract fields from the incoming packet and pack them together for simultaneous delivery to the exact match lookup component  404  and the wildcard lookup component  406 . In the prior art embodiment, the exact match lookup component  404  uses a hashing lookup into off-chip static random access memory (SRAM)  412  while the wildcard lookup component  406  performs the wildcard lookup on on-chip ternary content addressable memory (TCAM). The prior art exemplary embodiment continues with both results provided to the arbiter component  408  where the highest priority result is selected and provided to the packet editor  410  to modify the packet according to the matched flow, as directed by the arbiter  408 . 
     The following exemplary method embodiments describe a mechanism to facilitate exact matching flow lookup and wildcard flow lookup in a manner that is ideal for a parallel processor utilizing single instruction multiple data (SIMD) instructions or a multi-core processor. The exemplary method embodiments provide a constant time lookup for both the exact matching and the wildcard matching without a time consuming and unbounded linear lookup or special and expensive hardware. Further, the exemplary embodiments are scalable to the number of SIMD cores providing for a definable increase in capacity and/or performance. For example, the constant time is reduced linearly with the increasing number of SIMD execution cores. Unlike the prior art illustrated previously, the exemplary embodiments provide a flow exact pattern method and a parallel flow selection method constructed to take advantage of a parallel computing environment utilizing SIMD instruction set computation. 
     Looking now to  FIG. 5 , an exemplary embodiment  500  of a mechanism to perform a deterministic lookup utilizing a flow exact pattern  502  and a parallel flow selection  504  is depicted, including a packet  506  for processing, the flows  508 ,  510 ,  512 ,  514  associated with the arriving packet  506 , the hash tables  516 ,  518 ,  520 ,  522  associated with the flow exact patterns  502 , the parallel flow selection  504  mechanism for selecting a lookup result  524  based on the array of flow index with local maximum priority. Next in the exact pattern lookup phase of the exemplary embodiment, the lookup is described by the following pseudo code: 
                                                                                     For each Pi concurrently do                For each e ∈ Ei do                f = LF(e)                if (f != −1 &amp;&amp; Priority(f) &gt; Priority(MaxFi))                MaxFi = f                        
with P=Set of SIMD cores; Pi=SIMD core at index i; LF(e)=function to lookup a flow index from a flow exact pattern hash table based on a flow exact pattern (e) and return a valid flow index for a match or a non-valid flow index if a match is not found; Priority(f)=function to lookup the priority value based on the flow index; MaxF=array containing flow indexes with local maximum priority shared across the set P; MaxFi=flow index with local maximum priority for each Pi (initialized to a non-valid index value); and Ei=set of flow exact patterns distributed equally to Pi.
 
     Continuing with the exemplary embodiment, as stated in the pseudo code, the flow exact patterns  502  are distributed equally among the SIMD cores and, the operations inside the loop including LF(e), Priority(f), and comparisons are constant time operations. Accordingly, the computation time is calculated as O(E/P) where E is the number of flow exact patterns (maximum number is 4096 for the 12 field exemplary embodiment) and P is the number of SIMD cores. The output from this phase, flow exact patterns, is the MaxF array containing flow indexes with local maximum priority and the output array&#39;s size is P. It should be noted in the exemplary embodiment that this array is an input to the second phase parallel flow selection. 
     Next in the exemplary embodiment, the parallel flow selection  504  second phase, the MaxF array is searched by the previously described parallel flow selection  504 . With respect to the exemplary embodiment of  FIG. 7 , it can be seen that such a search uses log 2 n computation time where n is the number of input values. As a result for this exemplary embodiment, the computation time for the parallel flow selection  504  phase is O(log 2 P). Combining the flow exact pattern  502  phase and the parallel flow selection  504  phase, the total computation time is O(E/P+log 2 P) where the maximum for E is 4096 in the twelve field example of the exemplary embodiment. 
     The exemplary embodiments provide a constant time lookup and scalability to the number of multi-processor cores using SIMD instruction sets, without the use of any special hardware. It should be noted in the exemplary embodiments that the number of computation steps is bounded by the maximum number of flow exact patterns. It should also be noted in the exemplary embodiments that the bounded steps provide the constant time lookup for both the exact matching flows and the wildcard matching flows. Further, it should be noted, as illustrated previously, that the exemplary embodiments constant time operations are scalable to additional processors and/or multi-core processors with a greater number of cores providing for a scalable solution that reduces the lookup time linearly by adding additional processors or cores. The exemplary embodiments are also portable because no dedicated hardware is required to perform the lookup and the size of the flow tables can be significantly larger than the lookup tables associated with a dedicated hardware solution based on the expense of the dedicated hardware. 
     In another aspect of the exemplary embodiment, an apparatus comprising a plurality of processor cores can be configured to generate a plurality of flow exact patterns, based on an associated plurality of flows and to select a highest priority flow utilizing a parallel flow selection, based on the plurality of flow exact patterns. It should be noted that the processor cores of the apparatus should be configured to execute single instruction multiple data instructions (SIMD). Continuing with the exemplary embodiments, an apparatus comprising a plurality of processor cores can be configured to compare a plurality of flows and group indexes of all flows where all the exact fields of the plurality of flows having the same exact value are matched, to generate a table for each group of said indexes and to store a predetermined flow priority with each flow index in the table. It should be further noted that an additional entry is generated in the table with all fields being wildcards for a default matching entry. Further, in an exemplary embodiment, an apparatus comprising a plurality of processor cores can be configured to distribute a plurality of flows equally among said plurality of processor cores, to perform a first iteration of each processor core through comparing assigned flows to select a flow with a highest priority as output and to perform a second iteration of comparing said output from each processor core to select a flow with a highest priority as output. 
     Turning now to  FIG. 6 , an exemplary embodiment  600  of generating flow exact patterns  602  is depicted, including a series of flows  604 ,  606 ,  608 ,  610 ,  612 ,  614  and an associated series of flow exact pattern  602  hash tables  616 ,  618 ,  620 ,  622  based on the flows  604 ,  606 ,  608 ,  610 ,  612 ,  614 . In the exemplary embodiment, the flow exact pattern  602  is a pattern for grouping flows  604 ,  606 ,  608 ,  610 ,  612 ,  614  with similar exact value fields  624  in the flow table. This fact of the exemplary embodiment converts a wild card search operation into an exact match operation. Hence, in the exemplary embodiment, the number of flow exact patterns  602  is equal or less than the number of flows. Further in the exemplary embodiment, each flow exact pattern has its own hash table  616 ,  618 ,  620 ,  622  for storing the flows within the pattern. 
     Continuing with the exemplary embodiment, the number of flow exact patterns depends on the flows in the flow table but the maximum is bounded based on the maximum number of fields. For example, the maximum number of flow exact patterns for a twelve field header is the number of possible twelve-field combinations plus one, with the plus one field being a special pattern wherein every field is a wildcard field for use as a default matching pattern. Accordingly, the number for this exemplary embodiment can be calculated as follows: 
     
       
         
           
             
               
                 ( 
                 
                   
                     
                       12 
                     
                   
                   
                     
                       12 
                     
                   
                 
                 ) 
               
               + 
               
                 ( 
                 
                   
                     
                       12 
                     
                   
                   
                     
                       11 
                     
                   
                 
                 ) 
               
               + 
               
                 ( 
                 
                   
                     
                       12 
                     
                   
                   
                     
                       10 
                     
                   
                 
                 ) 
               
               + 
               … 
               + 
               
                 ( 
                 
                   
                     
                       12 
                     
                   
                   
                     
                       3 
                     
                   
                 
                 ) 
               
               + 
               
                 ( 
                 
                   
                     
                       12 
                     
                   
                   
                     
                       2 
                     
                   
                 
                 ) 
               
               + 
               
                 ( 
                 
                   
                     
                       12 
                     
                   
                   
                     
                       1 
                     
                   
                 
                 ) 
               
               + 
               1 
             
             = 
             4096 
           
         
       
     
     Turning now to  FIG. 7 , an exemplary embodiment of a parallel flow selection  700  is depicted, including a series of computational steps  702 ,  704 ,  706 ,  708  and a series of priority comparisons  710 ,  712 ,  714 ,  716 ,  718 ,  720 ,  722 . Parallel flow selection in the exemplary embodiment is a search for the flow with the highest priority, accomplished by dividing the work among SIMD cores. The exemplary embodiment search iterates through several rounds  702 ,  704 ,  706 ,  708  until the flow with maximum priority  708  is found. In the exemplary embodiment, set p equal to the number of SIMD cores active in each round and set n equal to the number of flows to search. The first round starts with p=n/2. In each round, both n and p are reduced by half. Xi is the flow index in the flow table at location i of the input array. The arrows  710 ,  712 ,  714 ,  716 ,  718 ,  720 ,  722  represent the priority comparison between Xi and Xj. Mij indicates the flow index with maximum priority from location i to j. The search proceeds until n equals 2 and p equals 1. After this, one comparison by the last core gives the final answer. As depicted in the exemplary embodiment, the search implies O(log 2 n) computation times where n is the number of flows to search. 
     Turning now to  FIG. 8 , an exemplary method embodiment  800  based on enhancing a table lookup for a parallel computing environment is depicted. Starting at exemplary method embodiment step  802 , a plurality of flow exact patterns is generated, based on an associated flow table, for grouping flows based on similar exact value fields. It should be noted in the exemplary embodiment that the number of flow exact patterns is less than or equal to the number of flows. Further in the exemplary embodiment, it should be noted that each flow exact pattern has its own hash table for storing the flows associated with the flow exact pattern. Next, the exemplary embodiment groups flows by comparing a plurality of flows and groups the indexes of all flows wherein all fields of said flows with the same exact value are matched. The exemplary embodiment then generates a table for each group of indexes and stores a predetermined flow priority with each flow index. 
     Continuing at step  804  of the exemplary embodiment, the plurality of flow exact pattern hash tables, created by step  802  of the exemplary embodiment, is provided as input to parallel flow selection of step  804 . The exemplary embodiment utilizes a parallel flow selection, based on said plurality of flow exact patterns, for selecting the highest priority flow from said plurality of flow exact patterns by iterating through the plurality of hash tables on parallel processors/cores comparing predefined flow priorities to determine the flow with the highest priority as the output of the lookup. In another aspect, the exemplary embodiment selects a highest priority flow from a plurality of flows by distributing the plurality of flows equally among a plurality of processors and/or processor cores, performing a first iteration of each processor and/or processor core through the assigned flows to determine the flow with the highest priority and then performing a second iteration of comparing the processor and/or processor core output of highest priority to another processor and/or processor core output of highest priority to select the highest priority flow. 
       FIG. 9  illustrates an example of a suitable computing system environment  900  in which the claimed subject matter can be implemented, although as made clear above, the computing system environment  900  is only one example of a suitable computing environment for an exemplary embodiment and is not intended to suggest any limitation as to the scope of use or functionality of the claimed subject matter. Further, the computing environment  900  is not intended to suggest any dependency or requirement relating to the claimed subject matter and any one or combination of components illustrated in the example computing environment  900 . 
     Looking now to  FIG. 9 , an example of a device for implementing the previously described innovation includes a general purpose computing device in the form of a computer  910 . Components of computer  910  can include, but are not limited to, a processing unit  920 , a system memory  930 , and a system bus  990  that couples various system components including the system memory to the processing unit  920 . The system bus  990  can be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. 
     Computer  910  can include a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer  910 . By way of example, and not limitation, computer readable media can comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile as well as removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CDROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computer  910 . Communication media can embody computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and can include any suitable information delivery media. 
     The system memory  930  can include computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) and/or random access memory (RAM). A basic input/output system (BIOS), containing the basic routines that help to transfer information between elements within computer  910 , such as during start-up, can be stored in memory  930 . Memory  930  can also contain data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit  920 . By way of non-limiting example, memory  930  can also include an operating system, application programs, other program modules, and program data. 
     The computer  910  can also include other removable/non-removable and volatile/nonvolatile computer storage media. For example, computer  910  can include a hard disk drive that reads from or writes to non-removable, nonvolatile magnetic media, a magnetic disk drive that reads from or writes to a removable, nonvolatile magnetic disk, and/or an optical disk drive that reads from or writes to a removable, nonvolatile optical disk, such as a CD-ROM or other optical media. Other removable/non-removable, volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM and the like. A hard disk drive can be connected to the system bus  990  through a non-removable memory interface such as an interface, and a magnetic disk drive or optical disk drive can be connected to the system bus  990  by a removable memory interface, such as an interface. 
     A user can enter commands and information into the computer  910  through input devices such as a keyboard or a pointing device such as a mouse, trackball, touch pad, and/or other pointing device. Other input devices can include a microphone, joystick, game pad, satellite dish, scanner, or similar devices. These and/or other input devices can be connected to the processing unit  920  through user input  940  and associated interface(s) that are coupled to the system bus  990 , but can be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB). 
     A graphics subsystem can also be connected to the system bus  990 . In addition, a monitor or other type of display device can be connected to the system bus  990  through an interface, such as output interface  950 , which can in turn communicate with video memory. In addition to a monitor, computers can also include other peripheral output devices, such as speakers and/or printing devices, which can also be connected through output interface  950 . 
     The processing unit  920  can comprise a plurality of processing cores providing greater computational power and parallel computing capabilities. Further, the computing environment  900  can contain a plurality of processing units providing greater computational power and parallel computing capabilities. It should be noted that the computing environment  900  can also be a combination of multi-processor and multi-core processor capabilities. 
     The computer  910  can operate in a networked or distributed environment using logical connections to one or more other remote computers, such as remote server  970 , which can in turn have media capabilities different from device  910 . The remote server  970  can be a personal computer, a server, a router, a network PC, a peer device or other common network node, and/or any other remote media consumption or transmission device, and can include any or all of the elements described above relative to the computer  910 . The logical connections depicted in  FIG. 9  include a network  980 , such as a local area network (LAN) or a wide area network (WAN), but can also include other networks/buses. 
     When used in a LAN networking environment, the computer  910  is connected to the LAN  980  through a network interface  960  or adapter. When used in a WAN networking environment, the computer  910  can include a communications component, such as a modem, or other means for establishing communications over a WAN, such as the Internet. A communications component, such as a modem, which can be internal or external, can be connected to the system bus  990  through the user input interface at input  940  and/or other appropriate mechanism. 
     In a networked environment, program modules depicted relative to the computer  910 , or portions thereof, can be stored in a remote memory storage device. It should be noted that the network connections shown and described are exemplary and other means of establishing a communications link between the computers can be used. 
     Additionally, it should be noted that as used in this application, terms such as “component,” “display,” “interface,” and other similar terms are intended to refer to a computing device, either hardware, a combination of hardware and software, software, or software in execution as applied to a computing device implementing a virtual keyboard. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program and a computing device. As an example, both an application running on a computing device and the computing device can be components. One or more components can reside within a process and/or thread of execution and a component can be localized on one computing device and/or distributed between two or more computing devices, and/or communicatively connected modules. Further, it should be noted that as used in this application, terms such as “system user,” “user,” and similar terms are intended to refer to the person operating the computing device referenced above. 
     Further, the term to “infer” or “inference” refer generally to the process of reasoning about or inferring states of the system, environment, user, and/or intent from a set of observations captured from events and/or data. Captured events and data can include user data, device data, environment data, behavior data, application data, implicit and explicit data, etc. Inference can be employed to identify a specific context or action, or can generate a probability distribution over states, for example. The inference can be probabilistic in that the computation of a probability distribution over states of interest based on a consideration of data and events. Inference can also refer to techniques employed for composing higher-level events from a set of events and/or data. Such inference results in the construction of new events or actions from a set of observed events and/or stored event data, whether or not the events are correlated in close temporal proximity, and whether the events and data come from one or several event and data sources. 
     The above-described exemplary embodiments are intended to be illustrative in all respects, rather than restrictive, of the present innovation. Thus the present innovation is capable of many variations in detailed implementation that can be derived from the description contained herein by a person skilled in the art. All such variations and modifications are considered to be within the scope and spirit of the present innovation as defined by the following claims. No element, act, or instruction used in the description of the present application should be construed as critical or essential to the invention unless explicitly described as such. Also, as used herein, the article “a” is intended to include one or more items.