Internet Research Task Force (IRTF) M. Mosko
Request for Comments: 8569 PARC, Inc.
Category: Experimental I. Solis
ISSN: 2070-1721 LinkedIn
C. Wood
University of California Irvine
July 2019
Internet Research Task Force (IRTF) M. Mosko
Request for Comments: 8569 PARC, Inc.
Category: Experimental I. Solis
ISSN: 2070-1721 LinkedIn
C. Wood
University of California Irvine
July 2019
Content-Centric Networking (CCNx) Semantics
以内容为中心的网络（CCNx）语义
Abstract
摘要
This document describes the core concepts of the Content-Centric Networking (CCNx) architecture and presents a network protocol based on two messages: Interests and Content Objects. It specifies the set of mandatory and optional fields within those messages and describes their behavior and interpretation. This architecture and protocol specification is independent of a specific wire encoding.
本文档描述了以内容为中心的网络（CCNx）体系结构的核心概念，并介绍了基于两条消息的网络协议：兴趣和内容对象。它指定这些消息中的一组必填字段和可选字段，并描述它们的行为和解释。该体系结构和协议规范独立于特定的有线编码。
The protocol also uses a control message called an Interest Return, whereby one system can return an Interest message to the previous hop due to an error condition. This indicates to the previous hop that the current system will not respond to the Interest.
该协议还使用了一个称为兴趣返回的控制消息，其中一个系统可以将一个兴趣消息返回到由于错误条件而导致的前一跳。这向上一个跃点指示当前系统不会响应兴趣。
This document is a product of the Information-Centric Networking Research Group (ICNRG). The document received wide review among ICNRG participants. Two full implementations are in active use and have informed the technical maturity of the protocol specification.
本文档是以信息为中心的网络研究小组（ICNRG）的产品。该文件得到了ICNRG参与者的广泛审查。两个完整的实现正在积极使用，并已告知协议规范的技术成熟度。
Status of This Memo
关于下段备忘
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/rfc8569.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8569.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
1.2. Architecture . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Protocol Overview . . . . . . . . . . . . . . . . . . . . 6
2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1. Message Grammar . . . . . . . . . . . . . . . . . . . . . 10
2.2. Consumer Behavior . . . . . . . . . . . . . . . . . . . . 14
2.3. Publisher Behavior . . . . . . . . . . . . . . . . . . . 15
2.4. Forwarder Behavior . . . . . . . . . . . . . . . . . . . 16
2.4.1. Interest HopLimit . . . . . . . . . . . . . . . . . . 16
2.4.2. Interest Aggregation . . . . . . . . . . . . . . . . 17
2.4.3. Content Store Behavior . . . . . . . . . . . . . . . 19
2.4.4. Interest Pipeline . . . . . . . . . . . . . . . . . . 19
2.4.5. Content Object Pipeline . . . . . . . . . . . . . . . 20
3. Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1. Name Examples . . . . . . . . . . . . . . . . . . . . . . 23
3.2. Interest Payload ID . . . . . . . . . . . . . . . . . . . 23
4. Cache Control . . . . . . . . . . . . . . . . . . . . . . . . 23
5. Content Object Hash . . . . . . . . . . . . . . . . . . . . . 24
6. Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7. Hashes . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
8. Validation . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.1. Validation Algorithm . . . . . . . . . . . . . . . . . . 25
8.2. Message Integrity Codes . . . . . . . . . . . . . . . . . 26
8.3. Message Authentication Codes . . . . . . . . . . . . . . 26
8.4. Signature . . . . . . . . . . . . . . . . . . . . . . . . 26
9. Interest to Content Object Matching . . . . . . . . . . . . . 28
10. Interest Return . . . . . . . . . . . . . . . . . . . . . . . 29
10.1. Message Format . . . . . . . . . . . . . . . . . . . . . 30
10.2. ReturnCode Types . . . . . . . . . . . . . . . . . . . . 31
10.3. Interest Return Protocol . . . . . . . . . . . . . . . . 32
10.3.1. No Route . . . . . . . . . . . . . . . . . . . . . . 32
10.3.2. HopLimit Exceeded . . . . . . . . . . . . . . . . . 33
10.3.3. Interest MTU Too Large . . . . . . . . . . . . . . . 33
10.3.4. No Resources . . . . . . . . . . . . . . . . . . . . 33
10.3.5. Path Error . . . . . . . . . . . . . . . . . . . . . 33
10.3.6. Prohibited . . . . . . . . . . . . . . . . . . . . . 33
10.3.7. Congestion . . . . . . . . . . . . . . . . . . . . . 34
10.3.8. Unsupported Content Object Hash Algorithm . . . . . 34
10.3.9. Malformed Interest . . . . . . . . . . . . . . . . . 34
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
12. Security Considerations . . . . . . . . . . . . . . . . . . . 34
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
13.1. Normative References . . . . . . . . . . . . . . . . . . 37
13.2. Informative References . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
1.2. Architecture . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Protocol Overview . . . . . . . . . . . . . . . . . . . . 6
2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1. Message Grammar . . . . . . . . . . . . . . . . . . . . . 10
2.2. Consumer Behavior . . . . . . . . . . . . . . . . . . . . 14
2.3. Publisher Behavior . . . . . . . . . . . . . . . . . . . 15
2.4. Forwarder Behavior . . . . . . . . . . . . . . . . . . . 16
2.4.1. Interest HopLimit . . . . . . . . . . . . . . . . . . 16
2.4.2. Interest Aggregation . . . . . . . . . . . . . . . . 17
2.4.3. Content Store Behavior . . . . . . . . . . . . . . . 19
2.4.4. Interest Pipeline . . . . . . . . . . . . . . . . . . 19
2.4.5. Content Object Pipeline . . . . . . . . . . . . . . . 20
3. Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1. Name Examples . . . . . . . . . . . . . . . . . . . . . . 23
3.2. Interest Payload ID . . . . . . . . . . . . . . . . . . . 23
4. Cache Control . . . . . . . . . . . . . . . . . . . . . . . . 23
5. Content Object Hash . . . . . . . . . . . . . . . . . . . . . 24
6. Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7. Hashes . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
8. Validation . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.1. Validation Algorithm . . . . . . . . . . . . . . . . . . 25
8.2. Message Integrity Codes . . . . . . . . . . . . . . . . . 26
8.3. Message Authentication Codes . . . . . . . . . . . . . . 26
8.4. Signature . . . . . . . . . . . . . . . . . . . . . . . . 26
9. Interest to Content Object Matching . . . . . . . . . . . . . 28
10. Interest Return . . . . . . . . . . . . . . . . . . . . . . . 29
10.1. Message Format . . . . . . . . . . . . . . . . . . . . . 30
10.2. ReturnCode Types . . . . . . . . . . . . . . . . . . . . 31
10.3. Interest Return Protocol . . . . . . . . . . . . . . . . 32
10.3.1. No Route . . . . . . . . . . . . . . . . . . . . . . 32
10.3.2. HopLimit Exceeded . . . . . . . . . . . . . . . . . 33
10.3.3. Interest MTU Too Large . . . . . . . . . . . . . . . 33
10.3.4. No Resources . . . . . . . . . . . . . . . . . . . . 33
10.3.5. Path Error . . . . . . . . . . . . . . . . . . . . . 33
10.3.6. Prohibited . . . . . . . . . . . . . . . . . . . . . 33
10.3.7. Congestion . . . . . . . . . . . . . . . . . . . . . 34
10.3.8. Unsupported Content Object Hash Algorithm . . . . . 34
10.3.9. Malformed Interest . . . . . . . . . . . . . . . . . 34
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
12. Security Considerations . . . . . . . . . . . . . . . . . . . 34
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
13.1. Normative References . . . . . . . . . . . . . . . . . . 37
13.2. Informative References . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
This document describes the principles of the CCNx architecture. It describes a network protocol that uses a hierarchical name to forward requests and to match responses to requests. It does not use endpoint addresses, such as Internet Protocol. Restrictions in a request can limit the response by the public key of the response's signer or the cryptographic hash of the response. Every CCNx forwarder along the path does the name matching and restriction checking. The CCNx protocol fits within the broader framework of Information-Centric Networking (ICN) protocols [RFC7927]. This document concerns the semantics of the protocol and is not dependent on a specific wire encoding. The CCNx Messages [RFC8609] document describes a type-length-value (TLV) wire-protocol encoding. This section introduces the main concepts of CCNx, which are further elaborated in the remainder of the document.
本文档描述了CCNx体系结构的原理。它描述了一种网络协议，该协议使用分层名称转发请求并将响应与请求相匹配。它不使用端点地址，例如Internet协议。请求中的限制可以通过响应签名者的公钥或响应的加密散列来限制响应。路径上的每个CCNx转发器都进行名称匹配和限制检查。CCNx协议适用于更广泛的以信息为中心的网络（ICN）协议框架[RFC7927]。本文档涉及协议的语义，不依赖于特定的有线编码。CCNx消息[RFC8609]文档描述了类型长度值（TLV）有线协议编码。本节介绍了CCNx的主要概念，这些概念将在本文档的其余部分中进一步阐述。
The CCNx protocol derives from the early ICN work by Jacobson, et al. [nnc]. Jacobson's version of CCNx is known as the 0.x version ("CCNx 0.x"), and the present work is known as the 1.0 version ("CCNx 1.0"). There are two active implementations of CCNx 1.0. The most complete implementation is Community ICN (CICN) [cicn], a Linux Foundation project hosted at fd.io. Another active implementation is CCN-lite [ccn-lite], with support for Internet of Things (IoT) systems and the RIOT operating system. CCNx 0.x formed the basis of the Named Data Networking (NDN) [ndn] university project.
CCNx协议源自Jacobson等人的早期ICN工作。[nnc]。Jacobson的CCNx版本称为0.x版本（“CCNx 0.x”），目前的工作称为1.0版本（“CCNx 1.0”）。CCNx 1.0有两个活跃的实现。最完整的实现是社区ICN（CICN）[CICN]，一个在FD.IO中托管的Linux基金会项目。另一个积极的实现是CCN lite[CCN lite]，它支持物联网（IoT）系统和RIOT操作系统。CCNx 0.x构成了命名数据网络（NDN）[NDN]大学项目的基础。
The current CCNx 1.0 specification diverges from CCNx 0.x in a few significant areas. The most pronounced behavioral difference between CCNx 0.x and CCNx 1.0 is that CCNx 1.0 has a simpler response processing behavior. In both versions, a forwarder uses a hierarchical longest prefix match of a request name against the forwarding information base (FIB) to send the request through the network to a system that can issue a response. A forwarder must then match a response's name to a request's name to determine the reverse path and deliver the response to the requester. In CCNx 0.x, the Interest name may be a hierarchical prefix of the response name, which allows a form of Layer 3 (L3) content discovery. In CCNx 1.0, a response's name must exactly equal a request's name. Content discovery is performed by a higher-layer protocol.
当前的CCNX1.0规范在几个重要方面与CCNx 0.x有所不同。CCNx 0.x和CCNx 1.0之间最显著的行为差异是CCNx 1.0具有更简单的响应处理行为。在这两个版本中，转发器使用请求名称与转发信息库（FIB）的分层最长前缀匹配，通过网络将请求发送到可以发出响应的系统。然后，转发器必须将响应的名称与请求的名称相匹配，以确定反向路径并将响应传递给请求者。在CCNx 0.x中，兴趣名称可以是响应名称的层次前缀，这允许第3层（L3）内容发现的形式。在CCNX1.0中，响应的名称必须与请求的名称完全相同。内容发现由更高层协议执行。
The selector protocol "CCNx Selectors" [selectors] is an example of using a higher-layer protocol on top of the CCNx 1.0 L3 to perform content discovery. The selector protocol uses a method similar to the original CCNx 0.x techniques without requiring partial name matching of a response to a request in the forwarder.
选择器协议“CCNx选择器”[Selectors]是在CCNx 1.0 L3之上使用更高层协议执行内容发现的示例。选择器协议使用了一种类似于原始CCNx 0.x技术的方法，无需在转发器中对请求的响应进行部分名称匹配。
This document represents the consensus of the Information-Centric Networking Research Group (ICNRG). It is the first ICN protocol from the RG, created from the early CCNx protocol [nnc] with significant revision and input from the ICN community and RG members. This document has received critical reading by several members of the ICN community and the RG. The authors and RG chairs approve of the contents. This document is sponsored under the IRTF, is not issued by the IETF, and is not an IETF standard. This is an experimental protocol and may not be suitable for any specific application. The specification may change in the future.
本文件代表了以信息为中心的网络研究小组（ICNRG）的共识。这是RG的第一个ICN协议，由早期CCNx协议[nnc]创建，ICN社区和RG成员进行了重大修订和输入。ICN社区和RG的一些成员对本文件进行了批判性阅读。作者和RG主席对内容表示赞同。本文件由IRTF赞助，并非由IETF发布，也不是IETF标准。这是一个实验性协议，可能不适用于任何特定应用。规格将来可能会改变。
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.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
We describe the architecture of the network in which CCNx operates and introduce certain terminology from [terminology]. The detailed behavior of each component and message grammar is in Section 2.
我们描述了CCNx运行的网络架构，并从[术语]中引入了某些术语。每个组件和消息语法的详细行为见第2节。
A producer (also called a "publisher") is an endpoint that encapsulates content in Content Objects for transport in the CCNx network. A producer has a public/private keypair and signs (directly or indirectly) the Content Objects. Usually, the producer's KeyId (hash of the public key) is well known or may be derived from the producer's namespace via standard means.
生产者（也称为“发布者”）是将内容封装在内容对象中以便在CCNx网络中传输的端点。制作人有一个公钥/私钥对，并（直接或间接）对内容对象进行签名。通常，生产者的KeyId（公钥的散列）是众所周知的，或者可以通过标准方式从生产者的名称空间派生。
A producer operates within one or more namespaces. A namespace is a name prefix that is represented in the forwarding information base (FIB). This allows a request to reach the producer and fetch a response (if one exists).
生产者在一个或多个名称空间中操作。命名空间是在转发信息库（FIB）中表示的名称前缀。这允许请求到达生产者并获取响应（如果存在）。
The FIB is a table that tells a forwarder where to send a request. It may point to a local application, a local cache or Content Store, or to a remote system. If there is no matching entry in the FIB, a forwarder cannot process a request. The detailed rules on name matching to the FIB are given in Section 2.4.4. An endpoint has a FIB, though it may be a simple default route. An intermediate system (i.e., a router) typically has a much larger FIB. A core CCNx forwarder, for example, would know all the global routes.
FIB是一个表，告诉转发器在哪里发送请求。它可以指向本地应用程序、本地缓存或内容存储，也可以指向远程系统。如果FIB中没有匹配条目，则转发器无法处理请求。第2.4.4节给出了与FIB名称匹配的详细规则。端点有一个FIB，尽管它可能是一个简单的默认路由。中间系统（即路由器）通常具有更大的FIB。例如，一个核心的CCNx转发器将知道所有的全球航线。
A consumer is an endpoint that requests a name. It is beyond the scope of this document to describe how a consumer learns of a name or publisher KeyId; higher-layer protocols built on top of CCNx handle those tasks, such as search engines or lookup services or well-known names. The consumer constructs a request, called an Interest, and forwards it via the endpoint's FIB. The consumer should get back either a response (called a Content Object) that matches the Interest or a control message (called an Interest Return) that indicates the network cannot handle the request.
使用者是请求名称的端点。描述消费者如何了解名称或发布者密钥ID超出了本文档的范围；构建在CCNx之上的更高层协议处理这些任务，例如搜索引擎、查找服务或知名名称。消费者构造一个称为兴趣的请求，并通过端点的FIB转发它。使用者应返回与兴趣匹配的响应（称为内容对象）或指示网络无法处理请求的控制消息（称为兴趣返回）。
There are three ways to detect errors in Interest handling. An Interest Return is a network control message that indicates a low-level error like "no route" or "out of resources". If an Interest arrives at a producer, but the producer does not have the requested content, the producer should send an application-specific error message (e.g., a "not found" message). Finally, a consumer may not receive anything; in which case, it should timeout and, depending on the application, retry the request or return an error to the application.
有三种方法可以检测兴趣处理中的错误。兴趣返回是一条网络控制消息，它指示诸如“无路由”或“资源不足”之类的低级错误。如果兴趣到达制作者，但制作者没有请求的内容，则制作者应发送特定于应用程序的错误消息（例如，“未找到”消息）。最后，消费者可能不会收到任何东西；在这种情况下，它应该超时，并根据应用程序重试请求或向应用程序返回错误。
The goal of CCNx is to name content and retrieve the content from the network without binding it to a specific network endpoint. A routing system (specified separately) populates the FIB tables at each CCNx router with hierarchical name prefixes that point towards the content producers under that prefix. A request finds matching content along those paths, in which case a response carries the data, or, if no match is found, a control message indicates the failure. A request may further refine acceptable responses with a restriction on the response's signer and the cryptographic hash of the response. The details of these restrictions are described below.
CCNx的目标是命名内容并从网络中检索内容，而无需将其绑定到特定的网络端点。路由系统（单独指定）使用层次名称前缀填充每个CCNx路由器上的FIB表，该前缀指向该前缀下的内容生产者。请求会沿着这些路径查找匹配的内容，在这种情况下，响应会携带数据，或者，如果没有找到匹配项，则会显示一条控制消息来指示失败。请求可以通过对响应的签名者和响应的加密散列的限制进一步细化可接受的响应。这些限制的详情如下所述。
The CCNx name is a hierarchical series of name segments. Each name segment has a type and zero or more bytes. Matching two names is done as a binary comparison of the type and value, and is done segment by segment. The human-readable form is defined under a URI scheme "ccnx:" [ccnx-uri], though the canonical encoding of a name is a series of pairs (type, octet string). There is no requirement that any name segment be human readable or UTF-8. The first few segments in a name will be matched against the FIB, and a routing protocol may put its own restrictions on the routable name components (e.g., a maximum length or character-encoding rules). In principle, name segments and names have unbounded length, though in practice they are limited by the wire encoding and practical considerations imposed by a routing protocol. Note that in CCNx, name segments use binary comparison, whereas in a URI, the authority uses a case-insensitive hostname (due to DNS).
CCNx名称是名称段的分层系列。每个名称段都有一个类型和零个或多个字节。匹配两个名称是作为类型和值的二进制比较来完成的，并且是逐段完成的。人类可读形式是在URI方案“ccnx:”[ccnx URI]下定义的，尽管名称的规范编码是一系列对（类型，八位字符串）。不要求任何名称段为人类可读或UTF-8。名称中的前几个段将与FIB匹配，路由协议可能会对可路由名称组件施加自身的限制（例如，最大长度或字符编码规则）。原则上，名称段和名称具有无界长度，但实际上它们受到布线编码和路由协议强加的实际考虑的限制。注意，在CCNx中，名称段使用二进制比较，而在URI中，授权使用不区分大小写的主机名（由于DNS）。
The CCNx name, as used by the forwarder, is purposefully left as a general octet-encoded type and value without any requirements on human readability and character encoding. The reason for this is that we are concerned with how a forwarder processes names. We expect that applications, routing protocols, or other higher layers will apply their own conventions and restrictions on the allowed name segment types and name segment values.
转发器使用的CCNx名称故意保留为通用的八位字节编码类型和值，对人类可读性和字符编码没有任何要求。原因是我们关心的是转发器如何处理名称。我们期望应用程序、路由协议或其他更高的层对允许的名称段类型和名称段值应用它们自己的约定和限制。
CCNx is a request and response protocol that fetches chunks of data using a name. The integrity of each chunk may be directly asserted through a digital signature or Message Authentication Code (MAC), or, alternatively, indirectly via hash chains. Chunks may also carry weaker Message Integrity Codes (MICs) or no integrity protection mechanism at all. Because provenance information is carried with each chunk (or larger indirectly protected block), we no longer need to rely on host identities, such as those derived from TLS certificates, to ascertain the chunk legitimacy. Therefore, data integrity is a core feature of CCNx; it does not rely on the data transmission channel. There are several options for data confidentiality, discussed later.
CCNx是一种请求和响应协议，它使用名称获取数据块。每个区块的完整性可以通过数字签名或消息认证码（MAC）直接断言，或者，也可以通过散列链间接断言。块还可能携带较弱的消息完整性代码（MIC），或者根本没有完整性保护机制。由于源信息随每个区块（或更大的间接保护区块）一起携带，因此我们不再需要依赖主机身份（例如从TLS证书派生的主机身份）来确定区块的合法性。因此，数据完整性是CCNx的核心特征；它不依赖于数据传输通道。数据保密性有几种选择，稍后讨论。
This document only defines the general properties of CCNx names. In some isolated environments, CCNx users may be able to use any name they choose and either inject that name (or prefix) into a routing protocol or use other information foraging techniques. In the Internet environment, there will be policies around the formats of names and assignments of names to publishers, though those are not specified here.
本文档仅定义了CCNx名称的一般属性。在一些隔离的环境中，CCNx用户可以使用他们选择的任何名称，或者将该名称（或前缀）注入路由协议，或者使用其他信息搜索技术。在互联网环境中，将有关于名称格式和出版商名称分配的政策，尽管此处未指定。
The key concept of CCNx is that a subjective name is cryptographically bound to a fixed payload. These publisher-generated bindings can therefore be cryptographically verified. A named payload is thus the tuple {{Name, ExtraFields, Payload, ValidationAlgorithm}, ValidationPayload}, where all fields in the inner tuple are covered by the validation payload (e.g., signature). Consumers of this data can check the binding integrity by recomputing the same cryptographic hash and verifying the digital signature in ValidationPayload.
CCNx的关键概念是，主观名称以加密方式绑定到固定负载。因此，可以对这些发布者生成的绑定进行加密验证。因此，命名的有效载荷是元组{Name，ExtraFields，payload，validationGorithm}，ValidationPayload}，其中内部元组中的所有字段都由验证有效载荷（例如，签名）覆盖。此数据的使用者可以通过重新计算相同的加密哈希并在ValidationPayload中验证数字签名来检查绑定完整性。
In addition to digital signatures (e.g., RSA), CCNx also supports message authentication codes (e.g., Hashed Message Authentication Code (HMAC)) and message integrity codes (e.g., Cyclic Redundancy Checks (CRC)). To maintain the cryptographic binding, there should be at least one object with a signature or authentication code, but not all objects require it. For example, a first object with a signature could refer to other objects via a hash chain, a Merkle tree, or a signed manifest. The later objects may not have any
除了数字签名（例如RSA），CCNx还支持消息身份验证码（例如哈希消息身份验证码（HMAC））和消息完整性码（例如循环冗余校验（CRC））。要维护加密绑定，应该至少有一个对象具有签名或身份验证代码，但并非所有对象都需要它。例如，具有签名的第一个对象可以通过哈希链、Merkle树或签名清单引用其他对象。后面的对象可能没有任何属性
validation and rely purely on the references. The use of an integrity code (e.g., CRC) is intended for detecting accidental corruption in an Interest.
验证和验证完全依赖于参考文献。使用完整性代码（如CRC）旨在检测利益中的意外腐败。
CCNx specifies a network protocol around Interests (request messages) and Content Objects (response messages) to move named payloads. An Interest includes the Name field, which identifies the desired response, and optional matching restrictions. Restrictions limit the possible matching Content Objects. Two restrictions exist: the Key ID restriction (KeyIdRestr) and Content Object Hash restriction (ContentObjectHashRestr). The first restriction on the KeyId limits responses to those signed with a ValidationAlgorithm KeyId field equal to the restriction. The second is the Content Object Hash restriction, which limits the response to one where the cryptographic hash of the entire named payload is equal to the restriction. Section 9 fully explains how these restrictions limit matching of a Content Object to an Interest.
CCNx指定了一个围绕兴趣（请求消息）和内容对象（响应消息）的网络协议，以移动指定的有效负载。兴趣包括名称字段（标识所需的响应）和可选的匹配限制。限制限制了可能的匹配内容对象。存在两个限制：密钥ID限制（KeyIdRestr）和内容对象哈希限制（ContentObjectHashRestr）。KeyId上的第一个限制将响应限制为使用与该限制相同的ValidationAlgorithm KeyId字段签名的响应。第二个是内容对象哈希限制，它将响应限制为整个命名负载的加密哈希等于该限制的响应。第9节充分解释了这些限制如何限制内容对象与兴趣的匹配。
The hierarchy of a CCNx name is used for routing via the longest matching prefix in a forwarder. The longest matching prefix is computed name segment by name segment in the hierarchical name, where each name segment must be exactly equal to match. There is no requirement that the prefix be globally routable. Within a deployment, any local routing may be used, even one that only uses a single flat (nonhierarchical) name segment.
CCNx名称的层次结构用于通过转发器中最长的匹配前缀进行路由。最长的匹配前缀是分层名称中按名称段计算的名称段，其中每个名称段必须完全等于匹配。不要求前缀是全局可路由的。在部署中，可以使用任何本地路由，即使是仅使用单个平面（非层次）名称段的路由。
Another concept of CCNx is that there should be flow balance between Interest messages and Content Object messages. At the network level, an Interest traveling along a single path should elicit no more than one Content Object response. If some node sends the Interest along more than one path, that node should consolidate the responses such that only one Content Object flows back towards the requester. If an Interest is sent broadcast or multicast on a multiple-access media, the sender should be prepared for multiple responses unless some other media-dependent mechanism like gossip suppression or leader election is used.
CCNx的另一个概念是，在兴趣消息和内容对象消息之间应该有流量平衡。在网络级别，沿单个路径移动的兴趣应该不会引发多个内容对象响应。如果某个节点沿多条路径发送兴趣，则该节点应合并响应，以便只有一个内容对象流回到请求者。如果在多址媒体上广播或多播发送兴趣，则发送方应准备好多次响应，除非使用其他媒体相关机制，如八卦抑制或领导人选举。
As an Interest travels the forward path following the FIB, it establishes state at each forwarder such that a Content Object response can trace its way back to the original requester(s) without the requester needing to include a routable return address. We use the notional Pending Interest Table (PIT) as a method to store state that facilitates the return of a Content Object.
当兴趣沿着FIB的转发路径移动时，它在每个转发器处建立状态，以便内容对象响应可以追溯到原始请求者，而请求者不需要包含可路由的返回地址。我们使用名义上的挂起兴趣表（PIT）作为一种存储状态的方法，以便于返回内容对象。
The notional PIT stores the last hop of an Interest plus its Name field and optional restrictions. This is the data required to match a Content Object to an Interest (see Section 9). When a Content
概念PIT存储感兴趣的最后一跳加上其名称字段和可选限制。这是将内容对象与兴趣匹配所需的数据（请参见第9节）。当一个内容
Object arrives, it must be matched against the PIT to determine which entries it satisfies. For each such entry, at most one copy of the Content Object is sent to each listed last hop in the PIT entries.
对象到达时，必须将其与PIT匹配，以确定它满足哪些条目。对于每个这样的条目，最多向PIT条目中列出的每个最后一跳发送一份内容对象副本。
An actual PIT is not mandated by this specification. An implementation may use any technique that gives the same external behavior. There are, for example, research papers that use techniques like label switching in some parts of the network to reduce the per-node state incurred by the PIT [dart]. Some implementations store the PIT state in the FIB, so there is not a second table.
本规范不强制要求使用实际坑。实现可以使用提供相同外部行为的任何技术。例如，有研究论文在网络的某些部分使用标签交换等技术，以减少PIT[dart]产生的每节点状态。一些实现将PIT状态存储在FIB中，因此没有第二个表。
If multiple Interests with the same {Name, [KeyIdRestr], [ContentObjectHashRestr]} tuple arrive at a node before a Content Object matching the first Interest comes back, they are grouped in the same PIT entry and their last hops are aggregated (see Section 2.4.2). Thus, one Content Object might satisfy multiple pending Interests in a PIT.
如果具有相同{Name、[KeyIdRestr]、[ContentObjectHashRestr]}元组的多个兴趣在与第一个兴趣匹配的内容对象返回之前到达一个节点，则将它们分组到同一个PIT条目中，并聚合它们的最后一跳（参见第2.4.2节）。因此，一个内容对象可能满足PIT中的多个未决兴趣。
In CCNx, higher-layer protocols are often called "name-based protocols" because they operate on the CCNx name. For example, a versioning protocol might append additional name segments to convey state about the version of payload. A content discovery protocol might append certain protocol-specific name segments to a prefix to discover content under that prefix. Many such protocols may exist and apply their own rules to names. They may be layered with each protocol encapsulating (to the left) a higher layer's name prefix.
在CCNx中，高层协议通常被称为“基于名称的协议”，因为它们在CCNx名称上运行。例如，版本控制协议可能会附加额外的名称段，以传递有关有效负载版本的状态。内容发现协议可能会将特定于协议的名称段附加到前缀，以发现该前缀下的内容。许多这样的协议可能存在，并对名称应用它们自己的规则。它们可以分层，每个协议封装（在左侧）更高层的名称前缀。
This document also describes a control message called an Interest Return. A network element may return an Interest message to a previous hop if there is an error processing the Interest. The returned Interest may be further processed at the previous hop or returned towards the Interest origin. When a node returns an Interest, it indicates that the previous hop should not expect a response from that node for the Interest, i.e., there is no PIT entry left at the returning node for a Content Object to follow.
本文档还描述了一条称为利息返还的控制消息。如果处理感兴趣的消息时出错，网络元件可以将感兴趣的消息返回到前一跳。返回的利息可在前一跳进一步处理或返回利息来源。当一个节点返回一个兴趣时，它表示前一个跃点不应期望该节点对该兴趣做出响应，即，在返回的节点上没有可供内容对象跟随的PIT条目。
There are multiple ways to describe larger objects in CCNx. Aggregating L3 Content Objects into larger objects is beyond the scope of this document. One proposed method, File-Like ICN Collection (FLIC) [flic], uses a manifest to enumerate the pieces of a larger object. Manifests are, themselves, Content Objects. Another option is to use a convention in the Content Object name, as in the CCNx Chunking [chunking] protocol where a large object is broken into small chunks and each chunk receives a special name component indicating its serial order.
在CCNx中，有多种方法可以描述较大的对象。将L3内容对象聚合为更大的对象超出了本文档的范围。一种被提议的方法，类似文件的ICN集合（FLIC）[FLIC]，使用清单来枚举较大对象的片段。清单本身就是内容对象。另一种选择是在内容对象名称中使用约定，如在CCNx Chunking[Chunking]协议中，一个大对象被分成小的块，每个块接收一个特殊的名称组件，指示其序列顺序。
At the semantic level, described in this document, we do not address fragmentation. One experimental fragmentation protocol, BeginEnd Fragments [befrags], uses a multipoint PPP-style technique for use over L2 interfaces with the specification for CCNx Messages [RFC8609] in TLV wire encoding.
在本文档中描述的语义级别上，我们不处理碎片。一个实验性的碎片协议BeginEnd Fragments[befrags]使用多点PPP风格的技术在L2接口上使用，其规范为TLV有线编码中的CCNx消息[RFC8609]。
With these concepts, the remainder of the document specifies the behavior of a forwarder in processing Interest, Content Object, and Interest Return messages.
利用这些概念，文档的其余部分指定了转发器在处理兴趣、内容对象和兴趣返回消息时的行为。
This section defines the grammar of a CCNx Message (Interest, Content Object, or Interest Return). It then presents typical behaviors for a consumer, a publisher, and a forwarder. In the forwarder section, there are detailed descriptions about how to handle the forwarder-specific topics, such as HopLimit and Content Store, along with detailed processing pipelines for Interest and Content Object messages.
本节定义CCNx消息的语法（兴趣、内容对象或兴趣返回）。然后介绍消费者、出版商和转发商的典型行为。在转发器一节中，有关于如何处理转发器特定主题的详细描述，如HopLimit和Content Store，以及兴趣和内容对象消息的详细处理管道。
The CCNx Message ABNF [RFC5234] grammar is shown in Figure 1. The grammar does not include any encoding delimiters, such as TLVs. Specific wire encodings are given in a separate document. If a Validation section exists, the Validation Algorithm covers from the Body (BodyName or BodyOptName) through the end of the ValidationAlg section. The InterestLifetime, CacheTime, and Return Code fields exist outside of the validation envelope and may be modified.
CCNx消息ABNF[RFC5234]语法如图1所示。语法不包括任何编码分隔符，例如TLV。具体的导线编码在单独的文档中给出。如果存在验证节，验证算法将覆盖从正文（BodyName或BodyOptName）到ValidationAg节的末尾。InterestLifetime、CacheTime和返回代码字段存在于验证信封之外，可以修改。
HashType, PayloadType, and Private Enterprise Number (PEN) need to correspond to IANA values registered in the "CCNx Hash Function Types" and "CCNx Payload Types" registries [ccnx-registry], as well as the "Private Enterprise Numbers" registry [eprise-numbers], respectively.
HashType、PayloadType和Private Enterprise Number（PEN）需要分别对应于“CCNx哈希函数类型”和“CCNx有效负载类型”注册表[CCNx注册表]以及“Private Enterprise Number”注册表[eprise Number]中注册的IANA值。
The various fields, in alphabetical order, are defined as:
按字母顺序排列的各个字段定义为：
AbsTime: Absolute times are conveyed as the 64-bit UTC time in milliseconds since the epoch (standard POSIX time).
AbsTime：绝对时间以64位UTC时间（以毫秒为单位）表示，自历元（标准POSIX时间）起。
CacheTime: The absolute time after which the publisher believes there is low value in caching the Content Object. This is a recommendation to caches (see Section 4).
CacheTime：发布者认为缓存内容对象的值较低的绝对时间。这是对缓存的建议（参见第4节）。
Cert: Some applications may wish to embed an X.509 certificate to both validate the signature and provide a trust anchor. The Cert is a DER-encoded X.509 certificate.
证书：一些应用程序可能希望嵌入X.509证书，以验证签名并提供信任锚。该证书是DER编码的X.509证书。
ConObjField: These are optional fields that may appear in a Content Object.
ConObjField：这些是可能出现在内容对象中的可选字段。
ConObjHash: The value of the Content Object Hash, which is the SHA256-32 over the message from the beginning of the body to the end of the message. Note that this coverage area is different from the ValidationAlg. This value SHOULD NOT be trusted across domains (see Section 5).
ConObjHash：内容对象散列的值，它是从正文开始到消息结束的消息上的SHA256-32。请注意，此覆盖区域与ValidationAG不同。不应跨域信任此值（请参阅第5节）。
ContentObjectHashRestr: The Content Object Hash restriction. A Content Object must hash to the same value as the restriction using the same HashType. The ContentObjectHashRestr MUST use SHA256-32.
ContentObjectHashRestr：内容对象哈希限制。内容对象必须使用相同的哈希类型哈希到与限制相同的值。ContentObjectHashRestr必须使用SHA256-32。
ExpiryTime: An absolute time after which the Content Object should be considered expired (see Section 4).
ExpiryTime：内容对象被视为过期的绝对时间（参见第4节）。
Hash: Hash values carried in a Message carry a HashType to identify the algorithm used to generate the hash followed by the hash value. This form is to allow hash agility. Some fields may mandate a specific HashType.
散列：消息中携带的散列值携带散列类型，以标识用于生成散列的算法，后跟散列值。此表单允许哈希灵活性。某些字段可能要求使用特定的哈希类型。
HashType: The algorithm used to calculate a hash, which must correspond to one of the IANA "CCNx Hash Function Types" [ccnx-registry].
HashType：用于计算哈希的算法，该算法必须对应于IANA“CCNx哈希函数类型”[CCNx注册表]之一。
HopLimit: Interest messages may loop if there are loops in the forwarding plane. To eventually terminate loops, each Interest carries a HopLimit that is decremented after each hop and no longer forwarded when it reaches zero. See Section 2.4.
HopLimit：如果转发平面中存在循环，则感兴趣的消息可能会循环。为了最终终止循环，每个兴趣携带一个hopflimit，该hopflimit在每个hop之后递减，当达到零时不再转发。见第2.4节。
InterestField: These are optional fields that may appear in an Interest message.
InterestField：这些是可选字段，可能出现在兴趣消息中。
KeyId: An identifier for the key used in the ValidationAlg. See Validation (Section 8) for a description of how it is used for MACs and signatures.
KeyId：ValidationAG中使用的密钥的标识符。有关如何将其用于MAC和签名的说明，请参见验证（第8节）。
KeyIdRestr: The KeyId Restriction. A Content Object must have a KeyId with the same value as the restriction.
KeyIdRestr:KeyId限制。内容对象必须具有与限制值相同的KeyId。
KeyLink: A Link (see Section 6) that names how to retrieve the key used to verify the ValidationPayload (see Section 8).
KeyLink：一个链接（参见第6节），用于指定如何检索用于验证ValidationPayload的密钥（参见第8节）。
Lifetime: The approximate time during which a requester is willing to wait for a response, usually measured in seconds. It is not strongly related to the network round-trip time, though it must necessarily be larger.
生存期：请求者愿意等待响应的大致时间，通常以秒为单位。它与网络往返时间关系不大，但必须更大。
Name: A name is made up of a nonempty first segment followed by zero or more additional segments, which may be of 0 length. Name segments are opaque octet strings and are thus case sensitive if encoding UTF-8. An Interest MUST have a Name. A Content Object MAY have a Name (see Section 9). The segments of a name are said to be complete if its segments uniquely identify a single Content Object. A name is exact if its segments are complete. An Interest carrying a full name is one that specifies an exact name and the Content Object Hash restriction of the corresponding Content Object.
名称：名称由非空的第一个段和零个或多个附加段组成，这些段的长度可能为0。名称段是不透明的八位字符串，因此如果编码UTF-8，则区分大小写。权益必须有名称。内容对象可以有名称（请参见第9节）。如果名称的段唯一标识单个内容对象，则称其为完整段。如果其段完整，则名称是精确的。带有全名的兴趣是指指定相应内容对象的确切名称和内容对象哈希限制的兴趣。
Payload: The message's data, as defined by PayloadType.
Payload：消息的数据，由PayloadType定义。
PayloadType: The format of the Payload field. If missing, assume Data type (T_PAYLOADTYPE_DATA) [ccnx-registry]. Data type means the payload is opaque application bytes. Key type (T_PAYLOADTYPE_KEY [ccnx-registry]) means the payload is a DER-encoded public key or X.509 certificate. Link type (T_PAYLOADTYPE_LINK [ccnx-registry]) means it is one or more Links (see Section 6).
PayloadType：有效负载字段的格式。如果缺少，则假定数据类型（T_PAYLOADTYPE_Data）[ccnx注册表]。数据类型表示有效负载是不透明的应用程序字节。密钥类型（T_PAYLOADTYPE_Key[ccnx registry]）表示有效负载是DER编码的公钥或X.509证书。链接类型（T_PAYLOADTYPE_Link[ccnx registry]）表示它是一个或多个链接（参见第6节）。
PublicKey: Some applications may wish to embed the public key used to verify the signature within the message itself. The PublickKey is DER encoded.
公钥：某些应用程序可能希望在消息本身中嵌入用于验证签名的公钥。PublickKey是DER编码的。
RelTime: A relative time, measured in milliseconds.
RelTime：以毫秒为单位的相对时间。
ReturnCode: States the reason an Interest message is being returned to the previous hop (see Section 10.2).
ReturnCode：说明将感兴趣的消息返回到上一个跃点的原因（参见第10.2节）。
SigTime: The absolute time (UTC milliseconds) when the signature was generated. The signature time only applies to the validation algorithm; it does not necessarily represent when the validated message was created.
SigTime：生成签名的绝对时间（UTC毫秒）。签名时间仅适用于验证算法；它不一定表示已验证消息的创建时间。
Vendor: Vendor-specific opaque data. The Vendor data includes the IANA Private Enterprise Numbers [eprise-numbers], followed by vendor-specific information. CCNx allows vendor-specific data in most locations of the grammar.
供应商：特定于供应商的不透明数据。供应商数据包括IANA私有企业编号[eprise编号]，然后是供应商特定信息。CCNx允许在语法的大多数位置使用特定于供应商的数据。
Message = Interest / ContentObject / InterestReturn
Interest = IntHdr BodyName [Validation]
IntHdr = HopLimit [Lifetime] *Vendor
ContentObject = ConObjHdr BodyOptName [Validation]
ConObjHdr = [CacheTime / ConObjHash] *Vendor
InterestReturn= ReturnCode Interest
BodyName = Name Common
BodyOptName = [Name] Common
Message = Interest / ContentObject / InterestReturn
Interest = IntHdr BodyName [Validation]
IntHdr = HopLimit [Lifetime] *Vendor
ContentObject = ConObjHdr BodyOptName [Validation]
ConObjHdr = [CacheTime / ConObjHash] *Vendor
InterestReturn= ReturnCode Interest
BodyName = Name Common
BodyOptName = [Name] Common
Common = *Field [Payload]
Validation = ValidationAlg ValidationPayload
Common = *Field [Payload]
Validation = ValidationAlg ValidationPayload
Name = FirstSegment *Segment
FirstSegment = 1*OCTET / Vendor
Segment = *OCTET / Vendor
Name = FirstSegment *Segment
FirstSegment = 1*OCTET / Vendor
Segment = *OCTET / Vendor
ValidationAlg = (RSA-SHA256 / EC-SECP-256K1 / EC-SECP-384R1 /
HMAC-SHA256 / CRC32C) *Vendor
ValidationPayload = 1*OCTET
PublicAlg = KeyId [SigTime] [KeyLink] [PublicKey] [Cert]
RSA-SHA256 = PublicAlg
EC-SECP-256K1 = PublicAlg
EC-SECP-384R1 = PublicAlg
HMAC-SHA256 = KeyId [SigTime] [KeyLink]
CRC32C = [SigTime]
ValidationAlg = (RSA-SHA256 / EC-SECP-256K1 / EC-SECP-384R1 /
HMAC-SHA256 / CRC32C) *Vendor
ValidationPayload = 1*OCTET
PublicAlg = KeyId [SigTime] [KeyLink] [PublicKey] [Cert]
RSA-SHA256 = PublicAlg
EC-SECP-256K1 = PublicAlg
EC-SECP-384R1 = PublicAlg
HMAC-SHA256 = KeyId [SigTime] [KeyLink]
CRC32C = [SigTime]
AbsTime = 8OCTET ; 64-bit UTC msec since epoch
CacheTime = AbsTime
ConObjField = ExpiryTime / PayloadType
ConObjHash = Hash
ExpiryTime = AbsTime
Field = InterestField / ConObjField / Vendor
Hash = HashType 1*OCTET
HashType = 2OCTET ; IANA "CCNx Hash Function Types"
HopLimit = OCTET
InterestField = KeyIdRestr / ContentObjectHashRestr
KeyId = Hash
KeyIdRestr = Hash
KeyLink = Link
Lifetime = RelTime
Link = Name [KeyIdRestr] [ContentObjectHashRestr]
ContentObjectHashRestr = Hash
Payload = *OCTET
PayloadType = OCTET ; IANA "CCNx Payload Types"
PublicKey = *OCTET ; DER-encoded public key
Cert = *OCTET ; DER-encoded X.509 Certificate
RelTime = 1*OCTET ; msec
ReturnCode = OCTET ; see Section 10.2
SigTime = AbsTime
Vendor = PEN *OCTET
PEN = 1*OCTET ; IANA "Private Enterprise Number"
AbsTime = 8OCTET ; 64-bit UTC msec since epoch
CacheTime = AbsTime
ConObjField = ExpiryTime / PayloadType
ConObjHash = Hash
ExpiryTime = AbsTime
Field = InterestField / ConObjField / Vendor
Hash = HashType 1*OCTET
HashType = 2OCTET ; IANA "CCNx Hash Function Types"
HopLimit = OCTET
InterestField = KeyIdRestr / ContentObjectHashRestr
KeyId = Hash
KeyIdRestr = Hash
KeyLink = Link
Lifetime = RelTime
Link = Name [KeyIdRestr] [ContentObjectHashRestr]
ContentObjectHashRestr = Hash
Payload = *OCTET
PayloadType = OCTET ; IANA "CCNx Payload Types"
PublicKey = *OCTET ; DER-encoded public key
Cert = *OCTET ; DER-encoded X.509 Certificate
RelTime = 1*OCTET ; msec
ReturnCode = OCTET ; see Section 10.2
SigTime = AbsTime
Vendor = PEN *OCTET
PEN = 1*OCTET ; IANA "Private Enterprise Number"
Figure 1: CCNx Message ABNF Grammar
图1:CCNx消息ABNF语法
To request a piece of content for a given {Name, [KeyIdRest], [ContentObjectHashRestr]} tuple, a consumer creates an Interest message with those values. It MAY add a validation section, typically only a CRC32C. A consumer MAY put a Payload field in an Interest to send additional data to the producer beyond what is in the name. The name is used for routing and may be remembered at each hop in the notional PIT to facilitate returning a Content Object; storing large amounts of state in the name could lead to high memory requirements. Because the payload is not considered when forwarding an Interest or matching a Content Object to an Interest, a consumer SHOULD put an Interest Payload ID (see Section 3.2) as part of the name to allow a forwarder to match Interests to Content Objects and avoid aggregating Interests with different payloads. Similarly, if a consumer uses a MAC or a signature, it SHOULD also include a unique segment as part of the name to prevent the Interest from being aggregated with other Interests or satisfied by a Content Object that has no relation to the validation.
为了为给定的{Name、[KeyIdRest]、[ContentObjectHashRestr]}元组请求一段内容，使用者使用这些值创建一条感兴趣的消息。它可以添加一个验证部分，通常仅添加一个CRC32C。消费者可能会将有效负载字段放在感兴趣的内容中，以便向生产者发送名称以外的其他数据。该名称用于路由，可在概念PIT中的每个跃点处记住，以便于返回内容对象；在名称中存储大量状态可能会导致高内存需求。由于转发兴趣或将内容对象与兴趣匹配时不考虑有效负载，消费者应将兴趣有效负载ID（参见第3.2节）作为名称的一部分，以允许转发器将兴趣与内容对象匹配，并避免使用不同的有效负载聚合兴趣。类似地，如果消费者使用MAC或签名，它还应该包括一个唯一段作为名称的一部分，以防止兴趣与其他兴趣聚合，或由与验证无关的内容对象满足。
The consumer SHOULD specify an InterestLifetime, which is the length of time the consumer is willing to wait for a response. The InterestLifetime is an application-scale time, not a network round-trip time (see Section 2.4.2). If not present, the InterestLifetime will use a default value (2 seconds).
使用者应指定InterestLifetime，这是使用者愿意等待响应的时间长度。InterestLifetime是应用程序规模的时间，而不是网络往返时间（参见第2.4.2节）。如果不存在，则InterestLifetime将使用默认值（2秒）。
The consumer SHOULD set the Interest HopLimit to a reasonable value or use the default 255. If the consumer knows the distances to the producer via routing, it SHOULD use that value.
消费者应将利息上限设置为合理值或使用默认值255。如果消费者知道通过路由到生产者的距离，则应使用该值。
A consumer hands off the Interest to its first forwarder, which will then forward the Interest over the network to a publisher (or replica) that may satisfy it based on the name (see Section 2.4).
消费者将兴趣转交给其第一个转发器，然后转发器将通过网络将兴趣转发给出版商（或复制品），出版商（或复制品）可能会根据名称满足其要求（见第2.4节）。
Interest messages are unreliable. A consumer SHOULD run a transport protocol that will retry the Interest if it goes unanswered, up to the InterestLifetime. No transport protocol is specified in this document.
兴趣信息是不可靠的。消费者应该运行一个传输协议，该协议将在兴趣未得到响应时重试该兴趣，直到兴趣寿命。本文档中未指定任何传输协议。
The network MAY send to the consumer an Interest Return message that indicates the network cannot fulfill the Interest. The ReturnCode specifies the reason for the failure, such as no route or congestion. Depending on the ReturnCode, the consumer MAY retry the Interest or MAY return an error to the requesting application.
网络可向消费者发送利息返回消息，指示网络无法实现利息。ReturnCode指定失败的原因，例如没有路线或拥挤。根据返回代码的不同，消费者可能会重试兴趣或向请求应用程序返回错误。
If the content was found and returned by the first forwarder, the consumer will receive a Content Object. The consumer uses the following set of checks to validate a received Content Object:
如果内容被第一个转发器找到并返回，消费者将收到一个内容对象。使用者使用以下一组检查来验证接收到的内容对象：
o The consumer MUST ensure the Content Object is properly formatted.
o 使用者必须确保内容对象的格式正确。
o The consumer MUST verify that the returned Content Object matches one or more pending Interests as per Section 9.
o 消费者必须根据第9节验证返回的内容对象是否与一个或多个未决兴趣匹配。
o If the Content Object is signed, the consumer SHOULD cryptographically verify the signature as per Section 8. If it does not have the corresponding key, it SHOULD fetch the key, such as from a key resolution service or via the KeyLink.
o 如果内容对象已签名，消费者应根据第8节以加密方式验证签名。如果它没有相应的密钥，则应该从密钥解析服务或通过KeyLink获取密钥。
o If the signature has a SigTime, the consumer MAY use that in considering if the signature is valid. For example, if the consumer is asking for dynamically generated content, it should expect the SigTime not to be before the time the Interest was generated.
o 如果签名具有SigTime，消费者可以使用该SigTime来考虑签名是否有效。例如，如果消费者请求动态生成的内容，则应该预期SigTime不会早于兴趣生成的时间。
o If the Content Object is signed, the consumer SHOULD assert the trustworthiness of the signing key to the namespace. Such an assertion is beyond the scope of this document, though one may use traditional PKI methods, a trusted key resolution service, or methods like [trust].
o 如果对内容对象进行了签名，使用者应该断言命名空间的签名密钥的可信度。尽管可以使用传统的PKI方法、可信密钥解析服务或类似[trust]的方法，但这种断言不在本文档的范围之内。
o The consumer MAY cache the Content Object for future use, up to the ExpiryTime if present.
o 消费者可以缓存内容对象以备将来使用，直到过期时间（如果存在）。
o The consumer MAY accept a Content Object off the wire that is expired. A packet Content Object may expire while in flight; there is no requirement that forwarders drop expired packets in flight. The only requirement is that Content Stores, caches, or producers MUST NOT respond with an expired Content Object.
o 消费者可以接受过期的内容对象。数据包内容对象可能在飞行中过期；没有要求转发器在飞行中丢弃过期的数据包。唯一的要求是内容存储、缓存或生产者不得使用过期的内容对象进行响应。
This document does not specify the method by which names populate a FIB table at forwarders (see Section 2.4). A publisher is either configured with one or more name prefixes under which it may create content or it chooses its name prefixes and informs the routing layer to advertise those prefixes.
本文件未规定名称在转发器处填充FIB表的方法（见第2.4节）。发布服务器配置有一个或多个名称前缀，可以在其下创建内容，或者选择其名称前缀并通知路由层公布这些前缀。
When a publisher receives an Interest, it SHOULD:
出版商收到兴趣时，应：
o Verify that the Interest is part of the publisher's namespace(s).
o 验证兴趣是否是发布者命名空间的一部分。
o If the Interest has a Validation section, verify it as per Section 8. Usually an Interest will only have a CRC32C, unless the publisher application specifically accommodates other validations. The publisher MAY choose to drop Interests that carry a Validation section if the publisher application does not expect those signatures, as this could be a form of computational denial of service. If the signature requires a key that the publisher does not have, it is NOT RECOMMENDED that the publisher fetch the key over the network unless it is part of the application's expected behavior.
o 如果权益有验证部分，请按照第8节进行验证。通常，兴趣只有一个CRC32C，除非发布者应用程序专门支持其他验证。如果发布者应用程序不需要这些签名，则发布者可以选择放弃带有验证部分的兴趣，因为这可能是一种计算拒绝服务的形式。如果签名需要发布者没有的密钥，则不建议发布者通过网络获取密钥，除非它是应用程序预期行为的一部分。
o Retrieve or generate the requested Content Object and return it to the Interest's previous hop. If the requested content cannot be returned, the publisher SHOULD reply with an Interest Return or a Content Object with application payload that says the content is not available; this Content Object should have a short ExpiryTime in the future or not be cacheable (i.e., an expiry time of 0).
o 检索或生成请求的内容对象，并将其返回到感兴趣的上一个跃点。如果无法返回请求的内容，则发布者应回复兴趣返回或内容对象，其中应用程序负载表示该内容不可用；此内容对象将来的到期时间应较短或不可缓存（即到期时间为0）。
A forwarder routes Interest messages based on a Forwarding Information Base (FIB), returns Content Objects that match Interests to the Interest's previous hop, and processes Interest Return control messages. It may also keep a cache of Content Objects in the notional Content Store table. This document does not specify the internal behavior of a forwarder, only these and other external behaviors.
转发器基于转发信息库（FIB）路由兴趣消息，返回与兴趣的上一跳匹配的内容对象，并处理兴趣返回控制消息。它还可以在概念内容存储表中保留内容对象的缓存。本文档未指定转发器的内部行为，仅指定这些行为和其他外部行为。
In this document, we will use two processing pipelines: one for Interests and one for Content Objects. Interest processing is made up of checking for duplicate Interests in the PIT (see Section 2.4.2), checking for a cached Content Object in the Content Store (see Section 2.4.3), and forwarding an Interest via the FIB. Content Store processing is made up of checking for matching Interests in the PIT and forwarding to those previous hops.
在本文档中，我们将使用两个处理管道：一个用于兴趣，另一个用于内容对象。兴趣处理由检查PIT中的重复兴趣（参见第2.4.2节）、检查内容存储中的缓存内容对象（参见第2.4.3节）和通过FIB转发兴趣组成。内容存储处理包括检查PIT中的匹配兴趣并转发到以前的跃点。
Interest looping is not prevented in CCNx. An Interest traversing loops is eventually discarded using the hop-limit field of the Interest, which is decremented at each hop traversed by the Interest.
在CCNx中不阻止利息循环。兴趣遍历循环最终使用兴趣的跃点限制字段丢弃，该字段在兴趣遍历的每个跃点处递减。
A loop may also terminate because the Interest is aggregated with its previous PIT entry along the loop. In this case, the Content Object will be sent back along the loop and eventually return to a node that already forwarded the content, so it will likely not have a PIT entry anymore. When the content reaches a node without a PIT entry, it
循环也可能终止，因为利息与循环中的前一个PIT条目聚合在一起。在这种情况下，内容对象将沿循环发回，并最终返回到已转发内容的节点，因此它可能不再具有PIT条目。当内容到达没有坑条目的节点时，它将
will be discarded. It may be that a new Interest or another looped Interest will return to that same node, in which case the node will return a cached response to make a new PIT entry, as below.
将被丢弃。可能是一个新的兴趣点或另一个循环兴趣点将返回到同一个节点，在这种情况下，该节点将返回一个缓存响应以创建一个新的PIT条目，如下所示。
The HopLimit is the last resort method to stop Interest loops where a Content Object chases an Interest around a loop and where the intermediate nodes, for whatever reason, no longer have a PIT entry and do not cache the Content Object.
HopLimit是停止兴趣循环的最后一种方法，其中内容对象围绕循环追逐兴趣，并且中间节点（无论出于何种原因）不再具有PIT条目并且不缓存内容对象。
Every Interest MUST carry a HopLimit. An Interest received from a local application MAY have a 0 HopLimit, which restricts the Interest to other local sources.
每一种利益都必须有一个限度。从本地应用程序收到的利息可能具有0 HopLimit，这将利息限制在其他本地来源。
When an Interest is received from another forwarder, the HopLimit MUST be positive, otherwise the forwarder will discard the Interest. A forwarder MUST decrement the HopLimit of an Interest by at least 1 before it is forwarded.
当从其他转发商收到利息时，HopLimit必须为正，否则转发商将放弃利息。在转发之前，转发商必须将利息的上限至少降低1。
If the decremented HopLimit equals 0, the Interest MUST NOT be forwarded to another forwarder; it MAY be sent to a local publisher application or serviced from a local Content Store.
如果递减的HopLimit等于0，则利息不得转发给其他转发商；它可以发送到本地发布者应用程序，也可以从本地内容存储提供服务。
A RECOMMENDED HopLimit-processing pipeline is below:
建议的HopLimit处理管道如下：
o If Interest received from a remote system:
o 如果从远程系统收到利息：
* If received HopLimit is 0, optionally send Interest Return (HopLimit Exceeded), and discard Interest.
* 如果收到的HopLimit为0，则可以选择发送利息回报（超过HopLimit），并放弃利息。
* Otherwise, decrement the HopLimit by 1.
* 否则，将HopLimit减小1。
o Process as per Content Store and Aggregation rules.
o 按照内容存储和聚合规则进行处理。
o If the Interest will be forwarded:
o 如果将转交利息：
* If the (potentially decremented) HopLimit is 0, restrict forwarding to the local system.
* 如果（可能减少的）跃点限制为0，则限制转发到本地系统。
* Otherwise, forward as desired to local or remote systems.
* 否则，根据需要转发到本地或远程系统。
Interest aggregation is when a forwarder receives an Interest message that could be satisfied by the response to another Interest message already forwarded by the node, so the forwarder suppresses forwarding the new Interest; it only records the additional previous hop so a Content Object sent in response to the first Interest will satisfy both Interests.
兴趣聚合是指转发器接收到一条兴趣消息，该消息可以通过对节点已经转发的另一条兴趣消息的响应来满足，因此转发器禁止转发新兴趣；它只记录额外的前一跳，因此响应第一个兴趣发送的内容对象将满足两个兴趣。
CCNx uses an Interest aggregation rule that assumes the InterestLifetime is akin to a subscription time and is not a network round-trip time. Some previous aggregation rules assumed the lifetime was a round-trip time, but this leads to problems of expiring an Interest before a response comes if the RTT is estimated too short or interfering with an Automatic Repeat reQuest (ARQ) scheme that wants to retransmit an Interest but a prior Interest overestimated the RTT.
CCNx使用一个兴趣聚合规则，该规则假设兴趣生命周期类似于订阅时间，而不是网络往返时间。一些先前的聚合规则假设生存期是往返时间，但如果RTT估计太短或干扰了想要重新传输兴趣但先前兴趣高估RTT的自动重复请求（ARQ）方案，则这会导致在响应到来之前过期兴趣的问题。
A forwarder MAY implement an Interest aggregation scheme. If it does not, then it will forward all Interest messages. This does not imply that multiple, possibly identical, Content Objects will come back. A forwarder MUST still satisfy all pending Interests, so one Content Object could satisfy multiple similar Interests, even if the forwarder did not suppress duplicate Interest messages.
转发器可以实现利益聚合方案。如果没有，那么它将转发所有感兴趣的消息。这并不意味着将返回多个可能相同的内容对象。转发器仍然必须满足所有未决的兴趣，因此一个内容对象可以满足多个类似的兴趣，即使转发器没有抑制重复的兴趣消息。
A RECOMMENDED Interest aggregation scheme is:
建议的利息汇总计划是：
o Two Interests are considered "similar" if they have the same Name, KeyIdRestr, and ContentObjectHashRestr, where a missing optional field in one must be missing in the other.
o 如果两个兴趣点具有相同的名称KeyIDRest和ContentObjectHashRest，则它们被视为“相似”，其中一个兴趣点中缺失的可选字段必须在另一个兴趣点中缺失。
o Let the notional value InterestExpiry (a local value at the forwarder) be equal to the receive time plus the InterestLifetime (or a platform-dependent default value if not present).
o 假设名义值InterestExpiry（转发器的本地值）等于接收时间加上InterestLifetime（或平台相关的默认值，如果不存在）。
o An Interest record (PIT entry) is considered invalid if its InterestExpiry time is in the past.
o 如果利息记录（PIT条目）的利息支付时间在过去，则该利息记录被视为无效。
o The first reception of an Interest MUST be forwarded.
o 必须转发首次收到的利息。
o A second or later reception of an Interest similar to a valid pending Interest from the same previous hop MUST be forwarded. We consider these a retransmission request.
o 必须转发第二次或以后接收到的与来自同一前一跳的有效未决利息类似的利息。我们认为这些是重传请求。
o A second or later reception of an Interest similar to a valid pending Interest from a new previous hop MAY be aggregated (not forwarded). If this Interest has a larger HopLimit than the pending Interest, it MUST be forwarded.
o 与来自新的前一跳的有效未决兴趣类似的兴趣的第二次或以后接收可以被聚合（不转发）。如果该利息的上限大于未决利息，则必须转发该利息。
o Aggregating an Interest MUST extend the InterestExpiry time of the Interest record. An implementation MAY keep a single InterestExpiry time for all previous hops or MAY keep the InterestExpiry time per previous hop. In the first case, the forwarder might send a Content Object down a path that is no longer waiting for it, in which case the previous hop (next hop of the Content Object) would drop it.
o 合计利息必须延长利息记录的利息支付时间。一个实现可以为所有前一跳保留一个interestepiry时间，或者可以为每个前一跳保留interestepiry时间。在第一种情况下，转发器可能会沿着不再等待它的路径发送内容对象，在这种情况下，前一跳（内容对象的下一跳）会将其丢弃。
The Content Store is a special cache that is an integral part of a CCNx forwarder. It is an optional component. It serves to repair lost packets and handle flash requests for popular content. It could be prepopulated or use opportunistic caching. Because the Content Store could serve to amplify an attack via cache poisoning, there are special rules about how a Content Store behaves.
内容存储是一个特殊的缓存，是CCNx转发器不可分割的一部分。它是一个可选组件。它用于修复丢失的数据包并处理流行内容的闪存请求。它可以预先填充或使用机会主义缓存。因为内容存储可以通过缓存中毒放大攻击，所以有一些关于内容存储行为的特殊规则。
1. A forwarder MAY implement a Content Store. If it does, the Content Store matches a Content Object to an Interest via the normal matching rules (see Section 9).
1. 转发器可以实现内容存储。如果是，内容存储将通过普通匹配规则将内容对象与兴趣匹配（请参见第9节）。
2. If an Interest has a KeyId restriction, then the Content Store MUST NOT reply unless it knows the signature on the matching Content Object is correct. It may do this by external knowledge (i.e., in a managed network or system with prepopulated caches) or by having the public key and cryptographically verifying the signature. A Content Store is NOT REQUIRED to verify signatures; if it does not, then it treats these cases like a cache miss.
2. 如果某个兴趣具有KeyId限制，则内容存储必须不回复，除非它知道匹配内容对象上的签名是正确的。它可以通过外部知识（即，在具有预填充缓存的受管网络或系统中）或通过公钥和密码验证签名来实现这一点。内容存储不需要验证签名；如果没有，则会将这些情况视为缓存未命中。
3. If a Content Store chooses to verify signatures, then it MAY do so as follows. If the public key is provided in the Content Object itself (i.e., in the PublicKey field) or in the Interest, the Content Store MUST verify that the public key's hash is equal to the KeyId and that it verifies the signature (see Section 8.4). A Content Store MAY verify the digital signature of a Content Object before it is cached, but it is not required to do so. A Content Store SHOULD NOT fetch keys over the network. If it cannot or has not yet verified the signature, it should treat the Interest as a cache miss.
3. 如果内容存储选择验证签名，那么它可以按如下方式进行验证。如果公钥是在内容对象本身（即，在公钥字段中）或兴趣中提供的，则内容存储必须验证公钥的散列是否等于密钥ID，并验证签名（参见第8.4节）。内容存储可以在缓存内容对象之前验证其数字签名，但不需要这样做。内容存储不应通过网络获取密钥。如果无法或尚未验证签名，则应将感兴趣的内容视为缓存未命中。
4. If an Interest has a Content Object Hash restriction, then the Content Store MUST NOT reply unless it knows the matching Content Object has the correct hash. If it cannot verify the hash, then it should treat the Interest as a cache miss.
4. 如果某个兴趣具有内容对象哈希限制，则内容存储必须不回复，除非它知道匹配的内容对象具有正确的哈希。如果无法验证哈希，则应将该兴趣视为缓存未命中。
5. It must obey the cache control directives (see Section 4).
5. 它必须遵守缓存控制指令（参见第4节）。
1. Perform the HopLimit check (see Section 2.4.1).
1. 执行跳跃极限检查（见第2.4.1节）。
2. If the Interest carries a validation, such as a MIC or a signature with an embedded public key or certificate, a forwarder MAY validate the Interest as per Section 8. A forwarder SHOULD NOT fetch keys via a KeyLink. If the forwarder drops an Interest
2. 如果权益带有验证，如MIC或带有嵌入公钥或证书的签名，则转发商可根据第8节验证权益。转发器不应通过KeyLink获取密钥。如果货运代理人放弃了一项利益
due to failed validation, it MAY send an Interest Return (Section 10.3.9).
由于验证失败，可能会发送利息申报表（第10.3.9节）。
3. Determine if the Interest can be aggregated as per Section 2.4.2. If it can be, aggregate and do not forward the Interest.
3. 确定利息是否可以按照第2.4.2节进行汇总。如果可以，则进行汇总，不进行利息远期。
4. If forwarding the Interest, check for a hit in the Content Store as per Section 2.4.3. If a matching Content Object is found, return it to the Interest's previous hop. This injects the Content Store as per Section 2.4.5.
4. 如果转发兴趣，请根据第2.4.3节检查内容存储中的点击。如果找到匹配的内容对象，则将其返回到感兴趣的上一个跃点。这将根据第2.4.5节注入内容存储。
5. Look up the Interest in the FIB. Longest Prefix Match (LPM) is performed name segment by name segment (not byte or bit). It SHOULD exclude the Interest's previous hop. If a match is found, forward the Interest. If no match is found or the forwarder chooses not to forward due to a local condition (e.g., congestion), it SHOULD send an Interest Return message as per Section 10.
5. 查一下对谎言的兴趣。最长前缀匹配（LPM）是按名称段逐名称段（而不是字节或位）执行的。它应该排除兴趣的前一跳。如果找到匹配项，则转发利息。如果未找到匹配项，或者由于本地条件（例如拥塞），转发器选择不转发，则应根据第10节发送利息返还消息。
1. It is RECOMMENDED that a forwarder that receives a Content Object check that the Content Object came from an expected previous hop. An expected previous hop is one pointed to by the FIB or one recorded in the PIT as having had a matching Interest sent that way.
1. 建议接收内容对象的转发器检查内容对象是否来自预期的前一跳。预期的前一个跃点是FIB指出的跃点或PIT中记录的以这种方式发送匹配兴趣的跃点。
2. A Content Object MUST be matched to all pending Interests that satisfy the matching rules (see Section 9). Each satisfied pending Interest MUST then be removed from the set of pending Interests.
2. 内容对象必须与满足匹配规则的所有未决兴趣相匹配（参见第9节）。然后，必须从待决权益集合中删除每个已满足的待决权益。
3. A forwarder SHOULD NOT send more than one copy of the received Content Object to the same Interest previous hop. It may happen, for example, that two Interests ask for the same Content Object in different ways (e.g., by name and by name and KeyId), and that they both come from the same previous hop. It is normal to send the same Content Object multiple times on the same interface, such as Ethernet, if it is going to different previous hops.
3. 转发器不应将接收到的内容对象的多个副本发送给同一个感兴趣的前一跳。例如，两个兴趣可能以不同的方式（例如，通过名称、名称和KeyId）请求相同的内容对象，并且它们都来自相同的前一跳。如果同一内容对象要发送到不同的前一个跃点，则在同一接口（如以太网）上多次发送同一内容对象是正常的。
4. A Content Object SHOULD only be put in the Content Store if it satisfied an Interest (and passed rule #1 above). This is to reduce the chances of cache poisoning.
4. 仅当内容对象满足兴趣（并通过上述规则1）时，才应将其放入内容存储中。这是为了减少缓存中毒的机会。
A CCNx name is a composition of name segments. Each name segment carries a label identifying the purpose of the name segment, and a value. For example, some name segments are general names and some serve specific purposes such as carrying version information or the sequencing of many chunks of a large object into smaller, signed Content Objects.
CCNx名称由名称段组成。每个名称段都带有一个标识名称段用途的标签和一个值。例如，有些名称段是通用名称，有些用于特定目的，例如携带版本信息或将大型对象的许多块排序为较小的签名内容对象。
There are three different types of names in CCNx: prefix, exact, and full names. A prefix name is simply a name that does not uniquely identify a single Content Object, but rather a namespace or prefix of an existing Content Object name. An exact name is one that uniquely identifies the name of a Content Object. A full name is one that is exact and is accompanied by an explicit or implicit ConObjHash. The ConObjHash is explicit in an Interest and implicit in a Content Object.
CCNx中有三种不同类型的名称：前缀、确切名称和全名。前缀名称只是一个名称，它不是唯一标识单个内容对象的名称，而是现有内容对象名称的命名空间或前缀。确切名称是唯一标识内容对象名称的名称。全名是一个确切的名称，并伴有显式或隐式的ConObjHash。ConObjHash在兴趣中是显式的，在内容对象中是隐式的。
Note that a forwarder does not need to know any semantics about a name. It only needs to be able to match a prefix to forward Interests and match an exact or full name to forward Content Objects. It is not sensitive to the name segment types.
请注意，转发器不需要知道名称的任何语义。它只需要能够匹配前缀以转发兴趣，并匹配准确或全名以转发内容对象。它对名称段类型不敏感。
The name segment labels specified in this document are given in Table 1. Name Segment is a general name segment, typically occurring in the routable prefix and user-specified content name. Interest Payload ID is a name segment to identify the Interest's payload. Application Components are a set of name segment types reserved for application use.
本文件中指定的名称段标签如表1所示。名称段是通用名称段，通常出现在可路由前缀和用户指定的内容名称中。兴趣负载ID是用于标识兴趣负载的名称段。应用程序组件是保留给应用程序使用的一组名称段类型。
+-------------+-----------------------------------------------------+
| Type | Description |
+-------------+-----------------------------------------------------+
| Name | A generic name segment that includes arbitrary |
| Segment | octets. |
| | |
| Interest | An octet string that identifies the payload carried |
| Payload ID | in an Interest. As an example, the Payload ID |
| | might be a hash of the Interest Payload. This |
| | provides a way to differentiate between Interests |
| | based on the payload solely through a name segment |
| | without having to include all the extra bytes of |
| | the payload itself. |
| | |
| Application | An application-specific payload in a name segment. |
| Components | An application may apply its own semantics to these |
| | components. A good practice is to identify the |
| | application in a name segment prior to the |
| | application component segments. |
+-------------+-----------------------------------------------------+
+-------------+-----------------------------------------------------+
| Type | Description |
+-------------+-----------------------------------------------------+
| Name | A generic name segment that includes arbitrary |
| Segment | octets. |
| | |
| Interest | An octet string that identifies the payload carried |
| Payload ID | in an Interest. As an example, the Payload ID |
| | might be a hash of the Interest Payload. This |
| | provides a way to differentiate between Interests |
| | based on the payload solely through a name segment |
| | without having to include all the extra bytes of |
| | the payload itself. |
| | |
| Application | An application-specific payload in a name segment. |
| Components | An application may apply its own semantics to these |
| | components. A good practice is to identify the |
| | application in a name segment prior to the |
| | application component segments. |
+-------------+-----------------------------------------------------+
Table 1: CCNx Name Segment Types
表1:CCNx名称段类型
At the lowest level, a forwarder does not need to understand the semantics of name segments; it need only identify name segment boundaries and be able to compare two name segments (both label and value) for equality. The forwarder matches names segment by segment against its forwarding table to determine a next hop.
在最底层，转发器不需要理解名称段的语义；它只需要标识名称段边界，并能够比较两个名称段（标签和值）是否相等。转发器根据其转发表逐段匹配名称，以确定下一个跃点。
This section uses the CCNx URI [ccnx-uri] representation of CCNx names. Note that as per the message grammar, an Interest must have a Name with at least one name segment that must have at least 1 octet of value. A Content Object must have a similar name or no name at all. The FIB, on the other hand, could have 0-length names (a default route), or a first name segment with no value, or a regular name.
本节使用CCNx名称的CCNx URI[CCNx URI]表示。请注意，根据消息语法，兴趣必须具有至少一个名称段的名称，该名称段必须具有至少1个八进制值。内容对象必须具有类似的名称或根本没有名称。另一方面，FIB可以有长度为0的名称（默认路由），或没有值的名字段，或常规名称。
+--------------------------+----------------------------------------+
| Name | Description |
+--------------------------+----------------------------------------+
| ccnx:/ | A 0-length name, corresponds to a |
| | default route. |
| | |
| ccnx:/NAME= | A name with 1 segment of 0 length, |
| | distinct from ccnx:/. |
| | |
| ccnx:/NAME=foo/APP:0=bar | A 2-segment name, where the first |
| | segment is of type NAME and the second |
| | segment is of type APP:0. |
+--------------------------+----------------------------------------+
+--------------------------+----------------------------------------+
| Name | Description |
+--------------------------+----------------------------------------+
| ccnx:/ | A 0-length name, corresponds to a |
| | default route. |
| | |
| ccnx:/NAME= | A name with 1 segment of 0 length, |
| | distinct from ccnx:/. |
| | |
| ccnx:/NAME=foo/APP:0=bar | A 2-segment name, where the first |
| | segment is of type NAME and the second |
| | segment is of type APP:0. |
+--------------------------+----------------------------------------+
Table 2: CCNx Name Examples
表2:CCNx名称示例
An Interest may also have a Payload field that carries state about the Interest but is not used to match a Content Object. If an Interest contains a payload, the Interest name should contain an Interest Payload ID (IPID). The IPID allows a PIT entry to correctly multiplex Content Objects in response to a specific Interest with a specific payload ID. The IPID could be derived from a hash of the payload or could be a Globally Unique Identifier (GUID) or a nonce. An optional Metadata field defines the IPID field so other systems can verify the IPID, such as when it is derived from a hash of the payload. No system is required to verify the IPID.
兴趣还可以具有有效载荷字段，该字段承载关于兴趣的状态，但不用于匹配内容对象。如果兴趣包含有效负载，则兴趣名称应包含兴趣有效负载ID（IPID）。IPID允许PIT条目正确地多路传输内容对象，以响应具有特定负载ID的特定兴趣。IPID可以从负载哈希派生，也可以是全局唯一标识符（GUID）或nonce。可选的元数据字段定义了IPID字段，以便其他系统可以验证IPID，例如当它是从有效负载的散列中派生出来时。无需系统验证IPID。
CCNx supports two fields that affect cache control. These determine how a cache or Content Store handles a Content Object. They are not used in the fast path; they are only used to determine if a Content Object can be injected onto the fast path in response to an Interest.
CCNx支持影响缓存控制的两个字段。它们决定缓存或内容存储如何处理内容对象。它们不用于快速路径；它们仅用于确定是否可以将内容对象注入快速路径以响应兴趣。
The ExpiryTime is a field that exists within the signature envelope of a Validation Algorithm. It is the UTC time in milliseconds after
ExpiryTime是存在于验证算法的签名信封中的字段。它是UTC时间，以毫秒为单位
which the Content Object is considered expired and MUST no longer be used to respond to an Interest from a cache. Stale content MAY be flushed from the cache.
内容对象被认为已过期，不能再用于响应来自缓存的兴趣。过时的内容可能会从缓存中刷新。
The Recommended Cache Time (RCT) is a field that exists outside the signature envelope. It is the UTC time in milliseconds after which the publisher considers the Content Object to be of low value to cache. A cache SHOULD discard it after the RCT, though it MAY keep it and still respond with it. A cache MAY also discard the Content Object before the RCT time; there is no contractual obligation to remember anything.
建议的缓存时间（RCT）是存在于签名信封之外的字段。它是UTC时间（以毫秒为单位），在该时间之后，发布者认为内容对象的缓存值较低。缓存应该在RCT之后丢弃它，尽管它可能会保留它并仍然使用它进行响应。缓存还可以在RCT时间之前丢弃内容对象；合同没有义务记住任何事情。
This formulation allows a producer to create a Content Object with a long ExpiryTime but short RCT and keep republishing the same signed Content Object over and over again by extending the RCT. This allows a form of "phone home" where the publisher wants to periodically see that the content is being used.
此公式允许生产者创建一个过期时间长但RCT短的内容对象，并通过扩展RCT不断地重新发布同一签名内容对象。这允许一种形式的“呼叫总部”，出版商希望定期查看内容是否被使用。
CCNx allows an Interest to restrict a response to a specific hash. The hash covers the Content Object message body and the validation sections, if present. Thus, if a Content Object is signed, its hash includes that signature value. The hash does not include the fixed or hop-by-hop headers of a Content Object. Because it is part of the matching rules (see Section 9), the hash is used at every hop.
CCNx允许兴趣限制对特定哈希的响应。散列包含内容对象消息体和验证部分（如果存在）。因此，如果对内容对象进行了签名，则其哈希包含该签名值。哈希不包括内容对象的固定或逐跳标头。因为它是匹配规则的一部分（参见第9节），所以在每个跃点使用哈希。
There are two options for matching the Content Object Hash restriction in an Interest. First, a forwarder could compute for itself the hash value and compare it to the restriction. This is an expensive operation. The second option is for a border device to compute the hash once and place the value in a header (ConObjHash) that is carried through the network. The second option, of course, removes any security properties from matching the hash, so it SHOULD only be used within a trusted domain. The header SHOULD be removed when crossing a trust boundary.
有两个选项可用于匹配兴趣中的内容对象哈希限制。首先，转发器可以自己计算散列值并将其与限制进行比较。这是一项昂贵的手术。第二个选项是边界设备计算一次散列，并将值放入通过网络传输的报头（ConObjHash）中。当然，第二个选项将删除与哈希匹配的任何安全属性，因此它只应在受信任域中使用。当跨越信任边界时，应删除标头。
A Link is the tuple {Name, [KeyIdRestr], [ContentObjectHashRestr]}. The information in a Link comprises the fields of an Interest that would retrieve the Link target. A Content Object with PayloadType of "Link" is an object whose payload is one or more Links. This tuple may be used as a KeyLink to identify a specific object with the certificate-wrapped key. It is RECOMMENDED to include at least one of either KeyId restriction or Content Object Hash restriction. If neither restriction is present, then any Content Object with a matching name from any publisher could be returned.
链接是元组{Name，[KeyIdRestr]，[ContentObjectHashRestr]}。链接中的信息包括检索链接目标的感兴趣字段。PayloadType为“Link”的内容对象是其有效负载为一个或多个链接的对象。此元组可用作密钥链接，以标识具有证书包装密钥的特定对象。建议至少包括KeyId限制或内容对象哈希限制中的一个。如果两个限制都不存在，则可以返回任何发布者提供的具有匹配名称的任何内容对象。
Several protocol fields use cryptographic hash functions, which must be secure against attack and collisions. Because these hash functions change over time, with better ones appearing and old ones falling victim to attacks, it is important that a CCNx protocol implementation supports hash agility.
几个协议字段使用加密哈希函数，这些函数必须能够防止攻击和冲突。由于这些散列函数会随着时间的推移而变化，更好的函数会出现，而旧的函数会成为攻击的受害者，因此CCNx协议实现支持散列灵活性非常重要。
In this document, we suggest certain hashes (e.g., SHA-256), but a specific implementation may use what it deems best. The normative CCNx Messages [RFC8609] specification should be taken as the definition of acceptable hash functions and uses.
在本文档中，我们建议使用某些哈希（例如SHA-256），但具体实现可能使用它认为最好的方法。标准CCNx消息[RFC8609]规范应被视为可接受散列函数和用途的定义。
The Validator consists of a ValidationAlgorithm that specifies how to verify the message and a ValidationPayload containing the validation output, e.g., the digital signature or MAC. The ValidationAlgorithm section defines the type of algorithm to use and includes any necessary additional information. The validation is calculated from the beginning of the CCNx Message through the end of the ValidationAlgorithm section (i.e., up to but not including the validation payload). We refer to this as the validation region. The ValidationPayload is the integrity value bytes, such as a MAC or signature.
验证器由指定如何验证消息的ValidationGorithm和包含验证输出的ValidationPayload（例如，数字签名或MAC）组成。ValidationAlgorithm部分定义要使用的算法类型，并包括任何必要的附加信息。验证从CCNx消息的开始到ValidationGorithm部分的结束（即，直到但不包括验证有效负载）进行计算。我们称之为验证区域。ValidationPayload是完整性值字节，例如MAC或签名。
The CCNx Message Grammar (Section 2.1) shows the allowed validation algorithms and their structure. In the case of a Vendor algorithm, the vendor may use any desired structure. A Validator can only be applied to an Interest or a Content Object, not an Interest Return. An Interest inside an Interest Return would still have the original validator, if any.
CCNx消息语法（第2.1节）显示了允许的验证算法及其结构。在供应商算法的情况下，供应商可以使用任何期望的结构。验证器只能应用于兴趣或内容对象，而不能应用于兴趣返回。利息申报表中的利息仍然具有原始验证器（如果有的话）。
The grammar allows multiple Vendor extensions to the validation algorithm. It is up to the vendor to describe the validation region for each extension. A vendor may, for example, use a regular signature in the validation algorithm, then append a proprietary MIC to allow for in-network error checking without using expensive signature verification. As part of this specification, we do not allow for multiple Validation Algorithm blocks apart from these vendor methods.
语法允许对验证算法进行多个供应商扩展。供应商负责描述每个扩展的验证区域。例如，供应商可以在验证算法中使用常规签名，然后附加一个专有的MIC，以允许在不使用昂贵的签名验证的情况下进行网络内错误检查。作为本规范的一部分，除了这些供应商方法之外，我们不允许使用多个验证算法块。
If the validation algorithm is CRC32C, then the validation payload is the output of the CRC over the validation region. This validation algorithm allows for an optional signature time (SigTime) to timestamp when the message was validated (calling it a "signature" time is a slight misnomer, but we reuse the same field for this purpose between MICs, MACs, and signatures).
如果验证算法是CRC32C，则验证有效负载是验证区域上CRC的输出。此验证算法允许在验证消息时使用可选的签名时间（SigTime）来标记时间戳（称之为“签名”时间有点用词不当，但我们在MIC、MAC和签名之间重复使用相同的字段）。
MICs are usually used with an Interest to avoid accidental in-network corruption. They are usually not used on Content Objects because the objects are either signed or linked to by hash chains, so the CRC32C is redundant.
MIC的使用通常是为了避免意外的网络损坏。它们通常不用于内容对象，因为对象通过哈希链进行签名或链接，因此CRC32C是冗余的。
If the validation algorithm is HMAC-SHA256, then the validation payload is the output of the HMAC over the validation region. The validation algorithm requires a KeyId and allows for a signature time (SigTime) and KeyLink.
如果验证算法为HMAC-SHA256，则验证有效负载是HMAC在验证区域上的输出。验证算法需要密钥ID，并允许签名时间（SigTime）和密钥链接。
The KeyId field identifies the shared secret used between two parties to authenticate messages. These secrets SHOULD be derived from a key exchange protocol such as [ccnx-ke]. The KeyId, for a shared secret, SHOULD be an opaque identifier not derived from the actual key; an integer counter, for example, is a good choice.
KeyId字段标识双方用于验证消息的共享秘密。这些秘密应该来自密钥交换协议，如[ccnx ke]。对于共享密钥，KeyId应该是一个不透明的标识符，而不是从实际密钥派生的；例如，整数计数器是一个不错的选择。
The signature time is the timestamp when the authentication code was computed and added to the messages.
签名时间是计算身份验证代码并将其添加到消息时的时间戳。
The KeyLink field in a MAC indicates how to negotiate keys and should point towards the key exchange endpoint. The use of a key negotiation algorithm is beyond the scope of this specification, and a key negotiation algorithm is not required to use this field.
MAC中的KeyLink字段指示如何协商密钥，并应指向密钥交换端点。密钥协商算法的使用超出了本规范的范围，使用此字段不需要密钥协商算法。
Signature-validation algorithms use public key cryptographic algorithms such as RSA and the Elliptic Curve Digital Signature Algorithm (ECDSA). This specification and the corresponding wire encoding [RFC8609] only support three specific signature algorithms: RSA-SHA256, EC-SECP-256K1, and EC-SECP-384R1. Other algorithms may be added in through other documents or by using experimental or vendor-validation algorithm types.
签名验证算法使用公钥密码算法，如RSA和椭圆曲线数字签名算法（ECDSA）。本规范和相应的有线编码[RFC8609]仅支持三种特定的签名算法：RSA-SHA256、EC-SECP-256K1和EC-SECP-384R1。其他算法可通过其他文档或使用实验或供应商验证算法类型添加。
A signature that is public key based requires a KeyId field and may optionally carry a signature time, an embedded public key, an embedded certificate, and a KeyLink. The signature time behaves as normal to timestamp when the signature was created. We describe the use and relationship of the other fields here.
基于公钥的签名需要KeyId字段，并且可以选择携带签名时间、嵌入公钥、嵌入证书和密钥链接。签名时间的行为与创建签名时的时间戳相同。我们在此描述其他字段的使用和关系。
It is not common to use embedded certificates, as they can be very large and may have validity periods different than the validated data. The preferred method is to use a KeyLink to the validating certificate.
使用嵌入式证书并不常见，因为它们可能非常大，并且有效期可能与验证数据不同。首选方法是使用验证证书的密钥链接。
The KeyId field in the ValidationAlgorithm identifies the public key used to verify the signature. It is similar to a Subject Key Identifier from X.509 (Section 4.2.1.2 of [RFC5280]). We define the KeyId to be a cryptographic hash of the public key in DER form. All implementations MUST support the SHA-256 digest as the KeyId hash.
ValidationAlgorithm中的KeyId字段标识用于验证签名的公钥。它类似于X.509（RFC5280第4.2.1.2节）中的主题密钥标识符。我们将KeyId定义为DER形式的公钥加密散列。所有实现都必须支持SHA-256摘要作为密钥ID哈希。
The use of other algorithms for the KeyId is allowed, and it will not cause problems at a forwarder because the forwarder only matches the digest algorithm and digest output and does not compute the digest (see Section 9). It may cause issues with a Content Store, which needs to verify the KeyId and PublicKey match (see Section 2.4.3); though in this case, it only causes a cache miss and the Interest would still be forwarded to the publisher. As long as the publisher and consumers support the hash, data will validate.
允许对KeyId使用其他算法，这不会在转发器上造成问题，因为转发器只匹配摘要算法和摘要输出，而不计算摘要（参见第9节）。它可能会导致内容存储出现问题，内容存储需要验证密钥ID和公钥匹配（参见第2.4.3节）；尽管在这种情况下，它只会导致缓存未命中，而且兴趣仍然会转发给发布服务器。只要发布者和使用者支持散列，数据就会被验证。
As per Section 9, a forwarder only matches the KeyId to a KeyId restriction. It does not need to look at the other fields such as the public key, certificate, or KeyLink.
根据第9节，转发器仅将密钥ID与密钥ID限制相匹配。它不需要查看其他字段，例如公钥、证书或密钥链接。
If a message carries multiples of the KeyId, public key, certificate, or KeyLink, an endpoint (consumer, cache, or Content Store) MUST ensure that any fields it uses are consistent. The KeyId MUST be the corresponding hash of the embedded public key or certificate public key. The hash function to use is the KeyId's HashType. If there is both an embedded public key and a certificate, the public keys MUST be the same.
若消息包含多个密钥ID、公钥、证书或密钥链接，则端点（使用者、缓存或内容存储）必须确保其使用的任何字段都是一致的。KeyId必须是嵌入公钥或证书公钥的相应哈希。要使用的哈希函数是KeyId的HashType。如果同时存在嵌入公钥和证书，则公钥必须相同。
A message SHOULD NOT have both a PublicKey and a KeyLink to a public key, as that is redundant. It MAY have a PublicKey and a KeyLink to a certificate.
消息不应同时具有公钥和指向公钥的密钥链接，因为这是多余的。它可能具有公钥和指向证书的密钥链接。
A KeyLink in a first Content Object may point to a second Content Object with a DER-encoded public key in the PublicKey field and an optional DER-encoded X.509 certificate in the payload. The second Content Object's KeyId MUST equal the first object's KeyId. The second object's PublicKey field MUST be the public key corresponding to the KeyId. That key must validate both the first and second
第一内容对象中的密钥链接可以指向第二内容对象，该第二内容对象在公钥字段中具有DER编码的公钥，在有效载荷中具有可选的DER编码的X.509证书。第二个内容对象的KeyId必须等于第一个对象的KeyId。第二个对象的公钥字段必须是与KeyId对应的公钥。该密钥必须同时验证第一个和第二个密钥
object's signature. A DER-encoded X.509 certificate may be included in the second object's payload and its embedded public key MUST match the PublicKey. It must be issued by a trusted authority, preferably specifying the valid namespace of the key in the distinguished name. The second object MUST NOT have a KeyLink; we do not allow for recursive key lookup.
对象的签名。DER编码的X.509证书可以包含在第二个对象的有效载荷中，并且其嵌入的公钥必须与公钥匹配。它必须由受信任的机构颁发，最好在可分辨名称中指定密钥的有效命名空间。第二个对象不能有键链接；我们不允许递归键查找。
A Content Object satisfies an Interest if and only if (a) the Content Object name, if present, exactly matches the Interest name, (b) the ValidationAlgorithm KeyId of the Content Object exactly equals the Interest KeyId restriction, if present, and (c) the computed Content Object Hash exactly equals the Interest Content Object Hash restriction, if present.
当且仅当（A）内容对象名称（如果存在）与兴趣名称完全匹配，（b）内容对象的ValidationAlgorithm KeyId完全等于兴趣KeyId限制（如果存在）和（c）计算的内容对象哈希完全等于兴趣内容对象哈希限制时，内容对象才满足兴趣，如果有。
The KeyId and KeyIdRestr use the Hash format (see Section 2.1). The Hash format has an embedded HashType followed by the hash value. When comparing a KeyId and KeyIdRestr, one compares both the HashType and the value.
KeyId和KeyIdRestr使用散列格式（见第2.1节）。哈希格式有一个内嵌的哈希类型，后跟哈希值。在比较KeyId和KeyIdRestr时，将同时比较HashType和值。
The matching rules are given by this predicate, which, if it evaluates true, means the Content Object matches the Interest. Ni = Name in the Interest (may not be empty), Ki = KeyIdRestr in the Interest (may be empty), and Hi = ContentObjectHashRestr in the Interest (may be empty). Likewise, No, Ko, and Ho are those properties in the Content Object, where No and Ko may be empty; Ho always exists (it is an intrinsic property of the Content Object). For binary relations, we use "&" for AND and "|" for OR. We use "E" for the EXISTS (not empty) operator and "!" for the NOT EXISTS operator.
匹配规则由该谓词给出，如果其计算结果为true，则表示内容对象与兴趣匹配。Ni=兴趣中的Name（可能不为空），Ki=兴趣中的KeyIdRestr（可能为空），Hi=兴趣中的contentobjecthashrest（可能为空）。同样，No、Ko和Ho是内容对象中的属性，其中No和Ko可能为空；Ho始终存在（它是内容对象的固有属性）。对于二进制关系，我们使用“&”表示和“|”表示或。我们对EXISTS（非空）操作符使用“E”，对notexists操作符使用“！”。
As a special case, if the Content Object Hash restriction in the Interest specifies an unsupported hash algorithm, then no Content Object can match the Interest, so the system should drop the Interest and MAY send an Interest Return to the previous hop. In this case, the predicate below will never get executed because the Interest is never forwarded. If the system is using the optional behavior of having a different system calculate the hash for it, then the system may assume all hash functions are supported and leave it to the other system to accept or reject the Interest.
作为一种特殊情况，如果兴趣中的内容对象哈希限制指定了不受支持的哈希算法，则任何内容对象都无法匹配兴趣，因此系统应放弃兴趣，并可能向上一跳发送兴趣返回。在这种情况下，下面的谓词将永远不会执行，因为兴趣永远不会被转发。如果系统正在使用让另一个系统为其计算哈希的可选行为，那么系统可能会假定所有哈希函数都受支持，并将其留给另一个系统来接受或拒绝兴趣。
(!No | (Ni=No)) & (!Ki | (Ki=Ko)) & (!Hi | (Hi=Ho)) & (E No | E Hi)
(!No | (Ni=No)) & (!Ki | (Ki=Ko)) & (!Hi | (Hi=Ho)) & (E No | E Hi)
As one can see, there are two types of attributes one can match. The first term depends on the existence of the attribute in the Content Object while the next two terms depend on the existence of the attribute in the Interest. The last term is the "Nameless Object"
可以看到，有两种类型的属性可以匹配。第一项取决于内容对象中属性的存在，而下两项取决于兴趣对象中属性的存在。最后一个术语是“无名物体”
restriction that states that if a Content Object does not have a Name, then it must match the Interest on at least the Hash restriction.
一种限制，表示如果内容对象没有名称，则它必须至少与哈希限制上的兴趣匹配。
If a Content Object does not carry the Content Object Hash as an expressed field, it must be calculated in network to match against. It is sufficient within an autonomous system to calculate a Content Object Hash at a border router and carry it via trusted means within the autonomous system. If a Content Object ValidationAlgorithm does not have a KeyId, then the Content Object cannot match an Interest with a KeyId restriction.
如果内容对象没有将内容对象哈希作为表示字段携带，则必须在网络中对其进行计算以匹配。在自治系统内，在边界路由器处计算内容对象散列并通过自治系统内的可信方式携带它就足够了。如果内容对象ValidationAlgorithm没有KeyId，则内容对象无法将兴趣与KeyId限制匹配。
This section describes the process whereby a network element may return an Interest message to a previous hop if there is an error processing the Interest. The returned Interest may be further processed at the previous hop or returned towards the Interest origin. When a node returns an Interest, it indicates that the previous hop should not expect a response from that node for the Interest, i.e., there is no PIT entry left at the returning node.
本节描述了当处理感兴趣的消息时，网元可以将感兴趣的消息返回到前一跳的过程。返回的利息可在前一跳进一步处理或返回利息来源。当一个节点返回一个兴趣点时，它表示前一跳不应该期望该节点对该兴趣点做出响应，即，返回的节点上没有剩余的PIT条目。
The returned message maintains compatibility with the existing TLV packet format (a fixed header, optional hop-by-hop headers, and the CCNx Message body). The returned Interest packet is modified in only two ways:
返回的消息保持与现有TLV数据包格式（固定报头、可选逐跳报头和CCNx消息体）的兼容性。仅通过两种方式修改返回的利息数据包：
o The PacketType is set to Interest Return to indicate a Feedback message.
o PacketType设置为Interest Return以指示反馈消息。
o The ReturnCode is set to the appropriate value to signal the reason for the return.
o ReturnCode设置为适当的值，以指示返回的原因。
The specific encodings of the Interest Return are specified in [RFC8609].
利息返还的具体编码在[RFC8609]中指定。
A forwarder is not required to send any Interest Return messages.
转发器不需要发送任何利息返还消息。
A forwarder is not required to process any received Interest Return message. If a forwarder does not process Interest Return messages, it SHOULD silently drop them.
转发器无需处理任何收到的利息返还消息。如果转发器不处理感兴趣的返回消息，它应该默默地删除它们。
The Interest Return message does not apply to a Content Object or any other message type.
利息返回消息不适用于内容对象或任何其他消息类型。
An Interest Return message is a 1-hop message between peers. It is not propagated multiple hops via the FIB. An intermediate node that receives an Interest Return may take corrective actions or may propagate its own Interest Return to previous hops as indicated in the reverse path of a PIT entry.
兴趣返回消息是对等方之间的一跳消息。它不会通过FIB传播多跳。接收利息回报的中间节点可采取纠正措施，或将其自身的利息回报传播到前一跳，如PIT条目的反向路径所示。
The Interest Return message looks exactly like the original Interest message with the exception of the two modifications mentioned above. The PacketType is set to indicate the message is an Interest Return, and the reserved byte in the Interest header is used as a Return Code. The numeric values for the PacketType and ReturnCodes are in [RFC8609].
除了上面提到的两个修改之外，利息返回消息看起来与原始利息消息完全相同。PacketType设置为指示消息是利息返回，利息头中的保留字节用作返回代码。PacketType和ReturnCodes的数值在[RFC8609]中。
This section defines the Interest Return ReturnCode introduced in this RFC. The numeric values used in the packet are defined in [RFC8609].
本节定义了本RFC中引入的利息返还代码。数据包中使用的数值在[RFC8609]中定义。
+----------------------+--------------------------------------------+
| Name | Description |
+----------------------+--------------------------------------------+
| No Route (Section | The returning forwarder has no route to |
| 10.3.1) | the Interest name. |
| | |
| HopLimit Exceeded | The HopLimit has decremented to 0 and |
| (Section 10.3.2) | needs to forward the packet. |
| | |
| Interest MTU too | The Interest's MTU does not conform to the |
| large (Section | required minimum and would require |
| 10.3.3) | fragmentation. |
| | |
| No Resources | The node does not have the resources to |
| (Section 10.3.4) | process the Interest. |
| | |
| Path error (Section | There was a transmission error when |
| 10.3.5) | forwarding the Interest along a route (a |
| | transient error). |
| | |
| Prohibited (Section | An administrative setting prohibits |
| 10.3.6) | processing this Interest. |
| | |
| Congestion (Section | The Interest was dropped due to congestion |
| 10.3.7) | (a transient error). |
| | |
| Unsupported Content | The Interest was dropped because it |
| Object Hash | requested a Content Object Hash |
| Algorithm (Section | restriction using a hash algorithm that |
| 10.3.8) | cannot be computed. |
| | |
| Malformed Interest | The Interest was dropped because it did |
| (Section 10.3.9) | not correctly parse. |
+----------------------+--------------------------------------------+
+----------------------+--------------------------------------------+
| Name | Description |
+----------------------+--------------------------------------------+
| No Route (Section | The returning forwarder has no route to |
| 10.3.1) | the Interest name. |
| | |
| HopLimit Exceeded | The HopLimit has decremented to 0 and |
| (Section 10.3.2) | needs to forward the packet. |
| | |
| Interest MTU too | The Interest's MTU does not conform to the |
| large (Section | required minimum and would require |
| 10.3.3) | fragmentation. |
| | |
| No Resources | The node does not have the resources to |
| (Section 10.3.4) | process the Interest. |
| | |
| Path error (Section | There was a transmission error when |
| 10.3.5) | forwarding the Interest along a route (a |
| | transient error). |
| | |
| Prohibited (Section | An administrative setting prohibits |
| 10.3.6) | processing this Interest. |
| | |
| Congestion (Section | The Interest was dropped due to congestion |
| 10.3.7) | (a transient error). |
| | |
| Unsupported Content | The Interest was dropped because it |
| Object Hash | requested a Content Object Hash |
| Algorithm (Section | restriction using a hash algorithm that |
| 10.3.8) | cannot be computed. |
| | |
| Malformed Interest | The Interest was dropped because it did |
| (Section 10.3.9) | not correctly parse. |
+----------------------+--------------------------------------------+
Table 3: Interest Return Reason Codes
表3：利息返还原因代码
This section describes the forwarder behavior for the various Reason codes for Interest Return. A forwarder is not required to generate any of the codes, but if it does, it MUST conform to this specification.
本节描述了各种利息返还原因代码的转发器行为。货运代理无需生成任何代码，但如果生成，则必须符合本规范。
If a forwarder receives an Interest Return, it SHOULD take these standard corrective actions. A forwarder is allowed to ignore Interest Return messages, in which case its PIT entry would go through normal timeout processes.
如果货运代理收到利息返还，则应采取这些标准纠正措施。允许转发器忽略利息返回消息，在这种情况下，其PIT条目将经历正常的超时过程。
o Verify that the Interest Return came from a next hop to which it actually sent the Interest.
o 验证利息返回是否来自它实际发送利息的下一个跃点。
o If a PIT entry for the corresponding Interest does not exist, the forwarder should ignore the Interest Return.
o 如果相应利息的PIT条目不存在，则货运代理应忽略利息返还。
o If a PIT entry for the corresponding Interest does exist, the forwarder MAY do one of the following:
o 如果存在相应权益的PIT条目，则货代可以执行以下操作之一：
* Try a different forwarding path, if one exists, and discard the Interest Return, or
* 尝试其他转发路径（如果存在），并放弃利息返还，或
* Clear the PIT state and send an Interest Return along the reverse path.
* 清除PIT状态并沿反向路径发送利息回报。
If a forwarder tries alternate routes, it MUST ensure that it does not use the same path multiple times. For example, it could keep track of which next hops it has tried and not reuse them.
如果转发器尝试替代路由，则必须确保它不会多次使用同一路径。例如，它可以跟踪下一次尝试的跳数，而不重复使用它们。
If a forwarder tries an alternate route, it may receive a second Interest Return, possibly of a different type than the first Interest Return. For example, node A sends an Interest to node B, which sends a No Route return. Node A then tries node C, which sends a Prohibited Interest Return. Node A should choose what it thinks is the appropriate code to send back to its previous hop.
如果转发器尝试另一条路线，它可能会收到第二次利息返还，可能与第一次利息返还的类型不同。例如，节点A向节点B发送兴趣，节点B发送无路由返回。节点A然后尝试节点C，后者发送禁止的利息回报。节点A应该选择它认为合适的代码发送回其上一跳。
If a forwarder tries an alternate route, it should decrement the Interest Lifetime to account for the time spent thus far processing the Interest.
如果转发器尝试另一条路线，它应该减少利息生存期，以说明迄今为止处理利息所花费的时间。
If a forwarder receives an Interest for which it has no route, or for which the only route is back towards the system that sent the Interest, the forwarder SHOULD generate a "No Route" Interest Return message.
如果转发器接收到的利息没有路由，或者唯一的路由返回到发送利息的系统，则转发器应生成“无路由”利息返回消息。
How a forwarder manages the FIB table when it receives a No Route message is implementation dependent. In general, receiving a No Route Interest Return should not cause a forwarder to remove a route. The dynamic routing protocol that installed the route should correct the route, or the administrator who created a static route should correct the configuration. A forwarder could suppress using that next hop for some period of time.
转发器在接收到无路由消息时如何管理FIB表取决于实现。一般来说，收到无路线利息回报不应导致转发商删除路线。安装路由的动态路由协议应更正路由，或者创建静态路由的管理员应更正配置。转发器可以在一段时间内禁止使用下一跳。
A forwarder MAY choose to send HopLimit Exceeded messages when it receives an Interest that must be forwarded off system and the HopLimit is 0.
当转发器接收到必须从系统外转发的兴趣并且HopLimit为0时，它可以选择发送超出HopLimit的消息。
If a forwarder receives an Interest whose MTU exceeds the prescribed minimum, it MAY send an "Interest MTU Too Large" message, or it may silently discard the Interest.
如果转发器收到MTU超过规定最小值的利息，它可能会发送“利息MTU太大”消息，或者它可能会自动放弃利息。
If a forwarder receives an "Interest MTU Too Large" response, it SHOULD NOT try alternate paths. It SHOULD propagate the Interest Return to its previous hops.
如果转发器收到“兴趣MTU太大”响应，则不应尝试其他路径。它应该将利息回报传播到以前的跃点。
If a forwarder receives an Interest and it cannot process the Interest due to lack of resources, it MAY send an Interest Return. A lack of resources could mean the PIT is too large or that there is some other capacity limit.
如果货运代理收到利息，但由于缺乏资源而无法处理利息，则可能会发送利息申报单。资源不足可能意味着矿坑太大或存在其他容量限制。
If a forwarder detects an error forwarding an Interest, such as over a reliable link, it MAY send a Path-Error Interest Return indicating that it was not able to send or repair a forwarding error.
如果转发器检测到转发兴趣的错误（例如通过可靠链路），它可能会发送路径错误兴趣返回，指示它无法发送或修复转发错误。
A forwarder may have administrative policies, such as access control lists (ACLs), that prohibit receiving or forwarding an Interest. If a forwarder discards an Interest due to a policy, it MAY send a Prohibited Interest Return to the previous hop. For example, if there is an ACL that says "/example/private" can only come from interface e0, but the forwarder receives one from e1, the forwarder must have a way to return the Interest with an explanation.
转发器可能具有禁止接收或转发兴趣的管理策略，例如访问控制列表（ACL）。如果转发器由于策略而放弃利息，它可能会向上一个跃点发送禁止利息返回。例如，如果有一个ACL表明“/example/private”只能来自接口e0，但转发器从e1收到一个，则转发器必须有一种方法返回利息并给出解释。
If a forwarder discards an Interest due to congestion, it MAY send a Congestion Interest Return to the previous hop.
如果一个转发器由于拥塞而丢弃了一个利息，它可以向上一跳发送一个拥塞利息返回。
If a Content Object Hash restriction specifies a hash algorithm the forwarder cannot verify, the Interest should not be accepted and the forwarder MAY send an Interest Return to the previous hop.
如果内容对象哈希限制指定了转发器无法验证的哈希算法，则不应接受该兴趣，转发器可能会将兴趣返回发送到上一跳。
If a forwarder detects a structural or syntactical error in an Interest, it SHOULD drop the Interest and MAY send an Interest Return to the previous hop. This does not imply that any router must validate the entire structure of an Interest.
如果转发器在某个兴趣中检测到结构或语法错误，它应该放弃该兴趣，并可能向上一跳发送兴趣返回。这并不意味着任何路由器都必须验证感兴趣的整个结构。
This document has no IANA actions.
本文档没有IANA操作。
The CCNx protocol is an L3 network protocol, which may also operate as an overlay using other transports such as UDP or other tunnels. It includes intrinsic support for message authentication via a signature (e.g., RSA or elliptic curve) or message authentication code (e.g., HMAC). In lieu of an authenticator, it may instead use a message integrity check (e.g., SHA or CRC). CCNx does not specify an encryption envelope; that function is left to a high-layer protocol (e.g., [esic]).
CCNx协议是一种L3网络协议，它也可以作为覆盖使用其他传输，如UDP或其他隧道。它包括通过签名（例如RSA或椭圆曲线）或消息身份验证码（例如HMAC）对消息身份验证的内在支持。代替身份验证器，它可以使用消息完整性检查（例如，SHA或CRC）。CCNx未指定加密信封；该功能留给高层协议（例如[esic]）。
The CCNx message format includes the ability to attach MICs (e.g., CRC32C), MACs (e.g., HMAC), and signatures (e.g., RSA or ECDSA) to all packet types. This does not mean that it is a good idea to use an arbitrary ValidationAlgorithm, nor to include computationally expensive algorithms in Interest packets, as that could lead to computational DoS attacks. Applications should use an explicit protocol to guide their use of packet signatures. As a general guideline, an application might use a MIC on an Interest to detect unintentionally corrupted packets. If one wishes to secure an Interest, one should consider using an encrypted wrapper and a protocol that prevents replay attacks, especially if the Interest is being used as an actuator. Simply using an authentication code or signature does not make an Interest secure. There are several examples in the literature on how to secure ICN-style messaging [mobile] [ace].
CCNx消息格式包括将MIC（如CRC32C）、MAC（如HMAC）和签名（如RSA或ECDSA）连接到所有数据包类型的能力。这并不意味着使用任意的ValidationAlgorithm是一个好主意，也不意味着在感兴趣的数据包中包含计算代价高昂的算法，因为这可能导致计算性DoS攻击。应用程序应该使用一个明确的协议来指导数据包签名的使用。一般来说，应用程序可能会在感兴趣的设备上使用麦克风来检测无意中损坏的数据包。如果希望获得兴趣，则应该考虑使用加密包装和防止重放攻击的协议，特别是如果兴趣被用作执行器的话。仅仅使用身份验证码或签名并不能保证利益的安全。文献中有几个例子说明了如何保护ICN风格的消息传递[mobile][ace]。
As an L3 protocol, this document does not describe how one arrives at keys or how one trusts keys. The CCNx Content Object may include a public key or certificate embedded in the object or may use the KeyLink field to point to a public key or certificate that authenticates the message. One key-exchange specification is CCNxKE [ccnx-ke] [mobile], which is similar to the TLS 1.3 key exchange except it is over the CCNx L3 messages. Trust is beyond the scope of an L3 protocol and left to applications or application frameworks.
作为L3协议，本文档不描述如何获得密钥或如何信任密钥。CCNx内容对象可以包括嵌入在对象中的公钥或证书，或者可以使用KeyLink字段指向认证消息的公钥或证书。一个密钥交换规范是CCNxKE[ccnx ke][mobile]，它类似于TLS 1.3密钥交换，只是它通过ccnx L3消息。信任超出了L3协议的范围，留给应用程序或应用程序框架。
The combination of an ephemeral key exchange (e.g., CCNxKE [ccnx-ke]) and an encapsulating encryption (e.g., [esic]) provides the equivalent of a TLS tunnel. Intermediate nodes may forward the Interests and Content Objects but have no visibility inside. It also completely hides the internal names in those used by the encryption layer. This type of tunneling encryption is useful for content that has little or no cacheability, as it can only be used by someone with the ephemeral key. Short-term caching may help with lossy links or mobility, but long-term caching is usually not of interest.
临时密钥交换（例如CCNxKE[ccnx ke]）和封装加密（例如[esic]）的组合提供了TLS隧道的等效性。中间节点可以转发兴趣和内容对象，但内部不可见。它还完全隐藏了加密层使用的内部名称。这种类型的隧道加密对于可缓存性很低或不可缓存的内容很有用，因为它只能由具有临时密钥的人使用。短期缓存可能有助于有损链接或移动性，但长期缓存通常不受关注。
Broadcast encryption or proxy re-encryption may be useful for content with multiple uses over time or many consumers. There is currently no recommendation for this form of encryption.
广播加密或代理重新加密可能对具有随时间变化的多种用途或许多消费者的内容有用。目前没有关于这种加密形式的建议。
The specific encoding of messages will have security implications. [RFC8609] uses a type-length-value (TLV) encoding. We chose to compromise between extensibility and unambiguous encodings of types and lengths. Some TLV encodings use variable-length "T" and variable-length "L" fields to accommodate a wide gamut of values while trying to be byte efficient. Our TLV encoding uses a fixed-length 2-byte "T" and 2-byte "L". Using a fixed-length "T" and "L" field solves two problems. The first is aliases. If one is able to encode the same value, such as %x02 and %x0002, in different byte lengths, then one must decide if they mean the same thing, if they are different, or if one is illegal. If they are different, then one must always compare on the buffers, not the integer equivalents. If one is illegal, then one must validate the TLV encoding, every field of every packet at every hop. If they are the same, then one has the second problem: how to specify packet filters. For example, if a name has 6 name components, then there are 7 T's and 7 L's, each of which might have up to 4 representations of the same value. That would be 14 fields with 4 encodings each, or 1001 combinations. It also means that one cannot compare, for example, a name via a memory function as one needs to consider that any embedded "T" or "L" might have a different format.
消息的特定编码将具有安全含义。[RFC8609]使用类型长度值（TLV）编码。我们选择在可扩展性和类型和长度的明确编码之间进行折衷。一些TLV编码使用可变长度“T”和可变长度“L”字段，以适应广泛的值范围，同时尽量提高字节效率。我们的TLV编码使用固定长度的2字节“T”和2字节“L”。使用固定长度的“T”和“L”字段可以解决两个问题。第一个是别名。如果能够以不同的字节长度对相同的值（如%x02和%x0002）进行编码，则必须确定它们是否表示相同的内容、是否不同或是否非法。如果它们不同，则必须始终在缓冲区上进行比较，而不是在整数等价项上进行比较。如果一个是非法的，那么必须验证TLV编码，每个跃点上每个数据包的每个字段。如果它们相同，那么就有第二个问题：如何指定数据包过滤器。例如，如果一个名称有6个名称组件，则有7个T和7个L，每个T和L最多可以有4个相同值的表示形式。这将是14个字段，每个字段有4个编码，或1001个组合。这也意味着人们不能通过一个记忆函数来比较一个名字，因为需要考虑任何嵌入的“T”或“L”可能有不同的格式。
The Interest Return message has no authenticator from the previous hop. Therefore, the payload of the Interest Return should only be used locally to match an Interest. A node should never forward that
兴趣返回消息没有来自上一跳的验证器。因此，利息回报的有效负载应该只在本地用于匹配利息。节点不应转发该消息
Interest Payload as an Interest. It should also verify that it sent the Interest in the Interest Return to that node and not allow anyone to negate Interest messages.
利息作为一种利息。它还应该验证是否已将兴趣返回中的兴趣发送到该节点，并且不允许任何人否定兴趣消息。
Caching nodes must take caution when processing Content Objects. It is essential that the Content Store obey the rules outlined in Section 2.4.3 to avoid certain types of attacks. CCNx 1.0 has no mechanism to work around an undesired result from the network (there are no "excludes"), so if a cache becomes poisoned with bad content, it might cause problems retrieving content. There are three types of access to content from a Content Store: unrestricted, signature restricted, and hash restricted. If an Interest has no restrictions, then the requester is not particular about what they get back, so any matching cached object is OK. In the hash-restricted case, the requester is very specific about what they want and the Content Store (and every forward hop) can easily verify that the content matches the request. In the signature-restricted case (often used for initial manifest discovery), the requester only knows the KeyId that signed the content. It is this case that requires the closest attention in the Content Store to avoid amplifying bad data. The Content Store must only respond with a Content Object if it can verify the signature; this means either the Content Object carries the public key inside it or the Interest carries the public key in addition to the KeyId. If that is not the case, then the Content Store should treat the Interest as a cache miss and let an endpoint respond.
在处理内容对象时，缓存节点必须小心。内容存储必须遵守第2.4.3节中概述的规则，以避免某些类型的攻击。CCNx 1.0没有机制来处理来自网络的不希望的结果（没有“排除”），因此，如果缓存被坏内容毒害，可能会导致检索内容时出现问题。从内容存储中访问内容有三种类型：无限制、签名限制和哈希限制。如果一个兴趣没有限制，那么请求者对他们返回的内容并不挑剔，所以任何匹配的缓存对象都是可以的。在哈希限制的情况下，请求者非常明确他们想要什么，并且内容存储（以及每个转发跃点）可以轻松地验证内容是否与请求匹配。在签名受限的情况下（通常用于初始清单发现），请求者只知道对内容签名的KeyId。正是在这种情况下，需要内容存储中最密切的关注，以避免放大坏数据。如果内容存储可以验证签名，则它必须仅使用内容对象进行响应；这意味着内容对象在其内部携带公钥，或者兴趣除了KeyId之外还携带公钥。如果情况并非如此，则内容存储应将兴趣视为缓存未命中，并让端点响应。
A user-level cache could perform full signature verification by fetching a public key or certificate according to the KeyLink. That is not, however, a burden we wish to impose on the forwarder. A user-level cache could also rely on out-of-band attestation, such as the cache operator only inserting content that it knows has the correct signature.
用户级缓存可以通过根据密钥链接获取公钥或证书来执行完整的签名验证。然而，这不是我们希望强加给货代的负担。用户级缓存也可以依赖带外认证，例如缓存操作员仅插入其知道具有正确签名的内容。
The CCNx grammar allows for hash-algorithm agility via the HashType. It specifies a short list of acceptable hash algorithms that should be implemented at each forwarder. Some hash values only apply to end systems, so updating the hash algorithm does not affect forwarders; they would simply match the buffer that includes the type-length-hash buffer. Some fields, such as the ConObjHash, must be verified at each hop, so a forwarder (or related system) must know the hash algorithm; it could cause backward compatibility problems if the hash type is updated. [RFC8609] is the authoritative source for per-field-allowed hash types in that encoding.
CCNx语法允许通过HashType实现哈希算法的灵活性。它指定了应在每个转发器上实现的可接受哈希算法的简短列表。一些散列值仅适用于终端系统，因此更新散列算法不会影响转发器；它们只需匹配包含类型长度哈希缓冲区的缓冲区。某些字段（如ConObjHash）必须在每个跃点进行验证，因此转发器（或相关系统）必须知道哈希算法；如果更新哈希类型，可能会导致向后兼容性问题。[RFC8609]是该编码中每个字段允许的哈希类型的权威源。
A CCNx name uses binary matching whereas a URI uses a case-insensitive hostname. Some systems may also use case-insensitive matching of the URI path to a resource. An implication of this is
CCNx名称使用二进制匹配，而URI使用不区分大小写的主机名。一些系统还可能使用URI路径到资源的不区分大小写的匹配。这意味着
that human-entered CCNx names will likely have case or non-ASCII symbol mismatches unless one uses a consistent URI normalization to the CCNx name. It also means that an entity that registers a CCNx routable prefix, say "ccnx:/example.com", would need separate registrations for simple variations like "ccnx:/Example.com". Unless this is addressed in URI normalization and routing protocol conventions, there could be phishing attacks.
除非对CCNx名称使用一致的URI规范化，否则人工输入的CCNx名称可能存在大小写或非ASCII符号不匹配。这也意味着注册CCNx可路由前缀（如“CCNx:/example.com”）的实体需要单独注册“CCNx:/example.com”等简单变体。除非URI规范化和路由协议约定解决了这一问题，否则可能存在网络钓鱼攻击。
For a more general introduction to ICN-related security concerns and approaches, see [RFC7927] and [RFC7945].
有关ICN相关安全问题和方法的更一般性介绍，请参阅[RFC7927]和[RFC7945]。
[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>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[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>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[ace] Shang, W., Yu, Y., Liang, T., Zhang, B., and L. Zhang, "NDN-ACE: Access Control for Constrained Environments over Named Data Networking", NDN Technical Report NDN-0036, December 2015, <http://new.named-data.net/ wp-content/uploads/2015/12/ndn-0036-1-ndn-ace.pdf>.
[ace]Shang，W.，Yu，Y.，Liang，T.，Zhang，B.，和L.Zhang，“NDN-ace：命名数据网络上受限环境的访问控制”，NDN技术报告NDN-0036，2015年12月<http://new.named-data.net/ wp content/uploads/2015/12/ndn-0036-1-ndn-ace.pdf>。
[befrags] Mosko, M. and C. Tschudin, "ICN "Begin-End" Hop by Hop Fragmentation", Work in Progress, draft-mosko-icnrg-beginendfragment-02, December 2016.
[befrags]Mosko，M.和C.Tschudin，“ICN”开始-结束“逐跳碎片化”，正在进行的工作，草稿-Mosko-icnrg-BeginedFragment-022016年12月。
[ccn-lite] Tschudin, C., et al., "CCN-lite", University of Basel, 2011-2019, <http://ccn-lite.net>.
伯尔尼大学学报，2011-2019，<http://ccn-lite.net>.
[ccnx-ke] Mosko, M., Uzun, E., and C. Wood, "CCNx Key Exchange Protocol Version 1.0", Work in Progress, draft-wood-icnrg-ccnxkeyexchange-02, March 2017.
[ccnx ke]Mosko，M.，Uzun，E.，和C.Wood，“ccnx密钥交换协议1.0版”，正在进行的工作，草稿-Wood-icnrg-ccnxkeyexchange-02，2017年3月。
[ccnx-registry] IANA, "Content-Centric Networking (CCNx)", <https://www.iana.org/assignments/ccnx>.
[ccnx注册表]IANA，“以内容为中心的网络（ccnx）”<https://www.iana.org/assignments/ccnx>.
[ccnx-uri] Mosko, M. and C. Wood, "The CCNx URI Scheme", Work in Progress, draft-mosko-icnrg-ccnxurischeme-01, April 2016.
[ccnx uri]Mosko，M.和C.Wood，“ccnx uri方案”，正在进行的工作，草稿-Mosko-icnrg-CCNxURI-01，2016年4月。
[chunking] Mosko, M., "CCNx Content Object Chunking", Work in Progress, draft-mosko-icnrg-ccnxchunking-02, June 2016.
[分块]Mosko，M.，“CCNx内容对象分块”，正在进行的工作，草稿-Mosko-icnrg-ccnxchunking-022016年6月。
[cicn] FD.io, "Community ICN (CICN)", February 2017, <https://wiki.fd.io/index.php?title=Cicn&oldid=7191>.
[cicn]FD.io，“社区ICN（cicn）”，2017年2月<https://wiki.fd.io/index.php?title=Cicn&oldid=7191>.
[dart] Garcia-Luna-Aceves, J. and M. Mirzazad-Barijough, "A Light-Weight Forwarding Plane for Content-Centric Networks", International Conference on Computing, Networking, and Communications (ICNC), DOI 10.1109/ICCNC.2016.7440637, February 2016, <https://arxiv.org/pdf/1603.06044.pdf>.
[dart]Garcia Luna Aceves，J.和M.Mirzad Barijough，“内容中心网络的轻型转发飞机”，国际计算、网络和通信会议（ICNC），DOI 10.1109/ICCNC.2016.7440637，2016年2月<https://arxiv.org/pdf/1603.06044.pdf>.
[eprise-numbers] IANA, "IANA Private Enterprise Numbers", <https://www.iana.org/assignments/enterprise-numbers>.
[eprise编号]IANA，“IANA私营企业编号”<https://www.iana.org/assignments/enterprise-numbers>.
[esic] Mosko, M. and C. Wood, "Encrypted Sessions In CCNx (ESIC)", Work in Progress, draft-wood-icnrg-esic-01, September 2017.
[esic]Mosko，M.和C.Wood，“CCNx（esic）中的加密会话”，正在进行的工作，草稿-Wood-icnrg-esic-01，2017年9月。
[flic] Tschudin, C. and C. Wood, "File-Like ICN Collection (FLIC)", Work in Progress, draft-tschudin-icnrg-flic-03, March 2017.
[flic]Tschudin，C.和C.Wood，“类似文件的ICN收集（flic）”，正在进行的工作，草稿-Tschudin-icnrg-flic-032017年3月。
[mobile] Mosko, M., Uzun, E., and C. Wood, "Mobile Sessions in Content-Centric Networks", IFIP Networking Conference (IFIP Networking) and Workshops, DOI 10.23919/IFIPNetworking.2017.8264861, June 2017, <https://dl.ifip.org/db/conf/networking/ networking2017/1570334964.pdf>.
[移动]Mosko，M.，Uzun，E.，和C.Wood，“以内容为中心的网络中的移动会话”，IFIP网络会议（IFIP网络）和研讨会，DOI 10.23919/IFIPNetworking.2017.826486112017年6月<https://dl.ifip.org/db/conf/networking/ 网络2017/1570334964.pdf>。
[ndn] UCLA, "Named Data Networking", 2019, <https://www.named-data.net>.
[ndn]加州大学洛杉矶分校，“命名数据网络”，2019年<https://www.named-data.net>.
[nnc] Jacobson, V., Smetters, D., Thornton, J., Plass, M., Briggs, N., and R. Braynard, "Networking Named Content", Proceedings of the 5th International Conference on Emerging Networking Experiments and Technologies, DOI 10.1145/1658939.1658941, December 2009, <https://dx.doi.org/10.1145/1658939.1658941>.
[nnc]Jacobson，V.，Smetters，D.，Thornton，J.，Plass，M.，Briggs，N.，和R.Braynard，“网络命名内容”，第五届新兴网络实验和技术国际会议记录，DOI 10.1145/1658939.16589411909年12月<https://dx.doi.org/10.1145/1658939.1658941>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<https://www.rfc-editor.org/info/rfc5234>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 5280，DOI 10.17487/RFC5280，2008年5月<https://www.rfc-editor.org/info/rfc5280>.
[RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, "Information-Centric Networking (ICN) Research Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, <https://www.rfc-editor.org/info/rfc7927>.
[RFC7927]Kutscher，D.，Ed.，Eum，S.，Pentikousis，K.，Psaras，I.，Corujo，D.，Saucez，D.，Schmidt，T.，和M.Waehlisch，“信息中心网络（ICN）研究挑战”，RFC 7927，DOI 10.17487/RFC7927，2016年7月<https://www.rfc-editor.org/info/rfc7927>.
[RFC7945] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S., and G. Boggia, "Information-Centric Networking: Evaluation and Security Considerations", RFC 7945, DOI 10.17487/RFC7945, September 2016, <https://www.rfc-editor.org/info/rfc7945>.
[RFC7945]Pentikousis，K.，Ed.，Ohlman，B.，Davies，E.，Spirou，S.，和G.Boggia，“以信息为中心的网络：评估和安全考虑”，RFC 7945，DOI 10.17487/RFC79452016年9月<https://www.rfc-editor.org/info/rfc7945>.
[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>.
[RFC8609]Mosko，M.，Solis，I.，和C.Wood，“TLV格式的内容中心网络（CCNx）消息”，RFC 8609，DOI 10.17487/RFC8609，2019年7月<https://www.rfc-editor.org/info/rfc8609>.
[selectors] Mosko, M., "CCNx Selector Based Discovery", Work in Progress, draft-mosko-icnrg-selectors-01, May 2019.
[selectors]Mosko，M.，“基于CCNx选择器的发现”，正在进行的工作，草稿-Mosko-icnrg-selectors-01，2019年5月。
[terminology] Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., Oran, D., and C. Tschudin, "Information-Centric Networking (ICN): CCN and NDN Terminology", Work in Progress, draft-irtf-icnrg-terminology-04, June 2019.
[术语]Wissingh，B.，Wood，C.，Afanasyev，A.，Zhang，L.，Oran，D.，和C.Tschudin，“以信息为中心的网络（ICN）：CCN和NDN术语”，正在进行的工作，草案-irtf-icnrg-terminology-042019年6月。
[trust] Tschudin, C., Uzun, E., and C. Wood, "Trust in Information-Centric Networking: From Theory to Practice", 25th International Conference on Computer Communication and Networks (ICCCN), DOI 10.1109/ICCCN.2016.7568589, August 2016, <https://doi.org/10.1109/ICCCN.2016.7568589>.
[trust]Tschudin，C.，Uzun，E.，和C.Wood，“信息中心网络中的信任：从理论到实践”，第25届计算机通信与网络国际会议（ICCCN），DOI 10.1109/ICCCN.2016.7568589，2016年8月<https://doi.org/10.1109/ICCCN.2016.7568589>.
Authors' Addresses
作者地址
Marc Mosko PARC, Inc. Palo Alto, California 94304 United States of America
Marc Mosko PARC，Inc.美国加利福尼亚州帕洛阿尔托94304
Phone: +01 650-812-4405
Email: marc.mosko@parc.com
Phone: +01 650-812-4405
Email: marc.mosko@parc.com
Ignacio Solis LinkedIn Mountain View, California 94043 United States of America
美国加利福尼亚州伊格纳西奥·索利斯LinkedIn山景酒店94043
Email: nsolis@linkedin.com
Email: nsolis@linkedin.com
Christopher A. Wood University of California Irvine Irvine, California 92697 United States of America
克里斯托弗A.伍德加利福尼亚大学欧文欧文，加利福尼亚92697美利坚合众国
Phone: +01 315-806-5939
Email: woodc1@uci.edu
Phone: +01 315-806-5939
Email: woodc1@uci.edu