Abstract:
A method and apparatus for of high-speed and memory efficient rule matching, the rule matching being performed on an m-dimensional universe with each dimension bound by a given range of coordinate values, and a set of rules that apply to an undetermined number of coordinates in that universe. More specifically, a high-speed computer based packet classification system, uses an innovative set intersection memory configuration to provide efficient matching of packets flowing through a network system to a specific process flow based on a packet tuple. The system also provides classification of packets as they flow through a network system. More particularly, this system correlates these flowing packets with previously received packets, along with identifying the packets so that they are handled efficiently. The ability to correlate packets to their corresponding process flows permits the implementation of service aware networks (SAN) that are capable of handling network situations at the application level.

Description:
BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     The present invention relates generally to rule matching in an m-dimensional universe with each dimension bound by a lower and upper limit value. In one example, this invention relates to the classification of packets, based on the tuple information, in high-speed digital communication networks, where the implementation of the system does not require dedicated hardware other than the computer system. 
     2. Description of the Related Art 
     There are many ways of implementing search engines that perform searches based on various types of search criteria. Consider, for example, a dating search engine utilizing several parameters for the actual search such as gender, age, height, weight, and income level. This type of matching system may develop various ways of matching persons and prioritizing the actual findings based on a variety of rules. In some instances, it may be beneficial to identify which rule applies to a particular coordinate in the various parameters. 
     One of the traditional approaches for this type of search includes a step by step check of each and every rule to determine if they match any or all of the coordinates possible in the system. Although these types of systems are possible, they are inefficient because they require a significant amount of computational power (e.g., CPU time, memory requirements, etc.) to complete within a reasonable amount of time. As the number of parameters and rules increase, so does the complexity of the search, resulting in a need for even more computational power. 
     Packets of data flow through a network of computers carrying portions of digital information between the different nodes. Broadly, the results of an application running at one node may be sent to a computer at another network node. To establish the transfer of data, the information is packetized and sent over their respective networks. A complete packet communication may be defined as the sending of a packet upstream, from a source computer system, where it proceeds along a communication path, and then downstream to a destination computer. Efficient network management and system administration of computer systems utilizing upstream/downstream packet communications typically require some type of packet content analysis to maintain this efficiency. 
     A typical packet utilized for computer network communications includes a packet header. A packet header, which is also referred to as a tuple, typically contains several sections comprising a total of 104 bits. A typical 104 bit packet header contains 32 bits for the Internet protocol (“IP”) source, 32 bits for the IP destination, 16 bits for the port source, 16 bits for the port destination, and the last 8 bits to identify the protocol type. Using the above-described configuration, the tuple typically contains information that can be used to identify the source and destination of the packet. In a high-speed network, millions of packets are sent every second. Thus, it is typically necessary to process these packets at wire speed in order to analyze them effectively and efficiently. It is also desirable for the processed packets to arrive at the appropriate destinations “unharmed.” Furthermore, it is desirable to provide these services to low-cost, general computing systems which are typically limited in their ability to efficiently communicate, receive and process packet header information. 
     A common problem that occurs during processing of an address space, such as the 104 bit tuple, is the inability to effectively process such a large memory address. To accomplish this, traditional systems commonly utilize a variety of hash tables or other techniques. However, these traditional systems typically lack the capability of operating at wire speed while addressing over one million different process flows. 
     Some of the traditional systems require numerous steps which grow in number, either linearly or exponentially, based on the number of process flows identified. Other systems require complex resources in order to effectively process the data. Commonly, these systems require a search mechanism that is time consuming and is therefore impractical for wire speed applications. 
     For example, U.S. Pat. No. 5,414,704 (Spinney) describes a method of searching with an N-bit input address hashed into N-bits. Spinney also describes the use of the lower 16-bits of the hashed address to supply pointers to a maximum of seven buckets. However, Spinney&#39;s described solution is not suited for network applications, and also does not support processing at wire-speed. The deficiencies of the Spinney system results from that system&#39;s utilization of a binary look-up tree, in conjunction with a content addressable memory (CAM) that is used in parallel to a hash function. The Spinney patent is incorporated herein by reference in its entirety for all purposes. 
     Descriptions of other types of searching methods may be found in U.S. Pat. No. 5,463,777 (Bialokowski et al.) and U.S. Pat. No. 5,574,910 (Bialokowski et al.). These references describe the use of a binary search tree that relies on a software implementation of an associative memory to match packet headers. While both of the Bialokowski et al. patents describe methods of searching nodes, they require extensive computational resources. Both of the Bialokowski et al. patents are incorporated herein by reference in their entirety for all purposes. 
     In U.S. Pat. No. 5,745,488 (Thompson et al.) another approach to packet processing is described. Thompson et al. describes a system where a packet tuple is checked and compared against a table of packet types. In this system, the table is implemented using a CAM. The packet tuple is classified so that further processing may occur, while another packet, having a different type, is processed on other system resources. The Thompson et al. patent is incorporated herein by reference in its entirety for all purposes. 
     Another method is discussed in U.S. Pat. No. 5,815,500 (Murono). Murono describes a system having a plurality of CAMs for the detection of certain packet header information, wherein each CAM is preloaded with the appropriate information. This approach is used in an attempt to expedite packet header processing and therefore increase the speed that the packet is processed through the system. However, the Murono approach is limited based upon this system&#39;s reliance upon the utilization of CAMs. The Murono patent is incorporated herein by reference in its entirety for all purposes. 
     Additional methods and techniques for increasing the speed of look-up tables are described in U.S. Pat. No. 6,032,190 (Bremer et al.), U.S. Pat. No. 6,052,683 (Irwin) U.S. Pat. No. 6,111,874 (Kerstein), and in U.S. Pat. No. 6,161,144 (Michels et al.). Some of the disadvantages of these systems and methods relate to their inability to ensue a predictable and limited time period for packet classification. In those systems, packet classification time typically varies from packet to packet, and in most cases is unpredictable, the utilization of these types of methods do not work well in a time sensitive system (e.g., a computer network). Moreover, these traditional systems&#39; extensive use of CAMs further complicates the overall design, resulting in excessive implementation costs. The Bremer et al., Irwin, Kerstein, and Michels et al. patents are incorporated herein by reference in their entirety for all purposes. 
     SUMMARY OF THE INVENTION 
     In view of the foregoing, one aspect of the present invention provides a method for rule checking a two dimensional rule table to identify whether one or more rules of a given rule-set apply to a specified data value. 
     In accordance with one aspect of the present invention, at least one rule vector is loaded into the available space of the rule table. Once the rule table has been loaded, the content of the rule table is compared to the data vector to determine whether one or more rules apply to the data vector. 
     In accordance with another aspect of the present invention, the number of rows in the rule table is determined from the maximum number of parameters of a rule vector. Also, the number of segments in each row is determined according to the maximum value possible for the parameters, and the number of bits in each segment is determined according to the maximum number of rules to be used in the rule table. 
     In another aspect of the present invention, the rule table may be constructed as a two dimensional memory array where the size of the array is defined by a user. 
     In still yet another aspect of the present invention, a computer&#39;s cache size is used to determine the size parameter of a rule table value segment. 
     In another aspect of the present invention, one of the rule table value segments utilize a “don&#39;t care” value. 
     In another aspect of the present invention, rule checking identifies a packet tuple based on its correspondence to any of the rules in the rule table. 
     In accordance with another aspect of the present invention, rule checking provides packet tuple processing in a predetermined time frame. 
     In another aspect of the present invention, rule checking provides packet tuple processing to be performed even though at least some of the parameter data is missing. 
     In accordance with another aspect of the present invention, rule checking is implemented as a resource conserving application so the system memory can be optimized. 
     These and other aspects, features and advantages of the present invention will become more apparent upon consideration of the following description of the preferred embodiments of the present invention taken in conjunction with the accompanying drawings. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a diagram illustrating an exemplary rule table having (I) parameters, (J) values and (R) rules; 
         FIG. 2  is a flowchart illustrating a exemplary method of loading a rule table; 
         FIG. 3  is a diagram illustrating a partially populated rule table after being loaded with a value vector for a first rule; 
         FIG. 4  is a diagram illustrating a rule table after being loaded with a value vector for a second rule; 
         FIG. 5  is a diagram illustrating a rule table after being loaded with a value vector for a third rule; 
         FIG. 6  is a flowchart illustrating an exemplary method checking a loaded rule table against a data vector (DV); 
         FIG. 7  is a diagram illustrating an enhanced rule table (ERT) having (I) parameters, (J) values, (R) rules, and configured to accept “don&#39;t care” cases; 
         FIG. 8  is a diagram illustrating bit locations of a typical packet tuple; 
         FIG. 9  is a diagram illustrating an enhanced rule table after being loaded with a value vector for a first rule; 
         FIG. 10  is a diagram illustrating an enhanced rule table after being loaded with a value vector for a second rule; 
         FIG. 11  is a flowchart illustrating an exemplary method checking a loaded enhanced rule table against a data vector (DV); 
         FIG. 12  is a flowchart illustrating an exemplary method for loading a rule vector having a range values into a rule table; 
         FIG. 13  is a diagram illustrating a rule table after being loaded with a range of values of a first parameter; 
         FIG. 14  is a diagram illustrating a rule table after being loaded with a range of values of all of the range parameters; 
         FIG. 15  is a diagram illustrating an exemplary modified extended rule table (MERT) for a network tuple; and 
         FIG. 16  is a flowchart illustrating an exemplary method for checking a loaded modified extended rule table (MERT) for a data vector (DV). 
     
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     In the following description of several embodiments, reference is made to the accompanying drawings, which form a part hereof It is to be understood by those of working skill in this technological field that other embodiments may be utilized, and structural and procedural changes may be made without departing from the scope of the present invention. 
     One embodiment of the present invention utilizes a computer system to identify the applicability of one or more rules of a given rule-set to a specific case. An appropriate computer system would include standard computer components, such as a central processing unit (CPU), memory, and the necessary interfaces to permit system input/output. A portion of the computer system&#39;s memory may be allocated for the creation of a rule table. A rule table may be constructed as a two dimensional memory array where the size of the array may be modified to accommodate any computer memory restrictions or limitations. The memory array size also may be defined or modified by a user. 
       FIG. 1  shows a two dimensional rule table (RT)  100 , comprising a predefined number of rows  110 . Each row  110  is divided into value segments  120 , each representing one possible value for a component of a rule vector (RV). Each value segment  120  is divided into a field of bits. The bits  130  located at the same location in each of the value segments  120  are used to define a particular rule. In a system having a maximum of “T” rows, “J” value segments, and “R” rules will result in a memory requirements of I*J*R bits for the rule table, or I*J*R/8 bytes, as each byte contains 8 bits. The array “A(I, J, R)” will be the format used to illustrate how a particular bit in the RT  100  may be addressed. 
     The present invention may be configured to accommodate a rule table having a number of value segments based on certain system parameters. One method to determine the number of value segments is to correlate the number of value segments with the cache size of the current system. That is, the number of different types of rules (i.e., length of a value segment  120 ) can be determined based on the length of one line of a cache in a computer system. Utilizing a computer system&#39;s cache size as the value segment  120  size parameter enhances the overall performance of present invention since unnecessary access to system memory is prevented. 
     The rule table  100  may be loaded with one or more sets of rule vectors (RVs). A format of an exemplary rule vector that may be used in the present invention is as follows:
 
