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


   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

   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
   ( 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",
   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

   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

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

   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

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

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

   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

   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

   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

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

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

   Device type:  The device type(s) to which this requirement applies

   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

   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

   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

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

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.

              Bormann, C., "Guidance for Light-Weight Implementations of
              the Internet Protocol Suite", draft-ietf-lwig-guidance-00
              (work in progress), June 2012.

              Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
              "Constrained Application Protocol (CoAP)",
              draft-ietf-core-coap-10 (work in progress), June 2012.

              Claise, B., Parello, J., Silver, L., Quittek, J., and B.
              Nordman, "Energy Management Framework",
              draft-ietf-eman-framework-04 (work in progress),
              March 2012.

              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


   Dan Romascanu (editor)


   Juergen Schoenwaelder (editor)
   Jacobs University Bremen


Ersue, et al.           Expires January 10, 2013               [Page 24]