IP Address Lookup in Hardware for High-Speed Routing

Transcription

1 IP Address Lookup in Hardware for High-Speed Routing Andreas Moestedt and Peter Sjödin Swedish Institute of Computer Science P.O. Box 1263, SE KISTA, Sweden Abstract This paper presents a way of doing IP packet classification at high speed, a critical operation for highcapacity routers. Two hardware designs are presented, both based on simple, standard logic. One goal is that the designs should be inexpensive and simple enough that it is feasible to replicate them on each input port on a router. The first design is for unicast forwarding, based on destination addresses, and does IP address lookup through a longest prefix match operation. The second design is for identifier lookup, used for multicast addresses and for packet flows. Both designs use standard memory and simple programmable logic, and are capable of one lookup per memory cycle. With standard memory technology, this corresponds to a rate of more than 10 Gb/s per port. In this paper we present the designs, analyse their performance and cost, and discuss how they can be used in a high-capacity router. 1.0 Introduction The growth of the Internet has lead to a situation where network capacity is becoming a scarce resource. It used to be that network capacity was mainly limited by the speed of the links, but this situation is now changing. Thanks to the developments in transmission technology, with the introduction of fiber optics, the bottleneck is moving from the links to the routers. The current trend for dealing with this problem is to relieve routers from some of the burden of switching traffic, and instead use switches of different kinds, such as FDDI switches, ATM switches, and Ethernet switches. This turns out to be a more costeffective solution, since the price for switching capacity is lower than the price for routing capacity. One of the main limiting factors for performance in a router, compared to a switch, is often thought to be the processing of incoming packets: When an IP packet arrives at an input port of a router, the packet needs to be examined and classified, and based on the classification the packet is forwarded to an output port. The packet classification operation consists of analysing information in the packet header (at least the destination address needs to be examined), and performing a lookup operation to obtain the information required to forward the packet to its next hop. In principle, the same kind of classification needs to be performed by a switch, but the operation is generally thought to be more complicated for an IP packet than for an ATM cell or an Ethernet frame, for example. The classification operation performed by a switch can be done through a few, simple operations. This typically includes fetching a field from the header of the incoming data unit, performing some simple arithmetical-logical operations on this field, and using the result as a direct index into a table with forwarding information. Such a table can be stored in ordinary RAM, which means that in the ideal case, a switch can classify data units at the rate of one data unit per memory cycle in the RAM. We will in this paper demonstrate that it is also possible to classify IP packets at the rate of one packet per memory cycle. The purpose is to present two IP address lookup mechanisms, lookup engines, which are suitable to implement in hardware. The first engine is for unicast IP addresses, and performs a longest prefix lookup. The data structure we use for this is a variant of a trie [9] with few levels. The second engine is a more general design intended for classifying multicast packets and packet flows. This design uses hashing with multiple parallel hash tables. Both lookup engines are based on cheap memory and standard logic, and are designed mainly with the goal to be scalable. The scalability is achieved in two ways: The first is that the lookup engines are so cheap that it allows a distributed router design where each link interface card has its own lookup engines. A router can then be built with any number of interface cards, since the lookup engines put a limit only on the capacity of individual interfaces, and not on the total capacity of the router. 1

