1. A Fast and Memory Efficient Dynamic IP Lookup Algorithm Based on B-Tree Author:Yeim-Kuan Chang and Yung-Chieh Lin Publisher: 2009 International Conference on AINA Presenter: Chen-Yu Chang Date: 2009/7/28

2. Outline Introduction Proposed Data Structure Performance Evaluation

3. Introduction This paper deals with the traditional IP address lookup problem with fast updates. We propose a B-tree data structure, called MMSPT (Multiway Most Specific Prefix Tree), which is constructed by using the most specific prefixes in routing tables. Finally, we compare our scheme with the existing dynamic schemes PBOB, MRT and PIBT.

4. Outline Introduction Proposed Data Structure Performance Evaluation

5. Proposed Data Structure(1/12) A. Preliminaries  A string b 0 b 1 b 2 …b i-1 *represents a prefix with length i.  prefix b 0 b 1 b 2 …b i-1 *represents a range of addresses [s, f].  For a prefix p, we use len(p), start(p), and finish(p) to denote the length, the start address(i.e., s), and the finish address(i.e., f) of p. Definition 1: For any two different prefixes p1 and p2, we say p1 covers p2 (or p2 is covered by p1) iff start(p1) ≤ start(p2) and finish(p2) ≤ finish(p1). We also say p2 is more specific than p1. Ex: p3 ⊆ p1, p5 ⊆ p2, p8 ⊆ p6

6. Proposed Data Structure(2/12) Definition 2: For any two different prefixes p1 and p2, we say p1 and p2 are disjoint iff finish(p1) < start(p2) or finish(p2) < start(p1). Ex:p1 and p2 are disjoint. Definition 3: For a given prefix set P, we say a prefix p ∈ P is the most specific prefix in P iff no prefixes in P-{p} are covered by p. Ex:p3, p5, p7, p8, and p9 are the most specific prefixes. Definition 4: For any two different prefixes p1 = [s1, f1] and p2 = [s2, f2], we say p1 f2. Ex:p1 < p2, p3 < p4, and p6 < p7.

7. Proposed Data Structure(3/12) B. Our Multiway Most Specific Prefix Tree Structure  For a given prefix set P, MMSPT stores the most specific prefixes in P as keys in each node.  Just like the traditional B-tree, each node x of MMSPT has the following fields: 1. n(x): the number of keys currently stored in x. 2. key i (x), for i = 1~n(x): keys, stored in increasing order, so that key 1 (x) < key 2 (x) < …< key n(x) (x). 3. childi(x), for i = 0 ~ n(x): child pointers, where child i (x) points to the ith child (subtree) of x. 4. Cover(x): prefix set, is a subset of P and each of prefixes in Cover(x) must follow the prefix allocation rule.

8. Proposed Data Structure(4/12)  Definition 5: For a MMSPT node x, each prefix p in Cover(x) must cover at least one key in node x and p is disjoint with all keys in the parent node (if it exists) of x. This is called the prefix allocation rule.

9. Proposed Data Structure(5/12) C. Longest Prefix Matching  Since all the keys stored in MMSPT are disjoint, no more than one key matches the query address d.  Since all the keys are most specific, this matched key must be the longest matching prefix of d.  If a query address d is both matched by two prefixes p1 ∈ Cover(x) and p2 ∈ Cover(x’s parent), then p2 covers p1 (i.e., p1 is more specific than p2 and len(p1) is longer than len(p2).).

10. Proposed Data Structure(6/12) Case1: d=23 return Case2: d=32 return Case3: d=16 collect[]={x, y} return

11. Proposed Data Structure(7/12)  In real routing tables, only less 10 percent of prefixes are stored in Cover(x) for some node x. Thus, backtracking is not performed frequently. Complexity Analysis: O (log 2 m * log m n) = O (log2n).

12. Proposed Data Structure(8/12) D. Inserting a Prefix Case1: p:[21.25]pCase2: p:[22.23] Modify the routing information Case3: p:[22]p 5 :[22, 23] p:[22] Case4: p:[1, 2] p:[1, 2]n(y)=2

13. Proposed Data Structure(9/12)  Buttom_up() When n (y) = m, node y is split into two node around key g (y), where. Keys of y to the left of key g (y) remain in y, those to the right are placed into a new node y’, and key g (y) is inserted into the parent node of y. Prefixes in Cover(y) that cover key g (y) are removed from Cover(y) and inserted into Cover(parent node of y). Prefixes in Cover(y) that are greater than key g (y) are also removed from Cover(y) and inserted into Cover(y’).

14. Proposed Data Structure(10/12) D. Deleting a Prefix  If p is in Cover(x) for some node x, then we remove p from Cover(x) and the deletion for p is finished.  If p is a key for some node x: Case 1): x is a leaf node To delete a prefix p where p = key i (x), we first determine is there a prefix p 2 with longest length in Cover(x), such that p 2 only covers p (i.e., p 2 dose not cover key i-1 (x) and key i+1 (x)). If such a prefix exists, we use p 2 to replace p as the new key i (x), and we are done. Otherwise, we remove key i (x) from x and the keys to the right of key i (x) are shifted one position left.

15. Proposed Data Structure(11/12)  The number of keys that remain in x is less than. If a nearest sibling of x has more than keys : Borrow from a sibling Otherwise: Merging two adjacent siblings

16. Proposed Data Structure(12/12) Case 2): x is an interior node  If there has any prefixes in Cover(x) that only cover p, we use the one who has the longest length to replace p.  Otherwise, p is replaced either by keyn (w) (w) or key 1 (v).  Assume we replace p by key 1 (v), For every node u on the path from z to v (including z and v), all prefixes stored in Cover(u) that cover key 1 (v) are removed from Cover(u) and added into Cover(x). p

17. Outline Introduction Proposed Data Structure Performance Evaluation

18. Performance Evaluation(1/3) A. Memory Usage

19. Performance Evaluation(2/3) B. Search Time

20. Performance Evaluation(3/3) C. Insertion Time and Deletion Time