rule-vector=&lt; P   0   &gt;.&lt;P   1   &gt;.&lt;P   2   &gt; . . . &lt;P   n &gt;
 
     A rule vector utilized in the present invention may have one or more rule parameters (e.g., P 0 , P 1 , P 2 , etc.), which are used to describe the specific rule. Typically, the number of possible rule parameters are defined prior to rule table loading, during initialization. 
     Load Rules into a Rule Table (RT) 
       FIG. 2  shows an exemplary method of loading a rule table with rule vectors, and this method will be discussed with reference to the rule table (RT)  100  shown in  FIG. 1 . In  FIG. 2 , at operation  200 , rules are loaded into the RT  100  by first initializing several parameters. Specifically, the number of rows “T” in the RT  100  are set to the maximum number of value vectors. The number of value segments  120  in each row are set to the maximum number of possible values (J) that are possible (J=max. values). The size of each value segment  120  (i.e., number of bits) is set to the maximum number of rules (R) that are utilized in the current system. The setting of all the bits in the RT  100  to a logical value “0” is also performed in this operation (A(I, J, R)=0). 
     In operation  210 , the system waits for the availability of a new rule vector. If no rule vector is available, then control stays at this operation. However, once a rule vector is made available, control will flow to operation  220  where the system checks the RT  100 &#39;s space availability (i.e., does the rule table have room for an additional row). If no space is available, then control remains at this operation while the system continues to check for space availability. However, once space availability is detected, control flows to operation  230 . In another embodiment of the invention, a notification of the inability of space in RT  100  is generated. In yet another embodiment of the invention, an error exception is generated and a process to increase the size of the RT  100  takes place by adding rule bits  130  to each value segment  120  of the RT  100 . 
     In operation  230 , the system sets the variable “r” to point to the first available rule number in the RT  100 . If the RT  100  does not contain any rules (i.e., an empty rule table), “r” would point to “0”. The value of “r” will therefore increase by one when a new rule is loaded into RT  100 , and will be decrease by one or more to reflect the emptying of one or more rules from the system. 
     Next, in operation  240  the value vector counter “i” is reset to “0”. This counter is used as a counting variable so that an inner loop may be established. The inner loop includes operations  250 – 280 , which enables the system to proceed through each row of the RT  100 . Once the value vector counter “i” counter is reset, control flows to operation  250  where the variable “v” is set to the value of the i th  parameter of the RV. At this point, variables “i”, “v” and “r” have all been set to their appropriate values. 
     Next, in operation  260 , the system sets an identified bit in the RT  100 , such that A(i,v,r)=1. In other words, the specified bit in a rule table “A” which corresponds to the i th  row, at the j th  value segment, and the respective r th  rule (i.e. the r th  bit  130  in the j th  value segment  120 ), is set to logical “1.” 
     In operation  270 , the vector value counter “i” is increased by one and then checked to determine if “i” has reached the maximum value “I” (operation  280 ). Once again, “I” represents the maximum number of value vectors. Thus, when “i” reaches “I”, all of the parameters of the RV will have been processed. As long as “i” is smaller than “I”, the sequence of operations  250  through  280  continue. However, once the value of “I” is reached, the system will exit out of the inner loop and continue execution at operation  210 , waiting for a new RV to become available. 
     Rule Table Loading with a First Rule Vector Rule 
       FIGS. 3–5  show a specific, non-limiting, example of a rule table (RT) after being loaded with value vectors using the method illustrated in  FIG. 2 . More particularly, these figures show examples of a loaded rule table RT  100  having a plurality of value segments  120 , rows  110 , and rule bits  130 . In these figures a total of six value segments  120  are shown, and are labeled as segment  0  through  5 . The RT  100  also has nine rows  110 , labeled  0  through  8 . Each individual value segment  120  is divided into four rule bits  130 , which are labeled  0  through  3 . Thus, each value segment  120  in the illustrated RT  100  has four rule cells ( 0 – 3 ). Each of these rule cells has a bit-wise property such that each bit (i.e., each rule cell) is capable of having a logical value of “0” or “1”. For clarity, the RT  100  rule cells having a logical value of “0” will be denoted by a blank cell. It should also be noted that the substance of a particular rule is not essential to the understanding of the present invention. 
     To illustrate one aspect of the present invention that provides a rule table loading method, the following exemplary RVs will be used. Specifically, the loading of rule vector values into a RT  100  will be demonstrated using the following exemplary rules, RV 0 , RV 1 , and RV 2 :
 
RV 0 =0.3.5.5.4.3.2.1.1
 
RV 1 =1.1.1.5.4.3.1.1.5
 
