Internet DRAFT - draft-turner-core-cool-problem-statement

draft-turner-core-cool-problem-statement







CoRE                                                      R. Turner, Ed.
Internet-Draft                                                Landis+Gyr
Intended status: Best Current Practice                      M. Veillette
Expires: September 12, 2016                      Trilliant Networks Inc.
                                                                A. Pelov
                                                                  Acklio
                                                             A. Somaraju
                                                   Tridonic GmbH & Co KG
                                                             A. Minaburo
                                                                  Acklio
                                                          March 11, 2016


                         CoOL Problem Statement
              draft-turner-core-cool-problem-statement-00

Abstract

   A significant part of the next tens of billion of devices that will
   be connected to the Internet will be constrained devices, connecting
   over constrained networks.  Managing these devices and the networks
   they form in a consistent, scalable, extensible, secure, energy-
   efficient manner with low computational and protocol complexity
   cannot be done in an ad-hoc manner.  This document outlines the
   problem at hand and provides a roadmap of the possible solutions
   develped at the IETF.  The description includes the basic constrained
   management problem, as well as properties of the solution.  Details
   as to the Constrained Objecs Language (CoOL) protocol itself can be
   found in companion documents.

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 12, 2016.





Turner, et al.         Expires September 12, 2016               [Page 1]

Internet-Draft                CoOL Problem                    March 2016


Copyright Notice

   Copyright (c) 2016 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Why CoOL? . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   The need exists for a unified approach to network management of
   constrained devices as well as constrained networks.  Constrained
   devices imply the solution should require minimal resources (CPU,
   memory) from the device platform; constrained networks imply the
   network management solution should impose minimal traffic on the
   network to accomplish a particular management objective.

2.  Problem Statement

   The problem of network management for constrained networks and
   devices includes a number of requirements not necessarily addressed
   by existing solutions.  Any solution must be conservative with "when"
   network traffic is required, as well as "how much" traffic is
   required in order to fulfill network management functions.  In
   addition, a solution should support "traditional" network management
   functions that have been useful in a variety of legacy use-cases, as
   well as new functionalities that address the evolving constrained
   device and constrained device scenarios.  In this context, the term
   "constrained" implies limited resources (RAM, FLASH), as well as
   limited CPU resources.  Therefore, the amount of code necessary to
   achieve network management functionality will need to be as small as
   possible, as well as the amount of RAM necessary to achieve the



Turner, et al.         Expires September 12, 2016               [Page 2]

Internet-Draft                CoOL Problem                    March 2016


   functionality will be limited.  Likewise, minimal network bandwidth
   should be required to support a solution.

   An ideal solution SHOULD therefore possess the following
   characteristics:

   o  Simple and efficient

      *  Low memory footprint (RAM)

      *  Low binary footprint (flash)

      *  Low protocol complexity (simple state machine)

   o  Scalable

      *  Thing-to-thing management

      *  Zero feature negotiation required

   o  Compact on the air/wire

   o  Secure

   o  Extensible

   o  Interoperable

   The IETF is coalescing around a set of solutions for transport of
   applications on constrained networks (CoAP).  Since constrained
   devices will likely include support for this constrained "stack", it
   would be advantageous to reuse this constrained device stack for
   network management as well, to address the constrained device
   property of limited resources.

   Additionally, the IETF is moving towards YANG as a data modeling
   language for configuration and state data often attributed to network
   management problems.  Therefore, any constrained device/network
   management solution should attempt to reuse this information when and
   where possible.

   YANG is a data modeling language used to model configuration and
   state data manipulated by the NETCONF protocol (RFC 6241), NETCONF
   remote procedure calls, and NETCONF notifications.  YANG was
   originally designed to work with the NETCONF configuration protocol;
   however, the idea of constrained networks and devices was not a
   factor in the design of NETCONF/YANG.  Any solution that attempts to
   use YANG in a constrained environment should consider constrained



Turner, et al.         Expires September 12, 2016               [Page 3]

Internet-Draft                CoOL Problem                    March 2016


   device and networking properties to the application of YANG in these
   scenarios.

   It would be advantageous to model the particular constrained network
   management functionality on the evolving NETCONF/RESTCONF operations,
   since some level of semantic interoperability might be expected by
   management systems that mix constrained and non-constrained
   management domains.

   One design element that could reduce the amount of traffic "on the
   wire" is requiring less metadata in management transactions.  Instead
   of endpoints semantically parsing the meaning of the data and/or
   traffic, the knowledge of the data and how it is expected to be used
   is, instead, required on the endpoints, a priori.

