TrieC: A High-Speed IPv6 Lookup with Fast Updates Using Network Processor

Transcription

1 TrieC: High-Speed IPv6 Lookup with Fast Updates Using Network Processor Xianghui Hu 1, Bei Hua 1, and Xinan Tang 2 1 Department of Computer Science and Technology, University of Science and Technology of China, Hefei, P.R. China xhhu@mail.ustc.edu.cn, bhua@ustc.edu.cn 2 Intel Compiler Lab, US xinan.tang@intel.com bstract. ddress lookup is one of the main bottlenecks in Internet backbone routers, as it requires the router to perform a longest-prefix-match when searching the routing table for a next hop. Ever-increasing Internet bandwidth, continuously growing prefix table size and inevitable migration to IPv6 address architecture further exacerbate this situation. In recent years, a variety of highspeed address lookup algorithms have been proposed, however most of them are inappropriate to IPv6 lookup. This paper proposes a high-speed IPv6 lookup algorithm TrieC, which achieves the goals of high-speed address lookup, fast incremental prefix updates, high scalability and reasonable memory requirement by taking great advantage of the network processor architecture. Performance of TrieC is carefully evaluated with several IPv6 routing tables of different sizes and different prefix length distributions on Intel IXP2800 network processor(npu). Simulation shows that TrieC can support IPv6 lookup at OC-192 line rate. Furthermore, if TrieC is pipelined in hardware, it can achieve one IPv6 lookup per memory access. Keywords: Network processor, IPv6 lookup, parallel programming, embedded system design, routing, prefix expansion. 1 Introduction Due to the rapid growth of the Internet bandwidth and continuously increasing size of the routing tables, IP address lookup becomes one of the most challenging tasks in backbone routers. By the inevitable migration to the next generation IPv6 128-bit address space, IPv6 lookup becomes even more demanding. Traditional routers generally use application specific integrated circuits (SIC), FPG, or general-purpose processor (GPP) as a building block. SIC provides guaranteed high-performance with low power, but lack of flexibility makes it unable to keep up with the rapid changes in network protocols. FPG offers certain flexibility but it costs more to build and its power consumption is very high. On the other hand, GPPs can meet the requirements of flexibility, short development period and low cost, but often fail to meet the performance requirements because they are not specially optimized for network processing. For example, the efficiency of the GPP cache system relies on data s temporal locality, which is not a common case in L.T. Yang et al. (Eds.): ICESS 2005, LNCS 3820, pp , Springer-Verlag Berlin Heidelberg 2005

2 118 X. Hu, B. Hua, and X. Tang today s high-speed and aggregated networks. s a consequence, network processor unit(npu) emerges as a promising candidate for networking building block. It retains both the high performance of SIC and flexibility advantage of GPP through parallel and programmable architecture. t present, many companies including Intel, Freescale, grere, MCC and EZchip have developed programmable NPUs. Many system companies including Cisco, lcatel, HUWEI, and ZTE use NPUs to build switches and routers. This paper presents an efficient IPv6 address lookup scheme called TrieC, which achieves O(1) search time with fast incremental updates and reasonable memory requirement by taking great advantage of the characteristics of NPU, especially of Intel IXP network processor. lthough our experiment was done on Intel IXP2800, the same performance can be achieved on other similar NPUs. The main contributions of the paper are as follows: new IPv6 address lookup algorithm (TrieC) is proposed with the features of high speed, fast prefix incremental updates, high scalability and reasonable memory requirement. modified compact prefix expansion (MCPE) technique is designed to use less memory for address search and prefix incremental update than traditional prefix expansion. n architecture awareness algorithm implementation aiming at IXP2800 NPU is elaborated, which: 1) takes advantage of the special instruction set of IXP 2800, especially the bit counting and CRC instruction to make the search of the compressed tables fast; 2) distributes IPv6 routing table in four SRM channels to support simultaneously data accesses; and 3) partitions the tasks appropriately on three IXP2800 Microengines(MEs) to achieve IPv6 lookup at OC-192 line rate. The rest of the paper is organized as follows. Section 2 describes issues of existing approaches in IP address lookup, especially in the IPv6 circumstances. Section 3 explains the design and mechanism of TrieC. Section 4 discusses how to implement incremental prefix updates efficiently. Section 5 introduces the optimized implementation on IXP2800. Section 6 shows simulation results and performance analysis. Finally, section 7 concludes. 2 Related Work The most popular data structure for longest prefix match is trie[6-8]. In order to reduce memory accesses in trie, various kinds of techniques such as prefix expansion and multibit trie[12] have been proposed. Multi-bit trie expands a set of arbitrary length prefixes to a predefined set of prefixes by prefix expansion. Its search time is linear with the multi-bit tree levels and its update time depends on both prefix length and maximum node size. However, its worst-case memory requirement is O(2 k *N*W/k), where k, N and W are search stride, number of prefixes and maximum prefix length respectively. Basic-24-8-DIR[13] is a hardware implementation using prefix expansion for IPv4 lookup with maximum two memory accesses, but it needs more than 32Mbytes memory and even more memory or dual memory bank for routing updates.

