rfc9236.original   rfc9236.txt 
ICN Research Group J. Hong Internet Research Task Force (IRTF) J. Hong
Internet-Draft T. You Request for Comments: 9236 T. You
Intended status: Informational ETRI Category: Informational ETRI
Expires: 18 June 2022 V. Kafle ISSN: 2070-1721 V. Kafle
NICT NICT
15 December 2021 April 2022
Architectural Considerations of ICN using Name Resolution Service Architectural Considerations of Information-Centric Networking (ICN)
draft-irtf-icnrg-nrsarch-considerations-07 Using a Name Resolution Service
Abstract Abstract
This document describes architectural considerations and implications This document describes architectural considerations and implications
related to the use of a Name Resolution Service (NRS) in Information- related to the use of a Name Resolution Service (NRS) in Information-
Centric Networking (ICN). It explains how the ICN architecture can Centric Networking (ICN). It explains how the ICN architecture can
change when an NRS is utilized and how its use influences the ICN change when an NRS is utilized and how its use influences the ICN
routing system. This document is a product of the Information- routing system. This document is a product of the Information-
Centric Networking Research Group (ICNRG). Centric Networking Research Group (ICNRG).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Research Task Force
and may be updated, replaced, or obsoleted by other documents at any (IRTF). The IRTF publishes the results of Internet-related research
time. It is inappropriate to use Internet-Drafts as reference and development activities. These results might not be suitable for
material or to cite them other than as "work in progress." deployment. This RFC represents the consensus of the Information-
Centric Networking Research Group of the Internet Research Task Force
(IRTF). Documents approved for publication by the IRSG are not
candidates for any level of Internet Standard; see Section 2 of RFC
7841.
This Internet-Draft will expire on 18 June 2022. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9236.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document.
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Background
4. Implications of NRS in ICN . . . . . . . . . . . . . . . . . 5 4. Implications of an NRS in ICN
5. ICN Architectural Considerations for NRS . . . . . . . . . . 6 5. ICN Architectural Considerations for NRS
5.1. Name mapping records registration, resolution, and 5.1. Name Mapping Records Registration, Resolution, and Update
update . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Protocols and Semantics
5.2. Protocols and Semantics . . . . . . . . . . . . . . . . . 8 5.3. Routing System
5.3. Routing System . . . . . . . . . . . . . . . . . . . . . 9 6. Conclusion
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. References
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References
9.1. Normative References . . . . . . . . . . . . . . . . . . 11 9.2. Informative References
9.2. Informative References . . . . . . . . . . . . . . . . . 11 Acknowledgements
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Information-Centric Networking (ICN) is an approach to evolving the Information-Centric Networking (ICN) is an approach to evolving the
Internet infrastructure to provide direct access to Named Data Internet infrastructure to provide direct access to Named Data
Objects (NDOs) by names. In two common ICN architectures, NDN [NDN] Objects (NDOs) by names. In two common ICN architectures, Named Data
and CCNx [CCNx], the name of an NDO is used directly to route a Networking (NDN) [NDN] and Content-Centric Networking (CCNx) [CCNx],
request to retrieve the data object. Such direct name-based routing the name of an NDO is used directly to route a request to retrieve
has inherent challenges in enabling a globally scalable routing the data object. Such direct name-based routing has inherent
system, accommodating producer mobility, and supporting off-path challenges in enabling a globally scalable routing system,
caching. These specific issues are discussed in detail in Section 3. accommodating producer mobility, and supporting off-path caching.
In order to address these challenges, a Name Resolution Service (NRS) These specific issues are discussed in detail in Section 3. In order
has been utilized in the literature as well as the proposals of to address these challenges, a Name Resolution Service (NRS) has been
several ICN projects [Afanasyev] [Zhang2] [Ravindran] [SAIL] [MF] utilized in the literature as well as the proposals of several ICN
[Bayhan]. projects [Afanasyev] [Zhang2] [Ravindran] [SAIL] [MF] [Bayhan].
This document describes the potential changes in the ICN architecture This document describes the potential changes in the ICN architecture
caused by the introduction of NRS and the corresponding implication caused by the introduction of an NRS and the corresponding
to the ICN routing system. It also describes ICN architectural implication to the ICN routing system. It also describes ICN
considerations for the integration of an NRS. The scope of this architectural considerations for the integration of an NRS. The
document includes considerations from the perspective of ICN scope of this document includes considerations from the perspective
architecture and routing system when using an NRS in ICN. A of an ICN architecture and routing system when using an NRS in ICN.
description of the NRS itself is provided in the companion NRS design A description of the NRS itself is provided in the companion NRS
considerations document [RFC9138], which provides the NRS approaches, design considerations document [RFC9138], which provides the NRS
functions and design considerations. approaches, functions, and design considerations.
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.
2. Terminology 2. Terminology
* Name Resolution Service (NRS): An NRS in ICN is defined as a Name Resolution Service (NRS): An NRS in ICN is defined as a service
service that provides the function of translating a content name that provides the function of translating a content name or a data
or a data object name into some other information such as a object name into some other information such as a routable prefix,
routable prefix, a locator, an off-path-cache pointer, or an alias a locator, an off-path-cache pointer, or an alias name that is
name that is more amenable than the input name to forwarding the more amenable than the input name to forwarding the object request
object request toward the target destination storing the NDO toward the target destination storing the NDO [RFC9138]. An NRS
[RFC9138]. An NRS is most likely implemented through the use of a is most likely implemented through the use of a distributed
distributed mapping database system. Domain Name System (DNS) may mapping database system. The Domain Name System (DNS) may be used
be used as an NRS. However, in this case, the requirements of as an NRS. However, in this case, the requirements of frequent
frequent updates of NRS records due to the creations of a lot of updates of NRS records due to the creations of a lot of new NDOs
new NDOs and changes in their locations in the network need to be and changes in their locations in the network need to be
considered. considered.
* NRS server: An NRS comprises the distributed NRS servers storing NRS server: An NRS comprises the distributed NRS servers storing the
the mapping records in their databases. NRS servers store and mapping records in their databases. NRS servers store and
maintain the mapping records that keep the mappings of content or maintain the mapping records that keep the mappings of content or
object name to some other information that is used for forwarding object name to some other information that is used for forwarding
the content request or the content itself. the content request or the content itself.
* NRS resolver: The client side function of an NRS is called an NRS NRS resolver: The client-side function of an NRS is called an NRS
resolver. The NRS resolver is responsible for initiating name resolver. The NRS resolver is responsible for initiating name
resolution request queries that ultimately lead to a name resolution request queries that ultimately lead to a name
resolution of the target data objects. NRS resolvers can be resolution of the target data objects. NRS resolvers can be
located in the consumer (or client) nodes and/or ICN routers. An located in the consumer (or client) nodes and/or ICN routers. An
NRS resolver may also cache the mapping records obtained through NRS resolver may also cache the mapping records obtained through
the name resolution for later usage. the name resolution for later usage.
* Name registration: In order to populate the NRS, the content names Name registration: In order to populate the NRS, the content names
and their mapping records must be registered in the NRS system by and their mapping records must be registered in the NRS system by
a publisher who has access right to at least one authoritative NRS a publisher who has access rights to at least one authoritative
server or by a producer who generates named data objects. The NRS server or by a producer who generates named data objects. The
records contain the mapping of an object name to some information records contain the mapping of an object name to some information
such as other alias names, routable prefixes and locators, which such as other alias names, routable prefixes, and locators, which
are used for forwarding the content request. Thus, a publisher or are used for forwarding the content request. Thus, a publisher or
producer of contents creates an NRS registration request and sends producer of content creates an NRS registration request and sends
it to an NRS server. On registration, the NRS server stores (or it to an NRS server. On registration, the NRS server stores (or
updates) the name mapping record in the database and sends an updates) the name mapping record in the database and sends an
acknowledgement back to the producer or publisher that made the acknowledgement back to the producer or publisher that made the
registration request. registration request.
* Name resolution: Name resolution is the main function of the NRS Name resolution: Name resolution is the main function of the NRS
system. It is performed by an NRS resolver which can be deployed system. It is performed by an NRS resolver, which can be deployed
on a consumer node or an ICN router. Resolvers are responsible on a consumer node or an ICN router. Resolvers are responsible
for either returning a cached mapping record (whose lifetime has for either returning a cached mapping record (whose lifetime has
not expired or alternatively sending a name resolution request not expired) or alternatively sending a name resolution request
toward an NRS server. The NRS server searches for the content toward an NRS server. The NRS server searches for the content
name in its mapping record database, and if found, retrieves the name in its mapping record database and, if found, retrieves the
mapping record and returns it in a name resolution response mapping record and returns it in a name resolution response
message to the NRS resolver. message to the NRS resolver.
* NRS node: NRS servers are also referred to as NRS nodes that NRS node: NRS servers are also referred to as NRS nodes that
maintain the name records. The terms are used interchangeably. maintain the name records. The terms are used interchangeably.
* NRS client: A node that uses the NRS is called an NRS client. Any NRS client: A node that uses the NRS is called an NRS client. Any
node that initiates a name registration, resolution, or update node that initiates a name registration, resolution, or update
procedure is an NRS client. That is, NRS resolvers, ICN client procedure is an NRS client; that is, NRS resolvers, ICN client
nodes, ICN routers, or producers can be NRS clients. nodes, ICN routers, or producers can be NRS clients.
3. Background 3. Background
A pure name-based routing approach in ICN has inherent challenges in A pure name-based routing approach in ICN has inherent challenges in
enabling a globally scalable routing system, accommodating producer enabling a globally scalable routing system, accommodating producer
mobility, and supporting off-path caching. In order to address these mobility, and supporting off-path caching. In order to address these
challenges, an NRS has been utilized in proposals and literature of challenges, an NRS has been utilized in proposals and literature of
several ICN projects as follows: several ICN projects as follows:
* Routing scalability: In ICN, application names identifying Routing scalability: In ICN, application names identifying content
contents are intended to be used directly for packet delivery, so are intended to be used directly for packet delivery, so ICN
ICN routers run a name-based routing protocol to build name-based routers run a name-based routing protocol to build name-based
routing and forwarding tables. Similar to the scalability routing and forwarding tables. Similar to the scalability
challenge of IP routing, if non-aggregatable name prefixes are challenge of IP routing, if non-aggregatable name prefixes are
injected into the Default Route Free Zone (DFZ) of ICN routers, injected into the Default Route Free Zone (DFZ) of ICN routers,
they would be driving the uncontrolled growth of the DFZ routing they would be driving the uncontrolled growth of the DFZ routing
table size. Thus, providing the level of indirection enabled by table size. Thus, providing the level of indirection enabled by
an NRS in ICN can be an approach to keeping the routing table size an NRS in ICN can be an approach to keeping the routing table size
under control. The NRS system resolves name prefixes which do not under control. The NRS system resolves name prefixes that do not
exist in the DFZ forwarding table into globally routable prefixes exist in the DFZ forwarding table into globally routable prefixes
such as one proposed in NDN [Afanasyev]. Another approach dealing such as the one proposed in NDN [Afanasyev]. Another approach
with routing scalability is the Multi-level Distributed Hash dealing with routing scalability is the Multi-level Distributed
Table (MDHT) used in NetInf [Dannewitz]. It provides name-based Hash Table (MDHT) used in NetInf [Dannewitz]. It provides name-
anycast routing that can support a non-hierarchical namespace and based anycast routing that can support a non-hierarchical
can be adopted on a global scale [Dannewitz2]. namespace and can be adopted on a global scale [Dannewitz2].
* Producer mobility: In ICN, if a producer moves into a different Producer mobility: In ICN, if a producer moves into a different name
name domain that uses a different name prefix, the request for a domain that uses a different name prefix, the request for a
content produced by the moving producer with the origin content content produced by the moving producer with the origin content
name must be forwarded to the moving producer's new location. name must be forwarded to the moving producer's new location.
Especially in a hierarchical naming scheme, producer mobility Especially in a hierarchical naming scheme, producer mobility
support is much harder than in a flat naming scheme since the support is much harder than in a flat naming scheme since the
routing tables in a broader area need to be updated to track the routing tables in a broader area need to be updated to track the
producer movement. Therefore, various ICN architectures such as producer movement. Therefore, various ICN architectures such as
NetInf [Dannewitz] and MobilityFirst [MF] have adopted NRS systems NetInf [Dannewitz] and MobilityFirst [MF] have adopted NRS systems
to tackle the issues of producers whose location changes. to tackle the issues of producers whose location changes.
* Off-path caching: In-network caching is a common feature of an ICN Off-path caching: In-network caching is a common feature of an ICN
architecture. Caching approaches can be categorized into on-path architecture. Caching approaches can be categorized into on-path
caching and off-path caching, according to the location of caches caching and off-path caching, according to the location of caches
in relation to the forwarding path from the original content store in relation to the forwarding path from the original content store
to a consumer. Off-path caching, sometimes also referred to as to a consumer. Off-path caching, sometimes also referred to as
content replication or content storing, aims to replicate a Named content replication or content storing, aims to replicate a Named
Data Object in various locations within a network in order to Data Object in various locations within a network in order to
increase the availability of contents, reduce access latency, or increase the availability of content, reduce access latency, or
both. These caching locations may not be lying along the content both. These caching locations may not be lying along the content
forwarding path. Thus, finding off-path cached contents requires forwarding path. Thus, finding off-path cached content requires
more complex forwarding procedures if a pure name-based routing is more complex forwarding procedures if a pure name-based routing is
employed. In order to support access to off-path caches, the employed. In order to support access to off-path caches, the
locations of replicas are usually advertised into a name-based locations of replicas are usually advertised into a name-based
routing system or into an NRS as described in [Bayhan]. routing system or into an NRS as described in [Bayhan].
This document discusses architectural considerations and implications This document discusses architectural considerations and implications
of ICN when an NRS is utilized to solve such challenges facing a of ICN when an NRS is utilized to solve such challenges facing a
name-based routing in ICN. name-based routing in ICN.
4. Implications of NRS in ICN 4. Implications of an NRS in ICN
An NRS is not a mandatory part of an ICN architecture, as the An NRS is not a mandatory part of an ICN architecture, as the
majority of ICN architectures uses name-based routing that avoids the majority of ICN architectures uses name-based routing that avoids the
need for a name resolution procedure. Therefore, the utilization of need for a name resolution procedure. Therefore, the utilization of
an NRS in an ICN architecture changes some architectural aspects at an NRS in an ICN architecture changes some architectural aspects at
least with respect to forwarding procedures, latency, and security, least with respect to forwarding procedures, latency, and security,
as discussed below: as discussed below:
* Forwarding procedure: When an NRS is included in an ICN Forwarding procedure: When an NRS is included in an ICN
architecture, the name resolution procedure has to be included in architecture, the name resolution procedure has to be included in
the ICN overall routing and forwarding architectural procedures. the ICN overall routing and forwarding architectural procedures.
To integrate an NRS into an ICN architecture, there are certain To integrate an NRS into an ICN architecture, there are certain
things that have to be decided and specified such as where, when things that have to be decided and specified such as where, when,
and how the name resolution task is performed. and how the name resolution task is performed.
* Latency: When an NRS is included in an ICN architecture, Latency: When an NRS is included in an ICN architecture, additional
additional latency introduced by the name resolution process is latency introduced by the name resolution process is incurred by
incurred by the routing and forwarding system. Although the the routing and forwarding system. Although the latency due to
latency due to the name resolution is added, the total latency of the name resolution is added, the total latency of individual
individual requests being served could be lower if the nearest requests being served could be lower if the nearest copies or off-
copies or off-path caches can be located by the NRS lookup path caches can be located by the NRS lookup procedure.
procedure. Additionally, there might be a favorable trade-off Additionally, there might be a favorable trade-off between the
between the name resolution latency and inter-domain traffic name resolution latency and inter-domain traffic reduction by
reduction by finding the nearest off-path cached copy of the finding the nearest off-path cached copy of the content. Finding
content. Finding the nearest cache holding the content might the nearest cache holding the content might significantly reduce
significantly reduce the content discovery as well as delivery the content discovery as well as delivery latency.
latency.
* Security: When any new component such as an NRS is introduced in Security: When any new component such as an NRS is introduced in the
the ICN architecture, the attack surface may increase. Protection ICN architecture, the attack surface may increase. Protection of
of the NRS system itself against attacks such as Distributed the NRS system itself against attacks such as Distributed Denial
Denial of Service (DDoS) and spoofing or alteration of name of Service (DDoS) and spoofing or alteration of name mapping
mapping records and related signaling messages may be challenging. records and related signaling messages may be challenging.
5. ICN Architectural Considerations for NRS 5. ICN Architectural Considerations for NRS
This section discusses the various items that can be considered from This section discusses the various items that can be considered from
the perspective of ICN architecture when employing an NRS system. the perspective of ICN architecture when employing an NRS system.
These items are related to the registration, resolution, and update These items are related to the registration, resolution, and update
of name mapping records, protocols and messages, and integration with of name mapping records, protocols and messages, and integration with
the routing system. the routing system.
5.1. Name mapping records registration, resolution, and update 5.1. Name Mapping Records Registration, Resolution, and Update
When an NRS is integrated in ICN architecture, the functions related When an NRS is integrated in ICN architecture, the functions related
to the registration, resolution and update of name mapping records to the registration, resolution, and update of name mapping records
have to be considered. The NRS nodes maintain the name mapping have to be considered. The NRS nodes maintain the name mapping
records and may exist as an overlay network over the ICN routers, records and may exist as an overlay network over the ICN routers,
that is, they communicate to each other through ICN routers. that is, they communicate to each other through ICN routers.
Figure 1 shows the NRS nodes and NRS clients connected through an Figure 1 shows the NRS nodes and NRS clients connected through an
underlying network. The NRS nodes should be deployed in such a underlying network. The NRS nodes should be deployed in such a
manner that an NRS node is always available at a short distance from manner that an NRS node is always available at a short distance from
an NRS client so that communication latency for the name registration an NRS client so that communication latency for the name registration
and resolution requested by the NRS client remains very low. The and resolution requested by the NRS client remains very low. The
name registration, name resolution and name record update procedures name registration, name resolution, and name record update procedures
are briefly discussed below. are briefly discussed below.
+------------+ +------------+ +------------+ +------------+
| NRS Node | | NRS Node | | NRS Node | | NRS Node |
+------------+ +------------+ +------------+ +------------+
| | | |
| | | |
+------------+ | | +------------+ +------------+ | | +------------+
| NRS Client |--------------------------------------| NRS Client | | NRS Client |--------------------------------------| NRS Client |
+------------+ underlying network +------------+ +------------+ underlying network +------------+
Figure 1: NRS nodes and NRS clients connected through an Figure 1: NRS Nodes and NRS Clients Connected through an
underlying network Underlying Network
* Name registration: Name registration is performed by the producer Name registration: Name registration is performed by the producer
(as an NRS client) when it creates a new content. When a producer (as an NRS client) when it creates a new content. When a producer
creates content and assigns a name from its name prefix space to creates content and assigns a name from its name prefix space to
the content, the producer performs the name registration in an NRS the content, the producer performs the name registration in an NRS
node. Name registration may be performed by an ICN router when node. Name registration may be performed by an ICN router when
the ICN architecture supports off-path caching or cooperative the ICN architecture supports off-path caching or cooperative
caching since involving an NRS may be a good idea for off-path caching since involving an NRS may be a good idea for off-path
caching. The ICN routers with forwarder caches do not require caching. The ICN routers with forwarder caches do not require
name registration for their cached content because they lie on the name registration for their cached content because they lie on the
path toward an upstream content store or producer. They will be path toward an upstream content store or producer. They will be
hit when a future request is forwarded to the content producer by hit when a future request is forwarded to the content producer by
skipping to change at page 7, line 40 skipping to change at line 308
invoke the name registration procedure so that other ICN routers invoke the name registration procedure so that other ICN routers
can depend on name resolutions to know about the off-path cache can depend on name resolutions to know about the off-path cache
locations. If a content gets cached in many off-path ICN routers, locations. If a content gets cached in many off-path ICN routers,
all of them may register the same content names in the same NRS all of them may register the same content names in the same NRS
node, resulting in multiple registration actions. In this case, node, resulting in multiple registration actions. In this case,
the NRS node adds the new location of the content to the name the NRS node adds the new location of the content to the name
record together with the previous locations. In this way, each of record together with the previous locations. In this way, each of
the name records stored in the NRS node may contain multiple the name records stored in the NRS node may contain multiple
locations of the content. Assigning validity time or a lifetime locations of the content. Assigning validity time or a lifetime
of each mapping record may be considered especially for the off- of each mapping record may be considered especially for the off-
path caching contents and managing mobility. path caching content and managing mobility.
* Name resolution: Name resolution is performed by an NRS client to Name resolution: Name resolution is performed by an NRS client to
obtain the name record from an NRS node by sending a name obtain the name record from an NRS node by sending a name
resolution request message and getting a response containing the resolution request message and getting a response containing the
record. In the name-based ICN routing context, the name record. In the name-based ICN routing context, the name
resolution is needed by any ICN router whose forwarding resolution is needed by any ICN router whose forwarding
information base (FIB) does not contain the requested name prefix. information base (FIB) does not contain the requested name prefix.
Name resolution may also be performed by the consumer (especially Name resolution may also be performed by the consumer (especially
in the case where the consumer is multihomed) to forward the in the case where the consumer is multihomed) to forward the
content request in a better direction so that it obtains the content request in a better direction so that it obtains the
content from the nearest cache. If the consumer is single homed, content from the nearest cache. If the consumer is single homed,
it may not bother to perform name resolution, instead depending on it may not bother to perform name resolution, instead depending on
either straightforward name-based routing or name resolution by an either straightforward name-based routing or name resolution by an
upstream ICN router. On this case, the consumer creates the upstream ICN router. In this case, the consumer creates the
content request packet containing the content name and forwards to content request packet containing the content name and forwards to
the nearest ICN router. The ICN router checks its FIB table to the nearest ICN router. The ICN router checks its FIB table to
see where to forward the content request. If the ICN router fails see where to forward the content request. If the ICN router fails
to know the requested content reachable, it performs name to identify whether the requested content is reachable, it
resolution to obtain the name mapping record and adds this performs name resolution to obtain the name mapping record and
information to its FIB. The ICN router may also perform name adds this information to its FIB. The ICN router may also perform
resolution even before the arrival of a content request to use the name resolution even before the arrival of a content request to
name mapping record to configure its FIB. use the name mapping record to configure its FIB.
* Name record update: Name record update is carried out when a Name record update: Name record update is carried out when a content
content name mapping record changes, e.g. the content is not name mapping record changes, e.g., the content is not available in
available in one or more of previous locations. The name record one or more of the previous locations. The name record update
update includes the substitution and deletion of the name mapping includes the substitution and deletion of the name mapping
records. The name record update may take place explicitly by the records. The name record update may take place explicitly by the
exchange of name record update messages or implicitly when a exchange of name record update messages or implicitly when a
timeout occurs and a name record is deemed to be invalid. The timeout occurs and a name record is deemed to be invalid. The
implicit update is possible when each record is accompanied by a implicit update is possible when each record is accompanied by a
lifetime value. The lifetime can be renewed only by the lifetime value. The lifetime can be renewed only by the
authoritative producer or node. The cached mapping records get authoritative producer or node. The cached mapping records get
erased after the lifetime expires unless a lifetime extension erased after the lifetime expires unless a lifetime extension
indication is obtained from the authoritative producer. indication is obtained from the authoritative producer.
5.2. Protocols and Semantics 5.2. Protocols and Semantics
In order to develop an NRS system within a local ICN network domain In order to develop an NRS system within a local ICN network domain
or global ICN network domain, new protocols and semantics must be or global ICN network domain, new protocols and semantics must be
designed and implemented to manage and resolve names among different designed and implemented to manage and resolve names among different
name spaces. namespaces.
One way of implementing an NRS for CCNx is by extending the basic TLV One way of implementing an NRS for CCNx is by extending the basic TLV
format and semantics [RFC8569] [RFC8609]. For instance, name format and semantics [RFC8569] [RFC8609]. For instance, name
resolution and response messages can be implemented by defining new resolution and response messages can be implemented by defining new
type fields in the Interest and Content Object messages [CCNxNRS]. type fields in the Interest and Content Object messages [CCNxNRS].
By leveraging the existing CCNx Interest and Content Object packets By leveraging the existing CCNx Interest and Content Object packets
for name resolution and registration, the NRS system can be deployed for name resolution and registration, the NRS system can be deployed
with a few ICN protocol changes. However, because of confining the with a few ICN protocol changes. However, because of confining the
changes to the basic ICN protocol and semantics, the NRS system may changes to the basic ICN protocol and semantics, the NRS system may
not be able to exploit more flexible and scalable designs. not be able to exploit more flexible and scalable designs.
On the other hand, an NRS system can be designed independently with On the other hand, an NRS system can be designed independently with
its own protocol and semantics like the NRS system described in its own protocol and semantics like the NRS system described in
[Hong]. For instance, the NRS protocol and messages can be [Hong]. For instance, the NRS protocol and messages can be
implemented by using a RESTful API and the NRS can be operated as an implemented by using a RESTful API, and the NRS can be operated as an
application protocol independent of the rest of the ICN protocol. application protocol independent of the rest of the ICN protocol.
5.3. Routing System 5.3. Routing System
An NRS reduces the routing complexity of ICN architecture compared to An NRS reduces the routing complexity of ICN architecture compared to
pure name-based routing. It does so by permitting the routing system pure name-based routing. It does so by permitting the routing system
to update the routing table on demand through the help of name to update the routing table on demand with the help of name records
records obtained from NRS. The routing system therefore needs to obtained from NRS. The routing system therefore needs to make name
make name resolution requests and process the information returned, resolution requests and process the information returned, such as a
such as a prefix, a locator, an off-path-cache pointer, or an alias prefix, a locator, an off-path-cache pointer, or an alias name,
name, obtained from the name resolution. obtained from the name resolution.
No matter what kind of information is obtained from the name No matter what kind of information is obtained from the name
resolution, as long as it is in the form of a name, the content resolution, as long as it is in the form of a name, the content
request message in the routing system may be reformatted with the request message in the routing system may be reformatted with the
obtained information. In this case, the content name requested obtained information. In this case, the content name requested
originally by a consumer needs to be involved in the reformatted originally by a consumer needs to be involved in the reformatted
content request to check the integrity of the binding between the content request to check the integrity of the binding between the
name and the requested content. In other words, the information name and the requested content. In other words, the information
obtained from the name resolution is used to forward the content obtained from the name resolution is used to forward the content
request and the original content name requested by a consumer is used request, and the original content name requested by a consumer is
to identify the content. Alternatively, the resolved information may used to identify the content. Alternatively, the resolved
be used to build the routing table. information may be used to build the routing table.
The information obtained from name resolution may not be in the form The information obtained from name resolution may not be in the form
of a name. For example, it may identify tunnel endpoints by IP of a name. For example, it may identify tunnel endpoints by IP
address and instead be used to construct an IP protocol tunnel address and instead be used to construct an IP protocol tunnel
through which to forward the content request. through which to forward the content request.
6. Conclusion 6. Conclusion
A Name Resolution Service (NRS) is not a mandatory part in an ICN A Name Resolution Service (NRS) is not a mandatory part in an ICN
architecture, as the majority of ICN architectures use name-based architecture, as the majority of ICN architectures use name-based
routing which does not employ a name resolution procedure. However, routing that does not employ a name resolution procedure. However,
such name-based routing in ICN has inherent challenges in enabling a such name-based routing in ICN has inherent challenges in enabling a
globally scalable routing system, accommodating producer mobility, globally scalable routing system, accommodating producer mobility,
and supporting off-path caching. In order to address these and supporting off-path caching. In order to address these
challenges, an NRS system has been introduced in several ICN challenges, an NRS system has been introduced in several ICN
projects. Therefore, this document describes how the ICN projects. Therefore, this document describes how the ICN
architecture changes when an NRS is utilized and how this affects the architecture changes when an NRS is utilized and how this affects the
ICN routing system. ICN routing system.
The document defines a few terminologies related to an NRS and The document defines a few terminologies related to an NRS and
explains some inherent challenges of pure name-based routing in ICN explains some inherent challenges of pure name-based routing in ICN
skipping to change at page 10, line 18 skipping to change at line 421
This document describes how the ICN architecture would change with This document describes how the ICN architecture would change with
respect to procedures, latency, and security when an NRS is utilized. respect to procedures, latency, and security when an NRS is utilized.
According to the ICN architectural changes, this document describes According to the ICN architectural changes, this document describes
ICN architectural considerations for NRS such as the functions ICN architectural considerations for NRS such as the functions
related to the registration, resolution and update of name mapping related to the registration, resolution and update of name mapping
records, protocols and semantics to implement an NRS system, and the records, protocols and semantics to implement an NRS system, and the
routing system involving the name resolution. routing system involving the name resolution.
7. IANA Considerations 7. IANA Considerations
There are no IANA actions required by this document. This document has no IANA actions.
8. Security Considerations 8. Security Considerations
When any new component such as an NRS is introduced in the ICN When any new component such as an NRS is introduced in the ICN
architecture, the attack surface increases. The related security architecture, the attack surface increases. The related security
vulnerability issues are discussed below: vulnerability issues are discussed below:
* Name space security: In order to deploy an NRS system in ICN Namespace security: In order to deploy an NRS system in ICN
architecture, ICN name spaces, which may be assigned by architecture, ICN namespaces, which may be assigned by
authoritative entities, must be securely mapped to the content authoritative entities, must be securely mapped to the content
publishers and securely managed by them. According to the ICN publishers and securely managed by them. According to the ICN
research challenges [RFC7927], a new name space can also provide research challenges [RFC7927], a new namespace can also provide an
an integrity verification function to authenticate its publisher. integrity verification function to authenticate its publisher.
The issues of namespace authentication and the mapping among The issues of namespace authentication and the mapping among
different name spaces require further investigation. different namespaces require further investigation.
* NRS system security: An NRS requires the deployment of new NRS system security: An NRS requires the deployment of new entities
entities (e.g. NRS servers) to build distributed and scalable NRS (e.g., NRS servers) to build distributed and scalable NRS systems.
systems. Thus, the entities, e.g., NRS server maintaining a Thus, the entities, e.g., an NRS server maintaining a mapping
mapping database, could be the focus of attacks by receiving database, could be the focus of attacks by receiving malicious
malicious requests from innumerable adversaries comprising a requests from innumerable adversaries comprising of Denial-of-
Denial of Service or Distributed Denial of service attacks. In Service or Distributed-Denial-of-Service attacks. In addition,
addition, NRS clients in general must trust the NRS nodes in other NRS clients in general must trust the NRS nodes in other network
network domains to some degree and communication among them must domains to some degree, and communication among them must also be
also be protected securely to prevent malicious entities from protected securely to prevent malicious entities from
participating in this communication. The history of name participating in this communication. The history of name
resolution data requires to be stored and analyzed as in passive resolution data requires to be stored and analyzed as in passive
DNS to uncover potential security incidents or discover malicious DNS to uncover potential security incidents or discover malicious
infrastructures. infrastructures.
* NRS protocol and message security: In an NRS system, the protocols NRS protocol and message security: In an NRS system, the protocols
to generate, transmit and receive NRS messages related to the name to generate, transmit, and receive NRS messages related to the
registration, resolution, and record update should be protected by name registration, resolution, and record update should be
proper security mechanisms. Proper security measures must be protected by proper security mechanisms. Proper security measures
provided so that only legitimate nodes can initiate and read NRS must be provided so that only legitimate nodes can initiate and
messages. These messages must have secured by integrity read NRS messages. These messages must be secured by integrity
protection and authentication mechanism so that unauthorized protection and authentication mechanisms so that unauthorized
parties cannot manipulate them when being forwarded through the parties cannot manipulate them when being forwarded through the
network. Security measures to encrypt these messages should also network. Security measures to encrypt these messages should also
be developed to thwart all threats to both security and privacy. be developed to thwart all threats to both security and privacy.
Numerous problems similar to the security issues of an IP network Numerous problems similar to the security issues of an IP network
and DNS can affect the overall ICN architecture. The DNS QNAME and DNS can affect the overall ICN architecture. The DNS QNAME
minimization type of approach would be suitable for preserving minimization type of approach would be suitable for preserving
privacy in the name resolution process. Therefore, security privacy in the name resolution process. Therefore, security
mechanisms such as accessibility, authentication, etc., for the mechanisms such as accessibility, authentication, etc., for the
NRS system [RFC9138] should be considered to protect not only the NRS system [RFC9138] should be considered to protect not only the
NRS system, but also the ICN architecture overall. NRS system but also the ICN architecture overall.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I.,
Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch,
"Information-Centric Networking (ICN) Research "Information-Centric Networking (ICN) Research
Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016,
<https://www.rfc-editor.org/info/rfc7927>. <https://www.rfc-editor.org/info/rfc7927>.
[RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric
Networking (CCNx) Semantics", Networking (CCNx) Semantics", RFC 8569,
https://www.rfc-editor.org/info/rfc8569 , July 2019. DOI 10.17487/RFC8569, July 2019,
<https://www.rfc-editor.org/info/rfc8569>.
[RFC8609] Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric
Format", https://www.rfc-editor.org/info/rfc8609 , July Networking (CCNx) Messages in TLV Format", RFC 8609,
2019. DOI 10.17487/RFC8609, July 2019,
<https://www.rfc-editor.org/info/rfc8609>.
[RFC9138] Hong, J. et al., "Design Considerations for Name [RFC9138] Hong, J., You, T., Dong, L., Westphal, C., and B. Ohlman,
Resolution Service in Information-Centric Networking "Design Considerations for Name Resolution Service in
(ICN)", https://www.rfc-editor.org/info/rfc9138 , November Information-Centric Networking (ICN)", RFC 9138,
2021. DOI 10.17487/RFC9138, December 2021,
<https://www.rfc-editor.org/info/rfc9138>.
9.2. Informative References 9.2. Informative References
[NDN] "NSF Named Data Networking project.",
http://www.named-data.net .
[CCNx] "Content Centric Networking project.",
https://wiki.fd.io/view/Cicn .
[Afanasyev] [Afanasyev]
Afanasyev, A. et al., "SNAMP: Secure Namespace Mapping to Afanasyev, A., Yi, C., Wang, L., Zhang, B., and L. Zhang,
Scale NDN Forwarding", IEEE Global Internet Symposium , "SNAMP: Secure namespace mapping to scale NDN forwarding",
April 2015. 2015 IEEE Conference on Computer Communications Workshops
(INFOCOM WKSHPS), DOI 10.1109/INFCOMW.2015.7179398, April
[Zhang2] Zhang, Y., "A Survey of Mobility Support in Named Data 2015, <https://doi.org/10.1109/INFCOMW.2015.7179398>.
Networking", NAMED-ORIENTED MOBILITY: ARCHITECTURES,
ALGORITHMS, AND APPLICATIONS(NOM) , 2016.
[Ravindran] [Bayhan] Bayhan, S., Ott, J., Kangasharju, J., Sathiaseelan, A.,
Ravindran, R. et al., "Forwarding-Label support in CCN and J. Crowcroft, "On Content Indexing for Off-Path
Protocol", draft-ravi-icnrg-ccn-forwarding-label-01 , July Caching in Information-Centric Networks", ACM ICN,
2017. DOI 10.1145/2984356.2984372, September 2016,
<https://doi.org/10.1145/2984356.2984372>.
[SAIL] "FP7 SAIL project.", http://www.sail-project.eu/ . [CCNx] "Cicn", <https://wiki.fd.io/view/Cicn>.
[MF] "NSF Mobility First project.", [CCNxNRS] Hong, J., You, T., and Y. Hong, "CCNx Extension for Name
http://mobilityfirst.winlab.rutgers.edu/ . Resolution Service", Work in Progress, Internet-Draft,
draft-hong-icnrg-ccnx-nrs-02, 2 July 2018,
<https://datatracker.ietf.org/doc/html/draft-hong-icnrg-
ccnx-nrs-02>.
[Bayhan] Bayhan, S. et al., "On Content Indexing for Off-Path [Dannewitz]
Caching in Information-Centric Networks", ACM ICN , and , "Network of Information (NetInf) – An information-
September 2016. centric networking architecture", Computer
Communications vol. 36, issue 7,
DOI 10.1016/j.comcom.2013.01.009, April 2013,
<https://doi.org/10.1016/j.comcom.2013.01.009>.
[CCNxNRS] Hong, J. et al., "CCNx Extension for Name Resolution [Dannewitz2]
Service", draft-hong-icnrg-ccnx-nrs-02 , July 2018. Dannewitz, C., D'Ambrosio, M., and V. Vercellone,
"Hierarchical DHT-based name resolution for information-
centric networks", Computer Communications vol. 36, issue
7, DOI 10.1016/j.comcom.2013.01.014, April 2013,
<https://doi.org/10.1016/j.comcom.2013.01.014>.
[Hong] Hong, J., Chun, W., and H. Jung, "Demonstrating a Scalable [Hong] Hong, J., Chun, W., and H. Jung, "Demonstrating a Scalable
Name Resolution System for Information-Centric Name Resolution System for Information-Centric
Networking", ACM ICN , September 2015. Networking", ACM ICN, DOI 10.1145/2810156.2812617,
September 2015, <https://doi.org/10.1145/2810156.2812617>.
[Dannewitz] [MF] Future Internet Architecture (FIA), "MobilityFirst",
Dannewitz, C. et al., "Network of Information (NetInf)-An <http://mobilityfirst.cs.umass.edu/>.
information centric networking architecture", Computer
Communications vol. 36, no. 7, April 2013.
[Dannewitz2] [NDN] NDN, "Named Data Networking", September 2010,
Dannewitz, C., DAmbrosio, M., and V. Vercellone, <https://www.named-data.net>.
"Hierarchical DHT-based name resolution for Information-
Centric Networks", Computer Communications vol. 36, no. 7, [Ravindran]
April 2013. Ravindran, R., Chakraborti, A., and A. Azgin, "Forwarding
Label support in CCN Protocol", Work in Progress,
Internet-Draft, draft-ravi-icnrg-ccn-forwarding-label-02,
5 March 2018, <https://datatracker.ietf.org/doc/html/
draft-ravi-icnrg-ccn-forwarding-label-02>.
[SAIL] "Scalable and Adaptive Internet Solutions (SAIL)",
<https://www.sail-project.eu/>.
[Zhang2] Zhang, Y., Afanasyev, A., Burke, J., and L. Zhang, "A
Survey of Mobility Support in Named Data Networking",
Named Data Networking, Workshop on Name-Oriented Mobility:
Architecture, Algorithms and Applications (NOM), April
2016.
Acknowledgements Acknowledgements
The authors would like to thank Dave Oran (ICNRG Co-chair) for very The authors would like to thank Dave Oran (ICNRG Co-chair) for very
useful reviews and comments on the document and they helped to useful reviews and comments, which helped to immeasurably improve
immeasurably improve the document. this document.
Authors' Addresses Authors' Addresses
Jungha Hong Jungha Hong
ETRI ETRI
218 Gajeong-ro, Yuseung-Gu Yuseung-Gu
218 Gajeong-ro
Daejeon Daejeon
34129
Republic of Korea
Email: jhong@etri.re.kr Email: jhong@etri.re.kr
Tae-Wan You Tae-Wan You
ETRI ETRI
218 Gajeong-ro, Yuseung-Gu Yuseung-Gu
218 Gajeong-ro
Daejeon Daejeon
34129
Republic of Korea
Email: twyou@etri.re.kr Email: twyou@etri.re.kr
Ved Kafle Ved Kafle
NICT NICT
Koganei
4-2-1 Nukui-Kitamachi, Tokyo 4-2-1 Nukui-Kitamachi, Tokyo
184-8795 184-8795
Japan Japan
Email: kafle@nict.go.jp Email: kafle@nict.go.jp
 End of changes. 80 change blocks. 
238 lines changed or deleted 252 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/