2 The second scalability property comes from the fact that the lookup engines themselves are flexible: for a high-speed link, they can be configured in such a way that they perform one lookup per memory cycle. Using slow SRAM with a memory cycle time of 100 nanoseconds, it is possible to process 10 million packets per second. Assuming that an average IP packet is bits long, this means that each lookup engine can deal with Gb/s worth of traffic. Higher capacity can easily be achieved by using faster memories. The rest of this paper is outlined as follows. The next section presents the IP address lookup problem in more detail and discusses possible ways of solving it. Section 3 and 4 presents our two designs in more detail, including how they are implemented. The paper ends with a summary in section IP Packet Classification We distinguish between two different types of IP packet classification: IP address lookup, which is used to forward unicast packet based on their destination address, and identifier lookup, intended for forwarding of multicast packets and flows of packets, for example. 2.1 IP Address Lookup A routing table entry for IP unicast addresses has two fields: a prefix and a next hop. A prefix represents a group of addresses, and consists of an IP address and a prefix length. For example, the IP (version 4) prefix /24 is a 24 bits long prefix represents all IP addresses with the 24 first bits equal to The address lookup operation consists of searching the routing table for the longest prefix matching the packet s destination address. The next hop field of that entry defines how packet should be forwarded. A common implementation is to organize the routing table as a sorted tree structure, such as a Patricia trie [4][17][19], and search the routing table by traversing the tree. In general, this requires several accesses to memory, and the performance of this method is limited by the number of memory references, which in turns depends on the size of the routing table and the organization of the tree. Recent work in this area have concentrated on algorithms to reduce the size in memory of the routing table, and to reduce the number of memory accesses needed for a lookup [2][8]. Combinations of hashing and trees have also been proposed [3]. A software implementation of routing table lookups depends on the processor being fast enough to keep up with the speed of the links. A multi-gigabit router typically requires a high-end CPU for the routing lookup. It may not be feasible to put such a CPU on each interface card, so instead the CPU is a centralized resource in the router. The router must then have means for synchronizing accesses to the CPU as well as additional data paths to and from the CPU, which increases the complexity of the router. Furthermore, the key to high performance in our work is to exploit parallelism in the lookups, something which is hard to with a CPU. There have been several suggestions to implementing routing table lookups by using Content Addressable Memory (CAM) to store the routing table [6][13][15]. However, CAM technology does not currently provide large memory at a sufficiently low cost to make this a practical solution. 2.2 Identifier Lookup There are traffic types for which an IP address lookup is not appropriate. Unlike unicast addresses, IP multicast addresses are not currently organized in a hierarchical structure. Instead, a multicast routing table lookup consists of locating complete IP addresses and consequently there is no gain in having multicast routing tables based on prefixes. Another case where a prefix lookup is not applicable is identification of flows, for instance when a flow of packets has been defined through the resource reservation protocol RSVP [1]. Then the router must identify the flows to which packets belong. A flow is identified by a combination of several fields in the IP packet header: the source address, destination address, protocol type (e.g. TCP or UDP), and the source and destination port numbers of that protocol. In IP version 6, there is a special flow label field in the header, which is used to identify the flow to which the packet belongs. We call the kind of lookup needed in the cases above identifier lookup, which is used when several fields in the packet header together form a packet identifier. Such an identifier has no hierarchical structure to it, and the identifier space is potentially very large. Therefore techniques such as hashing or CAM are required for the lookup. 2

