[Docs] [txt|pdf|xml] [Tracker] [Email] [Nits]

Versions: 00

ANIMA                                                        M. Stenberg
Internet-Draft
Intended status: Standards Track                           March 5, 2015
Expires: September 6, 2015


             Autonomic Distributed Node Consensus Protocol
                     draft-stenberg-anima-adncp-00

Abstract

   This document describes the Autonomic Distributed Node Consensus
   Protocol (ADNCP), a profile of Distributed Node Consensus Protocol
   (DNCP) for autonomic networking.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 6, 2015.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.





Stenberg                Expires September 6, 2015               [Page 1]


Internet-DraftAutonomic Distributed Node Consensus Protocol   March 2015


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   2
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  DNCP Profile  . . . . . . . . . . . . . . . . . . . . . . . .   3
   5.  Point-To-Point Operations . . . . . . . . . . . . . . . . . .   4
   6.  Distributed Operations  . . . . . . . . . . . . . . . . . . .   5
     6.1.  Discovery . . . . . . . . . . . . . . . . . . . . . . . .   5
     6.2.  Negotiation / Synchronization . . . . . . . . . . . . . .   5
     6.3.  Intent Distribution . . . . . . . . . . . . . . . . . . .   5
   7.  Area Support  . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Area Boundaries . . . . . . . . . . . . . . . . . . . . .   6
     7.2.  Area Identifier . . . . . . . . . . . . . . . . . . . . .   6
     7.3.  Area Formation  . . . . . . . . . . . . . . . . . . . . .   6
     7.4.  Import/Export . . . . . . . . . . . . . . . . . . . . . .   8
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     10.1.  Normative references . . . . . . . . . . . . . . . . . .   8
     10.2.  Informative references . . . . . . . . . . . . . . . . .   9
   Appendix A.  Open Issues  . . . . . . . . . . . . . . . . . . . .   9
   Appendix B.  Changelog  . . . . . . . . . . . . . . . . . . . . .  10
   Appendix C.  Draft Source . . . . . . . . . . . . . . . . . . . .  10
   Appendix D.  Acknowledgements . . . . . . . . . . . . . . . . . .  10
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   DNCP [I-D.ietf-homenet-dncp] provides a single-area link state
   database for arbitrary use.  ADNCP extends DNCP in several ways and
   makes it implementable by defining a profile.

   ADNCP allows for several types of point-to-point exchanges that match
   typical autonomic operations.  The shared state within ADNCP itself
   is used to also facilitate some autonomic operations.  Whether point-
   to-point or multi-party algorithms are used is left up to the
   specification of particular objectives.

   To provide for better scalability than the base DNCP, ADNCP also
   defines (optionally zero-configuration) multi-area system.

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].




Stenberg                Expires September 6, 2015               [Page 2]


Internet-DraftAutonomic Distributed Node Consensus Protocol   March 2015


3.  Terminology

   Reader is assumed to be familiar with the autonomic networking
   terminology described in
   [I-D.irtf-nmrg-autonomic-network-definitions] and
   [I-D.ietf-homenet-dncp].

   (ADNCP) area: A set of ADNCP running nodes that are directly
   connected using a set of DNCP connections.  In other words, DNCP
   network.  They share a link state database, and may also have some
   other data from other areas but no actual topology of the other
   areas.

   (ADNCP) network: A set of connected ADNCP areas.

   area owner: The ADNCP node with the highest Node Identifier within
   the ADNCP area.

   connection owner: Either ADNCP node with the highest Node Identifier
   on a multicast-capable link the connection maps to, or the unicast
   "server" node that other nodes connect.

   per-area: Applicable to the nodes in a particular area.

   area-wide: Distribution scope in which content is made available to
   nodes in only one area.

   per-net: Applies to the whole (ADNCP) network.

   net-wide: Distribution scope in which content is made available to
   nodes in all areas.

