File: rfc8884.html

package info (click to toggle)
doc-rfc 20230121-1
links: PTS, VCS
area: non-free
in suites: bookworm, forky, sid, trixie
size: 1,609,944 kB
file content (2327 lines) | stat: -rw-r--r-- 104,519 bytes
parent folder | download | duplicates (2)
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 8884: Research Directions for Using Information-Centric Networking (ICN) in Disaster Scenarios</title>
<meta content="Jan Seedorf" name="author">
<meta content="Mayutan Arumaithurai" name="author">
<meta content="Atsushi Tagami" name="author">
<meta content="K. K. Ramakrishnan" name="author">
<meta content="Nicola Blefari Melazzi" name="author">
<meta content="
       Information-Centric Networking (ICN) 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 ICN with respect to applying ICN
      approaches for coping with natural or human-generated, large-scale
      disasters. This document is a product of the Information-Centric
      Networking Research Group (ICNRG). 
       
    " name="description">
<meta content="xml2rfc 3.3.0" name="generator">
<meta content="ICN" name="keyword">
<meta content="8884" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.3.0
    Python 3.6.10
    appdirs 1.4.4
    ConfigArgParse 1.2.3
    google-i18n-address 2.3.5
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.2
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.19.0
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.3.1
    requests 2.22.0
    setuptools 40.6.2
    six 1.14.0
    WeasyPrint 51
-->
<link href="rfc8884.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

  NOTE: Changes at the bottom of this file overrides some earlier settings.

  Once the style has stabilized and has been adopted as an official RFC style,
  this can be consolidated so that style settings occur only in one place, but
  for now the contents of this file consists first of the initial CSS work as
  provided to the RFC Formatter (xml2rfc) work, followed by itemized and
  commented changes found necssary during the development of the v3
  formatters.

*/

/* fonts */
@import url('https://fonts.googleapis.com/css?family=Noto+Sans'); /* Sans-serif */
@import url('https://fonts.googleapis.com/css?family=Noto+Serif'); /* Serif (print) */
@import url('https://fonts.googleapis.com/css?family=Roboto+Mono'); /* Monospace */

@viewport {
  zoom: 1.0;
  width: extend-to-zoom;
}
@-ms-viewport {
  width: extend-to-zoom;
  zoom: 1.0;
}
/* general and mobile first */
html {
}
body {
  max-width: 90%;
  margin: 1.5em auto;
  color: #222;
  background-color: #fff;
  font-size: 14px;
  font-family: 'Noto Sans', Arial, Helvetica, sans-serif;
  line-height: 1.6;
  scroll-behavior: smooth;
}
.ears {
  display: none;
}

/* headings */
#title, h1, h2, h3, h4, h5, h6 {
  margin: 1em 0 0.5em;
  font-weight: bold;
  line-height: 1.3;
}
#title {
  clear: both;
  border-bottom: 1px solid #ddd;
  margin: 0 0 0.5em 0;
  padding: 1em 0 0.5em;
}
.author {
  padding-bottom: 4px;
}
h1 {
  font-size: 26px;
  margin: 1em 0;
}
h2 {
  font-size: 22px;
  margin-top: -20px;  /* provide offset for in-page anchors */
  padding-top: 33px;
}
h3 {
  font-size: 18px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h4 {
  font-size: 16px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h5, h6 {
  font-size: 14px;
}
#n-copyright-notice {
  border-bottom: 1px solid #ddd;
  padding-bottom: 1em;
  margin-bottom: 1em;
}
/* general structure */
p {
  padding: 0;
  margin: 0 0 1em 0;
  text-align: left;
}
div, span {
  position: relative;
}
div {
  margin: 0;
}
.alignRight.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignRight.art-text pre {
  padding: 0;
}
.alignRight {
  margin: 1em 0;
}
.alignRight > *:first-child {
  border: none;
  margin: 0;
  float: right;
  clear: both;
}
.alignRight > *:nth-child(2) {
  clear: both;
  display: block;
  border: none;
}
svg {
  display: block;
}
.alignCenter.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignCenter.art-text pre {
  padding: 0;
}
.alignCenter {
  margin: 1em 0;
}
.alignCenter > *:first-child {
  border: none;
  /* this isn't optimal, but it's an existence proof.  PrinceXML doesn't
     support flexbox yet.
  */
  display: table;
  margin: 0 auto;
}

/* lists */
ol, ul {
  padding: 0;
  margin: 0 0 1em 2em;
}
ol ol, ul ul, ol ul, ul ol {
  margin-left: 1em;
}
li {
  margin: 0 0 0.25em 0;
}
.ulCompact li {
  margin: 0;
}
ul.empty, .ulEmpty {
  list-style-type: none;
}
ul.empty li, .ulEmpty li {
  margin-top: 0.5em;
}
ul.compact, .ulCompact,
ol.compact, .olCompact {
  line-height: 100%;
  margin: 0 0 0 2em;
}

/* definition lists */
dl {
}
dl > dt {
  float: left;
  margin-right: 1em;
}
/* 
dl.nohang > dt {
  float: none;
}
*/
dl > dd {
  margin-bottom: .8em;
  min-height: 1.3em;
}
dl.compact > dd, .dlCompact > dd {
  margin-bottom: 0em;
}
dl > dd > dl {
  margin-top: 0.5em;
  margin-bottom: 0em;
}

/* links */
a {
  text-decoration: none;
}
a[href] {
  color: #22e; /* Arlen: WCAG 2019 */
}
a[href]:hover {
  background-color: #f2f2f2;
}
figcaption a[href],
a[href].selfRef {
  color: #222;
}
/* XXX probably not this:
a.selfRef:hover {
  background-color: transparent;
  cursor: default;
} */

/* Figures */
tt, code, pre, code {
  background-color: #f9f9f9;
  font-family: 'Roboto Mono', monospace;
}
pre {
  border: 1px solid #eee;
  margin: 0;
  padding: 1em;
}
img {
  max-width: 100%;
}
figure {
  margin: 0;
}
figure blockquote {
  margin: 0.8em 0.4em 0.4em;
}
figcaption {
  font-style: italic;
  margin: 0 0 1em 0;
}
@media screen {
  pre {
    overflow-x: auto;
    max-width: 100%;
    max-width: calc(100% - 22px);
  }
}

/* aside, blockquote */
aside, blockquote {
  margin-left: 0;
  padding: 1.2em 2em;
}
blockquote {
  background-color: #f9f9f9;
  color: #111; /* Arlen: WCAG 2019 */
  border: 1px solid #ddd;
  border-radius: 3px;
  margin: 1em 0;
}
cite {
  display: block;
  text-align: right;
  font-style: italic;
}

/* tables */
table {
  width: 100%;
  margin: 0 0 1em;
  border-collapse: collapse;
  border: 1px solid #eee;
}
th, td {
  text-align: left;
  vertical-align: top;
  padding: 0.5em 0.75em;
}
th {
  text-align: left;
  background-color: #e9e9e9;
}
tr:nth-child(2n+1) > td {
  background-color: #f5f5f5;
}
table caption {
  font-style: italic;
  margin: 0;
  padding: 0;
  text-align: left;
}
table p {
  /* XXX to avoid bottom margin on table row signifiers. If paragraphs should
     be allowed within tables more generally, it would be far better to select on a class. */
  margin: 0;
}

/* pilcrow */
a.pilcrow {
  color: #666; /* Arlen: AHDJ 2019 */
  text-decoration: none;
  visibility: hidden;
  user-select: none;
  -ms-user-select: none;
  -o-user-select:none;
  -moz-user-select: none;
  -khtml-user-select: none;
  -webkit-user-select: none;
  -webkit-touch-callout: none;
}
@media screen {
  aside:hover > a.pilcrow,
  p:hover > a.pilcrow,
  blockquote:hover > a.pilcrow,
  div:hover > a.pilcrow,
  li:hover > a.pilcrow,
  pre:hover > a.pilcrow {
    visibility: visible;
  }
  a.pilcrow:hover {
    background-color: transparent;
  }
}

/* misc */
hr {
  border: 0;
  border-top: 1px solid #eee;
}
.bcp14 {
  font-variant: small-caps;
}

.role {
  font-variant: all-small-caps;
}

/* info block */
#identifiers {
  margin: 0;
  font-size: 0.9em;
}
#identifiers dt {
  width: 3em;
  clear: left;
}
#identifiers dd {
  float: left;
  margin-bottom: 0;
}
#identifiers .authors .author {
  display: inline-block;
  margin-right: 1.5em;
}
#identifiers .authors .org {
  font-style: italic;
}

/* The prepared/rendered info at the very bottom of the page */
.docInfo {
  color: #666; /* Arlen: WCAG 2019 */
  font-size: 0.9em;
  font-style: italic;
  margin-top: 2em;
}
.docInfo .prepared {
  float: left;
}
.docInfo .prepared {
  float: right;
}

/* table of contents */
#toc  {
  padding: 0.75em 0 2em 0;
  margin-bottom: 1em;
}
nav.toc ul {
  margin: 0 0.5em 0 0;
  padding: 0;
  list-style: none;
}
nav.toc li {
  line-height: 1.3em;
  margin: 0.75em 0;
  padding-left: 1.2em;
  text-indent: -1.2em;
}
/* references */
.references dt {
  text-align: right;
  font-weight: bold;
  min-width: 7em;
}
.references dd {
  margin-left: 8em;
  overflow: auto;
}

