Binary Search Schemes for Fast IP Binary Search Schemes for Fast IP LookupsLookups

Pronita MehrotraPaul D. Franzon

Department of Electrical and Computer EngineeringNorth Carolina State University{pmehrot,paulf}@eos.ncsu.edu

This research is supported by

1

OutlineOutline

Background & MotivationDescription of the Scheme

Scheme using all nodesScheme using only leaves

PerformanceSearch TimeBuild TimeMemory Consumption

Conclusions

2

BackgroundBackground

Optical Burst SwitchingUsing Just In Time protocolMCNC/NCSU project

My groupNetwork Processor for OBS …..

OBS Edge Node

OBS Edge Node

OBS Edge NodeOBS Switch

OBS SwitchOBS Switch

OBS Switch

Network Core SwitchesCALLING HOST CALLED SWITCH CALLED HOST

OPTICALBURST

CONNECT

CONNECT

CONNECT

SETUP

SETUP

SETUP

SETUPACK

CALLING SWITCH

RELEASE

RELEASE

CROSSCONNECTCONFIGURED

CROSSCONNECTCONFIGUREDFOR EXPLICIT

RELEASE

3

Network Processor ArchitectureNetwork Processor Architecture

Input Message Buffer

MessageParser

Field UpdateModule

Message Reassembly

ConnectionStateChecker

ACK/NACKGenerator

JIT Message Engine Register Access Block

Forwarding Engine

Port Assignment

CRC Generator

OutputMessage Buffer

Output Port Requester

Data Bus

Output PortOutputDataRegister

Request Buffer

Request Arbiter

CRCChecker

STAGE 1 STAGE 2 STAGE 3 STAGE 4 STAGE 5

ME-In Controller

Input Port

STAGE 7 STAGE 8

ME-Out Controller

8

8

Forwarding Engine

4

ImplementationImplementation

5

Forwarding EngineForwarding Engine

Scalability in speedReduce the number of lookups esp. in main memoryiTrie based schemes good for IPv4 (worst case 32

lookups)iBinary schemes potentially better for IPv6

Scalability in memoryReduce the amount of memory required to store dataiDirect/Indirect lookup schemes use memory inefficientlyiTrie based schemes have a higher overhead (due to trie

completion)

The bottleneck of the forwarding engine is the route lookup

6

Problem DefinitionProblem Definition

Routers store prefixes and not IP addressesTo determine the next hop, the longest matching prefix needs to be determined

700101*810111*1011100*6011010*2101101*4001*5010110*1011*91011*310*Next HopPrefix

Example:Destination address = 1011010110*, 1011*, 101101* all matchLongest prefix match is 101101*Next hop address = 2

7

Trie Trie Vs. TreeVs. Tree

0

0

0 0 0 0

0

1

1

111

1

1

<

<

< < < <

<

>

>

>>>

>

>

