Name Resolution Service (NRS):

An NRS in ICN is defined as a service that provides the function of translating a content name or a data object name into some other information such as a routable prefix, a locator, an off-path-cache pointer, or an alias name that is more amenable than the input name to forwarding the object request toward the target destination storing the NDO [RFC 9138]. An NRS is most likely implemented through the use of a distributed mapping database system. The Domain Name System (DNS) may be used as an NRS. However, in this case, the requirements of frequent updates of NRS records due to the creations of a lot of new NDOs and changes in their locations in the network need to be considered.

NRS server:

An NRS comprises the distributed NRS servers storing the mapping records in their databases. NRS servers store and maintain the mapping records that keep the mappings of content or object name to some other information that is used for forwarding the content request or the content itself.

NRS resolver:

The client-side function of an NRS is called an NRS resolver. The NRS resolver is responsible for initiating name resolution request queries that ultimately lead to a name resolution of the target data objects. NRS resolvers can be located in the consumer (or client) nodes and/or ICN routers. An NRS resolver may also cache the mapping records obtained through the name resolution for later usage.

Name registration:

In order to populate the NRS, the content names and their mapping records must be registered in the NRS system by a publisher who has access rights to at least one authoritative NRS server or by a producer who generates named data objects. The records contain the mapping of an object name to some information such as other alias names, routable prefixes, and locators, which are used for forwarding the content request. Thus, a publisher or producer of content creates an NRS registration request and sends it to an NRS server. On registration, the NRS server stores (or updates) the name mapping record in the database and sends an acknowledgement back to the producer or publisher that made the registration request.

Name resolution:

Name resolution is the main function of the NRS system. It is performed by an NRS resolver, which can be deployed on a consumer node or an ICN router. Resolvers are responsible for either returning a cached mapping record (whose lifetime has not expired) or alternatively sending a name resolution request toward an NRS server. The NRS server searches for the content name in its mapping record database and, if found, retrieves the mapping record and returns it in a name resolution response message to the NRS resolver.

NRS node:

NRS servers are also referred to as NRS nodes that maintain the name records. The terms are used interchangeably.

NRS client:

A node that uses the NRS is called an NRS client. Any node that initiates a name registration, resolution, or update procedure is an NRS client; that is, NRS resolvers, ICN client nodes, ICN routers, or producers can be NRS clients.

Routing scalability:

In ICN, application names identifying content are intended to be used directly for packet delivery, so ICN routers run a name-based routing protocol to build name-based routing and forwarding tables. Similar to the scalability challenge of IP routing, if non-aggregatable name prefixes are injected into the Default Route Free Zone (DFZ) of ICN routers, they would be driving the uncontrolled growth of the DFZ routing table size. Thus, providing the level of indirection enabled by an NRS in ICN can be an approach to keeping the routing table size under control. The NRS system resolves name prefixes that do not exist in the DFZ forwarding table into globally routable prefixes such as the one proposed in NDN [Afanasyev]. Another approach dealing with routing scalability is the Multi-level Distributed Hash Table (MDHT) used in NetInf [Dannewitz]. It provides name-based anycast routing that can support a non-hierarchical namespace and can be adopted on a global scale [Dannewitz2].

Producer mobility:

In ICN, if a producer moves into a different name domain that uses a different name prefix, the request for a content produced by the moving producer with the origin content name must be forwarded to the moving producer's new location. Especially in a hierarchical naming scheme, producer mobility 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 producer movement. Therefore, various ICN architectures such as NetInf [Dannewitz] and MobilityFirst [MF] have adopted NRS systems to tackle the issues of producers whose location changes.

Off-path caching:

In-network caching is a common feature of an ICN architecture. Caching approaches can be categorized into on-path caching and off-path caching, according to the location of caches in relation to the forwarding path from the original content store to a consumer. Off-path caching, sometimes also referred to as content replication or content storing, aims to replicate a Named Data Object in various locations within a network in order to increase the availability of content, reduce access latency, or both. These caching locations may not be lying along the content forwarding path. Thus, finding off-path cached content requires more complex forwarding procedures if a pure name-based routing is employed. In order to support access to off-path caches, the locations of replicas are usually advertised into a name-based routing system or into an NRS as described in [Bayhan].

Forwarding procedure:

When an NRS is included in an ICN architecture, the name resolution procedure has to be included in the ICN overall routing and forwarding architectural procedures. To integrate an NRS into an ICN architecture, there are certain things that have to be decided and specified such as where, when, and how the name resolution task is performed.

Latency:

