tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7547

 
 
 

Management of Networks with Constrained Devices: Problem Statement and Requirements

Part 2 of 2, p. 16 to 44
Prev RFC Part

 


prevText      Top      Up      ToC       Page 16 
3.  Requirements on the Management of Networks with Constrained Devices

   This section describes the requirements categorized by management
   areas listed in subsections.

   Note that the requirements listed in this section have been separated
   from the context in which they may appear.  In general, this document
   does not recommend the realization of any subset of the described
   requirements.  As such, this document avoids selecting any of the
   requirements as mandatory to implement.  A device might be able to

Top      Up      ToC       Page 17 
   provide only a particular selected set of requirements and might not
   be capable to provide all requirements in this document.  On the
   other hand, a device vendor might select a specific relevant subset
   of the requirements to implement.

   The following template is used for the definition of the
   requirements.

   Req-ID:  An ID composed of two numbers: a section number indicating
      the topic area and a unique three-digit number per section.

   Title:  The title of the requirement.

   Description:  The rationale and description of the requirement.

   Source:  The origin of the requirement and the matching use case or
      application.  For the discussion of referred use cases for
      constrained management, please see [RFC7548].

   Requirement Type:  Functional Requirement, Non-functional
      Requirement.  A functional requirement is related to a function or
      component.  As such, functional requirements may be technical
      details or specific functionality that define what a system is
      supposed to accomplish.  Non-functional requirements (also known
      as design constraints or quality requirements) impose
      implementation-related considerations such as performance
      requirements, security, or reliability.

   Device type:  The device types by which this requirement can be
      supported: C0, C1, and/or C2.

   Priority:  The priority of the requirement showing its importance for
      a particular type of device: High, Medium, and Low.  The priority
      of a requirement can be High, e.g., for a C2 device, but Low for a
      C1 or C0 device, as the realization of complex features in a C1
      device is in many cases not possible.

Top      Up      ToC       Page 18 
3.1.  Management Architecture/System

   Req-ID:  1.001

   Title:  Support multiple device classes within a single network

   Description:  Larger networks usually consist of devices belonging to
      different device classes (e.g., constrained mesh endpoints and
      less constrained routers) communicating with each other.  Hence,
      the management architecture must be applicable to networks that
      have a mix of different device classes.  See Section 3 of
      [RFC7228] for the definition of Constrained Device Classes.

   Source:  All use cases

   Requirement Type:  Non-functional Requirement

   Device type:  C1 and/or C2

   Priority:  High

   ---

   Req-ID:  1.002

   Title:  Management scalability

   Description:  The management architecture must be able to scale with
      the number of devices involved and operate efficiently in any
      network size and topology.  This implies that, e.g., the managing
      entity is able to handle large amounts of device monitoring data
      and the management protocol is not sensitive to the decrease of
      the time between two client requests.  To achieve good
      scalability, caching techniques, in-network data aggregation
      techniques, and hierarchical management models may be used.

   Source:  General requirement for all use cases to enable large-scale
      networks

   Requirement Type:  Non-functional Requirement

   Device type:  C0, C1, and C2

   Priority:  High

   ---

   Req-ID:  1.003

Top      Up      ToC       Page 19 
   Title:  Hierarchical management

   Description:  Provide a means of hierarchical management, i.e.,
      provide intermediary management entities on different levels,
      which can take over the responsibility for the management of a
      subhierarchy of the network of constraint devices.  The
      intermediary management entity can, e.g., support management data
      aggregation to handle, e.g., high-frequent monitoring data or
      provide a caching mechanism for the uplink and downlink
      communication.  Hierarchical management contributes to management
      scalability.

   Source:  Use cases where a large amount of devices are deployed with
      a hierarchical topology

   Requirement Type:  Non-functional Requirement

   Device type:  Managing and intermediary entities

   Priority:  Medium

   ---

   Req-ID:  1.004

   Title:  Minimize state maintained on constrained devices

   Description:  The amount of state that needs to be maintained on
      constrained devices should be minimized.  This is important in
      order to save memory (especially relevant for C0 and C1 devices)
      and in order to allow devices to restart, for example, to apply
      configuration changes or to recover from extended periods of
      inactivity.

   Note:  One way to achieve this is to adopt a RESTful architecture
      that minimizes the amount of state maintained by managed
      constrained devices and that makes resources of a device
      addressable via URIs.

   Source:  Basic requirement that concerns all use cases

   Requirement Type:  Functional Requirement

   Device type:  C0, C1, and C2

   Priority:  High

   ---