3 3.0 Longest Prefix Matching Our design for performing longest prefix match is based on a tree representation of the routing table, where the tree is searched from shorter prefixes to longer. In contrast to other tree-based schemes, our tree uses a small, fixed number of prefix lengths. 3.1 The Data Structure The address space can be though of as a tree, where the nodes represent prefixes. Each level in the tree represents a specific prefix length, which is the same for all nodes on that level. In our scheme we limit the tree to a few levels (typically three to five). Figure 1 depicts a prefix tree with 6-bit addresses using three prefix lengths (2, 4 and 6). Prefixes with other lengths than the ones used in the tree have to be expanded into several longer prefixes. For example, for the tree in Figure 1, a prefix with length 3 has to be expanded into two prefixes with length 4, so the (binary) prefix 010/3 would have to be expanded into 0100/4 and 0101/ Invalid route Part of route Valid route Figure 1 Example routes in a prefix tree The tree has three types of nodes: valid, part and invalid nodes. A valid node represents an entry in the routing table. A part node corresponds to a prefix that matches an entry in the routing table, but is shorter than that entry ( prefix of a prefix ). An invalid node represents a prefix that does not appear in the routing table. To simplify the processing of the tree, we introduce two restrictions: First, all possible children of a part node must be present in the tree (this is called a prefix group). The unused prefixes in a prefix group are marked as invalid. The second restriction is that we do not allow a node to be both valid and part at the same time. So if there is a prefix in the routing table which is both a route in itself and a prefix of other routes, it will appear as several nodes in the tree: The prefix itself is inserted as a part node and the prefix is expanded into a prefix group where all entries are valid. To find a matching route, the tree is searched from the shortest prefix until the first valid or invalid node that matches the route is encountered. In this way, the longest matching entry is guaranteed to be found. For example, the following is the procedure to find the address in a routing table represented by the tree in Figure 1: First the shortest prefix 01/2 is looked up. The matching entry is a part, resulting in a second lookup, 0101/4. This entry is also a part. A last lookup is then performed, resulting in a valid entry. This entry points into a routing table where the forwarding information is stored. If only simple forwarding is needed for the entry, an output port identifier could be stored there instead of the pointer. 3.2 Memory Configuration The time it takes to look up a route depends on the number of levels in the prefix tree. Every level requires one memory access, so with fever levels, the lookup is faster. However, fewer levels requires more memory. This is due to prefix expansion, and the requirement that all entries in a prefix group need to be present. This will generate more nodes when there are few levels in the tree. If, for example, the step between two levels is 8 bits, every part node will have 256 children nodes in its prefix group. The ideal choice of levels and the distance between them, depends on what performance is needed, and how much memory can be used. AADS 17,465 routes MAE-East 43,839 routes Levels Part 6,680 6,680 1,618 12,163 12,154 2,518 Valid 50,091 50, , , , ,864 Invalid 115, , , , , ,762 Total 172, , , , , ,144 Per route Size 336kB 336kB 936kB 507kB 526kB 1,387kB MAE-West 11,021 routes PacBell 18,889 routes Levels Part 4,784 4,774 1,325 6,996 6,993 1,690 Valid 28,979 35,219 93,059 53,717 58, ,152 Invalid 108, , , , , ,334 Total 142, , , , , ,176 Per route Size 275kB 289kB 790kB 345kB 354kB 972kB Table 1 The number of nodes for prefix trees with 5, 4, and 3 levels. The levels correspond to prefixes with lengths {16, 20, 24, 28, 32}, {16, 20, 24, 32} and {16, 24, 32}, respectively. 3

