Content-Based Route Lookup using CAMs

Transcription

1 Content-Based Route Lookup using CAMs Yan Sun School of Electrical Engineering and Computer Science Washington State University Pullman, Washington , U.S.A. Norbert Egi, Guangyu Shi, Jianming Wu Huawei Technologies (USA) 2330 Central Expressway Santa Clara, CA 95050, U.S.A. {Norbert.Egi, shiguangyu, Abstract The applications of the Internet have evolved from being host-centric to being more content-oriented, such as file sharing, online audio and video applications, which constitute the majority of Internet traffic [1]. Several future Internet architectures, putting the content (or information) in the forefront, have lately been proposed in order to solve the limitations of the current architecture (i.e. insufficient bandwidth to servers, lack of security, mobility, virtualization, user/data centricity, etc.). However, one of the greatest challenges of a novel contentoriented Internet architecture lies in the complexity of looking up long, variable length names compared to the current 32 bit long IPv4 (or even 128 bit IPv6) addresses of today s networks. The success of widely adopting any content-oriented architecture highly depends on the success of designing algorithms that allow these complex names to be looked up at high-speed. Ternary Content Addressable Memories (TCAMs) are widely used in high-speed routers to find matching routes for packets in a routing table. They enable the longest prefix matching (LPM) operation on fixed length addresses to complete in a single clock cycle, however, they are not efficient to store and lookup name prefixes with variable lengths such as the ones proposed in namebased routing [2] [9]. In this paper, we propose an efficient namebased longest prefix matching algorithm for information-centric networks using TCAMs. In our algorithm, we split incoming prefixes in fixed blocks and subsequently hash these blocks for fixed length storage. Our approach is flexible to support both hierarchical name based routing lookup and flat name based routing lookup. In addition, our approach can be easily modified to support multiple matchings 1 instead of the longest prefix matching. The simulation results demonstrate that our approach is able to provide efficient name-based routing lookup even for the fastest backbone routers (i.e Gbps). Index Terms Information-centric networks, Name-based routing, TCAM I. INTRODUCTION The Internet was originally designed to exchange information between two nodes and IP addresses are used to identify the different nodes and to route packets to their destinations. When one node requests a service, the requested domain name will be translated into a globally unique IP address by the domain name system (DNS), and the communication is carried out based on the IP addresses. However, the majority of today s Internet usage is about accessing some form of content (i.e. web pages, audio and video files, file sharing, etc.) and users care more about the content a given service provides and do not know and in 1 By multiple matchings we mean the case, when all the prefixes that are matched are considered for forwarding and not only the longest one. the majority of cases do not even care about the location of the service or requested data. However, the communication is still based on the locations (i.e. the address of the node the given service or data resides on) not the content itself. Several content-based network architectures 2 have been proposed in the last years [2] [9]. The major difference between hostoriented and content-based network architectures is the shift of the identifier from IP addresses to the name of the content, which can take many forms, from URL-like variable length hierarchical names [2], [10] to flat names [11], [12] or other specified content name structures. Thus, designing efficient name prefix based route lookup algorithms is key to the adaptation of future content-centric Internet architectures. The major challenge comes from the fact that while IP addresses are fixed in length content names can vary and typically are also significantly longer. In the world of IPv4, the lengths of IP prefixes are between 8 and 32 bits and the input keys (i.e. destination IP addresses) are always 32 bits wide. However, in name-based routing lookup, the lengths of the names and their prefixes are virtually unlimited. Thus, traditional approaches, especially hardwarebased approaches are not suited in this new environment. In this paper, we discuss the challenges of name-based longest prefix matching, and propose an efficient algorithm to solve problems caused by the name-based routing properties. Because content-based routing is still in a rather early stage, we made our approach flexible enough to meet multiple proposed name-based routing requirements. We first introduce our approach based on the assumption that names are hierarchical, and then show how our approach can support flat name based routing lookup. The remainder of this paper is organized as follows. In Section II we briefly review the methods used in IPv4 longest prefix matching algorithms. Section III details the design of the proposed scheme for longest prefix matching in namebased route lookup. Section IV evaluates the achievements by our scheme and Section V discusses the scalability of our approach. Section VI compares the most-widely used longest prefix matching algorithms. Section VII concludes the paper. II. BACKGROUND A routing table in a router stores variable-length IP address prefixes and corresponding outgoing ports [13]. When a packet 2 We use the terms content, information and data interchangeably.

2 arrives, a router searches for the longest prefix match of the destination IP address stored in the packet, and then retrieves the corresponding outgoing port through which the packet has to be forwarded to next-hop node in the network. Since the speed of this procedure is the key to the overall performance of routers, many approaches have been proposed to overcome the bottlenecks of route lookups, both in the form of software and hardware-based solutions. In order to achieve high throughput of the name-based routing lookup, we focus on the hardwarebased approach and mainly use TCAMs to store prefixes. Our proposal is in fact using a hybrid of TCAMs and BCAMs to reduce hardware consumption, and we will discuss the details in the next section. Ternary Content Addressable Memories (TCAMs) have been widely adopted by routers to improve the speed of the longest prefix matching operation. They allow the don t care state to be stored in each memory cell besides the binary states 0 and 1, a critical feature for high-speed LPM operations. A memory cell in a don t care state matches both 0 and 1 in the corresponding input bit. A TCAM-based routing table is extremely fast because it allows the input key (i.e. an IP address in IP networks or the name of the content and contentcentric networks) to compare with all the prefixes stored in the TCAM simultaneously and retrieve the result in a single clock cycle. The architecture of a TCAM used for longest prefix matching in IPv4 networks is shown in Fig. 1. Input Register (key) Entry 0 Entry 1 Entry N--2 Entry N -1 Fig. 1. match vector TCAMs used in the Routing Tables priority encoder Log N output A key (destination IP address) is stored in the input register and each prefix is stored in a single entry. The key compares with all the prefixes in parallel and the results are stored in the match vector, where 1 s indicate that the corresponding entries matched the key, and the priority encoder chooses the longest prefix match. In the last step, the output signal is used to find the corresponding outgoing port. While the TCAM-based solutions are very fast, we have to note that TCAMs have two major disadvantages: high cost of production and high power consumption. In fact, both of them result from the circuit complexity of each TCAM cell. A typical TCAM cell requires two SRAM cells to store both the value bit and the mask bit, and four transistors for the match logic. A typical SRAM cell requires six transistors, which means each TCAM cell requires 16 transistors, which is about 2.7 times more than what can be found in a typical SRAM cell [13]. Therefore, how to use TCAMs efficiently becomes a critical issue. Several solutions have been proposed to tackle these problems, such as dividing the TCAMs into several small blocks and only trigger a subset of them each time. Compared to TCAMs, Binary CAMs (BCAMs) require much fewer transistors and less power because no mask is needed and the comparison circuit is simpler. However, they can store only 0 and 1; they don t have don t care state. III. PROPOSED ALGORITHM Compared with IP based forwarding, there are two sets of challenges in content based forwarding. First, the length of name to look up is variable and is not limited to 32-bit IP address for IPv4 or 128-bit for IPv6. Similarly, the length of name prefix is not bound in content based forwarding. That means the performance of traditional software based approaches will degrade dramatically, such as the tries, will become much more deeper in Trie-based approaches. In order to store variable length prefixes into limited fixed length TCAMs, we propose to hash these prefixes into short hash values. As discussed above, we first propose our approach based on hierarchical name prefix routing lookup, such as URLs or file names in a network. A simple way is to hash all the name prefixes into a fixed length value based on their segments, then the segments of the incoming name are hashed and matched against the name prefixes one by one, as illustrated in Fig. 2. Fig. 2. Prefix: /abc/d/ef/ hash(/abc/) hash(/abc/d/) hash(/abc/d/ef/) Prefixes of variable length hierarchical names hashed to fixed lengths However, segments usually have different lengths, which makes them inefficient to be implemented in hardware. Instead of using segments as processing units, we use a fixed length of block as the processing unit and include the delimiter character(s) as part of the name as described below. This approach has the following advantages: 1. It is efficient to be implemented in hardware, because it is easy to process a fixed length of incoming name in a clock cycle through methods such as hashing. If we chose to process a variable length name in hardware, we would still need to cut the name into small pieces of fixed length and process one piece in a clock cycle. 2. It is more scalable than segment based approaches, because we only need to increase the length of blocks. 3. The throughput is predictable. This is because we process a fixed portion of the incoming names for each clock cycle, while the processing speed of segment based approaches

3 depends on the number of segments and the length of each segment in the incoming name. 4. It is safer than segment based approach. Attackers can insert a high number of delimiter characters (e.g. / ) into the name to take down the processing speed. However, our approach can easily bound the length of incoming name to be checked and we will discuss this in the following sections. 5. It is more general, because it can be used with any variable length names, regardless of whether it is a hierarchical name where segments are separated by delimiters (e.g. / ) or it is a flat name without any explicit segmentation. So in this paper, we hash the name prefixes and incoming names block by block. We first set the block length to -bit and use CRC- as the hash function to hash multiple -bit blocks to a single -bit value. We will discuss other block lengths and other hash functions in the discussion section. In order to store each name prefix in a single TCAM entry, we need to hash the variable length name prefixes into values with fixed length. Assume the length of a name prefix is n (in bits), and the length of a block is m, so the number of whole blocks is n/m, and we call these blocks the head of a name prefix, and call the remainder part the tail of a name prefix, then the length of tail is n%m. If we hash these whole blocks and tail together and store them in the TCAM, we can only perform exact matching. In order to perform longest prefix matching instead of longest exact matching, we need to deal with the whole blocks and the tail separately. We propose to hash the first n/m whole -bit blocks of the name prefix to a single -bit value and store it in the BCAM and the remaining n%m bits are stored in the TCAM padded with (- n%m) don t care bits. So the whole blocks part performs exact match with exact length, and the tail part performs longest prefix match with bounded length. The process of storing a prefix into a TCAM entry is shown in Fig. 3. Prefix Counter Prefix head Prefix tail ( n / m )* m bits ( n % m ) bits CRC- BCAM(16-bit) CRC Round Prefix head Prefix tail Fig. 3. Storage of a name prefix in a single CAM entry So in our design, we store the whole blocks part in a -bit BCAM to reduce hardware resource consumption, and store the variable length tail part in a -bit TCAM. In order to reduce the CRC calculation rounds of the prefix head (i.e. n/m ), we store the remaining -bit block as the prefix tail in TCAM when the length of the prefix is multiple of. In the case the length of a name prefix is smaller than or equal to -bit, the BCAM will be empty (and Round equals 0), and the prefix will be stored in the TCAM padded with - n%m don t care bits in corresponding TCAM. We store the number of CRC round in the beginning to reduce the hash collision rate. During matching, the incoming name will be processed similarly to name prefixes during storage. The first i (i=0,1,2... ) -bit blocks will be iteratively hashed into a -bit hash value, combined with the next -bit data in the incoming name and compared against the data stored in the BCAM and TCAM, respectively, both in the same cycle. Note, that in every iteration we only need to calculate the CRC value of a single -bit block as the values of the previous calculations are reused. In addition, if power savings are more important than speed, one can pipeline the lookup of the BCAM and TCAM, as the TCAM only has to be looked up once a match has been found in the BCAM. However, if speed is more important (like in our case) performing the match in both the BCAM and TCAM at the same time is preferred. We repeat the process of shifting the incoming name by -bit chunks until we reach the end of it. After this, the match vector is checked and the longest prefix match or depending on the routing algorithm multiple matchings are found. If the length of an incoming name is shorter than -bit, we only need to look up the TCAM. Note that every match found in the look up table represents a match for the exact prefix stored in the given TCAM entry, thus, if there is an update by the routing protocol for a sub-prefix of an already existing prefix in the table, this new (sub-)prefix needs to be added to the table too similarly to how it s done in IPv4 network (e.g. if /a/b/c/d/ is already present in the table and a new update with /a/b/ arrives for the same output, we need to store this new prefix in a separate entry). The processing architecture is shown in Fig. 4. In Fig. 4, we demonstrate a configuration with CRC- as hashing function with 128-bit incoming data, which can be easily implemented in hardware. When the CAMs detect a match, we record the matching entry number. We must update the matching entry when we find a new match, because the incoming name is processed in multiple iterations, one -bit block at a time, so the most recent match will represent the longest prefix match we are looking for. However, there are some challenges left that need to be addressed. First, how to store the name prefixes in the CAMs efficiently. Second, how to detect and reduce hash collision. Third, how to increase the efficiency of the lookup algorithm by recognizing when to stop processing an incoming name after there are no more prefixes left that would match the name, even though we have not reached the end of it yet. The approach described below solves these challenges. First of all, we propose to group the entries in a manner outlined below and store a group ID for every entry of the lookup table in an SRAM. If there is an entry in the lookup

4 Entry0 Entry1 Counter Name Round Round Entry( n -2) Round Entry( n -1) Round Fig. 4. Current window -bit CRC- Next window -bit The proposed architecture using TCAMs match record table that is a prefix of other entries in the table, all these entries including the shortest one are allocated a unique group ID and stored in a SRAM with the belonging entry numbers. For example, in Fig. 5, prefix1 is the prefix of prefix0, so they are grouped together. For each group, the shortest prefix is the prefix of all other entries in the same group and it does not overlap with any entries in other groups. Thus, every incoming name can only match entries in a single group. Based on this property, we sort name prefixes within their group in order of decreasing lengths. 3 In addition to the group ID and the entries in a group we also store the length of the longest prefix in every group. This value is used to improve the efficiency of the lookup algorithm by making sure that we do not process an incoming name any further than the longest prefix in the group it has already found a match in. This ensures that the clock cycles needed to lookup a name is bound to the longest name prefix in its group. Based on this, after a first match is found in the table the group ID for that given entry is looked up and the length of the longest prefix in the group is copied to the Counter register, which ensures that no incoming name is processed any further than needed. Once that point has been reached, the lookup process is stopped and the priority encoder selects the longest prefix matched (i.e. the top most entry in the table) and fetches the corresponding output port from the SRAM. Another advantage of separating name prefixes into different groups is that we only need to sort prefixes (based on their lengths) within their group instead of globally. Normally we would need to sort ALL the prefixes relative to ALL other entries stored in the CAM, which makes it hard to update any name prefixes, because any change (i.e. replacement, addition, removal) in one entry may affect all other entries in 3 This way of ordering entries in the CAM is common practice in today s IPv4 routers. the TCAM. However, after separating prefixes into different groups, any change in one name prefix can only affect name prefixes within the same set because all these sets can be stored out of order. So this approach also improves the update performance in TCAMs. In addition to the above mentioned advantages of our grouping methodology, undetected collisions can only happen in two continuous name prefixes within the same group, and we claim that this kind of collision can be disregarded in real applications for the following reasons. First, in theory, the possibility of finding two messages with the same hash value is 2 or 1/ using CRC-, which is considered not strong enough only for some applications with large data to be hashed such as files or protein sequences [14], however, in the case of name prefixes with the length up to several hundred characters only, it is considered to be a very strong collision free hash function. In addition, the collision must happen in different parts of these two name prefixes, and such difference is usually very short compared with files. For example, in Fig. 5 we show two name prefixes and an incoming name. In this example, the hash collision can only happen in the field represented by asterisks, because the part before this field should also match the second name prefix and the corresponding collision can be detected, and the part after this field must match the TCAM field or be stopped by the longest name prefix in this set, which is the first name prefix in this example. Fig. 5. Name: firstseg ment/ *** ******** nt/... Prefix0: firstseg ment/sec ondsegme nt/ Prefix1: firstseg ment/ A simple example of collision can happen and cannot be detected That becomes another problem: given a -bit number v and a short number d 0, which represents the different part of two continuous name prefixes in the same set, is it computationally infeasible to find a number d 1 with the same length of d 0 such that CRC(d 0 ) = CRC(d 1 ). A. Flat Name Based Routing Lookup and Multiple Matchings The algorithm we have discussed is based on the assumption that the name-based routing is hierarchical and the longest prefix is searched for. As a matter of fact, our proposed lookup algorithm treats the hierarchical names as flat names, as it does not deal separately with the separator character(s) between the segments of hierarchical names, so our approach can equally be used for flat name based routing lookup. In our algorithm, we have shown how to perform longest prefix matching and how to get a single result for each match (i.e. the one with the longest prefix). In order to support multiple matchings instead of the longest prefix matching, we only need to remove the priority encoder after the TCAM entries and record all the matched entries. As we separate the name prefixes into a number of groups as discussed above,

5 TABLE I THE PROPERTIES OF GENERATED URL PREFIXES URLS Properties URL Prefixes URLs Number 100, ,284 Average length (segments) Average length (characters) Longest length (segments) Longest length (characters) multiple matchings happen only in continuous name prefixes within a single group, making it also significantly easier to record all the matchings. IV. EVALUATION As a realistic trace for names, we collect 314,284 URLs collected from several universities servers in the US, which represent the most popular URLs queried by users of the given universities. However, there is no prefix rule set and output ports for URLs. So we generate our name prefix rule set based on these URLs and the prefix length distribution property shown in [13]. We generate 100,000 URL prefixes based on the collected URLs and properties of these URL prefixes. The properties of the URLs are shown in TABLE I. We implement our approach on Xilinx Virtex-5 TX240T FPGA. We pipeline our design to increase throughput by dividing it into four stages: incoming name process, crc calculation, CAM matching and result finding. We assume the packet size is 4kB, which is a realistic packet size in Content- Centric Networking [2]. We test the URL lookup speed in real hardware through simulation of URL lookups and calculate the packet and bit rate. With different number of name prefixes, the hardware resources and throughput of name-based routing are shown in TABLE II. We can see that our approach can achieve high throughput, well exceeding current backbone networks speed. We did not simulate more prefixes because of the limitation of hardware resource in the FPGA, but it is well-scalable because each prefix consumes one TCAM entry, similar to TCAM based IP prefix matching. V. DISCUSSION We discussed that our approach can detect most kinds of hash collisions except two continuous name prefixes in the same set. Even though we did not find such collision in our simulation and we have analyzed that the possibility of such collision is very small, we need a scheme to detect it in some applications. One way is to check for the different part between the two name prefixes when we shift from a shorter match record to a longer one. Fortunately, the number of such substrings is small and their length is very short, and we do not need to consider the length of different part less than - bit because CRC- can detect any error below that length. For example, in Fig. 5, we only need to check the first four characters located in field represented by. Our approach can be easily extended to process longer blocks, such as 128-bit block. We just need to use CRC-128 and extend the width of CAMs. In some applications, a small percentage of hash collisions are tolerable, then we can shorten the blocks to 32-bit or even 16-bit to reduce the usage of TCAMs and CRC-32 or CRC-16 will be used respectively. Furthermore, we can use other hash functions instead of CRC calculation used here, and the collision detection approach does not need to be modified. Compared to software-based routers, TCAM-based solutions can store much less prefixes at a time. As an example, Juniper s new products (M120 and MX960) with DRAM rather than TCAM/SRAM has a capacity in the order of 2 million IPv4 prefixes, however a single 20Mb TCAM chip can only store about 625,000 IPv4 prefixes. According to [15], a high-end name-based router needs to handle about 280 million globally unique and routable hostnames. However, TCAM should only store the hot entries as part of the fast path, while the less frequently looked up names can be stored in the slow path and moved to the fast path based on well established caching and replacement algorithms. VI. RELATED WORKS There are three major categories of approaches used for longest prefix matching, including hash-based approaches, trie-based and CAM-based approaches. We will discuss them separately. a) Hash-based solutions: Hash-based routing lookup table approaches [16] [18] hash prefixes and store them in a hash table for later look ups. They are memory efficient but the hash-based approaches do not deal with variable lengths well, so they need to process prefixes with different lengths separately or expand short prefixes to long prefixes to reduce the number of unique prefix lengths. Some approaches use bloom filters to filter some lengths of prefixes [19] [21]. These approaches are efficient in large lookup table applications, however, multiple sets of bloom filters are needed to process different lengths of prefixes and the false positive rate of bloom filters increases the number of memory accesses. b) Trie-based solutions: Trie-based longest prefix matching techniques [22] [25] use tree-like architectures to store prefixes and corresponding output port information. They are easy to implement on general purpose processors or network processors and are also efficient in reducing memory consumption. However, as these approaches usually need multiple memory accesses for a single input packet, they usually cannot meet the requirement of today s high-speed routers. c) CAM-based solutions: Among hardware-based longest prefix matching techniques, the CAM-based ones dominate the high-speed router market, especially of multigigabits per second and faster routers. A disadvantage is that the TCAM chips are expensive and power-hungry. Therefore, several techniques have been proposed to use TCAM entries more efficiently and to reduce the required amount of TCAMs [13], [26] [28]. These approaches usually need to pre-process prefixes to compress them and then configure into TCAMs. However, these approaches should undergo a very complex update process, because they have to pre-process the set of prefixes again.

