Patent Application
20070201458
The present invention relates generally to a system and method for applying access control rules to packet traffic. More particularly, the present invention relates to a system and method for implementing Access Control Lists using hash-trie-key tables.
Access Control Lists (ACLs) are used in routers to control the flow of packet traffic. An ACL consists of a set of access control (AC) rules, where each rule specifies some of the fields in packets (some of the bits in these fields are typically wildcarded), and the action to be taken for packets which conform to the rule. Packet traffic throughput is screened in order to see which AC rule (if any) is to be applied to the packet.
One approach used to access rules within an ACL is using a multi-bit trie table structure. The multi-bit trie table structure was designed particularly for longest prefix matching applications. However, ACL's do not involve a prefix match, but rather matching of bits scattered throughout the key. The benefits of multi-bit trie in prefix matching is largely due to the early lookup termination when the prefix bits have been exhausted—but this advantage fails to gain much benefit for ACL's. Furthermore, the multi-bit trie structure can only examine a limited number of bits (typically 8) at each stage. This means that a verification of a 104-bit key will require over 10 stages. A lookup method that requires numerous stages, such as that used with the multi-bit trie table structure, is time consuming. With routers receiving large quantities of packets, a time consuming ACL lookup process reduces overall system efficiency and throughput.
The present invention may be better understood, and its numerous objects, features, and advantages made apparent to those skilled in the art by referencing the accompanying drawings, wherein:
The following is intended to provide a detailed description of an example of the invention and should not be taken to be limiting of the invention itself. Rather, any number of variations may fall within the scope of the invention, which is defined in the claims following the description.
The shortcomings of the prior art suggest the possibility of an algorithm based on exact match, not of the entire key, but of a specified subset of the bits in the ACL fields. On the surface there are a number of challenges with this new approach. First, the bits included in the specified subset are scattered throughout the key, making them somewhat more difficult to assemble. Second, if the number of bits used is in the subset is large, then a large lookup table is required. And third, wildcarding may cause “rule explosion”, that is, one rule may blow up into a large number of table entries, if a large number of wildcarded bits are included in the subset. The first two difficulties are addressed by using a hash-trie-key (HTK) lookup table approach, where the hash key is obtained by masking the selected bits in the original key. Alternatively, when the first difficulty is circumvented by other means, the bits in the specified subset may be assembled to form a key into a regular (flat) data table. The final difficulty is addressed by using multiple lookup tables in conjunction with different masks, such that the rules identified by each table have limited rule explosion.
The ACL rule identification in this approach is made based on a series of table lookups. Each table is built using a subset of the rules in the ACL. Hence each table validates or invalidates a subset of all the ACL rules. If the rule is validated in a table, in many cases the lookup process may be terminated, so it is not always necessary to look up in all the tables. It is also possible that the lookup process may terminate early even when no rule is validated, because rules for later tables may be eliminated from consideration if they are inconsistent with earlier lookups.
Each rule set corresponds to a different predefined mask (a first rule set corresponds to a first predefined mask, a second rule set corresponds to a second predefined mask, etc.). Predefined masks are stored in predefined masks data store 135. The corresponding predefined mask is used to mask the original key forming a masked key and this masked key is used in the lookup using the corresponding rule set. At step 130, the first rule set and the first predefined mask are selected. At step 140, the key (formed in step 120) is masked using the first predefined mask forming a “masked key.”
In one embodiment, the predefined masks in the previous paragraph is used to select bits from the original key. The bits selected by a mask are assembled into a key, which is used as an index into a lookup table. In this embodiment, no hashing is used on the key. The lookup tables are not hash-trie-key tables, but rather simple indexed arrays of data.
In one embodiment, the hashmask is used to lookup rules in the table lookup unit (TLU) (step 145). Alternatively, the lookup could be performed using a traditional microprocessor. Each lookup returns a Data or Fail result (step 150). A determination is made as to whether the lookup result is Data or if it failed (decision 155). If the result is Data, decision 155 branches to “yes” branch 158 and the data is returned to the CPU for examination.
If the data suggests a possible rule, then decision 160 branches to “yes” branch 164 whereupon one of the rule sets 165 (the rule set corresponding to the predefined mask that is being used) is checked in CPU (decision 175) to determine if the rule is valid. If the rule is validated, then decision 170 branches to “yes” branch 174 whereupon, at decision 175, the validated rule is compared with the current final rule (the final rule is initialized to be the default rule in step 125). If the newly validated rule has a higher priority than the existing final rule, then decision 175 branches to “yes” branch 178 and the final rule is replaced with the newly validated rule at step 180.
On the other hand, if the lookup was successful, but the lookup did not identify a rule, then decision 160 branches to “no” branch 162. Likewise, if a rule was found but it is not a valid rule, then decision 170 branches to “no” branch 172. Finally, if a valid rule was found but its priority is not higher than the last rule found, then decision 175 branches to “no” branch 176. Each of these “no” branches branch to decision 185 which is used to determine whether to terminate the lookup procedure.
Following each lookup, a termination check is performed, to see if further hash lookups are necessary (decision 185). The termination decision is based on information contained within the Key entry, as well as table-specific information. If the termination information indicates a continue, then the termination indicator is updated, decision 185 branches to “no” branch 188 which loops back to select the next hash mask (step 190), and the same lookup procedure is followed for the next HTK table as described above. When the lookup procedure is terminated, decision 185 branches to “yes” branch 192 whereupon the final rule is applied to the packet (step 195) and processing ends at 199.
A≡the entire set of rules
A0≡the entire set of effective rules (i.e. ineffective rules have been removed).
Each lookup table is constructed based on a subset of the entire set of rules. These rules are referred to as the “included rules” for that lookup table. The following notation is used:
Ij.≡the set of included rules for the j'th lookup table.
(The j'th table lookup either validates or invalidates the rules in set Ij.)
The included rule sets Ij are constructed in sequence. After the construction of the first rule set I1, the set of remaining rules is noted by A1: that is, A1≡A0\I1. The included set I2 is a subset of the remaining rules A1. The remaining rules following the construction of I2 are those rules in A1 which are not in I2: hence A2≡A1\I2. In summary:
A1=A0\I1;
A2=A1\I2;
A3=A2\I3;
Note that the included rule sets {Ij} are pairwise disjoint:
Ij∩Ik=Ø if j≠k.
On the other hand, the remaining rule sets {Aj} form a nested series:
A0⊃A1⊃A2⊃ . . . .
In addition, each included rule set Ij comprises two types of rules: first class rules and second class rules. The first class rules are those which may be conclusively validated by the j'th table lookup, and no further tablelookups are required. The second class rules require further lookups.
An ‘ineffective’ rule is characterized mathematically as follows. Let R be an ACL rule, and let M be the corresponding mask (using the format described in [1]). Then (R,M) is ineffective if there exists a rule, mask pair (R′,M′) such that:
In order to illustrate the concepts employed in the algorithm, an exemplary table of simplified rules is shown in Table 1. The rules are listed in order of decreasing priority—hence a lower rule index indicates a higher priority. Here the example assumes two 4-bit fields, which have been concatenated to form an 8-bit key. In practice, the key would be formed by a concatenation of multiple fields (typically Source IP, Destination IP, Source Port, Destination Port, and Protocol), and would be much longer (typically 104 bits).
In Table 1, a ‘0’ bit in the mask means the bit is arbitrary, and a ‘1’ bit means the bit is fixed. All the rules in Table 1 are “pre-masked”, so that if (Rj, Mj) is the j'th (rule,mask) pair we have:
Rj & Mj=Rj. (where ‘&’ is the bitwise ‘and’ operation).
Ineffective rules may be identified as follows. Table 2 is constructed where the (m,n) entry of the table is defined as:
T(m,n)=MnMm m>n.
0000
0000
0000
0000
0000
0000
0000
0000
0000
0000
0000
0000
0000
0000
The entries which yield all 0's are indicated in bold. In these rule pairs, the lower-priority mask is more restrictive than the higher-priority mask. For these bolded (m,n) entries, Table 3 shows the computation of Mm&Rn, and the comparison with Rm:
When Mm&Rn is equal to Rm for a given m and n, this indicates a rule pair for which the higher-priority rule always supersedes the lower-priority rule. For the example introduced in Table 1, Table 3 shows that Rule 6 supersedes Rule 7. In other words the higher-priority Rule 6 also applies whenever Rule 7 applies. Hence Rule 7 is ineffective, and can be dropped from the list of rules.
Returning to
Unresolvable pairs from the rule set in Table 1 are identified with the aid of Table 4, which is constructed according to the following rule:
T(m,n)=Rm & Mn m≠n.
Note that since the rules are pre-masked, this means that: T(m,n)=Rm & (Mm & Mn) m≠n.
In Table 4, the cell values are bolded for which T(m,n)=T(n,m). This means Rules m and n agree on their common mask, so they have at least one key in common, which in turn implies they are unresolvable. For instance, entries (1,2) and (2,1) are bolded in Table 4, and the key 10000111 satisfies both Rule 1 and Rule 2.
The first class rules may be characterized as follows:
If a first-class rule is validated, no further lookup is necessary, because all higher-priority rules must be invalid. In the case of Table 1, using Table 4 it can be seen that Rules 1,4, and 5 form the first-class set.
Returning to
The second-class set is not necessarily uniquely defined, for in some cases the set of first-class rules may be extended in multiple ways to form a maximal completely resolvable set. Note that if a second-class rule is validated, further lookups are used to make sure that no other higher-priority rule also matches the key. In contrast, a first-class rule uses no further lookups.
In the example provided, Rule 3 is a second-class rule, because it is resolvable with the first-class rules 1,4, and 5. The purpose of the second-class set is to augment the included rule set, so that the table may be used to validate more rules.
Returning to
It follows from the table that bit position 2 corresponds to the minimax value for number of consistent bits. Therefore, bit #2 is chosen as the first bit in the mask.
To find the next bit in the mask, a similar set of tables is created for the remaining bit positions (1-8, with 2 excluded). This time the consistency of each of the possible patterns ‘00’, ‘01’, ‘10’, and ‘11’ is determined for bit 2 and the given bit position. Note that an ‘N’ in Table 5 corresponding to bit ‘0’ will yield two ‘N’ entries in Table 6, while a ‘Y’ entry means the corresponding Table 6 entries will agree with Table 5. The analogous statements hold for bit ‘1’ and Table 7.
Bit positions 3,4,5, and 8 all yield the minimum overall max value 2 (overall max is the maximum of MAX values from Table 6 and Table 7). However of these four bit positions, position 5 has the minimum overall sum (overall sum is the sum of SUM values from Table 6 and Table 7). Hence bit 5 is chosen as the next bit position in the hash mask.
Finding the next bit position would require four tables similar to Table 5 in order to determine 3-bit pattern incidences. Continuing in this fashion, it is eventually determined that bit positions 2,5,8,3 are sufficient to resolve all four rules, as shown in Table 8. The various possible bit patterns are referred to as “templates”. Hence for this choice of bit positions, all templates correspond to at most one rule.
In the final lookup table, each template associated with a rule will correspond to a Key entry. If there are too many such templates, the number of table entries may be too large and cause problems with processing time and/or memory. In Table 8, it was determined that 9 templates (bit pattern for the hash mask bits) correspond to included rules. At first sight this may seems unusual because there are only 4 included rules. However, the reason becomes clear upon examination of Table 8: some rules correspond to multiple templates. In particular, Rule 5 corresponds to 4 separate templates, which would give rise to four separate Key entries.
In order to avoid table size difficulties, the algorithm includes the possibility of removing rules from the included set. Returning to
Template collisions can be illustrated with an example. Suppose a threshold of 5 distinct templates is set corresponding to rules. During the construction of the hash mask, this threshold is exceeded at the 3-bit stage. Table 9 shows the bit templates and rule incidences at this stage, with hash mask bits 2,5,8.
It is clear that if Rule 5 is removed from the list, then there is no rule collision among the 3 remaining rules (1,3,4). Furthermore, only three templates will be associated with rules, as shown in Table 9.
The rule removal procedure removes one rule at a time, using a metric criterion to decide which rule to remove. Only rules involved in collision are candidates for removal. Second-class rules are favored for removal, as are rules of low priority.
The simplified ACL rules example is continued using the bit templates in Table 10. An initial hash mask (bits 2,5,8) is constructed corresponding to an initial set of rules (1,3,4). However, the remaining rules (2,5 and 6) still need to be accommodated (recall that Rule 5 was removed from the included set to reduce memory requirements). In order to do so, the construction procedure detailed above is repeated on the new remaining rule set {2,5,6}. In this case, from Table 4 it is clear that Rule 2 and Rule 6 are not resolvable, and so they will require two separate lookup tables. Hash masks are chosen for these two tables. For the second table with rules {2,5}, bit 2 is chosen which resolves them. For the third rule table with the single Rule 6, bits 1,2,3 are chosen which are the un-wildcarded bits of Rule 6. The three lookup tables are referred to as HTK_Table[j], j=0,1,2.
Referring back to
At step 440, the number of templates corresponding to termination entries is estimated. A determination is made as to whether the number of templates is too large for the table (decision 450). If sufficient memory remains, decision 450 branches to “yes” branch 455 whereupon, at step 460, rule templates and termination information are created for the currently selected table (HTK_table[i]) from rules included in the table selected in the inner loop (HTK_table[j]). At step 470, the estimate of the number of templates corresponding to HTK_table[i] is updated. Processing then loops back to continue processing the various tables (the inner loop continues decrementing until it is satisfied—when the inner loop is satisfied, the outer loop is incremented until all the tables have been processed). If both the inner and outer loops have been satisfied, then processing ends at 475.
Returning to decision 450, if the number of templates is too large, decision 450 branches to “no” branch 490 and processing ends at 490. Obviously, the more tables that are processed with sufficient memory remaining, the greater number of rule templates and termination information that will be created for assisting in early termination of ACL lookups using the HTK tables.
The simplified ACL example introduced in Table 1 and expanded in subsequent tables can be used to illustrate the creation of rule templates and termination information. According to the iteration scheme shown in
The next iteration in
The storage of termination information is explained in more detail in the following tables and descriptions. The information gained in the previous stages of the algorithm shown in
In the simple ACL rules example introduced in Table 1, the data structures have values as shown in Table 14, below. Here the 3-bit hash mask displayed in Table 9 for HTK_Table[0] has been used. In addition, these tables assume that lookup termination information for HTK_Table[0] has only been added from HTK_Table[2].
The values of keylen in Table 16 are related to the size of the corresponding HTK table. If keylen is n, then the number of hash entries in the HTK table is 2n. The larger the value of keylen, the smaller the probability of hash collisions.
Referring back to
The HTK tables are constructed entry-by-entry. First, the entries corresponding to TableEntryA are added (see Table 11), and then the entries corresponding to TableEntryB are added (see Table 12). When TableEntryA entries are added, the values for the key entry data fields in Table 17 are obtained as follows.
Note that no key entry overwriting will occur when the TableEntryA entries are added, because each template-table combination is unique.
When TableEntryB entries are added, some of these entries may coincide with existing HTK key entries (i.e. with the same hashmasked key). Hence there are two cases to consider: (1) when a new key entry is being added; and (2) when an existing key entry is being modified.
When a new key entry is being added (case (1)), the values for the key entry data fields shown in
When an existing key entry is being modified (case (2)), the values for the key entry data fields in shown in
When rules are added to or subtracted from the ACL, the HTK tables are modified. One possible approach is to regenerate the entire sequence of HTK tables. This is somewhat time consuming. Fortunately, it is possible to formulate update procedures which use much less computational effort. These updated tables may not be quite as optimized as the tables constructed from scratch, but nonetheless afford adequate performance. Two alternative algorithms for HTK table modification are provided to accommodate ACL updates. The first algorithm is faster than the HTK table construction algorithm previously described in
The first algorithm option is quite similar to the HTK table construction described in
This HTK table modification procedure follows the outline shown in
Ineffective Rule
New Rule
Rule 7 in Table is shown in italics, because it was previously determined that Rule 7 is ineffective. The new rule has been labeled “2.5” to indicate its relative priority in relation to the other rules.
The new rule templates are computed just as in HTK table creation, as described in
If there are table collisions with existing rules in the table selected in the loop, decision 630 branches to “yes” branch 635 whereupon processing loops back to select the next table in order to check the next table for collisions. When there are no template collisions with a selected table, decision 630 branches to “no” branch 645 where the new rule is added to the table selected during the loop (step 650). Addition of a rule to a specified HTK table (step 650) proceeds as follows:
Returning to
Note that Rule 2.5 corresponds to templates {000,001,010,011} in HTK_Table[0] with hashmask 01001001. According to Table 14 and Table 15, these templates correspond to {Rule 3, Rule 1,Fail,Fail} respectively. For the two non-Fail entries, the “Valid termination” fields are {1,0}, while the “Invalid termination” fields are {1,1} (the ‘1’ values are assigned because HTK_Table.lkp_trm[0] is equal to 1, according to Table 16). However, now that new Rule 2.5 is included in HTK_Table[2], these “Valid termination” and “Invalid termination” fields are changed to {2,0} and {2,2} respectively. Furthermore, the HTK_Table.lkp_trm[0] field is changed to ‘2,’ because the Fail entries are still compatible with Rule 2.5 complicity.
The prior table adjustment when adding a new rule proceeds as follows:
As an example of this algorithm, assume that Rule 1 is removed from the HTK tables for the simple set of rules in Table 1. Rule 1 is in the included rule set of HTK_Table[0]. Therefore the associated hashmask that is used is 01001001, according to Table 13. Rule 1 is associated with a unique rule template ‘001’, which has corresponding hash key 00000001. If this entry is retrieved, the “Invalid termination” field for this entry is equal to ‘2’ which is equal to HTK_Table.lkp_trm[0]. It follows that the Key entry can be entirely removed from HTK_Table[0].
As a second example, assume that Rule 4 is removed. Rule 4 is also in the included rule set of HTK_Table[0], with unique rule template ‘111’ corresponding to hash key 01001001. If this entry is retrieved, the “Invalid termination” field for this entry is equal to ‘2’ (because of Rule 6-see Table 15). It follows that the “Rule priority” field is changed to “0×ffffff’, and otherwise the entry is left intact.
The lookup procedure is diagrammed in
In
If Key, then decision 155 branches to “yes” branch 158 whereupon a determination is made as to whether the rule was found (decision 160). Here the “Rule priority” field of the retrieved data is examined. If the value is 0×ffff, then no rule is indicated and decision 160 branches to “no” branch 156, otherwise processing continues to decision 170.
A determination is made as to whether a rule that was found is valid (decision 170). Here the “Rule key” from the retrieved data is compared with the original key masked according to the five prefix mask fields in the key data. If the “rule key” agrees with the original key masked according to the five prefix mask fields, then the rule is valid and decision 170 branches to “yes” branch 174. On the other hand, if the rule key does not agree with the original key masked according to the five prefix mask fields, then the rule is not valid and decision 170 branches to “no” branch 172.
If the rule is valid (decision 170 branching to “yes” branch 174), the rule priority (obtained from the key data) is compared with the priority of the current final rule. A determination is made as to whether the new rule's priority value is lower (indicating higher priority), than the final rule priority and action are reset to agree with the new rule (decision 175). If the new rule has a higher priority, then decision 175 branches to “yes” branch 178 whereupon this rule is set to be the last rule found (replacing a default rule or any previous rule that was last found from another HTK table).
A determination is made as to whether to terminate looking through the HTK tables (decision 185). This determination is based upon updating a termination indicator and checking whether checking can be terminated. There are three possible outcomes: (1) New rule has been validated; (2) New rule has been invalidated, or no new rule found; (3) No entry (Fail).
If the termination indicator is less than or equal to the current table indicator, then lookup is terminated and decision 185 branches to “yes” branch 192. The final step in decision 185 is to update the table indicator. This is performed by incrementing the table indicator by 1. On the other hand, if the termination indicator is greater than the current table indicator, then lookup continues and decision 185 branches to “no” branch 188 whereupon, at step 190, the predefined mask for the next rule set is selected and processing loops back to perform a lookup using the next predefined mask and rule set. This looping continues until either all rule sets have been searched or when decision 185 branches to “yes” branch 192. At step 195, the last rule that was found (i.e., the rule with the highest priority) is applied. For example, if the last rule was to “accept” the packet, then the request is accepted and if the last rule was to “deny” the packet, then the request is denied.
A loop is initialized at step 860 to loop through all of the hash tables. For each hash table, a determination is made as to whether the hash mask (recomputed in predefined process 820) has changed for the selected table (decision 870). If the hash mask has changed for the selected table, decision 870 branches to “yes” branch 875 whereupon, at step 880, the selected hash table is reconstructed using the recomputed rule template. On the other hand, if the hash mask has not changed, decision 870 branches to “no” branch 885 whereupon, at step 890, table entries are added and/or removed corresponding to the rules that have been added and/or removed for the selected table. Once all of the tables have been processed, the loop that was initialized in step 860 ends and processing ends at 890.
PCI bus 1014 provides an interface for a variety of devices that are shared by host processor(s) 1000 and Service Processor 1016 including, for example, flash memory 1018. PCI-to-ISA bridge 1035 provides bus control to handle transfers between PCI bus 1014 and ISA bus 1040, universal serial bus (USB) functionality 1045, power management functionality 1055, and can include other functional elements not shown, such as a real-time clock (RTC), DMA control, interrupt support, and system management bus support. Nonvolatile RAM 1020 is attached to ISA Bus 1040. Service Processor 1016 includes JTAG and I2C buses 1022 for communication with processor(s) 1000 during initialization steps. JTAG/I2C buses 1022 are also coupled to L2 cache 1004, Host-to-PCI bridge 1006, and main memory 1008 providing a communications path between the processor, the Service Processor, the L2 cache, the Host-to-PCI bridge, and the main memory. Service Processor 1016 also has access to system power resources for powering down information handling device 1001.
Peripheral devices and input/output (I/O) devices can be attached to various interfaces (e.g., parallel interface 1062, serial interface 1064, keyboard interface 1068, and mouse interface 1070 coupled to ISA bus 1040. Alternatively, many I/O devices can be accommodated by a super I/O controller (not shown) attached to ISA bus 1040.
In order to attach computer system 1001 to another computer system to copy files over a network, LAN card 1030 is coupled to PCI bus 1010. Similarly, to connect computer system 1001 to an ISP to connect to the Internet using a telephone line connection, modem 1075 is connected to serial port 1064 and PCI-to-ISA Bridge 1035.
While the computer system described in
While the router described in
One of the preferred implementations of the invention is a client application, namely, a set of instructions (program code) or other functional descriptive material in a code module that may, for example, be resident in the random access memory of the computer. Until required by the computer, the set of instructions may be stored in another computer memory, for example, in a hard disk drive, or in a removable memory such as an optical disk (for eventual use in a CD ROM) or floppy disk (for eventual use in a floppy disk drive), or downloaded via the Internet or other computer network. Thus, the present invention may be implemented as a computer program product for use in a computer. In addition, although the various methods described are conveniently implemented in a general purpose computer selectively activated or reconfigured by software, one of ordinary skill in the art would also recognize that such methods may be carried out in hardware, in firmware, or in more specialized apparatus constructed to perform the required method steps. Functional descriptive material is information that imparts functionality to a machine. Functional descriptive material includes, but is not limited to, computer programs, instructions, rules, facts, definitions of computable functions, objects, and data structures.
While particular embodiments of the present invention have been shown and described, it will be obvious to those skilled in the art that, based upon the teachings herein, changes and modifications may be made without departing from this invention and its broader aspects. Therefore, the appended claims are to encompass within their scope all such changes and modifications as are within the true spirit and scope of this invention. Furthermore, it is to be understood that the invention is solely defined by the appended claims. It will be understood by those with skill in the art that if a specific number of an introduced claim element is intended, such intent will be explicitly recited in the claim, and in the absence of such recitation no such limitation is present. For non-limiting example, as an aid to understanding, the following appended claims contain usage of the introductory phrases “at least one” and “one or more” to introduce claim elements. However, the use of such phrases should not be construed to imply that the introduction of a claim element by the indefinite articles “a” or “an” limits any particular claim containing such introduced claim element to inventions containing only one such element, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an;” the same holds true for the use in the claims of definite articles.