.refInstance {
  margin-bottom: 1.25em;
}

.references .ascii {
  margin-bottom: 0.25em;
}

/* index */
.index ul {
  margin: 0 0 0 1em;
  padding: 0;
  list-style: none;
}
.index ul ul {
  margin: 0;
}
.index li {
  margin: 0;
  text-indent: -2em;
  padding-left: 2em;
  padding-bottom: 5px;
}
.indexIndex {
  margin: 0.5em 0 1em;
}
.index a {
  font-weight: 700;
}
/* make the index two-column on all but the smallest screens */
@media (min-width: 600px) {
  .index ul {
    -moz-column-count: 2;
    -moz-column-gap: 20px;
  }
  .index ul ul {
    -moz-column-count: 1;
    -moz-column-gap: 0;
  }
}

/* authors */
address.vcard {
  font-style: normal;
  margin: 1em 0;
}

address.vcard .nameRole {
  font-weight: 700;
  margin-left: 0;
}
address.vcard .label {
  font-family: "Noto Sans",Arial,Helvetica,sans-serif;
  margin: 0.5em 0;
}
address.vcard .type {
  display: none;
}
.alternative-contact {
  margin: 1.5em 0 1em;
}
hr.addr {
  border-top: 1px dashed;
  margin: 0;
  color: #ddd;
  max-width: calc(100% - 16px);
}

/* temporary notes */
.rfcEditorRemove::before {
  position: absolute;
  top: 0.2em;
  right: 0.2em;
  padding: 0.2em;
  content: "The RFC Editor will remove this note";
  color: #9e2a00; /* Arlen: WCAG 2019 */
  background-color: #ffd; /* Arlen: WCAG 2019 */
}
.rfcEditorRemove {
  position: relative;
  padding-top: 1.8em;
  background-color: #ffd; /* Arlen: WCAG 2019 */
  border-radius: 3px;
}
.cref {
  background-color: #ffd; /* Arlen: WCAG 2019 */
  padding: 2px 4px;
}
.crefSource {
  font-style: italic;
}
/* alternative layout for smaller screens */
@media screen and (max-width: 1023px) {
  body {
    padding-top: 2em;
  }
  #title {
    padding: 1em 0;
  }
  h1 {
    font-size: 24px;
  }
  h2 {
    font-size: 20px;
    margin-top: -18px;  /* provide offset for in-page anchors */
    padding-top: 38px;
  }
  #identifiers dd {
    max-width: 60%;
  }
  #toc {
    position: fixed;
    z-index: 2;
    top: 0;
    right: 0;
    padding: 0;
    margin: 0;
    background-color: inherit;
    border-bottom: 1px solid #ccc;
  }
  #toc h2 {
    margin: -1px 0 0 0;
    padding: 4px 0 4px 6px;
    padding-right: 1em;
    min-width: 190px;
    font-size: 1.1em;
    text-align: right;
    background-color: #444;
    color: white;
    cursor: pointer;
  }
  #toc h2::before { /* css hamburger */
    float: right;
    position: relative;
    width: 1em;
    height: 1px;
    left: -164px;
    margin: 6px 0 0 0;
    background: white none repeat scroll 0 0;
    box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
    content: "";
  }
  #toc nav {
    display: none;
    padding: 0.5em 1em 1em;
    overflow: auto;
    height: calc(100vh - 48px);
    border-left: 1px solid #ddd;
  }
}

/* alternative layout for wide screens */
@media screen and (min-width: 1024px) {
  body {
    max-width: 724px;
    margin: 42px auto;
    padding-left: 1.5em;
    padding-right: 29em;
  }
  #toc {
    position: fixed;
    top: 42px;
    right: 42px;
    width: 25%;
    margin: 0;
    padding: 0 1em;
    z-index: 1;
  }
  #toc h2 {
    border-top: none;
    border-bottom: 1px solid #ddd;
    font-size: 1em;
    font-weight: normal;
    margin: 0;
    padding: 0.25em 1em 1em 0;
  }
  #toc nav {
    display: block;
    height: calc(90vh - 84px);
    bottom: 0;
    padding: 0.5em 0 0;
    overflow: auto;
  }
  img { /* future proofing */
    max-width: 100%;
    height: auto;
  }
}

/* pagination */
@media print {
  body {

    width: 100%;
  }
  p {
    orphans: 3;
    widows: 3;
  }
  #n-copyright-notice {
    border-bottom: none;
  }
  #toc, #n-introduction {
    page-break-before: always;
  }
  #toc {
    border-top: none;
    padding-top: 0;
  }
  figure, pre {
    page-break-inside: avoid;
  }
  figure {
    overflow: scroll;
  }
  h1, h2, h3, h4, h5, h6 {
    page-break-after: avoid;
  }
  h2+*, h3+*, h4+*, h5+*, h6+* {
    page-break-before: avoid;
  }
  pre {
    white-space: pre-wrap;
    word-wrap: break-word;
    font-size: 10pt;
  }
  table {
    border: 1px solid #ddd;
  }
  td {
    border-top: 1px solid #ddd;
  }
}

/* This is commented out here, as the string-set: doesn't
   pass W3C validation currently */
/*
.ears thead .left {
  string-set: ears-top-left content();
}

.ears thead .center {
  string-set: ears-top-center content();
}

.ears thead .right {
  string-set: ears-top-right content();
}

.ears tfoot .left {
  string-set: ears-bottom-left content();
}

.ears tfoot .center {
  string-set: ears-bottom-center content();
}

.ears tfoot .right {
  string-set: ears-bottom-right content();
}
*/

@page :first {
  padding-top: 0;
  @top-left {
    content: normal;
    border: none;
  }
  @top-center {
    content: normal;
    border: none;
  }
  @top-right {
    content: normal;
    border: none;
  }
}

@page {
  size: A4;
  margin-bottom: 45mm;
  padding-top: 20px;
  /* The follwing is commented out here, but set appropriately by in code, as
     the content depends on the document */
  /*
  @top-left {
    content: 'Internet-Draft';
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-left {
    content: string(ears-top-left);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-center {
    content: string(ears-top-center);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-right {
    content: string(ears-top-right);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @bottom-left {
    content: string(ears-bottom-left);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-center {
    content: string(ears-bottom-center);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-right {
      content: '[Page ' counter(page) ']';
      vertical-align: top;
      border-top: solid 1px #ccc;
  }
  */

}

/* Changes introduced to fix issues found during implementation */
/* Make sure links are clickable even if overlapped by following H* */
a {
  z-index: 2;
}
/* Separate body from document info even without intervening H1 */
section {
  clear: both;
}


/* Top align author divs, to avoid names without organization dropping level with org names */
.author {
  vertical-align: top;
}

/* Leave room in document info to show Internet-Draft on one line */
#identifiers dt {
  width: 8em;
}

/* Don't waste quite as much whitespace between label and value in doc info */
#identifiers dd {
  margin-left: 1em;
}

/* Give floating toc a background color (needed when it's a div inside section */
#toc {
  background-color: white;
}

/* Make the collapsed ToC header render white on gray also when it's a link */
@media screen and (max-width: 1023px) {
  #toc h2 a,
  #toc h2 a:link,
  #toc h2 a:focus,
  #toc h2 a:hover,
  #toc a.toplink,
  #toc a.toplink:hover {
    color: white;
    background-color: #444;
    text-decoration: none;
  }
}

/* Give the bottom of the ToC some whitespace */
@media screen and (min-width: 1024px) {
  #toc {
    padding: 0 0 1em 1em;
  }
}

/* Style section numbers with more space between number and title */
.section-number {
  padding-right: 0.5em;
}

/* prevent monospace from becoming overly large */
tt, code, pre, code {
  font-size: 95%;
}

/* Fix the height/width aspect for ascii art*/
pre.sourcecode,
.art-text pre {
  line-height: 1.12;
}


/* Add styling for a link in the ToC that points to the top of the document */
a.toplink {
  float: right;
  margin-right: 0.5em;
}

/* Fix the dl styling to match the RFC 7992 attributes */
dl > dt,
dl.dlParallel > dt {
  float: left;
  margin-right: 1em;
}
dl.dlNewline > dt {
  float: none;
}

/* Provide styling for table cell text alignment */
table td.text-left,
table th.text-left {
  text-align: left;
}
table td.text-center,
table th.text-center {
  text-align: center;
}
table td.text-right,
table th.text-right {
  text-align: right;
}

/* Make the alternative author contact informatio look less like just another
   author, and group it closer with the primary author contact information */
.alternative-contact {
  margin: 0.5em 0 0.25em 0;
}
address .non-ascii {
  margin: 0 0 0 2em;
}

/* With it being possible to set tables with alignment
  left, center, and right, { width: 100%; } does not make sense */
table {
  width: auto;
}

/* Avoid reference text that sits in a block with very wide left margin,
   because of a long floating dt label.*/
.references dd {
  overflow: visible;
}

/* Control caption placement */
caption {
  caption-side: bottom;
}

/* Limit the width of the author address vcard, so names in right-to-left
   script don't end up on the other side of the page. */

address.vcard {
  max-width: 30em;
  margin-right: auto;
}

/* For address alignment dependent on LTR or RTL scripts */
address div.left {
  text-align: left;
}
address div.right {
  text-align: right;
}

/* Provide table alignment support.  We can't use the alignX classes above
   since they do unwanted things with caption and other styling. */
