* I D ~~~ ~ Figure 2: Longest matching prefix.

Transcription

1 A fast and compact longest match prefix look-up method using pointer cache for very long network address Masanori Uga Kohei Shiomoto "IT Network Service Systems Laboratories Midori 3-9-, Musashino, Tokyo , Japan Abstract We propose a fast and compact longest match table look-up method for very long network addresses like IP version 6. This method uses two ideas for a routing-table arranged in a treestructure. First idea is to make table look-up fast by caching pointers to intermediate nodes in the tree, reducing the number of node traversals. Second idea is to reduce the memory size required for each node in the tree by one-third by eliminating common parts of addresses of adjacent nodes. Evaluating the performance of this method by using actual routing table data of an IP backbone network, we found it was five to ten times faster than a conventional method. I. INTRODUCTION The Internet started in the 960s as a research network and has been growing explosively since commercial services started in early '90s. Internet traffic is doubling every year and is predicted to telephone traffic around 2003 [l]. To cope with this exponential increase, we need to have efficient mechanisms for transporting the Internet traffic. The Internet uses Internet Protocol (IP) as a Layer 3 (network layer) protocol. IP is a datagram packet forwarding protocol. Routing decision is made for every packet. Each packet carries a network address for a destination. Each router in the network determines the outgoing route for the packet based on the destination address. The router keeps a forwarding table, a set of association between the network address and the outgoing route. The size of the routing table can be kept small, if we assign a network address to each host in a well-organized fashion, and stick to a fixed network topology. Unfortunately, this address assignment is difficult in most cases. Address assignment and topology design are related. In Fig., hierarchical address is used. Node A, B, and C have address of , , and A packet from node A to node C goes to the node in the upper-tier. The routing table at each tier is simple. A network address other than 7.8.*.* is simply fowarded to the upper-tier node. If traffic volume from node A to node C increases, it is more efficient to set a direct link between node A and C. In this case, the longest prefix matching lookup is needed. Namely, * goes to node C, while a network adress other than 7.8.*.* goes to the upper-tier node. CIDR (Classless Inter-Domain Routing) was introduced to cope with this problem. CIDR uses a variable length network address prefix to aggregate multiple destination address into a single prefix. A packet fro,,, A to c is fowarded It is more efficient to foward after being sended to upper-tier. packets from A to by using direct link between A and C. Figure : Difficulty in hierarchical aaddress assginment and topology design. The entry in the routing table is a pair consisting of a network address and a mask length. For example, if we have two network addresses and , whose destinations are the same, those addresses are aggregated into a single prefix , where 24 indicates the mask bit length and have a. common prefix whose length is 24. The prefix is kept in the forwarding table, making the table size small. When we need to determine the outgoing route for the packet, we use the longest matching prefi table look-up. We select the table entry whose prefix length is the longest among those that match the destination address of the packet (See Fig. 2). In Fig. 2, lo.*.*.* and ]OS.*.* match the input address , and 0.5.*.* is longer than lo.*.*.*. 0.5.*.* is the longest matching prefix and the Next-hop B associated with the prefix is a solution. I Prefix INext - hop A o.*.*.* 0.5.*.* * I D ~~~ ~ Figure 2: Longest matching prefix. For the longest prefix match look-up, the routing table can be arranged in a tree-structure such as Trie or Patricia [2]. Patricia is based on a binary-tree. Each node in the tree has a network address and a mask bit length. The root of the tree is the starting point for traversalthe destination address of the packet is compared with the network address in the root node. If they are identical, the root node is regarded as the nominally longest matching prefix node. Otherwise it is not regarded as /99/$ IEEE 595

