draft-ietf-homenet-dncp-03.txt   draft-ietf-homenet-dncp-04.txt 
Homenet Working Group M. Stenberg Homenet Working Group M. Stenberg
Internet-Draft Internet-Draft
Intended status: Standards Track S. Barth Intended status: Standards Track S. Barth
Expires: October 26, 2015 Expires: December 3, 2015
April 24, 2015 June 1, 2015
Distributed Node Consensus Protocol Distributed Node Consensus Protocol
draft-ietf-homenet-dncp-03 draft-ietf-homenet-dncp-04
Abstract Abstract
This document describes the Distributed Node Consensus Protocol This document describes the Distributed Node Consensus Protocol
(DNCP), a generic state synchronization protocol which uses Trickle (DNCP), a generic state synchronization protocol which uses Trickle
and Merkle trees. DNCP is transport agnostic and leaves some of the and Merkle trees. DNCP is transport agnostic and leaves some of the
details to be specified in profiles, which define actual details to be specified in profiles, which define actual
implementable DNCP based protocols. implementable DNCP based protocols.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 26, 2015. This Internet-Draft will expire on December 3, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 17
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Trickle-Driven Status Updates . . . . . . . . . . . . . . 7 5.1. Trickle-Driven Status Updates . . . . . . . . . . . . . . 7
5.2. Processing of Received TLVs . . . . . . . . . . . . . . . 7 5.2. Processing of Received TLVs . . . . . . . . . . . . . . . 7
5.3. Adding and Removing Peers . . . . . . . . . . . . . . . . 9 5.3. Adding and Removing Peers . . . . . . . . . . . . . . . . 9
5.4. Purging Unreachable Nodes . . . . . . . . . . . . . . . . 9 5.4. Purging Unreachable Nodes . . . . . . . . . . . . . . . . 10
6. Optional Extensions . . . . . . . . . . . . . . . . . . . . . 9 6. Optional Extensions . . . . . . . . . . . . . . . . . . . . . 10
6.1. Keep-Alives . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Keep-Alives . . . . . . . . . . . . . . . . . . . . . . . 10
6.1.1. Data Model Additions . . . . . . . . . . . . . . . . 10 6.1.1. Data Model Additions . . . . . . . . . . . . . . . . 11
6.1.2. Per-Endpoint Periodic Keep-Alives . . . . . . . . . . 10 6.1.2. Per-Endpoint Periodic Keep-Alives . . . . . . . . . . 11
6.1.3. Per-Peer Periodic Keep-Alives . . . . . . . . . . . . 10 6.1.3. Per-Peer Periodic Keep-Alives . . . . . . . . . . . . 11
6.1.4. Received TLV Processing Additions . . . . . . . . . . 11 6.1.4. Received TLV Processing Additions . . . . . . . . . . 11
6.1.5. Neighbor Removal . . . . . . . . . . . . . . . . . . 11 6.1.5. Neighbor Removal . . . . . . . . . . . . . . . . . . 12
6.2. Support For Dense Broadcast Links . . . . . . . . . . . . 11 6.2. Support For Dense Broadcast Links . . . . . . . . . . . . 12
6.3. Node Data Fragmentation . . . . . . . . . . . . . . . . . 12 6.3. Node Data Fragmentation . . . . . . . . . . . . . . . . . 12
7. Type-Length-Value Objects . . . . . . . . . . . . . . . . . . 12 7. Type-Length-Value Objects . . . . . . . . . . . . . . . . . . 13
7.1. Request TLVs . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Request TLVs . . . . . . . . . . . . . . . . . . . . . . 14
7.1.1. Request Network State TLV . . . . . . . . . . . . . . 13 7.1.1. Request Network State TLV . . . . . . . . . . . . . . 14
7.1.2. Request Node State TLV . . . . . . . . . . . . . . . 13 7.1.2. Request Node State TLV . . . . . . . . . . . . . . . 14
7.2. Data TLVs . . . . . . . . . . . . . . . . . . . . . . . . 14 7.2. Data TLVs . . . . . . . . . . . . . . . . . . . . . . . . 14
7.2.1. Node Endpoint TLV . . . . . . . . . . . . . . . . . . 14 7.2.1. Node Endpoint TLV . . . . . . . . . . . . . . . . . . 14
7.2.2. Network State TLV . . . . . . . . . . . . . . . . . . 14 7.2.2. Network State TLV . . . . . . . . . . . . . . . . . . 15
7.2.3. Node State TLV . . . . . . . . . . . . . . . . . . . 14 7.2.3. Node State TLV . . . . . . . . . . . . . . . . . . . 15
7.2.4. Custom TLV . . . . . . . . . . . . . . . . . . . . . 15 7.2.4. Custom TLV . . . . . . . . . . . . . . . . . . . . . 16
7.3. Data TLVs within Node State TLV . . . . . . . . . . . . . 16 7.3. Data TLVs within Node State TLV . . . . . . . . . . . . . 16
7.3.1. Fragment Count TLV . . . . . . . . . . . . . . . . . 16 7.3.1. Fragment Count TLV . . . . . . . . . . . . . . . . . 17
7.3.2. Neighbor TLV . . . . . . . . . . . . . . . . . . . . 16 7.3.2. Neighbor TLV . . . . . . . . . . . . . . . . . . . . 17
7.3.3. Keep-Alive Interval TLV . . . . . . . . . . . . . . . 17 7.3.3. Keep-Alive Interval TLV . . . . . . . . . . . . . . . 17
8. Security and Trust Management . . . . . . . . . . . . . . . . 18 8. Security and Trust Management . . . . . . . . . . . . . . . . 18
8.1. Pre-Shared Key Based Trust Method . . . . . . . . . . . . 18 8.1. Pre-Shared Key Based Trust Method . . . . . . . . . . . . 18
8.2. PKI Based Trust Method . . . . . . . . . . . . . . . . . 18 8.2. PKI Based Trust Method . . . . . . . . . . . . . . . . . 18
8.3. Certificate Based Trust Consensus Method . . . . . . . . 18 8.3. Certificate Based Trust Consensus Method . . . . . . . . 19
8.3.1. Trust Verdicts . . . . . . . . . . . . . . . . . . . 18 8.3.1. Trust Verdicts . . . . . . . . . . . . . . . . . . . 19
8.3.2. Trust Cache . . . . . . . . . . . . . . . . . . . . . 19 8.3.2. Trust Cache . . . . . . . . . . . . . . . . . . . . . 20
8.3.3. Announcement of Verdicts . . . . . . . . . . . . . . 20 8.3.3. Announcement of Verdicts . . . . . . . . . . . . . . 20
8.3.4. Bootstrap Ceremonies . . . . . . . . . . . . . . . . 21 8.3.4. Bootstrap Ceremonies . . . . . . . . . . . . . . . . 21
9. DNCP Profile-Specific Definitions . . . . . . . . . . . . . . 22 9. DNCP Profile-Specific Definitions . . . . . . . . . . . . . . 22
10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.1. Normative references . . . . . . . . . . . . . . . . . . 25 12.1. Normative references . . . . . . . . . . . . . . . . . . 25
12.2. Informative references . . . . . . . . . . . . . . . . . 25 12.2. Informative references . . . . . . . . . . . . . . . . . 25
Appendix A. Some Questions and Answers [RFC Editor: please Appendix A. Some Questions and Answers [RFC Editor: please
remove] . . . . . . . . . . . . . . . . . . . . . . 25 remove] . . . . . . . . . . . . . . . . . . . . . . 25
Appendix B. Changelog [RFC Editor: please remove] . . . . . . . 25 Appendix B. Changelog [RFC Editor: please remove] . . . . . . . 26
Appendix C. Draft Source [RFC Editor: please remove] . . . . . . 27 Appendix C. Draft Source [RFC Editor: please remove] . . . . . . 27
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 27 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
DNCP is designed to provide a way for nodes to publish data DNCP is designed to provide a way for nodes to publish data
consisting of an ordered set of TLV (Type-Length-Value) tuples and to consisting of an ordered set of TLV (Type-Length-Value) tuples and to
receive the data published by all other reachable DNCP nodes. receive the data published by all other reachable DNCP nodes.
skipping to change at page 3, line 49 skipping to change at page 3, line 49
[RFC6347] on top of UDP - is also required. [RFC6347] on top of UDP - is also required.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Terminology 3. Terminology
A DNCP profile is a definition of a set of rules and values listed in DNCP profile is a definition of a set of rules and values listed in
Section 9 specifying the behavior of a DNCP based protocol, such as Section 9 specifying the behavior of a DNCP based protocol, such as
the used transport method. For readability, any DNCP profile the used transport method. For readability, any DNCP profile
specific parameters with a profile-specific fixed value are prefixed specific parameters with a profile-specific fixed value are prefixed
with DNCP_. with DNCP_.
A DNCP node is a single node which runs a protocol based on a DNCP DNCP node is a single node which runs a protocol based on a DNCP
profile. profile.
The DNCP network is a set of DNCP nodes running the same DNCP profile DNCP network is a set of DNCP nodes running the same DNCP profile
that can reach each other, either via discovered connectivity in the that can reach each other, either via discovered connectivity in the
underlying network, or using each other's addresses learned via other underlying network, or using each other's addresses learned via other
means. As DNCP exchanges are bidirectional, DNCP nodes connected via means. As DNCP exchanges are bidirectional, DNCP nodes connected via
only unidirectional links are not considered connected. only unidirectional links are not considered connected.
A DNCP message is an abstract concept: when using a reliable stream DNCP message is an abstract concept: when using a reliable stream
transport, the whole stream of TLVs can be considered a single transport, the whole stream of TLVs can be considered a single
message, with new TLVs becoming one by one available once they have message, with new TLVs becoming one by one available once they have
been fully received. On a datagram transport, each individual been fully received. On a datagram transport, each individual
datagram is considered a separate message. datagram is considered a separate message.
The node identifier is an opaque fixed-length identifier consisting Node identifier is an opaque fixed-length identifier consisting of
of DNCP_NODE_IDENTIFIER_LENGTH bytes which uniquely identifies a DNCP DNCP_NODE_IDENTIFIER_LENGTH bytes which uniquely identifies a DNCP
node within a DNCP network. node within a DNCP network.
A link indicates a link-layer media over which directly connected Link indicates a link-layer media over which directly connected nodes
nodes can communicate. can communicate.
An interface indicates a port of a node that is connected to a Interface indicates a port of a node that is connected to a
particular link. particular link.
An endpoint denotes a locally configured use of DNCP on a DNCP node, Endpoint denotes a locally configured use of DNCP on a DNCP node. It
that is attached either to an interface, to a specific remote unicast is attached either to an interface, a specific remote unicast address
address to be contacted, or to a range of remote unicast addresses to be contacted, or a range of remote unicast addresses that are
that are allowed to contact. allowed to contact.
The endpoint identifier is a 32-bit opaque value, which identifies a Endpoint identifier is a 32-bit opaque value, which identifies a
particular endpoint of that particular DNCP node. The value 0 is particular endpoint of that particular DNCP node. The value 0 is
reserved for DNCP and sub-protocol purposes in the TLVs, and MUST NOT reserved for DNCP and sub-protocol purposes and MUST NOT be used to
be used to identify an actual endpoint. This definition is in sync identify an actual endpoint. This definition is in sync with the
with the interface index definition in [RFC3493], as the non-zero interface index definition in [RFC3493], as the non-zero small
small positive integers should comfortably fit within 32 bits. positive integers should comfortably fit within 32 bits.
A (DNCP) peer refers to another DNCP node with which a DNCP node (DNCP) peer refers to another DNCP node with which a DNCP node
communicates directly using a particular local and remote endpoint communicates directly using a particular local and remote endpoint
pair. pair.
The node data is a set of TLVs published by a node in the DNCP Node data is a set of TLVs published by a node in the DNCP network.
network. The whole node data is owned by the node that publishes it, The whole node data is owned by the node that publishes it, and it
and it MUST be passed along as-is, including TLVs unknown to the MUST be passed along as-is, including TLVs unknown to the forwarder.
forwarder.
The node state is a set of metadata attributes for node data. It Node state is a set of metadata attributes for node data. It
includes a sequence number for versioning, a hash value for comparing includes a sequence number for versioning, a hash value for comparing
and a timestamp indicating the time passed since its last and a timestamp indicating the time passed since its last
publication. The hash function and the number of bits used are publication. The hash function and the number of bits used are
defined in the DNCP profile. defined in the DNCP profile.
The network state (hash) is a hash value which represents the current Network state (hash) is a hash value which represents the current
state of the network. The hash function and the number of bits used state of the network. The hash function and the number of bits used
are defined in the DNCP profile. Whenever any node is added, removed are defined in the DNCP profile. Whenever a node is added, removed
or updates its published node data this hash value changes as well. or updates its published node data this hash value changes as well.
It is calculated over each reachable nodes' update number It is calculated over each reachable nodes' update number
concatenated with the hash value of its node data in ascending order concatenated with the hash value of its node data. For calculation
of the respective node identifier. these tuples are sorted in ascending order of the respective node's
node identifier.
The effective (trust) verdict for a certificate is defined as the (Trust) verdict is a statement about the trustworthiness of a
verdict with the highest priority within the set of verdicts certificate announced by a node participating in the certificate
announced for the certificate in the DNCP network. based trust consensus mechanism.
The neighbor graph is the undirected graph of DNCP nodes produced by Effective (trust) verdict for a certificate is defined as the verdict
with the highest priority within the set of verdicts announced for
the certificate in the DNCP network.
Neighbor graph is the undirected graph of DNCP nodes produced by
retaining only bidirectional peer relationships between nodes. retaining only bidirectional peer relationships between nodes.
4. Data Model 4. Data Model
A DNCP node has: A DNCP node has:
o A timestamp indicating the most recent neighbor graph traversal o A timestamp indicating the most recent neighbor graph traversal
described in Section 5.4. described in Section 5.4.
o Something with data about most recent request(s) for network state
- simplest one being a timestamp for the most recent request for
network state (see Section 5.2).
A DNCP node has for every DNCP node in the DNCP network: A DNCP node has for every DNCP node in the DNCP network:
o A node identifier, which uniquely identifies the node. o Node identifier, which uniquely identifies the node.
o The node data, an ordered set of TLV tuples published by that o Node data, an ordered set of TLV tuples published by that
particular node. This set of TLVs MUST use a well-defined order particular node. This set of TLVs MUST be strictly ordered based
based on ascending binary content (including TLV type and length). on ascending binary content (including TLV type and length). This
This facilitates linear time state delta processing. facilitates linear time state delta processing.
o The latest update sequence number, a 32 bit number that is o Latest update sequence number, a 32 bit number that is incremented
incremented any time the TLV set is published. For comparison any time the TLV set is published. For comparison purposes, a
purposes, a looping comparison should be used to avoid problems in looping comparison should be used to avoid problems in case of
case of overflow. An example would be: a < b <=> (a - b) % 2^32 & overflow. An example would be: a < b <=> (a - b) % 2^32 & 2^31 !=
2^31 != 0. 0.
o The relative time (in milliseconds) since the current TLV data set o Relative time (in milliseconds), time since the current TLV data
with the current update sequence number was published. It is also set with the current update sequence number was published. It is
a 32 bit number on the wire. If this number is close to overflow also a 32 bit number on the wire. If this number is close to
(greater than 2^32-2^16), a node MUST re-publish its TLVs even if overflow (greater than 2^32-2^16), a node MUST re-publish its TLVs
there is no change to avoid overflow of the value. In other even if there is no change. In other words, absent any other
words, absent any other changes, the TLV set MUST be re-published changes, the TLV set MUST be re-published roughly every 49 days.
roughly every 49 days.
o A timestamp identifying the time it was last reachable based on o Timestamp, the time it was last reachable based on neighbor graph
neighbor graph traversal described in Section 5.4. traversal described in Section 5.4.
Additionally, a DNCP node has a set of endpoints for which DNCP is Additionally, a DNCP node has a set of endpoints for which DNCP is
configured to be used. For each such endpoint, a node has: configured to be used. For each such endpoint, a node has:
o An endpoint identifier, a 32-bit opaque value. o An endpoint identifier, a 32-bit opaque value.
o An interface, a unicast address of a DNCP node it should connect o An interface, a unicast address of a DNCP node it should connect
with, or a range of addresses from which DNCP nodes are allowed to with, or a range of addresses from which DNCP nodes are allowed to
connect. connect.
skipping to change at page 6, line 42 skipping to change at page 6, line 50
The DNCP protocol consists of Trickle [RFC6206] driven unicast or The DNCP protocol consists of Trickle [RFC6206] driven unicast or
multicast status payloads which indicate the current status of shared multicast status payloads which indicate the current status of shared
TLV data and additional unicast exchanges which ensure DNCP peer TLV data and additional unicast exchanges which ensure DNCP peer
reachability and synchronize the data when necessary. reachability and synchronize the data when necessary.
If DNCP is to be used on a multicast-capable interface, as opposed to If DNCP is to be used on a multicast-capable interface, as opposed to
only point-to-point using unicast, a datagram-based transport which only point-to-point using unicast, a datagram-based transport which
supports multicast SHOULD be defined in the DNCP profile to be used supports multicast SHOULD be defined in the DNCP profile to be used
for the TLVs to be sent to the whole link. As this is used only to for the TLVs to be sent to the whole link. As this is used only to
identify potential new DNCP nodes and to notify that an unicast identify potential new DNCP nodes and to notify that a unicast
exchange should be triggered, the multicast transport does not have exchange should be triggered, the multicast transport does not have
to be particularly secure. to be particularly secure.
To form bidirectional peer relationships DNCP requires identification To form bidirectional peer relationships DNCP requires identification
of the endpoints used for communication. A DNCP node therefore MUST of the endpoints used for communication. A DNCP node therefore MUST
include an Endpoint TLV (Section 7.2.1) in each message intended to include an Endpoint TLV (Section 7.2.1) in each message intended to
maintain a DNCP peer relationship. maintain a DNCP peer relationship.
5.1. Trickle-Driven Status Updates 5.1. Trickle-Driven Status Updates
When employing unreliable transport, each node MUST send a Network When employing unreliable transport, each node MUST send a Network
State TLV (Section 7.2.2) every time the endpoint-specific Trickle State TLV (Section 7.2.2) every time the endpoint-specific Trickle
algorithm [RFC6206] instance indicates that an update should be sent. algorithm [RFC6206] instance indicates that an update should be sent.
Multicast MUST be employed on a multicast-capable interface; Multicast MUST be employed on a multicast-capable interface;
otherwise, unicast can be used as well. If possible, most recent, otherwise, unicast can be used as well. If possible, most recent,
recently changed, or best of all, all known Node State TLVs recently changed, or best of all, all known Node State TLVs
(Section 7.2.3) SHOULD be also included, unless it is defined as (Section 7.2.3) SHOULD be also included, unless it is defined as
undesirable for some reason by the DNCP profile. Avoiding sending undesirable for some reason by the DNCP profile. Avoiding sending
some or all Node State TLVs may make sense to avoid fragmenting some or all Node State TLVs may make sense to avoid fragmenting
packets to multicast destinations, or for security reasons. packets to multicast destinations, or for security reasons. If the
DNCP profile supports dense broadcast link optimization
(Section 6.2), and if a node does not have the highest node
identifier on a link, the endpoint may be in a unicast mode in which
multicast traffic is only listened to. In that mode, multicast
updates MUST NOT be sent.
A Trickle state MUST be maintained separately for each endpoint which A Trickle state MUST be maintained separately for each endpoint which
employs unreliable transport. The Trickle state for all endpoints is employs unreliable transport. The Trickle state for all endpoints is
considered inconsistent and reset if and only if the locally considered inconsistent and reset if and only if the locally
calculated network state hash changes. This occurs either due to a calculated network state hash changes. This occurs either due to a
change in the local node's own node data, or due to receipt of more change in the local node's own node data, or due to receipt of more
recent data from another node. recent data from another node.
The Trickle algorithm has 3 parameters: Imin, Imax and k. Imin and The Trickle algorithm has 3 parameters: Imin, Imax and k. Imin and
Imax represent the minimum and maximum values for I, which is the Imax represent the minimum and maximum values for I, which is the
skipping to change at page 7, line 44 skipping to change at page 8, line 8
This section describes how received TLVs are processed. The DNCP This section describes how received TLVs are processed. The DNCP
profile may specify criteria based on which particular TLVs are profile may specify criteria based on which particular TLVs are
ignored. Any 'reply' mentioned in the steps below denotes sending of ignored. Any 'reply' mentioned in the steps below denotes sending of
the specified TLV(s) via unicast to the originator of the TLV being the specified TLV(s) via unicast to the originator of the TLV being
processed. If the TLV being replied to was received via multicast processed. If the TLV being replied to was received via multicast
and it was sent to a link with shared bandwidth, the reply SHOULD be and it was sent to a link with shared bandwidth, the reply SHOULD be
delayed by a random timespan in [0, Imin/2]. Sending of replies delayed by a random timespan in [0, Imin/2]. Sending of replies
SHOULD be rate-limited by the implementation, and in case of excess SHOULD be rate-limited by the implementation, and in case of excess
load (or some other reason), a reply MAY be omitted altogether. load (or some other reason), a reply MAY be omitted altogether.
A DNCP node MUST reply to a request from any valid address, as
specified by a given DNCP profile, whether this address is known to
be the address of a neighbour 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.)
Upon receipt of: Upon receipt of:
o Request Network State TLV (Section 7.1.1): The receiver MUST reply 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 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 (Section 7.2.3) for each node data used to calculate the network
state hash. The Node State TLVs SHOULD NOT contain the optional state hash. The Node State TLVs SHOULD NOT contain the optional
node data part. node data part.
o Request Node State TLV (Section 7.1.2): If the receiver has node 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 data for the corresponding node, it MUST reply with a Node State
TLV (Section 7.2.3) for the corresponding node. The optional node TLV (Section 7.2.3) for the corresponding node. The optional node
data part MUST be included in the TLV. data part MUST be included in the TLV.
o Network State TLV (Section 7.2.2): If the network state hash o Network State TLV (Section 7.2.2): If the network state hash
differs from the locally calculated network state hash, and the differs from the locally calculated network state hash, and the
receiver is unaware of any particular node state differences with receiver is unaware of any particular node state differences with
the sender, the receiver MUST reply with a Request Network State the sender, the receiver MUST reply with a Request Network State
TLV (Section 7.1.1). The receiver MAY omit this, if there are TLV (Section 7.1.1). These replies MUST be rate limited to only
already recent pending requests for network or node state. 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 just sending at most one request for
network state per Imin. To facilitate faster state
synchronization, if a Request Network State TLV is sent in a
reply, a local, current Network State TLV SHOULD be also sent.
o Node State TLV (Section 7.2.3): o Node State TLV (Section 7.2.3):
* If the node identifier matches the local node identifier and * If the node identifier matches the local node identifier and
the TLV has a higher update sequence number than its current the TLV has a higher update sequence number than its current
local value, or the same update sequence number and a different local value, or the same update sequence number and a different
hash, the node SHOULD re-publish its own node data with an hash, the node SHOULD re-publish its own node data with an
update sequence number 1000 higher than the received one. This update sequence number 1000 higher than the received one. This
may occur normally once due to the local node restarting and may occur normally once due to the local node restarting and
not storing the most recently used update sequence number. If not storing the most recently used update sequence number. If
skipping to change at page 9, line 24 skipping to change at page 9, line 45
o If it comes via multicast, the node SHOULD be sent a (possibly o If it comes via multicast, the node SHOULD be sent a (possibly
rate-limited) unicast Request Network State TLV (Section 7.1.1). rate-limited) unicast Request Network State TLV (Section 7.1.1).
If keep-alives specified in Section 6.1 are NOT sent by the peer 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 (either the DNCP profile does not specify the use of keep-alives or
the particular peer chooses not to send keep-alives), some other the particular peer chooses not to send keep-alives), some other
means MUST be employed to ensure a DNCP peer is present. When the means MUST be employed to ensure a DNCP peer is present. When the
peer is no longer present, the Neighbor TLV and the local DNCP peer peer is no longer present, the Neighbor TLV and the local DNCP peer
state MUST be removed. state MUST be removed.
If the DNCP profile supports dense broadcast link optimization
(Section 6.2), and if a node does not have the highest node
identifier on a link, the endpoint may be in a unicast mode in which
multicast traffic is only listened to. In that mode, all peers
except the one with the highest node identifier MUST NOT have
Neighbor TLV (Section 7.3.2) published nor any local state.
5.4. Purging Unreachable Nodes 5.4. Purging Unreachable Nodes
DNCP validates the set of data within it by ensuring that it is
reachable via nodes that are currently accounted for; therefore,
unlike Time-To-Live (TTL) based solutions, it does not require
periodic re-publishing of the data by the nodes. On the other hand,
it does require the topology to be visible to every node that wants
to be able to identify unreachable nodes and therefore remove old,
stale data.
When a Neighbor TLV or a whole node is added or removed, the neighbor When a Neighbor TLV or a whole node is added or removed, the neighbor
graph SHOULD be traversed, starting from the local node. The edges graph SHOULD be traversed, starting from the local node. The edges
to be traversed are identified by looking for Neighbor TLVs on both to be traversed are identified by looking for Neighbor TLVs on both
nodes, that have the other node's identifier in the neighbor node nodes, that have the other node's identifier in the neighbor node
identifier, and local and neighbor endpoint identifiers swapped. identifier, and local and neighbor endpoint identifiers swapped.
Each node reached should be marked currently reachable. Each node reached should be marked currently reachable.
DNCP nodes MUST be either purged immediately when not marked DNCP nodes MUST be either purged immediately when not marked
reachable in a particular graph traversal, or eventually after they reachable in a particular graph traversal, or eventually after they
have not been marked reachable within DNCP_GRACE_INTERVAL. During have not been marked reachable within DNCP_GRACE_INTERVAL. During
skipping to change at page 12, line 8 skipping to change at page 12, line 43
react to nodes with a higher Node Identifier appearing. If the react to nodes with a higher Node Identifier appearing. If the
highest Node Identifier present on the link changes, the remote highest Node Identifier present on the link changes, the remote
unicast address of unicast endpoints MUST be changed. If the Node unicast address of unicast endpoints MUST be changed. If the Node
Identifier of the local node is the highest one, the node MUST keep Identifier of the local node is the highest one, the node MUST keep
the endpoint in multicast mode, and the node MUST allow others to the endpoint in multicast mode, and the node MUST allow others to
peer with it over the link via unicast as well. peer with it over the link via unicast as well.
6.3. Node Data Fragmentation 6.3. Node Data Fragmentation
A DNCP profile may be required to support node data which would not A DNCP profile may be required to support node data which would not
the fit maximum size of a single Node State TLV (Section 7.2.3) fit the maximum size of a single Node State TLV (Section 7.2.3)
(roughly 64KB of payload), or use a datagram-only transport with a (roughly 64KB of payload), or use a datagram-only transport with a
limited MTU and no reliable support for fragmentation. To handle limited MTU and no reliable support for fragmentation. To handle
such cases, a DNCP profile MAY specify a fixed number of trailing such cases, a DNCP profile MAY specify a fixed number of trailing
bytes in the Node Identifier to represent a fragment number bytes in the Node Identifier to represent a fragment number
indicating a part of a node's node data. The profile MAY also indicating a part of a node's node data. The profile MAY also
specify an upper bound for the size of a single fragment to specify an upper bound for the size of a single fragment to
accommodate limitations of links in the network. accommodate limitations of links in the network.
The data within Node State TLVs of fragments with non-zero fragment The data within Node State TLVs of fragments with non-zero fragment
number must be treated as opaque (as they may not contain even a number must be treated as opaque (as they may not contain even a
skipping to change at page 12, line 45 skipping to change at page 13, line 33
considered reachable if the fragment number 0 itself is reachable considered reachable if the fragment number 0 itself is reachable
based on graph traversal. based on graph traversal.
7. Type-Length-Value Objects 7. Type-Length-Value Objects
Each TLV is encoded as a 2 byte type field, followed by a 2 byte Each TLV is encoded as a 2 byte type field, followed by a 2 byte
length field (of the value, excluding header; 0 means no value) length field (of the value, excluding header; 0 means no value)
followed by the value itself (if any). Both type and length fields followed by the value itself (if any). Both type and length fields
in the header as well as all integer fields inside the value - unless in the header as well as all integer fields inside the value - unless
explicitly stated otherwise - are represented in network byte order. explicitly stated otherwise - are represented in network byte order.
Zero padding bytes MUST be added up to the next 4 byte boundary if Zeroed padding bytes MUST be added up to the next 4 byte boundary if
the length is not divisible by 4. These padding bytes MUST NOT be the length is not divisible by 4. These padding bytes MUST NOT be
included in the length field. included in the length field.
0 1 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | | Value |
| (variable # of bytes) | | (variable # of bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For example, type=123 (0x7b) TLV with value 'x' (120 = 0x78) is For example, type=123 (0x7b) TLV with value 'x' (120 = 0x78) is
encoded as: 007B 0001 7800 0000. encoded as: 007B 0001 7800 0000.
Notation: In this section, the following special notation is used:
.. = octet string concatenation operation. .. = octet string concatenation operation.
H(x) = non-cryptographic hash function specified by DNCP profile. H(x) = non-cryptographic hash function specified by DNCP profile.
7.1. Request TLVs 7.1. Request TLVs
7.1.1. Request Network State TLV 7.1.1. Request Network State TLV
0 1 2 3 0 1 2 3
skipping to change at page 13, line 49 skipping to change at page 14, line 33
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 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: REQ-NODE-STATE (2) | Length: >0 | | Type: REQ-NODE-STATE (2) | Length: >0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node Identifier | | Node Identifier |
| (length fixed in DNCP profile) | | (length fixed in DNCP profile) |
... ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV is used to request response with a Node State TLV This TLV is used to request a Node State TLV (Section 7.2.3)
(Section 7.2.3) for the node with matching node identifier which also (including node data) for the node with matching node identifier.
includes the node data.
7.2. Data TLVs 7.2. Data TLVs
7.2.1. Node Endpoint TLV 7.2.1. Node Endpoint TLV
0 1 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 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 | | Type: NODE-ENDPOINT (3) | Length: > 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 14, line 20 skipping to change at page 15, line 4
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 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 | | Type: NODE-ENDPOINT (3) | Length: > 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node Identifier | | Node Identifier |
| (length fixed in DNCP profile) | | (length fixed in DNCP profile) |
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Identifier | | Endpoint Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV identifies both the local node's node identifier, as well as This TLV identifies both the local node's node identifier, as well as
the particular endpoint's endpoint identifier. It MUST be sent in the particular endpoint's endpoint identifier. It MUST be sent in
every message if bidirectional peer relationship is desired with every message if bidirectional peer relationship is desired with
remote nodes on that endpoint. Bidirectional peer relationship is remote nodes on that endpoint. Bidirectional peer relationship is
not necessary for read-only access to the DNCP state, but it is not necessary for read-only access to the DNCP state, but it is
required to be able to publish something. required to be able to publish data.
7.2.2. Network State TLV 7.2.2. Network State TLV
0 1 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 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 | | Type: NETWORK-STATE (4) | Length: > 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| H(H(update number of node 1) .. H(node data of node 1) .. | | H(H(update number of node 1) .. H(node data of node 1) .. |
| .. H(update number of node N) .. H(node data of node N)) | | .. H(update number of node N) .. H(node data of node N)) |
| (length fixed in DNCP profile) | | (length fixed in DNCP profile) |
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV contains the current locally calculated network state hash. This TLV contains the current locally calculated network state hash.
It is calculated over each reachable nodes' update number It is calculated over each reachable nodes' update number
concatenated with the hash value of its node data in ascending order concatenated with the hash value of its node data in ascending order
of the respective node identifier. of the respective node identifiers.
7.2.3. Node State TLV 7.2.3. Node State TLV
0 1 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 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 | | Type: NODE-STATE (5) | Length: > 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node Identifier | | Node Identifier |
| (length fixed in DNCP profile) | | (length fixed in DNCP profile) |
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Update Sequence Number | | Update Sequence Number |
skipping to change at page 15, line 24 skipping to change at page 16, line 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Milliseconds since Origination | | Milliseconds since Origination |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| H(node data) | | H(node data) |
| (length fixed in DNCP profile) | | (length fixed in DNCP profile) |
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|(optionally) Nested TLVs containing node information | |(optionally) Nested TLVs containing node information |
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV represents the local node's knowledge about the published This TLV represents the local node's knowledge about the published
state of a node in the DNCP network identified by the node identifier state of a node in the DNCP network identified by the node identifier
field in the TLV. field in the TLV.
The whole network should have roughly same idea about the time since The whole network should have roughly the same idea about the time
origination of any particular published state. Therefore every node, since origination of any particular published state. Therefore every
including the originating one, MUST increment the time whenever it node, including the originating one, MUST increment the time whenever
needs to send a Node State TLV for already published node data. it needs to send a Node State TLV for already published node data.
The actual node data of the node may be included within the TLV as The actual node data of the node may be included within the TLV as
well; see Section 5.2 for the cases where it MUST or MUST NOT be well; see Section 5.2 for the cases where it MUST or MUST NOT be
included. In a DNCP profile which supports fragmentation, described included. In a DNCP profile which supports fragmentation, described
in Section 6.3, the TLV data may be only partial and not really in Section 6.3, the TLV data may be only partial and not really
usable without other fragments. usable without other fragments.
7.2.4. Custom TLV 7.2.4. Custom TLV
0 1 2 3 0 1 2 3
skipping to change at page 16, line 40 skipping to change at page 17, line 23
| (length fixed in DNCP profile) | | (length fixed in DNCP profile) |
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If the DNCP profile supports node data fragmentation as specified in If the DNCP profile supports node data fragmentation as specified in
Section 6.3, this TLV indicates that the node data is encoded as a Section 6.3, this TLV indicates that the node data is encoded as a
sequence of Node State TLVs. Following Node State TLVs with Node sequence of Node State TLVs. Following Node State TLVs with Node
Identifiers up to Count higher than the current one MUST be Identifiers up to Count higher than the current one MUST be
considered reachable and part of the same logical set of node data considered reachable and part of the same logical set of node data
that this TLV is within. The fragment portion of the Node Identifier that this TLV is within. The fragment portion of the Node Identifier
of the Node State TLV this is TLV appears in MUST be zeros. of the Node State TLV this TLV appears in MUST be zero.
7.3.2. Neighbor TLV 7.3.2. Neighbor TLV
0 1 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 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: NEIGHBOR (8) | Length: > 8 | | Type: NEIGHBOR (8) | Length: > 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| neighbor node identifier | | Neighbor Node Identifier |
| (length fixed in DNCP profile) | | (length fixed in DNCP profile) |
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Endpoint Identifier | | Neighbor Endpoint Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Endpoint Identifier | | Local Endpoint Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV indicates that the node in question vouches that the This TLV indicates that the node in question vouches that the
specified neighbor is reachable by it on the specified local specified neighbor is reachable by it on the specified local
skipping to change at page 22, line 30 skipping to change at page 22, line 41
8.3.4.4. Trust on First Use 8.3.4.4. Trust on First Use
A node which is not associated with any other DNCP node MAY trust the A node which is not associated with any other DNCP node MAY trust the
certificate of the first DNCP node it can successfully establish a certificate of the first DNCP node it can successfully establish a
connection with. This method MUST NOT be used when the node has connection with. This method MUST NOT be used when the node has
already associated with any other DNCP node. already associated with any other DNCP node.
9. DNCP Profile-Specific Definitions 9. DNCP Profile-Specific Definitions
Each DNCP profile MUST define following: Each DNCP profile MUST specify the following aspects:
o How the transport 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 Unicast and optionally multicast transport protocol(s) to be used. o Unicast and optionally multicast transport protocol(s) to be used.
If TLS scheme within this document is to be used security, TLS or
DTLS support for at least the unicast transport protocol is o How the chosen transport(s) are secured: Not at all, optionally or
mandatory. 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 Transport protocols' parameters such as port numbers to be used, o Transport protocols' parameters such as port numbers to be used,
or multicast address to be used. Unicast, multicast, and secure or multicast address to be used. Unicast, multicast, and secure
unicast may each require different parameters, if applicable. unicast may each require different parameters, if applicable.
o When receiving messages, what sort of messages are dropped, as o When receiving messages, what sort of messages are dropped, as
specified in Section 5.2. specified in Section 5.2.
o How to deal with node identifier collision as described in o How to deal with node identifier collision as described in
Section 5.2. Main options are either for one or both nodes to Section 5.2. Main options are either for one or both nodes to
assign new node identifiers to themselves, or to notify someone assign new node identifiers to themselves, or to notify someone
about a fatal error condition in the DNCP network. about a fatal error condition in the DNCP network.
o Imin, Imax and k ranges to be suggested for implementations to be o Imin, Imax and k ranges to be suggested for implementations to be
used in the Trickle algorithm. The Trickle algorithm does not used in the Trickle algorithm. The Trickle algorithm does not
require these to be same across all implementations for it to require these to be the same across all implementations for it to
work, but similar orders of magnitude helps implementations of a work, but similar orders of magnitude helps implementations of a
DNCP profile to behave more consistently and to facilitate DNCP profile to behave more consistently and to facilitate
estimation of lower and upper bounds for behavior of the network. estimation of lower and upper bounds for convergence behavior of
the network.
o Hash function H(x) to be used, and how many bits of the input are o Hash function H(x) to be used, and how many bits of the input are
actually used. The chosen hash function is used to handle both actually used. The chosen hash function is used to handle both
hashing of node specific data, and network state hash, which is a hashing of node specific data, and network state hash, which is a
hash of node specific data hashes. SHA-256 defined in [RFC6234] hash of node specific data hashes. SHA-256 defined in [RFC6234]
is the recommended default choice. is the recommended default choice.
o DNCP_NODE_IDENTIFIER_LENGTH: The fixed length of a node identifier o DNCP_NODE_IDENTIFIER_LENGTH: The fixed length of a node identifier
(in bytes). (in bytes).
skipping to change at page 25, line 41 skipping to change at page 26, line 4
Q: 32-bit endpoint id? Q: 32-bit endpoint id?
A: Here, it would save 32 bits per neighbor if it was 16 bits (and A: Here, it would save 32 bits per neighbor if it was 16 bits (and
less is not realistic). However, TLVs defined elsewhere would not less is not realistic). However, TLVs defined elsewhere would not
seem to even gain that much on average. 32 bits is also used for seem to even gain that much on average. 32 bits is also used for
ifindex in various operating systems, making for simpler ifindex in various operating systems, making for simpler
implementation. implementation.
Q: Why have topology information at all? Q: Why have topology information at all?
A: It is an alternative to the more traditional seq#/TTL-based A: It is an alternative to the more traditional seq#/TTL-based
flooding schemes. In steady state, there is no need to e.g. re- flooding schemes. In steady state, there is no need to e.g. re-
publish every now and then. publish every now and then.
Appendix B. Changelog [RFC Editor: please remove] Appendix B. Changelog [RFC Editor: please remove]
draft-ietf-homenet-dncp-04:
o Added mandatory rate limiting for network state requests, and
optional slightly faster convergence mechanism by including
current local network state in the remote network state requests.
draft-ietf-homenet-dncp-03: draft-ietf-homenet-dncp-03:
o Renamed connection -> endpoint. o Renamed connection -> endpoint.
o !!! Backwards incompatible change: Renumbered TLVs, and got rid of o !!! Backwards incompatible change: Renumbered TLVs, and got rid of
node data TLV; instead, node data TLV's contents are optionally node data TLV; instead, node data TLV's contents are optionally
within node state TLV. within node state TLV.
draft-ietf-homenet-dncp-02: draft-ietf-homenet-dncp-02:
 End of changes. 60 change blocks. 
111 lines changed or deleted 151 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/