分布式节点共识协议

摘要

本文描述了分布式节点共识协议(DNCP)，这是一个使用Trickle算法和哈希树的通用状态同步协议。DNCP是一个抽象的协议，必须与特定的配置文件相结合，才能成为一个完整的可实现协议。

1. 介绍

DNCP旨在为每个参与节点提供一种方式，使其能够发布一小组TLV（最多64KB），并为网络中每个当前双向可达的DNCP节点发布的数据提供一个共享的视图。
状态同步采用的是哈希树。形成方法是首先计算每个节点发布的数据集的哈希值，称为节点数据，然后在这些节点数据哈希值上计算另一个哈希值。所得的单一哈希称为网络状态哈希，使用Trickle算法[RFC6206]进行传输，以确保所有节点共享网络内发布数据的当前状态的相同视图。使用Trickle时只不频繁地发送网络状态哈希（在稳定状态下达到每个链路或单播连接的最大Trickle间隔时发送），使得DNCP在更新很少时非常节省流量。
为了保持拓扑结构及其内部数据的活性，采用Trickled网络状态、keep-alive和其他手段相结合的方式来保证可达。其核心思想是，如果每个节点都能保证其对等节点的存在，传播开来，整个网络状态也能保持最新。

1.1. 适用性

DNCP对于诸如路由器等嵌入式网络设备的自主引导、发现和协商等情况非常有用。此外，还可以作为运行分布式算法的基础，如[RFC7596]或附录C中描述的用例。DNCP是抽象的，这使得它可以通过定义配置文件来适配各种应用。这些配置文件包括以下选择：

单播传输: 用于通用协议操作的datagram或者基于stream的协议（如TCP/UDP/SCTP）。
可选传输安全：是否以及何时使用TLS或DTLS的安全（如果所选传输支持的话）。
可选组播传输：像UDP这样的可多播协议，允许自主发现对等体或更有效地使用多个接入链路。
通信范围：使用仅依靠link-local寻址的逐跳寻址（如局域网）、依靠现有路由基础架构的范围更广寻址（如通过广域网或互联网），或两者结合（如通过广域网或互联网在多个局域网之间交换状态）。
payload：额外的特定有效载荷(例如，IANA标准、企业特定或私有实现)。
扩展：额外的特定有效载荷(例如，IANA标准化、企业特定或私有实现)。
然而，在某些情况下，本文定义的标准是不太合适的选择。本清单提供了一个概览，而以下各段则就个别事项提供了更详细的指导。
大量数据：节点被限制为64KB的发布数据。
密集单播网络：节点将所有邻居的信息作为其发布数据的一部分。
主要最小的数据变化：节点数据总是按原样传输，导致只影响其中一小部分的变化的传输开销相对较大。
频繁变化的数据： DNCP使用的Trickle对稳定状态进行了优化，否则效率较低。
大量的受限节点：DNCP要求每个节点存储所有节点发布的全部数据。
设备的拓扑结构不受限制，自动发现。当完全依靠link-local通信时，所有具有DNCP节点的链路至少需要通过路由器在多个端点上运行协议进行中转连接，才能形成一个连接的网络。但是，并不要求物理网络中的每个设备都运行该协议。特别是在使用全局地址的情况下，DNCP对等体不需要在同一甚至相邻的物理链路上。自主发现功能通常用于本地网络场景；但是，在启用安全功能后，DNCP也可以在不安全的公共网络上使用。网络规模仅仅受限于设备的能力，即每个DNCP节点需要能够存储所有节点发布的全部数据。在本文中，每个单独节点标识符相关的数据被限制在64 KB左右；但是，如果需要的话，可以定义协议扩展来缓解这种或其他协议的限制。
DNCP最适合于变化不频繁的数据，以获得使用Trickle的最大效益。随着节点网络的增长，或者每个节点的数据变化频率增加，Trickle的使用最终会越来越少，使用DNCP的好处也会减少。在这些情况下，Trickle只是提供了额外的复杂性，几乎没有附加价值。
DNCP对特定应用的适用性可以通过考虑预期的全网平均状态变化间隔A_NC_I来粗略评估；计算方法是将节点发起一个新的TLV集的平均间隔除以参与节点的数量。如果使用了keep-alive，A_NC_I是计算出的A_NC_I和keep-alive间隔的最小值。如果A_NC_I小于(特定于应用的)Trickle最小间隔，那么DNCP很可能不适合应用，因为Trickle在大部分时间不会被利用。
如果需要持续快速的状态变化，最好的选择是使用一个额外的点对点通道，其地址或locator是用DNCP发布的。然而，如果这样做不能使A_NC_I超过（合理的选择）特定应用的Trickle间隔，那么使用DNCP可能不适合该应用。
另一个考虑是节点发布的TLV集的大小与TLV集中delta的大小相比。如果节点发布的TLV集非常大，而且经常有小的变化，本规范中目前规定的DNCP可能不适合，因为它缺乏delta同步方案，以保持实现的简单性。
DNCP可用于只有单播传输的网络中。虽然DNCP在利用组播时使用的带宽最少，即使在纯单播模式下，使用Trickle(理想的情况是k<2)会使协议具有指数型后退定时器，而且与不使用Trickle的简单协议相比，传输量更少。

2. 术语

DNCP profile：第9章中给出的一组参数值。本文中前缀是DNCP_。该profile还指定了要使用的一组可选的DNCP扩展。 DNCP profile的简单示例见附录C。

DNCP-based：根据第9章提供DNCP profile和来自每DNCP profile TLV注册表的零或多个TLV分配及其处理规则的协议。

DNCP node：一个运行DNCP-based协议的单个节点。

Link：一种链路层媒介，直接连接的节点可以通过它进行通信。

DNCP network：一组运行DNCP-based协议并有匹配DNCP profile的DNCP节点。该集合由使用DNCP profile中定义的传输方法、通过本地链路上的多播和/或使用单播通信发现彼此的节点集。

Node identifier：由DNCP_NODE_IDENTIFIER_LENGTH字节组成的不透明固定长度标识符，用于唯一标识DNCP网络中的DNCP节点。

Interface：一个节点到特定网络的连接。
Address：DNCP消息流的源或目的地标识符，例如，IPv6 UDP传输的元组（IPv6 Address、UDP端口）。

Endpoint：DNCP流的本地配置终端（潜在或已建立的）。端点是向单个节点单独发送单播流的源和目的地，也是向所有可达节点发送多播信息的源和目的地(例如，用于节点发现)。端点通常采用4.2节规定的传输模式之一。

Endpoint identifier：32位不透明的本地唯一值，用于识别特定DNCP节点的特定端点。值0是为DNCP和DNCP-based协议目的而保留的，不用于识别实际端点。这个定义与[RFC3493]中的接口索引定义是兼容的，因为非零小正整数应该可以轻松地容纳在32位之内。

Peer：另一个DNCP节点，DNCP节点使用至少一个特定的本地和远程端点对与之通信。

