A Novel Level-based IPv6 Routing Lookup Algorithm

Transcription

1 A Novel Level-based IPv6 Routing Lookup Algorithm Xiaohong Huang 1 Xiaoyu Zhao 2 Guofeng Zhao 1 Wenjian Jiang 2 Dongqu Zheng 1 Qiong Sun 1 Yan Ma 1,3 1. School of Computer Science and Technology, Beijing University of Posts and Telecommunications, Beijing, , P.R.China 2. France Telecom Research and Development Beijing, Beijing , P.R.China 1. {huangxh, zhaogf, zhengdq, mayan}@buptnet.edu.cn Abstract - Internet migration from IPv4 to IPv6 has introduced more challenge to IP address lookup problem. Nowadays, some existing address lookup algorithms work well for IPv4 addresses, however, few of them can scale well to IPv6 both in lookup and update speed. As IPv6 uses 128-bit addresses, schemes whose lookup time grows with address length become less attractive. In this paper, a novel level based IPv6 routing lookup algorithm, called Level-based Routing Lookup (LRL) algorithm, is proposed. This proposed algorithm is specially designed based on the extensive research on the characteristics of IPv6 prefix length distribution, which is composed of four levels. Different structures are used for different levels. Intensive experiments have been done to evaluate the algorithm. The results show that the new algorithm excels in following aspects: good support of IPv6, extremely excellent fast lookup speed, stable memory consumption and competitive update speed. Index Terms Routing Lookup, IPv6, Prefix Hierarchical Trie, Algorithms I. INTRODUCTION ITH the explosively growth of the Internet, the shortage Wof IPv4 address has attracted more and more attention. This has brought the academia and the industry growing interests in the next generation internet protocol, known as IPv6. IPv6 provides an extremely large address space with 128-bit address, about 3.4*10 38 addresses theoretically. The 128-bit IPv6 address and the exponential growth of the Internet have stressed the routing system. While the data rates of links have kept pace with the increasing traffic, it has been difficult for the packet processing capacity of routers to keep up with these increased data rates. Specifically, the address lookup operation is a major bottleneck in the forwarding performance of today s routers. There has been a remarkable interest in routing lookup during the last tens of years, but people mainly focused on the 32-bit IPv4 routing lookup. Furthermore, the 128-bit IPv6 address poses a great challenge to the previous Longest Prefix Matching (LPM) algorithms, such as [1][2][3], because previous algorithms were particularly designed for 32-bit IPv4 address and had poor scalability to the length of IPv6 address. Meanwhile, there are also some algorithms which could be scaled to 128-bit IPv6 address, such as [4][5], and some schemes that have also been proposed for IPv6 LPM, such as [6][7]. LC-trie [4] is a multi-bit trie based algorithm. It can reduce the height of the trie and enhance lookup performance. However, the performance of LC-trie is inversely proportional to the height of the trie, because its lookup time grows linearly 2. {xiaoyu.zhao, wenjian.jiang}@orange-ftgroup.com 3. Beijing Key Laboratory of Intelligent Telecommunications Software and Multimedia, Beijing University of Posts and Telecommunications, Beijing, , P.R.China with the length of the IP address. [6] is also a multi-bit trie algorithm. Its performance is better compared with the unibit trie because it inspects several bits in each one stride. However, its memory consumption is still too massive and its lookup performance decreases compared with its performance under IPv4 due to the longer address of IPv6. Moreover, these schemes can not balance well between lookup speed and memory consumption. This paper proposes a novel IPv6 routing lookup algorithm, called as Level-based Routing Lookup (LRL) algorithm, which is composed of four levels. The new algorithm has the following characteristics to differentiate it from other existing algorithms. First, it supports 128-bit long IPv6 address. Second, it has extremely excellent rapid search speed, stable memory consumption and competitive update speed. Third, it is optimized with IPv6 prefix length distribution, so it can fit in with the future IPv6 address distribution. This paper is organized as follows. Section II describes the IPv6 prefix length distribution. Section III presents the proposed scheme. Section IV shows the experimental results. Section V concludes the paper with a summary. II. IPV6 PREFIX LENGTH DISTRIBUTION As we know, responsibility for management of IPv6 address spaces is distributed globally in accordance with the hierarchical structure as shown in Fig. 1. The IANA maintains a high-level registry of IP addresses. It works with the RIRs to distribute the large blocks of IP addresses among the RIRs. Fig.1 IPv6 address allocation hierarchy As shown in [8], registry policies are defined for the assignment and allocation of globally-unique IPv6 addresses to ISPs and other organizations. The IANA allocates global unicast IPv6 addresses of /23 from 2000::/3 [9] to the RIRs, and /08/$ IEEE. 1

