Information Centric Networking to Support Disaster …Page 2 Content Centric Networks • Use of Communications Networks has become largely Information-centric – Information of all

Information Centric Networking to Support Disaster Management

K. K. Ramakrishnan WinLab, Rutgers University, NJ

(thanks to all the partners of the GreenICN EU-Japan project)

Page 2

Content Centric Networks • Use of Communications Networks has become largely Information-centric

– Information of all types becoming electronic and network accessible – Access of information primarily by its name, instead of location

• Obtain “information” of interest by asking the network

– CCNs separate the objective of retrieving data from the specifics of how to accomplish it

• Information Overload: Producers and Consumers face scale challenges

– Large number of producers (publishers; data sources) • Tremendous number of information producers makes it difficult for a consumer to know

where to find relevant information

– Even larger number of consumers (subscribers, users querying/looking for content)

– Challenge: “whom and what to ask” & “whom and what to tell”

Interest data

2

Named Data Networks: Operation

• Named Data Networks (NDN) – Forwarding Engine

3

Prefix Face

Forwarding Information Base (FIB)

Prefix Request Face

Pending Interest Table (PIT)

Name Data

Content Store

Face 1

Face 2

Face 3

Face 4

Routing and forwarding in NDN

• Data producers announce their names (prefixes) • Routers propagate name(prefix) announcements • Each router builds FIB

– Can have multiple forwarding entries per prefix

• Each router also has the two other components: PIT (Pending Interest Table), ContentStore

– Consumer ‘broadcasts’ an interest

– Interest identifies data or a collection of data - all data items whose name has the interest as a prefix.

– Anything that receives the interest and has an element of the collection can respond

• Hierarchically structured names enables similar scaling as IP – NDN FIBs can be smaller since the multi-source model allows inexact state

(e.g., Bloom filter): count on false positives

4

Content Oriented Pub/Sub System (COPSS)

• Pub/sub is a desirable feature in CCN: Standing Query – From the point of view of a publisher:

• Time of publication independent of when the data is queried

– From the point of view of a subscriber:

• Have CCN take care of a query without him being aware of when someone else publishes a piece of content

• COPSS approach

– Built on top of NDN

– CCN-oriented multicast capability

– Efficiency and scalability

– Examples we addressed:

• Content-focused Twitter-like pub/sub system

• Online gaming & content streaming

5

COPSS Introduces Pub/Sub in CCN

• NDN (query/response): FIB, PIT, Content Store [CoNext 2009]

• COPSS (pub/sub): ST [ANCS 2011]

6

Prefix Face

/atnt/mobile 1


Prefix Req. Face

/atnt/mobile/iphone4.pdf 2


Name Data

/atnt/mobile/iphone4.pdf/v1 ...

Content Store

Face 1

Face 2

Face 3

Face 4

Face Bloom Filter of Prefix(es)

1 /atnt/mobile/iphone

Subscription Table (ST)

Communication in COPSS

• Rendezvous-Point based multicast – Rendezvous point establishment

7

R1

R6

R2

R7

R8

R9

R3

R5

R4

3

3

4

2 1 6

8 3

2 4

3 5

9 1

4

3 R7 I serve “/R7” I serve “/R7” I serve “/R7” I serve “/R7” I serve “/R7”

FIB for /R7

I serve “/R7” I serve “/R7”

I serve “/R7”


• Rendezvous-Point based multicast – Subscribe: C1 -> “/sports”

8

R1

R6

R2

R7

R8

R9

R3

R5

R4

3

3

4

2 1 6

8 3

2 4

3 5

9 1

4

3 R7

FIB for /R7

C1

Subscribe “/sports”

Face Prefix(es)

ST of R5



9

R1

R6

R2

R7

R8

R9

R3

R5

R4

3

3

4

2 1 6

8 3

2 4

3 5

9 1

4

3 R7

FIB for /R7

C1


Face Prefix(es)

C1 /sports

ST of R5

ST for /sports



10

R1

R6

R2

R7

R8

R9

R3

R5

R4

3

3

4

2 1 6

8 3

2 4

3 5

9 1

4

3 R7

FIB for /R7

C1

𝐻𝑎𝑠ℎ "/sports/∗ " = "/𝑅7"

Prefix Face

/R7 R9

FIB of R5

ST for /sports


Communication in COPSS • Rendezvous-Point based multicast

– Subscribe: C2 -> “/sports/football”

Prefix Face

/R7 R9

11

R1

R6

R2

R7

R8

R9

R3

R5

R4

3

3

4

2 1 6