Node data：DNCP网络中一个节点发布并拥有的一组TLV。其他节点即使不能完全理解它，也会按原样传递。

Origination time：当前序列号的节点数据集被发布的（估计）时间。

Node state：节点数据的一组metadata属性。包括一个用于版本管理的序列号、一个用于比较保存的节点数据的散列值，以及一个时间戳–表示自上次发布（如自发起时间）以来所经过的时间。哈希函数和哈希值的长度在DNCP配置中定义。

Network state：一个代表当前网络哈希状态的哈希值，哈希函数和哈希值长度在DNCP配置中定义。每当一个节点添加、删除或更新其发布的节点数据时，这个哈希值就会变化。计算方法见4.1节。

Trust verdict：参加基于证书信任共识机制的节点宣布的证书可信度声明。

Effective trust：SDCP网络中公布的trust verdict集内优先级最高者。

Topology graph：DNCP节点的非直连（undirected？）图，只保留节点之间的双向对等关系。

Bidirectionally reachable：如果本地节点收到了持续多播或任何单播DNCP消息，则对端是本地单向可达的（见4.5节）。如果该对端也认为本地节点是单向可达的，则建立双向可达性。由于这个过程是基于发布对等关系和评估产生的拓扑图，如4.6节所述，这个信息对整个DNCP网络是可用的。

Trickle instance：由节点（第5章）保存的一个独特的Trickle[RFC6206]算法状态，并与一个端点或特定的（peer, endpoint）元组有关，其Trickle变量I、t和c见4.3节。

3. 概述

DNCP的运行主要是利用节点之间的单播交换，也可以使用组播进行基于Trickle的共享状态传播和拓扑发现。如果在不可靠传输的纯单播模式下使用，对等体之间也使用Trickle。
DNCP以交换TLV为基础(第7章)，并为其操作定义了一组强制和可选的TLV。分为请求信息（7.1节）、传输数据（7.2节）和作为数据发布（7.3节）的TLV。DNCP-based协议通常会指定额外扩展功能。
DNCP发现DNCP网络中节点的拓扑结构，并通过确保发布节点的双向可达来维持发布节点数据的活性。新的潜在对等体可以在多播链路上自主地发现；它们的地址可以手动配置，也可以通过特定的DNCP配置中定义等其他方式发现。例如，DNCP配置可以指定知名任意广播地址，或者规定通过DHCPv6[RFC3315]等其他协议来联系远程地址。
每个节点都会维护一棵高度为1的哈希树（根为自己）代表所有当前可达节点的状态（见4.1节），Trickle算法用于触发同步（见4.3节）。因此，通过比较各自哈希树的当前根，即各自计算的网络状态哈希值，来确定是否需要检查对等节点的状态变化。
在加入DNCP网络之前，节点首先要有一个哈希树，如果节点发布了一些TLV，那么这个哈希树只有一个叶子，否则就没有叶子。然后，它通过Trickle算法在其配置的所有端点上公布由哈希树计算出的网络状态哈希。
当一个节点检测到更新时（例如，从对等体接收到不同的网络状态哈希），会要求事件发起者提供一个所有节点的状态列表，即它用来计算自己哈希树的所有信息。节点使用该列表来确定自己的信息是否过时，并在必要时要求提供实际发生变化的节点数据。
每当一个节点的任何节点数据的本地副本和哈希树被更新时（例如，由于它自己的或另一个节点的节点状态改变或由于对等体被添加或删除），它的Trickle实例就会被重置，最终导致任何更新被传播到它的所有对等体。

4. 操作（Operation）

4.1. 哈希树（Hash Tree）

每个DNCP节点都会维护一棵高度为1的任意宽度的哈希树，树根代表整体网络状态哈希，用于判断两个或多个节点的网络视图是否一致和共享。每个叶子代表一个双向可到达的DNCP节点。每次从拓扑图中增加或删除一个节点（4.6节），同样也会增加或删除一个叶子。在任何时候，树的叶子都是按照节点标识符的升序排列的。

4.1.1. 计算网络状态和网络数据hash

网络状态哈希和节点数据哈希是使用DNCP配置（第9章）中定义的哈希函数计算的，并截断到指定位数。
单个节点数据哈希是通过对节点状态TLV中公布的各个节点的节点数据应用函数和截断来计算的。这种节点数据集总是按照7.2.3节中的定义进行排序。
网络状态哈希是通过对协整后的网络状态应用函数和截断来计算的。这个状态是通过首先将每个节点的序列号（网络序）与节点数据哈希连在一起，形成每个节点的节点资料。然后将这些每节点资料按照各节点的节点标识符升序进行串联，即按照节点在哈希树中出现的顺序进行串联。

4.1.2. 更新网络状态和节点数据hash

本地存储的每节点状态发生变化时，网络状态哈希和节点数据哈希都会按需更新。这包括在已发布的Peer TLV中编码的本地单向可达性（7.3.1节），并且与远程数据结合时，会导致双向可达性变化。

4.2. 数据传输

DNCP对底层传输的要求不高，它要求有某种方式向对等体传输单播数据报或流数据，如果在多播模式下使用，则要求有一种发送多播数据报的方式。由于组播仅用于识别潜在的新DNCP节点和发送状态消息，这些消息仅仅是通知应该触发单播交换，因此组播传输不必保证安全。如果需要单播安全，并且要使用内置的安全方法，则还需要支持一些TLS衍生的传输方案–例如TCP上的TLS[RFC5246]或UDP上的DTLS[RFC6347]。它们提供节点数据的完整性保护和保密性，以及使用"安全和信任管理"（第8章）中定义的方案进行认证和授权。DNCP配置必须提供使用的传输及其参数的具体定义。
TLV（第7章）按原样在传输中发送，如果因为MTU等原因不建议分批发送，则应一起发送。DNCP不会对TLV进行分片或重新组合；因此，底层传输在必要时执行这些操作。如果发送TLV，那么发送节点在将数据包交给各自的传输后，不需要跟踪发送的数据包，也就是说，仅仅通过明确定义的定时器和状态机（如Trickle）（4.3节）就可以保证DNCP的可靠运行。一般来说，TLV是单独的、无状态的处理（因此不需要按照任何特定的顺序发送），但有一个例外。为了形成双向对等关系，DNCP需要识别用于通信的端点。由于双向对等关系是验证发布的节点数据的活性所必需的，如4.6节所述，DNCP节点必须发送一个Node Endpoint TLV（7.2.1节）。何时发送取决于底层传输，但从概念上讲，每当处理网络状态TLV时，它应该是可用的：
• 如果使用流传输，每个连接必须至少发送一次 TLV，但不应发送超过一次。
• 如果使用数据报传输，它必须包含在每个也包含网络状态TLV（7.2.2节）的数据报中，并且必须位于任何此类TLC之前。它也必须包含在任何其他数据报中，以加快初始对等体检测。
鉴于各种传输选项以及潜在的端点配置，DNCP端点可用于各种传输模式：
单播：
 如果只使用可靠单播传输，则完全不用Trickle。每当本地计算的网络状态哈希发生变化时，就会向每个单播对等体发送一个网络状态TLV（7.2.2节）。此外，最近改变的节点状态TLV(7.2.3节)也可以包括在内。
 如果只使用不可靠单播传输，则每个对等体保留Trickle状态，并按照4.3节的规定，间歇性地发送网络状态TLV。

