idnits 2.17.1 draft-turner-core-cool-problem-statement-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 99: '...n ideal solution SHOULD therefore poss...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2016) is 2968 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE R. Turner, Ed. 3 Internet-Draft Landis+Gyr 4 Intended status: Best Current Practice M. Veillette 5 Expires: September 12, 2016 Trilliant Networks Inc. 6 A. Pelov 7 Acklio 8 A. Somaraju 9 Tridonic GmbH & Co KG 10 A. Minaburo 11 Acklio 12 March 11, 2016 14 CoOL Problem Statement 15 draft-turner-core-cool-problem-statement-00 17 Abstract 19 A significant part of the next tens of billion of devices that will 20 be connected to the Internet will be constrained devices, connecting 21 over constrained networks. Managing these devices and the networks 22 they form in a consistent, scalable, extensible, secure, energy- 23 efficient manner with low computational and protocol complexity 24 cannot be done in an ad-hoc manner. This document outlines the 25 problem at hand and provides a roadmap of the possible solutions 26 develped at the IETF. The description includes the basic constrained 27 management problem, as well as properties of the solution. Details 28 as to the Constrained Objecs Language (CoOL) protocol itself can be 29 found in companion documents. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 12, 2016. 48 Copyright Notice 50 Copyright (c) 2016 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 67 3. Why CoOL? . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 72 1. Introduction 74 The need exists for a unified approach to network management of 75 constrained devices as well as constrained networks. Constrained 76 devices imply the solution should require minimal resources (CPU, 77 memory) from the device platform; constrained networks imply the 78 network management solution should impose minimal traffic on the 79 network to accomplish a particular management objective. 81 2. Problem Statement 83 The problem of network management for constrained networks and 84 devices includes a number of requirements not necessarily addressed 85 by existing solutions. Any solution must be conservative with "when" 86 network traffic is required, as well as "how much" traffic is 87 required in order to fulfill network management functions. In 88 addition, a solution should support "traditional" network management 89 functions that have been useful in a variety of legacy use-cases, as 90 well as new functionalities that address the evolving constrained 91 device and constrained device scenarios. In this context, the term 92 "constrained" implies limited resources (RAM, FLASH), as well as 93 limited CPU resources. Therefore, the amount of code necessary to 94 achieve network management functionality will need to be as small as 95 possible, as well as the amount of RAM necessary to achieve the 96 functionality will be limited. Likewise, minimal network bandwidth 97 should be required to support a solution. 99 An ideal solution SHOULD therefore possess the following 100 characteristics: 102 o Simple and efficient 104 * Low memory footprint (RAM) 106 * Low binary footprint (flash) 108 * Low protocol complexity (simple state machine) 110 o Scalable 112 * Thing-to-thing management 114 * Zero feature negotiation required 116 o Compact on the air/wire 118 o Secure 120 o Extensible 122 o Interoperable 124 The IETF is coalescing around a set of solutions for transport of 125 applications on constrained networks (CoAP). Since constrained 126 devices will likely include support for this constrained "stack", it 127 would be advantageous to reuse this constrained device stack for 128 network management as well, to address the constrained device 129 property of limited resources. 131 Additionally, the IETF is moving towards YANG as a data modeling 132 language for configuration and state data often attributed to network 133 management problems. Therefore, any constrained device/network 134 management solution should attempt to reuse this information when and 135 where possible. 137 YANG is a data modeling language used to model configuration and 138 state data manipulated by the NETCONF protocol (RFC 6241), NETCONF 139 remote procedure calls, and NETCONF notifications. YANG was 140 originally designed to work with the NETCONF configuration protocol; 141 however, the idea of constrained networks and devices was not a 142 factor in the design of NETCONF/YANG. Any solution that attempts to 143 use YANG in a constrained environment should consider constrained 144 device and networking properties to the application of YANG in these 145 scenarios. 147 It would be advantageous to model the particular constrained network 148 management functionality on the evolving NETCONF/RESTCONF operations, 149 since some level of semantic interoperability might be expected by 150 management systems that mix constrained and non-constrained 151 management domains. 153 One design element that could reduce the amount of traffic "on the 154 wire" is requiring less metadata in management transactions. Instead 155 of endpoints semantically parsing the meaning of the data and/or 156 traffic, the knowledge of the data and how it is expected to be used 157 is, instead, required on the endpoints, a priori. 159 3. Why CoOL? 161 Currently proposed solutions for constrained management do not 162 specifically address the requirements previously suggested in this 163 memo. The solution introduced by CoOL seeks to remedy this by 164 introducing an alternative method for operations and encoding "on the 165 wire". CoOL will address these requirements while still utilizing 166 the IETF application "stack" and management data modeling language 167 (YANG). The alternative method employed by CoOL utilizes a more 168 concise representation of management transactions (specifically 169 management "data"). 171 The evolution of the CoOL solution will recognize the proliferation 172 of the "pub/sub" design pattern by relying on extensions both at the 173 CoAP, as well as CoOL protocol layers where needed. Incorporating 174 the pub/sub design pattern will assist in the application of CoOL 175 into larger scale networks (both constrained and non-constrained). 177 4. Roadmap 179 Within the CORE group, there are currently two threads of development 180 of a management interface for constrained devices and networks. They 181 both converge on the common grounds of using CoAP as fundamental 182 application protocol. Both solutions bring the YANG modeling 183 language to the world of constrained networks and devices, thus 184 bridging the gap to core network management. 186 These two approaches differ by their runtime-vs-compile time 187 complexity and efficiency. The first approach is based on unmanaged 188 identifiers (YANG hashes), which require zero compile-time efforts in 189 exchange for decreased runtime efficiency. The second approach is 190 based on managed identifiers (SID), which takes the opposite 191 direction, requiring more upfront preparation, aiming at maximal 192 efficiency, deterministic behavior and improved scalability. 194 Both solutions converge around the YANG data representation expressed 195 in CBOR, as well as the common comprehension of the problem 196 statement. The managed and unmanaged identifier spaces have their 197 specific underlaying function sets. These function set drafts define 198 the well-known REST resources that provide the device management 199 services. 201 The following drafts are currently available: 203 +----------------------------------------+ 204 | Problem statement | 205 | I-D.turner-core-cool-problem-statement | 206 +----------------------------------------+ 207 | 208 V 209 +----------------------------------------+ 210 | Data representation | 211 | I-D.veillette-core-yang-cbor-mapping | 212 +----------------------------------------+ 213 | | 214 V V 215 +---------------------------+ +----------------------------+ 216 | Managed IDs | | Unmanaged IDs | 217 | I-D.somaraju-core-sid | | I-D.bierman-core-yang-hash | 218 +---------------------------+ +----------------------------+ 219 | | 220 V V 221 +---------------------------+ +----------------------------+ 222 | Function set | | Function set | 223 | I-D.veillette-core-cool | | I-D.vanderstok-core-comi | 224 +---------------------------+ +----------------------------+ 226 5. Security Considerations 228 The security considerations applicable to network management of 229 enterprise networks is similar to, but different than that of 230 constrained networks given the potential risk involved. The risk 231 involved to enterprise networks could be local to an organization 232 (assets, reputation). However, in the case of constrained networks, 233 it is reasonable to assume significant risk due to the types of 234 application domains constrained devices would be applied to (sensors 235 controlling everything from home automation to medical devices). 236 With this risk should come a more strict understanding of the attack 237 vectors and vulnerabilities of any and all protocols in use in 238 constrained networks, especially those protocols tasked with the 239 management of a device. The CoOL working group will attempt to reuse 240 applicable ideas and technology originating from other IETF working 241 groups to address the problem of security. The initial focus of 242 security will involve the integrity and trustworthiness of 243 information originating from CoOL managed endpoints. The 244 confidentiality of this information will also be considered. 246 Authors' Addresses 248 Randy Turner (editor) 249 Landis+Gyr 250 30000 Mill Creek Ave 251 Alpharetta, Georgia 30022 252 USA 254 Phone: 678-258-1292 255 Email: randy.turner@landisgyr.com 257 Michel Veillette 258 Trilliant Networks Inc. 259 610 Rue du Luxembourg 260 Granby, Quebec J2J 2V2 261 Canada 263 Phone: +14503750556 264 Email: michel.veillette@trilliantinc.com 266 Alexander Pelov 267 Acklio 268 2bis rue de la Chataigneraie 269 Cesson-Sevigne, Bretagne 35510 270 France 272 Email: a@ackl.io 274 Abhinav Somaraju 275 Tridonic GmbH & Co KG 276 Farbergasse 15 277 Dornbirn, Vorarlberg 6850 278 Austria 280 Phone: +43664808926169 281 Email: abhinav.somaraju@tridonic.com 282 Ana Minaburo 283 Acklio 284 2bis rue de la chataigneraie 285 Cesson-Sevigne, Bretagne 35510 286 France 288 Email: ana@ackl.io