File: rfc9138.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 (2301 lines) | stat: -rw-r--r-- 112,985 bytes
<!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 9138: Design Considerations for Name Resolution Service in Information-Centric Networking (ICN)</title>
<meta content="Jungha Hong" name="author">
<meta content="Tae-Wan You" name="author">
<meta content="Lijun Dong" name="author">
<meta content="Cedric Westphal" name="author">
<meta content="Börje Ohlman" name="author">
<meta content="
       
        This document provides the functionalities and design considerations
        for a Name Resolution Service (NRS) in Information-Centric Networking (ICN).  

The purpose of an NRS in ICN is to translate
        an object name into some other information such as a locator, another
        name, etc. in order to forward the object request. This document is a product
        of the Information-Centric Networking Research Group (ICNRG).
       
    " name="description">
<meta content="xml2rfc 3.11.1" name="generator">
<meta content="9138" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.11.1
    Python 3.6.13
    appdirs 1.4.4
    ConfigArgParse 1.4.1
    google-i18n-address 2.4.0
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.3
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.15.1
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.4.1
    requests 2.24.0
    setuptools 40.5.0
    six 1.14.0
    WeasyPrint 52.5
-->
<link href="rfc9138.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.ulBare, li.ulBare {
  margin-left: 0em !important;
}
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;
}
/* Fix PDF info block run off issue */
@media print {
  #identifiers dd {
    float: none;
  }
}
#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: auto;
  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";
}
/* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */
li > p {
  margin-bottom: 0.5em
}
/* Don't let p margin spill out from inside list items */
li > p:last-of-type {
  margin-bottom: 0;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc9138" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-irtf-icnrg-nrs-requirements-06" 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 9138</td>
<td class="center">Design Considerations for NRS</td>
<td class="right">November 2021</td>
</tr></thead>
<tfoot><tr>
<td class="left">Hong, 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/rfc9138" class="eref">9138</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Informational</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2021-11" class="published">November 2021</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. Hong</div>
<div class="org">ETRI</div>
</div>
<div class="author">
      <div class="author-name">T. You</div>
<div class="org">ETRI</div>
</div>
<div class="author">
      <div class="author-name">L. Dong</div>
<div class="org">Futurewei Technologies Inc.</div>
</div>
<div class="author">
      <div class="author-name">C. Westphal</div>
<div class="org">Futurewei Technologies Inc.</div>
</div>
<div class="author">
      <div class="author-name">B. Ohlman</div>
<div class="org">Ericsson</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9138</h1>
<h1 id="title">Design Considerations for Name Resolution Service in Information-Centric Networking (ICN)</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">
        This document provides the functionalities and design considerations
        for a Name Resolution Service (NRS) in Information-Centric Networking (ICN).  

The purpose of an NRS in ICN is to translate
        an object name into some other information such as a locator, another
        name, etc. in order to forward the object request. 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
            candidates 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/rfc9138">https://www.rfc-editor.org/info/rfc9138</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) 2021 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 ulBare ulEmpty">
<li class="compact toc ulBare 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></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-name-resolution-service-in-" class="xref">Name Resolution Service in ICN</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.1">
                <p id="section-toc.1-1.2.2.1.1" class="keepWithNext"><a href="#section-2.1" class="xref">2.1</a>.  <a href="#name-explicit-name-resolution-ap" class="xref">Explicit Name Resolution Approach</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.2">
                <p id="section-toc.1-1.2.2.2.1" class="keepWithNext"><a href="#section-2.2" class="xref">2.2</a>.  <a href="#name-name-based-routing-approach" class="xref">Name-Based Routing Approach</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.3">
                <p id="section-toc.1-1.2.2.3.1"><a href="#section-2.3" class="xref">2.3</a>.  <a href="#name-hybrid-approach" class="xref">Hybrid Approach</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.4">
                <p id="section-toc.1-1.2.2.4.1"><a href="#section-2.4" class="xref">2.4</a>.  <a href="#name-comparisons-of-name-resolut" class="xref">Comparisons of Name Resolution Approaches</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare 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-functionalities-of-nrs-in-i" class="xref">Functionalities of NRS in ICN</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.1">
                <p id="section-toc.1-1.3.2.1.1"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-support-heterogeneous-name-" class="xref">Support Heterogeneous Name Types</a></p>
</li>
              <li class="compact toc ulBare 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-support-producer-mobility" class="xref">Support Producer Mobility</a></p>
</li>
              <li class="compact toc ulBare 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-support-scalable-routing-sy" class="xref">Support Scalable Routing System</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.4">
                <p id="section-toc.1-1.3.2.4.1"><a href="#section-3.4" class="xref">3.4</a>.  <a href="#name-support-off-path-caching" class="xref">Support Off-Path Caching</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.5">
                <p id="section-toc.1-1.3.2.5.1"><a href="#section-3.5" class="xref">3.5</a>.  <a href="#name-support-nameless-object" class="xref">Support Nameless Object</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.6">
                <p id="section-toc.1-1.3.2.6.1"><a href="#section-3.6" class="xref">3.6</a>.  <a href="#name-support-manifest" class="xref">Support Manifest</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.7">
                <p id="section-toc.1-1.3.2.7.1"><a href="#section-3.7" class="xref">3.7</a>.  <a href="#name-support-metadata" class="xref">Support Metadata</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare 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-design-considerations-for-n" class="xref">Design Considerations for NRS in ICN</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.1">
                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-resolution-response-time" class="xref">Resolution Response Time</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2">
                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-response-accuracy" class="xref">Response Accuracy</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.3">
                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-resolution-guarantee" class="xref">Resolution Guarantee</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.4">
                <p id="section-toc.1-1.4.2.4.1"><a href="#section-4.4" class="xref">4.4</a>.  <a href="#name-resolution-fairness" class="xref">Resolution Fairness</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.5">
                <p id="section-toc.1-1.4.2.5.1"><a href="#section-4.5" class="xref">4.5</a>.  <a href="#name-scalability" class="xref">Scalability</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.6">
                <p id="section-toc.1-1.4.2.6.1"><a href="#section-4.6" class="xref">4.6</a>.  <a href="#name-manageability" class="xref">Manageability</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.7">
                <p id="section-toc.1-1.4.2.7.1"><a href="#section-4.7" class="xref">4.7</a>.  <a href="#name-deployed-system" class="xref">Deployed System</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.8">
                <p id="section-toc.1-1.4.2.8.1"><a href="#section-4.8" class="xref">4.8</a>.  <a href="#name-fault-tolerance" class="xref">Fault Tolerance</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.9">
                <p id="section-toc.1-1.4.2.9.1"><a href="#section-4.9" class="xref">4.9</a>.  <a href="#name-security-and-privacy" class="xref">Security and Privacy</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.9.2.1">
                    <p id="section-toc.1-1.4.2.9.2.1.1"><a href="#section-4.9.1" class="xref">4.9.1</a>.  <a href="#name-confidentiality" class="xref">Confidentiality</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.9.2.2">
                    <p id="section-toc.1-1.4.2.9.2.2.1"><a href="#section-4.9.2" class="xref">4.9.2</a>.  <a href="#name-authentication" class="xref">Authentication</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.9.2.3">
                    <p id="section-toc.1-1.4.2.9.2.3.1"><a href="#section-4.9.3" class="xref">4.9.3</a>.  <a href="#name-integrity" class="xref">Integrity</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.9.2.4">
                    <p id="section-toc.1-1.4.2.9.2.4.1"><a href="#section-4.9.4" class="xref">4.9.4</a>.  <a href="#name-resiliency-and-availability" class="xref">Resiliency and Availability</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="compact toc ulBare 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-conclusion" class="xref">Conclusion</a></p>
</li>
          <li class="compact toc ulBare 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-iana-considerations" class="xref">IANA Considerations</a></p>
</li>
          <li class="compact toc ulBare 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-security-considerations" class="xref">Security Considerations</a></p>
</li>
          <li class="compact toc ulBare 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-references" class="xref">References</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.1">
                <p id="section-toc.1-1.8.2.1.1"><a href="#section-8.1" class="xref">8.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.2">
                <p id="section-toc.1-1.8.2.2.1"><a href="#section-8.2" class="xref">8.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#appendix-A" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#appendix-B" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</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">
          The current Internet is based upon a host-centric networking paradigm, where hosts are
          identified with IP addresses and communication is possible
          between any pair of hosts. Thus, information in the current Internet
          is identified by the name of the host (or server) where the information is stored.
          In contrast to host-centric networking, the primary communication
          objects in Information-Centric Networking (ICN) are the named data
          objects (NDOs), and they are uniquely identified by location-independent
          names. Thus, ICN aims for the efficient dissemination and retrieval of
          NDOs at a global scale and has been identified and acknowledged as a
          promising technology for a future Internet architecture to overcome
          the limitations of the current Internet, such as scalability and
          mobility <span>[<a href="#Ahlgren" class="xref">Ahlgren</a>]</span> <span>[<a href="#Xylomenos" class="xref">Xylomenos</a>]</span>.
          ICN also has emerged as a candidate architecture in the Internet of Things (IoT) environment
          since IoT focuses on data and information
          <span>[<a href="#Baccelli" class="xref">Baccelli</a>]</span> <span>[<a href="#Amadeo" class="xref">Amadeo</a>]</span> <span>[<a href="#Quevedo" class="xref">Quevedo</a>]</span>
        <span>[<a href="#Amadeo2" class="xref">Amadeo2</a>]</span> <span>[<a href="#I-D.irtf-icnrg-icniot" class="xref">ID.Zhang2</a>]</span>.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">Since naming data independently from its current location (where it is
          stored) is a primary concept of ICN, how to find any NDO using a
          location-independent name is one of the most important design challenges
          in ICN. Such ICN routing may comprise three steps <span>[<a href="#RFC7927" class="xref">RFC7927</a>]</span>:<a href="#section-1-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="olPercent" id="section-1-3">
        <dt>(1)</dt>
