www.idnet.re.kr 1

Bloom Filter-based Flat Name Resolution Sys-

tem for ICN

ICNRG Interim Meeting, Dallas

Jungha Hong, Woojik Chun, and Heeyoung JungMarch 22, 2015

2015-03-22

www.idnet.re.kr

Name Resolution Sys-tem• Basic functionality of NRS is to return a correspon-

dent locator for a given name

• Key operations– Name registration

• How/Where to insert names especially for flat names– Locator update

• How to insert/update locators– Locator lookup

• How to find the binding between name and locator

2015-03-22 2

www.idnet.re.kr

B-NRS structure

2015-03-22 3

Peering

Peering

: BF for its own

: BFs from child

: BFs from peer

N1 L1

N2 L2-1,L2-2

N3 L3

: B-NRS server

: Name lookup table (NLT)

www.idnet.re.kr

B-NRS Key operations

2015-03-22 4

Registration(N1) Insert (N1,LOC)

BF updateBF update

BF update

Lookup-request (N2)BF check (No)

Lookup-requestBF check (S3)

Lookup-requestBF check (S9)

Lookup-requestNLT lookup

Lookup-reply

S1

S2

S3

S4(N1)

S5

S6 S7S8 S9

(N2)

Lookup-reply

Lookup-reply

Lookup-reply

www.idnet.re.kr

NRS requirements (1)

• Scalability– The number of named data objects are significantly in-

creasing considering IoT, sensor data, vehicular, etc.– Distributes names and aggregates flat namesHierarchical structure of B-NRS and bloom filters are uti-

lized

DHT based approach is the most popular one• The binging must be stored in a certain server other than the

owner’s• Lookup message may be propagated through the long pathsNo constrains on registration in B-NRS

2015-03-22 5

www.idnet.re.kr

NRS requirements (2)

• Fast resolution– Initial packet may be significantly delayed or dropped if the

resolution time gets too longPeering relationship is allowed in the hierarchical B-NRS struc-

ture Operators can manage the name registration to support localityBF search has a fixed constant time

• Fast update– NRS should adapt quickly with changes according to mobile and

multi-homed devicesJust needs to change the locator information in the name

lookup table, which is related to fast resolution

2015-03-22 6

www.idnet.re.kr

NRS requirements (3)

• Resilience– If NRS lookup falis, then there is no way to send packets

toward destination since source knows only its nameRecovered by BF refresh

• Security– NRS can be a potential target for attacks such DoS at-

tacks– Messages from/to NRS server should be authenticatedSelf-certifying name is used

2015-03-22 7

www.idnet.re.kr

Periodic refresh for name deletion• No action when name is deleted from NRS

– False-positive error rate may increase for a while

• New BF will be passed to the parent(s) by its own policy

– Periodically rebuilds and replaces BFs using the shadow memory

– Refresh frequency can be few hours, a day, a week, a month, etc.

2015-03-22 8

www.idnet.re.kr

GPU assisted implemen-tation

2015-03-22 9

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’smatch

List ofchildren& peers

Extract only corresponding bits for the given name lookup

Implement with GPU

Multicast,Iterative,

or RandomQuery

Distribution

BF for its own

p children& q peers

www.idnet.re.kr 102015-03-22

Questions or Commentswww.idnet.re.kr