2 the longest prefix match node. After that it is determined which child node should be traversed by examining the bit next to the mask bit. If the next bit after the mask is 0, the left child node is traversed in the next step. Otherwise, the right one is traversed. The same procedure is performed for the child node. This procedure is iterated until we encounter a node whose prefix does not match the destination address (the nominally longest matching prefix becomes the genuine one). Figure 3 shows an example. The network address of packet is given. Node S which has a 3 bit network mask is examined. Because matches 00/3 in node S and the next bit (bit 4) is 0, node U is traversed in the next step. Because does not match 000/5 in node U, the tree traversal is halted. Finally, 00/3 in node S is determined as the longest match prefix. IP address I compare total of 3 bits finished The answer is 003 * & Figure 3: Patricia tree. Root node node U 003 node S diveraence bv value of bit position bf IP I3ecause of no hit in this node, so search is- 000 /5 00 OOOOO/g divergence of value + of bit position 4 of IP address node T With the Internet growing at an explosive rate, the following problems have arisen: the size of the routing table is growing and the network addresses are about to be exhausted. To cope with address exhaustion, network addresses are being extended In IP version 6 (network address length:l28-bits). A large table and long network addresses potentially reduce the performance of the Patricia tree. The long network address implies that the number of tree traversals can be 28 in the worst case. It also requires a large memory at each node for storing the network prefix We should note that 28 bits are needed for IP v6 for each node storage in the tree compared to 32 bits for IP v4. Along with the increase in the number of routing table entries, the memory size requirement for the Patricia tree becomes immense for IP v6. To cope with these problems with table lookup speed and memory size requirement for P v6, we propose a fast and compact longest matching prefix table look-up method for long network addresses. This method introduces two ideas. One is to make table look-up fast by caching pointers to intermediate nodes in content-addressable memories (CAMs), eliminating redundant tree traversals from the root of the tree. The other idea is to reduce the memory size required for each node by eliminating the common part of addresses of two adjacent nodes. These two ideas enable us to develop a fast and compact longest match method for IP v6. The rest of this paper is organized as follows. In Chapter 2, we describe our method in detail. In Chapter 3, we evaluate its performance of by using actual routing table data of an IP backbone network. In Chapter 4, we review conventional methods and compare our method with them. In Chapter 5, we summarize the result of this paper and address future work.. PROPOSED METHOD A. Pointer cache ) Prejix aggregation Let's consider the case in which we are searching for a node near a leaf of the Patricia tree. If we start to traverse at the root node, we need to traverse many nodes. If this kind of situation occurs often, the table lookup performance is significantly degraded. If we have any information on the location of the longest matching prefix node in the tree, we may cut some node traversals. Figure 4 shows a conceptual view of the our method. The idea here is to cache a pointer to an intermediate node addresses on the path from the root node to the node. The next question is to determine which intermediate node should be cached. The pointers to node are cached in a CAM. When a prefix is given to the CAM, it returns the table entry associated with the prefix directly, i.e., in O(). If there are multiple entries in the CAM, the table entry at the shortest address is returned. So if we perform the longest prefix match by using the CAM, we need to store the prefixes in descending order with respect to their prefix length. Since the routing table is often updated, it is not easy to maintain the order of the prefixes in the CAM. Another issue with CAM is its memory size. If we store many pointers in the CAM, we can find the longest matching prefix quickly. Unfortunately the memory sizes available for CAM are much smaller than for DRAM. Therefore, we need to reduce the number of entries stored in the CAM. -I IP address Figure 4: Proposed method. d" To cope with these problems with CAMs, we aggregate prefixes. Each prefix is classified into one of four categories 0, 8, 6, and 24 with respect to its length. Prefixes of length to 7 inclusive are classified into category 0 by rounding down their lengths. Likewise, the lengths of prefixes in category 8, 6, 24 are rounded down to 8, 6, and 24, respectively. Prefixes having the same rounded lengthes are aggregated into a single rounded prefix. For example, Fig. 5 shows that the routing table entries 2.96/4 and 2.32/5, whose outgoing routes are B and C, are aggregated into a prefix of 2/8. We should 596