2 each RIR allocates address in unit of /32 to its subordinate LIRs, then each LIR allocates IPv6 address in unit of /48 to its end users or small ISPs. RFC3177 [10] also recommends to the addressing registries (APNIC, ARIN and RIPE-NCC) on policies for assigning IPv6 address blocks to end sites. In particular, it recommends the assignment of /48 in the general case, /64 when it is known that one and only one subnet is needed and /128 when it is absolutely known that one and only one device is connecting. For further study, we collected 6 IPv6 backbone BGP routing tables in the real world. Four of them are from four different peers (Vatican, United Kingdom, USA and Japan) in the RouteViews 1 project and the other two are from Tilab 2 and Potaroo 3. The prefix length distributions for these 6 routing tables are listed in Table I, from which we can see that: 1) The number of routing entries in a routing table is less than 1000; 2) Most of the prefix lengths are less than 64 bits, and only 1 route is between 65 and 128; 3) There is no prefix with prefix length less than 16 (the length 0 route in Japan table is the default route.); 4) Routes mainly used are those with prefix length between 17 and 32, and the second one those with prefix length is between 33 and 48. TABLE I. PREFIX LENGTH DISTRIBUTIONS OF IPV6 ROUTING TABLES LENGTH TILAB POTAROO VA UK USA JAPAN ~ ~ ~ ~ Therefore, the following available characteristics can be concluded: 1) The first 3 bits of IPv6 prefix are constantly 001, which needs no process; 2) Lookup on 128 bits can be focused mainly on the 16th ~ 64th bits; 3) The values of word consisting of the 4rd ~16th bits are numerable; 4) Lookup on the 17th ~ 32nd bits is very frequent; 5) Lookup on the 33rd ~ 64th bits can take advantage of the hierarchy of prefixes; 6) Lookup on the 65th ~128th bits can be processed separately. III. THE PROPOSED ALGORITHM The objective of our proposed algorithm is to divide IPv6 address prefix into different levels, with which different levels are organized with different data structures. Meanwhile, a new data structure, i.e., Prefix Hierarchical Trie (PHT), is proposed. A. Prefix Hierarchical Trie (PHT) A prefix may represent an address block as allocated, a fragment of an allocated address block, or an aggregation of multiple allocated address blocks. Moreover, the address block represented by an advertised prefix can be a sub-block of another existing prefix. In this case we call the former a covered prefix and the latter a covering prefix. More formally, if an IP address block B 1 of size 2 n is fully contained in another address block B 2 of size 2 m, where n < m, we call the prefix for B 1 a covered prefix and the prefix for B 2 a covering prefix. Table II gives some example prefixes to show the relationships between prefixes. The 3rd column lists the address block represented by the corresponding prefix in 2nd column, e.g. prefix 1 represents the address block [00000, 01111]. Left graph in Fig.2 presents the trie of example prefixes, from which it is easily to find the relationships between covering and coverd prefixes. Several definitions for prefix hierarchical trie are introduced as follows. Sub-prefix: if a prefix is covered by another one, we call the former a sub-prefix of the latter one, e.g. prefix 3, 4, 5, 8 and 9 are all sub-prefixes of prefix 1. Direct sub-prefix: if a prefix is directly covered by another one, we call the former a direct sub-prefix of the latter one, e.g. prefix 3, 4 and 5 are all direct sub-prefixes of prefix 1, but prefix8 is direct sub-prefix of prefix 3 rather than prefix 1. Brother-prefix: all direct sub-prefixes of one same prefix are called brother-prefixes, e.g. prefix 3, 4 and 5 are brother-prefixes, but prefix 8 and 9 are not brother-prefixes. Meanwhile, all prefixes, which are not covered by any prefix, are also called brother-prefixes. TABLE II. EXAMPLE PREFIXES NO PREFIX ADDRESS BLOCK 1 0* [00000, 01111] 2 10* [10000, 10111] 3 000* [00000, 00011] 4 010* [01000, 01011] 5 011* [01100, 01111] * [10100, 10101] 7 111* [11100, 11111] * [00000, 00001] * [01000, 01001] * [10110, 10111] * [11100, 11101] Fig.2 The normal trie structure and the prefix hierarchical trie The prefix hierarchical trie for prefixes in table II is constructed as shown in Fig.2. The left child (virtual line) points to its direct sub-prefix, and the right child (solid line) points to its brother-prefix. Prefix 1, 2 and 7 are brother-prefixes because they are all not covered by any other prefix. Since the address block represented by prefix 1 is closer to 0 than prefix 2 and 7, prefix 1 is selected as the root node in the prefix hierarchical trie. And because the address block represented by prefix 2 is closer to 0 than prefix 7, prefix 2 is the right child of prefix 1 and prefix 7 is the right child of prefix 2. Similarly, prefix 3 is the left child of prefix 1 because that among the direct sub-prefixes of prefix 1, i.e., prefix 3, 4 and 5, the address block represented by prefix 3 is closest to 0. Then the prefix hierarchical trie is constructed recursively following this way. As Fig.2 shows, every node in the prefix hierarchical trie is a solid one, which denotes a prefix in the table, so there will be much less nodes in the prefix /08/$ IEEE. 2