组播+单播：如果端点上有多播数据报传输，Trickle状态只作为端点整体维护。用来定期发送网络状态TLV，如4.3节。此外，每个端点的keep-alive可以在DNCP配置中定义，如6.1.2节所述。

组播监听+单播：与单播一样，监听多播以检测最高节点标识符的变化。只有当DNCP配置支持密集组播的链路优化时，才会使用该模式（6.2节）

4.3. Trickle-Driven状态更新

Trickle算法[RFC6206]用于确保不可靠多播或单播传输可靠性。对于可靠单播传输是不必要的，所以省略（4.2节）。DNCP维护多个Trickle状态，如第5章定义。每个这样的状态可以基于不同的参数(见下文)，并负责确保定期向各自端点上的特定对等体或所有对等体提供节点当前本地计算的网络状态哈希值，以便进行状态比较，即检测网络状态的潜在分歧。
Trickle定义了3个参数：Imin、Imax和k。Imin和Imax代表I的最小值和Imin的最大倍数，其中I是时间间隔，在这个时间间隔内，必须在一个端点上看到至少k个Trickle更新以防止本地状态传输。实际建议的Trickle算法参数是针对DNCP配置的，如第9章所述。
第5章中定义的所有Trickle实例的Trickle状态被认为是不一致的，只有在本地计算的网络状态哈希发生变化时才会重置。这可能是由于本地节点自己的节点数据发生变化，也可能是由于从另一个节点接收到更多的最新数据，如4.1节所述。节点不能仅仅因为收到网络状态TLV(7.2.2节)中网络状态哈希值与本地计算的不同而重置其Trickle状态。
每当某个Trickle实例指示应该发送更新时，节点必须发送网络状态TLV（7.2.2 节），仅在以下情况下：
 端点处于组播+单播传输模式，在这种情况下，TLV必须通过组播发送。
 端点不在组播+单播传输模式下，而且单播传输不可靠，在这种情况下，TLV必须通过单播发送。
所有节点状态TLV的（子）集（7.2.3节）也可以包括在内，除非DNCP配置出于某种原因将其定义为不可用，或者在使用安全单播时，为了避免在不安全的多播中传输节点状态TLV而暴露。

4.4. 处理收到的TLV

本节描述了如何处理接收到的TLV。DNCP配置可以指定何时忽略特定的TLV，例如，修改安全属性–见第9章，了解哪些内容可以在配置中安全地定义为忽略。在下面的步骤中提到的任何’reply’表示将指定的TLV发送给正在处理的TLV发起者。所有这些回复必须使用单播方式发送。如果被回复的TLV是通过组播接收的，并且被发送到多条访问链路，
那么回复必须以[0，Imin/2]中的随机时间来延迟，以避免潜在的同时回复在某些链路上造成问题，除非DNCP配置中另有规定。响应的发送也可以被限制速率，或者被实现者在短时间内省略。然而，如果TLV没有被DNCP配置禁止，那么实现必须以非零的概率回复TLV的重发，以避饿死，从而破坏状态同步。
DNCP节点必须按照DNCP配置和特定端点的配置，处理从任何有效（如正确的范围）地址接收的TLV，无论这个地址是否已知是对等体的地址。这一规定满足了监控或其他主机软件需要发现DNCP拓扑而不增加网络中的状态的需求。
一旦收到：
 请求网络状态TLV（7.1.1节）。接收方必须为每个用于计算网络状态哈希值的节点数据回复一个网络状态TLV（7.2.2节）和一个节点状态TLV（7.2.3节）。节点状态TLV不应包含可选的节点数据部分，以避免节点数据的冗余传输，除非在DNCP配置中明确指定。
 请求节点状态TLV（7.1.2节）。如果接收方有相应节点的节点数据，则必须回复相应节点的节点状态TLV（7.2.3节）。TLV中必须包含可选的节点数据部分。
 网络状态TLV（7.2.2节）。如果网络状态哈希值与本地计算的网络状态哈希值不同，且接收方不知道与发送方有哪些节点状态差异，则接收方必须以请求网络状态TLV(7.1.1节)进行回复。这些回复必须受到速率限制，每个链路在Imin内的每个独特的网络状态散列最多只能回复一次。确保这种速率限制的最简单方法是用时间戳来指示请求，并且每个Imin最多发送一个请求网络状态TLV（7.1.1节）。为了便于更快地进行状态同步，如果在回复中发送了请求网络状态TLV，也可以发送一个本地的、当前的网络状态TLV。
 节点状态TLV（7.2.3节）：

如果节点标识符与本地节点标识符相匹配，且TLV的序列号大于其当前的本地值，或序列号相同而哈希值不同，节点应重新发布自己的节点数据，其序列号明显大于接收到的序列号（如1000），以重新获得节点标识符。这个差值是需要的，以确保它高于网络中任何潜在的节点状态的残留副本。由于本地节点重启且没有存储最近使用的序列号，这种情况通常可能发生一次。如果这种情况发生不止一次，或者对于没有重新发布自己节点数据的节点，DNCP配置文件必须提供如何处理这些情况的指导，因为它表明存在另一个具有相同节点标识符的活动节点。
如果节点标识符与本地节点标识符不匹配，并且以下一个或多个条件为真：
1、节点的本地信息已经过时（本地序列号小于TLV内的序列号）。
2、信息可能不正确（本地序列号匹配，但节点数据哈希不同）。
3、节点完全没有数据。
则：
如果TLV中包含Node Data字段，也应该通过确保本地计算的Node Data哈希值与TLV中H(Node Data)字段的内容相匹配来验证。如果两者不同，则应忽略TLV，不作进一步处理。
如果TLV不包含Node Data字段，并且TLV中的H(Node Data)字段与该节点的本地Node Data哈希不同(或者没有)，则接收方必须为相应节点回复一个请求节点状态TLV(7.1.2节)。
否则，接收方必须更新其本地存储的该节点的状态（如果存在节点数据字段则基于节点数据、序列号和相对时间）来匹配接收到的TLV。

为了比较序列号，必须使用一个循环比较函数，以避免在溢出时出现问题。建议使用比较函数a < b <=> ((a - b) % (2^32)) & (2^31) != 0，其中(a % b)代表a与b的余数，(a & b)代表a与b的位元连接，除非DNCP配置定义了另一个函数。
 任何其他TLV：接收者不识别的TLV必须默默忽略，除非它们是在另一个TLV中发送的（例如，Node State TLV的Node Data字段中的TLV）。接收者不能识别的Node State TLV的Node Data字段中的TLV必须保留，用于分发到其他节点和计算7.2.3节中描述的节点数据哈希，但对于其他目的来说，则忽略。
