Passa al contenuto principale

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

  • Stato: Informational
  • Pubblicato: April 2022
  • Stream: IRTF
  • Errata: Nessun 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).

Questo documento descrive le considerazioni architetturali e le implicazioni relative all'uso di un servizio di risoluzione dei nomi (NRS) nell'Information-Centric Networking (ICN). Spiega come l'architettura ICN può cambiare quando viene utilizzato un NRS e come il suo utilizzo influenza il sistema di routing ICN. Questo documento è un prodotto dell'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.

Questo documento non è una specifica Internet Standards Track; è pubblicato a scopo informativo.

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.

Questo documento è un prodotto dell'Internet Research Task Force (IRTF). L'IRTF pubblica i risultati delle attività di ricerca e sviluppo relative a Internet. Questi risultati potrebbero non essere adatti per la distribuzione. Questa RFC rappresenta il consenso dell'Information-Centric Networking Research Group dell'Internet Research Task Force (IRTF). I documenti approvati per la pubblicazione dall'IRSG non sono candidati per alcun livello di standard Internet; vedere la Sezione 2 della 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.

Informazioni sullo stato attuale di questo documento, eventuali errori e come fornire feedback su di esso possono essere ottenute all'indirizzo https://www.rfc-editor.org/info/rfc9236.

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.

Copyright (c) 2022 IETF Trust e le persone identificate come autori del documento. Tutti i diritti riservati.

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.

Questo documento è soggetto alla BCP 78 e alle disposizioni legali dell'IETF Trust relative ai documenti IETF (https://trustee.ietf.org/license-info) in vigore alla data di pubblicazione di questo documento. Si prega di esaminare attentamente questi documenti, poiché descrivono i propri diritti e restrizioni in relazione a questo documento.

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
  • 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].

L'Information-Centric Networking (ICN) è un approccio per far evolvere l'infrastruttura Internet per fornire accesso diretto ai Named Data Objects (NDO) tramite nomi. In due comuni architetture ICN, Named Data Networking (NDN) [NDN] e Content-Centric Networking (CCNx) [CCNx], il nome di un NDO viene utilizzato direttamente per instradare una richiesta di recupero dell'oggetto dati. Tale routing diretto basato sul nome presenta sfide intrinseche nell'abilitare un sistema di routing scalabile a livello globale, nell'adattare la mobilità del produttore e nel supportare la memorizzazione nella cache off-path. Questi problemi specifici sono discussi in dettaglio nella Sezione 3. Per affrontare queste sfide, un servizio di risoluzione dei nomi (NRS) è stato utilizzato in letteratura così come nelle proposte di diversi progetti 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.

Questo documento descrive le potenziali modifiche nell'architettura ICN causate dall'introduzione di un NRS e la corrispondente implicazione per il sistema di routing ICN. Descrive inoltre le considerazioni architetturali ICN per l'integrazione di un NRS. L'ambito di questo documento include considerazioni dal punto di vista di un'architettura e di un sistema di routing ICN quando si utilizza un NRS in ICN. Una descrizione dell'NRS stesso è fornita nel documento complementare sulle considerazioni di progettazione NRS [RFC9138], che fornisce gli approcci, le funzioni e le considerazioni di progettazione 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.

Questo documento rappresenta il consenso dell'Information-Centric Networking Research Group (ICNRG). È stato ampiamente rivisto dai membri del Research Group (RG) che sono attivamente coinvolti nella ricerca e nello sviluppo della tecnologia coperta da questo documento. Non è un prodotto IETF e non è uno 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].

Servizio di risoluzione dei nomi (NRS): Un NRS in ICN è definito come un servizio che fornisce la funzione di tradurre un nome di contenuto o un nome di oggetto dati in altre informazioni come un prefisso instradabile, un localizzatore, un puntatore cache off-path o un nome alias che è più adatto rispetto al nome di input per inoltrare la richiesta dell'oggetto verso la destinazione target che memorizza l'NDO [RFC9138]. Un NRS è molto probabilmente implementato attraverso l'uso di un sistema di database di mappatura distribuito. Il Domain Name System (DNS) può essere utilizzato come 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.