4 Table 1 shows the sizes of prefix trees with three, four and five levels for different routing tables. The routing tables come from the IPMA project [22], and are snapshots of real tables from four large backbone routers on the Internet. 1 For each routing table, the number of nodes that are part, valid, and invalid are given, as well as the total number of nodes and the number of nodes per route in the routing table. The last row gives the amount of memory required to store the prefix tree. Table 1 shows that larger routing table yield less nodes per route than smaller tables. In other words, larger tables have a higher degree of overlap between routes, which gives attractive scaling properties in terms of memory consumption. 3.3 Implementation A prefix based lookup engine using the previously described data structure could be implemented in a variety of ways. Here we present a high end hardware design, intended to maximize throughput. 31 part valid index 0 index 1 index 2 index 3 Level 0 Level 1 Level 2 Level 3 pointer Next hop Table Figure 2 The trie data structure, as a linked list of tables To represent our prefix tree in an implementation, we use is a trie [9], similar to the data structure commonly used for page tables in virtual memory systems. In routing tables, tries have been used previously for address lookup with fixed lengths [13][14][16]. Binary tries have also been used for variable length addresses, for example the commonly used Patricia trie, which is a refinement of a binary trie. But since IP (version 4) addresses are 32 bits long, a fast hardware implementation of Patricia tries is expensive and complex, as investigated in [17]. Instead we use a variant with only a few levels. The prefix tree structure is partitioned into several tables, Figure 2, where each table represents a prefix length. An entry in a table either represents a valid route, and then contains a pointer into a table defining the next hop, or represents a part of a route, and then contains a pointer to a new table. On a lookup the IP address is divided into subfields, one for each level in the prefix tree. These subfields are used as indices into the tables at the corresponding levels in the trie. So the first subfield from the IP address (i.e. the most significant bits) is used as an index into the first level table. This gives a pointer to a table at level two, indexed by the second subfield from the IP address, and so on. Figure 3 shows a very simple hardware design of a lookup engine with four levels. The tables are stored in different memory banks, with one bank for each level. This results in a pipelined design, with one stage per level. Besides the pointer field, each table entry also includes two bits indicating whether the node is part or valid. The pointer, the part bit and the valid bit are sent from one stage to the next. The lookup is completed when a stage either has the valid bit set, or has both the valid bit and the part bit cleared. When a match is found (i.e., a stage has the valid bit set), the resulting next hop pointer flows through the following stages, without being changed. The memory consumption depends on the size of the table entries. Each entry consists of one valid bit plus a pointer field. The part bit is not needed, instead when the valid bit is not set, the pointer refers to the first prefix group on the next level. In this groups all entries point to a similar group on the next level. On the last level a cleared valid bit indicates an invalid route. With 15 bits for the pointer, yielding a maximum of the 32k next-hops in the routing table, each entry occupies 16 bits (this is the table entry size used to calculate the memory consumption shown in Table 1). The performance of the design is mainly limited by the speed of the memory banks. Since the design is pipelined with one memory bank per pipeline stage, it can perform lookups at the rate of one lookup per memory cycle. Furthermore, the maximum delay for a lookup is the memory cycle time times the number of stages in the pipeline. 1 The tables in the example are from February 5, 1997 and April 7, We have also used routing tables from 1998 with the same result. 4

5 ptr ptr ptr ptr valid valid valid valid part part part outptr valid address Figure 3 The longest prefix lookup engine, with multiplexers, memory blocks and some gates 3.4 Optimized Memory Usage Our design utilizes the fact that many routes partly overlap so that the prefix tree becomes rather dense. If instead routes would be randomly distributed, many additional entries could be generated. The worst case occurs when a route is added that has no overlap with any existing entry in the tree. In this case, a new table will be generated at each level in the tree. The probability that this happens decreases as the tree grows, but nevertheless we think it is interesting to study these worst-case characteristics of the design. Therefore we perform another experiment where we use randomly generated routes. We generate prefixes with lengths between 8 and 32 bits to represent a sparse worst case routing table. The results, shown in Table 2, indicate that the size of a prefix tree is significantly larger for randomly generated tables than for a real routing table. It is also apparent that with random routes, the prefix tree gets much larger when the number of levels decreases. It is a common case in sparse routing tables that a prefix group is filled with only two kinds of entries. This is a result of prefix expansion, where the first kind consists of one or more consecutive valid entries, and the second kind consists of either invalid or valid entries. address bits mask table ptr 0 new ptr By only storing one entry of each kind, we would be able to save much memory. Therefore, as an optimization, we introduce a special representation of this kind of prefix groups which makes it possible to reduce the prefix group to only two entries. The reason this scheme is chosen is that it is simple to implement in hardware, with one AND-gate, one comparator and two multiplexers per stage. All components are four or eight bits wide. The size of each entry in the tables is expanded to 24 bits when the step to the next level is 4 bits, and to 28 bits then the step is 8 bits. The mechanism for decoding such compressed tables is shown in Figure 4. Other ways to reduce the memory overhead of tries have been proposed [10][11][12], but we find them too complex for a fast and simple implementation. The memory saved by our compression scheme compensates for its overhead, at least for sparse routing tables, as seen in Table 2. There is, however, little gain for the real routing table; there is even a slight increase in memory consumption. This is an indication that there is indeed a high degree of overlap in real routing tables. However, the optimization could still be worthwhile to use as a precautionary measure, since it is easy to implement and significantly improves the worst-case behaviour. Real routes Random routes Lengths Original Optimized original Optimized 5 507kB 592kB 2,019kB 711kB 4 526kB 653kB 7,821kB 689kB 3 1,387kB 1,933kB 17,754kB 4,095kB Table 2 The size of the data structure with and without the memory optimization for routing tables with 43,839 entries (MAE-EAST and a randomly generated table). address tag compress flag = 4.0 Fixed Length Lookup Engine Figure 4 The logic for table decompression The fixed length lookup engine is used when several fields in the packet header together form a packet identifier. This can be used for lookup of flows and multicast addresses, for example. In these cases the 5