Top      Up      ToC       Page 20 
   Req-ID:  1.005

   Title:  Automatic resynchronization with eventual consistency

   Description:  To support large scale networks, where some constrained
      devices may be offline at any point in time, it is necessary to
      distribute configuration parameters in a way that allows temporary
      inconsistencies but eventually converges, after a sufficiently
      long period of time without further changes, towards global
      consistency.

   Source:  Use cases with large-scale networks with many devices

   Requirement Type:  Functional Requirement

   Device type:  C0, C1, and C2

   Priority:  High

   ---

   Req-ID:  1.006

   Title:  Support for lossy links and unreachable devices

   Description:  Some constrained devices will only be able to support
      lossy and unreliable links characterized by a limited data rate, a
      high latency, and a high transmission error rate.  Furthermore,
      constrained devices often duty cycle their radio or the whole
      device in order to save energy.  Some classes of devices labeled
      as 'sleepy endpoints' set their network links to a disconnected
      state during long periods of time.  In all cases, the management
      system must not assume that constrained devices are always
      reachable.

   Source:  Basic requirement for networks of constrained devices with
      unreliable links and constrained devices that sleep to save energy

   Requirement Type:  Non-functional Requirement

   Device type:  C0, C1, and C2

   Priority:  High

   ---

Top      Up      ToC       Page 21 
   Req-ID:  1.007

   Title:  Network-wide configuration

   Description:  Provide means by which the behavior of the network can
      be specified at a level of abstraction (network-wide
      configuration) higher than a set of configuration information
      specific to individual devices.  It is useful to derive the
      device-specific configuration from the network-wide configuration.
      Such a repository can be used to configure predefined device or
      protocol parameters for the whole network.  Furthermore, such a
      network-wide view can be used to monitor and manage a group of
      routers or a whole network.  For example, monitoring the
      performance of a network requires information additional to what
      can be acquired from a single router using a management protocol.

   Note:  The identification of the relevant subset of the policies to
      be provisioned is according to the capabilities of each device and
      can be obtained from a preconfigured data-repository.

   Source:  In general, all use cases of network and device
      configuration based on a network view in a top-down manner

   Requirement Type:  Non-functional Requirement

   Device type:  C0, C1, and C2

   Priority:  Medium

   ---

   Req-ID:  1.008

   Title:  Distributed management

   Description:  Provide a means of simple distributed management, where
      a network of constrained devices can be managed or monitored by
      more than one manager.  Since the connectivity to a server cannot
      be guaranteed at all times, a distributed approach may provide
      higher reliability, at the cost of increased complexity.  This
      requirement implies the handling of data consistency in case of
      concurrent read and write access to the device datastore.  It
      might also happen that no management (configuration) server is
      accessible and the only reachable node is a peer device.  In this
      case, the device should be able to obtain its configuration from
      peer devices.

Top      Up      ToC       Page 22 
   Source:  Use cases where the count of devices to manage is high

   Requirement Type:  Non-functional Requirement

   Device type:  C1 and C2

   Priority:  Medium

3.2.  Management Protocols and Data Models

   Req-ID:  2.001

   Title:  Modular implementation of management protocols

   Description:  Management protocols should be specified to allow for
      modular implementations, i.e., it should be possible to implement
      only a basic set of protocol primitives on highly constrained
      devices, while devices with additional resources may provide more
      support for additional protocol primitives.  See Section 1.7 for a
      discussion on the level of configuration management and monitoring
      support constrained devices may provide.

   Source:  Basic requirement interesting for all use cases

   Requirement Type:  Non-functional Requirement

   Device type:  C0, C1, and C2

   Priority:  High

   ---

   Req-ID:  2.002

   Title:  Compact encoding of management data

   Description:  The encoding of management data should be compact and
      space efficient, enabling small message sizes.

   Source:  General requirement to save memory for the receiver buffer
      and on-air bandwidth

   Requirement Type:  Functional Requirement

   Device type:  C0, C1, and C2

   Priority:  High

Top      Up      ToC       Page 23 
   ---

   Req-ID:  2.003

   Title:  Compression of management data or complete messages

   Description:  Management data exchanges can be further optimized by
      applying data compression techniques or delta encoding techniques.
      Compression typically requires additional code size and some
      additional buffers and/or the maintenance of some additional state
      information.  For C0 devices, compression may not be feasible.

   Source:  Use cases where it is beneficial to reduce transmission time
      and bandwidth, e.g., mobile applications that require saving on-
      air bandwidth

   Requirement Type:  Functional Requirement

   Device type:  C1 and C2

   Priority:  Medium

   ---

   Req-ID:  2.004

   Title:  Mapping of management protocol interactions

   Description:  It is desirable to have a lossless automated mapping
      between the management protocol used to manage constrained devices
      and the management protocols used to manage regular devices.  In
      the ideal case, the same core management protocol can be used with
      certain restrictions taking into account the resource limitations
      of constrained devices.  However, for very resource-constrained
      devices, this goal might not be achievable.

   Source:  Use cases where high-frequency interaction with the
      management system of a unconstrained network is required

   Requirement Type:  Functional Requirement

   Device type:  C1 and C2

   Priority:  Medium

   ---

