idnits 2.17.1 draft-seedorf-icn-disaster-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 29, 2015) is 3034 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICNRG J. Seedorf 3 Internet-Draft NEC 4 Intended status: Informational M. Arumaithurai 5 Expires: July 1, 2016 University of Goettingen 6 A. Tagami 7 KDDI R&D Labs 8 K. Ramakrishnan 9 University of California 10 N. Blefari Melazzi 11 University Tor Vergata 12 December 29, 2015 14 Using ICN in disaster scenarios 15 draft-seedorf-icn-disaster-05 17 Abstract 19 Information Centric Networking (ICN) is a new paradigm where the 20 network provides users with named content, instead of communication 21 channels between hosts. This document outlines some research 22 directions for Information Centric Networking with respect to 23 applying ICN approaches for coping with natural or human-generated, 24 large-scale disasters. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on July 1, 2016. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Disaster Scenarios . . . . . . . . . . . . . . . . . . . . . 3 62 3. Research Challenges and Benefits of ICN . . . . . . . . . . . 4 63 3.1. High-Level Research Challenges . . . . . . . . . . . . . 4 64 3.2. How ICN can be Beneficial . . . . . . . . . . . . . . . . 5 65 3.3. ICN as Starting Point vs. Existing DTN Solutions . . . . 7 66 4. Use Cases and Requirements . . . . . . . . . . . . . . . . . 8 67 5. Solution Design . . . . . . . . . . . . . . . . . . . . . . . 9 68 6. The GreenICN Project . . . . . . . . . . . . . . . . . . . . 11 69 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 72 8.2. Informative References . . . . . . . . . . . . . . . . . 12 73 Appendix A. Acknowledgment . . . . . . . . . . . . . . . . . . . 14 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 76 1. Introduction 78 This document summarizes some research challenges for coping with 79 natural or human-generated, large-scale disasters. In particular, 80 the document discusses potential directions for applying Information 81 Centric Networking (ICN) to address these challenges. 83 There are existing research approaches (for instance, see further the 84 discussions in the IETF DTN Research Group [dtnrg]) and an IETF 85 specification [RFC5050] for disruptant tolerant networking, which is 86 a key necessecity for communicating in the disaster scenarios we are 87 considering in this document (see further Section 3.1). 88 'Disconnection tolerance' can thus be achieved with these existing 89 DTN approaches. However, while these approaches can provide 90 independence from an existing communication infrastructure (which 91 indeed may not work anymore after a disaster has happened), ICN 92 offers as key concepts suitable naming schemes and multicast 93 communication which together enable many key (publish/subribe-based) 94 use cases for communication after a disaster (e.g. message 95 prioritisation, one-to-many delivery of important messages, or group 96 communication among rescue teams, see further Section 4). One could 97 add such features to existing DTN protocols and solutions; however, 98 in this document we explore the use of ICN as starting point for 99 building a communication architecture that works well before and 100 after a disaster. We discuss the relationship between the ICN 101 approaches (for enabling communication after a disaster) discussed in 102 this document with existing work from the DTN community in more depth 103 in Section 3.3. 105 Section 2 gives some examples of what can be considered a large-scale 106 disaster and what the effects of such disasters on communication 107 networks are. Section 3 outlines why ICN can be beneficial in such 108 scenarios and provides a high-level overview on corresponding 109 research challenges. Section 4 describes some concrete use cases and 110 requirements for disaster scenarios. In Section 5, some concrete 111 ICN-based solutions approaches are outlined. Related research 112 activities are ongoing in the GreenICN research project; Section 6 113 provides an overview of this project. 115 2. Disaster Scenarios 117 An enormous earthquake hit Northeastern Japan (Tohoku areas) on March 118 11, 2011, and caused extensive damages including blackouts, fires, 119 tsunamis and a nuclear crisis. The lack of information and means of 120 communication caused the isolation of several Japanese cities. This 121 impacted the safety and well-being of residents, and affected rescue 122 work, evacuation activities, and the supply chain for food and other 123 essential items. Even in the Tokyo area that is 300km away from the 124 Tohoku area, more than 100,000 people became 'returner' refugees, who 125 could not reach their homes because they had no means of public 126 transportation (the Japanese government has estimated that more than 127 6.5 million people would become returner refugees if such a 128 catastrophic disaster were to hit the Tokyo area). 130 That earthquake in Japan also showed that the current network is 131 vulnerable against disasters and that mobile phones have become the 132 lifelines for communication including safety confirmation. The 133 aftermath of a disaster puts a high strain on available resources due 134 to the need for communication by everyone. Authorities such as the 135 President/Prime-Minister, local authorities, Police, fire brigades, 136 and rescue and medical personnel would like to inform the citizens of 137 possible shelters, food, or even of impending danger. Relatives 138 would like to communicate with each other and be informed about their 139 wellbeing. Affected citizens would like to make enquiries of food 140 distribution centres, shelters or report trapped, missing people to 141 the authorities. Moreover, damage to communication equipment, in 142 addition to the already existing heavy demand for communication 143 highlights the issue of fault-tolerance and energy efficiency. 145 Additionally, disasters caused by humans such as a terrorist attack 146 may need to be considered, i.e. disasters that are caused 147 deliberately and willfully and have the element of human intent. In 148 such cases, the perpetrators could be actively harming the network by 149 launching a Denial-of-Service attack or by monitoring the network 150 passively to obtain information exchanged, even after the main 151 disaster itself has taken place. Unlike some natural disasters that 152 are predictable using weather forecasting technologies and have a 153 slower onset and occur in known geographical regions and seasons, 154 terrorist attacks may occur suddenly without any advance warning. 155 Nevertheless, there exist many commonalities between natural and 156 human-induced disasters, particularly relating to response and 157 recovery, communication, search and rescue, and coordination of 158 volunteers. 160 The timely dissemination of information generated and requested by 161 all the affected parties during and the immediate aftermath of a 162 disaster is difficult to provide within the current context of global 163 information aggregators (such as Google, Yahoo, Bing etc.) that need 164 to index the vast amounts of specialized information related to the 165 disaster. Specialized coverage of the situation and timely 166 dissemination are key to successfully managing disaster situations. 167 We believe that network infrastructure capability provided by 168 Information Centric Networks can be suitable, in conjunction with 169 application and middleware assistance. 171 3. Research Challenges and Benefits of ICN 173 3.1. High-Level Research Challenges 175 Given a disaster scenario as described in Section 2, on a high-level 176 one can derive the following (incomplete) list of corresponding 177 technical challenges: 179 o Enabling usage of functional parts of the infrastructure, even 180 when these are disconnected from the rest of the network: Assuming 181 that parts of the network infrastructure (i.e. cables/links, 182 routers, mobile bases stations, ...) are functional after a 183 disaster has taken place, it is desirable to be able to continue 184 using such components for communication as much as possible. This 185 is challenging when these components are disconnected from the 186 backhaul, thus forming fragmented networks. This is especially 187 true for today's mobile networks which are comprised of a 188 centralised architecture, mandating connectivity to central 189 entities (which are located in the core of the mobile network) for 190 communication. But also in fixed networks, access to a name 191 resolution service is often necessary to access some given 192 content. 194 o Decentralised authentication: In mobile networks, users are 195 authenticated via central entities. In order to communicate in 196 fragmented or disconnected parts of a mobile network, the 197 challenge of decentralising such user authentication arises. 198 Independently of the network being fixed or mobile, data origin 199 authentication of content retrieved from the network is 200 challenging when being 'offline' (e.g. disconnected from servers 201 of a security infrastructure such as a PKI). 203 o Delivering/obtaining information and traffic prioritization in 204 congested networks: Due to broken cables, failed routers, etc., it 205 is likely that in a disaster scenario the communication network 206 has much less overall capacity for handling traffic. Thus, 207 significant congestion can be expected in parts of the 208 infrastructure. It is therefore a challenge to guarantee message 209 delivery in such a scenario. This is even more important as in 210 the case of a disaster aftermath, it may be crucial to deliver 211 certain information to recipients (e.g. warnings to citizens) with 212 higher priority than other content. 214 o Delay/Disruption Tolerant Approach: Fragmented networks makes it 215 difficult to support end-to-end communication. However, 216 communication in general and especially during disaster can 217 tolerate some form of delay. E.g. in order to know if his/her 218 relatives are safe or a 'SOS' call need not be supported in an 219 end-to-end manner. It is sufficient to improve communication 220 resilience in order to deliver such important messages. 222 o Energy Efficiency: Long-lasting power outages may lead to 223 batteries of communication devices running out, so designing 224 energy-efficient solutions is very important in order to maintain 225 a usable communication infrastructure. 227 o Contextuality: Like any communication in general, disaster 228 scenarios are inherently contextual. Aspects of geography, the 229 people affected, the rescue communities involved, the languages 230 being used and many other contextual aspects are highly relevant 231 for an efficient realization of any rescue effort and, with it, 232 therealization of the required communication. 234 The list above is most likely incomplete; future revisions of this 235 document intend to add additional challenges to the list. 237 3.2. How ICN can be Beneficial 239 Several aspects of ICN make related approaches attractive candidates 240 for addressing the challenges described in Section 3.1. Below is an 241 (incomplete) list of considerations why ICN approaches can be 242 beneficial to address these challenges: 244 o Routing-by-name: ICN protocols natively route by named data 245 objects and can identify objects by names, effectively moving the 246 process of name resolution from the application layer to the 247 network layer. This functionality is very handy in a fragmented 248 network where reference to location-based, fixed addresses may not 249 work as a consequence of disruptions. For instance, name 250 resolution with ICN does not necessarily rely on the reachability 251 of application-layer servers (e.g. DNS resolvers). In highly 252 decentralised scenarios (e.g. in infrastructureless, opportunistic 253 environments) the ICN routing-by-name paradigm effectively may 254 lead to a 'replication-by-name' approach, where content is 255 replicated depending on its name. 257 o Authentication of named data objects: ICN is built around the 258 concept of named data objects. Several proposals exist for 259 integrating the concept of 'self-certifying data' into a naming 260 scheme (see e.g. [RFC6920]). With such approaches, the origin of 261 data retrieved from the network can be authenticated without 262 relying on a trusted third party or PKI. 264 o Content-based access control: ICN can regulate access to data 265 objects (e.g. only to a specific user or class of users) by means 266 of content-based security; this functionality could facilitate 267 trusted communications among peer users in isolated areas of the 268 network. 270 o Caching: Caching content along a delivery path is an inherent 271 concept in ICN. Caching helps in handling huge amounts of 272 traffic, and can help to avoid congestion in the network (e.g. 273 congestion in backhaul links can be avoided by delivering content 274 from caches at access nodes). 276 o Sessionless: ICN does not require full end-to-end connectivity. 277 This feature facilitates a seemless aggregation between a normal 278 network and a fragmented network, which needs DTN-like message 279 forwarding. 281 o Potential to run traditional IP-based services (IP-over-ICN): 282 While ICN and DTN promote the development of novel applications 283 that fully utilize the new capabiliticbies of the ICN/DTN network, 284 work in [Trossen2015] has shown that an ICN-enabled network can 285 transport IP-based services, either directly at IP or even at HTTP 286 level. With this, IP- and ICN/DTN-based services can coexist, 287 providing the necessary support of legacy applications to affected 288 users, while reaping any benefits from the native support for ICN 289 in future applications. 291 o Opportunities for traffic engineering and traffic prioritization: 292 ICN provides the possibility to perform traffic engineering based 293 on the name of desired content. This enables priority based 294 replication depending on the scope of a given message 295 [Psaras2014]. In addition, as [Trossen2015], among others, have 296 pointed out, the realization ICN services and particularly of IP- 297 based services on top of ICN provide further traffic engineering 298 opportunities. The latter not only relate to the utilization of 299 cached content, as outlined before, but to the ability to flexbily 300 adapt to route changes (important in unreliable infrastructure 301 such as in disaster scenarios), mobility support without anchor 302 points (again, important when parts of the infrastructure are 303 likely to fail) and the inherent support for multicast and 304 multihoming delivery. 306 The list above is most likely incomplete; future revisions of this 307 document intend to add more considerations to the list and to argue 308 in more detail why ICN is suitable for addressing the aforementioned 309 research challenges. 311 3.3. ICN as Starting Point vs. Existing DTN Solutions 313 There has been quite some work in the DTN (Delay Tolerant Networking) 314 community on disaster communication (for instance, see further the 315 discussions in the IETF DTN Research Group [dtnrg]). However, most 316 DTN work lacks important features such as publish/subscribe (pub/sub) 317 capabilities, caching, multicast delivery, and message prioritisation 318 based on content types, which are needed in the disaster scenarios we 319 consider. One could add such features to existing DTN protocols and 320 solutions, and indeed individual proposals for adding such features 321 to DTN protocols have been made (e.g. [Greifenberg2008] [Yoneki2007] 322 propose the use of a pub/sub-based multicast distribution 323 infrastructure for DTN-based opportunistic networking environments). 325 However, arguably ICN---having these intrinsic properties (as also 326 outlined above)---makes a better starting point for building a 327 communication architecture that works well before and after a 328 disaster. For a disaster-enhanced ICN system this would imply the 329 following advantages: a) ICN data mules would have built-in caches 330 and can thus return content for interests straight on, b) requests do 331 not necessarily be routed to a source (as with existing DTN 332 protocols), instead any data mule or end-user can in principle 333 respond to an interest, c) Built-in multi-cast delivery implies 334 energy-efficient large-scale spreading of important information which 335 is crucial in disaster scenarios, and d) pub/sub extension for 336 popular ICN implementations exist [COPSS2011] which are very suitable 337 for efficient group communication in disasters and provide better 338 reliability, timeliness and scalability as compared to existing pub/ 339 sub approaches in DTN [Greifenberg2008] [Yoneki2007]. 341 Finally, most DTN routing algorithms have been solely designed for 342 particular DTN scenarios. By extending ICN approaches for DTN-like 343 scenarios, one ensures that a solution works in regular (i.e. well- 344 connected) settings just as well (which can be important in reality, 345 where a routing algorithm should work before and after a disaster). 346 It is thus reasonable to start with existing ICN approaches and 347 extend them with the necessary features needed in disaster scenarios. 349 4. Use Cases and Requirements 351 This Section describes some use cases for the aforementioned disaster 352 scenario (as outlined in Section 2) and discusses the corresponding 353 technical requirements for enabling these use cases. 355 o Delivering Messages to Relatives/Friends: After a disaster 356 strikes, citizens want to confirm to each other that they are 357 safe. For instance, shortly after a large disaster (e.g., 358 Earthquake, Tornado), people have moved to different refugee 359 shelters. The mobile network is not fully recovered and is 360 fragmented, but some base stations are functional. This use case 361 imposes the following high-level requirements: a) People must be 362 able to communicate with others in the same network fragment, b) 363 people must be able to communicate with others that are located in 364 different fragmented parts of the overall network. More 365 concretely, the following requirements are needed to enable the 366 use case: a) a mechanism for scalable message forwarding scheme 367 that dynamically adapts to changing conditions in disconnected 368 networks, b) DTN-like mechanisms for getting information from 369 disconnected island to another disconnected island, c) data origin 370 authentication so that users can confirm that the messages they 371 receive are indeed from their relatives or friends, and d) the 372 support for contextual caching in order to provide the right 373 information to the right set of affected people in the most 374 efficient manner. 376 o Spreading Crucial Information to Citizens: State authorities want 377 to be able to convey important information (e.g. warnings, or 378 information on where to go or how to behave) to citizens. These 379 kinds of information shall reach as many citizens as possible. 380 i.e. Crucial content from legal authorities shall potentially 381 reach all users in time. The technical requirements that can be 382 derived from this use case are: a) Data origin authentication, 383 such that citizens can confrim the authenticity of messages sent 384 by authorities, b) mechanisms that guarantee the timeliness and 385 loss-free delivery of such information, which may include 386 techniques for prioritizing certain messages in the network 387 depending on who sent them, and c) DTN-like mechanisms for getting 388 information from disconnected island to another disconnected 389 island. 391 It can be observed that different key use cases for disaster 392 scenarios imply overlapping and similar technical requirements for 393 fulfilling them. As discussed in Section 3.2, ICN approaches are 394 envisioned to be very suitable for addressing these requirements with 395 actual technical solutions. In [Robitzsch2015], a more elaborate set 396 of requirements is provided that addresses, among disaster scenarios, 397 a communication infrastructure for communities facing several 398 geographic, economic and political challenges. 400 5. Solution Design 402 This Section outlines some ICN-based approaches that aim at 403 fulfilling the previously mentioned use cases and requirements. 405 o ICN 'data mules': To facilitate the exchange of messages between 406 different network fragments, mobile entitites can act as ICN 'data 407 mules' which are equipped with storage space and move around the 408 disaster-stricken area gathering information to be disseminated. 409 As the mules move around, they deliver messages to other 410 individuals or points of attachment to different fragments of the 411 network. These 'data mules' could have a pre-determined path (an 412 ambulance going to and fro from a hospital), a fixed path (drone/ 413 robot assigned specifically to do so) or a completely random path 414 (doctors moving from one camp to another). 416 o Priority dependent Name-based replication: By allowing spatial and 417 temporal scoping of named messages, priority based replication 418 depending on the scope of a given message is possible. Clearly, 419 spreading information in disaster cases involves space and time 420 factors that have to be taken into account as messages spread. A 421 concrete approach for such scope-based prioritisation of ICN 422 messages in disasters, called 'NREP', has been proposed 423 [Psaras2014], where ICN messages have attributes such as user- 424 defined priority, space, and temporal-validity. These attributes 425 are then taken into account when prioritizing messages. In 426 [Psaras2014], evaluations show how this approach can be applied to 427 the use case 'Delivering Messages to Relatives/Friends' decribed 428 in Section 4. 430 o Information Resilience through Decentralised Forwarding: In a 431 dynamic or disruptive environment, such as the aftermath of a 432 disaster, both users and content servers may dynamically join and 433 leave the network (due to mobility or network fragmentation). 434 Thus, users might attach to the network and request content when 435 the network is fragmented and the corresponding content origin is 436 not reachable. In order to increase information resilience, 437 content cached both in in-network caches and in end-user devices 438 should be exploited. A concrete approach for the exploitation of 439 content cached in user devices is presented in [Sourlas2015]. The 440 proposal in [Sourlas2015] includes enhancements to the NDN router 441 design, as well as an alternative Interest forwarding scheme which 442 enables users to retrieve cached content when the network is 443 fragmented and the content origin is not reachable. Evaluations 444 show that this approach is a valid tool for the retrieval of 445 cached content in disruptive cases and can be applied to tackle 446 the challenges presented in Section 3.1. 448 o Energy Efficiency: A large-scale disaster causes a large-scale 449 blackout and thus a number of base stations (BSs) will be operated 450 by their batteries. Capacities of such batteries are not large 451 enough to provide cellular communication for several days after 452 the disaster. In order to prolong the batteries' life from one 453 day to several days, different techniques need to be explored: 454 Priority control, cell-zooming, and collaborative upload. Cell 455 zooming switches-off some of the BSs because switching-off is the 456 only way to reduce power consumed at the idle time. In cell 457 zooming, areas covered by such inactive BSs are covered by the 458 active BSs. Collaborative communication is complementary to cell 459 zooming and reduces power proportional to a load of a BS. The 460 load represents cellular frequency resources. In collaborative 461 communication, end-devices delegate sending and receiving messages 462 to and from a base station to a representative end-device of which 463 radio propagation quality is better. The design of an ICN-based 464 publish/subscribe protocol that incorporates collaborative upload 465 is ongoing work. In particular, the integration of collaborative 466 upload techniques into the COPSS (Content Oriented Publish/ 467 Subscribe System)} framework is envisioned [COPSS2011]. 469 o Data-centric confidentiality and access control: In ICN, the 470 requested content is not anymore associated to a trusted server or 471 an endpoint location, but it can be retrieved from any network 472 cache or a replica server. This call for 'data-centric' security, 473 where security relies on information exclusively contained in the 474 message itself, or, if extra information provided by trusted 475 entities is needed, this should be gathered through offline, 476 asynchronous, and non interactive communication, rather than from 477 an explicit online interactive handshake with trusted servers. 478 The ability to guarantee security without any online entities is 479 particularly important in disaster scenarios with fragmented 480 networks. One concrete cryptographic technique is 'Ciphertext- 481 Policy Attribute Based Encryption' (CP-ABE), allowing a party to 482 encrypt a content specifying a policy, which consists in a Boolean 483 expression over attributes, that must be satisfied by those who 484 want to decrypt such content. Such encryption schemes tie 485 confidentiality and access-control to the transferred data, which 486 can be transmitted also in an unsecured channel, enabling the 487 source to specify the set of nodes allowed to decrypt. 489 o Decentralised authentication of messages: Self-certifying names 490 provide the property that any entity in a distributed system can 491 verify the binding between a corresponding public key and the 492 self-certifying name without relying on a trusted third party. 493 Self-certifying names thus provide a decentralized form of data 494 origin authentication. However, self-certifying names lack a 495 binding with a corresponding real-world identity. Given the 496 decentralised nature of a disaster scenario, a PKI-based approach 497 for binding self-certifying names with real-world identities is 498 not feasible. Instead, a Web-of-Trust can be used to provide this 499 binding. Not only are the cryptograohic signatures used within a 500 Web-of-Trust independent of any central authority; there are also 501 technical means for making the inherent trust relationships of a 502 Web-of-Trust available to network entities in a decentralised, 503 'offline' fashion, such that information received can be assessed 504 based on these trust relationships. A concrete scheme for such an 505 approach has been published in [Seedorf2014], where also concrete 506 examples for fulfilling the use case 'Delivering Messages to 507 Relatives/Friends' with this approach are given. 509 6. The GreenICN Project 511 This section provides a brief overview of the GreenICN project. You 512 can find more information at the project web site 513 http://www.greenicn.org/ 515 The recently formed GreenICN project, funded by the EU and Japan, 516 aims to accelerate the practical deployment of ICN, addressing how 517 ICN networks and devices can operate in a highly scalable and energy- 518 efficient way. The project will exploit the designed infrastructure 519 to support multiple applications including the following two broad 520 exemplary scenarios: 1) The aftermath of a disaster, e.g. hurricane, 521 earthquake, tsunami, or a human-generated network breakdown when 522 energy and communication resources are at a premium and it is 523 critical to efficiently distribute disaster notification and critical 524 rescue information. Key to this is the ability to exploit fragmented 525 networks with only intermittent connectivity, the potential 526 exploitation of multiple modalities of communication and use of 527 query/response and pub/sub approaches; 2) Scalable, efficient pub/sub 528 video delivery, a key requirement in both normal and disaster 529 situations. 531 GreenICN will expose a functionality-rich API to spur the creation of 532 new applications and services expected to drive industry and 533 consumers, with special focus on the EU and Japanese environments, 534 into ICN adoption. Our team, comprising researchers with diverse 535 expertise, system and network equipment manufacturers, device 536 vendors, a startup, and mobile telecommunications operators, is very 537 well positioned to design, prototype and deploy GreenICN technology, 538 and validate usability and performance of real-world GreenICN 539 applications, contributing to create a new, low-energy, Information- 540 Centric global communications infrastructure. We also plan to make 541 contributions to standards bodies to further the adoption of ICN 542 technologies. 544 7. Conclusion 546 This document outlines some research directions for Information 547 Centric Networking (ICN) with respect to applying ICN approaches for 548 coping with natural or human-generated, large-scale disasters. The 549 document describes high-level research challenges as well as a 550 general rationale why ICN approaches could be beneficial to address 551 these challenges. One main objective of this document is to gather 552 feedback from the ICN community within the IETF and IRTF regarding 553 how ICN approaches can be suitable to solve the presented research 554 challenges. Future revisions of this draft intend to include 555 additional research challenges and to discuss what implications this 556 research area has regarding related, future IETF standardisation. 558 8. References 560 8.1. Normative References 562 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 563 Specification", RFC 5050, DOI 10.17487/RFC5050, November 564 2007, . 566 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 567 Keranen, A., and P. Hallam-Baker, "Naming Things with 568 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 569 . 571 8.2. Informative References 573 [COPSS2011] 574 Chen, J., Arumaithurai, M., Jiao, L., Fu, X., and K. 575 Ramakrishnan, "COPSS: An Efficient Content Oriented 576 Publish/Subscribe System", Seventh ACM/IEEE Symposium on 577 Architectures for Networking and Communications Systems 578 (ANCS), 2011. 580 [dtnrg] Fall, K. and J. Ott, "Delay-Tolerant Networking Research 581 Group - DTNRG", https://irtf.org/dtnrg. 583 [Greifenberg2008] 584 Greifenberg, J. and D. Kutscher, "Efficient publish/ 585 subscribe-based multicast for opportunistic networking 586 with self-organized resource utilization", Advanced 587 Information Networking and Applications-Workshops, 2008. 589 [Psaras2014] 590 Psaras, I., Saino, L., Arumaithurai, M., Ramakrishnan, K., 591 and G. Pavlou, "Name-Based Replication Priorities in 592 Disaster Cases", 2nd Workshop on Name Oriented Mobility 593 (NOM), 2014. 595 [Robitzsch2015] 596 Robitzsch, S., Trossen, D., Theodorou, C., Barker, T., and 597 A. Sathiaseel, "D2.1: Usage Scenarios and Requirements"", 598 H2020 project RIFE, public deliverable, 2015. 600 [Seedorf2014] 601 Seedorf, J., Kutscher, D., and F. Schneider, 602 "Decentralised Binding of Self-Certifying Names to Real- 603 World Identities for Assessment of Third-Party Messages in 604 Fragmented Mobile Networks", 2nd Workshop on Name 605 Oriented Mobility (NOM), 2014. 607 [Sourlas2015] 608 Sourlas, V., Tassiulas, L., Psaras, I., and G. Pavlou, 609 "Information Resilience through User-Assisted Caching in 610 Disruptive Content-Centric Networks", 14th IFIP 611 NETWORKING, May 2015. 613 [Trossen2015] 614 Trossen, D., "IP-over-ICN", To appear in EUCNC 2015. 616 [Yoneki2007] 617 Yoneki, E., Hui, P., Chan, S., and J. Crowcroft, "A socio- 618 aware overlay for publish/subscribe communication in delay 619 tolerant networks", Proceedings of the 10th ACM Symposium 620 on Modeling, Analysis, and Simulation of Wireless and 621 Mobile Systems, 2007. 623 Appendix A. Acknowledgment 625 The authors would like to thank Ioannis Psaras for useful comments. 626 Further, the authors would like to thank Joerg Ott and Dirk Trossen 627 for valuable comments and input, in particular regarding existing 628 work form the DTN community which is highly related to the ICN 629 approaches suggested in this document. 631 This document has been supported by the GreenICN project (GreenICN: 632 Architecture and Applications of Green Information Centric Networking 633 ), a research project supported jointly by the European Commission 634 under its 7th Framework Program (contract no. 608518) and the 635 National Institute of Information and Communications Technology 636 (NICT) in Japan (contract no. 167). The views and conclusions 637 contained herein are those of the authors and should not be 638 interpreted as necessarily representing the official policies or 639 endorsements, either expressed or implied, of the GreenICN project, 640 the European Commission, or NICT. 642 Authors' Addresses 644 Jan Seedorf 645 NEC 646 Kurfuerstenanlage 36 647 Heidelberg 69115 648 Germany 650 Phone: +49 6221 4342 221 651 Fax: +49 6221 4342 155 652 Email: seedorf@neclab.eu 654 Mayutan Arumaithurai 655 University of Goettingen 656 Goldschmidt Str. 7 657 Goettingen 37077 658 Germany 660 Phone: +49 551 39 172046 661 Fax: +49 551 39 14416 662 Email: arumaithurai@informatik.uni-goettingen.de 663 Atsushi Tagami 664 KDDI R&D Labs 665 2-1-15 Ohara 666 Fujimino, Saitama 356-85025 667 Japan 669 Phone: +81 49 278 73651 670 Fax: +81 49 278 7510 671 Email: tagami@kddilabs.jp 673 K. K. Ramakrishnan 674 University of California 675 Riverside CA 676 USA 678 Email: kkramakrishnan@yahoo.com 680 Nicola Blefari Melazzi 681 University Tor Vergata 682 Via del Politecnico, 1 683 Roma 00133 684 Italy 686 Phone: +39 06 7259 7501 687 Fax: +39 06 7259 7435 688 Email: blefari@uniroma2.it