table.right {
 margin-left: auto;
 margin-right: 0;
}
table.center {
 margin-left: auto;
 margin-right: auto;
}
table.left {
 margin-left: 0;
 margin-right: auto;
}

/* Give the table caption label the same styling as the figcaption */
caption a[href] {
  color: #222;
}

@media print {
  .toplink {
    display: none;
  }

  /* avoid overwriting the top border line with the ToC header */
  #toc {
    padding-top: 1px;
  }

  /* Avoid page breaks inside dl and author address entries */
  .vcard {
    page-break-inside: avoid;
  }

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: avoid-page;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc8884" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-irtf-icnrg-disaster-10" rel="prev">
  </head>
<body>
<script src="https://www.rfc-editor.org/js/metadata.min.js"></script>
<table class="ears">
<thead><tr>
<td class="left">RFC 8884</td>
<td class="center">ICN in Disaster Scenarios</td>
<td class="right">October 2020</td>
</tr></thead>
<tfoot><tr>
<td class="left">Seedorf, et al.</td>
<td class="center">Informational</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Internet Research Task Force (IRTF)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc8884" class="eref">8884</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Informational</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2020-10" class="published">October 2020</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">J. Seedorf</div>
<div class="org">HFT Stuttgart - Univ. of Applied Sciences</div>
</div>
<div class="author">
      <div class="author-name">M. Arumaithurai</div>
<div class="org">University of Göttingen</div>
</div>
<div class="author">
      <div class="author-name">A. Tagami</div>
<div class="org">KDDI Research Inc.</div>
</div>
<div class="author">
      <div class="author-name">K. Ramakrishnan</div>
<div class="org">University of California</div>
</div>
<div class="author">
      <div class="author-name">N. Blefari Melazzi</div>
<div class="org">University Tor Vergata</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8884</h1>
<h1 id="title">Research Directions for Using Information-Centric Networking (ICN) in Disaster Scenarios</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">Information-Centric Networking (ICN) 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 ICN with respect to applying ICN
      approaches for coping with natural or human-generated, large-scale
      disasters. This document is a product of the Information-Centric
      Networking Research Group (ICNRG).<a href="#section-abstract-1" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document is a product of the Internet Research Task Force
            (IRTF).  The IRTF publishes the results of Internet-related
            research and development activities.  These results might not be
            suitable for deployment.  This RFC represents the consensus of the Information-Centric Networking
            Research Group of the Internet Research Task Force (IRTF).
            Documents approved for publication by the IRSG are not a
            candidate for any level of Internet Standard; see Section 2 of RFC
            7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc8884">https://www.rfc-editor.org/info/rfc8884</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2020 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) 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.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-disaster-scenarios" class="xref">Disaster Scenarios</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-research-challenges-and-ben" class="xref">Research Challenges and Benefits of ICN</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.3.2.1">
                <p id="section-toc.1-1.3.2.1.1" class="keepWithNext"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-high-level-research-challen" class="xref">High-Level Research Challenges</a><a href="#section-toc.1-1.3.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.3.2.2">
                <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>.  <a href="#name-how-icn-can-be-beneficial" class="xref">How ICN Can be Beneficial</a><a href="#section-toc.1-1.3.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.3.2.3">
                <p id="section-toc.1-1.3.2.3.1"><a href="#section-3.3" class="xref">3.3</a>.  <a href="#name-icn-as-starting-point-vs-ex" class="xref">ICN as Starting Point vs. Existing DTN Solutions</a><a href="#section-toc.1-1.3.2.3.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-use-cases-and-requirements" class="xref">Use Cases and Requirements</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-icn-based-research-approach" class="xref">ICN-Based Research Approaches and Open Research Challenges</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.5.2.1">
                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-suggested-icn-based-researc" class="xref">Suggested ICN-Based Research Approaches</a><a href="#section-toc.1-1.5.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.5.2.2">
                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-open-research-challenges" class="xref">Open Research Challenges</a><a href="#section-toc.1-1.5.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-conclusion" class="xref">Conclusion</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-references" class="xref">References</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.9.2.1">
                <p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1" class="xref">9.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.9.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.9.2.2">
                <p id="section-toc.1-1.9.2.2.1"><a href="#section-9.2" class="xref">9.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.9.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-appendix.a" class="xref"></a><a href="#name-acknowledgment" class="xref">Acknowledgment</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">This document summarizes some research challenges for coping with
      natural or human-generated, large-scale disasters. In particular, the
      document discusses potential research directions for applying
      Information-Centric Networking (ICN) to address these challenges.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">
   Research and standardization approaches exist (for instance, see the work
   and discussions in the concluded IRTF DTN Research Group <span>[<a href="#dtnrg" class="xref">dtnrg</a>]</span> and in the IETF DTN Working Group <span>[<a href="#dtnwg" class="xref">dtnwg</a>]</span>). In addition, a published Experimental
   RFC in the IRTF Stream <span>[<a href="#RFC5050" class="xref">RFC5050</a>]</span> discusses
   Delay-Tolerant Networking (DTN), which is a key necessity for communicating
   in the disaster scenarios we are considering in this
   document. 'Disconnection tolerance' can thus be achieved with these
   existing DTN approaches.


However, while these approaches can provide independence from an existing
communication infrastructure (which indeed may not work anymore after a
disaster has happened), ICN offers key concepts, such as new naming schemes
and innovative multicast communication, which together enable many essential
(publish/subscribe-based) use cases for communication after a disaster (e.g.,
message prioritization, one-to-many delivery of messages, group communication
among rescue teams, and the use cases discussed in <a href="#usecases" class="xref">Section 4</a>). One could add such features to existing DTN protocols and
solutions; however, in this document, we explore the use of ICN as a starting
point for building a communication architecture that supports (somewhat
limited) communication capabilities after a disaster. We discuss the
relationship between the ICN approaches (for enabling communication after a
disaster) discussed in this document with existing work from the DTN community
in more depth in <a href="#researchgap" class="xref">Section 3.3</a>.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">'Emergency Support and Disaster Recovery' is also listed among the
      ICN Baseline Scenarios in <span>[<a href="#RFC7476" class="xref">RFC7476</a>]</span> as a
      potential scenario that 'can be used as a base for the evaluation of
      different ICN approaches so that they
      can be tested and compared against each other while showcasing their own
      advantages' <span>[<a href="#RFC7476" class="xref">RFC7476</a>]</span> . In this regard,
      this document complements <span>[<a href="#RFC7476" class="xref">RFC7476</a>]</span> by
      investigating the use of ICN approaches for 'Emergency Support and
      Disaster Recovery' in depth and discussing the relationship to existing
      work in the DTN community.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">This document focuses on ICN-based approaches that can enable
      communication after a disaster. These approaches reside mostly on the
      network layer. Other solutions for 'Emergency Support and Disaster
      Recovery' (e.g., on the application layer) may complement the ICN-based
      networking approaches discussed in this document and expand the solution
      space for enabling communications among users after a disaster. In fact,
      addressing the use cases explored in this document would require
      corresponding applications that would exploit the discussed ICN benefits
      on the network layer for users. However, the discussion of
      applications or solutions outside of the network layer are outside
      the scope of this document.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">This document represents the consensus of the Information-Centric
      Networking Research Group (ICNRG); it is not an IETF product and it does
      not define a standard.  It has been reviewed extensively by the ICN
      Research Group (RG) members active in the specific areas of work covered
      by the document.<a href="#section-1-5" class="pilcrow">¶</a></p>
<p id="section-1-6"><a href="#disaster" class="xref">Section 2</a> gives some examples of
      what can be considered a large-scale disaster and what the effects of
      such disasters on communication networks are. <a href="#whyicn" class="xref">Section 3</a> outlines why ICN can be beneficial in such scenarios
      and provides a high-level overview on corresponding research
      challenges. <a href="#usecases" class="xref">Section 4</a> describes some
      concrete use cases and requirements for disaster scenarios. In <a href="#solutions" class="xref">Section 5</a>, some concrete ICN-based solutions
      approaches are outlined.<a href="#section-1-6" class="pilcrow">¶</a></p>
</section>
<div id="disaster">
<section id="section-2">
      <h2 id="name-disaster-scenarios">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-disaster-scenarios" class="section-name selfRef">Disaster Scenarios</a>
      </h2>
<p id="section-2-1">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, which  is 300 km 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).<a href="#section-2-1" class="pilcrow">¶</a></p>
<p id="section-2-2">That earthquake in Japan also showed that the current network is
      vulnerable to disasters. Mobile phones have become the lifelines for
      communication, including safety confirmation. Besides (emergency) phone
      calls, services in mobile networks commonly being used after a disaster
      include network disaster SMS notifications (or SMS 'Cell Broadcast'
      <span>[<a href="#cellbroadcast" class="xref">cellbroadcast</a>]</span>), available in most
      cellular networks. 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 or 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 inquiries about food distribution centers and shelters or report trapped
      and 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.<a href="#section-2-2" class="pilcrow">¶</a></p>
<p id="section-2-3">Additionally, disasters caused by humans (i.e., disasters that are caused deliberately
      and willfully and have the element of human intent such as a terrorist attack)
      may need to be considered. 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 to a small extent using weather forecasting technologies, may have a slower
      onset, and occur in known geographical regions and seasons, terrorist
      attacks almost always 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.<a href="#section-2-3" class="pilcrow">¶</a></p>
