To provide pipeline and parallel processes for multi-TCAM systems, the trace-back and mis-match problems must be removed. Previous article [20] has proposed that if two rules contain any overlap region, then these two rules are ambiguous and may cause trace-back problem in multi-TCAM systems. By this definition, (R5, R6) and (R3, R4) in Figure 8 are ambiguous rules. However, since all entries in each TCAM are sorted by prefix length, R5 and R6 can be distinguished by prefix length. On the other hand, although R1 and R2 are disjoined in Figure 8, the source fields of these two rules are overlapped. R1
and R2 are ambiguous when lookup the source field first. Hence, our research presents two ambiguous cases that cause trace-back and mis-match problems in multi-TCAM systems.
Finally, our research shows the solutions of detecting and solving these cases in the rest of this session.
4.1. Ambiguous Cases in Multi-TCAM Environments
All entries are represented as prefixes in TCAM (ranges can also be translated to prefixes), so the relation between the same field of two rules can be classified as subset, super-set, or disjoin. To clarify, let and be the i-th field of rules A and B, respectively. Then ⊂ to denote that is a subset of , and ⊗ to denote that and are disjoined. The ambiguous cases in multi-TCAM systems are defined as follows, and for simplification, our research takes two five-bit fields for example:
i
Case I: Overlapping Rules
In the first case, rules A and B are overlapped if there exists ⊂ and ⊂ , where i ≠ j. Take Figure 8 as an example again and assume the priority of R3 is higher than that of R4. In single-TCAM environment, this is a simple case and what we should do is to put R3 on a higher position than R4 in the rule table. Nevertheless, in multi-TCAM environment, each field (a TCAM) should be sorted by prefix length. Taking two conflicting rules, (10***, *****) and (*****, 101**), for instance, these rules are overlapped in the area (10***, 101**).
i
RA RBi RBj RAj
Case II: Hidden Overlapped Rules
The second case is that rules A and B are hidden overlapped if there exists some field ⊂ and for other fields ⊗ , where i ≠ j. For instance, the rules R1 and R2 in Figure 8 are hidden overlapped. As for the source field, R2 is a subset of R1. But for the destination field, they are disjoined in Figure 8. Actually, for single-TCAM systems, R1
and R2 are completely disjoined. However, in the multi-TCAM systems, each field is stored in one TCAM and the packet classification algorithm compares one field each step. In this
i
RA RBi RAj RBj
case, it is possible that while searching the source field in the first TCAM, and a wrong rule may be selected according to the longest prefix match algorithm. As a result, the packet classifiers should trace-back and retry several times. This trace-back scheme is undesirable since it would take various delays to select the best rule. The proposed method is to insert a new rule into the rule table to resolve this ambiguous problem and obtain constant-time lookup.
Take R1=(10***,11***) and R2=(101**,10***) for example, R1 and R2 cause a hidden overlapped case in a two-TCAM system. When a packet with (source, destination) = (10110, 11100) comes in, and the classifier takes the source field as the search key. The classifier selects R2 with the longest prefix matching. However, when destination field (another TCAM) fails in searching, another entry in source field should be search again.
4.2. Detecting and Resolving Conflict rules
According to above mention, there are two kinds of conflicts (overlapped and hidden overlapped) among the rules in the multi-TCAM systems. This section proposes the ways to detect and resolve these ambiguous cases.
Solution for Case I:
In the first case, two rules A and B are ambiguous, if there exists ⊂ and
⊂ , where i ≠ j. The longest prefix match algorithm is unable to select the correct rule merely according to the prefix length.
i
RA RiB
j
RB RAj
The detecting procedure first distinguishes if all fields of two rules A and B are disjoined. Disjoin rules are undoubtedly not conflicted. If rule A and B are not disjoined but A is a subset of B or B is a subset of A, then A and B can be distinguished successfully by prefix length. The rest of the detecting procedure checks the subset relation of all fields of rule A and B.
The solution for this conflict case is to add a new rule C, in which each field of C is the longer prefix of rules A and B. This resolving algorithm should be recursively executed.
After adjusting, the packets belongs to overlapping area will match rule C by LPM.
Solution for Case II:
Two rules A and B have ambiguous case 2, if there exists some field ⊂ and for other fields ⊗ , where i ≠ j. The detecting procedure first distinguishes if two rules A and B are hidden overlapped. If rule A and B are hidden overlapped as for the source field, Bis a subset of A, but for the destination field, they are disjoined. The detecting procedure of hidden overlapped rules only exists in the multi-TCAM systems as each field is stored
i
RA RBi
j
RA RBj
in one TCAM and the packet classification algorithm compares one field at each step.
Similar to case I, the solution for this conflict is to add a new rule C in the rule table.
The source field of rule C is the longer prefix length of the source field of rules A and B;
however, the destination field is referred to the shorter prefix length destination field of rule A and B. After inserting rule C, the packet will match this new rule. Though this scheme inserts additional rules, it keeps the advantage of constant searching time for all cases.
4.3. Lookup Operations Without Ambiguous Cases
After detecting and resolving the ambiguous cases, the pipeline and parallel multi-TCAM system will not encounter trace-back and mis-match problems. In other words, the proposed multi-TCAM classification engine can take advantage of the benefits of pipeline and parallel architecture and enhance the lookup speed. The following contents give two examples for pipeline and parallel architectures individually.
To simplify the demonstration, we utilize two fields to show the lookup operations and point out the difference between original and modified policy tables. Figure 9 shows the first example for pipeline architecture. There are two rules that R1(140.114.78.*,140.114.*.*) and R2(140.114.*.*,140.114.79.*) in the policy table, and R1 has higher priority than R2. For incoming packet (140.114.78.59,140.114.79.80), TCAM-1 selects longest prefix rules and outputs T1 Then, combine T1 and second key (140.114.79.80) will not match in TCAM-2 without handling ambiguous rules. In this case, the trace-back problem occurs and classifier cannot get the correct result. To avoid trace-back problem, new rule-R3 detecting form ambiguous cases is created and inserted into policy table. The lookup procedure is as the following. First lookup in TCAM-1 also get the result (T1). Then, TCAM-2 outputs the correct result (A1) after eliminating ambiguous cases. In addition, the number of rule does not increase in TCAM-1 since the same data entries can be compacted with the same tag. Consequently, the pipeline architecture can be executed smoothly without the trace back problems.
For the parallel scenario shown in Figure 10, the policy rules are divided into two parts and store in TCAM-1 and TCAM-2. BCAM is a hash table and stores hash keys for policy rules. Classification engine inputs the searching keys into TCAMs concurrently and output the associated index. By combining the outputs from TCAM as a hash key, BCAM can lookup and output the correct result.
Originally, TCAM-1 and TCAM-2 output associated indexes (X1 and Y2) respectively. However, inputting the combination of X1 and Y2 will not match in the BCAM hashing. After the modification, only BCAM inserts a new hashing entry and
TCAMs make no change. Although TCAMs still output X1 and Y2, BCAM can extract the correct result after removing the mis-match problem.
Original Policy Table
Figure 9. Lookup operations of the pipeline architecture.
140.114.78.*
Figure 10. Lookup operations of the parallel architecture.