Top      Up      ToC       Page 24 
   Req-ID:  2.005

   Title:  Consistency of data models with the underlying information
      model

   Description:  The data models used by the management protocol must be
      consistent with the information model used to define data models
      for unconstrained networks.  This is essential to facilitate the
      integration of the management of constrained networks with the
      management of unconstrained networks.  Using an underlying
      information model for future data model design enables further
      top-down model design and model reuse as well as data
      interoperability (i.e., exchange of management information between
      the constrained and unconstrained networks).  This is a strong
      requirement, despite the fact that the underlying information
      models are often not explicitly documented in the IETF.

   Source:  General requirement to support data interoperability,
      consistency, and model reuse

   Requirement Type:  Non-functional Requirement

   Device type:  C0, C1, and C2

   Priority:  High

   ---

   Req-ID:  2.006

   Title:  Lossless mapping of management data models

   Description:  It is desirable to have a lossless automated mapping
      between the management data models used to manage regular devices
      and the management data models used for managing constrained
      devices.  In the ideal case, the same core data models can be used
      with certain restrictions taking into account the resource
      limitations of constrained devices.  However, for very resource-
      constrained devices, this goal might not be achievable.

   Source:  Use cases where consistent data exchange with the management
      system of a unconstrained network is required

   Requirement Type:  Functional Requirement

   Device type:  C2

   Priority:  Medium

Top      Up      ToC       Page 25 
   ---

   Req-ID:  2.007

   Title:  Protocol extensibility

   Description:  Provide means of extensibility for the management
      protocol, i.e., by adding new protocol messages or mechanisms that
      can deal with changing requirements on a supported message and
      data types effectively, without causing interoperability problems
      or having to replace/update large amount of deployed devices.

   Source:  Basic requirement useful for all use cases

   Requirement Type:  Functional Requirement

   Device type:  C0, C1, and C2

   Priority:  High

3.3.  Configuration Management

   Req-ID:  3.001

   Title:  Self-configuration capability

   Description:  Automatic configuration and reconfiguration 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 autoconfiguration
      scenario the device is the active part and initiates the
      configuration process.  Self-configuration can be initiated during
      the initial configuration or for subsequent configurations, where
      the configuration data needs to be refreshed.  Self-configuration
      should be also supported during the initialization phase or in the
      event of failures, where prior knowledge of the network topology
      is not available or the topology of the network is uncertain.

   Source:  In general, all use cases requiring easy deployment and
      plug&play behavior as well as easy maintenance of many constrained
      devices

   Requirement Type:  Functional Requirement

   Device type:  C0, C1, and C2

   Priority:  High for device categories C0 and C1; Medium for C2

Top      Up      ToC       Page 26 
   ---

   Req-ID:  3.002

   Title:  Capability discovery

   Description:  Enable the discovery of supported optional management
      capabilities of a device and their exposure via at least one
      protocol and/or data model.

   Source:  Use cases where the device interaction with other devices or
      applications is a function of the level of support for its
      capabilities

   Requirement Type:  Functional Requirement

   Device type:  C1 and C2

   Priority:  Medium

   ---

   Req-ID:  3.003

   Title:  Asynchronous transaction support

   Description:  Provide configuration management with asynchronous
      (event-driven) transaction support.  Configuration operations must
      support a transactional model, with asynchronous indications that
      the transaction was completed.

   Source:  Use cases that require transaction-oriented processing
      because of reliability or distributed architecture functional
      requirements

   Requirement Type:  Functional Requirement

   Device type:  C1 and C2

   Priority:  Medium

   ---

Top      Up      ToC       Page 27 
   Req-ID:  3.004

   Title:  Network reconfiguration

   Description:  Provide a means of iterative network reconfiguration in
      order to recover the network from node and communication failures.
      The network reconfiguration can be failure-driven and self-
      initiated (automatic reconfiguration).  The network
      reconfiguration can be also performed on the whole hierarchical
      structure of a network (network topology).

   Source:  Practically all use cases, as network connectivity is a
      basic requirement

   Requirement Type:  Functional Requirement

   Device type:  C0, C1, and C2

   Priority:  Medium