<dd id="section-1-3.1">Name resolution: matches/translates a content name to the locator
                  of the content producer or source that can provide the content.<a href="#section-1-3.1" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt>(2)</dt>
<dd id="section-1-3.2">Content request routing: routes the content request towards
                  the content's location based either on its name or locator.<a href="#section-1-3.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt>(3)</dt>
<dd id="section-1-3.3">Content delivery: transfers the content to the requester.<a href="#section-1-3.3" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-1-4">
          Among the three steps of ICN routing, this document investigates only
          the name resolution step, which translates a content name to the content locator.
          In addition, this document covers various possible types of name
          resolution in ICN such as one name to another name, name to locator,
          name to manifest, name to metadata, etc.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">
          The focus of this document is a Name Resolution Service (NRS) itself
          as a service or a system in ICN, and it provides the functionalities and
          the design considerations for an NRS in ICN as well as the overview of
          the NRS approaches in ICN. On the other hand, its companion document
          <span>[<a href="#I-D.irtf-icnrg-nrsarch-considerations" class="xref">NRSarch</a>]</span> describes considerations from the perspective
          of the ICN architecture and routing system when using an NRS in ICN.<a href="#section-1-5" class="pilcrow">¶</a></p>
<p id="section-1-6">
          This document represents the consensus of the Information-Centric
          Networking Research Group (ICNRG). It has been reviewed extensively
          by the Research Group (RG) members who are actively involved in the
          research and development of the technology covered by this document.
          It is not an IETF product and is not a standard.<a href="#section-1-6" class="pilcrow">¶</a></p>
</section>
<section id="section-2">
      <h2 id="name-name-resolution-service-in-">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-name-resolution-service-in-" class="section-name selfRef">Name Resolution Service in ICN</a>
      </h2>
<p id="section-2-1">
          A Name Resolution Service (NRS) in ICN is defined as the service that
          provides the name resolution function for translating an object name
          into some other information such as a locator, another name, metadata,
          next-hop info, etc. that is used for forwarding the object request.
          In other words, an NRS is a service that can be provided by the ICN
          infrastructure to help a consumer reach a specific piece of information
          (or named data object). The consumer provides an NRS with a persistent
          name, and the NRS returns a name or locator (or potentially multiple
          names and locators) that can reach a current instance of the
          requested object.<a href="#section-2-1" class="pilcrow">¶</a></p>
<p id="section-2-2">
         The name resolution is a necessary process in ICN routing, although the
         name resolution either can be separated from the content request routing
         as an explicit process or can be integrated with the content request
         routing as an implicit process.  The former is referred to as an "explicit name
         resolution approach", and the latter is referred to as a "name-based routing approach"
         in this document.<a href="#section-2-2" class="pilcrow">¶</a></p>
<section id="section-2.1">
        <h3 id="name-explicit-name-resolution-ap">
<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-explicit-name-resolution-ap" class="section-name selfRef">Explicit Name Resolution Approach</a>
        </h3>
<p id="section-2.1-1">
          An NRS could take the explicit name resolution approach to return the
          locators of the content to the client, which will be used by the underlying
          network as the identifier to route the client's request to one of the
          producers or to a copy of the content. There are several ICN projects
          that use the explicit name resolution approach, such as  Data-Oriented Network Architecture (DONA) <span>[<a href="#Koponen" class="xref">Koponen</a>]</span>, PURSUIT <span>[<a href="#PURSUIT" class="xref">PURSUIT</a>]</span>,
          Network of Information (NetInf) <span>[<a href="#SAIL" class="xref">SAIL</a>]</span>, MobilityFirst <span>[<a href="#MF" class="xref">MF</a>]</span>,
          IDNet <span>[<a href="#Jung" class="xref">Jung</a>]</span>, etc. In addition, the explicit name
          resolution approach has been allowed for 5G control planes <span>[<a href="#SA2-5GLAN" class="xref">SA2-5GLAN</a>]</span>.<a href="#section-2.1-1" class="pilcrow">¶</a></p>
</section>
<section id="section-2.2">
        <h3 id="name-name-based-routing-approach">
<a href="#section-2.2" class="section-number selfRef">2.2. </a><a href="#name-name-based-routing-approach" class="section-name selfRef">Name-Based Routing Approach</a>
        </h3>
<p id="section-2.2-1">An NRS could take the name-based routing approach, which integrates
            name resolution with content request message routing as in
            Named Data Networking / Content-Centric Networking (NDN/CCNx) <span>[<a href="#NDN" class="xref">NDN</a>]</span> <span>[<a href="#CCNx" class="xref">CCNx</a>]</span>.<a href="#section-2.2-1" class="pilcrow">¶</a></p>
<p id="section-2.2-2">
            In cases where the content request also specifies the reverse path,
            as in NDN/CCNx, the name resolution mechanism also derives the routing
            path for the data. This adds a requirement to the name resolution
            service to propagate the request in a way that is consistent with the
            subsequent data forwarding. Namely, the request must select a path
            for the data based upon finding a copy of the content but also
            properly delivering the data.<a href="#section-2.2-2" class="pilcrow">¶</a></p>
</section>
<section id="section-2.3">
        <h3 id="name-hybrid-approach">
<a href="#section-2.3" class="section-number selfRef">2.3. </a><a href="#name-hybrid-approach" class="section-name selfRef">Hybrid Approach</a>
        </h3>
<p id="section-2.3-1">
            An NRS could also take hybrid approach. For instance, it can attempt
            the name-based routing approach first. If this fails at a certain
            router, the router can go back to the explicit name resolution approach.
            The hybrid NRS approach also works the other way around: first by performing
            explicit name resolution to find the locators of routers, then by routing the client's request using the name-based routing approach.<a href="#section-2.3-1" class="pilcrow">¶</a></p>
<p id="section-2.3-2">
            A hybrid approach would combine name resolution over a subset of
            routers on the path with some tunneling in between (say, across an
            administrative domain) so that only a few of the nodes in the ICN
            network perform name resolution in the name-based routing approach.<a href="#section-2.3-2" class="pilcrow">¶</a></p>
</section>
<section id="section-2.4">
        <h3 id="name-comparisons-of-name-resolut">
<a href="#section-2.4" class="section-number selfRef">2.4. </a><a href="#name-comparisons-of-name-resolut" class="section-name selfRef">Comparisons of Name Resolution Approaches</a>
        </h3>