When an NRS is included in an ICN architecture, additional latency introduced by the name resolution process is incurred by the routing and forwarding system. Although the latency due to the name resolution is added, the total latency of individual requests being served could be lower if the nearest copies or off-path caches can be located by the NRS lookup procedure. Additionally, there might be a favorable trade-off between the name resolution latency and inter-domain traffic reduction by finding the nearest off-path cached copy of the content. Finding the nearest cache holding the content might significantly reduce the content discovery as well as delivery latency.

Security:

When any new component such as an NRS is introduced in the ICN architecture, the attack surface may increase. Protection of the NRS system itself against attacks such as Distributed Denial of Service (DDoS) and spoofing or alteration of name mapping records and related signaling messages may be challenging.

               +------------+             +------------+
               |  NRS Node  |             |  NRS Node  |
               +------------+             +------------+
                     |                          |
                     |                          |
  +------------+     |                          |     +------------+
  | NRS Client |--------------------------------------| NRS Client |
  +------------+         underlying network           +------------+
                  

Name registration:

Name registration is performed by the producer (as anNRS client) when it creates a new content. When a producer creates contentand assigns a name from its name prefix space to the content, the producerperforms the name registration in an NRS node. Name registration may beperformed by an ICN router when the ICN architecture supports off-path cachingor cooperative caching since involving an NRS may be a good idea for off-pathcaching. The ICN routers with forwarder caches do not require nameregistration for their cached content because they lie on the path toward anupstream content store or producer. They will be hit when a future request isforwarded to the content producer by an ICN router lying downstream toward theICN client node. However, ICN routers performing off-path caching of contentmust invoke the name registration procedure so that other ICN routers candepend on name resolutions to know about the off-path cache locations. If acontent gets cached in many off-path ICN routers, all of them may register thesame content names in the same NRS node, resulting in multiple registrationactions. In this case, the NRS node adds the new location of the content tothe name record together with the previous locations. In this way, each of thename records stored in the NRS node may contain multiple locations of thecontent. Assigning validity time or a lifetime of each mapping record may beconsidered especially for the off-path caching content and managing mobility.

Name resolution:

Name resolution is performed by an NRS client to obtain the name recordfrom an NRS node by sending a name resolution request message and getting aresponse containing the record. In the name-based ICN routing context, thename resolution is needed by any ICN router whose forwarding information base(FIB) does not contain the requested name prefix. Name resolution may also beperformed by the consumer (especially in the case where the consumer ismultihomed) to forward the content request in a better direction so that itobtains the content from the nearest cache. If the consumer is single homed,it may not bother to perform name resolution, instead depending on eitherstraightforward name-based routing or name resolution by an upstream ICNrouter. In this case, the consumer creates the content request packetcontaining the content name and forwards to the nearest ICN router. The ICNrouter checks its FIB table to see where to forward the content request. Ifthe ICN router fails to identify whether the requested content is reachable,it performs name resolution to obtain the name mapping record and adds thisinformation to its FIB. The ICN router may also perform name resolution evenbefore the arrival of a content request to use the name mapping record toconfigure its FIB.

Name record update:

Name record update is carried out when a content name mapping recordchanges, e.g., the content is not available in one or more of the previouslocations. The name record update includes the substitution and deletion ofthe name mapping records. The name record update may take place explicitly bythe exchange of name record update messages or implicitly when a timeoutoccurs and a name record is deemed to be invalid. The implicit update ispossible when each record is accompanied by a lifetime value. The lifetimecan be renewed only by the authoritative producer or node. The cached mappingrecords get erased after the lifetime expires unless a lifetime extensionindication is obtained from the authoritative producer.

Namespace security:

In order to deploy an NRS system in ICN architecture, ICN namespaces,which may be assigned by authoritative entities, must be securely mapped tothe content publishers and securely managed by them. According to the ICNresearch challenges [RFC 7927], a new namespace can also provide an integrity verification function to authenticate itspublisher. The issues of namespace authentication and the mapping amongdifferent namespaces require further investigation.

NRS system security:

An NRS requires the deployment of new entities (e.g., NRS servers) tobuild distributed and scalable NRS systems. Thus, the entities, e.g., an NRSserver maintaining a mapping database, could be the focus of attacks byreceiving malicious requests from innumerable adversaries comprising ofDenial-of-Service or Distributed-Denial-of-Service attacks. In addition, NRSclients in general must trust the NRS nodes in other network domains to somedegree, and communication among them must also be protected securely to preventmalicious entities from participating in this communication. The history ofname resolution data requires to be stored and analyzed as in passive DNS touncover potential security incidents or discover malicious infrastructures.