4.  DNCP Profile

   ADNCP is defined as a profile of DNCP [I-D.ietf-homenet-dncp] with
   the following parameters:

   o  ADNCP uses UDP datagrams on port ADNCP-UDP-PORT as a multicast
      transport over IPv6 using group All-ADNCP-Nodes-6, or IPv4 using
      group All-ADNCP-Nodes-4.  TLS [RFC5246] on port ADNCP-TCP-PORT is
      used for unicast transport.  Non-secure unicast transport MUST NOT
      be used and therefore is not defined at all.  In a typical case,
      multicast transport SHOULD be link-local scoped, although other
      scopes MAY be also used and supported if multicast routing is
      available.






Stenberg                Expires September 6, 2015               [Page 3]


Internet-DraftAutonomic Distributed Node Consensus Protocol   March 2015


   o  ADNCP operates over either unicast connections, or over multicast-
      capable interfaces.  Therefore the value encoded in the DNCP
      Connection Identifier is left up to the implementation.

   o  ADNCP nodes MUST support the X.509 PKI-based trust method, and MAY
      support the DNCP Certificate Based Trust Consensus method.

   o  ADNCP nodes MUST use the leading 128 bits of SHA256 [RFC6234] as
      DNCP non-cryptographic hash function H(x).

   o  ADNCP uses 128-bit node identifiers (DNCP_NODE_IDENTIFIER_LENGTH =
      128).  A node implementing ADNCP MUST generate their node
      identifier by applying the SHA256 to their public key.  If the
      node receives a Node State TLV with the same node identifier and a
      higher update sequence number multiple times, an error SHOULD be
      made visible to an administrator.

   o  ADNCP nodes MUST NOT send multicast Long Network State messages,
      and received ones MUST be ignored

   o  ADNCP nodes use the following Trickle parameters:

      *  k SHOULD be 1, given the timer reset on data updates and
         retransmissions should handle packet loss.

      *  Imin SHOULD be 200 milliseconds but SHOULD NOT be lower.  Note:
         Earliest transmissions may occur at Imin / 2.

      *  Imax SHOULD be 7 doublings of Imin (i.e. 25.6 seconds) but
         SHOULD NOT be lower.

   o  ADNCP nodes MUST use the keep-alive extension on all multicast
      interface-based connections.  The default keep-alive interval
      (DNCP_KEEPALIVE_INTERVAL) is 20 seconds, the multiplier
      (DNCP_KEEPALIVE_MULTIPLIER) MUST be 2.1, the grace-interval
      (DNCP_GRACE_INTERVAL) SHOULD be equal to DNCP_KEEPALIVE_MULTIPLIER
      times DNCP_KEEPALIVE_INTERVAL.

5.  Point-To-Point Operations

   For point-to-point operations such as discovery, negotiation, and
   synchronization, a single new class of DNCP messages is defined (TBD
   - more detail?).  It is identified by the presence of an objective-
   specific TLV, and if specified by the objective, it SHOULD be
   responded to only via unicast at most.  Therefore, if an ADNCP
   implementation does not recognize a message, it MUST be silently
   ignored.  These messages SHOULD NOT in and of themselves establish a




Stenberg                Expires September 6, 2015               [Page 4]


Internet-DraftAutonomic Distributed Node Consensus Protocol   March 2015


   DNCP-style bidirectional peering relationship between nodes, and
   therefore SHOULD NOT contain Node Connection TLV..

   Such objective-specific messages should either define some
   transaction id scheme (TBD - should it be here), or include the
   request verbatim within the replies, if any.

6.  Distributed Operations

6.1.  Discovery

   If point-to-point discovery (using either multicast-capable
   interface(s), or known unicast peers) is not chosen, discovery can be
   handled also either by participating in the ADNCP network, or by
   performing point-to-point operation with a node participating in the
   ADNCP.

   Presence (or lack) of content with ADNCP can be used to discover
   nodes that support particular objectives in some specific way; for
   example, an objective might specify TLV which contains an address of
   some particular type of server (for example, DHCPv6 PD), and
   therefore by just using ADNCP information, "closest" node (in terms
   of areas / in terms of routing of the address) could be determined.