<p id="section-2-4"> The timely dissemination of information generated and requested by
      all the affected parties during and in the immediate aftermath of a
      disaster is difficult to provide within the current context of global
      information aggregators (such as Google, Yahoo, Bing, etc.) that need to
      index the vast amounts of specialized information related to the
      disaster. Specialized coverage of the situation and timely dissemination
      are key to successfully managing disaster situations. We believe that
      network infrastructure capabilities provided by Information-Centric
      Networks can be suitable, in conjunction with application and middleware
      assistance.<a href="#section-2-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="whyicn">
<section id="section-3">
      <h2 id="name-research-challenges-and-ben">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-research-challenges-and-ben" class="section-name selfRef">Research Challenges and Benefits of ICN</a>
      </h2>
<div id="challenges">
<section id="section-3.1">
        <h3 id="name-high-level-research-challen">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-high-level-research-challen" class="section-name selfRef">High-Level Research Challenges</a>
        </h3>
<p id="section-3.1-1">Given a disaster scenario as described in <a href="#disaster" class="xref">Section 2</a>, on a high level, one can derive the following
 (incomplete) list of corresponding technical challenges:<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-3.1-2">
          <dt id="section-3.1-2.1">Enabling usage of functional parts of the infrastructure, even
   when these are disconnected from the rest of the network:</dt>
          <dd style="margin-left: 1.5em" id="section-3.1-2.2">Assuming
   that parts of the network infrastructure (i.e., cables/links,
   routers, mobile bases stations, etc.) 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 centralized
   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.<a href="#section-3.1-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-3.1-2.3">Decentralized authentication, content integrity, and trust:</dt>
          <dd style="margin-left: 1.5em" id="section-3.1-2.4">In
   mobile networks, users are authenticated via central entities. While
   special services important in a disaster scenario exist and may work
   without authentication (such as SMS 'Cell Broadcast' <span>[<a href="#cellbroadcast" class="xref">cellbroadcast</a>]</span> or emergency calls),
   user-to-user (or user-to-authorities) communication is normally not
   possible without being authenticated via a central entity in the
   network. In order to communicate in fragmented or disconnected parts
   of a mobile network, the challenge of decentralizing user
   authentication arises. Independently of the network being fixed or
   mobile, data origin authentication and verifying the correctness of
   content retrieved from the network may be challenging when being
   'offline' (e.g., potentially disconnected from content publishers as
   well as from servers of a security infrastructure, which can provide
   missing certificates in a certificate chain or up-to-date
   information on revoked keys/certificates). As the network suddenly
   becomes fragmented or partitioned, trust models may shift
   accordingly to the change in authentication infrastructure being
   used (e.g., one may switch from a PKI to a web-of-trust model, such
   as Pretty Good Privacy (PGP)). Note that blockchain-based approaches are, in most cases,
   likely not suitable for the disaster scenarios considered in this
   document, as the communication capabilities needed to find consensus
   for a new block as well as for retrieving blocks at nodes 
   will presumably not be available (or too excessive for the remaining
   infrastructure) after a disaster.<a href="#section-3.1-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-3.1-2.5">Delivering/obtaining information and traffic prioritization in
   congested networks: </dt>
          <dd style="margin-left: 1.5em" id="section-3.1-2.6">Due to broken cables, failed routers, etc., it
   is likely that the communication network has
   much less overall capacity for handling traffic in a disaster scenario. 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 because, in the case of a disaster
   aftermath, it may be crucial to deliver certain information to
   recipients (e.g., warnings to citizens) with higher priority than
   other content.<a href="#section-3.1-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-3.1-2.7">Delay/disruption-tolerant approach:</dt>
          <dd style="margin-left: 1.5em" id="section-3.1-2.8">Fragmented networks make it
   difficult to support direct end-to-end communication with small or
   no delay. However, communication in general and especially during a
   disaster can often tolerate some form of delay. For example, in order to
   know if someone's relatives are safe or not, a corresponding
   emergency message need not necessarily be supported in an end-to-end
   manner but would also be helpful to the human recipient if it can
   be transported in a hop-by-hop fashion with some delay. For these
   kinds of use cases, it is sufficient to improve communication
   resilience in order to deliver such important messages.<a href="#section-3.1-2.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-3.1-2.9">Energy efficiency:</dt>
          <dd style="margin-left: 1.5em" id="section-3.1-2.10">Long-lasting power outages may lead to
   batteries of communication devices running out, so designing
   energy-efficient solutions is very important in order to maintain a
   usable communication infrastructure.<a href="#section-3.1-2.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-3.1-2.11">Contextuality:</dt>
          <dd style="margin-left: 1.5em" id="section-3.1-2.12">Like any communication in general, disaster
   scenarios are inherently contextual. Aspects of geography, the
   people affected, the rescue communities involved, the languages
   being used, and many other contextual aspects are highly relevant for
   an efficient realization of any rescue effort and, with it, the
   realization of the required communication.<a href="#section-3.1-2.12" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="howicncanhelp">
<section id="section-3.2">
        <h3 id="name-how-icn-can-be-beneficial">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-how-icn-can-be-beneficial" class="section-name selfRef">How ICN Can be Beneficial</a>
        </h3>
<p id="section-3.2-1">Several aspects of ICN make related approaches attractive
 candidates for addressing the challenges described in <a href="#challenges" class="xref">Section 3.1</a>. Below is an (incomplete) list
 of considerations why ICN approaches can be beneficial to address
 these challenges:<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-3.2-2">
          <dt id="section-3.2-2.1">Routing-by-name:</dt>
          <dd style="margin-left: 1.5em" id="section-3.2-2.2">ICN protocols natively route by named data
   objects and can identify objects 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). In highly decentralized scenarios
   (e.g., in infrastructureless, opportunistic environments), the ICN
   routing-by-name paradigm effectively may lead to a
   'replication-by-name' approach, where content is replicated
   depending on its name.<a href="#section-3.2-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-3.2-2.3">Integrity and authentication of named data objects:</dt>
          <dd style="margin-left: 1.5em" id="section-3.2-2.4">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 (e.g., see <span>[<a href="#RFC6920" class="xref">RFC6920</a>]</span>). With
   such approaches, object integrity of data retrieved from the network
   can be verified without relying on a trusted third party or PKI. 

  In addition, given that the correct object name is known, such schemes can
  also provide data origin authentication (for instance, see the usage example
  in <span><a href="https://www.rfc-editor.org/rfc/rfc6920#section-8.3" class="relref">Section 8.3</a> of [<a href="#RFC6920" class="xref">RFC6920</a>]</span>).<a href="#section-3.2-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-3.2-2.5">Content-based access control:</dt>
          <dd style="margin-left: 1.5em" id="section-3.2-2.6">
          ICN promotes a data-centric communication model that naturally
          supports content-based security (e.g., allowing access to content
          only to a specific user or class of users). In fact, in ICN, it is
          the content itself that is secured (encrypted), if desired, rather than the
          communication channel.  This functionality could facilitate trusted
          communications among peer users in isolated areas of the network
          where a direct communication channel may not always or continuously
          exist.<a href="#section-3.2-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-3.2-2.7">Caching:</dt>
          <dd style="margin-left: 1.5em" id="section-3.2-2.8">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).<a href="#section-3.2-2.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-3.2-2.9">Sessionless:</dt>
          <dd style="margin-left: 1.5em" id="section-3.2-2.10">ICN does not require full end-to-end
   connectivity. This feature facilitates a seamless aggregation
   between a normal network and a fragmented network, which needs
   DTN-like message forwarding.<a href="#section-3.2-2.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-3.2-2.11">Potential to run traditional IP-based services (IP-over-ICN):</dt>
          <dd style="margin-left: 1.5em" id="section-3.2-2.12">While ICN and DTN promote the development of novel applications that
   fully utilize the new capabilities of the ICN/DTN network, work in
   <span>[<a href="#Trossen2015" class="xref">Trossen2015</a>]</span> has shown that an
   ICN-enabled network can transport IP-based services, either directly
   at IP or even at HTTP level. With this, IP- and ICN/DTN-based
   services can coexist, providing the necessary support of legacy
   applications to affected users while reaping any benefits from the
   native support for ICN in future applications.<a href="#section-3.2-2.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-3.2-2.13">Opportunities for traffic engineering and traffic
   prioritization:</dt>
          <dd style="margin-left: 1.5em" id="section-3.2-2.14">ICN provides the possibility to perform traffic
   engineering based on the name of desired content. This enables
   priority-based replication depending on the scope of a given message
   <span>[<a href="#Psaras2014" class="xref">Psaras2014</a>]</span>. In addition, as <span>[<a href="#Trossen2015" class="xref">Trossen2015</a>]</span>, among others, have pointed
   out, the realization of ICN services and particularly of IP-based
   services on top of ICN provide further traffic engineering
   opportunities. The latter not only relate to the utilization of
   cached content, as outlined before, but to the ability to flexibly
   adapt to route changes (important in unreliable infrastructure, such
   as in disaster scenarios), mobility support without anchor points
   (again, important when parts of the infrastructure are likely to
   fail), and the inherent support for multicast and multihoming
   delivery.<a href="#section-3.2-2.14" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="researchgap">
<section id="section-3.3">
        <h3 id="name-icn-as-starting-point-vs-ex">
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-icn-as-starting-point-vs-ex" class="section-name selfRef">ICN as Starting Point vs. Existing DTN Solutions</a>
        </h3>