3 TrieC: High-Speed IPv6 Lookup with Fast Updates Using Network Processor 119 Waldvogel et al.[9] use binary search on hash table organized by prefix length. The scheme requires log 2 W memory accesses, where W is the maximum prefix length, in the worst case. However, it requires very long preprocessing time to compute markers noting the existence of longer prefixes, hence the update time is O(N*log 2 W) and the whole routing table must be reconstructed. Multiway range tree [11] reduces search time and update time to O(k*log k N) through modifying binary search by prefix length, it also analyzes the feasibility for IPv6 address lookup. However, its memory requirement is O(k*N*log k N). Lapson et al.[10] introduce multicolumn search for IPv6 addresses that avoided the multiplicative factor of W/M inherent in basic binary search by doing binary search in columns of M bits, and moving between columns using pre-computed information. However, in the worst case, it needs approximate 15 memory accesses for IPv6 address lookup because of O(log k 2N+W/M) search time. dditionally, TCM-based, CPU caching[5], reconfigurable fast IP lookup engine[14], binary decision diagrams[20] etc. are all hardware-based IP lookup schemes. Their advantages are high lookup speed, whereas their disadvantages like specific hardware support, high power consumption, complicated prefix update and high cost limit their application to a certain degree. Obviously, the main problem of existing lookup schemes is that they cannot combine high-speed lookup, fast updates and acceptable memory storage for IPv6 address lookup at the same time. This paper presents our solution of an IPv6 lookup scheme-triec based on the modified compact prefix expansion (MCPE) technique and fixed-level multibit trie structure. High performance search is achieved through fixing the levels of TrieC tree, and fast incremental update is achieved by storing the unexpanded prefix length in MCPE nodes. Moreover, memory requirement is reduced to a reasonable capacity due to compressed MCPE technique. 3 lgorithm Design and Mechanism 3.1 Basic Idea In trie structure, prefix information is stored along the path from the root to the leaf node of the tree. To reduce the path length and thus memory access times, prefix expansion technique is applied to increase the routing table size in a fixed stride so that the resulted expanded table could be visited in the same stride index. The proposed scheme is based on the following observations: 1. 2 n-m redundant next-hop information must be stored if an m-bit prefix is expanded to 2 n n-bit prefixes, where n is equal to or greater than m, using prefix expansion. 2. Statistics of existing IPv6 routing tables and the IPv6 addresses allocation policies indicate that the percentage of the prefixes whose lengths are equal to or greater than 48-bit is approximate only 5%. 3. Only aggregatable global unicast addresses, whose format prefix (FP) field is always set to 001, need to be searched in the allocated IPv6 address space. dditionally, the lower 64 bits of IPv6 address are allocated to interface ID, so the core router can ignore them.[1-3]

