draft-ietf-homenet-dncp-02.txt   draft-ietf-homenet-dncp-03.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 24, 2015 Expires: October 26, 2015
April 22, 2015 April 24, 2015
Distributed Node Consensus Protocol Distributed Node Consensus Protocol
draft-ietf-homenet-dncp-02 draft-ietf-homenet-dncp-03
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 24, 2015. This Internet-Draft will expire on October 26, 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
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
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Trickle-Driven Status Update Messages . . . . . . . . . . 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 . . . . . . . . . . . . . . . . 9
6. Optional Extensions . . . . . . . . . . . . . . . . . . . . . 9 6. Optional Extensions . . . . . . . . . . . . . . . . . . . . . 9
6.1. Keep-Alives . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Keep-Alives . . . . . . . . . . . . . . . . . . . . . . . 9
6.1.1. Data Model Additions . . . . . . . . . . . . . . . . 10 6.1.1. Data Model Additions . . . . . . . . . . . . . . . . 10
6.1.2. Per-Connection Periodic Keep-Alives . . . . . . . . . 10 6.1.2. Per-Endpoint Periodic Keep-Alives . . . . . . . . . . 10
6.1.3. Per-Peer Periodic Keep-Alives . . . . . . . . . . . . 11 6.1.3. Per-Peer Periodic Keep-Alives . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . 11
6.2. Support For Dense Broadcast Links . . . . . . . . . . . . 11 6.2. Support For Dense Broadcast Links . . . . . . . . . . . . 11
6.3. Node Data Fragmentation . . . . . . . . . . . . . . . . . 12 6.3. Node Data Fragmentation . . . . . . . . . . . . . . . . . 12
7. Type-Length-Value Objects . . . . . . . . . . . . . . . . . . 12 7. Type-Length-Value Objects . . . . . . . . . . . . . . . . . . 12
7.1. Request TLVs . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Request TLVs . . . . . . . . . . . . . . . . . . . . . . 13
7.1.1. Request Network State TLV . . . . . . . . . . . . . . 13 7.1.1. Request Network State TLV . . . . . . . . . . . . . . 13
7.1.2. Request Node Data TLV . . . . . . . . . . . . . . . . 13 7.1.2. Request Node State TLV . . . . . . . . . . . . . . . 13
7.2. Data TLVs . . . . . . . . . . . . . . . . . . . . . . . . 14 7.2. Data TLVs . . . . . . . . . . . . . . . . . . . . . . . . 14
7.2.1. Node Connection TLV . . . . . . . . . . . . . . . . . 14 7.2.1. Node Endpoint TLV . . . . . . . . . . . . . . . . . . 14
7.2.2. Network State TLV . . . . . . . . . . . . . . . . . . 14 7.2.2. Network State TLV . . . . . . . . . . . . . . . . . . 14
7.2.3. Node State TLV . . . . . . . . . . . . . . . . . . . 14 7.2.3. Node State TLV . . . . . . . . . . . . . . . . . . . 14
7.2.4. Node Data TLV . . . . . . . . . . . . . . . . . . . . 15 7.2.4. Custom TLV . . . . . . . . . . . . . . . . . . . . . 15
7.2.5. Custom TLV . . . . . . . . . . . . . . . . . . . . . 16 7.3. Data TLVs within Node State TLV . . . . . . . . . . . . . 16
7.3. Data TLVs within Node Data TLV . . . . . . . . . . . . . 16
7.3.1. Fragment Count TLV . . . . . . . . . . . . . . . . . 16 7.3.1. Fragment Count TLV . . . . . . . . . . . . . . . . . 16
7.3.2. Neighbor TLV . . . . . . . . . . . . . . . . . . . . 17 7.3.2. Neighbor TLV . . . . . . . . . . . . . . . . . . . . 16
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 . . . . . . . . 18
8.3.1. Trust Verdicts . . . . . . . . . . . . . . . . . . . 18 8.3.1. Trust Verdicts . . . . . . . . . . . . . . . . . . . 18
8.3.2. Trust Cache . . . . . . . . . . . . . . . . . . . . . 19 8.3.2. Trust Cache . . . . . . . . . . . . . . . . . . . . . 19
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 . . . . . . . . . . . . . . . . . . . 23
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] . . . . . . . 26 Appendix B. Changelog [RFC Editor: please remove] . . . . . . . 25
Appendix C. Draft Source [RFC Editor: please remove] . . . . . . 26 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.
DNCP validates the set of data within it by ensuring that it is DNCP validates the set of data within it by ensuring that it is
skipping to change at page 4, line 22 skipping to change at page 4, line 16
A DNCP node is a single node which runs a protocol based on a DNCP A 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 The 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
transport, the whole stream of TLVs can be considered a single
message, with new TLVs becoming one by one available once they have
been fully received. On a datagram transport, each individual
datagram is considered a separate message.
The node identifier is an opaque fixed-length identifier consisting The node identifier is an opaque fixed-length identifier consisting
of DNCP_NODE_IDENTIFIER_LENGTH bytes which uniquely identifies a DNCP of 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 A link indicates a link-layer media over which directly connected
nodes can communicate. nodes can communicate.
An interface indicates a port of a node that is connected to a An interface indicates a port of a node that is connected to a
particular link. particular link.
A connection denotes a locally configured use of DNCP on a DNCP node, An endpoint denotes a locally configured use of DNCP on a DNCP node,
that is attached either to an interface, to a specific remote unicast that is attached either to an interface, to a specific remote unicast
address to be contacted, or to a range of remote unicast addresses address to be contacted, or to a range of remote unicast addresses
that are allowed to contact. that are allowed to contact.
The connection identifier is a 32-bit opaque value, which identifies The endpoint identifier is a 32-bit opaque value, which identifies a
a particular connection 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 in the TLVs, and MUST NOT
be used to identify an actual connection. This definition is in sync be used to identify an actual endpoint. This definition is in sync
with [RFC3493], as the non-zero small positive integers should with the interface index definition in [RFC3493], as the non-zero
comfortably fit within 32 bits. small positive integers should comfortably fit within 32 bits.
A (DNCP) peer refers to another DNCP node with which a DNCP node A (DNCP) peer refers to another DNCP node with which a DNCP node
communicates directly using a particular local and remote connection 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 The node data is a set of TLVs published by a node in the DNCP
network. The whole node data is owned by the node that publishes it, network. The whole node data is owned by the node that publishes it,
and it MUST be passed along as-is, including TLVs unknown to the and it 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 The 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 The 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 any node is added, removed
or changes 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 the hash values of each reachable nodes' node It is calculated over each reachable nodes' update number
data in ascending order of the respective node identifier. concatenated with the hash value of its node data in ascending order
of the respective node identifier.
The effective (trust) verdict for a certificate is defined as the The effective (trust) verdict for a certificate is defined as the
verdict with the highest priority within the set of verdicts verdict with the highest priority within the set of verdicts
announced for the certificate in the DNCP network. announced for the certificate in the DNCP network.
The neighbor graph is the undirected graph of DNCP nodes produced by The 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.
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 A node identifier, which uniquely identifies the node.
o The node data, an ordered set of TLV tuples published by that o The node data, an ordered set of TLV tuples published by that
particular node. This set of TLVs has a well-defined order based particular node. This set of TLVs MUST use a well-defined order
on ascending binary content (including TLV type and length). This based on ascending binary content (including TLV type and length).
facilitates linear time state delta processing. This facilitates linear time state delta processing.
o The latest update sequence number, a 32 bit number that is o The latest update sequence number, a 32 bit number that is
incremented any time the TLV set is published. For comparison incremented any time the TLV set is published. For comparison
purposes, a looping comparison should be used to avoid problems in purposes, a looping comparison should be used to avoid problems in
case of overflow. An example would be: a < b <=> (a - b) % 2^32 & case of overflow. An example would be: a < b <=> (a - b) % 2^32 &
2^31 != 0. 2^31 != 0.
o The relative time (in milliseconds) since the current TLV data set o The relative time (in milliseconds) since the current TLV data set
with the current update sequence number was published. It is also with the current update sequence number was published. It is also
a 32 bit number on the wire. If this number is close to overflow a 32 bit number on the wire. If this number is close to overflow
(greater than 2^32-2^16), a node MUST re-publish its TLVs even if (greater than 2^32-2^16), a node MUST re-publish its TLVs even if
there is no change to avoid overflow of the value. In other there is no change to avoid overflow of the value. In other
words, absent any other changes, the TLV set MUST be re-published words, absent any other 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 A timestamp identifying the time it was last reachable based on
neighbor graph traversal described in Section 5.4. neighbor graph traversal described in Section 5.4.
Additionally, a DNCP node has a set of connections for which DNCP is Additionally, a DNCP node has a set of endpoints for which DNCP is
configured to be used. For each such connection, a node has: configured to be used. For each such endpoint, a node has:
o A connection identifier. 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.
o A Trickle [RFC6206] instance with parameters I, T, and c. o A Trickle [RFC6206] instance with parameters I, T, and c.
For each remote (DNCP node,connection) pair detected on a particular For each remote (DNCP node, endpoint) pair detected on a local
connection, a DNCP node has: endpoint, a DNCP node has:
o The node identifier of the DNCP peer. o The node identifier of the DNCP peer.
o The connection identifier of the DNCP peer. o The endpoint identifier of the DNCP peer.
o The most recent address used by the DNCP peer (in an authenticated o The most recent address used by the DNCP peer (authenticated and
message, if security is enabled). authorized, if security is enabled).
5. Operation 5. Operation
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 an 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.
A DNCP message in and of itself is just an abstraction; when using To form bidirectional peer relationships DNCP requires identification
reliable stream transport, the whole stream of TLVs can be considered of the endpoints used for communication. A DNCP node therefore MUST
a single message, with new TLVs becoming gradually available once include an Endpoint TLV (Section 7.2.1) in each message intended to
they have been fully received. On datagram transport, each maintain a DNCP peer relationship.
individual datagram is a separate message. In order to facilitate
fast comparing of local state with that in a received update, TLVs in
every container TLV MUST be placed in ascending order based on the
binary comparison of both TLV header and value.
5.1. Trickle-Driven Status Update Messages 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 connection-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.
A Trickle state MUST be maintained separately for each connection A Trickle state MUST be maintained separately for each endpoint which
which employs unreliable transport. The Trickle state for all employs unreliable transport. The Trickle state for all endpoints is
connections is considered inconsistent and reset if and only if the considered inconsistent and reset if and only if the locally
locally calculated network state hash changes. This occurs either calculated network state hash changes. This occurs either due to a
due to a change in the local node's own node data, or due to receipt change in the local node's own node data, or due to receipt of more
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
time interval during which at least k Trickle updates must be seen on time interval during which at least k Trickle updates must be seen on
a connection to prevent local state transmission. The actual an endpoint to prevent local state transmission. The actual
suggested Trickle algorithm parameters are DNCP profile specific, as suggested Trickle algorithm parameters are DNCP profile specific, as
described in Section 9. described in Section 9.
5.2. Processing of Received TLVs 5.2. Processing of Received TLVs
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 message the specified TLV(s) via unicast to the originator of the TLV being
being processed. If the reply was caused by a multicast message and processed. If the TLV being replied to was received via multicast
sent to a link with shared bandwidth it SHOULD be delayed by a random and it was sent to a link with shared bandwidth, the reply SHOULD be
timespan in [0, Imin/2]. Sending of replies SHOULD be rate-limited delayed by a random timespan in [0, Imin/2]. Sending of replies
by the implementation, and in case of excess load (or some other SHOULD be rate-limited by the implementation, and in case of excess
reason), a reply MAY be omitted altogether. load (or some other reason), a reply MAY be omitted altogether.
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 TLV used to calculate the (Section 7.2.3) for each node data used to calculate the network
network state hash. state hash. The Node State TLVs SHOULD NOT contain the optional
node data part.
o Request Node State TLV (Section 7.1.2): If the receiver has node
data for the corresponding node, it MUST reply with a Node State
TLV (Section 7.2.3) for the corresponding node. The optional node
data part MUST be included in the TLV.
o 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). The receiver MAY omit this, if there are
already recent pending requests for node state or node data. already recent pending requests for network or node state.
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
this occurs more than once, the DNCP profile should provide this occurs more than once, the DNCP profile should provide
guidance on how to handle these situations as it indicates the guidance on how to handle these situations as it indicates the
existence of another active node with the same node identifier. existence of another active node with the same node identifier.
* If the node identifier does not match the local node * If the node identifier does not match the local node
identifier, and the local information is outdated for the identifier, and the local information is outdated for the
corresponding node (local update sequence number is lower than corresponding node (local update sequence number is lower than
that within the TLV), potentially incorrect (local update that within the TLV), potentially incorrect (local update
sequence number matches but the hash of the node data TLV sequence number matches but the node data hash differs), or the
differs), or the data is altogether missing, and there is no data is altogether missing:
corresponding Node Data TLV available, the receiver MUST reply
with a Request Node Data TLV (Section 7.1.2) for the
corresponding node.
o Request Node Data TLV (Section 7.1.2): If the receiver has node + If the TLV does not contain node data, and the hash of the
data for the corresponding node, it MUST reply with a Node State node data differs, the receiver MUST reply with a Request
TLV (Section 7.2.3) and a Node Data TLV (Section 7.2.4) for the Node State TLV (Section 7.1.2) for the corresponding node.
corresponding node.
o Node Data TLV (Section 7.2.4): If the message contains also a Node + Otherwise the receiver MUST update its locally stored state
State TLV (Section 7.2.3) with the same update sequence number, for that node (node data if present, update sequence number,
that is more recent than the local state (the received TLV has a relative time) to match the received TLV.
higher update sequence number, the node data TLV hash differs from
the local one, or local data is missing altogether), the receiver
MUST update its locally stored state for that node (node data,
update sequence number, relative time) to match the received TLVs.
o Any other TLV: DNCP profiles MAY add additional TLVs to the o Any other TLV: TLVs not recognized by the receiver MUST be
message specified here, or even define additional messages as silently ignored.
needed. TLVs not recognized by the receiver MUST be silently
ignored.
If secure unicast transport is configured for a connection, any Node If secure unicast transport is configured for an endpoint, any Node
Data TLVs and Node State TLVs received via insecure multicast MUST be State TLVs received via insecure multicast MUST be silently ignored.
silently ignored.
5.3. Adding and Removing Peers 5.3. Adding and Removing Peers
When receiving a message on a connection from an unknown peer: When receiving a Node Endpoint TLV (Section 7.2.1) on an endpoint
from an unknown peer:
o If it is a unicast message, and the message contains a Node o If it comes via unicast, the remote node MUST be added as a peer
Connection TLV (Section 7.2.1), the remote node MUST be added as a on the endpoint and a Neighbor TLV (Section 7.3.2) MUST be created
peer on the connection and a Neighbor TLV (Section 7.3.2) MUST be for it.
created for it.
o If it is a multicast message, and the message contains a Node o If it comes via multicast, the node SHOULD be sent a (possibly
Connection TLV (Section 7.2.1), the node SHOULD be sent a rate-limited) unicast Request Network State TLV (Section 7.1.1).
(possibly 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.
5.4. Purging Unreachable Nodes 5.4. Purging Unreachable Nodes
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 connection 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
the grace period, the nodes that were not marked reachable in the the grace period, the nodes that were not marked reachable in the
most recent graph traversal MUST NOT be used for calculation of the most recent graph traversal MUST NOT be used for calculation of the
network state hash, be provided to any applications that need to use network state hash, be provided to any applications that need to use
the whole TLV graph, or be provided to remote nodes. the whole TLV graph, or be provided to remote nodes.
6. Optional Extensions 6. Optional Extensions
This section specifies extensions to the core protocol that a DNCP This section specifies extensions to the core protocol that a DNCP
profile may want to use. profile may want to use.
6.1. Keep-Alives 6.1. Keep-Alives
The Trickle-driven messages provide a mechanism for handling of new Trickle-driven status updates (Section 5.1) provide a mechanism for
peer detection (if applicable) on a connection, as well as state handling of new peer detection (if applicable) on an endpoint, as
change notifications. Another mechanism may be needed to get rid of well as state change notifications. Another mechanism may be needed
old, no longer valid DNCP peers if the transport or lower layers do to get rid of old, no longer valid DNCP peers if the transport or
not provide one. lower layers do not provide one.
If keep-alives are not specified in the DNCP profile, the rest of If keep-alives are not specified in the DNCP profile, the rest of
this subsection MUST be ignored. this subsection MUST be ignored.
A DNCP profile MAY specify either per-connection or per-peer keep- A DNCP profile MAY specify either per-endpoint or per-peer keep-alive
alive support. support.
For every connection that a keep-alive is specified for in the DNCP For every endpoint that a keep-alive is specified for in the DNCP
profile, the connection-specific keep-alive interval MUST be profile, the endpoint-specific keep-alive interval MUST be
maintained. By default, it is DNCP_KEEPALIVE_INTERVAL. If there is maintained. By default, it is DNCP_KEEPALIVE_INTERVAL. If there is
a local value that is preferred for that for any reason a local value that is preferred for that for any reason
(configuration, energy conservation, media type, ..), it should be (configuration, energy conservation, media type, ..), it should be
substituted instead. If a non-default keep-alive interval is used on substituted instead. If a non-default keep-alive interval is used on
any connection, a DNCP node MUST publish appropriate Keep-Alive any endpoint, a DNCP node MUST publish appropriate Keep-Alive
Interval TLV(s) (Section 7.3.3) within its node data. Interval TLV(s) (Section 7.3.3) within its node data.
6.1.1. Data Model Additions 6.1.1. Data Model Additions
The following additions to the Data Model (Section 4) are needed to The following additions to the Data Model (Section 4) are needed to
support keep-alive: support keep-alive:
Each node MUST have a timestamp which indicates the last time a Each node MUST have a timestamp which indicates the last time a
Network State TLV (Section 7.2.2) was sent for each connection, i.e. Network State TLV (Section 7.2.2) was sent for each endpoint, i.e. on
on an interface or to the point-to-point peer(s). an interface or to the point-to-point peer(s).
Each node MUST have for each peer: Each node MUST have for each peer:
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 via multicast, or anything was received via unicast. the peer via multicast, or anything was received via unicast.
When adding a new peer, it should be initialized to the current When adding a new peer, it should be initialized to the current
time. time.
6.1.2. Per-Connection Periodic Keep-Alives 6.1.2. Per-Endpoint Periodic Keep-Alives
If per-connection keep-alives are enabled on a connection with a If per-endpoint keep-alives are enabled on an endpoint with a
multicast-enabled link, and if no traffic containing a Network State multicast-enabled link, and if no traffic containing a Network State
TLV (Section 7.2.2) has been sent to a particular connection within TLV (Section 7.2.2) has been sent to a particular endpoint within the
the connection-specific keep-alive interval, a Network State TLV endpoint-specific keep-alive interval, a Network State TLV
(Section 7.2.2) MUST be sent on that connection, and a new Trickle (Section 7.2.2) MUST be sent on that endpoint, and a new Trickle
transmission time 't' in [I/2, I] MUST be randomly chosen. The transmission time 't' in [I/2, I] MUST be randomly chosen. The
actual sending time SHOULD be further delayed by a random timespan in actual sending time SHOULD be further delayed by a random timespan in
[0, Imin/2]. [0, Imin/2].
6.1.3. Per-Peer Periodic Keep-Alives 6.1.3. Per-Peer Periodic Keep-Alives
If per-peer keep-alives are enabled on a unicast-only connection, and If per-peer keep-alives are enabled on a unicast-only endpoint, and
if no traffic containing a Network State TLV (Section 7.2.2) has been if no traffic containing a Network State TLV (Section 7.2.2) has been
sent to a particular peer within the connection-specific keep-alive sent to a particular peer within the endpoint-specific keep-alive
interval, a Network State TLV (Section 7.2.2) MUST be sent to the interval, a Network State TLV (Section 7.2.2) MUST be sent to the
peer and a new Trickle transmission time 't' in [I/2, I] MUST be peer and a new Trickle transmission time 't' in [I/2, I] MUST be
randomly chosen. randomly chosen.
6.1.4. Received TLV Processing Additions 6.1.4. Received TLV Processing Additions
If a TLV is received via unicast from the peer, the Last contact If a TLV is received via unicast from the peer, the Last contact
timestamp for the peer MUST be updated. timestamp for the peer MUST be updated.
On receipt of a Network State TLV (Section 7.2.2) which is consistent On receipt of a Network State TLV (Section 7.2.2) which is consistent
with the locally calculated network state hash, the Last contact with the locally calculated network state hash, the Last contact
timestamp for the peer MUST be updated. timestamp for the peer MUST be updated.
6.1.5. Neighbor Removal 6.1.5. Neighbor Removal
For every peer on every connection, the connection-specific keep- For every peer on every endpoint, the endpoint-specific keep-alive
alive interval must be calculated by looking for Keep-Alive Interval interval must be calculated by looking for Keep-Alive Interval TLVs
TLVs (Section 7.3.3) published by the node, and if none exist, using (Section 7.3.3) published by the node, and if none exist, using the
the default value of DNCP_KEEPALIVE_INTERVAL. If the peer's last default value of DNCP_KEEPALIVE_INTERVAL. If the peer's last contact
contact state timestamp has not been updated for at least state timestamp has not been updated for at least
DNCP_KEEPALIVE_MULTIPLIER times the peer's connection-specific keep- DNCP_KEEPALIVE_MULTIPLIER times the peer's endpoint-specific keep-
alive interval, the Neighbor TLV for that peer and the local DNCP alive interval, the Neighbor TLV for that peer and the local DNCP
peer state MUST be removed. peer state MUST be removed.
6.2. Support For Dense Broadcast Links 6.2. Support For Dense Broadcast Links
An upper bound for the number of neighbors that are allowed for a An upper bound for the number of neighbors that are allowed for a
(particular type of) link that a connection runs on SHOULD be (particular type of) link that an endpoint runs on SHOULD be provided
provided by a DNCP profile, user configuration, or some hardcoded by a DNCP profile, user configuration, or some hardcoded default in
default in the implementation. If an implementation does not support the implementation. If an implementation does not support this, the
this, the rest of this subsection MUST be ignored. rest of this subsection MUST be ignored.
If the specified limit is exceeded, nodes without the highest Node If the specified limit is exceeded, nodes without the highest Node
Identifier on the link SHOULD treat the connection as an unicast Identifier on the link SHOULD treat the endpoint as a unicast
connection connected to the node that has the highest Node Identifier endpoint connected to the node that has the highest Node Identifier
detected on the link. The nodes MUST also keep listening to detected on the link. The nodes MUST also keep listening to
multicast traffic to both detect the presence of that node, and to multicast traffic to both detect the presence of that node, and to
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 connection highest Node Identifier present on the link changes, the remote
endpoint MUST be changed. If the Node Identifier of the local node unicast address of unicast endpoints MUST be changed. If the Node
is the highest one, the node MUST keep the connection in normal Identifier of the local node is the highest one, the node MUST keep
multicast mode, and the node MUST allow others to peer with it over the endpoint in multicast mode, and the node MUST allow others to
the link. peer with it over the link via unicast as well.
6.3. Node Data Fragmentation 6.3. Node Data Fragmentation
A DNCP profile may require a node to exceed the maximum size of a A DNCP profile may be required to support node data which would not
single Node Data TLV (Section 7.2.4) (65535 bytes of payload), or use the fit maximum size of a single Node State TLV (Section 7.2.3)
a datagram-only transport with a limited MTU and no reliable support (roughly 64KB of payload), or use a datagram-only transport with a
for fragmentation. To handle such cases, a DNCP profile MAY specify limited MTU and no reliable support for fragmentation. To handle
a fixed number of trailing bytes in the Node Identifier to represent such cases, a DNCP profile MAY specify a fixed number of trailing
a fragment number indicating a part of a node's node data. The bytes in the Node Identifier to represent a fragment number
profile MAY also specify an upper bound for the size of a single indicating a part of a node's node data. The profile MAY also
fragment to accommodate limitations of links in the network. specify an upper bound for the size of a single fragment to
accommodate limitations of links in the network.
The data within Node Data 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
single full TLV). However, the concatenated node data for a single full TLV). However, the concatenated node data for a
particular node MUST be produced by concatenating all node data for particular node MUST be produced by concatenating all node data for
each fragment, in ascending fragment number order. The concatenated each fragment, in ascending fragment number order. The concatenated
node data MUST follow the ordering described in Section 4. node data MUST follow the ordering described in Section 4.
Any Node Identifiers on the wire used to identify the own or any Any Node Identifiers on the wire used to identify the own or any
other node MUST have the fragment number 0. For algorithm purposes, other node MUST have the fragment number 0. For algorithm purposes,
the relative time since the most recent fragment change MUST be used, the relative time since the most recent fragment change MUST be used,
regardless of fragment number. Therefore, even if just part of the regardless of fragment number. Therefore, even if just part of the
skipping to change at page 13, line 30 skipping to change at page 13, line 30
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
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-NETWORK-STATE (2) | Length: 0 | | Type: REQ-NETWORK-STATE (1) | Length: 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV is used to request response with a Network State TLV This TLV is used to request response with a Network State TLV
(Section 7.2.2) and all Node State TLVs (Section 7.2.3). (Section 7.2.2) and all Node State TLVs (Section 7.2.3).
7.1.2. Request Node Data TLV 7.1.2. Request 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: REQ-NODE-DATA (3) | 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 response with a Node State TLV
(Section 7.2.3) and a Node Data TLV (Section 7.2.4) for the node with (Section 7.2.3) for the node with matching node identifier which also
matching node identifier. includes the node data.
7.2. Data TLVs 7.2. Data TLVs
7.2.1. Node Connection 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-CONNECTION (1) | Length: > 4 | | Type: NODE-ENDPOINT (3) | Length: > 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node Identifier | | Node Identifier |
| (length fixed in DNCP profile) | | (length fixed in DNCP profile) |
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connection 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 connection identifier. It MUST be sent in every the particular endpoint's endpoint identifier. It MUST be sent in
message if bidirectional peer relationship is desired with remote every message if bidirectional peer relationship is desired with
nodes. Bidirectional peer relationship is not necessary for read- remote nodes on that endpoint. Bidirectional peer relationship is
only access to the DNCP state, but it is required to be able to not necessary for read-only access to the DNCP state, but it is
publish something. required to be able to publish something.
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 (10) | Length: > 0 | | Type: NETWORK-STATE (4) | Length: > 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| H(H(node data TLV 1) .. [...] .. H(node data TLV N)) | | 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)) |
| (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.
The network state hash is derived by calculating the hash value for It is calculated over each reachable nodes' update number
each currently reachable node's Node Data TLV, concatenating said concatenated with the hash value of its node data in ascending order
hash values based on the ascending order of their corresponding node of the respective node identifier.
identifiers, and hashing the resulting concatenated hash values.
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 (11) | 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Milliseconds since Origination | | Milliseconds since Origination |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| H(node data TLV) | | H(node data) |
| (length fixed in DNCP profile) | | (length fixed in DNCP profile) |
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|(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 same idea about the time since
origination of any particular published state. Therefore every node, origination of any particular published state. Therefore every node,
including the originating one, MUST increment the time whenever it including the originating one, MUST increment the time whenever it
needs to send a Node State TLV for an already published Node Data needs to send a Node State TLV for already published node data.
TLV. This age value is not included within the Node Data TLV,
however, as that is immutable and used to detect changes in the
network state.
7.2.4. Node Data TLV
0 1 2 3 The actual node data of the node may be included within the TLV as
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 well; see Section 5.2 for the cases where it MUST or MUST NOT be
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ included. In a DNCP profile which supports fragmentation, described
| Type: NODE-DATA (12) | Length: > 4 | in Section 6.3, the TLV data may be only partial and not really
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ usable without other fragments.
| node identifier |
| (length fixed in DNCP profile) |
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Update Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nested TLVs containing node information |
7.2.5. Custom TLV 7.2.4. Custom 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: CUSTOM-DATA (15) | Length: > 0 | | Type: CUSTOM-DATA (6) | Length: > 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| H(URI) | | H(URI) |
| (length fixed in DNCP profile) | | (length fixed in DNCP profile) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Data | | Opaque Data |
This TLV can be used to contain anything; the URI used should be This TLV can be used to contain anything; the URI used should be
under control of the author of that specification. The TLV may under control of the author of that specification. The TLV may
appear within protocol exchanges, or within Node Data TLV appear within protocol exchanges, or within Node State TLV
(Section 7.2.4). For example: (Section 7.2.3). For example:
V = H('http://example.com/author/json-for-dncp') .. '{"cool": "json V = H('http://example.com/author/json-for-dncp') .. '{"cool": "json
extension!"}' extension!"}'
or or
V = H('mailto:author@example.com') .. '{"cool": "json extension!"}' V = H('mailto:author@example.com') .. '{"cool": "json extension!"}'
7.3. Data TLVs within Node Data TLV 7.3. Data TLVs within Node State TLV
These TLVs are DNCP-specific parts of node-specific node data, and
are encoded within the Node State TLVs. If encountered outside Node
State TLV, they MUST be silently ignored.
7.3.1. Fragment Count TLV 7.3.1. Fragment Count 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: FRAGMENT-COUNT (9) | Length: > 0 | | Type: FRAGMENT-COUNT (7) | Length: > 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count | | Count |
| (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
series of Node Data TLVs. Subsequent Node Data with Node Identifiers sequence of Node State TLVs. Following Node State TLVs with Node
up to Count higher than the current one MUST be considered reachable Identifiers up to Count higher than the current one MUST be
and part of the same logical set of Node Data that this TLV is considered reachable and part of the same logical set of node data
within. The fragment portion of the Node Identifier of the Node Data that this TLV is within. The fragment portion of the Node Identifier
this is within MUST be zeros. of the Node State TLV this is TLV appears in MUST be zeros.
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 (13) | Length: > 8 | | Type: NEIGHBOR (8) | Length: > 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| neighbor node identifier | | neighbor node identifier |
| (length fixed in DNCP profile) | | (length fixed in DNCP profile) |
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Connection Identifier | | Neighbor Endpoint Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Connection 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
connection. The presence of this TLV at least guarantees that the endpoint. The presence of this TLV at least guarantees that the node
node publishing it has received traffic from the neighbor recently. publishing it has received traffic from the neighbor recently. For
For guaranteed up-to-date bidirectional reachability, the existence guaranteed up-to-date bidirectional reachability, the existence of
of both nodes' matching Neighbor TLVs should be checked. both nodes' matching Neighbor TLVs should be checked.
7.3.3. Keep-Alive Interval TLV 7.3.3. Keep-Alive Interval 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: KEEP-ALIVE-INTERVAL (14)| Length: 8 | | Type: KEEP-ALIVE-INTERVAL (9) | Length: 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Connection Identifier | | Endpoint Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interval | | Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV indicates a non-default interval being used to send keep- This TLV indicates a non-default interval being used to send keep-
alives specified in Section 6.1. alives specified in Section 6.1.
Connection identifier is used to identify the particular connection Endpoint identifier is used to identify the particular endpoint for
for which the interval applies. If 0, it applies for ALL connections which the interval applies. If 0, it applies for ALL endpoints for
for which no specific TLV exists. which no specific TLV exists.
Interval specifies the interval in milliseconds at which the node Interval specifies the interval in milliseconds at which the node
sends keep-alives. A value of zero means no keep-alives are sent at sends keep-alives. A value of zero means no keep-alives are sent at
all; in that case, some lower layer mechanism that ensures presence all; in that case, some lower layer mechanism that ensures presence
of nodes MUST be available and used. of nodes MUST be available and used.
8. Security and Trust Management 8. Security and Trust Management
If specified in the DNCP profile, either DTLS [RFC6347] or TLS If specified in the DNCP profile, either DTLS [RFC6347] or TLS
[RFC5246] may be used to authenticate and encrypt either some (if [RFC5246] may be used to authenticate and encrypt either some (if
skipping to change at page 21, line 8 skipping to change at page 21, line 8
found for any of the certificates, or a reasonable amount of time (10 found for any of the certificates, or a reasonable amount of time (10
minutes is suggested) with no reaction and no further authentication minutes is suggested) with no reaction and no further authentication
attempts has passed. Such verdicts SHOULD also be limited in rate attempts has passed. Such verdicts SHOULD also be limited in rate
and number to prevent denial-of-service attacks. and number to prevent denial-of-service attacks.
Trust verdicts are announced using Trust-Verdict TLVs: Trust verdicts are announced using Trust-Verdict TLVs:
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: Trust-Verdict (16) | Length: 37-100 | | Type: Trust-Verdict (10) | Length: 37-100 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Verdict | (reserved) | | Verdict | (reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| | | |
| | | |
| SHA-256 Fingerprint | | SHA-256 Fingerprint |
| | | |
| | | |
| | | |
skipping to change at page 22, line 32 skipping to change at page 22, line 32
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 define following:
o How the messages are secured: Not at all, optionally or always 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, 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 or with something else. If the links with DNCP nodes can be
sufficiently secured or isolated, it is possible to run DNCP in a sufficiently secured or isolated, it is possible to run DNCP in a
secure manner without using any form of authentication or secure manner without using any form of authentication or
encryption. 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 If TLS scheme within this document is to be used security, TLS or
DTLS support for at least the unicast transport protocol is DTLS support for at least the unicast transport protocol is
mandatory. mandatory.
skipping to change at page 24, line 24 skipping to change at page 24, line 24
network using a different identity. Stopping such an attack might network using a different identity. Stopping such an attack might
require physical intervention and flushing of the trust caches. require physical intervention and flushing of the trust caches.
11. IANA Considerations 11. IANA Considerations
IANA should set up a registry for DNCP TLV types, with the following IANA should set up a registry for DNCP TLV types, with the following
initial contents: initial contents:
0: Reserved (should not happen on wire) 0: Reserved (should not happen on wire)
1: Node connection 1: Request network state
2: Request network state
3: Request node data
4-8: Reserved for DNCP profile use 2: Request node state
9: Fragment count 3: Node endpoint
10: Network state 4: Network state
11: Node state 5: Node state
12: Node data 6: Custom
13: Neighbor 7: Fragment count
14: Keep-alive interval 8: Neighbor
15: Custom 9: Keep-alive interval
16: Trust-Verdict 10: Trust-Verdict
17-31: Reserved for future DNCP versions. 32-191: Reserved for per-DNCP profile use
192-255: Reserved for per-implementation experimentation. The nodes 192-255: Reserved for per-implementation experimentation. The nodes
using TLV types in this range SHOULD use e.g. Custom TLV to identify using TLV types in this range SHOULD use e.g. Custom TLV to identify
each other and therefore eliminate potential conflict caused by each other and therefore eliminate potential conflict caused by
potential different use of same TLV numbers. potential different use of same TLV numbers.
For the rest of the values (32-191, 256-65535), policy of 'standards For the rest of the values (11-31, 256-65535), policy of 'standards
action' should be used. action' should be used.
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, March 1997.
[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
skipping to change at page 25, line 37 skipping to change at page 25, line 32
[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, February 2003.
[RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms [RFC6234] Eastlake, 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, May 2011.
Appendix A. Some Questions and Answers [RFC Editor: please remove] Appendix A. Some Questions and Answers [RFC Editor: please remove]
Q: 32-bit connection 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-03:
o Renamed connection -> endpoint.
o !!! Backwards incompatible change: Renumbered TLVs, and got rid of
node data TLV; instead, node data TLV's contents are optionally
within node state TLV.
draft-ietf-homenet-dncp-02: draft-ietf-homenet-dncp-02:
o Changed DNCP "messages" into series of TLV streams, allowing o Changed DNCP "messages" into series of TLV streams, allowing
optimized round-trip saving synchronization. optimized round-trip saving synchronization.
o Added fragmentation support for bigger node data and for chunking o Added fragmentation support for bigger node data and for chunking
in absence of reliable L2 and L3 fragmentation. in absence of reliable L2 and L3 fragmentation.
draft-ietf-homenet-dncp-01: draft-ietf-homenet-dncp-01:
skipping to change at page 27, line 8 skipping to change at page 27, line 14
Appendix C. Draft Source [RFC Editor: please remove] Appendix C. Draft Source [RFC Editor: please remove]
As usual, this draft is available at https://github.com/fingon/ietf- As usual, this draft is available at https://github.com/fingon/ietf-
drafts/ in source format (with nice Makefile too). Feel free to send drafts/ in source format (with nice Makefile too). Feel free to send
comments and/or pull requests if and when you have changes to it! comments and/or pull requests if and when you have changes to it!
Appendix D. Acknowledgements Appendix D. Acknowledgements
Thanks to Ole Troan, Pierre Pfister, Mark Baugher, Mark Townsley, Thanks to Ole Troan, Pierre Pfister, Mark Baugher, Mark Townsley,
Juliusz Chroboczek and Jiazi Yi for their contributions to the draft. Juliusz Chroboczek, Jiazi Yi, Mikael Abrahamsson and Brian Carpenter
for their contributions to the draft.
Authors' Addresses Authors' Addresses
Markus Stenberg Markus Stenberg
Helsinki 00930 Helsinki 00930
Finland Finland
Email: markus.stenberg@iki.fi Email: markus.stenberg@iki.fi
Steven Barth Steven Barth
 End of changes. 105 change blocks. 
228 lines changed or deleted 222 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/