RFC 9236 - Architectural Considerations of Information-Centric Networking (ICN) Using a Name Resolution Service
- ステータス: Informational
- 発行日: April 2022
- ストリーム: IRTF
- エラッタ: エラッタなし
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).
このドキュメントでは、Information-Centric Networking(ICN)での名前解決サービス(NRS)の使用に関連するアーキテクチャ上の考慮事項と影響について説明します。NRSを使用した場合にICNアーキテクチャがどのように変化するか、およびその使用がICNルーティングシステムにどのように影響するかについて説明します。このドキュメントは、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.
このドキュメントは、Internet Research Task Force(IRTF)の成果物です。IRTFは、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開に適していない場合があります。このRFCは、Internet Research Task Force(IRTF)のInformation-Centric Networking Research Groupのコンセンサスを表しています。IRSGによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補でもありません。RFC 7841のセクション2を参照してください。
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.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、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およびドキュメントの作成者として特定された人物。全著作権所有。
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.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定(https://trustee.ietf.org/license-info)の対象となります。これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。
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].
Information-Centric Networking(ICN)は、名前による名前付きデータオブジェクト(NDO)への直接アクセスを提供するようにインターネットインフラストラクチャを進化させるアプローチです。2つの一般的なICNアーキテクチャ、Named Data Networking(NDN)[NDN]とContent-Centric Networking(CCNx)[CCNx]では、NDOの名前がデータオブジェクトを取得するための要求をルーティングするために直接使用されます。このような直接的な名前ベースのルーティングには、グローバルにスケーラブルなルーティングシステムの実現、プロデューサーのモビリティへの対応、オフパスキャッシングのサポートに固有の課題があります。これらの具体的な問題については、セクション3で詳しく説明します。これらの課題に対処するために、名前解決サービス(NRS)が文献およびいくつかの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.
このドキュメントでは、NRSの導入によって引き起こされるICNアーキテクチャの潜在的な変更と、ICNルーティングシステムへの対応する影響について説明します。また、NRSを統合するためのICNアーキテクチャ上の考慮事項についても説明します。このドキュメントの範囲には、ICNでNRSを使用する場合のICNアーキテクチャとルーティングシステムの観点からの考慮事項が含まれています。NRS自体の説明は、NRSのアプローチ、機能、および設計上の考慮事項を提供するコンパニオンNRS設計上の考慮事項ドキュメント[RFC9138]に記載されています。
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.
このドキュメントは、Information-Centric Networking Research Group(ICNRG)のコンセンサスを表しています。このドキュメントでカバーされている技術の研究開発に積極的に関わっているリサーチグループ(RG)メンバーによって広範囲にレビューされています。これはIETF製品ではなく、標準ではありません。
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): ICNのNRSは、コンテンツ名またはデータオブジェクト名を、ルーティング可能なプレフィックス、ロケーター、オフパスキャッシュポインター、またはNDOを格納しているターゲット宛先にオブジェクト要求を転送するために入力名よりも適切なエイリアス名などの他の情報に変換する機能を提供するサービスとして定義されています[RFC9138]。NRSは、分散マッピングデータベースシステムを使用して実装される可能性が最も高いです。ドメインネームシステム(DNS)を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システム: NRSシステムは、マッピングレコードを維持するアプリケーション層分散システムです。NRSサーバーと、マッピングレコードの管理と取得に使用されるプロトコルで構成されます。
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サーバー: NRSサーバーは、マッピングレコードを格納および維持するNRSシステムのコンポーネントです。また、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.
NRSクライアント: NRSクライアントは、名前解決要求をNRSシステムに送信するコンポーネントです。エンドホスト、ルーター、またはアプリケーションにすることができます。
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).
名前マッピングレコード: 名前マッピングレコードは、コンテンツ名を他の情報(ロケーター、エイリアス名など)にマッピングするNRSデータベース内のエントリです。
3. Background
In ICN, content names are used for routing content requests. This name-based routing has several challenges:
ICNでは、コンテンツ名はコンテンツ要求のルーティングに使用されます。この名前ベースのルーティングには、いくつかの課題があります。
- 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.
- オフパスキャッシング: ICNはネットワーク内キャッシングをサポートしています。ただし、要求者からプロデューサーへの直接パス上にないキャッシュされたコンテンツへのアクセスは、純粋な名前ベースのルーティングでは困難です。
An NRS can address these challenges by decoupling the content name from its location.
NRSは、コンテンツ名をその場所から分離することで、これらの課題に対処できます。
4. Implications of an NRS in ICN
The introduction of an NRS in ICN has several implications:
ICNへのNRSの導入には、いくつかの意味があります。
- 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.
- ルーティングシステム: ルーティングシステムは、すべてのコンテンツ名を処理する必要がなくなりました。代わりに、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.
- セキュリティ: NRSは重要なコンポーネントになり、攻撃の潜在的なターゲットになります。名前の登録と解決のための安全なメカニズムが必要です。
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.
NRSは、名前マッピングレコードの登録、解決、および更新のメカニズムをサポートする必要があります。これらのメカニズムは、安全かつ効率的である必要があります。
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.
NRSとの対話に使用されるプロトコルは、明確に定義されている必要があります。名前マッピングレコードの意味も明確である必要があります。
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.
NRSとICNルーティングシステムの相互作用は、慎重に設計する必要があります。ルーティングシステムは、NRSによって提供される情報を利用して、コンテンツ要求を効率的に転送できる必要があります。
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.
ICNでNRSを使用すると、スケーラビリティ、モビリティ、およびオフパスキャッシングの課題に対処できます。ただし、新しいアーキテクチャ上の考慮事項と影響も導入されます。このドキュメントでは、これらの考慮事項について説明し、NRSをICNアーキテクチャに統合するためのガイドラインを提供しました。
7. IANA Considerations
This document has no IANA actions.
このドキュメントには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.
NRSの使用により、新しいセキュリティ上の課題が生じます。NRSは、キャッシュポイズニング、サービス拒否、マッピングレコードの不正変更などの攻撃から保護する必要があります。認証と承認のための安全なメカニズムが必要です。
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]