8 3

2 4

3 5

9 1

4

3 R7

FIB for /R7

C1

FIB of R4 Face Prefix(es)

R9 /sports

ST for /sports

Subscribe “/sports/football”

C2

ST for /sports/football

ST of R7


• Rendezvous-Point based multicast – Subscribe: C2 -> “/sports/football”

12

R1

R6

R2

R7

R8

R9

R3

R5

R4

3

3

4

2 1 6

8 3

2 4

3 5

9 1

4

3 R7

FIB for /R7

C1

ST for /sports

Subscribe “/sports/football”

C2


Face Prefix(es)

R9 /sports /sports/football

ST of R7


• Rendezvous-Point based multicast – Publish: P -> “/sports/football”

13

R1

R6

R2

R7

R8

R9

R3

R5

R4

3

3

4

2 1 6

8 3

2 4

3 5

9 1

4

3 R7

FIB for /R7

C1

ST for /sports

C2


P

Multicast “/sports/football”

𝐻𝑎𝑠ℎ "/sports/∗ " = "/𝑅7" Interest “/R7”




14

R1

R6

R2

R7

R8

R9

R3

R5

R4

3

3

4

2 1 6

8 3

2 4

3 5

9 1

4

3 R7

FIB for /R7

C1

ST for /sports

C2


P


Face Prefix(es)

R9 /sports /sports/football

ST of R7



15

R1

R6

R2

R7

R8

R9

R3

R5

R4

3

3

4

2 1 6

8 3

2 4

3 5

9 1

4

3 R7

FIB for /R7

C1

ST for /sports

C2


P


Face Prefix(es)

R4 /sports/football

R5 /sports


ST of R9

2-Stage Dissemination

• Why? – We want both

• Timely pub/sub communication

• Large amount of data does not flood all the subscribers

• What? – Publisher multicasts snippet

– Subscribers query for the data if they are interested in the snippet

• Benefit: – Subscriber: indicate Interest

– Publisher: Policy control

– Network: Cache, Flow control…

16

Two Step Communication

• Pure push-based solution is not always perfect: – Not everyone may want a piece of published data although they are

interested in a topic

– Select a publication that a user has subscribed to - from one of multiple publishers

– Policy and access control at the publisher

• Desirable to have a two-step communication – Send “snippet” first to subscribers

– Subscribers can query for the data if they are interested in this piece of data

– Publishers can decide whether to provide the data (e.g., encrypted appropriately etc.)

17

Two Step Communication

Page 18

Publisher RN Subscriber

An

no

un

cem

ent

Path

CD: /RN/sports/football Snippet: /BBC/WorldCup/027

CD: /sports/football Snippet: /BBC/WorldCup/027

Announcement

Multicast

Name: /BBC/WorldCup/027 Query

Qu

ery

Path

Name: /BBC/WorldCup/027</segId> Content: “Detail of the match…”

Response

• Communication is a key component in managing Disasters – Timeliness is key to delivering critical information – Coverage of necessary and appropriate information related to the disaster is also

important • E.g., May be difficult to depend on information aggregators and commonly accessed search

engines

• Critical to efficiently distribute disaster notification and rescue information – Safety confirmation from refugees to their relatives and friends – Delivering emergency messages from local governments to refugees – Sharing information between local governments and refugees

• Energy and communication resources are at a premium after a disaster

– Base stations, end-devices running out of power • Need to work on prioritization and reliability of communication

• Networks may be fragmented

– Establish communication between communities with only intermittent connectivity. • Certain routes not available, servers unreachable, presence of mules, Delay tolerance

Disaster Management

19

Disaster Scenarios

• Disasters cause: – Link failures

– Base-station failures

– Increase in traffic demand (people want to use the network more)

• In the case of the East Japan Earthquake (March 11, 2011) – Up to 64% of base stations were reported out of order

– Traffic demand increased 9-fold

– 90% of calls had to be dropped – network couldn’t handle demand

Ad Hoc Communication is necessary to improve

Communication Resilience instead of only Network Resilience

Communication: Needs and Roles

• Communication network used to: – Seek for help

– Distribute important information

– Manage rescue teams

– Get in touch with friends and family • Authorities need to communicate critical information with

dynamically formed teams – Compsition of team members unknown, except the ‘name’ of the team

– Need for both querying for information and publicizing information • Need to be able to identify both senders and receivers by name

– Recipient hierarchies enable manage and control of information disseminated to manage situation

• Sub-teams within a particular authority (e.g., police) only need to know

• Geographical limits on relevance of information

