Download presentation
Presentation is loading. Please wait.
Published byGinger Franklin Modified over 9 years ago
1
ETRI Bloom Filter-based Flat Name Resolution System for ICN ICNRG Interim meeting, Paris Jungha Hong, Woojik Chun, and Heeyoung Jung September 27, 2014 2014-09-27www.idnet.re.kr1
2
ETRI Contents Review of last draft Updated parts Implementation issues –False positive probability (FPP) –Bloom filter (BF) size 2014-09-27www.idnet.re.kr2
3
ETRI Background In ICN, location independent and flat name is assumed The binding between name and locator is required for lookup-by-name routing –Name resolution system (NRS) –Maintains and resolves the bindings The most important challenge on designing NRS is scalability on the ever-increasing number of named data object (NDO) Bloom filter-based NRS (B-NRS) is proposed –We utilize the hierarchical structure of B-NRS and bloom filter Constructs a network of B-NRS servers, which consists of a forest by several disjoint trees Bloom filter as an aggregated form of names is announced instead of announcing the whole list of names www.idnet.re.kr32014-09-27
4
ETRI Bloom filter-based NRS (B- NRS) B-NRS structure A network of B-NRS servers Relationships of parent-child and peering B-NRS server components Peering : B-NRS Server Name lookup table Bloom filters (BFs) for its own, from child, and from peer BF for its own BF from child 1 BF from child 2 BF from peer 1 BF from peer 2 Announce to parents & peers Bitwise OR Lookup table NameLocator(s) Name 1 LOC 1 Name 2 LOC 2-1, LOC 2-2 2014-09-27www.idnet.re.kr4 B-NRS server
5
ETRI Name registration (1) No constraints –Flat names can be registered to any arbitrary B-NRS server Followed by BF updates : insert-through No BF update when name is deleted –BF cannot handle deletion –Use periodic refresh 2014-09-27www.idnet.re.kr5
6
ETRI Name registration (2) 2014-09-27www.idnet.re.kr6 S1 S3 S2 S7 S6 S5 S4 Peering Registration BF Update S : B-NRS server
7
ETRI Locator update When a NDO presents(depresents) into(from) the network, only locator information is inserted(deleted) into(from) lookup table –No effects on BFs and structure of B-NRS –Inherently supports mobility 2014-09-27www.idnet.re.kr7 NameLocator(s) N1LOC1 N2LOC2-1, LOC2-2 N3- N4LOC4-1, LOC4-2, LOC4-3
8
ETRI Lookup (1) Through the BF test for the given name, locator lookup request is forwarded into the B-NRS server where the binding is actually stored –BF is a role of forwarding table Request message is forwarded into all child and peers which return positive answers –If none of BFs returns positive answer, then it is forwarded into parent Reply takes the reverse path of the request 2014-09-27www.idnet.re.kr8
9
ETRI Lookup (2) 2014-09-27www.idnet.re.kr9 S1 S3 S2 S7 S6 S5 S4 Peering Request message Reply message Nack
10
ETRI Comparison with other NRS (1) 2014-09-27www.idnet.re.kr10 NRS Distributed NRS DHT-based NRS -MF-DMap -SAIL-MDHT B-NRS Centralized NRS
11
ETRI Comparison with other NRS (2) 2014-09-27www.idnet.re.kr11
12
ETRI Analysis of BF size and FPP n is the # of names in a BF m is the size of BF k is the # of hash functions In lower tier: –n=1K, m=8Kb m/n = 8, k = 5.4 FPP = 0.02 (2%) 1K servers with 1K entries for each 1M entries 1MB memory for FPP=0.02 In higher tier: –n = 1M, m = 16Mb m/n = 16, k = 11.09 FPP = 0.00046 (0.046%) 1M servers with 1M entries for each 1T entries 2TB memory for FPP=0.00046 2014-09-27www.idnet.re.kr12
13
ETRI Can we reduce the amount of memory? Need to invent algorithm for –Insert, refresh, lookup Name 5(6) hash values memory chunk –Structuring memory hierarchy (TCAM with DRAM) –Consider the possibility of using GPU 2014-09-27www.idnet.re.kr13
14
ETRI Lookup 2014-09-27www.idnet.re.kr14 BF for Child 1 BF for Child 2 BF for Child 3 BF for Child p BF for Peer 1 BF for Peer 2 BF for Peer q } All 1’s match List of Children & Peers BF for Name May implement with TCAM or GPU Multicast, Iterative, or Random Query Distribution BF for its own p children q peers
15
ETRI Design choice – ongoing work Same or different hash functions –Rehash in every server ? How many children and peers –Many servers have the limited no. of names How many levels (tiers) –Not so deep –Related with query distribution overhead H/W assisted implementation –TCAM or GPU –Performance for higher level server 2014-09-27www.idnet.re.kr15
16
ETRI 2014-09-27www.idnet.re.kr16 Questions or Comments www.idnet.re.kr
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.