6 TABLE II IMPLEMENTATION WITH DIFFERENT NUMBER OF NAME PREFIXES Number of Prefixes Slices 4-input LUTs BRAM Flip Flops Critical path(ns) URL Lookup Speed(M/s) Throughput(Gbps) 54% 35% 42% 31% % 38% 51% 40% % 41% % 53% % 43% 78% 71% % 46% 90% 84% To the best of our knowledge, all the TCAM-based longest prefix matching is designed for IP-based routing, which uses length bounded prefixes. Our goal is to design an efficient algorithm to store name prefixes with unbound length. VII. CONCLUSION In this paper, we present an approach to name-based route lookup for content-centric networks using CAMs. In our current scenario we use a hybrid configuration of BCAMs and TCAMs for demonstrating power optimization, while the algorithm can also be implemented in TCAMs if power usage is less important and a simpler design is required. We combine the hash scheme and prefix match scheme together to provide length bounded longest prefix matching process. We separate name prefixes into a number of sets based on their overlapping property and each incoming name can only match a single set. We pipeline our approach and implement it on a FPGA. Our simulation results show that our approach can achieve performance in the range of current backbone routers. Our approach is designed to support both hierarchical name based routing lookup and flat name based routing lookup. In addition, our approach can be easily modified to support multiple matchings instead of the longest prefix matching. REFERENCES [1] Cisco Visual Networking Index: Forecast and Methodology, ns705/ns827/white paper c pdf. [2] V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, N. H. Briggs, and R. L. Braynard, Networking named content, in Proceedings of the 5th international conference on Emerging networking experiments and technologies, ser. CoNEXT 09, 2009, pp [3] T. Koponen, M. Chawla, B.-G. Chun, A. Ermolinskiy, K. H. Kim, S. Shenker, and I. Stoica, A data-oriented (and beyond) network architecture, in Proceedings of the 2007 conference on Applications, technologies, architectures, and protocols for computer communications, ser. SIGCOMM 07, 2007, pp [4] V. Jacobson, D. K. Smetters, N. H. Briggs, M. F. Plass, P. Stewart, J. D. Thornton, and R. L. Braynard, VoCCN: voice-over content-centric networks, in Proceedings of the 2009 workshop on Re-architecting the internet, ser. ReArch 09, 2009, pp [5] M. Gritter and D. R. Cheriton, An architecture for content routing support in the internet, in Proceedings of the 3rd conference on USENIX Symposium on Internet Technologies and Systems - Volume 3, ser. USITS 01, [6] expressive Internet Architecture, xia/. [7] Nebula Future Internet Architecture Project, edu/. [8] Network of Information, [9] MobilityFirst Future Internet Architecture Project, upenn.edu/. [10] T. Yamauchi, H. Yuan, and P. Crowley, Implementing URL-based forwarding on a network processor-based router platform, in Proceedings of the 5th ACM/IEEE Symposium on Architectures for Networking and Communications Systems, ser. ANCS 09, 2009, pp [11] M. Caesar, T. Condie, J. Kannan, K. Lakshminarayanan, and I. Stoica, ROFL: routing on flat labels, in Proceedings of the 2006 conference on Applications, technologies, architectures, and protocols for computer communications, ser. SIGCOMM 06. New York, NY, USA: ACM, 2006, pp [12] A. Singla, P. B. Godfrey, K. Fall, G. Iannaccone, and S. Ratnasamy, Scalable routing on flat names, in Proceedings of the 6th International COnference, ser. Co-NEXT 10, New York, NY, USA, 2010, pp. 20:1 20:12. [13] Y. Sun and M. S. Kim, A hybrid approach to CAM-based longest prefix matching for IP route lookup, in Proceedings of IEEE Global Telecommunications Conference (GLOBECOM 2010), Dec [14] D. T. Jones, An improved -bit cyclic redundancy check for protein sequences, in University College London, Dec [15] D. Perino and M. Varvello, A reality check for content centric networking, in Proceedings of the ACM SIGCOMM workshop on Informationcentric networking, ser. ICN 11, New York, NY, USA, 2011, pp [16] Z. Huang, D. Lin, S. Chen, J.-K. Peir, and S. M. I. Alam, Fast routing table lookup based on deterministic multi-hashing, in Proceedings of the 18th IEEE International Conference on Network Protocols, Oct [17] S. K. J. T. P. Crowley, Peacock Hashing: Deterministic and updatable hashing for high performance networking, in Proceedings of IEEE INFOCOM, Apr. 2008, pp [18] S. Demetriades, M. Hanna, S. Cho, and R. Melhem, An efficient hardware-based multi-hash scheme for high speed IP lookup, in Proceedings of the th IEEE Symposium on High Performance Interconnects, Aug. 2008, pp [19] S. Dharmapurikar, P. Krishnamurthy, and D. Taylor, Longest prefix matching using bloom filters, IEEE/ACM Transactions on Networking, vol. 14, pp , Apr [20] H. Song, F. Hao, M. Kodialam, and T. Lakshman, IPv6 lookups using distributed and load balanced bloom filters for 100Gbps core router line cards, in Proceedings of IEEE INFOCOM, Apr. 2009, pp [21] H. Yu, R. Mahapatra, and L. Bhuyan, A hash-based scalable IP lookup using bloom and fingerprint filters, in Proceedings of the 17th IEEE International Conference on Network Protocols, Oct [22] Y. Chang and Y. Lin, A fast and memory efficient dynamic IP lookup algorithm based on B-Tree, in Proceedings of International Conference on Advanced Information Networking and Applications, May 2009, pp [23] L. C. Wuu, T. J. Liu, and K. M. Chen, A longest prefix first search tree for IP lookup, Computer Networks, vol. 51, no. 12, pp , Aug [24] R. Rojas-Cessa, L. Ramesh, D. Ziqian, C. Lin, and N. Ansari, Parallel search trie-based scheme for fast IP lookup, in Proceedings of IEEE Global Telecommunications Conference, Nov. 2007, pp [25] O. Erdem and C. F. Bazlamaci, Array design for trie-based IP lookup, IEEE Communications Letters, vol. 14, pp , [26] H. Liu, Reducing routing table size using Ternary-CAM, in Proceedings of the The Ninth Symposium on High Performance Interconnects, 2001, p. 69. [27] S. Stergiou and J. Jain, Optimizing routing tables on systems-on-chip with content addressable memories, in Proceedings of International Symposium on System-on-Chip, Nov [28] H. Noda, K. Inoue, M. Kuroiwa, F. Igaue, K. Yamamoto, H. Mattausch, T. Koide, A. Amo, A. Hachisuka, S. Soeda, I. Hayashi, F. M. K. Dosaka, K. Arimoto, K. Fujishima, K. Anami, and T. Yoshihara, A cost-efficient high-performance dynamic TCAM with pipelined hierarchical searching and shift redundancy architecture, IEEE Journal of Solid-State Circuits, vol. 40, pp , Jan