如果为端点配置了安全的单播传输，那么通过不安全的多播收到的任何节点状态TLV必须默默忽略。

4.5. 发现、添加和删除对等体

邻居之间用一到多个相互连接的端点建立对等关系。这样的邻居直接交换网络状态和发布数据信息，通过转发，这些信息再在整个网络中传播。
新的对等体是使用DNCP配置（第9章）中定义的常规单播或组播传输来发现的。这个过程与对等体的添加没有区别，也就是说，未知的对等体只是通过接收来自它的常规DNCP协议TLV来发现的，不存在专门的发现消息或TLV。对于只有单播的传输，各个节点的传输地址是预先配置好的，或者使用外部服务发现协议获得。在存在组播传输的情况下，来自未知对等体的消息与来自已知对等体的组播消息的处理方式相同，因此，在使用组播发送其常规DNCP协议TLV时，只需发现新的对等体即可。
当从未知对等体端点上接收Node Endpoint TLV（7.2.1节）时：

如果通过单播接收，远程节点必须被添加为端点上的对等体，并且必须为其创建一个Peer TLV（7.3.1节）。
如果通过组播接收，节点可以被发送一个（可能限制速率）单播Request Network State TLV（7.1.1节）。
如果对等体没有发送6.1节中指定的keep-alive（要么DNCP配置没有指定使用keep-alive，要么特定的对等体选择不发送keep-alive），则必须使用其他现有的本地传输特定手段（如以太网载波检测或TCP keep-alive）来确保其存在。如果对等体不发送keep-alive，并且没有验证对等体存在的手段，则必须认为该对等体不再存在，并且在它开始再次发送keep-alive之前，不应将其添加回对等体。当对等体不再存在时，Peer TLV和本地DNCP对等体状态必须删除。DNCP没有定义一个明确的消息或TLV来指示终端节点终止DNCP操作，但是，如果需要的话，派生协议可以指定一个扩展。
如果本地端点处于Multicast-Listen+Unicast传输模式，则禁止为不具有最高节点标识符的对等体发布Peer TLV（7.3.1节）。

4.6. Data Liveliness Validation

维护哈希树(4.1节)，从而使网络状态哈希更新依赖于从拓扑图中得出的双向节点可达性最新信息。每当网络中增加或删除节点时，或者当现有节点之间建立或失去双向连接时，该图就会发生变化。因此，当以下情况发生时，该图必须立即更新或以比DNCP配置定义的Trickle Imin更短时间内更新：

Peer TLV或整个节点被添加或删除，或
某节点的节点数据的发起时间（以毫秒为单位）小于当前时间-2³²⁺²15。
发起时间的人为上限用于优雅地避免发起时间的溢出，并允许节点重新发布其数据，如7.2.3节所述。
拓扑图更新从本地节点标记为可达开始，其他所有节点标记为不可达。然后使用以下算法迭代地将其他节点标记为可达。如果有一个端点为NE的候选非可达节点N，其端点为RE的可达节点R符合以下所有标准，则该节点被标记为可达：
• R的节点数据的发起时间(ms)大于current time - 2^32 + 2^15.
• R发布一个Peer TLV符合：
 Peer Node Identifier = N的节点标识符
 Peer Endpoint Identifier = NE的端点标识符
 Endpoint Identifier = RE的端点标识符
• N 发布的Peer TLV 符合：
 Peer Node Identifier = R的节点标识符
 Peer Endpoint Identifier = RE的端点标识符
 Endpoint Identifier = NE的端点标识符
当再也找不到符合这些标准的候选节点时，算法就会终止。
在最近一次拓扑图遍历中无法到达的DNCP节点不得用于计算网络状态哈希，不得提供给任何需要使用整个图的应用程序，也不得提供给远程节点。它们可以在拓扑图遍历后立即被遗忘，但是，建议至少短暂地保留，以提高DNCP网络状态收敛的速度。这减少了在初始网络收敛期间和当网络的一部分在该时间段内失去和恢复双向连接时重新收敛所需的查询次数。

5. 数据模型

本章描述了一个最小化实现可能使用的本地数据结构，只是为了方便实现者而提供。一些可选扩展（第6章）描述了额外的数据要求，核心协议的一些可选部分也可能需要更多。
DNCP节点有：
 一个包含最近发送的Request Network State TLV数据的数据结构（7.1.1节）。最简单的选择是保留最近一次请求的时间戳（需要满足4.4节中规定的回复率限制）。
DNCP网络中的每一个DNCP节点都有：

节点标识符：节点的唯一标识符。长度、如何产生以及如何处理碰撞由DNCP配置决定。
节点数据：该节点发布的一组TLV。由于它们是按照特定的顺序传输的（见Node State TLV（7.2.3节）），在这里保持数据结构内的顺序可能是合理的。
最新序列号：32位的序列号，每次发布TLV集时都会递增。它们的比较函数在4.4节中描述。
Origination时间：当前序列号的TLV集被发布的（估计）时间。它用于填充节点状态TLV中的Milliseconds Since Origination字段（7.2.3节）。理想情况下为毫秒精度。
此外，DNCP节点配置使用一组端点。对于每个这样的端点：
端点标识符：32位不透明的本地唯一值，用于标识节点内的端点。在端点被禁用后，不应被立即重复使用。
Trickle 实例：端点的Trickle实例，参数为I、T和c（仅在Multicast+Unicast传输模式的端点上）。
和以下一个（或多个）：
接口：指定的本地网络接口。
单播地址：应该连接的DNCP节点。
地址集：连接被接受的DNCP节点。
对于在本地端点上检测到的每一个远程（peer, endpoint）对，DNCP节点具有：
节点标识符：对等体的唯一标识符。
端点标识符：对等体使用的唯一端点标识符。
对等体地址：对等体最近使用的地址（如果启用了安全功能则已认证和授权）。
Trickle实例：特定对等体的Trickle实例，参数为I、T和c（当使用不可靠的单播传输时，仅在单播模式的端点上）。

6. 可选扩展

本节规定了DNCP配置可以指定使用的核心协议扩展。

6.1. Keep-Alive

虽然DNCP提供了在端点上发现和添加新对等体的机制（4.5 节），以及状态变化通知，但如果传输层或下层没有提供4.6节中提到的机制，则可能需要另一种机制来删除失效的对等体。
如果DNCP配置中没有指定keep-alive，本节其余部分必须忽略。
DNCP配置可以指定每个端点（使用组播发送至连接的所有DNCP节点）或每个对等体（使用单播发送至每个对等体）的keep-alive支持。
对于在DNCP配置中指定的每个端点，必须维护端点指定的保活时间间隔。默认是DNCP_KEEPALIVE_INTERVAL。如果由于任何原因（配置、节能、媒介类型…），也可以用首选本地值。如果在任何端点上使用非默认保活时间，DNCP节点必须在其节点数据中发布一个适当Keep-Alive Interval TLV（7.3.2节）。

6.1.1. Data Model补充