3.4.  Monitoring Functionality

   Req-ID:  4.001

   Title:  Device status monitoring

   Description:  Provide a monitoring function to collect and expose
      information about device status and expose it via at least one
      management interface.  The device monitoring might make use of the
      hierarchical management through the intermediary entities and the
      caching mechanism.  The device monitoring might also make use of
      neighbor-monitoring (fault detection in the local network) to
      support fast fault detection and recovery, e.g., in a scenario
      where a managing entity is unreachable and a neighbor can take
      over the monitoring responsibility.

   Source:  All use cases

   Requirement Type:  Functional Requirement

   Device type:  C0, C1, and C2

   Priority:  High; Medium for neighbor-monitoring

   ---

Top      Up      ToC       Page 28 
   Req-ID:  4.002

   Title:  Energy status monitoring

   Description:  Provide a monitoring function to collect and expose
      information about device energy parameters and usage (e.g.,
      battery level and average power consumption).

   Source:  Use case "Energy Management"

   Requirement Type:  Functional Requirement

   Device type:  C0, C1, and C2

   Priority:  High for energy reporting devices; Low for others

   ---

   Req-ID:  4.003

   Title:  Monitoring of current and estimated device availability

   Description:  Provide a monitoring function to collect and expose
      information about current device availability (energy, memory,
      computing power, forwarding-plane utilization, queue buffers,
      etc.) and estimation of remaining available resources.

   Source:  All use cases.  Note that monitoring energy resources (like
      battery status) may be required on all kinds of devices.

   Requirement Type:  Functional Requirement

   Device type:  C0, C1, and C2

   Priority:  Medium

   ---

Top      Up      ToC       Page 29 
   Req-ID:  4.004

   Title:  Network status monitoring

   Description:  Provide a monitoring function to collect, analyze, and
      expose information related to the status of a network or network
      segments connected to the interface of the device.

   Source:  All use cases

   Requirement Type:  Functional Requirement

   Device type:  C1 and C2

   Priority:  Low, based on the realization complexity

   ---

   Req-ID:  4.005

   Title:  Self-monitoring

   Description:  Provide self-monitoring (local fault detection) feature
      for fast fault detection and recovery.

   Source:  Use cases where the devices cannot be monitored centrally in
      an appropriate manner, e.g., self-healing is required

   Requirement Type:  Functional Requirement

   Device type:  C1 and C2

   Priority:  High for C2; Medium for C1

   ---

   Req-ID:  4.006

   Title:  Performance monitoring

   Description:  The device will provide a monitoring function to
      collect and expose information about the basic performance
      parameter of the device.  The performance management functionality
      might make use of the hierarchical management through the
      intermediary devices.

Top      Up      ToC       Page 30 
   Source:  Use cases "Building Automation" and "Transport Applications"

   Requirement Type:  Functional Requirement

   Device type:  C1 and C2

   Priority:  Low

   ---

   Req-ID:  4.007

   Title:  Fault detection monitoring

   Description:  The device will provide fault detection monitoring.
      The system collects information about network states in order to
      identify whether faults have occurred.  In some cases, the
      detection of the faults might be based on the processing and
      analysis of the parameters retrieved from the network or other
      devices.  In case of C0 devices, the monitoring might be limited
      to the check whether or not the device is alive.

   Source:  Use cases "Environmental Monitoring", "Building Automation",
      "Energy Management", "Infrastructure Monitoring"

   Requirement Type:  Functional Requirement

   Device type:  C0, C1 and C2

   Priority:  Medium

   ---

   Req-ID:  4.008

   Title:  Passive and reactive monitoring

   Description:  The device will provide passive and reactive monitoring
      capabilities.  The system or manager collects information about
      device components and network states (passive monitoring) and may
      perform postmortem analysis of collected data.  In case events of
      interest have occurred, the system or the manager can adaptively
      react (reactive monitoring), e.g., reconfigure the network.
      Typically, actions (reactions) will be executed or sent as
      commands by the management applications.

   Source:  Diverse use cases relevant for device status and network
      state monitoring

Top      Up      ToC       Page 31 
   Requirement Type:  Functional Requirement

   Device type:  C2

   Priority:  Medium

   ---

   Req-ID:  4.009

   Title:  Recovery

   Description:  Provide local, central and hierarchical recovery
      mechanisms (recovery is in some cases achieved by recovering the
      whole network of constrained devices).

   Source:  Use cases "Industrial Applications", "Home Automation", and
      "Building Automation", as well as mobile applications that involve
      different forms of clustering or area managers

   Requirement Type:  Functional Requirement

   Device type:  C2

   Priority:  Medium

   ---

   Req-ID:  4.010

   Title:  Network topology discovery

   Description:  Provide a network topology discovery capability (e.g.,
      use of topology extraction algorithms to retrieve the network
      state) and a monitoring function to collect and expose information
      about the network topology.

   Source:  Use cases "Community Network Applications" and mobile
      applications

   Requirement Type:  Functional Requirement

   Device type:  C1 and C2

   Priority:  Low, based on the realization complexity

   ---