<p id="section-2.4-1">
           The following compares the explicit name resolution and the name-based
           routing approaches in several aspects:<a href="#section-2.4-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2.4-2.1">Overhead due to the maintenance of the content location:
                  The content reachability is dynamic and includes new
                  content being cached or content being expired from a cache,
                  content producer mobility, etc. Maintaining a consistent
                  view of the content location across the network requires
                  some overhead that differs for the name resolution approaches.
                  The name-based routing approach may require flooding
                  parts of the network for update propagation. In the worst
                  case, the name-based routing approach may flood the whole network
                  (but mitigating techniques may be used to scope the flooding).
                  However, the explicit name resolution approach only requires
                  updating propagation in part of the name resolution system
                  (which could be an overlay with a limited number of nodes).<a href="#section-2.4-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-2.4-2.2">Resolution capability: The explicit name resolution approach, if designed and deployed with sufficient robustness, can offer at least weak guarantees that resolution will succeed for any content name in the network if it is registered to the name resolution overlay.
                  In the name-based routing approach, content resolution depends on the flooding scope of the content names (i.e., content publishing message and the resulting name-based routing tables).
                  For example, when content is cached, the router may only notify its direct neighbors of this information. Thus, only those neighboring
 routers can build a name-based entry for this cached content.
                  But if the neighboring routers continue to propagate this information, the other nodes are able to direct to this cached copy as well.<a href="#section-2.4-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-2.4-2.3">Node failure impact: Nodes involved in the explicit name resolution approach are the name resolution overlay servers (e.g., resolution handlers in DONA),
                  while the nodes involved in the name-based routing approach are routers that route messages based on the name-based routing tables (e.g.,  NDN routers).
                  Node failures in the explicit name resolution approach may cause some content request routing to fail even though the content is available.
                  This problem does not exist in the name-based routing approach because other alternative paths can be discovered to bypass the failed ICN routers, given the assumption that the network is still connected.<a href="#section-2.4-2.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-2.4-2.4">Maintained databases: The storage usage for the explicit name resolution approach is different from that of the name-based routing approach.
                  The explicit name resolution approach typically needs to maintain two databases: name-to-locator mapping in the name resolution overlay and routing tables in the routers on the data forwarding plane.
                  The  name-based routing approach needs to maintain only the name-based routing tables.<a href="#section-2.4-2.4" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-2.4-3">Additionally, some other intermediary step may be included in the name resolution -- namely, the mapping of one name to other names -- in order to facilitate the retrieval of named content by way of a manifest <span>[<a href="#Westphal" class="xref">Westphal</a>]</span> <span>[<a href="#RFC8569" class="xref">RFC8569</a>]</span>.
        The manifest is resolved using one of the two above approaches, and it may include further mapping of names to content and location. 
The steps for name resolution then become the following: first, translate the manifest name into a location of a copy of the manifest, which includes further names of the content components and potentially locations for the content, then retrieve the content by using these names and/or location, potentially resulting in additional name resolutions.<a href="#section-2.4-3" class="pilcrow">¶</a></p>
<p id="section-2.4-4">Thus, no matter which approach is taken by an NRS in ICN, the name resolution is the essential function that shall be provided by the ICN infrastructure.<a href="#section-2.4-4" class="pilcrow">¶</a></p>
</section>
</section>
<section id="section-3">
      <h2 id="name-functionalities-of-nrs-in-i">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-functionalities-of-nrs-in-i" class="section-name selfRef">Functionalities of NRS in ICN</a>
      </h2>
<p id="section-3-1">This section presents the functionalities of an NRS in ICN.<a href="#section-3-1" class="pilcrow">¶</a></p>
<section id="section-3.1">
        <h3 id="name-support-heterogeneous-name-">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-support-heterogeneous-name-" class="section-name selfRef">Support Heterogeneous Name Types</a>
        </h3>
<p id="section-3.1-1">
          In ICN, a name is used to identify the data object and is bound to it <span>[<a href="#RFC7927" class="xref">RFC7927</a>]</span>.
          ICN requires uniqueness and persistency of the name of the data object to ensure the
          reachability of the object within a certain scope.  There are
          heterogeneous approaches to designing ICN naming schemes <span>[<a href="#Bari" class="xref">Bari</a>]</span>.
          Ideally, a name can include any form of identifier, which can be
          flat or hierarchical, human readable or non-readable.<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<p id="section-3.1-2">
          Although there are diverse types of naming schemes proposed in the literature,
          they all need to provide basic functions for identifying a data object,
          supporting named data lookup, and routing. An NRS may combine the better
          aspects of different schemes. Basically, an NRS should be able to support
          a generic naming schema so that it can resolve any type of content name,
          irrespective of whether it is flat, hierarchical, attribute based, or
          anything else.<a href="#section-3.1-2" class="pilcrow">¶</a></p>
<p id="section-3.1-3">
          In PURSUIT <span>[<a href="#PURSUIT" class="xref">PURSUIT</a>]</span>, names are flat, and the rendezvous
          functions are defined for an NRS, which is implemented by a set of rendezvous
          nodes (RNs), known as the rendezvous network (RENE). Thus, a name consists of a
          sequence of scope IDs, and a single rendezvous ID is routed by the RNs in RENE.
          Thus, PURSUIT decouples name resolution and data routing, where the NRS
          is performed by the RENE.<a href="#section-3.1-3" class="pilcrow">¶</a></p>
<p id="section-3.1-4">
          In MobilityFirst <span>[<a href="#MF" class="xref">MF</a>]</span>, a name known as a "Global
          Unique Identifier (GUID)", derived from a human-readable name via a global
          naming service, is a flat typed 160-bit string with self-certifying
          properties. Thus, MobilityFirst defines a Global Name Resolution Service
          (GNRS), which resolves GUIDs to network addresses and decouples name
          resolution and data routing similarly to PURSUIT.<a href="#section-3.1-4" class="pilcrow">¶</a></p>
<p id="section-3.1-5">
          In NetInf <span>[<a href="#Dannewitz" class="xref">Dannewitz</a>]</span>, information objects are named using Named Information (NI) names <span>[<a href="#RFC6920" class="xref">RFC6920</a>]</span>, which consist of an authority part and digest part (content hash).
          The NI names can be flat as the authority part is optional. Thus, the NetInf architecture also includes a Name Resolution System (NRS), which can be used to resolve NI names to addresses in an underlying routable network layer.<a href="#section-3.1-5" class="pilcrow">¶</a></p>
<p id="section-3.1-6">
          In NDN <span>[<a href="#NDN" class="xref">NDN</a>]</span> and CCNx <span>[<a href="#CCNx" class="xref">CCNx</a>]</span>,
          names are hierarchical and may be similar to URLs. Each name component
          can be anything, including a human-readable string or a hash value.
          NDN/CCNx adopts the name-based routing approach. The NDN router forwards
          the request by doing the longest-match lookup in the Forwarding
          Information Base (FIB) based on the content name, and the request is
          stored in the Pending Interest Table (PIT).<a href="#section-3.1-6" class="pilcrow">¶</a></p>
</section>
<section id="section-3.2">
        <h3 id="name-support-producer-mobility">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-support-producer-mobility" class="section-name selfRef">Support Producer Mobility</a>
        </h3>
<p id="section-3.2-1">
           ICN inherently supports mobility by consumers. Namely, consumer or client
           mobility is handled by re-requesting the content in case the mobility
           event (say, handover) occurred before receiving the corresponding
           content from the network. Since ICN can ensure that content reception
           continues without any disruption in ICN applications, seamless mobility
           from the consumer's point of view can be easily supported.<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<p id="section-3.2-2">
           However, producer mobility does not emerge naturally from the ICN
           forwarding model as does consumer mobility. If a producer moves into
           a different network location or a different name domain, which is
           assigned by another authoritative publisher, it would be difficult for
           the mobility management to update Routing Information Base (RIB) and FIB entries in ICN routers
           with the new forwarding path in a very short time. Therefore, various
           ICN architectures in the literature have proposed adopting an NRS to
           achieve the producer or publisher mobility, where the NRS can be
           implemented in different ways such as rendezvous points and/or overlay mapping systems.<a href="#section-3.2-2" class="pilcrow">¶</a></p>
<p id="section-3.2-3">
           In NDN <span>[<a href="#Zhang2" class="xref">Zhang2</a>]</span>, for producer mobility support, rendezvous mechanisms have been proposed to build interest rendezvous
           (RV) with data generated by a mobile producer (MP). This can be
           classified into two approaches: chase mobile producer and rendezvous data.
           Regarding MP chasing, rendezvous acts as a mapping service that provides
           the mapping from the name of the data produced by the MP to the name
           of the MP's current point of attachment (PoA). 


Alternatively, the RV
           serves as a home agent as in IP mobility support, so the RV enables
           the consumer's Interest message to tunnel towards the MP at the PoA.
           Regarding rendezvous data, the solution involves moving the data produced
           by the MP to a data depot instead of forwarding Interest messages. 

Thus,
           a consumer's Interest message can be forwarded to stationary place called a "data rendezvous", so it would either return the data or fetch it
           using another mapping solution. Therefore, RV or other mapping functions
           are in the role of an NRS in NDN.<a href="#section-3.2-3" class="pilcrow">¶</a></p>