RV 2 =0.2.5.4.5.1.2.4.3
 
     First of all, it is to be understood that a rule vector (RV) structure has several components. Using RV 0  as an example, a rule vector contains nine parameter values (0.3.5.5.4.3.2.1.1), wherein each of these parameters relate to one of the rows  110  in the RT  100 . For example, in the RV 0 , the value of the first parameter “0” corresponds to the first row “ 0 ”, the value of the second parameter “3” corresponds to the second row “ 1 ”, while the value of the ninth parameter “1” of the RV 0  corresponds to the ninth (last) row “ 8 ” in the rule table. The actual value of each of these nine parameters (“0”, “3”, etc.) identifies the value segment  120 . Since six value segments  120  exist in the RT  100 , each parameter may contain a value between 0 and 5. For example, the first parameter value “0” in the RV 0  indicates that the value segment “0” is to be used to set the rule bit, while the second parameter value “3” indicates that the value segment “3” is to be used. 
     Lastly, the subscript of the rule vector, which is “0” in the RV 0  example, relates to a location of the rule cell (or rule bit)  130  within a particular value segment  120 . Again, each segment  120  parameter is divided into separate rule cells, labeled  0 – 3 . Thus, bit setting for RV 0  will take place in the rule cell labeled “0”, while RV 1  and RV 2 will use rule cells “ 1 ” and “ 2 ”, respectively. With this understanding, rule table loading of the rule vectors RV 0 , RV 1 , and RV 2  will now be described. In a first example, the method illustrated in  FIG. 2  is used to load the rule values denoted by RV 0  into a rule table, which results in the rule table shown in  FIG. 3 . 
     Referring now to  FIG. 2 , at operation  200 , rule vector loading is initiated by first initializing several parameters “I”, “J”, “R”, along with setting all the bits in RT  100  to a logical “0” (A(I, J, R)=0)). In the present example, “I” is set to 9, “J” is set to 6, and “R” is set to 4. 
     Next, in operation  210 , the rule vector (RV 0 ) is made available to the system. Since the RT  100  still has space available for a new rule (operation  220 ), control flows to operation  230  where the rule incrementing variable “r” is set to “0” (i.e., “r” is set to the first available rule number). 
     Next, in operation  240 , the value vector counter “i” (corresponding to the row of the RT  100 ) is reset to “0.” Control then flows to operation  250 , which is the first operation in the inner loop controlled by the vector counter “i.” In operation  250 , the variable “v” (corresponding to the value segment  120 ) is set to the i th  parameter (i.e., v=P 0 =0) of the RV 0 . At this point, “i” is set to “0”, “v” is set to “0”, and “r” is set to “0.” 
     In operation  260 , the identified bit location in the RT  100 , denoted by A(i,v,r), is set to a logical “1.” In the current example, A(0,0,0) is set to a logical “1.” Put another way, the first parameter of RV 0 , which is P 0 =0, results in setting a bit to “1” in the first row  110  (row “ 0 ”), in the first segment  120  (segment “0”) of the RT  100 . Also, the first bit (i.e., bit  0 ) of the four bit rule field is used since this is the first rule (i.e., the subscript of the RV 0  is “0”). 
     In operation  270 , the vector value counter “i” is incremented by one and then checked to determine if any additional vectors remain in the RV 0  (operation  280 ). In the current example, eight additional parameters P i  remain in RV 0 , so control passes back to operation  250  so that the next parameter P 1  (“3”) may be loaded into the RT  100 . 
     Returning to operation  250 , the second parameter of RV 0 , which is P 1 =3, is processed by executing the operations  250  through  280 . The completion of these operations results in the setting of a bit to a logical “1” in the second row  110  (row  1 ), in the fourth segment  120  (segment “3”) of the RT  100 . The fourth segment  120  is used since the value of P 1  is “3,” and the second row  110  is used since this is the second parameter in the RV 0 . Once again, the first bit (i.e., the “0” bit location) within the fourth segment  120 ) is used since this is the first rule (i.e., the subscript of the RV 0  is “0”). 
     This process of setting the appropriate rule bits  130  in the RT  100  is continued by cycling through operations  250  through  280  for each of the parameters in the RV 0 . Once completed, the RT  100  will be loaded with the RV 0  parameters.  FIG. 3  shows an example of a rule table loaded with the RV 0  rule vector. 
     Control is then transferred back to operation  210 , where the system determines whether a new RV is available. In the current example, the next rule vector (RV 1 ) is available, and since space is available in the RT  100  (operation  220 ), the rule incrementing variable “r” is then set to “1”. Similarly to the method used to load RV 0 , the RT  100  is loaded with the value vectors contained in RV 1  (i.e., “1.1.1.5.4.3.1.1.5”) by cycling through operations  250  through  280 . Upon exiting conditional operation  280 , the RT  100  will be loaded with rule parameters RV 0  and RV 1 .  FIG. 4  shows an example of a rule table loaded with the RV 0  and RV 1  rule vectors. 
     Once again, control is transferred back to operation  210  where the system again determines whether a new RV is available. In the present example, the next rule vector (RV 2 ) is made available to the system. Since the RT  100  still has space available for a new rule (operation  220 ), control flows to operation  230  where the rule incrementing variable “r” is set to “2” (i.e., “r” is set to the first available rule number). Similarly to the methods used to load the RV 0  and RV 1  vector values, the RT  100  is loaded with the RV 2  value vectors (i.e., 0.2.5.4.5.1.2.4.3). This is performed by cycling through operations  240  through  280 .  FIG. 5  shows an example of a rule table loaded with the RV 0 , RV 1 , and RV 2  rule vectors. 
     Control is then transferred to conditional operation  210  where the system waits for a new RV. However, in our current example, no new RV is available. Thus, the system waits at this operation until a new RV becomes available. Although a rule table having only three rules has been described, it should be understood that the RT  100  may be modified to include dozens or even hundreds of rules by utilizing the just-described methods 
     Loaded Rule Table Checked against a Data Vector (DV) 
     Once the RT  100  has been loaded with one or more rule vectors (e.g., RV 0 , RV 1 , RV 2 , etc.), the rule table may be checked to determine whether a received data vector (DV) has a corresponding rule vector (RV). It should also be noted that the DV and the RV will typically contain an identical number of parameters. That is, the RT  100  may be checked to determine whether a rule vector exists for a particular DV.  FIG. 6  illustrates one method for conducting this type of rule checking. 
     In  FIG. 6 , at the first operation  610 , the system waits for a DV to be received so that further processing may occur. Once a DV has been received, an inner loop counter variable “i” is reset to “0,” and a counter variable “c” is set to “−1.” (Operation  620 ). The counter variable “i” permits the system to cycle through each row of the rule table. The “−1” notation is commonly used to indicate that the variable “c” is set to a series of logical 1&#39;s over the entire bit-field range of this variable (e.g., c=“1111”). 
     Control then flows to operation  630 , which is the first operation controlled by the inner loop variable “i.” In this operation, a variable “v” is set equal to the value associated with the i th  parameter of the DV (i.e., v=DV(P i )). 
     In the next operation  640 , a bit-wise logical AND is performed between the content of the variable “c” and the content of the v th  segment  120  of the i th  row  110  (c AND A(i,v)). For example, if the initial value of variable “c” is “1111”, and the value of A(i, v) is “0100”, then the result of a bit-wise AND operation of these two elements would be “0100”. The result of the logical AND operation is then placed into the variable “c” (c=c AND A(i,v)). Thus, in this example, “c” is set equal to “0100.” 
     In operation  650 , the row counter “i” in incremented by one (i=i+1), which leads to operation  660  where the variable “i” and the constant “I” are compared. This comparison determines whether processing has occurred for each of the rows  110  in the RT  100 . While “i” is smaller than the maximum number of rows  110  in the RT  100  (i&lt;I), the inner loop is continued and control is passed to operation  630 . However, once the value of “i” is equal to “I” (i.e., each row has been processed), control is passed to operation  670 . 
     In operation  670 , the value of “c” is returned to the calling system, and control is passed back to operation  610  where the system waits for the next DV. 
     A specific, non-limiting example of checking a data vector (DV) against a loaded rule table will now be described. This description will be made with reference to the RT  100  shown in  FIG. 5 , which has been loaded with rule vectors RV 0 , RV 1 , and RV 2  in accordance with the method shown in  FIG. 2 . In this example, the following exemplary received value vector DV 0  will be used:
 
