A SCALABLE HARDWARE SOLUTION FOR PACKET CLASSIFICATION Hung-Yi Chang, Chia-Tai Chan, Pi-Chung Wang, Chun-Liang Lee Departemnt of Information Management, I-Shou University Kaohsiung, Taiwan 840, ROC. E-mail:
[email protected] ABSTRACT One of interesting hardware solutions proposed to solve the packet classification problem is bit-vector algorithm. Different from other hardware solutions such as ternary CAM, it efficiently utilizes the memories to achieve an excellent performance in medium size policy database; however, it cannot scale up with the policy number increases. In this paper, we proposed an improved bit-vector algorithm named Bit Vector Condensation which can be adapted to large policy databases. Experiments showed that our proposed algorithm drastically improves in the storage requirements and search speed as compared to the original algorithm. 1. INTRODUCTION Packet classification has been extensively employed in the Internet for secure filtering and service differentiation by administrators to reflect policies of network operations and resource allocation. Using the pre-defined policies, the packets can be assigned to a given class. However, packet classification with a potentially large number of policies is difficult and exhibits poor worst-case performance. A classifier which includes a set of policies is used to distinguish an incoming packets into multiple classes. Packet classification is performed using a packet classifier. The most common fields of a packet header are the IP source address (SA), the destination address (DA), the protocol type, the port numbers of source and destination applications, and protocol flags. A packet P is said to match a particular policy F if for all i, the ith field of the header satisfies the f [i]. In order to decide the best matching policy, each policy is usually assigned a cost to define its priority among the matched policies. The least-cost matched policy will be enacted to process the arriving packets. In this paper, we proposed the Bit Vector Condensation algorithm based on the existing Lucent Bit Vector (BV) Chia-Tai Chan and Chun-Liang Lee are now with the Telecommunication Laboratories, Chunghwa Telecom Co., Ltd, Taipei, Taiwan 106, ROC. E-mail: {ctchan, chlilee}@cht.com.tw). Pi-Chung Wang is now with the Institute of Computer Science and Information Technology, National Taichung Institute of Technology, Taichung, Taiwan 404, ROC. E-mail:
[email protected]).
scheme. The required storage space is far less than that of the bit vector scheme. The rest of this paper is organized as follows. Section 2 introduces some related works on packet classification and describes the basic ideas of Lucent BV and Aggregate Bit Vector (ABV) in details. Section 3 describes the main idea of Condensate Bit Vector (CBV) and how to apply the aggregation concept to construct the CABV. Section 4 presents the storage and speed comparisons of Lucent BV, ABV, CBV and CABV. Finally, Section 5 concludes the work. 2. RELATED WORK For the past few years, researchers got more interested in the packet classification problem and had proposed several algorithms to solve the issue [1]. The related studies could be mainly categorized into two classes: software-based and hardware-based. Several software-based schemes have been proposed in the literature such as linear search/caching, grid of tries/cross-producting, recursive-flow classification and hierarchical intelligent cuttings solutions [2–5]. The softwarebased solutions do not scale well in one of time or storage, thus we focus on the hardware-based solutions. In [6], Lakshman and Stiliadis proposed a bit parallelism scheme. They project every policy onto each dimension and use a bit vector to maintain the position information in policy database. By constructing k one-dimensional tries, each prefix node in every one-dimensional trie is associated with a bit vector (BV). The length of BV is equal to the number of policies in the policy database. Each bit position maps to a corresponding policy in the database. The policy database is assumed to be sorted by a descendent order of priority. They perform an AND operation on the all matched BV and find the first matched result as the best matching policy. Since the length of BV would increase proportional to the number of policies in the database, the Lucent BV scheme is only suitable for the medium size policy database. Baboescu et al. [7] proposed a bit-vector aggregation method to enhance the original BV scheme that is based on the following observations: 1) The distribution in the bit vectors are always sparse. 2) A packet usually matches
542 c 2004 IEEE 0-7803-8549-7/04/$20.00
ICCS 2004 Source Prefixes 000* P0 P1 0* P2 1* P3 01*
P4 P5 P6 P7
Table 1. Two-dimensional policy database with 16 rules.
111* 10* 011* *
0000000000000001
P7
0001
0010000000000011
0100010000000001 1101
P1
P2
0101010000000001
1001
0010001100000011
P3
1101
P5
1101 0010100000000011
1100011000101001 0101010001010101 1111
P0
P6
P4
1111
1101
(a) Source trie
Destination Prefixes P5 11* P0 P1 P6 0000* P2 P7 1111* P3 P8 010* P4 P9 00*
0000000010010000 0010
0111
P4
0010
1000000000000000
P7
P0
P3
P5
P1
Source Prefix 000* 0* 1* 01* 111* 0* 000* 10*
Dest. Prefix 11* 0000* 1111* 010* 00* 110* 1111* 1110*
Policies F8 F9 F10 F11 F12 F13 F14 F15
Source Prefix 10* 011* 000* 011* 000* 011* 1* *
Dest. Prefix 110* 10* 0110* 0* 010* 010* 00* 00*
shows the matched policy is F12 . With the ABV scheme, an AND operation on the ABVs “1111” and “1011” yields result “1011”. It indicates that the second 4-bit segment will not contain any set bits and could be ignored.
1000
3. CONDENSATE BIT VECTOR (CBV)
1100 1010010000000000
0100100010000011 1111
Policies F0 F1 F2 F3 F4 F5 F6 F7
1000010000000000
0001000010011100 1011
110* 1110* 10* 0110* 0*
P9
0000000001000000
0000100010010011
543
1000010000000011
P8
1100
P6
P2
1100
0000000010110000 0010
(b) Destination trie
Fig. 1. Bit vectors constructed by BV and ABV scheme. few policies in the policy database. By adding a new bitvector, Aggregate Bit Vector (ABV), the number of memory accesses is decreased significantly. The length of ABV is defined as N/A , where A is the aggregate size of ABV. By reducing the frequency of memory accesses, ABV scheme improves the Lucent BV scheme significantly. We use a simple two-dimensional policy (source prefix, destination prefix) database with 16 rules, shown in Table 1, to illustrate the constructed bit vectors of the BV and ABV scheme. There are 8 unique prefix nodes in the source trie and 10 unique prefix nodes in the destination trie, depicted as the shady nodes in Fig. 1. Each prefix node in both tries is labelled with two bit vectors, BV (16 bits) and ABV (4 bits). As describe earlier, the length of BV is equal to the number of policies in the database and the length of ABV could be altered by the aggregate size (4). For an incoming address pair (00001010, 01001100), Lucent BV scheme uses the SA 00001010 to walk through the source trie, it stops at P1 and receives the BV value “1100011000101001”. Similarly, it stops at P4 and gets a BV value “0001000010011100” by using the DA to walk through the destination trie. Finally, Lucent BV scheme performs an AND operation on these two BVs and obtains a result of “0000000000001000” that
In bit vector algorithm proposed in [6], the hardware solution achieves good performance for the medium size databases, but suffers from a performance degradation with the increase of policy number. Consequently, we propose an efficient method to improve the performance of Lucent BV scheme in both speed and storage. The new scheme is inspired by two observations. The first one is that the number of BVs is equal to the number of different prefixes for each dimension, which is pertinent to storage. The second observation is that the length of BVs is equal to the number of policies, which directly influences both speed and storage performance of the bit vector algorithm. Our proposed scheme consists of three parts: 1) subtrie root selection, 2) condensed policy database construction and 3) CBV construction. In the first part, the original prefixes extracted from the policies are used to construct the binary trie. For each dimensional trie, the following algorithm is executed to mark the subtrie root according to the pre-defined threshold “Indluced Prefix Num”. By traversing the original trie with depth first order, Subtrie Root Selection Algorithm checks whether the number of prefixes under the current node is equal to the threshold or not. If so, a subtrie root is marked. Otherwise, its left and right child nodes will be traversed recursively. The detailed algorithm is Fig. 2. We assume that the number of clustered prefixes (Included Prefix Num) is 2. After performing the proposed algorithm to the trie in Fig. 1, the constructed subtrie roots are shown in Fig. 3. Each dark-gray circle represents the position of the subtrie root. Next, the original prefixes in the policy are replaced by the bit-streams corresponding to the nearest ascending
544
ICCS 2004
Input: The root of the trie in each dimension Output: A new trie with CBV Subtrie Constructor(Node, Dimension) BEGIN IF (ChildWithPrefix(Node)==Included Prefix Num ) GenerateSubtrieRoot(Node, Dimension); ELSE Subtrie Constructor(Node→Left Child,Dimension); Subtrie Constructor(Node→Right Child,Dimension); IF (ChildWithPrefix(Node)>=Included Prefix Num) MarkSubtrieRoot(Node, Dimension); ELSE IF (Node == Trie Root && ChildWithPrefix(Node)!=Included Prefix Num) MarkSubtrieRoot(Node, Dimension); END
Fig. 2. Subtrie Root Selection Algorithm
Condensed Source Prefixes 01* P' 0 P' 1 0* P' 2 1* P7 P' 3 * 1100010011 111
Policies F0 F1 F2 F3 F4 F5 F6 F7 F8 F9
Second Dimension 11* 00* 111* 01* 00* 111* 11* * 01* 00*
Policies Included F0 , F 5 F1 F2 , F 7 F3 , F13 F4 , F14 F6 F8 F9 , F11 F10 , F12 F15
001
P1
1101000111 111
P2 P3
P0
0010101001 111
P5 P6
P4
(a) Source trie
Condensed Destination Prefixes 00* P' 0 0000001100 P' 1 01* P' 2 111* 010 P' 3 11* P' 4 *
P9
Table 2. New Policy Database. First Dimension 0* 0* 1* 01* 1* 0* 1* 01* 0* *
0000000001
0001001100
0100101101 111
110
P4
1000000100
P7
P0
101
1010010100
P3 P1
P5 P8
111
P6
P2
(b) Destination trie
Fig. 3. Bit Vector Condensation. one, CABV would be more condensate than the ABV.
subtrie roots. For example, F0 (000∗, 11∗) in Table 1 is changed to (0∗, 11∗), and F6 (000∗, 1111∗) is changed to (0∗, 111∗). Some new policies might be redundant, e.g. the new policies generated by F0 and F5 . These policies should be merged, and the indices of the original policies are appended to the new policy. Table 2 presents the new policy database. Once a matching policy in the new database is derived, we must examine the appended policies to derive the exact result. To carry out the task, linear search can be used because only few appended policies are present. The CBV construction is based on the new policies. Since the number of policies in the new database is reduced, the required bits in each bit vector is less than that in the Lucent BV. Furthermore, the number of different prefixes in each dimension is reduced, which, in turn, generated fewer vectors. An example transforming a 16-bit BV into a new 10-bit BV is shown in Fig. 3 as derived from the example in Fig. 1. In Fig. 3, we also present the condensate bit vector with aggregation and call it Condensate and Aggregate Bit Vector (CABV). We use the aggregate size of 4 in these cases. The construction of CABV follows the same procedure as that of ABV. Since our CBV scheme condenses several bits into
4. PERFORMANCE EVALUATION In this section, we use software simulation to evaluate the CBV scheme and compare it with both Lucent BV scheme and ABV scheme. Two different types of databases are evaluated in our simulation. First, we use 22 collected databases in 11 backbone routers of Abilene Network as real world classifiers. These databases contain at most 13K policies. The size of our synthetic databases varies from 10K to 100K. Assume that the memory word size and the aggregate size of ABV are both 32 bits, identical to the settings used in [7]. Two performance metrics are measured in our experiments: the storage requirement and the memory accesses. The required storage mainly ties to the number of bit vectors and their length. The speed of each packet classification is measured in terms of the number of memory accesses. The number of clustered prefixes are set to 2, 4, 8 and 16 in order to evaluate the effect of condensation. Since the number of clustered prefixes does not affect the Lucent BV and ABV schemes, their storage requirement and speed will remain constant. The storage of various classifiers are evaluated and the
ICCS 2004 4,500
4,500 Lucent BV scheme CBV scheme ABV scheme CABV scheme
3,500
Lucent BV scheme CBV scheme ABV scheme CABV scheme
4,000 Required Storage (Kbytes)
Required Storage (Kbytes)
4,000
3,000 2,500 2,000 1,500
3,500 3,000 2,500 2,000 1,500
1,000
1,000
500
500
0
0 0
2,000
4,000
6,000
8,000
10,000
12,000
14,000
0
2,000
4,000
Number of Policies
6,000
8,000
10,000
12,000
14,000
12,000
14,000
Number of Policies
(a) Clustered prefixes = 2
(b) Clustered prefixes = 4
4,500
4,500 Lucent BV scheme CBV scheme ABV scheme CABV scheme
3,500
Lucent BV scheme CBV scheme ABV scheme CABV scheme
4,000 Required Storage (Kbytes)
4,000 Required Storage (Kbytes)
545
3,000 2,500 2,000 1,500
3,500 3,000 2,500 2,000 1,500
1,000
1,000
500
500
0
0 0
2,000
4,000
6,000
8,000
10,000
12,000
14,000
Number of Policies
(c) Clustered prefixes = 8
0
2,000
4,000
6,000
8,000
10,000
Number of Policies
(d) Clustered prefixes = 16
Fig. 4. Storage requirements for real classifiers (lower is better). results are organized in Fig. 4. In Fig. 4(a), our CBV and CABV schemes do not improve the existing schemes when the size of classifiers is under 1,000 policies. This is because the effect of prefix clustering is not obvious for small classifier. Also, the overhead incurred by our schemes is larger than the original Lucent BV and ABV schemes. As the size of classifiers gets larger than 3,698, our schemes can achieve an improvement up to 50% as compared to both the Lucent BV and ABV schemes. If we enlarge the number of clustered prefixes to four, only 25% storage is required, as shown in Fig. 4(b). Figure 4(c) shows that it could achieve the same improvement level while the size of classifiers is larger than 2,348. Thus the proposed CBV and CABV schemes are scalable for large classifier. The results of worst-case memory accesses for the classifiers are demonstrated in Fig. 5. In the CBV-based schemes, the number of the worst-case memory accesses is equal to the summation of memory accesses for bit vectors and linear search. We assume that fetching one policy in the classifier takes one memory access. Figure 5(a) shows that CBV scheme features much better performance than the Lucent BV scheme while the CABV scheme behaves quite similar to the ABV scheme. When the number of clustered prefixes is enlarged, as shown in Fig. 5(b), the CBV scheme requires
only half memory accesses in Lucent BV to accomplish one packet classification. The performance of CABV is unstable as compared with ABV. In some cases, the CABV is even worse than CBV. This is because the false match caused by bit aggregation would decline the worst-case performance. In Fig. 5(c), the curve of CBV scheme is getting close to that of the ABV scheme since there is a great effect on the prefix clustering. If the classifier is large enough, the CABV will provide best performance in all schemes. In Fig. 5(d), we notice that the speed of CBV scheme and CABV scheme is almost the same in all classifiers. Since as the number of clustered prefixes increases, the number of policies processing in the linear-search phase would dominate the worstcase performance. Also in Fig. 5(d), as the number of clustered prefixes gets less than 2,202, our schemes would have a poorer performance than the ABV scheme since the prefix clustering could not take effect. In addition, the increasing number of policies in the linear-search phase would lead to degradation in the speed performance. We could avoid this by carefully selecting the parameter in the clustering number according to the characteristics of each classifier.
546
ICCS 2004 900
900 Lucent BV scheme CBV scheme ABV scheme CABV scheme
700
Lucent BV scheme CBV scheme ABV scheme CABV scheme
800 Number of Memory Accesses
Number of Memory Accesses
800
600 500 400 300 200 100
700 600 500 400 300 200 100
0
0 0
2,000
4,000
6,000
8,000
10,000
12,000
14,000
0
2,000
4,000
Number of Policies
8,000
10,000
12,000
14,000
12,000
14,000
Number of Policies
(a) Clustered prefixes = 2
(b) Clustered prefixes = 4
900
900 Lucent BV scheme CBV scheme ABV scheme CABV scheme
700
Lucent BV scheme CBV scheme ABV scheme CABV scheme
800 Number of Memory Accesses
800 Number of Memory Accesses
6,000
600 500 400 300 200 100
700 600 500 400 300 200 100
0
0 0
2,000
4,000
6,000
8,000
10,000
12,000
14,000
Number of Policies
(c) Clustered prefixes = 8
0
2,000
4,000
6,000
8,000
10,000
Number of Policies
(d) Clustered prefixes = 16
Fig. 5. Worst case memory accesses in real classifiers (lower is better). 5. CONCLUSIONS
March/April 2001, pp. 24–32.
In this work, we proposed the Condensate Bit Vector with linear search to improve the classification performance and decrease the required storage. The main idea of CBV is that the bit vector can inherit from their ancestors and utilize trie structure to condense several vectors into one. We also proposed Condensate and Aggregate Bit Vector which incorporates the bit aggregation into the CBV to decrease the number of memory accesses for large classifiers. In our experiments, the CBV scheme only needs less than 2 Mbytes for the synthetic database with 100K policies while the Lucent BV and ABV need near 50 Mbytes. Clearly, CBV-based scheme could fit the searchable structures into the fast SRAM and enable the BV-based schemes to support large classifiers. The experimental results also show that the CBV-based schemes feature similar speed performance as the ABV scheme and much faster than the Lucent BV scheme while the CBV-based schemes require less storage.
[2] V. Srinivasan and et al., “Fast and scalable level four switching,” in ACM SIGCOMM ’98, September 1998.
6. REFERENCES
[7] Florin Baboescu and George Varghese, “Scalable packet classification,” in ACM SIGCOMM ’01, August 2001, pp. 199–210.
[1] Pankaj Gupta and Nick Mckneown, “Algorithms for packet classification,” in IEEE Network Magazine,
[3] P. Gupta and N. McKeown, “Packet classification on multiple fields,” in ACM SIGCOMM ’99, September 1999. [4] P. Gupta and N. McKeown, “Packet classification using hierarchical intelligent cuttings,” in ACM SIGCOMM ’99, September 1999. [5] Thomas Y. C. Woo, “A modular approach to packet classification: Algorithms and results,” in INFOCOM (3), 2000, pp. 1213–1222. [6] T.V. Lakshman and D. Stiliadis, “High-speed policy-based packet forwarding using efficient multidemensional range matching,” in ACM SIGCOMM ’98, September 1998, pp. 203–214.