3 hierarchical trie. B. Level-based Routing Lookup Algorithm Based on the characteristics of IPv6 prefix length distribution introduced in Section II, a novel 4-level based IPv6 routing table lookup algorithm is proposed, which is shown in Fig.3. Fig.3 The data structure of LRL The Level 1 is an Index Table which has 8192 entries. According to previous analysis in section II, no prefix used is shorter than 16, so we only need to process prefix whose length is no less than 16. Since lookup of the 1st ~ 16th bits is required for each prefix, we had better design a very fast and simple method to search the 1st ~ 16th bits. According to RFC3587 [9], the first three bits of IPv6 unicast address should be constantly 001, so we could only need to search the 4th ~ 16th bits. Following this idea, we build an Index Table using the 4th ~ 16th bits as key to index, which is an array with 2 13 entries. Each entry in the Index Table has a pointer which points to the corresponding next level: Level 2. The advantage of the Index Table is obvious: fast, concise and flexible. Fig.4 The item structure of Segment Table Segment Table is used in Level 2. According to the discussion in section II, a majority of prefixes locate in length [17, 32] in current real BGP routing tables. More similar prefixes in near future routing tables are also expected. Such a high density of prefixes might cost great time complexity to search when using normal trie data structure or other data structures. So, we design a data structure named Segment Table, an array with 2 16 entries. As shown in Fig.4, each entry is composed of 4 parts: NextHop, Max_MaskLength, CollidePointer and Pointer. The NextHop indicates the next hop number to forward IP packet corresponding to this prefix; the Max_MaskLength indicates the length of the longest prefix whose prefix length is no longer than 32 and the value of the second word (17th ~ 32nd bits) is corresponding to this Segment Table entry; the CollidePointer indicates the length of prefixes which have the same second word-value but shorter than prefix of Length; the Pointer points to the Level 3. The Level 3 adopts the prefix hierarchical trie introduced in the previous subsection. Each entry in the Segment Table in Level 2, which has sub-prefixes longer than 32, points to a prefix hierarchical trie organized with the 33rd ~ 64th bits of the prefixes (32 bits exactly, one word for current mainstream 32-bit PC, only needs one instruction and one memory access). If the entry in the Segment Table has no sub-prefix longer than 32, it points to NULL and the lookup process will stop. The Level 4 is the Bucket. The Bucket in this level just cares about the 65th ~128th bits. As shown in section II, few prefix has the length longer than 64. Therefore, we can classify these prefixes into groups according to the first 64 bits. For those prefixes in one group, they share the same first 64 bits of value. One group of prefixes will be organized in a Bucket. The Bucket is a collection of prefixes with specific organization. Since few prefixes will appear in the Bucket, we can use simple lookup approaches, such as linear search, binary search on prefix interval [11], and binary search on prefix length [12], etc. The specific way that the Bucket is organized depends on both the number of routing entries it stores and the tradeoff between memory requirement and lookup performance. C. Routing Lookup 1 search(dstip) 2 { 3 BMP = next hop of the default route; 4 key1 = the 4th ~ 16th bits of dstip; 5 node1 = Level1[key1]; 6 if(node1 has next-hop) BMP = node1.next-hop; 7 if(!node1.ptr) return BMP; 8 key2 = the 17th ~ 32nd bits of dstip; 9 node2 = Level1[key1].ptr->Level2[key2]; 10 if(node2 has next-hop) BMP = node2.next-hop; 11 if(!node2.ptr) return BMP; 12 key3 = the 33rd ~ 64th bits of dstip; 13 node3 = searchlrl(key3); 14 if(node3!= null) BMP = node3.next-hop; 15 if(!node3.ptr) return BMP; 16 key4 = the 65th ~ 128th bits of dstip; 17 node4 = searchbucket(key4); 18 if(node4!= null) BMP = node4.next-hop; 19 return BMP; 20 } Fig.5 The lookup pseudo code for LRL The lookup process for this algorithm is straightforward, which starts from the Index Table at Level 1 and advances to the next Level. The pseudo code for the routing lookup algorithm is shown in Fig.5. At the very beginning, the Best Matching Prefix (BMP) stores the default route (line 3). Then, the 4th ~ 16th bits of the destination IPv6 address (dstip) are extracted to index the entry in the Index Table at Level 1 (line 4-5). If the indexed entry node1 indicates a prefix, the BMP is updated (line 6). If node1 doesn t point to the next level, the BMP is returned (line 7), otherwise the lookup process continues. The second step is extracting the 17th ~ 32nd bits of the dstip to get the matching entry node2 in corresponding Segment Table at level 2 (line 8-9). The BMP is updated if the node2 has next-hop (line 10). If the node2 points to a prefix hierarchical trie at Level 3, the /08/$ IEEE. 3