需要对Data Model（第5章）进行以下补充，以支持保活。
对于每个配置的端点，如果启用了每端点keep-alive：

最后一次发送：一个时间戳，表明最后一次通过该接口发送Network State TLV的时间（7.2.2节）。
对于在本地端点上检测到的每个远程（peer, endpoint）对，DNCP节点有：
最后联系时间戳：一个时间戳，表明最后一次通过组播从对等体收到一致的Network State TLV（7.2.2节）或通过单播收到任何东西时。如果在6.1.5节规定的一定时间内没有更新，将导致对等体被删除。当添加一个新的对等体时初始化为当前时间。
最后一次发送：如果启用了每对等体保活，则表示最后一次向该对等体发送Network State TLV（7.2.2节）的时间戳。当添加一个新的对等体时初始化为当前时间。

6.1.2. 每Endpoint周期保活

如果在Multicast+Unicast传输模式下的端点上启用了每端点保活，并且在端点的保活间隔内没有向特定端点发送包含Network State TLV（7.2.2节）的流量，则必须在该端点上发送Network State TLV（7.2.2节），并且按照[RFC6206]4.2节的步骤2规定开始一个新的Trickle时间间隔。实际发送时间应进一步延迟，以[0, Imin/2]的随机时间为准。

6.1.3. 每Peer周期保活

如果在纯单播端点上启用了每peer保活，并且在端点特定保活间隔内没有向特定的peer发送包含Network State TLV（7.2.2节）的流量，则必须向对等发送Network State TLV（7.2.2节），并且按照[RFC6206]4.2节第2步规定开始一个新的Trickle间隔。

6.1.4. 收到TLV处理补充

如果通过单播从对等体收到TLV，必须更新对等体的最后联系时间戳。
在收到与本地计算的网络状态哈希一致的网络状态TLV（7.2.2节）时，必须更新对等体的最后联系时间戳，以维持其为对等体。

6.1.5. Peer移除

对于每个端点上的每个对等体，必须通过寻找节点发布的Keep-Alive Interval TLV（7.3.2节）来计算端点特定的keep-alive间隔，如果不存在，则使用DNCP_KEEPALIVE_INTERVAL的默认值。如果对等体的最后联系时间戳至少在本地选择的可能终端指定的保活倍数（默认为DNCP_KEEPALIVE_MULTIPLIER）乘以对等体的终端指定保活间隔后没有更新，该对等体的Peer TLV和本地DNCP对等体状态必须移除。

6.2. 支持密集多播链接

需要这种优化来避免状态空间的爆炸。给定一大组DNCP节点使用组播的端点上发布数据，每个节点都会为每个对等体添加一个Peer TLV（7.3.1节）。虽然Trickle在一定程度上限制了稳定状态下链路的流量，但在启用组播的链路上给定N个节点，被添加到DNCP网络中并保持的数据总量是O(N^{2)。此外，如果使用每peer保活，如果对等体的存活没有通过其他方式（如TCP连接寿命、二层通知或每端点保活）保证，那么将有O(N}2)个保活在链接上运行。
Multicast+Unicast传输模式的端点在特定类型的链路上使用时，允许的对等体数量的上限应该由DNCP配置指定，但也可以在运行时选择。在为特定类型的链接选择约束（如果有的话）时，主要考虑的是是否支持组播流量，以及在该特定类型的链接上使用DNCP配置时，是否可能发生对等体数量过多的情况。如果这两种情况都不可能发生，那么为该特定链路类型指定该支持就没有什么意义。
如果DNCP配置完全不支持这个扩展，本节的其余部分必须忽略。这是因为当使用此扩展时，DNCP网络中的状态只包含网络完整拓扑的一个子集。因此，每个节点都必须意识到它在DNCP配置被使用的可能性。
如果在Multicast+Unicast传输模式下的某个端点超过了指定的上限，并且该节点没有链路上的最高节点标识符，那么它应该将该端点视为连接到链路上检测到的具有最高节点标识符的节点的单播端点，因此过渡到Multicast-listen+Unicast传输模式。具体端点行为的影响见4.2节。在Multicast-listen+Unicast传输模式的节点必须继续监听多播流量，以便从仍处于Multicast+Unicast模式的节点接收消息，并对出现的具有更大节点标识符的节点做出反应。如果链路上出现的最高节点标识符发生变化，Multicast-listen+Unicast传输模式端点的远程单播地址必须改变。如果本地节点的节点标识符是最高的，该节点必须切换回或保持在Multicast+Unicast模式，并按照4.5节的规定与所有对等体形成对等关系。

7. TLV对象

每个 TLV编码为：
• 一个2字节Type字段
• 一个2字节Length字段，包含Value字段的长度（以字节为单位），0表示没有Value。
• value (如果有)
• 值为0的填充字节，如果长度不能被4整除则填充至下一个4字节边界。
虽然填充字节不能包括在TLV的Length字段中，但如果TLV被包含在另一个TLV中，那么填充将被包含在外层TLV的长度值中。
每个没有定义可选字段或可变长度内容的TLV都可以在发送时在后面附加子TLV来扩展。在处理这种TLV类型时，每个节点必须接受收到的TLV，其长度超过为特定类型指定的固定字段，并忽略未知类型或该特定TLV中不支持类型的子TLV。如果有子TLV，TLV的长度字段为从TLV自身的Value（如果有的话）的第一个字节到最后一个子TLV的最后（填充）的字节数。
例如，type=123（0x7b）TLV的值为’x’（120=0x78），编码为：007B 0001 7800 0000. 如果它有一个类型124（0x7c）的子TLV，值为’y’，它将被编码为：007B 000C 7800 0000 007C 0001 7900 0000。
本章使用了以下特殊符号：
… = octet string连接操作。
H(x) =由DNCP配置指定的非加密散列函数。
除了本文定义的TLV类型外，TLV类型11-31和512-767是未指定的，可以通过Standards Action [RFC5226]从11开始依次注册，来扩展DNCP，可能用于多个DNCP配置。

7.1. 请求TLV

7.1.1. 请求Network State TLV

该TLV用于请求响应Network State TLV（7.2.2节）和所有Node State TLV（7.2.3节）（不带节点数据）。

7.1.2. 请求Node State TLV

用于请求具有指定节点标识符节点的Node State TLV（7.2.3节）（包括节点数据）。

7.2. Data TLV

7.2.1. Node Endpoint TLV

该TLV既表明了本地节点的节点标识符，也标识了特定的端点的端点标识符。4.2节规定了发送时机。

7.2.2. Network State TLV

此TLV包含由发送者计算的当前网络状态哈希值（4.1节描述了该算法）。

7.2.3. Node State TLV

