Skip to main content

RFC 9236 - Architectural Considerations of Information-Centric Networking (ICN) Using a Name Resolution Service

Abstract​

This document describes architectural considerations and implications related to the use of a Name Resolution Service (NRS) in Information-Centric Networking (ICN). It explains how the ICN architecture can change when an NRS is utilized and how its use influences the ICN routing system. This document is a product of the Information-Centric Networking Research Group (ICNRG).

Status of This Memo​

This document is not an Internet Standards Track specification; it is published for informational purposes.

This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Information-Centric Networking Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.

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 (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Table of Contents​

    1. Introduction
    1. Terminology
    1. Background
    1. Implications of an NRS in ICN
    1. ICN Architectural Considerations for NRS
    1. Conclusion
    1. IANA Considerations
    1. Security Considerations
    1. References
  • Acknowledgements
  • Authors' Addresses

1. Introduction​

Information-Centric Networking (ICN) is an approach to evolving the Internet infrastructure to provide direct access to Named Data Objects (NDOs) by names. In two common ICN architectures, Named Data Networking (NDN) [NDN] and Content-Centric Networking (CCNx) [CCNx], the name of an NDO is used directly to route a request to retrieve the data object. Such direct name-based routing has inherent challenges in enabling a globally scalable routing system, accommodating producer mobility, and supporting off-path caching. These specific issues are discussed in detail in Section 3. In order to address these challenges, a Name Resolution Service (NRS) has been utilized in the literature as well as the proposals of several ICN projects [Afanasyev] [Zhang2] [Ravindran] [SAIL] [MF] [Bayhan].

This document describes the potential changes in the ICN architecture caused by the introduction of an NRS and the corresponding implication to the ICN routing system. It also describes ICN architectural considerations for the integration of an NRS. The scope of this document includes considerations from the perspective of an ICN architecture and routing system when using an NRS in ICN. A description of the NRS itself is provided in the companion NRS design considerations document [RFC9138], which provides the NRS approaches, functions, and design considerations.

This document represents the consensus of the Information-Centric Networking Research Group (ICNRG). It has been reviewed extensively by the Research Group (RG) members who are actively involved in the research and development of the technology covered by this document. It is not an IETF product and is not a standard.

2. Terminology​

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 [RFC9138]. An NRS is most likely implemented through the use of a distributed mapping database system. The Domain Name System (DNS) may be used as the NRS [NDN-DNS-Orchest].

NRS System: An NRS system is an application-layer distributed system that maintains the mapping records. It consists of NRS servers and the protocol that is used for managing and retrieving the mapping records.

NRS Server: An NRS server is a component of the NRS system that stores and maintains the mapping records. It also handles the name resolution requests from the NRS clients.

NRS Client: An NRS client is a component that sends name resolution requests to the NRS system. It can be an end host, a router, or an application.

Name Mapping Record: A name mapping record is an entry in the NRS database that maps a content name to some other information (e.g., a locator, an alias name).

3. Background​

In ICN, content names are used for routing content requests. This name-based routing has several challenges:

  • Scalability: The number of content objects is much larger than the number of hosts. Maintaining a routing table for all content names is challenging.
  • Producer Mobility: When a content producer moves, the routing information needs to be updated, which can be slow and costly.
  • Off-Path Caching: ICN supports in-network caching. However, accessing cached content that is not on the direct path from the requester to the producer is difficult with pure name-based routing.

An NRS can address these challenges by decoupling the content name from its location.

4. Implications of an NRS in ICN​

The introduction of an NRS in ICN has several implications:

  • Routing System: The routing system no longer needs to handle all content names. Instead, it can route based on locators or routable prefixes obtained from the NRS.
  • Latency: Name resolution adds an extra step to the content retrieval process, which can increase latency. However, this can be mitigated by caching name resolution results.
  • Security: The NRS becomes a critical component and a potential target for attacks. Secure mechanisms for name registration and resolution are required.

5. ICN Architectural Considerations for NRS​

5.1. Name Mapping Records Registration, Resolution, and Update​

The NRS must support mechanisms for registering, resolving, and updating name mapping records. These mechanisms should be secure and efficient.

5.2. Protocols and Semantics​

The protocols used for interacting with the NRS must be well-defined. The semantics of the name mapping records must also be clear.

5.3. Routing System​

The interaction between the NRS and the ICN routing system must be carefully designed. The routing system should be able to utilize the information provided by the NRS to forward content requests efficiently.

6. Conclusion​

The use of an NRS in ICN can address scalability, mobility, and off-path caching challenges. However, it also introduces new architectural considerations and implications. This document has discussed these considerations and provided guidelines for integrating an NRS into the ICN architecture.

7. IANA Considerations​

This document has no IANA actions.

8. Security Considerations​

The use of an NRS introduces new security challenges. The NRS must be protected against attacks such as cache poisoning, denial of service, and unauthorized modification of mapping records. Secure mechanisms for authentication and authorization are required.

9. References​

9.1. Normative References​

[RFC9138] Hong, J., You, T., Dong, L., and C. Westphal, "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.

9.2. Informative References​

[NDN] Zhang, L., et al., "Named Data Networking", ACM SIGCOMM Computer Communication Review, Vol. 44, No. 3, pp. 66-73, July 2014.

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

[RFC7841] Halpern, J., Ed., Resnick, P., Ed., and O. Kolkman, Ed., "RFC Streams, Headers, and Boilerplates", RFC 7841, DOI 10.17487/RFC7841, May 2016, https://www.rfc-editor.org/info/rfc7841.

Acknowledgements​

The authors would like to thank...

Authors' Addresses​

Jungha Hong ETRI Email: [email protected]

Tae-Wan You ETRI Email: [email protected]

Ved Kafle NICT Email: [email protected]

Last updated on