4 lookup process goes on, otherwise the BMP is returned (line 11). At the third step, we will search the corresponding prefix hierarchical trie using the 33rd ~ 64th bits (line 12-13). If the result node3 is not null, the BMP is updated (line 14). If node3 still points to a Bucket, we ll continue searching the Bucket (line 16-17), otherwise the BMP is returned. If the result node4 at last step is not null, the BMP is updated (line 18). The BMP is returned at end (line 19). D. Routing Update The proposed algorithm supports incremental update excellently. It just needs to update its regional structure during insertion and deletion, instead of rebuilding the whole structure. 1) Insertion The insertion process is similar to the lookup, which needs to find the right place level by level and then updates the new prefix. There may be four types of positions for inserting a new prefix P. P is inserted into the Index Table. If the length of P is equal to 16, it is inserted into the Index Table. In Index Table, each prefix corresponds to exactly one entry in the Index Table. Therefore, this insertion is very easy. P is inserted into the Segment Table. If the length of P is between 17 and 32, it should be inserted to the Segment Table. At first, we ll extract the 4th ~ 16th bits of P to get the indexed entry in Index Table, and then we can get to the corresponding Segment Table. Because the length of P is shorter than 32, P should cover a sequential of entries in the Segment Table. (The length of 32, which just covers one entry, is special.) Then we insert P into all corresponding entries. If one entry indicates more than one prefixes, these prefixes should be ordered by their length, as described in Fig.5. P is inserted into the prefix hierarchical trie. As addressed in Section III, this case is most complicated, in which we must get the right prefix hierarchical trie through indexing the Index Table with the 4th ~ 16th bits and the Segment Table with the 17th ~ 32nd bits and then inserts P into prefix hierarchical trie. P is inserted into the Bucket. If the length of P is longer than 64, it must be inserted into a Bucket. This insertion process is similar to the routing lookup. We must get the corresponding Bucket through searching the previous three levels at first, and then insert P into it. How to insert P into the Bucket is based on the structure in Bucket. 2) Deletion The deletion process is very similar to insertion. There are also four cases for deletion a prefix P, corresponding to the four levels: If the length of P is 16, P locates in the Index table and we just need to reset the corresponding entry. If the length of P is between 17 and 32, P covers a sequential of entries in the Segment Table and we have to delete info of P from all these entries, after which the rest prefixes in these entries must be reordered by their length. The deletion process will happen in prefix hierarchical trie if the length of P is between 33 and 64, this case will follow the process as described in section III. The deletion will be very easy in Bucket if the length of P is longer than 64 because the structure in the Bucket is very simple. E. Algorithmic Complexity Assuming N routing prefixes exist in the routing table. Lookup complexity for each level is shown in Table III. TABLE III. ALGORITHM COMPLEXITY OF OPERATIONS Search Insert Delete Level 1 O(1) O(1) O(1) Level 2 Level 3 O(log 2N) O(log 2N) O(log 2N) Level 4 O(log 2N) O(log 2N) O(log 2N) Storage complexity for each level is shown in Table IV. TABLE IV. STORAGE COMPLEXITY Memory Consumption Level 1 O(1) Level 2 Level 3 Level 4 IV. PERFORMANCE EVALUATION This section presents the evaluation results. We implement the above data structure and algorithm with standard C++, and simulate the actual process of IPv6 router packet routing lookup under Linux on an Intel Pentium4 PC with CPU of 2.4GHz and 512MB RAM with synthetic and realistic BGP table and traffic. The performance of the new algorithm is also compared with that of several typical classical routing lookup algorithms, e.g. PATRICIA[13], LC-trie[4] and LPFST [14]. To evaluate the performances, two types of routing tables are used: 1) The real world IPv6 backbone BGP routing tables obtained world wide; 2) The synthetically created IPv6 routing tables. IP addresses were generated in proportion to the prefix distribution; thus, IP addresses corresponding to 48-bit, 64-bit and 32-bit prefixes in the routing table dominated the first, second and third largest part of the input traffic. We also generate one million IP addresses for each routing table. The verification IP addresses are not completely random ones, 80% of which are generated based on a routing entry randomly selected from the corresponding routing table and the other 20% are generated purely randomly. Each of IP addresses that are generated based on the routing entries matches at least the routing entry, based on which it is generated. Meanwhile, it can potentially match other routing entries because there are overlaps among the routing entries in the routing table. The IP addresses generated purely randomly may or may not match routing entry. A. Evaluation using real world IPv6 routing tables Lookup time(ns) LRL LC-trie LPFST PATRICIA Japan Potaroo USA VA Tilab London Routing table Fig.6 Lookup performance comparison using real world routing tables The results of four algorithms using real world IPv6 routing tables are shown in Fig.6, from which we can see that the lookup speed of LRL is about 3 times faster than LC-trie, 4 times faster /08/$ IEEE. 4