Delivery Latency of Emails

Ref: http://www.soumu.go.jp/main_content/000117676.pdf

Get better information dissemination

performance than this(90%, 80min)

in Tokyo!

This figure shows the delivery times of emails exchanged between users in Kanto-Koshinetsu region from 14:46 to midnight on Mar. 4 and Mar. 11

Confirmation Methods of Individual’s Safety within 30 min after the shock

23

0

0.2

0.4

0.6

0.8

1

1.2

1.4

0102030405060708090

100

実際とった方法

最も役立った方法

効果

連絡成功確率（効果)

%

The most useful method

Efficiency(Success

Rate)

Success P

robabili

ty o

f

confirm

ation

(Eff

icie

ncy)

Actions User

Perc

enta

ge

Ref: The Asahi Shimbun, Jun.4,2011

85% of people were indoors and could

have easily accessed the Internet through

PCs, but they did not.

Core Network

Internet

BS broken

Backhaul

Failures

6%

85%

Blackout

9%

Cellular Network after a Disaster The Great Japan East Earthquake

2

4

Cellular Network during Disaster Situations

25

• Cellular-based ICN networks desirable – People use the communication means they are used to during normal

conditions

– Battery-operated base stations (BSs) are the most critical from energy perspective to provide connectivity during the days after a large-scale disaster

• Providing connectivity between fragmented networks due to failures and blackouts is key feature – We evaluate various solutions in fragmented networks

• Focus on “communication resiliency” in addition to traditional notions of “network resiliency”

• Security concerns need to be handled: authorities are separated from other citizens by fragmented networks

GreenICN Architecture

GreenICN Infrastructure

ICN for Green Video Sharing

Fragmented Network

End Systems and APIs

End Systems and APIs

Traffic and Resource Control

Naming, Routing, Mobility and Node Architecture

Access Control and Management in fragmented networks

Forwarding Strategy and IP Migration

Energy-Efficient Mobile Video Delivery and Caching

Support Routing and Caching in Fragmented Networks

Information Delivery in Disaster Scenarios

2

6

• Internames: A name-to-name architecture • Names identify all entities involved in communication:

– content, users, devices, logical as well as physical entities and services

• Names are not statically bound to their current location – entities can be mobile, and can be reached by any of a number of basic

communication primitives

– the communication path can be dynamically bound to any of a number of end-points (both source and destination), and the end-points themselves could change as needed (unlike a host->name approach)

– communication can span networks with different technologies and allow for disconnected operation

• Enhance communication resilience in fragmented networks – Naming scheme accounts for priority

– Safety confirmation delivery mechanism • Enhanced Content Oriented Pub/sub (COPSS) for fragmented networks: disruption and delay tolerance

• w/o the need for central mobility management, Mules are seen as logical links

A Content Centric Framework for Disaster Management

27

Internames: A name-to-Name Architecture

28

Architecture

29

Internet VANET

Name Resolution Service (NRS)

ICN #1

Object Resolution Service (ORS)

SENSOR NET GSM

WIFI

Routing Resolution Service (RRS)

• Key role played by the Name Resolution Service (NRS) – co-existence of multiple network “realms”, including current IP and

non-IP networks, glued together by an over-arching name-to-name communication primitive

– resolution can lead to different results as a function of policies

• e.g., in disaster conditions names are resolved to different locations w.r.t. normal conditions, transparently to users

– dynamic mapping to assure efficient mobility and resource management

– complexity to be evaluated taking into account cloud computing and cloud networking functionality that would have been hardly predictable only few years ago (and Google)

Internames: Name Resolution Service

30

Architecture Components

31

Namespace

Name Realm # A

Name Realm

# B

Network Realms

ICN #1

Internet

VANET

Name Resolution Service (NRS)

n2n://nriA:Bob.com/photo1.jpg n2n://nriA:Alice.com/cell

Name Router #A

NAP #1 (locator)

NAP #2 (locator)

ICN #2 RRS

SD (e.g. HTTP)

Name Router #B

SD (e.g. CCN)

Routing Example

32

bob/fs/doc1.txt

alice/browser

NRS

Name Router (160.80.85.1)

RRS

Next-hop (IP router)

Intra-domain Routing

Realm #A (IP/HTTP)

Realm #B (IP/CCNx)

HTTP

CCN router

Simple Message flow

33

ORS Client NRS

1.Search: bob + doc

4. Dest_Realm->[Rz,dst-loc,SD]*

NetworkRealm Rz

NRa

5. Get_Next_Hop_NR[Rz,dst-loc,SD]