DV 0 =1.1.1.5.4.3.1.1.5
 
     Referring now to the flowchart in  FIG. 6 , an exemplary method of checking a DV against the loaded RT  100  will now be described. 
     In operation  610 , the system waits to receive a new DV. If a new DV has not been received, then control remains at this operation. However, once a DV is received, control will flow to operation  620 . 
     In operation  620 , the inner loop counter “i” is set to “0”, while variable “c” is set to “−1” (i.e., c=“1111”). Next, during a first iteration of an inner loop, the value of DV 0 (P 0 ) is determined and placed in variable “v” (operation  630 ). In the current example, the execution of this operation results in “v” having the value “1.” Therefore, the value denoted by A(i,v) is the value located in the RT  100  at A(0,1), which is “0100.” That is, as shown in  FIG. 5 , the value located at the second segment  120  (v=1) of the first row  110  (i=0) is “0100.” 
     Next, in operation  640 , the logical operation “1111” AND “0100” is performed, which results in “c” having the value “0100”. The row counter “i” is then incremented by one (operation  650 ), and then compared with the constant “I” to determined if any additional rows  110  are present (operation  660 ). In the present example, additional rows exist, so control is passed back to operation  630 . 
     In operation  630 , the variable “v” is set to the value of the second parameter of DV 0  is obtained (v=value of DV 0 P 1 )). Since v=DV 0 (P 1 ) is “1”, the content of the segment A(i,v)=(A(1,1))=“0100.” In the next operation  640 , the logical operation c AND A(1,1) (i.e., “0100” AND “0100”) is performed, which results in “c” having a value of “0100.” 
     The operations  630  through  660  are then performed for each of remaining rows of the rule table (i.e., these operations are performed for each parameter of the data vector). While cycling through each parameter of the data vector, the counter variable “i” will have been incremented to “7.” At this point, DV 0 (P 7 ) is a “1” (i.e., the seventh value in the string “1.1.1.5.4.3.1.1.5”), which correlates to the corresponding value segment A(7,1)=“1100.” When “1100” is ANDed with the content of “c”, which is “0100” (operation  640 ), the result will be placed in “c.” In the current example, this would result in setting “c” to “0100.” 
     Once again, operations  630  through  660  will be performed for each of remaining rows of the data vector. Thus, in the present example, two additional rows will be processed. Once these final two rows have been processed, the final value for “c” is “0100”, which indicates that DV 0  corresponds to the second rule defined in the RT  100 . In particular, the DV 0  corresponds to the second rule because the second bit position of the variable “c” equals a “1.” 
     To further illustrate the capabilities of the present invention, rule checking the RT  100  with another received data vector (DV 1 ) will now be discussed. In this example, the DV 1  will have the value:
 
DV 1 =1.0.1.5.4.3.1.1.5
 
     It should be noted that, in this example, only the second parameter DV 1 (P 1 ) is different from that of DV 0  (0 versus 1 respectively). Referring again to  FIG. 6 , operation  610 , the system waits to receive a new DV. In the current example, a new DV has been received (DV 1 ), so control will flow to operation  620 . 
     Once again, in operation  620 , the inner loop counter “i” is set to “0”, while variable “c” is set to “−1” (i.e., c=“1111”). Next, during a first iteration of an inner loop, the value of value of DV 1 (P 0 ) is determined and placed in variable “v” (operation  630 ). In the current example, the execution of this operation results in “v” having the value “1.” Therefore, the value denoted by A(i,v) is the value located in the RT  100  at A(0,1), which is “0100.” That is, as shown in  FIG. 5 , the value located at the second segment  120  (v=1) of the first row  110  (i=0) is “0100.” 
     Next, in operation  640 , the logical operation “1111” AND “0100” is performed, which results in “c” having the value “0100”. The row counter “i” is then incremented by one (operation  650 ), and then compared with the constant “I” to determined if any additional rows  110  are present (operation  660 ). In the present example, additional rows exist, so control is passed back to operation  630 . 
     In operation  630 , the value of the second parameter of DV 1  is obtained (v=value of DV 1 (P 1 )). Thus, since v=DV 1 (P 1 )=“0”, the content of that segment is “0000” (A(1, 0)=“0000”). In the next operation  640 , the logical operation “0100” AND “0000” is performed, which results in “c” having a value of “0000.” 
     Once again, operations  630  through  660  will be performed for each of the remaining data vector (DV 1 ) parameters. Thus, in the present example, seven additional rows will be processed (i.e., 1.5.4.3.1.1.5). Once these parameters have been processed, the final value for “c” will be “0000”, which indicates that no applicable rules exist in the RT  100  for this particular data vector (DV). It should be understood, as illustrated in these examples, that the determination of whether or not a particular rule applies to a received DV is bound by the number of parameters of the RV. 
     Extended Rule Table Having “Don&#39;t Care” Segments 
     In another embodiment, the present invention may be configured to process situations where a parameter P i  is a “don&#39;t care.” For example, as far as the comparison between a rule vector and a data vector is concerned, this embodiment permits the use of a “*” rather than a specific value for a P i  of a rule vector. 
     Similarly to the other embodiments of the present invention, this embodiment also may be performed by a computer system having standard computer components, such as a central processing unit (CPU), memory, and the necessary interface to permit system input/output. A portion of the system memory may be allocated for the creation of a Extended Rule Table (ERT). The ERT may be constructed as a two dimensional memory array where the size of the array may be modified to accommodate any computer memory restrictions or limitations. The memory array size also may be defined or modified by a user. 
       FIG. 7  shows a two-dimensional RT  700 , comprising a predefined number of rows  710  to store components of the RVs. Each row  710  is divided into value segments  720 , each representing one possible value for a component of an RV. Each value segment  720  is further divided into a field of bits, each bit  730  representing a portion of one rule. In contrast to the RT  100 , the RT  700  contains an additional value segment  740 . This additional segment is labeled with a star “*” and is denoted as a star segment  740 , which is used to denote a “don&#39;t care” value for the specific parameter. In a system utilizing an ERT  700  having a maximum of “I” rows, “J” value segments and “R” rules will result in a memory requirements of I*(J+1)*R bits for the ERT, or I*(J+1)*R/8 bytes, since each byte contains 8 bits. 
     Loading Rules into an Extended Rule Table (ERT) 
     Loading an extended rule table may be performed by using the method shown in  FIG. 2 . However, when the value of a parameter Pi is a “*”, then the “star” segment of the corresponding row is set at the bit position  730  corresponding to the current rule number “r.” 
     In one embodiment, the extended rule table may be implemented in a service aware network (SAN) where the rules are defined with respect to tuples that may be flowing through the network. For example,  FIG. 8  shows an exemplary tuple  800  structure having five separate parameters. The parameters include the source IP address  805 , destination IP address  810 , protocol field  820 , source port  830 , and a destination port  840 . Although each of the fields  805  through  840  may be used as a parameter, it may be beneficial to divide the relatively large 32 bit and 16 bit fields into smaller fields of 8-bits each, for example. Although this approach will limit the values to a range of 0 through 255 and result in some increase in the number of parameters, it will also decrease the overall size of the RT, an example of which is provided below. 
     The specific number and size of the parameters may be modified based on system requirements, such as a CPU cache structure, memory utilization, and memory speed, for example. One implementation of the present invention may be used to replace the content addressable memory described in U.S. patent application Ser. No. 09/547,034, entitled “A METHOD AND APPARATUS FOR WIRE-SPEED APPLICATION LAYER CLASSIFICATION OF DATA PACKETS”, filed Apr. 11, 2000, and assigned to a common assignee, the entire disclosure of which is incorporated herein by reference. 
     Another implementation of the present invention may be used in conjunction with the system disclosed in U.S. patent application Ser. No. 09/541,598, entitled “AN APPARATUS FOR WIRE-SPEED CLASSIFICATION AND PRE-PROCESSING OF DATA PACKETS IN A FULL DUPLEX NETWORK”, filed Apr. 3, 2000, now U.S. Pat. No. 6,831,893, issued on Dec. 14, 2004, and in U.S. patent application Ser. No. 09/715,152, entitled “AN APPARATUS AND METHOD FOR BUNDLING ASSOCIATED NETWORK PROCESS FLOWS IN SERVICE AWARE NETWORKS”, filed Nov. 11, 2000, both of which are assigned to a common assignee, and are herein incorporated by reference. 
     Referring now to  FIG. 9 , an exemplary extended rule table (ERT)  700  is shown having a plurality of rows  710 , segments  720 , and rule bits  730 . In this configuration, the ERT  700  has five rows  710 , which correspond to the parameters P 0 , P 1 , P 2 , P 3 , P 4  in the tuple RV  800 . The five rows  710  are labeled  0  to  4 . The ERT  700 , in this example, includes a total of 256 segments and are labeled as segments  0  through  255 . In contrast to the rule table shown in  FIG. 1 , the ERT  700  includes a star value segment  740 , which may be utilized for the “don&#39;t care” values. Each individual segment  720  and  740 , in this particular example, is divided into three rules, which are labeled  0  to  2 . Thus, each segment  720  and  740  in the extended rule table has three rule bits  730  labeled  0  to  2 , and each of these rule bits  730  are capable of having a logical value of “0” or “1”. For simplicity, blank cells in the ERT  700  identify a logical value of “0”. 
     Loading “Don&#39;t Care” Rules into Extended Rule Table 
     A non-limiting illustration of one aspect of the present invention that provides a rule loading method that utilizes “don&#39;t cares,” the loading of rule values into an ERT  700  will be demonstrated using the following exemplary rules, RV 0 , and RV 1 :
 