6.2.  Negotiation / Synchronization

   ADNCP is not suitable for (especially net-wide) transmission of any
   data that changes rapidly.  Therefore it should be used to sparingly
   publish data that changes at most gradually.

   With that limitation in mind, ADNCP can be used to implement
   arbitrary multi-party algorithms, such as Prefix Assignment
   [I-D.ietf-homenet-prefix-assignment].  Given appropriate per-area
   hierarchical assignment (published net-wide), it could be also
   employed net-wide though, as the per-net prefix assignments would
   change only rarely.

   For rapidly changing data, point-to-point exchanges (as needed)
   should be used instead and just e.g. relevant IP addresses published
   via ADNCP.

6.3.  Intent Distribution

   Arbitrary (operator-supplied) objective-specific intent can be
   supplied as TLVs within ADNCP, either per-area or per-network.






Stenberg                Expires September 6, 2015               [Page 5]


Internet-DraftAutonomic Distributed Node Consensus Protocol   March 2015


7.  Area Support

   Area support for DNCP is added so that non-area-capable
   implementations can benefit from it, but cannot support more than one
   interface (for same DNCP instance at any rate), as they cannot handle
   the logic for transferring data between areas.

   Areas are uniquely identified by a 32-bit Area Identifier.

7.1.  Area Boundaries

   A single connection always belongs to exactly one area.  Therefore
   the boundaries of the areas are within nodes that have multiple
   connections, and can transfer data between them.

   For every remote area detected (=on other connections, not on that
   particular connection), a node should include a Remote Area TLV which
   contains an Area Identifier, a Node Identifier of the area owner, and
   pared down (recursive) list of Remote Area TLVs from that area, that
   MUST be loop free.  An exception to the rule is the current area; if
   the current area is advertised elsewhere, it MUST be included if and
   only if the owner's Node Identifier differs from the local one.
   Longer paths to particular areas with matching owner Node Identifier
   MAY be also omitted.

   TBD: Remote Area TLV - area id, area owner (+container for more
   Remote Area TLVs recursively)

7.2.  Area Identifier

   Area Identifier for every connection is chosen by the connection
   owner.  The link is owned by the node with the highest Node
   Identifier on a connection which consists of a multicast-capable
   link, or the "server" node which other nodes are connecting to in
   case of an unicast link.

   TBD: Area Identifier TLV - just area id - originated by the area
   owner, and then included in every unicast message on link.

7.3.  Area Formation

   Areas by definition are connected parts of the network.  An operator
   may set explicit values for the Area Identifiers, thereby forming the
   areas, or alternatively an automatic formation process described here
   can be used by the connection owners.  Non connection owners on a
   particular connection should simply follow the connection owner's
   lead.




Stenberg                Expires September 6, 2015               [Page 6]


Internet-DraftAutonomic Distributed Node Consensus Protocol   March 2015


   If the connection owner does not have an area on a particular
   connection yet, it may use an existing area from some other
   connection if and only if following suitability criteria are met:

   o  The current set of links covered by that area (calculated by
      traversing through the neighbor graph) is not more than TBD.

   o  The number of nodes in that area is not more than TBD.

   o  The area owner does not publish an Area Full TLV.

   If nothing suitable is present, areas connected directly to other
   nodes within the area can be also considered.  For them, the
   suitability criteria are:

   o  A node within current area exists which publishes Remote Area TLV
      with the Area Identifier of the area.

   o  No published Area Full TLV for the area.

   If choosing to use a particular area, the node MUST wait random
   [TBD1, TBD2] seconds before making the actual assignment, and ensure
   that the suitability criteria are still matched when it makes the
   assignment.  If not, this process should be repeated again, starting
   from evaluating the candidates.

   If no area is found at all, a new area should be created, with a
   random delay of [TBD1, TBD2] seconds before announcing.  At the end
   of the interval, the presence of available areas to join should be
   checked before publishing the Area Identifier TLV.

   Once the area owner notices that the directly connected suitability
   criteria enumerated above are no longer filled by the local area (=it
   is too large), the area owner MUST publish an Area Full TLV.  It MAY
   be removed at later point, but if and only if the area is
   substantially below the maximum desired size in terms of number of
   links and number of nodes.

   If the owner of an area detects the presence of a Remote Area TLV
   with an Area Identifier identical to that of the area it is
   advertising and with an owner having a higher Node Identifier than
   itself, then the area owner MUST choose a new (random) Area
   Identifier.

   TBD: Area Full TLV - no content, but net-wide.






