[要約] RFC 9138は、情報中心ネットワーキング（ICN）における名前解決サービスの設計に関する考慮事項を提供します。この文書の目的は、ICN環境での効率的な名前解決メカニズムの開発を支援することです。利用場面としては、ICNアーキテクチャを採用するネットワークシステムの設計や評価に役立ちます。
Internet Research Task Force (IRTF) J. Hong
Request for Comments: 9138 T. You
Category: Informational ETRI
ISSN: 2070-1721 L. Dong
C. Westphal
Futurewei Technologies Inc.
B. Ohlman
Ericsson
November 2021
Design Considerations for Name Resolution Service in Information-Centric Networking (ICN)
情報中心ネットワーキングにおける名前解決サービスの設計上の考慮事項（ICN）
Abstract
概要
This document provides the functionalities and design considerations for a Name Resolution Service (NRS) in Information-Centric Networking (ICN). The purpose of an NRS in ICN is to translate an object name into some other information such as a locator, another name, etc. in order to forward the object request. This document is a product of the Information-Centric Networking Research Group (ICNRG).
この資料は、情報中心のネットワーキング（ICN）における名前解決サービス（NRS）の機能と設計上の考慮事項を提供します。ICN内のNRSの目的は、オブジェクト要求を転送するために、オブジェクト名をロケータ、他の名前などの他の情報に変換することです。この文書は、情報中心のネットワーキング研究グループ（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.
この文書は、インターネットリサーチタスクフォース（IRTF）の製品です。IRTFはインターネット関連の研究開発活動の結果を発行しています。これらの結果は展開には適していない可能性があります。このRFCは、インターネット研究タスクフォース（IRTF）の情報中心のネットワーキング研究グループの合意を表しています。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/rfc9138.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9138で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2021 IETFの信頼と文書著者として識別された人。全著作権所有。
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.
この文書は、この文書の公開日に有効なIETF文書（https://trustee.ietf.org/License-Info）に関するBCP 78およびIETF信頼の法的規定の対象となります。この文書に関してあなたの権利と制限を説明するので、これらの文書をよくレビューしてください。
Table of Contents
目次
1. Introduction
2. Name Resolution Service in ICN
2.1. Explicit Name Resolution Approach
2.2. Name-Based Routing Approach
2.3. Hybrid Approach
2.4. Comparisons of Name Resolution Approaches
3. Functionalities of NRS in ICN
3.1. Support Heterogeneous Name Types
3.2. Support Producer Mobility
3.3. Support Scalable Routing System
3.4. Support Off-Path Caching
3.5. Support Nameless Object
3.6. Support Manifest
3.7. Support Metadata
4. Design Considerations for NRS in ICN
4.1. Resolution Response Time
4.2. Response Accuracy
4.3. Resolution Guarantee
4.4. Resolution Fairness
4.5. Scalability
4.6. Manageability
4.7. Deployed System
4.8. Fault Tolerance
4.9. Security and Privacy
4.9.1. Confidentiality
4.9.2. Authentication
4.9.3. Integrity
4.9.4. Resiliency and Availability
5. Conclusion
6. IANA Considerations
7. Security Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgements
Authors' Addresses
The current Internet is based upon a host-centric networking paradigm, where hosts are identified with IP addresses and communication is possible between any pair of hosts. Thus, information in the current Internet is identified by the name of the host (or server) where the information is stored. In contrast to host-centric networking, the primary communication objects in Information-Centric Networking (ICN) are the named data objects (NDOs), and they are uniquely identified by location-independent names. Thus, ICN aims for the efficient dissemination and retrieval of NDOs at a global scale and has been identified and acknowledged as a promising technology for a future Internet architecture to overcome the limitations of the current Internet, such as scalability and mobility [Ahlgren] [Xylomenos]. ICN also has emerged as a candidate architecture in the Internet of Things (IoT) environment since IoT focuses on data and information [Baccelli] [Amadeo] [Quevedo] [Amadeo2] [ID.Zhang2].
現在のインターネットは、ホスト中心のネットワーキングパラダイムに基づいており、ここでホストはIPアドレスで識別され、任意のホストペア間で通信が可能です。したがって、現在のインターネット内の情報は、情報が格納されているホスト（またはサーバ）の名前によって識別される。ホスト中心のネットワーキングとは対照的に、情報中心ネットワーキング（ICN）内の主通信オブジェクトは、名前付きデータオブジェクト（NDO）であり、それらは位置に依存しない名前によって一意に識別されます。したがって、ICNは、世界規模でのNDOの効率的な普及と検索を目的とし、スケーラビリティとモビリティのような現在のインターネットの制限を克服するための将来のインターネットアーキテクチャのための有望な技術として認識され、認識されています[Xylomenos]]。IOTはデータや情報を中心とした[Baccelli] [Amadeo] [Amadeo2] [Amadeo2] [Amadeo2] [ID.ZHANG2] [Amadeo2] [Amadeo2] [Amadeo2] [Amadeo]。
Since naming data independently from its current location (where it is stored) is a primary concept of ICN, how to find any NDO using a location-independent name is one of the most important design challenges in ICN. Such ICN routing may comprise three steps [RFC7927]:
現在の場所（保存されている場所）とは独立してデータを命名することは、ICNの主な概念です。位置に依存しない名前を使用してNDOを見つける方法は、ICNの最も重要な設計上の課題の1つです。そのようなICNルーティングは3つのステップ[RFC7927]を含み得る。
(1) Name resolution: matches/translates a content name to the locator of the content producer or source that can provide the content.
(1) 名前解決：コンテンツを提供できるコンテンツプロデューサまたはソースのコンテンツ名に合わせて/変換します。
(2) Content request routing: routes the content request towards the content's location based either on its name or locator.
(2) コンテンツリクエストルーティング：その名前またはロケータに基づいてコンテンツ要求をコンテンツの場所に向けてルーティングします。
(3) Content delivery: transfers the content to the requester.
(3) コンテンツ配信：コンテンツをリクエスターに転送します。
Among the three steps of ICN routing, this document investigates only the name resolution step, which translates a content name to the content locator. In addition, this document covers various possible types of name resolution in ICN such as one name to another name, name to locator, name to manifest, name to metadata, etc.
ICNルーティングの3つのステップの中で、この文書は名前解決ステップのみを調査します。これはコンテンツ名をコンテンツロケータに変換します。さらに、このドキュメントでは、別の名前、ロケータへの名前、マニフェスト、メタデータへの名前など、ICN内の様々な種類の名前解決を説明します。
The focus of this document is a Name Resolution Service (NRS) itself as a service or a system in ICN, and it provides the functionalities and the design considerations for an NRS in ICN as well as the overview of the NRS approaches in ICN. On the other hand, its companion document [NRSarch] describes considerations from the perspective of the ICN architecture and routing system when using an NRS in ICN.
この文書の焦点は、ICNのサービスまたはシステムとしての名前解決サービス（NRS）自体であり、ICNのNRSの機能と設計上の考慮事項とICNのNRSアプローチの概要を提供します。一方、そのコンパニオン文書[NRSARCH]は、ICN内のNRSを使用するときのICNアーキテクチャとルーティングシステムの観点から考慮しています。
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.
この文書は、情報中心のネットワーキング研究グループ（ICNRG）の合意を表しています。この文書で対象となる技術の研究開発に積極的に関与している研究グループ（RG）のメンバーによって広く見直されています。IETF製品ではなく、標準ではありません。
A Name Resolution Service (NRS) in ICN is defined as the service that provides the name resolution function for translating an object name into some other information such as a locator, another name, metadata, next-hop info, etc. that is used for forwarding the object request. In other words, an NRS is a service that can be provided by the ICN infrastructure to help a consumer reach a specific piece of information (or named data object). The consumer provides an NRS with a persistent name, and the NRS returns a name or locator (or potentially multiple names and locators) that can reach a current instance of the requested object.
ICNの名前解決サービス（NRS）は、オブジェクト名をロケータ、別の名前、メタデータ、ネクストホップ情報などの他の情報に変換するための名前解決機能を提供するサービスとして定義されています。オブジェクト要求を転送します。言い換えれば、NRSは、消費者が特定の情報（または名前付きデータオブジェクト）に達するのを助けるためにICNインフラストラクチャによって提供され得るサービスである。消費者は永続的な名前を持つNRSを提供し、NRSは要求されたオブジェクトの現在のインスタンスに到達できる名前またはロケータ（または複数の名称およびロケータ）を返します。
The name resolution is a necessary process in ICN routing, although the name resolution either can be separated from the content request routing as an explicit process or can be integrated with the content request routing as an implicit process. The former is referred to as an "explicit name resolution approach", and the latter is referred to as a "name-based routing approach" in this document.
名前解決はICNルーティングで必要なプロセスですが、名前解決は明示的なプロセスとしてコンテンツ要求ルーティングから区切ることができますが、暗黙のプロセスとしてコンテンツ要求ルーティングと統合できます。前者は「明示的な名前解決方法」と呼ばれ、後者はこの文書の「名前ベースのルーティングアプローチ」と呼ばれます。
An NRS could take the explicit name resolution approach to return the locators of the content to the client, which will be used by the underlying network as the identifier to route the client's request to one of the producers or to a copy of the content. There are several ICN projects that use the explicit name resolution approach, such as Data-Oriented Network Architecture (DONA) [Koponen], PURSUIT [PURSUIT], Network of Information (NetInf) [SAIL], MobilityFirst [MF], IDNet [Jung], etc. In addition, the explicit name resolution approach has been allowed for 5G control planes [SA2-5GLAN].
NRSは、コンテンツのロケータをクライアントに返すように明示的な名前解決方法を取ります。これは、基礎となるネットワークによってクライアントの要求をプロデューサの1つまたはコンテンツのコピーにルーティングするための識別子として使用されます。データ指向ネットワークアーキテクチャ（DONA）[KOPONEN]、PURSUIT [PURSUIT]、情報のネットワーク（NETINF）[SAIL]、MOBILITYFIRST [MF]、IDNET [JUNG]など、明示的な名前解決アプローチを使用するICNプロジェクトがいくつかあります。なお、5G制御面[SA2-5GLAN]には、明示的な名前解決アプローチが許可されています。
An NRS could take the name-based routing approach, which integrates name resolution with content request message routing as in Named Data Networking / Content-Centric Networking (NDN/CCNx) [NDN] [CCNx].
NRSは、名前付きデータネットワーキング/コンテンツ中心ネットワーキング（NDN / CCNX）[NDN] [CCNx]と同様に、名前解決をコンテンツ要求メッセージルーティングに統合する名前ベースのルーティングアプローチを取ります。
In cases where the content request also specifies the reverse path, as in NDN/CCNx, the name resolution mechanism also derives the routing path for the data. This adds a requirement to the name resolution service to propagate the request in a way that is consistent with the subsequent data forwarding. Namely, the request must select a path for the data based upon finding a copy of the content but also properly delivering the data.
コンテンツ要求がリバースパスを指定している場合、NDN / CCNXのように、名前解決メカニズムはデータのルーティングパスも導出されます。これは、その後のデータ転送と一致する方法で要求を伝播するために、名前解決サービスに要件を追加します。すなわち、要求は、コンテンツのコピーを見つけるのに基づいてデータのパスを選択する必要がありますが、データを正しく配信する必要があります。
An NRS could also take hybrid approach. For instance, it can attempt the name-based routing approach first. If this fails at a certain router, the router can go back to the explicit name resolution approach. The hybrid NRS approach also works the other way around: first by performing explicit name resolution to find the locators of routers, then by routing the client's request using the name-based routing approach.
NRSはハイブリッドアプローチも取ります。たとえば、最初に名前ベースのルーティングアプローチを試みることができます。これが特定のルータで失敗すると、ルータは明示的な名前解決方法に戻ることができます。ハイブリッドNRSアプローチは、次のように機能します。
A hybrid approach would combine name resolution over a subset of routers on the path with some tunneling in between (say, across an administrative domain) so that only a few of the nodes in the ICN network perform name resolution in the name-based routing approach.
ハイブリッドアプローチは、ICNネットワーク内のいくつかのノードのみが名前ベースのルーティングアプローチで名前解決を実行するように、パス上のパス上の経路上のルータのサブセットを介して名前解決を組み合わせることになります。。
The following compares the explicit name resolution and the name-based routing approaches in several aspects:
以下は、明示的な名前解決といくつかの側面の名前ベースのルーティングアプローチを比較します。
* Overhead due to the maintenance of the content location: The content reachability is dynamic and includes new content being cached or content being expired from a cache, content producer mobility, etc. Maintaining a consistent view of the content location across the network requires some overhead that differs for the name resolution approaches. The name-based routing approach may require flooding parts of the network for update propagation. In the worst case, the name-based routing approach may flood the whole network (but mitigating techniques may be used to scope the flooding). However, the explicit name resolution approach only requires updating propagation in part of the name resolution system (which could be an overlay with a limited number of nodes).
* コンテンツの場所のメンテナンスによるオーバーヘッド：コンテンツの到達可能性は動的で、キャッシュされている新しいコンテンツ、またはキャッシュから有効期限が切れているコンテンツ、コンテンツプロデューサモビリティなどが含まれます。ネットワーク全体のコンテンツの場所の一貫したビューを維持するには、いくつかのオーバーヘッドが必要です。名前解像度のアプローチで異なります。名前ベースのルーティングアプローチは、更新伝播のためにネットワークのフラッディング部分を必要とするかもしれません。最悪の場合、名前ベースのルーティングアプローチはネットワーク全体をフラッディングすることがあります（ただし、軽減の手法を使用してフラッディングを照会することができます）。ただし、明示的な名前解決方法は、名前解決システムの一部での伝播を更新するだけで済みます（それは限られた数のノードのオーバーレイになる可能性があります）。
* Resolution capability: The explicit name resolution approach, if designed and deployed with sufficient robustness, can offer at least weak guarantees that resolution will succeed for any content name in the network if it is registered to the name resolution overlay. In the name-based routing approach, content resolution depends on the flooding scope of the content names (i.e., content publishing message and the resulting name-based routing tables). For example, when content is cached, the router may only notify its direct neighbors of this information. Thus, only those neighboring routers can build a name-based entry for this cached content. But if the neighboring routers continue to propagate this information, the other nodes are able to direct to this cached copy as well.
* 解決能力：明示的な名前解決アプローチは、十分な堅牢性で設計され展開されている場合、名前解決オーバーレイに登録されている場合、解決策がネットワーク内のどのコンテンツ名に対して解決されることが少なくとも弱い保証を提供できます。名前ベースのルーティングアプローチでは、コンテンツ解決は、コンテンツ名のフラッディングスコープ（すなわち、コンテンツ発行メッセージと結果として得られる名前ベースのルーティングテーブル）に依存します。たとえば、コンテンツがキャッシュされると、ルータはこの情報の直接の隣接しか通知できません。したがって、隣接するルータだけがこのキャッシュされたコンテンツの名前ベースのエントリを構築できます。しかし、隣接するルータがこの情報を伝播し続けると、他のノードもこのキャッシュされたコピーにも指示されます。
* Node failure impact: Nodes involved in the explicit name resolution approach are the name resolution overlay servers (e.g., resolution handlers in DONA), while the nodes involved in the name-based routing approach are routers that route messages based on the name-based routing tables (e.g., NDN routers). Node failures in the explicit name resolution approach may cause some content request routing to fail even though the content is available. This problem does not exist in the name-based routing approach because other alternative paths can be discovered to bypass the failed ICN routers, given the assumption that the network is still connected.
* ノード障害の影響：明示的な名前解決方法に関わるノードは、名前解決オーバーレイサーバ（DONAの解決ハンドラなど）であり、名前ベースのルーティングアプローチに含まれるノードは、名前ベースのルーティングに基づいてメッセージをルーティングするルータです。テーブル（例えば、NDNルータ）。明示的な名前解決方法のノード障害は、コンテンツが利用可能であっても、コンテンツ要求のルーティングが失敗する可能性があります。ネットワークがまだ接続されているという仮定を考慮して、失敗したICNルータを迂回するために他の代替パスを検出できるため、この問題は名前ベースのルーティングアプローチには存在しません。
* Maintained databases: The storage usage for the explicit name resolution approach is different from that of the name-based routing approach. The explicit name resolution approach typically needs to maintain two databases: name-to-locator mapping in the name resolution overlay and routing tables in the routers on the data forwarding plane. The name-based routing approach needs to maintain only the name-based routing tables.
* 維持されたデータベース：明示的な名前解決アプローチのストレージ使用量は、名前ベースのルーティングアプローチのストレージ使用量とは異なります。明示的な名前解決方法アプローチは通常、データ転送プレーン上のルータ内の名前解決オーバーレイとルーティングテーブルの2つのデータベースを維持する必要があります。名前ベースのルーティングアプローチは、名前ベースのルーティングテーブルのみを維持する必要があります。
Additionally, some other intermediary step may be included in the name resolution -- namely, the mapping of one name to other names -- in order to facilitate the retrieval of named content by way of a manifest [Westphal] [RFC8569]. The manifest is resolved using one of the two above approaches, and it may include further mapping of names to content and location. The steps for name resolution then become the following: first, translate the manifest name into a location of a copy of the manifest, which includes further names of the content components and potentially locations for the content, then retrieve the content by using these names and/or location, potentially resulting in additional name resolutions.
さらに、マニフェスト[westphal] [RFC8569]を介して名前付きコンテンツの検索を容易にするために、他のいくつかの中間ステップを名前解像度 - すなわち、ある名前へのマッピングを他の名前にマッピングすることができる。マニフェストは、上記の2つのアプローチのうちの1つを使用して解決され、それはコンテンツと場所への名前のさらなるマッピングを含み得る。名前解決の手順は次のとおりです。あるいは場所、その結果、追加の名前解決をもたらします。
Thus, no matter which approach is taken by an NRS in ICN, the name resolution is the essential function that shall be provided by the ICN infrastructure.
したがって、ICNのNRSによってどのアプローチが取られても、名前解決はICNインフラストラクチャによって提供される必須の関数です。
This section presents the functionalities of an NRS in ICN.
このセクションでは、ICN内のNRSの機能性を示します。
In ICN, a name is used to identify the data object and is bound to it [RFC7927]. ICN requires uniqueness and persistency of the name of the data object to ensure the reachability of the object within a certain scope. There are heterogeneous approaches to designing ICN naming schemes [Bari]. Ideally, a name can include any form of identifier, which can be flat or hierarchical, human readable or non-readable.
ICNでは、データオブジェクトを識別するために名前が使用され、それにバインドされています[RFC7927]。ICNは、特定のスコープ内のオブジェクトの到達可能性を確実にするために、データオブジェクトの名前の一意性と持続性を必要とします。ICN命名スキームを設計するための不均一なアプローチがあります[bari]。理想的には、名前は、フラットまたは階層的、人間が読める、または不可解なことができる任意の形式の識別子を含むことができる。
Although there are diverse types of naming schemes proposed in the literature, they all need to provide basic functions for identifying a data object, supporting named data lookup, and routing. An NRS may combine the better aspects of different schemes. Basically, an NRS should be able to support a generic naming schema so that it can resolve any type of content name, irrespective of whether it is flat, hierarchical, attribute based, or anything else.
文献に提案されている多様な種類の命名方式が提案されているが、それらはすべてデータオブジェクトを識別するための基本的な関数を提供し、名前付きデータ検索、およびルーティングをサポートする必要がある。NRSは、異なるスキームのより良い側面を組み合わせることができる。基本的に、NRSは、フラット、階層的、属性ベース、または他のものであるかに関係なく、汎用ネーミングスキーマをサポートできるようにする必要があります。
In PURSUIT [PURSUIT], names are flat, and the rendezvous functions are defined for an NRS, which is implemented by a set of rendezvous nodes (RNs), known as the rendezvous network (RENE). Thus, a name consists of a sequence of scope IDs, and a single rendezvous ID is routed by the RNs in RENE. Thus, PURSUIT decouples name resolution and data routing, where the NRS is performed by the RENE.
追跡[追跡]では、名前は平らであり、ランデブー関数はNRSに対して定義されており、これはランデブーネットワーク（RENE）と呼ばれるランデブーノード（RNS）のセットによって実装されています。したがって、名前は一連のスコープIDで構成され、単一のRendezvous IDはRNSのRNSによってルーティングされます。したがって、追跡は、NRSがRENEによって実行される名前の解像度とデータルーティングを切り捨てます。
In MobilityFirst [MF], a name known as a "Global Unique Identifier (GUID)", derived from a human-readable name via a global naming service, is a flat typed 160-bit string with self-certifying properties. Thus, MobilityFirst defines a Global Name Resolution Service (GNRS), which resolves GUIDs to network addresses and decouples name resolution and data routing similarly to PURSUIT.
MobilityFirst [MF]では、グローバルネームサービスを介して人間が読める名前から派生した「グローバル固有の識別子（GUID）」として知られている名前は、自己認証のプロパティを持つフラット型の160ビット文字列です。したがって、MobilityFirstはGlobal Name Resolution Service（GNRS）を定義します。これにより、GUIDをネットワークアドレスに解決し、名前の解決とデータルーティングを追跡と同様に切り捨てます。
In NetInf [Dannewitz], information objects are named using Named Information (NI) names [RFC6920], which consist of an authority part and digest part (content hash). The NI names can be flat as the authority part is optional. Thus, the NetInf architecture also includes a Name Resolution System (NRS), which can be used to resolve NI names to addresses in an underlying routable network layer.
NetInf [Dannewitz]では、情報オブジェクトは、権限部とダイジェスト部（コンテンツハッシュ）で構成された名前付き情報（NI）名[RFC6920]を使用して命名されています。権限部分がオプションであるため、NI名は平らになる可能性があります。したがって、NetINFアーキテクチャには、NI名を基になるルーティング可能なネットワーク層でアドレスに解決するために使用できる名前解決システム（NRS）も含まれます。
In NDN [NDN] and CCNx [CCNx], names are hierarchical and may be similar to URLs. Each name component can be anything, including a human-readable string or a hash value. NDN/CCNx adopts the name-based routing approach. The NDN router forwards the request by doing the longest-match lookup in the Forwarding Information Base (FIB) based on the content name, and the request is stored in the Pending Interest Table (PIT).
NDN [NDN]およびCCNX [CCNX]では、名前は階層的であり、URLに似ている可能性があります。各名前コンポーネントは、人間が読める文字列やハッシュ値を含めて何でも構いません。NDN / CCNXは名前ベースのルーティングアプローチを採用しています。NDNルータは、コンテンツ名に基づいて転送情報ベース（FIB）に最も長い一致検索を行うことによって要求を転送し、その要求は保留中の関心テーブル（PIT）に格納される。
ICN inherently supports mobility by consumers. Namely, consumer or client mobility is handled by re-requesting the content in case the mobility event (say, handover) occurred before receiving the corresponding content from the network. Since ICN can ensure that content reception continues without any disruption in ICN applications, seamless mobility from the consumer's point of view can be easily supported.
ICNは本質的に消費者によるモビリティをサポートします。すなわち、ネットワークからの対応するコンテンツを受信する前に、モビリティイベント（例えばハンドオーバ）が発生した場合に備えてコンテンツまたはクライアントモビリティを扱うことによって、コンテンツまたはクライアントモビリティが処理される。ICNは、ICNアプリケーションを中断することなくコンテンツ受信が続くことを確実にすることができるので、消費者の視点からのシームレスな移動性を簡単にサポートすることができる。
However, producer mobility does not emerge naturally from the ICN forwarding model as does consumer mobility. If a producer moves into a different network location or a different name domain, which is assigned by another authoritative publisher, it would be difficult for the mobility management to update Routing Information Base (RIB) and FIB entries in ICN routers with the new forwarding path in a very short time. Therefore, various ICN architectures in the literature have proposed adopting an NRS to achieve the producer or publisher mobility, where the NRS can be implemented in different ways such as rendezvous points and/or overlay mapping systems.
ただし、プロデューサーモビリティは、消費者の移動性と同様にICN転送モデルから自然に浮上しません。プロデューサが別の権限から割り当てられている別のネットワークの場所または異なる名前ドメインに移動した場合、Mobility Managementは、新しい転送パスを使用してICNルータのルーティング情報ベース（RIB）とFIBエントリを更新するのが困難です。非常に短時間で。したがって、文献内の様々なICNアーキテクチャは、プロデューサーまたは発行者の移動度を達成するためにNRSを採用し、ここで、NRSは、ランデブー点および/またはオーバーレイマッピングシステムなどの異なる方法で実施することができる。
In NDN [Zhang2], for producer mobility support, rendezvous mechanisms have been proposed to build interest rendezvous (RV) with data generated by a mobile producer (MP). This can be classified into two approaches: chase mobile producer and rendezvous data. Regarding MP chasing, rendezvous acts as a mapping service that provides the mapping from the name of the data produced by the MP to the name of the MP's current point of attachment (PoA). Alternatively, the RV serves as a home agent as in IP mobility support, so the RV enables the consumer's Interest message to tunnel towards the MP at the PoA. Regarding rendezvous data, the solution involves moving the data produced by the MP to a data depot instead of forwarding Interest messages. Thus, a consumer's Interest message can be forwarded to stationary place called a "data rendezvous", so it would either return the data or fetch it using another mapping solution. Therefore, RV or other mapping functions are in the role of an NRS in NDN.
NDN [Zhang2]では、プロデューサモビリティサポートのために、モバイルプロデューサ（MP）によって生成されたデータを用いてレンダリング（RV）を構築するためのランデブーメカニズムが提案されている。これは、Chase Mobile ProducerとRendezvousデータを2つのアプローチに分類できます。MP追跡に関しては、Rendezvousは、MPによって生成されたデータの名前からMPの現在の添付ファイルの名前（POA）の名前へのマッピングを提供するマッピングサービスとして機能します。あるいは、RVはIPモビリティサポートのようにホームエージェントとして機能するので、RVは消費者の関心メッセージをPOAでMPに向かってトンネルすることを可能にする。ランデブデータに関しては、ソリューションは、関心メッセージを転送するのではなく、MPによって生成されたデータをデータデポに移動させることを含む。したがって、消費者の関心メッセージは、「データrendezvous」と呼ばれる静止場所に転送することができるので、データを返却するか、別のマッピングソリューションを使用してそれを取り出します。したがって、RVまたは他のマッピング機能は、NDNのNRSの役割にあります。
In [Ravindran], the forwarding label (FL) object is used to enable identifier (ID) and locator (LID) namespaces to be split in ICN. Generally, IDs are managed by applications, while locators are managed by a network administrator so that IDs are mapped to heterogeneous name schemes and LIDs are mapped to the network domains or to specific network elements. Thus, the proposed FL object acts as a locator (LID) and provides the flexibility to forward Interest messages through a mapping service between IDs and LIDs. Therefore, the mapping service in control plane infrastructure can be considered as an NRS in this draft.
[Ravindran]では、転送ラベル（FL）オブジェクトを使用してICNで識別子（ID）とロケータ（LID）名前空間を分割することができます。一般に、IDはアプリケーションによって管理され、ロケータはネットワーク管理者によって管理されているので、IDが異種ネームスキームにマッピングされ、LIDSはネットワークドメインまたは特定のネットワーク要素にマッピングされます。したがって、提案されたFLオブジェクトはロケータ（LID）として機能し、IDSと蓋の間のマッピングサービスを通して関心メッセージを順守するための柔軟性を提供する。したがって、コントロールプレーンインフラストラクチャのマッピングサービスは、このドラフトのNRSと見なすことができます。
In MobilityFirst [MF], both consumer and publisher mobility can be primarily handled by the global name resolution service (GNRS), which resolves GUIDs to network addresses. Thus, the GNRS must be updated for mobility support when a network-attached object changes its point of attachment, which differs from NDN/CCNx.
MobilityFirst [MF]では、コンシューマとパブリッシャの両方のモビリティは、主にグローバルネーム解決サービス（GNRS）によって処理され、GUIDはネットワークアドレスに解決されます。したがって、ネットワーク接続されたオブジェクトが添付ファイルのポイントを変更したときに、GNRは、NDN / CCNXとは異なります。
In NetInf [Dannewitz], mobility is handled by an NRS in a very similar way to MobilityFirst.
NetInf [Dannewitz]では、MobilityFirstと非常によく似た方法で、MobilityはNRSによって処理されます。
Besides the consumer and producer mobility, ICN also faces challenges to support the other dynamic features such as multi-homing, migration, and replication of named resources such as content, devices, and services. Therefore, an NRS can help to support these dynamic features.
消費者とプロデューサーのモビリティの他に、ICNはまた、マルチホーミング、マイグレーション、およびコンテンツ、デバイス、およびサービスなどの名前付きリソースの複製などの他の動的機能をサポートすることに課題に直面しています。したがって、NRSはこれらの動的な機能をサポートするのに役立ちます。
In ICN, the name of data objects is used for routing by either a name resolution step or a routing table lookup. Thus, routing information for each data object should be maintained in the routing base, such as RIB and FIB. Since the number of data objects would be very large, the size of information bases would be significantly larger as well [RFC7927].
ICNでは、データオブジェクトの名前は、名前解決ステップまたはルーティングテーブルの検索によるルーティングに使用されます。したがって、各データオブジェクトのルーティング情報は、リブやFIBなどのルーティングベースに維持されるべきです。データオブジェクトの数は非常に大きくなるので、情報ベースのサイズも大幅に大きくなります[RFC7927]。
The hierarchical namespace used in CCNx [CCNx] and NDN [NDN] architectures reduces the size of these tables through name aggregation and improves the scalability of the routing system. A flat naming scheme, on the other hand, would aggravate the scalability problem of the routing system. The non-aggregated name prefixes injected into the Default Route Free Zone (DFZ) of ICN would create a more serious scalability problem when compared to the scalability issues of the IP routing system. Thus, an NRS may play an important role in the reduction of the routing scalability problem regardless of the types of namespaces.
ccnx [ccnx]およびndn [ndn]アーキテクチャで使用される階層的な名前空間は、名前集計を通してこれらのテーブルのサイズを減らし、ルーティングシステムのスケーラビリティを向上させます。一方、フラット命名方式は、ルーティングシステムのスケーラビリティ問題を悪化させるであろう。ICNのデフォルトルートフリーゾーン（DFZ）に挿入されていない非集約名プレフィックスは、IPルーティングシステムのスケーラビリティの問題と比較してより深刻なスケーラビリティ問題を作成します。したがって、NRSは、名前空間の種類にかかわらず、ルーティングスケーラビリティ問題の低減において重要な役割を果たす可能性があります。
In [Afanasyev], in order to address the routing scalability problem in NDN's DFZ, a well-known concept called "map-and-encap" is applied to provide a simple and secure namespace mapping solution. In the proposed map-and-encap design, data whose name prefixes do not exist in the DFZ forwarding table can be retrieved by a distributed mapping system called NDNS, which maintains and looks up the mapping information from a name to its globally routed prefixes, where NDNS is a kind of an NRS.
[AFAnasyEv]では、NDNのDFZのルーティングスケーラビリティの問題に対処するために、シンプルで安全な名前空間マッピングソリューションを提供するために、「Map-And Encap」という周知の概念が適用されます。提案されたマップおよびエンコンデザインでは、DFZ転送テーブルに名前プレフィックスが存在しないデータは、NDNと呼ばれる分散マッピングシステムによって検索され、これは名前からグローバルにルーティングされたプレフィックスへのマッピング情報を検索することができます。NDNSは一種のNRSです。
Caching in-network is considered to be a basic architectural component of an ICN architecture. It may be used to provide a level of quality-of-service (QoS) experience to users to reduce the overall network traffic, to prevent network congestion and denial-of-service (DoS) attacks, and to increase availability. Caching approaches can be categorized into off-path caching and on-path caching based on the location of caches in relation to the forwarding path from the original server to the consumer. Off-path caching, also referred to as "content replication" or "content storing", aims to replicate content within a network in order to increase availability, regardless of the relationship of the location to the forwarding path. Thus, finding off-path cached objects is not trivial in name-based routing of ICN. In order to support off-path caches, replicas are usually advertised into a name-based routing system or into an NRS.
ネットワーク内のキャッシングは、ICNアーキテクチャの基本的なアーキテクチャコンポーネントであると考えられています。ネットワークの輻輳やサービス拒否（DOS）攻撃を防ぎ、可用性を向上させるために、ネットワーク全体のトラフィックを削減するために、サービス品質（QoS）エクスペリエンスのレベルをユーザーに提供するために使用されることがあります。キャッシングアプローチは、オリジナルサーバーからコンシューマへの転送パスに関して、キャッシュの場所に基づいてオフパスキャッシュとオンパスキャッシュに分類できます。「コンテンツレプリケーション」または「コンテンツ格納」とも呼ばれるオフパスキャッシングは、転送パスへの位置の関係に関係なく、可用性を向上させるためにネットワーク内のコンテンツを複製することを目的としている。したがって、オフパスキャッシュされたオブジェクトを見つけることは、ICNの名前ベースのルーティングでは自明ではありません。オフパスキャッシュをサポートするために、レプリカは通常、名前ベースのルーティングシステムまたはNRSにアドバタイズされます。
In [Bayhan], an NRS is used to find off-path copies in the network, which may not be accessible via name-based routing mechanisms. Such a capability can be helpful for an Autonomous System (AS) to avoid the costly inter-AS traffic for external content more, to yield higher bandwidth efficiency for intra-AS traffic, and to decrease the data access latency for a pleasant user experience.
[Bayhan]では、NRSがネットワーク内のオフパスコピーを見つけるために使用されます。これは、名前ベースのルーティングメカニズムを介してアクセスできない可能性があります。そのような能力は、外部コンテンツのための高価な相互コンテンツのトラフィックを回避するために自律システム（AS）にとって有用であり得、イントラとしてのトラフィックのためのより高い帯域幅効率をもたらし、そして心地良いユーザエクスペリエンスのためのデータアクセス待ち時間を減少させる。
In CCNx 1.0 [Mosko2], the concept of a "Nameless Object", which is a Content Object without a name, is introduced to provide a means to move content between storage replicas without having to rename or re-sign the Content Objects for the new name. Nameless Objects can be addressed by the ContentObjectHash, which is to restrict Content Object matching by using a SHA-256 hash.
CCNX 1.0 [MOSKO2]では、名前なしのコンテンツオブジェクトである「無名オブジェクト」の概念が、コンテンツオブジェクトの名前を変更または再署名する必要なしにストレージレプリカ間のコンテンツを移動する手段を提供するために導入されました。新しい名前。名前のないオブジェクトはContentObjectHashによってアドレス指定できます。これは、SHA-256ハッシュを使用してコンテンツオブジェクトのマッチングを制限することです。
An Interest message would still carry a name and a ContentObjectHash, where a name is used for routing, while a ContentObjectHash is used for matching. However, on the reverse path, if the Content Object's name is missing, it is a "Nameless Object" and only matches against the ContentObjectHash. Therefore, a consumer needs to resolve the proper name and hashes through an outside system, which can be considered as an NRS.
興味メッセージはまだ名前とContentObjectHashを持ち、名前がルーティングに使用され、ContentObjectHashはマッチングに使用されます。ただし、リバースパスでは、コンテンツオブジェクトの名前が欠落している場合は、「名前のないオブジェクト」です。これはContentObjectHashとのみ一致します。したがって、消費者は、外部システムを通して適切な名前とハッシュを解決する必要があり、これはNRSと見なすことができます。
For collections of data objects that are organized as large and file-like contents [FLIC], manifests are used as data structures to transport this information. Thus, manifests may contain hash digests of signed Content Objects or other manifests so that large Content Objects that represent a large piece of application data can be collected by using such a manifest.
大規模およびファイルのようなコンテンツ[FLIC]として編成されているデータオブジェクトのコレクションの場合、この情報を転送するためのデータ構造としてマニフェストが使用されます。したがって、マニフェストは、符号付きコンテンツオブジェクトまたは他のマニフェストのハッシュダイジェストを含み、そのようなマニフェストを使用することによって大きなアプリケーションデータを表す大きなコンテンツオブジェクトを収集することができる。
In order to request Content Objects, a consumer needs to know a manifest root name to acquire the manifest. In the case of File-Like ICN Collections (FLIC), a manifest name can be represented by a nameless root manifest so that an outside system such as an NRS may be involved to give this information to the consumer.
コンテンツオブジェクトを要求するために、消費者はマニフェストを取得するための明白なルート名を知る必要があります。ファイルのようなICNコレクション（FLIC）の場合、マニフェスト名は無名のルートマニフェストによって表現することができ、NRSのような外部システムがこの情報を消費者に与えるために関与することができるようにすることができる。
When resolving the name of a Content Object, NRS could return a rich set of metadata in addition to returning a locator. The metadata could include alternative object locations, supported object transfer protocol(s), caching policy, security parameters, data format, hash of object data, etc. The consumer could use this metadata for the selection of object transfer protocol, security mechanism, egress interface, etc. An example of how metadata can be used in this way is provided by the Networked Object (NEO) ICN architecture [NEO].
Contentオブジェクトの名前を解決すると、NRSはロケータを返すのに加えてリッチメタデータのセットを返すことができます。メタデータには、代替のオブジェクトの位置、サポートされているオブジェクト転送プロトコル、キャッシングポリシー、セキュリティパラメータ、データフォーマット、オブジェクトデータのハッシュなどを含めることができます。消費者はオブジェクト転送プロトコル、セキュリティメカニズム、出力の選択にこのメタデータを使用できます。インタフェースなど、メタデータをこのように使用できる方法の例は、ネットワーク接続されたオブジェクト（NEO）ICNアーキテクチャ[NEO]によって提供されます。
This section presents the design considerations for NRS in ICN.
このセクションでは、ICNのNRSの設計上の考慮事項について説明します。
The name resolution process should provide a response within a reasonable amount of time. The response should be either a proper mapping of the name to a copy of the content or an error message stating that no such object exists. If the name resolution does not map to a location, the system may not issue any response, and the client should set a timer when sending a request so as to consider the resolution incomplete when the timer expires.
名前解決プロセスは、妥当な時間内に応答を提供する必要があります。応答は、コンテンツのコピーまたはそのようなオブジェクトが存在しないというエラーメッセージへの名前の適切なマッピングである必要があります。名前解決が場所にマッピングされない場合、システムは応答を発行しなくてもよく、クライアントは、タイマーが期限切れになると解決が不完全になるようにリクエストを検討するときにタイマーを設定する必要があります。
The acceptable response delay could be of the order of a round-trip time between the client issuing the request and the NRS servers that provide the response. While this RTT may vary greatly depending on the proximity between the two end points, some upper bound needs to be used. Especially in some delay-sensitive scenarios such as industrial Internet and telemedicine, the upper bound of the response delay must be guaranteed.
許容される応答遅延は、要求を発行するクライアントと応答を提供するNRSサーバとの間の往復時間の順序であり得る。このRTTは、2つの端点間の近接性に応じて大きく異なる場合がありますが、上限を使用する必要があります。特に産業用インターネットや遠隔医療などのいくつかの遅延に敏感なシナリオでは、応答遅延の上限は保証されなければなりません。
The response time includes all the steps of the resolution, including potentially a hop-by-hop resolution or a hierarchical forwarding of the resolution request.
応答時間は、潜在的にホップバイホップの解像度または解像度要求の階層的な転送を含む、解像度のすべてのステップを含む。
An NRS must provide an accurate response -- namely, a proper binding of the requested name (or prefix) with a location. The response can be either a (prefix, location) pair or the actual forwarding of a request to a node holding the content, which is then transmitted in return.
NRSは正確な応答を提供する必要があります。応答は、（プレフィックス、ロケーション）ペアまたはコンテンツを保持しているノードへの要求の実際の転送のいずれかであり得、それはその後戻って送信される。
An NRS must provide an up-to-date response -- namely, an NRS should be updated within a reasonable time when new copies of the content are being stored in the network. While every transient cache addition/eviction should not trigger an NRS update, some origin servers may move and require the NRS to be updated.
NRSは最新の応答を提供しなければなりません。つまり、コンテンツの新しいコピーがネットワークに格納されているときにNRSを妥当な時期に更新する必要があります。すべての一時的なキャッシュの追加/削除はNRSアップデートをトリガしないでくださいが、いくつかのオリジンサーバーが移動し、NRSを更新する必要があります。
An NRS must provide mechanisms to update the mapping of the content with its location. Namely, an NRS must provide a mechanism for a content provider to add new content, revoke old/dated/obsolete content, and modify existing content. Any content update should then be propagated through the NRS system within reasonable delay.
NRSは、その場所にコンテンツのマッピングを更新するためのメカニズムを提供する必要があります。すなわち、NRSは、コンテンツプロバイダが新しいコンテンツを追加し、古い/日付/時代遅れのコンテンツを取り消し、既存のコンテンツを変更するためのメカニズムを提供しなければならない。その後、任意のコンテンツ更新は、合理的な遅延内にNRSシステムを通して伝播されるべきです。
Content that is highly mobile may require specifying some type of anchor that is kept at the NRS instead of the content location.
非常にモバイルのコンテンツは、コンテンツの場所ではなくNRSに保持されているいくつかの種類のアンカーを指定する必要があるかもしれません。
An NRS must ensure that the name resolution is successful with high probability if the name-matching content exists in the network, regardless of its popularity and the number of cached copies existing in the network. Per Section 4.1, some resolutions may not occur in a timely manner. However, the probability of such an event should be minimized. The NRS system may provide a probability (five 9s or five sigmas, for instance) that a resolution will be satisfied.
NRSは、その人気とネットワーク内に存在するキャッシュされたコピーの数に関係なく、名前一致するコンテンツがネットワーク内に存在する場合、名前解決が高い確率で、名前解決が確実に成功したことを確認する必要があります。セクション4.1ごとに、いくつかの解像度はタイムリーに発生しない可能性があります。しかしながら、そのような事象の確率は最小限に抑えるべきである。NRSシステムは、解像度が満たされる確率（例えば、9秒または5つのシグマ）を提供することができる。
An NRS could provide this service for all content in a fair manner, independently of the specific content properties (content producer, content popularity, availability of copies, content format, etc.). Fairness may be defined as a per-request delay to complete the NRS steps that is agnostic to the properties of the content itself. Fairness may be defined as well as the number of requests answered per unit of time.
NRSは、特定のコンテンツのプロパティ（コンテンツプロデューサ、コンテンツの人気、コピーの可用性、コンテンツ形式など）とは無関係に、このサービスを公正な方法で提供することができます。公平性は、コンテンツ自体のプロパティにとって不具合なNRSステップを完了するために、要求ごとの遅延として定義されます。公平性は定義されてもよく、単位の時間ごとに回答された要求の数を定義することができます。
However, it is notable that content (or their associated producer) may request a different level of QoS from the network (see [RFC9064], for instance), and this may include the NRS as well, in which case considerations of fairness may be restricted to content within the same class of service.
しかしながら、コンテンツ（またはそれに関連するプロデューサ）がネットワークから異なるレベルのQoSを要求することができる（例えば、[RFC9064]参照）、これにはNRSも含まれる可能性があることが、その場合、公平性の考慮事項がある可能性があることが注目に値する。同じクラスのサービス内のコンテンツに制限されています。
The NRS system must scale up to support a very large user population (including human users as well as machine-to-machine communications). As an idea of the scale, it is expected that 50 billion devices will be connected in 2025 (per ITU projections). The system must be able to respond to a very large number of requests per unit of time. Message forwarding and processing, routing table buildup, and name record propagation must be efficient and scalable.
NRSシステムは、非常に大きなユーザー人口（人間のユーザーを含む、マシンからマシンの通信など）をサポートするために拡張する必要があります。スケールの考えとして、2025年に500億デバイスが接続されることが予想されます（ITU予測ごと）。システムは、単位時間当たりの非常に多数の要求に応答することができなければなりません。メッセージ転送と処理、ルーティングテーブルのビデオ、および名前レコードの伝播は効率的でスケーラブルでなければなりません。
The NRS system must scale up with the number of pieces of content (content names) and should be able to support a content catalog that is extremely large. Internet traffic is of the order of zettabytes per year (10^21 bytes). Since NRS is associated with actual traffic, the number of pieces of content should scale with the amount of traffic. Content size may vary from a few bytes to several GB, so the NRS should be expected scale up to a catalog of the size of 10^21 in the near future, and larger beyond.
NRSシステムは、コンテンツの数（コンテンツ名）の数でスケールアップし、非常に大きいコンテンツカタログをサポートできるはずです。インターネットトラフィックは年間ゼタバイトの順序です（10 ^ 21バイト）。NRSは実際のトラフィックに関連付けられているので、コンテンツの数はトラフィック量で拡張する必要があります。コンテンツサイズは数バイトから数GBまで変化しますので、NRSは近い将来、近い将来、10 ^ 21のサイズのカタログまでスケールアップします。
The NRS system must be able to scale up -- namely, to add NRS servers to the NRS system in a way that is transparent to the users. The addition of a new server should have a limited negative impact on the other NRS servers (or should have a negative impact on only a small subset of the NRS servers). The impact of adding new servers may induce some overhead at the other servers to rebuild a hierarchy or to exchange messages to include the new server within the service. Further, data may be shared among the new servers for load balancing or tolerance to failure. These steps should not disrupt the service provided by the NRS and should improve the quality of the service in the long run.
NRSシステムは、ユーザーに対して透過的な方法でNRSサーバーをNRSシステムに追加することができなければなりません。新しいサーバーの追加は、他のNRSサーバーに限られたマイナスの影響を及ぼします（または、NRSサーバーの小さなサブセットのみに影響を与えるはずです）。新しいサーバーを追加することの影響は、他のサーバーでいくつかのオーバーヘッドを誘発して階層を再構築したり、サービス内の新しいサーバーを含めるようにメッセージを交換することができます。また、負荷分散や障害に対する許容範囲のために、データを新しいサーバ間で共有することができる。これらのステップは、NRSによって提供されるサービスを中断してはならず、長期的にサービスの品質を向上させるべきです。
The NRS system may support access from a heterogeneity of connection methods and devices. In particular, the NRS system may support access from constrained devices, and interactions with the NRS system would not be too costly. An IoT node, for instance, should be able to access the NRS system as well as a more powerful node.
NRSシステムは、接続方法および装置の不均一性からのアクセスをサポートすることができる。特に、NRSシステムは制約付きデバイスからのアクセスをサポートし、NRSシステムとの対話は高すぎないであろう。たとえば、IOTノードは、NRSシステムとより強力なノードにアクセスできるはずです。
The NRS system should scale up in its responsiveness to the increased request rate that is expected from applications such as IoT or machine-to-machine (M2M), where data is being frequently generated and/or requested.
NRSシステムは、データやマシンからマシン（M2M）などのアプリケーションに予想される、データが頻繁に生成されていると要求されている要求率の上昇に対するその応答性に縮小する必要があります。
The NRS system must be manageable since some parts of the system may grow or shrink dynamically and an NRS system node may be added or deleted frequently.
システムの一部が動的に成長または縮小し、NRSシステムノードを頻繁に追加または削除することができるので、NRSシステムは管理可能でなければなりません。
The NRS system may support an NRS management layer that allows for adding or subtracting NRS nodes. In order to infer the circumstance, the management layer can measure the network status.
NRSシステムは、NRSノードを追加または減算することを可能にするNRS管理層をサポートすることができる。状況を推測するために、管理層はネットワークの状態を測定できます。
The NRS system must be deployable since deployability is important for a real-world system. The NRS system must be deployable in network edges and cores so that the consumers as well as ICN routers can perform name resolution in a very low latency.
Real-Worldシステムには、デプロイ可能性が重要なので、NRSシステムは展開可能である必要があります。NRSシステムは、消費者とICNルータが非常に低い待ち時間で名前解決を実行できるように、ネットワークエッジとコアで展開できなければなりません。
The NRS system must ensure resiliency in the event of NRS server failures. The failure of a small subset of nodes should not impact the NRS performance significantly.
NRSシステムは、NRSサーバーの障害が発生した場合に復元性を確保する必要があります。ノードの小さなサブセットの障害は、NRSのパフォーマンスに大きく影響しません。
After an NRS server fails, the NRS system must be able to recover and/or restore the name records stored in the NRS server.
NRSサーバーに障害が発生した後、NRSシステムは、NRSサーバーに保存されている名前レコードを回復および/または復元できなければなりません。
On utilizing an NRS in ICN, there are some security considerations for the NRS servers/nodes and name mapping records stored in the NRS system. This subsection describes them.
ICNのNRSを利用すると、NRSシステムに格納されているNRSサーバー/ノードおよび名前マッピングレコードについてはいくつかのセキュリティ上の考慮事項があります。このサブセクションについて説明します。
The name mapping records in the NRS system must be assigned with proper access rights such that the information contained in the name mapping records would not be revealed to unauthorized users.
NRSシステム内の名前マッピングレコードには、名前マッピングレコードに含まれる情報が不正なユーザーに明らかにされないように、適切なアクセス権を割り当てる必要があります。
The NRS system may support access control for certain name mapping records. Access control can be implemented with a reference monitor that uses client authentication, so only users with appropriate credentials can access these records, and they are not shared with unauthorized users. Access control can also be implemented by encryption-based techniques using control of keys to control the propagations of the mappings.
NRSシステムは、特定の名前マッピングレコードのアクセス制御をサポートすることがあります。アクセス制御は、クライアント認証を使用する参照モニタで実装できますので、適切な資格情報を持つユーザーだけがこれらのレコードにアクセスでき、それらは不正なユーザーと共有されません。アクセス制御は、マッピングの伝播を制御するためのキーの制御を使用して暗号化ベースの技法によっても実装することができる。
The NRS system may support obfuscation and/or encryption mechanisms so that the content of a resolution request may not be accessible by third parties outside of the NRS system.
NRSシステムは、難読化および/または暗号化メカニズムをサポートし、解像度要求の内容はNRSシステムの外部の第三者によってアクセス可能ではない可能性がある。
The NRS system must keep confidentiality to prevent sensitive name mapping records from being reached by unauthorized data requesters. This is more required in IoT environments where a lot of sensitive data is produced.
NRSシステムは、機密の名前マッピングレコードが不正なデータ要求者によって到達するのを防ぐために機密性を保つ必要があります。これは、多くの機密データが生成されたIOT環境ではより必要です。
The NRS system must also keep confidentiality of metadata as well as NRS usage to protect the privacy of the users. For instance, a specific user's NRS requests should not be shared outside the NRS system (with the exception of legal intercept).
NRSシステムはまた、ユーザのプライバシーを保護するためにメタデータとNRSの使用法の機密保持を保つ必要があります。たとえば、特定のユーザーのNRS要求は、NRSシステムの外で共有されてはいけません（有効な傍受を除く）。
* NRS server authentication: Authentication of the new NRS servers/ nodes that want to be registered with the NRS system must be required so that only authenticated entities can store and update name mapping records. The NRS system should detect an attacker attempting to act as a fake NRS server to cause service disruption or manipulate name mapping records.
* NRSサーバー認証：認証されたエンティティのみが名前マッピングレコードを保存および更新できるように、NRSシステムに登録されたい新しいNRSサーバー/ノードの認証を必要とする必要があります。NRSシステムは、スキャルのNRSサーバーとして機能しようとした攻撃者を検出して、サービスの中断を中断したり、ネームマッピング・レコードを操作したりします。
* Producer authentication: The NRS system must support authentication of the content producers to ensure that update/addition/removal of name mapping records requested by content producers are actually valid and that content producers are authorized to modify (or revoke) these records or add new records.
* プロデューサ認証：NRSシステムは、コンテンツプロデューサによって要求されたネームマッピングレコードの更新/追加/削除が実際に有効であり、これらのレコードを変更（または取り消す）または新しいレコードを追加することを許可されていることを確認するために、コンテンツプロデューサの認証をサポートしなければなりません。。
* Mapping record authentication: The NRS should verify new mapping records that are being registered so that it cannot be polluted with falsified information or invalid records.
* マッピングレコード認証：NRSは、登録されている新しいマッピングレコードを検証して、偽造された情報や無効なレコードで汚染されないようにする必要があります。
The NRS system must be protected from malicious users attempting to hijack or corrupt the name mapping records.
NRSシステムは、ネームマッピングレコードをハイジャックまたは破損しようとしている悪意のあるユーザーから保護する必要があります。
The NRS system should be resilient against denial-of-service attacks and other common attacks to isolate the impact of the attacks and prevent collateral damage to the entire system. Therefore, if a part of the NRS system fails, the failure should only affect a local domain. And fast recovery mechanisms need to be in place to bring the service back to normal.
NRSシステムは、攻撃の影響を隔離し、システム全体への担保の損傷を防ぐためのサービス拒否攻撃やその他の一般的な攻撃に対して弾力的であるべきです。したがって、NRSシステムの一部が失敗した場合、障害はローカルドメインにのみ影響します。そして、サービスを通常に戻すために、高速回復メカニズムを整理する必要があります。
ICN routing may comprise three steps: name resolution, content request routing, and content delivery. This document investigates the name resolution step, which is the first and most important to be achieved for ICN routing to be successful. A Name Resolution Service (NRS) in ICN is defined as the service that provides such a function of name resolution for translating an object name into some other information such as a locator, another name, metadata, next-hop info, etc. that is used for forwarding the object request.
ICNルーティングは、名前解決、コンテンツ要求ルーティング、およびコンテンツ配信の3つのステップを含み得る。この文書は名前解決ステップを調査します。これは、ICNルーティングが成功するために達成される最初のかつ最も重要です。ICN内の名前解決サービス（NRS）は、オブジェクト名をロケータ、別の名前、メタデータ、ネクストホップ情報などの他の情報に変換するための名前解決の関数を提供するサービスとして定義されています。オブジェクト要求を転送するために使用されます。
This document classifies and analyzes the NRS approaches according to whether the name resolution step is separated from the content request routing as an explicit process or not. This document also explains the NRS functions used to support heterogeneous name types, producer mobility, scalable routing system, off-path caching, nameless object, manifest, and metadata. Finally, this document presents design considerations for NRS in ICN, which include resolution response time and accuracy, resolution guarantee, resolution fairness, scalability, manageability, deployed system, and fault tolerance.
この文書は、名前解決ステップが明示的なプロセスとしてコンテンツ要求ルーティングから分離されているかどうかに応じて、NRSアプローチを分類し分析します。この文書では、異種ネームタイプ、プロデューサモビリティ、スケーラブルルーティングシステム、オフパスキャッシング、無名オブジェクト、マニフェスト、およびメタデータをサポートするために使用されるNRS関数も説明しています。最後に、この文書はICNのNRSの設計上の考慮事項を示しています。これには、解像度の応答時間と正確さ、解像度保証、解像度の公平性、スケーラビリティ、管理性、展開システム、およびフォールトトレランスが含まれます。
This document has no IANA actions.
この文書にはIANAの行動がありません。
A discussion of security guidelines is provided in Section 4.9.
セキュリティガイドラインの説明はセクション4.9で提供されています。
[RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, "Information-Centric Networking (ICN) Research Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, <https://www.rfc-editor.org/info/rfc7927>.
[RFC7927] Kutscher、D.、ED。、EUM、S、Pentikousis、K。、PSARAS、I。、Corujo、D.、Saucez、D.、Schmidt、T.、およびM. Wahlisch、2016年7月、RFC 7927、DOI 10.17487 / RFC7927、<https：//www.rfc-editor.org/info/rfc7927>。
[Afanasyev] Afanasyev, A. et al., "SNAMP: Secure Namespace Mapping to Scale NDN Forwarding", 2015 IEEE Conference on Computer Communications Workshops, DOI 10.1109/INFCOMW.2015.7179398, April 2015, <https://doi.org/10.1109/INFCOMW.2015.7179398>.
[Afanasyev] Afanasyev、A。ら、「スナップ：Secure NDNへの安全な名前空間マッピング」、2015年IEEEコンピュータ通信ワークショップ、DOI 10.1109 / INFCOMW.2015.7179398、<https：//doi.org/10.1109 / infcomw.2015.7179398>。
[Ahlgren] Ahlgren, B., Dannewitz, C., Imbrenda, C., Kutscher, D., and B. Ohlman, "A Survey of Information-Centric Networking", IEEE Communications Magazine, Vol. 50, Issue 7, DOI 10.1109/MCOM.2012.6231276, July 2012, <https://doi.org/10.1109/MCOM.2012.6231276>.
[Ahlgren] Ahlgren、B.、Dannewitz、C、Imbrenda、C、Kutcher、D.、およびB. Ohlman、「情報中心のネットワーキングの調査」、IEEE Communications Magazine、Vol。2012年7月、<https://doi.org/10.1109/mcom.2012.6231276>
[Amadeo] Amadeo, M., Campolo, C., Iera, A., and A. Molinaro, "Named data networking for IoT: An architectural perspective", European Conference on Networks and Communications (EuCNC), DOI 10.1109/EuCNC.2014.6882665, June 2014, <https://doi.org/10.1109/EuCNC.2014.6882665>.
【Amadeo】Amadeo、M.、Campolo、C.、Iera、A。、A. Molinaro、「IoTのためのデータネットワーキング：建築の観点」、ネットワークおよび通信に関するヨーロッパの会議（EUCNC）、DOI 10.1109 / EUCNC。2014.6882665、2014年6月、<https：//doi.org/10.1109/eucnc.2014.6882665>。
[Amadeo2] Amadeo, M. et al., "Information-centric networking for the internet of things: challenges and opportunities", IEEE Network, Vol. 30, No. 2, DOI 10.1109/MNET.2016.7437030, March 2016, <https://doi.org/10.1109/MNET.2016.7437030>.
[Amadeo2] Amadeo、M. et al。、「インターネットのインターネットのための情報中心のネットワーク：課題と機会」、IEEEネットワーク、Vol。30、No.2、DOI 10.1109 / MNET.2016.7437030、2016年3月、<https：//doi.org/10.1109/Mnet.2016.7437030>。
[Baccelli] Baccelli, E., Mehlis, C., Hahm, O., Schmidt, T., and M. Wählisch, "Information Centric Networking in the IoT: Experiments with NDN in the Wild", ACM-ICN 2014, DOI 10.1145/2660129.2660144, 2014, <https://doi.org/10.1145/2660129.2660144>.
[Baccelli] Baccelli、E.、Mehlis、C.、HAHM、O.、Schmidt、T.、およびM.Wählisch、「IOTにおける情報中心のネットワーキング：野生のNDNによる実験」、ACM-ICN 2014、DOI2014,2014、<https://doi.org/10.1145/2660129.2660144>。
[Bari] Bari, M.F., Chowdhury, S.R., Ahmed, R., Boutaba, R., and B. Mathieu, "A Survey of Naming and Routing in Information-Centric Networks", IEEE Communications Magazine, Vol. 50, No. 12, pp. 44-53, DOI 10.1109/MCOM.2012.6384450, December 2012, <https://doi.org/10.1109/MCOM.2012.6384450>.
[Bari] Bari、M.f.、Chowdhury、S.r.、Ahmed、R.、Boutaba、R.、B。Mathieu、「情報中心のネットワークにおける命名およびルーティングの調査」、IEEE Communications Magazine、Vol。50、No.12、PP。44-53、DOI 10.1109 / MCOM.2012.6384450、2012年12月、<https：//doi.org/10.1109/mcom.2012.6384450>。
[Bayhan] Bayhan, S. et al., "On Content Indexing for Off-Path Caching in Information-Centric Networks", ACM-ICN 2016, DOI 10.1145/2984356.2984372, September 2016, <https://doi.org/10.1145/2984356.2984372>.
[Bayhan] Bayhan、S. et al。、「情報中心ネットワークにおけるオフパスキャッシングのためのコンテンツインデックス」、ACM-ICN 2016、DOI 10.1145 / 2984356.2984372、2016年9月、<https：//doi.org/10.1145/ 2984356.2984372>。
[CCNx] "CICN", <https://wiki.fd.io/view/Cicn>.
[ccnx] "cicn"、<https://wiki.fd.io/view/cicn>。
[Dannewitz] Dannewitz, C. et al., "Network of Information (NetInf) - An information-centric networking architecture", Computer Communications, Vol. 36, Issue 7, DOI 10.1016/j.comcom.2013.01.009, April 2013, <https://doi.org/10.1016/j.comcom.2013.01.009>.
[Dannewitz] Dannewitz、C. et al。、「情報のネットワーク（NetInf） - 情報中心ネットワーキングアーキテクチャ」、コンピュータ通信、Vol。36、発行7、DOI 10.1016 / J.com.2013.01.009、2013年4月、<https://doi.org/10.1016/j.jp.comcom.2013.01.009>。
[FLIC] Tschudin, C., Wood, C. A., Mosko, M., and D. Oran, "File-Like ICN Collections (FLIC)", Work in Progress, Internet-Draft, draft-irtf-icnrg-flic-03, 7 November 2021, <https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-flic-03>.
[FLIC] Tschudin、C.、Wood、CA、Mosko、M.、およびD. Oran、「ファイルのようなICNコレクション（FLIC）」、進行中の作業、インターネットドラフト、ドラフト-IRTF-ICNRG-FLIC-03、2021年11月7日、<https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-flic-03>。
[ID.Zhang2] Ravindran, R., Zhang, Y., Grieco, L. A., Lindgren, A., Burke, J., Ahlgren, B., and A. Azgin, "Design Considerations for Applying ICN to IoT", Work in Progress, Internet-Draft, draft-irtf-icnrg-icniot-03, 2 May 2019, <https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-icniot-03>.
[Id.Zhang2] Ravindran、R.、Zhang、Y.、Grieco、La、Lindgren、A.、Burke、J.、Ahlgren、B.、A. Azgin、「IOTにICNを適用するための設計上の考慮事項」、仕事進行中、インターネットドラフト、ドラフト - IRTF-ICNRG-ICNIOT-03,2019、<https：//datatracker.ietf.org/doc/html/draft-irtf-icnrg-icniot-03>。
[Jung] Jung, H. et al., "IDNet: Beyond All-IP Network", ETRI Journal, Vol. 37, Issue 5, DOI 10.4218/etrij.15.2415.0045, October 2015, <https://doi.org/10.4218/etrij.15.2415.0045>.
[Jung] Jung、H. et al。、 "IDNet：All-IPネットワークを超えて"、atri Journal、Vol。37、発行5、DOI 10.4218 / ETRIJ.15.2415.0045、<https：//doi.org/10.4218/etrij.15.2415.0045>。
[Koponen] Koponen, T., Chawla, M., Chun, B., Ermolinskiy, A., Kim, K.H., Shenker, S., and I. Stoica, "A Data-Oriented (and Beyond) Network Architecture", ACM SIGCOMM 2007, pp. 181-192, DOI 10.1145/1282380.1282402, August 2007, <https://doi.org/10.1145/1282380.1282402>.
[Koponen]コポネン、T.、Chaula、M.、Chun、B.、Ermolinskiy、A。、KIM、KH、Shenker、S.、I。Stoica、「データ指向（そしてそれ以上）ネットワークアーキテクチャ」、ACM SIGCOMM 2007、PP.181-192、DOI 10.1145 / 1282380.1282402、2007年8月、<https：//doi.org/10.1145/1282380.1282402>。
[MF] "MobilityFirst Future Internet Architecture Project Overview", <http://mobilityfirst.winlab.rutgers.edu>.
[MF] "MobilityFirst Future Internet Architectureプロジェクトの概要"、<http://mobilityfirst.winlab.rutgers.edu>。
[Mosko2] Mosko, M., "Nameless Objects", IRTF ICNRG, January 2016, <https://datatracker.ietf.org/meeting/interim-2016-icnrg-01/materials/slides-interim-2016-icnrg-1-7.pdf>.
[Mosko2] Mosko、M.、 "Name Ress Object"、IRTF ICNRG、2016年1月、<https://datatracker.ietf.org/meeting/interim-2016-icgrg-01/Materials/Slides-Interm-2016-icg-1-7.pdf>。
[NDN] "Named Data Networking", <http://www.named-data.net>.
[NDN] "名前付きデータネットワーキング"、<http://www.named-data.net>。
[NEO] Eriksson, A. and A.M. Malik, "A DNS-based information-centric network architecture open to multiple protocols for transfer of data objects", 21st Conference on Innovation in Clouds, Internet and Networks and Workshops (ICIN), pp. 1-8, DOI 10.1109/ICIN.2018.8401595, February 2018, <https://doi.org/10.1109/ICIN.2018.8401595>.
[Neo]エリクソン、A.そしてam。Malik、「DNSベースの情報中心のネットワークアーキテクチャは、データオブジェクトの転送のための複数のプロトコルに開放されています」、雲の革新に関する第21回、インターネット、ネットワーク、ワークショップ（ICIN）、PP。1-8、DOI 10.1109 / ICIN。2018.8401595、2018年2月、<https：//doi.org/10.1109/iCin.2018.8401595>。
[NRSarch] Hong, J., You, T., and V. Kafle, "Architectural Considerations of ICN using Name Resolution Service", Work in Progress, Internet-Draft, draft-irtf-icnrg-nrsarch-considerations-06, 12 February 2021, <https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-nrsarch-considerations-06>.
[NRSARCH]香港、J.、You、T.、およびV.カフェ、「名前解決策を使用したICNの建築検討」、進行中の作業、インターネットドラフト、ドラフト - IRTF-ICNRG-NRSARCH-ICTICATIONS-06,122021年2月、<https://datatracker.ietf.org/doc/html/draft -irtf-icnrg-nrsarch-consididerations-06>。
[PURSUIT] "FP7 PURSUIT", <https://www.fp7-pursuit.eu/>.
[Pursuit] "FP7 Pursuit"、<https：//www.fp7-pursuit.eu/>。
[Quevedo] Quevedo, J., Corujo, D., and R. Aguiar, "A case for ICN usage in IoT environments", IEEE GLOBECOM, DOI GLOCOM.2014.7037227, December 2014, <https://doi.org/GLOCOM.2014.7037227>.
[Quevedo] Quevedo、J.、Corujo、D.、R.Aguiar、「IOT環境におけるICN使用のためのケース」、IEEE GlobeCom、Doi Glocom.2037227、2014年12月、2014年12月、<https：//doi.org/glocom。2014.7037227>。
[Ravindran] Ravindran, R., Chakraborti, A., and A. Azgin, "Forwarding Label support in CCN Protocol", Work in Progress, Internet-Draft, draft-ravi-icnrg-ccn-forwarding-label-02, 5 March 2018, <https://datatracker.ietf.org/doc/html/ draft-ravi-icnrg-ccn-forwarding-label-02>.
[Ravindran] Ravindran、R.、Chakraborti、A. A. Azgin、「CCNプロトコルの転送ラベルサポート」、進行中の作業、インターネットドラフト、ドラフト-RAVI-ICNRG-CCN転送ラベル-02,52018年3月、<https://datatracker.ietf.org/doc/html/ raft-ravi-icrg-ccn-forwarding-label-02>。
[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A., and P. Hallam-Baker, "Naming Things with Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, <https://www.rfc-editor.org/info/rfc6920>.
[RFC6920] Farrell、S.、Kutscher、D.、Dannewitz、C.、Ohlman、B.、Keranen、A.、およびP. Hallam-Baker、「ハッシュ付きのもの」、RFC 6920、DOI 10.17487 / RFC6920、2013年4月、<https：//www.rfc-editor.org/info/rfc6920>。
[RFC8569] 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>.
[RFC8569] Mosko、M.、Solis、I.、およびC. Wood、 "Content-Centric Networking（CCNX）セマンティクス"、RFC 8569、DOI 10.17487 / RFC8569、2019年7月、<https：///www.rfc-編集者.org / info / rfc8569>。
[RFC9064] Oran, D., "Considerations in the Development of a QoS Architecture for CCNx-Like Information-Centric Networking Protocols", RFC 9064, DOI 10.17487/RFC9064, June 2021, <https://www.rfc-editor.org/info/rfc9064>.
[RFC9064] Oran、D。、「CCNXのような情報中心のネットワーキングプロトコルのためのQoSアーキテクチャの開発における考察」、RFC 9064、DOI 10.17487 / RFC9064、2021年6月、<https：//www.rfc-編集者。ORG / INFO / RFC9064>。
[SA2-5GLAN] 3GPP, "New WID: 5GS Enhanced support of Vertical and LAN Services", TSG SA Meeting #SP-82, December 2018, <http://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_82/Docs/SP-181120.zip>.
[SA2-5GLAN] 3GPP、「新WID：垂直・LANサービスの5GSの強化されたサポート」、TSG SAミーティング＃SP-82、2018年12月、<http://www.3gpp.org/ftp/tsg_sa/tsg_sa/tsgs_82/docs/sp-181120.zip>。
[SAIL] "Scalable and Adaptive Internet Solutions (SAIL)", <http://www.sail-project.eu/>.
[Sail] "スケーラブルで適応的なインターネットソリューション（Sail）"、<http://www.sail-project.eu/>。
[Westphal] Westphal, C. and E. Demirors, "An IP-Based Manifest Architecture for ICN", ACM-ICN 2015, DOI 10.1145/2810156.2812614, September 2015, <https://doi.org/10.1145/2810156.2812614>.
[Westphal] Westphal、C.およびE.デモール、「ICNのためのIPベースのマニフェストアーキテクチャ」、ACM-ICN 2015、DOI 10.1145 / 2810156.2812614、2015年9月、<https：//doi.org/10.1145/2810156.2812614>。
[Xylomenos] Xylomenos, G., Ververidis, C., Siris, V., Fotiou, N., Tsilopoulos, C., Vasilakos, X., Katsaros, K., and G. Polyzos, "A Survey of Information-Centric Networking Research", IEEE Communications Surveys and Tutorials, Vol. 16, Issue 2, DOI 10.1109/SURV.2013.070813.00063, 2014, <https://doi.org/10.1109/SURV.2013.070813.00063>.
[Xylomenos] Xylomenos、G.、Ververidis、C.、Siris、V.、Fotiou、N.、Tsilopoulos、C、Vasilakos、X.、Katsaros、K.、およびG. Polyzos、Polyzosネットワーキング研究、IEEEコミュニケーションズ調査とチュートリアル、Vol。16、Issue 2、DOI 10.1109 / Broud.2013.070813.00063,2014、<https：//doi.org/10.1109/SURV.2013.070813.00063>。
[Zhang2] Zhang, Y. et al., "A Survey of Mobility Support in Named Data Networking", IEEE Conference on Computer Communications Workshops, DOI 10.1109/INFCOMW.2016.7562050, April 2016, <https://doi.org/10.1109/INFCOMW.2016.7562050>.
[Zhang2] Zhang、Y。et al。、「名前付きデータネットワーキングにおけるモビリティサポートの調査」、IEEEコンピュータ通信ワークショップ、DOI 10.1109 / INFCOMW.2016.7562050、2016年4月、<https：//doi.org/10.1109/ infcomw.2016.7562050>。
Acknowledgements
謝辞
The authors would like to thank Dave Oran, Dirk Kutscher, Ved Kafle, Vincent Roca, Marie-Jose Montpetit, Stephen Farrell, Mirja Kühlewind, and Colin Perkins for very useful reviews, comments, and improvements to the document.
著者らは、Dave Oran、Dirk Kutscher、Ved Kafle、Vincent Roca、Marie-Jose Montpetit、Stephen Farrell、MirjaKühlewind、Colin Perkins、コメント、および文書の改良をお寄せください。
Authors' Addresses
著者の住所
Jungha Hong ETRI Yuseung-Gu 218 Gajeong-ro Daejeon 34129 Republic of Korea
JUNGHA Hong Etri Yuseung-Gu 218 Gajeong-Ro大田34129韓国共和国
Email: jhong@etri.re.kr
Tae-Wan You ETRI Yuseung-Gu 218 Gajeong-ro Daejeon 34129 Republic of Korea
Tae-Wan you etri yuseung-g 218 Gajeong-Ro大田34129韓国共和国
Email: twyou@etri.re.kr
Lijun Dong Futurewei Technologies Inc. 10180 Telesis Court San Diego, CA 92121 United States of America
Lijun Dong Futurewe Technologies Inc. 10180 Telesis Court San Diego、CA 92121アメリカ合衆国
Email: lijun.dong@futurewei.com
Cedric Westphal Futurewei Technologies Inc. 2330 Central Expressway Santa Clara, CA 95050 United States of America
Cedric Westphal Futurewe Technologies Inc. 2330 Central Expresswayサンタクララ、CA 95050アメリカ合衆国
Email: cedric.westphal@futurewei.com
Börje Ohlman Ericsson Research SE-16480 Stockholm Sweden
BörjeOhlman Ericsson Research SE-16480ストックホルムスウェーデン
Email: Borje.Ohlman@ericsson.com