Diff: rfc9138xml2.original.xml

	rfc9138xml2.original.xml	rfc9138.xml

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


	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [	<!DOCTYPE rfc [
	<!ENTITY rfc1498 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/referenc	<!ENTITY nbsp " ">
	e.RFC.1498.xml">	<!ENTITY zwsp "">
	<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.	<!ENTITY nbhy "‑">
	RFC.2119.xml">	<!ENTITY wj "⁠">
	<!ENTITY rfc2460 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
	RFC.2460.xml">
	<!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/referenc
	e.RFC.6775.xml">
	<!ENTITY rfc6830 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/referenc
	e.RFC.6830.xml">
	<!ENTITY rfc6833 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/referenc
	e.RFC.6833.xml">
	<!ENTITY rfc7252 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/referenc
	e.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">
	]>	]>


	<rfc category="info" docName="draft-irtf-icnrg-nrs-requirements-06" ipr="trust20	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-irtf-icnrg-nrs-re
	0902">	quirements-06" number="9138" ipr="trust200902" obsoletes="" updates="" submissio
		nType="IRTF" category="info" consensus="true" xml:lang="en" tocInclude="true" to
	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>	cDepth="4" symRefs="true" sortRefs="true" version="3">
	<!-- used by XSLT processors -->
	<!-- For a complete list and description of processing instructions (PIs),
	please see http://xml.resource.org/authoring/README.html. -->
	<!-- 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 n
	ew page -->
	<?rfc subcompact="no" ?>
	<!-- keep one blank line between list items -->
	<!-- end of list of popular I-D processing instructions -->


	<!-- *** FRONT MATTER *** -->	<!-- xml2rfc v2v3 conversion 3.9.1 -->
	<front>	<front>

	<!-- The abbreviated title is used in the page header - it is only necessa	<title abbrev="Design Considerations for NRS">Design Considerations for Name
	ry if the	Resolution Service in Information-Centric Networking (ICN)</title>
	full title is longer than 39 characters -->	<seriesInfo name="RFC" value="9138"/>

	<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 -->
	<author fullname="Jungha Hong" initials="J." surname="Hong">	<author fullname="Jungha Hong" initials="J." surname="Hong">

	<organization>ETRI</organization>	<organization>ETRI</organization>
		<address>
	<address>	<postal>
	<postal>	<extaddr>Yuseung-Gu</extaddr>
	<street>218 Gajeong-ro, Yuseung-Gu</street>	<street>218 Gajeong-ro</street>
	<!-- Reorder these if your country does things differently -->	<city>Daejeon</city>
	<city>Daejeon</city>	<code>34129</code>
	<region></region>	<country>Republic of Korea</country>
	<code>34129</code>	</postal>
	<country>Korea</country>	<email>jhong@etri.re.kr</email>
	</postal>
	<phone></phone>
	<email>jhong@etri.re.kr</email>
	<!-- uri and facsimile elements may also be added -->
	</address>	</address>
	</author>	</author>


	<author fullname="Tae-Wan You" initials="T." surname="You">	<author fullname="Tae-Wan You" initials="T." surname="You">

	<organization>ETRI</organization>	<organization>ETRI</organization>
		<address>
	<address>	<postal>
	<postal>	<extaddr>Yuseung-Gu</extaddr>
	<street>218 Gajeong-ro, Yuseung-Gu</street>	<street>218 Gajeong-ro</street>
	<!-- Reorder these if your country does things differently -->	<city>Daejeon</city>
	<city>Daejeon</city>	<code>34129</code>
	<region></region>	<country>Republic of Korea</country>
	<code>34129</code>	</postal>
	<country>Korea</country>	<email>twyou@etri.re.kr</email>
	</postal>
	<phone></phone>
	<email>twyou@etri.re.kr</email>
	<!-- uri and facsimile elements may also be added -->
	</address>	</address>
	</author>	</author>


	<author fullname="Lijun Dong" initials="L." surname="Dong">	<author fullname="Lijun Dong" initials="L." surname="Dong">

	<organization>Futurewei Technologies Inc.</organization>	<organization>Futurewei Technologies Inc.</organization>
		<address>
	<address>	<postal>
	<postal>	<street>10180 Telesis Court</street>
	<street>10180 Telesis Court</street>	<city>San Diego</city>
	<!-- Reorder these if your country does things differently -->	<region>CA</region>
	<city>San Diego</city>	<code>92121</code>
	<region>CA</region>	<country>United States of America</country>
	<code>92121</code>	</postal>
	<country>USA</country>	<email>lijun.dong@futurewei.com</email>
	</postal>
	<phone></phone>
	<email>lijun.dong@futurewei.com</email>
	<!-- uri and facsimile elements may also be added -->
	</address>	</address>
	</author>	</author>

		<author fullname="Cedric Westphal" initials="C." surname="Westphal">
	<author fullname="Cedric Westphal" initials="C." surname="Westphal">	<organization>Futurewei Technologies Inc.</organization>
	<organization>Futurewei Technologies Inc.</organization>	<address>
		<postal>
	<address>	<street>2330 Central Expressway</street>
	<postal>	<city>Santa Clara</city>
	<street>2330 Central Expressway</street>	<region>CA</region>
	<!-- Reorder these if your country does things differently -->	<code>95050</code>
	<city>Santa Clara</city>	<country>United States of America</country>
	<region>CA</region>	</postal>
	<code>95050</code>	<email>cedric.westphal@futurewei.com</email>
	<country>USA</country>
	</postal>
	<phone></phone>
	<email>cedric.westphal@futurewei.com</email>
	<!-- uri and facsimile elements may also be added -->
	</address>	</address>
	</author>	</author>

		<author fullname="Börje Ohlman" initials="B." surname="Ohlman">
	<author fullname="Borje Ohlman" initials="B." surname="Ohlman">	<organization abbrev="Ericsson">Ericsson Research</organization>
	<organization abbrev="Ericsson">Ericsson Research</organization>	<address>
		<postal>
	<address>	<city>Stockholm</city>
	<postal>	<code>16480</code>
	<street>S-16480 Stockholm</street>	<country>Sweden</country>
	<!-- Reorder these if your country does things differently -->	</postal>
	<city></city>	<email>Borje.Ohlman@ericsson.com</email>
	<region></region>
	<code></code>
	<country>Sweden</country>
	</postal>
	<phone></phone>
	<email>Borje.Ohlman@ericsson.com</email>
	<!-- uri and facsimile elements may also be added -->
	</address>	</address>
	</author>	</author>

		<date month="November" year="2021"/>


	<date day="28" month="July" year="2021" />
	<!-- If the month and year are both specified and are the current ones, xml2
	rfc 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 sp
	ecified for the
	purpose of calculating the expiry date). With drafts it is normally suf
	ficient to
	specify just the year. -->

	<!-- Meta-data Declarations -->
	<area>ICNRG</area>	<area>ICNRG</area>

		<workgroup>Information-Centric Networking</workgroup>
	<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. -->

	<abstract>	<abstract>
	<t>	<t>
	This document provides the functionalities and design considerations	This document provides the functionalities and design considerations

	for a Name Resolution Service (NRS) in ICN. An NRS in ICN is to transla	for a Name Resolution Service (NRS) in Information-Centric Networking (I
	te	CN).

		The purpose of an NRS in ICN is to translate
	an object name into some other information such as a locator, another	an object name into some other information such as a locator, another

	name, etc. for forwarding the object request. This document is a product	name, etc. in order to forward the object request. This document is a pr oduct
	of the Information-Centric Networking Research Group (ICNRG).	of the Information-Centric Networking Research Group (ICNRG).
	</t>	</t>
	</abstract>	</abstract>

	</front>


		</front>
	<middle>	<middle>

		<section numbered="true" toc="default">
	<section title="Introduction">	<name>Introduction</name>
		<t>
	<t>
	The current Internet is based upon a host-centric networking paradigm, where hosts are	The current Internet is based upon a host-centric networking paradigm, where hosts are
	identified with IP addresses and communication is possible	identified with IP addresses and communication is possible
	between any pair of hosts. Thus, information in the current Internet	between any pair of hosts. Thus, information in the current Internet

	is identified by the name of the host (or server) where information is stored.	is identified by the name of the host (or server) where the informatio n is stored.
	In contrast to host-centric networking, the primary communication	In contrast to host-centric networking, the primary communication

	objects in Information-centric networking (ICN) are the named data	objects in Information-Centric Networking (ICN) are the named data
	objects (NDOs) and they are uniquely identified by location-independen	objects (NDOs), and they are uniquely identified by location-independe
	t	nt
	names. Thus, ICN aims for the efficient dissemination and retrieval of	names. Thus, ICN aims for the efficient dissemination and retrieval of

	NDOs at a global scale, and has been identified and acknowledged as a	NDOs at a global scale and has been identified and acknowledged as a
	promising technology for a future Internet architecture to overcome	promising technology for a future Internet architecture to overcome

	the limitations of the current Internet such as scalability and	the limitations of the current Internet, such as scalability and
	mobility <xref target="Ahlgren"></xref> <xref target="Xylomenos"></xre	mobility <xref target="Ahlgren" format="default"/> <xref target="Xylom
	f>.	enos" format="default"/>.
	ICN also has emerged as a candidate architecture in the IoT environmen	ICN also has emerged as a candidate architecture in the Internet of Th
	t	ings (IoT) environment
	since IoT focuses on data and information	since IoT focuses on data and information

	<xref target="Baccelli"></xref> <xref target="Amadeo"></xref> <xref ta	<xref target="Baccelli" format="default"/> <xref target="Amadeo" forma
	rget="Quevedo"></xref>	t="default"/> <xref target="Quevedo" format="default"/>
	<xref target="Amadeo2"></xref> <xref target="ID.Zhang2"></xref>.	<xref target="Amadeo2" format="default"/> <xref target="I-D.irtf-icnrg-i
	</t>	cniot" format="default"/>.
		</t>
	<t>Since naming data independently from its current location (where it i	<t>Since naming data independently from its current location (where it is
	s
	stored) is a primary concept of ICN, how to find any NDO using a	stored) is a primary concept of ICN, how to find any NDO using a
	location-independent name is one of the most important design challeng es	location-independent name is one of the most important design challeng es

	in ICN. Such ICN routing may comprise three steps <xref target="RFC792	in ICN. Such ICN routing may comprise three steps <xref target="RFC792
	7"></xref>:	7" format="default"/>:
	</t>	</t>

	<t>
	<list style="symbols">
	<t>Name resolutio
	n: matches/translates a content name to the locator
	of content producer or source that can provide the content. </
	t>
	<t>Content reques
	t routing: routes the content request towards
	the content's location either based on its name or locator. </
	t>
	<t>Content delive
	ry: transfers the content to the requester. </t>
	</list>
	</t>


	<t>	<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
		. </li>
		<li>Content request routing: routes the content request towards
		the content's location based either on its name or locator. </
		li>
		<li>Content delivery: transfers the content to the requester. </li>
		</ol>
		<t>
	Among the three steps of ICN routing, this document investigates only	Among the three steps of ICN routing, this document investigates only

	the name resolution step which translates a content name to the conten t locator.	the name resolution step, which translates a content name to the conte nt locator.
	In addition, this document covers various possible types of name	In addition, this document covers various possible types of name
	resolution in ICN such as one name to another name, name to locator,	resolution in ICN such as one name to another name, name to locator,
	name to manifest, name to metadata, etc.	name to manifest, name to metadata, etc.

	</t>	</t>
		<t>
	<t>
	The focus of this document is a Name Resolution Service (NRS) itself	The focus of this document is a Name Resolution Service (NRS) itself

	as a service or a system in ICN and it provides the functionalities an d	as a service or a system in ICN, and it provides the functionalities a nd
	the design considerations for an NRS in ICN as well as the overview of	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	the NRS approaches in ICN. On the other hand, its companion document

	<xref target="NRSarch"></xref> describes considerations from the persp	<xref target="I-D.irtf-icnrg-nrsarch-considerations" format="default"/
	ective	> describes considerations from the perspective
	of ICN architecture and routing system when using an NRS in ICN.	of the ICN architecture and routing system when using an NRS in ICN.
	</t>	</t>
		<t>
	<t>
	This document represents the consensus of the Information-Centric	This document represents the consensus of the Information-Centric
	Networking Research Group (ICNRG). It has been reviewed extensively	Networking Research Group (ICNRG). It has been reviewed extensively
	by the Research Group (RG) members who are actively involved in the	by the Research Group (RG) members who are actively involved in the
	research and development of the technology covered by this document.	research and development of the technology covered by this document.
	It is not an IETF product and is not a standard.	It is not an IETF product and is not a standard.

	</t>	</t>

	</section>

	<!--
	<section title="Conventions and Terminology">
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SH
	OULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are t
	o be interpreted as described in <xref target="RFC2119"></xref>.</t>
	</section>	</section>

	<section title="Name Resolution Service in ICN">	<section numbered="true" toc="default">
		<name>Name Resolution Service in ICN</name>
	<t>	<t>
	A Name Resolution Service (NRS) in ICN is defined as the service that	A Name Resolution Service (NRS) in ICN is defined as the service that
	provides the name resolution function for translating an object name	provides the name resolution function for translating an object name
	into some other information such as a locator, another name, metadata,	into some other information such as a locator, another name, metadata,

	next hop info, etc. that is used for forwarding the object request.	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	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 informa tion	infrastructure to help a consumer reach a specific piece of informatio n
	(or named data object). The consumer provides an NRS with a persistent	(or named data object). The consumer provides an NRS with a persistent

	name and the NRS returns a name or locator (or potentially multiple	name, and the NRS returns a name or locator (or potentially multiple
	names and locators) that can reach a current instance of the	names and locators) that can reach a current instance of the
	requested object.	requested object.

	</t>	</t>
		<t>
	<t>	The name resolution is a necessary process in ICN routing, although the
	The name resolution is a necessary process in ICN routing although the
	name resolution either can be separated from the content request routin g	name resolution either can be separated from the content request routin g
	as an explicit process or can be integrated with the content request	as an explicit process or can be integrated with the content request

	routing as an implicit process. The former is referred as explicit nam	routing as an implicit process. The former is referred to as an "expli
	e	cit name
	resolution approach, the latter is referred as name-based routing appro	resolution approach", and the latter is referred to as a "name-based ro
	ach	uting approach"
	in this document.	in this document.

	</t>	</t>
		<section numbered="true" toc="default">
	<section title="Explicit name resolution approach">	<name>Explicit Name Resolution Approach</name>
		<t>
	<t>
	An NRS could take the explicit name resolution approach to return the	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 under lying	locators of the content to the client, which will be used by the under lying
	network as the identifier to route the client's request to one of the	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	producers or to a copy of the content. There are several ICN projects

	that use the explicit name resolution approach such as DONA	that use the explicit name resolution approach, such as Data-Oriented
	<xref target="Koponen"></xref>, PURSUIT <xref target="PURSUIT"></xref>	Network Architecture (DONA) <xref target="Koponen" format="default"/>, PURSUIT
	,	<xref target="PURSUIT" format="default"/>,
	NetInf <xref target="SAIL"></xref>, MobilityFirst <xref target="MF"></	Network of Information (NetInf) <xref target="SAIL" format="default"/>
	xref>,	, MobilityFirst <xref target="MF" format="default"/>,
	IDNet <xref target="Jung"></xref>, etc. In addition, the explicit name	IDNet <xref target="Jung" format="default"/>, etc. In addition, the ex
	resolution approach has been allowed for 5G control planes <xref targe	plicit name
	t="SA2-5GLAN"></xref>.	resolution approach has been allowed for 5G control planes <xref targe
	</t>	t="SA2-5GLAN" format="default"/>.
		</t>
	</section>	</section>
		<section numbered="true" toc="default">
	<section title="Name-based routing approach">	<name>Name-Based Routing Approach</name>
		<t>An NRS could take the name-based routing approach, which integrates
	<t>An NRS could take the name-based routi	name resolution with content request message routing as in
	ng approach, which integrates	Named Data Networking / Content-Centric Networking (NDN/CCNx) <xref
	the name resolution with the content request message routing as in	target="NDN" format="default"/> <xref target="CCNx" format="default"/>.
	NDN <xref target="NDN"></xref>/CCNx <xref target="CCNx"></xref>.	</t>
	</t>	<t>
		In cases where the content request also specifies the reverse path,
	<t>
	In the case that the content request also specifies the reverse path
	,
	as in NDN/CCNx, the name resolution mechanism also derives the routi ng	as in NDN/CCNx, the name resolution mechanism also derives the routi ng

	path for the data. This adds a requirement on the name resolution	path for the data. This adds a requirement to the name resolution
	service to propagate request in a way that is consistent with the	service to propagate the request in a way that is consistent with th
		e
	subsequent data forwarding. Namely, the request must select a path	subsequent data forwarding. Namely, the request must select a path

	for the data based upon finding a copy of the content, but also	for the data based upon finding a copy of the content but also
	properly delivering the data.	properly delivering the data.

	</t>	</t>
		</section>
	</section>	<section numbered="true" toc="default">
		<name>Hybrid Approach</name>
	<section title="Hybrid approach">	<t>

	<t>
	An NRS could also take hybrid approach. For instance, it can attempt	An NRS could also take hybrid approach. For instance, it can attempt
	the name-based routing approach first. If this fails at a certain	the name-based routing approach first. If this fails at a certain
	router, the router can go back to the explicit name resolution appro ach.	router, the router can go back to the explicit name resolution appro ach.

	The hybrid NRS approach also works the other way around by performin	The hybrid NRS approach also works the other way around: first by pe
	g	rforming
	explicit name resolution first to find locators of routers. And then	explicit name resolution to find the locators of routers, then by ro
	it can carry out the name-based routing approach of the client's req	uting the client's request using the name-based routing approach.
	uest.	</t>
	</t>	<t>

	<t>
	A hybrid approach would combine name resolution over a subset of	A hybrid approach would combine name resolution over a subset of
	routers on the path with some tunneling in between (say, across an	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	administrative domain) so that only a few of the nodes in the ICN
	network perform name resolution in the name-based routing approach.	network perform name resolution in the name-based routing approach.

	</t>	</t>
		</section>
	</section>	<section numbered="true" toc="default">
		<name>Comparisons of Name Resolution Approaches</name>
	<section title="Comparisons of name resolution approaches	<t>
	">

	<t>
	The following compares the explicit name resolution and the name-base d	The following compares the explicit name resolution and the name-base d

	routing approaches for several aspects:	routing approaches in several aspects:
	</t>	</t>

		<ul spacing="normal">
	<t>	<li>Overhead due to the maintenance of the content location:
	<list style="symbols">
	<t>Overhead due t
	o the maintenance of the content location:
	The content reachability is dynamic and includes new	The content reachability is dynamic and includes new
	content being cached or content being expired from a cache,	content being cached or content being expired from a cache,
	content producer mobility, etc. Maintaining a consistent	content producer mobility, etc. Maintaining a consistent
	view of the content location across the network requires	view of the content location across the network requires
	some overhead that differs for the name resolution approaches.	some overhead that differs for the name resolution approaches.
	The name-based routing approach may require flooding	The name-based routing approach may require flooding
	parts of the network for update propagation. In the worst	parts of the network for update propagation. In the worst
	case, the name-based routing approach may flood the whole netw ork	case, the name-based routing approach may flood the whole netw ork
	(but mitigating techniques may be used to scope the flooding).	(but mitigating techniques may be used to scope the flooding).
	However, the explicit name resolution approach only requires	However, the explicit name resolution approach only requires
	updating propagation in part of the name resolution system	updating propagation in part of the name resolution system

	(which could be an overlay with a limited number of nodes). </	(which could be an overlay with a limited number of nodes). </
	t>	li>
	<t>Resolution cap	<li>Resolution capability: The explicit name resolution approach, if d
	ability: The explicit name resolution approach, if designed and deployed with su	esigned and deployed with sufficient robustness, can offer at least weak guarant
	fficient robustness, can offer at least weak guarantees that resolution will suc	ees that resolution will succeed for any content name in the network if it is re
	ceed for any content name in the network if it is registered to the name resolut	gistered to the name resolution overlay.
	ion overlay.	In the name-based routing approach, content resolution depends
	In the name-based routing approach, content resolution depends	on the flooding scope of the content names (i.e., content publishing message an
	on the flooding scope of the content names (i.e. content publishing message and	d the resulting name-based routing tables).
	the resulting name-based routing tables).	For example, when content is cached, the router may only notif
	For example, when a content is cached, the router may only not	y its direct neighbors of this information. Thus, only those neighboring
	ify this information to its direct neighbors. Thus, only those neighboring route	routers can build a name-based entry for this cached content.
	rs can build a named based entry for this cached content.	But if the neighboring routers continue to propagate this info
	But if the neighboring routers continue to propagate this info	rmation, the other nodes are able to direct to this cached copy as well. </li>
	rmation, the other nodes are able to direct to this cached copy as well. </t>
	<t>Node failure i
	mpact: Nodes involved in the explicit name resolution approach are the name reso
	lution overlay servers (e.g. Resolution Handlers in DONA),
	while the nodes involved in the name-based routing approach ar
	e routers which route messages based on the name-based routing tables (e.g. NDN
	routers).
	Node failures in the explicit name resolution approach may cau
	se 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 rout
	ers, given the assumption that the network is still connected.</t>
	<t>Maintained dat
	abases: 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 maint
	ain two databases: name to locator mapping in the name resolution overlay and ro
	uting tables in the routers on the data forwarding plane.
	The name-based routing approach needs to maintain only the na
	me-based routing tables.</t>
	</list>
	</t>

	<t>Additionally, some other intermediary step may be included in the nam
	e resolution, namely the mapping of one name to other names, in order to facilit
	ate the retrieval of named content, by way of a manifest <xref target="Westphal"
	></xref> <xref target="Mosko"></xref>.
	The manifest is resolved using one of the two above approaches, and it m
	ay include further mapping of names to content and location. The steps for name
	resolution then become: first translate the manifest name into a location of a c
	opy of the manifest; the manifest includes further names of the content componen
	ts, and potentially locations for the content.
	The content is then retrieved by using these names and/or location, pote
	ntially resulting in additional name resolutions. </t>


		<li>Node failure impact: Nodes involved in the explicit name resolutio
		n approach are the name resolution overlay servers (e.g., resolution handlers in
		DONA),
		while the nodes involved in the name-based routing approach ar
		e routers that route messages based on the name-based routing tables (e.g., NDN
		routers).
		Node failures in the explicit name resolution approach may cau
		se 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 rout
		ers, given the assumption that the network is still connected.</li>
		<li>Maintained databases: The storage usage for the explicit name reso
		lution approach is different from that of the name-based routing approach.
		The explicit name resolution approach typically needs to maint
		ain two databases: name-to-locator mapping in the name resolution overlay and ro
		uting tables in the routers on the data forwarding plane.
		The name-based routing approach needs to maintain only the na
		me-based routing tables.</li>
		</ul>
		<t>Additionally, some other intermediary step may be included in the nam
		e resolution -- namely, the mapping of one name to other names -- in order to fa
		cilitate the retrieval of named content by way of a manifest <xref target="Westp
		hal" format="default"/> <xref target="RFC8569" format="default"/>.
		The manifest is resolved using one of the two above approaches, and it m
		ay include further mapping of names to content and location.
		The steps for name resolution then become the following: first, translate the ma
		nifest name into a location of a copy of the manifest, which includes further na
		mes of the content components and potentially locations for the content, then re
		trieve the content by using these names and/or location, potentially resulting i
		n additional name resolutions. </t>
	<t>Thus, no matter which approach is taken by an NRS in ICN, the name re solution is the essential function that shall be provided by the ICN infrastruct ure. </t>	<t>Thus, no matter which approach is taken by an NRS in ICN, the name re solution is the essential function that shall be provided by the ICN infrastruct ure. </t>

		</section>
	</section>	</section>
		<section numbered="true" toc="default">
	</section>	<name>Functionalities of NRS in ICN</name>
		<t>This section presents the functionalities of an NRS in ICN. </t>
	<section title="Functionalities of NRS in ICN">	<section numbered="true" toc="default">
	<t>This section presents the functionalities of an NRS in ICN. </t>	<name>Support Heterogeneous Name Types</name>
		<t>
	<section title="Support heterogeneous name types">	In ICN, a name is used to identify the data object and is bound to it
	<t>	<xref target="RFC7927" format="default"/>.
	In ICN, a name is used to identify data object and is bound to it <xre	ICN requires uniqueness and persistency of the name of the data object
	f target="RFC7927"></xref>.	to ensure the
	ICN requires uniqueness and persistency of the name of data object to
	ensure the
	reachability of the object within a certain scope. There are	reachability of the object within a certain scope. There are

	heterogeneous approaches to designing ICN naming schemes <xref target= "Bari"></xref>.	heterogeneous approaches to designing ICN naming schemes <xref target= "Bari" format="default"/>.
	Ideally, a name can include any form of identifier, which can be	Ideally, a name can include any form of identifier, which can be

	flat or hierarchical, and human readable or non-readable.	flat or hierarchical, human readable or non-readable.
	</t>	</t>


	<t>	<t>

	Although there are diverse types of naming schemes proposed in literat	Although there are diverse types of naming schemes proposed in the lit
	ure,	erature,
	they all need to provide basic functions for identifying data object,	they all need to provide basic functions for identifying a data object
	supporting named data lookup and routing. An NRS may combine the bette	,
	r	supporting named data lookup, and routing. An NRS may combine the bett
		er
	aspects of different schemes. Basically, an NRS should be able to supp ort	aspects of different schemes. Basically, an NRS should be able to supp ort
	a generic naming schema so that it can resolve any type of content nam e,	a generic naming schema so that it can resolve any type of content nam e,

	irrespective of whether it is flat, hierarchical, attribute-based or	irrespective of whether it is flat, hierarchical, attribute based, or
	anything else.	anything else.
	</t>	</t>


	<t>	<t>

	In PURSUIT <xref target="PURSUIT"></xref>, names are flat and the rend	In PURSUIT <xref target="PURSUIT" format="default"/>, names are flat,
	ezvous	and the rendezvous
	functions are defined for an NRS, which is implemented by a set of Ren	functions are defined for an NRS, which is implemented by a set of ren
	dezvous	dezvous
	Nodes (RNs), the Rendezvous Network (RENE). Thus, a name consists of a	nodes (RNs), known as the rendezvous network (RENE). Thus, a name cons
	sequence of scope IDs and a single rendezvous ID is routed by the RNs	ists of a
	in RENE.	sequence of scope IDs, and a single rendezvous ID is routed by the RNs
		in RENE.
	Thus, PURSUIT decouples name resolution and data routing, where the NR S	Thus, PURSUIT decouples name resolution and data routing, where the NR S
	is performed by the RENE.	is performed by the RENE.
	</t>	</t>


	<t>	<t>

	In MobilityFirst <xref target="MF"></xref>, a name called a Global	In MobilityFirst <xref target="MF" format="default"/>, a name known as
	Unique IDentifier (GUID) derived from a human-readable name via a glob	a "Global
	al	Unique Identifier (GUID)", derived from a human-readable name via a gl
	naming service is a flat typed 160-bits string with self-certifying	obal
		naming service, is a flat typed 160-bit string with self-certifying
	properties. Thus, MobilityFirst defines a Global Name Resolution Servi ce	properties. Thus, MobilityFirst defines a Global Name Resolution Servi ce

	(GNRS) which resolves GUIDs to network addresses and decouples name	(GNRS), which resolves GUIDs to network addresses and decouples name
	resolution and data routing similarly to PURSUIT.	resolution and data routing similarly to PURSUIT.
	</t>	</t>


	<t>	<t>

	In NetInf <xref target="Dannewitz"></xref>, information objects are na	In NetInf <xref target="Dannewitz" format="default"/>, information obj
	med using ni-naming <xref target="RFC6920"></xref>, which consist of an authorit	ects are named using Named Information (NI) names <xref target="RFC6920" format=
	y part and digest part (content hash).	"default"/>, which consist of an authority part and digest part (content hash).
	The ni names can be flat as the authority part is optional. Thus, the	The NI names can be flat as the authority part is optional. Thus, the
	NetInf architecture also includes a Name Resolution System (NRS) which can be us	NetInf architecture also includes a Name Resolution System (NRS), which can be u
	ed to resolve ni-names to addresses in an underlying routable network layer.	sed to resolve NI names to addresses in an underlying routable network layer.
	</t>	</t>


	<t>	<t>

	In NDN <xref target="NDN"></xref> and CCNx <xref target="CCNx"></xref> ,	In NDN <xref target="NDN" format="default"/> and CCNx <xref target="CC Nx" format="default"/>,
	names are hierarchical and may be similar to URLs. Each name component	names are hierarchical and may be similar to URLs. Each name component
	can be anything, including a human-readable string or a hash value.	can be anything, including a human-readable string or a hash value.
	NDN/CCNx adopts the name-based routing approach. The NDN router forwar ds	NDN/CCNx adopts the name-based routing approach. The NDN router forwar ds
	the request by doing the longest-match lookup in the Forwarding	the request by doing the longest-match lookup in the Forwarding

	Information Base (FIB) based on the content name and the request is	Information Base (FIB) based on the content name, and the request is
	stored in the Pending Interest Table (PIT).	stored in the Pending Interest Table (PIT).
	</t>	</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 p
	ersistency of the name of any entity to ensure the reachability of the entity wi
	thin 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 identi
	fier, 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 resolut
	ion 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 principa
	l'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 ca
	lled Resolution Handlers (RHs). </t>
	<t>Content in PUR
	SUIT <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 dissem
	ination strategy for the content it contain. The rendezvous ID is the actual ide
	ntity for a particular content. Name resolution in PURSUIT is handled by a colle
	ction 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 an
	d may be similar to URLs. Each name component can be anything, including a dotte
	d 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 For
	warding Information Base (FIB) based on the content name and the request is stor
	ed in the Pending Interest Table (PIT). </t>
	<t>In MobilityFir
	st <xref target="MF"></xref>, every network entity, content has a Global Unique
	Identifier (GUID). GUIDs are flat 160-bit strings with no semantic structure. Na
	me Resolution in MobilityFirst is carried out via a Global Name Resolution Servi
	ce (GNRS). </t>
	</list>
	</t>

	<t>Although the existing naming schemes are diffe
	rent, they all need to provide basic functions for identifying a content, suppor
	ting trust provenance, content lookup and routing. The NRS may combine the advan
	tages of different mechanisms. The NRS should be able to support a generic namin
	g schema to resolve any type of content name, either it is flat or hierarchical.
	</t>
	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Support producer mobility">	<name>Support Producer Mobility</name>
		<t>
	<t>	ICN inherently supports mobility by consumers. Namely, consumer or cl
	ICN natively supports mobility management. Namely, consumer or client	ient
	mobility is handled by re-requesting the content in case the mobility	mobility is handled by re-requesting the content in case the mobility
	event (say, handover) occurred before receiving the corresponding	event (say, handover) occurred before receiving the corresponding
	content from the network. Since ICN can ensure that content reception	content from the network. Since ICN can ensure that content reception
	continues without any disruption in ICN applications, seamless mobili ty	continues without any disruption in ICN applications, seamless mobili ty
	from the consumer's point of view can be easily supported.	from the consumer's point of view can be easily supported.

	</t>	</t>
		<t>
	<t>
	However, producer mobility does not emerge naturally from the ICN	However, producer mobility does not emerge naturally from the ICN
	forwarding model as does consumer mobility. If a producer moves into	forwarding model as does consumer mobility. If a producer moves into
	a different network location or a different name domain, which is	a different network location or a different name domain, which is
	assigned by another authoritative publisher, it would be difficult fo r	assigned by another authoritative publisher, it would be difficult fo r

	the mobility management to update RIB and FIB entries in ICN routers	the mobility management to update Routing Information Base (RIB) and FIB entries in ICN routers
	with the new forwarding path in a very short time. Therefore, various	with the new forwarding path in a very short time. Therefore, various

	ICN architectures in the literature have proposed to adopt an NRS to	ICN architectures in the literature have proposed adopting an NRS to
	achieve the producer or publisher mobility, where the NRS can be	achieve the producer or publisher mobility, where the NRS can be
	implemented in different ways such as rendezvous points and/or overla y mapping systems.	implemented in different ways such as rendezvous points and/or overla y mapping systems.

	</t>	</t>
		<t>
	<t>	In NDN <xref target="Zhang2" format="default"/>, for producer mobilit
	In NDN <xref target="Zhang2"></xref>, for producer mobility support,	y support, rendezvous mechanisms have been proposed to build interest rendezvous
	rendezvous mechanisms have been proposed to build interests rendezvou
	s
	(RV) with data generated by a mobile producer (MP). This can be	(RV) with data generated by a mobile producer (MP). This can be

	classified into two approaches: chase mobile producer; and rendezvous data.	classified into two approaches: chase mobile producer and rendezvous data.
	Regarding MP chasing, rendezvous acts as a mapping service that provi des	Regarding MP chasing, rendezvous acts as a mapping service that provi des
	the mapping from the name of the data produced by the MP to the name	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	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	serves as a home agent as in IP mobility support, so the RV enables

	consumer's interest message to tunnel towards the MP at the PoA.	the consumer's Interest message to tunnel towards the MP at the PoA.
	Regarding rendezvous data, the solution involves moving the data prod uced	Regarding rendezvous data, the solution involves moving the data prod uced

	by the MP to a data depot instead of forwarding interest messages. Th	by the MP to a data depot instead of forwarding Interest messages.
	us,
	a consumer's interest message can be forwarded to stationary place as	Thus,
	called data rendezvous, so it would either return the data or fetch i	a consumer's Interest message can be forwarded to stationary place ca
	t	lled a "data rendezvous", so it would either return the data or fetch it
	using another mapping solution. Therefore, RV or other mapping functi ons	using another mapping solution. Therefore, RV or other mapping functi ons
	are in the role of an NRS in NDN.	are in the role of an NRS in NDN.

	</t>	</t>
		<t>
	<t>	In <xref target="I-D.ravi-icnrg-ccn-forwarding-label" format="default"
	In <xref target="Ravindran"></xref>, forwarding-label (FL) object is	/>, the forwarding label (FL) object is
	referred to enable identifier (ID) and locator (LID) namespaces to be	used to enable identifier (ID) and locator (LID) namespaces to be
	split in ICN. Generally, IDs are managed by applications, while locato rs	split in ICN. Generally, IDs are managed by applications, while locato rs

	are managed by a network administrator, so that IDs are mapping to	are managed by a network administrator so that IDs are mapped to
	heterogeneous name schemes and LIDs are mapping to the network domains	heterogeneous name schemes and LIDs are mapped to the network domains
	or	or
	to specific network elements. Thus, the proposed FL object acts as a l ocator	to specific network elements. Thus, the proposed FL object acts as a l ocator
	(LID) and provides the flexibility to forward Interest messages throug h	(LID) and provides the flexibility to forward Interest messages throug h

	mapping service between IDs and LIDs. Therefore, the mapping service i n	a mapping service between IDs and LIDs. Therefore, the mapping service in
	control plane infrastructure can be considered as an NRS in this draft .	control plane infrastructure can be considered as an NRS in this draft .
	</t>	</t>

		<t>
	<t>	In MobilityFirst <xref target="MF" format="default"/>, both consumer a
	In MobilityFirst <xref target="MF"></xref>, both consumer and publishe	nd publisher
	r
	mobility can be primarily handled by the global name resolution servic e	mobility can be primarily handled by the global name resolution servic e

	(GNRS) which resolves GUIDs to network addresses. Thus, the GNRS must	(GNRS), which resolves GUIDs to network addresses. Thus, the GNRS mus
	be updated for mobility support when a network attached object changes	t
		be updated for mobility support when a network-attached object changes
	its point of attachment, which differs from NDN/CCNx.	its point of attachment, which differs from NDN/CCNx.
	</t>	</t>


	<t>	<t>

	In NetInf <xref target="Dannewitz"></xref>, mobility is handled by	In NetInf <xref target="Dannewitz" format="default"/>, mobility is han dled by
	an NRS in a very similar way to MobilityFirst.	an NRS in a very similar way to MobilityFirst.
	</t>	</t>

		<t>
	<t>	Besides the consumer and producer mobility, ICN also faces
	Besides the consumer and producer mobility, ICN also has to face
	challenges to support the other dynamic features such as multi-homing ,	challenges to support the other dynamic features such as multi-homing ,
	migration, and replication of named resources such as content, device s,	migration, and replication of named resources such as content, device s,
	and services. Therefore, an NRS can help to support these dynamic fea tures.	and services. Therefore, an NRS can help to support these dynamic fea tures.

	</t>	</t>
	<!--
	<t>In ICN literature, it is said that mobility can be achieved in fundam
	ental feature of ICN. Especially, consumer or client mobility can be achieved by
	requesting information again according to the basic procedure from different in
	terfaces or through attachment point of the new network. Moreover, seamless mobi
	lity service in ICN ensures that content reception continues without any disrupt
	ion in ICN application, so in consumer point of view, seamless mobility can be e
	asily supported. </t>

	<t>However, producer or publisher mobility in ICN
	is more complicated to be supported. If a producer moves into different authori
	ty domain or network location, then the request for a content published by the m
	oving puroducer with origin name would be hardly forwarded to the moving produce
	r since the routing tables related in broad area should be updated according to
	the producer movement. Therefore, various ICN literatures would adopt NRS to ach
	ieve the producer or publisher mobility, where NRS can be implemented in differe
	nt 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 re
	sources such as content, devices, services, etc. and NRS may help to support the
	dynamism features. </t>
	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Support scalable routing system">	<name>Support Scalable Routing System</name>
		<t>
	<t>
	In ICN, the name of data objects is used for routing by either a name	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	resolution step or a routing table lookup. Thus, routing information
	for each data object should be maintained in the routing base, such	for each data object should be maintained in the routing base, such

	as Routing Information Base (RIB) and Forwarding Information Base (FI B).	as RIB and FIB.
	Since the number of data objects would be very large, the size of	Since the number of data objects would be very large, the size of

	information bases would be significantly larger as well <xref target=	information bases would be significantly larger as well <xref target=
	"RFC7927"></xref>.	"RFC7927" format="default"/>.
	</t>	</t>
		<t>
	<t>	The hierarchical namespace used in CCNx <xref target="CCNx" format="d
	The hierarchical namespace used in CCNx <xref target="CCNx"></xref>	efault"/>
	and NDN <xref target="NDN"></xref> architectures reduces the size of	and NDN <xref target="NDN" format="default"/> architectures reduces t
		he size of
	these tables through name aggregation and improves the scalability of	these tables through name aggregation and improves the scalability of
	the routing system. A flat naming scheme, on the other hand, would	the routing system. A flat naming scheme, on the other hand, would
	aggravate the scalability problem of the routing system.	aggravate the scalability problem of the routing system.

	The non-aggregated name prefixes injected to the Default Route Free	The non-aggregated name prefixes injected into the Default Route Free
	Zone (DFZ) of ICN would create more serious scalability problem when	Zone (DFZ) of ICN would create a more serious scalability problem whe
		n
	compared to the scalability issues of the IP routing system.	compared to the scalability issues of the IP routing system.
	Thus, an NRS may play an important role in the reduction of the routi ng	Thus, an NRS may play an important role in the reduction of the routi ng
	scalability problem regardless of the types of namespaces.	scalability problem regardless of the types of namespaces.

	</t>	</t>
		<t>
	<t>	In <xref target="Afanasyev" format="default"/>, in order to address t
	In <xref target="Afanasyev"></xref>, in order to address the routing	he routing
	scalability problem in NDN's DFZ, a well-known concept of Map-and-En	scalability problem in NDN's DFZ, a well-known concept called "map-an
	cap	d-encap" is applied to provide a simple and secure namespace mapping solution.
	is applied to provide a simple and secure namespace mapping solution.
	In the proposed map-and-encap design, data whose name prefixes do not	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	exist in the DFZ forwarding table can be retrieved by a distributed

	mapping system called NDNS, which maintains and lookups the mapping	mapping system called NDNS, which maintains and looks up the mapping
	information from a name to its globally routed prefixes, where NDNS i s	information from a name to its globally routed prefixes, where NDNS i s
	a kind of an NRS.	a kind of an NRS.

	</t>	</t>
	<!--

	<t>In ICN, data objects must be identified by names regardless their lo
	cation or container <xref target="RFC7927"></xref> and the names are divided int
	o 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 hierarc
	hy 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 routi
	ng is not easy since names in a flat namespace cannot be aggregated anymore, whi
	ch would cause more the scalability problem in routing system. In order to addre
	ss such problem, a flat name can be resolved to some information which is routab
	le through NRS. </t>

	<t>In ICN, application names identifying contents are used directl
	y 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-agg
	regated 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 th
	e same as the scalability issue of IP routing. Thus a solution to keep the routi
	ng table size under control is needed, which can be done by defining indirection
	layer. </t>
	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Support off-path caching">	<name>Support Off-Path Caching</name>
	<t>	<t>
	Caching in-network is considered to be a basic architectural component	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-o	of an ICN architecture. It may be used to provide a level of quality-o
	f-Service (QoS)	f-service (QoS)
	experience to users, to reduce the overall network traffic, to prevent	experience to users to reduce the overall network traffic, to prevent
	network	network
	congestion and Denial-of-Service (DoS) attacks and to increase availab	congestion and denial-of-service (DoS) attacks, and to increase availa
	ility.	bility.
	Caching approaches can be categorized into off-path caching and on-pat h	Caching approaches can be categorized into off-path caching and on-pat h
	caching based on the location of caches in relation to the forwarding	caching based on the location of caches in relation to the forwarding
	path from the original server to the consumer. Off-path caching, also	path from the original server to the consumer. Off-path caching, also

	referred as content replication or content storing, aims to replicate	referred to as "content replication" or "content storing", aims to rep licate
	content within a network in order to increase availability, regardless of	content within a network in order to increase availability, regardless of
	the relationship of the location to the forwarding path. Thus, finding	the relationship of the location to the forwarding path. Thus, finding
	off-path cached objects is not trivial in name-based routing of ICN.	off-path cached objects is not trivial in name-based routing of ICN.
	In order to support off-path caches, replicas are usually advertised	In order to support off-path caches, replicas are usually advertised
	into a name-based routing system or into an NRS.	into a name-based routing system or into an NRS.
	</t>	</t>

		<t>
	<t>	In <xref target="Bayhan" format="default"/>, an NRS is used to find of
	In <xref target="Bayhan"></xref>, an NRS is used to find off-path copi	f-path copies
	es
	in the network, which may not be accessible via name-based routing mec hanisms.	in the network, which may not be accessible via name-based routing mec hanisms.

	Such capability can be helpful for an Autonomous System (AS) to avoid	Such a capability can be helpful for an Autonomous System (AS) to avoi d
	the costly inter-AS traffic for external content more, to yield higher	the costly inter-AS traffic for external content more, to yield higher
	bandwidth efficiency for intra-AS traffic, and to decrease the data	bandwidth efficiency for intra-AS traffic, and to decrease the data
	access latency for a pleasant user experience.	access latency for a pleasant user experience.

	</t>

	</section>

	<section title="Support nameless object">

	<t>
	In CCNx 1.0 <xref target="Mosko2"></xref>, the concept of "Nameless
	Objects" that are a Content Object without a Name is introduced to
	provide a means to move Content between storage replicas without havin
	g
	to rename or re-sign the content objects for the new name. Nameless
	Objects can be addressed by the ContentObjectHash that is to restrict
	Content Object matching by using SHA-256 hash.
	</t>	</t>

		</section>
	<t>	<section numbered="true" toc="default">
	An Interest message would still carry a Name and a ContentObjectHash,	<name>Support Nameless Object</name>
	where a Name is used for routing, while a ContentObjectHash is used	<t>
		In CCNx 1.0 <xref target="Mosko2" format="default"/>, the concept of a
		"Nameless
		Object", which is a Content Object without a name, is introduced to
		provide a means to move content between storage replicas without havin
		g
		to rename or re-sign the Content Objects for the new name. Nameless
		Objects can be addressed by the ContentObjectHash, which is to restric
		t
		Content Object matching by using a SHA-256 hash.
		</t>
		<t>
		An Interest message would still carry a name and a ContentObjectHash,
		where a name is used for routing, while a ContentObjectHash is used
	for matching. However, on the reverse path, if the Content Object's	for matching. However, on the reverse path, if the Content Object's
	name is missing, it is a "Nameless Object" and only matches against th e	name is missing, it is a "Nameless Object" and only matches against th e

	ContentObjectHash. Therefore, a consumer needs to resolve proper name	ContentObjectHash. Therefore, a consumer needs to resolve the proper n ame
	and hashes through an outside system, which can be considered as an NR S.	and hashes through an outside system, which can be considered as an NR S.
	</t>	</t>

		</section>
	</section>	<section numbered="true" toc="default">
		<name>Support Manifest</name>
	<section title="Support manifest">	<t>
	<t>	For collections of data objects that are
	For collections of data objects which are	organized as large and file-like contents <xref target="I-D.irtf-icnrg-flic" for
	organized as large and file	mat="default"/>, manifests are used as data
	like contents <xref target="FLIC"></xref>, manifests are used as data
	structures to transport this information. Thus, manifests may contain	structures to transport this information. Thus, manifests may contain

	hash digests of signed content objects or other manifests, so that lar	hash digests of signed Content Objects or other manifests so that larg
	ge	e
	content objects which represent large piece of application data can be	Content Objects that represent a large piece of application data can b
	collected by using such manifest.	e
	</t>	collected by using such a manifest.
		</t>
	<t>	<t>
	In order to request content objects, a co	In order to request Content Objects, a co
	nsumer needs to know a manifest	nsumer needs to know a manifest
	root name to acquire the manifest. In case of FLIC, a manifest name	root name to acquire the manifest. In the case of File-Like ICN Collec
	can be represented by a nameless root manifest, so that outside system	tions (FLIC), a manifest name
		can be represented by a nameless root manifest so that an outside syst
		em
	such as an NRS may be involved to give this information to the consume r.	such as an NRS may be involved to give this information to the consume r.

	</t>	</t>
		</section>
	</section>	<section numbered="true" toc="default">
		<name>Support Metadata</name>
	<section title="Support metadata">	<t>
	<t>	When resolving the name of a Content Object, NRS could return a rich
	When resolving the name of a content object, NRS could return a rich
	set of metadata in addition to returning a locator. The metadata	set of metadata in addition to returning a locator. The metadata
	could include alternative object locations, supported object transfe r	could include alternative object locations, supported object transfe r
	protocol(s), caching policy, security parameters, data format, hash	protocol(s), caching policy, security parameters, data format, hash

	of object data, etc. The consumer could use this metadata for select ion	of object data, etc. The consumer could use this metadata for the se lection
	of object transfer protocol, security mechanism, egress interface, e tc.	of object transfer protocol, security mechanism, egress interface, e tc.
	An example of how metadata can be used in this way is provided by th e	An example of how metadata can be used in this way is provided by th e

	NEO ICN architecture <xref target="NEO"></xref>.	Networked Object (NEO) ICN architecture <xref target="NEO" format="d
	</t>	efault"/>.
		</t>
	</section>	</section>
		</section>
	</section>	<section numbered="true" toc="default">
		<name>Design Considerations for NRS in ICN</name>
	<section title="Design considerations for NRS in ICN">
	<t>	<t>
	This section presents the design considerations for NRS in ICN.	This section presents the design considerations for NRS in ICN.
	</t>	</t>

		<section numbered="true" toc="default" anchor="res-response">
	<section title="Resolution response time">	<name>Resolution Response Time</name>
	<t>	<t>
	The name resolution process should provide a response within a reaso	The name resolution process should provide a response within a reaso
	nable amount of time. The response should be either a proper mapping of the name	nable amount of time. The response should be either a proper mapping of the name
	to a copy of the content, or an error message stating that no such object exist	to a copy of the content or an error message stating that no such object exists
	s. If the name resolution does not map to a location, the system may not issue a	. If the name resolution does not map to a location, the system may not issue an
	ny response, and the client should set a timer when sending a request, so as to	y response, and the client should set a timer when sending a request so as to co
	consider the resolution incomplete when the timer expires.	nsider the resolution incomplete when the timer expires.
	</t>	</t>
	<t>	<t>
	The acceptable response delay could be of the order of a round trip	The acceptable response delay could be of the order of a round-trip
	time between the client issuing the request and the NRS servers that	time between the client issuing the request and the NRS servers that
	provides the response. While this RTT may vary greatly depending on the proximi	provide the response. While this RTT may vary greatly depending on the proximit
	ty between the two end points, some upper bound need be used.	y between the two end points, some upper bound needs to be used.
	Especially, in some delay-sensitive scenarios such as industrial Int	Especially in some delay-sensitive scenarios such as industrial Inte
	ernet and telemedicine, the upper bound of the response delay must be guaranteed	rnet and telemedicine, the upper bound of the response delay must be guaranteed.
	.	</t>
	</t>
	<!-- <t>
	The response time should be within the same order of magnitude for m
	ost pairs of a client issuing a request, and the NRS server responding to this r
	equest.
	</t>
	-->
	<t>	<t>
	The response time includes all the steps of the resolution, includin g potentially a hop-by-hop resolution or a hierarchical forwarding of the resolu tion request.	The response time includes all the steps of the resolution, includin g potentially a hop-by-hop resolution or a hierarchical forwarding of the resolu tion request.

	</t>	</t>
	<!--
	<t>The name resolution process provided by the NRS must be completed wi
	thin a minimum delay. If the name resolution takes too long, then the content re
	quest packet may get dropped or it will yield the high content retrieval time fo
	r content requestor. Thus, the content retrieval time has to be content requesto
	r-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 re
	cord 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 a
	pproach, with the content based routing table being broadcast within the larger
	scope in the network, the name resolution and request routing can have higher pr
	obability to successfully reach the nearer copy of the requested content.

	The NRS deployment should balance the number of nodes involved in the n
	ame 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 closes
	t copy. Message forwarding and processing should be efficient and computation co
	mplexity should be reasonable low and affordable by the current processor techno
	logies.

	<section title="Time transiency">
	<t>The NRS should support time-transient content, which is frequently c
	reated 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 refl
	ect 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>

		<section numbered="true" toc="default">
	<section title="Response accuracy">	<name>Response Accuracy</name>
		<t>
	<t>	An NRS must provide an accurate response -- namely, a proper bindin
	An NRS must provide an accurate response, namely a proper binding o	g of the requested name (or prefix) with a location. The response can be either
	f the requested name (or prefix) with a location. The response can be either a (	a (prefix, location) pair or the actual forwarding of a request to a node holdin
	prefix, location) pair, or the actual forwarding of a request to a node holding	g the content, which is then transmitted in return.
	the content, which is then transmitted in return.	</t>
	</t>	<t>
	<t>	An NRS must provide an up-to-date response -- namely, an NRS should
	An NRS must provide an up-to-date response, namely an NRS should be	be updated within a reasonable time when new copies of the content are being st
	updated within a reasonable time when new copies of the content are being store	ored in the network. While every transient cache addition/eviction should not tr
	d in the network. While every transient cache addition/eviction should not trigg	igger an NRS update, some origin servers may move and require the NRS to be upda
	er an NRS update, some origin servers may move and require the NRS to be updated	ted.
	.	</t>
	</t>	<t>
	<t>	An NRS must provide mechanisms to update the mapping of the content
	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 provid
	with its location. Namely, an NRS must provide a mechanism for a content provid	er to add new content, revoke old/dated/obsolete content, and modify existing co
	er to add new content, revoke old/dated/obsolete content, and modify existing co	ntent. Any content update should then be propagated through
	ntent. Any content update should then be propagated through the NRS system withi	the NRS system within reasonable delay.
	n reasonable delay.	</t>
	</t>	<t>
	<t>	Content that is highly mobile may require specifying some type of a
	Content that is highly mobile may require to specify some type of a	nchor that is kept at the NRS instead of the content location.
	nchor that is kept at the NRS, instead of the content location.	</t>
	</t>

	<!--
	<t>The NRS must provide accurate and up-to-date information on how to d
	iscover the requested content with minimum overhead in propagating the update in
	formation. 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 mini
	mum delay.</t>

	Content mobility and expiration must be reflected in the corresponding
	records in the NRS system with minimum delay to guarantee the accurate resolutio
	n.

	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Resolution guarantee">	<name>Resolution Guarantee</name>
	<t>	<t>
	An NRS must ensure that the name resolution is successful	An NRS must ensure that the name resolution is successful

	with high probability if the name matching content exists in the ne	with high probability if the name-matching content exists in the ne
	twork,	twork,
	regardless of its popularity and number of cached copies existing i	regardless of its popularity and the number of cached copies existi
	n the network.	ng in the network.
	As per Section 4.1, some resolution may not occur in a timely manne	Per <xref target="res-response"/>, some resolutions may not occur i
	r.	n a timely manner.
	However, the probability of such event should be minimized.	However, the probability of such an event should be minimized.
	The NRS system may provide a probability (say, five 9s, or	The NRS system may provide a probability (five 9s or
	five sigmas for instance) that a resolution will be satisfied.	five sigmas, for instance) that a resolution will be satisfied.
	</t>	</t>
	<!--
	<t>The NRS must ensure the name resolution success if the matching cont
	ent exists in the network, regardless of its popularity, number of cached copies
	. </t>
	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Resolution fairness">	<name>Resolution Fairness</name>
	<t>	<t>
	An NRS could provide this service for all content in a fair manner, independently of the specific content properties	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, cont ent format, etc.).	(content producer, content popularity, availability of copies, cont ent format, etc.).

	Fairness may be defined as a per request delay to complete the NRS steps that is not agnostic to the properties of the content itself.	Fairness may be defined as a per-request delay to complete the NRS steps that is agnostic to the properties of the content itself.
	Fairness may be defined as well as the number of requests answered per unit of time.	Fairness may be defined as well as the number of requests answered per unit of time.

	</t>	</t>
	<t>	<t>
	However, it is notable that content (or their associated producer)	However, it is notable that content (or their associated producer)
	may request a different level of QoS from the network (see <xref target="RFC9064	may request a different level of QoS from the network (see <xref target="RFC9064
	"></xref> for instance),	" 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.	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>	</t>
		</section>
	</section>	<section numbered="true" toc="default">
		<name>Scalability</name>
	<section title="Scalability">	<t>
	<t>
	The NRS system must scale up to support a very large user populatio n (including human users as well as machine-to-machine communications).	The NRS system must scale up to support a very large user populatio n (including human users as well as machine-to-machine communications).
	As an idea of the scale, it is expected that 50 billion devices wil l be connected in 2025 (per ITU projections).	As an idea of the scale, it is expected that 50 billion devices wil l be connected in 2025 (per ITU projections).
	The system must be able to respond to a very large number of reques ts per unit of time.	The system must be able to respond to a very large number of reques ts per unit of time.

	Message forwarding and processing, routing table building-up and na	Message forwarding and processing, routing table buildup, and name
	me records propagation must be efficient and scalable.	record propagation must be efficient and scalable.
	</t>	</t>
	<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.	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 bytes). Since NRS is associated with actual traffic,	Internet traffic is of the order of zettabytes per year (10<sup>21< /sup> bytes). Since NRS is associated with actual traffic,
	the number of pieces of content should scale with the amount of tra ffic. Content size may vary from a few bytes to several GB,	the number of pieces of content should scale with the amount of tra ffic. Content size may vary from a few bytes to several GB,

	so the NRS should be expected scale up to catalog of the size of 10	so the NRS should be expected scale up to a catalog of the size of
	^21 in the near future, and larger beyond.	10<sup>21</sup> in the near future, and larger beyond.
	</t>	</t>
	<t>	<t>
	The NRS system must be able to scale up, namely to add NRS servers	The NRS system must be able to scale up -- namely, to add NRS serve
	to the NRS system, in a way that is transparent to the users.	rs to the NRS system in a way that is transparent to the users.
	Addition of a new server should have limited negative impact on the	The addition of a new server should have a limited negative impact
	other NRS servers	on the other NRS servers
	(or should have a negative impact on only a small subset of the 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 ot her servers to rebuild a hierarchy or to exchange messages to include the new se rver within the service.	The impact of adding new servers may induce some overhead at the ot her servers to rebuild a hierarchy or to exchange messages to include the new se rver within the service.

	Further, data may be shared among the new servers, for load balanci	Further, data may be shared among the new servers for load balancin
	ng or tolerance to failure.	g or tolerance to failure.
	These steps should not disrupt the service provided by the NRS and	These steps should not disrupt the service provided by the NRS and
	should in the long run improve the quality of the service.	should improve the quality of the service in the long run.
	</t>	</t>
	<t>	<t>
	The NRS system may support access from a heterogeneity of connectio n methods and devices.	The NRS system may support access from a heterogeneity of connectio n methods and devices.

	In particular, the NRS system may support access from constrained d	In particular, the NRS system may support access from constrained d
	evices and interactions with the NRS system would not be too costly.	evices, and interactions with the NRS system would not be too costly.
	An IoT node for instance should be able to access the NRS system as	An IoT node, for instance, should be able to access the NRS system
	well as a more powerful node.	as well as a more powerful node.
	</t>	</t>
	<t>	<t>
	The NRS system should scale up in its responsiveness to the increas	The NRS system should scale up in its responsiveness to the increas
	ed request rate that is expected from applications such as IoT or M2M,	ed request rate that is expected from applications such as IoT or machine-to-mac
	where data is being frequently generated and/or frequently requeste	hine (M2M),
	d.	where data is being frequently generated and/or requested.
	</t>	</t>
		</section>
	</section>	<section numbered="true" toc="default">
		<name>Manageability</name>
	<section title="Manageability">	<t>
	<t>
	The NRS system must be manageable since some parts of the system ma y grow or shrink dynamically and an NRS system node may be added or deleted freq uently.	The NRS system must be manageable since some parts of the system ma y grow or shrink dynamically and an NRS system node may be added or deleted freq uently.

	</t>	</t>
	<t>	<t>
	The NRS system may support an NRS management layer that allows for	The NRS system may support an NRS management layer that allows for
	adding or subtracting NRS nodes. In order to infer the circumstance, the manage	adding or subtracting NRS nodes. In order to infer the circumstance, the manage
	ment layer can measure network status.	ment layer can measure the network status.
	</t>	</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>

		<section numbered="true" toc="default">
	<section title="Deployed system">	<name>Deployed System</name>
	<t>	<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 i n a very low latency.	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 i n a very low latency.

	</t>	</t>
	<!--
	<t>The NRS system must be deployable since deployability is important f
	or a real world system. If the NRS system can be deployed from the edges, then t
	he deployment can be simplified. </t>
	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Fault tolerance">	<name>Fault Tolerance</name>
	<t>	<t>
	The NRS system must ensure resiliency in the event of NRS server fa ilures.	The NRS system must ensure resiliency in the event of NRS server fa ilures.
	The failure of a small subset of nodes should not impact the NRS pe rformance significantly.	The failure of a small subset of nodes should not impact the NRS pe rformance significantly.

	</t>	</t>
	<t>	<t>
	After an NRS server fails, the NRS system must be able to recover a nd/or restore the name records stored in the NRS server.	After an NRS server fails, the NRS system must be able to recover a nd/or restore the name records stored in the NRS server.

	</t>	</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 th
	e NRS node. </t>

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

	<t>For example, in the explicit name resolution approach, when a NRS ove
	rlay 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 o
	f 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. H
	owever, it requires that the ICN router has propagated its name based routing in
	formation in the network. </t>
	</section>	</section>

		<section numbered="true" toc="default" anchor="sec-priv">
	<section title="Security and privacy">	<name>Security and Privacy</name>
		<t>
	<t>
	On utilizing an NRS in ICN, there are some security consideration s for the	On utilizing an NRS in ICN, there are some security consideration s for the
	NRS servers/nodes and name mapping records stored in the NRS syst em.	NRS servers/nodes and name mapping records stored in the NRS syst em.
	This subsection describes them.	This subsection describes them.

	</t>	</t>
		<section numbered="true" toc="default">
	<section title="Confidentiality">	<name>Confidentiality</name>
	<t>	<t>
	The name mapping records in the NRS system must be assigned with	The name mapping records in the NRS system must be assigned with
	proper access rights such that the information contained in the name	proper access rights such that the information contained in the name
	mapping records would not be revealed to unauthorized users .	mapping records would not be revealed to unauthorized users .

	</t>	</t>
	<t>	<t>
	The NRS system may support access control for certain name mapping	The NRS system may support access control for certain name mapping
	records. Access control can be implemented with a reference monitor	records. Access control can be implemented with a reference monitor
	that uses client authentication, so only users with appropr iate	that uses client authentication, so only users with appropr iate
	credentials can access these records, and they are not shar ed with	credentials can access these records, and they are not shar ed with
	unauthorized users. Access control can also be implemented by	unauthorized users. Access control can also be implemented by
	encryption-based techniques using control of keys to contro l the	encryption-based techniques using control of keys to contro l the
	propagations of the mappings.	propagations of the mappings.

	</t>	</t>
	<t>	<t>
	The NRS system may support obfuscation and/or encryption	The NRS system may support obfuscation and/or encryption
	mechanisms so that the content of a resolution request	mechanisms so that the content of a resolution request
	may not be accessible by third parties outside of the NRS s ystem.	may not be accessible by third parties outside of the NRS s ystem.

	</t>	</t>
	<t>	<t>
	The NRS system must keep confidentiality to prevent	The NRS system must keep confidentiality to prevent
	sensitive name mapping records from being reached by	sensitive name mapping records from being reached by
	unauthorized data requesters. This is more required	unauthorized data requesters. This is more required
	in IoT environments where a lot of sensitive data is produc ed.	in IoT environments where a lot of sensitive data is produc ed.

	</t>	</t>
	<t>	<t>
	The NRS system must also keep confidentiality of meta-data	The NRS system must also keep confidentiality of metadata
	as well as NRS usage to protect the privacy of the users.	as well as NRS usage to protect the privacy of the users.
	For instance, a specific user's NRS requests should	For instance, a specific user's NRS requests should
	not be shared outside the NRS system (with the exception	not be shared outside the NRS system (with the exception
	of legal intercept).	of legal intercept).

	</t>	</t>
	</section>	</section>
		<section numbered="true" toc="default">
	<section title="Authentication">	<name>Authentication</name>
	<t>	<ul spacing="normal">
	<list style="symbols">	<li>
	<t>
	NRS server authentication: Authentication of the ne w NRS	NRS server authentication: Authentication of the ne w NRS
	servers/nodes that want to be registered with the N RS system	servers/nodes that want to be registered with the N RS system
	must be required so that only authenticated entitie s can	must be required so that only authenticated entitie s can
	store and update name mapping records. The NRS syst em should	store and update name mapping records. The NRS syst em should
	detect an attacker attempting to act as a fake NRS server	detect an attacker attempting to act as a fake NRS server
	to cause service disruption or manipulate name mapp ing records.	to cause service disruption or manipulate name mapp ing records.

	</t>	</li>
	<t>	<li>
	Producer authentication: The NRS system must suppor t	Producer authentication: The NRS system must suppor t
	authentication of the content producers to ensure t hat	authentication of the content producers to ensure t hat
	update/addition/removal of name mapping records req uested	update/addition/removal of name mapping records req uested
	by content producers are actually valid and that co ntent	by content producers are actually valid and that co ntent
	producers are authorized to modify (or revoke) thes e records	producers are authorized to modify (or revoke) thes e records
	or add new records.	or add new records.

	</t>	</li>
	<t>	<li>
	Mapping record authentication: The NRS should verif y new	Mapping record authentication: The NRS should verif y new
	mapping records that are being registered so that i t cannot	mapping records that are being registered so that i t cannot
	be polluted with falsified information or invalid r ecords.	be polluted with falsified information or invalid r ecords.

	</t>	</li>
		</ul>
	</list>	</section>
	</t>	<section numbered="true" toc="default">
		<name>Integrity</name>
	</section>	<t>
		The NRS system must be protected from malicious users
	<section title="Integrity">
	<t>
	The NRS system must be prevented from malicious users
	attempting to hijack or corrupt the name mapping records.	attempting to hijack or corrupt the name mapping records.

	</t>	</t>
		</section>
	</section>	<section numbered="true" toc="default">
		<name>Resiliency and Availability</name>
	<section title="Resiliency and availability">	<t>
	<t>	The NRS system should be resilient against denial-of-servic
	The NRS system should be resilient against denial of servic	e attacks
	e attacks
	and other common attacks to isolate the impact of the attac ks and	and other common attacks to isolate the impact of the attac ks and
	prevent collateral damage to the entire system. Therefore, if a	prevent collateral damage to the entire system. Therefore, if a
	part of the NRS system fails, the failure should only affec t a local	part of the NRS system fails, the failure should only affec t a local
	domain. And fast recovery mechanisms need to be in place to bring	domain. And fast recovery mechanisms need to be in place to bring
	the service back to normal.	the service back to normal.

	</t>	</t>
	</section>	</section>
		</section>
	</section>	</section>
		<section numbered="true" toc="default">
	</section>	<name>Conclusion</name>
		<t>
	<section title="Conclusion">
	<t>
	ICN routing may comprise three steps: name resolution, content request routi ng,	ICN routing may comprise three steps: name resolution, content request routi ng,
	and content delivery. This document investigates the name resolution step,	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	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	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	that provides such a function of name resolution for translating an object
	name into some other information such as a locator, another name, metadata,	name into some other information such as a locator, another name, metadata,

	next hop info, etc. that is used for forwarding the object request.	next-hop info, etc. that is used for forwarding the object request.
	</t>	</t>
	<t>	<t>
	This document classifies and analyzes the NRS approaches according to whethe r	This document classifies and analyzes the NRS approaches according to whethe r
	the name resolution step is separated from the content request routing as an	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	explicit process or not. This document also explains the NRS functions used
	to support heterogeneous name types, producer mobility, scalable routing sys tem,	to support heterogeneous name types, producer mobility, scalable routing sys tem,
	off-path caching, nameless object, manifest, and metadata. Finally, this doc ument	off-path caching, nameless object, manifest, and metadata. Finally, this doc ument
	presents design considerations for NRS in ICN, which include resolution resp onse	presents design considerations for NRS in ICN, which include resolution resp onse
	time and accuracy, resolution guarantee, resolution fairness, scalability,	time and accuracy, resolution guarantee, resolution fairness, scalability,
	manageability, deployed system, and fault tolerance.	manageability, deployed system, and fault tolerance.

	</t>	</t>
	</section>	</section>
		<section anchor="IANA" numbered="true" toc="default">
	<section anchor="IANA" title="IANA Considerations">	<name>IANA Considerations</name>
	<t>There are no IANA considerations related to this document.</t>	<t>This document has no IANA actions.</t>
	</section>	</section>
		<section numbered="true" toc="default">
	<section title="Security Considerations">	<name>Security Considerations</name>

	<t>	<t>

	A discussion of security guidelines was provided in section 4.9.	A discussion of security guidelines is provided in <xref target="sec-pri v"/>.
	</t>	</t>

		</section>
	</section>	</middle>

	</middle>

	<!-- ***BACK MATTER *** -->
	<back>	<back>

	<!-- References split into informative and normative -->

	<!-- There are 2 ways to insert reference entries from the citation librarie
	s:
	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.xm
	l"?> 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 fi
	les in the same
	directory as the including file. You can also define the XML_LIBRARY enviro
	nment variable
	with a value containing a set of directories to search. These can be eithe
	r in the local
	filing system or remote ones accessed by http (http://domain/dir/... ).-->

	<references title="Normative References">

	&rfc7927;

	</references>

	<references title="Informative References">

	<reference 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'></au
	thor>
	<author initials='C.' surname='Imbrenda' fullname='C. Imbrenda'></auth
	or>
	<author initials='D.' surname='Kutscher' fullname='D. Kutscher'></auth
	or>
	<author initials='B.' surname='Ohlman' fullname='B. Ohlman'></author>
	<date month='' year='2012' />
	</front>
	<seriesInfo name='IEEE Communications Magarzine' value='Vol.50, Issue 7'
	/>
	</reference>

	<reference anchor='Xylomenos'>
	<front>
	<title>A Survey of Information-Centric Networking Research,Communicati
	ons Surveys and Tutorials</title>
	<author initials='G.' surname='Xylomenos' fullname='G. Xylomenos'></au
	thor>
	<author initials='C. N.' surname='Ververidis' fullname='C. N. Ververid
	is'></author>
	<author initials='V. A.' surname='Siris' fullname='V. A. Siris'></auth
	or>
	<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'></auth
	or>
	<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 Communications Surveys and Tutorials' value='vol.
	16, no. 2' />
	</reference>

	<reference 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'></auth
	or>
	<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'></auth
	or>
	<date month='' year='2014' />
	</front>
	<seriesInfo name='ACM ICN' value='2014' />
	</reference>

	<reference anchor='Amadeo'>
	<front>
	<title>Named data networking for IoT: An architectural perspective</ti
	tle>
	<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'></auth
	or>
	<date month='' year='2014' />
	</front>
	<seriesInfo name='European Conference on Networks and Communications (Eu
	CNC)' value='' />
	</reference>

	<reference 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'></au
	thor>
	<author initials='R.' surname='Aguiar' fullname='R. Aguiar'></au
	thor>
	<date month='' year='2014' />
	</front>
	<seriesInfo name='IEEE GLOBECOM' value='' />
	</reference>


	<reference anchor='Amadeo2'>	<displayreference target="I-D.irtf-icnrg-icniot" to="ID.Zhang2"/>
		<displayreference target="I-D.ravi-icnrg-ccn-forwarding-label" to="Ravindran"/>
	<front>	<displayreference target="I-D.irtf-icnrg-flic" to="FLIC"/>
	<title>Information-centric networking for the internet of things: chal	<displayreference target="I-D.irtf-icnrg-nrsarch-considerations" to="NRSarch"/>
	lenges and opportunitiesve</title>	<references>
	<author initials='' surname='Amadeo, M. et al.' fullname='Amadeo, M. et al.'	<name>References</name>
	></author>	<references>
	<date month='July' year='2016' />	<name>Normative References</name>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	</front>	FC.7927.xml"/>
	<seriesInfo name='IEEE Network' value='vol. 30, no. 2' />	</references>
		<references>
	</reference>	<name>Informative References</name>
		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<reference anchor='ID.Zhang2'>	FC.8569.xml"/>
	<front>
	<title>Design Considerations for Applying ICN to IoT</title>
	<author initials='' surname='Ravindran, R. et al.' fullname='Rav
	indran, R. et al.'></author>
	<date month='May' year='2019' />
	</front>
	<seriesInfo name='draft-zhang-icnrg-icniot-03' value='' />
	</reference>

	<reference 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>
	<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 pp. 181-192' />
	</reference>

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

	<reference anchor='SAIL'>
	<front>
	<title>FP7 SAIL project.</title>
	<author initials='' surname='' fullname=''></author>
	<date month='' year='' />
	</front>
	<seriesInfo name='http://www.sail-project.eu/' value='' />
	</reference>

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

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

	<reference anchor='MF'>
	<front>
	<title>NSF Mobility First project.</title>
	<author initials='' surname='' fullname=''></author>
	<date month='' year='' />
	</front>
	<seriesInfo name='http://mobilityfirst.winlab.rutgers.edu/' value='' />
	</reference>

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

	<reference anchor="SA2-5GLAN">
	<front>
	<title>SP-181129, Work Item Description, Vertical_LAN(SA2), 5GS Enhan
	ced Support of Vertical and LAN Services</title>
	<author initials="" surname="3gpp-5glan" />
	<date year="http://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_82/Docs/SP-181
	120.zip"/>
	</front>
	<seriesInfo name="3GPP" value=""/>
	</reference>

	<!--
	<reference anchor='Jacobson'>
	<front>
	<title>Networking Named Content</title>
	<author initials='V.' surname='Jacobson' fullname='V. Jacobson'></auth
	or>
	<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'></auth
	or>
	<author initials='N. H.' surname='Briggs' fullname='N. H. Briggs'></au
	thor>
	<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 Object
	s 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-Orien
	ted Networking (NOMEN)' value='' />
	</reference>

	<reference 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
	>
	<date month='' year='2012' />
	</front>
	<seriesInfo name='IEEE Communications Magazine' value='Vol. 50, No. 12,
	P.44-53' />
	</reference>


	<!--	<reference anchor="Ahlgren">
	<reference anchor='Rajahalme'>	<front>
	<front>	<title>A Survey of Information-Centric Networking</title>
	<title>On Name-based Inter-domain Routing</title>	<author initials="B." surname="Ahlgren" fullname="B. Ahlgren"/>
	<author initials='J.' surname='Rajahalme' fullname='J. Rajahalme'></au	<author initials="C." surname="Dannewitz" fullname="C. Dannewitz"/>
	thor>	<author initials="C." surname="Imbrenda" fullname="C. Imbrenda"/>
	<author initials='M.' surname='Sarela' fullname='M. Sarela'></author>	<author initials="D." surname="Kutscher" fullname="D. Kutscher"/>
	<author initials='K.' surname='Visala' fullname='K. Visala'></author>	<author initials="B." surname="Ohlman" fullname="B. Ohlman"/>
	<author initials='J.' surname='Riihijarvi' fullname='J. Riihijarvi'></	<date month="July" year="2012"/>
	author>	</front>
	<date month='March' year='2011' />	<seriesInfo name="DOI" value="10.1109/MCOM.2012.6231276"/>
	</front>	<refcontent>IEEE Communications Magazine, Vol. 50, Issue 7</refcontent
	<seriesInfo name='Computer Networks' value='Vol. 55, No. 4, P. 975-986'	>
	/>	</reference>
	</reference>


	<reference anchor='Katsaros'>	<reference anchor="Xylomenos">
	<front>	<front>
	<title>On Inter-Domain Name Resolution for Information-Centric Network	<title>A Survey of Information-Centric Networking Research</title>
	s</title>	<author initials="G." surname="Xylomenos" fullname="G. Xylomenos"/>
	<author initials='K. V.' surname='Katsaros' fullname='K. V. Katsaros'>	<author initials="C." surname="Ververidis" fullname="C. Ververidis"/
	</author>	>
	<author initials='N.' surname='Fotiou' fullname='N. Fotiou'></author>	<author initials="V." surname="Siris" fullname="V. Siris"/>
	<author initials='X.' surname='Vasilakos' fullname='X. Vasilakos'></au	<author initials="N." surname="Fotiou" fullname="N. Fotiou"/>
	thor>	<author initials="C." surname="Tsilopoulos" fullname="C.Tsilopoulos"
	<author initials='C. N.' surname='Ververidis' fullname='C. N. Ververid	/>
	is'></author>	<author initials="X." surname="Vasilakos" fullname="X. Vasilakos"/>
	<author initials='C.' surname='Tsilopoulos' fullname='C. Tsilopoulos'>	<author initials="K." surname="Katsaros" fullname="K. Katsaros"/>
	</author>	<author initials="G." surname="Polyzos" fullname="G. Polyzos"/>
	<author initials='G.' surname='Xylomenos' fullname='G. Xylomenos'></au	<date year="2014"/>
	thor>	</front>
	<author initials='G. C.' surname='Polyzos' fullname='G. C. Polyzos'></	<seriesInfo name="DOI" value="10.1109/SURV.2013.070813.00063"/>
	author>	<refcontent>IEEE Communications Surveys and Tutorials, Vol. 16, Issue
	<date month='' year='2012' />	2</refcontent>
	</front>	</reference>
	<seriesInfo name='Proc.IFIP-TC6 Networking Conference' value='' />
	</reference>


	<reference anchor='ID.Wang'>	<reference anchor="Baccelli">
	<front>	<front>
	<title>Namespace Resolution in Future Internet Architectures</title>	<title>Information Centric Networking in the IoT: Experiments with N
	<author initials='J.' surname='Wang' fullname='J. Wang'></author>	DN in the Wild</title>
	<author initials='S.' surname='Li' fullname='S. Li'></author>	<author initials="E." surname="Baccelli" fullname="E. Baccelli"/>
	<author initials='C.' surname='Wetphal' fullname='C. Wetphal'></author	<author initials="C." surname="Mehlis" fullname="C. Mehlis"/>
	>	<author initials="O." surname="Hahm" fullname="O. Hahm"/>
	<date month='October' year='2015' />	<author initials="T." surname="Schmidt" fullname="T. Schmidt"/>
	</front>	<author initials="M." surname="Wählisch" fullname="M. Wählisch"/>
	<seriesInfo name='draft-wang-fia-namespace-01' value='' />	<date month="" year="2014"/>
	</reference>	</front>
		<seriesInfo name="DOI" value="10.1145/2660129.2660144"/>
		<refcontent>ACM-ICN 2014</refcontent>
		</reference>


	<reference anchor='ID.Zhang'>	<reference anchor="Amadeo">
	<front>	<front>
	<title>PID: A Generic Naming Schema for Information-centric Network</t	<title>Named data networking for IoT: An architectural perspective</
	itle>	title>
	<author initials='X.' surname='Zhang' fullname='X. Zhang'></author>	<author initials="M." surname="Amadeo" fullname="M. Amadeo"/>
	<author initials='R.' surname='Ravindran' fullname='R. Ravindran'></au	<author initials="C." surname="Campolo" fullname="C. Campolo"/>
	thor>	<author initials="A." surname="Iera" fullname="A. Iera"/>
	<author initials='H.' surname='Xie' fullname='H. Xie'></author>	<author initials="A." surname="Molinaro" fullname="A. Molinaro"/>
	<author initials='G.' surname='Wang' fullname='G. Wang'></author>	<date month="June" year="2014"/>
	<date month='August' year='2013' />	</front>
	</front>	<seriesInfo name="DOI" value="10.1109/EuCNC.2014.6882665"/>
	<seriesInfo name='draft-zhang-icnrg-pid-naming-scheme-03' value='' />	<refcontent>European Conference on Networks and Communications (EuCNC)
	</reference>	</refcontent>
		</reference>


	<reference anchor='D.Zhang'>	<reference anchor="Quevedo">
	<front>	<front>
	<title>Routing and Name Resolution in Information-Centric Networks</ti	<title>A case for ICN usage in IoT environments</title>
	tle>	<author initials="J." surname="Quevedo" fullname="J. Quevedo"/>
	<author initials='D.' surname='Zhang' fullname='D. Zhang'></author>	<author initials="D." surname="Corujo" fullname="D. Corujo"/>
	<author initials='H.' surname='Liu' fullname='H. Liu'></author>	<author initials="R." surname="Aguiar" fullname="R. Aguiar"/>
	<date month='' year='2013' />	<date month="December" year="2014"/>
	</front>	</front>
	<seriesInfo name='22nd International Conference on Computer Communicatio	<seriesInfo name="DOI" value="GLOCOM.2014.7037227"/>
	ns and Networks (ICCCN)' value='' />	<refcontent>IEEE GLOBECOM</refcontent>
	</reference>	</reference>


	<reference anchor='Sevilla'>	<reference anchor="Amadeo2">
	<front>	<front>
	<title>iDNS: Enabling Information Centric Networking Through The DNS</	<title>Information-centric networking for the internet of things: ch
	title>	allenges and opportunities</title>
	<author initials='S.' surname='Sevilla' fullname='S. Sevilla'></author	<author initials="" surname="Amadeo, M. et al." fullname="Amadeo, M.
	>	et al."/>
	<author initials='P.' surname='Mahadevan' fullname='P. Mahadevan'></au	<date month="March" year="2016"/>
	thor>	</front>
	<author initials='J.' surname='Garcia-Luna-Aceves' fullname='J. Garcia	<seriesInfo name="DOI" value="10.1109/MNET.2016.7437030"/>
	-Luna-Aceves'></author>	<refcontent>IEEE Network, Vol. 30, No. 2</refcontent>
	<date month='' year='2014' />	</reference>
	</front>
	<seriesInfo name='Name Oriented Mobility (workshop co-located with Infoc
	om 2014)' value='' />
	</reference>


	&rfc1498;	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.irtf-ic nrg-icniot.xml"/>;


	<reference anchor='oneM2M'>	<reference anchor="Koponen">
	<front>	<front>
	<title>oneM2M Functional Architecture TS 0001.</title>	<title>A Data-Oriented (and Beyond) Network Architecture</title>
	<author initials='' surname='' fullname=''></author>	<author initials="T." surname="Koponen" fullname="T. Koponen"/>
	<date month='' year='' />	<author initials="M." surname="Chawla" fullname="M. Chawla"/>
	</front>	<author initials="B." surname="Chun" fullname="B. Chun"/>
	<seriesInfo name='http://www.onem2m.org/technical/published-documents.'	<author initials="A." surname="Ermolinskiy" fullname="A. Ermolinskiy
	value='' />	"/>
	</reference>	<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 </refcontent>
		</reference>


	&rfc7252;	<reference anchor="PURSUIT" target="https://www.fp7-pursuit.eu/">
		<front>
		<title>FP7 PURSUIT</title>
		<author />
		<date/>
		</front>
		</reference>


	<reference anchor='ID.Shelby'>	<reference anchor="SAIL" target="http://www.sail-project.eu/">
	<front>	<front>
	<title>CoRE Resource Directory</title>	<title>Scalable and Adaptive Internet Solutions (SAIL)</title>
	<author initials='Z.' surname='Shelby' fullname='Z. Shelby'></au	<author/>
	thor>	<date/>
	<date month='March' year='2017' />	</front>
	</front>	</reference>
	<seriesInfo name='draft-ietf-core-resource-directory-10' value='' />
	</reference>


	<reference anchor='CoRE'>	<reference anchor="NDN" target="http://www.named-data.net">
	<front>	<front>
	<title>Constrained RESTful Environments, CoRE</title>	<title>Named Data Networking</title>
	<author initials='' surname='' fullname=''></author>	<author/>
	<date month='March' year='2013' />	<date/>
	</front>	</front>
	<seriesInfo name='https://datatracker.ietf.org/wg/core/charter/' value='	</reference>
	' />
	</reference>


	<reference anchor='Westphal'>	<reference anchor="CCNx" target="https://wiki.fd.io/view/Cicn">
	<front>	<front>
	<title>An IP-based Manifest Architecture for ICN</title>	<title>CICN</title>
	<author initials='C.' surname='Westphal' fullname='C. Westphal'>	<author/>
	</author>	<date/>
	<author initials='E.' surname='Demirors' fullname='E. Demirors'>	</front>
	</author>	</reference>
	<date month='' year='2015' />
	</front>
	<seriesInfo name='ACM ICN' value='' />
	</reference>


	<reference anchor='Mosko'>	<reference anchor="MF" target="http://mobilityfirst.winlab.rutgers.edu">
	<front>	<front>
	<title>CCNx Manifest Specification</title>	<title>MobilityFirst Future Internet Architecture Project Overview</
	<author initials='M.' surname='Mosko' fullname='M. Mosko'></author>	title>
	<author initials='G.' surname='Scott' fullname='G. Scott'></author>	<author/>
	<author initials='I.' surname='Solis' fullname='I. Solis'></author>	<date/>
	<author initials='C.' surname='Wood' fullname='C. Wood'></author>	</front>
	<date month='July' year='2015' />	</reference>
	</front>
	<seriesInfo name='draft-wood-icnrg-ccnxmanifests-00' value='' />
	</reference>


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


	<reference anchor='RFC6920'>	<reference anchor="SA2-5GLAN" target="http://www.3gpp.org/ftp/tsg_sa/TSG
	<front>	_SA/TSGS_82/Docs/SP-181120.zip">
	<title>Naming Things with Hashes</title>	<front>
	<author initials='S.' surname='Farrell ' fullname='Stephen Farrell'></	<title>New WID: 5GS Enhanced support of Vertical and LAN Services</t
	author>	itle>
	<author initials='D.' surname='Kutscher' fullname='Dirk Kutscher'></au	<author><organization>3GPP</organization></author>
	thor>	<date month="December" year="2018"/>
	<author initials='C.' surname='Dannewitz' fullname='Christian Dannewit	</front>
	z'></author>	<refcontent>TSG SA Meeting #SP-82</refcontent>
	<author initials='B.' surname='Ohlman' fullname='Borje Ohlman'></autho	</reference>
	r>
	<author initials='A.' surname='Keranen' fullname='Ari Keranen'></autho
	r>
	<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="Bari">
	<reference anchor='Zhang'>	<front>
	<front>	<title>A Survey of Naming and Routing in Information-Centric Network
	<title>Named data networking</title>	s</title>
	<author initials='' surname='Zhang, L. et al.' fullname='L. Zhang et al.'></au	<author initials="M.F." surname="Bari" fullname="M.F. Bari"/>
	thor>	<author initials="S.R." surname="Chowdhury" fullname="S.R. Chowdhury
	<date month='July' year='2014' />	"/>
	</front>	<author initials="R." surname="Ahmed" fullname="R. Ahmed"/>
	<seriesInfo name='ACM SIGCOMM Computer Communication Review' value='vol. 44,	<author initials="R." surname="Boutaba" fullname="R. Boutaba"/>
	no. 3' />	<author initials="B." surname="Mathieu" fullname="B. Mathieu"/>
	</reference>	<date month="December" year="2012"/>
	<reference anchor='Zhang2'>	</front>
	<front>	<seriesInfo name="DOI" value="10.1109/MCOM.2012.6384450"/>
	<title>A Survey of Mobility Support in Named Data Networking</title>	<refcontent>IEEE Communications Magazine, Vol. 50, No. 12, pp. 44-53</
	<author initials='' surname='Zhang, Y. et al.' fullname='Y. Zhang et a	refcontent>
	l.'></author>	</reference>
	<date month='' year='2016'/>
	</front>
	<seriesInfo name='IEEE Conference on Computer Communications Workshops'
	value='' />
	</reference>


	<reference anchor='Dannewitz'>	<reference anchor="Westphal">
	<front>	<front>
	<title> Network of Information (NetInf)-An information centric networking ar	<title>An IP-Based Manifest Architecture for ICN</title>
	chitecture </title>	<author initials="C." surname="Westphal" fullname="C. Westphal"/>
	<author initials='' surname='Dannewitz, C. et al.' fullname='C. Dannewitz et	<author initials="E." surname="Demirors" fullname="E. Demirors"/>
	al.' ></author>	<date month="September" year="2015"/>
	<date month='April' year='2013' />	</front>
	</front>	<seriesInfo name="DOI" value="10.1145/2810156.2812614"/>
	<seriesInfo name='Computer Communications' value='vol. 36, no. 7' />	<refcontent>ACM-ICN 2015</refcontent>
	</reference>	</reference>


	<!--	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6920.
	<reference anchor='Seskar'>	xml"/>
	<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'>	<reference anchor="Zhang2">
	<front>	<front>
	<title>Hierarchical DHT-based name resolution for Information-Centric Networ	<title>A Survey of Mobility Support in Named Data Networking</title>
	ks</title>	<author initials="" surname="Zhang, Y. et al." fullname="Y. Zhang et
	<author initials='C.' surname='Dannewitz' fullname='C. Dannewitz' ></author>	al."/>
	<author initials='M.' surname='DAmbrosio' fullname='M. DAmbrosio' ></author>	<date month="April" year="2016"/>
	<author initials='V.' surname='Vercellone' fullname='V. Vercellone' ></autho	</front>
	r>	<seriesInfo name="DOI" value="10.1109/INFCOMW.2016.7562050"/>
	<date month='April' year='2013' />	<refcontent>IEEE Conference on Computer Communications Workshops</refc
	</front>	ontent>
	<seriesInfo name='Computer Communications' value='vol. 36, no. 7' />	</reference>
	</reference>


	<reference anchor='Vu'>	<reference anchor="Dannewitz">
	<front>	<front>
	<title>DMap: A Shared Hosting Scheme for Dynamic Identifier to Locator Mappi	<title> Network of Information (NetInf) - An information-centric net
	ng in the Global Internet </title>	working architecture </title>
	<author initials='' surname='Vu, T. et al.' fullname='T. Vu et al' ></author	<author initials="" surname="Dannewitz, C. et al." fullname="C. Dann
	>	ewitz et al."/>
	<date month='' year='2012' />	<date month="April" year="2013"/>
	</front>	</front>
	<seriesInfo name='IEEE 32nd International Conference on Distributed Computin	<seriesInfo name="DOI" value="10.1016/j.comcom.2013.01.009"/>
	g Systems' value='' />	<refcontent>Computer Communications, Vol. 36, Issue 7</refcontent>
	</reference>	</reference>


	<reference anchor='Hong'>	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ravi-ic
	<front>	nrg-ccn-forwarding-label.xml"/>
	<title>Demonstrating a Scalable Name Resolution System for Information-Centr
	ic 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='' />
	</reference>


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


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


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


	<reference anchor='FLIC'>	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.irtf-ic
	<front>	nrg-flic.xml"/>
	<title>File-Like ICN Collection (FLIC) </title>
	<author initials='' surname='Tschudin, C. et al.' fullname='C. Tschudin e
	t al' ></author>
	<date month='November' year='2019' />
	</front>
	<seriesInfo name='draft-irtf-icnrg-flic-02' value='' />
	</reference>


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


	<reference anchor='NRSarch'>	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.irtf-ic
	<front>	nrg-nrsarch-considerations.xml"/>
	<title>Architectural Considerations of ICN using Name Resolution Service</t
	itle>
	<author initials='' surname='Hong, J. et al.' fullname='J. Hong et al' ></a
	uthor>
	<date month='February' year='2021' />
	</front>
	<seriesInfo name='draft-irtf-icnrg-nrsarch-considerations-06' value='' />
	</reference>


	<reference anchor='RFC9064'>	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9064.
	<front>	xml"/>
	<title>Considerations in the development of a QoS Architecture for CCNx-lik
	e 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
	='' />
	</reference>


		</references>
	</references>	</references>

		<section anchor="Acknowledgments" numbered="false" toc="include">
	<section anchor="Acknowledgments" title="Acknowledgements" numbered="false"	<name>Acknowledgements</name>
	toc="include">	<t>
		The authors would like to thank <contact fullname="Dave Oran"/>, <cont
	<t>	act fullname="Dirk Kutscher"/>, <contact fullname="Ved Kafle"/>, <contact fullna
	The authors would like to thank Dave Oran, Dirk Kutscher, Ved Kafle,	me="Vincent Roca"/>, <contact fullname="Marie-Jose Montpetit"/>, <contact fullna
	Vincent Roca, Marie-Jose Montpetit, Stephen Farrell, Mirja Kuhlewind,	me="Stephen Farrell"/>, <contact fullname="Mirja Kühlewind"/>,
	and Colin Perkins for very useful reviews, comments and improvement	and <contact fullname="Colin Perkins"/> for very useful reviews, comme
	on the document.	nts, and improvements
	</t>	to the document.
		</t>
	</section>	</section>

		</back>
	</back>	</rfc>
	</rfc> <!--
	< </reference>
	title>Networking named content</title> <sInfo name='IEEE Network' va
	lue='vol. 30, no. 2' />
	</reference>
	&id.draft-winter-energy-efficient-internet;
	</reference>
	&i
	d.draft-cheshire-edns0-owner-option;
	<reference anchor='ITU'>
	<front>
	<title>Resolution 73 - Information and communication technologies an
	d 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'></autho
	r>
	<date month='December' year='2007'/>
	</front>
	<seriesInfo name='Proc. IEEE International Conference on Network Protoco
	ls (ICNP)' value=''/>
	</reference>

	<reference anchor='GreenSurvey'>
	<front>
	<title>A survey of green networking research</title>
	<author initials='A.P.' surname='Bianzino' fullname='Aruna Prem Bian
	zino'></author>
	<author initials='C.' surname='Chaudet' fullname='Claude Chaudet'></
	author>
	<author initials='D.' surname='Rossi' fullname='Dario Rossi'></autho
	r>
	<author initials='J.-L.' surname='Rougier' fullname='Jean-Louis Roug
	ier'></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'></a
	uthor>
	<author initials='K.' surname='Christensen' fullname='Ken Christense
	n'></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'></autho
	r>
	<date month='' year='2008' />
	</front>
	<seriesInfo name='Proc. IEEE Internat. Performance Computing and Communi
	cations Conf' value='' />
	</reference>

	<reference anchor='SKILL'>
	<front>
	<title>Skilled in the Art of Being Idle: Reducing Energy Waste in Ne
	tworked 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. Nord
	man'></author>
	<author initials='S.' surname='Ratnasamy' fullname='S. Ratnas
	amy'></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>
	-->

End of changes. 173 change blocks.
	1526 lines changed or deleted	860 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/