4 120 X. Hu, B. Hua, and X. Tang Therefore, the basic idea of TrieC is to ignore the highest three bits, build a four-level compressed multibit trie tree using the stride for the prefixes whose lengths are longer than 3bits and shorter than 49bits, then use hash to search the other prefixes whose lengths are longer than 48bits and shorter than 65bits. 3.2 Modified Compact Prefix Expansion The modified compact prefix expansion (MCPE) technique is motivated by the fact that there is a lot of redundant next-hop information in traditional prefix expansion. For example, if the IPv6 prefix (2002:4*::/18,) and (2002:5*::/20,B) are expanded to 24-bit prefixes using the traditional prefix expansion, 64(= ) new prefixes are formed as shown in Fig.1(a). Obviously, the same next-hop index repeats many times. repeats 48 times totally, and B repeats 16 times. 24-bit Index 2002:40*::/ :41*::/ :4F*::/ :50*::/ :51*::/ :5F*::/ :60*::/ :61*::/ :6F*::/ :70*::/ :71*::/ :7F*::/24 Next-Hop B B B (a) Traditional prefix expansion 18-bit Tindex 6-bit Bindex :4*::/ NHI B nul (b) Modified compact prefix expansion Fig. 1. Traditional prefix expansion vs. modified compact prefix expansion (MCPE) The main idea of MCPE is to store consecutively identical next-hop index only once in a next-hop index array (NHI). The NHI in Fig.1(b) has three entries (, B, ); the highest 18 bits of 24-bit prefix are used as the index to search a Tindex table and the next 6 bits are used as another index to search a bit-vector Bittlas in a Bindex table. The 64-bit Bittlas is organized as follows: if the next-hop information denoted by bit I is the same as that denoted by bit I-1, bit I is set to 0; otherwise, bit I is set to 1, indicating that different next-hop information must be added into NHI. In Fig. 2 (b), bit 0 is 1 since it starts a new NHI entry; bit 16 is 1 since its NHI is B that is different from previous entry ; bit 32 is 1 since its NHI is again which is different from previous entry B. Now assume we want to search the next-hop information relating to IPv6 address 2002:6*::/24. Firstly, we use the highest 18 bits as Tindex to find out the MCPE entry 2002:4*::/18, then we use the next 6 bits as Bindex to find the bit offset in Bittlas, which is 42. Since total three bits are set in Bittlas from offset 0 to offset 42, the third element in NHI is the lookup result. The TrieC table in Fig.1 is called TrieC18/6. Similarly, TrieCm/n is designed to represent 2 (m+n) uncompressed (m+n)-bit prefixes. Using MCPE technique, the TrieC tree eliminates redundant information and preserves the high-speed index access characteristic of traditional prefix expansion technique.

5 TrieC: High-Speed IPv6 Lookup with Fast Updates Using Network Processor Data Structure Our stride series for TrieC algorithm is The data structures include three types of tables: TrieC15/6 table (ignored highest three bits 001), TrieC4/4 table, and Hash-16 table. TrieC15/6 table is the first-level table that stores all the prefixes whose lengths fall into [1:24]-bit. TrieC4/4 tables are from the second to the fourth level of TrieC trees, whose prefix lengths belong to [25:32]-bit, [33:40]-bit, and [41:48]-bit respectively. Hash16 table stores all the prefixes whose lengths belong to [49:64]-bit. 1bit 9bits 6bits 0 Next-Hop ID Prefix Length 1 Index into Next Level TrieC (a) Next-Hop Index Bittlas Next-Hop Index 1 Next-Hop Index 2 Next-Hop Index 3 Next-Hop Index 4 (b) Basic TrieC15/6 entry Bittlas Next-Hop Index 1 Next-Hop Index 2 Next-Hop Index 3 (d) Basic TrieC4/4 entry NHI Bittlas NHI 2. Index into ExtraNHI table NHI TotalPosition-1 Reserved NHI TotalPosition (c) TrieC15/6 entry with ExtraNHI NHI NHI Bittlas Reserved. Index into ExtraNHI table NHI TotalPosition-1 NHI TotalPosition (e) TrieC4/4 entry with ExtraNHI Fig. 2. Data structures of TrieC scheme The next-hop index (NHI) structure, which stores the lookup result including the next-hop IP address and the output interface, is shown in Fig. 2(a). The original prefix length is stored in NHI due to the requirement of incremental prefix updates. Each NHI entry is 2 bytes, with the most significant bit setting to 0 indicating that the remaining bits consist of a next-hop ID in NHI[14:6], and an unexpanded prefix length in NHI[5:0], while a 1 in this bit indicating that the remaining 15 bits contain a pointer to the next level TrieC node. The TrieC15/6 table contains 2 15 entries, which is called TrieC15/6_entry, and has two types of structures: Basic and ExtraNHI. The basic structure supports up to four NHIs and ExtraNHI supports more NHIs, in which: 1. TrieC15/6_entry [127:64]: stores a 64-bit vector Bittlas. The least significant bit is always set to one because each IP address absolutely matches the default route. TotalEntropy that is the total number of bits set in the bit vector represents the size of array NHI or ExtraNHI. For a bit position P, the number of bits set in Bittlas[P:0] named PositionEntropy[P] gives the NHI index in array NHI or ExtraNHI. For each P, the equation PositionEntropy[P]<=TotalEntropy always holds. 2. TrieC15/6_entry[63:0]: stores up to 4 NHIs or a pointer to ExtraNHI array. If TotalEntropy of Bittlas field is no greater than 4, TrieC15/6_entry[63:0] stores NHI1, NHI2, NHI3 and NHI4 orderly as shown in Fig. 2(b). Otherwise, TrieC15/6_entry[63:32] stores a 32-bit pointer that points to ExtraNHI array as shown in Fig. 2(c). Similarly, each TrieC4/4 table has 2 4 entries and each entry is 8 bytes. The structures of basic and ExtraNHI TrieC4/4 entry are shown in Fig. 2 (d) and (e). The