<p id="section-3.2-4">
          In <span>[<a href="#I-D.ravi-icnrg-ccn-forwarding-label" class="xref">Ravindran</a>]</span>, the forwarding label (FL) object is
          used to enable identifier (ID) and locator (LID) namespaces to be
          split in ICN. Generally, IDs are managed by applications, while locators
          are managed by a network administrator so that IDs are mapped to
          heterogeneous name schemes and LIDs are mapped to the network domains or
          to specific network elements. Thus, the proposed FL object acts as a locator
          (LID) and provides the flexibility to forward Interest messages through
          a mapping service between IDs and LIDs. Therefore, the mapping service in
          control plane infrastructure can be considered as an NRS in this draft.<a href="#section-3.2-4" class="pilcrow">¶</a></p>
<p id="section-3.2-5">
          In MobilityFirst <span>[<a href="#MF" class="xref">MF</a>]</span>, both consumer and publisher
          mobility can be primarily handled by the global name resolution service
          (GNRS), which resolves GUIDs to network addresses. Thus, the GNRS  must
          be updated for mobility support when a network-attached object changes
          its point of attachment, which differs from NDN/CCNx.<a href="#section-3.2-5" class="pilcrow">¶</a></p>
<p id="section-3.2-6">
          In NetInf <span>[<a href="#Dannewitz" class="xref">Dannewitz</a>]</span>, mobility is handled by
          an NRS in a very similar way to MobilityFirst.<a href="#section-3.2-6" class="pilcrow">¶</a></p>
<p id="section-3.2-7">
           Besides the consumer and producer mobility, ICN also faces
           challenges to support the other dynamic features such as multi-homing,
           migration, and replication of named resources such as content, devices,
           and services. Therefore, an NRS can help to support these dynamic features.<a href="#section-3.2-7" class="pilcrow">¶</a></p>
</section>
<section id="section-3.3">
        <h3 id="name-support-scalable-routing-sy">
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-support-scalable-routing-sy" class="section-name selfRef">Support Scalable Routing System</a>
        </h3>
<p id="section-3.3-1">
           In ICN, the name of data objects is used for routing by either a name
           resolution step or a routing table lookup. Thus, routing information
           for each data object should be maintained in the routing base, such
           as RIB and FIB.
           Since the number of data objects would be very large, the size of
           information bases would be significantly larger as well <span>[<a href="#RFC7927" class="xref">RFC7927</a>]</span>.<a href="#section-3.3-1" class="pilcrow">¶</a></p>
<p id="section-3.3-2">
           The hierarchical namespace used in CCNx <span>[<a href="#CCNx" class="xref">CCNx</a>]</span>
           and NDN <span>[<a href="#NDN" class="xref">NDN</a>]</span> architectures reduces the size of
           these tables through name aggregation and improves the scalability of
           the routing system. A flat naming scheme, on the other hand, would
           aggravate the scalability problem of the routing system.
           The non-aggregated name prefixes injected into the Default Route Free
           Zone (DFZ) of ICN would create a more serious scalability problem when
           compared to the scalability issues of the IP routing system.
           Thus, an NRS may play an important role in the reduction of the routing
           scalability problem regardless of the types of namespaces.<a href="#section-3.3-2" class="pilcrow">¶</a></p>
<p id="section-3.3-3">
           In <span>[<a href="#Afanasyev" class="xref">Afanasyev</a>]</span>, in order to address the routing
           scalability problem in NDN's DFZ, a well-known concept called "map-and-encap" is applied to provide a simple and secure namespace mapping solution.
           In the proposed map-and-encap design, data whose name prefixes do not
           exist in the DFZ forwarding table can be retrieved by a distributed
           mapping system called NDNS, which maintains and looks up the mapping
           information from a name to its globally routed prefixes, where NDNS is
           a kind of an NRS.<a href="#section-3.3-3" class="pilcrow">¶</a></p>
</section>
<section id="section-3.4">
        <h3 id="name-support-off-path-caching">
<a href="#section-3.4" class="section-number selfRef">3.4. </a><a href="#name-support-off-path-caching" class="section-name selfRef">Support Off-Path Caching</a>
        </h3>
<p id="section-3.4-1">
          Caching in-network is considered to be a basic architectural component
          of an ICN architecture. It may be used to provide a level of quality-of-service (QoS)
          experience to users to reduce the overall network traffic, to prevent network
          congestion and denial-of-service (DoS) attacks, and to increase availability.
          Caching approaches can be categorized into off-path caching and on-path
          caching based on the location of caches in relation to the forwarding
          path from the original server to the consumer. Off-path caching, also
          referred to as "content replication" or "content storing", aims to replicate
          content within a network in order to increase availability, regardless of
          the relationship of the location to the forwarding path. Thus, finding
          off-path cached objects is not trivial in name-based routing of ICN.
          In order to support off-path caches, replicas are usually advertised
          into a name-based routing system or into an NRS.<a href="#section-3.4-1" class="pilcrow">¶</a></p>
<p id="section-3.4-2">
          In <span>[<a href="#Bayhan" class="xref">Bayhan</a>]</span>, an NRS is used to find off-path copies
          in the network, which may not be accessible via name-based routing mechanisms.
          Such a capability can be helpful for an Autonomous System (AS) to avoid
          the costly inter-AS traffic for external content more, to yield higher
          bandwidth efficiency for intra-AS traffic, and to decrease the data
          access latency for a pleasant user experience.<a href="#section-3.4-2" class="pilcrow">¶</a></p>
</section>
<section id="section-3.5">
        <h3 id="name-support-nameless-object">
<a href="#section-3.5" class="section-number selfRef">3.5. </a><a href="#name-support-nameless-object" class="section-name selfRef">Support Nameless Object</a>
        </h3>
<p id="section-3.5-1">
          In CCNx 1.0 <span>[<a href="#Mosko2" class="xref">Mosko2</a>]</span>, the concept of a "Nameless
          Object", which is a Content Object without a name, is introduced to
          provide a means to move content between storage replicas without having
          to rename or re-sign the Content Objects for the new name. Nameless
          Objects can be addressed by the ContentObjectHash, which is to restrict
          Content Object matching by using a SHA-256 hash.<a href="#section-3.5-1" class="pilcrow">¶</a></p>
<p id="section-3.5-2">
          An Interest message would still carry a name and a ContentObjectHash,
          where a name is used for routing, while a ContentObjectHash is used
          for matching. However, on the reverse path, if the Content Object's
          name is missing, it is a "Nameless Object" and only matches against the
          ContentObjectHash. Therefore, a consumer needs to resolve the proper name
          and hashes through an outside system, which can be considered as an NRS.<a href="#section-3.5-2" class="pilcrow">¶</a></p>
</section>
<section id="section-3.6">
        <h3 id="name-support-manifest">
<a href="#section-3.6" class="section-number selfRef">3.6. </a><a href="#name-support-manifest" class="section-name selfRef">Support Manifest</a>
        </h3>
<p id="section-3.6-1">
 For collections of data objects that are organized as large and file-like contents <span>[<a href="#I-D.irtf-icnrg-flic" class="xref">FLIC</a>]</span>, manifests are used as data
          structures to transport this information. Thus, manifests may contain
          hash digests of signed Content Objects or other manifests so that large
          Content Objects that represent a large piece of application data can be
          collected by using such a manifest.<a href="#section-3.6-1" class="pilcrow">¶</a></p>
<p id="section-3.6-2">
 In order to request Content Objects, a consumer needs to know a manifest
          root name to acquire the manifest. In the case of File-Like ICN Collections (FLIC), a manifest name
          can be represented by a nameless root manifest so that an outside system
          such as an NRS may be involved to give this information to the consumer.<a href="#section-3.6-2" class="pilcrow">¶</a></p>
</section>
<section id="section-3.7">
        <h3 id="name-support-metadata">
<a href="#section-3.7" class="section-number selfRef">3.7. </a><a href="#name-support-metadata" class="section-name selfRef">Support Metadata</a>
        </h3>
<p id="section-3.7-1">
            When resolving the name of a Content Object, NRS could return a rich
            set of metadata in addition to returning a locator. The metadata
            could include alternative object locations, supported object transfer
            protocol(s), caching policy, security parameters, data format, hash
            of object data, etc. The consumer could use this metadata for the selection
            of object transfer protocol, security mechanism, egress interface, etc.
            An example of how metadata can be used in this way is provided by the
            Networked Object (NEO) ICN architecture <span>[<a href="#NEO" class="xref">NEO</a>]</span>.<a href="#section-3.7-1" class="pilcrow">¶</a></p>
</section>
</section>
<section id="section-4">
      <h2 id="name-design-considerations-for-n">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-design-considerations-for-n" class="section-name selfRef">Design Considerations for NRS in ICN</a>
      </h2>
<p id="section-4-1">
        This section presents the design considerations for NRS in ICN.<a href="#section-4-1" class="pilcrow">¶</a></p>
