CS419: Computer NetworksLecture 6: March 7, 2005Fast Address Lookup:CS419Forwarding/Routing RevisitedCS419Best-match Longest-prefix forwarding table lookup| We looked at the “semantics” of best-match longest-prefix address lookupz As a linear walk through the list of FIB entries, in order of longest-to-shortest prefix| But we didn’t look at how to do this fast!CS419Tree Bitmap| This is a fast address lookup algorithm from George Varghese (UCSD)| Used in high-speed routers (Cisco)z George has a startup doing this| This lecture based on this paper:z W. Eatherton, Z. Dittia, G. Varghese, “Tree bitmap: hardware/software IP lookups with incremental updates,” ACM SIGCOMM CCR, Volume 34 , Issue 2 (April 2004)CS419Main goals:| Wire-speed forwarding at OC-192 (10 Gbps)| 24 million packets per second!!!z For small packets (TCP acks)| Minimize memory accesses (4-7 for 41K FIB entries!)| Performance guaranteesz Not just for lookup, but for constructing the tree as wellCS419Other goals| Operate in software and hardware modesz Variations on hardware: single-chip, off-chip memory, CAMs| Minimize memory size| Take advantage of memory characteristics (i.e. cache line associated with a read)| Tunable across many architecturesCS419Tuning to different memories| All these algorithms involve traversing some kind of tree structure| The trick to tuning is deciding where in physical memory to stick different parts of the tree…CS419Tuning to different memoriesCS419Tuning to different memoriesCS419Example: Multiple memory banks| Put top of tree in Bank A, bottom tree in Bank B, run two lookups in parallelCS419Example: Size of memory “burst”Various memory parameters determines the number of bytes that be read in one memory access. This in turn determines how to structure the lookup tree.CS419Some types of trees| Next we’ll look at a number of tree structures, each more advanced (and harder to understand!) than the lastz Unibit triesz Expanded triesz Lulea (bitmap)z Tree bitmapCS419Unibit triesCS419Unibit tries| Traverse the tree one bit at a time| If terminate at a prefix node, use that as the next hop| If terminate at a “place holder” (non-prefix) node, use most recently traversed prefix node as the next hop| One-way branches can be compressed outCS419Unibit tries| Small memory and update times | Main problem is the number of memory accesses requiredz 32 in the worst casez Way beyond our budget of approx 4• (OC48 requires 160ns lookup, or 4 accesses)CS419Expanded tries| To speed up lookup, branch on multiple bits at each decision instead of just onez The number of bits used is the “stride length”| Otherwise, lookup algorithm similar to unibitz i.e. remember most recently traversed prefix in case of non-prefix terminationCS419Prefix expansion without leaf pushingCS419Expansion| Prefixes that don’t fall on stride boundaries must be “expanded” to fill all slots| Eg P6 expanded to four slots| Or, P2 expanded initially to four slots, but then P4 and P5 take precedence over P2CS419Expanded trie inefficiencies| Expansion uses up more space| Also, each entry requires two fieldsz A pointer to the next node in the treez A prefix| This is because some entries require both a pointer and a prefixz i.e. P2, P5, and P6| Update speed versus memory size tradeoffCS419We can combine pointer and prefix…(leaf pushing)CS419Some observations| Leaf pushing increases update timez Prefix can appear in many nodes (i.e. P5)| Because of memory “burst” reads, the entire node can be read with one memory accessz Try to make node size match burst sizeCS419Lulea uses a bitmap to compress out repeated entriesCS419Lulea bitmapCS419Lulea bitmap processing| Doesn’t this just increase processing?z Have to shift through the bitmap…| Yes, but memory access is by far the bottleneckz Hardware easily process the bitmapsz Even software can execute many instructions in one memory accessCS419Lulea trie performance| Very compact storage| Very fast lookup| But, updating the Lulea trie can be very expensive| For instance, adding a short prefix can result in a lot of leaf pushing…many entries must be modifiedCS419Tree Bitmap: first insight| Avoid the problems of expansion and leaf pushing by going back (conceptually) to the basic Unibit tree| BUT: Avoid the problem of many pointers by storing child nodes in contiguous memory areas as an arrayz Instead of many pointers, calculate offset into child arrayCS419Tree Bitmap with three-bit stridesOffsetFixed sized nodesCS419Tree Bitmap: second insight| To compress, use two bitmaps instead of just onez Internal prefix bitmapz External pointers bitmap| This avoids leaf pushingz (which is what gives Lulea potential large update times)CS419Tree Bitmap’s two bitmaps0000 1 1 0 1Extended Paths BitmapInternal Tree BitmapCS419Compact “nodes”| Each child node contains only:z Internal Tree Bitmapz Extended Paths Bitmapz One pointer to child array| But what about the next hop info for stored prefixes???z This is what was pushed to the leaves in Lulea…CS419Stored next hop info for prefixes| Store prefixes in a separate array adjacent in memory to the node| Internal tree bitmap tells us where in that array to find the pointer| Furthermore, don’t actually retrieve the next hop info until the very end of the searchz Adds one extra memory access at the very endCS419Next hop pointer array in adjacent memory locationP1, P2, P3P6, P4, P5, P7P9P8CS419Lookup algorithm (basic idea anyway)| Conceptually, the two bitmaps allow you to “reconstruct” the Unibit tree for a given stride (i.e. 3 bits)| The child pointer plus Extended Paths Bitmap tell you where to find the child node| The Internal Tree Bitmap tells you which Unibit tree nodes have prefixesCS419Lookup algorithm (basic idea