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
Forwarding Information Base (FIB)
Prefix Req. Face
/atnt/mobile/iphone4.pdf 2
Pending Interest Table (PIT)
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”
Communication in COPSS
• 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
Communication in COPSS
• Rendezvous-Point based multicast – Subscribe: C1 -> “/sports”
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
Subscribe “/sports”
Face Prefix(es)
C1 /sports
ST of R5
ST for /sports
Communication in COPSS
• Rendezvous-Point based multicast – Subscribe: C1 -> “/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
Subscribe “/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
Communication in COPSS
• 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
ST for /sports/football
Face Prefix(es)
R9 /sports /sports/football
ST of R7
Communication in COPSS
• 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
ST for /sports/football
P
Multicast “/sports/football”
𝐻𝑎𝑠ℎ "/sports/∗ " = "/𝑅7" Interest “/R7”
Multicast “/sports/football”
Communication in COPSS
• Rendezvous-Point based multicast – Publish: P -> “/sports/football”
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
ST for /sports/football
P
Multicast “/sports/football”
Face Prefix(es)
R9 /sports /sports/football
ST of R7
Communication in COPSS
• Rendezvous-Point based multicast – Publish: P -> “/sports/football”
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
ST for /sports/football
P
Multicast “/sports/football”
Face Prefix(es)
R4 /sports/football
R5 /sports
Multicast “/sports/football”
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
Forwarding Information Base (FIB)
Prefix Req. Face
/atnt/mobile/iphone4.pdf 2
Pending Interest Table (PIT)
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