RFC 9236 - Architectural Considerations of Information-Centric Networking (ICN) Using a Name Resolution Service
- Statut: Informational
- Publié: April 2022
- Stream: IRTF
- Errata: Pas d'errata
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).
Ce document décrit les considérations architecturales et les implications liées à l'utilisation d'un service de résolution de noms (NRS) dans les réseaux centrés sur l'information (ICN). Il explique comment l'architecture ICN peut changer lorsqu'un NRS est utilisé et comment son utilisation influence le système de routage ICN. Ce document est un produit du groupe de recherche sur les réseaux centrés sur l'information (ICNRG).
Status of This Memo
This document is not an Internet Standards Track specification; it is published for informational purposes.
Ce document n'est pas une spécification de la voie de normalisation de l'Internet (Standards Track) ; il est publié à titre informatif.
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.
Ce document est un produit de l'Internet Research Task Force (IRTF). L'IRTF publie les résultats des activités de recherche et développement liées à Internet. Ces résultats pourraient ne pas être adaptés au déploiement. Ce RFC représente le consensus du groupe de recherche sur les réseaux centrés sur l'information de l'Internet Research Task Force (IRTF). Les documents approuvés pour publication par l'IRSG ne sont candidats à aucun niveau de norme Internet ; voir la section 2 de la 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.
Des informations sur l'état actuel de ce document, les éventuels errata et la manière de fournir des commentaires à son sujet peuvent être obtenues à l'adresse https://www.rfc-editor.org/info/rfc9236.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2022 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.
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.
Ce document est soumis aux dispositions légales du BCP 78 et de l'IETF Trust relatives aux documents IETF (https://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Veuillez examiner attentivement ces documents, car ils décrivent vos droits et restrictions concernant ce document.
Table of Contents
-
- Introduction
-
- Terminology
-
- Background
-
- Implications of an NRS in ICN
-
- ICN Architectural Considerations for NRS
-
- Conclusion
-
- IANA Considerations
-
- Security Considerations
-
- References
- Acknowledgments
- 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].
Les réseaux centrés sur l'information (ICN) sont une approche visant à faire évoluer l'infrastructure Internet pour fournir un accès direct aux objets de données nommés (NDO) par leurs noms. Dans deux architectures ICN courantes, Named Data Networking (NDN) [NDN] et Content-Centric Networking (CCNx) [CCNx], le nom d'un NDO est utilisé directement pour acheminer une demande de récupération de l'objet de données. Un tel routage direct basé sur le nom présente des défis inhérents pour permettre un système de routage globalement évolutif, s'adapter à la mobilité des producteurs et prendre en charge la mise en cache hors chemin. Ces problèmes spécifiques sont discutés en détail dans la section 3. Afin de relever ces défis, un service de résolution de noms (NRS) a été utilisé dans la littérature ainsi que dans les propositions de plusieurs projets ICN [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.
Ce document décrit les changements potentiels dans l'architecture ICN causés par l'introduction d'un NRS et l'implication correspondante pour le système de routage ICN. Il décrit également les considérations architecturales ICN pour l'intégration d'un NRS. La portée de ce document comprend des considérations du point de vue d'une architecture et d'un système de routage ICN lors de l'utilisation d'un NRS dans ICN. Une description du NRS lui-même est fournie dans le document d'accompagnement sur les considérations de conception NRS [RFC9138], qui fournit les approches, les fonctions et les considérations de conception NRS.
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.
Ce document représente le consensus du groupe de recherche sur les réseaux centrés sur l'information (ICNRG). Il a été examiné de manière approfondie par les membres du groupe de recherche (RG) qui participent activement à la recherche et au développement de la technologie couverte par ce document. Ce n'est pas un produit IETF et ce n'est pas une norme.
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].
Service de résolution de noms (NRS) : Un NRS dans ICN est défini comme un service qui fournit la fonction de traduction d'un nom de contenu ou d'un nom d'objet de données en d'autres informations telles qu'un préfixe routable, un localisateur, un pointeur de cache hors chemin ou un nom d'alias qui est plus approprié que le nom d'entrée pour transmettre la demande d'objet vers la destination cible stockant le NDO [RFC9138]. Un NRS est très probablement mis en œuvre grâce à l'utilisation d'un système de base de données de mappage distribué. Le système de noms de domaine (DNS) peut être utilisé comme 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.
Système NRS : Un système NRS est un système distribué de couche application qui gère les enregistrements de mappage. Il se compose de serveurs NRS et du protocole utilisé pour gérer et récupérer les enregistrements de mappage.
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.
Serveur NRS : Un serveur NRS est un composant du système NRS qui stocke et gère les enregistrements de mappage. Il gère également les demandes de résolution de noms des clients NRS.
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.
Client NRS : Un client NRS est un composant qui envoie des demandes de résolution de noms au système NRS. Il peut s'agir d'un hôte final, d'un routeur ou d'une 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).
Enregistrement de mappage de nom : Un enregistrement de mappage de nom est une entrée dans la base de données NRS qui mappe un nom de contenu à d'autres informations (par exemple, un localisateur, un nom d'alias).
3. Background
In ICN, content names are used for routing content requests. This name-based routing has several challenges:
Dans ICN, les noms de contenu sont utilisés pour acheminer les demandes de contenu. Ce routage basé sur le nom présente plusieurs défis :
- Scalability: The number of content objects is much larger than the number of hosts. Maintaining a routing table for all content names is challenging.
- Évolutivité : Le nombre d'objets de contenu est bien plus important que le nombre d'hôtes. Maintenir une table de routage pour tous les noms de contenu est un défi.
- Producer Mobility: When a content producer moves, the routing information needs to be updated, which can be slow and costly.
- Mobilité des producteurs : Lorsqu'un producteur de contenu se déplace, les informations de routage doivent être mises à jour, ce qui peut être lent et coûteux.
- 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.
- Mise en cache hors chemin : ICN prend en charge la mise en cache dans le réseau. Cependant, l'accès au contenu mis en cache qui ne se trouve pas sur le chemin direct du demandeur au producteur est difficile avec un routage purement basé sur le nom.
An NRS can address these challenges by decoupling the content name from its location.
Un NRS peut relever ces défis en découplant le nom du contenu de son emplacement.
4. Implications of an NRS in ICN
The introduction of an NRS in ICN has several implications:
L'introduction d'un NRS dans ICN a plusieurs 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.
- Système de routage : Le système de routage n'a plus besoin de gérer tous les noms de contenu. Au lieu de cela, il peut acheminer en fonction de localisateurs ou de préfixes routables obtenus à partir du 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.
- Latence : La résolution de nom ajoute une étape supplémentaire au processus de récupération de contenu, ce qui peut augmenter la latence. Cependant, cela peut être atténué en mettant en cache les résultats de la résolution de nom.
- Security: The NRS becomes a critical component and a potential target for attacks. Secure mechanisms for name registration and resolution are required.
- Sécurité : Le NRS devient un composant critique et une cible potentielle d'attaques. Des mécanismes sécurisés pour l'enregistrement et la résolution des noms sont nécessaires.
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.
Le NRS doit prendre en charge des mécanismes pour l'enregistrement, la résolution et la mise à jour des enregistrements de mappage de noms. Ces mécanismes doivent être sécurisés et efficaces.
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.
Les protocoles utilisés pour interagir avec le NRS doivent être bien définis. La sémantique des enregistrements de mappage de noms doit également être claire.
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.
L'interaction entre le NRS et le système de routage ICN doit être soigneusement conçue. Le système de routage doit être capable d'utiliser les informations fournies par le NRS pour acheminer efficacement les demandes de contenu.
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.
L'utilisation d'un NRS dans ICN peut relever les défis d'évolutivité, de mobilité et de mise en cache hors chemin. Cependant, elle introduit également de nouvelles considérations architecturales et implications. Ce document a discuté de ces considérations et fourni des directives pour l'intégration d'un NRS dans l'architecture ICN.
7. IANA Considerations
This document has no IANA actions.
Ce document n'a aucune action IANA.
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.
L'utilisation d'un NRS introduit de nouveaux défis de sécurité. Le NRS doit être protégé contre les attaques telles que l'empoisonnement du cache, le déni de service et la modification non autorisée des enregistrements de mappage. Des mécanismes sécurisés d'authentification et d'autorisation sont nécessaires.
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...
Les auteurs tiennent à remercier...
Authors' Addresses
Jungha Hong ETRI Email: [email protected]
Tae-Wan You ETRI Email: [email protected]
Ved Kafle NICT Email: [email protected]