3 note that even if 2.96/4 and have different outgoing routes, they are aggregated into a single prefix 2/8 in the cache table. The proposed method may add extra nodes whose prefix lengths are either 8, 6, or 24 and cache the pointers to these nodes after the prefix aggrefation has been performed. Routing table Figure 5: Prefix aggregation. L Aggregated pointer to pointer to CAM8 Table shows that the relationship between the category and the prefix length. The prefixes classified into one of three categories 8, 6, and 24 are stored separately in three CAMs, which we call CAM 8, 6, and 24. Namely, CAM 8 contains pointers to the nodes whose rounded prefix length is 8, and CAM 6 and CAM 24 likewise. The number of entries of CAMs should be much smaller than that of the routing table. Pointers for prefixes whose length is in the range of 8 to 5, 6 to 23, and 24 to 32 are cached in CAM 8, CAM 6, and CAM 24. Each entry in the cache table has a pointer to an intermediate node in the tree. Table Relationship between category and prefix length. Category Prefix length LXFl if; y6 When we get multiple hits in those CAMs, we select the CAM whose prefix is the longest. In this case the number of CAMs is only three, so we can reduce the complexity of the handling mechanism for the multi-hit situation (A simple three-to-one priority encoder can handle it). Because we perform the longest match in selecting CAMs, we can limit the search range and keep the worst-case node traversal time constant. For example, if CAM 6 is selected, the search range is limited between prefix lengths of 6 to 23. The worst-case node traversal time is eight, which is one-third of that of the conventional method. 2) Tree traversal The cache table has pointers to intermediate nodes in the tree whose prefix length is either 8, 6, or 24. We refer those nodes as aggregation nodes. A Patricia tree has two types of nodes. A node which has the outgoing route is referred to as a valid node, while a node that does not is referred to as a nonvalid node. The non-valid node is just a branch to either of two child nodes. In our method, these two types of nodes can be aggregation nodes, and aggregation and non-valid nodes may be added to the Patricia tree, if necessary. Once the pointer to an aggregation node has been determined, the Patricia tree traversal gets started. In ou method, the search range is limited to between two aggregation nodes. For example, if we start at the aggregation node whose prefix length is 8, the tree traversal is halted before we reach the next aggregation node whose prefix length is 6. Because the longest match is performed in selecting the CAM as mentioned before, the tree need not to be reached beyond the prefix length of 6. Doing the longest match in selecting CAM guarantees that there are no prefixes that match the address having a prefix length of more than 6. Our method returns the longest matching prefix in the search range. There is a case where we do not find any prefixes that match the network address in question because we perform prefix aggregation. Prefixes which are not in the routing table are aggregated into the aggregation node. For example, 2.8 /I 3 which is not in the routing table in Fig. 5 is aggregated into 2/8 in the cache. Therefore there is a situation where we do not find any prefixes in the search range. We store the default route at the aggregation node so that we can determine the outgoing route when we encounter a "no-match" situation in the search range. If we do not have any matching prefixes in the search range, the starting aggregation node stores a default outgoing route if it is not a valid node. Such a default node is determined by consulting the above tree. Of course, if the aggregation node is a valid node, the default outgoing route is not needed. The default outgoing route is the outgoing route of the longest match prefix of the node. Figure 6 shows an example. We assume that 0.0/9 and /22 are valid nodes and that 0.86 is an aggregation node for /22. Because the aggregation node 0.8/6 is not a valid node in this case, it has the same outgoing route as its longest match prefix valid node 0.0/9. According to the above mentioned rule, is routed for the outgoing route X and is routed for Y Figure 6: Tree traversal. Our method can be applied to a Multi-way tree, which is faster than the Patricia tree but it requires a lot of memory. It enable us to reduce the memory size because it limits the height of the sub-tree in each search range. Figure 7 shows an example. 597

