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]
