Reducing Routing Table Size Using Ternary-CAM

Huan Liu

Department of Electrical Engineering

Stanford University

huanliu@stanford.edu

http://www.stanford.edu/~huanliu

Hot Interconnect 9

Aug. 22, 2001

Longest prefix matching (LPM)

192.168.10.x Port 7

192.168.x.x Port 5

10.x.x.x Port 3

Prefix Next hop

Match against routing table

Pick longest match

Port 7

Destination IP address

192.168.10.1

Existing LPM algorithms• Software based algorithms (LC Trie, Hash..)

– Cheap– But slow, at least 4 memory accesses

• Hardware based algorithm (CAM/TCAM)– Fast– Deterministic– Expensive– Power hungry

? How can we make it less expensive and less power hungry?

Other half of the story….

Source: http://www.telstra.net/ops/bgptable.html

Need to worry about growth as well:

More motivation

• It is beneficial for routing prefix caching

• For detail on how to cache prefix, see: http://www.stanford.edu/~huanliu/icccn01.pdf

Routing Table

$

CompactedRouting Table

$

Lower miss ratio

Key observation

• Number of prefixes is large

• Number of distinct next hop is small

maeeast maewest pacbell aads paix

# of routes 36 40 19 37 26

# of prefixes 23554 32139 38791 15906 29195

Source: http://www.merit.edu/ipma Mar. 7, 2001

Redundancy

1***, port 5

11**, port 5

110*, port 3

1***, port 5

110*, port 3

Lookup

1110

port 5

port 5

Pruning

• Remove redundant routing entries

• Redundant entries are very common

• Fairly easy to do: simple recursion

0

5000

10000

15000

20000

25000

30000

35000

40000

maeeast maewest pacbell paix aads

pruning

after pruning

Pruning result

24.5%

23%

26.6%

25.6%

25.1%

Content addressable memory

• Fully associative memory: search in 1 cycle

• Binary CAM: fixed length exact match– Need several chips, one for each distinct prefix length

• Ternary CAM: – Store 0, 1, *– Masked match – For routing prefix, mask is all 1’s followed by all 0’s

196.128.0.0 0xFFFF0000

196.128.10.3

and? =

prefix

key

Mask extension

1101010*****

1100010*****

110*010*****

Prefix Next hop

prefix

prefix

minterm

Logic minimization

• Mask extension becomes a logic minimization problem

• ESPRESSO-II algorithm is used

………………

1101010*****

1100010*****

………………

Minimize using ESPRESSO-II

Convert whole routing table

***

****

****

*****

******

24bit Prefix

23bit Prefix

22bit Prefix

21bit Prefix

20bit Prefix

ESPRESSO-II

x

y

zw

Next Hop

For each prefix length For each next hop ……..

ESPRESSO-II options

• Exact– Minimum number of minterms but not

necessarily minimum number of literals– Optimal for us because minterms correspond to

CAM entries– Runtime close to other options (fast, 1 pass)

after pruning is applied first

Just say No

• Prefix expansion can increase optimization opportunity

• But, runtime is also substantially longer

***

****

****

*****

24bit Prefix

23bit Prefix

22bit Prefix

21bit Prefix

***

******

24bit Prefix

21bit Prefix

prefix expansion

0

5000

10000

15000

20000

25000

30000

35000

40000

maeeast maewest pacbell paix aads

Mask extension

after ME

Mask extension result

27.3%

29.1%

31.8%

28%

30.4%

0

5000

10000

15000

20000

25000

30000

35000

40000

maeeast maewest pacbell paix aads

pruning

mask extension

compacted table

Pruning + Mask Extension result

24.5%

18.2%

23%

20.6%

26.6%

21.4%

25.6%18.2%

25.1%

19.9%

Summary

• Two techniques to compact routing table– Pruning

• Applicable to all LPM algorithms

• Fast and easy to compute

– Mask extension• Applicable only to TCAM

• CPU intensive to compute

• Need fast incremental update algorithm

Update: route insert/withdraw• Pruning

– Incremental update is trivial– Fast

• Mask extension – Slow

– Can not afford to recompute after each update, need faster incremental update algorithm

maeeast maewest pacbell paix aads

Runtime (s) 14.2 49.3 77 8.26 44.1

Incremental insertion

• Use existing minterms as Don’t care set

00** 01**

10**

Insert 11**00** 01**

10** 11**

Minterms

On-set: 11**Don’t care: *0**

0***

Incremental withdrawal

• Several minterms may need to be removed

• Several prefixes may need to be re-minimized

• Use remaining minterms as Don’t care set

minterms

prefixes

Prefix withdrawn

Become invalid as a result

On set for minimization

Incremental update result

24000

24500

25000

25500

260001

2551

5101

7651

1020

112

751

1530

1

1785

120

401

2295

125

501

2805

130

601

3315

1

updates

orig

inal

tabl

e si

ze

18500

19000

19500

20000

20500

com

pact

ed ta

ble

size

compacted original

Incremental update speed

• Our implementation: 22ms/per update on Pentium III 500Mhz

• Can support ~50 updates/second

• Most route updates are routing flap: same prefix inserted/removed repeatedly

• Can use buffer to store routing flap before committing update so that we can support much more updates per second