1. EaseCAM: An Energy And Storage Efficient TCAM-based IP-Lookup Architecture Rabi Mahapatra Texas A&M University;

2. Overview  Introduction  Research Goal  Proposed approach  Results  Conclusion & Future work

3. Introduction IP LookupPacket Queue DRAMRouting Table Header Processing HdrData Hdr IP Address Next Hop

4. Introduction  HW and SW solutions for IP lookup  Software solutions unable to match link speed.  Hardware solutions can accommodate today’s link speeds  TCAMs most popular hardware device  Consume up to 15 W/chip, (4-8 chips)  Increased cooling costs and fewer ports

5. Current Approach  Power Reduction in TCAM  Partitioning of TCAM Array [Infocom’03, Hot Interconnect’02]  Compaction (minimization) [Micro’02]  Update techniques [Micro’02]  Routing update  TCAM updates

6. Bottleneck with existing approaches  Power reduction  Number of entries enabled is not bounded  Does not avoid storing redundant information  Update  Minimization techniques are not incremental  Update time is not independent of routing table size

7. Motivation  Solution for bounded and reduced power consumption  Truly incremental Routing and TCAM update

8. Contributions Contributions  A pipelined architecture for IP Lookup  New prefix properties (prefix aggregation and prefix expansion)  Upper bound on number of entries enabled (256 x 3)  Novel Page filling, memory management and incremental update techniques

9. Solution: Prefix properties  Prefix Aggregation 128.194.1.1/32 128.194.1.2/32 128.194.1.8/30 128.194.1.16/28 128.194.1.0/24 128.194.1.0/24 is the LCS for the given set of prefixes (rounded to nearest octet) 128.194.1.0/24 is the LCS for the given set of prefixes (rounded to nearest octet) Prefixes aggregated based on LCS mostly have the same next hop Prefixes aggregated based on LCS mostly have the same next hop Gives a bound on the number of prefixes minimized (256) Gives a bound on the number of prefixes minimized (256)

10. Solution: Prefix properties Router Total Prefixes Max Prefix Compaction Prefix Aggregation based Compaction ATT- Canada 1124125447657837 BBN- planet 1245386964671500 TABLE I. Comparision of prefix compaction using prefix aggregation property and Espresso II for attcanada and bbnplanet router

11. Solution: Prefix Properties  Prefix expansion Prefixes having same length can be minimized Prefixes having same length can be minimized To increase minimization, extend prefixes of different length to nearest octet by adding don’t-cares To increase minimization, extend prefixes of different length to nearest octet by adding don’t-cares Extending to nearest octet useful for incremental update Extending to nearest octet useful for incremental update 100101 1011011 1011111 1011 100101XX 1011011X 1011111X 1011XXXX

12. Solution: Prefix properties  Overlapping prefixes Prefix length < 8 not present in routing table Prefix length < 8 not present in routing table Number of matching prefixes for IP address is ≤ 25 Number of matching prefixes for IP address is ≤ 25 Property is used to selectively enable bounded number of entries in TCAM, (256 x 3) Property is used to selectively enable bounded number of entries in TCAM, (256 x 3)

13. Solution: Architecture  2 level architecture, w1 bits in 1 st level and 32- w1 in 2 nd level  Segment size corresponding to 1 st w(8) bits is variable  Power bounded by segment size 2 nd Level 1 2 127 128 254 255.. 24 bits 128.x 1.x 2.x Variable Sized Segment W 1 =8 bits 127.x 254.x 255.x 1 st Level Segmented Architecture for routing lookup using TCAM.

14. Solution: Architecture  Memory Compaction Apply prefix properties to remove redundancies Apply prefix properties to remove redundancies Apply pruning, prefix aggregation and minimization in succession Apply pruning, prefix aggregation and minimization in succession Put all prefixes < w1 into bucket (Rarely occurring prefixes) Put all prefixes < w1 into bucket (Rarely occurring prefixes) Total number of entries after compaction

15. Solution: Architecture  Paged TCAM architecture Group the prefixes of length > w1 based on their LCS Group the prefixes of length > w1 based on their LCS The LCS values (cubes) that cover the prefixes The LCS values (cubes) that cover the prefixes The cubes now correspond to the page id The cubes now correspond to the page id Prefixes covered by cube are stored in actual pages Prefixes covered by cube are stored in actual pages (Pages formed using LCS as page-id can result in under-utilization)

16. Architecture Block Diagram Page Table 1 Page Table I Page Table N Page I+1 Page I I+C max Bucket....................... Comparator (32-w 1 )bits 32 bits 32 bits 32 bits (N*  ) IP address IP address IP address Enable Line .................. Pages formed using LCS as page-id can result in under-utilization)

