Internet Engineering Task Force (IETF) M. Stenberg
Request for Comments: 7787 S. Barth
Category: Standards Track Independent
ISSN: 2070-1721 April 2016
Internet Engineering Task Force (IETF) M. Stenberg
Request for Comments: 7787 S. Barth
Category: Standards Track Independent
ISSN: 2070-1721 April 2016
Distributed Node Consensus Protocol
分布式节点一致性协议
Abstract
摘要
This document describes the Distributed Node Consensus Protocol (DNCP), a generic state synchronization protocol that uses the Trickle algorithm and hash trees. DNCP is an abstract protocol and must be combined with a specific profile to make a complete implementable protocol.
本文档介绍分布式节点一致性协议（DNCP），这是一种通用状态同步协议，使用涓流算法和哈希树。DNCP是一个抽象协议，必须与特定的概要文件相结合，才能形成一个完整的可实现协议。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7787.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7787.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 8
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Hash Tree . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Calculating Network State and Node Data Hashes . . . 10
4.1.2. Updating Network State and Node Data Hashes . . . . . 10
4.2. Data Transport . . . . . . . . . . . . . . . . . . . . . 10
4.3. Trickle-Driven Status Updates . . . . . . . . . . . . . . 12
4.4. Processing of Received TLVs . . . . . . . . . . . . . . . 13
4.5. Discovering, Adding, and Removing Peers . . . . . . . . . 15
4.6. Data Liveliness Validation . . . . . . . . . . . . . . . 16
5. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Optional Extensions . . . . . . . . . . . . . . . . . . . . . 19
6.1. Keep-Alives . . . . . . . . . . . . . . . . . . . . . . . 19
6.1.1. Data Model Additions . . . . . . . . . . . . . . . . 20
6.1.2. Per-Endpoint Periodic Keep-Alives . . . . . . . . . . 20
6.1.3. Per-Peer Periodic Keep-Alives . . . . . . . . . . . . 20
6.1.4. Received TLV Processing Additions . . . . . . . . . . 21
6.1.5. Peer Removal . . . . . . . . . . . . . . . . . . . . 21
6.2. Support for Dense Multicast-Enabled Links . . . . . . . . 21
7. Type-Length-Value Objects . . . . . . . . . . . . . . . . . . 22
7.1. Request TLVs . . . . . . . . . . . . . . . . . . . . . . 23
7.1.1. Request Network State TLV . . . . . . . . . . . . . . 23
7.1.2. Request Node State TLV . . . . . . . . . . . . . . . 24
7.2. Data TLVs . . . . . . . . . . . . . . . . . . . . . . . . 24
7.2.1. Node Endpoint TLV . . . . . . . . . . . . . . . . . . 24
7.2.2. Network State TLV . . . . . . . . . . . . . . . . . . 25
7.2.3. Node State TLV . . . . . . . . . . . . . . . . . . . 25
7.3. Data TLVs within Node State TLV . . . . . . . . . . . . . 26
7.3.1. Peer TLV . . . . . . . . . . . . . . . . . . . . . . 26
7.3.2. Keep-Alive Interval TLV . . . . . . . . . . . . . . . 27
8. Security and Trust Management . . . . . . . . . . . . . . . . 27
8.1. Trust Method Based on Pre-Shared Key . . . . . . . . . . 27
8.2. PKI-Based Trust Method . . . . . . . . . . . . . . . . . 28
8.3. Certificate-Based Trust Consensus Method . . . . . . . . 28
8.3.1. Trust Verdicts . . . . . . . . . . . . . . . . . . . 28
8.3.2. Trust Cache . . . . . . . . . . . . . . . . . . . . . 29
8.3.3. Announcement of Verdicts . . . . . . . . . . . . . . 30
8.3.4. Bootstrap Ceremonies . . . . . . . . . . . . . . . . 31
9. DNCP Profile-Specific Definitions . . . . . . . . . . . . . . 32
10. Security Considerations . . . . . . . . . . . . . . . . . . . 34
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 8
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Hash Tree . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Calculating Network State and Node Data Hashes . . . 10
4.1.2. Updating Network State and Node Data Hashes . . . . . 10
4.2. Data Transport . . . . . . . . . . . . . . . . . . . . . 10
4.3. Trickle-Driven Status Updates . . . . . . . . . . . . . . 12
4.4. Processing of Received TLVs . . . . . . . . . . . . . . . 13
4.5. Discovering, Adding, and Removing Peers . . . . . . . . . 15
4.6. Data Liveliness Validation . . . . . . . . . . . . . . . 16
5. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Optional Extensions . . . . . . . . . . . . . . . . . . . . . 19
6.1. Keep-Alives . . . . . . . . . . . . . . . . . . . . . . . 19
6.1.1. Data Model Additions . . . . . . . . . . . . . . . . 20
6.1.2. Per-Endpoint Periodic Keep-Alives . . . . . . . . . . 20
6.1.3. Per-Peer Periodic Keep-Alives . . . . . . . . . . . . 20
6.1.4. Received TLV Processing Additions . . . . . . . . . . 21
6.1.5. Peer Removal . . . . . . . . . . . . . . . . . . . . 21
6.2. Support for Dense Multicast-Enabled Links . . . . . . . . 21
7. Type-Length-Value Objects . . . . . . . . . . . . . . . . . . 22
7.1. Request TLVs . . . . . . . . . . . . . . . . . . . . . . 23
7.1.1. Request Network State TLV . . . . . . . . . . . . . . 23
7.1.2. Request Node State TLV . . . . . . . . . . . . . . . 24
7.2. Data TLVs . . . . . . . . . . . . . . . . . . . . . . . . 24
7.2.1. Node Endpoint TLV . . . . . . . . . . . . . . . . . . 24
7.2.2. Network State TLV . . . . . . . . . . . . . . . . . . 25
7.2.3. Node State TLV . . . . . . . . . . . . . . . . . . . 25
7.3. Data TLVs within Node State TLV . . . . . . . . . . . . . 26
7.3.1. Peer TLV . . . . . . . . . . . . . . . . . . . . . . 26
7.3.2. Keep-Alive Interval TLV . . . . . . . . . . . . . . . 27
8. Security and Trust Management . . . . . . . . . . . . . . . . 27
8.1. Trust Method Based on Pre-Shared Key . . . . . . . . . . 27
8.2. PKI-Based Trust Method . . . . . . . . . . . . . . . . . 28
8.3. Certificate-Based Trust Consensus Method . . . . . . . . 28
8.3.1. Trust Verdicts . . . . . . . . . . . . . . . . . . . 28
8.3.2. Trust Cache . . . . . . . . . . . . . . . . . . . . . 29
8.3.3. Announcement of Verdicts . . . . . . . . . . . . . . 30
8.3.4. Bootstrap Ceremonies . . . . . . . . . . . . . . . . 31
9. DNCP Profile-Specific Definitions . . . . . . . . . . . . . . 32
10. Security Considerations . . . . . . . . . . . . . . . . . . . 34
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
12.1. Normative References . . . . . . . . . . . . . . . . . . 36
12.2. Informative References . . . . . . . . . . . . . . . . . 36
Appendix A. Alternative Modes of Operation . . . . . . . . . . . 38
A.1. Read-Only Operation . . . . . . . . . . . . . . . . . . . 38
A.2. Forwarding Operation . . . . . . . . . . . . . . . . . . 38
Appendix B. DNCP Profile Additional Guidance . . . . . . . . . . 38
B.1. Unicast Transport -- UDP or TCP? . . . . . . . . . . . . 38
B.2. (Optional) Multicast Transport . . . . . . . . . . . . . 39
B.3. (Optional) Transport Security . . . . . . . . . . . . . . 39
Appendix C. Example Profile . . . . . . . . . . . . . . . . . . 40
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
12.1. Normative References . . . . . . . . . . . . . . . . . . 36
12.2. Informative References . . . . . . . . . . . . . . . . . 36
Appendix A. Alternative Modes of Operation . . . . . . . . . . . 38
A.1. Read-Only Operation . . . . . . . . . . . . . . . . . . . 38
A.2. Forwarding Operation . . . . . . . . . . . . . . . . . . 38
Appendix B. DNCP Profile Additional Guidance . . . . . . . . . . 38
B.1. Unicast Transport -- UDP or TCP? . . . . . . . . . . . . 38
B.2. (Optional) Multicast Transport . . . . . . . . . . . . . 39
B.3. (Optional) Transport Security . . . . . . . . . . . . . . 39
Appendix C. Example Profile . . . . . . . . . . . . . . . . . . 40
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
DNCP is designed to provide a way for each participating node to publish a small set of TLV (Type-Length-Value) tuples (at most 64 KB) and to provide a shared and common view about the data published by every currently bidirectionally reachable DNCP node in a network.
DNCP旨在为每个参与节点提供一种方式，以发布一小组TLV（类型长度值）元组（最多64 KB），并提供关于网络中每个当前可双向访问的DNCP节点发布的数据的共享和公共视图。
For state synchronization, a hash tree is used. It is formed by first calculating a hash for the data set published by each node, called node data, and then calculating another hash over those node data hashes. The single resulting hash, called network state hash, is transmitted using the Trickle algorithm [RFC6206] to ensure that all nodes share the same view of the current state of the published data within the network. The use of Trickle with only short network state hashes sent infrequently (in steady state, once the maximum Trickle interval per link or unicast connection has been reached) makes DNCP very thrifty when updates happen rarely.
对于状态同步，使用哈希树。它是通过首先计算每个节点发布的数据集的散列（称为节点数据），然后在这些节点数据散列上计算另一个散列而形成的。生成的单个散列称为网络状态散列，使用涓流算法[RFC6206]传输，以确保所有节点共享网络内已发布数据的当前状态的相同视图。当更新很少发生时，只使用很少发送的短网络状态哈希（在稳定状态下，一旦达到每个链路或单播连接的最大涓流间隔），使用涓流使得DNCP非常节俭。
For maintaining liveliness of the topology and the data within it, a combination of Trickled network state, keep-alives, and "other" means of ensuring reachability are used. The core idea is that if every node ensures its peers are present, transitively, the whole network state also stays up to date.
为了保持拓扑和其中的数据的生动性，使用了网络状态、保持有效性和确保可达性的“其他”方法的组合。其核心思想是，如果每个节点都以传递方式确保其对等节点存在，则整个网络状态也保持最新。
DNCP is useful for cases like autonomous bootstrapping, discovery, and negotiation of embedded network devices like routers. Furthermore, it can be used as a basis to run distributed algorithms like [RFC7596] or use cases as described in Appendix C. DNCP is abstract, which allows it to be tuned to a variety of applications by defining profiles. These profiles include choices of:
DNCP适用于诸如路由器等嵌入式网络设备的自主引导、发现和协商等情况。此外，它可以作为运行分布式算法（如[RFC7596]）或附录C中描述的用例的基础。DNCP是抽象的，通过定义配置文件，它可以调整到各种应用程序。这些配置文件包括以下选项：
- unicast transport: a datagram or stream-oriented protocol (e.g., TCP, UDP, or the Stream Control Transmission Protocol (SCTP)) for generic protocol operation.
- 单播传输：用于通用协议操作的数据报或面向流的协议（例如TCP、UDP或流控制传输协议（SCTP））。
- optional transport security: whether and when to use security based on Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS), if supported over the chosen transport.
- 可选传输安全性：如果所选传输支持，是否以及何时使用基于传输层安全性（TLS）或数据报传输层安全性（DTLS）的安全性。
- optional multicast transport: a multicast-capable protocol like UDP allowing autonomous peer discovery or more efficient use of multiple access links.
- 可选多播传输：一种支持多播的协议，如UDP，允许自主对等发现或更有效地使用多个访问链路。
- communication scopes: using either hop by hop only relying on link-local addressing (e.g., for LANs), addresses with broader scopes (e.g., over WANs or the Internet) relying on an existing routing infrastructure, or a combination of both (e.g., to exchange state between multiple LANs over a WAN or the Internet).
- 通信范围：使用仅依赖于链路本地寻址的逐跳地址（例如，对于LAN）、依赖于现有路由基础设施的范围更广的地址（例如，通过WAN或Internet）或两者的组合（例如，通过WAN或Internet在多个LAN之间交换状态）。
- payloads: additional specific payloads (e.g., IANA standardized, enterprise-specific, or private use).
- 有效载荷：额外的特定有效载荷（例如，IANA标准化、企业特定或私人使用）。
- extensions: possible protocol extensions, either as predefined in this document or specific for a particular use case.
- 扩展：可能的协议扩展，如本文档中预定义的或特定于特定用例的。
However, there are certain cases where the protocol as defined in this document is a less suitable choice. This list provides an overview while the following paragraphs provide more detailed guidance on the individual matters.
然而，在某些情况下，本文件中定义的协议不太合适。此列表提供了一个概述，而以下段落提供了有关个别事项的更详细指导。
- large amounts of data: nodes are limited to 64 KB of published data.
- 大量数据：节点被限制为64 KB的已发布数据。
- very dense unicast-only networks: nodes include information about all immediate neighbors as part of their published data.
- 非常密集的单播网络：节点将所有近邻的信息作为其发布数据的一部分。
- predominantly minimal data changes: node data is always transported as is, leading to a relatively large transmission overhead for changes affecting only a small part of it.
- 主要是最小的数据更改：节点数据总是按原样传输，这会导致仅影响其中一小部分的更改产生相对较大的传输开销。
- frequently changing data: DNCP with its use of Trickle is optimized for the steady state and less efficient otherwise.
- 频繁变化的数据：DNCP使用涓流优化稳态，否则效率较低。
- large amounts of very constrained nodes: DNCP requires each node to store the entirety of the data published by all nodes.
- 大量非常受限的节点：DNCP要求每个节点存储所有节点发布的全部数据。
The topology of the devices is not limited and automatically discovered. When relying on link-local communication exclusively, all links having DNCP nodes need to be at least transitively connected by routers running the protocol on multiple endpoints in order to form a connected network. However, there is no requirement for every device in a physical network to run the protocol. Especially if globally scoped addresses are used, DNCP peers do not need to be on the same or even neighboring physical links. Autonomous discovery features are usually used in local network scenarios; however, with security enabled, DNCP can also be used over unsecured public networks. Network size is restricted merely by the capabilities of the devices, i.e., each DNCP node needs to be able to store the entirety of the data published by all nodes. The data associated with each individual node identifier is limited to about 64 KB in this document; however, protocol extensions could be defined to mitigate this or other protocol limitations if the need arises.
设备的拓扑结构不受限制，可以自动发现。当完全依赖链路本地通信时，具有DNCP节点的所有链路需要至少通过在多个端点上运行协议的路由器进行传递性连接，以形成连接的网络。但是，并不要求物理网络中的每个设备都运行该协议。尤其是在使用全局范围的地址时，DNCP对等点不需要位于相同的甚至相邻的物理链路上。自治发现功能通常用于本地网络场景；但是，在启用安全性的情况下，DNCP也可以在不安全的公共网络上使用。网络大小仅受设备能力的限制，即每个DNCP节点需要能够存储所有节点发布的全部数据。在本文档中，与每个单独节点标识符相关联的数据限制在约64KB；但是，如果需要，可以定义协议扩展以减轻此协议或其他协议限制。
DNCP is most suitable for data that changes only infrequently to gain the maximum benefit from using Trickle. As the network of nodes grows, or the frequency of data changes per node increases, Trickle is eventually used less and less, and the benefit of using DNCP diminishes. In these cases, Trickle just provides extra complexity within the specification and little added value.
DNCP最适合于仅偶尔更改的数据，以从使用涓流中获得最大收益。随着节点网络的增长，或每个节点的数据更改频率的增加，涓流的使用最终会越来越少，使用DNCP的好处也会减少。在这些情况下，涓流只在规范中提供了额外的复杂性，几乎没有附加值。
The suitability of DNCP for a particular application can be roughly evaluated by considering the expected average network-wide state change interval A_NC_I; it is computed by dividing the mean interval at which a node originates a new TLV set by the number of participating nodes. If keep-alives are used, A_NC_I is the minimum of the computed A_NC_I and the keep-alive interval. If A_NC_I is less than the (application-specific) Trickle minimum interval, DNCP is most likely unsuitable for the application as Trickle will not be utilized most of the time.
DNCP对于特定应用的适用性可以通过考虑预期的平均网络范围状态变化间隔a_NC_I粗略评估；通过将节点发起新TLV集的平均间隔除以参与节点的数量来计算。如果使用保持有效，则A_NC_I是计算出的A_NC_I和保持有效间隔的最小值。如果A_NC_I小于（特定于应用的）涓流最小间隔，则DNCP很可能不适用于该应用，因为涓流在大部分时间内不会被利用。
If constant rapid state changes are needed, the preferable choice is to use an additional point-to-point channel whose address or locator is published using DNCP. Nevertheless, if doing so does not raise A_NC_I above the (sensibly chosen) Trickle interval parameters for a particular application, using DNCP is probably not suitable for the application.
如果需要持续快速的状态变化，最好的选择是使用附加的点对点通道，其地址或定位器使用DNCP发布。尽管如此，如果这样做不会使某一特定应用的涓流间隔参数（合理选择）高于_NC_I，则使用DNCP可能不适合该应用。
Another consideration is the size of the published TLV set by a node compared to the size of deltas in the TLV set. If the TLV set published by a node is very large, and has frequent small changes, DNCP as currently specified in this specification may be unsuitable as it lacks a delta synchronization scheme to keep implementation simple.
另一个需要考虑的问题是，与TLV集中的增量大小相比，节点发布的TLV集的大小。如果节点发布的TLV集非常大，并且经常有小的更改，那么本规范中当前指定的DNCP可能不合适，因为它缺少保持实现简单的增量同步方案。
DNCP can be used in networks where only unicast transport is available. While DNCP uses the least amount of bandwidth when multicast is utilized, even in pure unicast mode, the use of Trickle (ideally with k < 2) results in a protocol with an exponential backoff timer and fewer transmissions than a simpler protocol not using Trickle.
DNCP可用于只有单播传输可用的网络中。当使用多播时，即使在纯单播模式下，DNCP使用最少的带宽，但使用涓流（理想情况下为k<2）会导致协议具有指数退避计时器，并且比不使用涓流的更简单协议的传输更少。
DNCP profile the values for the set of parameters given in Section 9. They are prefixed with DNCP_ in this document. The profile also specifies the set of optional DNCP extensions to be used. For a simple example DNCP profile, see Appendix C.
DNCP剖面第9节中给出的一组参数值。在本文件中，它们的前缀为DNCP_u。配置文件还指定要使用的可选DNCP扩展集。有关DNCP配置文件的简单示例，请参见附录C。
DNCP-based a protocol that provides a DNCP profile, according protocol to Section 9, and zero or more TLV assignments from the per-DNCP profile TLV registry as well as their processing rules.
基于DNCP的协议，该协议根据第9节的协议提供DNCP配置文件，以及来自per DNCP配置文件TLV注册表的零个或多个TLV分配及其处理规则。
DNCP node a single node that runs a DNCP-based protocol.
DNCP节点运行基于DNCP的协议的单个节点。
Link a link-layer media over which directly connected nodes can communicate.
链路直接连接的节点可以通过其进行通信的链路层媒体。
DNCP network a set of DNCP nodes running a DNCP-based protocol(s) with a matching DNCP profile(s). The set consists of nodes that have discovered each other using the transport method defined in the DNCP profile, via multicast on local links, and/or by using unicast communication.
DNCP网络运行基于DNCP的协议的一组DNCP节点，具有匹配的DNCP配置文件。该集合由使用DNCP配置文件中定义的传输方法、通过本地链路上的多播和/或通过单播通信相互发现的节点组成。
Node identifier an opaque fixed-length identifier consisting of DNCP_NODE_IDENTIFIER_LENGTH bytes that uniquely identifies a DNCP node within a DNCP network.
节点标识符由DNCP_Node_identifier_length字节组成的不透明固定长度标识符，用于唯一标识DNCP网络中的DNCP节点。
Interface a node's attachment to a particular link.
将节点的附件连接到特定链接。
Address an identifier used as the source or destination of a DNCP message flow, e.g., a tuple (IPv6 address, UDP port) for an IPv6 UDP transport.
地址用作DNCP消息流的源或目标的标识符，例如，IPv6 UDP传输的元组（IPv6地址、UDP端口）。
Endpoint a locally configured termination point for (potential or established) DNCP message flows. An endpoint is the source and destination for separate unicast message flows to individual nodes and optionally for multicast messages to all thereby reachable nodes (e.g., for node discovery). Endpoints are usually in one of the transport modes specified in Section 4.2.
端点（可能的或已建立的）DNCP消息流的本地配置终止点。端点是到各个节点的单独单播消息流的源和目的地，并且可选地是到所有因此可到达的节点的多播消息的源和目的地（例如，用于节点发现）。端点通常采用第4.2节中规定的一种运输模式。
Endpoint a 32-bit opaque and locally unique value, which identifier identifies a particular endpoint of a particular DNCP node. The value 0 is reserved for DNCP and DNCP-based protocol purposes and not used to identify an actual endpoint. This definition is in sync with the interface index definition in [RFC3493], as the non-zero small positive integers should comfortably fit within 32 bits.
端点32位不透明且本地唯一的值，该标识符标识特定DNCP节点的特定端点。值0保留用于DNCP和基于DNCP的协议目的，不用于标识实际端点。此定义与[RFC3493]中的接口索引定义同步，因为非零小正整数应适合32位。
Peer another DNCP node with which a DNCP node communicates using at least one particular local and remote endpoint pair.
对等另一个DNCP节点，DNCP节点使用至少一个特定的本地和远程端点对与之通信。
Node data a set of TLVs published and owned by a node in the DNCP network. Other nodes pass it along as is, even if they cannot fully interpret it.
节点数据由DNCP网络中的节点发布和拥有的一组TLV。其他节点按原样传递它，即使它们不能完全解释它。
Origination time the (estimated) time when the node data set with the current sequence number was published.
起始时间发布具有当前序列号的节点数据集时的（估计）时间。
Node state a set of metadata attributes for node data. It includes a sequence number for versioning, a hash value for comparing equality of stored node data, and a timestamp indicating the time passed since its last publication (i.e., since the origination time). The hash function and the length of the hash value are defined in the DNCP profile.
节点状态节点数据的一组元数据属性。它包括用于版本控制的序列号、用于比较存储节点数据的相等性的哈希值以及指示自上次发布以来经过的时间（即，自发起时间）的时间戳。哈希函数和哈希值的长度在DNCP配置文件中定义。
Network state a hash value that represents the current state of hash the network. The hash function and the length of the hash value are defined in the DNCP profile. Whenever a node is added, removed, or updates its published node data, this hash value changes as well. For calculation, please see Section 4.1.
网络状态表示网络哈希当前状态的哈希值。哈希函数和哈希值的长度在DNCP配置文件中定义。每当添加、删除或更新节点的已发布节点数据时，此哈希值也会更改。有关计算，请参见第4.1节。
Trust verdict a statement about the trustworthiness of a certificate announced by a node participating in the certificate-based trust consensus mechanism.
信任裁决参与基于证书的信任共识机制的节点宣布的关于证书可信度的声明。
Effective trust the trust verdict with the highest priority within verdict the set of trust verdicts announced for the certificate in the DNCP network.
有效信任在DNCP网络中为证书宣布的一组信任裁决中具有最高优先级的信任裁决。
Topology graph the undirected graph of DNCP nodes produced by retaining only bidirectional peer relationships between nodes.
拓扑图仅保留节点之间的双向对等关系而生成的DNCP节点的无向图。
Bidirectionally a peer is locally unidirectionally reachable if a reachable consistent multicast or any unicast DNCP message has been received by the local node (see Section 4.5). If said peer in return also considers the local node unidirectionally reachable, then bidirectionally reachability is established. As this process is based on publishing peer relationships and evaluating the resulting topology graph as described in Section 4.6, this information is available to the whole DNCP network.
如果本地节点已接收到可到达的一致多播或任何单播DNCP消息，则双向对等点是本地单向可到达的（参见第4.5节）。如果所述对等方还认为本地节点单向可到达，则建立双向可到达性。由于该过程基于发布对等关系和评估第4.6节所述的拓扑图，因此该信息可用于整个DNCP网络。
Trickle instance a distinct Trickle [RFC6206] algorithm state kept by a node (Section 5) and related to an endpoint or a particular (peer, endpoint) tuple with Trickle variables I, t, and c. See Section 4.3.
涓流实例由节点（第5节）保持的独特涓流[RFC6206]算法状态，与端点或具有涓流变量I、t和c的特定（对等、端点）元组相关。见第4.3节。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照RFC 2119[RFC2119]中的说明进行解释。
DNCP operates primarily using unicast exchanges between nodes, and it may use multicast for Trickle-based shared state dissemination and topology discovery. If used in pure unicast mode with unreliable transport, Trickle is also used between peers.
DNCP主要使用节点之间的单播交换进行操作，它可以使用多播进行基于涓流的共享状态传播和拓扑发现。如果在具有不可靠传输的纯单播模式下使用，则也会在对等点之间使用涓流。
DNCP is based on exchanging TLVs (Section 7) and defines a set of mandatory and optional ones for its operation. They are categorized into TLVs for requesting information (Section 7.1), transmitting data (Section 7.2), and being published as data (Section 7.3). DNCP-based protocols usually specify additional ones to extend the capabilities.
DNCP基于交换TLV（第7节），并为其操作定义了一组强制性和可选的TLV。它们被分类为TLV，用于请求信息（第7.1节）、传输数据（第7.2节）和作为数据发布（第7.3节）。基于DNCP的协议通常会指定其他协议来扩展功能。
DNCP discovers the topology of the nodes in the DNCP network and maintains the liveliness of published node data by ensuring that the publishing node is bidirectionally reachable. New potential peers can be discovered autonomously on multicast-enabled links; their
DNCP发现DNCP网络中节点的拓扑，并通过确保发布节点是双向可访问的来保持发布节点数据的活跃性。可以在支持多播的链路上自主发现新的潜在对等点；他们的
addresses may be manually configured or they may be found by some other means defined in the particular DNCP profile. The DNCP profile may specify, for example, a well-known anycast address or provision the remote address to contact via some other protocol such as DHCPv6 [RFC3315].
地址可以手动配置，也可以通过特定DNCP配置文件中定义的其他方式找到。DNCP简档可以例如指定众所周知的选播地址，或者通过诸如DHCPv6[RFC3315]之类的一些其他协议将远程地址提供给联系人。
A hash tree of height 1, rooted in itself, is maintained by each node to represent the state of all currently reachable nodes (see Section 4.1), and the Trickle algorithm is used to trigger synchronization (see Section 4.3). The need to check peer nodes for state changes is thereby determined by comparing the current root of their respective hash trees, i.e., their individually calculated network state hashes.
每个节点都维护一个高度为1的哈希树，该哈希树自根，以表示所有当前可访问节点的状态（参见第4.1节），并使用涓流算法触发同步（参见第4.3节）。因此，通过比较对等节点各自散列树的当前根（即，各自计算的网络状态散列）来确定是否需要检查对等节点的状态变化。
Before joining a DNCP network, a node starts with a hash tree that has only one leaf if the node publishes some TLVs, and no leaves otherwise. It then announces the network state hash calculated from the hash tree by means of the Trickle algorithm on all its configured endpoints.
在加入DNCP网络之前，如果节点发布了一些TLV，则节点以只有一个叶的哈希树开始，否则没有叶。然后，它在其所有配置的端点上通过涓流算法宣布从哈希树计算的网络状态哈希。
When an update is detected by a node (e.g., by receiving a different network state hash from a peer), the originator of the event is requested to provide a list of the state of all nodes, i.e., all the information it uses to calculate its own hash tree. The node uses the list to determine whether its own information is outdated and -- if necessary -- requests the actual node data that has changed.
当节点检测到更新（例如，通过从对等方接收不同的网络状态散列）时，请求事件的发起人提供所有节点的状态列表，即，其用于计算其自身散列树的所有信息。节点使用该列表来确定其自身的信息是否过时，并在必要时请求已更改的实际节点数据。
Whenever a node's local copy of any node data and its hash tree are updated (e.g., due to its own or another node's node state changing or due to a peer being added or removed), its Trickle instances are reset, which eventually causes any update to be propagated to all of its peers.
每当一个节点的任何节点数据的本地副本及其哈希树被更新时（例如，由于其自身或另一个节点的节点状态发生变化，或由于添加或删除对等节点），其涓流实例都会被重置，这最终会导致任何更新传播到其所有对等节点。
Each DNCP node maintains an arbitrary width hash tree of height 1. The root of the tree represents the overall network state hash and is used to determine whether the view of the network of two or more nodes is consistent and shared. Each leaf represents one bidirectionally reachable DNCP node. Every time a node is added or removed from the topology graph (Section 4.6), it is likewise added or removed as a leaf. At any time, the leaves of the tree are ordered in ascending order of the node identifiers of the nodes they represent.
每个DNCP节点维护高度为1的任意宽度哈希树。树的根表示整个网络状态哈希，用于确定两个或多个节点的网络视图是否一致和共享。每个叶表示一个双向可到达的DNCP节点。每次从拓扑图（第4.6节）中添加或删除节点时，也会将其作为叶添加或删除。在任何时候，树的叶子都按照它们所代表的节点的节点标识符的升序排列。
The network state hash and the node data hashes are calculated using the hash function defined in the DNCP profile (Section 9) and truncated to the number of bits specified therein.
使用DNCP配置文件（第9节）中定义的哈希函数计算网络状态哈希和节点数据哈希，并将其截断为其中指定的位数。
Individual node data hashes are calculated by applying the function and truncation on the respective node's node data as published in the Node State TLV. Such node data sets are always ordered as defined in Section 7.2.3.
通过在节点状态TLV中发布的各个节点的节点数据上应用函数和截断来计算各个节点数据散列。此类节点数据集始终按照第7.2.3节的规定进行排序。
The network state hash is calculated by applying the function and truncation on the concatenated network state. This state is formed by first concatenating each node's sequence number (in network byte order) with its node data hash to form a per-node datum for each node. These per-node data are then concatenated in ascending order of the respective node's node identifier, i.e., in the order that the nodes appear in the hash tree.
网络状态散列是通过在连接的网络状态上应用函数和截断来计算的。该状态是通过首先将每个节点的序列号（以网络字节顺序）与其节点数据散列连接起来形成的，以形成每个节点的每个节点数据。然后，这些每节点数据按照各自节点的节点标识符的升序（即，按照节点在散列树中出现的顺序）连接起来。
The network state hash and the node data hashes are updated on-demand and whenever any locally stored per-node state changes. This includes local unidirectional reachability encoded in the published Peer TLVs (Section 7.3.1) and -- when combined with remote data -- results in awareness of bidirectional reachability changes.
网络状态散列和节点数据散列会按需更新，并且每当本地存储的每个节点状态发生变化时都会更新。这包括在已发布的对等TLV（第7.3.1节）中编码的本地单向可达性，并且当与远程数据结合时，会导致对双向可达性变化的感知。
DNCP has few requirements for the underlying transport; it requires some way of transmitting either a unicast datagram or stream data to a peer and, if used in multicast mode, a way of sending multicast datagrams. As multicast is used only to identify potential new DNCP nodes and to send status messages that merely notify that a unicast exchange should be triggered, the multicast transport does not have to be secured. If unicast security is desired and one of the built-in security methods is to be used, support for some TLS-derived transport scheme -- such as TLS [RFC5246] on top of TCP or DTLS [RFC6347] on top of UDP -- is also required. They provide for integrity protection and confidentiality of the node data, as well as authentication and authorization using the schemes defined in "Security and Trust Management" (Section 8). A specific definition of the transport(s) in use and its parameters MUST be provided by the DNCP profile.
DNCP对基础运输的要求很少；它需要某种方式将单播数据报或流数据传输到对等方，如果在多播模式下使用，还需要某种方式发送多播数据报。由于多播仅用于识别潜在的新DNCP节点，并发送仅通知应触发单播交换的状态消息，因此多播传输不必受到保护。如果需要单播安全性，并且要使用其中一种内置安全方法，则还需要支持某些TLS派生的传输方案，例如TCP上的TLS[RFC5246]或UDP上的DTLS[RFC6347]。它们提供节点数据的完整性保护和机密性，以及使用“安全和信任管理”（第8节）中定义的方案进行身份验证和授权。DNCP配置文件必须提供所用传输及其参数的具体定义。
TLVs (Section 7) are sent across the transport as is, and they SHOULD be sent together where, e.g., MTU considerations do not recommend sending them in multiple batches. DNCP does not fragment or
TLV（第7节）按原样在运输过程中发送，如果MTU考虑不建议多批次发送，则应一起发送。DNCP没有碎片或碎片
reassemble TLVs; thus, it MUST be ensured that the underlying transport performs these operations should they be necessary. If this document indicates sending one or more TLVs, then the sending node does not need to keep track of the packets sent after handing them over to the respective transport, i.e., reliable DNCP operation is ensured merely by the explicitly defined timers and state machines such as Trickle (Section 4.3). TLVs in general are handled individually and statelessly (and thus do not need to be sent in any particular order) with one exception: To form bidirectional peer relationships, DNCP requires identification of the endpoints used for communication. As bidirectional peer relationships are required for validating liveliness of published node data as described in Section 4.6, a DNCP node MUST send a Node Endpoint TLV (Section 7.2.1). When it is sent varies, depending on the underlying transport, but conceptually it should be available whenever processing a Network State TLV:
重新组装TLV；因此，必须确保底层传输在必要时执行这些操作。如果本文件指示发送一个或多个TLV，则发送节点无需在将数据包移交给相应传输后跟踪发送的数据包，即仅通过明确定义的计时器和状态机（如涓流）确保可靠的DNCP操作（第4.3节）。TLV通常是单独和无状态处理的（因此不需要以任何特定顺序发送），但有一个例外：为了形成双向对等关系，DNCP需要识别用于通信的端点。如第4.6节所述，验证已发布节点数据的活跃性需要双向对等关系，因此DNCP节点必须发送节点端点TLV（第7.2.1节）。发送时会有所不同，具体取决于基础传输，但从概念上讲，无论何时处理网络状态TLV，它都应该可用：
o If using a stream transport, the TLV MUST be sent at least once per connection but SHOULD NOT be sent more than once.
o 如果使用流传输，每个连接必须至少发送一次TLV，但不应发送多次。
o If using a datagram transport, it MUST be included in every datagram that also contains a Network State TLV (Section 7.2.2) and MUST be located before any such TLV. It SHOULD also be included in any other datagram to speed up initial peer detection.
o 如果使用数据报传输，则它必须包含在还包含网络状态TLV（第7.2.2节）的每个数据报中，并且必须位于任何此类TLV之前。它还应该包含在任何其他数据报中，以加速初始对等检测。
Given the assorted transport options as well as potential endpoint configuration, a DNCP endpoint may be used in various transport modes:
考虑到各种运输选项以及潜在的端点配置，DNCP端点可用于各种运输模式：
Unicast:
单播：
* If only reliable unicast transport is used, Trickle is not used at all. Whenever the locally calculated network state hash changes, a single Network State TLV (Section 7.2.2) is sent to every unicast peer. Additionally, recently changed Node State TLVs (Section 7.2.3) MAY be included.
* 如果只使用可靠的单播传输，则根本不使用涓流。每当本地计算的网络状态散列改变时，一个网络状态TLV（第7.2.2节）被发送到每个单播对等方。此外，可能包括最近更改的节点状态TLV（第7.2.3节）。
* If only unreliable unicast transport is used, Trickle state is kept per peer, and it is used to send Network State TLVs intermittently, as specified in Section 4.3.
* 如果仅使用不可靠的单播传输，则每个对等方都会保持涓流状态，并按照第4.3节的规定，使用涓流状态间歇发送网络状态TLV。
Multicast+Unicast: If multicast datagram transport is available on an endpoint, Trickle state is only maintained for the endpoint as a whole. It is used to send Network State TLVs periodically, as specified in Section 4.3. Additionally, per-endpoint keep-alives MAY be defined in the DNCP profile, as specified in Section 6.1.2.
多播+单播：如果多播数据报传输在端点上可用，则仅为整个端点保持涓流状态。按照第4.3节的规定，它用于定期发送网络状态TLV。此外，按照第6.1.2节的规定，每个端点保持有效性可在DNCP配置文件中定义。
MulticastListen+Unicast: Just like unicast, except multicast transmissions are listened to in order to detect changes of the highest node identifier. This mode is used only if the DNCP profile supports dense multicast-enabled link optimization (Section 6.2).
MulticastListen+单播：与单播一样，只不过会监听多播传输以检测最高节点标识符的变化。仅当DNCP配置文件支持密集多播启用的链路优化时，才使用此模式（第6.2节）。
The Trickle algorithm [RFC6206] is used to ensure protocol reliability over unreliable multicast or unicast transports. For reliable unicast transports, its actual algorithm is unnecessary and omitted (Section 4.2). DNCP maintains multiple Trickle states as defined in Section 5. Each such state can be based on different parameters (see below) and is responsible for ensuring that a specific peer or all peers on the respective endpoint are regularly provided with the node's current locally calculated network state hash for state comparison, i.e., to detect potential divergence in the perceived network state.
涓流算法[RFC6206]用于确保在不可靠的多播或单播传输上的协议可靠性。对于可靠的单播传输，其实际算法是不必要的，并且省略了（第4.2节）。DNCP保持第5节中定义的多个涓流状态。每个这样的状态可以基于不同的参数（见下文），并负责确保向各个端点上的特定对等方或所有对等方定期提供节点的当前本地计算的网络状态散列以进行状态比较，即，检测感知到的网络状态中的潜在分歧。
Trickle defines 3 parameters: Imin, Imax, and k. Imin and Imax represent the minimum value for I and the maximum number of doublings of Imin, where I is the time interval during which at least k Trickle updates must be seen on an endpoint to prevent local state transmission. The actual suggested Trickle algorithm parameters are DNCP profile specific, as described in Section 9.
涓流定义了3个参数：Imin、Imax和k。Imin和Imax表示I的最小值和Imin的最大加倍次数，其中I是一个时间间隔，在此期间，必须在端点上看到至少k个涓流更新，以防止本地状态传输。如第9节所述，实际建议的涓流算法参数是特定于DNCP剖面的。
The Trickle state for all Trickle instances defined in Section 5 is considered inconsistent and reset if and only if the locally calculated network state hash changes. This occurs either due to a change in the local node's own node data or due to the receipt of more recent data from another node as explained in Section 4.1. A node MUST NOT reset its Trickle state merely based on receiving a Network State TLV (Section 7.2.2) with a network state hash that is different from its locally calculated one.
当且仅当本地计算的网络状态散列发生变化时，第5节中定义的所有涓流实例的涓流状态被视为不一致并重置。发生这种情况的原因可能是本地节点自身节点数据的变化，也可能是如第4.1节所述，从另一个节点接收到较新的数据。节点不得仅根据接收到的网络状态TLV（第7.2.2节）以及不同于其本地计算的网络状态散列来重置其涓流状态。
Every time a particular Trickle instance indicates that an update should be sent, the node MUST send a Network State TLV (Section 7.2.2) if and only if:
每次特定涓流实例指示应发送更新时，节点必须发送网络状态TLV（第7.2.2节），如果且仅当：
o the endpoint is in Multicast+Unicast transport mode, in which case the TLV MUST be sent over multicast.
o 端点处于多播+单播传输模式，在这种情况下，TLV必须通过多播发送。
o the endpoint is NOT in Multicast+Unicast transport mode, and the unicast transport is unreliable, in which case the TLV MUST be sent over unicast.
o 端点未处于多播+单播传输模式，且单播传输不可靠，在这种情况下，必须通过单播发送TLV。
A (sub)set of all Node State TLVs (Section 7.2.3) MAY also be included, unless it is defined as undesirable for some reason by the DNCP profile or to avoid exposure of the node state TLVs by transmitting them within insecure multicast when using secure unicast.
也可以包括所有节点状态TLV（第7.2.3节）的（子）集，除非DNCP配置文件出于某种原因将其定义为不可取的，或者在使用安全单播时通过在不安全多播中传输来避免暴露节点状态TLV。
This section describes how received TLVs are processed. The DNCP profile may specify when to ignore particular TLVs, e.g., to modify security properties -- see Section 9 for what may be safely defined to be ignored in a profile. Any 'reply' mentioned in the steps below denotes the sending of the specified TLV(s) to the originator of the TLV being processed. All such replies MUST be sent using unicast. If the TLV being replied to was received via multicast and it was sent to a multiple access link, the reply MUST be delayed by a random time span in [0, Imin/2], to avoid potential simultaneous replies that may cause problems on some links, unless specified differently in the DNCP profile. The sending of replies MAY also be rate limited or omitted for a short period of time by an implementation. However, if the TLV is not forbidden by the DNCP profile, an implementation MUST reply to retransmissions of the TLV with a non-zero probability to avoid starvation, which would break the state synchronization.
本节介绍如何处理收到的TLV。DNCP配置文件可以指定何时忽略特定TLV，例如修改安全属性——请参阅第9节，了解配置文件中可以安全定义为忽略的内容。以下步骤中提到的任何“回复”表示将指定的TLV发送给正在处理的TLV的发起人。所有此类回复必须使用单播发送。如果要回复的TLV是通过多播接收的，并且被发送到多址链路，则回复必须延迟[0，Imin/2]中的随机时间跨度，以避免可能导致某些链路出现问题的潜在同步回复，除非DNCP配置文件中另有规定。响应的发送也可以由实现在短时间内被速率限制或省略。但是，如果DNCP配置文件未禁止TLV，则实现必须以非零概率回复TLV的重新传输，以避免饥饿，这将破坏状态同步。
A DNCP node MUST process TLVs received from any valid (e.g., correctly scoped) address, as specified by the DNCP profile and the configuration of a particular endpoint, whether this address is known to be the address of a peer or not. This provision satisfies the needs of monitoring or other host software that needs to discover the DNCP topology without adding to the state in the network.
DNCP节点必须处理从任何有效（例如，范围正确）地址接收的TLV，如DNCP配置文件和特定端点的配置所指定，无论该地址是否已知为对等方的地址。这项规定满足了需要在不增加网络状态的情况下发现DNCP拓扑的监控或其他主机软件的需要。
Upon receipt of:
收到下列文件后：
o Request Network State TLV (Section 7.1.1): The receiver MUST reply with a Network State TLV (Section 7.2.2) and a Node State TLV (Section 7.2.3) for each node data used to calculate the network state hash. The Node State TLVs SHOULD NOT contain the optional node data part to avoid redundant transmission of node data, unless explicitly specified in the DNCP profile.
o 请求网络状态TLV（第7.1.1节）：对于用于计算网络状态哈希的每个节点数据，接收器必须使用网络状态TLV（第7.2.2节）和节点状态TLV（第7.2.3节）进行回复。除非DNCP配置文件中明确规定，否则节点状态TLV不应包含可选的节点数据部分，以避免节点数据的冗余传输。
o Request Node State TLV (Section 7.1.2): If the receiver has node data for the corresponding node, it MUST reply with a Node State TLV (Section 7.2.3) for the corresponding node. The optional node data part MUST be included in the TLV.
o 请求节点状态TLV（第7.1.2节）：如果接收器具有对应节点的节点数据，则必须使用对应节点的节点状态TLV（第7.2.3节）进行回复。TLV中必须包含可选节点数据部分。
o Network State TLV (Section 7.2.2): If the network state hash differs from the locally calculated network state hash, and the receiver is unaware of any particular node state differences with
o 网络状态TLV（第7.2.2节）：如果网络状态散列与本地计算的网络状态散列不同，并且接收方不知道与本地计算的网络状态散列存在任何特定的节点状态差异
the sender, the receiver MUST reply with a Request Network State TLV (Section 7.1.1). These replies MUST be rate limited to only at most one reply per link per unique network state hash within Imin. The simplest way to ensure this rate limit is a timestamp indicating requests and sending at most one Request Network State TLV (Section 7.1.1) per Imin. To facilitate faster state synchronization, if a Request Network State TLV is sent in a reply, a local, current Network State TLV MAY also be sent.
发送方和接收方必须回复请求网络状态TLV（第7.1.1节）。对于Imin中的每个唯一网络状态哈希，这些回复的速率必须限制为每个链接最多只能有一个回复。确保此速率限制的最简单方法是使用一个时间戳来指示请求，并在每个Imin中最多发送一个请求网络状态TLV（第7.1.1节）。为了促进更快的状态同步，如果在应答中发送请求网络状态TLV，则还可以发送本地当前网络状态TLV。
o Node State TLV (Section 7.2.3):
o 节点状态TLV（第7.2.3节）：
* If the node identifier matches the local node identifier and the TLV has a greater sequence number than its current local value, or the same sequence number and a different hash, the node SHOULD republish its own node data with a sequence number significantly greater than the received one (e.g., 1000) to reclaim the node identifier. This difference is needed in order to ensure that it is higher than any potentially lingering copies of the node state in the network. This may occur normally once due to the local node restarting and not storing the most recently used sequence number. If this occurs more than once or for nodes not republishing their own node data, the DNCP profile MUST provide guidance on how to handle these situations as it indicates the existence of another active node with the same node identifier.
* 如果节点标识符与本地节点标识符匹配，并且TLV的序列号大于其当前本地值，或者相同的序列号和不同的散列，则节点应重新发布其自身的节点数据，其序列号显著大于接收到的序列号（例如，1000），以回收节点标识符。需要此差异，以确保其高于网络中节点状态的任何潜在延迟副本。由于本地节点重新启动且未存储最近使用的序列号，这通常会发生一次。如果这种情况发生不止一次，或者对于未重新发布其自身节点数据的节点，DNCP配置文件必须提供如何处理这些情况的指导，因为它指示存在具有相同节点标识符的另一个活动节点。
* If the node identifier does not match the local node identifier, and one or more of the following conditions are true:
* 如果节点标识符与本地节点标识符不匹配，并且以下一个或多个条件为真：
+ The local information is outdated for the corresponding node (the local sequence number is less than that within the TLV).
+ 对应节点的本地信息已过时（本地序列号小于TLV内的序列号）。
+ The local information is potentially incorrect (the local sequence number matches but the node data hash differs).
+ 本地信息可能不正确（本地序列号匹配，但节点数据哈希不同）。
+ There is no data for that node altogether.
+ 该节点完全没有数据。
Then:
然后：
+ If the TLV contains the Node Data field, it SHOULD also be verified by ensuring that the locally calculated hash of the node data matches the content of the H(Node Data) field within the TLV. If they differ, the TLV SHOULD be ignored and not processed further.
+ 如果TLV包含节点数据字段，还应通过确保节点数据的本地计算散列与TLV内H（节点数据）字段的内容匹配来验证。如果它们不同，则应忽略TLV，而不是进一步处理。
+ If the TLV does not contain the Node Data field, and the H(Node Data) field within the TLV differs from the local node data hash for that node (or there is none), the receiver MUST reply with a Request Node State TLV (Section 7.1.2) for the corresponding node.
+ 如果TLV不包含节点数据字段，并且TLV中的H（节点数据）字段与该节点的本地节点数据哈希不同（或者没有），则接收方必须使用相应节点的请求节点状态TLV（第7.1.2节）进行回复。
+ Otherwise, the receiver MUST update its locally stored state for that node (node data based on the Node Data field if present, sequence number, and relative time) to match the received TLV.
+ 否则，接收器必须更新该节点的本地存储状态（基于节点数据字段（如果存在）、序列号和相对时间的节点数据），以匹配接收到的TLV。
For comparison purposes of the sequence number, a looping comparison function MUST be used to avoid problems in case of overflow. The comparison function a < b <=> ((a - b) % (2^32)) & (2^31) != 0 where (a % b) represents the remainder of a modulo b and (a & b) represents bitwise conjunction of a and b is RECOMMENDED unless the DNCP profile defines another.
为了比较序列号，必须使用循环比较函数，以避免溢出时出现问题。比较函数a<b<=>（（a-b）%（2^32））和（2^31）！=0，其中（a%b）表示模b的剩余部分，（a&b）表示a和b的按位结合，建议使用，除非DNCP配置文件定义了另一个。
o Any other TLV: TLVs not recognized by the receiver MUST be silently ignored unless they are sent within another TLV (for example, TLVs within the Node Data field of a Node State TLV). TLVs within the Node Data field of the Node State TLV not recognized by the receiver MUST be retained for distribution to other nodes and for calculation of the node data hash as described in Section 7.2.3 but are ignored for other purposes.
o 任何其他TLV：接收器无法识别的TLV必须被静默忽略，除非它们在另一个TLV内发送（例如，节点状态TLV的节点数据字段内的TLV）。接收器未识别的节点状态TLV的节点数据字段中的TLV必须保留，以便分配给其他节点，并用于计算第7.2.3节所述的节点数据散列，但出于其他目的忽略。
If secure unicast transport is configured for an endpoint, any Node State TLVs received over insecure multicast MUST be silently ignored.
如果为端点配置了安全单播传输，则通过不安全多播接收的任何节点状态TLV都必须被静默忽略。
Peer relations are established between neighbors using one or more mutually connected endpoints. Such neighbors exchange information about network state and published data directly, and through transitivity, this information then propagates throughout the network.
使用一个或多个相互连接的端点在邻居之间建立对等关系。这些邻居直接交换有关网络状态和已发布数据的信息，然后通过传递性将这些信息传播到整个网络。
New peers are discovered using the regular unicast or multicast transport defined in the DNCP profile (Section 9). This process is not distinguished from peer addition, i.e., an unknown peer is simply discovered by receiving regular DNCP protocol TLVs from it, and dedicated discovery messages or TLVs do not exist. For unicast-only transports, the individual node's transport addresses are preconfigured or obtained using an external service discovery protocol. In the presence of a multicast transport, messages from unknown peers are handled in the same way as multicast messages from peers that are already known; thus, new peers are simply discovered when sending their regular DNCP protocol TLVs using multicast.
使用DNCP配置文件（第9节）中定义的常规单播或多播传输发现新的对等点。此过程与对等添加没有区别，即，通过从其接收常规DNCP协议TLV来发现未知对等，并且不存在专用的发现消息或TLV。对于仅单播传输，使用外部服务发现协议预配置或获取单个节点的传输地址。在存在多播传输的情况下，以与来自已知对等方的多播消息相同的方式处理来自未知对等方的消息；因此，当使用多播发送其常规DNCP协议TLV时，只需发现新的对等点。
When receiving a Node Endpoint TLV (Section 7.2.1) on an endpoint from an unknown peer:
从未知对等方接收端点上的节点端点TLV（第7.2.1节）时：
o If received over unicast, the remote node MUST be added as a peer on the endpoint, and a Peer TLV (Section 7.3.1) MUST be created for it.
o 如果通过单播接收，则必须将远程节点添加为端点上的对等节点，并且必须为其创建对等TLV（第7.3.1节）。
o If received over multicast, the node MAY be sent a (possibly rate-limited) unicast Request Network State TLV (Section 7.1.1).
o 如果通过多播接收，则可向节点发送（可能速率受限的）单播请求网络状态TLV（第7.1.1节）。
If keep-alives specified in Section 6.1 are NOT sent by the peer (either the DNCP profile does not specify the use of keep-alives or the particular peer chooses not to send keep-alives), some other existing local transport-specific means (such as Ethernet carrier detection or TCP keep-alive) MUST be used to ensure its presence. If the peer does not send keep-alives, and no means to verify presence of the peer are available, the peer MUST be considered no longer present, and it SHOULD NOT be added back as a peer until it starts sending keep-alives again. When the peer is no longer present, the Peer TLV and the local DNCP peer state MUST be removed. DNCP does not define an explicit message or TLV for indicating the termination of DNCP operation by the terminating node; however, a derived protocol could specify an extension, if the need arises.
如果对等方未发送第6.1节中规定的保持有效性（DNCP配置文件未指定保持有效性的使用，或特定对等方选择不发送保持有效性），则必须使用其他现有的本地传输特定方式（如以太网载波检测或TCP保持有效性）来确保其存在。如果该对等方未发送保留有效信息，且无法验证该对等方是否存在，则必须将该对等方视为不再存在，并且在其再次开始发送保留有效信息之前，不应将其添加回对等方。当对等机不再存在时，必须删除对等TLV和本地DNCP对等机状态。DNCP未定义用于指示终止节点终止DNCP操作的显式消息或TLV；但是，如果需要，派生协议可以指定扩展。
If the local endpoint is in the Multicast-Listen+Unicast transport mode, a Peer TLV (Section 7.3.1) MUST NOT be published for the peers not having the highest node identifier.
如果本地端点处于多播侦听+单播传输模式，则不得为没有最高节点标识符的对等方发布对等TLV（第7.3.1节）。
Maintenance of the hash tree (Section 4.1) and thereby network state hash updates depend on up-to-date information on bidirectional node reachability derived from the contents of a topology graph. This graph changes whenever nodes are added to or removed from the network or when bidirectional connectivity between existing nodes is established or lost. Therefore, the graph MUST be updated either immediately or with a small delay shorter than the DNCP profile-defined Trickle Imin whenever:
散列树（第4.1节）的维护以及网络状态散列更新取决于从拓扑图内容导出的双向节点可达性的最新信息。每当将节点添加到网络或从网络中删除节点时，或者当现有节点之间的双向连接建立或丢失时，此图都会更改。因此，在以下情况下，必须立即更新图表，或在短于DNCP配置文件定义的涓流Imin的小延迟时间内更新图表：
o A Peer TLV or a whole node is added or removed, or
o 添加或删除对等TLV或整个节点，或
o The origination time (in milliseconds) of some node's node data is less than current time - 2^32 + 2^15.
o 某些节点的节点数据的起始时间（毫秒）小于当前时间-2^32+2^15。
The artificial upper limit for the origination time is used to gracefully avoid overflows of the origination time and allow for the node to republish its data as noted in Section 7.2.3.
如第7.2.3节所述，人为设定的起始时间上限用于合理避免起始时间溢出，并允许节点重新发布其数据。
The topology graph update starts with the local node marked as reachable and all other nodes marked as unreachable. Other nodes are then iteratively marked as reachable using the following algorithm: A candidate not-yet-reachable node N with an endpoint NE is marked as reachable if there is a reachable node R with an endpoint RE that meets all of the following criteria:
拓扑图更新从标记为可访问的本地节点和标记为不可访问的所有其他节点开始。然后，使用以下算法将其他节点迭代标记为可到达：如果存在可到达节点R，且其端点RE满足以下所有条件，则具有端点NE的尚未到达的候选节点N将标记为可到达：
o The origination time (in milliseconds) of R's node data is greater than current time - 2^32 + 2^15.
o R的节点数据的起始时间（以毫秒为单位）大于当前时间-2^32+2^15。
o R publishes a Peer TLV with:
o R发布对等TLV，其中包含：
* Peer Node Identifier = N's node identifier
* 对等节点标识符=N的节点标识符
* Peer Endpoint Identifier = NE's endpoint identifier
* 对等端点标识符=网元的端点标识符
* Endpoint Identifier = RE's endpoint identifier
* 端点标识符=RE的端点标识符
o N publishes a Peer TLV with:
o N发布具有以下内容的对等TLV：
* Peer Node Identifier = R's node identifier
* 对等节点标识符=R的节点标识符
* Peer Endpoint Identifier = RE's endpoint identifier
* 对等端点标识符=RE的端点标识符
* Endpoint Identifier = NE's endpoint identifier
* 端点标识符=网元的端点标识符
The algorithm terminates when no more candidate nodes fulfilling these criteria can be found.
当无法找到满足这些条件的更多候选节点时，该算法终止。
DNCP nodes that have not been reachable in the most recent topology graph traversal MUST NOT be used for calculation of the network state hash, be provided to any applications that need to use the whole TLV graph, or be provided to remote nodes. They MAY be forgotten immediately after the topology graph traversal; however, it is RECOMMENDED to keep them at least briefly to improve the speed of DNCP network state convergence. This reduces the number of queries needed to reconverge during both initial network convergence and when a part of the network loses and regains bidirectional connectivity within that time period.
在最近的拓扑图遍历中无法访问的DNCP节点不得用于计算网络状态哈希，不得提供给需要使用整个TLV图的任何应用程序，也不得提供给远程节点。在拓扑图遍历之后，它们可能会立即被遗忘；但是，建议至少短暂保留它们，以提高DNCP网络状态收敛的速度。这减少了在初始网络聚合期间以及当网络的一部分在该时间段内失去并恢复双向连接时重新聚合所需的查询数量。
This section describes the local data structures a minimal implementation might use. This section is provided only as a convenience for the implementor. Some of the optional extensions (Section 6) describe additional data requirements, and some optional parts of the core protocol may also require more.
本节介绍最小实现可能使用的本地数据结构。本节仅为方便实施者而提供。一些可选扩展（第6节）描述了额外的数据需求，核心协议的一些可选部分也可能需要更多的数据。
A DNCP node has:
DNCP节点具有：
o A data structure containing data about the most recently sent Request Network State TLVs (Section 7.1.1). The simplest option is keeping a timestamp of the most recent request (required to fulfill reply rate limiting specified in Section 4.4).
o 一种数据结构，包含关于最近发送的请求网络状态TLV的数据（第7.1.1节）。最简单的选择是保留最近请求的时间戳（需要满足第4.4节中规定的回复速率限制）。
A DNCP node has the following for every DNCP node in the DNCP network:
DNCP节点对于DNCP网络中的每个DNCP节点具有以下功能：
o Node identifier: the unique identifier of the node. The length, how it is produced, and how collisions are handled is up to the DNCP profile.
o 节点标识符：节点的唯一标识符。长度、如何产生以及如何处理冲突取决于DNCP配置文件。
o Node data: the set of TLV tuples published by that particular node. As they are transmitted in a particular order (see Node State TLV (Section 7.2.3) for details), maintaining the order within the data structure here may be reasonable.
o 节点数据：由特定节点发布的TLV元组集。由于它们是以特定顺序传输的（详情见节点状态TLV（第7.2.3节）），因此在数据结构中保持顺序可能是合理的。
o Latest sequence number: the 32-bit sequence number that is incremented any time the TLV set is published. The comparison function used to compare them is described in Section 4.4.
o 最新序列号：发布TLV集时递增的32位序列号。第4.4节描述了用于比较它们的比较函数。
o Origination time: the (estimated) time when the current TLV set with the current sequence number was published. It is used to populate the Milliseconds Since Origination field in a Node State TLV (Section 7.2.3). Ideally, it also has millisecond accuracy.
o 起始时间：发布具有当前序列号的当前TLV集的（估计）时间。它用于填充节点状态TLV（第7.2.3节）中的“起始毫秒数”字段。理想情况下，它还具有毫秒精度。
Additionally, a DNCP node has a set of endpoints for which DNCP is configured to be used. For each such endpoint, a node has:
此外，DNCP节点具有一组端点，DNCP被配置为用于这些端点。对于每个这样的端点，节点具有：
o Endpoint identifier: the 32-bit opaque locally unique value identifying the endpoint within a node. It SHOULD NOT be reused immediately after an endpoint is disabled.
o 端点标识符：标识节点内端点的32位不透明本地唯一值。不应在禁用终结点后立即重用它。
o Trickle instance: the endpoint's Trickle instance with parameters I, T, and c (only on an endpoint in Multicast+Unicast transport mode).
o 涓流实例：端点的涓流实例，参数为I、T和c（仅在多播+单播传输模式下的端点上）。
and one (or more) of the following:
以及以下一项（或多项）：
o Interface: the assigned local network interface.
o 接口：指定的本地网络接口。
o Unicast address: the DNCP node it should connect with.
o 单播地址：它应该连接的DNCP节点。
o Set of addresses: the DNCP nodes from which connections are accepted.
o 地址集：接受连接的DNCP节点。
For each remote (peer, endpoint) pair detected on a local endpoint, a DNCP node has:
对于在本地端点上检测到的每个远程（对等、端点）对，DNCP节点具有：
o Node identifier: the unique identifier of the peer.
o 节点标识符：对等方的唯一标识符。
o Endpoint identifier: the unique endpoint identifier used by the peer.
o 端点标识符：对等方使用的唯一端点标识符。
o Peer address: the most recently used address of the peer (authenticated and authorized, if security is enabled).
o 对等地址：对等方最近使用的地址（如果启用了安全性，则经过身份验证和授权）。
o Trickle instance: the particular peer's Trickle instance with parameters I, T, and c (only on an endpoint in unicast mode, when using an unreliable unicast transport).
o 涓流实例：具有参数I、T和c的特定对等方的涓流实例（仅在单播模式下的端点上，当使用不可靠的单播传输时）。
This section specifies extensions to the core protocol that a DNCP profile may specify to be used.
本节指定了DNCP配置文件可能指定使用的核心协议的扩展。
While DNCP provides mechanisms for discovery and adding new peers on an endpoint (Section 4.5), as well as state change notifications, another mechanism may be needed to get rid of old, no longer valid peers if the transport or lower layers do not provide one as noted in Section 4.6.
虽然DNCP提供了在端点上发现和添加新对等点的机制（第4.5节）以及状态更改通知，但如果传输层或较低层未提供第4.6节所述的机制，则可能需要另一种机制来清除旧的、不再有效的对等点。
If keep-alives are not specified in the DNCP profile, the rest of this subsection MUST be ignored.
如果DNCP配置文件中未规定保持有效，则必须忽略本小节的其余部分。
A DNCP profile MAY specify either per-endpoint (sent using multicast to all DNCP nodes connected to a multicast-enabled link) or per-peer (sent using unicast to each peer individually) keep-alive support.
DNCP配置文件可以指定每个端点（使用多播发送到连接到启用多播的链路的所有DNCP节点）或每个对等点（单独使用单播发送到每个对等点）保持活动支持。
For every endpoint that a keep-alive is specified for in the DNCP profile, the endpoint-specific keep-alive interval MUST be maintained. By default, it is DNCP_KEEPALIVE_INTERVAL. If there is a local value that is preferred for that for any reason (configuration, energy conservation, media type, ...), it can be substituted instead. If a non-default keep-alive interval is used on any endpoint, a DNCP node MUST publish an appropriate Keep-Alive Interval TLV(s) (Section 7.3.2) within its node data.
对于DNCP配置文件中为其指定保持活动的每个端点，必须保持端点特定的保持活动间隔。默认情况下，它是DNCP_KEEPALIVE_INTERVAL。如果出于任何原因（配置、节能、介质类型等）存在首选的局部值，则可以将其替换。如果在任何端点上使用非默认保持活动间隔，DNCP节点必须在其节点数据内发布适当的保持活动间隔TLV（第7.3.2节）。
The following additions to the Data Model (Section 5) are needed to support keep-alives:
需要在数据模型（第5节）中添加以下内容以支持keep alives：
For each configured endpoint that has per-endpoint keep-alives enabled:
对于已启用每个端点保持有效性的每个已配置端点：
o Last sent: If a timestamp that indicates the last time a Network State TLV (Section 7.2.2) was sent over that interface.
o 上次发送：如果时间戳指示网络状态TLV（第7.2.2节）上次通过该接口发送的时间。
For each remote (peer, endpoint) pair detected on a local endpoint, a DNCP node has:
对于在本地端点上检测到的每个远程（对等、端点）对，DNCP节点具有：
o Last contact timestamp: A timestamp that indicates the last time a consistent Network State TLV (Section 7.2.2) was received from the peer over multicast or when anything was received over unicast. Failing to update it for a certain amount of time as specified in Section 6.1.5 results in the removal of the peer. When adding a new peer, it is initialized to the current time.
o Last contact timestamp：一个时间戳，指示通过多播从对等方接收到一致网络状态TLV（第7.2.2节）的最后时间，或通过单播接收到任何内容的最后时间。如果未能按照第6.1.5节的规定在一定时间内对其进行更新，将导致对等服务器被删除。添加新的对等点时，它将初始化为当前时间。
o Last sent: If per-peer keep-alives are enabled, a timestamp that indicates the last time a Network State TLV (Section 7.2.2) was sent to that point-to-point peer. When adding a new peer, it is initialized to the current time.
o 上次发送：如果启用了每个对等方保持有效性，则时间戳指示上次向该点对点对等方发送网络状态TLV（第7.2.2节）的时间。添加新的对等点时，它将初始化为当前时间。
If per-endpoint keep-alives are enabled on an endpoint in Multicast+Unicast transport mode, and if no traffic containing a Network State TLV (Section 7.2.2) has been sent to a particular endpoint within the endpoint-specific keep-alive interval, a Network State TLV (Section 7.2.2) MUST be sent on that endpoint, and a new Trickle interval started, as specified in step 2 of Section 4.2 of [RFC6206]. The actual sending time SHOULD be further delayed by a random time span in [0, Imin/2].
如果在多播+单播传输模式下的端点上启用了每端点保持活动，并且在特定于端点的保持活动间隔内未向特定端点发送包含网络状态TLV（第7.2.2节）的流量，则必须在该端点上发送网络状态TLV（第7.2.2节），并启动新的涓流间隔，按照[RFC6206]第4.2节第2步的规定。实际发送时间应进一步延迟[0，Imin/2]中的随机时间跨度。
If per-peer keep-alives are enabled on a unicast-only endpoint, and if no traffic containing a Network State TLV (Section 7.2.2) has been sent to a particular peer within the endpoint-specific keep-alive interval, a Network State TLV (Section 7.2.2) MUST be sent to the peer, and a new Trickle interval started, as specified in step 2 of Section 4.2 of [RFC6206].
如果在仅单播的端点上启用了每个对等方的保持活动，并且在特定于端点的保持活动间隔内未向特定对等方发送包含网络状态TLV（第7.2.2节）的流量，则必须向对等方发送网络状态TLV（第7.2.2节），并启动新的涓流间隔，按照[RFC6206]第4.2节第2步的规定。
If a TLV is received over unicast from the peer, the Last contact timestamp for the peer MUST be updated.
如果通过单播从对等方接收TLV，则必须更新对等方的最后联系时间戳。
On receipt of a Network State TLV (Section 7.2.2) that is consistent with the locally calculated network state hash, the Last contact timestamp for the peer MUST be updated in order to maintain it as a peer.
在收到与本地计算的网络状态哈希一致的网络状态TLV（第7.2.2节）时，必须更新对等方的最后联系时间戳，以便将其保持为对等方。
For every peer on every endpoint, the endpoint-specific keep-alive interval must be calculated by looking for Keep-Alive Interval TLVs (Section 7.3.2) published by the node, and if none exist, use the default value of DNCP_KEEPALIVE_INTERVAL. If the peer's Last contact timestamp has not been updated for at least a locally chosen potentially endpoint-specific keep-alive multiplier (defaults to DNCP_KEEPALIVE_MULTIPLIER) times the peer's endpoint-specific keep-alive interval, the Peer TLV for that peer and the local DNCP peer state MUST be removed.
对于每个端点上的每个对等点，必须通过查找节点发布的保持活动间隔TLV（第7.3.2节）来计算特定于端点的保持活动间隔，如果不存在，则使用默认值DNCP_KEEPALIVE_interval。如果对等方的上一次联系时间戳未至少更新为本地选择的潜在特定于端点的保持活动乘数（默认为DNCP_KEEPALIVE_乘数）乘以对等方特定于端点的保持活动间隔，则必须删除该对等方的对等TLV和本地DNCP对等方状态。
This optimization is needed to avoid a state space explosion. Given a large set of DNCP nodes publishing data on an endpoint that uses multicast on a link, every node will add a Peer TLV (Section 7.3.1) for each peer. While Trickle limits the amount of traffic on the link in stable state to some extent, the total amount of data that is added to and maintained in the DNCP network given N nodes on a multicast-enabled link is O(N^2). Additionally, if per-peer keep-alives are used, there will be O(N^2) keep-alives running on the link if the liveliness of peers is not ensured using some other way (e.g., TCP connection lifetime, Layer 2 notification, or per-endpoint keep-alive).
这种优化需要避免状态空间爆炸。如果有大量DNCP节点在链路上使用多播的端点上发布数据，则每个节点将为每个节点添加一个对等TLV（第7.3.1节）。尽管涓流在某种程度上限制了处于稳定状态的链路上的通信量，但在启用多播的链路上，给定N个节点，添加到DNCP网络并在其中维护的数据总量为O（N^2）。此外，如果使用了每个对等方的保持有效性，则如果没有使用其他方式（例如TCP连接生存期、第2层通知或每个端点保持有效性）确保对等方的活跃性，则链路上将有O（N^2）个保持有效性运行。
An upper bound for the number of peers that are allowed for a particular type of link that an endpoint in Multicast+Unicast transport mode is used on SHOULD be provided by a DNCP profile, but it MAY also be chosen at runtime. The main consideration when selecting a bound (if any) for a particular type of link should be whether it supports multicast traffic and whether a too large number of peers case is likely to happen during the use of that DNCP profile on that particular type of link. If neither is likely, there is little point specifying support for this for that particular link type.
DNCP配置文件应提供允许使用多播+单播传输模式的端点的特定类型链路的对等点数量上限，但也可以在运行时选择该上限。在为特定类型的链路选择绑定（如果有）时，主要考虑的是它是否支持多播通信，以及在该特定类型的链路上使用该DNCP配置文件期间是否可能发生过多对等点的情况。如果两者都不可能，那么为特定链接类型指定对此的支持就没有什么意义了。
If a DNCP profile does not support this extension at all, the rest of this subsection MUST be ignored. This is because when this extension is used, the state within the DNCP network only contains a subset of the full topology of the network. Therefore, every node must be aware of the potential of it being used in a particular DNCP profile.
如果DNCP配置文件根本不支持此扩展，则必须忽略本小节的其余部分。这是因为使用此扩展时，DNCP网络内的状态仅包含网络完整拓扑的子集。因此，每个节点都必须知道它在特定DNCP配置文件中使用的可能性。
If the specified upper bound is exceeded for some endpoint in Multicast+Unicast transport mode and if the node does not have the highest node identifier on the link, it SHOULD treat the endpoint as a unicast endpoint connected to the node that has the highest node identifier detected on the link, therefore transitioning to Multicast-listen+Unicast transport mode. See Section 4.2 for implications on the specific endpoint behavior. The nodes in Multicast-listen+Unicast transport mode MUST keep listening to multicast traffic to both receive messages from the node(s) still in Multicast+Unicast mode and react to nodes with a greater node identifier appearing. If the highest node identifier present on the link changes, the remote unicast address of the endpoints in Multicast-Listen+Unicast transport mode MUST be changed. If the node identifier of the local node is the highest one, the node MUST switch back to, or stay in, Multicast+Unicast mode and form peer relationships with all peers as specified in Section 4.5.
如果在多播+单播传输模式下，某些终结点超过了指定的上限，并且如果该节点在链路上没有最高的节点标识符，则应将该终结点视为连接到具有在链路上检测到的最高节点标识符的节点的单播终结点，因此，过渡到多播侦听+单播传输模式。有关特定端点行为的含义，请参见第4.2节。处于多播侦听+单播传输模式的节点必须保持侦听多播通信量，以接收来自仍处于多播+单播模式的节点的消息，并对出现更大节点标识符的节点作出反应。如果链路上存在的最高节点标识符发生更改，则必须更改多播侦听+单播传输模式下端点的远程单播地址。如果本地节点的节点标识符是最高的，则该节点必须切换回或保持多播+单播模式，并按照第4.5节的规定与所有对等方形成对等关系。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (if any) (+padding (if any)) |
..
| (variable # of bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (optional nested TLVs) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (if any) (+padding (if any)) |
..
| (variable # of bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (optional nested TLVs) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Each TLV is encoded as:
每个TLV编码为：
o a 2-byte Type field
o 2字节类型的字段
o a 2-byte Length field, which contains the length of the Value field in bytes; 0 means no value
o 2字节长度字段，包含值字段的长度（字节）；0意味着没有价值
o the value itself (if any)
o 值本身（如果有）
o padding bytes with a value of zero up to the next 4-byte boundary if the Length is not divisible by 4
o 如果长度不能被4整除，则将值为零的字节填充到下一个4字节边界
While padding bytes MUST NOT be included in the number stored in the Length field of the TLV, if the TLV is enclosed within another TLV, then the padding is included in the enclosing TLV's Length value.
虽然填充字节不能包含在TLV的长度字段中存储的数字中，但如果TLV包含在另一个TLV中，则填充将包含在封闭TLV的长度值中。
Each TLV that does not define optional fields or variable-length content MAY be sent with additional sub-TLVs appended after the TLV to allow for extensibility. When handling such TLV types, each node MUST accept received TLVs that are longer than the fixed fields specified for the particular type and ignore the sub-TLVs with either unknown types or types not supported within that particular TLV. If any sub-TLVs are present, the Length field of the TLV describes the number of bytes from the first byte of the TLV's own Value (if any) to the last (padding) byte of the last sub-TLV.
每个未定义可选字段或可变长度内容的TLV可以在TLV之后附加附加子TLV以允许扩展性。在处理此类TLV类型时，每个节点必须接受比为特定类型指定的固定字段长的接收TLV，并忽略具有未知类型或该特定TLV中不支持的类型的子TLV。如果存在任何子TLV，TLV的长度字段描述从TLV自身值的第一个字节（如果有）到最后一个子TLV的最后一个（填充）字节的字节数。
For example, type=123 (0x7b) TLV with value 'x' (120 = 0x78) is encoded as: 007B 0001 7800 0000. If it were to have a sub-TLV of type=124 (0x7c) with value 'y', it would be encoded as 007B 000C 7800 0000 007C 0001 7900 0000.
例如，值为“x”（120=0x78）的type=123（0x7b）TLV编码为：007B 0001 7800 0000。如果它有一个类型为124（0x7c）且值为“y”的子TLV，它将被编码为007B 000C 7800 0000 007C 0001 7900 0000。
In this section, the following special notation is used:
在本节中，使用以下特殊符号：
.. = octet string concatenation operation.
.. = 八位字符串串联操作。
H(x) = non-cryptographic hash function specified by the DNCP profile.
H（x）=DNCP配置文件指定的非加密哈希函数。
In addition to the TLV types defined in this document, TLV Types 11-31 and 512-767 are unassigned and may be sequentially registered, starting at 11, by Standards Action [RFC5226] by extensions to DNCP that may be applicable in multiple DNCP profiles.
除了本文件中定义的TLV类型外，TLV类型11-31和512-767是未分配的，可以从11开始通过标准行动[RFC5226]通过DNCP扩展顺序注册，该扩展可适用于多个DNCP配置文件。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type: Request network state (1)| Length: >= 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type: Request network state (1)| Length: >= 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV is used to request response with a Network State TLV (Section 7.2.2) and all Node State TLVs (Section 7.2.3) (without node data).
该TLV用于请求具有网络状态TLV（第7.2.2节）和所有节点状态TLV（第7.2.3节）（无节点数据）的响应。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: Request node state (2) | Length: > 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node Identifier |
| (length fixed in DNCP profile) |
...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: Request node state (2) | Length: > 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node Identifier |
| (length fixed in DNCP profile) |
...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV is used to request a Node State TLV (Section 7.2.3) (including node data) for the node with the matching node identifier.
该TLV用于为具有匹配节点标识符的节点请求节点状态TLV（第7.2.3节）（包括节点数据）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: Node endpoint (3) | Length: > 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node Identifier |
| (length fixed in DNCP profile) |
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: Node endpoint (3) | Length: > 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node Identifier |
| (length fixed in DNCP profile) |
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV identifies both the local node's node identifier, as well as the particular endpoint's endpoint identifier. Section 4.2 specifies when it is sent.
此TLV标识本地节点的节点标识符以及特定端点的端点标识符。第4.2节规定了发送时间。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: Network state (4) | Length: > 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| H(sequence number of node 1 .. H(node data of node 1) .. |
| .. sequence number of node N .. H(node data of node N)) |
| (length fixed in DNCP profile) |
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: Network state (4) | Length: > 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| H(sequence number of node 1 .. H(node data of node 1) .. |
| .. sequence number of node N .. H(node data of node N)) |
| (length fixed in DNCP profile) |
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV contains the current network state hash calculated by its sender (Section 4.1 describes the algorithm).
此TLV包含由其发送方计算的当前网络状态哈希（第4.1节描述了算法）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: Node state (5) | Length: > 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node Identifier |
| (length fixed in DNCP profile) |
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Milliseconds Since Origination |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| H(Node Data) |
| (length fixed in DNCP profile) |
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (optionally) Node Data (a set of nested TLVs) |
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: Node state (5) | Length: > 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node Identifier |
| (length fixed in DNCP profile) |
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Milliseconds Since Origination |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| H(Node Data) |
| (length fixed in DNCP profile) |
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (optionally) Node Data (a set of nested TLVs) |
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV represents the local node's knowledge about the published state of a node in the DNCP network identified by the Node Identifier field in the TLV.
此TLV表示本地节点对DNCP网络中由TLV中的节点标识符字段标识的节点的已发布状态的了解。
Every node, including the node publishing the node data, MUST update the Milliseconds Since Origination whenever it sends a Node State TLV based on when the node estimates the data was originally published. This is, e.g., to ensure that any relative timestamps contained within the published node data can be correctly offset and
每个节点（包括发布节点数据的节点）都必须根据节点估计数据最初发布的时间，在发送节点状态TLV时更新自发起以来的毫秒数。例如，这是为了确保包含在已发布的节点数据中的任何相对时间戳可以正确地偏移和删除
interpreted. Ultimately, what is provided is just an approximation, as transmission delays are not accounted for.
解释。最终，所提供的只是一个近似值，因为没有考虑传输延迟。
Absent any changes, if the originating node notices that the 32-bit Milliseconds Since Origination value would be close to overflow (greater than 2^32 - 2^16), the node MUST republish its TLVs even if there is no change. In other words, absent any other changes, the TLV set MUST be republished roughly every 48 days.
在没有任何更改的情况下，如果发起节点注意到自发起值起的32位毫秒将接近溢出（大于2^32-2^16），则即使没有更改，该节点也必须重新发布其TLV。换句话说，如果没有任何其他更改，TLV集必须大约每48天重新发布一次。
The actual node data of the node may be included within the TLV as well as in the optional Node Data field. The set of TLVs MUST be strictly ordered based on ascending binary content (including TLV type and length). This enables, e.g., efficient state delta processing and no-copy indexing by TLV type by the recipient. The node data content MUST be passed along exactly as it was received. It SHOULD be also verified on receipt that the locally calculated H(Node Data) matches the content of the field within the TLV, and if the hash differs, the TLV SHOULD be ignored.
节点的实际节点数据可以包括在TLV中以及可选节点数据字段中。TLV集必须严格按照升序二进制内容（包括TLV类型和长度）排序。例如，这使得收件人能够高效地进行状态增量处理，并且不需要按TLV类型进行复制索引。节点数据内容的传递必须与接收时完全一致。还应在收到时验证本地计算的H（节点数据）是否与TLV内的字段内容匹配，如果哈希不同，则应忽略TLV。
These TLVs are published by the DNCP nodes and are therefore only encoded in the Node Data field of Node State TLVs. If encountered outside Node State TLV, they MUST be silently ignored.
这些TLV由DNCP节点发布，因此仅在节点状态TLV的节点数据字段中编码。如果在节点状态TLV之外遇到，则必须静默忽略它们。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: Peer (8) | Length: > 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Node Identifier |
| (length fixed in DNCP profile) |
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Endpoint Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Local) Endpoint Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: Peer (8) | Length: > 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Node Identifier |
| (length fixed in DNCP profile) |
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Endpoint Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Local) Endpoint Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV indicates that the node in question vouches that the specified peer is reachable by it on the specified local endpoint. The presence of this TLV at least guarantees that the node publishing it has received traffic from the peer recently. For guaranteed up-to-date bidirectional reachability, the existence of both nodes' matching Peer TLVs needs to be checked.
此TLV表示有问题的节点保证指定的对等方可以在指定的本地端点上访问。此TLV的存在至少保证发布它的节点最近已从对等方接收到流量。为了保证最新的双向可达性，需要检查两个节点是否存在匹配的对等TLV。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: Keep-alive interval (9) | Length: >= 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: Keep-alive interval (9) | Length: >= 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV indicates a non-default interval being used to send keep-alives as specified in Section 6.1.
该TLV表示用于发送第6.1节中规定的保留有效期的非默认间隔。
Endpoint identifier is used to identify the particular (local) endpoint for which the interval applies on the sending node. If 0, it applies for ALL endpoints for which no specific TLV exists.
端点标识符用于标识在发送节点上应用间隔的特定（本地）端点。如果为0，则它适用于不存在特定TLV的所有端点。
Interval specifies the interval in milliseconds at which the node sends keep-alives. A value of zero means no keep-alives are sent at all; in that case, some lower-layer mechanism that ensures the presence of nodes MUST be available and used.
Interval指定节点发送keep alives的时间间隔（以毫秒为单位）。值为零意味着根本不发送保留有效信息；在这种情况下，必须使用一些确保节点存在的较低层机制。
If specified in the DNCP profile, either DTLS [RFC6347] or TLS [RFC5246] may be used to authenticate and encrypt either some (if specified optional in the profile) or all unicast traffic. The following methods for establishing trust are defined, but it is up to the DNCP profile to specify which ones may, should, or must be supported.
如果在DNCP配置文件中指定，则DTLS[RFC6347]或TLS[RFC5246]可用于验证和加密部分（如果配置文件中指定为可选）或所有单播流量。定义了以下建立信任的方法，但由DNCP配置文件指定哪些方法可以、应该或必须得到支持。
A trust model based on Pre-Shared Key (PSK) is a simple security management mechanism that allows an administrator to deploy devices to an existing network by configuring them with a predefined key, similar to the configuration of an administrator password or Wi-Fi Protected Access (WPA) key. Although limited in nature, it is useful to provide a user-friendly security mechanism for smaller networks.
基于预共享密钥（PSK）的信任模型是一种简单的安全管理机制，它允许管理员通过使用预定义密钥配置设备来将设备部署到现有网络，类似于管理员密码或Wi-Fi保护访问（WPA）密钥的配置。尽管本质上有限，但为较小的网络提供用户友好的安全机制是有用的。
A PKI-based trust model enables more advanced management capabilities at the cost of increased complexity and bootstrapping effort. However, it allows trust to be managed in a centralized manner and is therefore useful for larger networks with a need for an authoritative trust management.
基于PKI的信任模型实现了更高级的管理功能，但代价是增加了复杂性和引导工作。但是，它允许以集中的方式管理信任，因此对于需要权威信任管理的大型网络非常有用。
For some scenarios -- such as bootstrapping a mostly unmanaged network -- the methods described above may not provide a desirable trade-off between security and user experience. This section includes guidance for implementing an opportunistic security [RFC7435] method that DNCP profiles can build upon and adapt for their specific requirements.
对于某些场景（例如引导一个大部分不受管理的网络），上述方法可能无法在安全性和用户体验之间提供理想的折衷。本节包括实施机会安全[RFC7435]方法的指南，DNCP配置文件可基于该方法构建并适应其特定要求。
The certificate-based consensus model is designed to be a compromise between trust management effort and flexibility. It is based on X.509 certificates and allows each DNCP node to provide a trust verdict on any other certificate, and a consensus is found to determine whether a node using this certificate or any certificate signed by it is to be trusted.
基于证书的一致性模型旨在在信任管理工作和灵活性之间达成折衷。它基于X.509证书，允许每个DNCP节点提供对任何其他证书的信任判定，并找到一致意见以确定是否信任使用此证书或由其签名的任何证书的节点。
A DNCP node not using this security method MUST ignore all announced trust verdicts and MUST NOT announce any such verdicts by itself, i.e., any other normative language in this subsection does not apply to it.
未使用此安全方法的DNCP节点必须忽略所有已宣布的信任裁决，并且不得自行宣布任何此类裁决，即本小节中的任何其他规范性语言不适用于该节点。
The current effective trust verdict for any certificate is defined as the one with the highest priority from all trust verdicts announced for said certificate at the time.
任何证书的当前有效信托裁决被定义为在当时为该证书宣布的所有信托裁决中具有最高优先级的一个。
Trust verdicts are statements of DNCP nodes about the trustworthiness of X.509 certificates. There are 5 possible trust verdicts in order of ascending priority:
信任判定是DNCP节点关于X.509证书可信度的声明。按照优先级的升序，有5种可能的信托裁决：
0 (Neutral): no trust verdict exists, but the DNCP network should determine one.
0（中立）：不存在信任判定，但DNCP网络应确定一个。
1 (Cached Trust): the last known effective trust verdict was Configured or Cached Trust.
1（缓存信任）：配置或缓存了上一个已知的有效信任判定。
2 (Cached Distrust): the last known effective trust verdict was Configured or Cached Distrust.
2（缓存的不信任）：配置或缓存了上一个已知的有效信任判定。
3 (Configured Trust): trustworthy based upon an external ceremony or configuration.
3（配置信任）：基于外部仪式或配置的可信。
4 (Configured Distrust): not trustworthy based upon an external ceremony or configuration.
4（配置不信任）：基于外部仪式或配置不可信。
Trust verdicts are differentiated in 3 groups:
信托裁决分为三组：
o Configured verdicts are used to announce explicit trust verdicts a node has based on any external trust bootstrap or predefined relations a node has formed with a given certificate.
o 配置的判定用于根据节点与给定证书形成的任何外部信任引导或预定义关系宣布节点的显式信任判定。
o Cached verdicts are used to retain the last known trust state in case all nodes with configured verdicts about a given certificate have been disconnected or turned off.
o 缓存的判定用于在具有关于给定证书的配置判定的所有节点都已断开或关闭的情况下保留最后一个已知的信任状态。
o The Neutral verdict is used to announce a new node intending to join the network, so a final verdict for it can be found.
o 中立裁决用于宣布打算加入网络的新节点，因此可以找到该节点的最终裁决。
The current effective trust verdict for any certificate is defined as the one with the highest priority within the set of trust verdicts announced for the certificate in the DNCP network. A node MUST be trusted for participating in the DNCP network if and only if the current effective trust verdict for its own certificate or any one in its certificate hierarchy is (Cached or Configured) Trust, and none of the certificates in its hierarchy have an effective trust verdict of (Cached or Configured) Distrust. In case a node has a configured verdict, which is different from the current effective trust verdict for a certificate, the current effective trust verdict takes precedence in deciding trustworthiness. Despite that, the node still retains and announces its configured verdict.
任何证书的当前有效信任裁决被定义为在DNCP网络中为该证书宣布的一组信任裁决中具有最高优先级的一个。当且仅当节点自己的证书或其证书层次结构中的任何一个的当前有效信任裁决为（缓存或配置）信任，且其层次结构中的任何证书都没有（缓存或配置）不信任的有效信任裁决时，节点参与DNCP网络必须受信任。如果节点具有与证书的当前有效信任裁决不同的配置裁决，则当前有效信任裁决将优先决定可信度。尽管如此，节点仍然保留并宣布其配置的裁决。
Each node SHOULD maintain a trust cache containing the current effective trust verdicts for all certificates currently announced in the DNCP network. This cache is used as a backup of the last known state in case there is no node announcing a configured verdict for a known certificate. It SHOULD be saved to a non-volatile memory at reasonable time intervals to survive a reboot or power outage.
每个节点都应维护一个信任缓存，其中包含DNCP网络中当前宣布的所有证书的当前有效信任判决。如果没有节点宣布已知证书的配置判定，则此缓存将用作上一个已知状态的备份。应以合理的时间间隔将其保存到非易失性内存中，以在重新启动或断电后生存。
Every time a node (re)joins the network or detects the change of an effective trust verdict for any certificate, it will synchronize its cache, i.e., store new effective trust verdicts overwriting any previously cached verdicts. Configured verdicts are stored in the cache as their respective cached counterparts. Neutral verdicts are never stored and do not override existing cached verdicts.
每当节点（重新）加入网络或检测到任何证书的有效信任判定的更改时，它都将同步其缓存，即存储新的有效信任判定，覆盖以前缓存的任何判定。配置的判决作为各自的缓存副本存储在缓存中。中立裁决从不存储，也不会覆盖现有的缓存裁决。
A node SHOULD always announce any configured verdicts it has established by itself, and it MUST do so if announcing the configured verdict leads to a change in the current effective trust verdict for the respective certificate. In absence of configured verdicts, it MUST announce Cached Trust verdicts it has stored in its trust cache, if one of the following conditions applies:
节点应始终宣布其自己建立的任何已配置裁决，如果宣布已配置裁决导致相应证书的当前有效信任裁决发生更改，则必须这样做。在没有配置的判定的情况下，如果下列条件之一适用，则必须宣布存储在其信任缓存中的缓存信任判定：
o The stored trust verdict is Cached Trust, and the current effective trust verdict for the certificate is Neutral or does not exist.
o 存储的信任裁决为缓存信任，证书的当前有效信任裁决为中立或不存在。
o The stored trust verdict is Cached Distrust, and the current effective trust verdict for the certificate is Cached Trust.
o 存储的信任判定为缓存不信任，证书的当前有效信任判定为缓存信任。
A node rechecks these conditions whenever it detects changes of announced trust verdicts anywhere in the network.
每当节点检测到网络中任何位置的已宣布信任判决的更改时，都会重新检查这些条件。
Upon encountering a node with a hierarchy of certificates for which there is no effective trust verdict, a node adds a Neutral Trust-Verdict TLV to its node data for all certificates found in the hierarchy and publishes it until an effective trust verdict different from Neutral can be found for any of the certificates, or a reasonable amount of time (10 minutes is suggested) with no reaction and no further authentication attempts has passed. Such trust verdicts SHOULD also be limited in rate and number to prevent denial-of-service attacks.
当遇到具有证书层次结构且没有有效信任裁决的节点时，节点会将中立信任裁决TLV添加到该层次结构中找到的所有证书的节点数据中，并将其发布，直到可以为任何证书找到不同于中立的有效信任裁决，或者在合理的时间内（建议10分钟），没有反应，也没有进一步的身份验证尝试。此类信任判决的速率和数量也应受到限制，以防止拒绝服务攻击。
Trust verdicts are announced using Trust-Verdict TLVs:
使用信托裁决TLV宣布信托裁决：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: Trust-Verdict (10) | Length: > 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Verdict | (reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| |
| SHA-256 Fingerprint |
| |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Common Name |
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type: Trust-Verdict (10) | Length: > 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Verdict | (reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| |
| SHA-256 Fingerprint |
| |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Common Name |
Verdict represents the numerical index of the trust verdict.
裁决表示信任裁决的数字索引。
(reserved) is reserved for future additions and MUST be set to 0 when creating TLVs and ignored when parsing them.
（保留）保留供将来添加，在创建TLV时必须设置为0，在分析TLV时忽略。
SHA-256 Fingerprint contains the SHA-256 [RFC6234] hash value of the certificate in DER format.
SHA-256指纹包含DER格式的证书的SHA-256[RFC6234]哈希值。
Common name contains the variable-length (1-64 bytes) common name of the certificate.
公共名称包含证书的可变长度（1-64字节）公共名称。
The following non-exhaustive list of methods describes possible ways to establish trust relationships between DNCP nodes and node certificates. Trust establishment is a two-way process in which the existing network must trust the newly added node, and the newly added node must trust at least one of its peer nodes. It is therefore necessary that both the newly added node and an already trusted node perform such a ceremony to successfully introduce a node into the DNCP network. In all cases, an administrator MUST be provided with external means to identify the node belonging to a certificate based on its fingerprint and a meaningful common name.
以下非详尽的方法列表描述了在DNCP节点和节点证书之间建立信任关系的可能方法。信任建立是一个双向过程，其中现有网络必须信任新添加的节点，并且新添加的节点必须信任其至少一个对等节点。因此，新添加的节点和已经受信任的节点都必须执行这样的仪式，以成功地将节点引入DNCP网络。在所有情况下，必须向管理员提供外部手段，以根据其指纹和有意义的通用名称来识别属于证书的节点。
A node implementing certificate-based trust MUST provide an interface to retrieve the current set of effective trust verdicts, fingerprints, and names of all certificates currently known and set configured verdicts to be announced. Alternatively, it MAY provide a companion DNCP node or application with these capabilities with which it has a pre-established trust relationship.
实现基于证书的信任的节点必须提供一个接口，以检索当前有效的信任判决集、指纹以及当前已知的所有证书的名称，并设置要宣布的配置判决。或者，它可以提供具有这些功能的伴随DNCP节点或应用程序，与之具有预先建立的信任关系。
A node MAY be preconfigured to trust a certain set of node or CA certificates. However, such trust relationships MUST NOT result in unwanted or unrelated trust for nodes not intended to be run inside the same network (e.g., all other devices by the same manufacturer).
节点可以预配置为信任某一组节点或CA证书。但是，此类信任关系不得导致对不打算在同一网络内运行的节点（例如，同一制造商的所有其他设备）产生不必要或不相关的信任。
A node MAY provide a physical or virtual interface to put one or more of its internal network interfaces temporarily into a mode in which it trusts the certificate of the first DNCP node it can successfully establish a connection with.
节点可提供物理或虚拟接口，以将其一个或多个内部网络接口临时置于其信任其可成功建立连接的第一个DNCP节点的证书的模式。
A node that is not associated with any other DNCP node MAY trust the certificate of the first DNCP node it can successfully establish a connection with. This method MUST NOT be used when the node has already associated with any other DNCP node.
未与任何其他DNCP节点关联的节点可以信任其可以成功建立连接的第一个DNCP节点的证书。当节点已与任何其他DNCP节点关联时，不得使用此方法。
Each DNCP profile MUST specify the following aspects:
每个DNCP配置文件必须指定以下方面：
o Unicast and optionally a multicast transport protocol(s) to be used. If a multicast-based node and status discovery is desired, a datagram-based transport supporting multicast has to be available.
o 要使用的单播和可选多播传输协议。如果需要基于多播的节点和状态发现，则必须提供支持多播的基于数据报的传输。
o How the chosen transport(s) is secured: Not at all, optionally, or always with the TLS scheme defined here using one or more of the methods, or with something else. If the links with DNCP nodes can be sufficiently secured or isolated, it is possible to run DNCP in a secure manner without using any form of authentication or encryption.
o 所选传输的安全方式：完全不安全、可选安全，或者始终使用此处定义的TLS方案（使用一个或多个方法），或者使用其他方法。如果与DNCP节点的链接可以充分安全或隔离，则可以以安全的方式运行DNCP，而无需使用任何形式的身份验证或加密。
o Transport protocols' parameters such as port numbers to be used or multicast addresses to be used. Unicast, multicast, and secure unicast may each require different parameters, if applicable.
o 传输协议的参数，如要使用的端口号或要使用的多播地址。单播、多播和安全单播可能都需要不同的参数（如果适用）。
o When receiving TLVs, what sort of TLVs are ignored in addition -- as specified in Section 4.4 -- e.g., for security reasons. While the security of the node data published within the Node State TLVs is already ensured by the base specification (if secure unicast transport is used, Node State TLVs are sent only via unicast as multicast ones are ignored on receipt), if a profile adds TLVs that are sent outside the node data, a profile should indicate whether or not those TLVs should be ignored if they are received via multicast or non-secured unicast. A DNCP profile may define the following DNCP TLVs to be safely ignored:
o 当接收TLV时，根据第4.4节的规定，出于安全原因，还应忽略哪种类型的TLV。虽然在节点状态TLV内发布的节点数据的安全性已由基本规范保证（如果使用安全单播传输，则节点状态TLV仅通过单播发送，因为在接收时忽略多播TLV），但如果配置文件添加在节点数据外发送的TLV，配置文件应指明如果通过多播或非安全单播接收这些TLV，是否应忽略这些TLV。DNCP配置文件可定义以下安全忽略的DNCP TLV：
* Anything received over multicast, except Node Endpoint TLV (Section 7.2.1) and Network State TLV (Section 7.2.2).
* 通过多播接收的任何内容，除了节点端点TLV（第7.2.1节）和网络状态TLV（第7.2.2节）。
* Any TLVs received over unreliable unicast or multicast at a rate that is that is too high; Trickle will ensure eventual convergence given the rate slows down at some point.
* 以过高的速率通过不可靠的单播或多播接收的任何TLV；涓流将确保最终收敛，因为速度在某个点上会减慢。
o How to deal with node identifier collision as described in Section 4.4. Main options are either for one or both nodes to assign new node identifiers to themselves or to notify someone about a fatal error condition in the DNCP network.
o 如何处理节点标识符冲突，如第4.4节所述。主要选项是一个或两个节点为自己分配新的节点标识符，或通知某人DNCP网络中的致命错误情况。
o Imin, Imax, and k ranges to be suggested for implementations to be used in the Trickle algorithm. The Trickle algorithm does not require these to be the same across all implementations for it to work, but similar orders of magnitude help implementations of a DNCP profile to behave more consistently and to facilitate estimation of lower and upper bounds for convergence behavior of the network.
o 为涓流算法中使用的实现建议的Imin、Imax和k范围。涓流算法不要求所有实现中的这些参数都相同，但相似的数量级有助于DNCP配置文件的实现更加一致，并有助于估计网络收敛行为的上下限。
o Hash function H(x) to be used, and how many bits of the output are actually used. The chosen hash function is used to handle both hashing of node data and producing network state hash, which is a hash of node data hashes. SHA-256 defined in [RFC6234] is the recommended default choice, but a non-cryptographic hash function could be used as well. If there is a hash collision in the network state hash, the network will effectively be partitioned to partitions that believe they are up to date but are actually no longer converged. The network will converge either when some node data anywhere in the network changes or when conflicting Node State TLVs get transmitted across the partition (either caused by "Trickle-Driven Status Updates" (Section 4.3) or as part of the "Processing of Received TLVs" (Section 4.4)). If a node publishes
o 要使用的哈希函数H（x），以及实际使用的输出位数。所选的哈希函数用于处理节点数据的哈希和生成网络状态哈希，网络状态哈希是节点数据哈希的哈希。[RFC6234]中定义的SHA-256是推荐的默认选择，但也可以使用非加密哈希函数。如果网络状态散列中存在散列冲突，则网络将被有效地划分为相信它们是最新的但实际上不再聚合的分区。当网络中任何位置的某些节点数据发生变化时，或者当冲突的节点状态TLV通过分区传输时（由“涓流驱动的状态更新”（第4.3节）或作为“接收TLV的处理”（第4.4节）的一部分引起），网络将聚合。如果节点发布
node data with a hash that collides with any previously published node data, the update may not be (fully) propagated, and the old version of node data may be used instead.
如果节点数据的散列与以前发布的任何节点数据冲突，则更新可能不会（完全）传播，而可以使用旧版本的节点数据。
o DNCP_NODE_IDENTIFIER_LENGTH: The fixed length of a node identifier (in bytes).
o DNCP_NODE_IDENTIFIER_LENGTH：节点标识符的固定长度（以字节为单位）。
o Whether to send keep-alives, and if so, whether it is per-endpoint (requires multicast transport) or per-peer. Keep-alive also has associated parameters:
o 是否发送keep-alives，如果是，是每个端点（需要多播传输）还是每个对等点。“保持活动”还具有相关参数：
* DNCP_KEEPALIVE_INTERVAL: How often keep-alives are to be sent by default (if enabled).
* DNCP_KEEPALIVE_INTERVAL：默认情况下发送保留有效信息的频率（如果启用）。
* DNCP_KEEPALIVE_MULTIPLIER: How many times the DNCP_KEEPALIVE_INTERVAL (or peer-supplied keep-alive interval value) node may not be heard from to be considered still valid. This is just a default used in absence of any other configuration information or particular per-endpoint configuration.
* DNCP_KEEPALIVE_乘数：DNCP_KEEPALIVE_INTERVAL（或对等方提供的保持活动间隔值）节点可能听不到多少次才被视为仍然有效。这只是在没有任何其他配置信息或特定的每端点配置的情况下使用的默认值。
o Whether to support dense multicast-enabled link optimization (Section 6.2) or not.
o 是否支持启用密集多播的链路优化（第6.2节）。
For some guidance on choosing transport and security options, please see Appendix B.
有关选择运输和安全选项的一些指导，请参见附录B。
DNCP-based protocols may use multicast to indicate DNCP state changes and for keep-alive purposes. However, no actual published data TLVs will be sent across that channel. Therefore, an attacker may only learn hash values of the state within DNCP and may be able to trigger unicast synchronization attempts between nodes on a local link this way. A DNCP node MUST therefore rate limit its reactions to multicast packets.
基于DNCP的协议可以使用多播来指示DNCP状态更改，并用于保持活动状态。但是，不会通过该通道发送实际发布的数据TLV。因此，攻击者可能只了解DNCP内状态的哈希值，并可能通过这种方式触发本地链路上节点之间的单播同步尝试。因此，DNCP节点必须限制其对多播数据包的反应速率。
When using DNCP to bootstrap a network, PKI-based solutions may have issues when validating certificates due to potentially unavailable accurate time or due to the inability to use the network to either check Certificate Revocation Lists or perform online validation.
使用DNCP引导网络时，基于PKI的解决方案在验证证书时可能会出现问题，原因是可能无法获得准确的时间，或者无法使用网络检查证书吊销列表或执行在线验证。
The Certificate-based trust consensus mechanism defined in this document allows for a consenting revocation; however, in case of a compromised device, the trust cache may be poisoned before the actual revocation happens allowing the distrusted device to rejoin the network using a different identity. Stopping such an attack might require physical intervention and flushing of the trust caches.
本文件中定义的基于证书的信任共识机制允许同意撤销；然而，在设备受损的情况下，信任缓存可能在实际撤销发生之前中毒，从而允许不受信任的设备使用不同的身份重新加入网络。阻止这种攻击可能需要物理干预和刷新信任缓存。
IANA has set up a registry for the (decimal 16-bit) "DNCP TLV Types" under "Distributed Node Consensus Protocol (DNCP)". The registration procedure is Standards Action [RFC5226]. The initial contents are:
IANA已经为“分布式节点一致性协议（DNCP）”下的（十进制16位）“DNCP TLV类型”设置了一个注册表。注册程序为标准行动[RFC5226]。初步内容如下:
0: Reserved
0:保留
1: Request network state
1：请求网络状态
2: Request node state
2：请求节点状态
3: Node endpoint
3：节点端点
4: Network state
4：网络状态
5: Node state
5：节点状态
6: Reserved for future use (was: Custom)
6：保留供将来使用（was：自定义）
7: Reserved for future use (was: Fragment count)
7：保留供将来使用（was：碎片计数）
8: Peer
8：同行
9: Keep-alive interval
9：保持活动间隔
10: Trust-Verdict
10：信托裁决
11-31: Unassigned
11-31：未分配
32-511: Reserved for per-DNCP profile use
32-511：保留供每个DNCP配置文件使用
512-767: Unassigned
512-767：未分配
768-1023: Reserved for Private Use [RFC5226]
768-1023：保留供私人使用[RFC5226]
1024-65535: Reserved for future use
1024-65535：保留供将来使用
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, March 2011, <http://www.rfc-editor.org/info/rfc6206>.
[RFC6206]Levis，P.，Clausen，T.，Hui，J.，Gnawali，O.，和J.Ko，“涓流算法”，RFC 6206，DOI 10.17487/RFC6206，2011年3月<http://www.rfc-editor.org/info/rfc6206>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <http://www.rfc-editor.org/info/rfc6234>.
[RFC6234]Eastlake 3rd，D.和T.Hansen，“美国安全哈希算法（基于SHA和SHA的HMAC和HKDF）”，RFC 6234，DOI 10.17487/RFC6234，2011年5月<http://www.rfc-editor.org/info/rfc6234>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC 3315，DOI 10.17487/RFC3315，2003年7月<http://www.rfc-editor.org/info/rfc3315>.
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, DOI 10.17487/RFC3493, February 2003, <http://www.rfc-editor.org/info/rfc3493>.
[RFC3493]Gilligan，R.，Thomson，S.，Bound，J.，McCann，J.，和W.Stevens，“IPv6的基本套接字接口扩展”，RFC 3493，DOI 10.17487/RFC3493，2003年2月<http://www.rfc-editor.org/info/rfc3493>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC6347]Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，RFC 6347，DOI 10.17487/RFC6347，2012年1月<http://www.rfc-editor.org/info/rfc6347>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, <http://www.rfc-editor.org/info/rfc7435>.
[RFC7435]Dukhovni，V.，“机会主义安全：大部分时间的一些保护”，RFC 7435，DOI 10.17487/RFC7435，2014年12月<http://www.rfc-editor.org/info/rfc7435>.
[RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. Farrer, "Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, July 2015, <http://www.rfc-editor.org/info/rfc7596>.
[RFC7596]Cui，Y.，Sun，Q.，Boucadair，M.，Tsou，T.，Lee，Y.，和I.Farrer，“轻量级4over6：双栈精简架构的扩展”，RFC 7596，DOI 10.17487/RFC75962015年7月<http://www.rfc-editor.org/info/rfc7596>.
Beyond what is described in the main text, the protocol allows for other uses. These are provided as examples.
除了正文中描述的内容外，该协议还允许其他用途。这些都是作为例子提供的。
If a node uses just a single endpoint and does not need to publish any TLVs, full DNCP node functionality is not required. Such a limited node can acquire and maintain a view of the TLV space by implementing the processing logic as specified in Section 4.4. Such node would not need Trickle, peer-maintenance, or even keep-alives at all, as the DNCP nodes' use of it would guarantee eventual receipt of network state hashes, and synchronization of node data, even in the presence of unreliable transport.
如果节点仅使用单个端点，并且不需要发布任何TLV，则不需要完整的DNCP节点功能。这种受限节点可以通过实现第4.4节中规定的处理逻辑来获取和维护TLV空间的视图。这样的节点根本不需要涓流、对等维护，甚至不需要保持生命，因为DNCP节点使用它将保证最终接收网络状态哈希，并同步节点数据，即使在存在不可靠传输的情况下也是如此。
If a node with a pair of endpoints does not need to publish any TLVs, it can detect (for example) nodes with the highest node identifier on each of the endpoints (if any). Any TLVs received from one of them would be forwarded verbatim as unicast to the other node with the highest node identifier.
如果具有一对端点的节点不需要发布任何TLV，则它可以检测（例如）每个端点（如果有）上具有最高节点标识符的节点。从其中一个节点接收到的任何TLV都将作为单播逐字转发到具有最高节点标识符的另一个节点。
Any tinkering with the TLVs would remove guarantees of this scheme working; however, passive monitoring would obviously be fine. This type of simple forwarding cannot be chained, as it does not send anything proactively.
对TLV的任何修补都将取消该计划有效性的保证；然而，被动监测显然是好的。这种类型的简单转发无法链接，因为它不会主动发送任何内容。
This appendix explains implications of design choices made when specifying the DNCP profile to use particular transport or security options.
本附录解释了指定DNCP配置文件以使用特定传输或安全选项时所做设计选择的含义。
The node data published by a DNCP node is limited to 64 KB due to the 16-bit size of the length field of the TLV it is published within. Some transport choices may decrease this limit; if using, e.g., UDP datagrams for unicast transport, the upper bound of the node data size is whatever the nodes and the underlying network can pass to each other as DNCP does not define its own fragmentation scheme. A profile that chooses UDP has to be limited to small node data (e.g., somewhat smaller than IPv6 default MTU if using IPv6) or specify a minimum that all nodes have to support. Even then, if using non-link-local communications, there is some concern about what middleboxes do to fragmented packets. Therefore, the use of stream
DNCP节点发布的节点数据被限制为64 KB，因为它发布的TLV的长度字段的大小为16位。一些交通选择可能会降低这一限制；例如，如果使用UDP数据报进行单播传输，则节点数据大小的上限是节点和基础网络可以传递给彼此的任何内容，因为DNCP不定义其自己的分段方案。选择UDP的配置文件必须限于小节点数据（例如，如果使用IPv6，则略小于IPv6默认MTU）或指定所有节点必须支持的最小值。即使如此，如果使用非链接本地通信，也会有一些关于中间包对碎片数据包的影响的担忧。因此，使用流
transport such as TCP is probably a good idea if either non-link-local communication is desired or fragmentation is expected to cause problems.
如果需要非链接本地通信或碎片可能会导致问题，那么像TCP这样的传输可能是一个好主意。
TCP also provides some other facilities, such as a relatively long built-in keep-alive, which in conjunction with connection closes occurring from eventual failed retransmissions may be sufficient to avoid the use of in-protocol keep-alive defined in Section 6.1. Additionally, it is reliable, so there is no need for Trickle on such unicast connections.
TCP还提供了一些其他设施，如相对较长的内置保持活动，与最终失败的重新传输导致的连接关闭一起，可能足以避免使用第6.1节中定义的协议内保持活动。此外，它是可靠的，因此不需要在这种单播连接上滴流。
The major downside of using TCP instead of UDP with DNCP-based profiles lies in the loss of control over the time at which TLVs are received; while unreliable UDP datagrams also have some delay, TLVs within reliable stream transport may be delayed significantly due to retransmissions. This is not a problem if no relative time-dependent information is stored within the TLVs in the DNCP-based protocol; for such a protocol, TCP is a reasonable choice for unicast transport if it is available.
在基于DNCP的配置文件中使用TCP而不是UDP的主要缺点在于无法控制接收TLV的时间；虽然不可靠的UDP数据报也有一些延迟，但由于重新传输，可靠流传输中的TLV可能会显著延迟。如果在基于DNCP的协议中，TLV内没有存储相关的时间相关信息，则这不是问题；对于这样一个协议，如果可用的话，TCP是单播传输的合理选择。
Multicast is needed for dynamic peer discovery and to trigger unicast exchanges; for that, unreliable datagram transport (=typically UDP) is the only transport option defined within this specification, although DNCP-based protocols may themselves define some other transport or peer discovery mechanism (e.g., based on Multicast DNS (mDNS) or DNS).
动态对等发现和触发单播交换需要多播；因此，不可靠数据报传输（=通常为UDP）是本规范中定义的唯一传输选项，尽管基于DNCP的协议本身可能定义一些其他传输或对等发现机制（例如，基于多播DNS（MDN）或DNS）。
If multicast is used, a well-known address should be specified and for, e.g., IPv6, respectively, the desired address scopes. In most cases, link-local and possibly site-local are useful scopes.
如果使用多播，则应分别指定已知地址和所需地址范围（例如IPv6）。在大多数情况下，链接本地和站点本地都是有用的作用域。
In terms of provided security, DTLS and TLS are equivalent; they also consume a similar amount of state on the devices. While TLS is on top of a stream protocol, using DTLS also requires relatively long session caching within the DTLS layer to avoid expensive reauthentication/authorization steps if and when any state within the DNCP network changes or per-peer keep-alive (if enabled) is sent.
就提供的安全性而言，DTL和TLS是等效的；它们也会在设备上消耗类似数量的状态。虽然TLS位于流协议之上，但使用DTLS还需要在DTLS层中进行相对较长的会话缓存，以避免在DNCP网络中的任何状态发生变化或每个对等方保持活动（如果启用）发送时进行昂贵的重新验证/授权步骤。
TLS implementations (at the time of writing the specification) seem more mature and available (as open source) than DTLS ones. This may be due to a long history of use with HTTPS.
TLS实现（在编写规范时）似乎比DTLS实现更成熟、更可用（作为开源）。这可能是由于使用HTTPS有很长的历史。
Some libraries seem not to support multiplexing between insecure and secure communication on the same port, so specifying distinct ports for secured and unsecured communication may be beneficial.
有些库似乎不支持在同一端口上的不安全通信和安全通信之间进行多路复用，因此为安全通信和不安全通信指定不同的端口可能是有益的。
This is the DNCP profile of SHSP, an experimental (and for the purposes of this document fictional) home automation protocol. The protocol itself is used to make a key-value store published by each of the nodes available to all other nodes for distributed monitoring and control of a home infrastructure. It defines only one additional TLV type: a key=value TLV that contains a single key=value assignment for publication.
这是SHSP的DNCP配置文件，这是一个实验性（在本文档中是虚构的）家庭自动化协议。协议本身用于使每个节点发布的键值存储可供所有其他节点使用，以便对家庭基础设施进行分布式监视和控制。它只定义了一个附加的TLV类型：包含用于发布的单个键=值分配的键=值TLV。
o Unicast transport: IPv6 TCP on port EXAMPLE-P1 since only absolute timestamps are used within the key=value data and since it focuses primarily on Linux-based nodes that support both protocols as well. Connections from and to non-link-local addresses are ignored to avoid exposing this protocol outside the secure links.
o 单播传输：端口示例P1上的IPv6 TCP，因为在key=value数据中只使用绝对时间戳，而且它主要关注支持这两种协议的基于Linux的节点。忽略与非链接本地地址之间的连接，以避免将此协议暴露在安全链接之外。
o Multicast transport: IPv6 UDP on port EXAMPLE-P2 to link-local scoped multicast address ff02:EXAMPLE. At least one node per link in the home is assumed to facilitate node discovery without depending on any other infrastructure.
o 多播传输：端口EXAMPLE-P2上的IPv6 UDP连接本地作用域多播地址ff02:示例。假定家庭中的每条链路至少有一个节点有助于节点发现，而不依赖于任何其他基础设施。
o Security: None. It is to be used only on trusted links (WPA2-x wireless, physically secure wired links).
o 保安：没有。它只能用于受信任的链路（WPA2-x无线、物理安全的有线链路）。
o Additional TLVs to be ignored: None. No DNCP security is specified, and no new TLVs are defined outside of node data.
o 要忽略的其他TLV：无。未指定DNCP安全性，也未在节点数据之外定义新的TLV。
o Node identifier length (DNCP_NODE_IDENTIFIER_LENGTH): 32 bits that are randomly generated.
o 节点标识符长度（DNCP_Node_identifier_length）：随机生成的32位。
o Node identifier collision handling: Pick new random node identifier.
o 节点标识符冲突处理：拾取新的随机节点标识符。
o Trickle parameters: Imin = 200 ms, Imax = 7, k = 1. It means at least one multicast per link in 25 seconds in stable state (0.2 * 2^7).
o 涓流参数：Imin=200ms，Imax=7，k=1。这意味着在稳定状态下（0.2*2^7），每个链路在25秒内至少有一个多播。
o Hash function H(x) + length: SHA-256, only 128 bits used. It's relatively fast, and 128 bits should be plenty to prevent random conflicts (64 bits would most likely be sufficient, too).
o 散列函数H（x）+长度：SHA-256，仅使用128位。它相对较快，128位应该足够防止随机冲突（64位也很可能足够）。
o No in-protocol keep-alives (Section 6.1); TCP keep-alive is to be used. In practice, TCP keep-alive is seldom encountered anyway, as changes in network state cause packets to be sent on the
o 无协议有效性（第6.1节）；将使用TCP保持活动状态。实际上，很少遇到TCP保持活动，因为网络状态的变化会导致数据包在网络上发送
unicast connections, and those that fail sufficiently many retransmissions are dropped much before the keep-alive actually would fire.
单播连接，以及那些多次重新传输失败的连接，在“保持活力”实际触发之前就被丢弃。
o No support for dense multicast-enabled link optimization (Section 6.2); SHSP is a simple protocol for a few nodes (network wide, not even to mention on a single link) and therefore would not provide any benefit.
o 不支持密集多播链路优化（第6.2节）；SHSP是针对少数节点（网络范围，更不用说单个链路）的简单协议，因此不会提供任何好处。
Acknowledgements
致谢
Thanks to Ole Troan, Pierre Pfister, Mark Baugher, Mark Townsley, Juliusz Chroboczek, Jiazi Yi, Mikael Abrahamsson, Brian Carpenter, Thomas Clausen, DENG Hui, and Margaret Cullen for their contributions to the document.
感谢Ole Troan、Pierre Pfister、Mark Baugher、Mark Townsley、Juliusz Chroboczek、Jiazi Yi、Mikael Abrahamsson、Brian Carpenter、Thomas Clausen、DENG Hui和Margaret Cullen对该文件的贡献。
Thanks to Kaiwen Jin and Xavier Bonnetain for their related research work.
感谢Jin Kaiwen和Xavier Bonnetain的相关研究工作。
Authors' Addresses
作者地址
Markus Stenberg Independent Helsinki 00930 Finland
Markus Stenberg独立赫尔辛基00930芬兰
Email: markus.stenberg@iki.fi
Email: markus.stenberg@iki.fi
Steven Barth Independent Halle 06114 Germany
史蒂文·巴特独立学院哈雷06114德国
Email: cyrus@openwrt.org
Email: cyrus@openwrt.org