Stenberg                Expires September 6, 2015               [Page 7]


Internet-DraftAutonomic Distributed Node Consensus Protocol   March 2015


7.4.  Import/Export

   There is no explicit exporting of TLVs; any TLV type that has highest
   bit set (0x8000) will be considered area-originated, and spread net-
   wide, as opposed to the default area-wide node-originated.  It is
   important to note that currently node identifier of the originating
   node is lost as it transitions to another area (TBD), but within the
   area the originator is still visible.

   Given the node is on an area boundary, for all areas it is in, it
   must recursively traverse all Remote Area TLVs announced within the
   area, and keep track of the shortest recursion depth at which a
   particular area is first encountered.  The Node Identifier of the
   Remote Area TLV originator is used for tie-breaking, with the higher
   one preferred.  If encountering Remote Area TLV with the local area's
   Area Identifier, that TLV MUST NOT be recursed into to avoid loops.

   For any areas for which the node is identified as the importer (by
   having shortest path of areas, or winning tie-break), the node MUST
   import Remote Area Content TLV from the first-hop remote area
   verbatim if there are other areas on the path.  If the node is
   directly connected to the remote area, it MUST create and maintain
   Remote Area Content TLV which contains all TLVs marked for export.

   When Remote Area Content TLV changes, or is no longer present in the
   "upstream" area, it must be also updated/removed by the importer.

   TBD: Remote Area Content TLV - area id (+container for any exported
   TLVs from that area)

8.  Security Considerations

   TBD

9.  IANA Considerations

   TBD - TLVs values here + ADNCP-UDP-PORT, ADNCP-TCP-PORT

   All-ADNCP-Nodes-4, All-ADNCP-Nodes-6

10.  References

10.1.  Normative references

   [I-D.ietf-homenet-dncp]
              Stenberg, M. and S. Barth, "Distributed Node Consensus
              Protocol", draft-ietf-homenet-dncp-00 (work in progress),
              January 2015.



Stenberg                Expires September 6, 2015               [Page 8]


Internet-DraftAutonomic Distributed Node Consensus Protocol   March 2015


   [RFC6234]  Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

10.2.  Informative references

   [I-D.ietf-homenet-prefix-assignment]
              Pfister, P., Paterson, B., and J. Arkko, "Distributed
              Prefix Assignment Algorithm", draft-ietf-homenet-prefix-
              assignment-03 (work in progress), February 2015.

   [I-D.irtf-nmrg-autonomic-network-definitions]
              Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
              Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
              Networking - Definitions and Design Goals", draft-irtf-
              nmrg-autonomic-network-definitions-05 (work in progress),
              December 2014.

Appendix A.  Open Issues

   Should hierarchical PA be defined here or not?
   [I-D.ietf-homenet-prefix-assignment], with cross-area hierarchical
   extension, would facilitate even very large scale PA (with
   potentially multiple upstreams).  Perhaps the current mention is
   enough.

   Should areas importers / area ID choice TLVs include precedence
   value?

   Should we include node-data signatures or not?  They improve
   security, but are not visible across areas in any case - it would
   need per-TLV signature(!) in that case with a hefty footprint due to
   needing to include way to identify the public key too.  So I think
   not.

   Should some way to publish certificate id / raw public key be
   defined?  So it can be verified that e.g. node identifier is really
   generated based on one.  Perhaps..

   Should some sort of more granular delta transfer scheme be defined?
   For a large network, the current scheme's TLV set published by a
   single node can grow to substantial size.  This may occur either here
   or in DNCP.



Stenberg                Expires September 6, 2015               [Page 9]


Internet-DraftAutonomic Distributed Node Consensus Protocol   March 2015


Appendix B.  Changelog

   draft-stenberg-anima-adncp-00: Initial version.

Appendix C.  Draft Source

   As usual, this draft is available at https://github.com/fingon/ietf-
   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!

Appendix D.  Acknowledgements

   Thanks to Pierre Pfister, Mark Baugher and Steven Barth for their
   contributions to the draft.

Author's Address

   Markus Stenberg
   Helsinki  00930
   Finland

   Email: markus.stenberg@iki.fi





























Stenberg                Expires September 6, 2015              [Page 10]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/