[要約] RFC 9344 - CCNinfoは、Content-Centric Networks（CCNs）におけるネットワークトポロジとインネットワークキャッシュに関する情報を発見するためのメカニズムを記述しています。ICNRGによって作成され、CCNシステムのテストベッドネットワークや実験的展開の動作を理解しデバッグするのに役立ちます。
Internet Research Task Force (IRTF) H. Asaeda
Request for Comments: 9344 A. Ooka
Category: Experimental NICT
ISSN: 2070-1721 X. Shao
Toyohashi University of Technology
February 2023
This document describes a mechanism named "CCNinfo" that discovers information about the network topology and in-network cache in Content-Centric Networks (CCNs). CCNinfo investigates 1) the CCN routing path information per name prefix, 2) the Round-Trip Time (RTT) between the content forwarder and the consumer, and 3) the states of in-network cache per name prefix. CCNinfo is useful to understand and debug the behavior of testbed networks and other experimental deployments of CCN systems.
このドキュメントでは、コンテンツ中心のネットワーク（CCNS）のネットワークトポロジとネットワーク内キャッシュに関する情報を発見する「ccninfo」という名前のメカニズムについて説明します。CCNINFOは、1）名前のプレフィックスごとのCCNルーティングパス情報、2）コンテンツフォワーダーと消費者間の往復時間（RTT）、および3）名前のプレフィックスごとのネットワーク内キャッシュの状態を調査します。CCNINFOは、テストベッドネットワークの動作やCCNシステムのその他の実験的展開を理解してデバッグするのに役立ちます。
This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG). This document represents the consensus view of ICNRG and has been reviewed extensively by several members of the ICN community and the RG. The authors and RG chairs approve of the contents. The document is sponsored under the IRTF, is not issued by the IETF, and is not an IETF standard. This is an experimental protocol and the specification may change in the future.
このドキュメントは、IRTF情報中心のネットワーキング研究グループ（ICNRG）の製品です。このドキュメントは、ICNRGのコンセンサスビューを表しており、ICNコミュニティとRGの複数のメンバーによって広範囲にレビューされています。著者とRG椅子は内容を承認します。このドキュメントはIRTFの下で後援され、IETFによって発行されておらず、IETF標準ではありません。これは実験的なプロトコルであり、仕様は将来変化する可能性があります。
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントは、インターネット標準の追跡仕様ではありません。試験、実験的実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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/rfc9344.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9344で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 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ドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
1. Introduction
1.1. CCNinfo as an Experimental Tool
2. Terminology
2.1. Definitions
3. CCNinfo Message Formats
3.1. Request Message
3.1.1. Request Header Block and Request Block
3.1.2. Report Block TLV
3.1.3. Content Name Specification
3.2. Reply Message
3.2.1. Reply Block TLV
3.2.1.1. Reply Sub-Block TLV
4. CCNinfo User Behavior
4.1. Sending CCNinfo Request
4.1.1. Routing Path Information
4.1.2. In-Network Cache Information
4.2. Receiving CCNinfo Reply
5. Router Behavior
5.1. User and Neighbor Verification
5.2. Receiving CCNinfo Request
5.3. Forwarding CCNinfo Request
5.3.1. Regular Request
5.3.2. Full Discovery Request
5.4. Sending CCNinfo Reply
5.5. Forwarding CCNinfo Reply
5.6. PIT Entry Management for Multipath Support
6. CCNinfo Termination
6.1. Arriving at First-Hop Router
6.2. Arriving at Router Having Cache
6.3. Arriving at Last Router
6.4. Invalid Request
6.5. No Route
6.6. No Information
6.7. No Space
6.8. Fatal Error
6.9. CCNinfo Reply Timeout
6.10. Non-Supported Node
6.11. Administratively Prohibited
7. Configurations
7.1. CCNinfo Reply Timeout
7.2. HopLimit in Fixed Header
7.3. Access Control
8. Diagnosis and Analysis
8.1. Number of Hops and RTT
8.2. Caching Router Identification
8.3. TTL or Hop Limit
8.4. Time Delay
8.5. Path Stretch
8.6. Cache Hit Probability
9. IANA Considerations
9.1. Packet Type Registry
9.2. Top-Level Type Registry
9.3. Hop-by-Hop Type Registry
9.4. Message Type Registry
9.5. Reply Type Registry
10. Security Considerations
10.1. Policy-Based Information Provisioning for Request
10.2. Filtering CCNinfo Users Located in Invalid Networks
10.3. Topology Discovery
10.4. Characteristics of Content
10.5. Computational Attacks
10.6. Longer or Shorter CCNinfo Reply Timeout
10.7. Limiting Request Rates
10.8. Limiting Reply Rates
10.9. Adjacency Verification
11. References
11.1. Normative References
11.2. Informative References
Appendix A. ccninfo Command and Options
Acknowledgements
Authors' Addresses
In Content-Centric Networks (CCNs), publishers provide the content through the network, and receivers retrieve it by name. In this network architecture, routers forward content requests through their Forwarding Information Bases (FIBs), which are populated by name-based routing protocols. CCN also enables receivers to retrieve content from an in-network cache.
コンテンツ中心のネットワーク（CCNS）では、パブリッシャーはネットワークを介してコンテンツを提供し、レシーバーは名前で取得します。このネットワークアーキテクチャでは、Routersは、名前ベースのルーティングプロトコルが入力されている転送情報ベース（FIB）を介してコンテンツを転送します。また、CCNを使用すると、レシーバーはネットワーク内キャッシュからコンテンツを取得できます。
In CCN, while consumers do not generally need to know the content forwarder that is transmitting the content to them, the operators and developers may want to identify the content forwarder and observe the routing path information per name prefix for troubleshooting or investigating the network conditions.
CCNでは、消費者は一般にコンテンツを送信しているコンテンツの転送者を知る必要はありませんが、オペレーターと開発者は、コンテンツの転送者を特定し、ネットワーク条件をトラブルシューティングまたは調査するために名前のプレフィックスごとにルーティングパス情報を遵守したい場合があります。
IP traceroute is a useful tool for discovering the routing conditions in IP networks because it provides intermediate router addresses along the path between the source and the destination, and the Round-Trip Time (RTT) for the path. However, this IP-based network tool cannot trace the name prefix paths used in CCN. Moreover, such IP-based network tools do not obtain the states of the in-network cache to be discovered.
IP Tracerouteは、IPネットワークのルーティング条件を発見するための便利なツールです。これは、ソースと宛先の間のパスに沿って中間ルーターアドレスを提供し、パスの往復時間（RTT）を提供するためです。ただし、このIPベースのネットワークツールは、CCNで使用される名前のプレフィックスパスをトレースすることはできません。さらに、このようなIPベースのネットワークツールは、発見されるネットワーク内キャッシュの状態を取得しません。
Contrace [Contrace] enables end users (i.e., consumers) to investigate path and in-network cache conditions in CCN. Contrace is implemented as an external daemon process running over TCP/IP that can interact with a previous CCNx forwarding daemon (CCNx-0.8.2) to retrieve the caching information on the forwarding daemon. This solution is flexible, but it requires defining the common APIs used for global deployment in TCP/IP networks. ICN (Information-Centric Networking) ping [ICN-PING] and traceroute [ICN-TRACEROUTE] are lightweight operational tools that enable a user to explore the path(s) that reach a publisher or a cache storing the named content. ICN ping and traceroute, however, do not expose detailed information about the forwarders deployed by a network operator.
Contrace [Contrace]により、エンドユーザー（つまり、消費者）がCCNのパスとネットワーク内のキャッシュ条件を調査できます。Contraceは、以前のCCNX転送デーモン（CCNX-0.8.2）と対話できるTCP/IPを介して実行される外部デーモンプロセスとして実装され、転送デーモンに関するキャッシュ情報を取得できます。このソリューションは柔軟ですが、TCP/IPネットワークでのグローバル展開に使用される一般的なAPIを定義する必要があります。ICN（情報中心のネットワーキング）ping [icn-ping]およびtraceroute [icn-traceroute]は、ユーザーがパブリッシャーまたは名前付きコンテンツを保存するキャッシュに到達するパスを探索できるようにする軽量の動作ツールです。ただし、ICN PingとTracerouteは、ネットワークオペレーターによって展開されたフォワーダーに関する詳細な情報を公開しません。
This document describes the specifications of "CCNinfo", an active networking tool for discovering the path and content-caching information in CCN. CCNinfo defines the protocol messages to investigate path and in-network cache conditions in CCN. It is embedded in the CCNx forwarding process and can facilitate with non-IP networks as with the basic CCN concept.
このドキュメントでは、CCNのパスとコンテンツキャッシング情報を発見するためのアクティブなネットワークツールである「CCNINFO」の仕様について説明します。CCNINFOは、CCNのパスおよびネットワーク内のキャッシュ条件を調査するためのプロトコルメッセージを定義します。CCNX転送プロセスに組み込まれており、基本的なCCNコンセプトと同様に、非IPネットワークを使用することができます。
The two message types, Request and Reply messages, are encoded in the CCNx TLV format [RFC8609]. The Request-and-Reply message flow, walking up the tree from a consumer toward a publisher, is similar to the behavior of the IP multicast traceroute facility [RFC8487].
2つのメッセージタイプ、リクエストメッセージと返信メッセージは、CCNX TLV形式[RFC8609]でエンコードされています。消費者から出版社に向かってツリーを歩いているリクエストアンドレプリーのメッセージフローは、IPマルチキャストTraceroute施設[RFC8487]の動作に似ています。
CCNinfo facilitates the tracing of a routing path and provides 1) the RTT between the content forwarder (i.e., caching router or first-hop router) and consumer, 2) the states of the in-network cache per name prefix, and 3) the routing path information per name prefix.
CCNINFOは、ルーティングパスのトレースを促進し、1）コンテンツ転送業者（つまり、キャッシュルーターまたはファーストホップルーター）とコンシューマー間のRTTを提供します。2）名前ごとのネットワークキャッシュの状態、および3）名前のプレフィックスごとのルーティングパス情報。
In addition, CCNinfo identifies the states of the cache, such as the metrics for Content Store (CS) in the content forwarder as follows: 1) size of cached Content Objects, 2) number of cached Content Objects, 3) number of accesses (i.e., received Interests) per content, and 4) elapsed cache time and remaining cache lifetime of content.
さらに、CCNINFOは、コンテンツフォワーダーのコンテンツストア（CS）のメトリック（CS）などのキャッシュの状態を次のように識別します。1）キャッシュされたコンテンツオブジェクトのサイズ、2）キャッシュコンテンツオブジェクトの数、3）アクセス数（すなわち、コンテンツごとに利息を受け取り、4）キャッシュ時間と残りのキャッシュ寿命の経過寿命。
CCNinfo supports multipath forwarding. The Request messages can be forwarded to multiple neighbor routers. When the Request messages are forwarded to multiple routers, the different Reply messages are forwarded from different routers or publishers.
CCNINFOはマルチパス転送をサポートしています。リクエストメッセージは、複数の隣接ルーターに転送できます。要求メッセージが複数のルーターに転送されると、異なる応答メッセージが異なるルーターまたはパブリッシャーから転送されます。
Furthermore, CCNinfo implements policy-based information provisioning that enables administrators to "hide" secure or private information but does not disrupt message forwarding. This policy-based information provisioning reduces the deployment barrier faced by operators in installing and running CCNinfo on their routers.
さらに、CCNINFOは、管理者が安全または個人情報を「非表示」できるが、メッセージ転送を混乱させることができるポリシーベースの情報プロビジョニングを実装しています。このポリシーベースの情報プロビジョニングにより、ルーターにCCNINFOをインストールおよび実行する際に、オペレーターが直面する展開バリアが削減されます。
The document represents the consensus of the Information-Centric Networking Research Group (ICNRG). This document was read and reviewed by the active research group members. It is not an IETF product and is not a standard.
このドキュメントは、情報中心のネットワーキング研究グループ（ICNRG）のコンセンサスを表しています。このドキュメントは、アクティブな研究グループのメンバーによって読まれ、レビューされました。IETF製品ではなく、標準でもありません。
In order to carry out meaningful experimentation with CCNx protocols, comprehensive instrumentation and management information is needed to take measurements and explore both the performance and robustness characteristics of the protocols and of the applications using them. CCNinfo's primary goal is to gather and report this information. As experience is gained with both the CCNx protocols and CCNinfo itself, we can refine the instrumentation capabilities and discover what additional capabilities might be needed in CCNinfo and conversely which features wind up not being of sufficient value to justify the implementation complexity and execution overhead.
CCNXプロトコルを使用した意味のある実験を実行するには、測定を行い、プロトコルとそれらを使用したアプリケーションのパフォーマンスと堅牢性の両方の特性を調査するために、包括的な機器と管理情報が必要です。CCNINFOの主な目標は、この情報を収集して報告することです。CCNXプロトコルとCCNINFO自体の両方で経験が得られるため、計装機能を改良し、CCNINFOで必要な追加機能と逆に、実装の複雑さと実行オーバーヘッドを正当化するのに十分な価値がない機能を逆に発見することができます。
CCNinfo is intended as a comprehensive experimental tool for CCNx-based networks. It provides a wealth of information from forwarders, including on-path in-network cache conditions as well as forwarding path instrumentation of multiple paths toward content forwarders. As an experimental capability that exposes detailed information about the forwarders deployed by a network operator, CCNinfo employs more granular authorization policies than those required of ICN ping or ICN traceroute.
CCNINFOは、CCNXベースのネットワークの包括的な実験ツールとして意図されています。ネットワーク内のキャッシュ条件や、コンテンツフォワーダーへの複数のパスのパスインストルメンテーションを転送するだけでなく、転送者からの豊富な情報を提供します。ネットワークオペレーターによって展開されたフォワーダーに関する詳細な情報を公開する実験機能として、CCNINFOは、ICN PINGまたはICN Tracerouteに必要なものよりも多くの詳細な承認ポリシーを採用しています。
CCNinfo uses two message types: Request and Reply. A CCNinfo user, e.g., consumer, initiates a CCNinfo Request message when they want to obtain routing path and cache information. When an adjacent neighbor router receives the Request message, it examines its own cache information. If the router does not cache the specified content, it inserts its Report block into the hop-by-hop header of the Request message and forwards the message to its upstream neighbor router(s) decided by its FIB. In Figure 1, CCNinfo user and routers (Routers A, B, C) insert their own Report blocks into the Request message and forward the message toward the content forwarder.
CCNINFOは、リクエストと返信の2つのメッセージタイプを使用します。CCNINFOユーザー、たとえば、消費者は、ルーティングパスとキャッシュ情報を取得するときにCCNINFO要求メッセージを開始します。隣接する近隣ルーターがリクエストメッセージを受信すると、独自のキャッシュ情報を調べます。ルーターが指定されたコンテンツをキャッシュしない場合、レポートブロックをリクエストメッセージのホップバイホップヘッダーに挿入し、FIBによって決定された上流の近隣ルーターにメッセージを転送します。図1では、CCNINFOユーザーとルーター（ルーターA、B、C）は、独自のレポートブロックをリクエストメッセージに挿入し、メッセージをコンテンツフォワーダーに転送します。
1. Request 2. Request 3. Request
(U) (U+A) (U+A+B)
+----+ +----+ +----+
| | | | | |
| v | v | v
+--------+ +--------+ +--------+ +--------+ +---------+
| CCNinfo|----| Router |----| Router |----| Router |----|Publisher|
| user | | A | | B | | C | | |
+--------+ +--------+ +--------+ +--------+ +---------+
\
\ +-------+
3. Request \ | Cache |
(U+A+B) \ +---------+ |
v| Caching |----+
| router |
+---------+
Figure 1: Request Message Invoked by the CCNinfo User and Forwarded by Routers
図1：CCNINFOユーザーによって呼び出され、ルーターによって転送されるリクエストメッセージ
When the Request message reaches the content forwarder, the content forwarder forms the Reply message; it inserts its own Reply block TLV and Reply sub-block TLV(s) to the Request message. The Reply message is then forwarded back toward the user in a hop-by-hop manner along the Pending Interest Table (PIT) entries. In Figure 2, each router (Routers C, B, and A) forwards the Reply message along its PIT entry, and finally, the CCNinfo user receives a Reply message from Router C, which is the first-hop router for the publisher. Another Reply message from the caching router (i.e., Reply(C)) is discarded at Router B if the other Reply message (i.e., Reply(P)) was already forwarded by Router B.
リクエストメッセージがコンテンツフォワーダーに届くと、コンテンツフォワーダーは返信メッセージを形成します。独自の返信ブロックTLVを挿入し、リクエストメッセージにサブブロックTLVを返信します。返信メッセージは、保留中の利息テーブル（PIT）エントリに沿って、ホップバイホップでユーザーに転送されます。図2では、各ルーター（ルーターC、B、およびA）がピットエントリに沿って返信メッセージを転送し、最後に、CCNINFOユーザーは、パブリッシャーの最初のホップルーターであるRouter Cから返信メッセージを受信します。キャッシュルーター（すなわち、返信（c））からの別の返信メッセージは、他の返信メッセージ（すなわち、返信（p））がルーターBによってすでに転送された場合、ルーターBで破棄されます。
3. Reply(P) 2. Reply(P) 1. Reply(P)
+----+ +----+ +----+
| | | | | |
v | v | v |
+--------+ +--------+ +--------+ +--------+ +---------+
| CCNinfo|----| Router |----| Router |----| Router |----|Publisher|
| user | | A | | B | | C | | |
+--------+ +--------+ +--------+ +--------+ +---------+
^
\ +-------+
1. Reply(C) \ | Cache |
\ +---------+ |
\| Caching |----+
| router |
+---------+
Figure 2: Reply Messages Forwarded by Routers, and One Reply Message is Received by the CCNinfo User
図2：ルーターによって転送された返信メッセージ、および1つの返信メッセージがCCNINFOユーザーによって受信されます
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This document follows the basic terminologies and definitions described in [RFC8609]. Although CCNinfo requests flow in the opposite direction to the data flow, we refer to "upstream" and "downstream" with respect to data, unless explicitly specified.
このドキュメントは、[RFC8609]で説明されている基本的な用語と定義に従います。CCNINFOはデータフローとは反対の方向に流れを要求しますが、明示的に指定されていない限り、データに関して「上流」および「下流」を参照します。
Scheme name:
スキーム名：
A scheme name indicates a URI and protocol. This document only considers "ccnx:/" as the scheme name.
スキーム名は、URIとプロトコルを示します。このドキュメントは、「ccnx：/」のみをスキーム名と見なします。
Prefix name:
プレフィックス名：
A prefix name, which is defined in [RFC8569], is a name that does not uniquely identify a single Content Object, but rather a namespace or prefix of an existing Content Object name.
[RFC8569]で定義されているプレフィックス名は、単一のコンテンツオブジェクトを一意に識別するのではなく、既存のコンテンツオブジェクト名の名前空間またはプレフィックスを識別する名前です。
Exact name:
正確な名前：
An exact name, which is defined in [RFC8569], is one that uniquely identifies the name of a Content Object.
[RFC8569]で定義されている正確な名前は、コンテンツオブジェクトの名前を一意に識別するものです。
Node:
ノード：
A node within a CCN network can fulfill the role of a data publisher, a data consumer, and/or a forwarder for Interest and Content Object, as described in [RFC8793].
CCNネットワーク内のノードは、[RFC8793]で説明されているように、データパブリッシャー、データ消費者、および/または関心およびコンテンツオブジェクトの転送者の役割を満たすことができます。
Consumer:
消費者：
A node that requests Content Objects by generating and sending out Interests. It is the same definition of ICN Consumer, as given in [RFC8793].
関心を生成して送信することにより、コンテンツオブジェクトを要求するノード。[RFC8793]に与えられたICN消費者の同じ定義です。
Publisher:
出版社：
A node that creates Content Objects and makes them available for retrieval. It is the same definition of ICN Producer, as given in [RFC8793].
コンテンツオブジェクトを作成し、取得できるようにするノード。[RFC8793]に与えられたICNプロデューサーの同じ定義です。
Router:
ルーター：
A node that implements stateful forwarding in the path between consumer and publisher.
消費者と出版社の間のパスでのステートフルな転送を実装するノード。
Caching router:
キャッシュルーター：
A node that temporarily stores and potentially carries Interests or Content Objects before forwarding it to the next node.
次のノードに転送する前に、利息またはコンテンツオブジェクトを一時的に保存し、潜在的に運ぶノード。
Content forwarder:
コンテンツフォワーダー：
A content forwarder is either a caching router or a first-hop router that forwards Content Objects to consumers.
コンテンツフォワーダーは、キャッシュルーターまたはコンテンツオブジェクトを消費者に転送する最初のホップルーターのいずれかです。
CCNinfo user:
ccninfoユーザー：
A node that initiates the CCNinfo Request, which is either a consumer or a router that invokes the CCNinfo user program with the name prefix of the content. The CCNinfo user program, such as "ccninfo" command described in Appendix A or other similar commands, initiates the Request message to obtain routing path and cache information.
CCNINFOリクエストを開始するノード。これは、コンテンツの名前を使用してCCNINFOユーザープログラムを呼び出す消費者またはルーターのいずれかです。付録Aまたはその他の同様のコマンドで説明した「CCNINFO」コマンドなどのCCNINFOユーザープログラムは、ルーティングパスとキャッシュ情報を取得するための要求メッセージを開始します。
Incoming face:
着信顔：
The face on which data are expected to arrive from the specified name prefix.
データが指定された名前のプレフィックスから届くと予想される顔。
Outgoing face:
発信顔：
The face to which data from the publisher or router are expected to transmit for the specified name prefix. It is also the face on which the Request messages is received.
パブリッシャーまたはルーターからのデータが指定された名前のプレフィックスに対して送信されることが期待される顔。また、リクエストメッセージが受信される顔でもあります。
Upstream router:
上流のルーター：
The router that connects to an Incoming face of a router.
ルーターの着信面に接続するルーター。
Downstream router:
ダウンストリームルーター：
The router that connects to an Outgoing face of a router.
ルーターの発信面に接続するルーター。
First-hop router (FHR):
最初のホップルーター（FHR）：
The router that matches a FIB entry with an Outgoing face referring to a local application or a publisher.
FIBエントリと一致するルーターは、ローカルアプリケーションまたはパブリッシャーを指す発信顔と一致します。
Last-hop router (LHR):
ラストホップルーター（LHR）：
The router that is directly connected to a consumer.
消費者に直接接続されているルーター。
CCNinfo Request and Reply messages are encoded in the CCNx TLV format (see [RFC8609] and Figure 3). The Request message consists of a fixed header, Request block TLV (Figure 5), and Report block TLV(s) (Figure 7). The Reply message consists of a fixed header, Request block TLV, Report block TLV(s), Reply block TLV (Figure 9), and Reply sub-block TLV(s) (Figure 10).
CCNINFOリクエストと返信メッセージは、CCNX TLV形式でエンコードされています（[RFC8609]および図3を参照）。要求メッセージは、固定ヘッダー、要求ブロックTLV（図5）、およびブロックTLV（図7）で構成されています。返信メッセージは、固定ヘッダー、要求ブロックTLV、レポートブロックTLV（S）、応答ブロックTLV（図9）、および応答サブブロックTLV（図10）で構成されています。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Version | PacketType | PacketLength |
+---------------+---------------+---------------+---------------+
| PacketType specific fields | HeaderLength |
+---------------+---------------+---------------+---------------+
/ Optional Hop-by-hop header TLVs /
+---------------+---------------+---------------+---------------+
/ PacketPayload TLVs /
+---------------+---------------+---------------+---------------+
/ Optional CCNx ValidationAlgorithm TLV /
+---------------+---------------+---------------+---------------+
/ Optional CCNx ValidationPayload TLV (ValidationAlg required) /
+---------------+---------------+---------------+---------------+
Figure 3: Packet Format [RFC8609]
図3：パケット形式[RFC8609]
The PacketType values in the fixed header shown in Figure 3 are PT_CCNINFO_REQUEST and PT_CCNINFO_REPLY (see Table 1). CCNinfo Request and Reply messages are forwarded in a hop-by-hop manner. When the Request message reaches the content forwarder, the content forwarder turns it into a Reply message by changing the Type field value in the fixed header from PT_CCNINFO_REQUEST to PT_CCNINFO_REPLY and forwards it back toward the node that initiated the Request message.
図3に示す固定ヘッダーのpackettype値は、pt_ccninfo_requestとpt_ccninfo_replyです（表1を参照）。CCNINFOリクエストと返信メッセージは、ホップバイホップで転送されます。リクエストメッセージがコンテンツフォワーダーに到達すると、コンテンツフォワーダーは、PT_CCNINFO_REQUESTからPT_CCNINFO_REPLYに固定ヘッダーのタイプフィールド値を変更して、リクエストメッセージを開始したノードに戻します。
+======+=======================+
| Type | Name |
+======+=======================+
| 0x00 | PT_INTEREST [RFC8609] |
+------+-----------------------+
| 0x01 | PT_CONTENT [RFC8609] |
+------+-----------------------+
| 0x02 | PT_RETURN [RFC8609] |
+------+-----------------------+
| 0x03 | PT_CCNINFO_REQUEST |
+------+-----------------------+
| 0x04 | PT_CCNINFO_REPLY |
+------+-----------------------+
Table 1: CCNx Packet Types
表1：CCNXパケットタイプ
Following a fixed header, there can be a sequence of optional hop-by-hop header TLV(s) for a Request message. In the case of a Request message, it is followed by a sequence of Report blocks, each from a router on the path toward the publisher or caching router.
固定ヘッダーに続いて、リクエストメッセージのオプションのホップバイホップヘッダーTLVのシーケンスがあります。リクエストメッセージの場合、それぞれレポートブロックのシーケンスが続きます。それぞれが、それぞれ出版社またはキャッシュルーターに向かうパス上のルーターからです。
At the beginning of PacketPayload TLVs, a top-level TLV type, T_DISCOVERY (Table 2), exists at the outermost level of a CCNx protocol message. This TLV indicates that the Name segment TLV(s) and Reply block TLV(s) would follow in the Request or Reply message.
PacketPayload TLVの開始時には、トップレベルのTLVタイプであるT_Discovery（表2）がCCNXプロトコルメッセージの最も外側のレベルに存在します。このTLVは、名前セグメントTLV（s）およびReplyブロックTLV（s）がリクエストまたは返信メッセージに続くことを示しています。
+========+================================+
| Type | Name |
+========+================================+
| 0x0000 | Reserved [RFC8609] |
+--------+--------------------------------+
| 0x0001 | T_INTEREST [RFC8609] |
+--------+--------------------------------+
| 0x0002 | T_OBJECT [RFC8609] |
+--------+--------------------------------+
| 0x0003 | T_VALIDATION_ALG [RFC8609] |
+--------+--------------------------------+
| 0x0004 | T_VALIDATION_PAYLOAD [RFC8609] |
+--------+--------------------------------+
| 0x0005 | T_DISCOVERY |
+--------+--------------------------------+
Table 2: CCNx Top-Level Types
表2：CCNXトップレベルタイプ
When a CCNinfo user initiates a discovery request (e.g., via the ccninfo command described in Appendix A), a CCNinfo Request message is created and forwarded to its upstream router through the Incoming face(s) determined by its FIB.
CCNINFOユーザーがディスカバリーリクエストを開始すると（例：付録Aで説明するCCNINFOコマンドを介して）、CCNINFO要求メッセージが作成され、そのFIBによって決定された着信面を介して上流のルーターに転送されます。
The Request message format is shown in Figure 4. It consists of a fixed header, Request header block TLV (Figure 5), Report block TLV(s) (Figure 7), Name TLV, and Request block TLV. Request header block TLV and Report block TLV(s) are contained in the hop-by-hop header, as those might change from hop to hop. Request block TLV is encoded in the PacketPayload TLV by content forwarder as the protocol message itself. The PacketType value of the Request message is PT_CCNINFO_REQUEST (Table 1). The Type value of the CCNx Top-Level type is T_DISCOVERY (Table 2).
リクエストメッセージ形式を図4に示します。固定ヘッダー、要求ヘッダーブロックTLV（図5）、レポートブロックTLV（図7）、名前TLV、および要求ブロックTLVで構成されています。リクエストヘッダーブロックTLVとレポートブロックTLV（s）は、ホップからホップに変わる可能性があるため、ホップバイホップヘッダーに含まれています。リクエストブロックTLVは、プロトコルメッセージ自体としてコンテンツフォワーダーによってPacketPayload TLVにエンコードされます。リクエストメッセージのpackettype値はpt_ccninfo_requestです（表1）。CCNXトップレベルタイプのタイプ値はT_Discoveryです（表2）。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Version | PacketType | PacketLength |
+---------------+---------------+---------------+---------------+
| HopLimit | ReturnCode | Reserved(MBZ) | HeaderLength |
+===============+===============+===============+===============+
/ Request header block TLV /
+---------------+---------------+---------------+---------------+
/ Report block TLV 1 /
+---------------+---------------+---------------+---------------+
/ Report block TLV 2 /
+---------------+---------------+---------------+---------------+
/ . /
/ . /
+---------------+---------------+---------------+---------------+
/ Report block TLV n /
+===============+===============+===============+===============+
| Type (=T_DISCOVERY) | MessageLength |
+---------------+---------------+---------------+---------------+
| T_NAME | Length |
+---------------+---------------+---------------+---------------+
/ Name segment TLVs (name prefix specified by CCNinfo user) /
+---------------+---------------+---------------+---------------+
/ Request block TLV /
+---------------+---------------+---------------+---------------+
/ Optional CCNx ValidationAlgorithm TLV /
+---------------+---------------+---------------+---------------+
/ Optional CCNx ValidationPayload TLV (ValidationAlg required) /
+---------------+---------------+---------------+---------------+
Figure 4: Request Message
図4：メッセージを要求します
HopLimit:
hoplimit：
8 bits
8ビット
HopLimit is a counter that is decremented with each hop whenever a Request packet is forwarded. It is specified by the CCNinfo user program. The HopLimit value MUST be decremented by 1 prior to forwarding the Request packet. The packet is discarded if HopLimit is decremented to zero. HopLimit limits the distance that a Request may travel on the network. Only the specified number of hops from the CCNinfo user traces the Request. The last router stops the trace and sends the Reply message back to the CCNinfo user.
Hoplimitは、リクエストパケットが転送されるたびに各ホップで減少するカウンターです。CCNINFOユーザープログラムで指定されています。Request Packetを転送する前に、Hoplimit値を1で減少させる必要があります。hoplimitがゼロに減少した場合、パケットは破棄されます。Hoplimitは、要求がネットワーク上で移動する可能性のある距離を制限します。CCNINFOユーザーから指定されたホップ数のみがリクエストを追跡します。最後のルーターはトレースを停止し、返信メッセージをCCNINFOユーザーに送り返します。
ReturnCode:
ReturnCode：
8 bits
8ビット
ReturnCode is used for the Reply message. This value is replaced by the content forwarder when the Request message is returned as the Reply message (see Section 3.2). Until then, this field MUST be transmitted as zeros and ignored on receipt.
ReturnCodeは返信メッセージに使用されます。この値は、リクエストメッセージが返信メッセージとして返されると、コンテンツフォワーダーに置き換えられます（セクション3.2を参照）。それまでは、このフィールドはゼロとして送信され、受領時に無視されなければなりません。
+=======+=================+================================+
| Value | Name | Description |
+=======+=================+================================+
| 0x00 | NO_ERROR | No error |
+-------+-----------------+--------------------------------+
| 0x01 | WRONG_IF | CCNinfo Request arrived on an |
| | | interface to which this router |
| | | would not forward for the |
| | | specified name and/or function |
| | | toward the publisher. |
+-------+-----------------+--------------------------------+
| 0x02 | INVALID_REQUEST | Invalid CCNinfo Request is |
| | | received. |
+-------+-----------------+--------------------------------+
| 0x03 | NO_ROUTE | This router has no route for |
| | | the name prefix and no way to |
| | | determine a route. |
+-------+-----------------+--------------------------------+
| 0x04 | NO_INFO | This router has no cache |
| | | information for the specified |
| | | name prefix. |
+-------+-----------------+--------------------------------+
| 0x05 | NO_SPACE | There was not enough room to |
| | | insert another Report block in |
| | | the packet. |
+-------+-----------------+--------------------------------+
| 0x06 | INFO_HIDDEN | Information is hidden from |
| | | this discovery owing to some |
| | | policy. |
+-------+-----------------+--------------------------------+
| 0x0E | ADMIN_PROHIB | CCNinfo Request is |
| | | administratively prohibited. |
+-------+-----------------+--------------------------------+
| 0x0F | UNKNOWN_REQUEST | This router does not support |
| | | or recognize the Request |
| | | message. |
+-------+-----------------+--------------------------------+
| 0x80 | FATAL_ERROR | In a fatal error, the router |
| | | may know the upstream router |
| | | but cannot forward the message |
| | | to it. |
+-------+-----------------+--------------------------------+
Table 3: ReturnCode Used for the Reply Message
表3：返信メッセージに使用されるreturnCode
Reserved (MBZ):
予約済み（MBZ）：
8 bits
8ビット
The reserved fields in the Value field MUST be transmitted as zeros and ignored on receipt.
バリューフィールドの予約済みフィールドは、ゼロとして送信され、受領時に無視する必要があります。
When a CCNinfo user transmits the Request message, they MUST insert their Request header block TLV (Figure 5) into the hop-by-hop header and Request block TLV (Figure 6) into the message before sending it through the Incoming face(s).
CCNINFOユーザーがリクエストメッセージを送信する場合、リクエストヘッダーブロックTLV（図5）をホップバイホップヘッダーに挿入し、受信面から送信する前にメッセージにブロックTLV（図6）をリクエストする必要があります。。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Type (=T_DISC_REQHDR) | Length |
+---------------+---------------+-------+-------+-------+-+-+-+-+
| Request ID |SkipHop| Flags |V|F|O|C|
+---------------+---------------+-------+-------+-------+-+-+-+-+
Figure 5: Request Header Block TLV (Hop-by-Hop Header)
図5：ヘッダーブロックTLVをリクエストします（ホップバイホップヘッダー）
+===============+=======================+
| Type | Name |
+===============+=======================+
| 0x0000 | Reserved [RFC8609] |
+---------------+-----------------------+
| 0x0001 | T_INTLIFE [RFC8609] |
+---------------+-----------------------+
| 0x0002 | T_CACHETIME [RFC8609] |
+---------------+-----------------------+
| 0x0003 | T_MSGHASH [RFC8609] |
+---------------+-----------------------+
| 0x0004-0x0007 | Reserved [RFC8609] |
+---------------+-----------------------+
| 0x0008 | T_DISC_REQHDR |
+---------------+-----------------------+
| 0x0009 | T_DISC_REPORT |
+---------------+-----------------------+
| 0x0FFE | T_PAD [RFC8609] |
+---------------+-----------------------+
| 0x0FFF | T_ORG [RFC8609] |
+---------------+-----------------------+
| 0x1000-0x1FFF | Reserved [RFC8609] |
+---------------+-----------------------+
Table 4: CCNx Hop-by-Hop Types
表4：CCNXホップバイホップタイプ
Type:
タイプ：
16 bits
16ビット
Format of the Value field. The type value of the Request header block TLV MUST be T_DISC_REQHDR.
値フィールドの形式。リクエストヘッダーブロックTLVのタイプ値は、T_DISC_REQHDRでなければなりません。
Length:
長さ：
16 bits
16ビット
Length of the Value field in octets.
オクテットの値フィールドの長さ。
Request ID:
リクエストID：
16 bits
16ビット
This field is used as a unique identifier for the CCNinfo Request so that the duplicate or delayed Reply messages can be detected.
このフィールドは、CCNINFO要求の一意の識別子として使用されるため、複製または遅延の応答メッセージを検出できます。
SkipHop (Skip Hop Count):
Skiphop（スキップホップカウント）：
4 bits
4ビット
Number of skipped routers for a Request. It is specified by the CCNinfo user program. The number of routers corresponding to the value specified in this field are skipped, and the CCNinfo Request messages are forwarded to the next router without the addition of Report blocks; the next upstream router then starts the trace. The maximum value of this parameter is 15. This value MUST be lower than that of HopLimit at the fixed header.
リクエスト用のスキップルーターの数。CCNINFOユーザープログラムで指定されています。このフィールドで指定された値に対応するルーターの数はスキップされ、CCNINFO要求メッセージはレポートブロックを追加せずに次のルーターに転送されます。次のアップストリームルーターは、トレースを開始します。このパラメーターの最大値は15です。この値は、固定ヘッダーのhoplimitの値よりも低くする必要があります。
Flags:
フラグ：
12 bits
12ビット
The Flags field is used to indicate the types of the content or path discoveries. Currently, as shown in Table 5, four bits ("C", "O", "F", and "V") are assigned, and the other 8 bits are reserved (MBZ) for the future use. Each flag can be mutually specified with other flags. These flags are set by the CCNinfo user program when they initiate Requests (see Appendix A), and the routers that receive the Requests deal with the flags and change the behaviors (see Section 5 for details). The Flag values defined in this Flags field correspond to the Reply sub-blocks.
フラグフィールドは、コンテンツまたはパスの発見の種類を示すために使用されます。現在、表5に示すように、4ビット（ "c"、 "o"、 "f"、 "v"）が割り当てられ、他の8ビットは将来の使用のために予約されています（MBZ）。各フラグは、他のフラグで相互に指定できます。これらのフラグは、リクエストを開始するときにCCNINFOユーザープログラムによって設定され（付録Aを参照）、リクエストを受け取るルーターはフラグを扱い、動作を変更します（詳細についてはセクション5を参照）。このフラグフィールドで定義されているフラグ値は、応答サブブロックに対応しています。
+======+=======+=====================================+
| Flag | Value | Description |
+======+=======+=====================================+
| C | 0 | Path discovery (i.e., no cache |
| | | information retrieved) (default) |
+------+-------+-------------------------------------+
| C | 1 | Path and cache information |
| | | retrieval |
+------+-------+-------------------------------------+
| O | 0 | Request to any content forwarder |
| | | (default) |
+------+-------+-------------------------------------+
| O | 1 | Publisher discovery (i.e., only FHR |
| | | can reply) |
+------+-------+-------------------------------------+
| F | 0 | Request based on FIB's forwarding |
| | | strategy (default) |
+------+-------+-------------------------------------+
| F | 1 | Full discovery request. Request to |
| | | possible multiple upstream routers |
| | | specified in FIB simultaneously |
+------+-------+-------------------------------------+
| V | 0 | No reply validation (default) |
+------+-------+-------------------------------------+
| V | 1 | Reply sender validates Reply |
| | | message |
+------+-------+-------------------------------------+
Table 5: Codes and Types Specified in Flags Field
表5：フラグフィールドで指定されたコードとタイプ
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Type (=T_DISC_REQ) | Length |
+---------------+---------------+---------------+---------------+
| Request Arrival Time |
+---------------+---------------+---------------+---------------+
/ Node Identifier /
+---------------+---------------+---------------+---------------+
Figure 6: Request Block TLV (Packet Payload)
図6：要求ブロックTLV（パケットペイロード）
+===============+==========================+
| Type | Name |
+===============+==========================+
| 0x0000 | T_NAME [RFC8609] |
+---------------+--------------------------+
| 0x0001 | T_PAYLOAD [RFC8609] |
+---------------+--------------------------+
| 0x0002 | T_KEYIDRESTR [RFC8609] |
+---------------+--------------------------+
| 0x0003 | T_OBJHASHRESTR [RFC8609] |
+---------------+--------------------------+
| 0x0005 | T_PAYLDTYPE [RFC8609] |
+---------------+--------------------------+
| 0x0006 | T_EXPIRY [RFC8609] |
+---------------+--------------------------+
| 0x0007-0x000C | Reserved [RFC8609] |
+---------------+--------------------------+
| 0x000D | T_DISC_REQ |
+---------------+--------------------------+
| 0x000E | T_DISC_REPLY |
+---------------+--------------------------+
| 0x0FFE | T_PAD [RFC8609] |
+---------------+--------------------------+
| 0x0FFF | T_ORG [RFC8609] |
+---------------+--------------------------+
| 0x1000-0x1FFF | Reserved [RFC8609] |
+---------------+--------------------------+
Table 6: CCNx Message Types
表6：CCNXメッセージタイプ
Type:
タイプ：
16 bits
16ビット
Format of the Value field. For the Request block TLV, the type value(s) MUST be T_DISC_REQ (see Table 6) in the current specification.
値フィールドの形式。要求ブロックTLVの場合、現在の仕様のタイプ値はT_DISC_REQ（表6を参照）でなければなりません。
Length:
長さ：
16 bits
16ビット
Length of the Value field in octets.
オクテットの値フィールドの長さ。
Request Arrival Time:
到着時間をリクエスト：
32 bits
32ビット
The Request Arrival Time is a 32-bit NTP timestamp specifying the arrival time of the CCNinfo Request message at the router. The 32-bit form of an NTP timestamp consists of the middle 32 bits of the full 64-bit form, that is, the low 16 bits of the integer part and the high 16 bits of the fractional part.
リクエストの到着時間は、ルーターでのCCNINFO要求メッセージの到着時間を指定する32ビットNTPタイムスタンプです。NTPタイムスタンプの32ビット形式は、64ビットフルフォームの中央の32ビット、つまり整数部の16ビットと分数部分の16ビットで構成されています。
The following formula converts from a timespec (fractional part in nanoseconds) to a 32-bit NTP timestamp:
次のフォーミュラは、TimesPec（ナノ秒単位の分数部分）から32ビットNTPタイムスタンプに変換されます。
request_arrival_time
= ((tv.tv_sec + 32384) << 16) + ((tv.tv_nsec << 7) / 1953125)
The constant 32384 is the number of seconds from Jan 1, 1900 to Jan 1, 1970 truncated to 16 bits. ((tv.tv_nsec << 7) / 1953125) is a reduction of ((tv.tv_nsec / 1000000000) << 16), where "<<" denotes a logical left shift.
一定の32384は、1900年1月1日から1970年1月1日までの16ビットに切り捨てられた秒数です。（（tv.tv_nsec << 7） / 1953125）は（（tv.tv_nsec / 1000000000）<< 16）の削減です。ここで、「<<」は論理的な左シフトを示します。
Note that it is RECOMMENDED for all the routers on the path to have synchronized clocks to measure one-way latency per hop; however, even if they do not have synchronized clocks, CCNinfo measures the RTT between the content forwarder and the consumer.
パス上のすべてのルーターが、ホップあたりの一元配置レイテンシを測定するために同期したクロックを持つことが推奨されることに注意してください。ただし、たとえ時計が同期していなくても、CCNINFOはコンテンツフォワーダーと消費者の間でRTTを測定します。
Node Identifier:
ノード識別子：
variable length
可変長
This field specifies the node identifier (e.g., node name or hash-based self-certifying name [DCAuth]) or all-zeros if unknown. This document assumes that the Name TLV defined in the CCNx TLV format [RFC8609] can be used for this field and the node identifier is specified in it.
このフィールドは、ノード識別子（ノード名またはハッシュベースの自己認証名[dcauth]）または不明の場合は全ゼロを指定します。このドキュメントは、CCNX TLV形式[RFC8609]で定義されているTLVという名前がこのフィールドに使用できることを前提としており、ノード識別子が指定されています。
A CCNinfo user and each upstream router along the path would insert their own Report block TLV without changing the Type field of the fixed header of the Request message until one of these routers is ready to send a Reply. In the Report block TLV (Figure 7), the Request Arrival Time and Node Identifier values MUST be inserted.
パスに沿ったCCNINFOユーザーと各上流のルーターは、これらのルーターのいずれかが返信を送信するまで、リクエストメッセージの固定ヘッダーのタイプフィールドを変更せずに、独自のレポートブロックTLVを挿入します。レポートブロックTLV（図7）では、要求の到着時間とノード識別子値を挿入する必要があります。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Type (=T_DISC_REPORT) | Length |
+---------------+---------------+---------------+---------------+
| Request Arrival Time |
+---------------+---------------+---------------+---------------+
/ Node Identifier /
+---------------+---------------+---------------+---------------+
Figure 7: Report Block TLV (Hop-by-Hop Header)
図7：レポートブロックTLV（ホップバイホップヘッダー）
Type:
タイプ：
16 bits
16ビット
Format of the Value field. For the Report block TLV, the type value(s) MUST be T_DISC_REPORT in the current specification. For all the available types of the CCNx hop-by-hop types, please see Table 4.
値フィールドの形式。レポートブロックTLVの場合、タイプ値は現在の仕様のT_DISC_REPORTでなければなりません。利用可能なすべてのタイプのCCNXホップバイホップタイプについては、表4を参照してください。
Length:
長さ：
16 bits
16ビット
Length of the Value field in octets.
オクテットの値フィールドの長さ。
Request Arrival Time:
到着時間をリクエスト：
32 bits
32ビット
Same definition as given in Section 3.1.1.
セクション3.1.1で与えられたのと同じ定義。
Node Identifier:
ノード識別子：
variable length
可変長
Same definition as given in Section 3.1.1.
セクション3.1.1で与えられたのと同じ定義。
Specifications of the Name TLV (whose type value is T_NAME) and the Name Segment TLVs are described in [RFC8609], which is followed by CCNinfo. CCNinfo enables the specification of the content name with either a prefix name without chunk number (such as "ccnx:/news/ today") or an exact name (such as "ccnx:/news/today/Chunk=10"). When a CCNinfo user specifies a prefix name, they will obtain the summary information of the matched Content Objects in the content forwarder. In contrast, when a CCNinfo user specifies an exact name, they will obtain information only about the specified Content Object in the content forwarder. A CCNinfo Request message MUST NOT be sent only with a scheme name, ccnx:/. It will be rejected and discarded by routers.
TLVという名前（タイプ値はT_NAME）と名前セグメントTLVの仕様は[RFC8609]で説明されており、CCNINFOが続きます。CCNINFOは、チャンク番号のないプレフィックス名（「ccnx：/news/today」など）または正確な名前（「ccnx：/news/today/today/chunk = 10」など）でコンテンツ名の指定を有効にします。CCNINFOユーザーがプレフィックス名を指定すると、コンテンツフォワーダーの一致したコンテンツオブジェクトの要約情報を取得します。対照的に、CCNINFOユーザーが正確な名前を指定すると、コンテンツフォワーダー内の指定されたコンテンツオブジェクトに関する情報のみが取得されます。ccninfo要求メッセージは、スキーム名ccnx：/でのみ送信してはなりません。ルーターによって拒否され、廃棄されます。
When a content forwarder receives a CCNinfo Request message from an appropriate adjacent neighbor router, it inserts its own Reply block TLV and Reply sub-block TLV(s) to the Request message and turns the Request into the Reply by changing the Type field of the fixed header of the Request message from PT_CCNINFO_REQUEST to PT_CCNINFO_REPLY. The Reply message (see Figure 8) is then forwarded back toward the CCNinfo user in a hop-by-hop manner.
コンテンツフォワーダーが適切な隣接する近隣ルーターからCCNINFO要求メッセージを受信すると、独自の返信ブロックTLVを挿入し、サブブロックTLV（s）にリクエストメッセージに返信し、リクエストをリクエストに変換して返信に変えます。pt_ccninfo_requestからpt_ccninfo_replyにリクエストメッセージのヘッダーを固定しました。返信メッセージ（図8を参照）は、ホップバイホップでCCNINFOユーザーに転送されます。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Version | PacketType | PacketLength |
+---------------+---------------+-------------+-+---------------+
| HopLimit | ReturnCode | Reserved(MBZ) | HeaderLength |
+===============+===============+=============+=+===============+
/ Request header block TLV /
+---------------+---------------+---------------+---------------+
/ . /
/ . /
/ n Report block TLVs /
/ . /
/ . /
+===============+===============+===============+===============+
| Type (=T_DISCOVERY) | MessageLength |
+---------------+---------------+---------------+---------------+
| T_NAME | Length |
+---------------+---------------+---------------+---------------+
/ Name segment TLVs (name prefix specified by CCNinfo user) /
+---------------+---------------+---------------+---------------+
/ Request block TLV /
+---------------+---------------+---------------+---------------+
/ Reply block TLV /
+---------------+---------------+---------------+---------------+
/ Reply sub-block TLV 1 /
+---------------+---------------+---------------+---------------+
/ . /
/ . /
+---------------+---------------+---------------+---------------+
/ Reply sub-block TLV k /
+---------------+---------------+---------------+---------------+
/ Optional CCNx ValidationAlgorithm TLV /
+---------------+---------------+---------------+---------------+
/ Optional CCNx ValidationPayload TLV (ValidationAlg required) /
+---------------+---------------+---------------+---------------+
Figure 8: Reply Message
図8：返信メッセージ
The Reply block TLV is an envelope for the Reply sub-block TLV(s) (explained in the next section).
Reply Block TLVは、応答サブブロックTLV（S）の封筒です（次のセクションで説明しています）。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Type (=T_DISC_REPLY) | Length |
+---------------+---------------+---------------+---------------+
| Request Arrival Time |
+---------------+---------------+---------------+---------------+
/ Node Identifier /
+---------------+---------------+---------------+---------------+
Figure 9: Reply Block TLV (Packet Payload)
図9：返信ブロックTLV（パケットペイロード）
Type:
タイプ：
16 bits
16ビット
Format of the Value field. For the Reply block TLV, the type value MUST be T_DISC_REPLY shown in Table 6 in the current specification.
値フィールドの形式。ReplyブロックTLVの場合、型値は現在の仕様の表6にT_DISC_REPLYに示す必要があります。
Length:
長さ：
16 bits
16ビット
Length of the Value field in octets. This length is the total length of the Reply sub-block(s).
オクテットの値フィールドの長さ。この長さは、応答サブブロックの全長です。
Request Arrival Time:
到着時間をリクエスト：
32 bits
32ビット
Same definition as given in Section 3.1.1.
セクション3.1.1で与えられたのと同じ定義。
Node Identifier:
ノード識別子：
variable length
可変長
Same definition as given in Section 3.1.1.
セクション3.1.1で与えられたのと同じ定義。
The router on the traced path will add one or multiple Reply sub-blocks followed by the Reply block TLV before sending the Reply to its neighbor router. This section describes the Reply sub-block TLV for informing various cache states and conditions as shown in Figure 10. (Other Reply sub-block TLVs will be discussed in separate document(s).)
トレースされたパス上のルーターは、1つまたは複数の応答サブブロックを追加し、その後、隣のルーターに返信を送信する前にReplyブロックTLVが続きます。このセクションでは、図10に示すように、さまざまなキャッシュ状態と条件を通知するための応答サブブロックTLVについて説明します（その他の応答サブブロックTLVについては、個別のドキュメントで説明します）。
Note that some routers may not be capable of reporting the following values: Object Size, Object Count, # Received Interest, First Seqnum, Last Seqnum, Elapsed Cache Time, and Remain Cache Lifetime (shown in Figure 10). Or, some routers do not report these values due to their policy. In that case, the routers MUST set these fields to a value of all ones (i.e., 0xFFFFFFFF). The value of each field MUST be also all-one when the value is equal to or bigger than the maximum size expressed by the 32-bit field. The CCNinfo user program MUST inform that these values are not valid if the fields received are set to the value of all ones.
一部のルーターは、オブジェクトサイズ、オブジェクトカウント、＃受信率、最初のseqnum、最後のseqnum、経過キャッシュ時間、およびキャッシュ寿命のままです（図10を参照）のままです。または、一部のルーターは、ポリシーのためにこれらの値を報告しません。その場合、ルーターはこれらのフィールドをすべてのフィールド（つまり、0xffffffff）の値に設定する必要があります。各フィールドの値は、値が32ビットフィールドで表される最大サイズと等しく、または大きい場合にもすべてでなければなりません。CCNINFOユーザープログラムは、受信したフィールドがすべての値に設定されている場合、これらの値が有効ではないことを通知する必要があります。
If the cache is refreshed after reboot, the value in each field MUST be refreshed (i.e., MUST be set to 0). If the cache remains after reboot, the value MUST NOT be refreshed (i.e., MUST be reflected as it is).
再起動後にキャッシュが更新された場合、各フィールドの値を更新する必要があります（つまり、0に設定する必要があります）。再起動後にキャッシュが残っている場合、値を更新する必要はありません（つまり、そのまま反映する必要があります）。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Type | Length |
+---------------+---------------+---------------+---------------+
| Object Size |
+---------------+---------------+---------------+---------------+
| Object Count |
+---------------+---------------+---------------+---------------+
| # Received Interest |
+---------------+---------------+---------------+---------------+
| First Seqnum |
+---------------+---------------+---------------+---------------+
| Last Seqnum |
+---------------+---------------+---------------+---------------+
| Elapsed Cache Time |
+---------------+---------------+---------------+---------------+
| Remain Cache Lifetime |
+---------------+---------------+---------------+---------------+
| T_NAME | Length |
+---------------+---------------+---------------+---------------+
/ Name Segment TLVs /
+---------------+---------------+---------------+---------------+
Figure 10: Reply Sub-Block TLV for T_DISC_CONTENT and T_DISC_CONTENT_PUBLISHER (Packet Payload)
図10：T_DISC_CONTENTおよびT_DISC_CONTENT_PUBLISHER（パケットペイロード）のサブブロックTLVに返信
+===============+===============================+
| Type | Name |
+===============+===============================+
| 0x0000 | T_DISC_CONTENT |
+---------------+-------------------------------+
| 0x0001 | T_DISC_CONTENT_PUBLISHER |
+---------------+-------------------------------+
| 0x0FFF | T_ORG |
+---------------+-------------------------------+
| 0x1000-0x1FFF | Reserved for Experimental Use |
+---------------+-------------------------------+
Table 7: CCNx Reply Types
表7：CCNX応答タイプ
Type:
タイプ：
16 bits
16ビット
Format of the Value field. For the Reply sub-block TLV, the type value MUST be either T_DISC_CONTENT or T_DISC_CONTENT_PUBLISHER defined in the CCNx Reply Types (Table 7). T_DISC_CONTENT is specified when a content forwarder replies with the cache information. T_DISC_CONTENT_PUBLISHER is specified when a FHR attached to a publisher replies with the original content information.
値フィールドの形式。応答のサブブロックTLVの場合、タイプ値はCCNX応答タイプで定義されているT_DISC_CONTENTまたはT_DISC_CONTENT_PUBLISHERでなければなりません（表7）。T_DISC_CONTENTは、コンテンツの転送者がキャッシュ情報を返信するときに指定されます。T_DISC_CONTENT_PUBLISHERは、パブリッシャーに接続されたFHRが元のコンテンツ情報を返信するときに指定されます。
Length:
長さ：
16 bits
16ビット
Length of the Value field in octets.
オクテットの値フィールドの長さ。
Object Size:
オブジェクトサイズ：
32 bits
32ビット
The total size (KB) of the unexpired Content Objects. Values less than 1 KB are truncated. Note that the maximum size expressed by the 32-bit field is approximately 4.29 TB.
期限切れのないコンテンツオブジェクトの合計サイズ（KB）。1 kb未満の値は切り捨てられます。32ビットフィールドで表される最大サイズは約4.29 Tbであることに注意してください。
Object Count:
オブジェクトカウント：
32 bits
32ビット
The number of the unexpired Content Objects. Note that the maximum count expressed by the 32-bit field is approximately 4.29 billion.
期限切れのないコンテンツオブジェクトの数。32ビットフィールドで表される最大カウントは約429億であることに注意してください。
# Received Interest:
＃受け取った利息：
32 bits
32ビット
The total number of the received Interest messages to retrieve the cached Content Objects.
キャッシュされたコンテンツオブジェクトを取得するための受信した関心メッセージの総数。
First Seqnum:
最初のseqnum：
32 bits
32ビット
The first sequential number of the unexpired Content Objects.
期限切れのないコンテンツオブジェクトの最初のシーケンシャル番号。
Last Seqnum:
最後のseqnum：
32 bits
32ビット
The last sequential number of the unexpired Content Objects. The First Seqnum and Last Seqnum do not guarantee the consecutiveness of the cached Content Objects; however, knowing these values may help in the analysis of consecutive or discontinuous chunks such as [CONSEC-CACHING].
期限切れのないコンテンツオブジェクトの最後のシーケンシャル番号。最初のSeqnumと最後のSeqnumは、キャッシュされたコンテンツオブジェクトの連続性を保証するものではありません。ただし、これらの値を知ることは、[consecキャッシュ]などの連続したまたは不連続なチャンクの分析に役立つ可能性があります。
Elapsed Cache Time:
経過キャッシュ時間：
32 bits
32ビット
The elapsed time (seconds) after the oldest Content Object of the content is cached.
コンテンツの最も古いコンテンツオブジェクトの後の経過時間（秒）がキャッシュされます。
Remain Cache Lifetime:
キャッシュの寿命のまま：
32 bits
32ビット
The lifetime (seconds) of a Content Object, which is lastly cached.
最後にキャッシュされたコンテンツオブジェクトの寿命（秒）。
A CCNinfo user invokes a CCNinfo user program (e.g., ccninfo command) that initiates a CCNinfo Request message and sends it to the user's adjacent neighbor router(s) of interest. The user later obtains both the routing path information and in-network cache information in the single Reply.
CCNINFOユーザープログラム（例：CCNINFOコマンド）を呼び出して、CCNINFO要求メッセージを開始し、ユーザーの隣接するNeighborルーターに送信します。ユーザーは後で、単一の返信でルーティングパス情報とネットワーク内のキャッシュ情報の両方を取得します。
When the CCNinfo user program initiates a Request message, it MUST insert the necessary values, i.e., the "Request ID" and the "Node Identifier", in the Request block. The Request ID MUST be unique for the CCNinfo user until they receive the corresponding Reply message(s) or the Request is timed out.
CCNINFOユーザープログラムがリクエストメッセージを開始する場合、必要な値、つまり「リクエストID」と「ノード識別子」を要求ブロックに挿入する必要があります。リクエストIDは、CCNINFOユーザーが対応する返信メッセージを受信するか、リクエストがタイムアウトするまで一意でなければなりません。
Owing to some policies, a router may want to validate the CCNinfo Requests using the CCNx ValidationPayload TLV (whether it accepts the Request or not) especially when the router receives the "full discovery request" (see Section 5.3.2). Accordingly, the CCNinfo user program MAY require validating the Request message and appending the user's signature into the CCNx ValidationPayload TLV. The router then forwards the Request message. If the router does not approve the Request, it rejects the Request message as described in Section 6.11.
一部のポリシーにより、ルーターは、特にルーターが「完全な発見リクエスト」を受信した場合に、CCNX ValidationPayload TLV（リクエストを受け入れるかどうかにかかわらず）を使用してCCNINFO要求を検証したい場合があります（セクション5.3.2を参照）。したがって、CCNINFOユーザープログラムは、リクエストメッセージを検証し、ユーザーの署名をCCNX ValidationPayload TLVに追加する必要がある場合があります。次に、ルーターがリクエストメッセージを転送します。ルーターがリクエストを承認しない場合、セクション6.11で説明されているようにリクエストメッセージを拒否します。
After the CCNinfo user program sends the Request message, until the Reply is timed out or the expected numbers of Replies or a Reply message with a non-zero ReturnCode in the fixed header is received, the CCNinfo user program MUST keep the following information: HopLimit (specified in the fixed header), Request ID and Flags (specified in the Request header block), and Node Identifier and Request Arrival Time (specified in the Request block).
CCNINFOユーザープログラムがリクエストメッセージを送信した後、回答がタイムアウトされるか、予想される返信数または固定ヘッダーにゼロ以外の返信コードを含む返信メッセージを受信した後、CCNINFOユーザープログラムは次の情報を保持する必要があります：Hoplimit（固定ヘッダーで指定）、リクエストIDとフラグ（リクエストヘッダーブロックで指定）、およびノード識別子とリクエストの到着時間（リクエストブロックで指定）。
A CCNinfo user can send a CCNinfo Request for investigating the routing path information for the specified named content. Using the Request, a legitimate user can obtain 1) the node identifiers of the intermediate routers, 2) the node identifier of the content forwarder, 3) the number of hops between the content forwarder and the consumer, and 4) the RTT between the content forwarder and the consumer, per name prefix. This CCNinfo Request is terminated when it reaches the content forwarder.
CCNINFOユーザーは、指定された名前のコンテンツのルーティングパス情報を調査するためのCCNINFOリクエストを送信できます。リクエストを使用して、正当なユーザーは1）中間ルーターのノード識別子、2）コンテンツフォワーダーのノード識別子、3）コンテンツフォワーダーと消費者の間のホップ数、および4）4）コンテンツフォワーダーと消費者、名前ごとのプレフィックス。このCCNINFO要求は、コンテンツフォワーダーに到達すると終了します。
A CCNinfo user can send a CCNinfo Request for investigating in-network cache information. Using the Request, a legitimate user can obtain 1) the size of cached Content Objects, 2) the number of cached Content Objects, 3) the number of accesses (i.e., received Interests) per content, and 4) the lifetime and expiration time of the cached Content Objects, for Content Store (CS) in the content forwarder, unless the content forwarder is capable of reporting them (see Section 3.2.1.1). This CCNinfo Request is terminated when it reaches the content forwarder.
CCNINFOユーザーは、ネットワーク内のキャッシュ情報を調査するためのCCNINFOリクエストを送信できます。リクエストを使用して、正当なユーザーは1）キャッシュされたコンテンツオブジェクトのサイズ、2）キャッシュされたコンテンツオブジェクトの数、3）コンテンツあたりのアクセスの数（つまり、受信した利息）、4）寿命と有効期限の時間を取得できます。コンテンツフォワーダーのコンテンツストア（CS）用のキャッシュされたコンテンツオブジェクトのうち、コンテンツフォワーダーがそれらを報告できない限り（セクション3.2.1.1を参照）。このCCNINFO要求は、コンテンツフォワーダーに到達すると終了します。
A CCNinfo user program will receive one or multiple CCNinfo Reply messages from the adjacent neighbor router(s). When the program receives the Reply, it MUST compare the kept Request ID and Node Identifier values to identify the Request and Reply pair. If they do not match, the Reply message MUST be silently discarded.
CCNINFOユーザープログラムは、隣接する近隣ルーターから1つまたは複数のCCNINFO返信メッセージを受け取ります。プログラムが返信を受信したら、リクエストと応答のペアを識別するために、Keep Request IDとNode Identifierの値を比較する必要があります。それらが一致しない場合、返信メッセージは静かに破棄する必要があります。
If the number of Report blocks in the received Reply is more than the initial HopLimit value (which was inserted in the original Request), the Reply MUST be silently ignored.
受信した返信のレポートブロックの数が最初のHoplimit値（元のリクエストに挿入された）を超えている場合、返信は静かに無視する必要があります。
After the CCNinfo user has determined that they have traced the whole path or the maximum path that they can be expected to, they might collect statistics by waiting for a timeout. Useful statistics provided by CCNinfo are stated in Section 8.
CCNINFOユーザーが、予想されるパス全体または最大パスをたどったと判断した後、タイムアウトを待つことで統計を収集する可能性があります。CCNINFOが提供する有用な統計については、セクション8に記載されています。
Upon receiving a CCNinfo Request message, a router MAY examine whether a valid CCNinfo user has sent the message. If the router recognizes that the Request sender's signature specified in the Request is invalid, it SHOULD terminate the Request, as defined in Section 6.4.
CCNINFO要求メッセージを受信すると、ルーターは有効なCCNINFOユーザーがメッセージを送信したかどうかを調べることができます。ルーターが、リクエストで指定されたリクエスト送信者の署名が無効であることを認識している場合、セクション6.4で定義されているように、リクエストを終了する必要があります。
Upon receiving a CCNinfo Request or Reply message, a router MAY examine whether the message comes from a valid adjacent neighbor node. If the router recognizes that the Request or Reply sender is invalid, it SHOULD silently ignore the message, as specified in Section 10.9.
CCNINFOリクエストまたは返信メッセージを受信すると、ルーターは、メッセージが有効な隣接する近隣ノードから来るかどうかを調べることができます。ルーターがリクエストまたは返信送信者が無効であることを認識している場合、セクション10.9で指定されているように、メッセージを静かに無視する必要があります。
After a router accepts the CCNinfo Request message, it performs the following steps.
ルーターがCCNINFO要求メッセージを受け入れると、次の手順を実行します。
1. The value of "HopLimit" in the fixed header and the value of "SkipHop (Skip Hop Count)" in the Request block are counters that are decremented with each hop. If the HopLimit value is zero, the router terminates the Request, as defined in Section 6.5. If the SkipHop value is equal to or more than the HopLimit value, the router terminates the Request, as defined in Section 6.4; otherwise, until the SkipHop value becomes zero, the router forwards the Request message to the upstream router(s) without adding its own Report block and without replying to the Request. If the router does not know the upstream router(s) regarding the specified name prefix, it terminates the Request, as defined in Section 6.5. It should be noted that the Request messages are terminated at the FHR; therefore, although the maximum value for the HopLimit is 255 and that for SkipHop is 15, if the Request messages reach the FHR before the HopLimit or SkipHop value becomes 0, the FHR silently discards the Request message and the Request is timed out.
1. 固定ヘッダーの「hoplimit」の値とリクエストブロックの「スキップホップ（スキップホップカウント）」の値は、各ホップで減少するカウンターです。hoplimit値がゼロの場合、セクション6.5で定義されているように、ルーターはリクエストを終了します。Skiphop値がHoplimit値を超えている場合、またはそれ以上の場合、セクション6.4で定義されているように、ルーターはリクエストを終了します。それ以外の場合、スキップホップ値がゼロになるまで、ルーターはリクエストメッセージをアップストリームルーターに転送します。独自のレポートブロックを追加せず、リクエストに返信することなく。ルーターが指定された名前のプレフィックスに関する上流のルーターを知らない場合、セクション6.5で定義されているように、要求を終了します。要求メッセージはFHRで終了することに注意する必要があります。したがって、Hoplimitの最大値は255であり、Skiphopの最大値は15ですが、リクエストメッセージがHoplimitまたはSkiphop値が0になる前にFHRに到達した場合、FHRはリクエストメッセージを静かに破棄し、リクエストがタイミングを出します。
2. The router examines the Flags field (specified in Table 5) in the Request block of the received CCNinfo Request. If the "C" flag is not set, it is categorized as the "routing path information discovery". If the "C" flag is set, it is the "cache information discovery". If the "O" flag is set, it is the "publisher discovery".
2. ルーターは、受信したCCNINFO要求の要求ブロックでフラグフィールド（表5に指定）を調べます。「C」フラグが設定されていない場合、「ルーティングパス情報発見」に分類されます。「C」フラグが設定されている場合、それは「キャッシュ情報発見」です。「O」フラグが設定されている場合、それは「出版社の発見」です。
3. If the Request is either "cache information discovery" or "routing path information discovery", the router examines its FIB and CS. If the router caches the specified content, it sends the Reply message with its own Reply block and sub-block(s). If the router cannot insert its own Reply block or sub-block(s) because of no space, it terminates the Request, as specified in Section 6.7. If the router does not cache the specified content but knows the upstream neighbor router(s) for the specified name prefix, it creates the PIT entry, inserts its own Report block in the hop-by-hop header, and forwards the Request to the upstream neighbor(s). If the router cannot insert its own Report block because of no space, or if the router does not cache the specified content and does not know the upstream neighbor router(s) for the specified name prefix, it terminates the Request, as defined in Section 6.5.
3. 要求が「キャッシュ情報発見」または「ルーティングパス情報発見」のいずれかである場合、ルーターはそのFIBとCSを調べます。ルーターが指定されたコンテンツをキャッシュする場合、独自の返信ブロックとサブブロックで返信メッセージを送信します。ルーターがスペースがないために独自の返信ブロックまたはサブブロックを挿入できない場合、セクション6.7で指定されているように、リクエストを終了します。ルーターが指定されたコンテンツをキャッシュしないが、指定された名前プレフィックスの上流の近隣ルーターを知っている場合、ピットエントリを作成し、ホップバイホップヘッダーに独自のレポートブロックを挿入し、リクエストをリクエストを転送します上流の隣人。ルーターがスペースがないために独自のレポートブロックを挿入できない場合、またはルーターが指定されたコンテンツをキャッシュせず、指定された名前プレフィックスの上流の近隣ルーターを知らない場合、セクションで定義されているように、リクエストを終了します。6.5。
4. If the Request is the "publisher discovery", the router examines whether it is the FHR for the requested content. If the router is the FHR, it sends the Reply message with its own Report block and sub-blocks (in the case of cache information discovery) or the Reply message with its own Report block without adding any Reply sub-blocks (in the case of routing path information discovery). If the router is not the FHR but knows the upstream neighbor router(s) for the specified name prefix, it creates the PIT entry, inserts its own Report block, and forwards the Request to the upstream neighbor(s). If the router cannot insert its own Report block in the hop-by-hop header because of no space, it terminates the Request, as specified in Section 6.7. If the router is not the FHR and does not know the upstream neighbor router(s) for the specified name prefix, it terminates the Request, as defined in Section 6.5. Note that in Cefore [Cefore-site], there is an API by which a publisher informs the application prefix to the FHR, and the FHR registers it into the FIB. The prefix entry then can be statically configured on other routers or announced by a routing protocol.
4. リクエストが「パブリッシャーディスカバリー」である場合、ルーターは要求されたコンテンツのFHRであるかどうかを調べます。ルーターがFHRの場合、それは独自のレポートブロックとサブブロック（キャッシュ情報発見の場合）で返信メッセージを送信します。または、応答サブブロックを追加せずに独自のレポートブロックを使用した返信メッセージ（ケースではケースではルーティングパス情報発見の）。ルーターがFHRではないが、指定された名前プレフィックスの上流の近隣ルーターを知っている場合、ピットエントリを作成し、独自のレポートブロックを挿入し、リクエストをアップストリームネイバーに転送します。ルーターがスペースがないためホップバイホップヘッダーに独自のレポートブロックを挿入できない場合、セクション6.7で指定されているように、リクエストを終了します。ルーターがFHRではなく、指定された名前プレフィックスの上流の近隣ルーターがわからない場合、セクション6.5で定義されているように、要求を終了します。Cefore [cefore-site]には、パブリッシャーがアプリケーションのプレフィックスをFHRに通知し、FHRがFIBに登録するAPIがあることに注意してください。プレフィックスエントリは、他のルーターで静的に構成したり、ルーティングプロトコルで発表したりできます。
When a router decides to forward a Request message with its Report block to its upstream router(s), it specifies the Request Arrival Time and Node Identifier values in the Report block of the Request message. The router then forwards the Request message upstream toward the publisher or caching router based on the FIB entry like the ordinary Interest-Data exchanges in CCN.
ルーターがレポートブロックを使用してリクエストメッセージをアップストリームルーターに転送することを決定した場合、リクエストメッセージのレポートブロックにリクエスト到着時間とノード識別子値を指定します。次に、ルーターは、CCNの通常の利息DATA取引所のようなFIBエントリに基づいて、パブリッシャーまたはキャッシュルーターに上流のリクエストメッセージを転送します。
When the router forwards the Request message, it MUST record the F flag and Request ID in the Request block of the Request message and exploiting path labels (specified in Section 1) at the corresponding PIT entry. The router can later check the PIT entry to correctly forward the Reply message(s) back.
ルーターがリクエストメッセージを転送する場合、リクエストメッセージのリクエストブロックにFフラグとリクエストIDを記録し、対応するピットエントリでパスラベル（セクション1で指定）を悪用する必要があります。ルーターは後でピットエントリをチェックして、返信メッセージを正しく転送することができます。
CCNinfo supports multipath forwarding. The Request messages can be forwarded to multiple neighbor routers. Some routers may have a strategy for multipath forwarding; when a router sends Interest messages to multiple neighbor routers, it may delay or prioritize to send the message to the upstream routers. The CCNinfo Request, as the default, complies with such strategies; a CCNinfo user could trace the actual forwarding path based on the forwarding strategy and will receive a single Reply message such as a Content Object.
CCNINFOはマルチパス転送をサポートしています。リクエストメッセージは、複数の隣接ルーターに転送できます。一部のルーターには、マルチパス転送の戦略がある場合があります。ルーターが複数のネイバールーターに興味のメッセージを送信すると、上流のルーターにメッセージを送信するために遅延または優先順位付けされる場合があります。CCNINFO要求は、デフォルトとして、そのような戦略に準拠しています。CCNINFOユーザーは、転送戦略に基づいて実際の転送パスをトレースでき、コンテンツオブジェクトなどの単一の返信メッセージを受信できます。
There may be a case wherein a CCNinfo user wants to discover all possible forwarding paths and content forwarders based on the routers' FIBs. The "full discovery request" enables this functionality. If a CCNinfo user sets the F flag in the Request block of the Request message (as seen in Table 5) to request the full discovery, the upstream routers simultaneously forward the Requests to all multiple upstream routers based on the FIBs. Then, the CCNinfo user can trace all possible forwarding paths. As seen in Figure 11, each router forwards the Reply message along its PIT entry, and finally, the CCNinfo user receives two Reply messages: one from the FHR (Router C) and the other from the Caching router.
CCNINFOユーザーが、ルーターのFIBに基づいて、可能なすべての転送パスとコンテンツフォワーダーを発見したい場合がある場合があります。「完全なディスカバリーリクエスト」は、この機能を有効にします。CCNINFOユーザーが要求メッセージのリクエストブロックにFフラグを設定し（表5を参照）、完全な発見を要求する場合、上流のルーターはFIBSに基づいてすべての複数の上流ルーターにリクエストを同時に転送します。次に、CCNINFOユーザーは、可能なすべての転送パスをトレースできます。図11に示すように、各ルーターはそのピットエントリに沿って返信メッセージを転送し、最後に、CCNINFOユーザーは2つの応答メッセージを受信します。1つはFHR（ルーターC）から、もう1つはキャッシュルーターからです。
3. Reply(C) 2. Reply(C)
3. Reply(P) 2. Reply(P) 1. Reply(P)
+----+ +----+ +----+
| | | | | |
v | v | v |
+--------+ +--------+ +--------+ +--------+ +---------+
| CCNinfo|----| Router |----| Router |----| Router |----|Publisher|
| user | | A | | B | | C | | |
+--------+ +--------+ +--------+ +--------+ +---------+
^
\ +-------+
1. Reply(C) \ | Cache |
\ +---------+ |
\| Caching |----+
| router |
+---------+
Figure 11: Full Discovery Request: Reply Messages Forwarded by the Publisher and Routers
図11：完全なディスカバリーリクエスト：出版社とルーターによって転送された返信メッセージ
To receive different Reply messages forwarded from different routers, the PIT entries initiated by CCNinfo remain until the configured CCNinfo Reply Timeout (Section 7.1) is expired. In other words, unlike the ordinary Interest-Data exchanges in CCN, if routers that accept the full discovery request receive the full discovery request, the routers SHOULD NOT remove the PIT entry created by the full discovery request until the CCNinfo Reply Timeout value expires.
異なるルーターから転送された異なる返信メッセージを受信するために、CCNINFOによって開始されたPITエントリは、構成されたCCNINFO応答タイムアウト（セクション7.1）が期限切れになるまで残ります。言い換えれば、CCNの通常の利息DATA交換とは異なり、完全なディスカバリーリクエストを受け入れるルーターが完全なディスカバリーリクエストを受信した場合、ルーターはCCNINFO応答タイムアウト値が切れるまで完全なディスカバリーリクエストによって作成されたピットエントリを削除してはなりません。
Note that the full discovery request is an OPTIONAL implementation of CCNinfo; it may not be implemented on routers. Even if it is implemented on a router, it may not accept the full discovery request from non-validated CCNinfo users or routers or because of its policy. If a router does not accept the full discovery request, it rejects the full discovery request as described in Section 6.11. Routers that enable the full discovery request MAY rate-limit Replies, as described in Section 10.8 as well.
完全なディスカバリーリクエストは、CCNINFOのオプションの実装であることに注意してください。ルーターに実装されていない場合があります。ルーターに実装されていても、検証されていないCCNINFOユーザーまたはルーターからの完全な発見要求を受け入れない場合があります。ルーターが完全なディスカバリーリクエストを受け入れない場合、セクション6.11で説明されているように、完全なディスカバリーリクエストを拒否します。セクション10.8で説明されているように、完全なディスカバリーリクエストを有効にするルーターもレートリミット応答を行うことができます。
If there is a caching router or FHR for the specified content within the specified hop count along the path, the caching router or FHR sends back the Reply message toward the CCNinfo user and terminates the Request.
パスに沿った指定されたホップカウント内の指定されたコンテンツにキャッシュルーターまたはFHRがある場合、キャッシュルーターまたはFHRは、CCNINFOユーザーに応答メッセージを送り返し、リクエストを終了します。
When a router decides to send a Reply message to its downstream neighbor router or the CCNinfo user with a NO_ERROR return code, it inserts a Report block with the Request Arrival Time and Node Identifier values to the Request message. Then, the router inserts the corresponding Reply sub-block(s) (Figure 10) to the payload. The router finally changes the Type field in the fixed header from PT_CCNINFO_REQUEST to PT_CCNINFO_REPLY and forwards the message back as the Reply toward the CCNinfo user in a hop-by-hop manner.
ルーターがダウンストリームネイバールーターまたはNO_ERRORリターンコードを使用してCCNINFOユーザーに返信メッセージを送信することを決定した場合、リクエスト到着時刻とノード識別子値を要求に伴うレポートブロックをリクエストメッセージに挿入します。次に、ルーターは、対応する応答サブブロック（図10）をペイロードに挿入します。ルーターは最後に、PT_CCNINFO_REQUESTからPT_CCNINFO_REPLYに固定ヘッダーのタイプフィールドを変更し、CCNINFOユーザーへの応答としてメッセージをホップバイホップで転送します。
If a router cannot continue the Request, the router MUST put an appropriate ReturnCode in the Request message, change the Type field value in the fixed header from PT_CCNINFO_REQUEST to PT_CCNINFO_REPLY, and forward the Reply message back toward the CCNinfo user to terminate the Request (see Section 6).
ルーターがリクエストを継続できない場合、ルーターはリクエストメッセージに適切なRETURNCODEを配置する必要があります。固定ヘッダーのタイプフィールド値をPT_CCNINFO_REQUESTからPT_CCNINFO_REPLYに変更する必要があります。セクション6）。
When a router receives a CCNinfo Reply whose Request ID and Node Identifier values match those in the PIT entry, which is sent from a valid adjacent neighbor router, it forwards the CCNinfo Reply back toward the CCNinfo user. If the router does not receive the corresponding Reply within the [CCNinfo Reply Timeout] period, then it removes the corresponding PIT entry and terminates the trace.
ルーターがCCNINFOの返信を受信すると、リクエストIDとノード識別子値がPITエントリの値と一致し、有効な隣接Neighborルーターから送信されると、CCNINFOの返信をCCNINFOユーザーに転送します。ルーターが[ccninfo返信タイムアウト]期間内に対応する応答を受け取らない場合、対応するピットエントリを削除し、トレースを終了します。
The Flags field in the Request block TLV is used to indicate whether the router keeps the PIT entry during the CCNinfo Reply Timeout even after one or more corresponding Reply messages are forwarded. When the CCNinfo user does not set the F flag (i.e., "0"), the intermediate routers immediately remove the PIT entry whenever they forward the corresponding Reply message. When the CCNinfo user sets the F flag (i.e., "1"), which means the CCNinfo user chooses the "full discovery request" (see Section 5.3.2), the intermediate routers keep the PIT entry within the [CCNinfo Reply Timeout] period. After this timeout, the PIT entry is removed.
要求ブロックTLVのフラグフィールドは、1つ以上の対応する応答メッセージが転送された後でも、CCNINFO応答タイムアウト中にルーターがピットエントリを保持するかどうかを示すために使用されます。CCNINFOユーザーがFフラグを設定しない場合（つまり、 "0"）、中間ルーターは、対応する返信メッセージを転送するたびにピットエントリをすぐに削除します。CCNINFOユーザーがFフラグ（つまり、「1」）を設定すると、CCNINFOユーザーが「完全な発見リクエスト」を選択します（セクション5.3.2を参照）、中間ルーターは[CCNINFO応答タイムアウト]内にピットエントリを保持します。期間。このタイムアウトの後、ピットエントリが削除されます。
CCNinfo Replies MUST NOT be cached in routers upon the transmission of Reply messages.
CCNINFOの応答は、応答メッセージの送信時にルーターでキャッシュされてはなりません。
Within a network with a multipath condition, there is a case (Figure 12) wherein a single CCNinfo Request is split into multiple Requests (e.g., at Router A), which are injected into a single router (Router D). In this case, multiple Replies with the same Request ID and Node Identifier values, including different Report blocks, are received by the router (Router D).
マルチパス条件を備えたネットワーク内には、単一のCCNINFO要求が複数のリクエスト（ルーターAでは、1つのルーター（ルーターD）に注入されるケースがあります（図12）。この場合、異なるレポートブロックを含む同じ要求IDおよびノード識別子値を持つ複数の応答がルーター（ルーターD）によって受信されます。
+--------+
| Router |
| B |
+--------+
/ \
/ \
+--------+ +--------+ +--------+ +---------+
| CCNinfo|----| Router | | Router | ... |Publisher|
| user | | A | | D | | |
+--------+ +--------+ +--------+ +---------+
\ /
\ /
+--------+
| Router |
| C |
+--------+
Figure 12: An Example of Multipath Network Topology
図12：マルチパスネットワークトポロジの例
To recognize different CCNinfo Reply messages, the routers MUST distinguish the PIT entries by the Request ID and exploiting path labels, which could be a hash value of the concatenation information of the cumulate node identifiers in the hop-by-hop header and the specified content name. For example, when Router D in Figure 12 receives a CCNinfo Request from Router B, its PIT includes the Request ID and value such as H((Router_A|Router_B)|content_name), where "H" indicates some hash function and "|" indicates concatenation. When Router D receives a CCNinfo Request from Router C, its PIT includes the same Request ID and value of H((Router_A|Router_C)|content_name). Two different Replies are later received on Router D, and each Reply is appropriately forwarded to Router B and Router C, respectively. Note that two Reply messages coming from Router B and Router C are reached at Router A, but the CCNinfo user can only receive the first Reply message either from Router B or Router C as Router A removes the corresponding PIT entry after it forwards the first Reply.
さまざまなCCNINFO応答メッセージを認識するには、ルーターはリクエストIDとエクスプロイングパスラベルでピットエントリを区別する必要があります。名前。たとえば、図12のルーターDがルーターBからCCNINFO要求を受信すると、そのピットにはリクエストIDとh（Router_a | router_b）| content_nameなどの値が含まれます。ここで、「h」はハッシュ関数と「|」を示します。連結を示します。ルーターDがルーターCからCCNINFO要求を受信すると、そのピットには同じ要求IDとh（（router_a | router_c）| content_name）の値が含まれます。2つの異なる応答が後でルーターDで受信され、各返信はそれぞれルーターBとルーターCに適切に転送されます。ルーターBとルーターCから来る2つの返信メッセージがルーターAで到達しますが、CCNINFOユーザーはルーターBまたはルーターCから最初の返信メッセージを受信できることに注意してください。。
To avoid routing loops, when a router seeks the cumulate node identifiers of the Report blocks in the hop-by-hop header, it MUST examine whether its own node identifier is not previously inserted. If a router detects its own node identifier in the hop-by-hop header, the router inserts its Report block and terminates the Request as will be described in Section 6.8.
ルーティングループを回避するには、ルーターがホップバイホップヘッダーのレポートブロックの累積ノード識別子を探している場合、独自のノード識別子が以前に挿入されていないかどうかを調べる必要があります。ルーターがホップバイホップヘッダーで独自のノード識別子を検出すると、ルーターはレポートブロックを挿入し、セクション6.8で説明するリクエストを終了します。
When performing a hop-by-hop trace, it is necessary to determine when to stop the trace. There are several cases when an intermediate router might return a Reply before a Request reaches the caching router or the FHR.
ホップバイホップトレースを実行するときは、トレースをいつ停止するかを判断する必要があります。リクエストがキャッシュルーターまたはFHRに到達する前に、中間ルーターが返信を返す可能性がある場合は、いくつかのケースがあります。
A CCNinfo Request can be determined to have arrived at the FHR. To ensure that a router recognizes that it is the FHR for the specified content, it needs to have a FIB entry (or to attach) to the corresponding publisher or the content.
CCNINFOリクエストは、FHRに到着したと判断できます。ルーターが指定されたコンテンツのFHRであることを確認するには、対応するパブリッシャーまたはコンテンツにFIBエントリ（または添付）する必要があります。
A CCNinfo Request can be determined to have arrived at the router having the specified content cache within the specified HopLimit.
CCNINFO要求は、指定されたHoplimit内に指定されたコンテンツキャッシュを持つルーターに到着したと判断できます。
A CCNinfo Request can be determined to have arrived at the last router of the specified HopLimit. If the last router does not have the corresponding cache, it MUST insert its Report block and send the Reply message with a NO_INFO return code without appending any Reply block or sub-block TLVs.
CCNINFOリクエストは、指定されたHoplimitの最後のルーターに到着したと判断できます。最後のルーターに対応するキャッシュがない場合、レポートブロックを挿入し、返信ブロックまたはサブブロックTLVを追加せずにNO_INFOの返信コードで返信メッセージを送信する必要があります。
If the router does not validate the Request or the Reply even it is required, the router MUST note a ReturnCode of INVALID_REQUEST in the fixed header of the message, insert its Report block, and forward the message as the Reply back to the CCNinfo user. The router MAY, however, randomly ignore the received invalid messages. (See Section 10.7.)
ルーターがリクエストまたは応答を検証しない場合でも、Routerはメッセージの固定ヘッダーにInvalid_RequestのReturnCodeに注意し、レポートブロックを挿入し、メッセージをCCNINFOユーザーに返信する必要があります。ただし、ルーターは、受信した無効なメッセージをランダムに無視する場合があります。（セクション10.7を参照してください。）
If the router cannot determine the routing paths or neighbor routers for the specified name prefix within the specified HopLimit, it MUST note a ReturnCode of NO_ROUTE in the fixed header of the message, insert its Report block, and forward the message as the Reply back to the CCNinfo user.
ルーターが指定されたhoplimit内の指定された名前プレフィックスのルーティングパスまたはネイバールーターを決定できない場合は、メッセージの固定ヘッダーにno_routeのreturncodeに注意する必要があります。CCNINFOユーザー。
If the router does not have any information about the specified name prefix within the specified HopLimit, it MUST note a ReturnCode of NO_INFO in the fixed header of the message, insert its Report block, and forward the message as the Reply back to the CCNinfo user.
ルーターに指定されたhoplimit内の指定された名前のプレフィックスに関する情報がない場合、メッセージの固定ヘッダーにno_infoのreturncodeに注意する必要があります。レポートブロックを挿入し、メッセージをccninfoユーザーに返信するように転送する必要があります。。
If appending the Report block, the Reply block, or Reply sub-block would make the hop-by-hop header longer than 247 bytes or the Request packet longer than the MTU of the Incoming face, the router MUST note a ReturnCode of NO_SPACE in the fixed header of the message and forward the message as the Reply back to the CCNinfo user.
レポートブロックを追加している場合、Replyブロック、または応答サブブロックは、ホップバイホップヘッダーを247バイトよりも長くします。メッセージの固定ヘッダーとメッセージをCCNINFOユーザーに返信するように転送します。
If a CCNinfo Request has encountered a fatal error, the router MUST note a ReturnCode of FATAL_ERROR in the fixed header of the message and forward the message as the Reply back to the CCNinfo user. This may happen, for example, when the router detects some routing loop in the Request blocks (see Section 1). The fatal error can be encoded with another error: if a router detects routing loop but cannot insert its Report block, it MUST note NO_SPACE and FATAL_ERROR ReturnCodes (i.e., 0x85) in the fixed header and forward the message back to the CCNinfo user.
CCNINFOリクエストが致命的なエラーに遭遇した場合、ルーターはメッセージの固定ヘッダーにdatal_errorのリターンコードを記録し、CCNINFOユーザーへの返信としてメッセージを転送する必要があります。これは、たとえば、ルーターがリクエストブロック内のいくつかのルーティングループを検出するときに発生する可能性があります（セクション1を参照）。致命的なエラーは、別のエラーでエンコードできます。ルーターがルーティングループを検出してレポートブロックを挿入できない場合、固定ヘッダーのNO_SPACEおよびDATAL_ERROR RETURNCODES（つまり、0x85）に注意し、メッセージをCCNINFOユーザーに転送する必要があります。
If a router receives the Request or Reply message that expires its own [CCNinfo Reply Timeout] value (Section 7.1), the router will silently discard the Request or Reply message.
ルーターが独自の[ccninfo Reply Timeout]値（セクション7.1）を有効にするリクエストまたは返信メッセージを受信した場合、ルーターはリクエストまたは返信メッセージを静かに破棄します。
Cases will arise in which a router or a FHR along the path does not support CCNinfo. In such cases, a CCNinfo user and routers that forward the CCNinfo Request will time out the CCNinfo request.
パスに沿ったルーターまたはFHRがCCNINFOをサポートしないケースが発生します。そのような場合、CCNINFO要求を転送するCCNINFOユーザーとルーターがCCNINFO要求をタイムアウトします。
If CCNinfo is administratively prohibited, the router rejects the Request message and MUST send the CCNinfo Reply with the ReturnCode of ADMIN_PROHIB. The router MAY, however, randomly ignore the Request messages to be rejected (see Section 10.7).
CCNINFOが管理的に禁止されている場合、ルーターはリクエストメッセージを拒否し、admin_prohitのreturnCodeでCCNINFOの返信を送信する必要があります。ただし、ルーターは、拒否する要求メッセージをランダムに無視する場合があります（セクション10.7を参照）。
The [CCNinfo Reply Timeout] value is used to time out a CCNinfo Reply. The value for a router can be statically configured by the router's administrators and/or operators. The default value is 3 (seconds). The [CCNinfo Reply Timeout] value SHOULD NOT be larger than 4 (seconds) and SHOULD NOT be lower than 2 (seconds).
[CCNINFO REPLY TIMEOUT]値は、CCNINFO応答のタイムアウトに使用されます。ルーターの値は、ルーターの管理者および/またはオペレーターによって静的に構成できます。デフォルト値は3（秒）です。[ccninfo Reply Timeout]値は4（秒）より大きくなく、2（秒）より低くないようにしてください。
If a CCNinfo user does not specify the HopLimit value in the fixed header for a Request message as the HopLimit, the HopLimit is set to 32. Note that 0 HopLimit is an invalid Request; hence, the router in this case follows the way defined in Section 6.4.
CCNINFOユーザーがリクエストメッセージの固定ヘッダーのHoplimit値を指定していない場合、Hoplimitは32に設定されています。したがって、この場合のルーターは、セクション6.4で定義されている方法に従います。
A router MAY configure the valid or invalid networks to enable an access control. The access control MAY be defined per name prefix, such as "who can retrieve which name prefix" (see Section 10.2).
ルーターは、アクセス制御を有効にするように有効または無効なネットワークを構成する場合があります。アクセス制御は、「誰がどの名前のプレフィックスを取得できるか」など、名前のプレフィックスごとに定義できます（セクション10.2を参照）。
A CCNinfo Request message is forwarded in a hop-by-hop manner and each forwarding router appends its own Report block. We can then verify the number of hops to reach the content forwarder or publisher and the RTT between the content forwarder or publisher.
CCNINFO要求メッセージはホップバイホップで転送され、各転送ルーターは独自のレポートブロックを追加します。その後、ホップ数を確認して、コンテンツフォワーダーまたはパブリッシャーの間のコンテンツフォワーダーまたはパブリッシャーとRTTに到達できます。
While some routers may hide their node identifiers with all-zeros in the Report blocks (as seen in Section 10.1), the routers in the path from the CCNinfo user to the content forwarder can be identified.
一部のルーターは、レポートブロックのすべてのゼロを使用してノード識別子を非表示にする場合がありますが（セクション10.1に見られるように）、CCNINFOユーザーからコンテンツフォワーダーへのパス内のルーターを識別できます。
By taking the HopLimit from the content forwarder and forwarding the TTL threshold over all hops, it is possible to discover the TTL or hop limit required for the content forwarder to reach the CCNinfo user.
コンテンツフォワーダーからHoplimitを取得し、すべてのホップにTTLしきい値を転送することにより、コンテンツフォワーダーがCCNINFOユーザーにリーチするために必要なTTLまたはホップ制限を発見することができます。
If the routers have synchronized clocks, it is possible to estimate the propagation and queuing delays from the differences between the timestamps at the successive hops. However, this delay includes the control processing overhead; therefore, it is not necessarily indicative of the delay that would be experienced by the data traffic.
ルーターに同期されたクロックがある場合、連続したホップでのタイムスタンプ間の違いからの伝播とキューイングの遅延を推定することができます。ただし、この遅延には、制御処理オーバーヘッドが含まれます。したがって、データトラフィックが経験する遅延を必ずしも示しているわけではありません。
By obtaining the path stretch "d / P", where "d" is the hop count of the data and "P" is the hop count from the consumer to the publisher, we can measure the improvements in path stretch in various cases, such as in different caching and routing algorithms. We can then facilitate the investigation of the performance of the protocol.
パスストレッチ「D / P」を取得することにより、「D」はデータのホップカウントであり、「P」は消費者からパブリッシャーへのホップカウントです。さまざまなケースでパスストレッチの改善を測定できます。さまざまなキャッシュおよびルーティングアルゴリズムのように。その後、プロトコルのパフォーマンスの調査を促進できます。
CCNinfo can show the number of received Interests per cache or chunk on a router. Accordingly, CCNinfo measures the content popularity (i.e., the number of accesses for each content and/or cache), thereby enabling the investigation of the routing/caching strategy in networks.
CCNINFOは、キャッシュあたりの受信した利息またはルーターのチャンクの数を表示できます。したがって、CCNINFOはコンテンツの人気（つまり、各コンテンツやキャッシュのアクセス数）を測定し、それによりネットワークでのルーティング/キャッシュ戦略の調査を可能にします。
This section details each kind of CCNx protocol value that has been registered. As per [RFC8126], four assignments have been made in existing registries, and a new Reply Type registry has been created in the "Content-Centric Networking (CCNx)" registry group.
このセクションでは、登録されている各種類のCCNXプロトコル値について詳しく説明します。[RFC8126]に従って、既存のレジストリで4つの割り当てが行われ、「コンテンツ中心のネットワーク（CCNX）」レジストリグループに新しい返信タイプレジストリが作成されました。
As shown in Table 1, CCNinfo defines two packet types, PT_CCNINFO_REQUEST and PT_CCNINFO_REPLY, whose values are 0x03 and 0x04, respectively.
表1に示すように、CCNINFOは2つのパケットタイプ、PT_CCNINFO_REQUESTとPT_CCNINFO_REPLYを定義します。
As shown in Table 2, CCNinfo defines one top-level type, T_DISCOVERY, whose value is 0x0005.
表2に示すように、CCNINFOは、値が0x0005である1つのトップレベルタイプT_Discoveryを定義しています。
As shown in Table 4, CCNinfo defines two hop-by-hop types, T_DISC_REQHDR and T_DISC_REPORT, whose values are 0x0008 and 0x0009, respectively.
表4に示すように、CCNINFOは2つのホップバイホップ型、T_DISC_REQHDRとT_DISC_REPORTを定義します。
As shown in Table 6, CCNinfo defines two message types, T_DISC_REQ and T_DISC_REPLY, whose values are 0x000D and 0x000E, respectively.
表6に示すように、CCNINFOは2つのメッセージタイプ、T_DISC_REQとT_DISC_REPLYを定義します。
IANA has created the "CCNx Reply Types" registry and allocated the reply types. The registration procedure is "RFC Required" [RFC8126]. The Type value is 2 octets. The range is 0x0000-0xFFFF. As shown in Table 7, CCNinfo defines three reply types, T_DISC_CONTENT, T_DISC_CONTENT_PUBLISHER, and T_ORG, whose values are 0x0000, 0x0001, and 0x0FFF, respectively.
IANAは「CCNX Replyタイプ」レジストリを作成し、返信タイプを割り当てました。登録手順は「RFC必須」です[RFC8126]。タイプ値は2オクテットです。範囲は0x0000-0xffffです。表7に示すように、CCNINFOは3つの返信タイプ、t_disc_content、t_disc_content_publisher、およびt_orgを定義します。
This section addresses some of the security considerations.
このセクションでは、セキュリティ上の考慮事項の一部について説明します。
Although CCNinfo gives excellent troubleshooting cues, some network administrators or operators may not want to disclose everything about their network to the public or may wish to securely transmit private information to specific members of their networks. CCNinfo provides policy-based information provisioning, thereby allowing network administrators to specify their response policy for each router.
CCNINFOは優れたトラブルシューティングの手がかりを提供しますが、一部のネットワーク管理者またはオペレーターは、ネットワークに関するすべてを一般に公開したくないか、個人情報をネットワークの特定のメンバーに安全に送信したい場合があります。CCNINFOは、ポリシーベースの情報プロビジョニングを提供するため、ネットワーク管理者が各ルーターの応答ポリシーを指定できるようにします。
The access policy regarding "who is allowed to retrieve" and/or "what kind of cache information" can be defined for each router. For the former type of access policy, routers with the specified content MAY examine the signature enclosed in the Request message and decide whether they should notify the content information in the Reply. If the routers decide to not notify the content information, they MUST send the CCNinfo Reply with the ReturnCode of ADMIN_PROHIB without appending any Reply block or sub-block TLVs. For the latter type of policy, the permission, whether (1) All (all cache information is disclosed), (2) Partial (cache information with a particular name prefix can (or cannot) be disclosed), or (3) Deny (no cache information is disclosed), is defined at the routers.
「誰が取得できるか」に関するアクセスポリシーおよび/または「どのようなキャッシュ情報」を各ルーターに定義できます。以前のタイプのアクセスポリシーの場合、指定されたコンテンツを含むルーターは、リクエストメッセージに囲まれた署名を調べ、返信のコンテンツ情報に通知するかどうかを決定する場合があります。ルーターがコンテンツ情報に通知しないことを決定した場合、返信ブロックまたはサブブロックTLVを追加せずに、admin_prohibのreturnCodeでCCNINFOの返信を送信する必要があります。後者のタイプのポリシーの場合、許可、（1）すべて（すべてのキャッシュ情報が開示されている）、（2）部分的（特定の名前のプレフィックスを含むキャッシュ情報は開示できます）、または（3）拒否（キャッシュ情報は開示されていません）、ルーターで定義されています。
In contrast, we entail that each router does not disrupt the forwarding of CCNinfo Request and Reply messages. When a Request message is received, the router SHOULD insert the Report block if the ReturnCode is NO_ERROR. Here, according to the policy configuration, the Node Identifier field in the Report block MAY be null (i.e., all-zeros), but the Request Arrival Time field SHOULD NOT be null. Finally, the router SHOULD forward the Request message to the upstream router toward the content forwarder if the ReturnCode is kept with NO_ERROR.
対照的に、各ルーターがCCNINFOリクエストと返信メッセージの転送を妨害しないことを伴います。リクエストメッセージが受信されると、ReturnCodeがNO_ERRORの場合、ルーターはレポートブロックを挿入する必要があります。ここでは、ポリシー構成によれば、レポートブロックのノード識別子フィールドはnull（つまり、全ゼロ）である可能性がありますが、リクエスト到着時間フィールドはnullであってはなりません。最後に、RutremCodeがNO_ERRORで保持されている場合、ルーターはリクエストメッセージをコンテンツフォワーダーに向けて転送する必要があります。
A router MAY support an access control mechanism to filter out Requests from invalid CCNinfo users. To accomplish this, invalid networks (or domains) could, for example, be configured via a list of allowed or disallowed networks (as observed in Section 7.3). If a Request is received from a disallowed network (according to the node identifier in the Request block), the Request MUST NOT be processed and the Reply with the ReturnCode of INFO_HIDDEN SHOULD be used to note that. The router MAY, however, perform rate-limited logging of such events.
ルーターは、アクセス制御メカニズムをサポートして、無効なCCNINFOユーザーからのリクエストをフィルタリングする場合があります。これを達成するために、無効なネットワーク（またはドメイン）を、たとえば、許可されたネットワークまたは許可されていないネットワークのリスト（セクション7.3で観察される）を介して構成することができます。許可されていないネットワークから（要求ブロックのノード識別子によると）要求が受信された場合、リクエストを処理する必要はなく、Info_hiddenのReturnCodeを使用した返信を使用して注意する必要があります。ただし、ルーターは、このようなイベントのレート制限ロギングを実行する場合があります。
CCNinfo can be used to discover actively used topologies. If a network topology is not disclosed, CCNinfo Requests SHOULD be restricted at the border of the domain using the ADMIN_PROHIB return code.
CCNINFOを使用して、アクティブに使用されるトポロジを発見できます。ネットワークトポロジが開示されていない場合、ccninfoリクエストは、admin_prohibリターンコードを使用してドメインの境界で制限する必要があります。
CCNinfo can be used to discover the type of content being sent by publishers. If this information is a secret, CCNinfo Requests SHOULD be restricted at the border of the domain, using the ADMIN_PROHIB return code.
CCNINFOを使用して、パブリッシャーによって送信されるコンテンツの種類を発見できます。この情報が秘密である場合、CCNINFOリクエストは、admin_prohibリターンコードを使用して、ドメインの境界で制限される必要があります。
CCNinfo may impose heavy tasks at content forwarders because it makes content forwarders seek their internal cache states reported in the Reply messages whenever they form the Reply messages. The current CCNinfo specification allows to return null values for several fields, such as First/Last Seqnum or Elapsed Cache Time fields in the Reply sub-block. As mentioned in Section 3.2.1.1, these values MAY be null. This means that the content forwarder cannot only hide these values owing to privacy and security policies but also skip the implementations of the complex functions to report these values.
CCNINFOは、コンテンツフォワーダーが返信メッセージを形成するたびに返信メッセージで報告された内部キャッシュ状態を求めるため、コンテンツフォワーダーに重いタスクを課す可能性があります。現在のCCNINFO仕様により、Reply Subblockの最初の/最後のSeqnumやElapsed Cache Timeフィールドなど、いくつかのフィールドのnull値を返すことができます。セクション3.2.1.1で述べたように、これらの値はnullである場合があります。これは、コンテンツフォワーダーがプライバシーとセキュリティポリシーのためにこれらの値を隠すことはできないだけでなく、複雑な関数の実装をスキップしてこれらの値を報告することを意味します。
Routers can configure CCNinfo Reply Timeout (Section 7.1), which is the allowable timeout value to keep the PIT entry. If routers configure a longer timeout value, there may be an attractive attack vector against the PIT memory. Moreover, especially when the full discovery request option (Section 5.3) is specified for the CCNinfo Request, several Reply messages may be returned and cause a response storm. (See Section 10.8 for rate-limiting to avoid the storm). To avoid DoS attacks, routers MAY configure the timeout value, which is shorter than the user-configured CCNinfo timeout value. However, if it is too short, the Request may be timed out and the CCNinfo user does not receive all Replies; they only retrieve the partial path information (i.e., information about a part of the tree).
ルーターは、CCNINFOの応答タイムアウト（セクション7.1）を構成できます。これは、ピットエントリを維持するための許容タイムアウト値です。ルーターがより長いタイムアウト値を構成する場合、ピットメモリに対して魅力的な攻撃ベクトルがある可能性があります。さらに、特にCCNINFOリクエストに完全なディスカバリーリクエストオプション（セクション5.3）が指定されている場合、いくつかの返信メッセージが返され、応答ストームが発生する場合があります。（嵐を避けるために、料金制限についてはセクション10.8を参照）。DOS攻撃を回避するために、ルーターはタイムアウト値を構成する場合があります。これは、ユーザーが構成したCCNINFOタイムアウト値よりも短いです。ただし、短すぎる場合、リクエストはタイムアウトされ、CCNINFOユーザーはすべての返信を受け取っていません。それらは、部分的なパス情報（つまり、ツリーの一部に関する情報）のみを取得します。
There may be a way to enable incremental exploration (i.e., to explore the part of the tree that was not explored by the previous operation); however, discussing such mechanisms is out of scope of this document.
インクリメンタルな探索を有効にする方法があるかもしれません（つまり、前の操作で調査されなかったツリーの部分を探索する）。ただし、このようなメカニズムについて議論することは、このドキュメントの範囲外です。
A router MAY rate-limit CCNinfo Requests by ignoring some of the consecutive messages. The router MAY randomly ignore the received messages to minimize the processing overhead, i.e., to keep fairness in processing requests or to prevent traffic amplification. In such a case, no error message is returned. The rate limit function is left to the router's implementation.
ルーターは、連続したメッセージの一部を無視することにより、CCNINFOリクエストを格付けする場合があります。ルーターは、受信したメッセージをランダムに無視して、処理オーバーヘッドを最小限に抑えること、つまり、処理リクエストの公平性を維持したり、トラフィックの増幅を防ぎます。そのような場合、エラーメッセージは返されません。レート制限関数は、ルーターの実装に任されています。
CCNinfo supporting multipath forwarding may result in one Request returning multiple Reply messages. To prevent abuse, the routers in the traced path MAY need to rate-limit the Replies. In such a case, no error message is returned. The rate limit function is left to the router's implementation.
MultiPathの転送をサポートするCCNINFOは、複数の返信メッセージを返す1つのリクエストになる場合があります。乱用を防ぐために、トレースされた経路のルーターは、応答を評価する必要がある場合があります。そのような場合、エラーメッセージは返されません。レート制限関数は、ルーターの実装に任されています。
It is assumed that the CCNinfo Request and Reply messages are forwarded by adjacent neighbor nodes or routers. The CCNx message format or semantics do not define a secure way to verify the node and/or router adjacency, while a hop-by-hop authentication such as [DCAuth] provides a possible method for an adjacency verification and defines the corresponding message format for adjacency verification as well as the router behaviors. CCNinfo MAY use a similar method for node adjacency verification.
CCNINFOリクエストと返信メッセージは、隣接する隣接ノードまたはルーターによって転送されると想定されています。CCNXメッセージ形式またはセマンティクスは、ノードおよび/またはルーターの隣接を検証する安全な方法を定義しませんが、[dcauth]などのホップバイホップ認証は、隣接する検証に可能な方法を提供し、対応するメッセージ形式を定義します。隣接する検証とルーターの動作。CCNINFOは、ノード隣接の検証に同様の方法を使用する場合があります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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>.
[RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric
Networking (CCNx) Messages in TLV Format", RFC 8609,
DOI 10.17487/RFC8609, July 2019,
<https://www.rfc-editor.org/info/rfc8609>.
[Cefore] Asaeda, H., Ooka, A., Matsuzono, K., and R. Li, "Cefore:
Software Platform Enabling Content-Centric Networking and
Beyond", IEICE Transaction on Communications, Volume
E102-B, Issue 9, pp. 1792-1803,
DOI 10.1587/transcom.2018EII0001, September 2019,
<https://doi.org/10.1587/transcom.2018EII0001>.
[Cefore-site]
"Cefore", <https://cefore.net/>.
[CONSEC-CACHING]
Li, R., Matsuzono, K., Asaeda, H., and X. Fu, "Consecutive
Caching and Adaptive Retrieval for In-Network Big Data
Sharing", Proc. IEEE ICC, Kansas City, MO, USA,
DOI 10.1109/ICC.2018.8422233, May 2018,
<https://doi.org/10.1109/ICC.2018.8422233>.
[Contrace] Asaeda, H., Matsuzono, K., and T. Turletti, "Contrace: A
tool for measuring and tracing content-centric networks",
IEEE Communications Magazine, Vol. 53, No. 3, pp. 182-188,
DOI 10.1109/MCOM.2015.7060502, March 2015,
<https://doi.org/10.1109/MCOM.2015.7060502>.
[DCAuth] Li, R., Asaeda, H., and J. Wu, "DCAuth: Data-Centric
Authentication for Secure In-Network Big-Data Retrieval",
IEEE Transactions on Network Science and Engineering, Vol.
7, No. 1, pp. 15-27, DOI 10.1109/TNSE.2018.2872049,
October 2018, <https://doi.org/10.1109/TNSE.2018.2872049>.
[ICN-PING] Mastorakis, S., Oran, D., Gibson, J., Moiseenko, I., and
R. Droms, "ICN Ping Protocol Specification", Work in
Progress, Internet-Draft, draft-irtf-icnrg-icnping-07, 16
October 2022, <https://datatracker.ietf.org/doc/html/
draft-irtf-icnrg-icnping-07>.
[ICN-TRACEROUTE]
Mastorakis, S., Oran, D., Moiseenko, I., Gibson, J., and
R. Droms, "ICN Traceroute Protocol Specification", Work in
Progress, Internet-Draft, draft-irtf-icnrg-icntraceroute-
07, 16 October 2022,
<https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-
icntraceroute-07>.
[RFC8487] Asaeda, H., Meyer, K., and W. Lee, Ed., "Mtrace Version 2:
Traceroute Facility for IP Multicast", RFC 8487,
DOI 10.17487/RFC8487, October 2018,
<https://www.rfc-editor.org/info/rfc8487>.
[RFC8793] Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., Oran,
D., and C. Tschudin, "Information-Centric Networking
(ICN): Content-Centric Networking (CCNx) and Named Data
Networking (NDN) Terminology", RFC 8793,
DOI 10.17487/RFC8793, June 2020,
<https://www.rfc-editor.org/info/rfc8793>.
CCNinfo is implemented in Cefore [Cefore] [Cefore-site]. The command invoked by the CCNinfo user (e.g., consumer) is named "ccninfo". The ccninfo command sends the Request message and receives the Reply message(s). There are several options that can be specified with ccninfo, while the content name prefix (e.g., ccnx:/news/today) is the mandatory parameter.
ccninfoは、cefore [cefore] [cefore-site]に実装されています。CCNINFOユーザー（消費者など）によって呼び出されたコマンドの名前は「ccninfo」です。CCNINFOコマンドはリクエストメッセージを送信し、返信メッセージを受信します。CCNINFOで指定できるいくつかのオプションがありますが、コンテンツ名のプレフィックス（例えば、ccnx：/news/today）は必須パラメーターです。
The usage of the ccninfo command is as follows:
CCNINFOコマンドの使用は次のとおりです。
ccninfo [-c] [-f] [-o] [-V] [-r hop_count] [-s hop_count]
[-v algorithm] name_prefix
name_prefix:
name_prefix：
The prefix name of content (e.g., ccnx:/news/today) or exact name of content (e.g., ccnx:/news/today/Chunk=10) the CCNinfo user wants to trace.
コンテンツのプレフィックス名（例：ccnx：/news/today）または正確なコンテンツ名（例：ccnx：/news/today/chunk = 10）ccninfoユーザーがトレースしたい。
c option:
Cオプション：
This option can be specified if a CCNinfo user needs the cache information as well as the routing path information for the specified content/cache and RTT between the CCNinfo user and content forwarder.
このオプションは、CCNINFOユーザーがキャッシュ情報と、CCNINFOユーザーとコンテンツフォワーダーの間の指定されたコンテンツ/キャッシュとRTTのルーティングパス情報を必要とする場合に指定できます。
f option:
fオプション：
This option enables the "full discovery request"; routers send CCNinfo Requests to multiple upstream faces based on their FIBs simultaneously. The CCNinfo user can then trace all possible forwarding paths.
このオプションは、「完全な発見リクエスト」を有効にします。ルーターは、CCNINFOリクエストをFIBに同時に複数の上流の顔に送信します。CCNINFOユーザーは、可能なすべての転送パスをトレースできます。
o option:
o オプション：
This option enables the tracing of the path to the content publisher. Each router along the path to the publisher inserts each Report block and forwards the Request message. It does not send Reply even if it caches the specified content. FHR that attaches the publisher (who has the complete set of content and is not a caching router) sends the Reply message.
このオプションにより、コンテンツパブリッシャーへのパスのトレースが可能になります。出版社へのパスに沿った各ルーターは、各レポートブロックを挿入し、要求メッセージを転送します。指定されたコンテンツをキャッシュしても、返信は送信されません。パブリッシャー（コンテンツの完全なセットがあり、キャッシュルーターではない）を添付するFHRは、返信メッセージを送信します。
V option:
Vオプション：
This option requests the Reply sender to validate the Reply message with the Reply sender's signature. The Reply message will then include the CCNx ValidationPayload TLV. The validation algorithm is selected by the Reply sender.
このオプションは、返信送信者に返信送信者の署名を使用して返信メッセージを検証するよう要求します。返信メッセージには、ccnx validation -payload tlvが含まれます。検証アルゴリズムは、返信送信者によって選択されます。
r option:
Rオプション：
The number of traced routers. This value is set in the "HopLimit" field located in the fixed header of the Request. For example, when the CCNinfo user invokes the ccninfo command with this option, such as "-r 3", only three routers along the path examine their path and cache information.
トレースされたルーターの数。この値は、リクエストの固定ヘッダーにある「Hoplimit」フィールドに設定されています。たとえば、CCNINFOユーザーが「-R 3」などのこのオプションでCCNINFOコマンドを呼び出すと、パスに沿った3つのルーターのみがパスを調べ、情報をキャッシュします。
s option:
sオプション：
The number of skipped routers. This value is set in the "SkipHop" field located in the Request block TLV. For example, when the CCNinfo user invokes the ccninfo command with this option, such as "-s 3", three upstream routers along the path only forward the Request message but do not append their Report blocks in the hop-by-hop header and do not send Reply messages despite having the corresponding cache.
スキップされたルーターの数。この値は、要求ブロックTLVにある「Skiphop」フィールドに設定されています。たとえば、CCNINFOユーザーが「-S 3」などのこのオプションでCCNINFOコマンドを呼び出すとき、パスに沿って3つのアップストリームルーターが要求メッセージを転送するだけでなく、ホップバイホップヘッダーにレポートブロックを追加しないでください。対応するキャッシュがあるにもかかわらず、返信メッセージを送信しないでください。
v option:
Vオプション：
This option enables the CCNinfo user to validate the Request message with their signature. The Request message will include the CCNx ValidationPayload TLV. The validation algorithm is specified by the CCNinfo user.
このオプションにより、CCNINFOユーザーは署名を使用してリクエストメッセージを検証できます。リクエストメッセージには、CCNX ValidationPayload TLVが含まれます。検証アルゴリズムは、CCNINFOユーザーによって指定されています。
The authors would like to thank Jérôme François, Erik Kline, Spyridon Mastorakis, Paulo Mendes, Ilya Moiseenko, David Oran, and Thierry Turletti for their valuable comments and suggestions on this document.
著者は、この文書に関する貴重なコメントと提案について、ジェローム・フランソワ、エリック・クライン、スピリドン・マストラキス、パウロ・メンデス、イリヤ・モイゼンコ、デビッド・オラン、ティエリー・ターレットに感謝したいと思います。
Hitoshi Asaeda
National Institute of Information and Communications Technology
4-2-1 Nukui-Kitamachi, Koganei, Tokyo
184-8795
Japan
Email: asaeda@nict.go.jp
Atsushi Ooka
National Institute of Information and Communications Technology
4-2-1 Nukui-Kitamachi, Koganei, Tokyo
184-8795
Japan
Email: a-ooka@nict.go.jp
Xun Shao
Toyohashi University of Technology
1-1 Hibarigaoka Tempaku-cho, Toyohashi, Aichi
441-8580
Japan
Email: shao.xun.ls@tut.jp