ICNRG M. Arumaithurai
Internet-Draft University of Goettingen
Intended status: Informational J. Seedorf
Expires: April 24, 2014 NEC
A. Tagami
KDDI R&D Labs
K. Ramakrishnan
AT&T
N. Blefari Melazzi
Univ. Tor Vergata
October 21, 2013
Using ICN in disaster scenarios
draft-seedorf-icn-disaster-01
Abstract
Information Centric Networking is a new paradigm where the network
provides users with named content, instead of communication channels
between hosts. This document outlines some research directions for
Information Centric Networking (ICN) with respect to applying ICN
approaches for coping with natural or human-generated, large-scale
disasters.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 24, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Arumaithurai, et al. Expires April 24, 2014 [Page 1]
Internet-Draft ICN disaster October 2013
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Disaster Scenarios . . . . . . . . . . . . . . . . . . . . . 2
3. Research Challenges and Benefits of ICN . . . . . . . . . . . 3
3.1. High-Level Research Challenges . . . . . . . . . . . . . 3
3.2. How ICN can be Beneficial . . . . . . . . . . . . . . . . 4
4. Use Cases and Requirements . . . . . . . . . . . . . . . . . 5
5. The GreenICN Project . . . . . . . . . . . . . . . . . . . . 7
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Normative References . . . . . . . . . . . . . . . . . . . . 8
Appendix A. Acknowledgment . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
This document summarizes some research challenges for coping with
natural or human-generated, large-scale disasters. Further, the
document discusses potential directions for applying Information
Centric Networking (ICN) to address these challenges.
Section 2 gives some examples of what can be considered a large-scale
disaster and what the effects of such disasters on communication
networks are. Section 3 outlines why ICN can be beneficial in such
scenarios and provides a high-level overview on corresponding
research challenges. Section 4 lists some of the use case scenarios
that could be used to derive the requirements. Related research
activities are ongoing in the GreenICN research project; Section 5
provides an overview of this project.
2. Disaster Scenarios
An enormous earthquake hit Northeastern Japan (Tohoku areas) on March
11, 2011, and caused extensive damages including blackouts, fires,
tsunamis and a nuclear crisis. The lack of information and means of
communication caused the isolation of several Japanese cities. This
impacted the safety and well-being of residents, and affected rescue
work, evacuation activities, and the supply chain for food and other
Arumaithurai, et al. Expires April 24, 2014 [Page 2]
Internet-Draft ICN disaster October 2013
essential items. Even in the Tokyo area that is 300km away from the
Tohoku area, more than 100,000 people became 'returner' refugees, who
could not reach their homes because they had no means of public
transportation (the Japanese government has estimated that more than
6.5 million people would become returner refugees if such a
catastrophic disaster were to hit the Tokyo area). This recent
earthquake in Northeastern Japan also showed that the current network
is vulnerable against disasters and that mobile phones have become
the lifelines for communication including safety confirmation. The
aftermath of a disaster puts a high strain on available resources due
to the need for communication by everyone. Authorities such as the
President/Prime-Minister, local authorities, Police, fire brigades,
and rescue and medical personnel would like to inform the citizens of
possible shelters, food, or even of impending danger. Relatives
would like to communicate with each other and be informed about their
well-being. Affected citizens would like to make enquiries of food
distribution centres, shelters or report trapped, missing people to
the authorities. Moreover, damage to communication equipment, in
addition to the already existing heavy demand for communication
highlights the issue of fault-tolerance and energy efficiency.
Additionally, disasters caused by humans such as a terrorist attack
need to be considered, i.e. disasters that are caused deliberately
and willfully and have the element of human intent. In such cases,
the perpetrators could be actively harming the network by launching a
Denial-of-Service attack or by monitoring the network passively to
obtain information exchanged, even after the main disaster itself has
taken place. Unlike some natural disasters that are predictable
using weather forecasting technologies and have a slower onset and
occur in known geographical regions and seasons, terrorist attacks
may occur suddenly without any advance warning. Nevertheless, there
exist many commonalities between natural and human-induced disasters,
particularly relating to response and recovery, communication, search
and rescue, and coordination of volunteers.
3. Research Challenges and Benefits of ICN
3.1. High-Level Research Challenges
Given a disaster scenario as described in Section 2, on a high-level
one can derive the following (incomplete) list of corresponding
technical challenges:
o Enabling usage of functional parts of the infrastructure, even
when these are disconnected from the rest of the network: Assuming
that parts of the network infrastructure (i.e. cables/links,
routers, mobile bases stations, ...) are functional after a
disaster has taken place, it is desirable to be able to continue
Arumaithurai, et al. Expires April 24, 2014 [Page 3]
Internet-Draft ICN disaster October 2013
using such components for communication as much as possible. This
is challenging when these components are disconnected from the
backhaul, thus forming fragmented networks. This is especially
true for today's mobile networks which are comprised of a
centralised architecture, mandating connectivity to central
entities (which are located in the core of the mobile network) for
communication. But also in fixed networks, access to a name
resolution service is often necessary to access some given
content.
o Decentralised authentication: In mobile networks, users are
authenticated via central entities. In order to communicate in
fragmented or disconnected parts of a mobile network, the
challenge of decentralising such user authentication arises.
Irrespective of the network being fixed or mobile, data origin
authentication of content retrieved from the network is
challenging when being 'offline' (e.g. disconnected from servers
of a security infrastructure such as a PKI).
o Delivering/obtaining information in congested networks: Due to
broken cables, failed routers, etc., it is likely that in a
disaster scenario the communication network has much less overall
capacity for handling traffic. Thus, significant congestion can
be expected in parts of the infrastructure. It is therefore a
challenge to guarantee message delivery in such a scenario. This
is even more important as in the case of a disaster aftermath, it
may be crucial to deliver certain information to recipients (e.g.
warnings to citizens).
The list above is most likely incomplete; future revisions of this
document intend to add additional challenges to the list.
3.2. How ICN can be Beneficial
Several aspects of ICN make related approaches attractive candidates
for addressing the challenges described in Section 3.1. Below is an
(incomplete) list of considerations why ICN approaches can be
beneficial to address these challenges:
o Routing-by-name: ICN protocols natively route by named data
objects and can identify devices by names, effectively moving the
process of name resolution from the application layer to the
network layer. This functionality is very handy in a fragmented
network where reference to location-based, fixed addresses may not
work as a consequence of disruptions. For instance, name
resolution with ICN does not necessarily rely on the reachability
of application-layer servers (e.g. DNS resolvers).
Arumaithurai, et al. Expires April 24, 2014 [Page 4]
Internet-Draft ICN disaster October 2013
o Authentication of named data objects: ICN is built around the
concept of named data objects. Several proposals exist for
integrating the concept of 'self-certifying data' into a naming
scheme (see e.g. [RFC6920]). With such approaches, the origin of
data retrieved from the network can be authenticated without
relying on a trusted third party or PKI.
o Content-based access control: ICN can regulate access to data
objects (e.g. only to a specific user or class of users) by means
of content-based security; this functionality could facilitate
trusted communications among peer users in isolated areas of the
network.
o Caching: Caching content along a delivery path is an inherent
concept in ICN. Caching helps in handling huge amounts of
traffic, and can help to avoid congestion in the network (e.g.
congestion in backhaul links can be avoided by delivering content
from caches at access nodes).
The list above is most likely incomplete; future revisions of this
document intend to add more considerations to the list and to argue
in more detail why ICN is suitable for addressing the aforementioned
research challenges.
4. Use Cases and Requirements
This Section describes some use cases for the aforementioned disaster
scenario (as outlined in Section 2) and discusses the corresponding
technical requirements for enabling these use cases.
o Delivering Messages to Relatives/Friends: After a disaster
strikes, citizens want to confirm to each other that they are
safe. For instance, shortly after a large disaster (e.g.,
Earthquake, Tornado), people have moved to different refugee
shelters. The mobile network is not fully recovered and is
fragmented, but some base stations are functional. This use case
imposes the following high-level requirements: a) People must be
able to communicate with others in the same network fragment, b)
people must be able to communicate with others that are located in
different fragmented parts of the overall network. More
concretely, the following requirements are needed to enable the
use case: a) a mechanism for scalable message forwarding scheme
that dynamically adapts to changing conditions in disconnected
networks, b) DTN-like mechanisms for getting information from
disconnected island to another disconnected island, and c) data
origin authentication so that users can confirm that the messages
they receive are indeed from their relatives or friends.
Arumaithurai, et al. Expires April 24, 2014 [Page 5]
Internet-Draft ICN disaster October 2013
o Spreading Crucial Information to Citizens: State authorities want
to be able to convey important information (e.g. warnings, or
information on where to go or how to behave) to citizens. These
kinds of information shall reach as many citizens as possible.
i.e. Crucial content from legal authorities shall potentially
reach all users in time. The technical requirements that can be
derived from this use case are: a) Data origin authentication,
such that citizens can confrim the authenticity of messages sent
by authorities, b) mechanisms that guarantee the timeliness and
loss-free delivery of such information, which may include
techniques for prioritizing certain messages in the network
depending on who sent them, and c) DTN-like mechanisms for getting
information from disconnected island to another disconnected
island.
o Spreading (Crucial) Information from Citizens to Citizens: After a
disaster strikes, affected citizens might want to deliver
information to other citizens as well as authorities. This
information could concern dangerous places to avoid, food-
shelters, information about people in need of help. This type of
information might have to be verified for authenticity before
being delivered to others. This use-scenario is different from
the first one since the goal of the sender in this use-case is to
maximize reachability and not to limit access. The onus is on the
receiver and other forwarding nodes to decide on the validity of
the data. This use case imposes the following high-level
requirements: a) People should be able to communicate with
authorities either in the same or different network fragment, b)
Certain nodes (e.g. authorities) should have the capability to
verify the information before it spreads. More concretely, the
following requirements are needed to enable the use case: a) a
mechanism for scalable message forwarding scheme that dynamically
adapts to changing conditions in disconnected networks, b) DTN-
like mechanisms for getting information from disconnected island
to another disconnected island, and c) third party verification so
that users can confirm that the messages they receive are verified
by authorities.
It can be observed that different key use cases for disaster
scenarios imply overlapping and similar technical requirements for
fulfilling them. As discussed in Section 3.2, ICN approaches are
envisioned to be very suitable for addressing these requirements with
actual technical solutions. The list of use-cases are not exhaustive
and future versions of this draft will include more use-scenarios
based on discussions in the GreenICN project (Section 5), as well as
dicussions in the mailing list and at ICNRG.
Arumaithurai, et al. Expires April 24, 2014 [Page 6]
Internet-Draft ICN disaster October 2013
5. The GreenICN Project
This section provides a brief overview of the GreenICN project. You
can find more information at the project web site http://
www.greenicn.org/
The recently formed GreenICN project, funded by the EU and Japan,
aims to accelerate the practical deployment of ICN, addressing how
ICN networks and devices can operate in a highly scalable and energy-
efficient way. The project will exploit the designed infrastructure
to support multiple applications including the following two broad
exemplary scenarios: 1) The aftermath of a disaster, e.g. hurricane,
earthquake, tsunami, or a human-generated network breakdown when
energy and communication resources are at a premium and it is
critical to efficiently distribute disaster notification and critical
rescue information. Key to this is the ability to exploit fragmented
networks with only intermittent connectivity, the potential
exploitation of multiple modalities of communication and use of query
/response and pub/sub approaches; 2) Scalable, efficient pub/sub
video delivery, a key requirement in both normal and disaster
situations.
GreenICN will expose a functionality-rich API to spur the creation of
new applications and services expected to drive industry and
consumers, with special focus on the EU and Japanese environments,
into ICN adoption. Our team, comprising researchers with diverse
expertise, system and network equipment manufacturers, device
vendors, a startup, and mobile telecommunications operators, is very
well positioned to design, prototype and deploy GreenICN technology,
and validate usability and performance of real-world GreenICN
applications, contributing to create a new, low-energy, Information-
Centric global communications infrastructure. We also plan to make
contributions to standards bodies to further the adoption of ICN
technologies.
6. Conclusion
This document outlines some research directions for Information
Centric Networking (ICN) with respect to applying ICN approaches for
coping with natural or human-generated, large-scale disasters. The
document describes high-level research challenges as well as a
general rationale why ICN approaches could be beneficial to address
these challenges. One main objective of this document is to gather
feedback from the ICN community within the IETF and IRTF regarding
how ICN approaches can be suitable to solve the presented research
challenges. Future revisions of this draft intend to include
additional research challenges and to discuss what implications this
research area has regarding related, future IETF standardisation.
Arumaithurai, et al. Expires April 24, 2014 [Page 7]
Internet-Draft ICN disaster October 2013
7. Normative References
[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
Keranen, A., and P. Hallam-Baker, "Naming Things with
Hashes", RFC 6920, April 2013.
Appendix A. Acknowledgment
This document has been supported by the GreenICN project (GreenICN:
Architecture and Applications of Green Information Centric Networking
), a research project supported jointly by the European Commission
under its 7th Framework Program (contract no. 608518) and the
National Institute of Information and Communications Technology
(NICT) in Japan (contract no. 167). The views and conclusions
contained herein are those of the authors and should not be
interpreted as necessarily representing the official policies or
endorsements, either expressed or implied, of the GreenICN project,
the European Commission, or NICT.
Authors' Addresses
Mayutan Arumaithurai
University of Goettingen
Goldschmidtstr. 7
Goettingen 37077
Germany
Phone: +49 551 39 172031
Fax: +49 551 39 172031
Email: arumaithurai@cs.uni-goettingen.de
Jan Seedorf
NEC
Kurfuerstenanlage 36
Heidelberg 69115
Germany
Phone: +49 6221 4342 221
Fax: +49 6221 4342 155
Email: seedorf@neclab.eu
Arumaithurai, et al. Expires April 24, 2014 [Page 8]
Internet-Draft ICN disaster October 2013
Atsushi Tagami
KDDI R&D Labs
2-1-15 Ohara
Fujimino, Saitama 356-85025
Japan
Phone: +81 49 278 73651
Fax: +81 49 278 7510
Email: tagami@kddilabs.jp
K. K. Ramakrishnan
AT&T
180 Park Ave
Florham Park NJ 07932
USA
Email: kkrama@research.att.com
Nicola Blefari Melazzi
Univ. Tor Vergata
Via del Politecnico, 1
Roma 00133
Italy
Phone: +39 06 7259 7501
Fax: +39 06 7259 7435
Email: blefari@uniroma2.it
Arumaithurai, et al. Expires April 24, 2014 [Page 9]