Internet Engineering Task Force M. Ersue, Ed. Internet-Draft Nokia Siemens Networks Intended status: Informational D. Romascanu, Ed. Expires: January 10, 2013 Avaya J. Schoenwaelder, Ed. Jacobs University Bremen July 9, 2012 Management of Networks of Constrained Devices: Use Cases and Requirements draft-ersue-constrained-mgmt-00 Abstract This document raises the questions on and discusses the use cases, requirements and the solutions required for the management of a network 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 10, 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 Ersue, et al. Expires January 10, 2013 [Page 1] Internet-Draft Coman: Use Cases and Requirements July 2012 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Networks of Constrained Devices . . . . . . . . . . . . . 4 1.4. 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 4. Requirements per Device Class and Applications . . . . . . . . 18 4.1. Requirements Template . . . . . . . . . . . . . . . . . . 18 4.2. Requirement Examples . . . . . . . . . . . . . . . . . . . 18 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 8.1. Normative References . . . . . . . . . . . . . . . . . . . 23 8.2. Informative References . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Ersue, et al. Expires January 10, 2013 [Page 2] Internet-Draft Coman: Use Cases and Requirements July 2012 1. Introduction 1.1. Overview Constrained networks usually consist of many small and low-power nodes, so called constrained devices (aka. sensor, smart object or M2M device), and one or more entities between the constrained devices and the Internet, which can act as a gateway or proxy. 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, and so on 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 for long periods of time unsupervised. 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. 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 Ersue, et al. Expires January 10, 2013 [Page 3] Internet-Draft Coman: Use Cases and Requirements July 2012 to do simple resource management and monitoring. This document raises the questions on and aims to understand the use cases, requirements and the required solutions for the management of a network with constrained devices. Section 1.3 describes different options for the connectivity and management of constrained devices. Section 1.4 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 constrained management from the network as well as from the application point of view. Section 4 lists requirements on constrained networking and on management applications with constrained devices for discussion. 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. Server: The destination endpoint of a request; the originating endpoint of a response. 1.3. Networks of Constrained Devices We differentiate following options for the networking and management of networks of constrained devices: Network topology options: o a network of constrained devices which communicate with each other, Ersue, et al. Expires January 10, 2013 [Page 4] Internet-Draft Coman: Use Cases and Requirements July 2012 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 o Constrained devices which are connected to the Internet or a bigger IP network via the 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 Management topology options: 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, where functions are broken down and assigned to 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. Ersue, et al. Expires January 10, 2013 [Page 5] Internet-Draft Coman: Use Cases and Requirements July 2012 1.4. 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 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 Ersue, et al. Expires January 10, 2013 [Page 6] Internet-Draft Coman: Use Cases and Requirements July 2012 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 10, 2013 [Page 7] Internet-Draft Coman: Use Cases and 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 and 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 cases up to million smart meters or small devices, 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. 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, independently of the type of network (e.g., Smart Grid, wireless access or core network). Furthermore, it would be also desirable to Ersue, et al. Expires January 10, 2013 [Page 8] Internet-Draft Coman: Use Cases and Requirements July 2012 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 10, 2013 [Page 9] Internet-Draft Coman: Use Cases and 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 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. Ersue, et al. Expires January 10, 2013 [Page 10] Internet-Draft Coman: Use Cases and Requirements July 2012 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 to not only production equipment, but also to a factory that carries out centralized control of energy, HVAC (heating, ventilation, and air conditioning), lighting, access control, and so on 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. 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. Ersue, et al. Expires January 10, 2013 [Page 11] Internet-Draft Coman: Use Cases and Requirements July 2012 Sensor networks are an essential technology used for smart manufacturing. Measurements, automated controls, plant optimization, health and safety management, and other functions are be provided by large numbers of networked sectors. Data interoperability and seamless exchange of product, process, and project data is being 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 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 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 Ersue, et al. Expires January 10, 2013 [Page 12] Internet-Draft Coman: Use Cases and Requirements July 2012 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 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. Ersue, et al. Expires January 10, 2013 [Page 13] Internet-Draft Coman: Use Cases and Requirements July 2012 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. A smart grid is an electrical grid that uses data networks to gather and act on information, in an automated fashion 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, Blackout Prevention Systems, Advanced Metering Infrastructure (AMI), Advanced Distribution Management, Smart Substation Automation, Smart Metering, Demand Response/Load Management, Smart Home and Building Automation, E-mobility, etc. Smart Metering is a good example for an 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 and processed by a central entity and 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. Ersue, et al. Expires January 10, 2013 [Page 14] Internet-Draft Coman: Use Cases and Requirements July 2012 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, and Microwave), wireline and Internet Technologies (e.g., Ethernet, IP/MPLS, SDH/PDH over Fiber optic, and xDSL) as well as other technologies including ZigBee, Z-Wave, 6LoWPAN, Wi-Fi, PLC/BPL over power-line. 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 nor a 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 M2M service enablement or 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 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. 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 Ersue, et al. Expires January 10, 2013 [Page 15] Internet-Draft Coman: Use Cases and Requirements July 2012 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 have 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 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 Ersue, et al. Expires January 10, 2013 [Page 16] Internet-Draft Coman: Use Cases and Requirements July 2012 (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). Ersue, et al. Expires January 10, 2013 [Page 17] Internet-Draft Coman: Use Cases and Requirements July 2012 4. Requirements per Device Class and Applications The structure of this section is subject for discussion on the 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 10, 2013 [Page 18] Internet-Draft Coman: Use Cases and 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 10, 2013 [Page 19] Internet-Draft Coman: Use Cases and 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 10, 2013 [Page 20] Internet-Draft Coman: Use Cases and 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 10, 2013 [Page 21] Internet-Draft Coman: Use Cases and Requirements July 2012 7. Acknowledgments The editors would like to thank participants on the maillist for their valuable contributions and comments. Ersue, et al. Expires January 10, 2013 [Page 22] Internet-Draft Coman: Use Cases and Requirements July 2012 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [RFC6632] Ersue, M. and B. Claise, "An Overview of the IETF Network Management Standards", RFC 6632, June 2012. [I-D.ietf-lwig-guidance] Bormann, C., "Guidance for Light-Weight Implementations of the Internet Protocol Suite", draft-ietf-lwig-guidance-00 (work in progress), June 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., Winter, R., Dietz, T., Claise, B., and M. Chandramouli, "Requirements for Energy Management", draft-ietf-eman-requirements-07 (work in progress), July 2012. Ersue, et al. Expires January 10, 2013 [Page 23] Internet-Draft Coman: Use Cases and 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 10, 2013 [Page 24]