Skip to main content

Management of Networks of Constrained Devices: Use Cases and Requirements
draft-ersue-constrained-mgmt-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Mehmet Ersue , Dan Romascanu , Jürgen Schönwälder
Last updated 2012-07-16
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ersue-constrained-mgmt-01
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]