6 hash functions hash memories address table comparator identifier H1 SEL = found pointer H2 H3 Figure 5 The hash based lookup engine identifiers have no hierarchical structure, making a longest prefix lookup inefficient, particularly as the identifiers often are rather wide. 4.1 The Hash Architecture The basic block in the design is a simple hash table, where each table entry contains a pointer to a routing table with the forwarding information. The index into the table is computed as a hash function over the packet identifier. The operation of this lookup engine is straight-forward: When an IP packet arrives, an index into the table is computed by hashing the relevant fields in the packet header, and the entry at that position in the table gives a pointer to the forwarding information for the packet. A hashing scheme like this has the property that a hash function can map several identifiers into the same table location. Several solutions have been used to handle this [18][19][20]. Typically a hash table is implemented as a table of lists, where each table entry is a list of identifiers that share that index. The disadvantage with such an organization is that it requires repetitive accesses to memory in order to do a lookup, lowering performance. Furthermore, many such schemes rely on only one hash function, so rehashing has to be performed if the distribution gets too skewed. Our approach is instead to use several parallel hash paths, where each hash path consists of a hash table and a hash function. In our scheme, a given identifier can only appear in one of the paths at a time. Therefore a lookup for a given identifier will succeed in at most one of the paths, and consequently all paths can be searched in parallel. Figure 5 shows a lookup engine with three parallel paths. The hash functions are denoted H1, H2, and H3. A hash table entry contains an index into a second level table, the address table, where the full packet identifier is stored together with the forwarding information for the destination. When the lookup engine has detected a hit in a hash table, the packet identifier is compared to the original identifier in the table, making sure that they are the same. If they do not match it was a false hit, indicating that the identifier was not present in the routing table. This is an error situation which in a typical design will be handled by the router control processor. The hash calculation, the memory lookup, the table lookup and the comparison are all independent operations and can work in parallel, thus the lookup can easily be pipelined to increase throughput. The advantages with this design are twofold: first, it allows several tables to be examined in one memory cycle time, since the tables are composed in parallel. Second, there are several hash functions, which effectively decreases the need of rehashing. 4.2 Insertion of Identifiers When an identifier is added to the lookup engine it is initially hashed into the first path. If a collision occurs, i.e. there is already an identifier with the same index in the hash table, the two colliding identifiers are hashed into the second path. The entry in the first path where the collision occurred is invalidated so that it cannot be used for any other identifier. If a collision occurs also in the second path the same procedure is repeated with the colliding identifiers being moved to the third path, and so on. The reason why a hash entry where a collision has occurred is invalidated, is that it is then sufficient to only consider the first path with a hit. If there are hits also in subsequent paths, those hits are always false hits. So with this scheme, only one comparison with the real identifier has to be performed. 4.3 Memory Configuration If a collision occurs in the last path, the lookup table will overflow. There are several possible ways to han- 6