NRS protocol and message security:

In an NRS system, the protocols to generate, transmit, and receive NRSmessages related to the name registration, resolution, and record updateshould be protected by proper security mechanisms. Proper security measuresmust be provided so that only legitimate nodes can initiate and read NRSmessages. These messages must be secured by integrity protection andauthentication mechanisms so that unauthorized parties cannot manipulate themwhen being forwarded through the network. Security measures to encrypt thesemessages should also be developed to thwart all threats to both security andprivacy. Numerous problems similar to the security issues of an IP network andDNS can affect the overall ICN architecture. The DNS QNAME minimization typeof approach would be suitable for preserving privacy in the name resolutionprocess. Therefore, security mechanisms such as accessibility,authentication, etc., for the NRS system [RFC 9138] should be considered to protect not only the NRS system butalso the ICN architecture overall.

[RFC7927]

D. Kutscher, S. Eum, K. Pentikousis, I. Psaras, D. Corujo, D. Saucez, T. Schmidt, and M. Waehlisch, "Information-Centric Networking (ICN) Research Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016,
<https://www.rfc-editor.org/info/rfc7927>.

[RFC8569]

M. Mosko, I. Solis, and C. Wood, "Content-Centric Networking (CCNx) Semantics", RFC 8569, DOI 10.17487/RFC8569, July 2019,
<https://www.rfc-editor.org/info/rfc8569>.

[RFC8609]

M. Mosko, I. Solis, and C. Wood, "Content-Centric Networking (CCNx) Messages in TLV Format", RFC 8609, DOI 10.17487/RFC8609, July 2019,
<https://www.rfc-editor.org/info/rfc8609>.

[RFC9138]

J. Hong, T. You, L. Dong, C. Westphal, and B. Ohlman, "Design Considerations for Name Resolution Service in Information-Centric Networking (ICN)", RFC 9138, DOI 10.17487/RFC9138, December 2021,
<https://www.rfc-editor.org/info/rfc9138>.

[Afanasyev]

A. Afanasyev, C. Yi, L. Wang, B. Zhang, and L. Zhang, "SNAMP: Secure namespace mapping to scale NDN forwarding", DOI 10.1109/INFCOMW.2015.7179398, April 2015,
<https://doi.org/10.1109/INFCOMW.2015.7179398>.

[Bayhan]

S. Bayhan, , J. Ott, J. Kangasharju, A. Sathiaseelan, and J. Crowcroft, "On Content Indexing for Off-Path Caching in Information-Centric Networks", DOI 10.1145/2984356.2984372, September 2016,
<https://doi.org/10.1145/2984356.2984372>.

[CCNx]

"Cicn",
<https://wiki.fd.io/view/Cicn>.

[CCNxNRS]

ETRI, , , and , "CCNx Extension for Name Resolution Service", Internet-Draft draft-hong-icnrg-ccnx-nrs-02, July 2018,
<https://datatracker.ietf.org/doc/html/draft-hong-icnrg-ccnx-nrs-02>.

[Dannewitz]

C Dannewitz, D Kutscher, B Ohlman, S Farrell, B Ahlgren, and H Karl, "Network of Information (NetInf) - An information-centric networking architecture", DOI 10.1016/j.comcom.2013.01.009, April 2013,
<https://doi.org/10.1016/j.comcom.2013.01.009>.

[Dannewitz2]

C. Dannewitz, M. D'Ambrosio, and V. Vercellone, "Hierarchical DHT-based name resolution for information-centric networks", DOI 10.1016/j.comcom.2013.01.014, April 2013,
<https://doi.org/10.1016/j.comcom.2013.01.014>.

[Hong]

J. Hong, W. Chun, and H. Jung, "Demonstrating a Scalable Name Resolution System for Information-Centric Networking", DOI 10.1145/2810156.2812617, September 2015,
<https://doi.org/10.1145/2810156.2812617>.

[MF]

Future Internet Architecture (FIA), "MobilityFirst",
<http://mobilityfirst.cs.umass.edu/>.

[NDN]

NDN, "Named Data Networking", September 2010,
<https://www.named-data.net>.

[Ravindran]

Huawei Technologies, , , and , "Forwarding Label support in CCN Protocol", Internet-Draft draft-ravi-icnrg-ccn-forwarding-label-02, 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]

Y. Zhang, A. Afanasyev, J. Burke, and L. Zhang, "A Survey of Mobility Support in Named Data Networking", April 2016.

Jungha Hong

Tae-Wan You

Ved Kafle