<p id="section-3.3-1">There has been quite some work in the DTN (Delay-Tolerant
 Networking) community on disaster communication (for instance, see
 the work and discussions in the concluded IRTF DTN Research
 Group <span>[<a href="#dtnrg" class="xref">dtnrg</a>]</span> and in the IETF DTN
 Working Group <span>[<a href="#dtnwg" class="xref">dtnwg</a>]</span>). However, most
 DTN work lacks important features, such as publish/subscribe (pub/sub)
 capabilities, caching, multicast delivery, and message prioritization
 based on content types, which are needed in the disaster scenarios we
 consider. One could add such features to existing DTN protocols and
 solutions, and indeed individual proposals for adding such features to
 DTN protocols have been made (e.g., <span>[<a href="#Greifenberg2008" class="xref">Greifenberg2008</a>]</span> and <span>[<a href="#Yoneki2007" class="xref">Yoneki2007</a>]</span>
 propose the use of a pub/sub-based multicast distribution
 infrastructure for DTN-based opportunistic networking
 environments).<a href="#section-3.3-1" class="pilcrow">¶</a></p>
<p id="section-3.3-2">However, arguably ICN -- having these intrinsic properties (as also
 outlined above) -- makes a better starting point for building a
 communication architecture that works well before and after a
 disaster. For a disaster-enhanced ICN system, this would imply the
 following advantages: a) ICN data mules would have built-in caches and
 can thus return content for interests straight on, b) requests do not
 necessarily need to be routed to a source (as with existing DTN
 protocols), instead any data mule or end user can in principle respond
 to an interest, c) built-in multicast delivery implies
 energy-efficient, large-scale spreading of important information that
 is crucial in disaster scenarios, and d) pub/sub extension for popular
 ICN implementations exist <span>[<a href="#COPSS2011" class="xref">COPSS2011</a>]</span>,
 which are very suitable for efficient group communication in disasters
 and provide better reliability, timeliness, and scalability, as compared
 to existing pub/sub approaches in DTN <span>[<a href="#Greifenberg2008" class="xref">Greifenberg2008</a>]</span> <span>[<a href="#Yoneki2007" class="xref">Yoneki2007</a>]</span> .<a href="#section-3.3-2" class="pilcrow">¶</a></p>
<p id="section-3.3-3">Finally, most DTN routing algorithms have been solely designed for
 particular DTN scenarios. By extending ICN approaches for DTN-like
 scenarios, one ensures that a solution works in regular
 (i.e., well-connected) settings just as well (which can be important in
 reality, where a routing algorithm should work before and after a
 disaster). It is thus reasonable to start with existing ICN approaches
 and extend them with the necessary features needed in disaster
 scenarios. In any case, solutions for disaster scenarios need a
 combination of ICN-features and DTN-capabilities.<a href="#section-3.3-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="usecases">
<section id="section-4">
      <h2 id="name-use-cases-and-requirements">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-use-cases-and-requirements" class="section-name selfRef">Use Cases and Requirements</a>
      </h2>
<p id="section-4-1">This section describes some use cases for the aforementioned disaster
      scenario (as outlined in <a href="#disaster" class="xref">Section 2</a>) and
      discusses the corresponding technical requirements for enabling these
      use cases.<a href="#section-4-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-4-2">
        <dt id="section-4-2.1">Delivering Messages to Relatives/Friends:</dt>
        <dd style="margin-left: 1.5em" id="section-4-2.2">
          <p id="section-4-2.2.1">After a disaster
 strikes, citizens want to confirm to each other that they are
 safe. For instance, shortly after a large disaster (e.g., an earthquake
  or a 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 and 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 a scalable
 message forwarding scheme that dynamically adapts to changing
 conditions in disconnected networks, b) DTN-like mechanisms for
 getting information from one disconnected island to another disconnected
 island, c) source authentication and content integrity so that users
 can confirm that the messages they receive are indeed from their
 relatives or friends and have not been tampered with, and d) the
 support for contextual caching in order to provide the right
 information to the right set of affected people in the most efficient
 manner.<a href="#section-4-2.2.1" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-4-2.3">Spreading Crucial Information to Citizens:</dt>
        <dd style="margin-left: 1.5em" id="section-4-2.4">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) source authentication and content integrity, such that
 citizens can confirm the correctness and 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.<a href="#section-4-2.4" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-4-3">It can be observed that different key use cases for disaster
      scenarios imply overlapping and similar technical requirements for
      fulfilling them. As discussed in <a href="#howicncanhelp" class="xref">Section 3.2</a>, ICN approaches are envisioned to be very suitable
      for addressing these requirements with actual technical solutions. In
      <span>[<a href="#Robitzsch2015" class="xref">Robitzsch2015</a>]</span>, a more elaborate set of
      requirements is provided that addresses, among disaster scenarios, a
      communication infrastructure for communities facing several geographic,
      economic, and political challenges.<a href="#section-4-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="solutions">
<section id="section-5">
      <h2 id="name-icn-based-research-approach">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-icn-based-research-approach" class="section-name selfRef">ICN-Based Research Approaches and Open Research Challenges</a>
      </h2>
<p id="section-5-1">This section outlines some ICN-based research approaches that aim at
      fulfilling the previously mentioned use cases and requirements (<a href="#suggested" class="xref">Section 5.1</a>). Most of these works provide
      proof-of-concept type solutions, addressing singular challenges. Thus,
      several open issues remain, which are summarized in <a href="#open" class="xref">Section 5.2</a>.<a href="#section-5-1" class="pilcrow">¶</a></p>
<div id="suggested">
<section id="section-5.1">
        <h3 id="name-suggested-icn-based-researc">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-suggested-icn-based-researc" class="section-name selfRef">Suggested ICN-Based Research Approaches</a>
        </h3>