Top      Up      ToC       Page 32 
   Req-ID:  4.011

   Title:  Notifications

   Description:  The device will provide the capability of sending
      notifications on critical events and faults.

   Source:  All use cases

   Requirement Type:  Functional Requirement

   Device type:  C0, C1, and C2

   Priority:  Medium for C2; Low for C0 and C1

   ---

   Req-ID:  4.012

   Title:  Logging

   Description:  The device will provide the capability of building,
      keeping, and allowing retrieval of logs of events (including but
      not limited to critical faults and alarms).

   Source:  Use cases "Industrial Applications", "Building Automation",
      and "Infrastructure Monitoring"

   Requirement Type:  Functional Requirement

   Device type:  C2

   Priority:  High for some medical or industrial applications; Medium
      otherwise

3.5.  Self-Management

   Req-ID:  5.001

   Title:  Self-management -- Self-healing

   Description:  Enable event-driven and/or periodic self-management
      functionality in a device.  The device should be able to react in
      case of a failure, e.g., by initiating a fully or partly reset and
      initiate a self-configuration or management data update as
      necessary.  A device might be further able to check for failures

Top      Up      ToC       Page 33 
      cyclically or on a schedule in order to trigger self-management as
      necessary.  It is a matter of device design and subject for
      discussion how much self-management a C1 device can support.

      Failure detection and self-management logic are assumed to be
      generally useful for the self-healing of a device.

   Source:  The requirement generally relates to all use cases in this
      document.

   Requirement Type:  Functional Requirement

   Device type:  C1 and C2

   Priority:  High for C2; Medium for C1

3.6.  Security and Access Control

   Req-ID:  6.001

   Title:  Authentication of management system and devices

   Description:  Systems having a management role must be properly
      authenticated to the device such that the device can exercise
      proper access control and in particular distinguish rightful
      management systems from rogue systems.  On the other hand, managed
      devices must authenticate themselves to systems having a
      management role such that management systems can protect
      themselves from rogue devices.  In certain application scenarios,
      it is possible that a large number of devices need to be
      (re-)started at about the same time.  Protocols and authentication
      systems should be designed such that a large number of devices
      (re-)starting simultaneously does not negatively impact the device
      authentication process.

   Source:  Basic security requirement for all use cases

   Requirement Type:  Functional Requirement

   Device type:  C0, C1, and C2

   Priority:  High; Medium for the (re-)start of a large number of
      devices

   ---

Top      Up      ToC       Page 34 
   Req-ID:  6.002

   Title:  Support suitable security bootstrapping mechanisms

   Description:  Mechanisms should be supported that simplify the
      bootstrapping of device that is the discovery of newly deployed
      devices in order to provide them with appropriate access control
      permissions.

   Source:  Basic security requirement for all use cases

   Requirement Type:  Functional Requirement

   Device type:  C0, C1, and C2

   Priority:  High

   ---

   Req-ID:  6.003

   Title:  Access control on management system and devices

   Description:  Systems acting in a management role must provide an
      access control mechanism that allows the security administrator to
      restrict which devices can access the managing system (e.g., using
      an access control white list of known devices).  On the other
      hand, managed constrained devices must provide an access control
      mechanism that allows the security administrator to restrict how
      systems in a management role can access the device (e.g., no-
      access, read-only access, and read-write access).

   Source:  Basic security requirement for use cases where access
      control is essential

   Requirement Type:  Functional Requirement

   Device type:  C0, C1, and C2

   Priority:  High

   ---

   Req-ID:  6.004

   Title:  Select cryptographic algorithms that are efficient in both
      code space and execution time

Top      Up      ToC       Page 35 
   Description:  Cryptographic algorithms have a major impact in terms
      of both code size and overall execution time.  Therefore, it is
      necessary to select mandatory to implement cryptographic
      algorithms that are reasonable to implement with the available
      code space and that have a small impact at runtime.  Furthermore,
      some wireless technologies (e.g., IEEE 802.15.4) require the
      support of certain cryptographic algorithms.  It might be useful
      to choose algorithms that are likely to be supported in wireless
      chipsets for certain wireless technologies.

   Source:  Generic requirement to reduce the footprint and CPU usage of
      a constrained device

   Requirement Type:  Non-functional Requirement

   Device type:  C0, C1, and C2

   Priority:  High; Medium for hardware-supported algorithms