RV 0 =0.*.2.3.4
 
RV 1 =1.254.*.255.*
 
     In one implementation, the method illustrated in  FIG. 2 , modified to accommodate “don&#39;t care” values, is used to load the rule values, denoted by RV 0 , which results in the rule table shown in  FIG. 9 . For clarity, since loading of rule values into a rule table has been previously described, some of the details of loading the RV 0  into the RT  700  have been omitted. 
     Referring now to  FIG. 2 , rule table loading is initiated by performing operations  200 – 220 . Next, in operation  230 , the value of variable “r” is set to “0” since this is the first available rule number. Next, in operation  240 , the value vector counter “i” is reset to “0.” Control then flows to operation  250 , which is the first operation in the inner loop controlled by the vector counter “i.” In operation  250 , the variable “v” is set to the i th  parameter (i.e., P 0 ) of the RV 0 . At this point “i” is set to “0”, “v” is set to “0”, and “r” is set to “0.” 
     In operation  260 , the identified bit location in the RT  700 , denoted by A(i,v,r), is set to a logical “1.” In the current example, A(0,0,0) is set to a logical “1.” Put another way, the first parameter of RV 0 , which is P 0 , results in setting a bit to “1” in the first row  110  (row  0 ), in the first segment  120  (segment “0” (i.e., P 0 =“0”)) of the RV 0 . Also, the first bit of the three bit rule field is used since this is the first rule (i.e., the subscript of the RV 0  is “0”). 
     In operation  270 , the vector value counter “i” is incremented by one and then checked to determine if any additional parameters P 1  remain in the RV 0  (operation  280 ). In the current example, four additional vectors remain in RV 0  (*.2.3.4), so control passes back to operation  250  so that the next parameter P 1  (“*”) may be loaded into the RT  700 . 
     Returning to operation  250 , the second parameter P 1  of RV 0  is processed by executing the operations  250  through  280 . The completion of these operations results in setting a bit to a logical “1” in the second row  110  (row “ 1 ”), in the “don&#39;t care” segment  740  (“*”) of the RT  700 . The “don&#39;t care” segment  740  is used since the value of P 1  is a “*”, representing a “don&#39;t care,” and the second row  110  is used since this is the second parameter P 1  in the RV 0 . Once again, the first bit of the three bit rule field is used since this is the first rule (i.e., the subscript of the RV 0  is “0”). This process of setting the appropriate rule bits in the RT  700  is continued by cycling through operations  250  through  280  for each of the parameters in the RV 0 . Once completed, the RT  700  will be loaded with the RV 0  parameters.  FIG. 9  shows an example of a rule table loaded with the RV 0  rule vector. 
     Control is then transferred back to operation  210 , where the system determines whether a new RV is available. In the current example, the next rule vector (RV 1 ) is available, and since space is available in the RT  700  (operation  220 ), the rule incrementing variable “r” is then set to “1”. Similarly to the method used to load RV 0 , the RT  700  is loaded with the value vectors contained in RV 1  (i.e., “1.254.*.255.*”) by cycling through operations  250  through  280 . Upon exiting conditional operation  280 , the RT  700  will be loaded with rule parameters RV 0  and RV 1 .  FIG. 10  shows an example of a rule table loaded with the RV 0  and RV 1  rule vectors. It is notable that the extended rule table shown in  FIG. 10  includes two additional “don&#39;t care” values after the loading of the RV 1  rule vector. 
     Extended Rule Table Checked against a Data Vector (DV) 
     One embodiment of the present invention provides for the checking of a data vector (DV) against a loaded extended rule table. To illustrate this embodiment, the ERT  700 , which has been loaded with rule vectors RV.sub.0 and RV.sub.1 will be used. Also, the DV checking will be described with reference to  FIG. 11 . 
     Because of the similarities of the rule tables shown in  FIGS. 1 and 7 , some of the rule checking methods that may be used for a RT  100  also may be used for the RT  700 . In other words, some of the rule checking methods illustrated in  FIG. 6  for the RT  100  also may be used for the RT  700 . More particularly, operations used for the ERT  700  ( FIG. 11 , operations  1110  through  1130 , and  1150  through  1170 ) correspond to the operations used for the ERT  100  ( FIG. 6 , operations  610  through  630 , and  650  through  670 ). However, one notable difference between these methods is shown in  FIG. 11 . In this figure, operation  1140  is changed to reflect the use of the “don&#39;t care” operation utilized by the ERT  700 . Specifically, in operation  1140 , the value corresponding to the value contained in the segment pointed to by the respective parameter of a received DV, is logically ORed with the value contained in the “star” segment of the same row. 
     For example, if a specific segment contains “0000” and the “star” segment contained “0100”, the result of a bit-wise logical OR operation would be “0100.” The result of this OR operation would then be ANDed with the value of the “c” variable. In other words, once the logical OR operation is performed, processing continues to utilize a logical AND operation in this operation, as described in reference to  FIG. 6 , operation  640 . 
     Loaded Extended Rule Table Checked against Data Value Example 
     To illustrate the ability of the present invention to utilize a “don&#39;t care” situation, a non-limiting, specific example of checking a data vector (DV) against the ERT  700  will now be described. This description will be made with reference to the RT  700  shown in  FIG. 10 , which has been loaded with rule vectors RV 0 , and RV 1  in accordance with the method shown in  FIG. 2 . In this example, the following exemplary value vector DV 0  will be used:
 