此TLV代表本地节点保存的DNCP网络中由指定节点发布状态。
每个节点（包括发布节点数据的节点）发送Node State TLV时，都必须根据节点估计数据最初发布时间更新Milliseconds Since Origination。这是为了确保发布的节点数据中包含的任何相对时间戳能够被正确地抵消和解释。提供的只是一个近似值，因为没有考虑到传输延迟。
在没有任何变化的情况下，如果发端节点注意到32位Milliseconds Since Origination接近溢出（大于2^32 - 2^16），即使没有变化，该节点也必须重新发布其TLV。换句话说，如果没有任何其他变化，TLV集必须大约每48天重新发布一次。
节点的实际节点数据可以包含在TLV中，也可以包含在可选Node Data字段中。TLV集必须根据升序的二进制内容（包括TLV类型和长度）严格排序。这可以使接收方有效地进行状态delta处理，并通过TLV类型进行无拷贝索引。节点的数据内容必须完全按照它的接收方式来传递。在到时还应收该验证本地计算的H(Node Data)是否与TLV中的字段内容相匹配，如果哈希值不同，TLV应该被忽略。

7.3. Node State TLV 中的Data TLV

这些TLV是由DNCP节点发布的，因此只编码在Node State TLV的Node Data字段中。如果在Node State TLV之外遇到，必须默默忽略掉。

7.3.1. Peer TLV

此TLV表示节点证明指定的Peer在指定的本地端点上是可以到达的。这个TLV的存在至少可以保证发布它的节点最近收到了来自对等体的流量。为了保证最新的双向可达性，需要检查两节点的对应Peer TLV是否存在。

7.3.2. Keep-Alive Interval TLV

此TLV表示一个非默认的间隔，用于发送6.1节中规定的保活。
端点标识符用于识别发送节点上适用该间隔的（本地）端点。如果是0，则适用于所有的端点，不存在特定TLV。
间隔指定节点发送keep-alive的时间间隔，单位是毫秒。如果数值为0，意味着根本不保活；在这种情况下，必须有一些确保节点存在的下层机制。

8. 安全和信任管理

如果在 DNCP 配置文件中指定，DTLS [RFC6347] 或 TLS [RFC5246] 可用于认证和加密某些（如果在配置文件中指定为可选）或所有单播流量。以下是建立信任的方法，但由DNCP配置文件来指定哪些方法可以、应该或必须支持。

8.1.基于Pre-Shared Key的信任方法

基于预共享密钥（PSK）的信任模型是一种简单的安全管理机制，允许管理员通过配置预定义密钥将设备部署到现有网络中，类似于配置管理员密码或Wi-Fi保护访问（WPA）密钥。虽然作用有限，但对于为较小的网络提供一个用户友好的安全机制是很有用的。

8.2. PKI-Based信任方法

基于PKI的信任模型可以实现更高级的管理能力，但代价是增加了复杂性和启动工作。然而，它允许以集中的方式管理信任，因此对需要权威信任管理的大型网络很有用。

8.3. 基于证书的信任共识法

对于某些场景–例如引导启动一个基本无人管理的网络–上述方法可能无法在安全和用户体验之间提供理想的权衡。本节包括实施机会安全[RFC7435]方法的指导，DNCP配置文件可以在此基础上进行调整，以满足具体要求。
基于证书的共识模型设计为信任管理工作和灵活性之间的妥协。它基于X.509证书，允许每个DNCP节点对任何其他证书提供信任判决，并找到一个共识，以确定使用该证书的节点或由其签署的任何证书是否值得信任。
不使用这种安全方法的 DNCP 节点必须忽略所有通告的信任判决，并且不得自行通告任何此类判决，即本小节中的任何其他规范性语言对其不适用。
任何证书的当前有效信任判决被定义为当时为该证书通告的所有信任判决中最高优先级的判决。

8.3.1. 信任判决（Trust Verdict）

信任判决是DNCP节点对X.509证书的可信度的声明。有5种可能的信任判决，按优先级升序排列：
0 (Neutral)：不存在信任判决，但DNCP网络应该确定一个。
1 (Cached Trust)：最后已知的有效信任判决是配置或缓存信任。
2 (Cached Distrust)：最后已知的有效信任判决是配置的或缓存的不信任。
3 (Configured Trust)：基于外部ceremony或配置的信任。
4 (Configured Distrust)：根据外部ceremony或配置不信任。

信任判决被分为3组：

配置的裁决，用于通告节点基于外部信任引导或节点与给定证书形成的预定义关系的明确信任裁决。
缓存裁决，用于保留最后的已知信任状态，以防所有对指定证书配置裁决的节点都断开或关闭。
中立判决，用于通告一个打算加入网络的新节点，因此可以为它找到一个最终判决。
任何证书的当前有效信任判决定义为DNCP网络中为该证书通告的信任判决集中最高优先级的判决。当且仅当一个节点自己的证书或其证书层次中的任何一个的当前有效信任判决为（缓存或配置）信任，并且其层次中没有任何证书的有效信任判决为（缓存或配置）不信任时，该节点必须被信任以参与DNCP网络。如果节点有配置的判决，而这个判决与证书的当前有效信任判决不同，那么在决定可信度时，当前的有效信任判决优先。尽管如此，该节点仍然保留并通告其配置的判决。

8.3.2. Trust Cache

每个节点应维护一个信任缓存，其中包含当前在DNCP网络中通告的所有证书的当前有效信任判决。该缓存被用作最后已知状态的备份，以防没有节点通告已知证书的配置判决。它应该以合理的时间间隔被保存到非易失性存储器中，以便在重启或断电时仍能生效。
每当节点（重新）加入网络或检测到任何证书的有效信任判决变化时，将同步其缓存，即存储新的有效信任判决，覆盖任何先前缓存的判决。配置好的裁决被存储在缓存中。中立判决不存储，也不会覆盖现有的缓存判决。

8.3.3. 判决通告

节点应始终通告自己建立的任何配置的判决，如果通告配置的判决会导致相应证书的当前有效信任判决发生变化，它必须这样做。在没有配置的裁决的情况下，如果下列条件之一适用，必须通告已存储在其信任缓存中的缓存信任裁决：

存储的信任判决是缓存的信任，而该证书当前的有效信任判决是中立或不存在。
存储的信任判决是缓存的不信任，而该证书的当前有效信任判决是缓存的信任。
每当节点检测到网络中任何地方通告的信任判决发生变化时，就会重新检查这些条件。
没有有效信任判决的证书层次的节点会在其节点数据中为该层次中发现的所有证书添加一个中立信任判决TLV，并通告，直到为任何证书找到不同于中立的有效信任判决，或者在合理的时间内（建议为10分钟）没有任何反应且没有进一步的认证尝试。这种信任裁决的速度和数量也应该受到限制，以防止拒绝服务攻击。
信任判决是使用Trust-Verdict TLV通告的：

Verdict代表信任判决的数字索引。
(reserved)是为将来实现保留的，在创建TLV时必须设置为0，在解析TLV时忽略。
SHA-256 Fingerprint包含DER格式证书的SHA-256 [RFC6234]哈希值。
Common name包含可变长度（1-64字节）证书通用名。

8.3.4. Bootstrap Ceremony

