One document matched: draft-seedorf-icn-disaster-01.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="no" ?>
<?rfc subcompact="no" ?>

<rfc category="info" docName="draft-seedorf-icn-disaster-01"
     ipr="trust200902">
  <front>
    <title abbrev="ICN disaster">Using ICN in disaster scenarios</title>
    
    <author fullname="Mayutan Arumaithurai" initials="M." surname="Arumaithurai">
      <organization>University of Goettingen</organization>

      <address>
        <postal>
          <street>Goldschmidtstr. 7</street>
	  
          <code>37077</code>
	  
          <city>Goettingen</city>

          <country>Germany</country>
        </postal>

        <phone>+49 551 39 172031</phone>

        <facsimile>+49 551 39 172031</facsimile>

        <email>arumaithurai@cs.uni-goettingen.de</email>

      </address>
    </author>


    <author fullname="Jan Seedorf" initials="J." surname="Seedorf">
      <organization abbrev="NEC">NEC</organization>

      <address>
        <postal>
          <street>Kurfuerstenanlage 36</street>
	  
          <code>69115</code>
	  
          <city>Heidelberg</city>

          <country>Germany</country>
        </postal>

        <phone>+49 6221 4342 221</phone>

        <facsimile>+49 6221 4342 155</facsimile>

        <email>seedorf@neclab.eu</email>

      </address>
    </author>
    
    <author initials='A.' surname='Tagami'
	    fullname='Atsushi Tagami'>
      <organization>KDDI R&D Labs</organization>
      <address>
      <postal>
          <street>2-1-15 Ohara</street>
	  
          <code>356-85025</code>
	  
          <city>Fujimino, Saitama  </city>

          <country>Japan</country>
        </postal>

        <phone>+81 49 278 73651</phone>

        <facsimile>+81 49 278 7510</facsimile>  
      
      
	<email>tagami@kddilabs.jp</email>
      </address>
    </author>

    <author initials='K. K.' surname='Ramakrishnan' fullname='K. K. Ramakrishnan'>
      <organization>AT&T</organization>
      <address>
        <postal>
          <street>180 Park Ave</street>
          <city>Florham Park</city>
          <code>NJ 07932</code>
          <country>USA</country>
        </postal>
        <email>kkrama@research.att.com</email>
      </address>
    </author>



    <author initials='N.' surname='Blefari Melazzi' fullname='Nicola Blefari Melazzi'>
      <organization>Univ. Tor Vergata</organization>
      <address>
        <postal>
          <street>Via del Politecnico, 1</street>
          <city>Roma</city>
          <code>00133</code>
          <country>Italy</country>
        </postal>
        
        <phone>+39 06 7259 7501</phone>

        <facsimile>+39 06 7259 7435</facsimile>  
        
        
        <email>blefari@uniroma2.it</email>
      </address>
    </author>
    

    <date year="2013" />

    <area>IRTF</area>

    <workgroup>ICNRG</workgroup>

    <keyword>ICN</keyword>


    <abstract>
      <t>
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.
      </t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">

      <t>
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.
      </t>
      
       <t>
<xref target="disaster"/> gives some examples of what can be considered a large-scale disaster and what the effects of such disasters on communication networks are. <xref target="whyicn"/> outlines why ICN can be beneficial in such scenarios and provides a high-level overview on corresponding research challenges. <xref target="usecases"/> 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; <xref target="greenicn"/> provides an overview of this project. 
      </t>
      
      
    </section>
    

    
  
      <section anchor="disaster" title="Disaster Scenarios">

      <t>
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 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.
      </t>
      
  <t>
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.
</t>
  
  
    </section>
  
  
        <section anchor="whyicn" title="Research Challenges and Benefits of ICN">


<section anchor="challenges" title="High-Level Research Challenges">
      <t>
Given a disaster scenario as described in <xref target="disaster"/>, on a high-level one can derive the following (incomplete) list of corresponding technical challenges:
<list style="symbols">
          

          <t>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 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.</t>
          
         <t>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).</t>
         
         <t>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).</t>
         
       
          
        </list> 

The list above is most likely incomplete; future revisions of this document intend to add additional challenges to the list.
      </t>   
</section>
  
<section anchor="howicncanhelp" title="How ICN can be Beneficial">
      <t>
Several aspects of ICN make related approaches attractive candidates for addressing the challenges described in <xref target="challenges"/>. Below is an (incomplete) list of considerations why ICN approaches can be beneficial to address these challenges:

<list style="symbols">

         <t>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).</t>
         
         <t>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. <xref target="RFC6920"/>). With such approaches, the origin of data retrieved from the network can be authenticated without relying on a trusted third party or PKI.</t>
         
         <t>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.</t>
                  
         <t>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).</t>


         
 </list>
 
 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.
 </t> 

         
</section>  
  
    </section>
    
    
          <section anchor="usecases" title="Use Cases and Requirements">

      <t>
This Section describes some use cases for the aforementioned disaster scenario (as outlined in <xref target="disaster"/>) and discusses the corresponding technical requirements for enabling these use cases.


<list style="symbols">

         <t>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. </t>
         
         <t>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.</t>

  <t>
    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.</t>
         
 </list>


It can be observed that different key use cases for disaster scenarios imply overlapping and similar technical requirements for fulfilling them. As discussed in <xref target="howicncanhelp"/>, 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 (<xref target="greenicn"/>), as well as dicussions in the mailing list and at ICNRG. 
    </t>
      

  
  
    </section>
    
    
  
    <section anchor="greenicn" title="The GreenICN Project">

      <t>
This section provides a brief overview of the GreenICN project. You can find more information at the project web site http://www.greenicn.org/
      </t>

      <t>
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.
	</t>
	
	<t>
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.
	</t>

      
    </section>


       <section anchor="conclusion" title="Conclusion">
           <t>
     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.
           </t>
       </section>     
    

  
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.6920" ?>
    </references>

	
	



    <section title="Acknowledgment">
      <t>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.</t>

     </section>

  </back>
</rfc>