idnits 2.17.1 draft-ietf-opsawg-coman-probstate-reqs-05.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 1, 2015) is 3306 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Ersue, Ed. 3 Internet-Draft Nokia Networks 4 Intended status: Informational D. Romascanu 5 Expires: September 2, 2015 Avaya 6 J. Schoenwaelder 7 Jacobs University Bremen 8 U. Herberg 9 March 1, 2015 11 Management of Networks with Constrained Devices: Problem Statement and 12 Requirements 13 draft-ietf-opsawg-coman-probstate-reqs-05 15 Abstract 17 This document provides a problem statement, deployment and management 18 topology options as well as requirements addressing the different use 19 cases of the management of networks where constrained devices are 20 involved. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 2, 2015. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.3. Network Types and Characteristics in Focus . . . . . . . 5 60 1.4. Constrained Device Deployment Options . . . . . . . . . . 9 61 1.5. Management Topology Options . . . . . . . . . . . . . . . 9 62 1.6. Managing the Constrainedness of a Device or Network . . . 10 63 1.7. Configuration and Monitoring Functionality Levels . . . . 13 64 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 14 65 3. Requirements on the Management of Networks with Constrained 66 Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 67 3.1. Management Architecture/System . . . . . . . . . . . . . 17 68 3.2. Management Protocols and Data Models . . . . . . . . . . 21 69 3.3. Configuration Management . . . . . . . . . . . . . . . . 24 70 3.4. Monitoring Functionality . . . . . . . . . . . . . . . . 26 71 3.5. Self-management . . . . . . . . . . . . . . . . . . . . . 31 72 3.6. Security and Access Control . . . . . . . . . . . . . . . 32 73 3.7. Energy Management . . . . . . . . . . . . . . . . . . . . 34 74 3.8. Software Distribution . . . . . . . . . . . . . . . . . . 36 75 3.9. Traffic Management . . . . . . . . . . . . . . . . . . . 36 76 3.10. Transport Layer . . . . . . . . . . . . . . . . . . . . . 37 77 3.11. Implementation Requirements . . . . . . . . . . . . . . . 39 78 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 40 80 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41 81 7. Informative References . . . . . . . . . . . . . . . . . . . 41 82 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 42 83 A.1. draft-ietf-opsawg-coman-probstate-reqs-04 - draft-ietf- 84 opsawg-coman-probstate-reqs-05 . . . . . . . . . . . . . 42 85 A.2. draft-ietf-opsawg-coman-probstate-reqs-03 - draft-ietf- 86 opsawg-coman-probstate-reqs-04 . . . . . . . . . . . . . 42 87 A.3. draft-ietf-opsawg-coman-probstate-reqs-02 - draft-ietf- 88 opsawg-coman-probstate-reqs-03 . . . . . . . . . . . . . 42 89 A.4. draft-ietf-opsawg-coman-probstate-reqs-01 - draft-ietf- 90 opsawg-coman-probstate-reqs-02 . . . . . . . . . . . . . 43 91 A.5. draft-ietf-opsawg-coman-probstate-reqs-00 - draft-ietf- 92 opsawg-coman-probstate-reqs-01 . . . . . . . . . . . . . 43 93 A.6. draft-ersue-constrained-mgmt-03 - draft-ietf-opsawg- 94 coman-probstate-reqs-00 . . . . . . . . . . . . . . . . . 44 95 A.7. draft-ersue-constrained-mgmt-02-03 . . . . . . . . . . . 44 96 A.8. draft-ersue-constrained-mgmt-01-02 . . . . . . . . . . . 45 97 A.9. draft-ersue-constrained-mgmt-00-01 . . . . . . . . . . . 46 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 100 1. Introduction 102 1.1. Overview 104 Constrained devices, aka. sensor, smart object, or smart device, with 105 limited CPU, memory, and power resources, can constitute a network. 106 Such a network of constrained devices itself may be constrained or 107 challenged, e.g., with unreliable or lossy channels, wireless 108 technologies with limited bandwidth and a dynamic topology, needing 109 the service of a gateway or proxy to connect to the Internet. In 110 other scenarios, the constrained devices can be connected to a non- 111 constrained network using off-the-shelf protocol stacks. 113 Constrained devices might be in charge of gathering information in 114 diverse settings including natural ecosystems, buildings, and 115 factories, and send the information to one or more server stations. 116 Constrained devices may also work under severe resource constraints 117 such as limited battery and computing power, little memory and 118 insufficient wireless bandwidth, and communication capabilities. A 119 central entity, e.g., a base station or controlling server, might 120 have more computational and communication resources and can act as a 121 gateway between the constrained devices and the application logic in 122 the core network. 124 Today diverse size of constrained devices with different resources 125 and capabilities are being connected. Mobile personal gadgets, 126 building-automation devices, cellular phones, Machine-to-machine 127 (M2M) devices, etc. benefit from interacting with other "things" in 128 the near or somewhere in the Internet. With this the Internet of 129 Things (IoT) becomes a reality, build up of uniquely identifiable 130 objects (things). And over the next decade, this could grow to 131 trillions of constrained devices and will greatly increase the 132 Internet's size and scope. 134 Network management is characterized by monitoring network status, 135 detecting faults, and inferring their causes, setting network 136 parameters, and carrying out actions to remove faults, maintain 137 normal operation, and improve network efficiency and application 138 performance. The traditional network monitoring application 139 periodically collects information from a set of elements that are 140 needed to manage, processes the data, and presents them to the 141 network management users. Constrained devices, however, often have 142 limited power, low transmission range, and might be unreliable. They 143 might also need to work in hostile environments with advanced 144 security requirements or need to be used in harsh environments for a 145 long time without supervision. Due to such constraints, the 146 management of a network with constrained devices faces different type 147 of challenges compared to the management of a traditional IP network. 149 The IETF has already done substantial standardization work to enable 150 the communication in IP networks and to manage such networks as well 151 as the manifold type of nodes in these networks [RFC6632]. However, 152 the IETF so far has not developed any specific technologies for the 153 management of constrained devices and the networks comprised by 154 constrained devices. IP-based sensors or constrained devices in such 155 an environment, i.e., devices with very limited memory, CPU, and 156 energy resources, use nowadays application-layer protocols in an ad- 157 hoc manner to do simple resource management and monitoring. 159 This document provides a problem statement and lists requirements for 160 the different use cases of management of a network with constrained 161 devices. Section 1.3 and Section 1.5 describe different topology 162 options for the networking and management of constrained devices. 163 Section 2 provides a problem statement on the issue of the management 164 of networked constrained devices. Section 3 lists requirements on 165 the management of applications and networks with constrained devices. 166 Note that the requirements listed in Section 3 have been separated 167 from the context in which they may appear. Depending on the concrete 168 circumstances, an implementer may decide to address a certain 169 relevant subset of the requirements. 171 The use cases in the context of networks with constrained devices can 172 be found in the companion document [COM-USE]. This informational 173 document provides a list of objectives for discussions and does not 174 aim to be a strict requirements document for all use cases. In fact, 175 there likely is not a single solution that works equally well for all 176 the use cases. 178 1.2. Terminology 180 Concerning constrained devices and networks this document generally 181 builds on the terminology defined in [RFC7228], where the terms 182 Constrained Device, Constrained Network, etc. are defined. 184 The following terms are additionally used throughout this 185 documentation: 187 AMI: (Advanced Metering Infrastructure) A system including hardware, 188 software, and networking technologies that measures, collects, and 189 analyzes energy usage, and communicates with a hierarchically 190 deployed network of metering devices, either on request or on a 191 schedule. 193 C0: Class 0 constrained device as defined in Section 3. of 194 [RFC7228]. 196 C1: Class 1 constrained device as defined in Section 3. of 197 [RFC7228]. 199 C2: Class 2 constrained device as defined in Section 3. of 200 [RFC7228]. 202 Network of Constrained Devices: A network to which constrained 203 devices are connected that may or may not be a Constrained Network 204 (see [RFC7228] for the definition of the term Constrained 205 Network). 207 M2M: (Machine to Machine) stands for the automatic data transfer 208 between devices of different kind. In M2M scenarios a device 209 (such as a sensor or meter) captures an event, which is relayed 210 through a network (wireless, wired or hybrid) to an application. 212 MANET: Mobile Ad-hoc Networks [RFC2501], a self-configuring and 213 infrastructureless network of mobile devices connected by wireless 214 technologies. 216 Smart Grid: An electrical grid that uses communication technologies 217 to gather and act on information in an automated fashion to 218 improve the efficiency, reliability and sustainability of the 219 production and distribution of electricity. 221 Smart Meter: An electrical meter in the context of a Smart Grid. 223 For a detailed discussion on the constrained networks as well as 224 classes of constrained devices and their capabilities please see 225 [RFC7228]. 227 1.3. Network Types and Characteristics in Focus 229 In this document we differentiate following types of networks 230 concerning their transport and communication technologies: 232 (Note that a network in general can involve constrained and non- 233 constrained devices.) 235 1. Wireline non-constrained networks, e.g., an Ethernet-LAN with 236 constrained and non-constrained devices involved. 238 2. A combination of wireline and wireless networks, possibly with a 239 multi-hop connectivity between constrained devices, utilizing 240 dynamic routing in both the wireless and wireline portions of the 241 network. Such networks usually support highly distributed 242 applications with many nodes (e.g., environmental monitoring) and 243 tend to deal with large-scale multipoint-to-point systems. 244 Wireless Mesh Networks (WMN), as a specific variant, use off-the- 245 shelf radio technology such as Wi-Fi, WiMax, and cellular 3G/4G. 246 WMNs are reliable based on the redundancy they offer and have 247 often a more planned deployment to provide dynamic and cost 248 effective connectivity over a certain geographic area. 250 3. A combination of wireline and wireless networks with point-to- 251 point or point-to-multipoint communication generally with single- 252 hop connectivity to constrained devices, utilizing static routing 253 over the wireless network. Such networks support short-range, 254 point-to-point, low-data-rate, source-to-sink type of 255 applications such as RFID systems, light switches, fire and smoke 256 detectors, and home appliances. This type of networks also 257 support confined short-range spaces such as a home, a factory, a 258 building, or the human body. IEEE 802.15.1 (Bluetooth) and IEEE 259 802.15.4 are well-known examples of applicable standards for such 260 networks. By using 6LowPAN (IPv6 over Low-Power Wireless 261 Personal Area Networks) [RFC4919] and RPL (IPv6 Routing Protocol 262 for Low-Power and Lossy Networks) [RFC6550] on top of IEEE 263 802.15.4, multi-hop connectivity and dynamic routing can be 264 achieved. With RPL the IETF has specified a proactive route-over 265 architecture where routing and forwarding is implemented at the 266 network layer. The protocol provides a mechanism whereby 267 multipoint-to-point, point-to-multipoint and point-to-point 268 traffic are supported. 270 4. Self-configuring infrastructureless networks of mobile devices 271 (e.g., Mobile Adhoc networks, MANET) are a particular type of 272 network connected by wireless technologies. Infrastructureless 273 networks are mostly based on point-to-point communications of 274 devices moving independently in any direction and changing the 275 links to other devices frequently. Such devices do act as a 276 router to forward traffic unrelated to their own use. 278 Wireline non-constrained networks with constrained and non- 279 constrained devices are mainly used for specific applications like 280 Building Automation or Infrastructure Monitoring. Wireline and 281 wireless networks with multi-hop or point-to-multipoint connectivity 282 are used e.g., for environmental monitoring as well as transport and 283 mobile applications. 285 Furthermore different network characteristics are determined by 286 multiple dimensions: dynamicity of the topology, bandwidth, and loss 287 rate. In the following, each dimension is explained, and networks in 288 scope for this document are outlined: 290 Network Topology: 292 The topology of a network can be represented as a graph, with edges 293 (i.e., links) and vertices (routers and hosts). Examples of 294 different topologies include "star" topologies (with one central node 295 and multiple nodes in one hop distance), tree structures (with each 296 node having exactly one parent), directed acyclic graphs (with each 297 node having one or more parents), clustered topologies (where one or 298 more "cluster heads" are responsible for a certain area of the 299 network), mesh topologies (fully distributed), etc. 301 Management protocols may take advantage of specific network 302 topologies, for example by distributing large-scale management tasks 303 amongst multiple distributed network management stations (e.g., in 304 case of a mesh topology), or by using a hierarchical management 305 approach (e.g., in case of a tree or clustered topology). These 306 different management topology options are described in Section 1.6. 308 Note that in certain network deployments, such as community ad hoc 309 networks (see the use case "Community Network Applications" in [COM- 310 USE]), the topology is not pre-planned, and thus may be unknown for 311 management purposes. In other use cases, such as industrial 312 applications (see the use case "Industrial Applications" in [COM- 313 USE]), the topology may be designed in advance and therefore taken 314 advantage of when managing the network. 316 Dynamicity of the network topology: 318 The dynamicity of the network topology determines the rate of change 319 of the graph as a function of time. Such changes can occur due to 320 different factors, such as mobility of nodes (e.g., in MANETs or 321 cellular networks), duty cycles (for low-power devices enabling their 322 network interface only periodically to transmit or receive packets), 323 or unstable links (in particular wireless links with strongly 324 fluctuating link quality). 326 Examples of different levels of dynamicity of the topology are 327 Ethernets (with typically a very static topology) on the one side, 328 and low-power and lossy networks (LLNs) on the other side. LLNs 329 nodes are often duty-cycled and operate on unreliable wireless links 330 and are potentially mobile (e.g., for sensor networks). 332 The more dynamic the topology is, the more have routing, transport 333 and application layer protocols to cope with interrupted connectivity 334 and/or longer delays. For example, management protocols (with a 335 given underlying transport protocol) that expect continuous session 336 flows without changes of routes during a communication flow, may fail 337 to operate. 339 Networks with a very low dynamicity (e.g., Ethernet) with no or 340 infrequent topology changes (e.g., less than once every 30 minutes), 341 are in-scope of this document if they are used with constrained 342 devices (see e.g., the use case "Building Automation" in [COM-USE]). 344 Traffic flows: 346 The traffic flow in a network determines from which sources data 347 traffic is sent to which destinations in the network. Several 348 different traffic flows are defined in [RFC7102], including "point- 349 to-point" (P2P), "multipoint-to-point" (MP2P), and "point-to- 350 multipoint" (P2MP) flows as: 352 o P2P: Point-To-Point. This refers to traffic exchanged between two 353 nodes (regardless of the number of hops between the two nodes). 355 o P2MP: Point-to-Multipoint traffic refers to traffic between one 356 node and a set of nodes. This is similar to the P2MP concept in 357 Multicast or MPLS Traffic Engineering. 359 o MP2P: Multipoint-to-Point is used to describe a particular traffic 360 pattern (e.g., MP2P flows collecting information from many nodes 361 flowing inwards towards a collecting sink). 363 If one of these traffic patterns is predominant in a network, 364 protocols (routing, transport, application) may be optimized for the 365 specific traffic flow. For example, in a network with a tree 366 topology and MP2P traffic, collection tree protocols are efficient to 367 send data from the leaves of the tree to the root of the tree, via 368 each node's parent. 370 Bandwidth: 372 The bandwidth of the network is the amount of data that can be sent 373 per unit of time between two communication end-points. It is usually 374 determined by the link with the minimum bandwidth on the path from 375 the source to the destination of data packets. The bandwidth in 376 networks can range from a few Kilobytes per second (such as on some 377 802.15.4 link layers) to many Gigabytes per second (e.g., on fiber 378 optics). 380 For management purposes, the management protocol typically requires 381 to send information between the network management station and the 382 clients, for monitoring or control purposes. If the available 383 bandwidth is insufficient for the management protocol, packets will 384 be buffered and eventually dropped, and thus management is not 385 possible with such a protocol. 387 Networks without bandwidth limitation (e.g., Ethernet) are in-scope 388 of this document if they are used with constrained devices (see the 389 use case "Building Automation" in [COM-USE]). 391 Loss rate: 393 The loss rate (or bit error rate) is the number of bit errors divided 394 by the total number of bits transmitted. For wired networks, loss 395 rates are typically extremely low, e.g., around 10^-12 or 10^-13 for 396 the latest 10Gbit Ethernet. For wireless networks, such as 802.15.4, 397 the bit error rate can be as high as 10^-1 to 1 in case of 398 interferences. Even when using a reliable transport protocol, 399 management operations can fail if the loss rate is too high, unless 400 they are specifically designed to cope with these situations. 402 1.4. Constrained Device Deployment Options 404 We differentiate following deployment options for the constrained 405 devices: 407 o A network of constrained devices that communicate with each other, 409 o Constrained devices, which are connected directly to an IP 410 network, 412 o A network of constrained devices which communicate with a gateway 413 or proxy with more communication capabilities acting possibly as a 414 representative of the device to entities in the non-constrained 415 network 417 o Constrained devices, which are connected to the Internet or an IP 418 network via a gateway/proxy 420 o A hierarchy of constrained devices, e.g., a network of C0 devices 421 connected to one or more C1 devices - connected to one or more C2 422 devices - connected to one or more gateways - connected to some 423 application servers or NMS system 425 o The possibility of device grouping (possibly in a dynamic manner) 426 such as that the grouped devices can act as one logical device at 427 the edge of the network and one device in this group can act as 428 the managing entity 430 1.5. Management Topology Options 432 We differentiate following options for the management of networks of 433 constrained devices: 435 o A network of constrained devices managed by one central manager. 436 A logically centralized management might be implemented in a 437 hierarchical fashion for scalability and robustness reasons. The 438 manager and the management application logic might have a gateway/ 439 proxy in between or might be on different nodes in different 440 networks, e.g., management application running on a cloud server. 442 o Distributed management, where a network of constrained devices is 443 managed by more than one manager. Each manager controls a 444 subnetwork and may communicate directly with other manager 445 stations in a cooperative fashion. The distributed management may 446 be weakly distributed, where functions are broken down and 447 assigned to many managers dynamically, or strongly distributed, 448 where almost all managed things have embedded management 449 functionality and explicit management disappears, which usually 450 comes with the price that the strongly distributed management 451 logic now needs to be managed. 453 o Hierarchical management, where a hierarchy of networks with 454 constrained devices are managed by the managers at their 455 corresponding hierarchy level. I.e., each manager is responsible 456 for managing the nodes in its sub-network. It passes information 457 from its sub-network to its higher-level manager, and disseminates 458 management functions received from the higher-level manager to its 459 sub-network. Hierarchical management is essentially a scalability 460 mechanism, logically the decision-making may be still centralized. 462 1.6. Managing the Constrainedness of a Device or Network 464 The capabilities of a constrained device or network and the 465 constrainedness thereof influence and have an impact on the 466 requirements for the management of such network or devices. 468 Note that the list below gives examples and does not claim 469 completeness. 471 A constrained device: 473 o might only support an unreliable (e.g. lossy) radio link, i.e., 474 the client and server of a management protocol need to gracefully 475 handle incomplete command exchanges or missing commands. 477 o might only be able to go online from time-to-time, where it is 478 reachable, i.e., a command might be necessary to repeat after a 479 longer timeout or the timeout value with which one endpoint waits 480 on a response needs to be sufficiently high. 482 o might only be able to support a limited operating time (e.g., 483 based on the available battery), or may behave as 'sleepy 484 endpoints' setting their network links to a disconnected state 485 during long periods of time i.e., the devices need to economize 486 their energy usage with suitable mechanisms and the managing 487 entity needs to monitor and control the energy status of the 488 constrained devices it manages. 490 o might only be able to support one simple communication protocol, 491 i.e., the management protocol needs to be possible to downscale 492 from constrained (C2) to very constrained (C0) devices with 493 modular implementation and a very basic version with just a few 494 simple commands. 496 o might only be able to support a communication protocol, which is 497 not IP-based. 499 o might only be able to support limited or no user and/or transport 500 security, i.e., the management system needs to support a less- 501 costly and simple but sufficiently secure authentication 502 mechanism. 504 o might not be able to support compression and decompression of 505 exchanged data based on limited CPU power, i.e., an intermediary 506 entity which is capable of data compression should be able to 507 communicate with both, devices that support data compression 508 (e.g., C2) and devices that do not support data compression (e.g., 509 C1 and C0). 511 o might only be able to support a simple encryption, i.e., it would 512 be beneficial if the devices use cryptographic algorithms that are 513 supported in hardware and the encryption used is efficient in 514 terms of memory and CPU usage. 516 o might only be able to communicate with one single managing entity 517 and cannot support the parallel access of many managing entities. 519 o might depend on a self-configuration feature, i.e., the managing 520 entity might not know all devices in a network and the device 521 needs to be able to initiate connection setup for the device 522 configuration. 524 o might depend on self- or neighbor-monitoring feature, i.e., the 525 managing entity might not be able to monitor all devices in a 526 network continuously. 528 o might only be able to communicate with its neighbors, i.e., the 529 device should be able to get its configuration from a neighbor. 531 o might only be able to support parsing of data models with limited 532 size, i.e., the device data models need to be compact containing 533 the most necessary data and if possible parsable as a stream. 535 o might only be able to support a limited or no failure detection, 536 i.e., the managing entity needs to handle the situation, where a 537 failure does not get detected or gets detected late gracefully 538 e.g., with asking repeatedly. 540 o might only be able to support the reporting of just one or a 541 limited set failure types. 543 o might only be able to support a limited set of notifications, 544 possible only an "I-am-alive" message. 546 o might only be able to support a soft-reset from failure recovery. 548 o might possibly generate a large amount of redundant reporting 549 data, i.e., the intermediary management entity (see [RFC7252]) 550 should be able to filter and aggregate redundant data. 552 A network of constrained devices: 554 o might only support an unreliable (e.g. lossy) radio link, i.e., 555 the client and server of a management protocol need to repeat 556 commands as necessary or gracefully ignore incomplete commands. 558 o might be necessary to manage based on multicast communication, 559 i.e., the managing entity needs to be prepared to configure many 560 devices at once based on the same data model. 562 o might have a very large topology supporting 10,000 or more nodes 563 for some applications and as such node naming is a specific issue 564 for constrained networks. 566 o needs to support self-organization, i.e., given the large number 567 of nodes and their potential placement in hostile locations and 568 frequently changing topology, manual configuration of nodes is 569 typically not feasible. As such, the network would benefit from 570 the ability to reconfigure itself so that it can continue to 571 operate properly and support reliable connectivity. 573 o might need a management solution that is energy-efficient, using 574 as little wireless bandwidth as possible since communication is 575 highly energy demanding. 577 o needs to support localization schemes to determine the location of 578 devices since the devices might be moving and location information 579 is important for some applications. 581 o needs a management solution that is scalable as the network may 582 consist of thousands of nodes and may need to be extended 583 continuously. 585 o needs to provide fault tolerance. Faults in network operation 586 including hardware and software errors or failures detected by the 587 transport protocol should be handled smoothly. In such a case it 588 should be possible to run the protocol possibly at a reduced level 589 but avoiding to fail completely. E.g., self-monitoring mechanisms 590 or graceful degradation of features can be used to provide fault 591 tolerance. 593 o might require new management capabilities: for example, network 594 coverage information and a constrained device power-distribution- 595 map. 597 o might require a new management function for data management, since 598 the type and amount of data collected in constrained networks is 599 different from those of the traditional networks. 601 o might also need energy-efficient key management. 603 1.7. Configuration and Monitoring Functionality Levels 605 Devices often differ significantly on the level of configuration 606 management support they provide. This document classifies the 607 configuration management functionality as follows: 609 CL0: Devices are pre-configured and allow no runtime configuration 610 changes. Configuration parameters are often hard coded and 611 compiled directly into the firmware image. 613 CL1: Devices have explicit configuration objects. However, changes 614 require a restart of the device to take effect. 616 CL2: Devices allow management systems to replace the entire 617 configuration (or pre-determined subsets) in bulk. Configuration 618 changes take effect by soft-restarts of the system (or 619 subsystems). 621 CL3: Devices allow management systems to modify configuration 622 objects without bulk replacements and changes take effect 623 immediately. 625 CL4: Devices support multiple configuration datastores and they 626 might distinguish between the currently running and the next 627 startup configuration. 629 CL5: Devices support configuration datastore locking and device- 630 local configuration change transactions, i.e., either all 631 configuration changes are applied or none of them. 633 CL6: Devices support configuration change transactions across 634 devices. 636 This document defines a classification of devices with regards to 637 different levels of monitoring support. In general a device may be 638 in several of the levels listed below: 640 ML0: Devices push pre-defined monitoring data. 642 ML1: Devices allow management systems to pull pre-defined monitoring 643 data. 645 ML2: Devices allow management systems to pull user-defined filtered 646 subsets of monitoring data. 648 ML3: Devices are able to locally process monitoring data in order to 649 detect threshold crossings or to aggregate data. 651 At the time of this writing, constrained devices often implement a 652 combination of one of CL0-CL2 with one of ML0-ML1. 654 2. Problem Statement 656 The terminology for the "Internet of Things" is still nascent, and 657 depending on the network type or layer in focus diverse technologies 658 and terms are in use. Common to all these considerations is the 659 "Things" or "Objects" are supposed to have physical or virtual 660 identities using interfaces to communicate. In this context, we need 661 to differentiate between the Constrained and Smart Devices identified 662 by an IP address compared to virtual entities such as Smart Objects, 663 which can be identified as a resource or a virtual object by using a 664 unique identifier. Furthermore, the smart devices usually have a 665 limited memory and CPU power as well as aim to be self-configuring 666 and easy to deploy. 668 However, the constraints of the network nodes require a rethinking of 669 the protocol characteristics concerning power consumption, 670 performance, bandwidth consumption, memory, and CPU usage. As such, 671 there is a demand for protocol simplification, energy-efficient 672 communication, less CPU usage and smaller memory footprint. 674 On the application layer the IETF is already developing protocols 675 like the Constrained Application Protocol (CoAP) [RFC7252] enabling 676 the communication of constrained devices and networks e.g., for smart 677 energy applications or home automation environments. The deployment 678 of such an environment involves in fact many, in some scenarios up to 679 million constrained devices (e.g., smart meters), which produce a 680 large amount of data. This data needs to be collected, filtered, and 681 pre-processed for further use in diverse services. 683 Considering the high number of nodes to deploy, one has to think 684 about the manageability aspects of the smart devices and plan for 685 easy deployment, configuration, and management of the networks of 686 constrained devices as well as the devices themselves. Consequently, 687 seamless monitoring and self-configuration of such network nodes 688 becomes more and more imperative. Self-configuration and self- 689 management is already a reality in the standards of some of the 690 bodies such as 3GPP. To introduce self-configuration of smart 691 devices successfully a device-initiated connection establishment is 692 often required. 694 A simple and efficient application layer protocol, such as CoAP, is 695 essential to address the issue of efficient object-to-object 696 communication and information exchange. Such an information exchange 697 should be done based on interoperable data models to enable the 698 exchange and interpretation of diverse application and management 699 related data. 701 In an ideal world, we would have only one network management protocol 702 for monitoring, configuration, and exchanging management data, 703 independently of the type of the network (e.g., Smart Grid, wireless 704 access, or core network). Furthermore, it would be desirable to 705 derive the basic data models for constrained devices from the core 706 models used today to enable reuse of functionality and end-to-end 707 information exchange. However, the current management protocols seem 708 to be too heavyweight compared to the capabilities the constrained 709 devices have and are not applicable directly for the use in a network 710 of constrained devices. Furthermore, the data models addressing the 711 requirements of such smart devices need yet to be designed. 713 The IETF so far has not developed any specific technologies for the 714 management of constrained devices and the networks comprised by 715 constrained devices. IP-based sensors or constrained devices in such 716 an environment, i.e., devices with very limited memory and CPU 717 resources, use today, e.g., application-layer protocols to do simple 718 resource management and monitoring. This might be sufficient for 719 some basic cases, however, there is a need to reconsider the network 720 management mechanisms based on the new, changed, as well as reduced 721 requirements coming from smart devices and the network of such 722 constrained devices. Albeit it is questionable whether we can take 723 the same comprehensive approach we use in an IP network also for the 724 management of constrained devices. Hence, the management of a 725 network with constrained devices is necessary to design in a 726 simplified and less complex manner. 728 As Section 1.6 highlights, there are diverse characteristics of 729 constrained devices or networks, which stem from their 730 constrainedness and therefore have an impact on the requirements for 731 the management of such a network with constrained devices. The use 732 cases discussed in [COM-USE] show that the requirements on 733 constrained networks are manifold and need to be analyzed from 734 different angles, e.g., concerning the design of the management 735 architecture, the selection of the appropriate protocol features as 736 well as the specific issues which are new in the context of 737 constrained devices. Examples of such issues are e.g., the careful 738 management of the scarce energy resources, the necessity for self- 739 organization and self-management of such devices but also the 740 implementation considerations to enable the use of common 741 communication technologies on a constrained hardware in an efficient 742 manner. For an exhaustive list of issues and requirements that need 743 to be addressed for the management of a network with constrained 744 devices please see Section 1.6 and Section 3. 746 3. Requirements on the Management of Networks with Constrained Devices 748 This section describes the requirements categorized by management 749 areas listed in subsections. 751 Note that the requirements listed in this section have been separated 752 from the context in which they may appear. This document in general 753 does not recommend the realization of any subset of the described 754 requirements. As such this document avoids selecting any of the 755 requirements as mandatory to implement. A device might be able to 756 provide only a particular selected set of requirements and might not 757 be capable to provide all requirements in this document. On the 758 other hand a device vendor might select a specific relevant subset of 759 the requirements to implement. 761 The following template is used for the definition of the 762 requirements. 764 Req-ID: An ID composed by two numbers: section number indicating the 765 topic area and a unique three-digit number per section 767 Title: The title of the requirement. 769 Description: The rational and description of the requirement. 771 Source: The origin of the requirement and the matching use case or 772 application. For the discussion of referred use cases for 773 constrained management please see [COM-USE]. 775 Requirement Type: Functional Requirement, Non-Functional 776 Requirement. A functional requirement is related to a function or 777 component. As such functional requirements may be technical 778 details, or specific functionality that define what a system is 779 supposed to accomplish. Non-functional requirements (also known 780 as design constraints or quality requirements) impose 781 implementation-related considerations such as performance 782 requirements, security, or reliability. 784 Device type: The device types by which this requirement can be 785 supported: C0, C1 and/or C2. 787 Priority: The priority of the requirement showing its importance for 788 a particular type of device: High, Medium, and Low. The priority 789 of a requirement can be High e.g., for a C2 device but Low for a 790 C1 or C0 device as the realization of complex features in a C1 791 device is in many cases not possible. 793 3.1. Management Architecture/System 795 Req-ID: 1.001 797 Title: Support multiple device classes within a single network. 799 Description: Larger networks usually consist of devices belonging to 800 different device classes (e.g., constrained mesh endpoints and 801 less constrained routers) communicating with each other. Hence, 802 the management architecture must be applicable to networks that 803 have a mix of different device classes. See Section 3. of 804 [RFC7228] for the definition of Constrained Device Classes. 806 Source: All use cases. 808 Requirement Type: Non-Functional Requirement 810 Device type: C1 and/or C2 812 Priority: High 814 --- 816 Req-ID: 1.002 818 Title: Management scalability. 820 Description: The management architecture must be able to scale with 821 the number of devices involved and operate efficiently in any 822 network size and topology. This implies that e.g., the managing 823 entity is able to handle large amounts of device monitoring data 824 and the management protocol is not sensitive to the decrease of 825 the time between two client requests. To achieve good 826 scalability, caching techniques, in-network data aggregation 827 techniques, hierarchical management models may be used. 829 Source: General requirement for all use cases to enable large scale 830 networks. 832 Requirement Type: Non-Functional Requirement 834 Device type: C0, C1, and C2 836 Priority: High 838 --- 840 Req-ID: 1.003 842 Title: Hierarchical management 844 Description: Provide a means of hierarchical management, i.e., 845 provide intermediary management entities on different levels, 846 which can take over the responsibility for the management of a 847 sub-hierarchy of the network of constraint devices. The 848 intermediary management entity can e.g., support management data 849 aggregation to handle e.g., high-frequent monitoring data or 850 provide a caching mechanism for the uplink and downlink 851 communication. Hierarchical management contributes to management 852 scalability. 854 Source: Use cases where a large amount of devices are deployed with 855 a hierarchical topology. 857 Requirement Type: Non-Functional Requirement 859 Device type: Managing and intermediary entities. 861 Priority: Medium 863 --- 865 Req-ID: 1.004 867 Title: Minimize state maintained on constrained devices. 869 Description: The amount of state that needs to be maintained on 870 constrained devices should be minimized. This is important in 871 order to save memory (especially relevant for C0 and C1 devices) 872 and in order to allow devices to restart for example to apply 873 configuration changes or to recover from extended periods of 874 inactivity. 876 Note: One way to achieve this is to adopt a RESTful architecture 877 that minimizes the amount of state maintained by managed 878 constrained devices and that makes resources of a device 879 addressable via URIs. 881 Source: Basic requirement which concerns all use cases. 883 Requirement Type: Functional Requirement 885 Device type: C0, C1, and C2 887 Priority: High 889 --- 891 Req-ID: 1.005 893 Title: Automatic re-synchronization with eventual consistency. 895 Description: To support large scale networks, where some constrained 896 devices may be offline at any point in time, it is necessary to 897 distribute configuration parameters in a way that allows temporary 898 inconsistencies but eventually converges, after a sufficiently 899 long period of time without further changes, towards global 900 consistency. 902 Source: Use cases with large scale networks with many devices. 904 Requirement Type: Functional Requirement 906 Device type: C0, C1, and C2 908 Priority: High 910 --- 912 Req-ID: 1.006 914 Title: Support for lossy links and unreachable devices 915 Description: Some constrained devices will only be able to support 916 lossy and unreliable links characterized by a limited data rate, a 917 high latency, and a high transmission error rate. Furthermore, 918 constrained devices often duty cycle their radio or the whole 919 device in order to save energy. Some classes of devices labeled 920 as 'sleepy endpoints' set their network links to a disconnected 921 state during long periods of time. In all cases the management 922 system must not assume that constrained devices are always 923 reachable. 925 Source: Basic requirement for networks of constrained devices with 926 unreliable links and constrained devices that sleep to save 927 energy. 929 Requirement Type: Non-Functional Requirement 931 Device type: C0, C1, and C2 933 Priority: High 935 --- 937 Req-ID: 1.007 939 Title: Network-wide configuration 941 Description: Provide means by which the behavior of the network can 942 be specified at a level of abstraction (network-wide 943 configuration) higher than a set of configuration information 944 specific to individual devices. It is useful to derive the device 945 specific configuration from the network-wide configuration. Such 946 a repository can be used to configure pre-defined device or 947 protocol parameters for the whole network. Furthermore, such a 948 network-wide view can be used to monitor and manage a group of 949 routers or a whole network. E.g., monitoring the performance of a 950 network requires additional information other than what can be 951 acquired from a single router using a management protocol. 953 Note: The identification of the relevant subset of the policies to 954 be provisioned is according to the capabilities of each device and 955 can be obtained from a pre-configured data-repository. 957 Source: In general all use cases of network and device configuration 958 based on a network view in a top-down manner. 960 Requirement Type: Non-Functional Requirement 962 Device type: C0, C1, and C2 963 Priority: Medium 965 --- 967 Req-ID: 1.008 969 Title: Distributed management 971 Description: Provide a means of simple distributed management, where 972 a network of constrained devices can be managed or monitored by 973 more than one manager. Since the connectivity to a server cannot 974 be guaranteed at all times, a distributed approach may provide a 975 higher reliability, at the cost of increased complexity. This 976 requirement implies the handling of data consistency in case of 977 concurrent read and write access to the device datastore. It 978 might also happen that no management (configuration) server is 979 accessible and the only reachable node is a peer device. In this 980 case the device should be able to obtain its configuration from 981 peer devices. 983 Source: Use cases where the count of devices to manage is high. 985 Requirement Type: Non-Functional Requirement 987 Device type: C1 and C2 989 Priority: Medium 991 3.2. Management Protocols and Data Models 993 Req-ID: 2.001 995 Title: Modular implementation of management protocols 997 Description: Management protocols should be specified to allow for 998 modular implementations, i.e., it should be possible to implement 999 only a basic set of protocol primitives on highly constrained 1000 devices while devices with additional resources may provide more 1001 support for additional protocol primitives. See Section 1.7 for a 1002 discussion on the level of configuration management and monitoring 1003 support constrained devices may provide. 1005 Source: Basic requirement interesting for all use cases. 1007 Requirement Type: Non-Functional Requirement 1009 Device type: C0, C1, and C2 1010 Priority: High 1012 --- 1014 Req-ID: 2.002 1016 Title: Compact encoding of management data 1018 Description: The encoding of management data should be compact and 1019 space efficient, enabling small message sizes. 1021 Source: General requirement to save memory for the receiver buffer 1022 and on-air bandwidth. 1024 Requirement Type: Functional Requirement 1026 Device type: C0, C1, and C2 1028 Priority: High 1030 --- 1032 Req-ID: 2.003 1034 Title: Compression of management data or complete messages 1036 Description: Management data exchanges can be further optimized by 1037 applying data compression techniques or delta encoding techniques. 1038 Compression typically requires additional code size and some 1039 additional buffers and/or the maintenance of some additional state 1040 information. For C0 devices compression may not be feasible. 1042 Source: Use cases where it is beneficial to reduce transmission time 1043 and bandwidth, e.g., mobile applications which require to save on- 1044 air bandwidth. 1046 Requirement Type: Functional Requirement 1048 Device type: C1 and C2 1050 Priority: Medium 1052 --- 1054 Req-ID: 2.004 1056 Title: Mapping of management protocol interactions 1057 Description: It is desirable to have a lossless automated mapping 1058 between the management protocol used to manage constrained devices 1059 and the management protocols used to manage regular devices. In 1060 the ideal case, the same core management protocol can be used with 1061 certain restrictions taking into account the resource limitations 1062 of constrained devices. However, for very resource constrained 1063 devices, this goal might not be achievable. 1065 Source: Use cases where high-frequent interaction with the 1066 management system of a non-constrained network is required. 1068 Requirement Type: Functional Requirement 1070 Device type: C1 and C2 1072 Priority: Medium 1074 --- 1076 Req-ID: 2.005 1078 Title: Consistency of data models with the underlying information 1079 model 1081 Description: The data models used by the management protocol must be 1082 consistent with the information model used to define data models 1083 for non-constrained networks. This is essential to facilitate the 1084 integration of the management of constrained networks with the 1085 management of non-constrained networks. Using an underlying 1086 information model for future data model design enables furthermore 1087 top-down model design and model reuse as well as data 1088 interoperability (i.e., exchange of management information between 1089 the constrained and non-constrained networks). This is a strong 1090 requirement, even despite the fact that the underlying information 1091 models are often not explicitly documented in the IETF. 1093 Source: General requirement to support data interoperability, 1094 consistency and model reuse. 1096 Requirement Type: Non-Functional Requirement 1098 Device type: C0, C1, and C2 1100 Priority: High 1102 --- 1104 Req-ID: 2.006 1105 Title: Lossless mapping of management data models. 1107 Description: It is desirable to have a lossless automated mapping 1108 between the management data models used to manage regular devices 1109 and the management data models used for managing constrained 1110 devices. In the ideal case, the same core data models can be used 1111 with certain restrictions taking into account the resource 1112 limitations of constrained devices. However, for very resource 1113 constrained devices, this goal might not be achievable. 1115 Source: Use cases where consistent data exchange with the management 1116 system of a non-constrained network is required. 1118 Requirement Type: Functional Requirement 1120 Device type: C2 1122 Priority: Medium 1124 --- 1126 Req-ID: 2.007 1128 Title: Protocol extensibility 1130 Description: Provide means of extensibility for the management 1131 protocol, i.e., by adding new protocol messages or mechanisms that 1132 can deal with changing requirements on a supported message and 1133 data types effectively, without causing interoperability problems 1134 or having to replace/update large amount of deployed devices. 1136 Source: Basic requirement useful for all use cases. 1138 Requirement Type: Functional Requirement 1140 Device type: C0, C1, and C2 1142 Priority: High 1144 3.3. Configuration Management 1146 Req-ID: 3.001 1148 Title: Self-configuration capability 1150 Description: Automatic configuration and re-configuration of devices 1151 without manual intervention. Compared to the traditional 1152 management of devices where the management application is the 1153 central entity configuring the devices, in the auto-configuration 1154 scenario the device is the active part and initiates the 1155 configuration process. Self-configuration can be initiated during 1156 the initial configuration or for subsequent configurations, where 1157 the configuration data needs to be refreshed. Self-configuration 1158 should be also supported during the initialization phase or in the 1159 event of failures, where prior knowledge of the network topology 1160 is not available or the topology of the network is uncertain. 1162 Source: In general all use cases requiring easy deployment and 1163 plug&play behavior as well as easy maintenance of many constrained 1164 devices. 1166 Requirement Type: Functional Requirement 1168 Device type: C0, C1, and C2 1170 Priority: High for device categories C0 and C1, Medium for C2. 1172 --- 1174 Req-ID: 3.002 1176 Title: Capability discovery 1178 Description: Enable the discovery of supported optional management 1179 capabilities of a device and their exposure via at least one 1180 protocol and/or data model. 1182 Source: Use cases where the device interaction with other devices or 1183 applications is a function of the level of support for its 1184 capabilities. 1186 Requirement Type: Functional Requirement 1188 Device type: C1 and C2 1190 Priority: Medium 1192 --- 1194 Req-ID: 3.003 1196 Title: Asynchronous transaction support 1198 Description: Provide configuration management with asynchronous 1199 (event-driven) transaction support. Configuration operations must 1200 support a transactional model, with asynchronous indications that 1201 the transaction was completed. 1203 Source: Use cases that require transaction-oriented processing 1204 because of reliability or distributed architecture functional 1205 requirements. 1207 Requirement Type: Functional Requirement 1209 Device type: C1 and C2 1211 Priority: Medium 1213 --- 1215 Req-ID: 3.004 1217 Title: Network reconfiguration 1219 Description: Provide a means of iterative network reconfiguration in 1220 order to recover the network from node and communication failures. 1221 The network reconfiguration can be failure-driven and self- 1222 initiated (automatic reconfiguration). The network 1223 reconfiguration can be also performed on the whole hierarchical 1224 structure of a network (network topology). 1226 Source: Practically all use cases, as network connectivity is a 1227 basic requirement. 1229 Requirement Type: Functional Requirement 1231 Device type: C0, C1, and C2 1233 Priority: Medium 1235 3.4. Monitoring Functionality 1237 Req-ID: 4.001 1239 Title: Device status monitoring 1241 Description: Provide a monitoring function to collect and expose 1242 information about device status and exposing it via at least one 1243 management interface. The device monitoring might make use of the 1244 hierarchical management through the intermediary entities and the 1245 caching mechanism. The device monitoring might also make use of 1246 neighbor-monitoring (fault detection in local network) to support 1247 fast fault detection and recovery, e.g., in a scenario where a 1248 managing entity is unreachable and a neighbor can take over the 1249 monitoring responsibility. 1251 Source: All use cases 1253 Requirement Type: Functional Requirement 1255 Device type: C0, C1, and C2 1257 Priority: High, Medium for neighbor-monitoring. 1259 --- 1261 Req-ID: 4.002 1263 Title: Energy status monitoring 1265 Description: Provide a monitoring function to collect and expose 1266 information about device energy parameters and usage (e.g., 1267 battery level and average power consumption). 1269 Source: Use case Energy Management 1271 Requirement Type: Functional Requirement 1273 Device type: C0, C1, and C2 1275 Priority: High for energy reporting devices, Low for others. 1277 --- 1279 Req-ID: 4.003 1281 Title: Monitoring of current and estimated device availability 1283 Description: Provide a monitoring function to collect and expose 1284 information about current device availability (energy, memory, 1285 computing power, forwarding plane utilization, queue buffers, 1286 etc.) and estimation of remaining available resources. 1288 Source: All use cases. Note that monitoring energy resources (like 1289 battery status) may be required on all kinds of devices. 1291 Requirement Type: Functional Requirement 1293 Device type: C0, C1, and C2 1295 Priority: Medium 1296 --- 1298 Req-ID: 4.004 1300 Title: Network status monitoring 1302 Description: Provide a monitoring function to collect, analyze and 1303 expose information related to the status of a network or network 1304 segments connected to the interface of the device. 1306 Source: All use cases. 1308 Requirement Type: Functional Requirement 1310 Device type: C1 and C2 1312 Priority: Low, based on the realization complexity. 1314 --- 1316 Req-ID: 4.005 1318 Title: Self-monitoring 1320 Description: Provide self-monitoring (local fault detection) feature 1321 for fast fault detection and recovery. 1323 Source: Use cases where the devices cannot be monitored centrally in 1324 appropriate manner, e.g., self-healing is required. 1326 Requirement Type: Functional Requirement 1328 Device type: C1 and C2 1330 Priority: High for C2, Medium for C1 1332 --- 1334 Req-ID: 4.006 1336 Title: Performance monitoring 1338 Description: The device will provide a monitoring function to 1339 collect and expose information about the basic performance 1340 parameter of the device. The performance management functionality 1341 might make use of the hierarchical management through the 1342 intermediary devices. 1344 Source: Use cases Building automation, and Transport applications 1346 Requirement Type: Functional Requirement 1348 Device type: C1 and C2 1350 Priority: Low 1352 --- 1354 Req-ID: 4.007 1356 Title: Fault detection monitoring 1358 Description: The device will provide fault detection monitoring. 1359 The system collects information about network states in order to 1360 identify whether faults have occurred. In some cases the 1361 detection of the faults might be based on the processing and 1362 analysis of the parameters retrieved from the network or other 1363 devices. In case of C0 devices the monitoring might be limited to 1364 the check whether the device is alive or not. 1366 Source: Use cases Environmental Monitoring, Building Automation, 1367 Energy Management, Infrastructure Monitoring 1369 Requirement Type: Functional Requirement 1371 Device type: C0, C1 and C2 1373 Priority: Medium 1375 --- 1377 Req-ID: 4.008 1379 Title: Passive and reactive monitoring 1381 Description: The device will provide passive and reactive monitoring 1382 capabilities. The system or manager collects information about 1383 device components and network states (passive monitoring) and may 1384 perform postmortem analysis of collected data. In case events of 1385 interest have occurred the system or manager can adaptively react 1386 (reactive monitoring), e.g., reconfigure the network. Typically 1387 actions (re-actions) will be executed or sent as commands by the 1388 management applications. 1390 Source: Diverse use cases relevant for device status and network 1391 state monitoring 1393 Requirement Type: Functional Requirement 1395 Device type: C2 1397 Priority: Medium 1399 --- 1401 Req-ID: 4.009 1403 Title: Recovery 1405 Description: Provide local, central and hierarchical recovery 1406 mechanisms (recovery is in some cases achieved by recovering the 1407 whole network of constrained devices). 1409 Source: Use cases Industrial applications, Home and Building 1410 Automation, Mobile Applications that involve different forms of 1411 clustering or area managers. 1413 Requirement Type: Functional Requirement 1415 Device type: C2 1417 Priority: Medium 1419 --- 1421 Req-ID: 4.010 1423 Title: Network topology discovery 1425 Description: Provide a network topology discovery capability (e.g., 1426 use of topology extraction algorithms to retrieve the network 1427 state) and a monitoring function to collect and expose information 1428 about the network topology. 1430 Source: Use cases Community Network Applications and Mobile 1431 Applications 1433 Requirement Type: Functional Requirement 1435 Device type: C1 and C2 1437 Priority: Low, based on the realization complexity. 1439 --- 1440 Req-ID: 4.011 1442 Title: Notifications 1444 Description: The device will provide the capability of sending 1445 notifications on critical events and faults. 1447 Source: All use cases. 1449 Requirement Type: Functional Requirement 1451 Device type: C0, C1, and C2 1453 Priority: Medium for C2, Low for C0 and C1 1455 --- 1457 Req-ID: 4.012 1459 Title: Logging 1461 Description: The device will provide the capability of building, 1462 keeping, and allowing retrieval of logs of events (including but 1463 not limited to critical faults and alarms). 1465 Source: Use cases Industrial Applications, Building Automation, 1466 Infrastructure monitoring 1468 Requirement Type: Functional Requirement 1470 Device type: C2 1472 Priority: High for some medical or industrial applications, Medium 1473 otherwise 1475 3.5. Self-management 1477 Req-ID: 5.001 1479 Title: Self-management - Self-healing 1481 Description: Enable event-driven and/or periodic self-management 1482 functionality in a device. The device should be able to react in 1483 case of a failure e.g., by initiating a fully or partly reset and 1484 initiate a self-configuration or management data update as 1485 necessary. A device might be further able to check for failures 1486 cyclically or schedule-controlled to trigger self-management as 1487 necessary. It is a matter of device design and subject for 1488 discussion how much self-management a C1 device can support. A 1489 minimal failure detection and self-management logic is assumed to 1490 be generally useful for the self-healing of a device. 1492 Source: The requirement generally relates to all use cases in this 1493 document. 1495 Requirement Type: Functional Requirement 1497 Device type: C1 and C2 1499 Priority: High for C2, Medium for C1 1501 3.6. Security and Access Control 1503 Req-ID: 6.001 1505 Title: Authentication of management system and devices. 1507 Description: Systems having a management role must be properly 1508 authenticated to the device such that the device can exercise 1509 proper access control and in particular distinguish rightful 1510 management systems from rogue systems. On the other hand managed 1511 devices must authenticate themselves to systems having a 1512 management role such that management systems can protect 1513 themselves from rogue devices. In certain application scenarios, 1514 it is possible that a large number of devices need to be 1515 (re)started at about the same time. Protocols and authentication 1516 systems should be designed such that a large number of devices 1517 (re)starting simultaneously does not negatively impact the device 1518 authentication process. 1520 Source: Basic security requirement for all use cases. 1522 Requirement Type: Functional Requirement 1524 Device type: C0, C1, and C2 1526 Priority: High, Medium for the (re)start of a large number of 1527 devices 1529 --- 1531 Req-ID: 6.002 1533 Title: Support suitable security bootstrapping mechanisms 1534 Description: Mechanisms should be supported that simplify the 1535 bootstrapping of device that is the discovery of newly deployed 1536 devices in order to provide them with appropriate access control 1537 permissions. 1539 Source: Basic security requirement for all use cases. 1541 Requirement Type: Functional Requirement 1543 Device type: C0, C1, and C2 1545 Priority: High 1547 --- 1549 Req-ID: 6.003 1551 Title: Access control on management system and devices 1553 Description: Systems acting in a management role must provide an 1554 access control mechanism that allows the security administrator to 1555 restrict which devices can access the managing system (e.g., using 1556 an access control white list of known devices). On the other hand 1557 managed constrained devices must provide an access control 1558 mechanism that allows the security administrator to restrict how 1559 systems in a management role can access the device (e.g., no- 1560 access, read-only access, and read-write access). 1562 Source: Basic security requirement for use cases where access 1563 control is essential. 1565 Requirement Type: Functional Requirement 1567 Device type: C0, C1, and C2 1569 Priority: High 1571 --- 1573 Req-ID: 6.004 1575 Title: Select cryptographic algorithms that are efficient in both 1576 code space and execution time. 1578 Description: Cryptographic algorithms have a major impact in terms 1579 of both code size and overall execution time. It is therefore 1580 necessary to select mandatory to implement cryptographic 1581 algorithms that are reasonable to implement with the available 1582 code space and that have a small impact at runtime. Furthermore 1583 some wireless technologies (e.g., IEEE 802.15.4) require the 1584 support of certain cryptographic algorithms. It might be useful 1585 to choose algorithms that are likely to be supported in wireless 1586 chipsets for certain wireless technologies. 1588 Source: Generic requirement to reduce the footprint and CPU usage of 1589 a constrained device. 1591 Requirement Type: Non-Functional Requirement 1593 Device type: C0, C1, and C2 1595 Priority: High, Medium for hardware-supported algorithms. 1597 3.7. Energy Management 1599 Req-ID: 7.001 1601 Title: Management of energy resources 1603 Description: Enable managing power resources in the network, e.g., 1604 reduce the sampling rate of nodes with critical battery and reduce 1605 node transmission power, put nodes to sleep, put single interfaces 1606 to sleep, reject a management job based on available energy, 1607 criteria e.g., importance levels pre-defined by the management 1608 application, etc. (e.g., a task marked as essential can be 1609 executed even if the energy level is low). The device may further 1610 implement standard data models for energy management and expose it 1611 through a management protocol interface, e.g., EMAN MIB modules 1612 and extensions (work ongoing). It might be necessary to use a 1613 subset of EMAN MIBs for C1 and C2 devices. 1615 Source: Use case Energy Management 1617 Requirement Type: Functional Requirement 1619 Device type: C0, C1, and C2 1621 Priority: Medium for the use case Energy Management, Low otherwise. 1623 --- 1625 Req-ID: 7.002 1627 Title: Support of energy-optimized communication protocols 1628 Description: Use of an optimized communication protocol to minimize 1629 energy usage for the device (radio) receiver/transmitter, on-air 1630 bandwidth (protocol efficiency), reduced amount of data 1631 communication between nodes (implies data aggregation and 1632 filtering but also a compact format for the transferred data). 1634 Source: Use cases Energy Management and Mobile Applications. 1636 Requirement Type: Non-Functional Requirement 1638 Device type: C2 1640 Priority: Medium 1642 --- 1644 Req-ID: 7.003 1646 Title: Support for layer 2 energy-aware protocols 1648 Description: The device will support layer 2 energy management 1649 protocols (e.g., energy-efficient Ethernet IEEE 802.3az) and be 1650 able to report on these. 1652 Source: Use case Energy Management 1654 Requirement Type: Non-Functional Requirement 1656 Device type: C0, C1, and C2 1658 Priority: Medium 1660 --- 1662 Req-ID: 7.004 1664 Title: Dying gasp 1666 Description: When energy resources draw below the red line level, 1667 the device will send a dying gasp notification and perform if 1668 still possible a graceful shutdown including conservation of 1669 critical device configuration and status information. 1671 Source: Use case Energy Management 1673 Requirement Type: Functional Requirement 1675 Device type: C0, C1, and C2 1676 Priority: Medium 1678 3.8. Software Distribution 1680 Req-ID: 8.001 1682 Title: Group-based provisioning 1684 Description: Support group-based provisioning, i.e., firmware update 1685 and configuration management, of a large set of constrained 1686 devices with eventual consistency and coordinated reload times. 1687 The device should accept group-based configuration management 1688 based on bulk commands, which aim similar configurations of a 1689 large set of constrained devices of the same type in a given 1690 group, and which may share a common data model. Activation of 1691 configuration may be based on pre-loaded sets of default values. 1693 Source: All use cases 1695 Requirement Type: Non-Functional Requirement 1697 Device type: C0, C1, and C2 1699 Priority: Medium 1701 3.9. Traffic Management 1703 Req-ID: 9.001 1705 Title: Congestion avoidance 1707 Description: Support congestion control principles as defined in 1708 [RFC2914], e.g., the ability to avoid congestion by modifying the 1709 device's reporting rate for periodical data (which is usually 1710 redundant) based on the importance and reliability level of the 1711 management data. This functionality is usually controlled by the 1712 managing entity, where the managing entity marks the data as 1713 important or relevant for reliability. However, reducing a 1714 device's reporting rate can also be initiated by a device if it is 1715 able to detect congestion or has insufficient buffer memory. 1717 Source: Use cases with high reporting rate and traffic e.g., AMI or 1718 M2M. 1720 Requirement Type: Non-Functional Requirement 1722 Device type: C1 and C2 1723 Priority: Medium 1725 --- 1727 Req-ID: 9.002 1729 Title: Reroute traffic 1731 Description: Provide the ability for network nodes to redirect 1732 traffic from overloaded intermediary nodes in a network to another 1733 path in order to prevent congestion on a central server and in the 1734 primary network. 1736 Source: Use cases with high reporting rate and traffic e.g., AMI or 1737 M2M. 1739 Requirement Type: Non-Functional Requirement 1741 Device type: Intermediary entity in the network. 1743 Priority: Medium 1745 --- 1747 Req-ID: 9.003 1749 Title: Traffic Shaping. 1751 Description: Provide the ability to apply traffic shaping policies 1752 to incoming and outgoing links on an overloaded intermediary node 1753 as necessary in order to reduce the amount of traffic in the 1754 network. 1756 Source: Use cases with high reporting rate and traffic e.g., AMI or 1757 M2M. 1759 Requirement Type: Non-Functional Requirement 1761 Device type: Intermediary entity in the network. 1763 Priority: Medium 1765 3.10. Transport Layer 1767 Req-ID: 10.001 1769 Title: Scalable transport layer 1770 Description: Enable the use of a scalable transport layer, i.e., not 1771 sensitive to a high rate of incoming client requests, which is 1772 useful for applications requiring frequent access to device data. 1774 Source: Applications with high frequent access to the device data. 1776 Requirement Type: Non-Functional Requirement 1778 Device type: C0, C1 and C2 1780 Priority: Medium 1782 --- 1784 Req-ID: 10.002 1786 Title: Reliable unicast transport of messages 1788 Description: Diverse applications need a reliable transport of 1789 messages. The reliability might be achieved based on a transport 1790 protocol such as TCP or can be supported based on message 1791 repetition if an acknowledgment is missing. 1793 Source: Generally applications benefit from the reliability of the 1794 message transport. 1796 Requirement Type: Functional Requirement 1798 Device type: C0, C1, and C2 1800 Priority: High 1802 --- 1804 Req-ID: 10.003 1806 Title: Best-effort multicast 1808 Description: Provide best-effort multicast of messages, which is 1809 generally useful when devices need to discover a service provided 1810 by a server or many devices need to be configured by a managing 1811 entity at once based on the same data model. 1813 Source: Use cases where a device needs to discover services as well 1814 as use cases with high amount of devices to manage, which are 1815 hierarchically deployed, e.g., AMI or M2M. 1817 Requirement Type: Functional Requirement 1818 Device type: C0, C1, and C2 1820 Priority: Medium 1822 --- 1824 Req-ID: 10.004 1826 Title: Secure message transport 1828 Description: Enable secure message transport providing 1829 authentication, data integrity, confidentiality by using existing 1830 transport layer technologies with small footprint such as TLS/ 1831 DTLS. 1833 Source: All use cases. 1835 Requirement Type: Non-Functional Requirements 1837 Device type: C1 and C2 1839 Priority: High 1841 3.11. Implementation Requirements 1843 Req-ID: 11.001 1845 Title: Avoid complex application layer transactions requiring large 1846 application layer messages. 1848 Description: Complex application layer transactions tend to require 1849 large memory buffers that are typically not available on C0 or C1 1850 devices and only by limiting functionality on C2 devices. 1851 Furthermore, the failure of a single large transaction requires 1852 repeating the whole transaction. On constrained devices, it is 1853 often more desirable to split a large transaction into a sequence 1854 of smaller transactions that require less resources and allow to 1855 make progress using a sequence of smaller steps. 1857 Source: Basic requirement which concerns all use cases with memory 1858 constrained devices. 1860 Requirement Type: Non-Functional Requirement 1862 Device type: C0, C1, and C2 1864 Priority: High 1865 --- 1867 Req-ID: 11.002 1869 Title: Avoid reassembly of messages at multiple layers in the 1870 protocol stack. 1872 Description: Reassembly of messages at multiple layers in the 1873 protocol stack requires buffers at multiple layers, which leads to 1874 inefficient use of memory resources. This can be avoided by 1875 making sure the application layer, the security layer, the 1876 transport layer, the IPv6 layer and any adaptation layers are 1877 aware of the limitations of each other such that unnecessary 1878 fragmentation and reassembly can be avoided. In addition, message 1879 size constraints must be announced to protocol peers such that 1880 they can adapt and avoid sending messages that can't be processed 1881 due to resource constraints on the receiving device. 1883 Source: Basic requirement which concerns all use cases with memory 1884 constrained devices. 1886 Requirement Type: Non-Functional Requirement 1888 Device type: C0, C1, and C2 1890 Priority: High 1892 4. IANA Considerations 1894 This document does not introduce any new code-points or namespaces 1895 for registration with IANA. 1897 Note to RFC Editor: this section may be removed on publication as an 1898 RFC. 1900 5. Security Considerations 1902 This document discusses the problem statement and requirements on 1903 networks of constrained devices. Section 1.6 mentions a number of 1904 limitations that could prevent the implementation of strong 1905 cryptographic algorithms. Requirements for security and access 1906 control are listed in Section 3.6. 1908 Constrained devices might be deployed often in unsafe environments, 1909 where attackers can gain physical access to the devices. As a 1910 consequence, it is crucial that devices are robust and tamper 1911 resistant, have no backdoors, do not provide services that are not 1912 essential for the primary function, and properly protect any security 1913 credentials that may be stored on the device (e.g., by using hardware 1914 protection mechanisms). Furthermore, it is important that any 1915 credentials leaking from a single device do not simplify the attack 1916 on other (similar) devices. In particular, security credentials 1917 should never be shared. 1919 Since constrained devices often have limited computational resources, 1920 care should be taken in choosing efficient but cryptographically 1921 strong cryptographic algorithms. Designers of constrained devices 1922 that have a long expected lifetime need to ensure that cryptographic 1923 algorithms can be updated once devices have been deployed. The 1924 ability to perform secure firmware and software updates is an 1925 important management requirement. 1927 Constrained devices might also generate sensitive data or require the 1928 processing of sensitive data. It is therefore an important 1929 requirement to properly protect access to the data in order to 1930 protect the privacy of humans using Internet-enabled devices. For 1931 certain types of data, protection during the transmission over the 1932 network may not be sufficient and methods should be investigated that 1933 provide protection of data while it is cached or stored (e.g., when 1934 using a store-and-forward transport mechanism). 1936 6. Acknowledgments 1938 Following persons reviewed and provided valuable comments to 1939 different versions of this document: 1941 Dominique Barthel, Andy Bierman, Carsten Bormann, Zhen Cao, Benoit 1942 Claise, Hui Deng, Bert Greevenbosch, Joel M. Halpern, Ulrich 1943 Herberg, James Nguyen, Anuj Sehgal, Zach Shelby, Peter van der Stok, 1944 Thomas Watteyne, and Bert Wijnen. 1946 The editors would like to thank the reviewers and the participants on 1947 the Coman and OPSAWG mailing lists for their valuable contributions 1948 and comments. 1950 7. Informative References 1952 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 1953 2914, September 2000. 1955 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 1956 (MANET): Routing Protocol Performance Issues and 1957 Evaluation Considerations", RFC 2501, January 1999. 1959 [RFC6632] Ersue, M. and B. Claise, "An Overview of the IETF Network 1960 Management Standards", RFC 6632, June 2012. 1962 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 1963 Lossy Networks", RFC 7102, January 2014. 1965 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1966 Constrained-Node Networks", RFC 7228, May 2014. 1968 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1969 Application Protocol (CoAP)", RFC 7252, June 2014. 1971 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 1972 over Low-Power Wireless Personal Area Networks (6LoWPANs): 1973 Overview, Assumptions, Problem Statement, and Goals", RFC 1974 4919, August 2007. 1976 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 1977 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 1978 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 1979 Lossy Networks", RFC 6550, March 2012. 1981 [COM-USE] Ersue, M., Romascanu, D., and J. Schoenwaelder, 1982 "Constrained Management: Use Cases", draft-ietf-opsawg- 1983 coman-use-cases (work in progress), July 2014. 1985 Appendix A. Change Log 1987 A.1. draft-ietf-opsawg-coman-probstate-reqs-04 - draft-ietf-opsawg- 1988 coman-probstate-reqs-05 1990 o Extended Abstract and Overview sections to clarify the type of 1991 requirements the draft describes. 1993 o Extended security highlighting the devices should make sure 1994 credentials are properly protected. 1996 A.2. draft-ietf-opsawg-coman-probstate-reqs-03 - draft-ietf-opsawg- 1997 coman-probstate-reqs-04 1999 o Changed in section 1.3 "10^-0" to "1". 2001 o Clarified in section 3 how the Requirements ID is composed. 2003 A.3. draft-ietf-opsawg-coman-probstate-reqs-02 - draft-ietf-opsawg- 2004 coman-probstate-reqs-03 2006 o General bug fixing. 2008 o Stated in the abstract and introduction section that the 2009 requirements listed in the document are potential requirements. 2011 o Added text in section 1.3 to highlight that with the usage of 2012 6LowPAN and RPL multi-hop connectivity and dynamic routing can be 2013 achieved. 2015 A.4. draft-ietf-opsawg-coman-probstate-reqs-01 - draft-ietf-opsawg- 2016 coman-probstate-reqs-02 2018 o General bug fixing. 2020 o Resolved the use of the term profile of requirements. 2022 o Changed requirement title from Redirect traffic to Reroute traffic 2023 and the description accordingly. 2025 o Changed requirement title from Traffic delay schemes to Traffic 2026 Shaping and the description accordingly. 2028 o Extended Security Considerations section. 2030 o Deleted empty section on Normative References. 2032 A.5. draft-ietf-opsawg-coman-probstate-reqs-00 - draft-ietf-opsawg- 2033 coman-probstate-reqs-01 2035 o General bug fixing. 2037 o Added Section 1.7. on Configuration and Monitoring Functionality 2038 Levels. 2040 o Changed diverse occurences of "networks" to "networks with/of 2041 constrained devices". 2043 o Introduced the term "Self-configuring infrastructureless networks" 2044 instead of MANET as it is a superset. 2046 o Introduced the term 'sleepy endpoints'. 2048 o Changed requirement IDs to be independent of section number. 2050 o Introduced notes for parts of the requirements text if it is 2051 focusing on implementation or solution. 2053 o Extended Security Considerations section. 2055 o Deleted Appendix A and B on other SDO's work and related projects 2056 as they provided dynamic information and couldn't be kept up-to- 2057 date. 2059 A.6. draft-ersue-constrained-mgmt-03 - draft-ietf-opsawg-coman- 2060 probstate-reqs-00 2062 o Reduced the terminology section for terminology addressed in the 2063 LWIG terminology draft. Referenced the LWIG terminology draft. 2065 o Checked and aligned all terminology against the LWIG terminology 2066 draft. 2068 o Moved section 1.4. Constrained Device Deployment Options and 2069 section 3. Use Cases to the companion document [COM-USE]. 2071 o Renamed Section 1.3. Class of Networks in Focus to "Network Types 2072 in Focus" and removed abbreviations C0, C1 and C2 for network 2073 classes as they have not been used. 2075 o Changed requirement priority classes to be High, Medium and Low. 2077 o Changed requirement types to be Functional and Non-Functional and 2078 added text to explain the requirement types. 2080 o Reformulation of some text parts for more clarity. 2082 A.7. draft-ersue-constrained-mgmt-02-03 2084 o Extended the terminology section and removed some of the 2085 terminology addressed in the new LWIG terminology draft. 2086 Referenced the LWIG terminology draft. 2088 o Moved Section 1.3. on Constrained Device Classes to the new LWIG 2089 terminology draft. 2091 o Class of networks considering the different type of radio and 2092 communication technologies in use and dimensions extended. 2094 o Extended the Problem Statement in Section 2. following the 2095 requirements listed in Section 4. 2097 o Following requirements, which belong together and can be realized 2098 with similar or same kind of solutions, have been merged. 2100 * Distributed Management and Peer Configuration, 2102 * Device status monitoring and Neighbor-monitoring, 2104 * Passive Monitoring and Reactive Monitoring, 2105 * Event-driven self-management - Self-healing and Periodic self- 2106 management, 2108 * Authentication of management systems and Authentication of 2109 managed devices, 2111 * Access control on devices and Access control on management 2112 systems, 2114 * Management of Energy Resources and Data models for energy 2115 management, 2117 * Software distribution (group-based firmware update) and Group- 2118 based provisioning. 2120 o Deleted the empty section on the gaps in network management 2121 standards, as it will be written in a separate draft. 2123 o Added links to mentioned external pages. 2125 o Added text on OMA M2M Device Classification in appendix. 2127 A.8. draft-ersue-constrained-mgmt-01-02 2129 o Extended the terminology section. 2131 o Added additional text for the use cases concerning deployment 2132 type, network topology in use, network size, network capabilities, 2133 radio technology, etc. 2135 o Added examples for device classes in a use case. 2137 o Added additional text provided by Cao Zhen (China Mobile) for 2138 Mobile Applications and by Peter van der Stok for Building 2139 Automation. 2141 o Added the new use cases 'Advanced Metering Infrastructure' and 2142 'MANET Concept of Operations in Military'. 2144 o Added the section 'Managing the Constrainedness of a Device or 2145 Network' discussing the needs of very constrained devices. 2147 o Added a note that the requirements in Section 3 need to be seen as 2148 standalone requirements and the current document does not 2149 recommend any profile of requirements. 2151 o Added Section 3 on the detailed requirements on constrained 2152 management matched to management tasks like fault, monitoring, 2153 configuration management, Security and Access Control, Energy 2154 Management, etc. 2156 o Solved nits and added references. 2158 o Added Appendix A on the related development in other bodies. 2160 o Added Appendix B on the work in related research projects. 2162 A.9. draft-ersue-constrained-mgmt-00-01 2164 o Splitted the section on 'Networks of Constrained Devices' into the 2165 sections 'Network Topology Options' and 'Management Topology 2166 Options'. 2168 o Added the use case 'Community Network Applications' and 'Mobile 2169 Applications'. 2171 o Provided a Contributors section. 2173 o Extended the section on 'Medical Applications'. 2175 o Solved nits and added references. 2177 Authors' Addresses 2179 Mehmet Ersue (editor) 2180 Nokia Networks 2182 Email: mehmet.ersue@nsn.com 2184 Dan Romascanu 2185 Avaya 2187 Email: dromasca@avaya.com 2189 Juergen Schoenwaelder 2190 Jacobs University Bremen 2192 Email: j.schoenwaelder@jacobs-university.de 2194 Ulrich Herberg 2196 Email: ulrich@herberg.name