<div id="res-response">
<section id="section-4.1">
        <h3 id="name-resolution-response-time">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-resolution-response-time" class="section-name selfRef">Resolution Response Time</a>
        </h3>
<p id="section-4.1-1">
            The name resolution process should provide a response within a reasonable amount of time. The response should be either a proper mapping of the name to a copy of the content or an error message stating that no such object exists. If the name resolution does not map to a location, the system may not issue any response, and the client should set a timer when sending a request so as to consider the resolution incomplete when the timer expires.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<p id="section-4.1-2">
            The acceptable response delay could be of the order of a round-trip
            time between the client issuing the request and the NRS servers that provide the response. While this RTT may vary greatly depending on the proximity between the two end points, some upper bound needs to be used.
            Especially in some delay-sensitive scenarios such as industrial Internet and telemedicine, the upper bound of the response delay must be guaranteed.<a href="#section-4.1-2" class="pilcrow">¶</a></p>
<p id="section-4.1-3">
            The response time includes all the steps of the resolution, including potentially a hop-by-hop resolution or a hierarchical forwarding of the resolution request.<a href="#section-4.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-4.2">
        <h3 id="name-response-accuracy">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-response-accuracy" class="section-name selfRef">Response Accuracy</a>
        </h3>
<p id="section-4.2-1">
             An NRS must provide an accurate response -- namely, a proper binding of the requested name (or prefix) with a location. The response can be either a (prefix, location) pair or the actual forwarding of a request to a node holding the content, which is then transmitted in return.<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<p id="section-4.2-2">
             An NRS must provide an up-to-date response -- namely, an NRS should be updated within a reasonable time when new copies of the content are being stored in the network. While every transient cache addition/eviction should not trigger an NRS update, some origin servers may move and require the NRS to be updated.<a href="#section-4.2-2" class="pilcrow">¶</a></p>
<p id="section-4.2-3">
             An NRS must provide mechanisms to update the mapping of the content with its location. Namely, an NRS must provide a mechanism for a content provider to add new content, revoke old/dated/obsolete content, and modify existing content. Any content update should then be propagated through
 the NRS system within reasonable delay.<a href="#section-4.2-3" class="pilcrow">¶</a></p>
<p id="section-4.2-4">
             Content that is highly mobile may require specifying some type of anchor that is kept at the NRS instead of the content location.<a href="#section-4.2-4" class="pilcrow">¶</a></p>
</section>
<section id="section-4.3">
        <h3 id="name-resolution-guarantee">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-resolution-guarantee" class="section-name selfRef">Resolution Guarantee</a>
        </h3>
<p id="section-4.3-1">
             An NRS must ensure that the name resolution is successful
             with high probability if the name-matching content exists in the network,
             regardless of its popularity and the number of cached copies existing in the network.
             Per <a href="#res-response" class="xref">Section 4.1</a>, some resolutions may not occur in a timely manner.
             However, the probability of such an event should be minimized.
             The NRS system may provide a probability (five 9s or
             five sigmas, for instance) that a resolution will be satisfied.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
</section>
<section id="section-4.4">
        <h3 id="name-resolution-fairness">
<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-resolution-fairness" class="section-name selfRef">Resolution Fairness</a>
        </h3>
<p id="section-4.4-1">
             An NRS could provide this service for all content in a fair manner, independently of the specific content properties
             (content producer, content popularity, availability of copies, content format, etc.).
             Fairness may be defined as a per-request delay to complete the NRS steps that is agnostic to the properties of the content itself.
             Fairness may be defined as well as the number of requests answered per unit of time.<a href="#section-4.4-1" class="pilcrow">¶</a></p>
<p id="section-4.4-2">
             However, it is notable that content (or their associated producer) may request a different level of QoS from the network (see <span>[<a href="#RFC9064" class="xref">RFC9064</a>]</span>, for instance),
             and this may include the NRS as well, in which case considerations of fairness may be restricted to content within the same class of service.<a href="#section-4.4-2" class="pilcrow">¶</a></p>
</section>
<section id="section-4.5">
        <h3 id="name-scalability">
<a href="#section-4.5" class="section-number selfRef">4.5. </a><a href="#name-scalability" class="section-name selfRef">Scalability</a>
        </h3>
<p id="section-4.5-1">
             The NRS system must scale up to support a very large user population (including human users as well as machine-to-machine communications).
             As an idea of the scale, it is expected that 50 billion devices will be connected in 2025 (per ITU projections).
             The system must be able to respond to a very large number of requests per unit of time.
             Message forwarding and processing, routing table buildup, and name record propagation must be efficient and scalable.<a href="#section-4.5-1" class="pilcrow">¶</a></p>
<p id="section-4.5-2">
             The NRS system must scale up with the number of pieces of content (content names) and should be able to support a content catalog that is extremely large.
             Internet traffic is of the order of zettabytes per year (10<sup>21</sup> bytes). Since NRS is associated with actual traffic,
             the number of pieces of content should scale with the amount of traffic. Content size may vary from a few bytes to several GB,
             so the NRS should be expected scale up to a catalog of the size of 10<sup>21</sup> in the near future, and larger beyond.<a href="#section-4.5-2" class="pilcrow">¶</a></p>
<p id="section-4.5-3">
             The NRS system must be able to scale up -- namely, to add NRS servers to the NRS system in a way that is transparent to the users.
             The addition of a new server should have a limited negative impact on the other NRS servers
             (or should have a negative impact on only a small subset of the NRS servers).
             The impact of adding new servers may induce some overhead at the other servers to rebuild a hierarchy or to exchange messages to include the new server within the service.
             Further, data may be shared among the new servers for load balancing or tolerance to failure.
             These steps should not disrupt the service provided by the NRS and should improve the quality of the service in the long run.<a href="#section-4.5-3" class="pilcrow">¶</a></p>
<p id="section-4.5-4">
             The NRS system may support access from a heterogeneity of connection methods and devices.
             In particular, the NRS system may support access from constrained devices, and interactions with the NRS system would not be too costly.
             An IoT node, for instance, should be able to access the NRS system as well as a more powerful node.<a href="#section-4.5-4" class="pilcrow">¶</a></p>
<p id="section-4.5-5">
             The NRS system should scale up in its responsiveness to the increased request rate that is expected from applications such as IoT or machine-to-machine (M2M),
             where data is being frequently generated and/or requested.<a href="#section-4.5-5" class="pilcrow">¶</a></p>
</section>
<section id="section-4.6">
        <h3 id="name-manageability">
<a href="#section-4.6" class="section-number selfRef">4.6. </a><a href="#name-manageability" class="section-name selfRef">Manageability</a>
        </h3>
<p id="section-4.6-1">
             The NRS system must be manageable since some parts of the system may grow or shrink dynamically and an NRS system node may be added or deleted frequently.<a href="#section-4.6-1" class="pilcrow">¶</a></p>
<p id="section-4.6-2">
             The NRS system may support an NRS management layer that allows for adding or subtracting NRS nodes.  In order to infer the circumstance, the management layer can measure the network status.<a href="#section-4.6-2" class="pilcrow">¶</a></p>
</section>
<section id="section-4.7">
        <h3 id="name-deployed-system">
<a href="#section-4.7" class="section-number selfRef">4.7. </a><a href="#name-deployed-system" class="section-name selfRef">Deployed System</a>
        </h3>
<p id="section-4.7-1">
             The NRS system must be deployable since deployability is important for a real-world system. The NRS system must be deployable in network edges and cores so that the consumers as well as ICN routers can perform name resolution in a very low latency.<a href="#section-4.7-1" class="pilcrow">¶</a></p>
</section>
<section id="section-4.8">
        <h3 id="name-fault-tolerance">
<a href="#section-4.8" class="section-number selfRef">4.8. </a><a href="#name-fault-tolerance" class="section-name selfRef">Fault Tolerance</a>
        </h3>
<p id="section-4.8-1">
             The NRS system must ensure resiliency in the event of NRS server failures.
             The failure of a small subset of nodes should not impact the NRS performance significantly.<a href="#section-4.8-1" class="pilcrow">¶</a></p>
<p id="section-4.8-2">
             After an NRS server fails, the NRS system must be able to recover and/or restore the name records stored in the NRS server.<a href="#section-4.8-2" class="pilcrow">¶</a></p>
</section>
<div id="sec-priv">
<section id="section-4.9">
        <h3 id="name-security-and-privacy">
<a href="#section-4.9" class="section-number selfRef">4.9. </a><a href="#name-security-and-privacy" class="section-name selfRef">Security and Privacy</a>
        </h3>
