A NOVEL LEVEL-BASED IPV6 ROUTING LOOKUP ALGORITHM

1. A NOVEL LEVEL-BASED IPV6 ROUTING LOOKUP ALGORITHM Author: Xiaohong Huang, Xiaoyu Zhao, Guofeng Zhao, Wenjian Jiang, Dongqu Zheng, Qiong Sun and Yan Ma Publisher/Conf.: IEEE GLOBECOM 2008 Speaker: Han-Jhen Guo Date: 2009.01.07

2. OUTLINE • Introduction • The Proposed Algorithm • Performance Evaluation

3. INTRODUCTION • IPv6 address allocation hierarchy global unicast IPv6 addresses of /23 from “001*” /32 /48

4. INTRODUCTION • IPv6 Prefix Length Distribution • 6 IPv6 backbone BGP routing tables in the real world • the number of routing entries in a routing table < 1000 default route no prefixes lookup frequently mainly used mainly used secondly

5. INTRODUCTION • Characteristics • according to RFC3587, the first three bits of IPv6 unicast address should be constantly ‘001’→ needs no process • lookup on 128 bits can be focused mainly on the 16th ~ 64th bits • the values of word consisting of the 4rd ~16th bits are numerable • lookup on the 17th ~ 32nd bits is very frequent • lookup on the 33rd ~ 64th bits can take advantage of the hierarchy of prefixes • lookup on the 65th ~128th bits can be processed separately

6. THE PROPOSED ALGORITHM- OUTLINE • Level-based Routing Lookup (LRL) algorithm • Data Structure 16 bits for each lv.

7. THE PROPOSED ALGORITHM- LEVEL 1 • Level 1: Index Table • first three bits = 001 → 2(16-3) entries • use 4th ~ 16th bits to index • data structure of each entry

8. THE PROPOSED ALGORITHM- LEVEL 2 • Level 2: Segment Table • 216 entries • use 17th ~ 32th bits to index • data structure • Max_MaskLength: 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 • CollidePointer: the length of prefixes which have the same second word-value but shorter than prefix of Length use for “update”

9. THE PROPOSED ALGORITHM- LEVEL 3 • Level 3: Prefix Hierarchical Trie (PHT) • use 33th ~ 64th bits • definition • Sub-prefix • if a prefix is covered by another one, we call the former a sub-prefix of the latter one (descendent) • Direct sub-prefix • if a prefix is directly covered by another one, we call the former a direct sub-prefix of the latter one (direct descendent) • Brother-prefix • all direct sub-prefixes of one same prefix

10. THE PROPOSED ALGORITHM- LEVEL 3 • Construction a PHT direct sub-prefix brother-prefix

11. THE PROPOSED ALGORITHM- LEVEL 3 • Searching on a PHT • search the IP = 01011 0* 000* 10* 0000* 010* 111* 1010* 0100* 1011* 1010* 011* return next-hop info. = 4

12. THE PROPOSED ALGORITHM- LEVEL 3 • Insertion into a PHT • insert a prefix = 101* 0* 000* 10* len. of inserted prefix < searched prefix or a NULL ptr. is searched →stop and insert there 0000* 010* 111* 101* 1010* 6 0100* 1011* 1010* 011* 10

13. THE PROPOSED ALGORITHM- LEVEL 4 • Level 4: Bucket • use 65th ~ 128th bits • data structure • depend on lookup approach (such as linear search, binary search, etc.)

14. PERFORMANCE EVALUATION • Evaluation using real world IPv6 routing tables • lookup performance comparison

15. PERFORMANCE EVALUATION • Evaluation using real world IPv6 routing tables • memory consumption

16. PERFORMANCE EVALUATION • Evaluation using synthetically created IPv6 routing tables • lookup performance comparison

17. PERFORMANCE EVALUATION • Evaluation using synthetically created IPv6 routing tables • memory consumption stable than other schemes

18. Thanks for your listening!