17. How to avoid Under-utilization?  LCS aggregation 1. Aggregate prefixes having different LCS by modifying the cube 2. Set page-size to optimal value – avoid too large and small pages Observe: The maximum size of page can be 256, based on the above property 101 100 10*

18. Solution: Page Filling Algorithm  Page Filling Heuristics (2) 1. Generates cubes such that it covers maximum prefixes and page size < 256 2. Aggregate the page ID’s in the page tables and store them in comparators for a 0 th level lookup 3. Find the total memory consumed (pages, page tables and comparator) for different values of w1 4. Get optimal value of w1 and page size β for which total memory is the least

19. Solution: Page Filling  Page filling heuristics ensures: No page has more than β*γ entries, where γ is the page fill-factor No page has more than β*γ entries, where γ is the page fill-factor Number of cubes that cover all the prefixes are minimum Number of cubes that cover all the prefixes are minimum Total memory consumption is the least for a specific value of w1 and β Total memory consumption is the least for a specific value of w1 and β

20. Architecture Block Diagram Power Enabled blocks in EaseCAM Page Table 1 Page Table I Page Table N Page I+1 Page I I+C max Bucket....................... Comparator (32-w 1 )bits 32 bits 32 bits 32 bits (N*  ) IP address IP address IP address Enable Line ..................

21. Solution: Architecture  Bucket Prefixes of size < w1 are stored in bucket Prefixes of size < w1 are stored in bucket Word length of bucket is 32 Word length of bucket is 32 Either bucket or pages are searched during each lookup in the 2 nd level Either bucket or pages are searched during each lookup in the 2 nd level

22. Solution: Architecture  Empirical model for memory  α: fraction of total entries in the bucket  αf : bucket fill factor  γ: page fill factor  Cmax: number of page ids in the page table  N: the number of entries  Pagemax: total number of pages  βw1: represents the optimal page size  Mimimum memory requirement  = βw1* Pagemax * (32-w1)/32 + Pagemax + Pagemax/Cmax + N*α/ αf

23. Incremental Updates  100s updates/sec and 10 updates/sec after routing flaps  Insertion If length of prefix > w1, If length of prefix > w1, 1.Minimize the prefix and find the new cube 2.Number of prefixes minimized < 256 3.Update the page table and comparator if required 4.Update the TCAM with changed entries 5.TCAM insertion time and minimization time is time bounded

24. Solution: Incremental Update  Deletion Delete the prefix from TCAM Delete the prefix from TCAM Update the page table entry and comparator if required Update the page table entry and comparator if required Total number of prefixes minimized < 256 Total number of prefixes minimized < 256 TCAM update time is also bounded TCAM update time is also bounded

25. Solution: Incremental Update Router Total Prefixes Micro’02 Approach Proposed Approach Size Time (sec) SizeTime(sec) attcanada 112412151461098.472230.005 bbnplanet 124538758063.042560.006 Comparision of incremental update time

26. Solution: Memory Management  Managing page overflow  Reason: Lower value of γ. Pages with same cube are recomputed Pages with same cube are recomputed Free pages available in TCAM are used Free pages available in TCAM are used Comparators are also updated when required Comparators are also updated when required

27. Results  Power consumption per lookup bbnplanet router attcanada router

28. Results Results  Case study Memory requirements (γ=1 and α=1) Memory requirements (γ=1 and α=1) Router Raw data (entries) After Compaction (entries) Effect of Architecture (entries) Attcanada1124125783750182 Bbnplanet1245387150059883 Reduction in memory requirements

29. Results: Access time  Pre-estimation using Cacti 3.0 on CAM structure Router Raw data (ns) (ns) After Compaction (ns) Effect of Architecture (ns) Attcanada240.5381.874.39 Bbnplanet265.32117.94.43 Reduction in access time

30. Results: Power  Pre-estimation using Cacti 3.0 on CAM structure Reduction in power Router Raw data (W) After Compaction (W) Effect of Architecture (W) Attcanada14.35W7.38W0.135W Bbnplanet15.9W12.31W0.12W

31. Conclusion  Significant reduction in memory consumption based on prefix compaction  Pipelined architecture to store prefixes to achieve bounded power consumption  Efficient memory management and incremental update techniques

32. Future work  Apply Cacti model to TCAM structure  Identify/design low-power TCAM cell  Consider classification together with IP- lookup  Fast on-chip logic minimization  Explore parallel architectures & algorithms for IP processing.

33. Thank You !! Thank You !!Questions?