<p id="section-5.1-1">The research community has investigated ICN-based solutions to
 address the aforementioned challenges in disaster scenarios. Overall,
 the focus is on delivery of messages and not real-time
 communication. 

        While most users would probably like to conduct real-time voice/video
        calls after a disaster, in the extreme scenario we consider (with
        users being scattered over different fragmented networks as can be the
        case in the scenarios described in <a href="#disaster" class="xref">Section 2</a>), somewhat delayed message delivery appears to be
        inevitable, and full-duplex real-time communication seems infeasible
        to achieve (unless users are in close proximity).

        Thus, the assumption is that -- for a certain amount of time at least
        (i.e., the initial period until the regular communication
        infrastructure has been repaired) -- users would need to live with
        message delivery and publish/subscribe services but without real-time
        communication. Note, however, that a) in principle, ICN can support
        Voice over IP (VoIP) calls; thus, if users are in close proximity,
        (duplex) voice communication via ICN is possible <span>[<a href="#Gusev2015" class="xref">Gusev2015</a>]</span>, and b) delayed message delivery
        can very well include (recorded) voice messages.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-5.1-2">
          <dt id="section-5.1-2.1">ICN 'data mules':</dt>
          <dd style="margin-left: 1.5em" id="section-5.1-2.2">To facilitate the exchange of messages between
   different network fragments, mobile entities can act as ICN 'data
   mules', which are equipped with storage space and move around the
   disaster-stricken area gathering information to be disseminated. As
   the mules move around, they deliver messages to other individuals or
   points of attachment to different fragments of the network. These
   'data mules' could have a predetermined path (an ambulance going to
   and from a hospital), a fixed path (drone/robot assigned
   specifically to do so), or a completely random path (doctors moving
   from one camp to another). An example of a many-to-many
   communication service for fragmented networks based on ICN data
   mules has been proposed in <span>[<a href="#Tagami2016" class="xref">Tagami2016</a>]</span>.<a href="#section-5.1-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.1-2.3">Priority-dependent or popularity-dependent, name-based
   replication:</dt>
          <dd style="margin-left: 1.5em" id="section-5.1-2.4">By allowing spatial and temporal scoping of named
   messages, priority-based replication depending on the scope of a
   given message is possible. Clearly, spreading information in
   disaster cases involves space and time factors that have to be taken
   into account as messages spread. A concrete approach for such
   scope-based prioritization of ICN messages in disasters, called
   'NREP', has been proposed <span>[<a href="#Psaras2014" class="xref">Psaras2014</a>]</span>, where ICN messages have attributes, such as
   user-defined priority, space, and temporal validity. These
   attributes are then taken into account when prioritizing
   messages. In <span>[<a href="#Psaras2014" class="xref">Psaras2014</a>]</span>,
   evaluations show how this approach can be applied to the use case
   'Delivering Messages to Relatives/Friends' described in <a href="#usecases" class="xref">Section 4</a>. In <span>[<a href="#Seedorf2016" class="xref">Seedorf2016</a>]</span>, a scheme is presented that enables estimating
   the popularity of ICN interest messages in a completely
   decentralized manner among data mules in a scenario with random,
   unpredictable movements of ICN data mules. The approach exploits the
   use of nonces associated with end user requests, common in most ICN
   architectures. It enables for a given ICN data mule to estimate the
   overall popularity (among end users) of a given ICN interest
   message. This enables data mules to optimize content dissemination
   with limited caching capabilities by prioritizing interests based on
   their popularity.<a href="#section-5.1-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.1-2.5">Information resilience through decentralized forwarding:</dt>
          <dd style="margin-left: 1.5em" id="section-5.1-2.6">In a
   dynamic or disruptive environment, such as the aftermath of a
   disaster, both users and content servers may dynamically join and
   leave the network (due to mobility or network fragmentation). Thus,
   users might attach to the network and request content when the
   network is fragmented and the corresponding content origin is not
   reachable. In order to increase information resilience, content
   cached both in in-network caches and in end-user devices should be
   exploited. A concrete approach for the exploitation of content
   cached in user devices is presented in <span>[<a href="#Sourlas2015" class="xref">Sourlas2015</a>]</span> . The proposal in <span>[<a href="#Sourlas2015" class="xref">Sourlas2015</a>]</span> includes enhancements to the Named Data
   Networking (NDN) router design,
   as well as an alternative Interest-forwarding scheme that enables
   users to retrieve cached content when the network is fragmented and
   the content origin is not reachable. Evaluations show that this
   approach is a valid tool for the retrieval of cached content in
   disruptive cases and can be applied to tackle the challenges
   presented in <a href="#challenges" class="xref">Section 3.1</a> .<a href="#section-5.1-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.1-2.7">Energy efficiency:</dt>
          <dd style="margin-left: 1.5em" id="section-5.1-2.8">


          A large-scale disaster can cause a large-scale blackout; thus, a
          number of base stations (BSs) will be operated by their batteries.

          Capacities of such batteries are not large enough to provide
          cellular communication for several days after the disaster. In order
          to prolong the batteries' life from one day to several days,
          different techniques need to be explored, including priority
          control, cell zooming, and collaborative upload. Cell zooming
          switches off some of the BSs because switching off is the only way
          to reduce power consumed at the idle time. In cell zooming, areas
          covered by such inactive BSs are covered by the active
          BSs. Collaborative communication is complementary to cell zooming
          and reduces power proportional to a load of a BS. The load
          represents cellular frequency resources. In collaborative
          communication, end devices delegate sending and receiving messages
          to and from a BS to a representative end device of which radio
          propagation quality is better. The design of an ICN-based
          publish/subscribe protocol that incorporates collaborative upload is
          ongoing work. In particular, the integration of collaborative upload
          techniques into the COPSS (Content Oriented Publish/Subscribe
          System) framework is envisioned <span>[<a href="#COPSS2011" class="xref">COPSS2011</a>]</span>.<a href="#section-5.1-2.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.1-2.9">Data-centric confidentiality and access control:</dt>
          <dd style="margin-left: 1.5em" id="section-5.1-2.10">In ICN, the
   requested content is no longer associated to a trusted server or
   an endpoint location, but it can be retrieved from any network cache
   or a replica server. This calls for 'data-centric' security, where
   security relies on information exclusively contained in the message
   itself, or if extra information provided by trusted entities is
   needed, this should be gathered through offline, asynchronous, and
   noninteractive communication, rather than from an explicit online
   interactive handshake with trusted servers. The ability to guarantee
   security without any online entities is particularly important in
   disaster scenarios with fragmented networks. One concrete
   cryptographic technique is 'Ciphertext-Policy Attribute Based
   Encryption (CP-ABE)', allowing a party to encrypt a content
   specifying a policy that  consists in a Boolean expression over
   attributes that must be satisfied by those who want to decrypt such
   content. Such encryption schemes tie confidentiality and
   access control to the transferred data, which can also be transmitted
   in an unsecured channel. These schemes enable the source to
   specify the set of nodes allowed to later on decrypt the content
   during the encryption process.<a href="#section-5.1-2.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.1-2.11">Decentralized authentication of messages:</dt>
          <dd style="margin-left: 1.5em" id="section-5.1-2.12">Self-certifying names
   provide the property that any entity in a distributed system can
   verify the binding between a corresponding public key and the
   self-certifying name without relying on a trusted third
   party. Self-certifying names thus provide a decentralized form of
   data origin authentication. However, self-certifying names lack a
   binding with a corresponding real-world identity. Given the
   decentralized nature of a disaster scenario, a PKI-based approach
   for binding self-certifying names with real-world identities is not
   feasible. Instead, a Web of Trust can be used to provide this
   binding. Not only are the cryptographic signatures used within a
   Web of Trust independent of any central authority, but there are also
   technical means for making the inherent trust relationships of a
   Web of Trust available to network entities in a decentralized,
   'offline' fashion, such that information received can be assessed
   based on these trust relationships. A concrete scheme for such an
   approach has been published in <span>[<a href="#Seedorf2014" class="xref">Seedorf2014</a>]</span>, in which concrete examples for fulfilling the
   use case 'Delivering Messages to Relatives/Friends' with this
   approach are also given.<a href="#section-5.1-2.12" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="open">
<section id="section-5.2">
        <h3 id="name-open-research-challenges">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-open-research-challenges" class="section-name selfRef">Open Research Challenges</a>
        </h3>
<p id="section-5.2-1">The proposed solutions in <a href="#suggested" class="xref">Section 5.1</a> investigate how ICN approaches can, in principle,
 address some of the outlined challenges. However, several research
 challenges remain open and still need to be addressed. The following
 (incomplete) list summarizes some unanswered research questions and
 items that are being investigated by researchers:<a href="#section-5.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.2-2.1">Evaluating the proposed mechanisms (and their scalability) in
   realistic, large-scale testbeds with actual, mature implementations
   (compared to simulations or emulations).<a href="#section-5.2-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.2-2.2">
          To specify, for each mechanism suggested, what would be the user
          equipment required or necessary before and after a disaster and to
          what extent ICN should be deployed in the network.<a href="#section-5.2-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.2-2.3">How can DTN and ICN approaches be best used for an optimal overall
   combination of techniques?<a href="#section-5.2-2.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.2-2.4">How do data-centric encryption schemes scale and perform in
   large-scale, realistic evaluations?<a href="#section-5.2-2.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.2-2.5">Building and testing real (i.e., not early-stage prototypes) ICN data
   mules by means of implementation and integration with lower-layer
   hardware; conducting evaluations of decentralized forwarding schemes in
   real environments with these actual ICN data mules.<a href="#section-5.2-2.5" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.2-2.6">How to derive concrete, name-based policies allowing prioritized
         spreading of information.<a href="#section-5.2-2.6" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.2-2.7">Further investigating, developing, and verifying of mechanisms that address
   energy efficiency requirements for communication after a
   disaster.<a href="#section-5.2-2.7" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.2-2.8">How to properly disseminate authenticated object names to nodes
   (for decentralized integrity verification and authentication) before
   a disaster or how to retrieve new authenticated object names by
   nodes during a disaster.<a href="#section-5.2-2.8" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
</section>
</div>
<div id="security">
<section id="section-6">
      <h2 id="name-security-considerations">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-6-1">This document does not define a new protocol (or protocol extension)
      or a particular mechanism; therefore, it introduces no specific new
      security considerations. General security considerations for
      ICN, which also apply when using ICN
      techniques to communicate after a disaster, are discussed
      in <span>[<a href="#RFC7945" class="xref">RFC7945</a>]</span>.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">The after-disaster communication scenario, which is the focus of this
      document, raises particular attention to decentralized authentication,
      content integrity, and trust as key research challenges (as outlined in
      <a href="#challenges" class="xref">Section 3.1</a>). The corresponding use
      cases and ICN-based research approaches discussed in this document thus
      imply certain security requirements. In particular, data origin
      authentication, data integrity, and access control are key requirements
      for many use cases in the aftermath of a disaster (see <a href="#usecases" class="xref">Section 4</a>).<a href="#section-6-2" class="pilcrow">¶</a></p>
<p id="section-6-3">In principle, the kinds of disasters discussed in this document can
      happen as a result of a natural disaster, accident, or
      human error. However, intentional actions can also cause such a disaster
      (e.g., a terrorist attack, as mentioned in <a href="#disaster" class="xref">Section 2</a>). In this case (i.e., intentionally caused disasters
      by attackers), special attention needs to be paid when re-enabling
      communications as temporary, somewhat unreliable communications with
      potential limited security features may be anticipated and abused by
      attackers (e.g., to circulate false messages to cause further
      intentional chaos among the human population, to leverage this less
      secure infrastructure to refine targeting, or to track the responses of
      security/police forces). Potential solutions on how to cope with
      intentionally caused disasters by attackers and on how to enable a
      secure communications infrastructure after an intentionally caused
      disaster are out of scope of this document.<a href="#section-6-3" class="pilcrow">¶</a></p>
<p id="section-6-4">The use of data-centric security schemes, such as 'Ciphertext-Policy
      Attribute Based Encryption' (as mentioned in <a href="#suggested" class="xref">Section 5.1</a>), which encrypt the data itself (and not the
      communication channel), in principle, allows for the transmission of such
      encrypted data over an unsecured channel. However, metadata about
      the encrypted data being retrieved still arises. Such metadata may disclose
      sensitive information to a network-based attacker, even if such an
      attacker cannot decrypt the content itself.<a href="#section-6-4" class="pilcrow">¶</a></p>
<p id="section-6-5">This document has summarized research directions for addressing these
      challenges and requirements, such as efforts in data-centric
      confidentiality and access control, as well as recent works for
      decentralized authentication of messages in a disaster-struck networking
      infrastructure with nonfunctional routing links and limited
      communication capabilities (see <a href="#solutions" class="xref">Section 5</a>).<a href="#section-6-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="conclusion">