<p id="section-4.9-1">
               On utilizing an NRS in ICN, there are some security considerations for the
               NRS servers/nodes and name mapping records stored in the NRS system.
               This subsection describes them.<a href="#section-4.9-1" class="pilcrow">¶</a></p>
<section id="section-4.9.1">
          <h4 id="name-confidentiality">
<a href="#section-4.9.1" class="section-number selfRef">4.9.1. </a><a href="#name-confidentiality" class="section-name selfRef">Confidentiality</a>
          </h4>
<p id="section-4.9.1-1">
                     The name mapping records in the NRS system must be assigned with
                     proper access rights such that the information contained in the name
                     mapping records would not be revealed to unauthorized users.<a href="#section-4.9.1-1" class="pilcrow">¶</a></p>
<p id="section-4.9.1-2">
                     The NRS system may support access control for certain name mapping
                     records. Access control can be implemented with a reference monitor
                     that uses client authentication, so only users with appropriate
                     credentials can access these records, and they are not shared with
                     unauthorized users. Access control can also be implemented by
                     encryption-based techniques using control of keys to control the
                     propagations of the mappings.<a href="#section-4.9.1-2" class="pilcrow">¶</a></p>
<p id="section-4.9.1-3">
                     The NRS system may support obfuscation and/or encryption
                     mechanisms so that the content of a resolution request
                     may not be accessible by third parties outside of the NRS system.<a href="#section-4.9.1-3" class="pilcrow">¶</a></p>
<p id="section-4.9.1-4">
                     The NRS system must keep confidentiality to prevent
                     sensitive name mapping records from being reached by
                     unauthorized data requesters. This is more required
                     in IoT environments where a lot of sensitive data is produced.<a href="#section-4.9.1-4" class="pilcrow">¶</a></p>
<p id="section-4.9.1-5">
                     The NRS system must also keep confidentiality of metadata
                     as well as NRS usage to protect the privacy of the users.
                     For instance, a specific user's NRS requests should
                     not be shared outside the NRS system (with the exception
                     of legal intercept).<a href="#section-4.9.1-5" class="pilcrow">¶</a></p>
</section>
<section id="section-4.9.2">
          <h4 id="name-authentication">
<a href="#section-4.9.2" class="section-number selfRef">4.9.2. </a><a href="#name-authentication" class="section-name selfRef">Authentication</a>
          </h4>
<ul class="normal">
<li class="normal" id="section-4.9.2-1.1">
                             NRS server authentication: Authentication of the new NRS
                             servers/nodes that want to be registered with the NRS system
                             must be required so that only authenticated entities can
                             store and update name mapping records. The NRS system should
                             detect an attacker attempting to act as a fake NRS server
                             to cause service disruption or manipulate name mapping records.<a href="#section-4.9.2-1.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.9.2-1.2">
                             Producer authentication: The NRS system must support
                             authentication of the content producers to ensure that
                             update/addition/removal of name mapping records requested
                             by content producers are actually valid and that content
                             producers are authorized to modify (or revoke) these records
                             or add new records.<a href="#section-4.9.2-1.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.9.2-1.3">
                             Mapping record authentication: The NRS should verify new
                             mapping records that are being registered so that it cannot
                             be polluted with falsified information or invalid records.<a href="#section-4.9.2-1.3" class="pilcrow">¶</a>
</li>
          </ul>
</section>
<section id="section-4.9.3">
          <h4 id="name-integrity">
<a href="#section-4.9.3" class="section-number selfRef">4.9.3. </a><a href="#name-integrity" class="section-name selfRef">Integrity</a>
          </h4>
<p id="section-4.9.3-1">
                     The NRS system must be protected from malicious users
                     attempting to hijack or corrupt the name mapping records.<a href="#section-4.9.3-1" class="pilcrow">¶</a></p>
</section>
<section id="section-4.9.4">
          <h4 id="name-resiliency-and-availability">
<a href="#section-4.9.4" class="section-number selfRef">4.9.4. </a><a href="#name-resiliency-and-availability" class="section-name selfRef">Resiliency and Availability</a>
          </h4>
<p id="section-4.9.4-1">
                     The NRS system should be resilient against denial-of-service attacks
                     and other common attacks to isolate the impact of the attacks and
                     prevent collateral damage to the entire system. Therefore, if a
                     part of the NRS system fails, the failure should only affect a local
                     domain. And fast recovery mechanisms need to be in place to bring
                     the service back to normal.<a href="#section-4.9.4-1" class="pilcrow">¶</a></p>
</section>
</section>
</div>
</section>
<section id="section-5">
      <h2 id="name-conclusion">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-conclusion" class="section-name selfRef">Conclusion</a>
      </h2>
<p id="section-5-1">
    ICN routing may comprise three steps: name resolution, content request routing,
    and content delivery. This document investigates the name resolution step,
    which is the first and most important to be achieved for ICN routing to be
    successful. A Name Resolution Service (NRS) in ICN is defined as the service
    that provides such a function of name resolution for translating an object
    name into some other information such as a locator, another name, metadata,
    next-hop info, etc. that is used for forwarding the object request.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">
    This document classifies and analyzes the NRS approaches according to whether
    the name resolution step is separated from the content request routing as an
    explicit process or not. This document also explains the NRS functions used
    to support heterogeneous name types, producer mobility, scalable routing system,
    off-path caching, nameless object, manifest, and metadata. Finally, this document
    presents design considerations for NRS in ICN, which include resolution response
    time and accuracy, resolution guarantee, resolution fairness, scalability,
    manageability, deployed system, and fault tolerance.<a href="#section-5-2" class="pilcrow">¶</a></p>
</section>
<div id="IANA">
<section id="section-6">
      <h2 id="name-iana-considerations">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-6-1">This document has no IANA actions.<a href="#section-6-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-7">
      <h2 id="name-security-considerations">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-7-1">
        A discussion of security guidelines is provided in <a href="#sec-priv" class="xref">Section 4.9</a>.<a href="#section-7-1" class="pilcrow">¶</a></p>
</section>
<section id="section-8">
      <h2 id="name-references">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-8.1">
        <h3 id="name-normative-references">
<a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC7927">[RFC7927]</dt>
      <dd>
<span class="refAuthor">Kutscher, D., Ed.</span>, <span class="refAuthor">Eum, S.</span>, <span class="refAuthor">Pentikousis, K.</span>, <span class="refAuthor">Psaras, I.</span>, <span class="refAuthor">Corujo, D.</span>, <span class="refAuthor">Saucez, D.</span>, <span class="refAuthor">Schmidt, T.</span>, and <span class="refAuthor">M. Waehlisch</span>, <span class="refTitle">"Information-Centric Networking (ICN) Research Challenges"</span>, <span class="seriesInfo">RFC 7927</span>, <span class="seriesInfo">DOI 10.17487/RFC7927</span>, <time datetime="2016-07" class="refDate">July 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7927">https://www.rfc-editor.org/info/rfc7927</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-8.2">
        <h3 id="name-informative-references">
<a href="#section-8.2" class="section-number selfRef">8.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="Afanasyev">[Afanasyev]</dt>
        <dd>
<span class="refAuthor">Afanasyev, A. et al.</span>, <span class="refTitle">"SNAMP: Secure Namespace Mapping to Scale NDN Forwarding"</span>, <span class="refContent">2015 IEEE Conference on Computer Communications Workshops </span>, <span class="seriesInfo">DOI 10.1109/INFCOMW.2015.7179398</span>, <time datetime="2015-04" class="refDate">April 2015</time>, <span>&lt;<a href="https://doi.org/10.1109/INFCOMW.2015.7179398">https://doi.org/10.1109/INFCOMW.2015.7179398</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Ahlgren">[Ahlgren]</dt>
        <dd>
<span class="refAuthor">Ahlgren, B.</span>, <span class="refAuthor">Dannewitz, C.</span>, <span class="refAuthor">Imbrenda, C.</span>, <span class="refAuthor">Kutscher, D.</span>, and <span class="refAuthor">B. Ohlman</span>, <span class="refTitle">"A Survey of Information-Centric Networking"</span>, <span class="refContent">IEEE Communications Magazine, Vol. 50, Issue 7</span>, <span class="seriesInfo">DOI 10.1109/MCOM.2012.6231276</span>, <time datetime="2012-07" class="refDate">July 2012</time>, <span>&lt;<a href="https://doi.org/10.1109/MCOM.2012.6231276">https://doi.org/10.1109/MCOM.2012.6231276</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Amadeo">[Amadeo]</dt>
        <dd>
