22nd International Conference on Advanced Information Networking and Applications - Workshops
Ternary CAM Compaction For IP Address Lookup Yi-Ting Fang, Tzung-Chian Huang, Pi-Chung Wang Department of Computer Science National Chung Hsing University, Taichung, Taiwan phd9509, s9456026,
[email protected]
Abstract
SRAMs, and ternary-CAMs is even more expensive, the cost is about 8 to 10 times then SRAMs.
Motivated by the high cost problem of ternary CAM, we proposed a new technique for providing a compaction routing table. With the comparisons with existing algorithms, our new technique can improve the use of ternary-CAM space under reasonable compressing time, performs well without consider the size of routing table size. And our scheme outperforms other existing schemes in terms of the use of the ternary-CAM space and the processing time.
1
4. Ternary-CAMs have long update time. Entries in the ternary-CAM routing table require sorting based on prefix lengths. This lead to that each addition requires the complexity of O(N), where the N is the total number of prefixes to be stored in the routing table [6].
Several researchers have explored the pros and cons of a ternary-CAM based route lookup approach in the past few years. Pei and Zokowski [5] proposed the basic ternaryCAM approach for the longest prefix matching problem. McAuley and Francis [4] described a multiple-cycle singlelogic CAM lookup algorithm which is what we refer to as a conventional ternary-CAM approach. One of the important issues concerns fast updating in ternary-CAM. As the entries in ternary-CAM need to be stored in decreasing order of prefix lengths, the addition of prefix may require a large number of entries to be shifted. Shah and Gupta [6] proposed two algorithms to reduce the ternary-CAM update time. Their PLO OPT algorithm reduces the update time by a factor of two over earlier solutions. Their CAO OPT algorithm offers an average of 1.02 to 1.06 memory accesses each update. Liu [3] offers two techniques to reduce the ternary-CAM table size in order to optimize ternary-CAM utility. The first technique, pruning, identifies the redundant prefixes and remove them. The second technique, mask extension, combines prefixes by using mask bits arbitrarily. This two techniques claim that the resultant compaction ratio can be achieved up to 45 percent.
Introduction
Many commercial router designers have chosen to use ternary-CAM (Content Addressable Memory) for IP routing lookup in order to keep pace with high speed requirement despite their power consumption, large size, cost and long update time relative to SRAM (Static Random Access Memory). Among the existing hardware approaches, ternary-CAMs are presently dominant devices since longest prefix matching is required to implement the most recent IP routing lookup problem standard. In spite of the success in using ternary-CAMs, some problems are usually found to be associated with ternary-CAM routing tables: 1. All conventional implementations of ternary-CAMs have high power consumption because for every lookup operation all memory cells must be active. As a result, the power consumption of ternary-CAMs is about two to three times more than SRAMs.
2 Routing Table Merging Algorithm
2. An important limiting factor is the priority encoder at the ternary-CAMs’ output stage. With the size of routing table rapidly growing up, the size of ternary-CAMs is still bounded by the priority encoder.
2.1
Our idea comes from the observation on the routing tables. First, we know that there are typically many routing entries — in the range of several thousands in the routing
3. Another issue being focused is the cost of ternaryCAMs. Commercially available CAMs cost much than
978-0-7695-3096-3/08 $25.00 © 2008 IEEE DOI 10.1109/WAINA.2008.168
Background and Definition
1462
table. In contrast, the possible next-hops are limited by the outgoing interface ports of a router (Table 1, 2). Second, the adjacent entries in the routing table have trend to lead the lookup to the same next-hop, due to the IP address dispatch strategy. Based on the observation, we offer a new technique to reduce the entries of forwarding table stored in ternary-CAMs. The main characteristic notations of a routing table given above, in this section we have the following definitions to classify the relationship between the entries in the routing table: (P = {p1 , p2 , . . . pn } is a set of prefixes, Q = {q1 , q2 , . . . qx }, is the set of x ports of the router. )
Table 1. Statistics of outgoing interface ports of BGP Reports routers. AS1221 AS4637 AS6447 # of nexthop 283 2 40 # of prefixes 288961 210849 29353
Table 2. Statistics of outgoing interface ports of APNIC routers. 2006 Feb. 2006 Apr. 2006 Jun. # of nexthop 41 41 40 # of prefixes 182795 187247 190610 2006 Aug. 2006 Oct. 2006 Dec. # of nexthop 37 39 39 # of prefixes 194513 201287 204697
• Enclosure: An entry is enclosure, if there is at least one pair in P (length(pi ) 6= length(qj ) and length(pi ) < length(pj )) is a prefix for pi . • Disjoint: Two entries in routing table are disjoint, if none of them is a prefix of the other.
2.2
Basic Scheme
(NHA) as in [6], It ensures that every address range in the collection of routing table is covered by exactly one entry. Hence a search of address falls in an address range would result in a unique lookup. As the defined above, none of the two entries is a prefix of the other in the disjoint NHA. With this property, each lookup in the disjoint NHA requires only O(1) time. After the preprocessing step, all entries in the routing table will be disjoint with each other and listed by the order as their cover address on the IP address line. As we have mentioned before, adjacent prefixes have the trend that leads the search to the same the next-hop. The main step is to merge these multiple routing entries into one representative entry or range. So we read each entry in sequence and check if the next entry can be merged with the current processing one. If they can not be merged to one representive prefix or range, this process will restart for the next entry, else we merge these two entries and continue processing on this newly merged entry. The process required only one scan thoughtout the routing table, so it can be done in acceptable time. However, a significant compression ratio may result. The pseudocode
We take the routing table as a collection of ranges lie on the IP address line, and each entry covers a range on the line. It is possible that the address range corresponding to one routing table entry covers some other routing table entry. Corresponding to the definitions above, the former entry is an enclosure of the latter entry. If the latter entry leads the lookup to the same next-hop of the former with longer length, it is called a redundant entry. Take two entries and as an example, if qi equals to qj , and length(pj ) > length(pi ), pj is a redundant prefix in the routing table. This kind of entries is common in the routing table (Table 3, 4). In the preprocessing step, We can cull away this entries to reduce a small percentage of the forwarding table size. Moreover, If the latter entry leads the lookup to different next-hop of the former, for example qi not equals to qj , and length(pj ) 6= length(pi ). We cannot cull away the latter entry, but in stead to transfer these two entries to other representative prefixes without losing any routing information, as shown in Table 5. Next, by calculating the routing table, we can find the next-hop that covers maximal address space in the interval that is covered by the routing table. It is set as the default outgoing port that needs only on entry to represent. For fast speed lookups, the most straightforward way to implement a lookup scheme is to spread each address on the IP address line in same number of entries (232 ) [5]. This design needs only one memory access for each searching, but the required size is huge. Based on this idea, we only spread the addresses in the interval that are covered by the routing table, but keep an adequate size of forwarding table. For this purpose, we construct a disjoint next-hop array
Table 3. Redundant prefixes in routing table of BGP Reports. AS1221 AS4637 AS6447 # of redundancies 6950 6323 1294 # of prefixes 288961 210849 29353 percentage 2.4% 3.0% 4.4%
1463
14. Table 4. Redundant prefixes in routing table of APNIC. 2006 Feb. 2006 Apr. 2006 Jun. # of redundancies 6167 5789 6750 # of prefixes 182795 187247 190610 percentage 3.4% 3.1% 3.5% 2006 Aug. 2006 Oct. 2006 Dec. # of redundancies 6321 6470 6559 # of prefixes 194513 201287 204697 percentage 3.2% 3.2% 3.2%
15. for each r ∈ R 16.
• (Line 3) removes the redundant prefixes from the routing table S, and return a new routing table S’ without any redundant prefixes inside. • (Line 4) finds out the maximal coverage of the nexthop and set it as the default outgoing port. • (Line 5) applies the disjoint NHA process in [2], and returns a disjoint set Sd0 of prefixes.
20.138.0.22/16 (1300)
• (Line 7 14) merges adjacent prefixes in Sd0 if possible.
20.138.0.0/16 (1300) 12.15.168.0/24 (1296)
• (Line 15, 16) transfers the output result of the previous step to entries that can be stored in ternary-CAMs.
12.15.168.0/23 (1296)
12.15.168.0/23 (1296) 12.15.169.0/24 (1296)
2.3
1. Input: A routing table S sorted based on the position on the IP address line 2. Output: A set R of routing table entries 0
3. S ← RedundantRemove(S) 0
4. Sm ← FindMaxCovergaePort(S ) 0
3 Experimental and Comparison with Existing Scheme
5. Sd ← disjointNHA(S ) 6. R ← NIL
To evaluate the performance of our proposed scheme and compare it with the existing algorithm based on the hardware [3]. Under the same routing tables, the evaluation is based on the storage requirement and processing time of the algorithms. The measurement was performed on a personal computer with Inter Pentium D dual processor 2.8 GHz running Windows XP sp2. These programs are written in C and have been compiled with the Dev-C++ 4.9.9.2 based on GNU C-compiler gcc 3.4.2. Table 6 and Table 7 show the compressed ratio of our one-phase algorithm and the processing time is provided in Table 12 and Table 13. The data shows that our approach
0
7. for each prefix p ∈ Sd − Sm 8. 9.
do new r ∈ R r←p 0
10.
p ← next prefix in S
11.
while nexthop(p ) = nexthop(p)
12. 13.
Two phase scheme
In previous, we presented a new approach that reduces the routing table to half of the original size. The technique can be done with a short, acceptable processing time. Moreover, ternary-CAMs allow the use of arbitrary mask, so that the bits of ones or zeros need not to be continuous. Hence, for achieving a higher compressing ratio, the logic minimization technique in [3] can be employed after the process of our technique to achieve higher compression ratio. So, we extend the mask of output compact data produced by the basic scheme. It can be used as the input of the logic minimization process. The results of employing Espresso-II as the two phase scheme will be presented in the next section.
includes all processes is shown in below.
0
do RangeToPrefix(r)
The description of merging algorithm :
Table 5. The transformation of enclosure. Enclosure prefixes Result prefix 20.138.0.0/22 (1300)
0
p ← next prefix in S
0
0
do p ← merge(p, p ) 0
delete p
1464
Table 6. The compression ratio of one-phase HA on BGP Report routing tables. Routing Original Size after Compressed Table size merge Ratio AS1221 288961 146971 50.8% AS4637 210849 78529 37.2% AS6447 29353 780 2.6%
Table 7. The compression ratio of one-phase HA on APNIC routing tables. Routing Original Size after Compressed Table size merge Ratio 2006 Feb. 182795 90751 49.6% 2006 Apr. 187247 90744 48.4% 2006 Jun. 190610 51391 26.9% 2006 Aug. 194513 69706 35.8% 2006 Oct. 201287 101080 50.2% 2006 Dec. 204697 100222 48.9%
Figure 1. The histogram of processing time.
can effectively reduce half size of the storage in almost all the routing tables. And the processing time is relatively short. Table 8 and Table 9 show the compressing ratio of our two-phase algorithm.The compressing ratio is shrunk to one fourth of the original size. For comparison, the compressing ratio of RC (a shorter notation for the scheme is provided in [3]) is provided in Table 10 and Table 11. For each table, the two-phase algorithm can reduce 75 to 85 percentage of ternary-CAM space, as the reduced percentage of RC is 60 to 70. The data shown in Table 12 and Table 13 also proves that our two-phase algorithm can perform well within reasonable processing time. Thus, this approach can be considered to be more efficient when dealing with the large tables.
Table 8. The compression ratio of two-phase on BGP Report routing tables. Routing Original Size after Compressed Table size merge Ratio AS1221 288961 146971 24.2% AS4637 210849 78529 9.6% AS6447 29353 780 1.8%
Figure 2. The histogram of compression ratio.
Figure 1 and Figure 2 illustrate the comparison among
1465
Table 14. Performance Evaluation Routing table
Size
HAP-1(ratio)
HAP-2(ratio)
RC(ratio)
HAP-1(time)
HAP-2(time)
RC(time)
AS1221
288961
50.8%
24.2%
40.3%
54m37s
3m57s
1h 45m 41s
AS4637
210849
37.2%
9.6%
23.6%
49m24s
45m8s
6h6m 31s
AS6447
29353
2.6%
1.8%
7.9%
46s
1s
36s
APNIC 06’ Feb.
182795
49.6%
15.4%
29.0%
39m 54s
9m 24s
3h 6m 41s
APNIC 06’ Apr.
187247
48.4%
22.9%
33.7%
36m 57s
36m 12s
3h 56m 40s
APNIC 06’ Jun.
190610
26.9%
13.4%
26.7%
46m 29s
6m 52s
4h 14m 29s
APNIC 06’ Aug.
194513
35.8%
16.9%
34.0%
44m 9s
11m 35s
3h 42m 30s
APNIC 06’ Oct.
201287
50.2%
22.8%
32.5%
41m 2s
36m 10s
4h 10m 52s
APNIC 06’ Dec.
204697
48.9%
22.5%
32.6%
42m 28s
35m 56s
3h 58m 59s
Table 9. The compression ratio of two-phase on APNIC routing tables. Routing Original Size after Compressed Table size merge Ratio 2006 Feb. 182795 90751 15.4% 2006 Apr. 187247 90744 22.9% 2006 Jun. 190610 51391 13.4% 2006 Aug. 194513 69706 16.9% 2006 Oct. 201287 101080 22.8% 2006 Dec. 204697 100222 22.5%
Table 11. The compression ratio of RC on APNIC routing tables. Routing Original Size after Compressed Table size merge Ratio 2006 Feb. 182795 90751 29.0% 2006 Apr. 187247 90744 33.7% 2006 Jun. 190610 51391 26.7% 2006 Aug. 194513 69706 34.0% 2006 Oct. 201287 101080 32.5% 2006 Dec. 204697 100222 32.6%
Table 10. The compression ratio of RC on BGP Report routing tables. Routing Original Size after Compressed Table size merge Ratio AS1221 288961 146971 40.3% AS4637 210849 78529 23.6% AS6447 29353 780 7.9%
Table 12. The processing time of RC and HA on BGP Report routing tables. Routing Table AS1221 AS4637 AS6447
different approaches in terms of compressing ratio and processing time. In Figure 1, the numbers 1 to 3 on the X-axis represents the processing time of each routing table from BGP, numbers 4 to 9 represents the processing time of each routing table from APNIC report. A similar arrangement are also used to illustrate the compressing ratio in Figure 2.
RC 1h 45m 41s 6h 6m 31s 36s
HA phase-1 54m 37s 49m 24s 46s
HA phase-2 3m 57s 45m 8s 1s
2007 and APNIC [7] in 2006 for comparison. All the compressing ratios and the processing times of these algorithms is provided in table 14. First two columns shows the character of routing tables, next three columns is the comparison on compressing ratios between schemes, and the last three columns gives the processing time of each scheme. These data shows that our approach can effectively reduce half (phase-1) to one fourth (phase-2) of the original size of
We use real data available from the BGP Reports [8] in
1466
Table 13. The processing time of RC and HA on APNIC routing tables. Routing Table RC HA phase-1 HA phase-2 2006 Feb. 3h 6m 41s 39m 54s 9m 24s 2006 Apr. 3h 56m 40s 36m 57s 36m 12s 2006 Jun. 4h 14m 29s 46m 29s 6m 52s 2006 Aug. 3h 42m 30s 44m 9s 11m 35s 2006 Oct. 4h 10m 52s 41m 2s 36m 10s 2006 Dec. 3h 58m 59s 42m 28s 35m 56s
the storage in almost all the routing tables. And the processing time is relatively short. For each table, the two-phase algorithm can reduce 75 to 85 percentage of ternary-CAM space, as the reduced percentage of RC is 60 to 70.
4
Conclusion
In our proposed scheme, a new technique has been proposed for providing a routing table compaction that can reduce 75% to 85% of the original size. By comparing to the existing algorithm, our hardware-based approach can improve the use of ternary-CAM space under reasonable compressing time, and perform well without consider the size of routing table. In conclusion, this technique works well under variable table size. The contribution of this technique for reducing the size of routing tables stored in ternaryCAM can directly result in decreased cost, power consumption and heat dissipation.
References [1] P. Gupta, S. Lin, and N. McKeown, ”Routing Lookups in Hardware at Memory Access Speeds,” Proc. IEEE INFOCOM, (1999), pp. 1240-1247. [2] N.Huang, S. Zhao and J. Pan, ”A Novel IP-Routing Lookup Scheme and Hardware Architecture for Multigigabit Switching Routers,” IEEE J. Selected Areas Comm., Vol. 17, (1999), pp. 1093-1104. [3] H. Liu, ”Routing Table Compaction in Ternary CAM,” IEEE Micro, Vol. 22, (2002), pp. 58-64. [4] A. J. McAulay and P. Francis, ”Fast Routing Table Lookup Using CAMs,” Proc. IEEE INFOCOM, (1993), pp. 1382-1391. [5] T. Pei and C. Zukowski, ”Putting Routing Tables in Silicon,” IEEE Network, Vol. 6, (1992), pp. 42-50. [6] D. Shah and P. Gupta, ”Fast Updating Algorithm for TCAMs,” IEEE Micro, Vol. 21, (2001), pp. 324-334.
1467
[7] APNIC, ”Asia Pacific Network Information Center,” See http://www.apnic.net/, 2006. [8] CIDR REPORT, ”BGP Routing Table Analysis Reports,” See http://bgp.potaroo.net/, 2007.