以下非详尽方法清单描述了在DNCP节点和节点证书之间建立信任关系的可能方式。信任的建立是一个双向的过程，现有网络必须信任新加入的节点，而新加入的节点必须至少信任一个对等节点。因此，新添加的节点和已经受信任的节点都必须执行这样的过程，以成功地将一个节点引入DNCP网络。在所有的情况下，必须为管理员提供外部手段，根据指纹和有意义的通用名来识别属于证书的节点。

8.3.4.1. 通过标识信任

实施基于证书信任的节点必须提供一个接口，以检索当前有效的信任判决集、指纹和当前已知的所有证书名，并设置要通告的配置判决。或者可以向与它有预先建立信任关系的伙伴DNCP节点或应用程序提供这些能力。

8.3.4.2. 预配置信任

节点可以预设为信任某一组节点或CA证书。然而，这种信任关系不得导致对不打算在同一网络内运行的节点（例如，同一制造商的所有其他设备）的不必要或不相关的信任。

8.3.4.3. 按键信任

节点可以提供一个物理或虚拟接口，把它的一个或多个内部网络接口暂时放入一种模式，在这种模式下，信任能成功建立连接的第一个DNCP节点的证书。

8.3.4.4. 首次使用信任

没有与任何其他DNCP节点关联的节点，可以信任能成功建立连接的第一个DNCP节点的证书。当节点已经与任何DNCP节点关联时，决不能使用这种方法。

9. DNCP Profile具体定义

每个DNCP配置必须指定以下方面：

要使用的单播和可选的多播传输协议。如果需要基于组播的节点和状态发现，必须有一个支持组播的数据报传输。
所选择的传输方式的安全性：完全没有，可以选择，也可以始终使用这里定义的使用使用一种或多种方法的TLS方案，或者使用其他方法。如果与DNCP节点的链接能够充分保护或隔离，那么就有可能以安全的方式运行DNCP，而不使用任何形式的认证或加密。
传输协议的参数，如要使用的端口号或多播地址。单播、多播和安全单播可能各自需要不同的参数（如果适用）。
当接收TLV时，忽略什么样的TLV–如4.4节中规定的–例如，出于安全原因。虽然基本规范已经确保了在Node State TLV中发布的节点数据的安全性（如果使用安全的单播传输，Node State TLV只能通过单播发送，因为多播的在接收时被忽略），但如果配置增加了在节点数据之外发送的TLV，配置文件应该说明如果通过多播或非安全的单播接收这些TLV，是否应该被忽略。DNCP配置可以定义安全忽略以下DNCP TLV：
 通过组播收到的任何东西，除了Node Endpoint TLV（7.2.1节）和Network State TLV（7.2.2节）。
 任何通过不可靠单播或多播收到的速率过高TLV；Trickle将通过放慢速率确保最终收敛。
如何处理4.4节中描述的节点标识符碰撞问题。主要的选择是，一个或两个节点为自己分配新的节点标识符，或者通知别人DNCP网络中的致命错误状况。
建议在Trickle算法中使用Imin、Imax和k范围。Trickle算法并不要求所有的实施方案都是一样的，但相似数量级有助于DNCP配置文件的实施方案表现得更加一致，并便于估计网络收敛行为的下限和上限。
要使用的哈希函数H(x)，以及使用时输出多少位。指定的散列函数用于处理节点数据的散列和产生网络状态的散列（节点数据散列的散列）。[RFC6234]中定义的SHA-256是推荐的默认选择，但也可以使用非加密的哈希函数。如果在网络状态哈希中存在哈希碰撞，网络将有效地被划分为认为是最新的但实际上不再收敛的分区。当网络中任何地方的节点数据发生变化时，或者当冲突的Node State TLV在分区中得到传输时（由Trickle-Driven Status Updates（4.3节）或作为Processing of Received TLV（4.4节）的一部分引起），网络将收敛。如果一个节点发布的节点数据的哈希值与之前发布的任何节点数据相冲突，那么更新可能不会被（完全）传播，旧版本的节点数据可能被使用。
DNCP_NODE_IDENTIFIER_LENGTH：节点标识符的固定长度（字节数）。
是否发送keep-alive，如果是的话，是每端点（需要多播传输）还是每peer。Keep-alive也有相关参数：
 DNCP_KEEPALIVE_INTERVAL：发送keep-alive的默认频率（如果启用）。
 DNCP_KEEPALIVE_MULTIPLIER：节点多少次DNCP_KEEPALIVE_INTERVAL（或对端提供的保活间隔）没有收到才会认为失效。这只是在没有任何其他配置信息或特定的每端点配置时使用的默认值。
是否支持密集组播启用的链路优化（6.2节）。
关于选择传输和安全选项的指导见附录B。

10. 安全考虑

基于DNCP的协议可以使用组播来指示DNCP的状态变化，并用于保活。然而，没有实际通告的数据TLV会在该通道上发送。因此，攻击者可能只了解DNCP内部状态的哈希值，并可能以这种方式触发本地链路上节点之间的单播同步尝试。因此，一个DNCP节点必须限制其对多播数据包的反应速度。
当使用DNCP来引导启动网络时，基于PKI的解决方案在验证证书时可能会出现问题，因为可能无法获得准确的时间，或者由于无法使用网络来检查证书撤销列表或执行在线验证。
本文定义的基于证书的信任共识机制允许同意撤销；但是，在设备被破坏的情况下，信任缓存可能会在实际撤销发生之前被恶意修改，允许不信任的设备使用不同的身份重新加入网络。阻止这种攻击可能需要物理干预和flush信任缓存。

11. IANA考虑

IANA为"分布式节点共识协议（DNCP）"下的（十进制16位）"DNCP TLV Type"建立了一个注册表。注册程序是Standards Action [RFC5226]。最初的内容是:
0: Reserved
1: Request network state
2: Request node state
3: Node endpoint
4: Network state
5: Node state
6: 留作未来使用(was: Custom)
7: 留作未来使用(was: Fragment count)
8: Peer
9: Keep-alive interval
10: Trust-Verdict
11-31: 未分配
32-511: 留作per-DNCP profile使用
512-767: 未分配
768-1023: 留作私有实现 [RFC5226]
1024-65535: 留作未来使用

附录A. 备选操作模式

除了正文中描述的内容，该协议还允许其他用途。这些都是作为例子提供的：

A.1. 只读操作

如果一个节点只使用一个端点，不需要发布任何TLV，就不需要完整的DNCP节点功能。这样一个受限节点可以通过实现4.4节中规定的处理逻辑来获取和维护TLV空间的视图。这样的节点根本不需要Trickle、Peer维护，甚至不需要keep-alive，因为DNCP节点使用其保证最终收到网络状态的哈希值，以及节点数据的同步，即使在存在不可靠传输的情况下。

A.2. 转发操作

如果一个拥有一对端点的节点不需要发布任何TLV，它可以检测（例如）每个端点上具有最高节点标识符的节点（如果有的话）。从其中一个节点收到的任何TLV将被逐字转发到具有最高节点标识的另一个节点。
对TLV的任何改动都会不能保证这一方案可工作；然而，被动监测显然是好的。这种类型的简单转发不能链，因为它不会主动发送任何东西。

