Distributed Node Consensus Protocol
Extracted elements (31)
DNCP is intentionally abstract and profile-based so it can be tuned for diverse applications by specifying transport, security, multicast support, addressing scope, payload types, and extensions. Poor fits include nodes with large data sets, predominantly small incremental changes, very high update frequency, or very dense unicast-only topologies.
SHA-256 is the recommended default hash function for both node data hashing and network state hash computation. A non-cryptographic hash is permissible; however, a hash collision in the network state hash will partition the network until some data changes or conflicting Node State TLVs cross the partition boundary via Trickle.
The dense multicast optimization (Section 6.2) avoids O(N²) growth in both published state size and keep-alive traffic on large multicast-enabled links. Nodes without the highest node identifier delegate to the highest-identifier node via unicast, reducing full-mesh Peer TLV and keep-alive counts to O(N).
Trickle transmits only the short network state hash rather than full data; in steady state, once the maximum Trickle interval is reached, only one hash per interval is needed, making DNCP 'very thrifty when updates happen rarely.' Networks with A_NC_I below the Trickle minimum interval gain little benefit from DNCP.
TLV types that lack optional fields or variable-length content MAY carry appended sub-TLVs for extensibility; receivers MUST accept TLVs longer than their defined fixed portion and MUST silently ignore sub-TLVs with unknown or locally unsupported types, ensuring forward compatibility with future extensions.
A DNCP node MUST send a Node Endpoint TLV to enable bidirectional peer relationship formation. On a stream transport it MUST be sent at least once per connection (SHOULD NOT more than once); on a datagram transport it MUST appear in every datagram that contains a Network State TLV and MUST be positioned before any such TLV.
A node MUST be trusted for DNCP participation if and only if the effective trust verdict for its own certificate or any ancestor in its hierarchy is Cached or Configured Trust, AND none of the certificates in the hierarchy carry an effective verdict of Cached or Configured Distrust.
A node MUST NOT reset its Trickle state merely because it receives a Network State TLV with a different hash; Trickle state is reset if and only if the locally calculated network state hash changes (due to local data change or receipt of more recent data).
DNCP MUST NOT fragment or reassemble TLVs; the underlying transport MUST perform fragmentation/reassembly if necessary. TLVs SHOULD be sent together where MTU permits.
Each DNCP profile MUST specify: unicast transport (and optionally multicast); security scheme; transport parameters (ports, multicast addresses); additional TLV ignore rules; node identifier collision handling; Trickle Imin/Imax/k ranges; hash function H(x) and output bit length; DNCP_NODE_IDENTIFIER_LENGTH; and keep-alive configuration.
Every node MUST update the Milliseconds Since Origination field in any Node State TLV it sends, based on the estimated original publication time. To prevent 32-bit overflow, the originating node MUST republish its TLV set roughly every 48 days even when unchanged (when the field would exceed 2³² − 2¹⁶).
If secure unicast transport is configured for an endpoint, any Node State TLVs received over insecure multicast MUST be silently ignored.
Replies to multicast TLVs received on a multiple-access link MUST be delayed by a random time in [0, Imin/2] to avoid simultaneous replies. Network State TLV replies MUST be rate limited to at most one Request Network State TLV per link per unique network state hash within Imin.
Sequence number comparisons MUST use a looping modular function to handle 32-bit wrap-around: a < b ⟺ ((a − b) mod 2³²) & 2³¹ ≠ 0, unless the DNCP profile specifies an alternative.
The set of TLVs in Node Data MUST be strictly ordered by ascending binary content (type and length included). Node data content MUST be passed along exactly as received; the H(Node Data) field SHOULD be verified on receipt and mismatching TLVs SHOULD be discarded.
The topology graph MUST be updated immediately or within less than Trickle Imin whenever a Peer TLV or node is added or removed, or a node's origination time approaches 32-bit overflow (> current time − 2³² + 2¹⁵ ms). Nodes not reachable in the latest topology traversal MUST NOT contribute to the network state hash or be provided to applications or remote nodes.
Unrecognized top-level TLVs MUST be silently ignored. Unrecognized TLVs within Node Data MUST be retained for forwarding to other nodes and for node data hash calculation, but are otherwise ignored.
When a Node Endpoint TLV is received over unicast from an unknown peer, the remote node MUST be added as a peer and a Peer TLV MUST be created for it. If a peer sends no keep-alives and no lower-layer presence verification exists, the peer MUST be considered no longer present and SHOULD NOT be re-added until it resumes sending keep-alives.
When a Trickle instance fires, the node MUST send a Network State TLV via multicast if the endpoint is in Multicast+Unicast mode, or via unicast if the endpoint uses unreliable unicast transport.
DNCP is an abstract state synchronization protocol in which each node publishes up to 64 KB of TLV tuples; a hash tree of height 1 (network state hash) combined with the Trickle algorithm provides a shared, consistent view of all bidirectionally reachable nodes' data across the DNCP network.
DNCP maintains an arbitrary-width hash tree of height 1 per node; each leaf represents one bidirectionally reachable node. The network state hash is H(seq_1 ‖ H(data_1) ‖ … ‖ seq_N ‖ H(data_N)) with per-node data concatenated in ascending node-identifier order.
The certificate-based trust consensus mechanism defines five verdicts in ascending priority: Neutral (0), Cached Trust (1), Cached Distrust (2), Configured Trust (3), Configured Distrust (4). The effective trust verdict for a certificate is the highest-priority verdict announced by any node in the DNCP network for that certificate.
IANA has created the 'DNCP TLV Types' registry under 'Distributed Node Consensus Protocol (DNCP)' with registration procedure Standards Action. Initial assignments: 0 (Reserved), 1 (Request network state), 2 (Request node state), 3 (Node endpoint), 4 (Network state), 5 (Node state), 8 (Peer), 9 (Keep-alive interval), 10 (Trust-Verdict); 11–31 and 512–767 unassigned; 32–511 reserved for per-profile use; 768–1023 private use; 1024–65535 reserved.
An attacker with multicast access can only observe network state hashes and may trigger spurious unicast synchronization between nodes; no published data TLVs traverse the multicast channel. A DNCP node MUST therefore rate limit its reactions to multicast packets.
The trust cache in the certificate-based consensus mechanism can be poisoned before revocation occurs, allowing a compromised device to rejoin the network under a different identity. Remediation may require physical intervention and manual flushing of trust caches on all nodes.
Endpoint transport mode transitions: a node starts in Multicast+Unicast or unicast mode. When peer count on a Multicast+Unicast endpoint exceeds the profile upper bound and the local node does not have the highest node identifier, the endpoint SHOULD transition to MulticastListen+Unicast (unicast only, to the highest-identifier peer, while continuing to listen to multicast). If the local node becomes the highest-identifier node, it MUST switch back to Multicast+Unicast and form full peer relationships.
Each TLV is encoded as a 2-byte Type field, a 2-byte Length field (value bytes only, excluding padding), the value bytes, and zero-padding bytes to the next 4-byte boundary. Padding bytes are excluded from the Length field itself but are counted in any enclosing TLV's Length.
Keep-Alive Interval TLV (type 9) encodes a 32-bit Endpoint Identifier (0 = all endpoints without a specific TLV) and a 32-bit Interval in milliseconds; a value of zero means no keep-alives are sent, requiring a lower-layer presence mechanism.
Node State TLV (type 5) encodes: Node Identifier (profile-defined length), 32-bit Sequence Number, 32-bit Milliseconds Since Origination, H(Node Data) (profile-defined length), and an optional Node Data field containing nested TLVs.
Peer TLV (type 8) encodes: Peer Node Identifier (profile-defined length), 32-bit Peer Endpoint Identifier, and 32-bit Local Endpoint Identifier. Published within Node Data to assert that the publishing node can reach the specified peer on the specified local endpoint.
Trust-Verdict TLV (type 10) encodes: 1-byte Verdict (0–4), 3 reserved bytes (must be zero), 32-byte SHA-256 fingerprint of the DER-encoded certificate, and a variable-length Common Name (1–64 bytes).