DV 0 =0.4.2.3.4
 
     In  FIG. 11 , at the first operation  1110 , the system waits for a new DV. If a new DV has not been received, then control remains at this operation. However, once a DV is received, then control will flow to operation  1120 . In operation  1120 , the inner loop counter variable “i” is reset to “0”, while the variable “c” is initialized to “−1” (i.e., c=111). Next, during a first iteration of an inner loop, the value of DV 0  (P 0 ) is determined and placed in variable “v” (operation  1130 ). In the current example, since P 0 =“0”, the execution of this operation results in “v” having the value “0.” 
     In operation  1140 , two separate operations are performed. First, the DV segment value and the “star” segment value are logically ORed. That is, the value of A(i,v) is ORed with the value of A(i,J). The second operation performed in this operation is a logical AND between the variable “c” and the result of the logical OR operation. 
     In the current example, the corresponding value of the value segment A(i,v) (i.e., the value of A(0,0), is “100”, while the corresponding value of the “star” segment A(i, J) (i.e., A(0,256)) is “000.” Thus, in performing the first operation of operation  1140 , “100” is ORed with “000”, resulting in the value “100.” In performing the next operation, the variable “c” is ANDed with the result of the logical OR operation. Since variable “c” has a current value of “111” (because of the initialization performed in operation  1120 ), “111” is ANDed with “100.” The result of this second operation is “100”, which is placed in the variable “c.” 
     Control is then passed to operation  1150  where the row counter “i” is incremented and control is then passed to a check operation that determines whether additional rows are to be processed (operation  1160 ). In the current example, additional rows are to be processed so control returns to operation  1130 . 
     During a second iteration of the inner loop, in operation  1130 , the operations illustrated in operations  1130  and  1140  are performed based on the second parameter P 1  of the DV 0 . In the current example, the second parameter of DV 0  (P 1 ) is “4”, which has a corresponding segment value of “000” (i.e., A(1,4)=“000”), while the “star” segment value for the same row is “100” (i.e., A(1,256)=“100”). Thus, the first operation performed in operation  1140  is “000” being ORed with “100”, resulting in “ 100 .” The next operation performed is a logical AND between “c” and the result of the logical OR operation. 
     Since variable “c” has a current value of “100” (because of the prior inner loop cycle), “100” is ANDed with “100.” The result of this second operation is “100”, which is placed in the variable “c.” Once again, the rule checking process continues by cycling through operations  1150  and  1160 , and since there are additional rows that need processing, control returns again to operation  1130 . 
     During a third iteration of the rule checking method, the operations illustrated in operations  1130  and  1140  are performed based on the third parameter P 2  of the DV 0 . In the current example, the third parameter of DV 0  (P 2 ) is “2”, which has a corresponding value segment of “100” (i.e., A(2,2)=“100”), while the “star” segment value for the same row is “010” (i.e., A(2,256)=“010”). Thus, the first operation performed in this operation is “100” being ORed with “010”, resulting in “110.” The next operation performed is a logical AND between “c” and the result of the logical OR operations. 
     Since variable “c” has a current value of “100” (because of the prior inner loop cycle), “100” is ANDed with “110.” The result of this second operation is “100”, which is placed in the variable “c.” Once again, the rule checking process continues by cycling through operations  1150  and  1160 , and since there are additional rows that are to be processed, control returns again to operation  1130 . 
     Operations  1130  through  1150  will repeat until all the DV 0  parameters (“0.4.2.3.4”) have been processed. In the current example, after all of the parameters of DV 0  have been processed, “c” will have a value of “100”, which indicates that the received DV 0  corresponds to the first rule RV 0 . In particular, the DV 0  corresponds to the first rule RV 0  because the first bit position of the variable “c” equals a “1.” 
     One of ordinary skill will realize that the rule checking method described above may be modified in a variety of ways. For example, this rule checking method may be modified to identify a situation where rules do not exist in a particular rule table (i.e., there are no corresponding RVs and DVs). Another modification may be to add an additional procedure to operation  1140 , for example, where “c” is checked for a “0” value (e.g., c=“000”). In this modified operation  1140 , if “c” is contains a “0” value, then there would be no need to continue checking any additional rows of the RT  700 , so control could then be transferred to operation  1170 , for example. 
     It is to be understood that in the present invention, the search time is bounded by the number of parameters in the rule vector, thus providing a significant advantage over traditional searching methods. For example, traditional systems typically experience a dramatic increase in search time as the number of parameters increase, which is not the case in this aspect of the present invention. 
     Rule Table Having a Range of Values 
     Several methods for rule table loading and checking have been described utilizing rule vectors having a single value, but the present invention is not so limited. For example, situations may occur where a user may wish to load, and subsequently check, a rule table having parameters with a range of values, rather then a single value. One type of situation where a range of values may be useful is in a system that processes color pixel information. For example, pixel color may be determined by three parameters, red, green and blue, wherein each of these parameters has a value ranging from 0 to 255. An exemplary rule vector (RV) that can accommodate this situation may have the following format:
 
RV=P red .P green .P blue 
 
       FIGS. 13 and 14  show an exemplary rule table (RT) that may be used to accommodate pixel color situation. The RT may be configured with three rows, one for each parameter (red, green, blue), with 256 segments in each row. The number of bits in each segment will typically depend on the maximum number of rules utilized by the system. For example, one may wish to define a particular rule for determining whether or not a color is red. This rule would indicate that a particular color is red if the range of the red component is between 200 and 255, the green component is between 0 and 50, and the blue component is between 0 and 50. An exemplary rule vector have a range of values may utilize the following format:
 RV red =200–255.0–50.0–50 
     However, it should be understood that since each RV typically must have a specific value in each place, these types of RVs may have to be preprocessed so that they may be utilized in a standard rule table. For example, RV red  could be divided into a series of rule vectors, as illustrated by the following rule vectors:
 
RVa=200.0.0
 
RVb=201.0.0
 
     Utilizing this type of rule vector format would result in the very last rule vector having the following format:
 
RVz=255.50.50
 
     Utilizing the above-described rule vector format would result in no fewer than 145,656 rules (i.e., (255–200+1)*(50–0+1)*(50–0+1)). To implement this type of rule vector format, a sub-rule map table (SMT) may be used to map the sub-rules to the original rule that has created them. During rule checking, when a match is found to a sub-rule (i.e., a match between a data vector and a rule vector) the SMT may be checked to identify the matching original rule. Since the creation of an appropriate SMT is well known in the art, it will not be further described in the specification. 
     It is to be realized that the rule table loading method described in  FIG. 2  also may be used to load the “color” rule vector into a rule table. Furthermore, the rule table checking method shown in  FIG. 6  may easily be modified to accommodate any necessary operations to check for the “color” RVs. It is also to be understood that rule checking for “color” rule vectors may utilize the “star” segment (i.e., “don&#39;t care”) method illustrated in  FIG. 11 . 
     Modified Rule Table Having a Range of Values 
     The above method accommodates rule vectors having a range of values. More specifically, the method permits rule checking for pixel colors having three parameters, red, green and blue, each ranging in value from 0 to 255. Although this range of values aspect is described with respect to a “color pixel” implementation, the present invention is not so limited and may easily be modified. 
     For example, while the described range of values method may be utilized on a variety of computer systems, this method requires a large number of bits which may exceed the capacity, or requirements of some systems. To accommodate these systems, the present invention provides a modified method in which the bit requirements are significantly reduced while still providing for rule vectors having a range of values. 
       FIG. 12  shows an example of a modified rule loading method. It is to be realized that the rule table loading shown in  FIG. 12  is similar to the methods used in  FIG. 2 . For example, in  FIG. 12 , operations  1200  through  1220 , relate to  FIG. 2 , operations  200  through  240 . Also,  FIG. 12 , operations  1260  and  1265  relate to  FIG. 2 , operations  270  and  280 . For clarity, since these particular operations have been described with respect to  FIG. 2 , a detailed description is not provided for some of the operations shown in this figure. The method illustrated in  FIG. 12  will now be discussed with reference to the loaded rule tables shown in  FIGS. 13 and 14 , as an example. 
     First, in  FIG. 12 , in operations  1200  through  1220 , the rule table is initialized and then several checks are performed to determine RT availability. More detailed description of these operations can be found in the discussion relating to  FIG. 2  since operations  1200  through  1220  correspond to operations  200  through  240 . 
     Next, in operation  1225 , the i th  parameter P i  is checked to determine whether it contains a single value or a range of values. If the parameter P i  contains a range of values, control passes to operation  1235  where the variable “v” is set to the low value of the parameter P i . Next, in operation  1240 , the variable “VH” is set to the high value of P i . Control then passes to operation  1245 . 
     However, if at operation  1225  it was determined that the i th  parameter P i  contains a single value, execution would flow to operation  1230 . In operation  1230 , the variable “v” and the variable “VH” are set to the value contained in the parameter P i . Once this operation is completed, control passes to operation  1245 . 
     In operation  1245 , which is a first operation of an inner loop, execution continues and a value assignment is made to the specific bit in the rule table “A” which corresponds to the i th  row  110 , at the v th  value  120  and the respective r th  rule bit(s)  130 . Specifically, A(i,v,r) is assigned the bit value “1.” It should be understood that the inner loop, which is bounded by the operations  1245  through  1255 , assigns the necessary values throughout the range of values. That is, the appropriate value assignments are made for the entire value range, from the lower range to the upper range (e.g., v to VH). 
     Next, in operation  1250 , the variable “v” is incremented by “1”, which is followed by a check in operation  1255 . In this operation, the value of “v” is compared against the value of “VH.” If “v” is less than or equal to “VH”, then execution of the inner loop continues and process control is passed to operation  1245 . However, where the value of “v” is more than “VH”, indicating that the entire range (e.g., v to VH) has been processed, control passes to operation  1260 . 
     In operation  1260 , the “i” counter variable is incremented by “1”, and then checked in operation  1265  to determine if “i” has reached the maximum value “I.” Again, “I” represents the maximum number of rows in the RT (or the maximum number of parameters P I  in the RV). Thus, when “i” reaches the “I” value, all of the parameters of the RV have been processed. As long as “i” is smaller than “I”, the sequence of operations  1225  through  1265  continue. However, once the value of “I” is reached, the system will exit out of the loop and continue execution at operation  1205 , waiting for a new rule vector. 
     Loading and Checking a Rule Table Having (RGB) Rule Vectors 
     To illustrate the method shown in  FIG. 12  for loading a rule table, the loading of several exemplary rule vectors (e.g., RGB) will now be discussed with reference to the loaded rule tables shown in  FIGS. 13 and 14 . 
       FIG. 13  shows a rule table that contains three parameters that correspond to the Red, Green and Blue components of an RGB signal. Each of these parameters is provided with a value between 0 and 255. Also, in this rule table, a maximum of three rules are specified. Accordingly, the size requirement of a rule table having this configuration is 3*256*3=2,304 bits or 288 bytes. 
     In the current example, a user may define three separate rules to identify “red”, “green” and “blue” according to the dominance of the color component, such that a “red” would have a high intensity of redness and so on. Accordingly, the loading of rule values into a rule table will be demonstrated using the following exemplary rule vectors:
 
RV red =200–255.0–50.0–50
 
RV green =0–50.200–255.0–50
 
RV blue =0–50.0–50.200–255
 
       FIG. 12  shows that the RV red  may be loaded into a rule table by performing the initialization procedures illustrated operations  1200  through  1220 , as described above. 
     Control then passes to operation  1225 , which is the start of the first inner loop. In this operation, the i th  parameter P 0  (or P r ) is checked to determine whether it contains a single value or a range of values. In the current example, the first parameter contains the range of values “200–255”, which represents the “red” component of the RV red  rule value. Since a range of values is present, control flows to operation  1235  where the variable “v” is set to the low range value “200.” Next, in operation  1240 , the variable “VH” to set to the high value “255.” Control then passes to operation  1245  where A(i,v,r) (i.e., A(“r”, 200, “R”)) is assigned the bit value “1.” 
     Next, in operation  1250 , the variable “v” is incremented by “1”, which is followed by a check in operation  1255 . In the current example, “v” is less than “VH”, so execution of the inner loop continues and process control is passed to operation  1245 . This inner loop will continue until “v” is greater than “VH”, indicating that the entire range (e.g., 200–255) has been processed. At this point, control passes to operation  1260  where the counting variable “i” is incremented. 
     In the next operation  1265 , counting variable “i” is checked to determine whether the “I” value has been reached. In the current example, “I” is equal to three (i.e., there are three rows corresponding to the red, green, and blue parameters P i  of the vectors RV red , RV green , and RV blue , in the RT). Thus, two additional rows still require loading, so control is passed back to operation  1225 . 
     Returning to operation  1225 , the incremented i th  parameter P 1  (or P g ) of the rule vector RV red  is checked to determine whether it contains a single value or a range of values. In the current example, this parameter contains the range of values “0–50”, which represents the “green” component of the RV red  rule vector. Again, a range of values is present so control flows to operation  1235 . 
     In operation  1235 , the variable “v” is set to the low range value “0”, and in operation  1240 , the variable “VH” to set to the high value “50.” Control then passes to operation  1245  where A(i,v,r) (i.e., A(“g”, 0, “R”)) is assigned the bit value “1.” 
     Next, in operation  1250 , the variable “v” is incremented by “1”, which is followed by a check in operation  1255 . In the current example, “v” is still less than “VH”, so execution of the inner loop continues and process control is passed to operation  1245 . This inner loop will continue until “v” is greater than “VH”, indicating that the entire range (e.g., 0–50) has been processed. Once the range of values has been processed, control passes to operation  1260  where the counting variable “i” is incremented. 
     In the next operation  1265 , counting variable “i” is checked to determine whether the “I” value has been reached (“I” is equal to three). Thus, one additional row still requires loading, so control is passed back to operation  1225 . 
     Returning for a third time at operation  1225 , the incremented i th  parameter P 2  (or P b ) of the rule vector RV red  is checked to determine whether it contains a single value or a range of values. In the current example, this parameter contains the range of values “0–50”, which represents the “blue” component of the RV red  rule vector. Once again, a range of values is present so control flows to operation  1235 . 
     In operation  1235 , the variable “v” is set to the low range value “0”, and in operation  1240 , the variable “VH” to set to the high value “50.” Control then passes to operation  1245  where A(i,v,r) (i.e., A(“b”, 0, “R”)) is assigned the bit value “1.” 
     Next, in operation  1250 , the variable “v” is incremented by “1”, which is followed by a check in operation  1255 . In the current example, “v” is still less than “VH”, so execution of the inner loop continues and process control is passed to operation  1245 . This inner loop will continue until “v” is greater than “VH”, indicating that the entire range (e.g., 0–50) has been processed. Once the range of values has been processed, control passes to operation  1260  where the counting variable “i” is incremented. 
     In the next operation  1265 , counting variable “i” is checked to determine whether the “I” value has been reached (“I” is equal to three). Since the “I” value has been reached (i.e., all rows have been loaded), control is passed back to operation  1205 .  FIG. 13  shows an example of a rule table loaded with the RV red  rule vector. 
     In the current example, the next rule vector RV green  is available. The RV green  rule vector may be loaded into the rule table using the same method as was described to load the RV red  rule vector (i.e., cycling through operations  1205 – 1265 ). Likewise, this same method may be used to load the RV blue  rule vector.  FIG. 14  shows an exemplary rule table loaded with all three rule vectors RV red , RV blue , and RV green . 
     Check Data Vectors 
     To illustrate some of the additional capabilities of the present invention, a specific example of checking a DV against a rule values having a range of values will now be described. This description will be made with reference to the rule table shown in  FIG. 14 , which has been loaded with rule vectors RV red , RV blue , and RV green  in accordance with the method shown in  FIG. 12 . In this example, the following exemplary received value vectors DV 0  and DV 1  will be used:
 
DV 0 =255.255.255
 
DV 1 =4.255.0
 
     Referring now to the flowchart in  FIG. 6 , an exemplary method of checking a DV against a loaded RT will now be described. However, since rule checking using the method shown in this figure has previously described, some of the operations will be omitted from the following discussion. 
     In  FIG. 6 , at operation  620 , the inner loop counter “i” is set to “0”, while variable “c” is set to “−1” (i.e., c=“111”). Next, during a first iteration of an inner loop, the value of the I th  parameter P 0  of the DV 0  is determined and placed in variable “v” (i.e., v=DV 0 (P 0 )). (Operation  630 ). In the current example, the execution of this operation results in “v” having the value “255.” Therefore, the value denoted by A(i,v) is the value located in the RT at A(0,255), which is “100.” That is, as shown in  FIG. 14 , the value located at the last segment  120  of the RT (v=255) of the first row  110  (i=0) is “100.” 
     Next, in operation  640 , the logical operation “111” AND “100” is performed, which results in “c” having the value “100”The row counter “i” is then incremented by one (operation  650 ), and then compared with the constant “I” to determined if any additional rows  110  are present (operation  660 ). In the present example, as seen in  FIG. 14 , additional rows exist, so control is passed back to operation  630 . 
     In operation  630 , the variable “v” is set to the value of the second parameter P 1  of the DV 0  (i.e., v=DV 0 (P 1 )). Since DV 0 (P 1 ) is “255”, the content of the segment A(I,v) is “010” (i.e., A(1, 255)=“010”). In the next operation  640 , the logical operation “100” AND “010” is performed, which results in “c” having a value of “000.” Since one additional row exists, control is again passed back to operation  630 . 
     Returning now to operation  630 , the variable “v” is set to the value of the third parameter P 2  of the DV 0  (i.e., v=DV 0 (P 2 ). Since DV 0 (P 2 ) is “255”, the content of the segment A(Iv) is “001” (i.e., A(2, 255)=“001”). In the next operation  640 , the logical operation “000” AND “001” is performed, which results in “c” again having a value of “000.” Since no additional rows exist, the value of “c”, which is “000”, is returned to the system (operation  670 ). The “000” “c” value indicates that DV 0  does not correspond to any of the rules defined in the RT. 
     Rule checking the RT with another received data vector DV 1  will now be discussed. Once again processing reaches operation  620  where the inner loop counter “i” is set to “0”, while variable “c” is set to “−1” (i.e., c=“111”). Next, during a first iteration of an inner loop, the value of the first parameter P 0  of the DV 1  is determined and placed in variable “v” (operation  630 ). In the current example, the execution of this operation results in “v” having the value “4.” Therefore, the value denoted by A(i,v) is the value located in the RT at the location A(0,4), which is “011.” That is, as shown in  FIG. 14 , the value located at segment four of the RT (v=4) of the first row (i=0) is “011.” 
     Next, in operation  640 , the logical operation “111” AND “011” is performed, which results in “c” having the value “011”. The row counter “i” is then incremented by one (operation  650 ), and then compared with the constant “I” to determine if any additional rows  110  are present (operation  660 ). In the present example, as seen in  FIG. 14 , additional rows exist, so control is passed back to operation  630 . 
     In operation  630 , the variable “v” is set to the value of the second parameter P 1  of the DV 1  (i.e., v=DV 1 (P i )). Since DV 1 (P 1 ) is “255”, the content of that segment is “010” (A(1, 255)=“010”). In the next operation  640 , the logical operation “011” AND “010” is performed, which results in “c” having a value of “010.” Since one additional row exists, control is again passed back to operation  630 . 
     Returning once again to operation  630 , the variable “v” is set to the value of the third parameter P 2  of the DV 1  (i.e., v=DV 1 (P 2 )). Since DV 1 (P 2 ) is “0”, the content of that segment A(i, v) is “110” (i.e., A(2, 0)=“110”). In the next operation  640 , the logical operation “010” AND “110” is performed, which results in “c” having a value of “010.” Since no additional rows exist, the value of “c”, which is “010”, is returned to the system (operation  670 ). The “010” value in “c” indicates that DV 1  corresponds with the second rule defined in the RT, and in this particular example, would be considered “green.” 
     It would be understood by those skilled in the art that the invention can be extended to DVs containing a range of values. 
     Modified Extended Rule Table 
     It is to be realized that the above rule checking method may be modified to incorporate a modified extended rule table (MERT) that utilizes “don&#39;t care” situations. One application of this method is in performing rule checking to identify an IP tuple. In this case “don&#39;t care” values may be used instead of yet unknown values of an IP tuple. This, by a non-limiting example, can be useful when a process flow generates process flows where certain of the components of the tuple are known but not all of them. The unknown values can be replaced by a “don&#39;t care” value and substituted at a later time, when such unknown values become known. 
     Looking again at  FIG. 8 , a source IP address and a destination IP address are shown having 32 bits each, so they therefore provide values range from “0” to “2 32 −1.” This figure also shows the protocol type as an 8-bit field, and the source port and destination port are 16-bits each. While it may be impractical to create a rule table for the entire range of values, it is possible to divide each of the 8-bit fields into smaller segments. For example, each 8-bit field may be defined by a one byte segment. Therefore, the IP addresses may be 4 bytes each (4*8=32 bits), and the port addresses two bytes each. Each parameter may have a range from “0” to “255.” The number of rows in the MERT will now expand from five rows, as shown in  FIGS. 9 and 10 , to thirteen rows, as shown in  FIG. 15 . This approach results in significant savings in the rule table size. More specifically, while the number of rows within the rule table is increased (i.e., from 5 to 13), the required number of total bits necessary to represent the rule table is significantly reduced. In the first case, the maximum number of rows is 5, the maximum value range is 2 32 , and N number of rules are allowed. Therefore the total memory requirement is 5*2 32 *N bits. However, when more rows are used, as in the example above, the maximum number of rows is 13, the maximum value range is 2 8 , and N number of rules are allowed. Therefore the total memory requirement is 13*2 8 *N bits, which results in a significantly smaller memory requirement. 
     Additional savings (e.g., reduction in bits required to represent the rule table, reduction in rule checking and loading, etc.) also may be achieved by utilizing the “don&#39;t care” method only where the full range of the original 32-bit or corresponding 16-bit parameter are represented in the MERT. One method for implementing this approach results in providing the “don&#39;t care” option once every four rows.  FIG. 15  shows an exemplary MERT utilizing this approach. Specifically, blank rows  750  are used in rows zero through two, and in rows four through six. The “don&#39;t care” rows  710  are used in rows  3 ,  7 ,  10 , and  12 . 
     Modified Extended Rule Table (MERT) Data Vector (DV) Checking 
     To illustrate the checking of a data vector (DV) against a loaded modified extended rule table (MERT), reference will be made to the MERT rule table shown in  FIG. 15 . It is to be appreciated that the loading of the MERT may be accomplished by any of the previously described rule table loading methods (e.g.,  FIG. 2 ). For clarity, further description of rule loading into the MERT rule table is omitted. 
     Referring now to the flowchart in  FIG. 16 , an exemplary method of checking a data vector (DV) against a loaded MERT will now be described. In  FIG. 16 , at operation  1610 , the system is waiting for a new DV. When a new DV is received, control will flow to operation  1620 . In operation  1620 , each parameter of the DV is stored in a separate variable. Each of these storage variables are one byte long, for example, and are designated V 1 , V 2 , V i , . . . V 12 . Upon the completion of operation  1620 , the values contained in DV 1-12  will be stored in corresponding variables V 1-12 . Once the DV&#39;s parameters are stored, process flows to operation  1630 . 
     Operations  1630  and  1640  are similar procedures which may be utilized to calculate a series of logical AND/OR operations. The procedures performed in operation  1630  relate to the IP source address, while the procedures performed in operation  1640  relate to the IP destination address. 
     Looking first to operation  1630 , C 0  is calculated by ANDing the content located at four separate segments within the MERT. Specifically, the content located at the segments A(0,V 0 ), A(1,V 1 ), A(2,V 2 ) and A(3,V 3 ) are ANDed together. The result of this ANDing is then ORed with the content located at A(3,256). Put another way, this operation performs a logical AND operation on the content of the corresponding segments of each of the four rows (rows  0 – 3 ) and the result is logically ORed with the content of the “don&#39;t care” cell (cell “256” of the fourth row (row “ 3 ” )). Once C 0  has been calculated, control flows to operation  1640 . 
     In operation  1640 , C 1  is also calculated by ANDing the content located at four separate segments within the MERT. The calculation of C 1  may be performed in a manner similarly to the method used to calculate C 0 . That is, C 1  may be calculated by ANDing the content located at the segments A(4,V 4 ), A(5,V 5 ), A(6,V 6 ) and A(7,V 7 ). The result of this ANDing is then ORed with the content located at A(7,256) (i.e., the “don&#39;t care” segment). 
     A similar process takes place in operations  1650  and  1660 , but in these operations only two rows are ANDed together since each component denoted by these segments have only two bytes. For example, segments A(9,V.sub.9) and A(10,V.sub.10) may be used to represent the source port address, while segments A(11,V.sub.11) and A(12,V.sub.12) may be used to represent the destination port address. 
     As shown in operation  1650 , C 2  is calculated by ANDing the A(9,V 9 ) and A(10,V 10 ) segments, with the result of this ANDing being ORed with the content located at A(10,256), which is the “don&#39;t care” segment. Once C 2  has been calculated, control flows to operation  1660 . 
     In operation  1660 , C 3  is calculated by ANDing the content located at the segments A(11,V 11 ) and A(12,V 12 ), and then ORing this result with the content located at the “don&#39;t care” segment A(12,256). 
     Next, in operation  1670 , a logical AND is performed between all the previously calculated components (i.e., C 0 , C 1 , C 2 , C 3 ), and the result of the logical OR between the content of the segment corresponding to the value of the protocol type (i.e., A(8, V 8 )) and the value of the “don&#39;t care” segment belonging to the same row (i.e., A(8,256)). This value (i.e., C 0 ) is returned in operation  1680  to the calling function, and the system returns to its waiting position for another DV to arrive. 
     The previous description of the preferred embodiments is provided to enable a person skilled in the art to make and use the present invention. Moreover, various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles and specific examples defined herein may be applied to other embodiments without the use of inventive faculty. Therefore, the present invention is not intended to be limited to the embodiments described herein but is to be accorded the widest scope as defined by the limitations of the claims and equivalents thereof.