3.7.  Energy Management

   Req-ID:  7.001

   Title:  Management of energy resources

   Description:  Enable managing power resources in the network, e.g.,
      reduce the sampling rate of nodes with critical battery and reduce
      node transmission power, put nodes to sleep, put single interfaces
      to sleep, reject a management job based on available energy or
      criteria predefined by the management application (such as
      importance levels forcing execution even if the energy level is
      low), etc.  The device may further implement standard data models
      for energy management and expose it through a management protocol
      interface, e.g., EMAN MIB modules [RFC7460] and [RFC7461] as well
      as other EMAN extensions.  It might be necessary to use a subset
      of EMAN MIBs for C1 and C2 devices.

   Source:  Use case "Energy Management"

   Requirement Type:  Functional Requirement

   Device type:  C0, C1, and C2

   Priority:  Medium for the use case "Energy Management"; Low otherwise

   ---

Top      Up      ToC       Page 36 
   Req-ID:  7.002

   Title:  Support of energy-optimized communication protocols

   Description:  Use an optimized communication protocol to minimize
      energy usage for the device (radio) receiver/transmitter, on-air
      bandwidth usage (i.e., maximize protocol efficiency), and the
      amount of data communication between nodes.  Minimizing data
      communication implies data aggregation and filtering but also a
      compact format for the transferred data.

   Source:  Use cases "Energy Management" and mobile applications

   Requirement Type:  Non-functional Requirement

   Device type:  C2

   Priority:  Medium

   ---

   Req-ID:  7.003

   Title:  Support for Layer 2 (L2) energy-aware protocols

   Description:  The device will support L2 energy-management protocols
      (e.g., energy-efficient Ethernet [IEEE802.3az]) and be able to
      report on these.

   Source:  Use case "Energy Management"

   Requirement Type:  Non-functional Requirement

   Device type:  C0, C1, and C2

   Priority:  Medium

   ---

   Req-ID:  7.004

   Title:  Dying gasp

   Description:  When energy resources draw below the red-line level,
      the device will send a "dying gasp" notification and perform, if
      still possible, a graceful shutdown including conservation of
      critical device configuration and status information.

Top      Up      ToC       Page 37 
   Source:  Use case "Energy Management"

   Requirement Type:  Functional Requirement

   Device type:  C0, C1, and C2

   Priority:  Medium

3.8.  Software Distribution

   Req-ID:  8.001

   Title:  Group-based provisioning

   Description:  Support group-based provisioning, i.e., firmware update
      and configuration management of a large set of constrained devices
      with eventual consistency and coordinated reload times.  The
      device should accept group-based configuration management based on
      bulk commands, which aim similar configurations of a large set of
      constrained devices of the same type in a given group and which
      may share a common data model.  Activation of configuration may be
      based on preloaded sets of default values.

   Source:  All use cases

   Requirement Type:  Non-functional Requirement

   Device type:  C0, C1, and C2

   Priority:  Medium

3.9.  Traffic Management

   Req-ID:  9.001

   Title:  Congestion avoidance

   Description:  Support congestion control principles as defined in
      [RFC2914], e.g., the ability to avoid congestion by modifying the
      device's reporting rate for periodical data (which is usually
      redundant) based on the importance and reliability level of the
      management data.  This functionality is usually controlled by the
      managing entity, where the managing entity marks the data as
      important or relevant for reliability.  However, reducing a
      device's reporting rate can also be initiated by a device if it is
      able to detect congestion or has insufficient buffer memory.

Top      Up      ToC       Page 38 
   Source:  Use cases with high reporting rate and traffic, e.g., AMI or
      M2M

   Requirement Type:  Non-functional Requirement

   Device type:  C1 and C2

   Priority:  Medium

   ---

   Req-ID:  9.002

   Title:  Reroute traffic

   Description:  Provide the ability for network nodes to redirect
      traffic from overloaded intermediary nodes in a network to another
      path in order to prevent congestion on a central server and in the
      primary network.

   Source:  Use cases with high reporting rate and traffic, e.g., AMI or
      M2M

   Requirement Type:  Non-functional Requirement

   Device type:  Intermediary entity in the network

   Priority:  Medium

   ---

   Req-ID:  9.003

   Title:  Traffic Shaping

   Description:  Provide the ability to apply traffic-shaping policies
      to incoming and outgoing links on an overloaded intermediary node
      (as necessary) in order to reduce the amount of traffic in the
      network.

   Source:  Use cases with high reporting rate and traffic, e.g., AMI or
      M2M

   Requirement Type:  Non-functional Requirement

   Device type:  Intermediary entity in the network

   Priority:  Medium