附录 B. DNCP Profile附加指南

本附录解释了在指定DNCP配置文件以使用特定的传输或安全选项时设计选择的影响。

B.1. 单播 – UDP还是TCP?

DNCP节点发布的节点数据限制在64KB，因为它被TLV的16位Length限制。一些传输选择可能会降低这个限制；如果使用UDP数据报进行单播传输，节点数据的上限是节点和底层网络可以相互传递的内容，因为DNCP没有定义自己的碎片方案。选择UDP的配置文件必须限于小的节点数据（例如，如果使用IPv6，比IPv6默认MTU小一些），或者指定一个所有节点都必须支持的最小值。即便如此，如果使用非linklocal通信，人们也会担心中间件对碎片化的数据包做什么。因此，如果希望使用非linklocal通信或预计碎片会造成问题，使用流传输（如TCP）可能是一个好主意。
TCP还提供了一些其他设施，比如相对较长的内置保活，结合重传失败产生的连接关闭，可能足以避免使用6.1节中定义的协议内保活。此外，它是可靠的，所以在这种单播连接上不需要Trickle。
在基于DNCP的配置中使用TCP而不是UDP的主要缺点在于失去了对接收TLV的时间的控制；虽然不可靠的UDP数据报也有一些延迟，但可靠的流传输中的TLV可能会因为重传而被大大延迟。如果基于DNCP协议中的TLV中没有存储相对时间信息，这就不是一个问题；对于这样的协议，如果有TCP，那么TCP是单播传输的合理选择。

B.2. (可选) 组播传输

动态对端发现和触发单播交换需要组播；为此，不可靠的数据报传输（=通常是UDP）是本规范内定义的唯一传输选项，尽管基于DNCP的协议本身可以定义一些其他传输或对等体发现机制（例如，基于组播DNS（mDNS）或DNS）。
如果使用组播，应指定一个知名地址，对于，例如IPv6，应分别指定所需的地址范围。在大多数情况下，linklocal和可能的site-local是有用的范围。

B.3. (可选) 传输安全

DTLS和TLS提供的安全性差不多；它们也在设备上消耗了类似的状态。虽然TLS是在流协议之上，但使用DTLS也需要在DTLS层内进行相对较长的会话缓存，以避免在DNCP网络内的任何状态发生变化或发送每peer的keep-alive（如果启用）时进行昂贵的重新认证/授权步骤。
TLS的实现（在编写本规范时）似乎比DTLS的实现更加成熟和可用（作为开源代码）。这可能是由于HTTPS有很长的使用历史。
一些库似乎不支持同一端口的不安全和安全通信一起使用，因此为安全和不安全通信指定不同的端口可能是有益的。
附录 C. Profile例子
这是SHSP的DNCP配置文件，这是一个实验性的（就本文而言是虚构的）家庭自动化协议。该协议本身是用来使每个节点发布的kv存储对所有其他节点可用，以便对家庭基础设施进行分布式监控。它只定义了一个额外的TLV类型：一个key=value TLV，内含key=value 分配用于发布。

单播传输：EXAMPLE-P1端口的IPv6 TCP，因为在key=value数据中只使用了绝对的时间戳，并且由于它主要集中在支持这两种协议的Linux节点上。来自非linklocal地址的连接被忽略，以避免将该协议暴露在安全链路之外。
多播传输：端口EXAMPLE-P2上的IPv6 UDP到linklocal范围的组播地址ff02:EXAMPLE。假设家庭中每条链路至少有一个节点支持节点发现而不依赖于任何其他基础设施。
安全性：无。它只用于可信的链接（WPA2-x无线，物理安全的有线链接）。
要忽略的其他TLV：无。没有指定DNCP安全性，也没有在节点数据之外定义新的TLV。
节点标识符长度（DNCP_NODE_IDENTIFIER_LENGTH）：32位，随机生成。
节点标识符的碰撞处理：挑选新的随机节点标识符。
Trickle参数：Imin = 200 ms, Imax = 7, k = 1. 这意味着在稳定状态下，每条链路在25秒内至少有一次组播（0.2 * 2^7）。
o Hash函数H(x)+长度：SHA-256，只使用128位。它的速度相对较快，而且128位应该足够防止随机冲突（64位也很可能足够）。

o 没有协议内的保活（6.1节）；使用TCP保活。在实践中，TCP keep-alive很少遇到，因为网络状态的变化时会有数据包在单播连接上发送，而那些失败的数据包在keep-alive真正启动之前就被丢弃了。

o 不支持密集组播的链路优化（6.2节）；SHSP是少数节点的简单协议（网络范围，甚至不提在单一链路上），因此不会提供任何好处。

RFC7787-Distributed Node Consensus Protocol-DNCP相关推荐

【Paper】2021_Analysis of the Consensus Protocol of Heterogeneous Agents with Time-Delays
发一篇自己写的文章,欢迎各位引用,引用格式如下: Zhao, Jichao & Dai, Fengzhi & Yunzhong, Song. (2021). Analysis of t ...
【Paper】2017_The distributed optimal consensus algorithms for general linear multi-agent systems
Zhang F, Wang H, Tan C, et al. The distributed optimal consensus algorithms for general linear multi ...
【Paper】2021_Optimal Distributed Leader-following Consensus of Linear Multi-agent Systems: A Dynamic
Ren Y, Wang Q, Duan Z. Optimal Distributed Leader-following Consensus of Linear Multi-agent Systems: ...
Consul Consensus Protocol
Consensus Protocol(一致性协议) Consul使用共识协议来提供一致性(由CAP定义).共识协议基于"Raft:寻找可理解的共识算法".有关Raft的直观解释,请 ...
Nomad技术手册：共识协议（Consensus Protocol）
Nomad使用共识协议来提供一致性(由CAP定义).共识协议的基础是"Raft:寻找一种可以理解的共识算法".有关Raft的可视化解释,请参见数据的秘密生命. 高级主题!这个页面涵 ...
【NDN IoT】Challenges in IoT Networking via TCP/IP Architecture 全文翻译
Challenges in IoT Networking via TCP/IP Architecture 在TCP/IP体系结构下物联网络存在的挑战 Wentao Shang ...
An Overview of Blockchain Technology: Architecture, Consensus, and Future Trends 全文翻译
An Overview of Blockchain Technology: Architecture, Consensus, and Future Trends 区块链技术综述:体系结构,共识算法和未 ...
【Paper】2020_Distributed optimal consensus with obstacle avoidance algorithm of mixed-order UAVs
Yang X, Wang W, Huang P. Distributed optimal consensus with obstacle avoidance algorithm of mixed-or ...
From blockchain consensus back to Byzantine consensus
文章目录 1. Pow model 2. 一般化的共识问题--拜占庭共识 3. 区块链共识算法 3.1 有向无环图(DAG: Directed acyclic graph) 3.2 分叉(Forks) ...

RFC7787-Distributed Node Consensus Protocol-DNCP