<section id="section-7">
      <h2 id="name-conclusion">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-conclusion" class="section-name selfRef">Conclusion</a>
      </h2>
<p id="section-7-1">This document has outlined some research directions for
      ICN with respect to applying ICN
      approaches for 
      coping with natural or human-generated, large-scale disasters. The
      document has described high-level research challenges for enabling
      communication after a disaster has happened, as well as a general
      rationale why ICN approaches could be beneficial to address these
      challenges. Further, concrete use cases have been described and how
      these can be addressed with ICN-based approaches has been discussed.<a href="#section-7-1" class="pilcrow">¶</a></p>
<p id="section-7-2">Finally, this document provides an overview of examples of existing
      ICN-based solutions that address the previously outlined research
      challenges. These concrete solutions demonstrate that indeed the
      communication challenges in the aftermath of a disaster can be addressed
      with techniques that have ICN paradigms at their base, validating our
      overall reasoning. However, further, more-detailed challenges exist, and
      more research is necessary in all areas discussed: efficient content
      distribution and routing in fragmented networks, traffic prioritization,
      security, and energy efficiency. An incomplete, high-level list of such
      open research challenges has concluded the document.<a href="#section-7-2" class="pilcrow">¶</a></p>
<p id="section-7-3">In order to deploy ICN-based solutions for disaster-aftermath
      communication in actual mobile networks, standardized ICN baseline
      protocols are a must. It is unlikely to expect all user equipment in a
      large-scale mobile network to be from the same vendor. In this respect,
      the work being done in the IRTF ICNRG is very useful as it works toward
      standards for concrete ICN protocols that enable interoperability among
      solutions from different vendors. 

      These protocols -- currently being developed in the IRTF ICNRG as
      Experimental specifications in the IRTF Stream -- provide a good
      foundation for deploying ICN-based, disaster-aftermath communication and
      thereby address key use cases that arise in such situations (as outlined
      in this document).<a href="#section-7-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="iana">
<section id="section-8">
      <h2 id="name-iana-considerations">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-8-1">This document has no IANA actions.<a href="#section-8-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-9">
      <h2 id="name-references">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-9.1">
        <h3 id="name-normative-references">
<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC5050">[RFC5050]</dt>
        <dd>
<span class="refAuthor">Scott, K.</span><span class="refAuthor"> and S. Burleigh</span>, <span class="refTitle">"Bundle Protocol Specification"</span>, <span class="seriesInfo">RFC 5050</span>, <span class="seriesInfo">DOI 10.17487/RFC5050</span>, <time datetime="2007-11" class="refDate">November 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5050">https://www.rfc-editor.org/info/rfc5050</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6920">[RFC6920]</dt>
        <dd>
<span class="refAuthor">Farrell, S.</span><span class="refAuthor">, Kutscher, D.</span><span class="refAuthor">, Dannewitz, C.</span><span class="refAuthor">, Ohlman, B.</span><span class="refAuthor">, Keranen, A.</span><span class="refAuthor">, and P. Hallam-Baker</span>, <span class="refTitle">"Naming Things with Hashes"</span>, <span class="seriesInfo">RFC 6920</span>, <span class="seriesInfo">DOI 10.17487/RFC6920</span>, <time datetime="2013-04" class="refDate">April 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6920">https://www.rfc-editor.org/info/rfc6920</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7476">[RFC7476]</dt>
        <dd>
<span class="refAuthor">Pentikousis, K., Ed.</span><span class="refAuthor">, Ohlman, B.</span><span class="refAuthor">, Corujo, D.</span><span class="refAuthor">, Boggia, G.</span><span class="refAuthor">, Tyson, G.</span><span class="refAuthor">, Davies, E.</span><span class="refAuthor">, Molinaro, A.</span><span class="refAuthor">, and S. Eum</span>, <span class="refTitle">"Information-Centric Networking: Baseline Scenarios"</span>, <span class="seriesInfo">RFC 7476</span>, <span class="seriesInfo">DOI 10.17487/RFC7476</span>, <time datetime="2015-03" class="refDate">March 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7476">https://www.rfc-editor.org/info/rfc7476</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7945">[RFC7945]</dt>
      <dd>
<span class="refAuthor">Pentikousis, K., Ed.</span><span class="refAuthor">, Ohlman, B.</span><span class="refAuthor">, Davies, E.</span><span class="refAuthor">, Spirou, S.</span><span class="refAuthor">, and G. Boggia</span>, <span class="refTitle">"Information-Centric Networking: Evaluation and Security Considerations"</span>, <span class="seriesInfo">RFC 7945</span>, <span class="seriesInfo">DOI 10.17487/RFC7945</span>, <time datetime="2016-09" class="refDate">September 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7945">https://www.rfc-editor.org/info/rfc7945</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-9.2">
        <h3 id="name-informative-references">
<a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="cellbroadcast">[cellbroadcast]</dt>
        <dd>
<span class="refAuthor">Wikipedia</span>, <span class="refTitle">"Cell Broadcast"</span>, <time datetime="2020-08" class="refDate">August 2020</time>, <span>&lt;<a href="https://en.wikipedia.org/w/index.php?title=Cell_Broadcast&amp;oldid=972614007">https://en.wikipedia.org/w/index.php?title=Cell_Broadcast&amp;oldid=972614007</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="COPSS2011">[COPSS2011]</dt>
        <dd>
<span class="refAuthor">Chen, J.</span><span class="refAuthor">, Arumaithurai, M.</span><span class="refAuthor">, Jiao, L.</span><span class="refAuthor">, Fu, X.</span><span class="refAuthor">, and K. Ramakrishnan</span>, <span class="refTitle">"COPSS: An Efficient Content Oriented Publish/Subscribe System"</span>, <span class="refContent">Seventh ACM/IEEE Symposium on Architectures for
   Networking and Communications Systems (ANCS)</span>, <span class="seriesInfo">DOI 10.1109/ANCS.2011.27</span>, <time datetime="2011-10" class="refDate">October 2011</time>, <span>&lt;<a href="https://doi.org/10.1109/ANCS.2011.27">https://doi.org/10.1109/ANCS.2011.27</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="dtnrg">[dtnrg]</dt>
        <dd>
<span class="refAuthor">IRTF</span>, <span class="refTitle">"Delay-Tolerant Networking Research Group (DTNRG)"</span>, <span>&lt;<a href="https://irtf.org/dtnrg">https://irtf.org/dtnrg</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="dtnwg">[dtnwg]</dt>
        <dd>
<span class="refAuthor">IETF</span>, <span class="refTitle">"Delay/Disruption Tolerant Networking (dtn)"</span>, <span>&lt;<a href="https://datatracker.ietf.org/wg/dtn/about/">https://datatracker.ietf.org/wg/dtn/about/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Greifenberg2008">[Greifenberg2008]</dt>
        <dd>
<span class="refAuthor">Greifenberg, J.</span><span class="refAuthor"> and D. Kutscher</span>, <span class="refTitle">"Efficient Publish/Subscribe-Based Multicast for Opportunistic Networking with Self-Organized Resource Utilization"</span>, <span class="refContent">Advanced Information Networking and Applications - Workshops</span>, <span class="seriesInfo">DOI 10.1109/WAINA.2008.255</span>, <time datetime="2008-03" class="refDate">March 2008</time>, <span>&lt;<a href="https://doi.org/10.1109/WAINA.2008.255">https://doi.org/10.1109/WAINA.2008.255</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Gusev2015">[Gusev2015]</dt>
        <dd>
<span class="refAuthor">Gusev, P.</span><span class="refAuthor"> and J. Burke</span>, <span class="refTitle">"NDN-RTC: Real-Time Videoconferencing over Named Data Networking"</span>, <span class="refContent">2nd ACM Conference on Information-Centric Networking
   (ICN)</span>, <span class="seriesInfo">DOI 10.1145/2810156.2810176</span>, <time datetime="2015-09" class="refDate">September 2015</time>, <span>&lt;<a href="https://doi.org/10.1145/2810156.2810176">https://doi.org/10.1145/2810156.2810176</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Psaras2014">[Psaras2014]</dt>
        <dd>
<span class="refAuthor">Psaras, I.</span><span class="refAuthor">, Saino, L.</span><span class="refAuthor">, Arumaithurai, M.</span><span class="refAuthor">, Ramakrishnan, K.</span><span class="refAuthor">, and G. Pavlou</span>, <span class="refTitle">"Name-based replication priorities in disaster cases"</span>, <span class="refContent">IEEE Conference on Computer Communications Workshops</span>, <span class="seriesInfo">DOI 10.1109/INFCOMW.2014.6849271</span>, <time datetime="2014-04" class="refDate">April 2014</time>, <span>&lt;<a href="https://doi.org/10.1109/INFCOMW.2014.6849271">https://doi.org/10.1109/INFCOMW.2014.6849271</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Robitzsch2015">[Robitzsch2015]</dt>
        <dd>
<span class="refAuthor">Robitzsch, S.</span><span class="refAuthor">, Trossen, D.</span><span class="refAuthor">, Theodorou, C.</span><span class="refAuthor">, Barker, T.</span><span class="refAuthor">, and A. Sathiaseel</span>, <span class="refTitle">"D2.1: Usage Scenarios and Requirements"</span>, <span class="refContent">H2020 project RIFE, public deliverable</span>. </dd>
<dd class="break"></dd>
<dt id="Seedorf2014">[Seedorf2014]</dt>
        <dd>