5 than LPFST and 5 times faster than PATRICIA respectively. With a sample software implementation of LRL on a PC with 2.4GHz Pentium4 CPU, 512M DDR333 RAM and Linux operating system, we can achieve more than 15MLPS (Million Lookups per Second), which satisfies the forwarding requirements of 10Gbps routers if the average IPv6 packet size is 80 bytes. Table V shows a performance comparison in terms of memory consumption, from which we can see that LRL needs more memories than other algorithms. Since the entry in the Index Table must point to a Segment Table if there is a prefix whose length is longer than 16 and each Segment Table has 2 16 entries, Segment Tables will consume a majority of memories. But this algorithm is designed for long term planning as can be seen in next section. When the number of prefixes increases gradually, the existed Segment Tables will satisfy their requirements and the amount won t rise sharply. TABLE V. MEMORY CONSUMPTION COMPARISON USING REAL WORLD IPV6 ROUTING TABLES (UNIT: KB) PATRICIA LC-TRIE LPFST LRL Japan Potaroo USA VA Tilab London B. Evaluation using synthetically created IPv6 routing tables Since there are no more than 1000 entries in current real world IPv6 routing tables, which is shown in Table I, we can hardly estimate the real performance of our algorithm. Therefore, we synthetically create several IPv6 routing tables with different sizes by v6gen [15], to test the scalability. The Fig.7 shows an intuitionistic comparison of the routing lookup speed of each algorithm using synthetical routing tables, from which we can see that our algorithm always has the best performance with the routing table size increasing. Lookup time(ns) LRL LC-trie LPFST PATRICIA 1K 2k 5k 10k 50k 100k 200k Routing table size Fig.7 Lookup performance comparison using synthetical routing tables The memory consumptions of these algorithms under the synthesized IPv6 routing tables are displayed in Table VI. As the table shows, proposed algorithm will consume more memories than other algorithms. However, the performance of the proposed algorithm will outperform other algorithms when the size of routing table increases. We can draw the conclusion that the new algorithm has better scalability for memories consumption especially when the size of routing table increases. TABLE VI. MEMORY CONSUMTION COMPARISON USING SYNTHESIZED IPV6 ROUTING TABLES (UNIT:KB) PATRICIA LC-TRIE LPFST LRL 1k k k k k k k V. CONCLUSION In this paper, we proposed a novel IPv6 routing lookup algorithm, which is based on the prefix hierarchical trie and the characteristics of IPv6 prefix length distribution. As the experiment results show, the new algorithm has extremely excellent rapid search speed, stable memory consumption and competitive update speed, which makes it a good candidate for IPv6 routing lookup algorithm. Under Linux in a 2.4GHz Pentium4 PC with 512M DDR333 RAM, the average lookup speed can be up to 62 ns with realistic routing table, which is equivalent to 10Gbps with 80 Bytes of IPv6 packet. REFERENCES [1] P. Gupta, S. Lin, and N. McKeown, Routing lookups in hardware at memory access speeds, in INFOCOM '98. IEEE, Vol.3, pp , April [2] W. Eatherton, Z. Dittia, and G. Varghese, Tree bitmap: hardware/ software IP lookups with incremental updates, in ACM SIGCOMM, vol.34, No. 2, pp , [3] M. Sundstrom, and L. Larzon, High-Performance Longest Prefix Matching supporting High-Speed Incremental Updates and Guaranteed Compression, in INFOCOM '05. IEEE, Vol.3, pp [4] S. Nilsson and G. Karlsson, IP-Address Lookup Using LC-Tries, IEEE J. SAC, vol. 17, No. 6, pp , June [5] B. Lampson, V. Srinivasan, and G. Varghese, IP Lookups Using Multiway and Multicolumn Search, in INFOCOM '98. IEEE, vol. 3, pp , April [6] M. Zitterbart, T. Harbaum, D. Meier, D. Brokelmann, Efficient routing table lookup for IPv6, in Proc. IEEE High-Performance Communication Systems, June 1997, pp.1 9. [7] M. Waldvogel, Fast longest prefix matching: algorithms, analysis, and applications, Ph. D. dissertation, Swiss Federal Institute of Technology, Swiss, [8] APNIC Document: IPv6 Address Allocation and Assignment Policy. [9] R. Hinden, S. Deering and E. Nordmark, IPv6 Global Unicast Address Format, RFC 3587, August, [10] IAB and IESG, IAB/IESG recommendations on IPv6 Address Allocations to Sites, RFC3177, September, [11] B. Lampson, V. Srinivasan and G. Varghese, IP lookups using multiway and multicolumn search, IEEE/ACM Transactions on Networking, Vol.7, No. 3, pp , June [12] P. Mehrotra and P. D. Franzon, Binary search schemes for fast IP lookups, in GLOBECOM '02. IEEE, vol.2, pp , [13] D. R. Morrison, PATRICIA Practical Algorithm to Retrieve Information Coded in Alphanumeric, Journal of the ACM, Vol.15, No.4, pp , [14] L.C. Wnn, K.M. Chen and T.J. Liu, A Longest Prefix First Search Tree for IP Lookup, in ICC '05, pp , May [15] K. Zheng and B. Liu, V6Gene: A scalable IPv6 prefix generator for route lookup algorithm benchmark, in IEEE AINA, Vienna, Austria, Vol.1, pp , April /08/$ IEEE. 5