4 NH=Y 0/4 NH=Z Figure 7: Multi-way tree. c2 Newnode Root node NH=Y 0/3 NH-Y 000/6 00/6 00/6 0/6 NH=Z NH=Z NH=Z NH=Z 0 Valid node. I Aggregationnode B. Insertion and deletion of a node I The routing table is subject to change due to changes in the network topology. If a new prefix entry is added to the routing table, a new node is added to the tree. Figure 8 shows the node insertion procedure for our method. We search for the place where the the new node is inserted from the root node of the tree at the beginning of procedure. The normal searching process is executed until we find the place, where the new node is inserted. Once we arrive at the place, where the new node is inserted, the following two steps are executed. First step is to add the new node. Second step is to search for all aggregation nodes which are needed to change the default outgoing route by adding the new node. If the new node has child node, only the first step is executed. Otherwise first and second steps are executed. The first step Three cases are considered. StepI-la If the new prefix is identical to the rounded prefix, the new inserted node becomes an aggregation node. StepI-lb If the new node doesn't become an aggregation node and the parent node of the new node exits in the difference categories, an aggregation node needs to be inserted as well. The route memorized just before finding the place becomes the default outgoing route for the aggregation node. Step I-lc If an aggregation node needs not to be added, we just insert the new node. If an aggregation node needs to be added, the corresponding CAM entry is also added in first two cases. When we insert the new node, we must insert a non-valid node, if necessary. '-la just add \ I-] Aggregation node e n [F) -2 - Figure 8: Node insertion. non-valid node 6 r"=e)e"=ej - To search quickly for all aggregation nodes which are needed to change the default outgoing route, we add an agregation link pointer. This is a pointer to an aggregation node which has the common default outgoing route. Figure 9 shows how we set these pointer to aggregation nodes and new nodes are inserted. If the aggregation node which is a non-valid node is insert, we set the aggregation link pointer to this node by traversing aggregation nodes which has the common default outgoing route from valid node which has the origin route. Inserting the new node referred to "NH=B" in Fig. 9 shows the example of this process. We have to memorize the aggregation link pointer from valid node to practice this process on the way of searching for the place to insert the new node. Using this pointer enables us to traverse aggregation nodes which have the common default outgoing route. So we can search quickly for all aggregation nodes which are needed to change the default outgoing route by inserting the new node. Figure 9 also shows that the aggregation node changes the default outgoing route. In this case, the aggregation link pointers are needed to be renewed. non-valid node n a n Figure 9: quick insertion. ' from A to C Newnode The second step The second step is needed only when the new node has a child node. STEPI-2 We must search for all aggregation nodes which are needed to change the default outgoing route. These nodes are located in lower height of the tree than the new node and are non-valid nodes. Figure 0 shows the node deletion procedure for the our method. We start the procedure to search for a deleted node from the route node like the insertion procedure. We must practice two step at the worst case after finding the deleted node. First step is to delete the node. Second step is to search for all aggregation nodes which are needed to change the default outgoing route by delete the node. Second step isn't 598

5 needed when the delete node doesn't have any child nodes. The first step We execute the normal deletion process except special two cases. StepD-la First special case is that three conditions is met. (I) the deleted node doesn't have any child nodes, (2) the parent of the deleted node is the aggregation node which doesn't have other child, and (3) the parent node is a non-valid node. In this case, we delete the aggregation node and the deleted node. Step D-lb Second special case is that the following four conditions is met. () the deleted node has only one child node, (2) the parent of the deleted node is the aggregation node which doesn't have other child, (3) the parent node is a non-valid node, and (4) all children of the deleted node located in difference category of the deleted node. In this case, we also delete the aggregation node and the deleted node and a non-valid node,if necessary. Step D-lc Except special two cases, we just delete the deleted node and a non-valid node,if necessary. The second step Second step is to search for all aggregation nodes which are needed to change the default outgoing route by deleting the node. This step is executed when the deleted node has child node. STEPD-2 We must search for all aggregation nodes which are needed to change the default outgoing route by deleting the deleted node.these nodes are located in lower place of the tree than the deleted node and are non-valid nodes. Figure shows the example to renew the aggregation link pointers in the case of "Step D-la" and "Step D-2". By memorizing the aggregation link pointer from valid node on the way of searching for the deleted node, we can use this pointer to traverse aggregation nodes which has the common default outgoing route. Deleting the deleted node in the case of Step D-la and Step D-lb, we have to renew the aggregation link pointer to keep it to point a proper node. In the case of Step D-2, we also have to memorize the aggregation link pointer from the deleted node to know aggregation nodes which are needed to change the default outgoing route. To memorize these two aggregation link pointers enables us to set the aggregation link pointer properly. C. Patricia tree table reduction In the Patricia tree, each node has a prefix. The network address is compared with the prefix of each node as the tree traversal proceeds. Each node has storage for at most 32 bits prefix int the case of IP v4. Because prefixes in IP v6 could be up to 28 bits long, a huge memory size is required to store them at each node. Our method eliminates common prefix Figure 0: Node deletion. link Dointer Figure : quick deletion. don't change amreclation delete two nodes a deleted node change route from E to C change route from C to A -.a set pointer deleted node information between adjacent nodes and reduce the memory size. It has K bits of storage for prefix information at each node. The difference between 0******/2 and 000 ***I5 is **00***. Because the significant bit length is three, three bits of storage are sufficient. If the significant bit length of the difference between two adjacent prefixes is larger than K, new nodes are added to the tree to make the significant bit length is smaller then K. Those nodes are referred to as connection nodes. The first upper K bits of the difference are stored at the first connecting node, the second upper K bits are stored at the second connection node, and so on. In this way, the difference between the prefixes of two adjacent nodes is segmented into multiple K bits and stored in connecting nodes. In addition to the above memory size reduction, we can cut one bit by omitting the reference bit, which is used to decide which child-should be reached at the next traversal. The pointers to left and right children are used for the same purpose, so the reference bit is redundant. Figure 2 shows an example where the network address is 8 bits long and the size of the difference of addresses K is 4. At a parent node, the reference bit is examined. If it is 0, the left child is reached. Otherwise, the right child is reached. Concatenation of the reference bit and the difference stored at the child node is used as the difference in addresses of the parent and child nodes. In this example, node U has a difference 0**/2 and the difference between nodes U and S is 00*/3. 599

