Internet Engineering Task Force (IETF) A. Brandt
Request for Comments: 7733 Sigma Designs
Category: Standards Track E. Baccelli
ISSN: 2070-1721 INRIA
R. Cragie
ARM Ltd.
P. van der Stok
Consultant
February 2016
Internet Engineering Task Force (IETF) A. Brandt
Request for Comments: 7733 Sigma Designs
Category: Standards Track E. Baccelli
ISSN: 2070-1721 INRIA
R. Cragie
ARM Ltd.
P. van der Stok
Consultant
February 2016
Applicability Statement: The Use of the Routing Protocol for Low-Power and Lossy Networks (RPL) Protocol Suite in Home Automation and Building Control
适用性声明：低功耗和有损网络路由协议（RPL）协议套件在家庭自动化和楼宇控制中的使用
Abstract
摘要
The purpose of this document is to provide guidance in the selection and use of protocols from the Routing Protocol for Low-Power and Lossy Networks (RPL) protocol suite to implement the features required for control in building and home environments.
本文件旨在为低功耗和有损网络路由协议（RPL）协议套件中协议的选择和使用提供指导，以实现楼宇和家庭环境中控制所需的功能。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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/rfc7733.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7733.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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 ....................................................4
1.1. Relationship to Other Documents ............................5
1.2. Terminology ................................................6
1.3. Required Reading ...........................................6
1.4. Requirements That Are Out of Scope .........................6
2. Deployment Scenario .............................................6
2.1. Network Topologies .........................................7
2.2. Traffic Characteristics ....................................8
2.2.1. General .............................................9
2.2.2. Source-Sink (SS) Communication Paradigm ............10
2.2.3. Publish-Subscribe (PS, or Pub/Sub)
Communication Paradigm .............................10
2.2.4. Peer-to-Peer (P2P) Communication Paradigm ..........10
2.2.5. Peer-to-Multipeer (P2MP) Communication Paradigm ....11
2.2.6. Additional Considerations: Duocast and N-Cast ......11
2.2.7. RPL Applicability per Communication Paradigm .......11
2.3. Layer 2 Applicability .....................................13
3. Using RPL to Meet Functional Requirements ......................13
4. RPL Profile ....................................................14
4.1. RPL Features ..............................................14
4.1.1. RPL Instances ......................................15
4.1.2. Storing vs. Non-Storing Mode .......................15
4.1.3. DAO Policy .........................................15
4.1.4. Path Metrics .......................................15
4.1.5. Objective Function .................................16
4.1.6. DODAG Repair .......................................16
4.1.7. Multicast ..........................................16
4.1.8. Security ...........................................17
4.1.9. P2P Communications .................................21
4.1.10. IPv6 Address Configuration ........................21
4.2. Layer 2 Features ..........................................21
4.2.1. Specifics about Layer 2 ............................21
4.2.2. Services Provided at Layer 2 .......................21
4.2.3. IPv6 over Low-Power Wireless Personal Area
Network (6LoWPAN) Options Assumed ..................21
4.2.4. Mesh Link Establishment (MLE) and Other Things .....21
4.3. Recommended Configuration Defaults and Ranges .............21
4.3.1. Trickle Parameters .................................22
4.3.2. Other Parameters ...................................22
5. MPL Profile ....................................................23
5.1. Recommended Configuration Defaults and Ranges .............23
5.1.1. Real-Time Optimizations ............................23
5.1.2. Trickle Parameters .................................23
5.1.3. Other Parameters ...................................24
6. Manageability Considerations ...................................25
1. Introduction ....................................................4
1.1. Relationship to Other Documents ............................5
1.2. Terminology ................................................6
1.3. Required Reading ...........................................6
1.4. Requirements That Are Out of Scope .........................6
2. Deployment Scenario .............................................6
2.1. Network Topologies .........................................7
2.2. Traffic Characteristics ....................................8
2.2.1. General .............................................9
2.2.2. Source-Sink (SS) Communication Paradigm ............10
2.2.3. Publish-Subscribe (PS, or Pub/Sub)
Communication Paradigm .............................10
2.2.4. Peer-to-Peer (P2P) Communication Paradigm ..........10
2.2.5. Peer-to-Multipeer (P2MP) Communication Paradigm ....11
2.2.6. Additional Considerations: Duocast and N-Cast ......11
2.2.7. RPL Applicability per Communication Paradigm .......11
2.3. Layer 2 Applicability .....................................13
3. Using RPL to Meet Functional Requirements ......................13
4. RPL Profile ....................................................14
4.1. RPL Features ..............................................14
4.1.1. RPL Instances ......................................15
4.1.2. Storing vs. Non-Storing Mode .......................15
4.1.3. DAO Policy .........................................15
4.1.4. Path Metrics .......................................15
4.1.5. Objective Function .................................16
4.1.6. DODAG Repair .......................................16
4.1.7. Multicast ..........................................16
4.1.8. Security ...........................................17
4.1.9. P2P Communications .................................21
4.1.10. IPv6 Address Configuration ........................21
4.2. Layer 2 Features ..........................................21
4.2.1. Specifics about Layer 2 ............................21
4.2.2. Services Provided at Layer 2 .......................21
4.2.3. IPv6 over Low-Power Wireless Personal Area
Network (6LoWPAN) Options Assumed ..................21
4.2.4. Mesh Link Establishment (MLE) and Other Things .....21
4.3. Recommended Configuration Defaults and Ranges .............21
4.3.1. Trickle Parameters .................................22
4.3.2. Other Parameters ...................................22
5. MPL Profile ....................................................23
5.1. Recommended Configuration Defaults and Ranges .............23
5.1.1. Real-Time Optimizations ............................23
5.1.2. Trickle Parameters .................................23
5.1.3. Other Parameters ...................................24
6. Manageability Considerations ...................................25
7. Security Considerations ........................................25
7.1. Security Considerations during Initial Deployment .........26
7.2. Security Considerations during Incremental Deployment .....27
7.3. Security Considerations for P2P Implementations ...........27
7.4. MPL Routing ...............................................27
7.5. RPL Security Features .....................................27
8. Other Related Protocols ........................................28
9. References .....................................................28
9.1. Normative References ......................................28
9.2. Informative References ....................................32
Appendix A. RPL Shortcomings in Home and Building Deployments .....35
A.1. Risk of Undesirable Long P2P Routes ........................35
A.1.1. Traffic Concentration at the Root ......................35
A.1.2. Excessive Battery Consumption in Source Nodes ..........35
A.2. Risk of Delayed Route Repair ...............................35
A.2.1. Broken Service .........................................36
Appendix B. Communication Failures ................................36
Acknowledgements ..................................................38
Authors' Addresses ................................................38
7. Security Considerations ........................................25
7.1. Security Considerations during Initial Deployment .........26
7.2. Security Considerations during Incremental Deployment .....27
7.3. Security Considerations for P2P Implementations ...........27
7.4. MPL Routing ...............................................27
7.5. RPL Security Features .....................................27
8. Other Related Protocols ........................................28
9. References .....................................................28
9.1. Normative References ......................................28
9.2. Informative References ....................................32
Appendix A. RPL Shortcomings in Home and Building Deployments .....35
A.1. Risk of Undesirable Long P2P Routes ........................35
A.1.1. Traffic Concentration at the Root ......................35
A.1.2. Excessive Battery Consumption in Source Nodes ..........35
A.2. Risk of Delayed Route Repair ...............................35
A.2.1. Broken Service .........................................36
Appendix B. Communication Failures ................................36
Acknowledgements ..................................................38
Authors' Addresses ................................................38
The primary purpose of this document is to give guidance in the use of the Routing Protocol for Low-Power and Lossy Networks (RPL) protocol suite in two application domains:
本文件的主要目的是在两个应用领域中为低功耗和有损网络（RPL）协议套件的路由协议的使用提供指导：
o Home automation
o 家庭自动化
o Building automation
o 楼宇自动化
The guidance is based on the features required by the requirements documents "Home Automation Routing Requirements in Low-Power and Lossy Networks" [RFC5826] and "Building Automation Routing Requirements in Low-Power and Lossy Networks" [RFC5867], respectively. The Advanced Metering Infrastructure is also considered where appropriate. The applicability domains distinguish themselves in the way they are operated, their performance requirements, and the most likely network structures. An abstract set of distinct communication paradigms is then used to frame the applicability domains.
本指南分别基于要求文件“低功率和有损网络中的家庭自动化路由要求”[RFC5826]和“低功率和有损网络中的楼宇自动化路由要求”[RFC5867]所要求的功能。在适当的情况下，还考虑采用先进的计量基础设施。适用性域在其操作方式、性能要求和最可能的网络结构方面有所不同。然后使用一组抽象的不同通信范例来构建适用性域。
Home automation and building automation application domains share a substantial number of properties:
家庭自动化和楼宇自动化应用领域共享大量属性：
o In both domains, the network can be disconnected from the ISP and must still continue to provide control to the occupants of the home or building. Routing needs to be possible independent of the existence of a border router.
o 在这两个域中，网络都可以断开与ISP的连接，并且必须继续为住宅或建筑物的居住者提供控制。路由需要独立于边界路由器的存在。
o Both domains are subject to unreliable links but require instant and very reliable reactions. This has an impact on routing because of timeliness and multipath routing.
o 这两个域都有不可靠的链接，但需要即时和非常可靠的反应。由于时效性和多路径路由，这会对路由产生影响。
The differences between the two application domains mostly appear in commissioning, maintenance, and the user interface, which do not typically affect routing. Therefore, the focus of this applicability document is on reliability, timeliness, and local routing.
这两个应用程序域之间的差异主要出现在调试、维护和用户界面中，这通常不会影响路由。因此，本适用性文件的重点是可靠性、及时性和本地路由。
It should be noted that adherence to the guidance in this document does not necessarily guarantee fully interoperable solutions in home automation networks and building control networks and that additional rigorous and managed programs will be needed to ensure interoperability.
应注意的是，遵守本文件中的指南并不一定能保证家庭自动化网络和楼宇控制网络中的解决方案完全互操作，还需要额外的严格和管理的计划来确保互操作性。
The Routing Over Low power and Lossy networks (ROLL) working group has specified a set of routing protocols for Low-Power and Lossy Networks (LLNs) [RFC6550]. This applicability text describes a subset of those protocols and the conditions under which the subset is appropriate, and it provides recommendations and requirements for the accompanying parameter value ranges.
低功耗和有损网络上的路由（ROLL）工作组为低功耗和有损网络（LLN）指定了一组路由协议[RFC6550]。本适用性文本描述了这些协议的子集以及子集适用的条件，并提供了相关参数值范围的建议和要求。
In addition, [RFC6997] was written specifically as an extension to core RPL [RFC6550] and provides a solution for reactive discovery of point-to-point routes in LLNs. The present applicability document provides recommendations and requirements for the accompanying parameter value ranges.
此外，[RFC6997]是作为核心RPL[RFC6550]的扩展而专门编写的，它为LLN中点到点路由的反应式发现提供了解决方案。本适用性文件提供了随附参数值范围的建议和要求。
[RFC7416] describes a common set of security threats. The applicability statements provided in Section 4.1.8.2.2 of this document complement [RFC7416] by describing preferred security settings and solutions within the applicability statement conditions. This applicability statement recommends lighter-weight security solutions appropriate for home and building environments and indicates why these solutions are appropriate.
[RFC7416]描述了一组常见的安全威胁。本文件第4.1.8.2.2节中提供的适用性声明通过描述适用性声明条件内的首选安全设置和解决方案来补充[RFC7416]。本适用性声明建议适用于家庭和建筑环境的轻型安全解决方案，并说明这些解决方案的适用性。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Additionally, this document uses terminology from [RFC6997], [RFC7731], [RFC7102], [IEEE802.15.4], and [RFC6550].
此外，本文件使用了[RFC6997]、[RFC7731]、[RFC7102]、[IEEE802.15.4]和[RFC6550]中的术语。
Applicable requirements are described in [RFC5826] and [RFC5867]. A survey of the application field is described in [BC-Survey].
[RFC5826]和[RFC5867]中描述了适用的要求。[BC survey]中介绍了应用领域的概况。
The considered network diameter is limited to a maximum diameter of 10 hops and a typical diameter of five hops; this captures the most common cases in home automation and building control networks.
所考虑的网络直径限制为最大直径为10跳，典型直径为5跳；这捕获了家庭自动化和楼宇控制网络中最常见的情况。
This document does not consider the applicability of RPL-related specifications for urban and industrial applications [RFC5548] [RFC5673], which may exhibit significantly larger network diameters.
本文件不考虑RPL相关规范适用于城市和工业应用[RFC5648 ] [RCF5673]，这可能表现出更大的网络直径。
The use of communications networks in buildings is essential to satisfy energy-saving regulations. Environmental conditions of buildings can be adapted to suit the comfort of the individuals present inside. Consequently, when no one is present, energy consumption can be reduced. Cost is the main driving factor behind deployment of wireless networking in buildings, especially in the case of retrofitting, where wireless connectivity saves costs incurred due to cabling and building modifications.
在建筑物中使用通信网络对于满足节能法规至关重要。建筑物的环境条件可以进行调整，以适应室内人员的舒适度。因此，当无人在场时，可以降低能耗。成本是在建筑物中部署无线网络的主要驱动因素，尤其是在改装的情况下，无线连接可以节省布线和建筑物改造所产生的成本。
A typical home automation network is comprised of less than 100 nodes. Large building deployments may span 10,000 nodes, but to ensure uninterrupted service of light and air conditioning systems in individual zones of the building, nodes are typically organized in subnetworks. Each subnetwork in a building automation deployment typically contains tens to hundreds of nodes and, for critical operations, may operate independently from the other subnetworks.
典型的家庭自动化网络由不到100个节点组成。大型建筑部署可能跨越10000个节点，但为了确保建筑各个区域的照明和空调系统的不间断服务，节点通常组织在子网中。楼宇自动化部署中的每个子网通常包含数十到数百个节点，对于关键操作，可以独立于其他子网运行。
The main purpose of the home or building automation network is to provide control over light and heating/cooling resources. User intervention via wall controllers is combined with movement, light and temperature sensors to enable automatic adjustment of window blinds, reduction of room temperature, etc. In general, the sensors
家庭或楼宇自动化网络的主要目的是提供对照明和供暖/制冷资源的控制。通过墙壁控制器进行的用户干预与运动、光线和温度传感器相结合，以实现自动调整百叶窗、降低室温等。通常，传感器
and actuators in a home or building typically have fixed physical locations and will remain in the same home or building automation network.
家庭或建筑物中的执行器通常具有固定的物理位置，并将保持在同一个家庭或建筑物自动化网络中。
People expect an immediate and reliable response to their presence or actions. For example, a light not switching on after entry into a room may lead to confusion and a profound dissatisfaction with the lighting product.
人们期望对他们的存在或行为做出立即可靠的反应。例如，进入房间后未打开的灯可能会导致混乱和对照明产品的严重不满。
Monitoring of functional correctness is at least as important as timely responses. Devices typically communicate their status regularly and send alarm messages to notify users or implementers that a malfunction of controlled equipment or a controlled network has occurred.
对功能正确性的监控至少与及时响应同等重要。设备通常定期传达其状态，并发送警报消息，通知用户或实施者受控设备或受控网络发生故障。
In building control, the infrastructure of the building management network can be shared with security/access, Internet Protocol (IP) telephony, and fire/alarm networks. This approach has a positive impact on the operation and cost of the network; however, care should be taken to ensure that the availability of the building management network does not become compromised beyond the ability of critical functions to perform adequately.
在楼宇控制中，楼宇管理网络的基础设施可与安全/接入、互联网协议（IP）电话和火灾/报警网络共享。这种方法对网络的运营和成本有积极影响；但是，应注意确保建筑物管理网络的可用性不会超出关键功能充分执行的能力。
In homes, the entertainment network for audio/video streaming and gaming has different requirements, where the most important requirement is the need for high bandwidth not typically needed for home or building control. It is therefore expected that the entertainment network in the home will mostly be separate from the control network, as this will also lessen the impact on the availability of the control network.
在家庭中，用于音频/视频流和游戏的娱乐网络有不同的要求，其中最重要的要求是对家庭或建筑控制通常不需要的高带宽的需求。因此，预计家庭中的娱乐网络将主要与控制网络分开，因为这也将减少对控制网络可用性的影响。
In general, the home automation network or building control network consists of wired and wireless subnetworks. In large buildings in particular, the wireless subnetworks can be connected to an IP backbone network where all infrastructure services (e.g., Domain Name System (DNS), automation servers) are located.
通常，家庭自动化网络或楼宇控制网络由有线和无线子网络组成。特别是在大型建筑物中，无线子网可以连接到所有基础设施服务（例如域名系统（DNS）、自动化服务器）所在的IP主干网。
The wireless subnetwork can be configured according to any of the following topologies:
无线子网可根据以下任何拓扑进行配置：
o A stand-alone network of 10-100 nodes without a border router. This typically occurs in the home with a stand-alone control network, in low-cost buildings, and during installation of high-end control systems in buildings.
o 由10-100个节点组成的独立网络，没有边界路由器。这通常发生在具有独立控制网络的家庭、低成本建筑以及在建筑中安装高端控制系统的过程中。
o A connected network with one border router. This configuration will happen in homes where home appliances are controlled from outside the home, possibly via a smart phone, and in many building control scenarios.
o 带有一个边界路由器的连接网络。这种配置将发生在家用电器由家庭外部控制（可能通过智能手机）的家庭中，以及许多楼宇控制场景中。
o A connected network with multiple border routers. This will typically happen in installations of large buildings.
o 具有多个边界路由器的连接网络。这通常发生在大型建筑物的安装中。
Many of the nodes are battery powered and may be sleeping nodes that wake up according to clock signals or external events.
许多节点由电池供电，可能是根据时钟信号或外部事件唤醒的休眠节点。
In a building control network, for a large installation with multiple border routers, subnetworks often overlap both geographically and from a wireless coverage perspective. Due to two purposes of the network -- (i) direct control and (ii) monitoring -- there may exist two types of routing topologies in a given subnetwork: (i) a tree-shaped collection of routes spanning from a central building controller via the border router, on to destination nodes in the subnetwork, and (ii) a flat, undirected collection of intra-network routes between functionally related nodes in the subnetwork.
在楼宇控制网络中，对于具有多个边界路由器的大型装置，子网络通常在地理位置和无线覆盖角度上重叠。由于网络的两个目的——（i）直接控制和（ii）监控——给定子网中可能存在两种类型的路由拓扑：（i）从中央建筑控制器通过边界路由器到子网中的目标节点的树状路由集合，以及（ii）平面，子网络中功能相关节点之间的网络内路由的无向集合。
The majority of nodes in home and building automation networks are typically Class 0 devices [RFC7228], such as individual wall switches. Only a few nodes (such as multi-purpose remote controls) are more expensive Class 1 devices, which can afford more memory capacity.
家庭和楼宇自动化网络中的大多数节点通常为0级设备[RFC7228]，例如单独的墙壁开关。只有少数节点（如多用途遥控器）是更昂贵的1类设备，可以提供更多的内存容量。
Traffic may enter the network originating from a central controller, or it may originate from an intra-network node. The majority of traffic is of a lightweight point-to-point control style, e.g., Put-Ack or Get-Response. There are, however, exceptions. Bulk data transfer is used for firmware updates and logging, where firmware updates enter the network and logs leave the network. Group communication is used for service discovery or to control groups of nodes, such as light fixtures.
流量可以从中央控制器进入网络，也可以从网络内节点进入网络。大多数流量是轻量级的点对点控制方式，例如Put Ack或Get Response。然而，也有例外。批量数据传输用于固件更新和日志记录，其中固件更新进入网络，日志离开网络。组通信用于服务发现或控制节点组，如照明设备。
Often, there is a direct physical relationship between a controlling sensor and the controlled equipment. For example, the temperature sensor and room controller are located in the same room, sharing the same climate conditions. Consequently, the bulk of senders and receivers are separated by a distance that allows one-hop direct path communication. A graph of the communication will show several fully connected subsets of nodes. However, due to interference, multipath fading, reflection, and other transmission mechanisms, the one-hop direct path may be temporarily disconnected. For reliability purposes, it is therefore essential that alternative n-hop communication routes exist for quick error recovery. (See Appendix B for motivation.)
通常，控制传感器和受控设备之间存在直接的物理关系。例如，温度传感器和房间控制器位于同一房间，共享相同的气候条件。因此，大部分发送方和接收方之间的距离允许单跳直接路径通信。通信图将显示几个完全连接的节点子集。然而，由于干扰、多径衰落、反射和其他传输机制，一跳直接路径可能暂时断开。因此，出于可靠性目的，必须存在替代的n-hop通信路由，以实现快速错误恢复。（动机见附录B。）
Looking over time periods of a day, the networks are very lightly loaded. However, bursts of traffic can be generated by, for example, incessant pushing of the button of a remote control, the occurrence of a defect, and other unforeseen events. Under those conditions, the timeliness must nevertheless be maintained. Therefore, measures are necessary to remove any unnecessary traffic. Short routes are preferred. Long multi-hop routes via the border router should be avoided whenever possible.
从一天的时间段来看，网络负载非常轻。然而，例如，连续按下遥控器的按钮、发生故障和其他不可预见的事件可产生突发通信量。在这种情况下，必须保持及时性。因此，有必要采取措施消除任何不必要的交通。短途路线优先。应尽可能避免通过边界路由器的长多跳路由。
Group communication is essential for lighting control. For example, once the presence of a person is detected in a given room, lighting control applies to that room only, and no other lights should be dimmed or switched on/off. In many cases, this means that a multicast message with a one-hop and two-hop radius would suffice to control the required lights. The same argument holds for Heating, Ventilating, and Air Conditioning (HVAC) and other climate-control devices. To reduce network load, it is advisable that messages to the lights in a room are not distributed any further in the mesh than necessary, based on intended receivers.
群组通信对于照明控制至关重要。例如，一旦在给定房间内检测到有人在场，照明控制仅适用于该房间，不应调暗或打开/关闭其他灯光。在许多情况下，这意味着具有一跳和两跳半径的多播消息足以控制所需的灯光。同样的观点也适用于暖通空调（HVAC）和其他气候控制设备。为了减少网络负载，建议根据预期的接收器，在网格中向房间内的灯发送的消息不要超出必要的范围。
[Office-Light] provides an example of an office space, and [OccuSwitch] describes the current use of wireless lighting control products.
[Office Light]提供了一个办公空间的示例，[OccupSwitch]介绍了无线照明控制产品的当前使用情况。
Although air conditioning and other environmental-control applications may accept response delays of tens of seconds or longer, alarm and light control applications may be regarded as soft real-time systems. A slight delay is acceptable, but the perceived quality of service degrades significantly if response times exceed 250 ms. If the light does not turn on at short notice, a user may activate the controls again, thus causing a sequence of commands such as Light{on,off,on,off,...} or Volume{up,up,up,up,up,...}. In
尽管空调和其他环境控制应用可能接受数十秒或更长的响应延迟，但报警和灯光控制应用可能被视为软实时系统。轻微延迟是可以接受的，但如果响应时间超过250毫秒，感知服务质量会显著下降。如果灯在短时间内没有打开，用户可能会再次激活控件，从而导致一系列命令，例如灯{on，off，on，off，…}或音量{up，up，up，up，…}。在里面
addition, the repetitive sending of commands creates an unnecessary loading of the network, which in turn increases the poor responsiveness of the network.
此外，重复发送命令会造成不必要的网络负载，这反过来又会增加网络的不良响应。
This paradigm translates to many sources sending messages to the same sink, sometimes reachable via the border router. As such, Source-Sink (SS) traffic can be present in home and building networks. The traffic may be generated by environmental sensors (often present in a wireless subnetwork) that push periodic readings to a central server. The readings may be used for pure logging or, more often, processed to adjust light, heating, and ventilation. Alarm sensors may also generate SS-style traffic. The central server in a home automation network will be connected mostly to a wired network segment of the home network, although it is likely that cloud services will also be used. The central server in a building automation network may be connected to a backbone or placed outside the building.
这种模式转换为多个源向同一个接收器发送消息，有时可通过边界路由器到达。因此，源-汇（SS）流量可以出现在家庭和楼宇网络中。流量可能由环境传感器（通常存在于无线子网络中）产生，这些传感器将定期读数推送到中央服务器。读数可用于纯记录，或更常见的是，用于调节光线、加热和通风。报警传感器也可能产生SS类型的流量。家庭自动化网络中的中央服务器将主要连接到家庭网络的有线网段，尽管也可能使用云服务。楼宇自动化网络中的中央服务器可以连接到主干网或放置在建筑物外部。
With regard to message latency, most SS transmissions can tolerate worst-case delays measured in tens of seconds. Fire detectors, however, represent an exception; for example, special provisions with respect to the location of the fire detectors and smoke dampers need to be put in place to meet stringent delay requirements that are measured in seconds.
关于消息延迟，大多数SS传输可以容忍以数十秒为单位测量的最坏情况延迟。然而，火灾探测器是一个例外；例如，需要制定有关火灾探测器和烟雾挡板位置的特殊规定，以满足以秒为单位的严格延迟要求。
This paradigm translates to a number of devices expressing their interest in a service provided by a server device. For example, a server device can be a sensor delivering temperature readings on the basis of delivery criteria, like changes in acquisition value or age of the latest acquisition. In building automation networks, this paradigm may be closely related to the SS paradigm, given that servers, which are connected to the backbone or outside the building, can subscribe to data collectors that are present at strategic places in the building automation network. The use of PS will probably differ significantly from installation to installation.
这个范例转化为许多设备，它们表示对服务器设备提供的服务感兴趣。例如，服务器设备可以是传感器，根据传递标准传递温度读数，如采集值的变化或最新采集的时间。在楼宇自动化网络中，这种模式可能与SS模式密切相关，因为连接到主干网或楼宇外部的服务器可以订阅楼宇自动化网络中关键位置的数据采集器。PS的使用可能因安装而异。
This paradigm translates to a device transferring data to another device often connected to the same subnetwork. Peer-to-Peer (P2P) traffic is a common traffic type in home automation networks. Most building automation networks rely on P2P traffic as described in the next paragraph. Other building automation networks rely on P2P control traffic between controls and a local controller box for
这种模式转化为一个设备将数据传输到另一个设备，该设备通常连接到同一子网络。对等（P2P）流量是家庭自动化网络中常见的流量类型。如下一段所述，大多数楼宇自动化网络依赖于P2P流量。其他楼宇自动化网络依赖于控制之间的P2P控制流量和本地控制器箱进行通信
advanced group control. A local controller box can be further connected to service control boxes, thus generating more SS or PS traffic.
高级组控制。本地控制器盒可以进一步连接到服务控制盒，从而产生更多的SS或PS通信量。
P2P traffic is typically generated by remote controls and wall controllers that push Control Messages directly to light or heat sources. P2P traffic has a stringent requirement for low latency, since P2P traffic often carries application messages that are invoked by humans. As mentioned in Section 2.2.1, application messages should be delivered within a few hundred milliseconds, even when connections fail momentarily.
P2P流量通常由遥控器和墙壁控制器生成，这些控制器将控制消息直接推送到光源或热源。P2P流量对低延迟有严格的要求，因为P2P流量通常携带由人类调用的应用程序消息。如第2.2.1节所述，应用程序消息应该在几百毫秒内传递，即使连接暂时失败。
This paradigm translates to a device sending a message as many times as there are destination devices. Peer-to-Multipeer (P2MP) traffic is common in home and building automation networks. Often, a thermostat in a living room responds to temperature changes by sending temperature acquisitions to several fans and valves consecutively. This paradigm is also closely related to the PS paradigm in the case where a single server device has multiple subscribers.
这个范例转化为一个设备发送消息的次数与目标设备的发送次数相同。点对多点（P2MP）通信在家庭和楼宇自动化网络中很常见。通常，客厅中的恒温器通过连续向多个风扇和阀门发送温度采集数据来响应温度变化。在单个服务器设备具有多个订阅者的情况下，此范例也与PS范例密切相关。
This paradigm translates to a device sending a message to many destinations in one network transfer invocation. Multicast is well suited for lighting where a presence sensor sends a presence message to a set of lighting devices. Multicast increases the probability that the message is delivered within strict time constraints. The recommended multicast algorithm (e.g., [RFC7731]) provides a mechanism for delivering messages to all intended destinations.
此范例转换为一个设备在一次网络传输调用中向多个目的地发送消息。多播非常适合于存在传感器向一组照明设备发送存在信息的照明。多播增加了在严格的时间限制内传递消息的概率。推荐的多播算法（例如，[RFC7731]）提供了将消息传递到所有预期目的地的机制。
In the case of the SS paradigm applied to a wireless subnetwork to a server reachable via a border router, the use of RPL [RFC6550] in non-storing mode is appropriate. Given the low resources of the devices, source routing will be used from the border router to the destination in the wireless subnetwork for messages generated outside the mesh network. No specific timing constraints are associated with the SS-type messages, so network repair does not violate the operational constraints. When no SS traffic takes place, it is good practice to load only RPL code that enables the P2P mode of operation [RFC6997] to reduce the code size and satisfy memory requirements.
在SS范例应用于无线子网到可通过边界路由器到达的服务器的情况下，在非存储模式下使用RPL[RFC6550]是合适的。鉴于设备的资源较低，将使用从边界路由器到无线子网中的目的地的源路由，以便在网状网络之外生成消息。SS类型消息没有特定的定时约束，因此网络修复不会违反操作约束。当没有SS流量发生时，最好只加载RPL代码，从而启用P2P操作模式[RFC6997]，以减少代码大小并满足内存需求。
To assure responsiveness, P2P-RPL [RFC6997] is required for all P2P and P2MP traffic taking place between nodes within a wireless subnetwork (excluding the border router). Source and destination devices are typically physically close, based on room layout. Consequently, most P2P and P2MP traffic is one-hop or two-hop traffic. Appendix A identifies shortcomings of using RPL for this type of communication; these shortcomings are counteracted through the use of P2P-RPL. Appendix B explains why reliability measures such as multipath routing are necessary even when one-hop communication dominates.
为确保响应性，无线子网（不包括边界路由器）内节点之间发生的所有P2P和P2MP流量都需要P2P-RPL[RFC6997]。根据房间布局，源设备和目标设备通常在物理上接近。因此，大多数P2P和P2MP流量是一跳或两跳流量。附录A确定了使用RPL进行此类通信的缺点；这些缺点通过使用P2P-RPL得到了弥补。附录B解释了为什么即使在单跳通信占主导地位的情况下，也必须采取可靠性措施，如多路径路由。
Examples of additional advantages of P2P-RPL for home and building automation networks are as follows:
P2P-RPL用于家庭和楼宇自动化网络的其他优势示例如下：
o Individual wall switches are typically inexpensive Class 0 devices [RFC7228] with extremely low memory capacities. Multi-purpose remote controls for use in a home environment typically have more memory, but such devices are asleep when there is no user activity. P2P-RPL reactive discovery allows a node to wake up and find new routes within a few seconds, while memory-constrained nodes only have to keep routes to relevant targets.
o 单个墙壁开关通常是价格低廉的0级设备[RFC7228]，具有极低的内存容量。家庭环境中使用的多用途遥控器通常具有更多内存，但当没有用户活动时，此类设备处于休眠状态。P2P-RPL反应式发现允许节点在几秒钟内醒来并找到新路由，而内存受限的节点只需保留到相关目标的路由。
o The reactive discovery features of P2P-RPL ensure that commands are normally delivered within the 250 ms time window. When connectivity needs to be restored, discovery is typically completed within seconds. In most cases, an alternative route (a route that was discovered earlier) will work and route rediscovery is not necessary.
o P2P-RPL的反应式发现功能确保命令通常在250毫秒的时间窗口内发送。当需要恢复连接时，发现通常在几秒钟内完成。在大多数情况下，备用路由（先前发现的路由）将起作用，无需重新发现路由。
o Broadcast storms typically associated with route discovery for the Ad hoc On-Demand Distance Vector (AODV) [RFC3561] are less disruptive for P2P-RPL. P2P-RPL has a "Stop" bit, which is set by the target of a route discovery to notify all other nodes that no more Destination-Oriented Directed Acyclic Graph (DODAG) Information Object (DIO) messages should be forwarded for this temporary DAG. Something that looks like a broadcast storm may happen when no target is responding; however, in this case, the Trickle suppression mechanism kicks in, limiting the number of DIO forwards in dense networks.
o 通常与特定按需距离向量（AODV）[RFC3561]的路由发现相关联的广播风暴对P2P-RPL的破坏性较小。P2P-RPL有一个“停止”位，该位由路由发现的目标设置，以通知所有其他节点不再为该临时DAG转发面向目的地的有向无环图（DODAG）信息对象（DIO）消息。当没有目标响应时，可能会发生类似广播风暴的事情；然而，在这种情况下，涓流抑制机制起作用，限制密集网络中DIO转发的数量。
Due to the limited memory of the majority of devices, P2P-RPL SHOULD be deployed with source routing in non-storing mode, as explained in Section 4.1.2.
由于大多数设备的内存有限，如第4.1.2节所述，P2P-RPL应在非存储模式下与源路由一起部署。
Multicast with the Multicast Protocol for Low-Power and Lossy Networks (MPL) [RFC7731] is preferably deployed for N-cast over the wireless network. Configuration constraints that are necessary to meet reliability and timeliness with MPL are discussed in Section 4.1.7.
具有用于低功率和有损网络的多播协议（MPL）[RFC7731]的多播优选地部署用于无线网络上的N-cast。第4.1.7节讨论了满足MPL可靠性和及时性所需的配置约束。
This document applies to [IEEE802.15.4] and [G.9959], which are adapted to IPv6 by the adaptation layers [RFC4944] and [RFC7428]. Other Layer 2 technologies, accompanied by an "IP-over-Foo" specification, are also relevant, provided there is no frame size issue and there are link-layer acknowledgements.
本文件适用于[IEEE802.15.4]和[G.9959]，它们通过适配层[RFC4944]和[RFC7428]适配到IPv6。其他第2层技术以及“IP over Foo”规范也与此相关，前提是不存在帧大小问题，并且存在链路层确认。
The above-mentioned adaptation layers leverage on the compression capabilities of [RFC6554] and [RFC6282]. Header compression allows small IP packets to fit into a single Layer 2 frame, even when source routing is used. A network diameter limited to five hops helps to achieve this, even while using source routing.
上述适配层利用[RFC6554]和[RFC6282]的压缩能力。报头压缩允许将小IP数据包放入单个第2层帧中，即使在使用源路由时也是如此。即使在使用源路由时，网络直径限制为五跳也有助于实现这一点。
Dropped packets are often experienced in the targeted environments. Internet Control Message Protocol (ICMP), User Datagram Protocol (UDP), and even Transmission Control Protocol (TCP) flows may benefit from link-layer unicast acknowledgements and retransmissions. Link-layer unicast acknowledgements SHOULD be enabled when [IEEE802.15.4] or [G.9959] is used with RPL and P2P-RPL.
丢弃的数据包通常在目标环境中出现。Internet控制消息协议（ICMP）、用户数据报协议（UDP）甚至传输控制协议（TCP）流可能受益于链路层单播确认和重传。当[IEEE802.15.4]或[G.9959]与RPL和P2P-RPL一起使用时，应启用链路层单播确认。
Several features required by [RFC5826] and [RFC5867] challenge the P2P paths provided by RPL. Appendix A reviews these challenges. In some cases, a node may need to spontaneously initiate the discovery of a path towards a desired destination that is neither the root of a DAG nor a destination originating Destination Advertisement Object (DAO) signaling. Furthermore, P2P paths provided by RPL are not satisfactory in all cases because they involve too many intermediate nodes before reaching the destination.
[RFC5826]和[RFC5867]所需的几个特性对RPL提供的P2P路径提出了挑战。附录A回顾了这些挑战。在一些情况下，节点可能需要自发地发起到既不是DAG的根也不是目的地发起目的地广告对象（DAO）信令的期望目的地的路径的发现。此外，RPL提供的P2P路径在所有情况下都不令人满意，因为它们在到达目的地之前涉及太多的中间节点。
P2P-RPL [RFC6997] SHOULD be used in home automation and building control networks, as traffic of a point-to-point style is substantial and route repair needs to be completed within seconds. P2P-RPL provides a reactive mechanism for quick, efficient, and root-independent route discovery/repair. The use of P2P-RPL furthermore allows data traffic to avoid having to go through a central region around the root of the tree and drastically reduces path length [SOFT11] [INTEROP12]. These characteristics are desirable in home and building automation networks because they substantially decrease unnecessary network congestion around the root of the tree.
P2P-RPL[RFC6997]应用于家庭自动化和楼宇控制网络，因为点对点的通信量很大，路由修复需要在几秒钟内完成。P2P-RPL为快速、高效和根独立的路由发现/修复提供了一种反应机制。P2P-RPL的使用还允许数据流量避免通过树根周围的中心区域，并大幅减少路径长度[SOFT11][INTEROP12]。这些特性在家庭和楼宇自动化网络中是可取的，因为它们大大减少了树根周围不必要的网络拥塞。
When more reliability is required, P2P-RPL enables the establishment of multiple independent paths. For one-hop destinations, this means that one one-hop communication and a second two-hop communication take place via a neighboring node. Such a pair of redundant communication paths can be achieved by using MPL, where the source is an MPL Forwarder while a second MPL Forwarder is one hop away from both the source and the destination node. When the source multicasts the message, it may be received by both the destination and the second MPL Forwarder. The second MPL Forwarder forwards the message to the destination, thus providing two routes from sender to destination.
当需要更高的可靠性时，P2P-RPL支持建立多条独立路径。对于单跳目的地，这意味着通过相邻节点进行一个单跳通信和第二个两跳通信。这样一对冗余通信路径可以通过使用MPL来实现，其中源是MPL转发器，而第二个MPL转发器距离源节点和目的节点都一跳。当源多播消息时，目的地和第二个MPL转发器都可以接收该消息。第二个MPL转发器将消息转发到目的地，从而提供从发送方到目的地的两条路由。
To provide more reliability with multiple paths, P2P-RPL can maintain two independent P2P source routes per destination, at the source. Good practice is to use the paths alternately to assess their existence. When one P2P path has failed (possibly only temporarily), as described in Appendix B, the alternative P2P path can be used without discarding the failed path. The failed P2P path, unless proven to work again, can be safely discarded after a timeout (typically 15 minutes). A new route discovery is done when the number of P2P paths is exhausted due to persistent link failures.
为了在多条路径上提供更高的可靠性，P2P-RPL可以在源位置为每个目的地维护两个独立的P2P源路由。好的做法是交替使用路径来评估它们的存在。如附录B所述，当一条P2P路径出现故障（可能只是暂时出现故障）时，可以使用替代P2P路径，而无需丢弃故障路径。失败的P2P路径，除非再次证明有效，可以在超时（通常为15分钟）后安全丢弃。当由于持续链路故障而耗尽P2P路径数时，将执行新的路由发现。
P2P-RPL SHOULD be used in home automation and building control networks. Its reactive discovery allows for low application response times, even when on-the-fly route repair is needed. Non-storing mode SHOULD be used to reduce memory consumption in repeaters with constrained memory when source routing is used.
P2P-RPL应用于家庭自动化和楼宇控制网络。它的反应式发现允许较低的应用程序响应时间，即使在需要实时修复时也是如此。当使用源路由时，在内存受限的中继器中，应使用非存储模式来减少内存消耗。
An important constraint on the application of RPL is the presence of sleeping nodes.
RPL应用的一个重要限制是睡眠节点的存在。
For example, in a stand-alone network, the master node (or coordinator) providing the logical Layer 2 identifier and unique node identifiers to connected nodes may be a remote control that returns to sleep once new nodes have been added. Due to the absence of the border router, there may be no global routable prefixes at all. Likewise, there may be no authoritative always-on root node, since there is no border router to host this function.
例如，在独立网络中，向连接的节点提供逻辑层2标识符和唯一节点标识符的主节点（或协调器）可以是在添加新节点后返回睡眠的远程控制。由于没有边界路由器，可能根本没有全局可路由前缀。同样，根节点上可能没有权威的“始终在”节点，因为没有边界路由器来承载此功能。
In a network with a border router and many sleeping nodes, there may be battery-powered sensors and wall controllers configured to contact other nodes in response to events and then return to sleep. Such nodes may never detect the announcement of new prefixes via multicast.
在具有边界路由器和许多休眠节点的网络中，可能存在电池供电的传感器和墙壁控制器，这些传感器和控制器配置为与其他节点联系以响应事件，然后返回休眠状态。这样的节点可能永远不会通过多播检测到新前缀的宣布。
In each of the above-mentioned constrained deployments, a link-layer node (e.g., coordinator or master) SHOULD assume the role of an authoritative root node, transmitting unicast Router Advertisement (RA) messages with a Unique Local Address (ULA) prefix information option to nodes during the joining process to prepare the nodes for a later operational phase, where a border router is added.
在上述每个受限部署中，链路层节点（例如，协调器或主节点）应承担权威根节点的角色，用唯一本地地址（ULA）发送单播路由器广告（RA）消息在加入过程中为节点添加前缀信息选项，以便为添加边界路由器的后续操作阶段准备节点。
A border router SHOULD be designed to be aware of sleeping nodes in order to support the distribution of updated global prefixes to such sleeping nodes.
边界路由器应设计为能够感知休眠节点，以便支持向此类休眠节点分发更新的全局前缀。
When operating P2P-RPL on a stand-alone basis, there is no authoritative root node maintaining a permanent RPL DODAG. A node MUST be able to join at least one RPL Instance, as a new, temporary instance is created during each P2P-RPL route discovery operation. A node MAY be designed to join multiple RPL Instances.
在独立运行P2P-RPL时，没有维护永久RPL DODAG的权威根节点。节点必须能够加入至少一个RPL实例，因为在每个P2P-RPL路由发现操作期间会创建一个新的临时实例。一个节点可以设计为连接多个RPL实例。
Non-storing mode MUST be used to cope with the extremely constrained memory of a majority of nodes in the network (such as individual light switches).
必须使用非存储模式来处理网络中大多数节点（如单独的灯开关）的极为有限的内存。
Nodes send DAO messages to establish downward paths from the root to themselves. In order to minimize the power consumption overhead associated with path discovery, DAO messages are not acknowledged in networks composed of battery-operated field devices. The DAO messages build up a source route because the nodes MUST be in non-storing mode.
节点发送DAO消息以建立从根到自身的向下路径。为了最小化与路径发现相关的功耗开销，DAO消息在由电池操作的现场设备组成的网络中不被确认。DAO消息建立了一个源路由，因为节点必须处于非存储模式。
If devices in LLNs participate in multiple RPL Instances and DODAGs, both the RPLInstance ID and the DODAGID SHOULD be included in the DAO.
如果LLN中的设备参与多个RPL实例和DoDAG，则RPLINInstance ID和DODAGID都应包含在DAO中。
Expected Transmission Count (ETX) is the RECOMMENDED metric. [RFC6551] provides other options.
预期传输计数（ETX）是建议的指标。[RFC6551]提供了其他选项。
Packets from asymmetric and/or unstable links SHOULD be deleted at Layer 2.
来自非对称和/或不稳定链路的数据包应在第2层删除。
Objective Function Zero (OF0) [RFC6552] MUST be the Objective Function. Other Objective Functions MAY be used when dictated by circumstances.
目标函数0（OF0）[RFC6552]必须是目标函数。当环境要求时，可使用其他目标函数。
Since P2P-RPL only creates DODAGs on a temporary basis during route repair or route discovery, there is no need to repair DODAGs.
由于P2P-RPL仅在路由修复或路由发现期间临时创建DoDAG，因此无需修复DoDAG。
For SS traffic, local repair is sufficient. The accompanying process is known as "poisoning" and is described in Section 8.2.2.5 of [RFC6550]. Given that the majority of nodes in the building do not physically move around, creating new DODAGs should not happen frequently.
对于SS交通，局部维修就足够了。伴随的过程称为“中毒”，并在[RFC6550]第8.2.2.5节中描述。考虑到建筑物中的大多数节点不会在物理上移动，创建新的DoDAG不应该频繁发生。
Commercial lighting deployments may have a need for multicast to distribute commands to a group of lights in a timely fashion. Several mechanisms exist for achieving such functionality; [RFC7731] is the RECOMMENDED protocol for home and building deployments. This section relies heavily on the conclusions of [RT-MPL].
商业照明部署可能需要多播，以便及时将命令分发给一组照明设备。有几种机制可实现这种功能；[RFC7731]是家庭和建筑部署的推荐协议。本节主要依赖于[RT-MPL]的结论。
At reception of a packet, the MPL Forwarder starts a series of consecutive Trickle timer intervals, where the first interval has a minimum size of Imin. Each consecutive interval is twice as long as the former, with a maximum value of Imax. There is a maximum number of intervals given by max_expiration. For each interval of length I, a time t is randomly chosen in the period [I/2, I]. For a given packet, p, MPL counts the number of times it receives p during the period [0, t] in a counter c. At time t, MPL rebroadcasts p when c < k, where k is a predefined constant with a value k > 0.
在接收到分组时，MPL转发器启动一系列连续的涓流定时器间隔，其中第一个间隔的最小大小为Imin。每个连续间隔的长度是前者的两倍，最大值为Imax。max_expiration给出了最大间隔数。对于长度I的每个间隔，在周期[I/2，I]中随机选择时间t。对于给定的分组p，MPL在计数器c中的周期[0，t]内统计它接收p的次数。在时间t，MPL在c<k时重播p，其中k是值k>0的预定义常数。
The density of forwarders and the frequency of message generation are important aspects to obtain timeliness during control operations. A high frequency of message generation can be expected when a remote-control button is incessantly pressed or when alarm situations arise.
转发器的密度和消息生成的频率是在控制操作期间获得及时性的重要方面。持续按下遥控按钮或出现报警情况时，可能会产生高频率的信息。
Guaranteeing timeliness is intimately related to the density of the MPL routers. In ideal circumstances, the message is propagated as a single wave through the network, such that the maximum delay is related to the number of hops times the smallest repetition interval of MPL. Each forwarder that receives the message passes the message on to the next hop by repeating the message. When several copies of a message reach the forwarder, it is specified that the copy need not
保证及时性与MPL路由器的密度密切相关。在理想情况下，消息以单波形式通过网络传播，因此最大延迟与跳数乘以MPL的最小重复间隔有关。接收消息的每个转发器通过重复消息将消息传递到下一个跃点。当邮件的多个副本到达转发器时，指定不需要该副本
be repeated. Repetition of the message can be inhibited by a small value of k. To assure timeliness, the chosen value of k should be high enough to make sure that messages are repeated at the first arrival of the message in the forwarder. However, a network that is too dense leads to a saturation of the medium that can only be prevented by selecting a low value of k. Consequently, timeliness is assured by choosing a relatively high value of k but assuring at the same time a low enough density of forwarders to reduce the risk of medium saturation. Depending on the reliability of the network links, it is advisable to configure the density of the network such that at least two forwarders per hop repeat messages to the same set of destinations.
重复一遍。消息的重复可以通过较小的k值来抑制。为确保及时性，所选的k值应足够高，以确保消息在转发器中首次到达时重复。但是，密度过大的网络会导致介质饱和，只有选择较低的k值才能防止饱和。因此，通过选择相对较高的k值来确保及时性，但同时确保足够低的货代密度，以降低介质饱和的风险。根据网络链路的可靠性，建议配置网络密度，以使每跳至少两个转发器将消息重复到同一组目的地。
There are no rules about selecting forwarders for MPL. In buildings with central management tools, the forwarders can be selected, but at the time of this writing it is not possible to automatically configure the forwarder topology in the home.
没有关于为MPL选择转发器的规则。在具有中央管理工具的建筑物中，可以选择转发器，但在撰写本文时，无法在家中自动配置转发器拓扑。
RPL MAY use unsecured RPL messages to reduce message size. If there is a single node that uses unsecured RPL messages, link-layer security MUST be used on all nodes. Therefore, all RPL messages MUST be secured using:
RPL可能会使用不安全的RPL消息来减少消息大小。如果有一个节点使用不安全的RPL消息，则必须在所有节点上使用链路层安全性。因此，必须使用以下方法保护所有RPL消息：
o RPL message security, or
o RPL消息安全性，或
o Link-layer security, or
o 链路层安全，或
o Both RPL message security and link-layer security
o RPL消息安全性和链路层安全性
A symmetric key is used to secure a RPL message using either RPL message security or link-layer security. The symmetric key MUST be distributed or established in a secure fashion. There may be more than one symmetric key in use by any node at any one time. The same symmetric key MUST NOT be used for both RPL message security and link-layer security between two peer nodes.
对称密钥用于使用RPL消息安全性或链路层安全性保护RPL消息。必须以安全的方式分发或建立对称密钥。任何节点在任何时间都可能使用多个对称密钥。两个对等节点之间的RPL消息安全性和链路层安全性不得使用相同的对称密钥。
The scope of symmetric key distribution MUST be no greater than the network itself, i.e., a group key. This document describes what needs to be implemented to meet this requirement. The scope of symmetric key distribution MAY be smaller than the network -- for example:
对称密钥分发的范围不得大于网络本身，即组密钥。本文件描述了满足此要求需要实施的内容。对称密钥分发的范围可能小于网络，例如：
o A pairwise symmetric key between two peers.
o 两个对等方之间的成对对称密钥。
o A group key shared between a subset of nodes in the network.
o 网络中节点子集之间共享的组密钥。
The authentication mechanism as described in Section 6.9 of [ZigBeeIP] SHALL be used to securely distribute a network-wide symmetric key.
[ZigBeeIP]第6.9节所述的认证机制应用于安全分发网络范围的对称密钥。
The purpose of the authentication procedure is to provide mutual authentication resulting in:
认证程序的目的是提供相互认证，从而：
o Preventing untrusted nodes without appropriate credentials from joining the trusted network.
o 防止没有适当凭据的不受信任节点加入受信任网络。
o Preventing trusted nodes with appropriate credentials from joining an untrusted network.
o 阻止具有适当凭据的受信任节点加入不受信任的网络。
There is an Authentication Server, which is responsible for authenticating the nodes on the network. If the authentication is successful, the Authentication Server sends the network security material to the joining node through the Protocol for Carrying Authentication for Network Access (PANA) [RFC5191] [RFC6345]. The joining node becomes a full participating node in the network and is able to apply Layer 2 security to RPL messages using the distributed network key.
有一个身份验证服务器，负责对网络上的节点进行身份验证。如果身份验证成功，则身份验证服务器通过承载网络访问身份验证协议（PANA）[RFC5191][RFC6345]向加入节点发送网络安全材料。加入节点成为网络中的完全参与节点，并且能够使用分布式网络密钥对RPL消息应用第2层安全性。
The joining node does not initially have access to the network security material. Therefore, it is not able to apply Layer 2 security to the packets exchanged during the authentication process. The enforcement point rules at the edge of the network ensure that the packets involved in PANA authentication are processed even though they are unsecured at the Medium Access Control (MAC) layer. The rules also ensure that any other incoming traffic that is not secured at the MAC layer is discarded and is not forwarded.
加入节点最初无权访问网络安全资料。因此，它不能将第2层安全性应用于在认证过程中交换的分组。网络边缘的强制点规则确保处理PANA身份验证中涉及的数据包，即使这些数据包在介质访问控制（MAC）层是不安全的。这些规则还确保在MAC层不安全的任何其他传入流量被丢弃，并且不会被转发。
Authentication can be viewed as a protocol stack as a layer encapsulates the layers above it.
身份验证可以看作是一个协议栈，因为一个层封装了它上面的层。
o Transport Layer Security (TLS) [RFC5246] MUST be used at the highest layer of the authentication stack and carries the authentication exchange. There is one cipher suite based on a Pre-Shared Key (PSK) [RFC6655] and one cipher suite based on Elliptic Curve Cryptography (ECC) [RFC7251].
o 传输层安全性（TLS）[RFC5246]必须在身份验证堆栈的最高层使用，并承载身份验证交换。有一个基于预共享密钥（PSK）[RFC6655]的密码套件和一个基于椭圆曲线密码（ECC）[RFC7251]的密码套件。
o Extensible Authentication Protocol-TLS (EAP-TLS) [RFC5216] MUST be used at the next layer to carry the TLS records for the authentication protocol.
o 下一层必须使用可扩展身份验证协议TLS（EAP-TLS）[RFC5216]来承载身份验证协议的TLS记录。
o EAP [RFC3748] MUST be used to provide the mechanisms for mutual authentication. EAP requires a way to transport EAP packets between the joining node and the node on which the Authentication Server resides. These nodes are not necessarily in radio range of each other, so it is necessary to have multi-hop support in the EAP transport method. PANA [RFC5191] [RFC6345], which operates over UDP, MUST be used for this purpose. [RFC3748] specifies the derivation of a session key using the EAP key hierarchy; only the EAP Master Session Key shall be derived, as [RFC5191] specifies that it is used to set up keys for PANA authentication and encryption.
o EAP[RFC3748]必须用于提供相互认证的机制。EAP需要一种在加入节点和身份验证服务器所在节点之间传输EAP数据包的方法。这些节点不一定在彼此的无线电范围内，因此在EAP传输方法中有必要具有多跳支持。为此，必须使用通过UDP操作的PANA[RFC5191][RFC6345]。[RFC3748]使用EAP密钥层次结构指定会话密钥的派生；只能导出EAP主会话密钥，因为[RFC5191]指定它用于设置PANA身份验证和加密密钥。
o PANA [RFC5191] and a PANA relay [RFC6345] MUST be used at the next layer:
o 必须在下一层使用PANA[RFC5191]和PANA继电器[RFC6345]：
* The joining node MUST act as the PANA Client (PaC).
* 加入节点必须充当PANA客户端（PaC）。
* The parent edge router node MUST act as a PANA Relay Element (PRE) according to [RFC6345], unless it is also the Authentication Server. All routers at the edge of the network MUST be capable of functioning in the PRE role.
* 根据[RFC6345]，父边缘路由器节点必须充当PANA中继元素（PRE），除非它也是身份验证服务器。网络边缘的所有路由器必须能够在PRE角色中运行。
* The Authentication Server node MUST act as the PANA Authentication Agent (PAA). The Authentication Server MUST be able to handle packets relayed according to [RFC6345].
* 身份验证服务器节点必须充当PANA身份验证代理（PAA）。认证服务器必须能够处理根据[RFC6345]转发的数据包。
This network authentication process uses link-local IPv6 addresses for transport between the new node and its parent. If the parent is not the Authentication Server, it MUST then relay packets from the joining node to the Authentication Server and vice versa, using the PANA relay mechanism [RFC6345]. The joining node MUST use a link-local address based on its EUI-64 as the source address for initial PANA authentication message exchanges.
此网络身份验证过程使用链路本地IPv6地址在新节点及其父节点之间进行传输。如果父节点不是身份验证服务器，则必须使用PANA中继机制[RFC6345]将数据包从加入节点中继到身份验证服务器，反之亦然。加入节点必须使用基于其EUI-64的链路本地地址作为初始PANA身份验证消息交换的源地址。
The following applicability statements describe the relationship between the various specifications.
以下适用性声明描述了各种规范之间的关系。
[RFC6655] contains Authenticated Encryption with Associated Data (AEAD) TLS cipher suites that are very similar to [RFC5487], whose AEAD part is detailed in [RFC5116]. [RFC5487] references both [RFC5288] and the original PSK cipher suite document [RFC4279], which references RFC 2246, which was eventually replaced by [RFC5246], which defines the TLS 1.2 messages.
[RFC6655]包含与[RFC5487]非常相似的带有关联数据（AEAD）的认证加密TLS密码套件，其AEAD部分在[RFC5116]中有详细说明。[RFC5487]引用了[RFC5288]和原始PSK密码套件文档[RFC4279]，其中引用了RFC 2246，最终被定义TLS 1.2消息的[RFC5246]取代。
[RFC7251] contains AEAD TLS cipher suites that are very similar to [RFC5289], whose AEAD part is detailed in [RFC5116]. [RFC5289] references the original ECC cipher suite document [RFC4492], which references RFC 2246, which was eventually replaced by [RFC5246], which defines the TLS 1.2 messages.
[RFC7251]包含与[RFC5289]非常相似的AEAD TLS密码套件，其AEAD部分详见[RFC5116]。[RFC5289]引用了原始ECC密码套件文档[RFC4492]，该文档引用了RFC 2246，最终被定义TLS 1.2消息的[RFC5246]所取代。
[RFC5216] specifies how [RFC3748] is used to package [RFC5246] TLS records into EAP packets. [RFC5191] provides transportation for the EAP packets and the network-wide key carried in an encrypted Attribute-Value Pair (AVP) as specified in [RFC6786]. The proposed Pseudorandom Function (PRF) and authentication (AUTH) hashes based on SHA-256 are represented as specified in [RFC7296] and detailed in [RFC4868].
[RFC5216]指定如何使用[RFC3748]将[RFC5246]TLS记录打包到EAP数据包中。[RFC5191]为EAP数据包和在[RFC6786]中指定的加密属性值对（AVP）中携带的网络范围密钥提供传输。建议的基于SHA-256的伪随机函数（PRF）和身份验证（AUTH）散列如[RFC7296]所述，并在[RFC4868]中详细说明。
If RPL is used with secured messages [RFC6550], the following RPL security parameter values SHOULD be used:
如果RPL与安全消息[RFC6550]一起使用，则应使用以下RPL安全参数值：
o Counter is Time (T) flag = 0: Do not use the timestamp in the Counter field. Counters based on timestamps are typically more applicable to industrial networks, where strict timing synchronization between nodes is often implemented. Home and building networks typically do not implement such strict timing synchronization; therefore, a monotonically increasing counter is more appropriate.
o 计数器是时间（T）标志=0：不要在计数器字段中使用时间戳。基于时间戳的计数器通常更适用于工业网络，其中通常在节点之间实现严格的定时同步。家庭和楼宇网络通常不实现这种严格的定时同步；因此，单调递增计数器更合适。
o Algorithm = 0: Use Counter with the Cipher Block Chaining Message Authentication Code (CBC-MAC Mode) (CCM) with AES-128. This is the only assigned mode at present.
o 算法=0：将计数器与密码块链接消息身份验证码（CBC-MAC模式）（CCM）一起使用AES-128。这是目前唯一指定的模式。
o Key Identifier Mode (KIM) = 10: Use a group key, Key Source present, and Key Index present. Given the relatively confined perimeter of a home or building network, a group key is usually sufficient to protect RPL messages sent between nodes. The use of the Key Source field allows multiple group keys to be used within the network.
o 密钥标识符模式（KIM）=10：使用组密钥、密钥源和密钥索引。考虑到家庭或建筑网络相对受限的周界，组密钥通常足以保护节点之间发送的RPL消息。密钥源字段的使用允许在网络中使用多个组密钥。
o Security Level (LVL) = 0: Use MAC-32. This is recommended, as integrity protection for RPL messages is the basic requirement. Encryption is unlikely to be necessary, given the relatively non-confidential nature of RPL message payloads.
o 安全级别（LVL）=0：使用MAC-32。建议这样做，因为RPL消息的完整性保护是基本要求。鉴于RPL消息有效负载的相对非机密性，不太可能需要加密。
[RFC6997] MUST be used to accommodate P2P traffic, which is typically substantial in home and building automation networks.
[RFC6997]必须用于容纳P2P流量，这在家庭和楼宇自动化网络中通常非常重要。
Assigned IP addresses MUST be routable and unique within the routing domain [RFC5889].
分配的IP地址必须在路由域[RFC5889]内可路由且唯一。
No particular requirements exist for Layer 2, except for those cited in the "IP-over-Foo" RFCs (see Section 2.3).
第2层无特殊要求，但“IP over Foo”RFC中引用的要求除外（见第2.3节）。
Not applicable
不适用
Not applicable
不适用
4.2.3. IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Options Assumed
4.2.3. 假设采用低功耗无线个人区域网（6LoWPAN）上的IPv6选项
Not applicable
不适用
Not applicable
不适用
The following sections describe the recommended parameter values for P2P-RPL and Trickle.
以下各节介绍了P2P-RPL和涓流的建议参数值。
Trickle is used to distribute network parameter values to all nodes without stringent time restrictions. The recommended Trickle parameter values are:
涓流用于将网络参数值分发到所有节点，无需严格的时间限制。建议的涓流参数值为：
o DIOIntervalMin 4, which translates to 16 ms
o DIOIntervalMin 4，翻译为16毫秒
o DIOIntervalDoublings 14
o 迪奥瓦多布林14
o DIORedundancyConstant 1
o 双余度常数1
When a node sends a changed DIO, this is an inconsistency and forces the receiving node to respond within Imin. So, when something happens that affects the DIO, the change is ideally communicated to a node that is n hops away, within n times Imin. Often, depending on the node density, packets are lost or are not sent, leading to larger delays.
当一个节点发送一个更改的DIO时，这是一个不一致性，并迫使接收节点在Imin内响应。因此，当发生影响DIO的事情时，理想情况下，该变化会在n次Imin内传递到一个距离为n跳的节点。通常，根据节点密度，数据包丢失或不发送，导致更大的延迟。
In general, we can expect DIO changes to propagate within 1 to 3 seconds within the envisaged networks.
一般来说，我们可以期望DIO更改在设想的网络中在1到3秒内传播。
When nothing happens, the DIO sending interval increases to 4.37 minutes, thus drastically reducing the network load. When a node does not receive DIO messages for more than 10 minutes, it can safely conclude that the connection with other nodes has been lost.
当什么也不发生时，DIO发送间隔将增加到4.37分钟，从而大大降低了网络负载。当一个节点没有收到DIO消息超过10分钟时，它可以安全地断定与其他节点的连接已丢失。
This section discusses the P2P-RPL parameters.
本节讨论P2P-RPL参数。
P2P-RPL [RFC6997] provides the features requested by [RFC5826] and [RFC5867]. P2P-RPL uses a subset of the frame formats and features defined for RPL [RFC6550] but may be combined with RPL frame flows in advanced deployments.
P2P-RPL[RFC6997]提供[RFC5826]和[RFC5867]所要求的功能。P2P-RPL使用为RPL[RFC6550]定义的帧格式和功能的子集，但可以在高级部署中与RPL帧流相结合。
The recommended parameter values for P2P-RPL are:
P2P-RPL的建议参数值为：
o MinHopRankIncrease 1
o MinHopRankIncrease 1
o MaxRankIncrease 0
o MaxRankIncrease 0
o MaxRank 6
o MaxRank 6
o Objective Function: OF0
o 目标函数：OF0
MPL is used to distribute values to groups of devices. Using MPL, based on the Trickle algorithm, timeliness should also be guaranteed. A deadline of 200 ms needs to be met when human action is followed by an immediately observable action such as switching on lights. The deadline needs to be met in a building where the number of hops from seed to destination varies between 1 and 10.
MPL用于将值分配给设备组。使用基于涓流算法的MPL，还应保证及时性。当人类活动之后紧接着一个可立即观察到的活动（如打开灯）时，需要满足200 ms的截止时间。在从种子到目的地的跳数在1到10之间变化的建筑中，需要满足最后期限。
When the network is heavily loaded, MAC delays contribute significantly to the end-to-end delays when MPL intervals between 10 and 100 ms are used to meet the 200 ms deadline. It is possible to set the number of buffers in the MAC to 1 and set the number of back-off repetitions to 1. The number of MPL repetitions compensates for the reduced probability of transmission per MAC invocation [RT-MPL].
当网络负载较重时，当使用10到100毫秒之间的MPL间隔来满足200毫秒的最后期限时，MAC延迟对端到端延迟有显著影响。可以将MAC中的缓冲区数量设置为1，并将后退重复次数设置为1。MPL重复的次数补偿了每次MAC调用传输概率的降低[RT-MPL]。
In addition, end-to-end delays and message losses are reduced by adding a real-time layer between MPL and MAC to throw away the earliest messages (exploiting the MPL message numbering) and favor the most recent ones.
此外，通过在MPL和MAC之间添加一个实时层来丢弃最早的消息（利用MPL消息编号）并偏爱最近的消息，可以减少端到端延迟和消息丢失。
This section proposes values for the Trickle parameters used by MPL for the distribution of packets that need to meet a 200 ms deadline. The probability of meeting the deadline is increased by (1) choosing a small Imin value, (2) reducing the number of MPL intervals, thus reducing the load, and (3) reducing the number of MPL Forwarders to also reduce the load.
本节提出MPL用于分发需要满足200毫秒截止时间的数据包的涓流参数值。通过（1）选择一个较小的Imin值，（2）减少MPL间隔的数量，从而减少负载，（3）减少MPL转发器的数量，从而也减少负载，可以提高满足最后期限的概率。
The consequence of this approach is that the value of k can be larger than 1 because network load reduction is already guaranteed by the network configuration.
这种方法的结果是k的值可以大于1，因为网络配置已经保证了网络负载的降低。
Under the condition that the density of MPL repeaters can be limited, it is possible to choose low MPL repeat intervals (Imin) connected to k values such that k > 1. The minimum value of k is related to:
在可以限制MPL中继器的密度的条件下，可以选择连接到k值的低MPL重复间隔（Imin），使得k>1。k的最小值与以下各项有关：
o The value of Imin. The length of Imin determines the number of packets that can be received within the listening period of Imin.
o Imin的价值。Imin的长度决定了在Imin的侦听周期内可以接收的数据包的数量。
o The number of repeaters receiving the broadcast message from the same forwarder or seed. These repeaters repeat within the same Imin interval, thus increasing the c counter.
o 从同一转发器或种子接收广播消息的中继器数。这些中继器在相同的Imin间隔内重复，从而增加c计数器。
Within the first MPL interval, a limited number, q, of messages can be transmitted. Assuming a 3 ms transmission interval, q is given by q = Imin / 3. Assuming that at most q message copies can reach a given forwarder within the first repeat interval of length Imin, the related MPL parameter values are suggested in the following sections.
在第一MPL间隔内，可以传输有限数量的消息q。假设传输间隔为3 ms，q由q=Imin/3给出。假设在长度为Imin的第一个重复间隔内，最多q个消息副本可以到达给定的转发器，相关MPL参数值将在以下部分中建议。
The recommended value is Imin = 10 to 50 ms.
建议值为Imin=10至50 ms。
When the chosen Imin value is much smaller, the interference between the copies leads to significant losses, given that q is much smaller than the number of repeated packets. With much larger intervals, the probability that the deadline will be met decreases with increasing hop count.
当选择的Imin值小得多时，如果q远小于重复数据包的数量，则拷贝之间的干扰会导致显著的损失。如果间隔更大，则满足截止日期的概率将随着跳数的增加而降低。
The recommended value is Imax = 100 to 400 ms.
建议值为Imax=100至400 ms。
The value of Imax is less important than the value of max_expiration. Given an Imin value of 10 ms, the third MPL interval has a value of 10 * 2 * 2 = 40 ms. When Imin has a value of 40 ms, the third interval has a value of 160 ms. Given that more than three intervals are unnecessary, Imax does not contribute much to performance.
Imax的值不如max\u expiration的值重要。如果Imin值为10 ms，则第三个MPL间隔的值为10*2*2=40 ms。如果Imin值为40 ms，则第三个间隔的值为160 ms。如果不需要三个以上的间隔，则Imax对性能的贡献不大。
Other parameters are the k parameter and the max_expiration parameter.
其他参数包括k参数和max_expiration参数。
k > q (see condition above). Under this condition, and for a small Imin value, a value of k = 2 or k = 3 is usually sufficient to minimize the losses of packets in the first repeat interval.
k>q（见上述条件）。在这种情况下，对于较小的Imin值，k＝2或k＝3的值通常足以最小化第一重复间隔中的分组丢失。
max_expiration = 2 - 4. Higher values lead to more network load while generating copies that will probably not meet their deadline.
最大有效期=2-4。较高的值会导致更多的网络负载，同时生成可能无法满足其截止日期要求的副本。
At this time, it is not clear how homenets will be managed. Consequently, it is not clear which tools will be used and which parameters must be visible for management.
目前还不清楚家庭网络将如何管理。因此，不清楚将使用哪些工具以及哪些参数必须对管理可见。
In building control, management is mandatory. It is expected that installations will be managed using the set of currently available tools (including IETF tools like Management Information Base (MIB) modules, Network Configuration Protocol (NETCONF) modules, Dynamic Host Configuration Protocol (DHCP), and others), with large differences between the ways an installation is managed.
在建筑物控制方面，管理是强制性的。预计将使用一组当前可用的工具（包括IETF工具，如管理信息库（MIB）模块、网络配置协议（NETCONF）模块、动态主机配置协议（DHCP）等）管理安装，管理安装的方式存在很大差异。
This section refers to the security considerations of [RFC6997], [RFC6550], and [RFC7731], as well as some attacks and countermeasures as discussed in Sections 6 and 7, respectively, of [RFC7416].
本节涉及[RFC6997]、[RFC6550]和[RFC7731]的安全注意事项，以及[RFC7416]第6节和第7节分别讨论的一些攻击和对策。
Communications network security is based on providing integrity protection and encryption to messages. This can be applied at various layers in the network protocol stack, based on using various credentials and a network identity.
通信网络安全基于对消息提供完整性保护和加密。基于使用各种凭证和网络标识，这可以应用于网络协议栈中的各个层。
The credentials that are relevant in the case of RPL are (i) the credential used at the link layer in the case where link-layer security is applied (see Section 7.1) or (ii) the credential used for securing RPL messages. In both cases, the assumption is that the credential is a shared key. Therefore, there MUST be a mechanism in place that allows secure distribution of a shared key and configuration of a network identity. Both MAY be done using (i) pre-installation using an out-of-band method, (ii) secure delivery when a device is introduced into the network, or (iii) secure delivery by a trusted neighboring device, as described in Section 4.1.8.1. The shared key MUST be stored in a secure fashion that will make it difficult to be read by an unauthorized party.
在RPL情况下相关的凭证是（i）在应用链路层安全性的情况下在链路层使用的凭证（参见第7.1节）或（ii）用于保护RPL消息的凭证。在这两种情况下，假设凭证是共享密钥。因此，必须有一种机制，允许安全分发共享密钥和配置网络标识。这两种方法都可以使用（i）使用带外方法进行预安装，（ii）将设备引入网络时的安全交付，或（iii）由受信任的相邻设备进行安全交付，如第4.1.8.1节所述。共享密钥必须以安全的方式存储，这将使未授权方难以读取。
This document mandates that a Layer 2 mechanism be used during initial and incremental deployment. Please see the following sections.
本文档要求在初始和增量部署期间使用第2层机制。请参阅以下章节。
Wireless mesh networks are typically secured at the link layer in order to prevent unauthorized parties from accessing the information exchanged over the links. It is a basic practice to create a network of nodes that share the same keys for link-layer security and exclude nodes sending unsecured messages. With per-message data origin authentication, it is possible to prevent unauthorized nodes from joining the mesh.
无线网状网络通常在链路层受到保护，以防止未经授权的方访问通过链路交换的信息。基本做法是创建一个节点网络，共享相同的密钥以实现链路层安全，并排除发送不安全消息的节点。通过每消息数据源身份验证，可以防止未经授权的节点加入网格。
At initial deployment, the network is secured by consecutively securing nodes at the link layer, thus building a network of secured nodes. Section 4.1.8.2 describes a mechanism for building a network of secured nodes.
在初始部署时，通过在链路层连续保护节点来保护网络，从而构建由安全节点组成的网络。第4.1.8.2节描述了构建安全节点网络的机制。
This document does not specify a multicast security solution. Networks deployed with this specification will depend upon Layer 2 security to prevent outsiders from sending multicast traffic. It is recognized that this does not protect this control traffic from impersonation by already-trusted devices. This is an area for a future specification.
本文档未指定多播安全解决方案。使用此规范部署的网络将依赖于第2层安全性，以防止外部人员发送多播流量。我们认识到，这并不能保护此控制流量不受已受信任设备的模拟。这是未来规范的一个领域。
For building control, an installer will use an installation tool that establishes a secure communication path with the joining node. It is recognized that the recommendations for initial deployment as discussed in this section do not cover all building requirements, such as selecting -- independent of network topology -- the node to be secured.
对于建筑控制，安装程序将使用一个安装工具，该工具将与加入节点建立一个安全的通信路径。我们认识到，本节中讨论的初始部署建议并不涵盖所有构建要求，例如选择要保护的节点（独立于网络拓扑）。
It is expected that a set of protocol combinations will evolve within currently existing alliances of building control manufacturers. Each set satisfies the installation requirements of installers, operators, and manufacturers of building control networks in a given installation context, e.g., lighting deployment in offices, HVAC installation, incremental addition of equipment in homes, and others.
预计一组协议组合将在当前建筑控制制造商的现有联盟中发展。每套设备满足给定安装环境下建筑控制网络安装人员、操作员和制造商的安装要求，例如办公室照明部署、HVAC安装、家庭设备增量添加等。
In the home, nodes can be visually inspected by the home owner. Also, a simple procedure, e.g., pushing buttons simultaneously on an already-secured device and an unsecured joining device, is usually sufficient to ensure that the unsecured joining device is authenticated securely, configured securely, and paired appropriately.
在家庭中，家庭所有者可以目视检查节点。此外，一个简单的过程，例如，在已经安全的设备和未安全的加入设备上同时按下按钮，通常足以确保未安全的加入设备被安全地认证、安全地配置和适当地配对。
This recommendation is in line with the countermeasures described in Section 7.1 of [RFC7416].
该建议符合[RFC7416]第7.1节中描述的对策。
Once a network is operational, new nodes need to be added, or nodes fail and need to be replaced. When a new node needs to be added to the network, the new node is added to the network via an assisting node in the manner described in Section 7.1.
网络运行后，需要添加新节点，或者节点出现故障，需要更换。当需要将新节点添加到网络中时，新节点通过辅助节点以第7.1节所述的方式添加到网络中。
On detection of a compromised node, all trusted nodes need to have their symmetric keys that are known to be shared with the compromised node rekeyed, and the trusted network is built up as described in Section 7.1.
在检测到受损节点时，所有受信任节点都需要将已知与受损节点共享的对称密钥重新加密，并按照第7.1节所述建立受信任网络。
Refer to the security considerations of [RFC6997].
请参阅[RFC6997]中的安全注意事项。
The routing of MPL is determined by the enabling of the interfaces for specified multicast addresses. The specification of these addresses can be done via a Constrained Application Protocol (CoAP) application as specified in [RFC7390]. An alternative is the creation of an MPL MIB and the use of the Simple Network Management Protocol (SNMPv3) [RFC3411] or equivalent techniques to specify the multicast addresses in the MIB. For secure dissemination of MPL packets, Layer 2 security SHOULD be used, and the configuration of multicast addresses as described in this section MUST be secure.
MPL的路由由指定多播地址的接口启用决定。这些地址的指定可通过[RFC7390]中规定的受限应用程序协议（CoAP）应用程序完成。另一种方法是创建MPL MIB，并使用简单网络管理协议（SNMPv3）[RFC3411]或等效技术来指定MIB中的多播地址。对于MPL数据包的安全分发，应使用第2层安全性，并且本节所述的多播地址配置必须是安全的。
This section refers to the structure of Section 8 ("RPL Security Features") of [RFC7416]. [RFC7416] provides a thorough analysis of security threats and proposed countermeasures relevant to RPL and MPL.
本节涉及[RFC7416]第8节（“RPL安全功能”）的结构。[RFC7416]全面分析了安全威胁，并提出了与RPL和MPL相关的应对措施。
In accordance with Section 8.1 ("Confidentiality Features") of [RFC7416], RPL message security implements payload protection, as explained in Section 7 of this document. The attributes for key length and lifetime of the keys depend on operational conditions, maintenance, and installation procedures.
根据[RFC7416]第8.1节（“保密特征”），RPL消息安全性实施有效负载保护，如本文件第7节所述。密钥长度和密钥寿命的属性取决于操作条件、维护和安装程序。
Sections 7.1 and 7.2 of this document recommend link-layer security to assure integrity in accordance with Section 8.2 ("Integrity Features") of [RFC7416].
根据[RFC7416]第8.2节（“完整性特征”），本文件第7.1节和第7.2节建议链路层安全，以确保完整性。
The provision of multiple paths recommended in Section 8.3 ("Availability Features") of [RFC7416] is also recommended from a reliability point of view. Randomly choosing paths MAY be supported.
从可靠性角度来看，还建议提供[RFC7416]第8.3节（“可用性特征”）中建议的多条路径。可能支持随机选择路径。
A mechanism for key management, as discussed in Section 8.4 ("Key Management") of [RFC7416], is provided in Section 4.1.8.2 of this document.
本文件第4.1.8.2节提供了[RFC7416]第8.4节（“密钥管理”）中讨论的密钥管理机制。
Application and transport protocols used in home and building automation domains are expected to mostly consist of CoAP over UDP, or equivalents. Typically, UDP is used for IP transport to keep down the application response time and bandwidth overhead. CoAP is used at the application layer to reduce memory footprint and bandwidth requirements.
家庭和楼宇自动化领域中使用的应用程序和传输协议预计主要由基于UDP的CoAP或等效协议组成。通常，UDP用于IP传输，以减少应用程序响应时间和带宽开销。CoAP用于应用层，以减少内存占用和带宽需求。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, <http://www.rfc-editor.org/info/rfc3748>.
[RFC3748]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，编辑，“可扩展身份验证协议（EAP）”，RFC 3748，DOI 10.17487/RFC3748，2004年6月<http://www.rfc-editor.org/info/rfc3748>.
[RFC4279] Eronen, P., Ed., and H. Tschofenig, Ed., "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, DOI 10.17487/RFC4279, December 2005, <http://www.rfc-editor.org/info/rfc4279>.
[RFC4279]Eronen，P.，Ed.，和H.Tschofenig，Ed.，“用于传输层安全（TLS）的预共享密钥密码套件”，RFC 4279，DOI 10.17487/RFC4279，2005年12月<http://www.rfc-editor.org/info/rfc4279>.
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, DOI 10.17487/RFC4492, May 2006, <http://www.rfc-editor.org/info/rfc4492>.
[RFC4492]Blake Wilson，S.，Bolyard，N.，Gupta，V.，Hawk，C.，和B.Moeller，“用于传输层安全（TLS）的椭圆曲线密码（ECC）密码套件”，RFC 4492，DOI 10.17487/RFC4492，2006年5月<http://www.rfc-editor.org/info/rfc4492>.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, DOI 10.17487/RFC4868, May 2007, <http://www.rfc-editor.org/info/rfc4868>.
[RFC4868]Kelly，S.和S.Frankel，“在IPsec中使用HMAC-SHA-256、HMAC-SHA-384和HMAC-SHA-512”，RFC 4868，DOI 10.17487/RFC4868，2007年5月<http://www.rfc-editor.org/info/rfc4868>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, <http://www.rfc-editor.org/info/rfc4944>.
[RFC4944]黑山，G.，Kushalnagar，N.，Hui，J.，和D.Culler，“通过IEEE 802.15.4网络传输IPv6数据包”，RFC 4944，DOI 10.17487/RFC4944，2007年9月<http://www.rfc-editor.org/info/rfc4944>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, <http://www.rfc-editor.org/info/rfc5116>.
[RFC5116]McGrew，D.“认证加密的接口和算法”，RFC 5116，DOI 10.17487/RFC5116，2008年1月<http://www.rfc-editor.org/info/rfc5116>.
[RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, May 2008, <http://www.rfc-editor.org/info/rfc5191>.
[RFC5191]Forsberg，D.，Ohba，Y.，Ed.，Patil，B.，Tschofenig，H.，和A.Yegin，“承载网络接入认证（PANA）的协议”，RFC 5191，DOI 10.17487/RFC5191，2008年5月<http://www.rfc-editor.org/info/rfc5191>.
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, March 2008, <http://www.rfc-editor.org/info/rfc5216>.
[RFC5216]Simon，D.，Aboba，B.和R.Hurst，“EAP-TLS认证协议”，RFC 5216，DOI 10.17487/RFC5216，2008年3月<http://www.rfc-editor.org/info/rfc5216>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, DOI 10.17487/RFC5288, August 2008, <http://www.rfc-editor.org/info/rfc5288>.
[RFC5288]Salowey，J.，Choudhury，A.，和D.McGrew，“用于TLS的AES伽罗瓦计数器模式（GCM）密码套件”，RFC 5288，DOI 10.17487/RFC5288，2008年8月<http://www.rfc-editor.org/info/rfc5288>.
[RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)", RFC 5289, DOI 10.17487/RFC5289, August 2008, <http://www.rfc-editor.org/info/rfc5289>.
[RFC5289]Rescorla，E.“具有SHA-256/384和AES伽罗瓦计数器模式（GCM）的TLS椭圆曲线密码套件”，RFC 5289，DOI 10.17487/RFC5289，2008年8月<http://www.rfc-editor.org/info/rfc5289>.
[RFC5487] Badra, M., "Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode", RFC 5487, DOI 10.17487/RFC5487, March 2009, <http://www.rfc-editor.org/info/rfc5487>.
[RFC5487]Badra，M.，“具有SHA-256/384和AES伽罗瓦计数器模式的TLS预共享密钥密码套件”，RFC 5487，DOI 10.17487/RFC5487，2009年3月<http://www.rfc-editor.org/info/rfc5487>.
[RFC5548] Dohler, M., Ed., Watteyne, T., Ed., Winter, T., Ed., and D. Barthel, Ed., "Routing Requirements for Urban Low-Power and Lossy Networks", RFC 5548, DOI 10.17487/RFC5548, May 2009, <http://www.rfc-editor.org/info/rfc5548>.
[RFC5548]Dohler，M.，Ed.，Watteyne，T.，Ed.，Winter，T.，Ed.，和D.Barthel，Ed.，“城市低功率和有损网络的路由要求”，RFC 5548，DOI 10.17487/RFC5548，2009年5月<http://www.rfc-editor.org/info/rfc5548>.
[RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T. Phinney, "Industrial Routing Requirements in Low-Power and Lossy Networks", RFC 5673, DOI 10.17487/RFC5673, October 2009, <http://www.rfc-editor.org/info/rfc5673>.
[RFC5673]Pister，K.，Ed.，Thubert，P.，Ed.，Dwars，S.，和T.Phinney，“低功率和有损网络中的工业路由要求”，RFC 5673，DOI 10.17487/RFC5673，2009年10月<http://www.rfc-editor.org/info/rfc5673>.
[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5826, DOI 10.17487/RFC5826, April 2010, <http://www.rfc-editor.org/info/rfc5826>.
[RFC5826]Brandt，A.，Buron，J.，和G.Porcu，“低功率和有损网络中的家庭自动化路由要求”，RFC 5826，DOI 10.17487/RFC5826，2010年4月<http://www.rfc-editor.org/info/rfc5826>.
[RFC5867] Martocci, J., Ed., De Mil, P., Riou, N., and W. Vermeylen, "Building Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5867, DOI 10.17487/RFC5867, June 2010, <http://www.rfc-editor.org/info/rfc5867>.
[RFC5867]Martocci，J.，Ed.，De Mil，P.，Riou，N.，和W.Vermeylen，“低功率和有损网络中的楼宇自动化路由要求”，RFC 5867，DOI 10.17487/RFC5867，2010年6月<http://www.rfc-editor.org/info/rfc5867>.
[RFC6282] Hui, J., Ed., and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011, <http://www.rfc-editor.org/info/rfc6282>.
[RFC6282]Hui，J.，Ed.，和P.Thubert，“基于IEEE 802.15.4的网络上IPv6数据报的压缩格式”，RFC 6282，DOI 10.17487/RFC6282，2011年9月<http://www.rfc-editor.org/info/rfc6282>.
[RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., Ed., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA) Relay Element", RFC 6345, DOI 10.17487/RFC6345, August 2011, <http://www.rfc-editor.org/info/rfc6345>.
[RFC6345]Duffy，P.，Chakrabarti，S.，Cragie，R.，Ohba，Y.，Ed.，和A.Yegin，“承载网络接入认证（PANA）中继元件的协议”，RFC 6345DOI 10.17487/RFC6345，2011年8月<http://www.rfc-editor.org/info/rfc6345>.
[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>.
[RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., and D. Barthel, "Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks", RFC 6551, DOI 10.17487/RFC6551, March 2012, <http://www.rfc-editor.org/info/rfc6551>.
[RFC6551]Vasseur，JP.，Ed.，Kim，M.，Ed.，Pister，K.，Dejean，N.，和D.Barthel，“低功率和有损网络中用于路径计算的路由度量”，RFC 6551，DOI 10.17487/RFC6551，2012年3月<http://www.rfc-editor.org/info/rfc6551>.
[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6554, DOI 10.17487/RFC6554, March 2012, <http://www.rfc-editor.org/info/rfc6554>.
[RFC6554]Hui，J.，Vasseur，JP.，Culler，D.，和V.Manral，“低功耗和有损网络（RPL）路由协议源路由的IPv6路由头”，RFC 6554，DOI 10.17487/RFC6554，2012年3月<http://www.rfc-editor.org/info/rfc6554>.
[RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for Transport Layer Security (TLS)", RFC 6655, DOI 10.17487/RFC6655, July 2012, <http://www.rfc-editor.org/info/rfc6655>.
[RFC6655]McGrew，D.和D.Bailey，“用于传输层安全（TLS）的AES-CCM密码套件”，RFC 6655，DOI 10.17487/RFC6655，2012年7月<http://www.rfc-editor.org/info/rfc6655>.
[RFC6786] Yegin, A. and R. Cragie, "Encrypting the Protocol for Carrying Authentication for Network Access (PANA) Attribute-Value Pairs", RFC 6786, DOI 10.17487/RFC6786, November 2012, <http://www.rfc-editor.org/info/rfc6786>.
[RFC6786]Yegin，A.和R.Cragie，“加密用于承载网络访问身份验证（PANA）属性值对的协议”，RFC 6786，DOI 10.17487/RFC6786，2012年11月<http://www.rfc-editor.org/info/rfc6786>.
[RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and J. Martocci, "Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks", RFC 6997, DOI 10.17487/RFC6997, August 2013, <http://www.rfc-editor.org/info/rfc6997>.
[RFC6997]Goyal，M.，Ed.，Baccelli，E.，Philipp，M.，Brandt，A.，和J.Martocci，“低功率和有损网络中点对点路由的反应性发现”，RFC 6997，DOI 10.17487/RFC6997，2013年8月<http://www.rfc-editor.org/info/rfc6997>.
[RFC6998] Goyal, M., Ed., Baccelli, E., Brandt, A., and J. Martocci, "A Mechanism to Measure the Routing Metrics along a Point-to-Point Route in a Low-Power and Lossy Network", RFC 6998, DOI 10.17487/RFC6998, August 2013, <http://www.rfc-editor.org/info/rfc6998>.
[RFC6998]Goyal，M.，Ed.，Baccelli，E.，Brandt，A.，和J.Martocci，“在低功耗和有损网络中沿点对点路由测量路由度量的机制”，RFC 6998，DOI 10.17487/RFC6998，2013年8月<http://www.rfc-editor.org/info/rfc6998>.
[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>.
[RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS", RFC 7251, DOI 10.17487/RFC7251, June 2014, <http://www.rfc-editor.org/info/rfc7251>.
[RFC7251]McGrew，D.，Bailey，D.，Campagna，M.，和R.Dugal，“用于TLS的AES-CCM椭圆曲线加密（ECC）密码套件”，RFC 7251，DOI 10.17487/RFC7251，2014年6月<http://www.rfc-editor.org/info/rfc7251>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <http://www.rfc-editor.org/info/rfc7296>.
[RFC7296]Kaufman，C.，Hoffman，P.，Nir，Y.，Eronen，P.，和T.Kivinen，“互联网密钥交换协议版本2（IKEv2）”，STD 79，RFC 7296，DOI 10.17487/RFC72962014年10月<http://www.rfc-editor.org/info/rfc7296>.
[RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., and M. Richardson, Ed., "A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, <http://www.rfc-editor.org/info/rfc7416>.
[RFC7416]Tsao，T.，Alexander，R.，Dohler，M.，Daza，V.，Lozano，A.，和M.Richardson，Ed.，“低功耗和有损网络（RPLs）路由协议的安全威胁分析”，RFC 7416，DOI 10.17487/RFC7416，2015年1月<http://www.rfc-editor.org/info/rfc7416>.
[RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731, February 2016, <http://www.rfc-editor.org/info/rfc7731>.
[RFC7731]Hui，J.和R.Kelsey，“低功耗和有损网络的多播协议（MPL）”，RFC 7731，DOI 10.17487/RFC7731，2016年2月<http://www.rfc-editor.org/info/rfc7731>.
[IEEE802.15.4] IEEE, "IEEE Standard for Local and metropolitan area networks--Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs)", IEEE 802.15.4, DOI 10.1109/ieeestd.2011.6012487, <http://ieeexplore.ieee.org/servlet/ opac?punumber=6012485>.
[IEEE802.15.4]IEEE，“局域网和城域网的IEEE标准——第15.4部分：低速无线个人区域网（LR WPAN）”，IEEE 802.15.4，DOI 10.1109/ieeestd.2011.6012487<http://ieeexplore.ieee.org/servlet/ opac？punumber=6012485>。
[G.9959] International Telecommunication Union, "Short range narrow-band digital radiocommunication transceivers - PHY, MAC, SAR and LLC layer specifications", ITU-T Recommendation G.9959, January 2015, <http://www.itu.int/rec/T-REC-G.9959>.
[G.9959]国际电信联盟，“短程窄带数字无线电通信收发器-物理层、MAC层、SAR层和LLC层规范”，ITU-T建议G.9959，2015年1月<http://www.itu.int/rec/T-REC-G.9959>.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, DOI 10.17487/RFC3411, December 2002, <http://www.rfc-editor.org/info/rfc3411>.
[RFC3411]Harrington，D.，Presohn，R.，和B.Wijnen，“描述简单网络管理协议（SNMP）管理框架的体系结构”，STD 62，RFC 3411，DOI 10.17487/RFC34112002年12月<http://www.rfc-editor.org/info/rfc3411>.
[RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-Demand Distance Vector (AODV) Routing", RFC 3561, DOI 10.17487/RFC3561, July 2003, <http://www.rfc-editor.org/info/rfc3561>.
[RFC3561]Perkins，C.，Belding Royer，E.，和S.Das，“临时按需距离向量（AODV）路由”，RFC 3561，DOI 10.17487/RFC3561，2003年7月<http://www.rfc-editor.org/info/rfc3561>.
[RFC5889] Baccelli, E., Ed., and M. Townsley, Ed., "IP Addressing Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889, September 2010, <http://www.rfc-editor.org/info/rfc5889>.
[RFC5889]Baccelli，E.，Ed.，和M.Townsley，Ed.，“Ad Hoc网络中的IP寻址模型”，RFC 5889，DOI 10.17487/RFC5889，2010年9月<http://www.rfc-editor.org/info/rfc5889>.
[RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6552, DOI 10.17487/RFC6552, March 2012, <http://www.rfc-editor.org/info/rfc6552>.
[RFC6552]Thubert，P.，Ed.“低功耗和有损网络路由协议（RPL）的目标函数零”，RFC 6552，DOI 10.17487/RFC6552，2012年3月<http://www.rfc-editor.org/info/rfc6552>.
[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>.
[RFC7390] Rahman, A., Ed., and E. Dijk, Ed., "Group Communication for the Constrained Application Protocol (CoAP)", RFC 7390, DOI 10.17487/RFC7390, October 2014, <http://www.rfc-editor.org/info/rfc7390>.
[RFC7390]Rahman，A.，Ed.，和E.Dijk，Ed.“受限应用协议（CoAP）的组通信”，RFC 7390，DOI 10.17487/RFC7390，2014年10月<http://www.rfc-editor.org/info/rfc7390>.
[RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets over ITU-T G.9959 Networks", RFC 7428, DOI 10.17487/RFC7428, February 2015, <http://www.rfc-editor.org/info/rfc7428>.
[RFC7428]Brandt，A.和J.Buron，“通过ITU-T G.9959网络传输IPv6数据包”，RFC 7428，DOI 10.17487/RFC7428，2015年2月<http://www.rfc-editor.org/info/rfc7428>.
[SOFT11] Baccelli, E., Philipp, M., and M. Goyal, "The P2P-RPL Routing Protocol for IPv6 Sensor Networks: Testbed Experiments", Proceedings of the 19th Annual Conference on Software Telecommunications and Computer Networks, Split, Croatia, September 2011.
[SOFT11]Baccelli，E.，Philipp，M.和M.Goyal，“IPv6传感器网络的P2P-RPL路由协议：试验台实验”，第19届软件电信和计算机网络年会论文集，克罗地亚斯普利特，2011年9月。
[INTEROP12] Philipp, M., Baccelli, E., Brandt, A., Valev, H., and J. Buron, "Report on P2P-RPL Interoperability Testing", INRIA Research Report RR-7864, January 2012.
[INTEROP12]Philipp，M.，Baccelli，E.，Brandt，A.，Valev，H.，和J.Buron，“P2P-RPL互操作性测试报告”，INRIA研究报告RR-7864，2012年1月。
[RT-MPL] van der Stok, P., "Real-Time multicast for wireless mesh networks using MPL", White paper, April 2014, <http://www.vanderstok.org/papers/Real-time-MPL.pdf>.
[RT-MPL]van der Stok，P.，“使用MPL的无线网状网络实时多播”，白皮书，2014年4月<http://www.vanderstok.org/papers/Real-time-MPL.pdf>.
[OccuSwitch] Philips lighting Electronics, "OccuSwitch Wireless (brochure)", May 2012, <http://www.philipslightingcontrols.com/assets/ cms/uploads/files/osw/MK_OSWNETBROC_5.pdf>.
[OccupSwitch]飞利浦照明电子公司，“OccupSwitch无线（手册）”，2012年5月<http://www.philipslightingcontrols.com/assets/ cms/uploads/files/osw/MK_OSWNETBROC_5.pdf>。
[Office-Light] Clanton and Associates, Inc., "Wireless Lighting Control - A Life Cycle Cost Evaluation of Multiple Lighting Control Strategies", February 2014, <http://www.daintree.net/ wp-content/uploads/2014/02/ clanton_lighting_control_report_0411.pdf>.
[Office Light]Clanton and Associates，Inc.，“无线照明控制——多种照明控制策略的生命周期成本评估”，2014年2月<http://www.daintree.net/ wp content/uploads/2014/02/clanton_lighting_control_report_0411.pdf>。
[RTN2011] Holtman, K. and P. van der Stok, "Real-time routing for low-latency 802.15.4 control networks", 23rd Euromicro Conference on Real-Time Systems, Porto, Portugal, July 2011.
[RTN2011]Holtman，K.和P.van der Stok，“低延迟802.15.4控制网络的实时路由”，第23届欧洲微实时系统会议，葡萄牙波尔图，2011年7月。
[MEAS] Holtman, K., "Connectivity loss in large scale IEEE 802.15.4 network", Private Communication, November 2013.
[MEAS]Holtman，K.，“大规模IEEE 802.15.4网络中的连接损失”，私人通信，2013年11月。
[BC-Survey] Kastner, W., Neugschwandtner, G., Soucek, S., and H. Newmann, "Communication Systems for Building Automation and Control", Proceedings of the IEEE, Vol. 93, No. 6, DOI 10.1109/JPROC.2005.849726, June 2005.
[BC Survey]Kastner，W.，Neugschwandtner，G.，Soucek，S.，和H.Newmann，“楼宇自动化和控制的通信系统”，IEEE会议录，第93卷，第6期，DOI 10.1109/JPROC.2005.849726，2005年6月。
[ZigBeeIP] ZigBee Alliance, "ZigBee IP specification", ZigBee document 095023r34, March 2014, <http://www.zigbee.org/>.
[ZigBeeIP]ZigBee联盟，“ZigBee IP规范”，ZigBee文件095023r34，2014年3月<http://www.zigbee.org/>.
The DAG, being a tree structure, is formed from a root. If nodes residing in different branches need to communicate internally, DAG mechanisms provided in RPL [RFC6550] will propagate traffic towards the root, potentially all the way to the root, and down along another branch [RFC6998]. In a typical example, two nodes could reach each other via only two router nodes, but in some unfortunate cases, RPL may send traffic three hops up and three hops down again. This leads to several undesirable phenomena, as described in the following sections.
DAG是树形结构，由根构成。如果驻留在不同分支中的节点需要内部通信，RPL[RFC6550]中提供的DAG机制将把流量传播到根，可能一直传播到根，然后沿着另一个分支向下传播[RFC6998]。在一个典型的例子中，两个节点只能通过两个路由器节点相互联系，但在一些不幸的情况下，RPL可能会向上三跳，再向下三跳发送流量。这会导致一些不良现象，如以下各节所述。
If many P2P data flows have to move up towards the root to get down again in another branch, there is an increased risk of congestion the nearer to the root of the DAG the data flows. Due to the broadcast nature of radio frequency (RF) systems, any child node of the root is not only directing RF power downwards in its sub-tree but just as much upwards towards the root, potentially jamming other MP2P traffic leaving the tree or preventing the root of the DAG from sending P2MP traffic into the DAG because the listen-before-talk link-layer protection kicks in.
如果许多P2P数据流必须向上移动到根，才能在另一个分支中再次向下移动，那么数据流越靠近DAG的根，拥塞的风险就越高。由于射频（RF）系统的广播性质，根节点的任何子节点不仅在其子树中向下引导射频功率，而且同样向上指向根节点，可能会干扰离开树的其他MP2P通信，或阻止DAG的根将P2MP通信发送到DAG，因为“先听后讲”链路层保护开始生效。
Battery-powered nodes originating P2P traffic depend on the route length. Long routes cause source nodes to stay awake for longer periods before returning to sleep. Thus, a longer route translates proportionally (more or less) into higher battery consumption.
发起P2P流量的电池供电节点取决于路由长度。长路由会导致源节点在返回睡眠之前长时间保持清醒。因此，较长的路线会相应地（或多或少地）转化为较高的电池消耗。
The RPL DAG mechanism uses DIO and DAO messages to monitor the health of the DAG. On rare occasions, changed radio conditions may render routes unusable just after a destination node has returned a DAO indicating that the destination is reachable. Given enough time, the next Trickle timer-controlled DIO/DAO update will eventually repair the broken routes; however, this may not occur in a timely manner appropriate to the application. In an apparently stable DAG, Trickle timer dynamics may reduce the update rate to a few times every hour. If a user issues an actuator command, e.g., light on in the time interval between the time that the last DAO message was issued the destination module and the time that one of the parents sends the next DIO, the destination cannot be reached. There is no
RPL DAG机制使用DIO和DAO消息来监视DAG的运行状况。在极少数情况下，在目标节点返回指示可到达目标的DAO后，更改的无线电条件可能会导致路由不可用。如果有足够的时间，由涓流定时器控制的下一次DIO/DAO更新将最终修复损坏的路由；但是，这可能不会以适合于应用程序的方式及时发生。在一个明显稳定的DAG中，涓流计时器动态可能会将更新速率降低到每小时几次。如果用户发出执行器命令，例如，在向目标模块发出最后一条DAO消息和其中一个父模块发送下一个DIO之间的时间间隔内，指示灯亮起，则无法到达目标。没有
mechanism in RPL to initiate the restoration of connectivity in a reactive fashion. The consequence is a broken service in home and building applications.
RPL中以反应方式启动连接恢复的机制。其结果是家庭和建筑应用中的服务中断。
Experience from the telecom industry shows that if the voice delay exceeds 250 ms, users start getting confused, frustrated, and/or annoyed. In the same way, if the light does not turn on within the same period of time, a home control user will activate the controls again, causing a sequence of commands such as Light{on,off,off,on,off,...} or Volume{up,up,up,up,up,...}. Whether the outcome is nothing or some unintended response, this is unacceptable. A controlling system must be able to restore connectivity to recover from the error situation. Waiting for an unknown period of time is not an option. Although this issue was identified during the P2P analysis, it applies just as well to application scenarios where an IP application outside the LLN controls actuators, lights, etc.
电信行业的经验表明，如果语音延迟超过250毫秒，用户就会开始感到困惑、沮丧和/或烦恼。同样，如果灯在同一时间段内未打开，则家庭控制用户将再次激活控制，从而导致一系列命令，例如灯{on，off，off，on，off，…}或音量{up，up，up，up，…}。无论结果是什么都没有或是一些意外的反应，这都是不可接受的。控制系统必须能够恢复连接以从错误情况中恢复。等待未知的时间段不是一种选择。尽管在P2P分析期间发现了此问题，但它同样适用于LLN之外的IP应用程序控制执行器、灯等的应用场景。
Measurements of connectivity between neighboring nodes are discussed in [RTN2011] and [MEAS].
[RTN2011]和[MEAS]中讨论了相邻节点之间的连通性测量。
The work is motivated by the measurements in literature that affirm that the range of an antenna is not circle symmetric but that the signal strength of a given level follows an intricate pattern around the antenna, and there may be holes within the area delineated by a polar plot. It is reported that communication is not symmetric: reception of messages from node A by node B does not imply reception of messages from node B by node A. The quality of the signal fluctuates over time, and also the height of the antenna within a room can have consequences for the range. As a function of the distance from the source, three regions are generally recognized: (1) a clear region with excellent signal quality, (2) a region with fluctuating signal quality, and (3) a region without reception. Installation of meshes with neighbors in the clear region is not sufficient, as described below.
这项工作是由文献中的测量结果推动的，这些测量结果确认天线的范围不是圆对称的，但给定电平的信号强度遵循天线周围的复杂图案，并且极坐标图描绘的区域内可能存在孔洞。据报道，通信是不对称的：节点B接收来自节点A的消息并不意味着节点A接收来自节点B的消息。信号质量随时间而波动，房间内天线的高度也会对范围产生影响。作为与源距离的函数，通常可识别三个区域：（1）信号质量优良的清晰区域，（2）信号质量波动的区域，以及（3）无接收的区域。如下所述，仅在透明区域中安装相邻网格是不够的。
[RTN2011] extends existing work by:
[RTN2011]通过以下方式扩展现有工作：
o Observations over periods of at least a week,
o 至少一周的观察，
o Testing links that are in the clear region,
o 测试处于清除区域的链接，
o Observation in an office building during working hours, and
o 工作时间在办公楼内观察，以及
o Concentrating on one-hop and two-hop routes.
o 专注于一跳和两跳路线。
Eight nodes were distributed over a surface of 30 square meters. All nodes are at a one-hop distance from each other, and all are situated in each other's clear region. Each node sends messages to each of its neighbors and repeats the message until it arrives. The latency of the message was measured over periods of at least a week. It was noticed that latencies longer than a second occurred without any apparent reason, but only during working days and never during the weekends. Bad periods could last for minutes. By sending messages via two paths -- (1) a one-hop path directly and (2) a two-hop path via a randomly chosen neighbor -- the probability of delays larger than 100 ms decreased significantly.
八个节点分布在30平方米的表面上。所有节点彼此之间的距离为一跳，并且都位于彼此的空白区域。每个节点向其每个邻居发送消息，并重复该消息，直到其到达。在至少一周的时间内测量消息的延迟。有人注意到，在没有任何明显原因的情况下，延迟时间超过一秒，但仅在工作日发生，而从不在周末发生。月经不好可能持续几分钟。通过两条路径发送消息——（1）直接一跳路径和（2）通过随机选择的邻居发送两跳路径——延迟大于100ms的概率显著降低。
The conclusion is that even for one-hop communication between not-too-distant "line of sight" nodes, there are periods of low reception in which communication deadlines of 200 ms are exceeded. It pays to send a second message over a two-hop path to increase the reliability of timely message transfer.
结论是，即使对于距离不太远的“视线”节点之间的单跳通信，也存在超过200ms通信截止时间的低接收时段。通过两跳路径发送第二条消息以提高及时消息传输的可靠性是值得的。
[MEAS] confirms that temporary bad reception by close neighbors can occur within other types of areas. Nodes were installed on the ceiling in a grid with a distance of 30-50 cm between them. Two hundred nodes were distributed over an area of 10 m x 5 m. It clearly transpired that with increasing distance the probability of reception decreased. At the same time, a few nodes furthest away from the sender had a high probability of message reception, while some close neighbors of the sender did not receive messages. The patterns of nodes experiencing good reception evolved over time.
[MEAS]证实，在其他类型的区域内，近邻可能会出现暂时的不良反应。节点安装在天花板上的网格中，间距为30-50 cm。200个节点分布在10 m x 5 m的区域内。很明显，随着距离的增加，接收概率降低。同时，距离发送方最远的几个节点接收消息的概率较高，而发送方的一些近邻没有接收消息。节点接收良好的模式会随着时间的推移而演变。
The conclusion here is that even for direct neighbors reception can temporarily be bad for periods of several minutes. For reliable and timely communication, it is imperative to have at least two communication paths available (e.g., two-hop paths next to the one-hop path for direct neighbors).
这里的结论是，即使是直接邻居，在几分钟的时间内，接收效果也可能暂时不好。为了可靠和及时的通信，必须至少有两条通信路径可用（例如，直接邻居的一跳路径旁边有两条跳路径）。
Acknowledgements
致谢
This document reflects discussions and remarks from several individuals, including (in alphabetical order) Stephen Farrell, Mukul Goyal, Sandeep Kumar, Jerry Martocci, Catherine Meadows, Yoshihiro Ohba, Charles Perkins, Yvonne-Anne Pignolet, Michael Richardson, Ines Robles, Zach Shelby, and Meral Sherazipour.
本文件反映了几个个人的讨论和评论，包括（按字母顺序排列）斯蒂芬·法雷尔、穆库尔·戈亚尔、桑德普·库马尔、杰里·马托西、凯瑟琳·梅多斯、大贺吉郎、查尔斯·珀金斯、伊冯·安·皮格诺莱、迈克尔·理查森、伊内斯·罗伯斯、扎克·谢尔比和梅拉尔·谢拉齐普尔。
Authors' Addresses
作者地址
Anders Brandt Sigma Designs
安德斯·勃兰特·西格玛设计
Email: anders_Brandt@sigmadesigns.com
Email: anders_Brandt@sigmadesigns.com
Emmanuel Baccelli INRIA
伊曼纽尔杆菌
Email: Emmanuel.Baccelli@inria.fr
Email: Emmanuel.Baccelli@inria.fr
Robert Cragie ARM Ltd. 110 Fulbourn Road Cambridge CB1 9NJ United Kingdom
Robert Cragie ARM Ltd.英国剑桥CB1 9NJ富尔伯恩路110号
Email: robert.cragie@arm.com
Email: robert.cragie@arm.com
Peter van der Stok Consultant
彼得·范德斯托克顾问
Email: consultancy@vanderstok.org
Email: consultancy@vanderstok.org