idnits 2.17.1 draft-ietf-opsawg-coman-probstate-reqs-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 : ---------------------------------------------------------------------------- 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 (January 20, 2014) is 3747 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-ietf-lwig-terminology-06 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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 Solutions and Networks 4 Intended status: Informational D. Romascanu 5 Expires: July 24, 2014 Avaya 6 J. Schoenwaelder 7 Jacobs University Bremen 8 January 20, 2014 10 Management of Networks with Constrained Devices: Problem Statement and 11 Requirements 12 draft-ietf-opsawg-coman-probstate-reqs-00 14 Abstract 16 This document provides a problem statement, deployment and management 17 topology options as well as the requirements for the management of 18 networks where constrained devices are involved. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on July 24, 2014. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.3. Networks Types and Characteristics in Focus . . . . . . . 5 58 1.4. Constrained Device Deployment Options . . . . . . . . . . 9 59 1.5. Management Topology Options . . . . . . . . . . . . . . . 9 60 1.6. Managing the Constrainedness of a Device or Network . . . 10 61 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 14 62 3. Requirements on the Management of Networks with 63 Constrained Devices . . . . . . . . . . . . . . . . . . . . . 16 64 3.1. Management Architecture/System . . . . . . . . . . . . . . 16 65 3.2. Management protocols and data model . . . . . . . . . . . 21 66 3.3. Configuration management . . . . . . . . . . . . . . . . . 24 67 3.4. Monitoring functionality . . . . . . . . . . . . . . . . . 26 68 3.5. Self-management . . . . . . . . . . . . . . . . . . . . . 31 69 3.6. Security and Access Control . . . . . . . . . . . . . . . 32 70 3.7. Energy Management . . . . . . . . . . . . . . . . . . . . 34 71 3.8. SW Distribution . . . . . . . . . . . . . . . . . . . . . 36 72 3.9. Traffic management . . . . . . . . . . . . . . . . . . . . 36 73 3.10. Transport Layer . . . . . . . . . . . . . . . . . . . . . 38 74 3.11. Implementation Requirements . . . . . . . . . . . . . . . 39 75 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 42 77 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 43 78 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 80 8.1. Normative References . . . . . . . . . . . . . . . . . . . 45 81 8.2. Informative References . . . . . . . . . . . . . . . . . . 45 82 Appendix A. Related Development in other Bodies . . . . . . . . . 47 83 A.1. ETSI TC M2M . . . . . . . . . . . . . . . . . . . . . . . 47 84 A.2. OASIS . . . . . . . . . . . . . . . . . . . . . . . . . . 48 85 A.3. OMA . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 86 A.4. IPSO Alliance . . . . . . . . . . . . . . . . . . . . . . 49 87 Appendix B. Related Research Projects . . . . . . . . . . . . . . 51 88 Appendix C. Open issues . . . . . . . . . . . . . . . . . . . . . 52 89 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 53 90 D.1. draft-ersue-constrained-mgmt-03 - 91 draft-ersue-opsawg-coman-probstate-reqs-00 . . . . . . . . 53 92 D.2. draft-ersue-constrained-mgmt-02-03 . . . . . . . . . . . . 53 93 D.3. draft-ersue-constrained-mgmt-01-02 . . . . . . . . . . . . 54 94 D.4. draft-ersue-constrained-mgmt-00-01 . . . . . . . . . . . . 55 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56 97 1. Introduction 99 1.1. Overview 101 Small devices with limited CPU, memory, and power resources, so 102 called constrained devices (aka. sensor, smart object, or smart 103 device) can constitute a network. Such a network of constrained 104 devices itself may be constrained or challenged, e.g. with unreliable 105 or lossy channels, wireless technologies with limited bandwidth and a 106 dynamic topology, needing the service of a gateway or proxy to 107 connect to the Internet. In other scenarios, the constrained devices 108 can be connected to a non-constrained network using off-the-shelf 109 protocol stacks. 111 Constrained devices might be in charge of gathering information in 112 diverse settings including natural ecosystems, buildings, and 113 factories and send the information to one or more server stations. 114 Constrained devices may work under severe resource constraints such 115 as limited battery and computing power, little memory and 116 insufficient wireless bandwidth, and communication capabilities. A 117 central entity, e.g., a base station or controlling server, might 118 have more computational and communication resources and can act as a 119 gateway between the constrained devices and the application logic in 120 the core network. 122 Today diverse size of small devices with different resources and 123 capabilities are being connected. Mobile personal gadgets, building- 124 automation devices, cellular phones, Machine-to-machine (M2M) 125 devices, etc. benefit from interacting with other "things" in the 126 near or somewhere in the Internet. With this the Internet of Things 127 (IoT) becomes a reality build up of uniquely identifiable objects 128 (things). And over the next decade, this could grow to trillions of 129 constrained devices and will greatly increase the Internet's size and 130 scope. 132 Network management is characterized by monitoring network status, 133 detecting faults, and inferring their causes, setting network 134 parameters, and carrying out actions to remove faults, maintain 135 normal operation, and improve network efficiency and application 136 performance. The traditional network management application 137 periodically collects information from a set of elements that are 138 needed to manage, processes the data, and presents them to the 139 network management users. Constrained devices, however, often have 140 limited power, low transmission range, and might be unreliable. They 141 might also need to work in hostile environments with advanced 142 security requirements or need to be used in harsh environments for a 143 long time without supervision. Due to such constraints, the 144 management of a network with constrained devices offers different 145 type of challenges compared to the management of a traditional IP 146 network. 148 The IETF has already done a lot of standardization work to enable the 149 communication in IP networks and to manage such networks as well as 150 the manifold type of nodes in these networks [RFC6632]. However, the 151 IETF so far has not developed any specific technologies for the 152 management of constrained devices and the networks comprised by 153 constrained devices. IP-based sensors or constrained devices in such 154 an environment, i.e., devices with very limited memory and CPU 155 resources, use today application-layer protocols in an ad-hoc manner 156 to do simple resource management and monitoring. 158 This document provides a problem statement and lists the requirements 159 for the management of a network with constrained devices. 160 Section 1.3 and Section 1.5 describe different topology options for 161 the networking and management of constrained devices. Section 2 162 provides a problem statement on the issue of the management of 163 networked constrained devices. Section 3 lists requirements on the 164 management of applications and networks with constrained devices. 165 Note that the requirements in Section 3 need to be seen as standalone 166 requirements, where different implementer may decide to realize a 167 different set of them. 169 The use cases in the context of networks with constrained devices can 170 be found in the companion document [COM-US]. 172 1.2. Terminology 174 Concerning constrained devices and networks this document generally 175 builds on the terminology defined in [I-D.ietf-lwig-terminology], 176 where the terms Constrained Device, Constrained Network, etc. are 177 defined. 179 The following terms are additionally used throughout this 180 documentation: 182 AMI: (Advanced Metering Infrastructure) A system including hardware, 183 software, and networking technologies that measures, collects, and 184 analyzes energy usage, and communicates with a hierarchically 185 deployed network of metering devices, either on request or on a 186 schedule. 188 C0: Class 0 constrained device as defined in Section 3. of 189 [I-D.ietf-lwig-terminology]. 191 C1: Class 1 constrained device as defined in Section 3. of 192 [I-D.ietf-lwig-terminology]. 194 C2: Class 2 constrained device as defined in Section 3. of 195 [I-D.ietf-lwig-terminology]. 197 Network of Constrained Devices: A network to which constrained 198 devices are connected that may or may not be a Constrained Network 199 (see [I-D.ietf-lwig-terminology] for the definition of the term 200 Constrained Network). 202 M2M: (Machine to Machine) stands for the automatic data transfer 203 between devices of different kind. In M2M scenarios a device 204 (such as a sensor or meter) captures an event, which is relayed 205 through a network (wireless, wired or hybrid) to an application. 207 MANET: Mobile Ad-hoc Networks, a self-configuring and 208 infrastructureless network of mobile devices connected by wireless 209 technologies. 211 Smart Grid: An electrical grid that uses communication technologies 212 to gather and act on information in an automated fashion to 213 improve the efficiency, reliability and sustainability of the 214 production and distribution of electricity. 216 Smart Meter: An electrical meter in the context of a Smart Grid. 218 For a detailed discussion on the constrained networks as well as 219 classes of constrained devices and their capabilities please see 220 [I-D.ietf-lwig-terminology]. 222 1.3. Networks Types and Characteristics in Focus 224 In this document we differentiate following type of networks 225 concerning their transport and communication technologies: 227 Note that a network in general can involve constrained and non- 228 constrained devices. 230 1. Wireline non-constrained networks, e.g. an Ethernet-LAN with non- 231 constrained and constrained devices involved. 233 2. A combination of wireline and wireless networks, which may or may 234 not be mesh-based but have a multi-hop connectivity between 235 constrained devices, utilizing dynamic routing in both the 236 wireless and wireline portions of the network. Such networks 237 usually support highly distributed applications with many nodes 238 (e.g. environmental monitoring) and tend to deal with large-scale 239 multipoint-to-point systems with massive data flows. Wireless 240 Mesh Networks (WMN), as a specific variant, use off-the-shelf 241 radio technology such as Wi-Fi, WiMax, and cellular 3G/4G. WMNs 242 are reliable based on the redundancy they offer and have often a 243 more planned deployment to provide dynamic and cost effective 244 connectivity over a certain geographic area. 246 3. A combination of wireline and wireless networks with point-to- 247 point or point-to-multipoint communication generally with single- 248 hop connectivity to constrained devices, utilizing static routing 249 over the wireless network. Such networks support short-range, 250 point-to-point, low-data-rate, source-to-sink type of 251 applications such as RFID systems, light switches, fire and smoke 252 detectors, and home appliances. This type of networks also 253 support confined short-range spaces such as a home, a factory, a 254 building, or the human body. IEEE 802.15.1 (Bluetooth) and IEEE 255 802.15.4 are well-known examples of applicable standards for such 256 networks. 258 4. Mobile Adhoc networks (MANET) are self-configuring 259 _infrastructureless_ networks of mobile devices connected by 260 wireless technologies. MANETs are based on point-to-point 261 communications of devices moving independently in any direction 262 and changing the links to other devices frequently. MANET 263 devices do act as a router to forward traffic unrelated to their 264 own use. 266 Wireline non-constrained networks are mainly used for specific 267 applications like Building Automation or Infrastructure Monitoring. 268 However, wireline and wireless networks with multi-hop or point-to- 269 multipoint connectivity are especially in the interest of the 270 analysis on the management of constrained devices in this document. 272 Furthermore different network characteristics are determined by 273 multiple dimensions: dynamicity of the topology, bandwidth, and loss 274 rate. In the following, each dimension is explained, and networks in 275 scope for this document are outlined: 277 Network Topology: 279 The topology of a network can be represented as a graph, with edges 280 (i.e., links) and vertices (routers and hosts). Examples of 281 different topologies include "star" topologies (with one central node 282 and multiple nodes in one hop distance), tree structures (with each 283 node having exactly one parent), directed acyclic graphs (with each 284 node having one or more parents), clustered topologies (where one or 285 more "cluster heads" are responsible for a certain area of the 286 network), mesh topologies (fully distributed), etc. 288 Management protocols may take advantage of specific network 289 topologies, for example by distributing large-scale management tasks 290 amongst multiple distributed network management stations (e.g., in 291 case of a mesh topology), or by using a hierarchical management 292 approach (e.g., in case of a tree topology). These different 293 management topology options are described in Section 1.6. 295 Note that in certain network deployments, such as community ad hoc 296 networks (see the use case "Community Network Applications" in 297 [COM-US]), the topology is not pre-planned, and thus may be unknown 298 for management purposes. In other use cases, such as industrial 299 applications (see the use case "Industrial Applications" in 300 [COM-US]), the topology may be designed in advance and therefore 301 taken advantage of when managing the network. 303 Dynamicity of the network topology: 305 The dynamicity of the network topology determines the rate of change 306 of the graph per time. Such changes can occur due to different 307 factors, such as mobility of nodes (e.g., in MANETs or cellular 308 networks), duty cycles (for low-power devices enabling their network 309 interface only periodically to transmit or receive packets), or 310 unstable links (in particular wireless links with strongly 311 fluctuating link quality). 313 Examples of different levels of dynamicity of the topology are 314 Ethernets (with typically a very static topology) on the one side, 315 and low-power and lossy networks (LLNs) on the other side. LLNs 316 nodes often using duty cycles, operate on unreliable wireless links 317 and are potentially mobile (e.g. for sensor networks). 319 The more the topology is dynamic, the more routing, transport and 320 application layer protocols have to cope with interrupted 321 connectivity and/or longer delays. For example, management protocols 322 (with a given underlying transport protocol) that expect continuous 323 session flows without changes of routes during a communication flow, 324 may fail to operate. 326 Networks with a very low dynamicity (e.g. Ethernet) with no or 327 infrequent topology changes (e.g. less than once every 30 minutes), 328 are in-scope of this document if they are used with constrained 329 devices (see e.g. the use case "Building Automation" in [COM-US]). 331 Traffic flows: 333 The traffic flow in a network determines from which sources data 334 traffic is sent to which destinations in the network. Several 335 different traffic flows are defined in [I-D.ietf-roll-terminology], 336 including "point-to-point" (P2P), "multipoint-to-point" (MP2P), and 337 "point-to-multipoint" (P2MP) flows as: 339 o P2P: Point To Point. This refers to traffic exchanged between two 340 nodes (regardless of the number of hops between the two nodes). 342 o P2MP: Point-to-Multipoint traffic refers to traffic between one 343 node and a set of nodes. This is similar to the P2MP concept in 344 Multicast or MPLS Traffic Engineering. 346 o MP2P: Multipoint-to-Point is used to describe a particular traffic 347 pattern (e.g. MP2P flows collecting information from many nodes 348 flowing inwards towards a collecting sink). 350 If one of these traffic patterns is predominant in a network, 351 protocols (routing, transport, application) may be optimized for the 352 specific traffic flow. For example, in a network with a tree 353 topology and MP2P traffic, collection tree protocols are efficient to 354 send data from the leaves of the tree to the root of the tree, via 355 each node's parent. 357 Bandwidth: 359 The bandwidth of the network is the amount of data that can be sent 360 per time between two communication end-points. It is usually 361 determined by the link with the minimum bandwidth on the path from 362 the source to the destination of data packets. The bandwidth in 363 networks can range from a few Kilobytes per second (such as on some 364 802.15.4 link layers) to many Gigabytes per second (e.g., on fiber 365 optics). 367 For management purposes, the management protocol typically requires 368 to send information between the network management station and the 369 clients, for monitoring or control purposes. If the available 370 bandwidth is insufficient for the management protocol, packets will 371 be buffered and eventually dropped, and thus management is not 372 possible with such a protocol. 374 Networks without bandwidth limitation (e.g. Ethernet) are in-scope 375 of this document if they are used with constrained devices (see the 376 use case "Building Automation" in [COM-US]). 378 Loss rate: 380 The loss rate (or bit error rate) is the number of bit errors divided 381 by the total number of bits transmitted. For wired networks, loss 382 rates are typically extremely low, e.g. around 10^-12 or 10^-13 for 383 the latest 10Gbit Ethernet. For wireless networks, such as 802.15.4, 384 the bit error rate can be as high as 10^-1 to 10^-0 in case of 385 interferences.Even when using a reliable transport protocol, 386 management operations can fail if the loss rate is too high, unless 387 they are specifically designed to cope with these situations. 389 Note: The discussion on the management requirements of MANETs is 390 currently not in the focus of this document. [COM-US] provides a use 391 case to make it clear how a MANET-based application differs from 392 others. 394 1.4. Constrained Device Deployment Options 396 We differentiate following Deployment options for the constrained 397 devices: 399 o a network of constrained devices, which communicate with each 400 other, 402 o Constrained devices, which are connected directly to the Internet 403 or an IP network 405 o A network of constrained devices which communicate with a gateway 406 or proxy with more communication capabilities acting possibly as a 407 representative of the device to entities in the non-constrained 408 network 410 o Constrained devices, which are connected to the Internet or an IP 411 network via a gateway/proxy 413 o A hierarchy of constrained devices, e.g., a network of C0 devices 414 connected to one or more C1 devices - connected to one or more C2 415 devices - connected to one or more gateways - connected to some 416 application servers or NMS system 418 o The possibility of device grouping (possibly in a dynamic manner) 419 such as that the grouped devices can act as one logical device at 420 the edge of the network and one device in this group can act as 421 the managing entity 423 1.5. Management Topology Options 425 We differentiate following options for the management of networks of 426 constrained devices: 428 o A network of constrained devices managed by one central manager. 429 A logically centralized management might be implemented in a 430 hierarchical fashion for scalability and robustness reasons. The 431 manager and the management application logic might have a gateway/ 432 proxy in between or might be on different nodes in different 433 networks, e.g., management application running on a cloud server. 435 o Distributed management, where a constrained network is managed by 436 more than one manager. Each manager controls a subnetwork and may 437 communicate directly with other manager stations in a cooperative 438 fashion. The distributed management may be weakly distributed, 439 where functions are broken down and assigned to many managers 440 dynamically, or strongly distributed, where almost all managed 441 things have embedded management functionality and explicit 442 management disappears, which usually comes with the price that the 443 strongly distributed management logic now needs to be managed. 445 o Hierarchical management, where a hierarchy of constrained networks 446 are managed by the managers at their corresponding hierarchy 447 level. I.e. each manager is responsible for managing the nodes in 448 its sub-network. It passes information from its sub-network to 449 its higher-level manager, and disseminates management functions 450 received from the higher-level manager to its sub-network. 451 Hierarchical management is essentially a scalability mechanism, 452 logically the decision-making may be still centralized. 454 1.6. Managing the Constrainedness of a Device or Network 456 The capabilities of a constrained device or network and the 457 constrainedness thereof influence and have an impact on the 458 requirements for the management of such network or devices. 460 A constrained device: 462 o might only support an unreliable radio with lossy links, i.e. the 463 client and server of a management protocol need to gracefully 464 ignore incomplete commands or repeat commands as necessary. 466 o might only be able to go online from time-to-time, where it is 467 reachable, i.e. a command might be necessary to repeat after a 468 longer timeout or the timeout value with which one endpoint waits 469 on a response needs to be sufficiently high. 471 o might only be able to support a limited operating time (e.g. based 472 on the available battery), i.e. the devices need to economize 473 their energy usage with suitable mechanisms and the managing 474 entity needs to monitor and control the energy status of the 475 constrained devices it manages. 477 o might only be able to support one simple communication protocol, 478 i.e. the management protocol needs to be possible to downscale 479 from constrained (C2) to very constrained (C0) devices with 480 modular implementation and a very basic version with just a few 481 simple commands. 483 o might only be able to support limited or no user and/or transport 484 security, i.e. the management system needs to support a less- 485 costly and simple but sufficiently secure authentication 486 mechanism. 488 o might not be able to support compression and decompression of 489 exchanged data based on limited CPU power, i.e. an intermediary 490 entity which is capable of data compression should be able to 491 communicate with both, devices, which support data compression 492 (e.g. C2) and devices, which do not support data compression 493 (e.g. C1 and C0). 495 o might only be able to support very simple encryption, i.e. it 496 would be efficient if the devices use cryptographic algorithms 497 that are supported in hardware. 499 o might only be able to communicate with one single managing entity 500 and cannot support the parallel access of many managing entities. 502 o might depend on a self-configuration feature, i.e. the managing 503 entity might not know all devices in a network and the device 504 needs to be able to initiate connection setup for the device 505 configuration. 507 o might depend on self- or neighbor-monitoring feature, i.e. the 508 managing entity might not be able to monitor all devices in a 509 network continuously. 511 o might only be able to communicate with its neighbors, i.e. the 512 device should be able to get its configuration from a neighbor. 514 o might only be able to support parsing of data models with limited 515 size, i.e. the device data models need to be compact containing 516 the most necessary data and if possible parsable as a stream. 518 o might only be able to support a limited or no failure detection, 519 i.e. the managing entity needs to handle the situation, where a 520 failure does not get detected or gets detected late gracefully 521 e.g. with asking repeatedly. 523 o might only be able to support the reporting of just one or a 524 limited set failure types. 526 o might only be able to support a limited set of notifications, 527 possible only an "I-am-alive" message. 529 o might only be able to support a soft-reset from failure recovery. 531 o might possibly generate a huge amount of redundant reporting data, 532 i.e. the intermediary management entity (see [I-D.ietf-core-coap]) 533 should be able to filter and aggregate redundant data. 535 A constrained network: 537 o might only support an unreliable radio with lossy links, i.e. the 538 client and server of a management protocol need to repeat commands 539 as necessary or gracefully ignore incomplete commands. 541 o might be necessary to manage based on multicast communication, 542 i.e. the managing entity needs to be prepared to configure many 543 devices at once based on the same data model. 545 o might have a very large topology supporting 10.000 or more nodes 546 for some applications and as such node naming is a specific issue 547 for constrained networks. 549 o must be able to self-organize, i.e. given the large number of 550 nodes and their potential placement in hostile locations and 551 frequently changing topology, manual configuration is typically 552 not feasible. As such the network must be able to reconfigure 553 itself so that it can continue to operate properly and support 554 reliable connectivity. 556 o needs a management solution, which is energy-efficient, using as 557 little wireless bandwidth as possible since communication is 558 highly energy demanding. 560 o needs to support localization schemes to determine the location of 561 devices since the devices might be moving and location information 562 is important for some applications. 564 o needs a management solution, which is scalable as the network may 565 consist of thousands of nodes and may need to be extended 566 continuously. 568 o needs to provide fault tolerance. Faults in network operation 569 including hardware and software errors or failures detected by the 570 transport protocol should be handled smoothly enabling. In such a 571 case it should be possible to run the protocol possibly at a 572 reduced level but avoiding to fail completely. E.g. self- 573 monitoring mechanisms or graceful degradation of features can be 574 used to provide fault tolerance. 576 o might require new management capabilities: for example, network 577 coverage information and a constrained device power-distribution- 578 map. 580 o might require a new management function for data management, since 581 the type and amount of data collected in constrained networks is 582 different from those of the traditional networks. 584 o might also need energy-efficient key management algorithms for 585 security. 587 2. Problem Statement 589 The terminology for the "Internet of Things" is still nascent, and 590 depending on the network type or layer in focus diverse technologies 591 and terms are in use. Common to all these considerations is the 592 "Things" or "Objects" are supposed to have physical or virtual 593 identities using interfaces to communicate. In this context, we need 594 to differentiate between the Constrained and Smart Devices identified 595 by an IP address compared to virtual entities such as Smart Objects, 596 which can be identified as a resource or a virtual object by using a 597 unique identifier. Furthermore, the smart devices usually have a 598 limited memory and CPU power as well as aim to be self-configuring 599 and easy to deploy. 601 However, the tininess of the network nodes requires a rethinking of 602 the protocol characteristics concerning power consumption, 603 performance, memory, and CPU usage. As such, there is a demand for 604 protocol simplification, energy-efficient communication, less CPU 605 usage and small memory footprint. 607 On the application layer the IETF is already developing protocols 608 like the Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] 609 supporting constrained devices and networks e.g., for smart energy 610 applications or home automation environments. The deployment of such 611 an environment involves in fact many, in some scenarios up to million 612 small devices (e.g. smart meters), which produce a huge amount of 613 data. This data needs to be collected, filtered, and pre-processed 614 for further use in diverse services. 616 Considering the high number of nodes to deploy, one has to think on 617 the manageability aspects of the smart devices and plan for easy 618 deployment, configuration, and management of the networks of 619 constrained devices as well as the devices themselves. Consequently, 620 seamless monitoring and self-configuration of such network nodes 621 becomes more and more imperative. Self-configuration and self- 622 management is already a reality in the standards of some of the 623 bodies such as 3GPP. To introduce self-configuration of smart 624 devices successfully a device-initiated connection establishment is 625 required. 627 A simple application layer protocol, such as CoAP, is essential to 628 address the issue of efficient object-to-object communication and 629 information exchange. Such an information exchange should be done 630 based on interoperable data models to enable the exchange and 631 interpretation of diverse application and management related data. 633 In an ideal world, we would have only one network management protocol 634 for monitoring, configuration, and exchanging management data, 635 independently of the type of the network (e.g., Smart Grid, wireless 636 access, or core network). Furthermore, it would be desirable to 637 derive the basic data models for constrained devices from the core 638 models used today to enable reuse of functionality and end-to-end 639 information exchange. However, the current management protocols seem 640 to be too heavyweight compared to the capabilities the constrained 641 devices have and are not applicable directly for the use in a network 642 of constrained devices. Furthermore, the data models addressing the 643 requirements of such smart devices need yet to be designed. 645 The IETF so far has not developed any specific technologies for the 646 management of constrained devices and the networks comprised by 647 constrained devices. IP-based sensors or constrained devices in such 648 an environment, i.e., devices with very limited memory and CPU 649 resources, use today, e.g., application-layer protocols to do simple 650 resource management and monitoring. This might be sufficient for 651 some basic cases, however, there is a need to reconsider the network 652 management mechanisms based on the new, changed, as well as reduced 653 requirements coming from smart devices and the network of such 654 constrained devices. Albeit it is questionable whether we can take 655 the same comprehensive approach we use in an IP network also for the 656 management of constrained devices. Hence, the management of a 657 network with constrained devices is necessary to design in a 658 simplified and less complex manner. 660 As the Section 1.6 highlights, there are diverse characterists of 661 constrained devices or networks, which stem from their constraindness 662 and therefor have an impact on the requirements for the management of 663 such a network with constrained devices. The use cases discussed in 664 [COM-US] show that the requirements on constrained networks are 665 manifold and need to be analyzed from different angles, e.g. 666 concerning the design of the management architecture, the selection 667 of the appropriate protocol features as well as the specific issues 668 which are new in the context of constrained devices. Examples of 669 such issues are e.g. the careful management of the scarce energy 670 resources, the necessity for self-organization and self-management of 671 such devices but also the implementation considerations to enable the 672 use of common communication technologies on a constrained hardware in 673 an efficient manner. For an exhaustive list of issues and 674 requirements, which need to be addressed for the management of a 675 network with constrained devices please see Section 1.6 and 676 Section 3. 678 3. Requirements on the Management of Networks with Constrained Devices 680 This section describes the requirements categorized by management 681 areas listed in subsections. 683 Note that the requirements in this section need to be seen as 684 standalone requirements. A device might be able to provide only a 685 particular profile of requirements (i.e. selected set of 686 requirements) and might not be capable to provide all requirements in 687 this document. On the other hand a device vendor might select a 688 subset of the requirements to implement. As of today this document 689 does not recommend the realization of a profile of requirements. 691 Following template is used for the definition of the requirements. 693 Req-ID: An ID uniquely identified by a three-digit number 695 Title: The title of the requirement. 697 Description: The rational and description of the requirement. 699 Source: The origin of the requirement and the matching use case or 700 application. For the discussion of referred use cases for 701 constrained management please see [COM-US]. 703 Requirement Type: Functional Requirement, Non-Functional 704 Requirement. A functional requirement is related to a proposed 705 function or component. As such functional requirements may be 706 technical details, or specific functionality that define what a 707 system is supposed to accomplish. Non-functional requirements 708 (also known as design constraints or quality requirements) impose 709 implementation related considerations such as performance 710 requirements, security, or reliability. 712 Device type: The device types by which this requirement can be 713 supported: C0, C1 and/or C2. 715 Priority: The priority of the requirement showing it's importance 716 for a particular type of device: High, Medium, and Low. The 717 priority of a requirement can be High e.g. for a C2 device but Low 718 for a C1 or C0 device as the realization of complex features in a 719 C1 device is in many cases not possible. 721 3.1. Management Architecture/System 722 Req-ID: 4.1.001 724 Title: Support multiple device classes within a single network. 726 Description: Larger networks usually are made up of devices 727 belonging to different device classes (e.g., constrained mesh 728 endpoints and less constrained routers) that work together. 729 Hence, the management architecture must be applicable to networks 730 that have a mix of different device classes. See Section 3. of 731 [I-D.ietf-lwig-terminology] for the definition of Constrained 732 Device Classes. 734 Source: All use cases. 736 Requirement Type: Non-Functional Requirement 738 Device type: Managing and intermediary entities. 740 Priority: High 742 --- 744 Req-ID: 4.1.002 746 Title: Management scalability. 748 Description: The management architecture must be able to scale with 749 the number of devices involved and operate efficiently in any 750 network size and topology. This implies that e.g. the managing 751 entity is able to handle huge amount of device monitoring data and 752 the management protocol is not sensitive to the decrease of the 753 time between two client requests. To achieve good scalability, 754 caching techniques, in-network data aggregation techniques, 755 hierarchical management models may be used. 757 Source: General requirement for all use cases to enable large scale 758 networks. 760 Requirement Type: Non-Functional Requirement 762 Device type: C0, C1, and C2 764 Priority: High 766 --- 767 Req-ID: 4.1.003 769 Title: Hierarchical management 771 Description: Provide a means of hierarchical management, i.e. 772 provide intermediary management entities on different levels, 773 which can take over the responsibility for the management of a 774 sub-hierarchy of the network of constraint devices. The 775 intermediary management entity can e.g. support management data 776 aggregation to handle e.g. high-frequent monitoring data or 777 provide a caching mechanism for the uplink and downlink 778 communication. Hierarchical management contributes to management 779 scalability. 781 Source: Use cases where a huge amount of devices are deployed with a 782 hierarchical topology. 784 Requirement Type: Non-Functional Requirement 786 Device type: Managing and intermediary entities. 788 Priority: Medium 790 --- 792 Req-ID: 4.1.004 794 Title: Minimize state maintained on constrained devices. 796 Description: The amount of state that needs to be maintained on 797 constrained devices should be minimized. This is important in 798 order to save memory (especially relevant for C0 and C1 devices) 799 and in order to allow devices to restart for example to apply 800 configuration changes or to recover from extended periods of 801 inactivity. One way to achieve this is to adopt a RESTful 802 architecture that minimizes the amount of state maintained by 803 managed constrained devices and that makes resources of a device 804 addressable via URIs. 806 Source: Basic requirement which concerns all use cases. 808 Requirement Type: Functional Requirement 810 Device type: C0, C1, and C2 811 Priority: High 813 --- 815 Req-ID: 4.1.005 817 Title: Automatic re-synchronization with eventual consistency. 819 Description: To support large scale networks, where some constrained 820 devices may be offline at any point in time, it is necessary to 821 distribute configuration parameters in a way that allows temporary 822 inconsistencies but eventually converges, after a sufficiently 823 long period of time without further changes, towards global 824 consistency. 826 Source: Use cases with large scale networks with many devices. 828 Requirement Type: Functional Requirement 830 Device type: C0, C1, and C2 832 Priority: High 834 --- 836 Req-ID: 4.1.006 838 Title: Support for lossy links and unreachable devices. 840 Description: Some constrained devices will only be able to support 841 lossy and unreliable links characterized by a limited data rate, a 842 high latency, and a high transmission error rate. Furthermore 843 constrained devices often duty cycle their radio or the whole 844 device in order to save energy. In both cases the management 845 system must not assume that constrained devices are always 846 reachable. The management protocol(s) must act gracefully if a 847 conctrained device is not reachable and provide a high degree of 848 resilience. Intermediaries may be used that provide information 849 for devices currently inactive or that take responsibility to re- 850 synchronize devices when they become reachable again after an 851 extended offline period. 853 Source: Basic requirement for constrained networks with unreliable 854 links and constrained devices which sleep to save energy. 856 Requirement Type: Non-Functional Requirement 858 Device type: C0, C1, and C2 860 Priority: High 862 --- 864 Req-ID: 4.1.007 866 Title: Network-wide configuration 868 Description: Provide means by which the behavior of the network can 869 be specified at a level of abstraction (network-wide 870 configuration) higher than a set of configuration information 871 specific to individual devices. It is useful to derive the device 872 specific configuration from the network-wide configuration. The 873 identification of the relevant subset of the policies to be 874 provisioned is according to the capabilities of each device and 875 can be obtained from a pre-configured data-repository. Such a 876 repository can be used to configure pre-defined device or protocol 877 parameters for the whole network. Furthermore, such a network- 878 wide view can be used to monitor and manage a group of routers or 879 a whole network. E.g. monitoring the performance of a network 880 requires additional information other than what can be acquired 881 from a single router using a management protocol. 883 Source: In general all use cases, which want to configure the 884 network and its devices based on a network view in a top-down 885 manner. 887 Requirement Type: Non-Functional Requirement 889 Device type: C0, C1, and C2 891 Priority: Medium 893 --- 895 Req-ID: 4.1.008 897 Title: Distributed Management 899 Description: Provide a means of simple distributed management, where 900 a constrained network can be managed or monitored by more than one 901 manager. Since the connectivity to a server cannot be guaranteed 902 at all times, a distributed approach may provide a higher 903 reliability, at the cost of increased complexity. This 904 requirement implies the handling of data consistency in case of 905 concurrent read and write access to the device datastore. It 906 might also happen that no management (configuration) server is 907 accessible and the only reachable node is a peer device. In this 908 case the device should be able to obtain its configuration from 909 peer devices. 911 Source: Use cases where the count of devices to manage is high. 913 Requirement Type: Non-Functional Requirement 915 Device type: C1 and C2 917 Priority: Medium 919 3.2. Management protocols and data model 921 Req-ID: 4.2.001 923 Title: Modular implementation of management protocols 925 Description: Management protocols should allow modular 926 implementations, i.e., it should be possible to implement only a 927 basic set of protocol primitives on highly constrained devices 928 while devices with additional resources may provide more support 929 for additional protocol primitives. It should be possible to 930 discover the management protocol primitives by a device. 932 Source: Basic requirement interesting for all use cases. 934 Requirement Type: Non-Functional Requirement 936 Device type: C0, C1, and C2 938 Priority: High 940 --- 942 Req-ID: 4.2.002 944 Title: Compact encoding of management data 946 Description: The encoding of management data should be compact and 947 space efficient, enabling small message sizes. 949 Source: General requirement to save memory for the receiver buffer 950 and on-air bandwith. 952 Requirement Type: Functional Requirement 954 Device type: C0, C1, and C2 956 Priority: High 958 --- 960 Req-ID: 4.2.003 962 Title: Compression of management data or complete messages 964 Description: Management data exchanges can be further optimized by 965 applying data compression techniques or delta encoding techniques. 966 Compression typically requires additional code size and some 967 additional buffers and/or the maintenance of some additional state 968 information. For C0 devices compression may not be feasible. As 969 such, this requirement is marked as optional. 971 Source: Use cases where it is beneficial to reduce transmission time 972 and bandwith, e.g. mobile applications which require to save on- 973 air bandwith. 975 Requirement Type: Functional Requirement 977 Device type: C1 and C2 979 Priority: Medium 981 --- 983 Req-ID: 4.2.004 985 Title: Mapping of management protocol interactions. 987 Description: It is desirable to have a loss-less automated mapping 988 between the management protocol used to manage constrained devices 989 and the management protocols used to manage regular devices. In 990 the ideal case, the same core management protocol can be used with 991 certain restrictions taking into account the resource limitations 992 of constrained devices. However, for very resource constrained 993 devices, this goal might not be achievable. Hence this 994 requirement is marked optional for device class C2. 996 Source: Use cases where high-frequent interaction with the 997 management system of a non-constrained network is required. 999 Requirement Type: Functional Requirement 1001 Device type: C2 1003 Priority: Medium 1005 --- 1007 Req-ID: 4.2.005 1009 Title: Consistency of data models with the underlying information 1010 model. 1012 Description: The data models used by the management protocol must be 1013 consistent with the information model used to define data models 1014 for non-constrained networks. This is essential to facilitate the 1015 integration of the management of constrained networks with the 1016 management of non-constrained networks. Using an underlying 1017 information model for future data model design enables furthermore 1018 top-down model design and model reuse as well as data 1019 interoperability (i.e. exchange of management information between 1020 the constrained and non-constrained networks). This is a strong 1021 requirement, even despite the fact that the underlying information 1022 models are often not explicitly documented in the IETF. 1024 Source: General requirement to support data interoperability, 1025 consistency and model reuse. 1027 Requirement Type: Non-Functional Requirement 1029 Device type: C0, C1, and C2 1031 Priority: High 1033 --- 1035 Req-ID: 4.2.006 1037 Title: Loss-less mapping of management data models. 1039 Description: It is desirable to have a loss-less automated mapping 1040 between the management data models used to manage regular devices 1041 and the management data models used for managing constrained 1042 devices. In the ideal case, the same core data models can be used 1043 with certain restrictions taking into account the resource 1044 limitations of constrained devices. However, for very resource 1045 constrained devices, this goal might not be achievable. Hence 1046 this requirement is marked optional for device class C2. 1048 Source: Use cases where consistent data exchange with the management 1049 system of a non-constrained network is required. 1051 Requirement Type: Functional Requirement 1053 Device type: C2 1055 Priority: Medium 1057 --- 1059 Req-ID: 4.2.007 1061 Title: Protocol extensibility 1063 Description: Provide means of extensibility for the management 1064 protocol, i.e. by adding new protocol messages or mechanisms that 1065 can deal with the changing requirements on a supported message and 1066 data types effectively, without causing inter-operability problems 1067 or having to replace/update large amounts of deployed devices. 1069 Source: Basic requirement useful for all use cases. 1071 Requirement Type: Functional Requirement 1073 Device type: C0, C1, and C2 1075 Priority: High 1077 3.3. Configuration management 1079 Req-ID: 4.3.001 1081 Title: Self-configuration capability 1083 Description: Automatic configuration and re-configuration of devices 1084 without manual intervention. Compared to the traditional 1085 management of devices where the management application is the 1086 central entity configuring the devices, in the auto-configuration 1087 scenario the device is the active part and initiates the 1088 configuration process. Self-configuration can be initiated during 1089 the initial configuration or for subsequent configurations, where 1090 the configuration data needs to be refreshed. Self-configuration 1091 should be also supported during the initialization phase or in the 1092 event of failures, where prior knowledge of the network topology 1093 is not available or the topology of the network is uncertain. 1095 Source: In general all use cases requiring easy deployment and plug& 1096 play behavior as well as easy maintenance of many constrained 1097 devices. 1099 Requirement Type: Functional Requirement 1101 Device type: C0, C1, and C2 1103 Priority: High for device categories C0 and C1, Medium for C2. 1105 --- 1107 Req-ID: 4.3.002 1109 Title: Capability Discovery 1111 Description: Enable the discovery of supported optional management 1112 capabilities of a device and their exposure via at least one 1113 protocol and/or data model. 1115 Source: Use cases where the device interaction with other devices or 1116 applications is a function of the level of support for its 1117 capabilities. 1119 Requirement Type: Functional Requirement 1121 Device type: C1 and C2 1123 Priority: Medium 1125 --- 1127 Req-ID: 4.3.003 1129 Title: Asynchronous Transaction Support 1131 Description: Provide configuration management with asynchronous 1132 transaction support. Configuration operations must support a 1133 transactional model, with asynchronous indications that the 1134 transaction was completed. 1136 Source: Use cases, which require transaction-oriented processing 1137 because of reliability or distributed architecture functional 1138 requirements. 1140 Requirement Type: Functional Requirement 1142 Device type: C1 and C2 1144 Priority: Medium 1146 --- 1148 Req-ID: 4.3.004 1150 Title: Network reconfiguration 1152 Description: Provide a means of iterative network reconfiguration in 1153 order to recover the network functionality from node and 1154 communication faults. The network reconfiguration can be failure- 1155 driven and self-initiated (automatic reconfiguration). The 1156 network reconfiguration can be also performed on the whole 1157 hierarchical structure of a network (network topology). 1159 Source: Practically all use cases, as network connectivity is a 1160 basic requirement. 1162 Requirement Type: Functional Requirement 1164 Device type: C0, C1, and C2 1166 Priority: Medium 1168 3.4. Monitoring functionality 1170 Req-ID: 4.4.001 1172 Title: Device status monitoring 1174 Description: Provide a monitoring function to collect and expose 1175 information about device status and exposing it via at least one 1176 management interface. The device monitoring might make use of the 1177 hierarchical management through the intermediary entities and the 1178 data caching mechanism. The device monitoring might also make use 1179 of neighbor-monitoring (fault detection in local network) to 1180 support fast fault detection and recovery, e.g. in a scenario 1181 where a managing entity is unreachable and a neighbor can take 1182 over the monitoring responsibility. 1184 Source: All use cases 1185 Requirement Type: Functional Requirement 1187 Device type: C0, C1, and C2 1189 Priority: High, Medium for neighbor-monitoring. 1191 --- 1193 Req-ID: 4.4.002 1195 Title: Energy status monitoring 1197 Description: Provide a monitoring function to collect and expose 1198 information about device energy parameters and usage (e.g. battery 1199 level and communication power). 1201 Source: Use case Energy Management 1203 Requirement Type: Functional Requirement 1205 Device type: C0, C1, and C2 1207 Priority: High for energy reporting devices, Low for others. 1209 --- 1211 Req-ID: 4.4.003 1213 Title: Monitoring of current and estimated device availability 1215 Description: Provide a monitoring function to collect and expose 1216 information about current device availability (energy, memory, 1217 computing power, forwarding plane utilization, queue buffers, 1218 etc.) and estimation of remaining available resources. 1220 Source: All use cases. Note that monitoring energy resources (like 1221 battery status) may be required on all kinds of devices. 1223 Requirement Type: Functional Requirement 1225 Device type: C0, C1, and C2 1227 Priority: Medium 1229 --- 1230 Req-ID: 4.4.004 1232 Title: Network status monitoring 1234 Description: Provide a monitoring function to collect and expose 1235 information related to the status of a network or network segments 1236 connected to the interfaces of the device. 1238 Source: All use cases. 1240 Requirement Type: Functional Requirement 1242 Device type: C1 and C2 1244 Priority: Low, based on the realization complexity. 1246 --- 1248 Req-ID: 4.4.005 1250 Title: Self-monitoring 1252 Description: Provide self-monitoring (local fault detection) feature 1253 for fast fault detection and recovery. 1255 Source: Use cases where the devices cannot be monitored centrally in 1256 appropriate manner, e.g. self-healing is required. 1258 Requirement Type: Functional Requirement 1260 Device type: C1 and C2 1262 Priority: High for C2, Medium for C1 1264 --- 1266 Req-ID: 4.4.006 1268 Title: Performance Monitoring 1270 Description: The device will provide a monitoring function to 1271 collect and expose information about the basic performance 1272 parameter (TBD) of the device. The performance management 1273 functionality might make use of the hierarchical management 1274 through the intermediary devices. 1276 Source: Use cases Building automation, and Transport applications 1278 Requirement Type: Functional Requirement 1280 Device type: C1 and C2 1282 Priority: Low 1284 --- 1286 Req-ID: 4.4.007 1288 Title: Fault detection monitoring 1290 Description: The device will provide fault detection monitoring. 1291 The system collects information about network states in order to 1292 identify whether faults have occurred. In some cases the 1293 detection of the faults might be based on the processing and 1294 analysis of the parameters retrieved from the network or other 1295 devices. In case of C0 devices the monitoring might be limited to 1296 the check whether the device is alive or not. 1298 Source: Use cases Environmental Monitoring, Building Automation, 1299 Energy Management, Infrastructure Monitoring 1301 Requirement Type: Functional Requirement 1303 Device type: C0, C1 and C2 1305 Priority: Medium 1307 --- 1309 Req-ID: 4.4.008 1311 Title: Passive and Reactive Monitoring 1313 Description: The device will provide passive and reactive monitoring 1314 capabilities. The system or manager collects information about 1315 device components and network states (passive monitoring) and may 1316 perform postmortem analysis of collected data. In case events of 1317 interest have occurred the system or manager can adaptively react 1318 (reactive monitoring), e.g. reconfigure the network. Typically 1319 actions (re-actions) will be executed or sent as commands by the 1320 management applications. 1322 Source: Diverse use cases relevant for device status and network 1323 state monitoring 1325 Requirement Type: Functional Requirement 1327 Device type: C2 1329 Priority: Medium 1331 --- 1333 Req-ID: 4.4.009 1335 Title: Recovery 1337 Description: Provide local, central and hierarchical recovery 1338 mechanisms (recovery is in some cases achieved by recovering the 1339 whole network of constrained devices). 1341 Source: Use cases Industrial applications, Home and Building 1342 Automation, Mobile Applications that involve different forms of 1343 clustering or area managers. 1345 Requirement Type: Functional Requirement 1347 Device type: C2 1349 Priority: Medium 1351 --- 1353 Req-ID: 4.4.010 1355 Title: Network topology discovery 1357 Description: Provide a network topology discovery capability (e.g. 1358 use of topology extraction algorithms to retrieve the network 1359 state) and a monitoring function to collect and expose information 1360 about the network topology. 1362 Source: Use cases Community Network Applications and Mobile 1363 Applications 1365 Requirement Type: Functional Requirement 1366 Device type: C1 and C2 1368 Priority: Low, based on the realization complexity. 1370 --- 1372 Req-ID: 4.4.011 1374 Title: Notifications 1376 Description: The device will provide the capability of sending 1377 notifications on critical events and faults. 1379 Source: All use cases. 1381 Requirement Type: Functional Requirement 1383 Device type: C0, C1, and C2 1385 Priority: Medium for C2, Low for C1 1387 --- 1389 Req-ID: 4.4.012 1391 Title: Logging 1393 Description: The device will provide the capability of building, 1394 keeping, and allowing retrieval of logs of events (including but 1395 not limited to critical faults and alarms). 1397 Source: Use cases Industrial Applications, Building Automation, 1398 Infrastructure monitoring 1400 Requirement Type: Functional Requirement 1402 Device type: C2 1404 Priority: High for some medical or industrial applications, Medium 1405 otherwise 1407 3.5. Self-management 1409 Req-ID: 4.5.001 1410 Title: Self-management - Self-healing 1412 Description: Enable event-driven and/or periodic self-management 1413 functionality in a device. The device should be able to react in 1414 case of a failure e.g. by initiating a fully or partly reset and 1415 initiate a self-configuration or management data update as 1416 necessary. A device might be further able to check for failures 1417 cyclically or schedule-controlled to trigger self-management as 1418 necessary. It is a matter of device design and subject for 1419 discussion how much self-management a C1 device can support. A 1420 minimal failure detection and self-management logic is assumed to 1421 be generally useful for the self-healing of a device. 1423 Source: The requirement generally relates to all use cases in this 1424 document. 1426 Requirement Type: Functional Requirement 1428 Device type: C1 and C2 1430 Priority: High for C2, Medium for C1 1432 3.6. Security and Access Control 1434 Req-ID: 4.6.001 1436 Title: Authentication of management system and devices. 1438 Description: Systems having a management role must be properly 1439 authenticated to the device such that the device can exercise 1440 proper access control and in particular distinguish rightful 1441 management systems from rogue systems. On the other hand managed 1442 devices must authenticate themselves to systems having a 1443 management role such that management systems can protect 1444 themselves from rogue devices. In certain application scenarios, 1445 it is possible that a large number of devices need to be 1446 (re)started at about the same time. Protocols and authentication 1447 systems should be designed such that a large number of devices 1448 (re)starting simultaneously does not negatively impact the device 1449 authentication process. 1451 Source: Basic security requirement for all use cases. 1453 Requirement Type: Functional Requirement 1454 Device type: C0, C1, and C2 1456 Priority: High, Medium for the (re)start of a large number of 1457 devices 1459 --- 1461 Req-ID: 4.6.002 1463 Title: Support suitable security bootstrapping mechanisms 1465 Description: Mechanisms should be supported that simplify the 1466 bootstrapping of device that is the discovery of newly deployed 1467 devices in order to add them to access control lists. 1469 Source: Basic security requirement for all use cases. 1471 Requirement Type: Functional Requirement 1473 Device type: C0, C1, and C2 1475 Priority: High 1477 --- 1479 Req-ID: 4.6.003 1481 Title: Access control on management system and devices 1483 Description: Systems acting in a management role must provide an 1484 access control mechanism that allows the security administrator to 1485 restrict which devices can access the managing system (e.g., using 1486 an access control white list of known devices). On the other hand 1487 managed constrained devices must provide an access control 1488 mechanism that allows the security administrator to restrict how 1489 systems in a management role can access the device (e.g., no- 1490 access, read-only access, and read-write access). 1492 Source: Basic security requirement for use cases where access 1493 control is essential. 1495 Requirement Type: Functional Requirement 1497 Device type: C0, C1, and C2 1498 Priority: High 1500 --- 1502 Req-ID: 4.6.004 1504 Title: Select cryptographic algorithms that are efficient in both 1505 code space and execution time. 1507 Description: Cryptographic algorithms have a major impact in terms 1508 of both code size and overall execution time. It is therefore 1509 necessary to select mandatory to implement cryptographic 1510 algorithms (like some elliptic curve algorithm) that are 1511 reasonable to implement with the available code space and that 1512 have a small impact at runtime. Furthermore some wireless 1513 technologies (e.g., IEEE 802.15.4) require the support of certain 1514 cryptographic algorithms. It might be useful to choose algorithms 1515 that are likely to be supported in wireless chipsets for certain 1516 wireless technologies. 1518 Source: Generic requirement to reduce the footprint and CPU usage of 1519 a constrained device. 1521 Requirement Type: Non-Functional Requirement 1523 Device type: C0, C1, and C2 1525 Priority: High, Medium for hardware-supported algorithms. 1527 3.7. Energy Management 1529 Req-ID: 4.7.001 1531 Title: Management of Energy Resources 1533 Description: Enable managing power resources in the network, e.g. 1534 reduce the sampling rate of nodes with critical battery and reduce 1535 node transmission power, put nodes to sleep, put single interfaces 1536 to sleep, reject a management job based on available energy, 1537 criteria e.g. importance levels pre-defined by the management 1538 application, etc. (e.g. a task marked as essential can be executed 1539 even if the energy level is low). The device may further 1540 implement standard data models for energy management and expose it 1541 through a management protocol interface, e.g. EMAN MIB modules 1542 and extensions. It might be necessary to downscale EMAN MIBs for 1543 the use in C1 and C2 devices. 1545 Source: Use case Energy Management 1547 Requirement Type: Functional Requirement 1549 Device type: C0, C1, and C2 1551 Priority: Medium for the use case Energy Management, Low otherwise. 1553 --- 1555 Req-ID: 4.7.002 1557 Title: Support of energy-optimized communication protocols 1559 Description: Use of an optimized communication protocol to minimize 1560 energy usage for the device (radio) receiver/transmitter, on-air 1561 bandwidth (protocol efficiency), reduced amount of data 1562 communication between nodes (implies data aggregation and 1563 filtering but also a compact format for the transferred data). 1565 Source: Use cases Energy Management and Mobile Applications. 1567 Requirement Type: Non-Functional Requirement 1569 Device type: C2 1571 Priority: Medium 1573 --- 1575 Req-ID: 4.7.003 1577 Title: Support for layer 2 energy-aware protocols 1579 Description: The device will support layer 2 energy management 1580 protocols (e.g. energy-efficient Ethernet IEEE 802.3az) and be 1581 able to report on these. 1583 Source: Use case Energy Management 1585 Requirement Type: Non-Functional Requirement 1587 Device type: C0, C1, and C2 1589 Priority: Medium 1591 --- 1592 Req-ID: 4.7.004 1594 Title: Dying gasp 1596 Description: When energy resources draw below the red line level, 1597 the device will send a dying gasp notification and perform if 1598 still possible a graceful shutdown including conservation of 1599 critical device configuration and status information. 1601 Source: Use case Energy Management 1603 Requirement Type: Functional Requirement 1605 Device type: C0, C1, and C2 1607 Priority: Medium 1609 3.8. SW Distribution 1611 Req-ID: 4.8.001 1613 Title: Group-based provisioning 1615 Description: Support group-based provisioning, i.e. firmware update 1616 and configuration management, of a large set of constrained 1617 devices with eventual consistency and coordinated reload times. 1618 The device should accept group-based configuration management 1619 based on bulk commands, which aim similar configurations of a 1620 large set of constrained devices of the same type in a given 1621 group. Activation of configuration may be based on pre-loaded 1622 sets of default values. 1624 Source: All use cases 1626 Requirement Type: Non-Functional Requirement 1628 Device type: C0, C1, and C2 1630 Priority: Medium 1632 3.9. Traffic management 1634 Req-ID: 4.9.001 1636 Title: Congestion avoidance 1637 Description: Provide the ability to avoid congestion by modifying 1638 the device's reporting rate for periodical data (which is usually 1639 redundant) based on the importance and reliability level of the 1640 management data. This functionality is usually controlled by the 1641 managing entity, where the managing entity marks the data as 1642 important or relevant for reliability. However reducing a 1643 device's reporting rate can also be initiated by a device if it is 1644 able to detect congestion or has insufficient buffer memory. 1646 Source: Use cases with high reporting rate and traffic e.g. AMI or 1647 M2M. 1649 Requirement Type: Non-Functional Requirement 1651 Device type: C1 and C2 1653 Priority: Medium 1655 --- 1657 Req-ID: 4.9.002 1659 Title: Redirect traffic 1661 Description: Provide the ability for network nodes to redirect 1662 traffic from overloaded intermediary nodes in a network to another 1663 path in order to prevent congestion on a central server and in the 1664 primary network. 1666 Source: Use cases with high reporting rate and traffic e.g. AMI or 1667 M2M. 1669 Requirement Type: Non-Functional Requirement 1671 Device type: Intermediary entity in the network. 1673 Priority: Medium 1675 --- 1677 Req-ID: 4.9.003 1679 Title: Traffic delay schemes. 1681 Description: Provide the ability to apply delay schemes to incoming 1682 and outgoing links on an overloaded intermediary node as necessary 1683 in order to reduce the amount of traffic in the network. 1685 Source: Use cases with high reporting rate and traffic e.g. AMI or 1686 M2M. 1688 Requirement Type: Non-Functional Requirement 1690 Device type: Intermediary entity in the network. 1692 Priority: Medium 1694 3.10. Transport Layer 1696 Req-ID: 4.10.001 1698 Title: Scalable transport layer 1700 Description: Enable the use of a scalable transport layer, i.e. not 1701 sensitive to the decrease of the time between two client requests, 1702 which is useful for applications requiring frequent access to 1703 device data. 1705 Source: Applications with high frequent access to the device data. 1707 Requirement Type: Non-Functional Requirement 1709 Device type: C0, C1 and C2 1711 Priority: Medium 1713 --- 1715 Req-ID: 4.10.002 1717 Title: Reliable unicast transport of messages 1719 Description: Diverse applications need a reliable transport of 1720 messages. The reliability might be achieved based on a transport 1721 protocol such as TCP or can be supported based message repetition 1722 if an acknowledgement is missing. 1724 Source: Generally applications benefit from the reliability of the 1725 message transport. 1727 Requirement Type: Functional Requirement 1729 Device type: C0, C1, and C2 1730 Priority: High 1732 --- 1734 Req-ID: 4.10.003 1736 Title: Best-effort multicast 1738 Description: Provide best-effort multicast of messages, which is 1739 generally useful when devices need to discover a service provided 1740 by a server or many devices need to be configured by a managing 1741 entity at once based on the same data model. 1743 Source: Use cases where a device needs to discover services as well 1744 as use cases with high amount of devices to manage, which are 1745 hierarchically deployed, e.g. AMI or M2M. 1747 Requirement Type: Functional Requirement 1749 Device type: C0, C1, and C2 1751 Priority: Medium 1753 Req-ID: 4.10.004 1755 Title: Secure message transport. 1757 Description: Enable secure message transport providing 1758 authentication, data integrity, confidentiality by using existing 1759 transport layer technologies with small footprint such as TLS/ 1760 DTLS. 1762 Source: All use cases. 1764 Requirement Type: Non-Functional Requirements 1766 Device type: C1 and C2 1768 Priority: High 1770 3.11. Implementation Requirements 1772 Req-ID: 4.11.001 1774 Title: Avoid complex application layer transactions requiring large 1775 application layer messages. 1777 Description: Complex application layer transactions tend to require 1778 large memory buffers that are typically not available on C0 or C1 1779 devices and only by limiting functionality on C2 devices. 1780 Furthermore, the failure of a single large transaction requires 1781 repeating the whole transaction. On constrained devices, it is 1782 often more desirable to a large transaction down into a sequence 1783 of smaller transactions, which require less resources and allow to 1784 make progress using a sequence of smaller steps. 1786 Source: Basic requirement which concerns all use cases with memory 1787 constrained devices. 1789 Requirement Type: Non-Functional Requirement 1791 Device type: C0, C1, and C2 1793 Priority: High 1795 Req-ID: 4.11.002 1797 Title: Avoid reassembly of messages at multiple layers in the 1798 protocol stack. 1800 Description: Reassembly of messages at multiple layers in the 1801 protocol stack requires buffers at multiple layers, which leads to 1802 inefficient use of memory resources. This can be avoided by 1803 making sure the application layer, the security layer, the 1804 transport layer, the IPv6 layer and any adaptation layers are 1805 aware of the limitations of each other such that unnecessary 1806 fragmentation and reassembly can be avoided. In addition, message 1807 size constraints must be announced to protocol peers such that 1808 they can adapt and avoid sending messages that can't be processed 1809 due to resource constraints on the receiving device. 1811 Source: Basic requirement which concerns all use cases with memory 1812 constrained devices. 1814 Requirement Type: Non-Functional Requirement 1816 Device type: C0, C1, and C2 1818 Priority: High 1820 4. IANA Considerations 1822 This document does not introduce any new code-points or namespaces 1823 for registration with IANA. 1825 Note to RFC Editor: this section may be removed on publication as an 1826 RFC. 1828 5. Security Considerations 1830 This document discusses the problem statement and requirements on the 1831 network of constrained devices. If specific requirements for 1832 security will be identified, they will be described in future 1833 versions of this document. 1835 6. Contributors 1837 Ulrich Herberg (Fujitsu Laboratories of America) contributed to the 1838 Section 1.3 on Networks Types and Characteristics in Focus. 1840 7. Acknowledgments 1842 Following persons reviewed and provided valuable comments to 1843 different versions of this document: 1845 Dominique Barthel, Carsten Bormann, Zhen Cao, Benoit Claise, Bert 1846 Greevenbosch, Ulrich Herberg, James Nguyen, Anuj Sehgal, Zach Shelby, 1847 and Peter van der Stok. 1849 The editors would like to thank the reviewers and the participants on 1850 the Coman maillist for their valuable contributions and comments. 1852 8. References 1854 8.1. Normative References 1856 8.2. Informative References 1858 [RFC6632] Ersue, M. and B. Claise, "An Overview of the IETF Network 1859 Management Standards", RFC 6632, June 2012. 1861 [I-D.ietf-lwig-terminology] 1862 Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1863 Constrained Node Networks", draft-ietf-lwig-terminology-06 1864 (work in progress), December 2013. 1866 [I-D.ietf-core-coap] 1867 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 1868 Application Protocol (CoAP)", draft-ietf-core-coap-18 1869 (work in progress), June 2013. 1871 [I-D.ietf-roll-terminology] 1872 Vasseur, J., "Terms used in Routing for Low power And 1873 Lossy Networks", draft-ietf-roll-terminology-13 (work in 1874 progress), October 2013. 1876 [M2MDEVCLASS] 1877 Open Mobile Alliance, "OMA M2M Device Classification 1878 v1.0", October 2012, . 1882 [EU-IOT-A] 1883 EU Commission Seventh Framework Programme, "EU FP7 Project 1884 Internet-of-Things Architecture", . 1886 [EU-SENSEI] 1887 EU Commission Seventh Framework Programme, "EU Project 1888 SENSEI", . 1890 [EU-FI-WARE] 1891 EU Commission Future Internet Public Private Partnership 1892 (FI-PPP), "EU Project Future Internet-Core Platform", 1893 . 1895 [EU-IOT-BUTLER] 1896 EU Commission Seventh Framework Programme, "EU FP7 Project 1897 Butler Smartlife", . 1899 [COM-US] Ersue, M., "Constrained Management: Use Cases", 1900 draft-ietf-opsawg-coman-use-cases (work in progress), 1901 October 2013. 1903 Appendix A. Related Development in other Bodies 1905 Note that over time the summary on the related work in other bodies 1906 might become outdated. 1908 A.1. ETSI TC M2M 1910 ETSI Technical Committee Machine-to-Machine (ETSI TC M2M) aims to 1911 provide an end-to-end view of M2M standardization, which enables the 1912 integration of multiple vertical M2M applications. The main goal is 1913 to overcome the current M2M market fragmentation and to reuse 1914 existing mechanisms from telecom standards such as from OMA or 3GPP. 1916 ETSI Release 1 is functionally frozen. The main focus is on use 1917 cases for Smart Metering (Technical Report (TR) 102 691) but it also 1918 includes eHealth use cases (TR 102 732) and some others. The Service 1919 requirements (Technical Standard (TS) 102 689) derived from the use 1920 cases, and the functional architecture specification (TS 102 690), 1921 will together define the M2M platform. The architecture consists of 1922 Service Capabilities (SC), which are basic functional building blocks 1923 for building the M2M platform. 1925 Smart Metering is seen as the important showcase for M2M. It is 1926 believed that the Service Enablers that were defined based on the 1927 work done for Smart Metering and eHealth segments will also allow the 1928 building of other services like vending machines, alarm systems etc. 1930 The functional architecture includes following management-related 1931 definitions: 1933 o Network Management Functions: consists of all functions required 1934 to manage the Access, Transport and Core networks: these include 1935 Provisioning, Supervision, Fault Management, etc. 1937 o M2M Management Functions: consists of functions required to manage 1938 generic functionalities of M2M Applications and M2M Service 1939 Capabilities in the Network and Applications Domain. The 1940 management of the M2M Devices and Gateways may use specific M2M 1941 Service Capabilities. 1943 The Release 2 work of ETSI TC M2M has started beginning of 2012. 1944 Following is a list of networking- and management-related topics 1945 under work: 1947 o Interworking with 3GPP networks. This is a new work item, and no 1948 discussion has been held on technical details. The intent is to 1949 define which ETSI TC M2M functions are applicable when 3GPP NW is 1950 used as transport. It is possible that this work would also cover 1951 details on how to use 3GPP interfaces, e.g. those defined in the 1952 SIMTC work, but also for charging and policy control. 1954 o Creating a Semantic Model or Data Abstraction layer for vertical 1955 industries and interworking. This would provide some high level 1956 information description that would be usable for interworking with 1957 local networks (e.g. ZigBee), and also for verticals, and it 1958 would allow the ETSI Service Enablement layer to also understand 1959 the data, instead of being just a bit storage and bit pipe. All 1960 technical details are still under discussion, but it has been 1961 agreed that a function for this exists in the architecture at 1962 least for interworking. 1964 A.2. OASIS 1966 Developments in OASIS related to management of constrained networks 1967 are following: 1969 o The Energy Interoperation TC works to define interaction between 1970 Smart Grids and their end nodes, including Smart Buildings, 1971 Enterprises, Industry, Homes, and Vehicles. The TC develops data 1972 and communication models that enable the interoperable and 1973 standard exchange of signals for dynamic pricing, reliability, and 1974 emergencies. The TC's agenda also extends to the communication of 1975 market participation data (such as bids), load predictability, and 1976 generation information. The first version of the Energy 1977 Interoperation specification is in final review. 1979 o OASIS Open Data Protocol (OData) aims to simplify the querying and 1980 sharing of data across disparate applications and multiple 1981 stakeholders for re-use in the enterprise, Cloud, and mobile 1982 devices. As a REST-based protocol, OData builds on HTTP, AtomPub, 1983 and JSON using URIs to address and access data feed resources. It 1984 enables information to be accessed from a variety of sources 1985 including (but not limited to) relational databases, file systems, 1986 content management systems, and traditional Web sites. 1988 o Open Building Information Exchange (oBIX) aims to enable the 1989 mechanical and electrical control systems in buildings to 1990 communicate with enterprise applications, and to provide a 1991 platform for developing new classes of applications that integrate 1992 control systems with other enterprise functions. Enterprise 1993 functions include processes such as Human Resources, Finance, 1994 Customer Relationship Management (CRM), and Manufacturing. 1996 A.3. OMA 1998 OMA is currently working on Lightweight M2M Enabler, OMA Device 1999 Management (OMA DM) Next Generation, and a white paper on M2M Device 2000 Classification. 2002 The Lightweight M2M Enabler covers both M2M device management and 2003 service management for constrained devices. In the case of less 2004 constrained devices, OMA DM Next Generation Enabler may be more 2005 appropriate. OMA DM is structured around Management Objects (MO), 2006 each specified for a specific purpose. There is also ongoing work 2007 with various other MOs such as the Gateway Management Object (GwMO). 2008 A draft for the "Lightweight M2M Requirements" is available. 2010 OMA Lightweight M2M and OMA DM Next Generation are important to M2M 2011 device management, provisioning and service managements in both the 2012 protocol and management objects. OMA Lightweight M2M work seems to 2013 have grown from its original scope of being targeted for very simple 2014 devices only, i.e. such that could not handle all those protocols 2015 that ETSI M2M requires. 2017 The white paper on the M2M Device Classification [M2MDEVCLASS] 2018 provides an M2M device classification framework based on the 2019 horizontal attributes (e.g., wide or local area communication 2020 interface, IP stack, I/O capabilities) of interest to communication 2021 service providers and M2M service providers, independent of vertical 2022 markets, such as smart grid, connected cars, e-health, etc. The 2023 white paper can be used as a tool to analyze the applicability of 2024 existing requirements and specifications developed by OMA and other 2025 cooperative standards development organizations. 2027 A.4. IPSO Alliance 2029 IPSO Alliance developed a profile for Device Functions supporting 2030 devices such as sensors with a limited user interface, where the 2031 configuration of even basic parameters is impossible to do manually. 2032 This is a challenge especially for consumer devices that are managed 2033 by non-professional users. The configuration of a web service 2034 application running on a constrained device goes beyond the 2035 autoconfiguration of the IP stack and local information (e.g. proxy 2036 address). Constrained devices need additionally service provider and 2037 user account related configuration, such as an address/locator and 2038 the username for a web server. 2040 IPSO discusses the use cases and requirements for user friendly 2041 configuration of such information on a constrained device, and 2042 specifies how IPSO profile Device Function Set can be used in the 2043 process. It furthermore defines a standard format for the basic 2044 application configuration information. 2046 Appendix B. Related Research Projects 2048 o The EU project IoT-A (Internet-of-Things Architecture) develops an 2049 architectural reference model together with the definition of an 2050 initial set of key building blocks. These enable the integration 2051 of IoT into the service layer of the Future Internet, and realize 2052 a novel resolution infrastructure, as well as a network 2053 infrastructure that allows the seamless communication flow between 2054 IoT devices and services. The development includes a conceptual 2055 model of a smart object as well as a basic Internet of Things 2056 reference model defining the interaction and communication between 2057 IoT devices and relevant entities. The requirements document 2058 includes also network and information management requirements (see 2059 [EU-IOT-A]). 2061 o The EU project SENSEI specified the document on 'End to End 2062 Networking and Management' for Wireless Sensor and Actuator 2063 Networks. This report presents several research results carried 2064 out in SENSEI's tasks related to End-to-End Networking and 2065 Management. Particular analyses have been addressed related to 2066 naming and addressing of resources, management of resources, 2067 resource plug and play, resource level mobility and traffic 2068 modelling. The detailed analysis on each of these topics is 2069 intended to identify possible gaps between their specific 2070 mechanisms and the functional requirements in the SENSEI reference 2071 architecture (see [EU-SENSEI]). 2073 o The EU project FI-WARE is developing the Things Management GE 2074 (generic enabler), which uses a data model derived from the OMA DM 2075 NGSI data model. Using the abstraction level of things which 2076 include non-technical things like rooms, places and people, Things 2077 Management GE aims to discover and look up IoT resources that can 2078 provide information about things or actuate on these things. The 2079 system aimes to manage the dynamic associations between IoT 2080 resources and things in order to allow internal components as well 2081 as external applications to interact with the system using the 2082 thing abstraction as the core concept (see [EU-FI-WARE]). 2084 o EU project BUTLER Smart Life discusses different IoT management 2085 aspects and collects requirements for smart life use cases (e.g. 2086 smart home or smart city) mainly from service management pov. (see 2087 [EU-IOT-BUTLER]). 2089 Appendix C. Open issues 2091 o Section 4 on the management requirements, as the core section in 2092 the document, needs further consolidation. 2094 Appendix D. Change Log 2096 D.1. draft-ersue-constrained-mgmt-03 - 2097 draft-ersue-opsawg-coman-probstate-reqs-00 2099 o Reduced the terminology section for terminology addressed in the 2100 LWIG terminology draft. Referenced the LWIG terminology draft. 2102 o Checked and aligned all terminology against the LWIG terminology 2103 draft. 2105 o Moved section 1.4. Constrained Device Deployment Options and 2106 section 3. Use Cases to the companion document [COM-US]. 2108 o Renamed Section 1.3. Class of Networks in Focus to "Network Types 2109 in Focus" and removed abbreviations C0, C1 and C2 for network 2110 classes as they have not been used. 2112 o Changed requirement priority classes to be High, Medium and Low. 2114 o Changed requirement types to be Functional and Non-Functional and 2115 added text to explain the requirement types. 2117 o Reformulation of some text parts for more clarity. 2119 D.2. draft-ersue-constrained-mgmt-02-03 2121 o Extended the terminology section and removed some of the 2122 terminology addressed in the new LWIG terminology draft. 2123 Referenced the LWIG terminology draft. 2125 o Moved Section 1.3. on Constrained Device Classes to the new LWIG 2126 terminology draft. 2128 o Class of networks considering the different type of radio and 2129 communication technologies in use and dimensions extended. 2131 o Extended the Problem Statement in Section 2. following the 2132 requirements listed in Section 4. 2134 o Following requirements, which belong together and can be realized 2135 with similar or same kind of solutions, have been merged. 2137 * Distributed Management and Peer Configuration, 2139 * Device status monitoring and Neighbor-monitoring, 2140 * Passive Monitoring and Reactive Monitoring, 2142 * Event-driven self-management - Self-healing and Periodic self- 2143 management, 2145 * Authentication of management systems and Authentication of 2146 managed devices, 2148 * Access control on devices and Access control on management 2149 systems, 2151 * Management of Energy Resources and Data models for energy 2152 management, 2154 * Software distribution (group-based firmware update) and Group- 2155 based provisioning. 2157 o Deleted the empty section on the gaps in network management 2158 standards, as it will be written in a separate draft. 2160 o Added links to mentioned external pages. 2162 o Added text on OMA M2M Device Classification in appendix. 2164 D.3. draft-ersue-constrained-mgmt-01-02 2166 o Extended the terminology section. 2168 o Added additional text for the use cases concerning deployment 2169 type, network topology in use, network size, network capabilities, 2170 radio technology, etc. 2172 o Added examples for device classes in a use case. 2174 o Added additional text provided by Cao Zhen (China Mobile) for 2175 Mobile Applications and by Peter van der Stok for Building 2176 Automation. 2178 o Added the new use cases 'Advanced Metering Infrastructure' and 2179 'MANET Concept of Operations in Military'. 2181 o Added the section 'Managing the Constrainedness of a Device or 2182 Network' discussing the needs of very constrained devices. 2184 o Added a note that the requirements in Section 3 need to be seen as 2185 standalone requirements and the current document does not 2186 recommend any profile of requirements. 2188 o Added Section 3 on the detailed requirements on constrained 2189 management matched to management tasks like fault, monitoring, 2190 configuration management, Security and Access Control, Energy 2191 Management, etc. 2193 o Solved nits and added references. 2195 o Added Appendix A on the related development in other bodies. 2197 o Added Appendix B on the work in related research projects. 2199 D.4. draft-ersue-constrained-mgmt-00-01 2201 o Splitted the section on 'Networks of Constrained Devices' into the 2202 sections 'Network Topology Options' and 'Management Topology 2203 Options'. 2205 o Added the use case 'Community Network Applications' and 'Mobile 2206 Applications'. 2208 o Provided a Contributors section. 2210 o Extended the section on 'Medical Applications'. 2212 o Solved nits and added references. 2214 Authors' Addresses 2216 Mehmet Ersue (editor) 2217 Nokia Solutions and Networks 2219 Email: mehmet.ersue@nsn.com 2221 Dan Romascanu 2222 Avaya 2224 Email: dromasca@avaya.com 2226 Juergen Schoenwaelder 2227 Jacobs University Bremen 2229 Email: j.schoenwaelder@jacobs-university.de