RFC 7547
Management of Networks with Constrained Devices: Problem Statement and Requirements
Pages: 44
Informational
Informational
Part 2 of 2 – Pages 16 to 44
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
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.
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
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
---
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
---
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.
Source: Use cases where the count of devices to manage is high Requirement Type: Non-functional Requirement Device type: C1 and C2 Priority: Medium3.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
---
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
---
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
---
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
---
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
---
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
---
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
---
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.
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
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
---
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
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
---
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
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
---
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.
Source: Use case "Energy Management" Requirement Type: Functional Requirement Device type: C0, C1, and C2 Priority: Medium3.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: Medium3.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.
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
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.
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
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
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>.
[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>.
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