<span class="refAuthor">Amadeo, M.</span>, <span class="refAuthor">Campolo, C.</span>, <span class="refAuthor">Iera, A.</span>, and <span class="refAuthor">A. Molinaro</span>, <span class="refTitle">"Named data networking for IoT: An architectural perspective"</span>, <span class="refContent">European Conference on Networks and Communications (EuCNC)</span>, <span class="seriesInfo">DOI 10.1109/EuCNC.2014.6882665</span>, <time datetime="2014-06" class="refDate">June 2014</time>, <span>&lt;<a href="https://doi.org/10.1109/EuCNC.2014.6882665">https://doi.org/10.1109/EuCNC.2014.6882665</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Amadeo2">[Amadeo2]</dt>
        <dd>
<span class="refAuthor">Amadeo, M. et al.</span>, <span class="refTitle">"Information-centric networking for the internet of things: challenges and opportunities"</span>, <span class="refContent">IEEE Network, Vol. 30, No. 2</span>, <span class="seriesInfo">DOI 10.1109/MNET.2016.7437030</span>, <time datetime="2016-03" class="refDate">March 2016</time>, <span>&lt;<a href="https://doi.org/10.1109/MNET.2016.7437030">https://doi.org/10.1109/MNET.2016.7437030</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Baccelli">[Baccelli]</dt>
        <dd>
<span class="refAuthor">Baccelli, E.</span>, <span class="refAuthor">Mehlis, C.</span>, <span class="refAuthor">Hahm, O.</span>, <span class="refAuthor">Schmidt, T.</span>, and <span class="refAuthor">M. Wählisch</span>, <span class="refTitle">"Information Centric Networking in the IoT: Experiments with NDN in the Wild"</span>, <span class="refContent">ACM-ICN 2014</span>, <span class="seriesInfo">DOI 10.1145/2660129.2660144</span>, <time datetime="2014" class="refDate">2014</time>, <span>&lt;<a href="https://doi.org/10.1145/2660129.2660144">https://doi.org/10.1145/2660129.2660144</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Bari">[Bari]</dt>
        <dd>
<span class="refAuthor">Bari, M.F.</span>, <span class="refAuthor">Chowdhury, S.R.</span>, <span class="refAuthor">Ahmed, R.</span>, <span class="refAuthor">Boutaba, R.</span>, and <span class="refAuthor">B. Mathieu</span>, <span class="refTitle">"A Survey of Naming and Routing in Information-Centric Networks"</span>, <span class="refContent">IEEE Communications Magazine, Vol. 50, No. 12, pp. 44-53</span>, <span class="seriesInfo">DOI 10.1109/MCOM.2012.6384450</span>, <time datetime="2012-12" class="refDate">December 2012</time>, <span>&lt;<a href="https://doi.org/10.1109/MCOM.2012.6384450">https://doi.org/10.1109/MCOM.2012.6384450</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Bayhan">[Bayhan]</dt>
        <dd>
<span class="refAuthor">Bayhan, S. et al.</span>, <span class="refTitle">"On Content Indexing for Off-Path Caching in Information-Centric Networks"</span>, <span class="refContent">ACM-ICN 2016</span>, <span class="seriesInfo">DOI 10.1145/2984356.2984372</span>, <time datetime="2016-09" class="refDate">September 2016</time>, <span>&lt;<a href="https://doi.org/10.1145/2984356.2984372">https://doi.org/10.1145/2984356.2984372</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="CCNx">[CCNx]</dt>
        <dd>
<span class="refTitle">"CICN"</span>, <span>&lt;<a href="https://wiki.fd.io/view/Cicn">https://wiki.fd.io/view/Cicn</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Dannewitz">[Dannewitz]</dt>
        <dd>
<span class="refAuthor">Dannewitz, C. et al.</span>, <span class="refTitle">"Network of Information (NetInf) - An information-centric networking architecture"</span>, <span class="refContent">Computer Communications, Vol. 36, Issue 7</span>, <span class="seriesInfo">DOI 10.1016/j.comcom.2013.01.009</span>, <time datetime="2013-04" class="refDate">April 2013</time>, <span>&lt;<a href="https://doi.org/10.1016/j.comcom.2013.01.009">https://doi.org/10.1016/j.comcom.2013.01.009</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.irtf-icnrg-flic">[FLIC]</dt>
        <dd>
<span class="refAuthor">Tschudin, C.</span>, <span class="refAuthor">Wood, C. A.</span>, <span class="refAuthor">Mosko, M.</span>, and <span class="refAuthor">D. Oran</span>, <span class="refTitle">"File-Like ICN Collections (FLIC)"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-irtf-icnrg-flic-03</span>, <time datetime="2021-11-07" class="refDate">7 November 2021</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-flic-03">https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-flic-03</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.irtf-icnrg-icniot">[ID.Zhang2]</dt>
        <dd>
<span class="refAuthor">Ravindran, R.</span>, <span class="refAuthor">Zhang, Y.</span>, <span class="refAuthor">Grieco, L. A.</span>, <span class="refAuthor">Lindgren, A.</span>, <span class="refAuthor">Burke, J.</span>, <span class="refAuthor">Ahlgren, B.</span>, and <span class="refAuthor">A. Azgin</span>, <span class="refTitle">"Design Considerations for Applying ICN to IoT"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-irtf-icnrg-icniot-03</span>, <time datetime="2019-05-02" class="refDate">2 May 2019</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-icniot-03">https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-icniot-03</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Jung">[Jung]</dt>
        <dd>
<span class="refAuthor">Jung, H. et al.</span>, <span class="refTitle">"IDNet: Beyond All-IP Network"</span>, <span class="refContent">ETRI Journal, Vol. 37, Issue 5</span>, <span class="seriesInfo">DOI 10.4218/etrij.15.2415.0045</span>, <time datetime="2015-10" class="refDate">October 2015</time>, <span>&lt;<a href="https://doi.org/10.4218/etrij.15.2415.0045">https://doi.org/10.4218/etrij.15.2415.0045</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Koponen">[Koponen]</dt>
        <dd>
<span class="refAuthor">Koponen, T.</span>, <span class="refAuthor">Chawla, M.</span>, <span class="refAuthor">Chun, B.</span>, <span class="refAuthor">Ermolinskiy, A.</span>, <span class="refAuthor">Kim, K.H.</span>, <span class="refAuthor">Shenker, S.</span>, and <span class="refAuthor">I. Stoica</span>, <span class="refTitle">"A Data-Oriented (and Beyond) Network Architecture"</span>, <span class="refContent">ACM SIGCOMM 2007, pp. 181-192 </span>, <span class="seriesInfo">DOI 10.1145/1282380.1282402</span>, <time datetime="2007-08" class="refDate">August 2007</time>, <span>&lt;<a href="https://doi.org/10.1145/1282380.1282402">https://doi.org/10.1145/1282380.1282402</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="MF">[MF]</dt>
        <dd>
<span class="refTitle">"MobilityFirst Future Internet Architecture Project Overview"</span>, <span>&lt;<a href="http://mobilityfirst.winlab.rutgers.edu">http://mobilityfirst.winlab.rutgers.edu</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Mosko2">[Mosko2]</dt>
        <dd>
<span class="refAuthor">Mosko, M.</span>, <span class="refTitle">"Nameless Objects"</span>, <span class="refContent">IRTF ICNRG</span>, <time datetime="2016-01" class="refDate">January 2016</time>, <span>&lt;<a href="https://datatracker.ietf.org/meeting/interim-2016-icnrg-01/materials/slides-interim-2016-icnrg-1-7.pdf">https://datatracker.ietf.org/meeting/interim-2016-icnrg-01/materials/slides-interim-2016-icnrg-1-7.pdf</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="NDN">[NDN]</dt>
        <dd>
<span class="refTitle">"Named Data Networking"</span>, <span>&lt;<a href="http://www.named-data.net">http://www.named-data.net</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="NEO">[NEO]</dt>
        <dd>
<span class="refAuthor">Eriksson, A.</span> and <span class="refAuthor">A.M. Malik</span>, <span class="refTitle">"A DNS-based information-centric network architecture open to multiple protocols for transfer of data objects"</span>, <span class="refContent">21st Conference on Innovation in Clouds, Internet and Networks and Workshops (ICIN), pp. 1-8</span>, <span class="seriesInfo">DOI 10.1109/ICIN.2018.8401595</span>, <time datetime="2018-02" class="refDate">February 2018</time>, <span>&lt;<a href="https://doi.org/10.1109/ICIN.2018.8401595">https://doi.org/10.1109/ICIN.2018.8401595</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.irtf-icnrg-nrsarch-considerations">[NRSarch]</dt>
        <dd>
