Internet Engineering Task Force (IETF) M. Ersue, Ed.
Request for Comments: 7547 Nokia Networks
Category: Informational D. Romascanu
ISSN: 2070-1721 Avaya
J. Schoenwaelder
Jacobs University Bremen
U. Herberg
May 2015
Internet Engineering Task Force (IETF) M. Ersue, Ed.
Request for Comments: 7547 Nokia Networks
Category: Informational D. Romascanu
ISSN: 2070-1721 Avaya
J. Schoenwaelder
Jacobs University Bremen
U. Herberg
May 2015
Management of Networks with Constrained Devices: Problem Statement and Requirements
设备受限的网络管理：问题陈述和要求
Abstract
摘要
This document provides a problem statement, deployment and management topology options, as well as requirements addressing the different use cases of the management of networks where constrained devices are involved.
本文档提供了问题陈述、部署和管理拓扑选项，以及解决涉及受限设备的网络管理的不同用例的要求。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7547.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7547.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
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 described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Overview ...................................................3
1.2. Terminology ................................................4
1.3. Network Types and Characteristics in Focus .................5
1.4. Constrained Device Deployment Options ......................9
1.5. Management Topology Options ...............................10
1.6. Managing the Constrainedness of a Device or Network .......10
1.7. Configuration and Monitoring Functionality Levels .........13
2. Problem Statement ..............................................14
3. Requirements on the Management of Networks with
Constrained Devices ............................................16
3.1. Management Architecture/System ............................18
3.2. Management Protocols and Data Models ......................22
3.3. Configuration Management ..................................25
3.4. Monitoring Functionality ..................................27
3.5. Self-Management ...........................................32
3.6. Security and Access Control ...............................33
3.7. Energy Management .........................................35
3.8. Software Distribution .....................................37
3.9. Traffic Management ........................................37
3.10. Transport Layer ..........................................39
3.11. Implementation Requirements ..............................40
4. Security Considerations ........................................41
5. Informative References .........................................42
Acknowledgments ...................................................44
Authors' Addresses ................................................44
1. Introduction ....................................................3
1.1. Overview ...................................................3
1.2. Terminology ................................................4
1.3. Network Types and Characteristics in Focus .................5
1.4. Constrained Device Deployment Options ......................9
1.5. Management Topology Options ...............................10
1.6. Managing the Constrainedness of a Device or Network .......10
1.7. Configuration and Monitoring Functionality Levels .........13
2. Problem Statement ..............................................14
3. Requirements on the Management of Networks with
Constrained Devices ............................................16
3.1. Management Architecture/System ............................18
3.2. Management Protocols and Data Models ......................22
3.3. Configuration Management ..................................25
3.4. Monitoring Functionality ..................................27
3.5. Self-Management ...........................................32
3.6. Security and Access Control ...............................33
3.7. Energy Management .........................................35
3.8. Software Distribution .....................................37
3.9. Traffic Management ........................................37
3.10. Transport Layer ..........................................39
3.11. Implementation Requirements ..............................40
4. Security Considerations ........................................41
5. Informative References .........................................42
Acknowledgments ...................................................44
Authors' Addresses ................................................44
Constrained devices (also known as sensors, smart objects, or smart devices) with limited CPU, memory, and power resources can be connected to a network. It might be based on unreliable or lossy channels, it may use wireless technologies with limited bandwidth and a dynamic topology, or it may need the service of a gateway or proxy to connect to the Internet. In other scenarios, the constrained devices can be connected to a unconstrained network using off-the-shelf protocol stacks.
CPU、内存和电源资源有限的受约束设备（也称为传感器、智能对象或智能设备）可以连接到网络。它可能基于不可靠或有损信道，可能使用带宽有限的无线技术和动态拓扑，或者可能需要网关或代理服务来连接到Internet。在其他场景中，受约束的设备可以使用现成的协议栈连接到不受约束的网络。
Constrained devices might be in charge of gathering information in diverse settings including natural ecosystems, buildings, and factories and sending the information to one or more server stations. Constrained devices may also 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 and can act as a gateway between the constrained devices and the application logic in the core network.
受约束的设备可能负责在各种环境中收集信息，包括自然生态系统、建筑物和工厂，并将信息发送到一个或多个服务器站。受限制的设备也可能在严重的资源限制下工作，例如电池和计算能力有限、内存不足、无线带宽不足以及通信能力不足。中心实体，例如基站或控制服务器，可能具有更多的计算和通信资源，并且可以充当受约束设备和核心网络中的应用逻辑之间的网关。
Today, constrained devices of diverse size and with different resources and capabilities are being connected. Mobile personal gadgets, building-automation devices, cellular phones, machine-to-machine (M2M) devices, etc., benefit from interacting with other "things" in the near or somewhere in the Internet. With this the Internet of Things (IoT) becomes a reality, built 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.
如今，各种尺寸、不同资源和能力的受限设备正在连接。移动个人小玩意、楼宇自动化设备、手机、机器对机器（M2M）设备等，从与互联网附近或某处的其他“事物”的交互中获益。有了这一点，物联网（IoT）成为现实，由唯一可识别的对象（物）组成。在未来十年中，这可能会发展到数万亿台受限设备，并将大大增加互联网的规模和范围。
Network management is characterized by monitoring network status, detecting faults (and inferring their causes), setting network parameters, and carrying out actions to remove faults, maintain normal operation, and improve network efficiency and application performance. The traditional network monitoring application periodically collects information from a set of managed network elements, it processes the data, and it presents the results to the network management users. Constrained devices, however, often have limited power, have 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 without supervision. Due to such constraints, the
网络管理的特点是监视网络状态、检测故障（并推断其原因）、设置网络参数、执行操作以消除故障、维持正常运行、提高网络效率和应用程序性能。传统的网络监控应用程序定期从一组管理的网元收集信息，处理数据，并将结果呈现给网络管理用户。然而，受限制的设备通常功率有限，传输范围小，可能不可靠。它们可能还需要在具有高级安全要求的敌对环境中工作，或者需要在没有监督的恶劣环境中长时间使用。由于这些限制
management of a network with constrained devices faces a different type of challenges compared to the management of a traditional IP network.
与传统IP网络管理相比，使用受限设备管理网络面临不同类型的挑战。
The IETF has already done substantial standardization work to enable communication in IP networks and to manage such networks as well as the manifold types 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, CPU, and energy resources) nowadays use application-layer protocols in an ad hoc manner to do simple resource management and monitoring.
IETF已经做了大量的标准化工作，以实现IP网络中的通信，并管理此类网络以及这些网络中的多种类型的节点[RFC6632]。然而，到目前为止，IETF还没有开发任何特定的技术来管理受约束设备和由受约束设备组成的网络。在这样的环境中，基于IP的传感器或受限设备（即内存、CPU和能源资源非常有限的设备）现在以特别的方式使用应用层协议来进行简单的资源管理和监控。
This document provides a problem statement and lists requirements for the different use cases of management of a network with constrained devices. Sections 1.3 and 1.5 describe different topology options for the networking and management of constrained devices. Section 2 provides a problem statement on the issue of the management of networked constrained devices. Section 3 lists requirements on the management of applications and networks with constrained devices. Note that the requirements listed in Section 3 have been separated from the context in which they may appear. Depending on the concrete circumstances, an implementer may decide to address a certain relevant subset of the requirements.
本文档提供了问题陈述，并列出了使用受限设备管理网络的不同用例的要求。第1.3节和第1.5节描述了受约束设备联网和管理的不同拓扑选项。第2节提供了有关网络化受限设备管理问题的问题陈述。第3节列出了使用受限设备管理应用程序和网络的要求。请注意，第3节中列出的要求已与可能出现的上下文分开。根据具体情况，实现者可能决定解决需求的某个相关子集。
The use cases in the context of networks with constrained devices can be found in [RFC7548]. This document provides a list of objectives for discussions and does not aim to be a strict requirements document for all use cases. In fact, there likely is not a single solution that works equally well for all the use cases.
具有受限设备的网络上下文中的用例可在[RFC7548]中找到。本文档为讨论提供了一个目标列表，并不打算成为所有用例的严格需求文档。事实上，不可能有一个单一的解决方案对所有用例都同样有效。
Concerning constrained devices and networks, this document generally builds on the terminology defined in [RFC7228], where the terms "constrained device", "constrained network", and others are defined.
关于受限设备和网络，本文件通常以[RFC7228]中定义的术语为基础，其中定义了术语“受限设备”、“受限网络”等。
Additionally, the following terms are used throughout:
此外，以下术语贯穿始终：
AMI: (Advanced Metering Infrastructure) A system including hardware, software, and networking technologies that measures, collects, and analyzes energy use and that communicates with a hierarchically deployed network of metering devices, either on request or on a schedule.
AMI：（高级计量基础设施）一种系统，包括硬件、软件和网络技术，用于测量、收集和分析能源使用，并根据请求或计划与分层部署的计量设备网络进行通信。
C0: Class 0 constrained device as defined in Section 3 of [RFC7228].
C0:RFC7228第3节中定义的0类受约束设备。
C1: Class 1 constrained device as defined in Section 3 of [RFC7228].
C1:[RFC7228]第3节中定义的1类约束装置。
C2: Class 2 constrained device as defined in Section 3 of [RFC7228].
C2:[RFC7228]第3节中定义的2类约束装置。
Network of Constrained Devices: A network to which constrained devices are connected that may or may not be a constrained network (see [RFC7228] for the definition of the term constrained network).
受约束设备网络：受约束设备所连接的网络，该网络可能是受约束网络，也可能不是受约束网络（有关术语受约束网络的定义，请参见[RFC7228]）。
M2M: (Machine to Machine) The automatic data transfer between devices of different kinds. In M2M scenarios, a device (such as a sensor or meter) captures an event, which is relayed through a network (wireless, wired, or hybrid) to an application.
M2M：（机器对机器）不同类型设备之间的自动数据传输。在M2M场景中，设备（如传感器或仪表）捕获事件，该事件通过网络（无线、有线或混合）中继到应用程序。
MANET: (Mobile Ad Hoc Network [RFC2501]) A self-configuring and infrastructureless network of mobile devices connected by wireless technologies.
MANET：（移动自组织网络[RFC2501]）通过无线技术连接的移动设备的自配置和无基础设施网络。
Smart Grid: An electrical grid that uses communication technologies to gather and act on information in an automated fashion to improve the efficiency, reliability, and sustainability of the production and distribution of electricity.
智能电网：利用通信技术以自动化方式收集和处理信息的电网，以提高发电和配电的效率、可靠性和可持续性。
Smart Meter: An electrical meter in the context of a smart grid.
智能电表：智能电网中的电表。
For a detailed discussion on the constrained networks as well as classes of constrained devices and their capabilities, please see [RFC7228].
有关受限网络以及受限设备类别及其功能的详细讨论，请参阅[RFC7228]。
In this document, we differentiate the following types of networks concerning their transport and communication technologies:
在本文件中，我们就其运输和通信技术区分了以下类型的网络：
(Note that a network in general can involve constrained and unconstrained devices.)
（请注意，网络通常包括受约束和不受约束的设备。）
1. Wireline unconstrained networks, e.g., an Ethernet LAN with constrained and unconstrained devices involved.
1. 有线无约束网络，例如，涉及约束和无约束设备的以太网LAN。
2. A combination of wireline and wireless networks, possibly with a multi-hop connectivity between constrained devices, utilizing dynamic routing in both the wireless and wireline portions of the network. Such networks usually support highly distributed applications with many nodes (e.g., environmental monitoring) and
2. 有线和无线网络的组合，可能在受限设备之间具有多跳连接，在网络的无线和有线部分中利用动态路由。此类网络通常支持具有多个节点（例如，环境监测）和
tend to deal with large-scale multipoint-to-point (MP2P) systems. Wireless Mesh Networks (WMNs), as a specific variant, use off-the-shelf radio technology such as Wi-Fi, WiMAX, and cellular 3G/4G. WMNs are reliable based on the redundancy they offer and have often a more planned deployment to provide dynamic and cost effective connectivity over a certain geographic area.
倾向于处理大规模多点对点（MP2P）系统。无线网状网络（WMN）作为一种特定的变体，使用现成的无线电技术，如Wi-Fi、WiMAX和蜂窝3G/4G。WMN基于其提供的冗余而可靠，并且通常有更计划的部署，以在特定地理区域提供动态且经济高效的连接。
3. A combination of wireline and wireless networks with point-to-point (P2P) or point-to-multipoint (P2MP) communication generally with single-hop connectivity to constrained devices, utilizing static routing over the wireless network. Such networks support short-range, P2P, low-data-rate, source-to-sink types of applications, such as RFID systems, light switches, fire/smoke detectors, and home appliances. This type of network also supports confined short-range spaces such as a home, a factory, a building, or the human body. [IEEE802.15.1] (Bluetooth) and [IEEE802.15.4] are well-known examples of applicable standards for such networks. By using 6LoWPANs (IPv6 over Low-Power Wireless Personal Area Networks) [RFC4919] and RPL (Routing Protocol for Low-Power and Lossy Networks) [RFC6550] on top of IEEE 802.15.4, multi-hop connectivity and dynamic routing can be achieved. With RPL, the IETF has specified a proactive "route-over" architecture where routing and forwarding is implemented at the network layer. The protocol provides a mechanism whereby MP2P, P2MP, and P2P traffic are supported.
3. 有线和无线网络的组合，具有点对点（P2P）或点对多点（P2MP）通信，通常与受限制的设备进行单跳连接，利用无线网络上的静态路由。此类网络支持短距离、P2P、低数据速率、源到汇类型的应用，如RFID系统、光开关、火灾/烟雾探测器和家用电器。这种类型的网络还支持受限的短程空间，如家庭、工厂、建筑物或人体。[IEEE802.15.1]（蓝牙）和[IEEE802.15.4]是此类网络适用标准的著名示例。通过在IEEE 802.15.4之上使用6LoWPANs（低功率无线个人区域网络上的IPv6）[RFC4919]和RPL（低功率和有损网络路由协议）[RFC6550]，可以实现多跳连接和动态路由。通过RPL，IETF指定了一种主动式“路由覆盖”架构，其中路由和转发在网络层实现。该协议提供了一种支持MP2P、P2MP和P2P流量的机制。
4. Self-configuring infrastructureless networks of mobile devices (e.g., MANET) are a particular type of network connected by wireless technologies. Infrastructureless networks are mostly based on P2P communications of devices moving independently in any direction and changing the links to other devices frequently. Such devices do act as a router to forward traffic unrelated to their own use.
4. 移动设备（例如MANET）的自配置无基础设施网络是通过无线技术连接的一种特殊类型的网络。无基础设施网络主要基于设备在任何方向上独立移动并频繁更改与其他设备的链接的P2P通信。这类设备确实充当路由器，转发与其自身用途无关的流量。
Wireline unconstrained networks with constrained and unconstrained devices are mainly used for specific applications like Building Automation or Infrastructure Monitoring. Wireline and wireless networks with multi-hop or P2MP connectivity are used, e.g., for environmental monitoring as well as transport and mobile applications.
有线无约束网络与约束和无约束设备主要用于特定应用，如楼宇自动化或基础设施监控。使用具有多跳或P2MP连接的有线和无线网络，例如用于环境监测以及运输和移动应用。
Furthermore, different network characteristics are determined by multiple dimensions: dynamicity of the topology, bandwidth, and loss rate. In the following, each dimension is explained, and networks in scope for this document are outlined:
此外，不同的网络特性由多个维度决定：拓扑的动态性、带宽和丢失率。下文对每个维度进行了解释，并概述了本文件范围内的网络：
Network Topology:
网络拓扑：
The topology of a network can be represented as a graph, with edges (i.e., links) and vertices (routers and hosts). Examples of different topologies include "star" topologies (with one central node and multiple nodes in one-hop distance), tree structures (with each node having exactly one parent), directed acyclic graphs (with each node having one or more parents), clustered topologies (where one or more "cluster heads" are responsible for a certain area of the network), mesh topologies (fully distributed), etc.
网络的拓扑可以表示为一个图，带有边（即链接）和顶点（路由器和主机）。不同拓扑的示例包括“星形”拓扑（一个中心节点和多个节点在一跳距离内）、树结构（每个节点正好有一个父节点）、有向无环图（每个节点有一个或多个父节点）、集群拓扑（其中一个或多个“簇头”）负责网络的特定区域）、网状拓扑（完全分布式）等。
Management protocols may take advantage of specific network topologies, for example, by distributing large-scale management tasks amongst multiple distributed network management stations (e.g., in case of a mesh topology), or by using a hierarchical management approach (e.g., in case of a tree or clustered topology). These different management topology options are described in Section 1.6.
管理协议可利用特定网络拓扑，例如，通过在多个分布式网络管理站之间分配大规模管理任务（例如，在网状拓扑的情况下），或通过使用分层管理方法（例如，在树拓扑或集群拓扑的情况下）。第1.6节介绍了这些不同的管理拓扑选项。
Note that in certain network deployments, such as community ad hoc networks (see the use case "Community Network Applications" in [RFC7548]), the topology is not preplanned; thus, it may be unknown for management purposes. In other use cases, such as industrial applications (see the use case "Industrial Applications" in [RFC7548]), the topology may be designed in advance and therefore taken advantage of when managing the network.
请注意，在某些网络部署中，例如社区自组织网络（请参阅[RFC7548]中的用例“社区网络应用程序”），拓扑未预先规划；因此，出于管理目的，它可能是未知的。在其他用例中，例如工业应用程序（参见[RFC7548]中的用例“工业应用程序”），可以提前设计拓扑结构，从而在管理网络时利用拓扑结构。
Dynamicity of the network topology:
网络拓扑的动态性：
The dynamicity of the network topology determines the rate of change of the graph as a function of time. Such changes can occur due to different factors, such as mobility of nodes (e.g., in MANETs or cellular networks), duty cycles (for low-power devices enabling their network interface only periodically to transmit or receive packets), or unstable links (in particular wireless links with strongly fluctuating link quality).
网络拓扑的动态性决定了图形随时间的变化率。这种变化可能是由于不同的因素引起的，例如节点的移动性（例如，在manet或蜂窝网络中）、占空比（对于仅使其网络接口能够周期性地发送或接收分组的低功率设备）或不稳定链路（尤其是具有剧烈波动链路质量的无线链路）。
Examples of different levels of dynamicity of the topology are Ethernets (with typically a very static topology) on the one side, and Low-power and Lossy Networks (LLNs) on the other side. LLNs nodes are often duty-cycled and operate on unreliable wireless links and are potentially mobile (e.g., for sensor networks).
拓扑的不同动态性级别的示例包括一侧的以太网（通常是非常静态的拓扑）和另一侧的低功耗和有损网络（LLN）。LLN节点通常是负载循环的，在不可靠的无线链路上运行，并且可能是移动的（例如，对于传感器网络）。
The more dynamic the topology is, the more have routing, transport and application-layer protocols to cope with interrupted connectivity and/or longer delays. For example, management protocols (with a given underlying transport protocol) that expect continuous session flows without changes of routes during a communication flow, may fail to operate.
拓扑结构越动态，路由、传输和应用层协议就越多，以应对中断的连接和/或更长的延迟。例如，期望在通信流期间连续会话流而不改变路由的管理协议（具有给定的底层传输协议）可能无法运行。
Networks with a very low dynamicity (e.g., Ethernet) with no or infrequent topology changes (e.g., less than once every 30 minutes), are in the scope of this document if they are used with constrained devices (see, e.g., the use case "Building Automation" in [RFC7548]).
动态性极低的网络（如以太网）如果与受约束的设备一起使用，且没有或很少发生拓扑变化（如每30分钟少于一次），则属于本文件的范围（如参见[RFC7548]中的用例“楼宇自动化”）。
Traffic flows:
交通流量：
The traffic flow in a network determines from which sources data traffic is sent to which destinations in the network. Several different traffic flows are defined in [RFC7102], including P2P, MP2P, and P2MP flows as:
网络中的流量决定了数据流量从哪个来源发送到网络中的哪个目的地。[RFC7102]中定义了几种不同的流量，包括P2P、MP2P和P2MP流量，如下所示：
o P2P: Point-to-point refers to traffic exchanged between two nodes (regardless of the number of hops between the two nodes).
o P2P：点对点指的是两个节点之间交换的流量（无论两个节点之间的跳数如何）。
o P2MP: Point-to-multipoint traffic refers to traffic between one node and a set of nodes. This is similar to the P2MP concept in Multicast or MPLS Traffic Engineering.
o P2MP：点对多点流量是指一个节点和一组节点之间的流量。这类似于多播或MPLS流量工程中的P2MP概念。
o MP2P: Multipoint-to-point is used to describe a particular traffic pattern (e.g., MP2P flows collecting information from many nodes flowing inwards towards a collecting sink).
o MP2P：多点对点用于描述特定的流量模式（例如，MP2P流从许多向内流向收集汇的节点收集信息）。
If one of these traffic patterns is predominant in a network, protocols (routing, transport, application) may be optimized for the specific traffic flow. For example, in a network with a tree topology and MP2P traffic, collection tree protocols are efficient to send data from the leaves of the tree to the root of the tree, via each node's parent.
如果这些业务模式中的一种在网络中占主导地位，则可以针对特定的业务流优化协议（路由、传输、应用）。例如，在具有树拓扑和MP2P流量的网络中，收集树协议可以有效地通过每个节点的父节点将数据从树的叶子发送到树的根。
Bandwidth:
带宽：
The bandwidth of the network is the amount of data that can be sent per unit of time between two communication endpoints. It is usually determined by the link with the minimum bandwidth on the path from the source to the destination of data packets. The bandwidth in networks can range from a few kilobytes per second (such as on some IEEE 802.15.4 link layers) to many gigabytes per second (e.g., on fiber optics).
网络带宽是两个通信端点之间每单位时间可以发送的数据量。它通常由从数据包的源到目的地的路径上具有最小带宽的链路来确定。网络中的带宽可以从每秒几千字节（例如在某些IEEE 802.15.4链路层上）到每秒几千字节（例如在光纤上）。
For management purposes, the management protocol typically requires the sending of information between the network management station and the clients, for monitoring or control purposes. If the available bandwidth is insufficient for the management protocol, packets will be buffered and eventually dropped; thus, management is not possible with such a protocol.
出于管理目的，管理协议通常需要在网络管理站和客户端之间发送信息，以用于监视或控制目的。如果可用带宽不足以满足管理协议，则数据包将被缓冲并最终丢弃；因此，使用这样的协议进行管理是不可能的。
Networks without bandwidth limitation (e.g., Ethernet) are in the scope of this document if they are used with constrained devices (see the use case "Building Automation" in [RFC7548]).
如果无带宽限制的网络（如以太网）与受限制的设备一起使用（参见[RFC7548]中的“楼宇自动化”用例），则属于本文件的范围。
Loss rate:
损失率：
The loss rate (or bit error rate) is the number of bit errors divided by the total number of bits transmitted. For wired networks, loss rates are typically extremely low, e.g., around 10^-12 or 10^-13 for the latest 10 Gbit Ethernet. For wireless networks, such as IEEE 802.15.4, the bit error rate can be as high as 10^-1 to 1 in case of interferences. Even when using a reliable transport protocol, management operations can fail if the loss rate is too high, unless they are specifically designed to cope with these situations.
丢失率（或误码率）是误码数除以传输的总比特数。对于有线网络，丢失率通常非常低，例如，对于最新的10 Gbit以太网，大约为10^-12或10^-13。对于无线网络，如IEEE 802.15.4，在出现干扰的情况下，误码率可能高达10^-1到1。即使在使用可靠的传输协议时，如果丢失率过高，管理操作也可能失败，除非它们是专门为应对这些情况而设计的。
We differentiate the following deployment options for the constrained devices:
我们为受约束的设备区分以下部署选项：
o A network of constrained devices that communicate with each other,
o 相互通信的受约束设备网络，
o Constrained devices that are connected directly to an IP network,
o 直接连接到IP网络的受约束设备，
o A network of constrained devices that communicate with a gateway or proxy with more communication capabilities possibly acting as a representative of the device to entities in the unconstrained network,
o 受约束设备的网络，其与网关或代理进行通信，网关或代理具有更多通信能力，可能作为设备对无约束网络中实体的代表，
o Constrained devices that are connected to the Internet or an IP network via a gateway/proxy,
o 通过网关/代理连接到Internet或IP网络的受约束设备，
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, and
o 受约束设备的层次结构，例如，连接到一个或多个C1设备的C0设备网络——连接到一个或多个C2设备——连接到一个或多个网关——连接到一些应用服务器或NM，以及
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.
o 设备分组的可能性（可能以动态方式），例如分组的设备可以作为网络边缘的一个逻辑设备，并且该组中的一个设备可以作为管理实体。
We differentiate the 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 由一个中央管理器管理的受约束设备网络。出于可伸缩性和健壮性的原因，可以以分层方式实现逻辑集中的管理。管理器和管理应用程序逻辑之间可能有网关/代理，或者可能位于不同网络中的不同节点上，例如，在云服务器上运行的管理应用程序。
o Distributed management, where a network of constrained devices is managed by more than one manager. Each manager controls a subnetwork and may communicate directly with other manager stations in a cooperative fashion. The distributed management may be weakly distributed, where functions are broken down and assigned to 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 分布式管理，其中受约束设备的网络由多个管理器管理。每个管理器控制一个子网，并且可以以协作方式直接与其他管理器站通信。分布式管理可能是弱分布式的，其中功能被分解并动态分配给许多管理者；或者是强分布式的，其中几乎所有被管理的东西都具有嵌入式管理功能，而显式管理消失，这通常伴随着现在需要管理强分布式管理逻辑的代价。
o Hierarchical management, where a hierarchy of networks with constrained devices are managed by the managers at their corresponding hierarchy level. That is, each manager is responsible for managing the nodes in its subnetwork. It passes information from its subnetwork to its higher-level manager and disseminates management functions received from the higher-level manager to its subnetwork. Hierarchical management is essentially a scalability mechanism, logically the decision-making may be still centralized.
o 分层管理，其中具有受约束设备的网络的层次结构由管理器在其相应的层次结构级别进行管理。也就是说，每个管理器负责管理其子网中的节点。它将信息从其子网传递到其更高级别的管理者，并将从更高级别的管理者接收到的管理功能传播到其子网。分层管理本质上是一种可扩展机制，从逻辑上讲，决策可能仍然是集中的。
The capabilities of a constrained device or network and the constrainedness thereof influence and have an impact on the requirements for the management of such a network or devices.
受约束设备或网络的能力及其约束性影响并影响此类网络或设备的管理要求。
Note that the list below gives examples and does not claim completeness.
请注意，下面的列表给出了示例，并不要求完整性。
A constrained device:
受约束设备：
o might only support an unreliable (e.g., lossy) radio link, i.e., the client and server of a management protocol need to gracefully handle incomplete command exchanges or missing commands.
o 可能只支持不可靠（如有损）的无线电链路，即管理协议的客户端和服务器需要优雅地处理不完整的命令交换或丢失的命令。
o might only be able to go online from time to time, where it is reachable, i.e., a command might be necessary to repeat after a longer timeout or the timeout value with which one endpoint waits on a response needs to be sufficiently high.
o 可能只能在可访问的情况下不时联机，即可能需要在更长的超时后重复命令，或者一个端点等待响应的超时值需要足够高。
o might only be able to support a limited operating time (e.g., based on the available battery) or may behave as 'sleepy endpoints', setting their network links to a disconnected state during long periods of time, i.e., the devices need to economize their energy usage with suitable mechanisms and the managing entity needs to monitor and control the energy status of the constrained devices it manages.
o 可能只能支持有限的操作时间（例如，基于可用电池），或者可能表现为“休眠端点”，在长时间内将其网络链接设置为断开状态，即。，设备需要通过适当的机制节约能源使用，管理实体需要监控其管理的受约束设备的能源状态。
o might only be able to support one simple communication protocol, i.e., the management protocol needs to be possible to downscale from constrained (C2) to very constrained (C0) devices with modular implementation and a very basic version with just a few simple commands.
o 可能只能支持一个简单的通信协议，即，管理协议需要能够通过模块化实现从受限（C2）设备缩减到非常受限（C0）设备，并且只需几个简单命令即可实现非常基本的版本。
o might only be able to support a communication protocol, which is not IP based.
o 可能只能支持非基于IP的通信协议。
o might only be able to support limited or no user and/or transport security, i.e., the management system needs to support a less-costly and simple but sufficiently secure authentication mechanism.
o 可能只能支持有限或无用户和/或传输安全，即，管理系统需要支持成本较低、简单但足够安全的身份验证机制。
o might not be able to support compression and decompression of exchanged data based on limited CPU power, i.e., an intermediary entity which is capable of data compression should be able to communicate with both, devices that support data compression (e.g., C2) and devices that do not support data compression (e.g., C1 and C0).
o 可能无法基于有限的CPU能力支持交换数据的压缩和解压缩，即，能够进行数据压缩的中间实体应该能够与支持数据压缩的设备（例如C2）和不支持数据压缩的设备（例如C1和C0）进行通信。
o might only be able to support a simple encryption, i.e., it would be beneficial if the devices use cryptographic algorithms that are supported in hardware and the encryption used is efficient in terms of memory and CPU usage.
o 可能仅能够支持简单的加密，即，如果设备使用硬件支持的加密算法，并且所使用的加密在内存和CPU使用方面是有效的，则这将是有益的。
o might only be able to communicate with one single managing entity and cannot support the parallel access of many managing entities.
o 可能只能与单个管理实体通信，并且无法支持多个管理实体的并行访问。
o might depend on a self-configuration feature, i.e., the managing entity might not know all devices in a network and the device needs to be able to initiate connection setup for the device configuration.
o 可能取决于自配置功能，即管理实体可能不知道网络中的所有设备，并且设备需要能够启动设备配置的连接设置。
o might depend on self- or neighbor-monitoring features, i.e., the managing entity might not be able to monitor all devices in a network continuously.
o 可能取决于自身或邻居监控功能，即管理实体可能无法连续监控网络中的所有设备。
o might only be able to communicate with its neighbors, i.e., the device should be able to get its configuration from a neighbor.
o 可能只能与其邻居通信，即设备应该能够从邻居获取其配置。
o might only be able to support parsing of data models with limited size, i.e., the device data models need to be compact containing the most necessary data and if possible parsable as a stream.
o 可能只能支持有限大小的数据模型解析，即设备数据模型需要紧凑，包含最必要的数据，并且如果可能，可以作为流解析。
o might only be able to support a limited or no-failure detection, i.e., the managing entity needs to handle the situation, where a failure does not get detected or gets detected late gracefully, e.g., with asking repeatedly.
o 可能只能支持有限或无故障检测，即管理实体需要处理故障未被检测到或检测延迟的情况，例如，重复询问。
o might only be able to support the reporting of just one or a limited set failure types.
o 可能只支持报告一种或一组有限的故障类型。
o might only be able to support a limited set of notifications, possible only an "I am alive." message.
o 可能只能支持有限的一组通知，可能只有“我还活着”消息。
o might only be able to support a soft-reset from failure recovery.
o 可能只能支持故障恢复的软重置。
o might possibly generate a large amount of redundant reporting data, i.e., the intermediary management entity (see [RFC7252]) should be able to filter and aggregate redundant data.
o 可能会生成大量冗余报告数据，即中间管理实体（请参见[RFC7252]）应该能够过滤和聚合冗余数据。
A network of constrained devices:
受约束设备的网络：
o might only support an unreliable (e.g., lossy) radio link, i.e., the client and server of a management protocol need to repeat commands as necessary or gracefully ignore incomplete commands.
o 可能仅支持不可靠（如有损）的无线电链路，即管理协议的客户端和服务器需要根据需要重复命令，或优雅地忽略不完整的命令。
o might be necessary to manage based on multicast communication, i.e., the managing entity needs to be prepared to configure many devices at once based on the same data model.
o 可能需要基于多播通信进行管理，即，管理实体需要准备好基于相同的数据模型一次配置多个设备。
o might have a very large topology supporting 10,000 or more nodes for some applications and as such node naming is a specific issue for constrained networks.
o 对于某些应用程序，可能具有支持10000个或更多节点的非常大的拓扑，因此节点命名是受约束网络的一个特定问题。
o needs to support self-organization, i.e., given the large number of nodes and their potential placement in hostile locations and frequently changing topology, manual configuration of nodes is typically not feasible. As such, the network would benefit from the ability to reconfigure itself so that it can continue to operate properly and support reliable connectivity.
o 需要支持自组织，即，考虑到大量节点及其在敌对位置的潜在位置和频繁变化的拓扑，手动配置节点通常是不可行的。因此，网络将从重新配置自身的能力中获益，以便能够继续正常运行并支持可靠的连接。
o might need a management solution that is energy efficient, using as little wireless bandwidth as possible since communication is highly energy demanding.
o 可能需要一个节能的管理解决方案，因为通信对能源的要求很高，所以尽可能少地使用无线带宽。
o needs to support localization schemes to determine the location of devices since the devices might be moving and location information is important for some applications.
o 需要支持本地化方案以确定设备的位置，因为设备可能正在移动，并且位置信息对于某些应用程序很重要。
o needs a management solution that is scalable as the network may consist of thousands of nodes and may need to be extended continuously.
o 需要一个可扩展的管理解决方案，因为网络可能由数千个节点组成，并且可能需要不断扩展。
o needs to provide fault tolerance. Faults in network operation including hardware and software errors or failures detected by the transport protocol should be handled smoothly. In such a case, it should be possible to run the protocol at a reduced level but avoid failing completely. For example, self-monitoring mechanisms or graceful degradation of features can be used to provide fault tolerance.
o 需要提供容错能力。应顺利处理网络运行中的故障，包括硬件和软件错误或传输协议检测到的故障。在这种情况下，应该可以在降低的级别上运行协议，但避免完全失败。例如，可以使用自我监控机制或功能的优雅降级来提供容错。
o might require new management capabilities, for example, network coverage information and a constrained device power distribution map.
o 可能需要新的管理功能，例如，网络覆盖信息和受限制的设备配电图。
o might require a new management function for data management, since the type and amount of data collected in constrained networks is different from those of the traditional networks.
o 由于受限网络中收集的数据类型和数量不同于传统网络，因此可能需要新的数据管理功能。
o might also need energy-efficient key management.
o 可能还需要节能的密钥管理。
Devices often differ significantly on the level of configuration management support they provide. This document classifies the configuration management functionality as follows:
设备通常在其提供的配置管理支持级别上存在显著差异。本文档将配置管理功能分类如下：
CL0: Devices are preconfigured and allow no runtime configuration changes. Configuration parameters are often hard coded and compiled directly into the firmware image.
CL0:设备已预配置，不允许运行时配置更改。配置参数通常是硬编码的，并直接编译到固件映像中。
CL1: Devices have explicit configuration objects. However, changes require a restart of the device to take effect.
CL1:设备具有显式配置对象。但是，更改需要重新启动设备才能生效。
CL2: Devices allow management systems to replace the entire configuration (or predetermined subsets) in bulk. Configuration changes take effect by soft-restarts of the system (or subsystems).
CL2：设备允许管理系统批量替换整个配置（或预定子集）。配置更改通过系统（或子系统）的软重启生效。
CL3: Devices allow management systems to modify configuration objects without bulk replacements and changes take effect immediately.
CL3：设备允许管理系统修改配置对象，而无需批量替换，更改将立即生效。
CL4: Devices support multiple configuration datastores and they might distinguish between the currently running and the next startup configuration.
CL4：设备支持多个配置数据存储，它们可能区分当前运行的配置和下一个启动配置。
CL5: Devices support configuration datastore locking and device-local configuration change transactions, i.e., either all configuration changes are applied or none of them are.
CL5：设备支持配置数据存储锁定和设备本地配置更改事务，即要么应用所有配置更改，要么不应用任何配置更改。
CL6: Devices support configuration change transactions across devices.
CL6：设备支持跨设备的配置更改事务。
This document defines a classification of devices with regard to different levels of monitoring support. In general, a device may be in several of the levels listed below:
本文件针对不同级别的监控支持定义了设备分类。一般来说，一台设备可能处于下列几个级别：
ML0: Devices push predefined monitoring data.
ML0：设备推送预定义的监控数据。
ML1: Devices allow management systems to pull predefined monitoring data.
ML1：设备允许管理系统提取预定义的监控数据。
ML2: Devices allow management systems to pull user-defined filtered subsets of monitoring data.
ML2：设备允许管理系统提取监控数据的用户定义的过滤子集。
ML3: Devices are able to locally process monitoring data in order to detect threshold crossings or to aggregate data.
ML3：设备能够本地处理监控数据，以便检测阈值交叉或聚合数据。
At the time of this writing, constrained devices often implement a combination of one of CL0-CL2 with one of ML0-ML1.
在撰写本文时，受约束设备通常实现CL0-CL2之一与ML0-ML1之一的组合。
The terminology for the "Internet of Things" 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 and 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 limited memory and CPU power as well as aim to be self-configuring and easy to deploy.
将IP地址标识的受约束设备和智能设备与虚拟实体（如智能对象）进行区分，智能对象可通过使用唯一标识符标识为资源或虚拟对象。此外，智能设备通常具有有限的内存和CPU能力，并且旨在自我配置和易于部署。
However, the constraints of the network nodes require a rethinking of the protocol characteristics concerning power consumption, performance, bandwidth consumption, memory, and CPU usage. As such, there is a demand for protocol simplification, energy-efficient communication, less CPU usage, and a smaller memory footprint.
然而，网络节点的约束要求重新考虑有关功耗、性能、带宽消耗、内存和CPU使用的协议特性。因此，需要协议简化、高效节能的通信、更少的CPU使用和更小的内存占用。
On the application layer, the IETF is already developing protocols like the Constrained Application Protocol (CoAP) [RFC7252] enabling the communication of constrained devices and networks, e.g., for smart energy applications or home automation environments. In fact, the deployment of such an environment involves many, in some scenarios up to million, constrained devices (e.g., smart meters), which produce a large amount of data. This data needs to be collected, filtered, and preprocessed for further use in diverse services.
在应用层，IETF已经在开发诸如受限应用协议（CoAP）[RFC7252]之类的协议，以实现受限设备和网络的通信，例如用于智能能源应用或家庭自动化环境。事实上，这种环境的部署涉及许多（在某些情况下高达百万）受限制的设备（如智能电表），这些设备会产生大量数据。这些数据需要收集、过滤和预处理，以便在各种服务中进一步使用。
Considering the high number of nodes to deploy, one has to think about the 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. Consequently, seamless monitoring and self-configuration of such network nodes becomes more and more imperative. Self-configuration and self-management are already a reality in the standards of some organizations such as 3GPP. To introduce self-configuration of smart devices successfully, a device-initiated connection establishment is often required.
考虑到要部署的节点数量较多，必须考虑智能设备的可管理性方面，并计划方便地部署、配置和管理受约束设备的网络以及设备本身。因此，这种网络节点的无缝监控和自我配置变得越来越迫切。自我配置和自我管理在一些组织（如3GPP）的标准中已经成为现实。为了成功引入智能设备的自配置，通常需要设备启动的连接建立。
A simple and efficient 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.
简单高效的应用层协议（如CoAP）对于解决有效的对象间通信和信息交换问题至关重要。这种信息交换应基于可互操作的数据模型进行，以便能够交换和解释各种应用和管理相关数据。
In an ideal world, we would have only one network management protocol for monitoring, configuration, and exchanging management data, independently of the type of the network (e.g., smart grid, wireless access, or core network). Furthermore, it would be desirable to derive the basic data models for constrained devices from the core models used 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 use in a network of constrained devices. Furthermore, the data models addressing the requirements of such smart devices need yet to be designed.
与受约束设备所具有的功能相比，其重量太重，不能直接用于受约束设备网络。此外，还需要设计满足此类智能设备需求的数据模型。
So far, the IETF 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., today, devices with very limited memory and CPU resources use, 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, and reduced requirements coming from smart devices and the network of such constrained devices. Although it is questionable whether we can take the same comprehensive approach we use in an IP network and use it for the management of constrained devices. Hence, the management of a network with constrained devices is necessarily designed in a simplified and less complex manner.
到目前为止，IETF还没有开发任何特定的技术来管理受约束设备和由受约束设备组成的网络。基于IP的传感器或受限设备在这样的环境中，即今天，内存和CPU资源非常有限的设备使用，例如，应用层协议来进行简单的资源管理和监控。对于一些基本情况，这可能就足够了；然而，有必要根据智能设备和此类受限设备的网络带来的新的、变化的和减少的需求，重新考虑网络管理机制。尽管我们是否可以采用我们在IP网络中使用的相同综合方法，并将其用于受约束设备的管理，这一点值得怀疑。因此，具有受限设备的网络的管理必须以简化且不太复杂的方式设计。
As Section 1.6 highlights, there are diverse characteristics of constrained devices or networks, which stem from their constrainedness and therefore have an impact on the requirements for the management of such a network with constrained devices. The use cases discussed in [RFC7548] show that the requirements on constrained networks are manifold and need to be analyzed from different angles, e.g., concerning the design of the management architecture, the selection of the appropriate protocol features, as well as the specific issues that are new in the context of constrained devices. Examples of such issues are careful management of scarce energy resources, the necessity for self-organization and self-management of such devices but also the implementation considerations to enable the use of common communication technologies on a constrained hardware in an efficient manner. For an exhaustive list of issues and requirements that need to be addressed for the management of a network with constrained devices, please see Sections 1.6 and 3.
正如第1.6节所强调的，受约束设备或网络具有各种各样的特征，这些特征源于它们的约束性，因此对具有受约束设备的此类网络的管理要求产生影响。[RFC7548]中讨论的用例表明，受约束网络的需求是多方面的，需要从不同角度进行分析，例如，管理架构的设计、适当协议功能的选择以及受约束设备上下文中新出现的特定问题。这些问题的例子包括对稀缺能源的谨慎管理、此类设备自组织和自管理的必要性，以及实现方面的考虑，以便能够以有效的方式在受限硬件上使用通用通信技术。有关使用受限设备管理网络需要解决的问题和要求的详尽列表，请参见第1.6节和第3节。
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.
Req ID：由两个数字组成的ID：一个表示主题区域的节号和每个节唯一的三位数字。
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].
来源：需求的来源和匹配的用例或应用程序。有关约束管理的参考用例的讨论，请参见[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.
设备类型：支持此要求的设备类型：C0、C1和/或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.
优先级：要求的优先级，显示其对特定类型设备的重要性：高、中、低。需求的优先级可能较高，例如C2设备，但C1或C0设备的优先级较低，因为C1设备中的复杂功能在许多情况下是不可能实现的。
Req-ID: 1.001
请求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.
描述：大型网络通常由属于不同设备类别的设备（例如，受约束的网格端点和受约束较少的路由器）组成，这些设备相互通信。因此，管理体系结构必须适用于混合了不同设备类别的网络。有关受约束设备类的定义，请参见[RFC7228]第3节。
Source: All use cases
来源：所有用例
Requirement Type: Non-functional Requirement
需求类型：非功能性需求
Device type: C1 and/or C2
装置类型：C1和/或C2
Priority: High
优先事项：高
---
---
Req-ID: 1.002
请求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
设备类型：C0、C1和C2
Priority: High
优先事项：高
---
---
Req-ID: 1.003
请求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
请求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.
说明：应尽量减少受约束设备上需要维护的状态量。这对于节省内存（尤其与C0和C1设备相关）以及允许设备重新启动（例如，应用配置更改或从长时间的不活动状态恢复）非常重要。
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.
注意：实现这一点的一种方法是采用RESTful体系结构，该体系结构将受管理的受约束设备维护的状态量降至最低，并使设备的资源可通过URI寻址。
Source: Basic requirement that concerns all use cases
来源：涉及所有用例的基本需求
Requirement Type: Functional Requirement
需求类型：功能需求
Device type: C0, C1, and C2
设备类型：C0、C1和C2
Priority: High
优先事项：高
---
---
Req-ID: 1.005
请求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
设备类型：C0、C1和C2
Priority: High
优先事项：高
---
---
Req-ID: 1.006
请求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
设备类型：C0、C1和C2
Priority: High
优先事项：高
---
---
Req-ID: 1.007
请求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
设备类型：C0、C1和C2
Priority: Medium
优先：中等
---
---
Req-ID: 1.008
请求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
设备类型：C1和C2
Priority: Medium
优先：中等
Req-ID: 2.001
请求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.
描述：应指定管理协议，以允许模块化实现，即，应能够在高度受限的设备上仅实现一组基本的协议原语，而具有额外资源的设备可为额外的协议原语提供更多支持。有关受限制设备可能提供的配置管理和监控支持级别的讨论，请参见第1.7节。
Source: Basic requirement interesting for all use cases
来源：所有用例的基本需求
Requirement Type: Non-functional Requirement
需求类型：非功能性需求
Device type: C0, C1, and C2
设备类型：C0、C1和C2
Priority: High
优先事项：高
---
---
Req-ID: 2.002
申请编号：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
设备类型：C0、C1和C2
Priority: High
优先事项：高
---
---
Req-ID: 2.003
请求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.
说明：通过应用数据压缩技术或增量编码技术，可以进一步优化管理数据交换。压缩通常需要额外的代码大小和一些额外的缓冲区和/或维护一些额外的状态信息。对于C0设备，压缩可能不可行。
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
设备类型：C1和C2
Priority: Medium
优先：中等
---
---
Req-ID: 2.004
请求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
设备类型：C1和C2
Priority: Medium
优先：中等
---
---
Req-ID: 2.005
请求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.
说明：管理协议使用的数据模型必须与用于定义无约束网络数据模型的信息模型一致。这对于促进受约束网络管理与无约束网络管理的集成至关重要。在未来的数据模型设计中使用底层信息模型可以进一步实现自上而下的模型设计和模型重用以及数据互操作性（即，在受约束和不受约束的网络之间交换管理信息）。这是一个强烈的要求，尽管IETF中通常没有明确记录底层信息模型。
Source: General requirement to support data interoperability, consistency, and model reuse
来源：支持数据互操作性、一致性和模型重用的一般要求
Requirement Type: Non-functional Requirement
需求类型：非功能性需求
Device type: C0, C1, and C2
设备类型：C0、C1和C2
Priority: High
优先事项：高
---
---
Req-ID: 2.006
请求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
设备类型：C2
Priority: Medium
优先：中等
---
---
Req-ID: 2.007
请求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
设备类型：C0、C1和C2
Priority: High
优先事项：高
Req-ID: 3.001
请求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
设备类型：C0、C1和C2
Priority: High for device categories C0 and C1; Medium for C2
优先级：C0和C1类设备的优先级较高；中号指挥与控制
---
---
Req-ID: 3.002
请求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
设备类型：C1和C2
Priority: Medium
优先：中等
---
---
Req-ID: 3.003
请求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
设备类型：C1和C2
Priority: Medium
优先：中等
---
---
Req-ID: 3.004
请求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
设备类型：C0、C1和C2
Priority: Medium
优先：中等
Req-ID: 4.001
请求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
设备类型：C0、C1和C2
Priority: High; Medium for neighbor-monitoring
优先事项：高；邻居监测介质
---
---
Req-ID: 4.002
请求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
设备类型：C0、C1和C2
Priority: High for energy reporting devices; Low for others
优先级：能源报告装置的优先级高；对其他人来说很低
---
---
Req-ID: 4.003
请求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
设备类型：C0、C1和C2
Priority: Medium
优先：中等
---
---
Req-ID: 4.004
请求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
设备类型：C1和C2
Priority: Low, based on the realization complexity
优先级：低，基于实现复杂性
---
---
Req-ID: 4.005
请求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
设备类型：C1和C2
Priority: High for C2; Medium for C1
优先级：指挥与控制高；C1的培养基
---
---
Req-ID: 4.006
请求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
设备类型：C1和C2
Priority: Low
优先：低
---
---
Req-ID: 4.007
请求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.
说明：该设备将提供故障检测监控。系统收集有关网络状态的信息，以确定是否发生了故障。在某些情况下，故障检测可能基于对从网络或其他设备检索的参数的处理和分析。对于C0设备，监控可能仅限于检查设备是否处于活动状态。
Source: Use cases "Environmental Monitoring", "Building Automation", "Energy Management", "Infrastructure Monitoring"
资料来源：用例“环境监测”、“建筑自动化”、“能源管理”、“基础设施监测”
Requirement Type: Functional Requirement
需求类型：功能需求
Device type: C0, C1 and C2
设备类型：C0、C1和C2
Priority: Medium
优先：中等
---
---
Req-ID: 4.008
请求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
设备类型：C2
Priority: Medium
优先：中等
---
---
Req-ID: 4.009
请求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
设备类型：C2
Priority: Medium
优先：中等
---
---
Req-ID: 4.010
请求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
设备类型：C1和C2
Priority: Low, based on the realization complexity
优先级：低，基于实现复杂性
---
---
Req-ID: 4.011
请求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
设备类型：C0、C1和C2
Priority: Medium for C2; Low for C0 and C1
优先权：指挥与控制能力中等；C0和C1的电压过低
---
---
Req-ID: 4.012
请求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
设备类型：C2
Priority: High for some medical or industrial applications; Medium otherwise
优先级：对于某些医疗或工业应用，优先级较高；中等或中等
Req-ID: 5.001
请求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.
周期性地或按计划进行，以便在必要时触发自我管理。这是一个设备设计的问题，也是讨论C1设备能够支持多少自我管理的主题。
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
设备类型：C1和C2
Priority: High for C2; Medium for C1
优先级：指挥与控制高；C1的培养基
Req-ID: 6.001
请求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
设备类型：C0、C1和C2
Priority: High; Medium for the (re-)start of a large number of devices
优先事项：高；用于（重新）启动大量设备的介质
---
---
Req-ID: 6.002
请求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
设备类型：C0、C1和C2
Priority: High
优先事项：高
---
---
Req-ID: 6.003
请求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
设备类型：C0、C1和C2
Priority: High
优先事项：高
---
---
Req-ID: 6.004
请求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.
说明：密码算法对代码大小和总体执行时间都有重大影响。因此，有必要选择“强制”来实现加密算法，这些算法可以用可用的代码空间合理地实现，并且在运行时影响很小。此外，一些无线技术（如IEEE 802.15.4）需要支持某些加密算法。对于某些无线技术，选择无线芯片组中可能支持的算法可能很有用。
Source: Generic requirement to reduce the footprint and CPU usage of a constrained device
来源：减少受限设备占用空间和CPU使用的一般要求
Requirement Type: Non-functional Requirement
需求类型：非功能性需求
Device type: C0, C1, and C2
设备类型：C0、C1和C2
Priority: High; Medium for hardware-supported algorithms
优先事项：高；硬件支持算法的介质
Req-ID: 7.001
请求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.
描述：启用管理网络中的电源资源，例如，降低具有关键电池的节点的采样率并降低节点传输功率，使节点处于睡眠状态，使单个接口处于睡眠状态，根据可用能量或管理应用程序预定义的标准拒绝管理作业（例如，即使能量级别较低也强制执行的重要性级别）等。设备可进一步实现用于能量管理的标准数据模型，并通过管理协议接口公开它，例如，EMAN MIB模块[RFC7460]和[RFC7461]以及其他EMAN扩展。可能需要为C1和C2设备使用EMAN MIB的子集。
Source: Use case "Energy Management"
来源：用例“能源管理”
Requirement Type: Functional Requirement
需求类型：功能需求
Device type: C0, C1, and C2
设备类型：C0、C1和C2
Priority: Medium for the use case "Energy Management"; Low otherwise
优先级：用例“能源管理”的媒介；否则就低
---
---
Req-ID: 7.002
申请编号：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
设备类型：C2
Priority: Medium
优先：中等
---
---
Req-ID: 7.003
请求ID:7.003
Title: Support for Layer 2 (L2) energy-aware protocols
标题：支持第2层（L2）能量感知协议
Description: The device will support L2 energy-management protocols (e.g., energy-efficient Ethernet [IEEE802.3az]) and be able to report on these.
说明：设备将支持L2能源管理协议（例如，节能以太网[IEEE802.3az]），并能够报告这些协议。
Source: Use case "Energy Management"
来源：用例“能源管理”
Requirement Type: Non-functional Requirement
需求类型：非功能性需求
Device type: C0, C1, and C2
设备类型：C0、C1和C2
Priority: Medium
优先：中等
---
---
Req-ID: 7.004
请求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
设备类型：C0、C1和C2
Priority: Medium
优先：中等
Req-ID: 8.001
请求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
设备类型：C0、C1和C2
Priority: Medium
优先：中等
Req-ID: 9.001
请求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.
描述：支持[RFC2914]中定义的拥塞控制原则，例如，通过根据管理数据的重要性和可靠性级别修改设备的定期数据报告率（通常是冗余的），避免拥塞的能力。此功能通常由管理实体控制，管理实体将数据标记为重要或与可靠性相关。但是，如果设备能够检测到拥塞或缓冲内存不足，则降低设备的报告速率也可以由设备启动。
Source: Use cases with high reporting rate and traffic, e.g., AMI or M2M
来源：具有高报告率和流量的用例，例如AMI或M2M
Requirement Type: Non-functional Requirement
需求类型：非功能性需求
Device type: C1 and C2
设备类型：C1和C2
Priority: Medium
优先：中等
---
---
Req-ID: 9.002
申请编号：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
来源：具有高报告率和流量的用例，例如AMI或M2M
Requirement Type: Non-functional Requirement
需求类型：非功能性需求
Device type: Intermediary entity in the network
设备类型：网络中的中间实体
Priority: Medium
优先：中等
---
---
Req-ID: 9.003
请求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
来源：具有高报告率和流量的用例，例如AMI或M2M
Requirement Type: Non-functional Requirement
需求类型：非功能性需求
Device type: Intermediary entity in the network
设备类型：网络中的中间实体
Priority: Medium
优先：中等
Req-ID: 10.001
请求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
设备类型：C0、C1和C2
Priority: Medium
优先：中等
---
---
Req-ID: 10.002
请求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.
描述：不同的应用程序需要可靠的消息传输。可靠性可以基于传输协议（如TCP）来实现，或者如果缺少确认，则可以基于消息重复来支持可靠性。
Source: Generally, applications benefit from the reliability of the message transport
来源：一般来说，应用程序受益于消息传输的可靠性
Requirement Type: Functional Requirement
需求类型：功能需求
Device type: C0, C1, and C2
设备类型：C0、C1和C2
Priority: High
优先事项：高
---
---
Req-ID: 10.003
请求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
来源：设备需要发现服务的用例以及需要管理大量设备的用例，这些设备是分层部署的，例如AMI或M2M
Requirement Type: Functional Requirement
需求类型：功能需求
Device type: C0, C1, and C2
设备类型：C0、C1和C2
Priority: Medium
优先：中等
---
---
Req-ID: 10.004
请求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.
描述：通过使用现有的传输层技术（如TLS/DTL），实现安全的消息传输，提供身份验证、数据完整性和机密性。
Source: All use cases
来源：所有用例
Requirement Type: Non-functional Requirements
需求类型：非功能性需求
Device type: C1 and C2
设备类型：C1和C2
Priority: High
优先事项：高
Req-ID: 11.001
请求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.
描述：复杂的应用层事务往往需要大型内存缓冲区，这些缓冲区通常在C0或C1设备上不可用，并且仅通过限制C2设备上的功能。此外，单个大型事务的失败需要重复整个事务。在受约束的设备上，通常更希望将大型事务拆分为一系列较小的事务，这些事务需要较少的资源，并允许使用一系列较小的步骤进行处理。
Source: Basic requirement that concerns all use cases with memory constrained devices
来源：涉及内存受限设备的所有用例的基本要求
Requirement Type: Non-functional Requirement
需求类型：非功能性需求
Device type: C0, C1, and C2
设备类型：C0、C1和C2
Priority: High
优先事项：高
---
---
Req-ID: 11.002
请求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.
描述：在协议栈的多个层上重新组装消息需要在多个层上使用缓冲区，这会导致内存资源的低效使用。这可以通过确保应用层、安全层、传输层、IPv6层和任何适配层了解彼此的限制来避免，从而避免不必要的碎片和重组。此外，必须向协议对等方宣布消息大小限制，以便它们能够适应并避免发送由于接收设备上的资源限制而无法处理的消息。
Source: Basic requirement that concerns all use cases with memory constrained devices
来源：涉及内存受限设备的所有用例的基本要求
Requirement Type: Non-functional Requirement
需求类型：非功能性需求
Device type: C0, C1, and C2
设备类型：C0、C1和C2
Priority: High
优先事项：高
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.
本文件讨论受约束设备网络的问题陈述和要求。第1.6节提到了一些可能会妨碍实施强加密算法的限制。第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).
受约束的设备还可能生成敏感数据或需要处理敏感数据。因此，为了保护使用互联网设备的人的隐私，正确保护对数据的访问是一项重要的要求。对于某些类型的数据，网络传输期间的保护可能不够，应研究在缓存或存储数据时（例如，当使用存储转发传输机制时）提供数据保护的方法。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, DOI 10.17487/RFC2914, September 2000, <http://www.rfc-editor.org/info/rfc2914>.
[RFC2914]Floyd，S.，“拥塞控制原则”，BCP 41，RFC 2914，DOI 10.17487/RFC2914，2000年9月<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>.
[RFC2501]Corson，S.和J.Macker，“移动自组网（MANET）：路由协议性能问题和评估考虑”，RFC 2501，DOI 10.17487/RFC2501，1999年1月<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>.
[RFC6632]Ersue，M.，Ed.和B.Claise，“IETF网络管理标准概述”，RFC 6632，DOI 10.17487/RFC6632，2012年6月<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>.
[RFC7102]Vasseur，JP.，“低功率和有损网络路由中使用的术语”，RFC 7102，DOI 10.17487/RFC7102，2014年1月<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>.
[RFC7228]Bormann，C.，Ersue，M.和A.Keranen，“受限节点网络的术语”，RFC 7228，DOI 10.17487/RFC7228，2014年5月<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>.
[RFC7252]Shelby，Z.，Hartke，K.，和C.Bormann，“受限应用协议（CoAP）”，RFC 7252，DOI 10.17487/RFC7252，2014年6月<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>.
[RFC4919]Kushalnagar，N.，黑山，G.和C.Schumacher，“低功率无线个人区域网络（6LoWPANs）上的IPv6：概述，假设，问题陈述和目标”，RFC 4919，DOI 10.17487/RFC4919，2007年8月<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>.
[RFC6550]温特，T.，Ed.，Thubert，P.，Ed.，Brandt，A.，Hui，J.，Kelsey，R.，Levis，P.，Pister，K.，Struik，R.，Vasseur，JP.，和R.Alexander，“RPL:低功耗和有损网络的IPv6路由协议”，RFC 6550，DOI 10.17487/RFC6550，2012年3月<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>.
[RFC7460]Chandramouli，M.，Claise，B.，Schoining，B.，Quitek，J.，和T.Dietz，“电力和能源的监控MIB”，RFC 7460，DOI 10.17487/RFC7460，2015年3月<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>.
[RFC7461]Parello，J.，Claise，B.，和M.Chandramouli，“能源对象上下文MIB”，RFC 7461，DOI 10.17487/RFC7461，2015年3月<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>.
[RFC7548]Ersue，M.，Ed.，Romascanu，D.，Schoenwaeld，J.，和A.Sehgal，“受约束设备的网络管理：用例”，RFC 7548，DOI 10.17487/RFC7548，2015年5月<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.4]IEEE，“第15.4部分：低速无线个人区域网络（LR WPAN）”，IEEE标准802.15.4，2011年9月<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.15.1]IEEE，“第15.1部分：无线个人区域网络（WPAN）的无线媒体访问控制（MAC）和物理层（PHY）规范”，IEEE标准802.15.1，2005年6月<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>.
[IEEE802.3az]IEEE，“以太网”，IEEE标准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.
作者要感谢Coman和OPSAWG邮件列表上的评审员和参与者，感谢他们的宝贵贡献和评论。
Juergen Schoenwaelder was partly funded by Flamingo, a Network of Excellence project (ICT-318488) supported by the European Commission under its Seventh Framework Programme.
Juergen Schoenwaeld的部分资金来自Flamingo，这是一个卓越网络项目（ICT-318488），由欧盟委员会在其第七个框架计划下支持。
Authors' Addresses
作者地址
Mehmet Ersue (editor) Nokia Networks
Mehmet Ersue（编辑）诺基亚网络
EMail: mehmet.ersue@nokia.com
EMail: mehmet.ersue@nokia.com
Dan Romascanu Avaya
丹·罗马斯卡努·阿瓦亚
EMail: dromasca@avaya.com
EMail: dromasca@avaya.com
Juergen Schoenwaelder Jacobs University Bremen
不莱梅大学
EMail: j.schoenwaelder@jacobs-university.de
EMail: j.schoenwaelder@jacobs-university.de
Ulrich Herberg
乌尔里希·赫伯格
EMail: ulrich@herberg.name
EMail: ulrich@herberg.name