/bob/fs/doc1.txt @dst-loc

*: If NRS returns multiple Name Realms, client will have to choose

RRS

6. Next_Hop_NR -> NRa

7. Get[/bob/fs/doc1.txt, Ra, dst-loc,SD]

NRz

NetworkRealm Ra

NRb

2. (/bob/fs/doc1.txt)

3. Get_Dest_Realm (/bob/fs/doc1.txt)

Migration

34

• End-Result – Unified framework and universal inter-operability, simplification of

overall architecture

– Avoid disadvantages of some existing ICN frameworks:

• Routing scalability: high number of prefixes and update frequency

• Security: e.g. users allowed to update the routing plane to make their content reachable

• Stateful forwarding, by populating PIT entries

• (D)DoS due to caching of fake content. Check of validity before caching is thus required (security engine in the router…costly)

• Lack of smooth migration paths from current IP-centric networks

• Cumbersome support for push services

Advantages of Internames

35

Content Oriented Pub/Sub System (COPSS)

• Pub/sub is a desirable feature for information dissemination – Enables time/space-decoupled communications, especially in disruption-

prone and fragmented networks

– From the point of view of a publisher:

• Time of publication independent of when the data is queried

– From the point of view of a subscriber:

• Have CCN take care of a query without having to be aware of when someone else publishes a piece of content

• COPSS approach

– Built on top of NDN

– CCN-oriented multicast capability

– Efficiency and scalability

• We’ve built a disaster information dissemination framework on top of COPSS

36

COPSS Introduces Pub/Sub in CCN

• NDN (query/response): FIB, PIT, Content Store [CoNext 2009]

• COPSS (pub/sub): ST [ANCS 2011]

37

Prefix Face

/atnt/mobile 1


Prefix Req. Face

/atnt/mobile/iphone4.pdf 2


Name Data

/atnt/mobile/iphone4.pdf/v1 ...

Content Store

Face 1

Face 2

Face 3

Face 4

Face Bloom Filter of Prefix(es)

1 /atnt/mobile/iphone

Subscription Table (ST)

• In disaster scenarios: – End-end connectivity is not guaranteed – Network resource (include storage) is limited

• Routing and caching schemes for information dissemination – Consider power consumption when replicating messages

• Avoid message flooding • How to deliver message between fragmented networks?

– Mobile device is not always connected to network • Support for Publish/Subscribe in disaster situations:

– Utilize data mules to deliver messages

• Separate the Logical interface (‘Face’) from the Physical interface

• Queue message on the ‘logical interface’ – Buffer messages until the physical interface establishes an association with

an appropriate ‘next hop’

Name-based Routing and Forwarding in fragmented networks

38

• Enable fragmented communities to exchange information

– Utilize mules to implement content-centric, delay-tolerant communication system

• Deliver important messages with lower delay and better reliability

• Prioritize messages

– Consider mule’s destination, data importance and size

• Exploit the predictability of mule movements

– Ambulances often go to hospitals, police to stations, etc

– Data mules (drones, buses...) have fixed paths

• For query-response

– Decouple interest and data path (avoid PIT and related rules such as time-outs)

Desirable Characteristics for CCN in Fragmented Networks

39

• Consider the safety confirmation scenario

– A user knows the name of person whose safety is being disseminated

• Links of logical topology constructed over a ‘dynamic’ physical network • Extend COPPS

– Avoid timeouts of the query-response type architecture

• Routing by FIB and subscription table

– Data mule has a route to RP on FIB and subscription table

Name-based Routing with COPSS

40

Data Mule

Shelter#1

Publish

Shelter#2

Subscribe

Central Office

Data Mule

Logical Topology Physical Network

Shelter#2 Shelter#1

RP Central Office

• Analyze the message arrival probability from publisher to subscriber

– Data mule does not always go on the same route

– If there are 10 data mules, 95% messages arrive to subscribers even if a data mule follows the route with 50% probability.

Effectiveness of Routing

41

number of data mules

• Communication is a critical component in managing disasters – For authorities

– For people affected by the disaster • A name-based communication interface can be a key to

providing timely information with much needed convenience – Internames further enhances current information-centric network

architectures with a name-name framework for sources and destinations

• Network fragmentation is likely – Communication Resilience is desired

– Integrate ICN and DTN concepts • We’re doing these as part of the GreenICN project - a EU-

Japan joint, cooperative effort

Summary

42

Documents

Information Centric Networking to Support Disaster …Page 2 Content Centric Networks • Use of Communications Networks has become largely Information-centric – Information of all