<span class="refAuthor">Hong, J.</span>, <span class="refAuthor">You, T.</span>, and <span class="refAuthor">V. Kafle</span>, <span class="refTitle">"Architectural Considerations of ICN using Name Resolution Service"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-irtf-icnrg-nrsarch-considerations-06</span>, <time datetime="2021-02-12" class="refDate">12 February 2021</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-nrsarch-considerations-06">https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-nrsarch-considerations-06</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="PURSUIT">[PURSUIT]</dt>
        <dd>
<span class="refTitle">"FP7 PURSUIT"</span>, <span>&lt;<a href="https://www.fp7-pursuit.eu/">https://www.fp7-pursuit.eu/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Quevedo">[Quevedo]</dt>
        <dd>
<span class="refAuthor">Quevedo, J.</span>, <span class="refAuthor">Corujo, D.</span>, and <span class="refAuthor">R. Aguiar</span>, <span class="refTitle">"A case for ICN usage in IoT environments"</span>, <span class="refContent">IEEE GLOBECOM</span>, <span class="seriesInfo">DOI GLOCOM.2014.7037227</span>, <time datetime="2014-12" class="refDate">December 2014</time>, <span>&lt;<a href="https://doi.org/GLOCOM.2014.7037227">https://doi.org/GLOCOM.2014.7037227</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ravi-icnrg-ccn-forwarding-label">[Ravindran]</dt>
        <dd>
<span class="refAuthor">Ravindran, R.</span>, <span class="refAuthor">Chakraborti, A.</span>, and <span class="refAuthor">A. Azgin</span>, <span class="refTitle">"Forwarding Label support in CCN Protocol"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ravi-icnrg-ccn-forwarding-label-02</span>, <time datetime="2018-03-05" class="refDate">5 March 2018</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ravi-icnrg-ccn-forwarding-label-02">https://datatracker.ietf.org/doc/html/draft-ravi-icnrg-ccn-forwarding-label-02</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>, and <span class="refAuthor">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="RFC8569">[RFC8569]</dt>
        <dd>
<span class="refAuthor">Mosko, M.</span>, <span class="refAuthor">Solis, I.</span>, and <span class="refAuthor">C. Wood</span>, <span class="refTitle">"Content-Centric Networking (CCNx) Semantics"</span>, <span class="seriesInfo">RFC 8569</span>, <span class="seriesInfo">DOI 10.17487/RFC8569</span>, <time datetime="2019-07" class="refDate">July 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8569">https://www.rfc-editor.org/info/rfc8569</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9064">[RFC9064]</dt>
        <dd>
<span class="refAuthor">Oran, D.</span>, <span class="refTitle">"Considerations in the Development of a QoS Architecture for CCNx-Like Information-Centric Networking Protocols"</span>, <span class="seriesInfo">RFC 9064</span>, <span class="seriesInfo">DOI 10.17487/RFC9064</span>, <time datetime="2021-06" class="refDate">June 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9064">https://www.rfc-editor.org/info/rfc9064</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="SA2-5GLAN">[SA2-5GLAN]</dt>
        <dd>
<span class="refAuthor">3GPP</span>, <span class="refTitle">"New WID: 5GS Enhanced support of Vertical and LAN Services"</span>, <span class="refContent">TSG SA Meeting #SP-82</span>, <time datetime="2018-12" class="refDate">December 2018</time>, <span>&lt;<a href="http://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_82/Docs/SP-181120.zip">http://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_82/Docs/SP-181120.zip</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="SAIL">[SAIL]</dt>
        <dd>
<span class="refTitle">"Scalable and Adaptive Internet Solutions (SAIL)"</span>, <span>&lt;<a href="http://www.sail-project.eu/">http://www.sail-project.eu/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Westphal">[Westphal]</dt>
        <dd>
<span class="refAuthor">Westphal, C.</span> and <span class="refAuthor">E. Demirors</span>, <span class="refTitle">"An IP-Based Manifest Architecture for ICN"</span>, <span class="refContent">ACM-ICN 2015</span>, <span class="seriesInfo">DOI 10.1145/2810156.2812614</span>, <time datetime="2015-09" class="refDate">September 2015</time>, <span>&lt;<a href="https://doi.org/10.1145/2810156.2812614">https://doi.org/10.1145/2810156.2812614</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Xylomenos">[Xylomenos]</dt>
        <dd>
<span class="refAuthor">Xylomenos, G.</span>, <span class="refAuthor">Ververidis, C.</span>, <span class="refAuthor">Siris, V.</span>, <span class="refAuthor">Fotiou, N.</span>, <span class="refAuthor">Tsilopoulos, C.</span>, <span class="refAuthor">Vasilakos, X.</span>, <span class="refAuthor">Katsaros, K.</span>, and <span class="refAuthor">G. Polyzos</span>, <span class="refTitle">"A Survey of Information-Centric Networking Research"</span>, <span class="refContent">IEEE Communications Surveys and Tutorials, Vol. 16, Issue 2</span>, <span class="seriesInfo">DOI 10.1109/SURV.2013.070813.00063</span>, <time datetime="2014" class="refDate">2014</time>, <span>&lt;<a href="https://doi.org/10.1109/SURV.2013.070813.00063">https://doi.org/10.1109/SURV.2013.070813.00063</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Zhang2">[Zhang2]</dt>
      <dd>
<span class="refAuthor">Zhang, Y. et al.</span>, <span class="refTitle">"A Survey of Mobility Support in Named Data Networking"</span>, <span class="refContent">IEEE Conference on Computer Communications Workshops</span>, <span class="seriesInfo">DOI 10.1109/INFCOMW.2016.7562050</span>, <time datetime="2016-04" class="refDate">April 2016</time>, <span>&lt;<a href="https://doi.org/10.1109/INFCOMW.2016.7562050">https://doi.org/10.1109/INFCOMW.2016.7562050</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="Acknowledgments">
<section id="appendix-A">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="appendix-A-1">
          The authors would like to thank <span class="contact-name">Dave Oran</span>, <span class="contact-name">Dirk Kutscher</span>, <span class="contact-name">Ved Kafle</span>, <span class="contact-name">Vincent Roca</span>, <span class="contact-name">Marie-Jose Montpetit</span>, <span class="contact-name">Stephen Farrell</span>, <span class="contact-name">Mirja Kühlewind</span>,
          and <span class="contact-name">Colin Perkins</span> for very useful reviews, comments, and improvements
          to the document.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="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">Jungha Hong</span></div>
<div dir="auto" class="left"><span class="org">ETRI</span></div>
<div dir="auto" class="left"><span class="extended-address">Yuseung-Gu</span></div>
<div dir="auto" class="left"><span class="street-address">218 Gajeong-ro</span></div>
<div dir="auto" class="left"><span class="locality">Daejeon</span></div>
<div dir="auto" class="left"><span class="postal-code">34129</span></div>
<div dir="auto" class="left"><span class="country-name">Republic of Korea</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:jhong@etri.re.kr" class="email">jhong@etri.re.kr</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Tae-Wan You</span></div>
<div dir="auto" class="left"><span class="org">ETRI</span></div>
<div dir="auto" class="left"><span class="extended-address">Yuseung-Gu</span></div>
<div dir="auto" class="left"><span class="street-address">218 Gajeong-ro</span></div>
<div dir="auto" class="left"><span class="locality">Daejeon</span></div>
<div dir="auto" class="left"><span class="postal-code">34129</span></div>
<div dir="auto" class="left"><span class="country-name">Republic of Korea</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:twyou@etri.re.kr" class="email">twyou@etri.re.kr</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Lijun Dong</span></div>
<div dir="auto" class="left"><span class="org">Futurewei Technologies Inc.</span></div>
<div dir="auto" class="left"><span class="street-address">10180 Telesis Court</span></div>
<div dir="auto" class="left">
<span class="locality">San Diego</span>, <span class="region">CA</span> <span class="postal-code">92121</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:lijun.dong@futurewei.com" class="email">lijun.dong@futurewei.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Cedric Westphal</span></div>
<div dir="auto" class="left"><span class="org">Futurewei Technologies Inc.</span></div>
<div dir="auto" class="left"><span class="street-address">2330 Central Expressway</span></div>
<div dir="auto" class="left">
<span class="locality">Santa Clara</span>, <span class="region">CA</span> <span class="postal-code">95050</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:cedric.westphal@futurewei.com" class="email">cedric.westphal@futurewei.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Börje Ohlman</span></div>
<div dir="auto" class="left"><span class="org">Ericsson Research</span></div>
<div dir="auto" class="left">SE-<span class="postal-code">16480</span> <span class="locality">Stockholm</span>
</div>
<div dir="auto" class="left"><span class="country-name">Sweden</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:Borje.Ohlman@ericsson.com" class="email">Borje.Ohlman@ericsson.com</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>