6 122 X. Hu, B. Hua, and X. Tang unique difference among all TrieC4/4 tables is that if the flag bit of NHI in the fourth level of TrieC tree is set to one, the Hash16 table must be searched. The Hash16 table uses cyclic redundancy check (CRC) as a hash function that is known as a semiperfect hash function. The structure of a Hash16 entry is (prefix, next-hopid) pair. 3.4 Lookup Mechanism Fig. 3 gives a routing table search algorithm based on compressed TrieC tables. We will use an example to show how these tables are searched. IPv6_Lookup_TrieC (IN DstIP, OUT Next-HopID) { 1. Current_Block = TrieC15_6; 2. Tindex = DstIP [124:110]; 3. Bit_Vec = GetBitVec (Current_Block, Tindex); 4. Bindex = DstIP [109:104]; 5. NHI = GetNHI(Bit_vec, Bindex); 6. if (NHI.flag = 0) return NHI.Next-HopID; 7. else 8. {// search TrieC4/4 tables, base[i] is base of (i+1) th -level TrieC tree 9. Current_Block = TrieC4/4 at Base[0]+NHI[14:0]; 10. for (i=1;i<=3;i++) 11. { 12. Tindex = DstIP[103-8*(i-1):100-8*(i-1)]; 13. Bit_vec = GetBitVec (Current_Block, Tindex); 14. Bindex= DstIP[99-8*(i-1):96-8*(i-1)]; 15. NHI = GetNHI (Bit_Vec, Bindex); 16. If (NHI.flag = 0) return NHI.Next-HopID; 17. else 18. { 19. if (i!=3) Current_Block=TrieC4/4 at Base[i]+NHI [14:0]<<4; 20. else break; //search longer prefix in Hash } 22. } 23. if (Hash (DstIP [79:64])) return Next-HopID; 24. else return Default-Next-HopID; 25. } }// IPv6_Lookup_TrieC Fig. 3. Pseudo code to search TrieC multi-level tree for IPv6 address ssume that the following routes are already in the TrieC table: (2002:4C60::/18,), (2002:4C6F::/28,B). The first route requires an entry in TrieC15/6 that corresponds to the 24-bit prefixes from 2002:40*::/24 to 2002:7F*::/24. The second route further needs a second level TrieC4/4 to be used because its length is 28-bits. Suppose we are looking up the destination IPv6 ddress 2002:4C6::200C, Fig. 4 shows the detailed lookup process. Firstly, DstIP[124:110] that is is used as the Tindex to find the entry 2002:4*::/18 in TrieC15/6; then DstIP[109:104] that is is used as the Bindex to find the bit offset that is 12 in Bittlas; two bits set from offset 0 to offset 12 makes PositionEntropy=2, thus the second entry in NHI is located; a 1 in NHI[15] indicates that NHI[14:0] contains a pointer to the

7 TrieC: High-Speed IPv6 Lookup with Fast Updates Using Network Processor 123 next level TrieC4/4, so NHI[14:0]<<4+DstIP[103:100] is used as the Tindex to the next level TrieC4/4, and then DstIP[99:96] is used as the Bindex to find out the PositionEntropy that is 1, which then locates the desired next-hop ID, which is B. 24 bits 8 bits 8 bits 8 bits 16 bits Interface ID x200C Bindex 0110 Bindex PositionEntropy=2 TrieC4/4 PositionEntropy=1 Tindex 0 B Tindex Index Next-hop ID=B TrieC15/6 NHI[14:0]<<4+DstIP[103:100] Example Routing Table: Destination IPv6ddress 2002:4C6::200C 2002:4C60::/ :4C6F::/28 B 4 Routing Updates Fig. 4. IPv6 address lookup example of the TrieC scheme New routing information must be exchanged among routers as network topology changes. The frequency of routing updates could be as high as a few hundred times per second. Since the routing table cannot be accessed during update, routing updates must be executed fast and efficiently. The operation of adding a new prefix, NewRoute(new_prefix/new_length, new_next-hop), can be classified into two categories according to the value of new_length: Bittlas affected and Bittlas unaffected. The range of the prefix length corresponding to the former is called TableRange[start_length, end_length] and the range corresponding to the latter is called BittlasRange[start_length, end_length]. For instance, the TableRange and BittlasRange of TrieC15/6 table are [4,18] and [19,24] respectively. Consider the updates in a TableRange. Because a NewEntry matches 2 (TableRange.end_length-new_length) TrieC entries and their whole Bittlas fields, we only need update the NHIs of matched entries. If an old NHI satisfies: flag=0, PrefixLength<=NewEntry.new_length and Next-HopID NewEntry.new_next-hop, it is replaced by the NewEntry. Otherwise, we need search and update the next level of TrieC tree. In the case of BittlasRange, NewEntry exactly matches one TrieC entry and 2 (BittlasRange.end_length-new_length) bits in the Bittlas field of the matched entry. For each matched bit, we only need update the bit and its corresponding NHI if PrefixLength<=NewEntry.new_length and Next-HopID NewEntry.new_next-hop. Otherwise, we need search and update the next level of TrieC tree. The process of adding new prefixes (2002:E7B::/17,C) and (2002:279::/23,D) into the example routing table is shown as Fig. 5. The prefix (2002:E7B::/17,C) matches two TrieC15/6 entries with the Tindex and Only the first NHI() of the former TrieC15/6 entry is replaced by NHI(0,C,17) because the NHI() matches the update condition. In Fig. 5(b), the prefix

8 124 X. Hu, B. Hua, and X. Tang C Routing Table 2002:4C60::/ :4C6F::/28 B 2002:E7B::/17 C 2002:279::/23 D 0B TrieC15/6 (a) TrieC tree after (2002:E7B::/17,C) added F TrieC4/ C 17 0 D C B TrieC15/6 (b) TrieC tree after (2002:279::/23,D) added F TrieC4/4 Fig. 5. Routing updates of the example IPv6 routing table (2002:279::/23,D) matches only one TrieC15/16 entry, whose Tindex is , and two bits in the Bittlas field of this entry. Because the NHI corresponding to these two bits matches the update condition, i.e., NHI.Prefix- Length=17<new_length=23 and NHI.Next-HopID=C new_next-hop=d, both of these two bits are set to one and the corresponding NHIs are updated. 5 Optimization on IXP2800 Network Processor Intel IXP2800 NPU is a programmable network processor that comprises a single XScale processor, sixteen Microengines(MEs), four SRM controllers, three RDRM controllers and high-speed bus interfaces. Each ME has eight hardwareassisted threads of execution. ll threads in a particular ME execute the same code stored on that ME. Complete descriptions of the hardware architecture and software framework are available from the IXP2800 manuals[19]. We implemented TrieC algorithm in MicroengineC language and simulated it on Intel Developer DevWorkbench 4.1[19], which offers a cycle-accurate simulator of IXP2800 network processor. Through analysis, we identified the following operations as time-consuming ones: calculation of TotalEntropy and PositionEntropy, SRM memory accesses, and CRC hash operation. The efficiency of those operations affects the performance of TrieC greatly. We will show how to optimize these operations by taking advantage of the characteristics of IXP2800 network processor. Firstly, the main workload of entropy calculation in TrieC is to count the number of bit set in bit-vector Bittlas. The naive implementation of checking each bit and counting the number of bit set seen so far it is very slow and needs a few hundred shift, LU and branch instructions. Intel IXP2800 network processor has a built-in instruction POP_COUNT that can calculate the number of bit set in a 32-bit register in three clock cycles. Such tremendous reduction of the number of instructions lays a solid foundation for TrieC to achieve line rate.

9 TrieC: High-Speed IPv6 Lookup with Fast Updates Using Network Processor 125 On IXP2800 NPU, each SRM access takes more than 100 cycles, hiding memory latency becomes another important step towards high-performance. We hid the memory-access latencies by means of: Parallelized access: IXP2800 NPU contains four independent SRM controllers and each channel supports up to 64Mbytes SRM. We partitioned the TrieC tables, and then distributed them properly into four SRM channels. TrieC15/6 table and hash16 table were stored in SRM channel 0, because their sizes were smaller than that of each TrieC4/4. The second, third and fourth level TrieC4/4 tables were stored in SRM channel 1, 2 and 3 respectively, so that they could be accessed in parallel. Vectoring access: On IXP2800 NPU, adjacent SRM locations can be fetched in one instruction to the array of SRM transfer registers, which allows for a significant reduction in the number of SRM access. s the maximal length of each SRM access instruction can be up to 64-bytes, we carefully designed the data structures of Tries15/6 and TriesC4/4 such that the sizes of TrieC15/6 entry and TrieC4/4 entry were less than 64-bytes and thus each table entry could be fetched in one SRM access. Finally, each ME has a CRC Unit, which operates in parallel with the execution of data path and supports one time CRC operation within the period of each two consecutive instructions. By using the CRC unit to perform hash calculation, TrieC speeded up the search of hash16 table. 6 Simulation and Performance nalysis Since IPv6 is not yet widely deployed, existing IPv6 tables, which normally have less 1000 prefixes[16][17], are small and unlikely to reflect future IPv6 network growth. Currently, randomly generated tables are often used for IPv6 research and development. To reflect the IPv6 address distribution as objectively as possible, we used three different ways to generate nine IPv6 routing tables whose prefix length distributions are shown in Tab. 1. Group was generated from the CERNET[17], 6Bone, 6Net and Telstra BGP IPv6 routing tables[16], reflecting the existing IPv6 prefix length distribution. Group B was generated from the non-random generator IPv6 table proposed by M Wang et. al[18], reflecting the ideal IPv6 routing tables. Group C was calculated as the arithmetical average of and B, reflecting the future IPv6 tables. Table 1. Prefix length and entries used in simulation Prefix Number N= N= N= Length B C B C B C

10 126 X. Hu, B. Hua, and X. Tang 40 Group Group B Group C DIR-24-8-BSIC(IPv4) Memory requirement(mb) K 300K 400K Number of prefix Fig. 6. Memory requirements of nine IPv6 routing tables vs. of DIR-24-8-BSIC(IPv4) For each group, we generated three different sizes of tables with 200K, 300K and 400K entries. ll the prefix values are generated randomly. Memory requirements of the nine IPv6 tables are shown in Fig. 6. Obviously, memory requirements increase along with table sizes. Note that the memory requirement of table B-400K is approximate 35Mbytes,which is slightly higher than 33Mbyes of DIR-24-8-BSIC for IPv4, but is significantly lower than the estimated memory requirement of multibit-trie, which is approximately more than 820Mbytes at 8-bit strides for 400K entries. With such high a compression rate, the entire routing tables can be stored in SRM verage memory accesses K B-200K C-200K -300K B-300K C-300K -400K B-400K C-400K Simulation routing table Fig. 7. verage memory accesses of nine IPv6 routing tables In the worst case, TrieC needs eight memory accesses and one hash operation. It is clear from Fig. 7 that there is no any relation between average memory accesses and size of IPv6 routing table; the average memory accesses depend only on the prefix length distribution of the table. For example, the average memory accesses of the three tables belonging to group-b are all close to four, because the percentages of the prefixes whose lengths between bits in these tables are all higher than 70%. On average, the number of memory access of these nine IPv6 tables is far less than eight, which indicates that the percentage of the ExtraNHI nodes is extremely low. Simulation results demonstrated it, and found that the percentage was only about 3.6%.

11 TrieC: High-Speed IPv6 Lookup with Fast Updates Using Network Processor 127 Table 2. Minimal threads number required to meet OC-192 line rate on IXP2800 NPU Routing table Minimal Threads Lookup rate (Mlps.) number Single-thread Multi-threads Group Group B Group C Worst case ssume that the minimal packet size is 60-bytes, then approximate 20.83Mlps lookup rate is required to support OC-192 line rate. Tab. 2 gives the minimal number of threads required to reach the line rate speed for each group, in which on average 9, 17 and 11 threads are needed for group, B and C respectively. Considering that there are 16 MEs on IXP2800, and TrieC just consumed less than three MEs of entire ME budget; therefore, there is still enough room for other networking application such as classification and traffic management to meet their line rate requirements. Finally, we compare the performance of TrieC with some existing outstanding schemes in Tab. 3. Table 3. Comparison of search, update, space complexities and scalability for IPv6 Scheme Search time Update time Memory requirement IPv6 Patricia trie O(W) O(W) O(N*W) N Multibit trie O(W/k) O(W/k+2 k ) O(2 k *N*W/k) N Binary search O(log 2W) O(N*log 2W) O(N*log 2W) Y Multiway search O(log K2N) O(N) O(N) Y DIR-24-8-BSIC O(1) Dual bank memory 33MB@IPv4 N TrieC O(1) O(W/k) O(N*W/k) Y 7 Conclusion This paper proposes an IXP2800-based high performance IPv6 lookup algorithm (TrieC) that features high-speed address lookup, fast routing table update, high scalability, and reasonable memory requirement. modified compact prefix expansion (MCPE) technique that supports faster address search and prefix incremental update with less memory requirement than traditional prefix expansion is designed to build a four-level TrieC tree for IPv6 address lookup. Techniques such as distributed routing table allocation in four SRM channels, functional pipelining, Bittlas field calculation speedup, parallelized SRM accesses, consolidating adjacent SRM accesses and hardware CRC hash unit are used to optimize the proposed scheme on IXP2800 network processor. These optimizaiton techniques can also be applied to other similar NP architectures. Performance of TrieC is evaluated with nine IPv6 routing tables of different sizes and different prefix length distributions on Intel IXP2800 network processor. Simulation shows that TrieC implemented on IXP2800 can support IPv6 lookup at OC-192 line rate. Furthermore this algorithm can be easily implemented in a pipelined architecture (SIC) and achieve one IPv6 lookup per SRM access.

12 128 X. Hu, B. Hua, and X. Tang References 1. R. Hinden, S. Deering, RFC2373 IP Version 6 ddressing rchitecture 2. R. Hinden, S. Deering, RFC2374 IPv6 ggregatable global unicast address format, 3. S. Deering, R. Hinden, RFC2460 Internet Protocol, Version 6IPv6Specification 4. Internet Performance Measurement and nalysis Project, 5. M.. Ruiz-Sanchez, E.W. Biersack, and W. Dabbous, Survey and taxonomy of IP address lookup algorithms, IEEE Network, vol. 15, pp.8 23, Mar.-pr Morrison, PTRICI-Practical lgorithm to Retrieve Information Coded in lphanumeric, J. CM, vol. 15, no. 4, pp , Oct W. Doeringer, G. Karjoth and M. Nassehi, Routing on Longest Matching Prefixes, IEEE Trans. on Networking, vol. 4, no. 1, pp.86-97, Feb N. Yazdani and P. S. Min, Fast and scalable schemes for the IP address lookup problem, in Proc. IEEE Conf. High Performance Switching and Routing, 2000, pp M. Waldvogel, G. Varghese, J. Turner, and B. Plattner, Scalable high speed IP routing lookups, Proc. CM SIGCOMM 97, vol. 27, no. 4, pp , Oct B. Lampson, V. Srinivasan, and G. Varghese, IP lookups using multiway and multicolumn search, in Proc. IEEE INFOCOM 98, San Francisco, C, 1998, pp Subhash Suri; Varghese, G.; Warkhede, P.R., Multiway Range Trees: Scalable IP Lookup with Fast updates, Global Telecommunications Conference, 2001.GLOBECOM'01. IEEE Volume 3, Nov pp vol V. Srinivasan, G. Varghese, Fast address lookups using controlled prefix expansion, Proc. CM Sigmetrics 98, June 1998 pp P. Gupta, S. Lin, and N. McKeown, Routing lookups in hardware at memory access speeds, in Proc. IEEE INFOCOM 98, vol. 3, San Francisco, US, 1998, pp E. Taylor, J. W. Lockwood, T. S. Sproull, J. S. Turner, and D. B. Parlour, Scalable IP lookup for programmable routers, in Proc. IEEE INFOCOM 2002, vol. 2, New York, 2002, pp Raj Jain, Comparison of Hashing Schemes for ddress Lookup in Computer Networks, Communications, IEEE Transactions on Volume 40, Issue 10, Oct pp M Wang, S Deering, T Hain, L Dunn Non-random Generator for IPv6 Tables High Performance Interconnects, Proceedings 12th nnual IEEE Symposium on ug pp Sangireddy, R.; Somani,.K.; High-speed IP routing with binary decision diagrams based hardware address lookup engine, Selected reas in Communications, IEEE Journal on Volume 21, Issue 4, May 2003 pp