6 Our method enable us to keep the memory size for each node constant independent of the address length. If we use it for IP v6, we can reduce the memory size from 28+7+R to 7+R if K=7, where R denotes the memory size required for pointers to children and the outgoing route identifier. Figure 2: Memory reduction.. PERFORMANCE EVALUATION A. Routing table data To evaluate our method, we used actual data of an IP backbone network [3]. The routing table had 43, 499 entries. Figure 3 shows the distribution of prefix lengths of the routing table data. Almost half of the prefixes had a length of 24. We constructed a Patricia tree for the data and evaluated the average search depth for it. The average search depth is defined as the average number of node traversals for randomly generated IP addresses. The average depth was5.7, which implies that we need to traverse 5.7 nodes on average to look up the outgoing route in the routing table. io5,,,,,,,,,,,,,,, I I,,, l I,, I I, l I the prefixes were 24 bits and we set the aggregation prefixes to 8, 6, and 24. Since prefixes whose length is 24 cannot be aggregated into smaller ones, the aggregation effect was very small. We devised a way to aggregate prefixes of length 24 into smaller ones. We thought that offsetting the aggregation points would reduce the memory size of CAMs. We introduced an offset parameter b to reduce the memory size of CAMs. Namely we set the aggregation prefix lengths as 8+b, 6+b, and 24+b, where 0 < b < 8. Figure 4 shows the CAM size as a function of b. Offsetting the aggregation prefix by one (b=l) is the most effective (the CAM size is reduced to about 5,87 entries which is less than one-eight of the total number of entries in the routing table). By offsetting the prefix length of 24 by one, prefixes whose length is between 7 and 25 are aggregated into prefix length of 7. Many prefixes whose length is 24 are aggregated into the one whose length is 7. Aggregating prefixes leads to a need for extra node traversals. There is a trade-off between the search depths and the CAM size. Figure 5 shows the average search depth as a function of b. Offsetting the aggregation prefixes increases the average search depth. When we offset them by one (b=l), the average search depth becomes the highest (about 3.2). However the value is still much less than that of the conventional Patricia (Recall that Patricia requires an average search depth of 5.7). We argue that offsetting by one is the most effective for reducing the CAM size at the expense of a small increase in the average search depth. x 000, I I, I a Y G 04 g /24/99 Mae-East b Figure 4: CAM size as a function of the offset value b. Prefix length Figure 3: Prefix length distribution. B. EfSect of pointer cache I We evaluated the effect of pointer caches used in our method. We found that the average search depth was reduced to about.5 (one tenth of that in the conventional Patricia tree). The worst-case search depth was obviously the search range, i.e., eight. The memory size of CAMs 8, 6, and 24 amounted to about 3, 427 entries. We cut 2, 072 entries out of the 43, 499. The reduction was not so large because almost half of C. Tree memory size requirements Our method may add extra nodes to the Patricia tree to create the aggregation nodes (If there are nodes at the aggregation prefix length, we do not have to add the extra node). This potentially increases the memory size of the tree. We evaluated the tree s memory size, calculating it on the assumption that tree table can have 28, 000 prefix entries, and store 5 bits for the index of the Next-hop table. So the memory size for one entry is 89 bits in the Patricia tree table (Fig. 7) and 5 bits in the Multi-way tree table. Figure 6 shows the tree memory size as a function of b. The memory size is more than twice that of 600