Top      Up      ToC       Page 39 
3.10.  Transport Layer

   Req-ID:  10.001

   Title:  Scalable transport layer

   Description:  Enable the use of a scalable transport layer, i.e., not
      sensitive to a high rate of incoming client requests, which is
      useful for applications requiring frequent access to device data.

   Source:  Applications with frequent access to the device data

   Requirement Type:  Non-functional Requirement

   Device type:  C0, C1 and C2

   Priority:  Medium

   ---

   Req-ID:  10.002

   Title:  Reliable unicast transport of messages

   Description:  Diverse applications need a reliable transport of
      messages.  The reliability might be achieved based on a transport
      protocol such as TCP or can be supported based on message
      repetition if an acknowledgment is missing.

   Source:  Generally, applications benefit from the reliability of the
      message transport

   Requirement Type:  Functional Requirement

   Device type:  C0, C1, and C2

   Priority:  High

   ---

   Req-ID:  10.003

   Title:  Best-effort multicast

   Description:  Provide best-effort multicast of messages, which is
      generally useful when devices need to discover a service provided
      by a server or many devices need to be configured by a managing
      entity at once based on the same data model.

Top      Up      ToC       Page 40 
   Source:  Use cases where a device needs to discover services as well
      as use cases with high amount of devices to manage, which are
      hierarchically deployed, e.g., AMI or M2M

   Requirement Type:  Functional Requirement

   Device type:  C0, C1, and C2

   Priority:  Medium

   ---

   Req-ID:  10.004

   Title:  Secure message transport

   Description:  Enable secure message transport providing
      authentication, data integrity, and confidentiality by using
      existing transport-layer technologies with a small footprint such
      as TLS/DTLS.

   Source:  All use cases

   Requirement Type:  Non-functional Requirements

   Device type:  C1 and C2

   Priority:  High

3.11.  Implementation Requirements

   Req-ID:  11.001

   Title:  Avoid complex application-layer transactions requiring large
      application-layer messages

   Description:  Complex application-layer transactions tend to require
      large memory buffers that are typically not available on C0 or C1
      devices and only by limiting functionality on C2 devices.
      Furthermore, the failure of a single large transaction requires
      repeating the whole transaction.  On constrained devices, it is
      often more desirable to split a large transaction into a sequence
      of smaller transactions that require less resources and allow
      making progress using a sequence of smaller steps.

   Source:  Basic requirement that concerns all use cases with memory
      constrained devices

Top      Up      ToC       Page 41 
   Requirement Type:  Non-functional Requirement

   Device type:  C0, C1, and C2

   Priority:  High

   ---

   Req-ID:  11.002

   Title:  Avoid reassembly of messages at multiple layers in the
      protocol stack

   Description:  Reassembly of messages at multiple layers in the
      protocol stack requires buffers at multiple layers, which leads to
      inefficient use of memory resources.  This can be avoided by
      making sure the application layer, the security layer, the
      transport layer, the IPv6 layer, and any adaptation layers are
      aware of the limitations of each other such that unnecessary
      fragmentation and reassembly can be avoided.  In addition, message
      size constraints must be announced to protocol peers such that
      they can adapt and avoid sending messages that can't be processed
      due to resource constraints on the receiving device.

   Source:  Basic requirement that concerns all use cases with memory
      constrained devices

   Requirement Type:  Non-functional Requirement

   Device type:  C0, C1, and C2

   Priority:  High

4.  Security Considerations

   This document discusses the problem statement and requirements on
   networks of constrained devices.  Section 1.6 mentions a number of
   limitations that could prevent the implementation of strong
   cryptographic algorithms.  Requirements for security and access
   control are listed in Section 3.6.

   Often, constrained devices might be deployed in unsafe environments
   where attackers can gain physical access to the devices.  As a
   consequence, it is crucial that devices are robust and tamper
   resistant, have no backdoors, do not provide services that are not
   essential for the primary function, and properly protect any security
   credentials that may be stored on the device (e.g., by using hardware
   protection mechanisms).  Furthermore, it is important that any

Top      Up      ToC       Page 42 
   credentials leaking from a single device do not simplify the attack
   on other (similar) devices.  In particular, security credentials
   should never be shared.

   Since constrained devices often have limited computational resources,
   care should be taken in choosing efficient but cryptographically
   strong cryptographic algorithms.  Designers of constrained devices
   that have a long expected lifetime need to ensure that cryptographic
   algorithms can be updated once devices have been deployed.  The
   ability to perform secure firmware and software updates is an
   important management requirement.

   Constrained devices might also generate sensitive data or require the
   processing of sensitive data.  Therefore, it is an important
   requirement to properly protect access to the data in order to
   protect the privacy of humans using Internet-enabled devices.  For
   certain types of data, protection during the transmission over the
   network may not be sufficient, and methods should be investigated
   that provide protection of data while it is cached or stored (e.g.,
   when using a store-and-forward transport mechanism).

