Internet Engineering Task Force M. Ersue, Ed. Internet-Draft Nokia Siemens Networks Intended status: Informational D. Romascanu, Ed. Expires: January 17, 2013 Avaya J. Schoenwaelder, Ed. Jacobs University Bremen July 16, 2012 Management of Networks of Constrained Devices: Use Cases and Requirements draft-ersue-constrained-mgmt-01 Abstract This document raises the questions on and discusses the use cases and requirements for the management of networks with constrained devices. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 17, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as Ersue, et al. Expires January 17, 2013 [Page 1] Internet-Draft Constrained Mgmt: Use Case & Requirements July 2012 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Network Topology Options . . . . . . . . . . . . . . . . . 5 1.4. Management Topology Options . . . . . . . . . . . . . . . 5 1.5. Constrained Device Classes . . . . . . . . . . . . . . . . 6 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 8 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Environmental Monitoring . . . . . . . . . . . . . . . . . 10 3.2. Medical Applications . . . . . . . . . . . . . . . . . . . 10 3.3. Industrial Applications . . . . . . . . . . . . . . . . . 11 3.4. Home Automation . . . . . . . . . . . . . . . . . . . . . 12 3.5. Building Automation . . . . . . . . . . . . . . . . . . . 13 3.6. Energy Management . . . . . . . . . . . . . . . . . . . . 14 3.7. Transport Applications . . . . . . . . . . . . . . . . . . 15 3.8. Infrastructure Monitoring . . . . . . . . . . . . . . . . 16 3.9. Community Network Applications . . . . . . . . . . . . . . 17 3.10. Mobile Applications . . . . . . . . . . . . . . . . . . . 18 4. Requirements per Device Class and Applications . . . . . . . . 20 4.1. Requirements Template . . . . . . . . . . . . . . . . . . 20 4.2. Requirement Examples . . . . . . . . . . . . . . . . . . . 20 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 24 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 9.1. Normative References . . . . . . . . . . . . . . . . . . . 26 9.2. Informative References . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 Ersue, et al. Expires January 17, 2013 [Page 2] Internet-Draft Constrained Mgmt: Use Case & Requirements July 2012 1. Introduction 1.1. Overview Small devices with limited CPU, memory and power resources, so called constrained devices (aka. sensor, smart object or smart device) can constitute a network. Such a network of constrained devices itself may be constrained or challenged, e.g. with unreliable or lossy channels, wireless technologies with limited bandwidth and a dynamic topology, needing the service of a gateway or proxy to connect to the Internet. In other scenarios the constrained devices can be connected to a non-constrained network using off-the-shelf protocol stacks. Constrained devices might be in charge of gathering information in diverse settings including natural ecosystems, buildings, and factories and send the information to one or more server stations. Constrained devices may work under severe resource constraints such as limited battery and computing power, little memory and insufficient wireless bandwidth, and communication capabilities. A central entity, e.g., a base station or controlling server, might have more computational and communication resources, which acts as a gateway between the constrained devices and the application logic in the core network. Today diverse size of small devices with different resources and capabilities are becoming connected. Mobile personal gadgets, building-automation devices, cellular phones, M2M devices, etc. benefit from interacting with other "things" in the near or somewhere in the Internet. With this The Internet of Things becomes a reality build up of uniquely identifiable objects (things). And over the next decade, this could grow to trillions of constrained devices and will greatly increase the Internet's size and scope. Network management is characterized by monitoring network status, detecting faults and inferring their causes, setting network parameters, and carrying out actions to remove faults and improve the performance. The traditional network management application periodically collects information from a set of elements that are needed to be managed, processes the data, and presents them to the network management users. Constrained devices, however, often have limited power, low transmission range, and might be unreliable. They might also need to work in hostile environments with advanced security requirements or need to be used in harsh environments for a long time period without supervision. Due to such constraints, the management of a network with constrained devices offers different types of challenges compared to the management of a traditional IP network. Ersue, et al. Expires January 17, 2013 [Page 3] Internet-Draft Constrained Mgmt: Use Case & Requirements July 2012 The IETF has already done a lot of standardization work to enable the communication in IP networks and to manage such networks as well as the manifold type of nodes in these networks [RFC6632]. However, the IETF so far has not developed any specific technologies for the management of constrained devices and the networks comprised by constrained devices. IP-based sensors or constrained devices in such an environment, i.e., devices with very limited memory and CPU resources, use today application-layer protocols in an ad-hoc manner to do simple resource management and monitoring. This document raises the questions on and aims to understand the use cases, requirements and the required solution space for the management of a network with constrained devices. The document especially aims to avoid recommending any particular solutions. Section 1.3 and Section 1.4 describe different topology options for the networking and management of constrained devices. Section 1.5 explains the classes with which constrained devices can be categorized. Section 2 aims to provide a problem statement on the issue of the management of networked constrained devices. Section 3 lists diverse use cases and scenarios for the management from the network as well as from the application point of view. Section 4 lists requirements on the management of applications and networks with constrained devices. 1.2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The following terms are used throughout this documentation: Constrained Device: A device with resource constraints, e.g., limited amount of memory, limited processing capabilities, limited energy supply. Constrained Network: A network constrained in resources, e.g., bandwidth, latency or data rate. Network of Constrained Devices: A network to which constrained devices are connected. It may or may not be a Constrained Network. Client: The originating endpoint of a request; the destination endpoint of a response. Ersue, et al. Expires January 17, 2013 [Page 4] Internet-Draft Constrained Mgmt: Use Case & Requirements July 2012 Server: The destination endpoint of a request; the originating endpoint of a response. 1.3. Network Topology Options We differentiate following topology options for the networks of constrained devices: o a network of constrained devices which communicate with each other, o Constrained devices which are connected directly to the Internet or a bigger IP network o A network of constrained devices which communicate with a gateway or proxy with more communication capabilities acting possibly as a representative of the device to entities in the non-constrained network o Constrained devices, which are connected to the Internet or a bigger IP network via a gateway/proxy o A hierarchy of constrained devices, e.g., a network of C0 devices connected to one or more C1 devices - connected to one or more C2 devices - connected to one or more gateways - connected to some application servers or NMS system o The possibility of device grouping (possibly in a dynamic manner) such as that the grouped devices can act as one logical device at the edge of the network and one device in this group can act as the managing entity 1.4. Management Topology Options We differentiate following options for the management of networks of constrained devices: o A network of constrained devices managed by one central manager. A logically centralized management might be implemented in a hierarchical fashion for scalability and robustness reasons. The manager and the management application logic might have a gateway/ proxy in between or might be on different nodes in different networks, e.g., management application running on a cloud server. o Distributed management, where a constrained network is managed by more than one manager. Each manager controls a subnetwork and may communicate directly with other manager stations in a cooperative fashion. The distributed management may be weakly distributed, Ersue, et al. Expires January 17, 2013 [Page 5] Internet-Draft Constrained Mgmt: Use Case & Requirements July 2012 where functions are broken down and assigned to many managers dynamically, or strongly distributed, where almost all managed things have embedded management functionality and explicit management disappears, which usually comes with the price that the strongly distributed management logic now needs to be managed. o Hierarchical management, where a hierarchy of constrained networks are managed by the managers at their corresponding hierarchy level. I.e. each manager is responsible for managing the nodes in its sub-network. It passes information from its sub-network to its higher-level manager, and also disseminates management functions received from the higher-level manager to its sub- network. Hierarchical management is essentially a scalability mechanism, logically the decision making may be still centralized. 1.5. Constrained Device Classes To organize the discussion, it is often useful to have some succinct terminology for different classes of constrained devices. Following [I-D.ietf-lwig-guidance], we distinguish the following classes: +---------+-----------------------+-------------------------+ | Name | data size (e.g., RAM) | code size (e.g., Flash) | +---------+-----------------------+-------------------------+ | Class 0 | << 10 KiB | << 100 KiB | | | | | | Class 1 | ~ 10 KiB | ~ 100 KiB | | | | | | Class 2 | ~ 50 KiB | ~ 250 KiB | +---------+-----------------------+-------------------------+ Table 1: Classes of Constrained Devices Class-0 (C0) devices are very constrained sensor-like motes. They will most likely not have the possibility to have a direct communications with the Internet in a secure manner. These class-0 devices will participate in Internet communications with the help of larger devices acting as proxy or gateways. It is assumed that C0 devices cannot be managed comprehensively in the traditional sense. They will be most likely preconfigured and if ever will be reconfigured rarely with a very small data set. At most they could answer keep-alive signals and send on/off or basic health indications. Class-1 (C1) devices cannot easily talk to other Internet nodes with a full protocol stack using HTTP, TLS and related security protocols, and XML-based data representations. However, they have enough power to use a reduced or lightweight protocol stack (e.g., with CoAP over Ersue, et al. Expires January 17, 2013 [Page 6] Internet-Draft Constrained Mgmt: Use Case & Requirements July 2012 UDP) and participate in meaningful conversations without the help of a gateway node. So they can be integrated into an IP network in one way or the other but need to spare with memory for the protocol and application usage. Class-2 (C2) can support mostly the same protocol stack as used on notebooks or servers. However, even these devices can benefit from lightweight and energy-efficient protocols and consuming less bandwidth on air. Furthermore, using less network resources would leave more resources available to applications. As such using the same protocol stack on Class 1 and 2 devices might reduce development costs and increase the interoperability. For C1 devices it is indeed important to understand what type of applications they could run and which management mechanisms would be most suitable. Even though they have some more functionality available, C2 devices need to be assessed for the type of applications they will be running and the management they would need. To be able to derive the requirements, the uses cases and the involvement of the devices in the management scenario need to be analyzed. The use cases where C1 or C2 devices build a cluster or are part of a hierarchy as well as the assumed degree of automation might be essentially important. C1 and C2 devices are typically driven by 8-bit or 16-bit processors and they have in common that they are severely constrained by the amount of memory they can use. There are, however, also a number of devices that can afford to have 32-bit processors and memory sizes counted in MiB instead of KiB. While such devices are easily capable to run a complete IP protocol stack, they still can be constrained by a limited energy supply. We will call this class of devices power constrained devices. Ersue, et al. Expires January 17, 2013 [Page 7] Internet-Draft Constrained Mgmt: Use Case & Requirements July 2012 2. Problem Statement The terminology for the "Internet of Things" (IoT) is still nascent, and depending on the network type or layer in focus diverse technologies and terms are in use. Common to all these considerations is the "Things" or "Objects" are supposed to have physical or virtual identities using interfaces to communicate. In this context, we need to differentiate between the Constrained or Smart Devices identified by an IP address compared to virtual entities such as Smart Objects, which can be identified as a resource or a virtual object by using a unique identifier. Furthermore, the smart devices usually have a limited memory and CPU power as well as aim to be self-configuring and easy to deploy. However, the tininess of the network nodes requires a rethinking of the protocol characteristics concerning power consumption, performance, memory, and CPU usage. As such, there is a demand for protocol simplification, energy-efficient communication, less CPU usage and small memory footprint. On the application layer the IETF is already developing protocols like the Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] supporting constrained devices and networks e.g., for smart energy applications or home automation environments. The deployment of such an environment involves in fact many, in some scenarios up to million small devices (e.g. smart meters), which produce a huge amount of data. This data needs to be collected, filtered, and pre-processed for further use in diverse services. Considering the high number of nodes to deploy, one has to think on manageability aspects of the smart devices and plan for easy deployment, configuration and management of the networks of constrained devices as well as the devices themselves. As a consequence, seamless monitoring and self-configuration of such network nodes becomes more and more imperative. Self-configuration and self-management is already a reality in the standards of some of the bodies such as 3GPP. To introduce self-configuration of smart devices successfully a device-initiated connection establishment might be useful. A simple application layer protocol, such as CoAP, is essential to address the issue of efficient object-to-object communication and information exchange. Such an information exchange should be done based on interoperable data models to enable the exchange and interpretation of diverse application and management related data. In an ideal world, we would have only one network management protocol for monitoring, configuration, and exchanging management data, Ersue, et al. Expires January 17, 2013 [Page 8] Internet-Draft Constrained Mgmt: Use Case & Requirements July 2012 independently of the type of network (e.g., Smart Grid, wireless access or core network). Furthermore, it would be also desirable to derive the basic data models for constrained devices from the core model we use today to enable reuse of functionality and end-to-end information exchange. However, the current management protocols seem to be too heavyweight compared to the capabilities the constrained devices have and are not applicable directly for the use in a network of constrained devices. Furthermore, the data models addressing the requirements of such smart devices need yet to be designed. The IETF so far has not developed any specific technologies for the management of constrained devices and the networks comprised by constrained devices. IP-based sensors or constrained devices in such an environment, i.e., devices with very limited memory and CPU resources, use today, e.g., application-layer protocols to do simple resource management and monitoring. This might be sufficient for some basic cases, however, there is a need to reconsider the network management mechanisms based on the new, changed as well as reduced requirements coming from smart devices and the network of such constrained devices. Albeit it is questionable whether we can take the same comprehensive approach we use in an IP network also for the management of constrained devices. Hence the management of a network with constrained devices might become necessary to design as much as possible simplified and less complex. Ersue, et al. Expires January 17, 2013 [Page 9] Internet-Draft Constrained Mgmt: Use Case & Requirements July 2012 3. Use Cases This section discusses some application scenarios where networks of constrained devices are expected to be deployed. For each application scenario, we first briefly describe the characteristics followed by a discussion how network management can be provided, who is likely going to be responsible for it, and on which time scale management operations are likely carried out. 3.1. Environmental Monitoring Environmental monitoring applications are characterized by the deployment of a number of sensors to monitor emissions, water quality, or even the movements and habits of wildlife. Other applications in this category include earth quake or tsunami early- warning systems. The sensors often span a large geographic area, they can be mobile, and they are often difficult to replace. Furthermore, the sensors are usually not protected against tampering. Management of environmental monitoring applications is largely concerned with the monitoring whether the system is still functional and the roll-out of new constrained devices in case the system looses too much of its structure. The constrained devices themselves need to be able to establish connectivity (auto-configuration) and they need to be able to deal with events such as loosing neighbors or being moved to other locations. Management responsibility typically rests with the organization running the environmental monitoring application. Since these monitoring application must be designed to tolerate a number of failures, the time scale for detecting and recording failures is for some of these applications likely measured in hours and repairs might easily take days. However, for certain environmental monitoring applications, much tighter time scales may exist and might be enforced by regulations (e.g., monitoring of nuclear radiation). 3.2. Medical Applications Constrained devices can be seen as an enabling technology for advanced and possibly remote health monitoring and emergency notification systems, ranging from blood pressure and heart rate monitors to advanced devices capable to monitor implanted technologies, such as pacemakers or advanced hearing aids. Medical sensors may not only be attached to human bodies, they might also exist in the infrastructure used by humans such as bathrooms or kitchens. Medical applications will also be used to ensure treatments are being applied properly and they might guide people losing orientation. Fitness and wellness applications, such as Ersue, et al. Expires January 17, 2013 [Page 10] Internet-Draft Constrained Mgmt: Use Case & Requirements July 2012 connected scales or wearable heart monitors, encourage consumers to exercise and empower self-monitoring of key fitness indicators. Different applications use Bluetooth, Wi-Fi or Zigbee connections to access the patient's smartphone or home cellular connection to access the Internet. Constrained devices that are part of medical applications are either managed by the users of those devices or by an organization providing medical (monitoring) services for physicians. In the first case, management must be automatic and or easy to install and setup by average people. In the second case, it can be expected that devices are controlled by specially trained people. In both cases, however, it is crucial to protect the privacy of the people to which medical devices are attached. Even though the data collected by a heart beat monitor might be protected, the pure fact that someone carries such a device may need protection. As such, certain medical appliances may not want to participate in discovery and self-configuration protocols in order to remain invisible. Many medical devices are likely used (and relied upon) to provide data to physicians in critical situations since the biggest market is likely elderly and handicapped people. As such, fault detection of the communication network or the constrained devices becomes a crucial function that must be carried out with high reliability and, depending on the medical appliance and its application, within seconds. 3.3. Industrial Applications Industrial Applications and smart manufacturing refer not only to production equipment, but also to a factory that carries out centralized control of energy, HVAC (heating, ventilation, and air conditioning), lighting, access control, etc. via a network. For the management of a factory it is becoming essential to implement smart capabilities. From an engineering standpoint, industrial applications are intelligent systems enabling rapid manufacturing of new products, dynamic response to product demand, and real-time optimization of manufacturing production and supply chain networks. Potential industrial applications e.g. for smart factories and smart manufacturing are: o Digital control systems with embedded, automated process controls, operator tools, and service information systems optimizing plant operations and safety. o Asset management using predictive maintenance tools, statistical evaluation, and measurements maximizing plant reliability. Ersue, et al. Expires January 17, 2013 [Page 11] Internet-Draft Constrained Mgmt: Use Case & Requirements July 2012 o Smart sensors detecting anomalies to avoid abnormal or catastrophic events. o Smart systems integrated within the industrial energy management system and externally with the smart grid enabling real-time energy optimization. Sensor networks are an essential technology used for smart manufacturing. Measurements, automated controls, plant optimization, health and safety management, and other functions are provided by a large number of networked sectors. Data interoperability and seamless exchange of product, process, and project data are enabled through interoperable data systems used by collaborating divisions or business systems. Intelligent automation and learning systems are vital to smart manufacturing but must be effectively integrated with the decision environment. Wireless sensor networks (WSN) have been developed for machinery condition-based maintenance (CBM) as they offer significant cost savings and enable new functionalities. Inaccessible locations, rotating machinery, hazardous areas, and mobile assets can be reached with wireless sensors. WSNs can provide today wireless link reliability, real-time capabilities, and quality- of-service and enable industrial and related wireless sense and control applications. Management of industrial and factory applications is largely focused on the monitoring whether the system is still functional, real-time continuous performance monitoring and optimization as necessary. The factory network might be part of a campus network or connected to the Internet. The constrained devices in such a network need to be able to establish configuration themselves (auto-configuration) and might need to deal with error conditions as much as possible locally. Access control has to be provided with multi-level administrative access and security. Support and diagnostics can be provided through remote monitoring access centralized outside of the factory. Management responsibility is typically owned by the organization running the industrial application. Since the monitoring applications must handle a potentially large number of failures, the time scale for detecting and recording failures is for some of these applications likely measured in minutes. However, for certain industrial applications, much tighter time scales may exist, e.g. in real-time, which might be enforced by the manufacturing process or the use of critical material. 3.4. Home Automation Home automation includes the control of lighting, heating, ventilation, air conditioning, appliances, and entertainment devices Ersue, et al. Expires January 17, 2013 [Page 12] Internet-Draft Constrained Mgmt: Use Case & Requirements July 2012 to improve convenience, comfort, energy efficiency and security. It can be seen as a residential extension of building automation. Home automation networks need a certain amount of configuration (associating switches or sensors to actors) that is either provided by electricians deploying home automation solutions or done by residents by using the application user interface to configure (parts of) the home automation solution. Similarly, failures may be reported via suitable interfaces to residents or they might be recorded and made available to electricians in charge of the maintenance of the home automation infrastructure. The management responsibility lies either with the residents or it may be outsourced to electricians providing management of home automation solutions as a service. The time scale for failure detection and resolution is in many cases likely counted in hours to days. 3.5. Building Automation Building automation comprises the distributed systems designed and deployed to monitor and control the mechanical, electrical and electronic systems inside buildings with various destinations (e.g., public and private, industrial, institutions, or residential). Advanced Building Automation Systems (BAS) may be deployed concentrating the various functions of safety, environmental control, occupancy, security. In some cases the deployment of the various functional systems may be made atop of the same communication infrastructure, which may involve wired or wireless communications networks inside the building. Building automation requires the deployment of a large number of sensors that monitor the status of devices, and parameters inside the building and controllers with different specialized functionality for areas with or the totality of the building. Examples of functions performed by such controllers are the regulating the quality, humidity and temperature of the air inside the building and lighting. Other systems may report the status of the machinery inside the building like elevators, or inside the rooms like projectors in meeting rooms. Security cameras and sensors may be deployed and operated on the same or on separate dedicated infrastructures. The deployment area of a BAS is typically inside one building (or part of it) or several buildings geographically grouped in a campus. Some of the sensors in Building Automation Systems (for example fire alarms or security systems) register, record and transfer critical alarms information and must to be resilient to events like loss of power or security attacks. This leads to the need that some Ersue, et al. Expires January 17, 2013 [Page 13] Internet-Draft Constrained Mgmt: Use Case & Requirements July 2012 components and subsystems operate in constrained conditions. Also in some environments the malfunctioning of a control system (like temperature control) needs to be reported in the shortest possible time. Complex control systems can misbehave, and their critical status reporting and safety algorithms need to be basic and robust and perform even in critical conditions. 3.6. Energy Management [I-D.ietf-eman-framework] defines a framework for providing Energy Management for devices within or connected to communication networks. This document observes that one of the challenges of energy management is that a power distribution network is responsible for the supply of energy to various devices and components, while a separate communication network is typically used to monitor and control the power distribution network. Devices that have energy management capability are defined as Energy Devices and identified components within a device (Energy Device Components) can be monitored for parameters like Power, Energy, Demand and Power Quality. If a device contains batteries, they can be also monitored and managed. Energy devices differ in complexity and may include basic sensors or switches, specialized electrical meters, or power distribution units (PDU), and also subsystems inside network devices (routers, network switches) or home or industrial appliances. An Energy Management System is a combination of hardware and software used to administer a network with the primary purpose being Energy Management. The operators of such systems are either the utility providers or customers that aim to control and reduce the energy consumption and the associated costs. The topologies differ and the radius of deployment can cover areas from small surfaces (individual homes) to large geographical areas. [I-D.ietf-eman-requirements] discusses the requirements for energy management concerning monitoring and control functions. A smart grid is an electrical grid that uses data networks to gather and act on information, in an automated fashion with the goal to improve the efficiency, reliability, economics, and sustainability of the production and distribution of electricity. As such Smart Grid provides sustainable and reliable generation, transmission, distribution, storage and consumption of electrical energy based on advanced energy and ICT solutions and enables e.g. following specific application areas: Smart transmission systems, Demand Response/Load Management, Substation Automation, Advanced Distribution Management, Advanced Metering Infrastructure (AMI), Smart Metering, Smart Home and Building Automation, E-mobility, etc. Ersue, et al. Expires January 17, 2013 [Page 14] Internet-Draft Constrained Mgmt: Use Case & Requirements July 2012 Smart Metering is a good example of a machine-to-machine (M2M) application and can be realized as one of the vertical applications in an M2M environment. Many different type of possibly wireless small meters produce all together a huge amount of data which is collected by a central entity and processed by an application server. The M2M infrastructure can be provided by a mobile network operator as the meters in urban areas will have most likely a cellular or WiMAX radio. Smart Grid is a distributed and heterogeneous network and might have been built based on diverse networking technologies, such as wireless Access Technologies (WiMAX, Cellular, etc.), wireline and Internet Technologies (e.g., IP/MPLS, Ethernet, SDH/PDH over Fiber optic, etc.) as well as technologies enabling the networking of smart meters, home appliances, and constrained devices (e.g. BT-LE, ZigBee, Z-Wave, Wi-Fi, etc.). The operational effectiveness of the smart grid is highly dependent on a robust, two-way, highly secure, and reliable communications network with suitable availability. The management of a distributed system like smart grid requires an end-to-end management of and information exchange through different type of networks. However, as of today there is no integrated smart grid management approach and no common smart grid information model available. Specific smart grid applications or network islands use their own management mechanisms. For example, the management of smart meters depends very much on the AMI environment they have been integrated to and the networking technologies they are using. In general smart meters do only need seldom reconfiguration and they send a small amount of redundant data to a central entity. For a discussion on the management needs in Smart Home and Building Automation see Section 3.4 and Section 3.5. 3.7. Transport Applications Transport application is a generic term for the integrated application of communications, control and information processing in a transportation system. Transport telematics or vehicle telematics are used as a term for the group of technologies that support transportation systems. Transport applications running on such a transportation system cover all modes of the transport and consider all elements of the transportation system, i.e. the vehicle, the infrastructure, and the driver or user, interacting together dynamically. The overall aim is to improve decision making, often in real time, by transport network controllers and other users, thereby improving the operation of the entire transport system. As such transport applications can be seen as one of the important M2M service scenarios with the involvement of manifold small devices. Ersue, et al. Expires January 17, 2013 [Page 15] Internet-Draft Constrained Mgmt: Use Case & Requirements July 2012 The definition encompasses a broad array of techniques and approaches that may be achieved through stand-alone technological applications or as enhancements to other transportation communication schemes. Examples for transport applications are inter and intra vehicular communication, smart traffic control, smart parking, electronic toll collection systems, logistic and fleet management, vehicle control, and safety and road assistance. As a distributed system transport systems require an end-to-end management of and information exchange through different types of networks. It is likely that constrained devices in a network (e.g. a moving in-car network) have to be controlled by an application running on an application server in the network of a service provider. Such a network might be a wireless access network using diverse wireless technologies. As a result the management of constrained devices in the transport system might be necessary to plan top-down and might need to use data models obliged from and defined on the application layer. Management responsibility typically rests within the organization running the transport application. The constrained devices in a moving transport network might be initially configured in a factory and a reconfiguration might be needed only rarely. New devices might be integrated in an ad-hoc manner based on self-management and -configuration capabilities. Monitoring and data exchange might be necessary to do via a gateway entity connected to the back-end transport infrastructure. The devices and entities in the transport infrastructure need to be monitored more frequently and can be able to communicate with a higher data rate. The connectivity of such entities does not necessarily need to be wireless. The time scale for detecting and recording failures in a moving transport network is likely measured in hours and repairs might easily take days. It is likely that a self-healing feature would be used locally. 3.8. Infrastructure Monitoring Infrastructure monitoring is concerned with the monitoring of infrastructures such as bridges, railway tracks or (offshore) windmills. The primary goal is usually to detect any events or changes of the structural conditions that can impact the risk and safety of the infrastructure being monitored. Another secondary goal is to schedule repair and maintenance activities in a cost effective manner. Management of infrastructure monitoring applications is primary concerned with the monitoring of the functioning of the system. Infrastructure monitoring devices are typically rolled out and installed by dedicated experts and changes are rare since the Ersue, et al. Expires January 17, 2013 [Page 16] Internet-Draft Constrained Mgmt: Use Case & Requirements July 2012 infrastructure itself changes rarely. However, monitoring devices are often deployed in unsupervised environments and hence special attention must be given to protecting the devices from being modified. Management responsibility typically rests with the organization owning the infrastructure or responsible for its operation. The time scale for detecting and recording failures is likely measured in hours and repairs might easily take days. However, certain events (e.g., natural disasters) may require that status information is obtained much more quickly and that replacements of failed sensors can be rolled out quickly (or redundant sensors be activated quickly). 3.9. Community Network Applications Community networks are comprised of constrained routers in a "mesh" topology, communicating over a lossy, and often wireless channel. While community networks have an instable nature they are usually formed by non-constrained devices with sufficient resources. Examples of such community networks are the FunkFeuer network (Vienna, Austria), FreiFunk (Berlin, Germany), Seattle Wireless (Seattle, USA), and AWMN (Athens, Greece). These community networks are public and non-regulated, allowing their users to connect to each other and - through an uplink to an ISP - to the Internet for no fee, other than the initial purchase of a wireless router. Applications of these community networks can be diverse, e.g., location based services, free Internet access, file sharing between users, distributed chat services, social networking etc, video sharing etc. As an example of a community network, the FunkFeuer network comprises several hundred routers, many of which have several radio interfaces (with omnidirectional and some directed antennas). The routers of the network are small-sized wireless routers, such as the Linksys WRT54GL, available in 2011 for less than 50 Euros. These routers, with 16 MB of RAM and 264 MHz of CPU power, are mounted on the rooftops of the users. When new users want to connect to the network, they acquire a wireless router, install the appropriate firmware and routing protocol, and mount the router on the rooftop. IP address(es) for the router are assigned manually from a list of addresses (because of the lack of autoconfiguration standards for mesh networks in the IETF). While the routers are non-mobile, fluctuations in link quality require an ad hoc routing protocol that allows for quick convergence to reflect the effective topology of the network (such as NHDP [RFC6130] and OLSRv2 [I-D.ietf-manet-olsrv2] developed in the MANET WG). Usually, no human interaction is required for these protocols, Ersue, et al. Expires January 17, 2013 [Page 17] Internet-Draft Constrained Mgmt: Use Case & Requirements July 2012 as all variable parameters required by the routing protocol are either negotiated in the control traffic exchange, or are only of local importance to each router (i.e. do not influence interoperability). However, external management and monitoring of an ad hoc routing protocol may be desirable to optimize parameters of the routing protocol. Such an optimization may lead to a more stable perceived topology and to a lower control traffic overhead, and therefore to a higher delivery success ratio of data packets, a lower end-to-end delay, and less unnecessary bandwidth and energy usage. Different use cases for the management of community networks are possible: o One single network management station (e.g., a border gateway providing connectivity to the Internet) requires to manage or monitor routers in the community network, in order to investigate problems (monitoring) or to improve performance by changing parameters (managing). As the topology of the network is dynamic, constant connectivity of each router towards the management station cannot be guaranteed. Current network management protocols, such as SNMP and Netconf, may be used (e.g., using interfaces such as the NHDP-MIB [I-D.ietf-manet-nhdp-mib]), however, given the constrained routers and dynamic topology, not adapted to community networks. o A distributed network monitoring, in which more than one management station monitors or manages other routers. Because connectivity to a server cannot be guaranteed at all times, a distributed approach may provide a higher reliability, at the cost of increased complexity. Currently, no IETF standard exists for distributed monitoring and management. o Monitoring and management of a whole network or a group of routers. Monitoring the performance of a community network may require more information than what can be acquired from a single router using a network management protocol. Statistics, such as topology changes over time, data throughput along certain routing paths, congestion etc., are of interest for a group of routers (or the routing domain) as a whole. As of 2012, no IETF standard allows for monitoring or managing whole networks, instead of single routers. 3.10. Mobile Applications Machine-to-machine (M2M) services are increasingly provided by mobile service providers as numerous devices, home appliances, utility meters, cars, video surveillance cameras, and health monitors, are connected with mobile broadband technologies. This diverse range of Ersue, et al. Expires January 17, 2013 [Page 18] Internet-Draft Constrained Mgmt: Use Case & Requirements July 2012 machines bring new network and service requirements and challenges. Different applications e.g. in a home appliance or car network use Bluetooth, Wi-Fi or Zigbee and connect to a cellular module acting as a gateway between the constrained environment and the mobile cellular network. Such a gateway might provide different options for the connectivity to the mobile network and constrained devices, e.g.: o a smart phone with 3G/4G radio using BT-LE connecting to the devices in a home area network, o a femtocell might be combined with a home gateway acting as a low- power cellular base station connecting smart devices to the application server of a mobile service provider. o an embedded cellular module with LTE radio connecting the devices in the car network with the server running the telematics service, o an M2M gateway connected to the mobile operator network supporting diverse IoT connectivity technologies including ZigBee and CoAP over 6LoWPAN over IEEE 802.15.4. Common to all scenarios above is that they are embedded in a service and connected to a network provided by a mobile service provider. Usually there is a hierarchical management topology in use where different parts of the network are managed by different management entities. In case the devices are directly connected to a gateway they are most likely managed by a management entity integrated with the gateway, which itself is part of the network management system (NMS) run by the mobile operator. Smart phones or embedded modules connected to a gateway might be themselves in charge to manage the devices on their level. The initial and subsequent configuration of such a device is mainly based on self-configuration and is triggered by the device itself. The data models used in these scenario are mostly derived from the models of the operator NMS and might be used to monitor the status of the devices and to exchange the data sent by or read from the devices. The gateway might be in charge of filtering and aggregating the data received from the device as the information sent by the device might be mostly redundant. Ersue, et al. Expires January 17, 2013 [Page 19] Internet-Draft Constrained Mgmt: Use Case & Requirements July 2012 4. Requirements per Device Class and Applications The structure of this section is subject for discussion on the IETF Coman maillist. 4.1. Requirements Template Following is the requirements template proposed to use. Req-ID: An ID uniquely identified by a three-digit number Title: The title of the requirement. Requirement Type: Functional Requirements (FR), Non-Functional Requirements (NFR), Design Constraints (DC); Description: The rational and description of the requirement. Source: The origin of the requirement and the matching use case or application. Device type: The device type(s) to which this requirement applies to. Priority: The priority of the requirement showing the importance. Mandatory (M), Optional (O), Conditional (C). 4.2. Requirement Examples Following are two examples for the use of the requirements template. Req-ID: R-001 Title: Constrained devices must support auto-configuration capability. Requirement Type: FR Description: Auto-configuration or self-configuration is the automatic configuration and re-configuration of devices without manual intervention. Compared to the traditional management of devices where the management application is the central entity configuring the devices, in the auto-configuration scenario the device is the active part and initiates the configuration process. Auto-configuration in general simplifies the deployment, initial operation and the maintenance of the constrained devices and becomes indispensable if there are a huge number of devices to configure or a plug&play behavior is desired. Ersue, et al. Expires January 17, 2013 [Page 20] Internet-Draft Constrained Mgmt: Use Case & Requirements July 2012 Source: Diverse use cases requiring easy deployment and plug&play behavior as well as easy maintenance of many constrained devices. Device type: C1 and C2. Priority: M Req-ID: R-002 Title: The system must support secure network management access. Requirement Type: FR Description: Access control is a security feature provided by the management system allowing an administrator to restrict access to a subset of the management operations and data using various criteria. There is a need for standard mechanisms to restrict the access for particular users to a pre-configured subset of all available management operations and content. Usually a conceptual access control model is used to configure and monitor the access control procedures desired by the administrator to enforce a particular access control policy and authorization of the administrative users. It is unlikely that constrained devices would need multiple identities with different access control policies. Access privileges (access control rules) and the policy might be hard wired in a C1 device. It is assumed that C2 devices can provide a better granularity of the access control feature. However, access control needs to be defined modular to enable choosing between particular functionality and a lightweight implementation. Source: Diverse use cases providing access to management operations and data on constrained devices. Device type: C1 and C2. Priority: M Ersue, et al. Expires January 17, 2013 [Page 21] Internet-Draft Constrained Mgmt: Use Case & Requirements July 2012 5. IANA Considerations This document does not introduce any new code-points or namespaces for registration with IANA. Note to RFC Editor: this section may be removed on publication as an RFC. Ersue, et al. Expires January 17, 2013 [Page 22] Internet-Draft Constrained Mgmt: Use Case & Requirements July 2012 6. Security Considerations This document discusses the use cases and requirements on the network of constrained devices. If specific requirements for security will be identified, they will be described in future versions of this document. Ersue, et al. Expires January 17, 2013 [Page 23] Internet-Draft Constrained Mgmt: Use Case & Requirements July 2012 7. Contributors Following persons made significant contributions to and reviewed this document: o Ulrich Herberg (Fujitsu Laboratories of America) contributed the Section 3.9 on Community Network Applications. o Ersue, et al. Expires January 17, 2013 [Page 24] Internet-Draft Constrained Mgmt: Use Case & Requirements July 2012 8. Acknowledgments The editors would like to thank participants on the maillist for their valuable contributions and comments. Ersue, et al. Expires January 17, 2013 [Page 25] Internet-Draft Constrained Mgmt: Use Case & Requirements July 2012 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [RFC6632] Ersue, M. and B. Claise, "An Overview of the IETF Network Management Standards", RFC 6632, June 2012. [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", RFC 6130, April 2011. [I-D.ietf-manet-olsrv2] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, "The Optimized Link State Routing Protocol version 2", draft-ietf-manet-olsrv2-15 (work in progress), May 2012. [I-D.ietf-manet-nhdp-mib] Herberg, U., Cole, R., and I. Chakeres, "Definition of Managed Objects for the Neighborhood Discovery Protocol", draft-ietf-manet-nhdp-mib-15 (work in progress), July 2012. [I-D.ietf-lwig-guidance] Bormann, C., "Guidance for Light-Weight Implementations of the Internet Protocol Suite", draft-ietf-lwig-guidance-01 (work in progress), July 2012. [I-D.ietf-core-coap] Shelby, Z., Hartke, K., Bormann, C., and B. Frank, "Constrained Application Protocol (CoAP)", draft-ietf-core-coap-10 (work in progress), June 2012. [I-D.ietf-eman-framework] Claise, B., Parello, J., Silver, L., Quittek, J., and B. Nordman, "Energy Management Framework", draft-ietf-eman-framework-04 (work in progress), March 2012. [I-D.ietf-eman-requirements] Quittek, J., Chandramouli, M., Winter, R., Dietz, T., and B. Claise, "Requirements for Energy Management", draft-ietf-eman-requirements-08 (work in progress), July 2012. Ersue, et al. Expires January 17, 2013 [Page 26] Internet-Draft Constrained Mgmt: Use Case & Requirements July 2012 Authors' Addresses Mehmet Ersue (editor) Nokia Siemens Networks Email: mehmet.ersue@nsn.com Dan Romascanu (editor) Avaya Email: dromasca@avaya.com Juergen Schoenwaelder (editor) Jacobs University Bremen Email: j.schoenwaelder@jacobs-university.de Ersue, et al. Expires January 17, 2013 [Page 27]