<span class="refAuthor">Seedorf, J.</span><span class="refAuthor">, Kutscher, D.</span><span class="refAuthor">, and F. Schneider</span>, <span class="refTitle">"Decentralised binding of self-certifying names to real-world identities for assessment of third-party messages in fragmented mobile networks"</span>, <span class="refContent">IEEE Conference on Computer Communications Workshops</span>, <span class="seriesInfo">DOI 10.1109/INFCOMW.2014.6849268</span>, <time datetime="2014-04" class="refDate">April 2014</time>, <span>&lt;<a href="https://doi.org/10.1109/INFCOMW.2014.6849268">https://doi.org/10.1109/INFCOMW.2014.6849268</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Seedorf2016">[Seedorf2016]</dt>
        <dd>
<span class="refAuthor">Seedorf, J.</span><span class="refAuthor">, Kutscher, D.</span><span class="refAuthor">, and B. Gill</span>, <span class="refTitle">"Decentralised Interest Counter Aggregation for ICN in Disaster Scenarios"</span>, <span class="refContent">IEEE Globecom Workshops</span>, <span class="seriesInfo">DOI 10.1109/GLOCOMW.2016.7848869</span>, <time datetime="2016-12" class="refDate">December 2016</time>, <span>&lt;<a href="https://doi.org/10.1109/GLOCOMW.2016.7848869">https://doi.org/10.1109/GLOCOMW.2016.7848869</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Sourlas2015">[Sourlas2015]</dt>
        <dd>
<span class="refAuthor">Sourlas, V.</span><span class="refAuthor">, Tassiulas, L.</span><span class="refAuthor">, Psaras, I.</span><span class="refAuthor">, and G. Pavlou</span>, <span class="refTitle">"Information resilience through user-assisted caching in disruptive Content-Centric Networks"</span>, <span class="refContent">IFIP Networking Conference</span>, <span class="seriesInfo">DOI 10.1109/IFIPNetworking.2015.7145301</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span>&lt;<a href="https://doi.org/10.1109/IFIPNetworking.2015.7145301">https://doi.org/10.1109/IFIPNetworking.2015.7145301</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Tagami2016">[Tagami2016]</dt>
        <dd>
<span class="refAuthor">Tagami, A.</span><span class="refAuthor">, Yagyu, T.</span><span class="refAuthor">, Sugiyama, K.</span><span class="refAuthor">, Arumaithurai, M.</span><span class="refAuthor">, Nakamura, K.</span><span class="refAuthor">, Hasegawa, T.</span><span class="refAuthor">, Asami, T.</span><span class="refAuthor">, and K. Ramakrishnan</span>, <span class="refTitle">"Name-based push/pull message dissemination for disaster message board"</span>, <span class="refContent">IEEE International Symposium on Local and
     Metropolitan Area Networks (LANMAN)</span>, <span class="seriesInfo">DOI 10.1109/LANMAN.2016.7548855</span>, <time datetime="2016-06" class="refDate">June 2016</time>, <span>&lt;<a href="https://doi.org/10.1109/LANMAN.2016.7548855">https://doi.org/10.1109/LANMAN.2016.7548855</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Trossen2015">[Trossen2015]</dt>
        <dd>
<span class="refAuthor">Trossen, D.</span><span class="refAuthor">, Reed, M.</span><span class="refAuthor">, Riihijärvi, J.</span><span class="refAuthor">, Georgiades, M.</span><span class="refAuthor">, Fotiou, N.</span><span class="refAuthor">, and G. Xylomenos</span>, <span class="refTitle">"IP over ICN - The better IP?"</span>, <span class="refContent">2European Conference on Networks and Communications
     (EuCNC)</span>, <span class="seriesInfo">DOI 10.1109/EuCNC.2015.7194109</span>, <time datetime="2015-06" class="refDate">June 2015</time>, <span>&lt;<a href="https://doi.org/10.1109/EuCNC.2015.7194109">https://doi.org/10.1109/EuCNC.2015.7194109</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Yoneki2007">[Yoneki2007]</dt>
      <dd>
<span class="refAuthor">Yoneki, E.</span><span class="refAuthor">, Hui, P.</span><span class="refAuthor">, Chan, S.</span><span class="refAuthor">, and J. Crowcroft</span>, <span class="refTitle">"A socio-aware overlay for publish/subscribe communication in delay tolerant networks"</span>, <span class="refContent">Proceedings of the 10th ACM Symposium on Modeling,
     Analysis, and Simulation of Wireless and Mobile
     Systems</span>, <span class="seriesInfo">DOI 10.1145/1298126.1298166</span>, <time datetime="2007-10" class="refDate">October 2007</time>, <span>&lt;<a href="https://doi.org/10.1145/1298126.1298166">https://doi.org/10.1145/1298126.1298166</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<section id="section-appendix.a">
      <h2 id="name-acknowledgment">
<a href="#name-acknowledgment" class="section-name selfRef">Acknowledgment</a>
      </h2>
<p id="section-appendix.a-1">The authors would like to thank <span class="contact-name">Ioannis Psaras</span>
      for useful comments. Also, the authors are grateful to <span class="contact-name">Christopher Wood</span> and <span class="contact-name">Daniel Corujo</span>
      for valuable feedback and suggestions on concrete text for 
      improving the document. Further, the authors would like to thank
      <span class="contact-name">Joerg Ott</span> and <span class="contact-name">Dirk Trossen</span>
      for valuable comments and input, in particular, 
      regarding existing work from the DTN community that is highly related
      to the ICN approaches suggested in this document. Also, <span class="contact-name">Akbar Rahman</span>
      provided useful comments and suggestions, in particular, regarding
      existing disaster warning mechanisms in today's mobile phone
      networks.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
<p id="section-appendix.a-2">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 the NICT. More information
      is available at the project website: <span><a href="http://www.greenicn.org/">http://www.greenicn.org/</a></span>.<a href="#section-appendix.a-2" class="pilcrow">¶</a></p>
<p id="section-appendix.a-3">This document has also been supported by the Coordination Support
      Action entitled 'Supporting European Experts Presence in International
      Standardisation Activities in ICT' (<a href="https://standict.eu/">StandICT.eu</a>) funded by the European Commission under
      the Horizon 2020 Programme with Grant Agreement no. 780439. 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 European
      Commission.<a href="#section-appendix.a-3" class="pilcrow">¶</a></p>
</section>
<div id="authors-addresses">
<section id="section-appendix.b">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Jan Seedorf</span></div>
<div dir="auto" class="left"><span class="org">HFT Stuttgart - Univ. of Applied Sciences</span></div>
<div dir="auto" class="left"><span class="street-address">Schellingstrasse 24</span></div>
<div dir="auto" class="left">
<span class="postal-code">70174</span> <span class="locality">Stuttgart</span>
</div>
<div dir="auto" class="left"><span class="country-name">Germany</span></div>
<div class="tel">
<span>Phone:</span>
<a href="tel:+49%20711%208926%202801" class="tel">+49 711 8926 2801</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:jan.seedorf@hft-stuttgart.de" class="email">jan.seedorf@hft-stuttgart.de</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Mayutan Arumaithurai</span></div>
<div dir="auto" class="left"><span class="org">University of Göttingen</span></div>
<div dir="auto" class="left"><span class="street-address">Goldschmidt Str. 7</span></div>
<div dir="auto" class="left">
<span class="postal-code">37077</span> <span class="locality">Göttingen
            </span>
</div>
<div dir="auto" class="left"><span class="country-name">Germany</span></div>
<div class="tel">
<span>Phone:</span>
<a href="tel:+49%20551%2039%20172046" class="tel">+49 551 39 172046</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:arumaithurai@informatik.uni-goettingen.de" class="email">arumaithurai@informatik.uni-goettingen.de</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Atsushi Tagami</span></div>
<div dir="auto" class="left"><span class="org">KDDI Research Inc.</span></div>
<div dir="auto" class="left">
<span class="street-address">2-1-15 Ohara, Fujimino</span>, <span class="region">Saitama</span>
</div>
<div dir="auto" class="left"><span class="postal-code">356-85025</span></div>
<div dir="auto" class="left"><span class="country-name">Japan</span></div>
<div class="tel">
<span>Phone:</span>
<a href="tel:+81%2049%20278%2073651" class="tel">+81 49 278 73651</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:tagami@kddi-research.jp" class="email">tagami@kddi-research.jp</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">K. K. Ramakrishnan</span></div>
<div dir="auto" class="left"><span class="org">University of California</span></div>
<div dir="auto" class="left">
<span class="locality">Riverside</span>,  <span class="postal-code">CA</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:kkrama@ucr.edu" class="email">kkrama@ucr.edu</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Nicola Blefari Melazzi</span></div>
<div dir="auto" class="left"><span class="org">University Tor Vergata</span></div>
<div dir="auto" class="left"><span class="street-address">Via del Politecnico, 1</span></div>
<div dir="auto" class="left">
<span class="postal-code">00133</span> <span class="locality">Roma</span> </div>
<div dir="auto" class="left"><span class="country-name">Italy</span></div>
<div class="tel">
<span>Phone:</span>
<a href="tel:+39%2006%207259%207501" class="tel">+39 06 7259 7501</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:blefari@uniroma2.it" class="email">blefari@uniroma2.it</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
  toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
  toc.classList.remove("active");
});
</script>
</body>
</html>