5.  Informative References

   [RFC2914]  Floyd, S., "Congestion Control Principles", BCP 41,
              RFC 2914, DOI 10.17487/RFC2914, September 2000,
              <http://www.rfc-editor.org/info/rfc2914>.

   [RFC2501]  Corson, S. and J. Macker, "Mobile Ad hoc Networking
              (MANET): Routing Protocol Performance Issues and
              Evaluation Considerations", RFC 2501,
              DOI 10.17487/RFC2501, January 1999,
              <http://www.rfc-editor.org/info/rfc2501>.

   [RFC6632]  Ersue, M., Ed. and B. Claise, "An Overview of the IETF
              Network Management Standards", RFC 6632,
              DOI 10.17487/RFC6632, June 2012,
              <http://www.rfc-editor.org/info/rfc6632>.

   [RFC7102]  Vasseur, JP., "Terms Used in Routing for Low-Power and
              Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
              2014, <http://www.rfc-editor.org/info/rfc7102>.

   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained-Node Networks", RFC 7228,
              DOI 10.17487/RFC7228, May 2014,
              <http://www.rfc-editor.org/info/rfc7228>.

Top      Up      ToC       Page 43 
   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <http://www.rfc-editor.org/info/rfc7252>.

   [RFC4919]  Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
              over Low-Power Wireless Personal Area Networks (6LoWPANs):
              Overview, Assumptions, Problem Statement, and Goals",
              RFC 4919, DOI 10.17487/RFC4919, August 2007,
              <http://www.rfc-editor.org/info/rfc4919>.

   [RFC6550]  Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
              Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
              JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
              Low-Power and Lossy Networks", RFC 6550,
              DOI 10.17487/RFC6550, March 2012,
              <http://www.rfc-editor.org/info/rfc6550>.

   [RFC7460]  Chandramouli, M., Claise, B., Schoening, B., Quittek, J.,
              and T. Dietz, "Monitoring and Control MIB for Power and
              Energy", RFC 7460, DOI 10.17487/RFC7460, March 2015,
              <http://www.rfc-editor.org/info/rfc7460>.

   [RFC7461]  Parello, J., Claise, B., and M. Chandramouli, "Energy
              Object Context MIB", RFC 7461, DOI 10.17487/RFC7461, March
              2015, <http://www.rfc-editor.org/info/rfc7461>.

   [RFC7548]  Ersue, M., Ed., Romascanu, D., Schoenwaelder, J., and A.
              Sehgal, "Management of Networks with Constrained Devices:
              Use Cases", RFC 7548, DOI 10.17487/RFC7548, May 2015,
              <http://www.rfc-editor.org/info/rfc7548>.

   [IEEE802.15.4]
              IEEE, "Part 15.4: Low-Rate Wireless Personal Area Networks
              (LR-WPANs)", IEEE Standard 802.15.4, September 2011,
              <https://standards.ieee.org/about/get/802/802.15.html>.

   [IEEE802.15.1]
              IEEE, "Part 15.1: Wireless medium access control (MAC) and
              physical layer (PHY) specifications for wireless personal
              area networks (WPANs)", IEEE Standard 802.15.1, June 2005,
              <https://standards.ieee.org/about/get/802/802.15.html>.

   [IEEE802.3az]
              IEEE, "ETHERNET", IEEE Standard 802.3az, 2012-2014,
              <https://standards.ieee.org/about/get/802/802.3.html>.

Top      Up      ToC       Page 44 
Acknowledgments

   The following reviewed and provided valuable comments during the
   creation of this document:

   Dominique Barthel, Andy Bierman, Carsten Bormann, Zhen Cao, Benoit
   Claise, Hui Deng, Bert Greevenbosch, Joel M. Halpern, Ulrich Herberg,
   James Nguyen, Anuj Sehgal, Zach Shelby, Peter van der Stok, Thomas
   Watteyne, and Bert Wijnen.

   The authors would like to thank the reviewers and the participants on
   the Coman and OPSAWG mailing lists for their valuable contributions
   and comments.

   Juergen Schoenwaelder was partly funded by Flamingo, a Network of
   Excellence project (ICT-318488) supported by the European Commission
   under its Seventh Framework Programme.

Authors' Addresses

   Mehmet Ersue (editor)
   Nokia Networks

   EMail: mehmet.ersue@nokia.com


   Dan Romascanu
   Avaya

   EMail: dromasca@avaya.com


   Juergen Schoenwaelder
   Jacobs University Bremen

   EMail: j.schoenwaelder@jacobs-university.de


   Ulrich Herberg

   EMail: ulrich@herberg.name