Sistema NRS: Un sistema NRS è un sistema distribuito a livello di applicazione che gestisce i record di mappatura. È costituito da server NRS e dal protocollo utilizzato per gestire e recuperare i record di mappatura.

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.

Server NRS: Un server NRS è un componente del sistema NRS che memorizza e gestisce i record di mappatura. Gestisce anche le richieste di risoluzione dei nomi dai client 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 è un componente che invia richieste di risoluzione dei nomi al sistema NRS. Può essere un host finale, un router o un'applicazione.

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).

Record di mappatura dei nomi: Un record di mappatura dei nomi è una voce nel database NRS che mappa un nome di contenuto con altre informazioni (ad esempio, un localizzatore, un nome alias).

3. Background​

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

In ICN, i nomi dei contenuti vengono utilizzati per instradare le richieste di contenuto. Questo routing basato sul nome presenta diverse sfide:

  • Scalability: The number of content objects is much larger than the number of hosts. Maintaining a routing table for all content names is challenging.
  • Scalabilità: Il numero di oggetti contenuto è molto più grande del numero di host. Mantenere una tabella di routing per tutti i nomi di contenuto è una sfida.
  • Producer Mobility: When a content producer moves, the routing information needs to be updated, which can be slow and costly.
  • Mobilità del produttore: Quando un produttore di contenuti si sposta, le informazioni di routing devono essere aggiornate, il che può essere lento e costoso.
  • 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.
  • Memorizzazione nella cache off-path: ICN supporta la memorizzazione nella cache in rete. Tuttavia, l'accesso al contenuto memorizzato nella cache che non si trova sul percorso diretto dal richiedente al produttore è difficile con il routing puramente basato sul nome.

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

Un NRS può affrontare queste sfide disaccoppiando il nome del contenuto dalla sua posizione.

4. Implications of an NRS in ICN​

The introduction of an NRS in ICN has several implications:

L'introduzione di un NRS in ICN ha diverse implicazioni:

  • 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.
  • Sistema di routing: Il sistema di routing non deve più gestire tutti i nomi dei contenuti. Invece, può instradare in base a localizzatori o prefissi instradabili ottenuti dall'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.
  • Latenza: La risoluzione dei nomi aggiunge un passaggio extra al processo di recupero dei contenuti, che può aumentare la latenza. Tuttavia, ciò può essere mitigato memorizzando nella cache i risultati della risoluzione dei nomi.
  • Security: The NRS becomes a critical component and a potential target for attacks. Secure mechanisms for name registration and resolution are required.
  • Sicurezza: L'NRS diventa un componente critico e un potenziale bersaglio di attacchi. Sono necessari meccanismi sicuri per la registrazione e la risoluzione dei nomi.

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.

L'NRS deve supportare meccanismi per la registrazione, la risoluzione e l'aggiornamento dei record di mappatura dei nomi. Questi meccanismi dovrebbero essere sicuri ed efficienti.

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.

I protocolli utilizzati per interagire con l'NRS devono essere ben definiti. Anche la semantica dei record di mappatura dei nomi deve essere chiara.

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'interazione tra l'NRS e il sistema di routing ICN deve essere progettata con attenzione. Il sistema di routing dovrebbe essere in grado di utilizzare le informazioni fornite dall'NRS per inoltrare le richieste di contenuto in modo efficiente.

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'uso di un NRS in ICN può affrontare le sfide di scalabilità, mobilità e memorizzazione nella cache off-path. Tuttavia, introduce anche nuove considerazioni architetturali e implicazioni. Questo documento ha discusso queste considerazioni e fornito linee guida per l'integrazione di un NRS nell'architettura ICN.

7. IANA Considerations​

This document has no IANA actions.

Questo documento non ha azioni 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'uso di un NRS introduce nuove sfide per la sicurezza. L'NRS deve essere protetto da attacchi come avvelenamento della cache, denial of service e modifica non autorizzata dei record di mappatura. Sono necessari meccanismi sicuri per l'autenticazione e l'autorizzazione.

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...

Gli autori desiderano ringraziare...

Authors' Addresses​

Jungha Hong ETRI Email: [email protected]

Tae-Wan You ETRI Email: [email protected]

Ved Kafle NICT Email: [email protected]

Ultimo aggiornamento il