*Nick McKeown, Balaji Prabhakar, “High Performance Switches and Routers: Theory and Practice”,Hot Interconnects Tutorial Slides (http://tiny-tera.stanford.edu/nickm/talks/index.html), 1999

Binary Trie Binary Tree

◗Binary Trie: Number of address bits (32 for IPv4)◗Binary Tree: log2(N) (∼ 16 for 64K entries)

Memory Accesses:

8

Trie Trie or Tree?or Tree?

Issues with Trie Based Schemes:Extra Nodes with no data add to the depth of the treeiMore Memory Accesses Needed

Search time proportional to the size of the addressiBinary Trie for IPv4 can take up to 32 cyclesiFor IPv6 the worst case could be 128 cycles.

Issues with Tree Based SchemesBinary Search works for exact matchingiBacktracking or wrong pathsiUnbalanced Approaches

Pre-processing overhead higherSearch time depends on the number of entries

Goal : Binary Tree Scheme with faster build and search times

9

Binary Search Binary Search –– Sort StepSort Step

If n = m,Compare by numerical value

If n ≠ m,Chop longer prefix and compare. If chopped prefixes are equal then, the shorter prefix is considered larger

Two prefixes:A=a1a2…an B=b1b2…bm

After Sorting:000101*, 001*, 010110*, 011010*,011100*, 011*, 101101*, 10111*,1011*, 10*

Sorting Prefixes:

Sample Prefix Set

700101*

810111*

1011100*

6011010*

2101101*

4001*

5010110*

1011*

91011*

310*

Next HopPrefix

10

Equivalent Binary TreeEquivalent Binary Tree

Sorting gives depth-first-search of corresponding binary trieBinary Tree constructed as:

If A is a prefix of B, then B is the child of AIf A < B, then A lies on the left of B

001*

Root(*)

011* 10*

00101* 011010* 011100* 1011*

101101* 10111*

010110*

Sorted List:000101*, 001*, 010110*, 011010*,011100*, 011*, 101101*, 10111*,1011*, 10*

NOTE: Tree build implicitin sorted list. No need to buildexplicitly.

11

Store Tree in MemoryStore Tree in Memory

Key Element:Store parent information with each node

001*

Root(*)

011* 10*

00101* 011010* 011100* 1011*

101101* 10111*

010110*

00101* 0…010100

This entry has 5 bitsParent with 3 bits

001* 0…000100

101101* 0…101010

… …

This entry has 6 bitsParent with 4 bitsParent with 2 bits

12

Full Modified Prefix TableFull Modified Prefix Table

Store Information about all parents in “Path Information” and “Next Hop List”

-0…000010310*

30…00101091011*

9,30…011010810111*

9,30…1010102101101*

-0…0001008011*

80…1001001011100*

80…1001006011010*

-0…1000005010110*

-0…0001004001*

40…010100700101*

Next Hop List

Path Information

Next Hop

Prefix

13

Sample SearchSample Search

E.g. 100*1. Search prefix column

i Fall between011*101101*

2. Exact match on “≥” entrySearch Complete

3. Inexact matcha. How many bits match?b. 1 in this posn completec. 0 in this posn default (root)

2 bits match, 2nd bit (bit 1 = 1)Correspond to next hop = 3

-0…000010310*

30…00101091011*

9,30…011010810111*

9,30…1010102101101*

-0…0001008011*

80…1001001011100*

80…1001006011010*

-0…1000005010110*

-0…0001004001*

40…010100700101*

Next Hop List

Path Information

Next Hop

Prefix

14

Binary Search using Disjoint PrefixesBinary Search using Disjoint Prefixes

9,30…011010810111*

9,30…1010102101101*

80…1001001011100*

80…1001006011010*

-0…1000005010110*

40…010100700101*

Next Hop List

Path Information

Next Hop

PrefixSearch space can be reduced further by using only leaves and eliminating all internal nodesFor practical routing tables, this leads to a reduction of about 7% entriesAdditional step is required to find the longest matching prefix and the corresponding next hop

011100*

101101*100*

Compare 100* with both 011100* and 101101*,101101* gives a better match.Next hop = 3 again.

15

Build TimeBuild Time

300ms100ms120ms31,958AADS

150ms50ms60ms17,641Paix

260ms90ms90ms27,491PacBell

330ms120ms130ms35,752MaeWest

210ms80ms80ms23,113MaeEast

LSV Scheme

Binary Search (Only Leaves)

Binary Search (All Nodes)

EntriesSite

Build time of binary schemes less than half that of LSV scheme

Sorting step accounts for most of the difference (number of entries half that in LSV scheme)

Build time in binary scheme using only leaves is not very different from that using all nodes

16

Profile of Routing TablesProfile of Routing Tables

05000

10000150002000025000300003500040000

MaeE

ast

MaeW

est

PacB

ell Paix

AADS

Total EntriesNo. of Leaves0 Internal Nodes1 Internal Node2 Internal Nodes3 Internal Nodes4 Internal Nodes

Most core routing tables do not have any internal nodesAbout 7% of total entries correspond to internal nodes

In about 93% of cases, the next hop list does not need to be looked at

17

Search TimeSearch Time

777ns640ns700ns31,958AADS

739ns634ns640ns17,641Paix

761ns656ns703ns27,491PacBell

845ns652ns742ns35,752MaeWest

761ns610ns662ns23,113MaeEast

LSV Scheme

Binary Search (Only Leaves)

Binary Search (All Nodes)

EntriesSite

For the binary scheme using all nodes, > 10% improvement in average search speed over LSV scheme

1-2 fewer memory accesses requiredFor binary scheme using only leaves, 15-20% improvement in speed obtained

18

Memory RequirementMemory Requirement

1.46MB0.81MB0.86MB31,958AADS

0.81MB0.45MB0.48MB17,641Paix

1.26MB0.7MB0.74MB27,491PacBell

1.64MB0.9MB0.96MB35,752MaeWest

1.06MB0.58MB0.62MB23,113MaeEast

LSV Scheme

Binary Search (Only Leaves)

Binary Search (All Nodes)

EntriesSite

Memory consumption for both binary schemes, about half that in LSV scheme

Each prefix in LSV scheme gives rise to two entries in the routing table

Memory consumption for binary scheme using only leaves not very different from that using all nodes

19

Scaling to IPv6Scaling to IPv6

0

2000

4000

6000

8000

10000

12000

14000

0 5 10 15 20 25 30

Most IPv4 prefixes exist between 16 and 24 bitsThe path information field, in this case needs to be only 23 bits wide

For IPv6, in a given domain, much fewer than 128 bits would most likely be required for the path information field

20

UpdatesUpdates

Port reassignments and new internal nodesOne entry needs to be rewritten

New leaf nodesSubstantial updateConsider sparing of table to prevent dead time

21

ConclusionsConclusions

Binary Search Schemes are possibly better suited for large addresses like IPv6

Number of lookups depend on the number of entries and not the address size

Binary Search schemes for larger address size1-2 fewer memory accesses as compared to LSV schemeiUp to 20% faster than LSV

Memory requirement ∼ 2x lesser than the LSV schemeBuild time is less than half that of LSV schemeiSorting step accounts for most of the difference

Update Process at O(N)Mainly intended for software implementation

Trie based hardware scheme presented at HPSR’02