7 ' 3.5 c 3 E w &, z L 0 2 LI h Figure 5: Average search depth as a function of the offset value b. the conventional Patricia, but the memory requirement is still feasible using current hardware technology. The Patricia tree is more efficient in memory consumption than the Multi-way tree. As Fig. 6 shows memory size little dependence on b for the Patricia tree, whereas it increases with b for the Multi-way tree. The Multi-way tree needs more memory because it requires redundant nodes. than that of the Patricia tree. With an offset of one, the Multi-way tree requires.5 times the memory size of the Patricia tree. As the offset increases, the number of redundant nodes and the memory size both increase. The Multi-way tree has full entries and the search depth is exactly one. By using the Multi-way tree with an offset of one, we achieve fast table lookup with a small increase in tree memory size. 6,,, I 5 0 Patricia tree 0 ',, I I I h Figure 6: Tree memory size as a function of the offset value b. D. Efect of Patricia tree table reduction We calculated the memory size on the assumption that the tree table can have 28,000 prefix entries, and stores 5 bits for the index of the Next-hop table (Fig 7). Random IP addresses were generated to count the number of searches. Table 2 shows the results of comparing the memory size and number of searches by the conventional Patricia and our method. The difference 2 bits means that the tree table has 2 bits to store the difference in addresses of two adjacent nodes. We calculated the memory size on the assumption that one entry in the tree table needs 89 bits for typical a Patricia tree table, 56 bits for the difference 2 bits, 59 bits for the difference 4 bits, and 64 bits for the difference 8 bits. One entry in the tree table needs fixed number of bits for the pointer to child node and the index of the Next-hop table. Because the ratio of IP address bits to the total number of bits for one entry of IP v6 is more than that of IP v4, our method will be more effective in tree table memory reduction. Limiting the width of storage size for the difference between prefixes enables us to add extra connection nodes as mentioned in Section C. This increases the memory size, which is a potential drawback of our method. - We examined the impact of the extra connection nodes. Comparing average number of searches, we found little difference between the conventional method and our method, showing that the impact of the extra connecting nodes is negligible. Thus we argue that the table entry memory reduction idea of our method achieves memory reduction at the expense of a small increase in the search time. 89bits bits Figure 7: Tree table entry. I I E:lefl child exit. or not 0dddmss:polnlsr to I& child E:rigM Child ex9 or not -addrew:poinler lo right child NENext-hop exit8 or not Table 2 Number of searches I and memory size in conventional method and our method. proposed tree table difference difference difference ~ ~ ~ l ~ a l 2 bits A hits A hits Memovsize : :5 : : 6 (k byte) Ave. number of searches Max. number of searches Iv. RELATED WORK Recently several methods has been proposed for an efficient IP datagram transport mechanism. They fall into two categories. The first is to use the label swapping technique. The label is used to expedite packet identification. A small, fixed-size label such as VCI for ATM is used [4, 5, 6. These methods can foward a packet quickly just doing exact matching. These are suited to provide quiality of services in small network. But these are less scalable than the longest matching prefix method. It is difficult to use them in large network whether a label is assigned by flow driven or topology driven. These also require a label binding protocol and it takes time for them to be deployed extensively. In general it takes a considerable time for new 60

8 protocol to become a proven technology. The other is to use the longest matching prefix method. Because it does not require any protocol change, it can be easily deployed [7, 8. A survey of recent longest match methods was compiled by Varghese [9]. They classified into them software-based [IO,, 2, 3 and hardware-based [ 4, 5, 6, 7 approaches. A sophisticated binary search algorithm for selecting the longest prefix using a hash function was proposed [2]. Even though a cyclic redundancy check (CRC) code may be used for the hash function [ 8, the performance is probabilistic. An algorithm for making the routing table compact was proposed [ 3. If the data structure is made compact, the total routing table can reside in cache memory in a state-of-the-art processor. The performance of software-based approaches depends on the clock rate and the cache size of the processor. The performance is probabilistic and somewhat difficult to predict. Hardware implementation of Trie was examined [ 4. and hardware implementation of the Patricia tree using pipelining was proposed [ 6. Practical hardware implementation of the Multi-way tree for IP v4 was proposed [ 7. The performance of hardware-based approaches is easier to predict that that of software-based ones. Our method is suitable for hardware implementation to achieve predictable worst-case performance. We argue that our method achieves fast table lookup and a small table size for very long network address such as IP v6, which cannot be achieved with previous methods. v. CLOSING REMARKS We proposed a fast and compact longest match table lookup method for very long network address. We have shown that our method is effective at decreasing the number of searches and the memory size using an actual routing table composed of IP v4 address prefixes. In future work, paying attention to the assignment of IP v6 address, we will implement these proposals. IEEE/ACM Trans. Networking, vol. 6, no. I, pp , Feb Washington University, Washington University Workshop on Integration of IP and ATM, St. Louis, MO, Nov. 996, wustl.edu/arl/workshops/ipatm/proceedings. html/. 9 G. Varghese, Building fast routes: from ATM to best matching prefix, in Hot Interconnects VI, Aug [lo] G. R. Wright and W. R. Stevens, TCP/IP illustrated volume 2: The implementation, Addison-Wesley, 995. [ll] W. Doeringer, G. Karjoth, and M. Nassehi, Routing on longest-matching prefixes, IEEEIACM Trans. Networking, vol. 4, no., pp , Feb [2] M. Waldvogel, G. Varghese, J. Turner, and B. Plattner, Scalable high speed IP routing lookups, in ACM Sigcomm 97, Sept [3] M. Degermark, A. Brodnik, S. Carlsson, and S. Pink, Small forwarding tables for fast routing lookups, in ACM Sigcomm 97, Sept [4] T. B. Pei and C. Zukowski, Putting routing tables in silicon, IEEE Network Mag., pp , Jan [5] A. J. Mcauley and P. Francis, Fast routing table lookup using CAMS, in Proc. of IEEE Infocom 93, 993, pp , San Francisco, USA. [I6 A. Moestedt and P. Sj odin, IP address lookup in hardware for high-speed routing, in Hot Interconnects VI, Aug [ 7 P. Gupta, S. Lin, and N. McKeown, Routing lookups in hardware at memory access speeds, in IEEE Infocom 98, Mar [8] R. Jain, A comparison of hashing schemes for address lookup in computer networks, IEEE Trans. Commun., vol. 40, no. 0, pp , Oct VI. REFERENCES [l] K. G. Coffman and A. M. Odlyzko, The size and growth rate of the Internet, Tech. Rep., 998, [2] R. Sedgewick, Algorithms in C+ +, Addison-Wesley, 990. [3] [4] G. P. Chandranmenon and G. Varghese, Trading packet headers for packet processing, IEEWACM Trans. Networking, vol. 4, no. 2, pp. 4-52, April 996. [SI P. Newman, T. Lyon, and G. Minshall, Flow labelled IP: a connectionless approach to ATM, in Proc. of IEEE Infocorn 96, 996, pp , pd. [6] E.Rosen, A.Viswanathan, and R.Callon, Multiprotocol Label Switching Architecture, Internet Draft, Apr 999. [7] C. Partridge et al., Fifty gigabit per second IP router, 602