7 dle this. For example, Digital s Gigaswitch FDDI bridge [18] stores addresses in a single hash table and uses a small CAM memory to store the overflow. It is also possible to have a small, fast buffer next to the lookup mechanism, and search this buffer sequentially for the lookup. Yet another solution is to let a separate control processor do the lookup, and if a specific identifier is used often, it is exchanged with a less used one in the address table. In other words, the lookup engine is used as a cache for the routing table in the control processor. In Table 4 the number of paths is kept constant, and the table size is varied. The total memory size is 5M entries in all cases, and 1280k identifiers are inserted. By using larger tables in the first path and smaller tables in the others, the rapid decrease in overflow seen in Figure 6 is utilized in all the hash paths. In the last configuration of Table 4, the first hash table is unnecessarily large, and therefore wastes memory that could be used more efficiently in the other paths. The memory requirements scales linearly with the number of identifiers, making the design suitable both for small and large address tables. Figure 6 Address overflow Memory entries The larger the tables in the hash paths, the lower the probability that identifiers collide. The number of overflowing identifiers from a table is approximately given by the expression n N n( 1 e ) where n is the number of identifiers inserted, and N the number of entries in the table. Figure 6 shows how the overflow from a single table varies with the memory size (up to 8M entries), when 128k, 256k, and 512k identifiers are inserted 2. As the graph shows, the overflow first decreases rapidly when the memory size grows but then the change gets smaller. For example, with 512k identifiers and a singe 4M table, the overflow is about 70k identifiers. If instead two 2M tables are used, the first has an overflow of 128k identifiers, and if those identifiers are fed into the second table, the resulting overflow is about 10k. It is apparently better to divide the memory into several paths as described above, than using all memory for one single path with a large table. Table 3 shows different configurations, all with a total memory of 4M entries, when 512k identifiers are inserted, and the number of paths are varied. By adding more paths the overflow is effectively reduced. 2. In this model the hash functions are assumed to spread identifiers uniformly. Number of hash paths Memory size (million entries) Identifier overflow , , Table 3 Memory usage, 512k identifiers To summarize, the most efficient memory usage is obtained when the table is divided into several hash paths. The hash paths should be organized hierarchically with the largest table at the highest level and smaller tables at the lower levels. A possible optimization is based on the assumption that most of the entries will reside in the first, largest hash table. In this case, the other tables will be used less frequently, allowing sequential access to them. Then only a few (two or three, say) parallel paths have to be implemented, since all paths but the first share the same lookup mechanism and the same memory. A drawback with this scheme is the increase in worst case latency. Memory configuration (sizes in k entries) Identifier overflow , ,033 Table 4 Overflow for different configurations 4.4 Choosing Hash Functions An ideal choice for the hash function would be CRC polynomials, which have good hashing properties. Unfortunately, calculating the CRC is easy when data arrives serially, but is more complex to do on a parallel word of data. There are, however, other solutions, such as XOR folding, that have also proved to work 7

