ETRI

www.idnet.re.kr 1

Bloom Filter-based Flat Name Resolution Sys-

tem for ICN

ICNRG Interim meeting, Paris

Jungha Hong, Woojik Chun, and Heeyoung JungSeptember 27, 2014

2014-09-27

ETRI

www.idnet.re.kr

Contents

• Review of last draft• Updated parts• Implementation issues

– False positive probability (FPP)– Bloom filter (BF) size

2014-09-27 2

ETRI

www.idnet.re.kr 3

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 dis-joint trees

• Bloom filter as an aggregated form of names is announced instead of announcing the whole list of names

2014-09-27

ETRI

www.idnet.re.kr 4

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

⋮

Announceto parents & peers

Bitwise OR

Lookup tableName Locator(s)

Name1 LOC1

Name2 LOC2-1, LOC2-2

2014-09-27

B-NRS server

ETRI

www.idnet.re.kr

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-27 5

ETRI

www.idnet.re.kr

Name registration (2)

2014-09-27 6

S1

S3S2

S7S6S5S4

Peering

Registration

BF Update

S : B-NRS server

ETRI

www.idnet.re.kr

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-27 7

Name Locator(s)

N1 LOC1

N2 LOC2-1, LOC2-2

N3 -

N4 LOC4-1, LOC4-2, LOC4-3

ETRI

www.idnet.re.kr

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 for-warded into parent

• Reply takes the reverse path of the request

2014-09-27 8

ETRI

www.idnet.re.kr

Lookup (2)

2014-09-27 9

S1

S3S2

S7S6S5S4

Peering

Request messageReply message

Nack

ETRI

www.idnet.re.kr

Comparison with other NRS (1)

2014-09-27 10

NRS

Distributed NRS

DHT-based NRS- MF-DMap- SAIL-MDHT

B-NRS

Centralized NRS

ETRI

www.idnet.re.kr

Comparison with other NRS (2)

2014-09-27 11

ETRI

www.idnet.re.kr

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-27 12

ETRI

www.idnet.re.kr

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-27 13

ETRI

www.idnet.re.kr

Lookup

2014-09-27 14

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 ofChildren& Peers

BF for Name

May implement with TCAM or GPU

Multicast,Iterative,

or RandomQuery

Distribution

BF for its own

p childrenq peers

ETRI

www.idnet.re.kr

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-27 15

ETRI

www.idnet.re.kr 162014-09-27

Questions or Commentswww.idnet.re.kr