3.  Why CoOL?

   Currently proposed solutions for constrained management do not
   specifically address the requirements previously suggested in this
   memo.  The solution introduced by CoOL seeks to remedy this by
   introducing an alternative method for operations and encoding "on the
   wire".  CoOL will address these requirements while still utilizing
   the IETF application "stack" and management data modeling language
   (YANG).  The alternative method employed by CoOL utilizes a more
   concise representation of management transactions (specifically
   management "data").

   The evolution of the CoOL solution will recognize the proliferation
   of the "pub/sub" design pattern by relying on extensions both at the
   CoAP, as well as CoOL protocol layers where needed.  Incorporating
   the pub/sub design pattern will assist in the application of CoOL
   into larger scale networks (both constrained and non-constrained).

4.  Roadmap

   Within the CORE group, there are currently two threads of development
   of a management interface for constrained devices and networks.  They
   both converge on the common grounds of using CoAP as fundamental
   application protocol.  Both solutions bring the YANG modeling
   language to the world of constrained networks and devices, thus
   bridging the gap to core network management.

   These two approaches differ by their runtime-vs-compile time
   complexity and efficiency.  The first approach is based on unmanaged
   identifiers (YANG hashes), which require zero compile-time efforts in
   exchange for decreased runtime efficiency.  The second approach is
   based on managed identifiers (SID), which takes the opposite




Turner, et al.         Expires September 12, 2016               [Page 4]

Internet-Draft                CoOL Problem                    March 2016


   direction, requiring more upfront preparation, aiming at maximal
   efficiency, deterministic behavior and improved scalability.

   Both solutions converge around the YANG data representation expressed
   in CBOR, as well as the common comprehension of the problem
   statement.  The managed and unmanaged identifier spaces have their
   specific underlaying function sets.  These function set drafts define
   the well-known REST resources that provide the device management
   services.

   The following drafts are currently available:

             +----------------------------------------+
             |          Problem statement             |
             | I-D.turner-core-cool-problem-statement |
             +----------------------------------------+
                                  |
                                  V
             +----------------------------------------+
             |          Data representation           |
             |  I-D.veillette-core-yang-cbor-mapping  |
             +----------------------------------------+
                      |                      |
                      V                      V
   +---------------------------+  +----------------------------+
   |       Managed IDs         |  |       Unmanaged IDs        |
   |   I-D.somaraju-core-sid   |  | I-D.bierman-core-yang-hash |
   +---------------------------+  +----------------------------+
                      |                      |
                      V                      V
   +---------------------------+  +----------------------------+
   |       Function set        |  |       Function set         |
   |  I-D.veillette-core-cool  |  |  I-D.vanderstok-core-comi  |
   +---------------------------+  +----------------------------+

5.  Security Considerations

   The security considerations applicable to network management of
   enterprise networks is similar to, but different than that of
   constrained networks given the potential risk involved.  The risk
   involved to enterprise networks could be local to an organization
   (assets, reputation).  However, in the case of constrained networks,
   it is reasonable to assume significant risk due to the types of
   application domains constrained devices would be applied to (sensors
   controlling everything from home automation to medical devices).
   With this risk should come a more strict understanding of the attack
   vectors and vulnerabilities of any and all protocols in use in
   constrained networks, especially those protocols tasked with the



Turner, et al.         Expires September 12, 2016               [Page 5]

Internet-Draft                CoOL Problem                    March 2016


   management of a device.  The CoOL working group will attempt to reuse
   applicable ideas and technology originating from other IETF working
   groups to address the problem of security.  The initial focus of
   security will involve the integrity and trustworthiness of
   information originating from CoOL managed endpoints.  The
   confidentiality of this information will also be considered.

Authors' Addresses

   Randy Turner (editor)
   Landis+Gyr
   30000 Mill Creek Ave
   Alpharetta, Georgia  30022
   USA

   Phone: 678-258-1292
   Email: randy.turner@landisgyr.com


   Michel Veillette
   Trilliant Networks Inc.
   610 Rue du Luxembourg
   Granby, Quebec  J2J 2V2
   Canada

   Phone: +14503750556
   Email: michel.veillette@trilliantinc.com


   Alexander Pelov
   Acklio
   2bis rue de la Chataigneraie
   Cesson-Sevigne, Bretagne  35510
   France

   Email: a@ackl.io


   Abhinav Somaraju
   Tridonic GmbH & Co KG
   Farbergasse 15
   Dornbirn, Vorarlberg  6850
   Austria

   Phone: +43664808926169
   Email: abhinav.somaraju@tridonic.com





Turner, et al.         Expires September 12, 2016               [Page 6]

Internet-Draft                CoOL Problem                    March 2016


   Ana Minaburo
   Acklio
   2bis rue de la chataigneraie
   Cesson-Sevigne, Bretagne  35510
   France

   Email: ana@ackl.io












































Turner, et al.         Expires September 12, 2016               [Page 7]