8 well [5]. In our simulations we have used both kinds of functions with good results. The XOR folding is probably the preferred choice in an implementation, being very simple and easy to vary. 4.5 Performance The hash function can be implemented by standard programmable components such as Programmable Logic Devices (PLDs). XOR folding can be implemented with one level of logic, which would take between 5 and 15 nanoseconds with standard components. This means that the pipeline stage with the memory is the slowest stage, so memory speed is the main limiting factor for performance also in this design. Thus, like the longest prefix match engine, this design is capable of performing one lookup per memory cycle. The delay through this design is one memory cycle plus the time to compute the hash function. 5.0 Summary We have demonstrated how fast IP address lookup engines can be built from a small amount of inexpensive, off-the-shelf components such as slow Static or Dynamic RAM (SRAM, DRAM) and Programmable Logic Devices (PLDs). We have presented two designs: one for prefix based lookups for ordinary unicast forwarding and one for lookup of flat identifiers, intended for multicast address and flow lookups. Both designs are pipelined and can perform lookups at the rate of one packet per memory cycle. Depending on the memory technology used, this corresponds to rates up to 50 million packets per second. Both designs achieve the high speed by exploiting parallelism. Due to their inherent simplicity, it is very easy to assess implementation complexity as well as performance. Memory consumption is, however, less obvious so this is the key aspect in our work. For the prefix-based engine, the memory usage lies in the range of 300 KB to 1.9 MB, depending on the original routing table and the memory configuration. Using a conservative approach with four or five levels in the pipeline, the memory consumption is less than 700 KB even for very large routing tables, such as the table from MAE-EAST. For the hash-based engine, we study different ways of partitioning the memory in order to reduce memory consumption and minimize overflow. The best result is achieved if the memory is partioned into a hierarchy, with larger memories at the top. The total amount of memory grows linearly with the number of identifiers stored in the table, which makes the design suitable both for small and large tables. References [1] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, Resource ReSerVation Protocol (RSVP) Version 1 Functional Specification, RFC 2205, September 1997, Proposed Standard [2] M. Degermark, A. Brodnik, S. Carlsson, S. Pink, Small Forwarding Tables for Fast Routing Lookups, Proceedings of SIGCOMM'97 Conference on Communications Architectures, Protocols and Applications. Sep [3] M. Waldvogel, G. Varghese, J. Turner, B. Plattner, Scalable High Speed IP Routing Lookups, Proceedings of SIGCOMM'97 Conference on Communications Architectures, Protocols and Applications. Sep [4] W. Doeringer, G. Karjoth, M. Nassehi, Routing on Longest-Matching Prefixes, IEEE/ACM Transactions on Networking, vol. 4, no. 1, pp , Feb [5] R. Jain, A Comparison of Hashing Schemes for Address Lookup in Computer Networks, IEEE Transactions on Communications, vol. 40, no. 10, pp , [6] A. McAuley, P. Francis, Fast Routing Table Lookup Using CAMs, IEEE INFOCOM 93, vol. 3, pp , March [7] P. Newman, G. Minshall, T. Lyon, L. Huston, IP Switching and Gigabit Routers, IEEE Communications Magazine, vol. 35, no. 1, Jan [8] S. Nilsson and G. Karlsson, Fast Address Look- Up for Internet Routers. Proceedings of IFIP International Conference of Broadband Communications (BC'98), Stuttgart, Germany, April To appear. [9] E. Fredkin, Trie Memory, Communications of the ACM, vol. 3, no. 9, pp , Sept [10] K. Maly, Compressed Tries, Communications of the ACM, vol. 19, no. 7, pp , July 1976 [11] D. Comer and R. Sethi, The Complexity of Trie Index Construction, Journal of the ACM, vol. 24, no. 3, pp , July 1977 [12] D. Comer, Analysis of a Heuristic for Full Trie Minimization, ACM Transactions on Database Systems, vol. 6, no. 3, pp , Sept

9 [13] T. Pei, C. Zukowski, VLSI Implementation of Routing Tables: Tries and CAMs, Proceedings of INFOCOM '91, [14] T. Pei, C. Zukowski, Putting Routing Tables in Silicon, IEEE Network Magazine, pp , [15] A. Tantawy, O. Koufopavlou, M. Zittertbart, "On the Design of a Multigigabit IP Router", Journal of High Speed Networks, vol. 3, no. 3, [16] N. Clarke, A. Cantoni, Z. Budrikis, ATM Switching Tables, Proceedings of Australian Telecommunication Networks & Applications Conference 1994, vol.2, pp , Dec [17] D. Knox, S. Panchanathan, Parallel Searching Techniques for Routing Table Lookup, IEEE INFOCOM 93, vol. 3, pp , March [18] R. J. Souza, et.al., GIGAswitch System: A High-performance packet-switching Platform, Digital Technical Journal, vol. 6, no. 1, winter 1994 [19] D. E. Knuth, The Art of Computer Programming, vol III: Searching and Sorting, Addison-Wesley, Reading Ma., 1975 [20] M. Tsukakoshi, O. Takada, T. Murakami, M. Terada, M. Yamaga, Large-scale and High-speed Interconnection of Multiple FDDIs using ATM-based Backbone LAN, IEEE INFOCOM 92, vol. 3, pp , May 1992 [21] C. Partridge, A Fifty Gigabit per Second IP Router, paper in preparation. [22] Internet Performance Measurement and Analysis, URL: 9