draft-ietf-homenet-dncp-11.txt   draft-ietf-homenet-dncp-12.txt 
Homenet Working Group M. Stenberg Homenet Working Group M. Stenberg
Internet-Draft S. Barth Internet-Draft S. Barth
Intended status: Standards Track Independent Intended status: Standards Track Independent
Expires: April 16, 2016 October 14, 2015 Expires: May 5, 2016 November 2, 2015
Distributed Node Consensus Protocol Distributed Node Consensus Protocol
draft-ietf-homenet-dncp-11 draft-ietf-homenet-dncp-12
Abstract Abstract
This document describes the Distributed Node Consensus Protocol This document describes the Distributed Node Consensus Protocol
(DNCP), a generic state synchronization protocol that uses the (DNCP), a generic state synchronization protocol that uses the
Trickle algorithm and hash trees. DNCP is an abstract protocol, and Trickle algorithm and hash trees. DNCP is an abstract protocol, and
must be combined with a specific profile to make a complete must be combined with a specific profile to make a complete
implementable protocol. implementable protocol.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 April 16, 2016. This Internet-Draft will expire on May 5, 2016.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 7 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 8
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Hash Tree . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Hash Tree . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Calculating network state and node data hashes . . . 8 4.1.1. Calculating network state and node data hashes . . . 9
4.1.2. Updating network state and node data hashes . . . . . 9 4.1.2. Updating network state and node data hashes . . . . . 10
4.2. Data Transport . . . . . . . . . . . . . . . . . . . . . 9 4.2. Data Transport . . . . . . . . . . . . . . . . . . . . . 10
4.3. Trickle-Driven Status Updates . . . . . . . . . . . . . . 10 4.3. Trickle-Driven Status Updates . . . . . . . . . . . . . . 11
4.4. Processing of Received TLVs . . . . . . . . . . . . . . . 11 4.4. Processing of Received TLVs . . . . . . . . . . . . . . . 12
4.5. Discovering, Adding and Removing Peers . . . . . . . . . 14 4.5. Discovering, Adding and Removing Peers . . . . . . . . . 15
4.6. Data Liveliness Validation . . . . . . . . . . . . . . . 15 4.6. Data Liveliness Validation . . . . . . . . . . . . . . . 16
5. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 16 5. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Optional Extensions . . . . . . . . . . . . . . . . . . . . . 17 6. Optional Extensions . . . . . . . . . . . . . . . . . . . . . 19
6.1. Keep-Alives . . . . . . . . . . . . . . . . . . . . . . . 18 6.1. Keep-Alives . . . . . . . . . . . . . . . . . . . . . . . 19
6.1.1. Data Model Additions . . . . . . . . . . . . . . . . 18 6.1.1. Data Model Additions . . . . . . . . . . . . . . . . 19
6.1.2. Per-Endpoint Periodic Keep-Alives . . . . . . . . . . 19 6.1.2. Per-Endpoint Periodic Keep-Alives . . . . . . . . . . 20
6.1.3. Per-Peer Periodic Keep-Alives . . . . . . . . . . . . 19 6.1.3. Per-Peer Periodic Keep-Alives . . . . . . . . . . . . 20
6.1.4. Received TLV Processing Additions . . . . . . . . . . 19 6.1.4. Received TLV Processing Additions . . . . . . . . . . 20
6.1.5. Peer Removal . . . . . . . . . . . . . . . . . . . . 19 6.1.5. Peer Removal . . . . . . . . . . . . . . . . . . . . 20
6.2. Support For Dense Multicast-Enabled Links . . . . . . . . 20 6.2. Support For Dense Multicast-Enabled Links . . . . . . . . 21
7. Type-Length-Value Objects . . . . . . . . . . . . . . . . . . 21 7. Type-Length-Value Objects . . . . . . . . . . . . . . . . . . 22
7.1. Request TLVs . . . . . . . . . . . . . . . . . . . . . . 22 7.1. Request TLVs . . . . . . . . . . . . . . . . . . . . . . 23
7.1.1. Request Network State TLV . . . . . . . . . . . . . . 22 7.1.1. Request Network State TLV . . . . . . . . . . . . . . 23
7.1.2. Request Node State TLV . . . . . . . . . . . . . . . 22 7.1.2. Request Node State TLV . . . . . . . . . . . . . . . 23
7.2. Data TLVs . . . . . . . . . . . . . . . . . . . . . . . . 22 7.2. Data TLVs . . . . . . . . . . . . . . . . . . . . . . . . 23
7.2.1. Node Endpoint TLV . . . . . . . . . . . . . . . . . . 22 7.2.1. Node Endpoint TLV . . . . . . . . . . . . . . . . . . 23
7.2.2. Network State TLV . . . . . . . . . . . . . . . . . . 23 7.2.2. Network State TLV . . . . . . . . . . . . . . . . . . 24
7.2.3. Node State TLV . . . . . . . . . . . . . . . . . . . 23 7.2.3. Node State TLV . . . . . . . . . . . . . . . . . . . 24
7.3. Data TLVs within Node State TLV . . . . . . . . . . . . . 24 7.3. Data TLVs within Node State TLV . . . . . . . . . . . . . 25
7.3.1. Peer TLV . . . . . . . . . . . . . . . . . . . . . . 24 7.3.1. Peer TLV . . . . . . . . . . . . . . . . . . . . . . 25
7.3.2. Keep-Alive Interval TLV . . . . . . . . . . . . . . . 25 7.3.2. Keep-Alive Interval TLV . . . . . . . . . . . . . . . 26
8. Security and Trust Management . . . . . . . . . . . . . . . . 25 8. Security and Trust Management . . . . . . . . . . . . . . . . 26
8.1. Pre-Shared Key Based Trust Method . . . . . . . . . . . . 25 8.1. Pre-Shared Key Based Trust Method . . . . . . . . . . . . 26
8.2. PKI Based Trust Method . . . . . . . . . . . . . . . . . 26 8.2. PKI Based Trust Method . . . . . . . . . . . . . . . . . 27
8.3. Certificate Based Trust Consensus Method . . . . . . . . 26 8.3. Certificate Based Trust Consensus Method . . . . . . . . 27
8.3.1. Trust Verdicts . . . . . . . . . . . . . . . . . . . 26 8.3.1. Trust Verdicts . . . . . . . . . . . . . . . . . . . 27
8.3.2. Trust Cache . . . . . . . . . . . . . . . . . . . . . 27 8.3.2. Trust Cache . . . . . . . . . . . . . . . . . . . . . 28
8.3.3. Announcement of Verdicts . . . . . . . . . . . . . . 28 8.3.3. Announcement of Verdicts . . . . . . . . . . . . . . 29
8.3.4. Bootstrap Ceremonies . . . . . . . . . . . . . . . . 29 8.3.4. Bootstrap Ceremonies . . . . . . . . . . . . . . . . 30
9. DNCP Profile-Specific Definitions . . . . . . . . . . . . . . 30 9. DNCP Profile-Specific Definitions . . . . . . . . . . . . . . 31
10. Security Considerations . . . . . . . . . . . . . . . . . . . 31 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
12.1. Normative references . . . . . . . . . . . . . . . . . . 33 12.1. Normative references . . . . . . . . . . . . . . . . . . 34
12.2. Informative references . . . . . . . . . . . . . . . . . 33 12.2. Informative references . . . . . . . . . . . . . . . . . 34
Appendix A. Alternative Modes of Operation . . . . . . . . . . . 34 Appendix A. Alternative Modes of Operation . . . . . . . . . . . 35
A.1. Read-only Operation . . . . . . . . . . . . . . . . . . . 34 A.1. Read-only Operation . . . . . . . . . . . . . . . . . . . 35
A.2. Forwarding Operation . . . . . . . . . . . . . . . . . . 34 A.2. Forwarding Operation . . . . . . . . . . . . . . . . . . 35
Appendix B. DNCP Profile Additional Guidance . . . . . . . . . . 34 Appendix B. DNCP Profile Additional Guidance . . . . . . . . . . 36
B.1. Unicast Transport - UDP or TCP? . . . . . . . . . . . . . 34 B.1. Unicast Transport - UDP or TCP? . . . . . . . . . . . . . 36
B.2. (Optional) Multicast Transport . . . . . . . . . . . . . 35 B.2. (Optional) Multicast Transport . . . . . . . . . . . . . 36
B.3. (Optional) Transport Security . . . . . . . . . . . . . . 35 B.3. (Optional) Transport Security . . . . . . . . . . . . . . 37
Appendix C. Example Profile . . . . . . . . . . . . . . . . . . 36 Appendix C. Example Profile . . . . . . . . . . . . . . . . . . 37
Appendix D. Some Questions and Answers [RFC Editor: please Appendix D. Some Questions and Answers [RFC Editor: please
remove] . . . . . . . . . . . . . . . . . . . . . . 37 remove] . . . . . . . . . . . . . . . . . . . . . . 38
Appendix E. Changelog [RFC Editor: please remove] . . . . . . . 37 Appendix E. Changelog [RFC Editor: please remove] . . . . . . . 38
Appendix F. Draft Source [RFC Editor: please remove] . . . . . . 39 Appendix F. Draft Source [RFC Editor: please remove] . . . . . . 40
Appendix G. Acknowledgements . . . . . . . . . . . . . . . . . . 39 Appendix G. Acknowledgements . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
DNCP is designed to provide a way for each participating node to 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 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 KB), and to provide a shared and common view about the data published
by every currently bidirectionally reachable DNCP node in a network. by every currently bidirectionally reachable DNCP node in a network.
For state synchronization a hash tree is used. It is formed by first For state synchronization a hash tree is used. It is formed by first
calculating a hash for the dataset published by each node, called calculating a hash for the dataset published by each node, called
skipping to change at page 3, line 51 skipping to change at page 3, line 51
of ensuring reachability are used. The core idea is that if every of ensuring reachability are used. The core idea is that if every
node ensures its peers are present, transitively, the whole network node ensures its peers are present, transitively, the whole network
state also stays up-to-date. state also stays up-to-date.
1.1. Applicability 1.1. Applicability
DNCP is useful for cases like autonomous bootstrapping, discovery and DNCP is useful for cases like autonomous bootstrapping, discovery and
negotiation of embedded network devices like routers. Furthermore it negotiation of embedded network devices like routers. Furthermore it
can be used as a basis to run distributed algorithms like can be used as a basis to run distributed algorithms like
[I-D.ietf-homenet-prefix-assignment] or usecases as described in [I-D.ietf-homenet-prefix-assignment] or usecases as described in
Appendix C. The topology of the devices is not limited and Appendix C. DNCP is abstract, which allows it to be tuned to a
automatically discovered. If globally scoped addresses are used, variety of applications by defining profiles. These profiles include
DNCP peers do not necessarily need to be on the same link. choices of:
- unicast transport: datagram or stream oriented protocol (e.g.,
TCP, UDP, SCTP) for generic protocol operation
- optional transport security: whether and when to use security
based on (D)TLS, if supported over the chosen transport
- optional multicast transport: multicast-capable protocol like UDP
allowing autonomous peer discovery or more efficient use of
multiple access links
- communication scopes: either hop-by-hop only relying on link-local
addressing (e.g., for LANs) or using 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)
- payloads: additional specific payloads (e.g., IANA standardized,
enterprise-specific or private use)
- extensions: possible protocol extensions, either as predefined in
this document or specific for a particular usecase
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 64KB of published data
- 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.
- large amounts of very constrained nodes: DNCP requires each node
to store the entirety of the data published by all nodes.
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 Autonomous discovery features are usually used in local network
scenario however - with security enabled - DNCP can also be used over scenario however - with security enabled - DNCP can also be used over
unsecured public networks. Network size is restricted merely by the unsecured public networks. Network size is restricted merely by the
capabilities of the devices, i.e., each DNCP node needs to be able to capabilities of the devices, i.e., each DNCP node needs to be able to
store the entirety of the data published by all nodes. store the entirety of the data published by all nodes. The data
associated with each individual node identifier is limited to about
64KB in this document, however protocol extensions could be defined
to mitigate this or other protocol limitations if the need arises.
DNCP is most suitable for data that changes only infrequently to gain DNCP is most suitable for data that changes only infrequently to gain
the maximum benefit from using Trickle. As the network of nodes the maximum benefit from using Trickle. As the network of nodes
grows, or the frequency of data changes per node increases, Trickle grows, or the frequency of data changes per node increases, Trickle
is eventually used less and less and the benefit of using DNCP is eventually used less and less and the benefit of using DNCP
diminishes. In these cases Trickle just provides extra complexity diminishes. In these cases Trickle just provides extra complexity
within the specification and little added value. within the specification and little added value.
The suitability of DNCP for a particular application can roughly be The suitability of DNCP for a particular application can roughly be
evaluated by considering the expected average network-wide state evaluated by considering the expected average network-wide state
skipping to change at page 6, line 10 skipping to change at page 7, line 15
Endpoint a 32-bit opaque and locally unique value, which Endpoint a 32-bit opaque and locally unique value, which
identifier identifies a particular endpoint of a particular identifier identifies a particular endpoint of a particular
DNCP node. The value 0 is reserved for DNCP and DNCP node. The value 0 is reserved for DNCP and
DNCP-based protocol purposes and not used to DNCP-based protocol purposes and not used to
identify an actual endpoint. This definition is in identify an actual endpoint. This definition is in
sync with the interface index definition in sync with the interface index definition in
[RFC3493], as the non-zero small positive integers [RFC3493], as the non-zero small positive integers
should comfortably fit within 32 bits. should comfortably fit within 32 bits.
Peer another DNCP node with which a DNCP node Peer another DNCP node with which a DNCP node
communicates using a particular local and remote communicates using at least one particular local
endpoint pair. and remote endpoint pair.
Node data a set of TLVs published and owned by a node in the Node data a set of TLVs published and owned by a node in the
DNCP network. Other nodes pass it along as-is, even DNCP network. Other nodes pass it along as-is, even
if they cannot fully interpret it. if they cannot fully interpret it.
Origination Time the (estimated) time when the node data set with Origination Time the (estimated) time when the node data set with
the current sequence number was published. the current sequence number was published.
Node state a set of metadata attributes for node data. It Node state a set of metadata attributes for node data. It
includes a sequence number for versioning, a hash includes a sequence number for versioning, a hash
skipping to change at page 10, line 22 skipping to change at page 11, line 26
detection. detection.
Given the assorted transport options as well as potential endpoint Given the assorted transport options as well as potential endpoint
configuration, a DNCP endpoint may be used in various transport configuration, a DNCP endpoint may be used in various transport
modes: modes:
Unicast: Unicast:
* If only reliable unicast transport is used, Trickle is not used * If only reliable unicast transport is used, Trickle is not used
at all. Whenever the locally calculated network state hash at all. Whenever the locally calculated network state hash
changes, a single Network State TLV (Section 7.2.2) is sent changes, a single Network State TLV (Section 7.2.2) is sent to
instead to every unicast peer. Additionally, recently changed every unicast peer. Additionally, recently changed Node State
Node State TLVs (Section 7.2.3) MAY be included. TLVs (Section 7.2.3) MAY be included.
* If only unreliable unicast transport is used, Trickle state is * If only unreliable unicast transport is used, Trickle state is
kept per peer and it is used to send Network State TLVs kept per peer and it is used to send Network State TLVs
intermittently, as specified in Section 4.3. intermittently, as specified in Section 4.3.
Multicast+Unicast: If multicast datagram transport is available on Multicast+Unicast: If multicast datagram transport is available on
an endpoint, Trickle state is only maintained for the endpoint as an endpoint, Trickle state is only maintained for the endpoint as
a whole. It is used to send Network State TLVs periodically, as a whole. It is used to send Network State TLVs periodically, as
specified in Section 4.3. Additionally, per-endpoint keep-alives specified in Section 4.3. Additionally, per-endpoint keep-alives
MAY be defined in the DNCP profile, as specified in Section 6.1.2. MAY be defined in the DNCP profile, as specified in Section 6.1.2.
skipping to change at page 14, line 8 skipping to change at page 15, line 10
For comparison purposes of the sequence number, a looping For comparison purposes of the sequence number, a looping
comparison function MUST be used to avoid problems in case of comparison function MUST be used to avoid problems in case of
overflow. The comparison function a < b <=> ((a - b) % (2^32)) & overflow. The comparison function a < b <=> ((a - b) % (2^32)) &
(2^31) != 0 where (a % b) represents the remainder of a modulo b (2^31) != 0 where (a % b) represents the remainder of a modulo b
and (a & b) represents bitwise conjunction of a and b is and (a & b) represents bitwise conjunction of a and b is
RECOMMENDED unless the DNCP profile defines another. RECOMMENDED unless the DNCP profile defines another.
o Any other TLV: TLVs not recognized by the receiver MUST be o Any other TLV: TLVs not recognized by the receiver MUST be
silently ignored unless they are sent within another TLV (for silently ignored unless they are sent within another TLV (for
example, TLVs within the Node Data field of a Node State TLV). 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 calculating the node data hash as described in
Section 7.2.3 but are ignored for other purposes.
If secure unicast transport is configured for an endpoint, any Node If secure unicast transport is configured for an endpoint, any Node
State TLVs received over insecure multicast MUST be silently ignored. State TLVs received over insecure multicast MUST be silently ignored.
4.5. Discovering, Adding and Removing Peers 4.5. Discovering, Adding and Removing Peers
Peer relations are established between neighbors using one or more Peer relations are established between neighbors using one or more
mutually connected endpoints. Such neighbors exchange information mutually connected endpoints. Such neighbors exchange information
about network state and published data directly and through about network state and published data directly and through
transitivity this information then propagates throughout the network. transitivity this information then propagates throughout the network.
skipping to change at page 18, line 46 skipping to change at page 19, line 51
o Last sent: If a timestamp which indicates the last time a Network o Last sent: If a timestamp which indicates the last time a Network
State TLV (Section 7.2.2) was sent over that interface. State TLV (Section 7.2.2) was sent over that interface.
For each remote (peer, endpoint) pair detected on a local endpoint, a For each remote (peer, endpoint) pair detected on a local endpoint, a
DNCP node has: DNCP node has:
o Last contact timestamp: a timestamp which indicates the last time o Last contact timestamp: a timestamp which indicates the last time
a consistent Network State TLV (Section 7.2.2) was received from a consistent Network State TLV (Section 7.2.2) was received from
the peer over multicast, or anything was received over unicast. the peer over multicast, or anything was received over unicast.
Failing to updated it for a certain amount of time as specified in 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 Section 6.1.5 results in the removal of the peer. When adding a
new peer, it is initialized to the current time. new peer, it is initialized to the current time.
o Last sent: If per-peer keep-alives are enabled, a timestamp which o Last sent: If per-peer keep-alives are enabled, a timestamp which
indicates the last time a Network State TLV (Section 7.2.2) was indicates the last time a Network State TLV (Section 7.2.2) was
sent to to that point-to-point peer. When adding a new peer, it sent to to that point-to-point peer. When adding a new peer, it
is initialized to the current time. is initialized to the current time.
6.1.2. Per-Endpoint Periodic Keep-Alives 6.1.2. Per-Endpoint Periodic Keep-Alives
skipping to change at page 23, line 21 skipping to change at page 24, line 21
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(sequence number of node 1 .. H(node data of node 1) .. | | H(sequence number of node 1 .. H(node data of node 1) .. |
| .. sequence number of node N .. H(node data of node N)) | | .. sequence 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 network state hash calculated by its
see Section 4.1 for how it is calculated. sender (Section 4.1 describes the algorithm).
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) |
skipping to change at page 31, line 15 skipping to change at page 32, line 15
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 the 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 convergence behavior of estimation of lower and upper bounds for convergence behavior of
the network. the network.
o Hash function H(x) to be used, and how many bits of the output are 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 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 data, and to produce network state hash, which is
hash of node specific data hashes. SHA-256 defined in [RFC6234] a hash of node data hashes. SHA-256 defined in [RFC6234] is the
is the recommended default choice, but a non-cryptographic hash recommended default choice, but a non-cryptographic hash function
function could be used as well. 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 that they are up to date, but 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
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 o DNCP_NODE_IDENTIFIER_LENGTH: The fixed length of a node identifier
(in bytes). (in bytes).
o Whether to send keep-alives, and if so, whether per-endpoint o Whether to send keep-alives, and if so, whether per-endpoint
(requires multicast transport), or per-peer. Keep-alive has also (requires multicast transport), or per-peer. Keep-alive has also
associated parameters: associated parameters:
* DNCP_KEEPALIVE_INTERVAL: How often keep-alives are to be sent * DNCP_KEEPALIVE_INTERVAL: How often keep-alives are to be sent
by default (if enabled). by default (if enabled).
skipping to change at page 33, line 14 skipping to change at page 34, line 23
768-1023: Private use [RFC5226] 768-1023: Private use [RFC5226]
1024-65535: Reserved for future protocol evolution (for example, 1024-65535: Reserved for future protocol evolution (for example,
DNCP version 2) DNCP version 2)
12. References 12. References
12.1. Normative references 12.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
"The Trickle Algorithm", RFC 6206, March 2011. "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206,
March 2011, <http://www.rfc-editor.org/info/rfc6206>.
[RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI
10.17487/RFC6234, May 2011,
<http://www.rfc-editor.org/info/rfc6234>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
12.2. Informative references 12.2. Informative references
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6", RFC Stevens, "Basic Socket Interface Extensions for IPv6", RFC
3493, February 2003. 3493, DOI 10.17487/RFC3493, February 2003,
<http://www.rfc-editor.org/info/rfc3493>.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
and M. Carney, "Dynamic Host Configuration Protocol for C., and M. Carney, "Dynamic Host Configuration Protocol
IPv6 (DHCPv6)", RFC 3315, July 2003. for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012. Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/
RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, DOI 10.17487/RFC7435, Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <http://www.rfc-editor.org/info/rfc7435>. December 2014, <http://www.rfc-editor.org/info/rfc7435>.
[I-D.ietf-homenet-prefix-assignment] [I-D.ietf-homenet-prefix-assignment]
Pfister, P., Paterson, B., and J. Arkko, "Distributed Pfister, P., Paterson, B., and J. Arkko, "Distributed
Prefix Assignment Algorithm", draft-ietf-homenet-prefix- Prefix Assignment Algorithm", draft-ietf-homenet-prefix-
assignment-08 (work in progress), August 2015. assignment-08 (work in progress), August 2015.
 End of changes. 20 change blocks. 
88 lines changed or deleted 166 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/