<?xml version="1.0" encoding="US-ASCII"?> encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY rfc1498 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1498.xml"> nbsp    "&#160;">
  <!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"> zwsp   "&#8203;">
  <!ENTITY rfc2460 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml"> nbhy   "&#8209;">
  <!ENTITY rfc4919 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4919.xml">
<!ENTITY rfc4944 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4944.xml">
<!ENTITY rfc5826 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5826.xml">
<!ENTITY rfc6282 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6282.xml">
<!ENTITY rfc6568 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6568.xml">
  <!ENTITY rfc6775 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6775.xml">
  <!ENTITY rfc6830 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6830.xml">
  <!ENTITY rfc6833 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6833.xml">
  <!ENTITY rfc7252 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7252.xml">
<!ENTITY rfc7228 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7228.xml">
<!ENTITY rfc7428 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7428.xml">
<!ENTITY rfc7668 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7668.xml">
<!ENTITY rfc7927 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7927.xml"> wj     "&#8288;">
]>

<rfc category="info" xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-irtf-icnrg-nrs-requirements-06" ipr="trust200902">

  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
  <!-- used by XSLT processors -->
  <!-- For a complete list and description of processing instructions (PIs),
   please see http://xml.resource.org/authoring/README.html. --> number="9138" ipr="trust200902" obsoletes="" updates="" submissionType="IRTF" category="info" consensus="true" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">

  <!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
   (Here they are set differently than their defaults in xml2rfc v1.32) -->
  <?rfc strict="yes" ?>
  <!-- give errors regarding ID-nits and DTD validation -->
  <!-- control the table of contents (ToC) -->
  <?rfc toc="yes"?>
  <!-- generate a ToC -->
  <?rfc tocdepth="4"?>
  <!-- the number of levels of subsections in ToC. default: 3 -->
  <!-- control references -->
  <?rfc symrefs="yes"?>
  <!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
  <?rfc sortrefs="no" ?>
  <!-- sort the reference entries alphabetically -->
  <!-- control vertical white space
   (using these PIs as follows is recommended by the RFC Editor) -->
  <?rfc compact="no" ?>
  <!-- do not start each<ul><li></li></ul><ul><li></li></ul> main section on a new page -->
  <?rfc subcompact="no" ?>
  <!-- keep one blank line between list items -->
  <!-- end of list of popular I-D processing instructions -->

  <!-- ***** FRONT MATTER ***** v2v3 conversion 3.9.1 -->
  <front>
      <!-- The abbreviated title is used in the page header - it is only necessary if the
       full title is longer than 39 characters -->
    <title abbrev="Design Considerations for NRS">Design Considerations for Name Resolution Service in ICN</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->
    <!-- Another author who claims to be an editor --> Information-Centric Networking (ICN)</title>
    <seriesInfo name="RFC" value="9138"/>
    <author fullname="Jungha Hong" initials="J." surname="Hong">
      <organization>ETRI</organization>
      <address>
        <postal>
	  <extaddr>Yuseung-Gu</extaddr>
          <street>218 Gajeong-ro, Yuseung-Gu</street>
                <!-- Reorder these if your country does things differently --> Gajeong-ro</street>
          <city>Daejeon</city>
                <region></region>
          <code>34129</code>
                <country>Korea</country>
          <country>Republic of Korea</country>
        </postal>
            <phone></phone>
        <email>jhong@etri.re.kr</email>
            <!-- uri and facsimile elements may also be added -->
        </address>
    </author>
    <author fullname="Tae-Wan You" initials="T." surname="You">
      <organization>ETRI</organization>
      <address>
        <postal>
	  <extaddr>Yuseung-Gu</extaddr>
          <street>218 Gajeong-ro, Yuseung-Gu</street>
                <!-- Reorder these if your country does things differently --> Gajeong-ro</street>
          <city>Daejeon</city>
                <region></region>
          <code>34129</code>
                <country>Korea</country>
          <country>Republic of Korea</country>
        </postal>
            <phone></phone>
        <email>twyou@etri.re.kr</email>
            <!-- uri and facsimile elements may also be added -->
        </address>
    </author>
    <author fullname="Lijun Dong" initials="L." surname="Dong">
      <organization>Futurewei Technologies Inc.</organization>
      <address>
        <postal>
          <street>10180 Telesis Court</street>
                <!-- Reorder these if your country does things differently -->
          <city>San Diego</city>
          <region>CA</region>
          <code>92121</code>
                <country>USA</country>
          <country>United States of America</country>
        </postal>
            <phone></phone>
        <email>lijun.dong@futurewei.com</email>
            <!-- uri and facsimile elements may also be added -->
        </address>
    </author>
    <author fullname="Cedric Westphal" initials="C." surname="Westphal">
      <organization>Futurewei Technologies Inc.</organization>
      <address>
        <postal>
          <street>2330 Central Expressway</street>
                <!-- Reorder these if your country does things differently -->
          <city>Santa Clara</city>
          <region>CA</region>
          <code>95050</code>
                <country>USA</country>
          <country>United States of America</country>
        </postal>
            <phone></phone>
        <email>cedric.westphal@futurewei.com</email>
            <!-- uri and facsimile elements may also be added -->
        </address>
    </author>
    <author fullname="Borje fullname="Börje Ohlman" initials="B." surname="Ohlman">
      <organization abbrev="Ericsson">Ericsson Research</organization>
      <address>
        <postal>
                <street>S-16480 Stockholm</street>
                <!-- Reorder these if your country does things differently -->
                <city></city>
                <region></region>
                <code></code>
          <city>Stockholm</city>
          <code>16480</code>
          <country>Sweden</country>
        </postal>
            <phone></phone>
        <email>Borje.Ohlman@ericsson.com</email>
            <!-- uri and facsimile elements may also be added -->
        </address>
    </author>
    <date day="28" month="July" year="2021" />
    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill
     in the current day for you. If only the current year is specified, xml2rfc will fill
	 in the current day and month for you. If the year is not the current one, it is
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to
	 specify just the year. -->

    <!-- Meta-data Declarations --> month="November" year="2021"/>

    <area>ICNRG</area>

    <workgroup>ICN Research Group</workgroup>

    <!-- WG name at the upperleft corner of the doc,
     IETF is fine for individual submissions.
	 If this element is not present, the default is "Network Working Group",
     which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>Internet Draft</keyword>

    <!-- Keywords will be incorporated into HTML output
     files in a meta tag but they have no effect on text or nroff
     output. If you submit your draft to the RFC Editor, the
     keywords will be used for the search engine. -->
    <workgroup>Information-Centric Networking</workgroup>
    <abstract>
      <t>
        This document provides the functionalities and design considerations
        for a Name Resolution Service (NRS) in ICN.  An 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. for forwarding in order to forward the object request. This document is a product
        of the Information-Centric Networking Research Group (ICNRG).
      </t>
    </abstract>

  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>
          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 Information-Centric Networking (ICN) are the named data
          objects (NDOs) (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, scale and has been identified and acknowledged as a
          promising technology for a future Internet architecture to overcome
          the limitations of the current Internet Internet, such as scalability and
          mobility <xref target="Ahlgren"></xref> target="Ahlgren" format="default"/> <xref target="Xylomenos"></xref>. target="Xylomenos" format="default"/>.
          ICN also has emerged as a candidate architecture in the IoT Internet of Things (IoT) environment
          since IoT focuses on data and information
          <xref target="Baccelli"></xref> target="Baccelli" format="default"/> <xref target="Amadeo"></xref> target="Amadeo" format="default"/> <xref target="Quevedo"></xref> target="Quevedo" format="default"/>
        <xref target="Amadeo2"></xref> target="Amadeo2" format="default"/> <xref target="ID.Zhang2"></xref>. target="I-D.irtf-icnrg-icniot" format="default"/>.
      </t>
      <t>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 <xref target="RFC7927"></xref>: target="RFC7927" format="default"/>:
      </t>

				<t>
							<list style="symbols">
								<t>Name

      <ol type="(%d)" spacing="normal">
        <li>Name resolution: matches/translates a content name to the locator
                  of the content producer or source that can provide the content. </t>
								<t>Content </li>
        <li>Content request routing: routes the content request towards
                  the content's location either based either on its name or locator. </t>
								<t>Content </li>
        <li>Content delivery: transfers the content to the requester. </t>
							</list>
				</t> </li>
      </ol>
      <t>
          Among the three steps of ICN routing, this document investigates only
          the name resolution step 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.
      </t>
      <t>
          The focus of this document is a Name Resolution Service (NRS) itself
          as a service or a system in ICN 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
          <xref target="NRSarch"></xref> target="I-D.irtf-icnrg-nrsarch-considerations" format="default"/> describes considerations from the perspective
          of the ICN architecture and routing system when using an NRS in ICN.
      </t>
      <t>
          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.
      </t>
    </section>

<!--
    <section title="Conventions and Terminology">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119"></xref>.</t>
    </section>
-->
    <section title="Name numbered="true" toc="default">
      <name>Name Resolution Service in ICN"> ICN</name>
      <t>
          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
          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 to reach a specific piece of information
          (or named data object). The consumer provides an NRS with a persistent
          name
          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.
      </t>
      <t>
         The name resolution is a necessary process in ICN routing 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 explicit an "explicit name
         resolution approach, approach", and the latter is referred to as name-based a "name-based routing approach approach"
         in this document.
      </t>
      <section title="Explicit name resolution approach"> numbered="true" toc="default">
        <name>Explicit Name Resolution Approach</name>
        <t>
          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 approach, such as DONA  Data-Oriented Network Architecture (DONA) <xref target="Koponen"></xref>, target="Koponen" format="default"/>, PURSUIT <xref target="PURSUIT"></xref>,
          NetInf target="PURSUIT" format="default"/>,
          Network of Information (NetInf) <xref target="SAIL"></xref>, target="SAIL" format="default"/>, MobilityFirst <xref target="MF"></xref>, target="MF" format="default"/>,
          IDNet <xref target="Jung"></xref>, target="Jung" format="default"/>, etc. In addition, the explicit name
          resolution approach has been allowed for 5G control planes <xref target="SA2-5GLAN"></xref>. target="SA2-5GLAN" format="default"/>.
        </t>
      </section>
      <section title="Name-based routing approach"> numbered="true" toc="default">
        <name>Name-Based Routing Approach</name>
        <t>An NRS could take the name-based routing approach, which integrates
            the
            name resolution with the content request message routing as in
            NDN
            Named Data Networking / Content-Centric Networking (NDN/CCNx) <xref target="NDN"></xref>/CCNx target="NDN" format="default"/> <xref target="CCNx"></xref>. target="CCNx" format="default"/>.
        </t>
        <t>
            In the case that 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 on 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, content but also
            properly delivering the data.
        </t>
      </section>
      <section title="Hybrid approach"> numbered="true" toc="default">
        <name>Hybrid Approach</name>
        <t>
            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 around: first by performing
            explicit name resolution first to find the locators of routers. And routers, then
            it can carry out the name-based by routing approach of the client's request. request using the name-based routing approach.
        </t>
        <t>
            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.
        </t>
      </section>
      <section title="Comparisons numbered="true" toc="default">
        <name>Comparisons of name resolution approaches"> Name Resolution Approaches</name>
        <t>
           The following compares the explicit name resolution and the name-based
           routing approaches for in several aspects:
        </t>

 				<t>
 							<list style="symbols">
 								<t>Overhead
        <ul spacing="normal">
          <li>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). </t>
 								<t>Resolution </li>
          <li>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. (i.e., content publishing message and the resulting name-based routing tables).
                  For example, when a content is cached, the router may only notify this information to its direct neighbors. neighbors of this information. Thus, only those neighboring
 routers can build a named based 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. </t>
 								<t>Node </li>

          <li>Node failure impact: Nodes involved in the explicit name resolution approach are the name resolution overlay servers (e.g. Resolution Handlers (e.g., resolution handlers in DONA),
                  while the nodes involved in the name-based routing approach are routers which that route messages based on the name-based routing tables (e.g. (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.</t>
 								<t>Maintained connected.</li>
          <li>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 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.</t>
 							</list>
 				</t> tables.</li>
        </ul>
        <t>Additionally, some other intermediary step may be included in the name resolution, namely resolution -- namely, the mapping of one name to other names, names -- in order to facilitate the retrieval of named content, content by way of a manifest <xref target="Westphal"></xref> target="Westphal" format="default"/> <xref target="Mosko"></xref>. target="RFC8569" format="default"/>.
        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: first become the following: first, translate the manifest name into a location of a copy of the manifest; the manifest manifest, which includes further names of the content components, components and potentially locations for the content.
        The content is content, then retrieved retrieve the content by using these names and/or location, potentially resulting in additional name resolutions. </t>
        <t>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. </t>
      </section>
    </section>
    <section title="Functionalities numbered="true" toc="default">
      <name>Functionalities of NRS in ICN"> ICN</name>
      <t>This section presents the functionalities of an NRS in ICN. </t>
      <section title="Support heterogeneous name types"> numbered="true" toc="default">
        <name>Support Heterogeneous Name Types</name>
        <t>
          In ICN, a name is used to identify the data object and is bound to it <xref target="RFC7927"></xref>. target="RFC7927" format="default"/>.
          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 <xref target="Bari"></xref>. target="Bari" format="default"/>.
          Ideally, a name can include any form of identifier, which can be
          flat or hierarchical, and human readable or non-readable.
        </t>
        <t>
          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 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 attribute based, or
          anything else.
        </t>
        <t>
          In PURSUIT <xref target="PURSUIT"></xref>, target="PURSUIT" format="default"/>, names are flat flat, and the rendezvous
          functions are defined for an NRS, which is implemented by a set of Rendezvous
          Nodes rendezvous
          nodes (RNs), known as the Rendezvous Network rendezvous network (RENE). Thus, a name consists of a
          sequence of scope IDs 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.
        </t>
        <t>
          In MobilityFirst <xref target="MF"></xref>, target="MF" format="default"/>, a name called known as a Global "Global
          Unique IDentifier (GUID) Identifier (GUID)", derived from a human-readable name via a global
          naming service service, is a flat typed 160-bits 160-bit string with self-certifying
          properties. Thus, MobilityFirst defines a Global Name Resolution Service
          (GNRS)
          (GNRS), which resolves GUIDs to network addresses and decouples name
          resolution and data routing similarly to PURSUIT.
        </t>
        <t>
          In NetInf <xref target="Dannewitz"></xref>, target="Dannewitz" format="default"/>, information objects are named using ni-naming Named Information (NI) names <xref target="RFC6920"></xref>, target="RFC6920" format="default"/>, which consist of an authority part and digest part (content hash).
          The ni NI names can be flat as the authority part is optional. Thus, the NetInf architecture also includes a Name Resolution System (NRS) (NRS), which can be used to resolve ni-names NI names to addresses in an underlying routable network layer.
        </t>
        <t>
          In NDN <xref target="NDN"></xref> target="NDN" format="default"/> and CCNx <xref target="CCNx"></xref>, target="CCNx" format="default"/>,
          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).
        </t>

<!--
        <t>  In ICN design, a name is used to identify an entity, such as named data content, a device, an application, a service. ICN requires uniqueness and persistency of the name of any entity to ensure the reachability of the entity within certain scope and with proper authentication and trust guarantees. The name does not change with the mobility and multi-home of the corresponding entity. A client can always use this name to retrieve the content from network and verify the binding of the content and the name. </t>

				<t>Ideally, a name can include any form of identifier, which can be flat, hierarchical, and human readable or non-readable. </t>

				<t>There are heterogeneous content naming schemes <xref target="ID.Zhang"></xref> <xref target="RFC1498"></xref> and name resolution approaches from different ICN architectures. For example: </t>

				<t>
							<list style="symbols">
								<t>Names in DONA <xref target="Koponen"></xref> consist of the cryptographic hash of the principal's public key P and a label L uniquely identifying the information with respect to the principal. Name resolution in DONA is provided by specialized servers called Resolution Handlers (RHs). </t>
								<t>Content in PURSUIT <xref target="PURSUIT"></xref> is identified by a combination of a scope ID and a rendezvous ID. The scope ID represents the boundaries of a defined dissemination strategy for the content it contain. The rendezvous ID is the actual identity for a particular content. Name resolution in PURSUIT is handled by a collection of Rendezvous Nodes (RNs), which are implemented as a hierarchical Dynamic Hash Table (DHT)<xref target="Rajahalme"></xref> <xref target="Katsaros"></xref>. </t>
								<t>Names in NDN <xref target="NDN"></xref> and CCN <xref target="CCN"></xref> are hierarchical and may be similar to URLs. Each name component can be anything, including a dotted human-readable string or a hash value. NDN/CCN adopts the name based routing. The NDN router forwards the request by doing the longest-match lookup in the Forwarding Information Base (FIB) based on the content name name, and the request is
          stored in the Pending Interest Table (PIT).
        </t>
								<t>In MobilityFirst <xref target="MF"></xref>, every network entity, content has a Global Unique Identifier (GUID). GUIDs are flat 160-bit strings with no semantic structure. Name Resolution in MobilityFirst is carried out via a Global Name Resolution Service (GNRS). </t>
							</list>
				</t>

				<t>Although the existing naming schemes are different, they all need to provide basic functions for identifying a content, supporting trust provenance, content lookup and routing. The NRS may combine the advantages of different mechanisms. The NRS should be able to support a generic naming schema to resolve any type of content name, either it is flat or hierarchical. </t>
-->
	     </section>
      <section title="Support producer mobility"> numbered="true" toc="default">
        <name>Support Producer Mobility</name>
        <t>
           ICN natively inherently supports mobility management. 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.
        </t>
        <t>
           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 RIB 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 to adopt 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.
        </t>
        <t>
           In NDN <xref target="Zhang2"></xref>, target="Zhang2" format="default"/>, for producer mobility support, rendezvous mechanisms have been proposed to build interests interest rendezvous
           (RV) with data generated by a mobile producer (MP). This can be
           classified into two approaches: chase mobile producer; 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 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 Interest messages.

Thus,
           a consumer's interest Interest message can be forwarded to stationary place as called data rendezvous, 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.
        </t>
        <t>
          In <xref target="Ravindran"></xref>, forwarding-label target="I-D.ravi-icnrg-ccn-forwarding-label" format="default"/>, the forwarding label (FL) object is
          referred
          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, administrator so that IDs are mapping mapped to
          heterogeneous name schemes and LIDs are mapping 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.
        </t>
        <t>
          In MobilityFirst <xref target="MF"></xref>, target="MF" format="default"/>, both consumer and publisher
          mobility can be primarily handled by the global name resolution service
          (GNRS)
          (GNRS), which resolves GUIDs to network addresses. Thus, the GNRS  must
          be updated for mobility support when a network attached network-attached object changes
          its point of attachment, which differs from NDN/CCNx.
        </t>
        <t>
          In NetInf <xref target="Dannewitz"></xref>, target="Dannewitz" format="default"/>, mobility is handled by
          an NRS in a very similar way to MobilityFirst.
        </t>
        <t>
           Besides the consumer and producer mobility, ICN also has to face 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.
        </t>
<!--
        <t>In ICN literature, it is said that mobility can be achieved in fundamental feature of ICN. Especially, consumer or client mobility can be achieved by requesting information again according to the basic procedure from different interfaces or through attachment point of the new network. Moreover, seamless mobility service in ICN ensures that content reception continues without any disruption in ICN application, so in consumer point of view, seamless mobility can be easily supported. </t>

				<t>However, producer or publisher mobility in ICN is more complicated to be supported. If a producer moves into different authority domain or network location, then the request for a content published by the moving puroducer with origin name would be hardly forwarded to the moving producer since the routing tables related in broad area should be updated according to the producer movement. Therefore, various ICN literatures would adopt NRS to achieve the producer or publisher mobility, where NRS can be implemented in different ways such as rendezvous mechanism, mapping, etc. </t>

				<t>Besides mobility, ICN has challenge to support the dynamism features like multi-homing, migration, and replication of named resources such as content, devices, services, etc. and NRS may help to support the dynamism features. </t>
-->
       </section>
      <section title="Support scalable routing system"> numbered="true" toc="default">
        <name>Support Scalable Routing System</name>
        <t>
           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 Routing Information Base (RIB) RIB and Forwarding Information Base (FIB). FIB.
           Since the number of data objects would be very large, the size of
           information bases would be significantly larger as well <xref target="RFC7927"></xref>. target="RFC7927" format="default"/>.
        </t>
        <t>
           The hierarchical namespace used in CCNx <xref target="CCNx"></xref> target="CCNx" format="default"/>
           and NDN <xref target="NDN"></xref> target="NDN" format="default"/> 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 to 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.
        </t>
        <t>
           In <xref target="Afanasyev"></xref>, target="Afanasyev" format="default"/>, in order to address the routing
           scalability problem in NDN's DFZ, a well-known concept of Map-and-Encap 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 lookups looks up the mapping
           information from a name to its globally routed prefixes, where NDNS is
           a kind of an NRS.
        </t>
<!--

         <t>In ICN, data objects must be identified by names regardless their location or container <xref target="RFC7927"></xref> and the names are divided into two types of schemes: hierarchical and flat namespaces. A hierarchical scheme used in CCN and NDN architectures has a structure similar to current URIs, where the hierarchy improves scalability of routing system. It is because the hierarchy enables aggregation of the name resulting in reducing the size of RIB or FIB as similar to IP routing system. In a flat scheme, on the other hand, name routing is not easy since names in a flat namespace cannot be aggregated anymore, which would cause more the scalability problem in routing system. In order to address such problem, a flat name can be resolved to some information which is routable through NRS. </t>

	       <t>In ICN, application names identifying contents are used directly for packet delivery, so ICN routers run a name-based routing protocol to build name-based routing and forwarding tables. Regardless of name scheme, if non-aggregated name prefixes are injected to the Default Route Free Zone (DFZ) of ICN, then they would be driving the growth of the DFZ routing table size, which is the same as the scalability issue of IP routing. Thus a solution to keep the routing table size under control is needed, which can be done by defining indirection layer. </t>
-->
	     </section>
      <section title="Support off-path caching"> numbered="true" toc="default">
        <name>Support Off-Path Caching</name>
        <t>
          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 quality-of-service (QoS)
          experience to users, users to reduce the overall network traffic, to prevent network
          congestion and Denial-of-Service denial-of-service (DoS) attacks 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 "content replication" or content storing, "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.
        </t>
        <t>
          In <xref target="Bayhan"></xref>, target="Bayhan" format="default"/>, 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.
        </t>
      </section>
      <section title="Support nameless object"> numbered="true" toc="default">
        <name>Support Nameless Object</name>
        <t>
          In CCNx 1.0 <xref target="Mosko2"></xref>, target="Mosko2" format="default"/>, the concept of a "Nameless
          Objects" that are
          Object", which is a Content Object without a Name name, is introduced to
          provide a means to move Content content between storage replicas without having
          to rename or re-sign the content objects Content Objects for the new name. Nameless
          Objects can be addressed by the ContentObjectHash that ContentObjectHash, which is to restrict
          Content Object matching by using a SHA-256 hash.
        </t>
        <t>
          An Interest message would still carry a Name name and a ContentObjectHash,
          where a Name 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.
        </t>
      </section>
      <section title="Support manifest"> numbered="true" toc="default">
        <name>Support Manifest</name>
        <t>
					For collections of data objects which that are organized as large and file
          like file-like contents <xref target="FLIC"></xref>, target="I-D.irtf-icnrg-flic" format="default"/>, manifests are used as data
          structures to transport this information. Thus, manifests may contain
          hash digests of signed content objects Content Objects or other manifests, manifests so that large
          content objects which
          Content Objects that represent a large piece of application data can be
          collected by using such a manifest.
        </t>
        <t>
					In order to request content objects, Content Objects, a consumer needs to know a manifest
          root name to acquire the manifest. In the case of FLIC, File-Like ICN Collections (FLIC), a manifest name
          can be represented by a nameless root manifest, manifest so that an outside system
          such as an NRS may be involved to give this information to the consumer.
        </t>
      </section>
      <section title="Support metadata"> numbered="true" toc="default">
        <name>Support Metadata</name>
        <t>
            When resolving the name of a content object, 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
            NEO
            Networked Object (NEO) ICN architecture <xref target="NEO"></xref>. target="NEO" format="default"/>.
        </t>
      </section>
    </section>
    <section title="Design considerations numbered="true" toc="default">
      <name>Design Considerations for NRS in ICN"> ICN</name>
      <t>
        This section presents the design considerations for NRS in ICN.
      </t>
      <section title="Resolution response time"> numbered="true" toc="default" anchor="res-response">
        <name>Resolution Response Time</name>
        <t>
            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, 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, request so as to consider the resolution incomplete when the timer expires.
        </t>
        <t>
            The acceptable response delay could be of the order of a round trip round-trip
            time between the client issuing the request and the NRS servers that provides provide the response. While this RTT may vary greatly depending on the proximity between the two end points, some upper bound need needs to be used.
            Especially,
            Especially in some delay-sensitive scenarios such as industrial Internet and telemedicine, the upper bound of the response delay must be guaranteed.
        </t>
  <!--        <t>
            The response time should be within the same order of magnitude for most pairs of a client issuing a request, and the NRS server responding to this request.
          </t>
 -->
          <t>
            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.
        </t>
<!--
         <t>The name resolution process provided by the NRS must be completed within a minimum delay. If the name resolution takes too long, then the content request packet may get dropped or it will yield the high content retrieval time for content requestor. Thus, the content retrieval time has to be content requestor-tolerant.</t>
-->
         </section>
<!--         must not introduce significant latencies. With more number of name record replications, the number of nodes involved in the name resolution may be reduced. For example, in the explicit name resolution approach, with the name record being replicated to higher hierarchy or the peer NRS server in the overlay, the name resolution can be responded more promptly. In the name based routing approach, with the content based routing table being broadcast within the larger scope in the network, the name resolution and request routing can have higher probability to successfully reach the nearer copy of the requested content.

         The NRS deployment should balance the number of nodes involved in the name resolution and the overhead/cost for the name record replication. To ensure the low latency, the NRS should be able to route a content request to the closest copy. Message forwarding and processing should be efficient and computation complexity should be reasonable low and affordable by the current processor technologies.

         <section title="Time transiency">
         <t>The NRS should support time-transient content, which is frequently created in and disappearing from the network. This kind of content only stays in the network for a short time, which requires the NRS to be able to promptly reflect the records of them in the system. For example, some video clip only exists in the network for a very short time, which requires the NRS to promptly update their name records. </t>
         </section>
-->
         <section title="Response accuracy"> numbered="true" toc="default">
        <name>Response Accuracy</name>
        <t>
             An NRS must provide an accurate response, namely response -- namely, a proper binding of the requested name (or prefix) with a location. The response can be either a (prefix, location) pair, pair or the actual forwarding of a request to a node holding the content, which is then transmitted in return.
        </t>
        <t>
             An NRS must provide an up-to-date response, namely 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.
        </t>
        <t>
             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.
        </t>
        <t>
             Content that is highly mobile may require to specify specifying some type of anchor that is kept at the NRS, NRS instead of the content location.
        </t>

<!--
         <t>The NRS must provide accurate and up-to-date information on how to discover the requested content with minimum overhead in propagating the update information. For example, a content can be moved from one domain to another domain due to the mobility of the producer, then the old name record should be deleted from the NRS system and a new name record should be added and updated with minimum delay.</t>

         Content mobility and expiration must be reflected in the corresponding records in the NRS system with minimum delay to guarantee the accurate resolution.
-->
         </section>
      <section title="Resolution guarantee"> numbered="true" toc="default">
        <name>Resolution Guarantee</name>
        <t>
             An NRS must ensure that the name resolution is successful
             with high probability if the name matching name-matching content exists in the network,
             regardless of its popularity and the number of cached copies existing in the network.
             As per Section 4.1,
             Per <xref target="res-response"/>, some resolution 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 (say, five 9s, (five 9s or
             five sigmas sigmas, for instance) that a resolution will be satisfied.
        </t>
<!--
         <t>The NRS must ensure the name resolution success if the matching content exists in the network, regardless of its popularity, number of cached copies. </t>
-->
         </section>
      <section title="Resolution fairness"> numbered="true" toc="default">
        <name>Resolution Fairness</name>
        <t>
             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 per-request delay to complete the NRS steps that is not agnostic to the properties of the content itself.
             Fairness may be defined as well as the number of requests answered per unit of time.
        </t>
        <t>
             However, it is notable that content (or their associated producer) may request a different level of QoS from the network (see <xref target="RFC9064"></xref> target="RFC9064" format="default"/>, 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.
        </t>
      </section>
      <section title="Scalability"> numbered="true" toc="default">
        <name>Scalability</name>
        <t>
             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 building-up buildup, and name records record propagation must be efficient and scalable.
        </t>
        <t>
             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 the zettabytes per year (10^21 (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^21 10<sup>21</sup> in the near future, and larger beyond.
        </t>
        <t>
             The NRS system must be able to scale up, namely up -- namely, to add NRS servers to the NRS system, system in a way that is transparent to the users.
             Addition
             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, servers for load balancing or tolerance to failure.
             These steps should not disrupt the service provided by the NRS and should in the long run improve the quality of the service. service in the long run.
        </t>
        <t>
             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 devices, and interactions with the NRS system would not be too costly.
             An IoT node node, for instance instance, should be able to access the NRS system as well as a more powerful node.
        </t>
        <t>
             The NRS system should scale up in its responsiveness to the increased request rate that is expected from applications such as IoT or M2M, machine-to-machine (M2M),
             where data is being frequently generated and/or frequently requested.
        </t>
      </section>
      <section title="Manageability"> numbered="true" toc="default">
        <name>Manageability</name>
        <t>
             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.
        </t>
        <t>
             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.
        </t>
<!--
         <t>The NRS system must be manageable since some parts of the system may grow or shrink dynamically and a NRS system node may be added or deleted. </t>
-->
         </section>
      <section title="Deployed system"> numbered="true" toc="default">
        <name>Deployed System</name>
        <t>
             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.
        </t>
<!--
         <t>The NRS system must be deployable since deployability is important for a real world system. If the NRS system can be deployed from the edges, then the deployment can be simplified. </t>
-->
         </section>
      <section title="Fault tolerance"> numbered="true" toc="default">
        <name>Fault Tolerance</name>
        <t>
             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.
        </t>
        <t>
             After an NRS server fails, the NRS system must be able to recover and/or restore the name records stored in the NRS server.
        </t>

<!--
         <t>The NRS system must ensure resilience to node failures. After a NRS node fails, the NRS system must be able to restore the name records stored in the NRS node. </t>

         The NRS must also ensure resolution failure at one NRS node would be resolved and corrected by other NRS nodes.

        <t>For example, in the explicit name resolution approach, when a NRS overlay server fails, the name records should be able to transferred and recovered in its peer server or its replacement. In the name based approach, the failure of one ICN router does not cause much trouble in the name resolution, because the other alternative paths can be established that bypass the failed ICN router. However, it requires that the ICN router has propagated its name based routing information in the network. </t>
-->
         </section>
      <section title="Security numbered="true" toc="default" anchor="sec-priv">
        <name>Security and privacy"> Privacy</name>
        <t>
               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.
        </t>
        <section title="Confidentiality"> numbered="true" toc="default">
          <name>Confidentiality</name>
          <t>
                     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.
          </t>
          <t>
                     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.
          </t>
          <t>
                     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.
          </t>
          <t>
                     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.
          </t>
          <t>
                     The NRS system must also keep confidentiality of meta-data 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).
          </t>
        </section>
        <section title="Authentication">
                  <t>
                       <list style="symbols">
                           <t> numbered="true" toc="default">
          <name>Authentication</name>
          <ul spacing="normal">
            <li>
                             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.
                           </t>
                           <t>
                           </li>
            <li>
                             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.
                           </t>
                           <t>
                           </li>
            <li>
                             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.
                           </t>

                         </list>
                   </t>
                           </li>
          </ul>
        </section>
        <section title="Integrity"> numbered="true" toc="default">
          <name>Integrity</name>
          <t>
                     The NRS system must be prevented protected from malicious users
                     attempting to hijack or corrupt the name mapping records.
          </t>
        </section>
        <section title="Resiliency numbered="true" toc="default">
          <name>Resiliency and availability"> Availability</name>
          <t>
                     The NRS system should be resilient against denial of service 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.
          </t>
        </section>
      </section>
    </section>
    <section title="Conclusion"> numbered="true" toc="default">
      <name>Conclusion</name>
      <t>
    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
    next-hop info, etc. that is used for forwarding the object request.
      </t>
      <t>
    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.
      </t>
    </section>
    <section anchor="IANA" title="IANA Considerations">
		<t>There are numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document has no IANA considerations related to this document.</t> actions.</t>
    </section>
    <section title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
        A discussion of security guidelines was is provided in section 4.9. <xref target="sec-priv"/>.
      </t>
    </section>
  </middle>

<!--  *****BACK MATTER ***** -->
<back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
     (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">

	 		&rfc7927;

<displayreference target="I-D.irtf-icnrg-icniot" to="ID.Zhang2"/>
<displayreference target="I-D.ravi-icnrg-ccn-forwarding-label" to="Ravindran"/>
<displayreference target="I-D.irtf-icnrg-flic" to="FLIC"/>
<displayreference target="I-D.irtf-icnrg-nrsarch-considerations" to="NRSarch"/>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7927.xml"/>
      </references>

 		<references title="Informative References">
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8569.xml"/>

        <reference anchor='Ahlgren'> anchor="Ahlgren">
          <front>
            <title>A Survey of Information-Centric Networking</title>
            <author initials='B.' surname='Ahlgren' fullname='B. Ahlgren'></author>
          <author initials='C.' surname='Dannewitz' fullname='C. Dannewitz'></author>
          <author initials='C.' surname='Imbrenda' fullname='C. Imbrenda'></author>
          <author initials='D.' surname='Kutscher' fullname='D. Kutscher'></author>
          <author initials='B.' surname='Ohlman' fullname='B. Ohlman'></author> initials="B." surname="Ahlgren" fullname="B. Ahlgren"/>
            <author initials="C." surname="Dannewitz" fullname="C. Dannewitz"/>
            <author initials="C." surname="Imbrenda" fullname="C. Imbrenda"/>
            <author initials="D." surname="Kutscher" fullname="D. Kutscher"/>
            <author initials="B." surname="Ohlman" fullname="B. Ohlman"/>
            <date month='' year='2012' /> month="July" year="2012"/>
          </front>
          <seriesInfo name='IEEE name="DOI" value="10.1109/MCOM.2012.6231276"/>
          <refcontent>IEEE Communications Magarzine' value='Vol.50, Magazine, Vol. 50, Issue 7' /> 7</refcontent>
        </reference>

        <reference anchor='Xylomenos'> anchor="Xylomenos">
          <front>
            <title>A Survey of Information-Centric Networking Research,Communications Surveys and Tutorials</title> Research</title>
            <author initials='G.' surname='Xylomenos' fullname='G. Xylomenos'></author>
          <author initials='C. N.' surname='Ververidis' fullname='C. N. Ververidis'></author>
          <author initials='V. A.' surname='Siris' fullname='V. A. Siris'></author> initials="G." surname="Xylomenos" fullname="G. Xylomenos"/>
            <author initials='N.' surname='Fotiou' fullname='N. Fotiou'></author>
          <author initials='C.' surname='Tsilopoulos' fullname='C.Tsilopoulos'></author>
          <author initials='X.' surname='Vasilako' fullname='X. Vasilako'></author>
          <author initials='K. V.' surname='Katsaros' fullname='K. V. Katsaros'></author>
          <author initials='G. C.' surname='Polyzos' fullname='G. C. Polyzos'></author>
          <date month='' year='2014' />
         </front>
        <seriesInfo name='IEEE initials="C." surname="Ververidis" fullname="C. Ververidis"/>
            <author initials="V." surname="Siris" fullname="V. Siris"/>
            <author initials="N." surname="Fotiou" fullname="N. Fotiou"/>
            <author initials="C." surname="Tsilopoulos" fullname="C.Tsilopoulos"/>
            <author initials="X." surname="Vasilakos" fullname="X. Vasilakos"/>
            <author initials="K." surname="Katsaros" fullname="K. Katsaros"/>
            <author initials="G." surname="Polyzos" fullname="G. Polyzos"/>
            <date year="2014"/>
          </front>
          <seriesInfo name="DOI" value="10.1109/SURV.2013.070813.00063"/>
          <refcontent>IEEE Communications Surveys and Tutorials' value='vol. Tutorials, Vol. 16, no. 2' /> Issue 2</refcontent>
	</reference>

        <reference anchor='Baccelli'> anchor="Baccelli">
          <front>
            <title>Information Centric Networking in the IoT: Experiments with NDN in the Wild</title>
            <author initials='E.' surname='Baccelli' fullname='E. Baccelli'></author>
          <author initials='C.' surname='Mehlis' fullname='C. Mehlis'></author>
          <author initials='O.' surname='Hahm' fullname='O. Hahm'></author>
          <author initials='T.' surname='Schmidt' fullname='T. Schmidt'></author>
          <author initials='M.' surname='Wahlisch' fullname='M. Wahlisch'></author> initials="E." surname="Baccelli" fullname="E. Baccelli"/>
            <author initials="C." surname="Mehlis" fullname="C. Mehlis"/>
            <author initials="O." surname="Hahm" fullname="O. Hahm"/>
            <author initials="T." surname="Schmidt" fullname="T. Schmidt"/>
            <author initials="M." surname="Wählisch" fullname="M. Wählisch"/>
            <date month='' year='2014' /> month="" year="2014"/>
          </front>
          <seriesInfo name='ACM ICN' value='2014' /> name="DOI" value="10.1145/2660129.2660144"/>
          <refcontent>ACM-ICN 2014</refcontent>
        </reference>

        <reference anchor='Amadeo'> anchor="Amadeo">
          <front>
            <title>Named data networking for IoT: An architectural perspective</title>
            <author initials='M.' surname='Amadeo' fullname='M. Amadeo'></author>
          <author initials='C.' surname='Campolo' fullname='C. Campolo'></author>
          <author initials='A.' surname='Iera' fullname='A. Iera'></author>
          <author initials='A.' surname='Molinaro' fullname='A. Molinaro'></author>
          <date month='' year='2014' />
         </front>
        <seriesInfo name='European initials="M." surname="Amadeo" fullname="M. Amadeo"/>
            <author initials="C." surname="Campolo" fullname="C. Campolo"/>
            <author initials="A." surname="Iera" fullname="A. Iera"/>
            <author initials="A." surname="Molinaro" fullname="A. Molinaro"/>
            <date month="June" year="2014"/>
          </front>
          <seriesInfo name="DOI" value="10.1109/EuCNC.2014.6882665"/>
          <refcontent>European Conference on Networks and Communications (EuCNC)' value='' /> (EuCNC)</refcontent>
        </reference>

        <reference anchor='Quevedo'> anchor="Quevedo">
          <front>
            <title>A case for ICN usage in IoT environments</title>
            <author initials='J.' surname='Quevedo' fullname='J. Quevedo'></author>
                <author initials='D.' surname='Corujo' fullname='D. Corujo'></author>
                <author initials='R.' surname='Aguiar' fullname='R. Aguiar'></author> initials="J." surname="Quevedo" fullname="J. Quevedo"/>
            <author initials="D." surname="Corujo" fullname="D. Corujo"/>
            <author initials="R." surname="Aguiar" fullname="R. Aguiar"/>
            <date month='' year='2014' /> month="December" year="2014"/>
          </front>
          <seriesInfo name='IEEE GLOBECOM' value='' /> name="DOI" value="GLOCOM.2014.7037227"/>
          <refcontent>IEEE GLOBECOM</refcontent>
        </reference>

        <reference anchor='Amadeo2'> anchor="Amadeo2">
          <front>
            <title>Information-centric networking for the internet of things: challenges and opportunitiesve</title> opportunities</title>
            <author initials='' surname='Amadeo, initials="" surname="Amadeo, M. et al.' fullname='Amadeo, al." fullname="Amadeo, M. et al.'></author> al."/>
            <date month='July' year='2016' /> month="March" year="2016"/>
          </front>
          <seriesInfo name='IEEE Network' value='vol. name="DOI" value="10.1109/MNET.2016.7437030"/>
          <refcontent>IEEE Network, Vol. 30, no. 2' />

     </reference>

      <reference anchor='ID.Zhang2'>                                                         <front>
          <title>Design Considerations for Applying ICN to IoT</title>
                <author initials='' surname='Ravindran, R. et al.' fullname='Ravindran, R. et al.'></author>
                <date month='May' year='2019' />
        </front>
        <seriesInfo name='draft-zhang-icnrg-icniot-03' value='' /> No. 2</refcontent>
        </reference>

<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.irtf-icnrg-icniot.xml"/>

        <reference anchor='Koponen'> anchor="Koponen">
          <front>
            <title>A Data-Oriented (and Beyond) Network Architecture</title>
            <author initials='T.' surname='Koponen' fullname='T. Koponen'></author>
          <author initials='M.' surname='Chawla' fullname='M. Chawla'></author>
          <author initials='B.' surname='Chun' fullname='B. Chun'></author>
          <author initials='A.' surname='Ermolinskiy' fullname='A. Ermolinskiy'></author>
          <author initials='K. H.' surname='Kim' fullname='K. H. Kim'></author> initials="T." surname="Koponen" fullname="T. Koponen"/>
            <author initials="M." surname="Chawla" fullname="M. Chawla"/>
            <author initials='S.' surname='Shenker' fullname='S. Shenker'></author>
          <author initials='I.' surname='Stoica' fullname='I. Stoica'></author>
          <date month='' year='2007' />
         </front>
        <seriesInfo name='ACM SIGCOMM' value='2007 initials="B." surname="Chun" fullname="B. Chun"/>
            <author initials="A." surname="Ermolinskiy" fullname="A. Ermolinskiy"/>
            <author initials="K.H." surname="Kim" fullname="K.H. Kim"/>
            <author initials="S." surname="Shenker" fullname="S. Shenker"/>
            <author initials="I." surname="Stoica" fullname="I. Stoica"/>
            <date month="August" year="2007"/>
          </front>
          <seriesInfo name="DOI" value="10.1145/1282380.1282402"/>
          <refcontent>ACM SIGCOMM 2007, pp. 181-192' /> 181-192 </refcontent>
        </reference>

        <reference anchor='PURSUIT'> anchor="PURSUIT" target="https://www.fp7-pursuit.eu/">
          <front>
            <title>FP7 PURSUIT project.</title> PURSUIT</title>
            <author initials='' surname='' fullname=''></author>
                <date month='' year='' />
            <date/>
          </front>
        <seriesInfo name='http://www.fp7-pursuit.eu/PursuitWeb/' value='' />
        </reference>

        <reference anchor='SAIL'> anchor="SAIL" target="http://www.sail-project.eu/">
          <front>
                <title>FP7 SAIL project.</title>
                <author initials='' surname='' fullname=''></author>
                <date month='' year='' />
            <title>Scalable and Adaptive Internet Solutions (SAIL)</title>
            <author/>
            <date/>
          </front>
        <seriesInfo name='http://www.sail-project.eu/' value='' />
        </reference>

        <reference anchor='NDN'> anchor="NDN" target="http://www.named-data.net">
          <front>
                <title>NSF Named
            <title>Named Data Networking project.</title>
                <author initials='' surname='' fullname=''></author>
                <date month='' year='' /> Networking</title>
            <author/>
            <date/>
          </front>
        <seriesInfo name='http://www.named-data.net' value='' />
        </reference>

        <reference anchor='CCNx'> anchor="CCNx" target="https://wiki.fd.io/view/Cicn">
          <front>
                <title>Content Centric Networking project.</title>
                <author initials='' surname='' fullname=''></author>
                <date month='' year='' />
            <title>CICN</title>
            <author/>
            <date/>
          </front>
        <seriesInfo name='https://wiki.fd.io/view/Cicn' value='' />
        </reference>

        <reference anchor='MF'> anchor="MF" target="http://mobilityfirst.winlab.rutgers.edu">
          <front>
                <title>NSF Mobility First project.</title>
                <author initials='' surname='' fullname=''></author>
                <date month='' year='' />
            <title>MobilityFirst Future Internet Architecture Project Overview</title>
            <author/>
            <date/>
          </front>
        <seriesInfo name='http://mobilityfirst.winlab.rutgers.edu/' value='' />
        </reference>

        <reference anchor='Jung'> anchor="Jung">
          <front>
            <title>IDNet: Beyond All-IP Network</title>
            <author initials='' surname='Jung, initials="" surname="Jung, H. et al.' fullname='H. al." fullname="H. Jung et al.' ></author> al."/>
            <date month='October' year='2015' /> month="October" year="2015"/>
          </front>
          <seriesInfo name='ETRI Jouranl' value='vol. name="DOI" value="10.4218/etrij.15.2415.0045"/>
          <refcontent>ETRI Journal, Vol. 37, no. 5' /> Issue 5</refcontent>
        </reference>

        <reference anchor="SA2-5GLAN"> anchor="SA2-5GLAN" target="http://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_82/Docs/SP-181120.zip">
          <front>
           <title>SP-181129, Work Item Description, Vertical_LAN(SA2),
            <title>New WID: 5GS Enhanced Support support of Vertical and LAN Services</title>
           <author initials="" surname="3gpp-5glan" />
            <author><organization>3GPP</organization></author>
            <date year="http://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_82/Docs/SP-181120.zip"/> month="December" year="2018"/>
          </front>
         <seriesInfo name="3GPP" value=""/>
       </reference>

<!--
      <reference anchor='Jacobson'>                                                               <front>
          <title>Networking Named Content</title>
          <author initials='V.' surname='Jacobson' fullname='V. Jacobson'></author>
          <author initials='D. K.' surname='Smetters' fullname='D. K. Smetters'></author>
          <author initials='J. D.' surname='Thornton' fullname='J. D. Thornton'></author>
          <author initials='M. F.' surname='Plass' fullname='M. F. Plass'></author>
          <author initials='N. H.' surname='Briggs' fullname='N. H. Briggs'></author>
          <author initials='R. L.' surname='Braynard' fullname='R. L. Braynard'></author>
          <date month='' year='2009' />
         </front>
        <seriesInfo name='ACM CoNEXT' value='' />
      </reference>

      <reference anchor='Baid'>                                                               <front>
          <title>Comparing Alternative Approaches for Networking of Named Objects in the Future Internet</title>
          <author initials='A.' surname='Baid' fullname='A. Baid'></author>
          <author initials='T.' surname='Vu' fullname='T. Vu'></author>
          <author initials='D.' surname='Raychaudhuri' fullname='D. Raychaudhuri'></author>
          <date month='' year='2012' />
         </front>
        <seriesInfo name='IEEE Workshop on Emerging Design Choices in Name-Oriented Networking (NOMEN)' value='' />
          <refcontent>TSG SA Meeting #SP-82</refcontent>
        </reference>
-->

      <reference anchor='Bari'> anchor="Bari">
          <front>
            <title>A Survey of Naming and Routing in Information-Centric Networks</title>
            <author initials='M. F.' surname='Bari' fullname='M. F. Bari'></author>
          <author initials='S. R.' surname='Chowdhury' fullname='S. R. Chowdhury'></author>
          <author initials='R.' surname='Ahmed' fullname='R. Ahmed'></author>
          <author initials='R.' surname='Boutaba' fullname='R. Boutaba'></author>
          <author initials='B.' surname='Mathieu' fullname='B. Mathieu'></author> initials="M.F." surname="Bari" fullname="M.F. Bari"/>
            <author initials="S.R." surname="Chowdhury" fullname="S.R. Chowdhury"/>
            <author initials="R." surname="Ahmed" fullname="R. Ahmed"/>
            <author initials="R." surname="Boutaba" fullname="R. Boutaba"/>
            <author initials="B." surname="Mathieu" fullname="B. Mathieu"/>
            <date month='' year='2012' /> month="December" year="2012"/>
          </front>
          <seriesInfo name='IEEE name="DOI" value="10.1109/MCOM.2012.6384450"/>
          <refcontent>IEEE Communications Magazine' value='Vol. Magazine, Vol. 50, No. 12, P.44-53' />
      </reference>

<!--
      <reference anchor='Rajahalme'>                                                               <front>
          <title>On Name-based Inter-domain Routing</title>
          <author initials='J.' surname='Rajahalme' fullname='J. Rajahalme'></author>
          <author initials='M.' surname='Sarela' fullname='M. Sarela'></author>
          <author initials='K.' surname='Visala' fullname='K. Visala'></author>
          <author initials='J.' surname='Riihijarvi' fullname='J. Riihijarvi'></author>
          <date month='March' year='2011' />
         </front>
        <seriesInfo name='Computer Networks' value='Vol. 55, No. 4, P. 975-986' />
      </reference>

      <reference anchor='Katsaros'>                                                               <front>
          <title>On Inter-Domain Name Resolution for Information-Centric Networks</title>
          <author initials='K. V.' surname='Katsaros' fullname='K. V. Katsaros'></author>
          <author initials='N.' surname='Fotiou' fullname='N. Fotiou'></author>
          <author initials='X.' surname='Vasilakos' fullname='X. Vasilakos'></author>
          <author initials='C. N.' surname='Ververidis' fullname='C. N. Ververidis'></author>
          <author initials='C.' surname='Tsilopoulos' fullname='C. Tsilopoulos'></author>
          <author initials='G.' surname='Xylomenos' fullname='G. Xylomenos'></author>
          <author initials='G. C.' surname='Polyzos' fullname='G. C. Polyzos'></author>
          <date month='' year='2012' />
         </front>
        <seriesInfo name='Proc.IFIP-TC6 Networking Conference' value='' />
      </reference>

      <reference anchor='ID.Wang'>                                                               <front>
          <title>Namespace Resolution in Future Internet Architectures</title>
          <author initials='J.' surname='Wang' fullname='J. Wang'></author>
          <author initials='S.' surname='Li' fullname='S. Li'></author>
          <author initials='C.' surname='Wetphal' fullname='C. Wetphal'></author>
          <date month='October' year='2015' />
         </front>
        <seriesInfo name='draft-wang-fia-namespace-01' value='' />
      </reference>

      <reference anchor='ID.Zhang'>                                                               <front>
          <title>PID: A Generic Naming Schema for Information-centric Network</title>
          <author initials='X.' surname='Zhang' fullname='X. Zhang'></author>
          <author initials='R.' surname='Ravindran' fullname='R. Ravindran'></author>
          <author initials='H.' surname='Xie' fullname='H. Xie'></author>
          <author initials='G.' surname='Wang' fullname='G. Wang'></author>
          <date month='August' year='2013' />
         </front>
        <seriesInfo name='draft-zhang-icnrg-pid-naming-scheme-03' value='' />
      </reference>

      <reference anchor='D.Zhang'>                                                               <front>
          <title>Routing and Name Resolution in Information-Centric Networks</title>
          <author initials='D.' surname='Zhang' fullname='D. Zhang'></author>
          <author initials='H.' surname='Liu' fullname='H. Liu'></author>
          <date month='' year='2013' />
         </front>
        <seriesInfo name='22nd International Conference on Computer Communications and Networks (ICCCN)' value='' />
      </reference>

      <reference anchor='Sevilla'>                                                               <front>
          <title>iDNS: Enabling Information Centric Networking Through The DNS</title>
          <author initials='S.' surname='Sevilla' fullname='S. Sevilla'></author>
          <author initials='P.' surname='Mahadevan' fullname='P. Mahadevan'></author>
          <author initials='J.' surname='Garcia-Luna-Aceves' fullname='J. Garcia-Luna-Aceves'></author>
          <date month='' year='2014' />
         </front>
        <seriesInfo name='Name Oriented Mobility (workshop co-located with Infocom 2014)' value='' />
      </reference>

      &rfc1498;

      <reference anchor='oneM2M'>
            <front>
                <title>oneM2M Functional Architecture TS 0001.</title>
                <author initials='' surname='' fullname=''></author>
                <date month='' year='' />
            </front>
        <seriesInfo name='http://www.onem2m.org/technical/published-documents.' value='' />
      </reference>

      &rfc7252;

      <reference anchor='ID.Shelby'>
            <front>
                <title>CoRE Resource Directory</title>
                <author initials='Z.' surname='Shelby' fullname='Z. Shelby'></author>
                <date month='March' year='2017' />
            </front>
        <seriesInfo name='draft-ietf-core-resource-directory-10' value='' />
      </reference>

      <reference anchor='CoRE'>
            <front>
                <title>Constrained RESTful Environments, CoRE</title>
                <author initials='' surname='' fullname=''></author>
                <date month='March' year='2013' />
            </front>
        <seriesInfo name='https://datatracker.ietf.org/wg/core/charter/' value='' /> pp. 44-53</refcontent>
        </reference>
-->

      <reference anchor='Westphal'> anchor="Westphal">
          <front>
            <title>An IP-based IP-Based Manifest Architecture for ICN</title>
            <author initials='C.' surname='Westphal' fullname='C. Westphal'></author>
                <author initials='E.' surname='Demirors' fullname='E. Demirors'></author>
                <date month='' year='2015' />
         </front>
        <seriesInfo name='ACM ICN' value='' />
      </reference>

      <reference anchor='Mosko'>                                                       <front>
          <title>CCNx Manifest Specification</title>
          <author initials='M.' surname='Mosko' fullname='M. Mosko'></author>
          <author initials='G.' surname='Scott' fullname='G. Scott'></author>
          <author initials='I.' surname='Solis' fullname='I. Solis'></author>
          <author initials='C.' surname='Wood' fullname='C. Wood'></author>
                <date month='July' year='2015' />
         </front>
        <seriesInfo name='draft-wood-icnrg-ccnxmanifests-00' value='' />
      </reference>

<!--
      &rfc6830;
      &rfc6833;
-->

      <reference anchor='RFC6920'>                                                       <front>
          <title>Naming Things with Hashes</title>
          <author initials='S.' surname='Farrell ' fullname='Stephen Farrell'></author>
          <author initials='D.' surname='Kutscher' fullname='Dirk Kutscher'></author>
          <author initials='C.' surname='Dannewitz' fullname='Christian Dannewitz'></author>
          <author initials='B.' surname='Ohlman' fullname='Borje Ohlman'></author>
          <author initials='A.' surname='Keranen' fullname='Ari Keranen'></author>
          <author initials='P.' surname='Hallam-Baker' fullname='Phillip Hallam-Baker'></author>
                <date month='April' year='2013' />
         </front>
        <seriesInfo name='RFC6920, DOI 10.17487/RFC6920, https://rfc-editor.org/rfc/rfc6920.txt' value='' />
      </reference>

<!--
  <reference anchor='Zhang'>
  <front>
  <title>Named data networking</title> initials="C." surname="Westphal" fullname="C. Westphal"/>
            <author initials='' surname='Zhang, L. et al.' fullname='L. Zhang et al.'></author> initials="E." surname="Demirors" fullname="E. Demirors"/>
            <date month='July' year='2014' /> month="September" year="2015"/>
          </front>
          <seriesInfo name='ACM SIGCOMM Computer Communication Review' value='vol. 44, no. 3'   /> name="DOI" value="10.1145/2810156.2812614"/>
          <refcontent>ACM-ICN 2015</refcontent>
        </reference>
-->

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6920.xml"/>

      <reference anchor='Zhang2'> anchor="Zhang2">
          <front>
            <title>A Survey of Mobility Support in Named Data Networking</title>
            <author initials='' surname='Zhang, initials="" surname="Zhang, Y. et al.' fullname='Y. al." fullname="Y. Zhang et al.'></author> al."/>
            <date month='' year='2016'/> month="April" year="2016"/>
          </front>
          <seriesInfo name='IEEE name="DOI" value="10.1109/INFCOMW.2016.7562050"/>
          <refcontent>IEEE Conference on Computer Communications Workshops' value=''   /> Workshops</refcontent>
        </reference>

        <reference anchor='Dannewitz'> anchor="Dannewitz">
          <front>
            <title> Network of Information (NetInf)-An information centric (NetInf) - An information-centric networking architecture </title>
            <author initials='' surname='Dannewitz, initials="" surname="Dannewitz, C. et al.' fullname='C. al." fullname="C. Dannewitz et al.' ></author>
    <date month='April' year='2013' />
    </front>
    <seriesInfo name='Computer Communications' value='vol. 36, no. 7' />
    </reference>

<!--
  <reference anchor='Seskar'>
        <front>
        <title>MobilityFirst Future Internet Architecture Project</title>
     <author initials='I.' surname='Seskar' fullname='I. Seskar' ></author>
     <author initials='K.' surname='Nagaraja' fullname='K. Nagaraja' ></author>
     <author initials='S.' surname='Nelson' fullname='S. Nelson'  ></author>
     <author initials='D.' surname='Raychaudhuri' fullname='D. Raychaudhurin' ></author>
     <date month='November' year='2011' />
     </front>
     <seriesInfo name='7th Asian Internet Engineering Conference' value='' />
     </reference>

    <reference anchor='Dannewitz2'>
    <front>
    <title>Hierarchical DHT-based name resolution for Information-Centric Networks</title>
    <author initials='C.' surname='Dannewitz' fullname='C. Dannewitz' ></author>
    <author initials='M.' surname='DAmbrosio' fullname='M. DAmbrosio' ></author>
    <author initials='V.' surname='Vercellone' fullname='V. Vercellone' ></author> al."/>
            <date month='April' year='2013' /> month="April" year="2013"/>
          </front>
          <seriesInfo name='Computer Communications' value='vol. name="DOI" value="10.1016/j.comcom.2013.01.009"/>
          <refcontent>Computer Communications, Vol. 36, no. 7' />
    </reference>

    <reference anchor='Vu'>
    <front>
    <title>DMap: A Shared Hosting Scheme for Dynamic Identifier to Locator Mapping in the Global Internet </title>
    <author initials='' surname='Vu, T. et al.' fullname='T. Vu et al' ></author>
    <date month='' year='2012' />
    </front>
    <seriesInfo name='IEEE 32nd International Conference on Distributed Computing Systems' value='' />
    </reference>

    <reference anchor='Hong'>
    <front>
    <title>Demonstrating a Scalable Name Resolution System for Information-Centric Networking </title>
    <author initials='J.' surname='Hong' fullname='J. Hong' ></author>
    <author initials='W.' surname='Chun' fullname='W. Chun' ></author>
    <author initials='H.' surname='Jung' fullname='H. Jung' ></author>
    <date month='September' year='2015' />
    </front>
    <seriesInfo name='ACM ICN' value='' />
    </reference>
-->
    <reference anchor='Ravindran'>
    <front>
    <title>Forwarding-Label support in CCN Protocol </title>
    <author initials='' surname='Ravindran, R. et al.' fullname='R. Ravindran et al' ></author>
    <date month='March' year='2018' />
    </front>
    <seriesInfo name='draft-ravi-icnrg-ccn-forwarding-label-02' value='' /> Issue 7</refcontent>
        </reference>

<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ravi-icnrg-ccn-forwarding-label.xml"/>

        <reference anchor='Afanasyev'> anchor="Afanasyev">
          <front>
            <title>SNAMP: Secure Namespace Mapping to Scale NDN Forwarding </title>
            <author initials='' surname='Afanasyev, initials="" surname="Afanasyev, A. et al.' fullname='A. al." fullname="A. Afanasyev et al' ></author> al."/>
            <date month='April' year='2015' /> month="April" year="2015"/>
          </front>
          <seriesInfo name='IEEE Global Internet Symposium' value='' /> name="DOI" value="10.1109/INFCOMW.2015.7179398"/>
          <refcontent>2015 IEEE Conference on Computer Communications Workshops </refcontent>
        </reference>

        <reference anchor='Mosko2'> anchor="Mosko2" target="https://datatracker.ietf.org/meeting/interim-2016-icnrg-01/materials/slides-interim-2016-icnrg-1-7.pdf">
          <front>
            <title>Nameless Objects </title>
            <author initials='M.' surname='Mosko' fullname='M. Mosko' ></author> initials="M." surname="Mosko" fullname="M. Mosko"/>
            <date month='January' year='2016' /> month="January" year="2016"/>
          </front>
    <seriesInfo name='IRTF ICNRG' value='' />
          <refcontent>IRTF ICNRG</refcontent>
        </reference>

        <reference anchor='Bayhan'> anchor="Bayhan">
          <front>
            <title>On Content Indexing for Off-Path Caching in Information-Centric Networks </title>
            <author initials='' surname='Bayhan, initials="" surname="Bayhan, S. et al.' fullname='S. al." fullname="S. Bayhan et al' ></author> al."/>
            <date month='September' year='2016' /> month="September" year="2016"/>
          </front>
          <seriesInfo name='ACM ICN' value='' /> name="DOI" value="10.1145/2984356.2984372"/>
          <refcontent>ACM-ICN 2016</refcontent>
        </reference>

<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.irtf-icnrg-flic.xml"/>

        <reference anchor='FLIC'>
    	<front>
    	<title>File-Like ICN Collection (FLIC) </title>
    	<author initials='' surname='Tschudin, C. et al.' fullname='C. Tschudin et al' ></author>
    	<date month='November' year='2019' />
    	</front>
    	<seriesInfo name='draft-irtf-icnrg-flic-02' value='' />
    </reference>

    <reference anchor='NEO'> anchor="NEO">
          <front>
            <title>A DNS-based information-centric network architecture open to multiple protocols for transfer of data objects </title>
            <author initials='A.' surname='Eriksson' fullname='A. Eriksson' ></author>
     <author initials='A.' surname='M. Malik' fullname='A. M. Malik' ></author>
     <date month='' year='2018' />
     </front>
     <seriesInfo name='21st initials="A." surname="Eriksson" fullname="A. Eriksson"/>
            <author initials="A.M." surname="Malik" fullname="A.M. Malik"/>
            <date month="February" year="2018"/>
          </front>
          <seriesInfo name="DOI" value="10.1109/ICIN.2018.8401595"/>
          <refcontent>21st Conference on Innovation in Clouds, Internet and Networks and Workshops (ICIN),' value='pp. 1-8' />
   </reference>

   <reference anchor='NRSarch'>
     <front>
     <title>Architectural Considerations of ICN using Name Resolution Service</title>
     <author initials='' surname='Hong, J. et al.' fullname='J. Hong et al' ></author>
     <date month='February' year='2021' />
     </front>
     <seriesInfo name='draft-irtf-icnrg-nrsarch-considerations-06' value='' />
   </reference>

   <reference anchor='RFC9064'>
     <front>
     <title>Considerations in the development of a QoS Architecture for CCNx-like ICN protocols</title>
     <author initials='D.' surname='Oran' fullname='D. Oran'></author>
     <date month='June' year='2021' />
     </front>
     <seriesInfo name='RFC9064, https://datatracker.ietf.org/doc/rfc9064/' value='' /> (ICIN), pp. 1-8</refcontent>
        </reference>

<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.irtf-icnrg-nrsarch-considerations.xml"/>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9064.xml"/>

      </references>
    </references>
    <section anchor="Acknowledgments" title="Acknowledgements" numbered="false" toc="include">
      <name>Acknowledgements</name>
      <t>
          The authors would like to thank Dave Oran, Dirk Kutscher, Ved Kafle,
          Vincent Roca, Marie-Jose Montpetit, Stephen Farrell, Mirja Kuhlewind,
          and Colin Perkins <contact fullname="Dave Oran"/>, <contact fullname="Dirk Kutscher"/>, <contact fullname="Ved Kafle"/>, <contact fullname="Vincent Roca"/>, <contact fullname="Marie-Jose Montpetit"/>, <contact fullname="Stephen Farrell"/>, <contact fullname="Mirja Kühlewind"/>,
          and <contact fullname="Colin Perkins"/> for very useful reviews, comments comments, and improvement
          on improvements
          to the document.
      </t>
    </section>
  </back>
</rfc>                        <!--
 <       </reference>                                                              title>Networking named content</title>          <sInfo name='IEEE Network' value='vol. 30, no. 2' />                                                                                                </reference>                                                                  &id.draft-winter-energy-efficient-internet;
    </reference>                                                                                                                                              &id.draft-cheshire-edns0-owner-option;
    <reference anchor='ITU'>
        <front>
            <title>Resolution 73 - Information and communication technologies and climate change</title>
            <author></author>
            <date month='October' year='2008' />
        </front>
        </reference>

    <reference anchor='EPC'>
        <front>
            <title>The Case for Energy-Proportional Computing</title>
            <author initials='L.' surname='Barroso' fullname='Luiz Andre Barroso'></author>
            <author initials='U.' surname='Holzle' fullname='Urs Holzle'></author>
            <date month='December' year='2007'/>
        </front>
        <seriesInfo name='Proc. IEEE International Conference on Network Protocols (ICNP)' value=''/>
    </reference>

	<reference anchor='GreenSurvey'>
        <front>
            <title>A survey of green networking research</title>
            <author initials='A.P.' surname='Bianzino' fullname='Aruna Prem Bianzino'></author>
            <author initials='C.' surname='Chaudet' fullname='Claude Chaudet'></author>
            <author initials='D.' surname='Rossi' fullname='Dario Rossi'></author>
            <author initials='J.-L.' surname='Rougier' fullname='Jean-Louis Rougier'></author>            <date month='' year='2012' />
        </front>
        <seriesInfo name='IEEE Communications Surveys Tutorials' value='' />
    </reference>

    <reference anchor='EEE'>
        <front>
            <title>802.3az-2010</title>
            <author></author>
            <date month='' year='2010' />
        </front>
        <seriesInfo name='IEEE std' value='' />
    </reference>

    <reference anchor='PROXZZZY'>
        <front>
            <title>ProxZZZy for sleeping hosts</title>
            <author></author>
            <date month='June' year='2012' />
        </front>
        <seriesInfo name='ECMA International' value='ECMA-393' />
    </reference>

    <reference anchor='EEEC'>
        <front>
            <title>Improving the Energy Efficiency of Ethernet-Connected:
			A Proposal for Proxying</title>
            <author initials='B.' surname='Nordman' fullname='Bbuce Nordman'></author>
            <author initials='K.' surname='Christensen' fullname='Ken Christensen'></author>
            <date month='September' year='2007' />
        </front>
        <seriesInfo name='Ethernet Alliance' value='' />
    </reference>

    <reference anchor='NCP'>
        <front>
            <title>A Network Connection Proxy to Enable Hosts to Sleep and Save Energy</title>
            <author initials='M.' surname='Jimeno' fullname='M. Jimeno'></author>
            <author initials='K.' surname='Christensen' fullname='K. Christensen'></author>
	    <author initials='B.' surname='Nordman' fullname='B. Nordman'></author>
	 <date month='' year='2008' />
        </front>
        <seriesInfo name='Proc. IEEE Internat. Performance Computing and Communications Conf' value='' />
    </reference>

    <reference anchor='SKILL'>
        <front>
            <title>Skilled in the Art of Being Idle: Reducing Energy Waste in Networked Systems</title>
            <author initials='S.' surname='Nedevschi' fullname='S. Nedevschi'></author>
            <author initials='J.' surname='Liu' fullname='J. Liu'></author>
			<author initials='B.' surname='Nordman' fullname='B. Nordman'></author>
		    <author initials='S.' surname='Ratnasamy' fullname='S. Ratnasamy'></author>
			<author initials='N.' surname='Taft' fullname='N. Taft'></author>
			<date month='' year='2009' />
        </front>
        <seriesInfo name='Proc. USENIX Symposium on Networked Systems Design and Implementation' value='' />
    </reference>
 -->