Internet Engineering Task Force (IETF) M. Goyal, Ed.
Request for Comments: 6997 Univ. of Wisconsin Milwaukee
Category: Experimental E. Baccelli
ISSN: 2070-1721 M. Philipp
INRIA
A. Brandt
Sigma Designs
J. Martocci
Johnson Controls
August 2013
Internet Engineering Task Force (IETF) M. Goyal, Ed.
Request for Comments: 6997 Univ. of Wisconsin Milwaukee
Category: Experimental E. Baccelli
ISSN: 2070-1721 M. Philipp
INRIA
A. Brandt
Sigma Designs
J. Martocci
Johnson Controls
August 2013
Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks
低功耗有损网络中点到点路由的无功发现
Abstract
摘要
This document specifies a point-to-point route discovery mechanism, complementary to the Routing Protocol for Low-power and Lossy Networks (RPL) core functionality. This mechanism allows an IPv6 router to discover "on demand" routes to one or more IPv6 routers in a Low-power and Lossy Network (LLN) such that the discovered routes meet specified metrics constraints.
本文档指定了一种点对点路由发现机制，它是对低功耗和有损网络（RPL）核心功能路由协议的补充。此机制允许IPv6路由器在低功耗有损网络（LLN）中发现到一个或多个IPv6路由器的“按需”路由，以便发现的路由满足指定的度量约束。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6997.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6997.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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
2. The Use Cases ...................................................4
3. Terminology .....................................................5
4. Applicability ...................................................6
5. Functional Overview .............................................7
6. P2P Route Discovery Mode of Operation ..........................10
6.1. Setting a P2P Mode DIO ....................................10
7. P2P Route Discovery Option (P2P-RDO) ...........................15
8. The P2P Discovery Reply Object (P2P-DRO) .......................18
8.1. Secure P2P-DRO ............................................20
8.2. Setting a P2P-RDO Carried in a P2P Discovery Reply
Object ....................................................21
9. P2P-RPL Route Discovery by Creating a Temporary DAG ............21
9.1. Joining a Temporary DAG ...................................21
9.2. Trickle Operation for P2P Mode DIOs .......................22
9.3. Processing a P2P Mode DIO .................................24
9.4. Additional Processing of a P2P Mode DIO at an
Intermediate Router .......................................26
9.5. Additional Processing of a P2P Mode DIO at the Target .....27
9.6. Processing a P2P-DRO at an Intermediate Router ............28
9.7. Processing a P2P-DRO at the Origin ........................30
10. The P2P Discovery Reply Object Acknowledgement (P2P-DRO-ACK) ..31
11. Secure P2P-RPL Operation ......................................32
12. Packet Forwarding along a Route Discovered Using P2P-RPL ......33
13. Interoperability with Core RPL ................................34
14. Security Considerations .......................................34
15. IANA Considerations ...........................................36
15.1. Additions to Mode of Operation ...........................36
15.2. Additions to RPL Control Message Options .................36
15.3. Additions to RPL Control Codes ...........................36
16. Known Issues and Future Work ..................................37
17. Acknowledgements ..............................................37
18. References ....................................................38
18.1. Normative References .....................................38
18.2. Informative References ...................................38
1. Introduction ....................................................4
2. The Use Cases ...................................................4
3. Terminology .....................................................5
4. Applicability ...................................................6
5. Functional Overview .............................................7
6. P2P Route Discovery Mode of Operation ..........................10
6.1. Setting a P2P Mode DIO ....................................10
7. P2P Route Discovery Option (P2P-RDO) ...........................15
8. The P2P Discovery Reply Object (P2P-DRO) .......................18
8.1. Secure P2P-DRO ............................................20
8.2. Setting a P2P-RDO Carried in a P2P Discovery Reply
Object ....................................................21
9. P2P-RPL Route Discovery by Creating a Temporary DAG ............21
9.1. Joining a Temporary DAG ...................................21
9.2. Trickle Operation for P2P Mode DIOs .......................22
9.3. Processing a P2P Mode DIO .................................24
9.4. Additional Processing of a P2P Mode DIO at an
Intermediate Router .......................................26
9.5. Additional Processing of a P2P Mode DIO at the Target .....27
9.6. Processing a P2P-DRO at an Intermediate Router ............28
9.7. Processing a P2P-DRO at the Origin ........................30
10. The P2P Discovery Reply Object Acknowledgement (P2P-DRO-ACK) ..31
11. Secure P2P-RPL Operation ......................................32
12. Packet Forwarding along a Route Discovered Using P2P-RPL ......33
13. Interoperability with Core RPL ................................34
14. Security Considerations .......................................34
15. IANA Considerations ...........................................36
15.1. Additions to Mode of Operation ...........................36
15.2. Additions to RPL Control Message Options .................36
15.3. Additions to RPL Control Codes ...........................36
16. Known Issues and Future Work ..................................37
17. Acknowledgements ..............................................37
18. References ....................................................38
18.1. Normative References .....................................38
18.2. Informative References ...................................38
Targeting Low-power and Lossy Networks (LLNs), the IPv6 Routing Protocol for LLNs (RPL) [RFC6550] provides paths along a Directed Acyclic Graph (DAG) rooted at a single router in the network. Establishment and maintenance of a DAG are performed by routers in the LLN using Destination-Oriented DAG (DODAG) Information Object (DIO) messages. When two arbitrary routers (neither of which is the DAG's root) need to communicate, the data packets are restricted to travel only along the links in the DAG. Such point-to-point (P2P) routing functionality may not be sufficient for several home automation [RFC5826] and building automation [RFC5867] applications, due to the following reasons:
针对低功耗和有损网络（LLN），针对LLN的IPv6路由协议（RPL）[RFC6550]提供了沿着植根于网络中单个路由器的有向无环图（DAG）的路径。DAG的建立和维护由LLN中的路由器使用面向目的地的DAG（DODAG）信息对象（DIO）消息来执行。当两个任意路由器（两者都不是DAG的根）需要通信时，数据包仅限于沿DAG中的链路传输。由于以下原因，此类点对点（P2P）路由功能可能不足以满足多个家庭自动化[RFC5826]和楼宇自动化[RFC5867]应用：
o The need to pre-establish routes: Each potential destination in the network must declare itself as such ahead of the time a source needs to reach it.
o 需要预先建立路由：网络中的每个潜在目的地必须在源到达之前声明自己是这样的。
o The need to route only along the links in the DAG: A DAG is built to optimize the routing cost to reach the root. Restricting P2P routes to use only the in-DAG links may result in significantly suboptimal routes and severe traffic congestion near the DAG root.
o 只需沿DAG中的链接布线：构建DAG是为了优化到达根的布线成本。限制P2P路由仅使用DAG内链路可能会导致明显次优的路由和DAG根附近的严重流量拥塞。
This document describes an extension to core RPL (i.e., the RPL functionality described in [RFC6550]) that enables an IPv6 router in the LLN to discover routes to one or more IPv6 routers in the LLN "on demand". The discovered routes may not be the best available but are guaranteed to meet the specified routing metric constraints. Thus, such routes are considered "good enough" from the application's perspective. This reactive P2P route discovery mechanism is henceforth referred to as P2P-RPL.
本文档描述了对核心RPL（即，[RFC6550]中描述的RPL功能）的扩展，该扩展使LLN中的IPv6路由器能够“按需”发现到LLN中一个或多个IPv6路由器的路由。发现的路由可能不是可用的最佳路由，但保证满足指定的路由度量约束。因此，从应用程序的角度来看，这样的路由被认为“足够好”。这种反应式P2P路由发现机制从此被称为P2P-RPL。
A mechanism to measure the end-to-end cost of an existing route is specified in [RFC6998]. As discussed in Section 4, measuring the end-to-end cost of an existing route may help in deciding whether to initiate the discovery of a better route using P2P-RPL and the metric constraints to be used for this purpose.
[RFC6998]中规定了测量现有路由的端到端成本的机制。如第4节所述，测量现有路由的端到端成本可能有助于决定是否使用P2P-RPL和用于此目的的度量约束来启动更好路由的发现。
One use case, common in home [RFC5826] and commercial building [RFC5867] environments, involves a device (say, a remote control) that suddenly needs to communicate with another device (say, a lamp) to which it does not already have a route (and whose network address it knows a priori). In this case, the remote control must be able to discover a route to the lamp "on demand".
一个在家庭[RFC5826]和商业建筑[RFC5867]环境中常见的用例涉及一个突然需要与另一个设备（例如，一个灯）通信的设备（例如，一个遥控器），该设备没有路由（并且事先知道其网络地址）。在这种情况下，遥控器必须能够“按需”发现通向指示灯的路线。
Another use case, common in a commercial building environment, involves a large LLN deployment where P2P communication along a particular DAG among hundreds (or thousands) of routers creates severe traffic congestion near that DAG's root. In this case, it is desirable to discover direct routes between various source-destination pairs that do not pass through the DAG's root.
另一个在商业建筑环境中常见的用例涉及大型LLN部署，其中数百（或数千）个路由器之间沿着特定DAG的P2P通信在该DAG根附近造成严重的流量拥塞。在这种情况下，希望发现不通过DAG根的各种源-目的地对之间的直接路由。
Other use cases involve scenarios where energy or latency constraints are not satisfied by the P2P routes along an existing DAG because they involve traversing many more routers than necessary to reach the destination.
其他用例涉及这样的场景，即沿着现有DAG的P2P路由无法满足能量或延迟约束，因为它们需要穿越比到达目的地所需的更多的路由器。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
Additionally, this document uses terminology from [RFC6550] and [RFC6554]. Further terminology may be found in [ROLL-TERMS]. This document introduces the following terms:
此外，本文件使用[RFC6550]和[RFC6554]中的术语。更多术语见[滚动术语]。本文件介绍了以下术语：
Origin: The IPv6 router initiating the P2P-RPL route discovery.
来源：发起P2P-RPL路由发现的IPv6路由器。
Target: The IPv6 router at the other end point of the P2P route(s) to be discovered. A P2P-RPL route discovery can discover routes to multiple Targets at the same time.
目标：要查找的P2P路由的另一个端点处的IPv6路由器。P2P-RPL路由发现可以同时发现到多个目标的路由。
Intermediate Router: An IPv6 router that is neither the Origin nor a Target.
中间路由器：既不是源路由器也不是目标路由器的IPv6路由器。
Forward direction: The direction from the Origin to the Target.
正向：从原点到目标的方向。
Reverse direction: The direction from the Target to the Origin.
反向：从目标到原点的方向。
Forward Route: A route in the Forward direction.
前进路线：前进方向的路线。
Reverse Route: A route in the Reverse direction.
反向路由：反向路由。
Bidirectional Route: A route that can be used in both Forward and Reverse directions.
双向路由：可在正向和反向使用的路由。
Ingress-only Interface: A network interface that can only receive packets.
仅入口接口：只能接收数据包的网络接口。
Egress-only Interface: A network interface that can only send packets.
仅出口接口：只能发送数据包的网络接口。
Source Route: A complete and ordered list of routers that can be used by a packet to travel from a source to a destination node.
源路由：一个完整且有序的路由器列表，数据包可以使用它从源节点传输到目的节点。
Hop-by-hop Route: The route characterized by each router on the route using its routing table to determine the next hop on the route.
逐跳路由：以路由上的每个路由器为特征的路由，使用其路由表确定路由上的下一跳。
RPL Security Configuration: The values for the Counter is Time, Security Algorithm, Key Identifier Mode, and Security Level fields, as defined in Section 6.1 of [RFC6550], inside the Security section of a secure RPL control message.
RPL安全配置：计数器的值是时间、安全算法、密钥标识符模式和安全级别字段，如[RFC6550]第6.1节所定义，位于安全RPL控制消息的安全部分内。
A route discovery using P2P-RPL may be performed by an Origin when no route exists between itself and the Target(s) or when the existing routes do not satisfy the application requirements. P2P-RPL is designed to discover Hop-by-hop or Source Routes to one or more Targets such that the discovered routes meet the specified constraints. In some application contexts, the constraints that the discovered routes must satisfy are intrinsically known or can be specified by the application. For example, an Origin that expects its Targets to be less than 5 hops away may use "hop-count < 5" as the constraint. In other application contexts, the Origin may need to measure the cost of the existing route to a Target to determine the constraints. For example, an Origin that measures the total expected transmission count (ETX) along its current route to a Target to be 20 may use "ETX < x*20", where x is a fraction that the Origin chooses, as the constraint. A mechanism to measure the cost of an existing route between two IPv6 routers is specified in [RFC6998]. If there is no existing route between the Origin and the Target(s) or the cost measurement for the existing routes fails, the Origin will have to guess the constraints to be used in the initial route discovery. Once the initial route discovery succeeds or fails, the Origin will have a better estimate for the constraints to be used in the subsequent route discovery.
当源站与目标站之间不存在路由或现有路由不满足应用要求时，可由源站执行使用P2P-RPL的路由发现。P2P-RPL设计用于逐跳或源路由到一个或多个目标，以便发现的路由满足指定的约束。在某些应用程序上下文中，发现的路由必须满足的约束本质上是已知的，或者可以由应用程序指定。例如，期望其目标距离小于5跳的原点可以使用“跳数<5”作为约束。在其他应用程序上下文中，原点可能需要测量到目标的现有路由的成本，以确定约束。例如，测量沿其当前路径到目标的总预期传输计数（ETX）为20的原点可以使用“ETX<x*20”，其中x是原点选择的分数，作为约束。[RFC6998]中规定了测量两个IPv6路由器之间现有路由成本的机制。如果起点和目标之间没有现有路由，或者现有路由的成本测量失败，则起点将不得不猜测初始路由发现中要使用的约束。一旦初始路由发现成功或失败，源站将对后续路由发现中使用的约束有更好的估计。
P2P-RPL may result in discovery of better P2P routes than those available along a global DAG designed to optimize routing cost to the DAG's root. The improvement in route quality depends on a number of factors, including the network topology, the "distance" between the Origin and the Target (in terms of the routing metrics in use), and the prevalent conditions in the network. In general, a P2P-RPL route may be better than the one along a global DAG if the Origin and the Target are nearby. Similarly, a P2P-RPL route may not be much better than the one along a global DAG if the Origin and the Target are far apart. Note that even when P2P-RPL routes are not much better than those along a global DAG, P2P-RPL routes may still be able to avoid
P2P-RPL可能会发现比全局DAG上的可用P2P路由更好的P2P路由，该全局DAG旨在优化DAG根的路由成本。路由质量的改善取决于许多因素，包括网络拓扑、源站和目标站之间的“距离”（就使用的路由度量而言）以及网络中的普遍条件。一般来说，如果源和目标在附近，P2P-RPL路由可能比沿着全局DAG的路由更好。类似地，如果起点和目标相距很远，则P2P-RPL路由可能不会比沿着全局DAG的路由好多少。请注意，即使P2P-RPL路由并不比全局DAG上的路由好多少，P2P-RPL路由仍然可以避免
congestion that might occur near the root if the routing takes place only along a global DAG. In general, the cost associated with a P2P-RPL route discovery (in terms of the control messages -- mostly DIOs -- generated) increases with the distance between the Origin and the Target. However, it is possible to limit the cost of route discovery by carefully setting the routing constraints, the Trickle parameters (which govern DIO generation), and the time duration for which a router maintains its membership in the temporary DAG created for the route discovery. A network designer may take into consideration both the benefits (potentially better routes; no need to maintain routes proactively; avoid congestion near the global DAG's root) and costs when using P2P-RPL. The latency associated with a P2P-RPL route discovery again depends on the distance between the Origin and the Target and on the Trickle parameters.
如果路由仅沿全局DAG进行，则可能在根附近发生的拥塞。一般来说，与P2P-RPL路由发现相关的成本（就生成的控制消息而言——主要是DIOs而言）随着源和目标之间的距离而增加。但是，可以通过仔细设置路由约束、涓流参数（控制DIO生成）以及路由器在为路由发现创建的临时DAG中保持其成员身份的持续时间来限制路由发现的成本。当使用P2P-RPL时，网络设计者可能会考虑到好处（可能更好的路由；无需主动维护路由；避免全局DAG根附近的拥塞）和成本。与P2P-RPL路由发现相关的延迟同样取决于源和目标之间的距离以及涓流参数。
Like core RPL [RFC6550], P2P-RPL operation requires that links have bidirectional reachability. For this reason, the routers participating in a P2P-RPL route discovery must ensure that
与核心RPL[RFC6550]一样，P2P-RPL操作要求链路具有双向可达性。因此，参与P2P-RPL路由发现的路由器必须确保
o Links that do not have bidirectional reachability do not become part of the route being discovered; and
o 没有双向可达性的链路不会成为被发现路由的一部分；和
o IPv6 addresses belonging to Ingress-only (or Egress-only) Interfaces do not become part of the route being discovered.
o 属于仅入口（或仅出口）接口的IPv6地址不会成为正在发现的路由的一部分。
This section contains a high-level description of P2P-RPL.
本节包含P2P-RPL的高级描述。
A P2P-RPL route discovery takes place by forming a DAG rooted at the Origin. As is the case with core RPL, P2P-RPL uses IPv6 link-local multicast DIO messages to establish a DAG. However, unlike core RPL, this DAG is temporary in nature. The routes are discovered and installed while the DAG is alive. Once the specified duration of their membership in the DAG is over, the routers leave the DAG, and hence the DAG ceases to exist. However, the installed routes are retained for their specified lifetime (which is different than the specified duration of a router's membership in the DAG) even though the DAG that caused their installation no longer exists. In P2P-RPL, the sole purpose of DAG creation is to discover routes to the Target(s), and DIOs serve as the route discovery messages. Each router joining the DAG determines a rank for itself in the DAG and ignores the subsequent DIOs received from lower-ranked (higher in numerical value) neighbors. Thus, the route discovery messages propagate away from the Origin rather than return to it. As in core RPL, DIO generation at a router is controlled by a Trickle timer [RFC6206], which allows a router to avoid generating unnecessary messages while providing protection against packet loss. P2P-RPL
P2P-RPL路由发现是通过在源节点形成一个DAG来实现的。与核心RPL一样，P2P-RPL使用IPv6链路本地多播DIO消息来建立DAG。但是，与核心RPL不同，此DAG本质上是临时的。在DAG处于活动状态时发现并安装路由。一旦路由器在DAG中的成员身份的指定期限结束，路由器将离开DAG，因此DAG将不再存在。但是，即使导致安装的DAG已不存在，已安装的路由仍将保留其指定的生存期（与路由器在DAG中的成员身份的指定持续时间不同）。在P2P-RPL中，DAG创建的唯一目的是发现到目标的路由，DIOs充当路由发现消息。加入DAG的每个路由器确定其自身在DAG中的排名，并忽略从排名较低（数值较高）的邻居接收的后续DIO。因此，路由发现消息从源位置传播出去，而不是返回到源位置。与核心RPL一样，路由器上的DIO生成由涓流计时器[RFC6206]控制，该计时器允许路由器避免生成不必要的消息，同时防止数据包丢失。P2P-RPL
also uses the routing metrics [RFC6551], Objective Functions, and packet-forwarding framework [RFC6554] [RFC6553] developed for core RPL.
还使用为核心RPL开发的路由度量[RFC6551]、目标函数和包转发框架[RFC6554][RFC6553]。
An Origin may use P2P-RPL to discover routes to one or more Targets identified by one or more unicast/multicast addresses. P2P-RPL allows for the discovery of one Hop-by-hop Route or up to four Source Routes per Target. The discovered routes are guaranteed to meet the specified routing metric constraints but may not be the best available. P2P-RPL may fail to discover any route if the specified routing constraints are overly strict.
源可以使用P2P-RPL来发现到由一个或多个单播/多播地址标识的一个或多个目标的路由。P2P-RPL允许发现一个逐跳路由或每个目标最多四个源路由。发现的路由保证满足指定的路由度量约束，但可能不是可用的最佳路由。如果指定的路由约束过于严格，P2P-RPL可能无法发现任何路由。
The Origin initiates a P2P-RPL route discovery by forming a temporary DAG rooted at itself. The DIOs used to create the temporary DAG are identified by a new Mode of Operation (P2P Route Discovery mode, defined in Section 6). The DIOs listing the P2P Route Discovery mode as the Mode of Operation are henceforth referred to as the P2P mode DIOs. A P2P mode DIO always carries exactly one P2P Route Discovery Option (P2P-RDO, defined in Section 7) in which the Origin specifies the following information:
源节点通过形成一个扎根于自身的临时DAG来启动P2P-RPL路由发现。用于创建临时DAG的DIO通过新的操作模式（第6节中定义的P2P路由发现模式）进行标识。将P2P路由发现模式列为操作模式的DIOs此后被称为P2P模式DIOs。P2P模式DIO始终只携带一个P2P路由发现选项（P2P-RDO，在第7节中定义），其中来源指定以下信息：
o The IPv6 address of a Target. This could be a unicast address or a multicast address. Any additional Targets may be specified by including one or more RPL Target options [RFC6550] inside the DIO.
o 目标的IPv6地址。这可以是单播地址或多播地址。可通过在DIO内包含一个或多个RPL目标选项[RFC6550]来指定任何其他目标。
o The nature of the route(s) to be discovered: Hop-by-hop or Source Routes. This specification allows for the discovery of one Hop-by-hop Route or up to four Source Routes per Target.
o 要发现的路由的性质：逐跳路由或源路由。此规范允许发现一个逐跳路由或每个目标最多四个源路由。
o The desired number of routes (if Source Routes are being discovered).
o 所需的路由数（如果正在查找源路由）。
o Whether the Target(s) should send P2P Discovery Reply Object (P2P-DRO) messages (defined in Section 8) back to the Origin on receiving a DIO message. A P2P-DRO message carries a discovered Source Route back to the Origin or establishes a Hop-by-hop Route between the Origin and the Target.
o 目标是否应在收到DIO消息时将P2P发现回复对象（P2P-DRO）消息（在第8节中定义）发送回源站。P2P-DRO消息将发现的源路由带回源站，或在源站和目标站之间建立逐跳路由。
A P2P-RDO also includes the best route from the Origin that the router, generating the P2P mode DIO, has seen so far.
P2P-RDO还包括到目前为止生成P2P模式DIO的路由器所看到的来自原点的最佳路由。
A P2P mode DIO MAY also carry:
P2P模式DIO还可以携带：
o One or more Metric Container options to specify:
o 要指定的一个或多个公制容器选项：
* The relevant routing metrics.
* 相关的路由度量。
* The constraints that the discovered route must satisfy. These constraints also limit how far the DIO messages may travel.
* 发现的路由必须满足的约束。这些限制也限制了DIO消息的传播距离。
o One or more RPL Target options to specify additional unicast or multicast Targets.
o 一个或多个RPL目标选项，用于指定其他单播或多播目标。
As the routers join the temporary DAG, they keep track of the best route(s) (so far from the Origin) they have seen and advertise these routes, along with the corresponding routing metrics, in their P2P mode DIOs. A router, including the Target(s), discards a received P2P mode DIO if the aggregated routing metrics on the route advertised by the DIO do not satisfy the listed constraints. These constraints can be used to limit the propagation of P2P mode DIO messages. A router may also discard a received P2P mode DIO if it does not wish to be a part of the discovered route due to limited resources or due to policy reasons.
当路由器加入临时DAG时，它们会跟踪它们所看到的最佳路由（到目前为止，距离原点不远），并在其P2P模式DIO中公布这些路由以及相应的路由度量。如果由DIO公布的路由上的聚合路由度量不满足列出的约束，则路由器（包括目标）丢弃接收到的P2P模式DIO。这些约束可用于限制P2P模式DIO消息的传播。如果由于资源有限或由于策略原因，路由器不希望成为发现的路由的一部分，则路由器也可以丢弃接收到的P2P模式DIO。
When a Target receives a P2P mode DIO, it contains inside the P2P-RDO a complete Source Route from the Origin to this Target. Since the links in the discovered route have bidirectional reachability (Section 7), the Target may use the discovered route to reach the Origin. Thus, a router that provides a particular service in the LLN (e.g., an outside temperature server) could initiate a P2P-RPL route discovery listing all its potential clients as Targets, thereby allowing the clients to discover a Source Route back to the server. In this case, the Origin (the server) might want to disable the generation of P2P-DRO messages by the Targets (the clients). If the Origin has requested that P2P-DRO messages be sent back, the Target may select the discovered route in the received DIO for further processing, as described next. This document does not specify a particular method for the Target to use to select a route for further processing. Example methods include selecting any route that meets the constraints or selecting the best route(s) discovered over a certain time period.
当目标接收到P2P模式DIO时，它在P2P-RDO中包含从源到该目标的完整源路由。由于发现的路由中的链路具有双向可达性（第7节），目标可以使用发现的路由到达原点。因此，在LLN中提供特定服务的路由器（例如，外部温度服务器）可以启动P2P-RPL路由发现，将其所有潜在客户机列为目标，从而允许客户机发现返回服务器的源路由。在这种情况下，源（服务器）可能希望禁用目标（客户端）生成P2P-DRO消息。如果源站已请求将P2P-DRO消息发送回，则目标站可在接收到的DIO中选择发现的路由以进行进一步处理，如下所述。本文档未指定目标用于选择路线进行进一步处理的特定方法。示例方法包括选择满足约束的任何路由或选择在特定时间段内发现的最佳路由。
If one or more Source Routes are being discovered, the Target sends the selected Source Route(s) to the Origin via P2P-DRO messages, with one P2P-DRO message carrying one discovered route. On receiving a P2P-DRO message, the Origin stores the discovered route in its memory. This specification allows the Origin to discover up to four Source Routes per Target, thereby allowing the Origin to have sufficient ready-to-use alternatives should one or more of these
如果发现一个或多个源路由，则目标通过P2P-DRO消息将选定的源路由发送到源，其中一条P2P-DRO消息携带一条发现的路由。当接收到P2P-DRO消息时，源站将发现的路由存储在其内存中。该规范允许源站发现每个目标最多四条源路由，从而允许源站在其中一条或多条路由出现时有足够的备用路由
routes fail. If a Hop-by-hop Route is being discovered, the Target sends a P2P-DRO message containing the selected route to the Origin. The P2P-DRO message travels back to the Origin along the selected route, establishing state for the Forward Route in the routers on the path.
路线失败。如果发现逐跳路由，则目标将向源发送包含所选路由的P2P-DRO消息。P2P-DRO消息沿所选路由返回到源站，在路径上的路由器中建立前向路由的状态。
The Target may request that the Origin acknowledge the receipt of a P2P-DRO message by sending back a P2P-DRO Acknowledgement (P2P-DRO-ACK) message (defined in Section 10). The Origin unicasts a P2P-DRO-ACK message to the Target. If the Target does not receive the requested P2P-DRO-ACK within a certain time interval of sending a P2P-DRO, it resends the P2P-DRO message (up to a certain number of times) carrying the same route as before.
目标可通过发送回P2P-DRO确认（P2P-DRO-ACK）消息（在第10节中定义），请求源站确认收到P2P-DRO消息。源站单播P2P-DRO-ACK消息到目标站。如果目标在发送P2P-DRO的特定时间间隔内未接收到请求的P2P-DRO-ACK，则它将重新发送P2P-DRO消息（最多发送一定次数），该消息将承载与之前相同的路由。
The use of Trickle timers to delay the propagation of DIO messages may cause some nodes to generate these messages even when the desired routes have already been discovered. In order to preempt the generation of such unnecessary messages, the Target may set a "Stop" flag in the P2P-DRO message to let the nodes in the LLN know about the completion of the route discovery process. The routers receiving such a P2P-DRO should not generate any more DIOs for this temporary DAG, nor should they process any received DIOs for this temporary DAG in the future. However, such routers must still process the P2P-DROs received for this temporary DAG.
使用涓流计时器延迟DIO消息的传播可能会导致某些节点生成这些消息，即使在已发现所需路由的情况下也是如此。为了抢占此类不必要消息的生成，目标可以在P2P-DRO消息中设置“停止”标志，以让LLN中的节点知道路由发现过程的完成。接收此类P2P-DRO的路由器不应为该临时DAG生成更多的DIO，也不应在将来为该临时DAG处理任何接收到的DIO。然而，这样的路由器仍然必须处理为这个临时DAG接收的P2P DRO。
This section specifies a new RPL Mode of Operation (MOP), P2P Route Discovery mode (or P2P mode, for short), with value 4. A DIO message listing P2P mode as the MOP is identified as performing a P2P-RPL route discovery by creating a temporary DAG. A P2P mode DIO MUST carry exactly one P2P Route Discovery Option (P2P-RDO, specified in Section 7).
本节指定一个新的RPL操作模式（MOP）、P2P路由发现模式（简称P2P模式），值为4。将P2P模式列为MOP的DIO消息被标识为通过创建临时DAG来执行P2P-RPL路由发现。P2P模式DIO必须正好携带一个P2P路由发现选项（第7节中指定的P2P-RDO）。
The Base object in a P2P mode DIO message MUST be set in the following manner:
P2P模式DIO消息中的基本对象必须按以下方式设置：
o RPLInstanceID: RPLInstanceID MUST be a local value as described in Section 5.1 of [RFC6550]. The Origin chooses the RPLInstanceID to be used for a particular route discovery in accordance with the following rules:
o RPLInstanceID:RPLInstanceID必须是[RFC6550]第5.1节所述的本地值。始发站根据以下规则选择用于特定路由发现的RPLInstanceID：
* The Origin SHOULD NOT reuse a RPLInstanceID for a route discovery if some routers might still maintain membership in the DAG that the Origin had initiated for the previous route discovery using this RPLInstanceID. As described in Section 7,
* 如果某些路由器可能仍然保持源使用此RPLInstanceID为先前路由发现启动的DAG中的成员身份，则源不应将RPLInstanceID重新用于路由发现。如第7节所述，
a router's membership in a DAG created for a P2P-RPL route discovery lasts for the time duration (say, 't' seconds) indicated by the L field inside the P2P-RDO. In general, there is no upper bound on the time duration by when all the routers have left the DAG created for a P2P-RPL route discovery. In the specific case where the discovered route must be at most 'n' hops in length, all the routers must have left the DAG "(n+1)*t" seconds after its initiation by the Origin. In practice, all the routers should have joined the DAG within 't' seconds of its initiation (since the route discovery must complete while the Origin still belongs to the DAG), and hence all the routers should have left the DAG within "2*t" seconds of its initiation. Hence, it is usually sufficient that the Origin wait for twice the duration indicated by the L field inside the P2P-RDO used for the previous route discovery before reusing the RPLInstanceID for a new route discovery. Individual P2P-RPL deployments are encouraged to share their experience with various RPLInstanceID reuse policies to help guide the development of a Standards Track version of the protocol.
路由器在为P2P-RPL路由发现创建的DAG中的成员身份将持续一段时间（例如，“t”秒），由P2P-RDO中的L字段指示。一般来说，当所有路由器离开为P2P-RPL路由发现而创建的DAG时，持续时间没有上限。在发现的路由长度必须最多为“n”个跃点的特定情况下，所有路由器必须在原点启动DAG（n+1）*t”秒后离开DAG。实际上，所有路由器应该在DAG启动后的“t”秒内加入DAG（因为路由发现必须在源站仍然属于DAG时完成），因此所有路由器应该在DAG启动后的“2*t”秒内离开DAG。因此，在重新使用RPLInstanceID进行新的路由发现之前，通常只要原点等待两倍于用于先前路由发现的P2P-RDO内的L字段所指示的持续时间就足够了。鼓励个人P2P-RPL部署分享他们在各种RPLInstanceID重用策略方面的经验，以帮助指导协议标准跟踪版本的开发。
* When initiating a new route discovery to a particular Target, the Origin MUST NOT reuse the RPLInstanceID used in a previous route discovery to this Target if the state created during the previous route discovery might still exist in some routers. Note that it is possible that the previous route discovery did not succeed yet some routers still ended up creating state. The Default Lifetime and Lifetime Unit parameters in the DODAG Configuration Option specify the lifetime of the state that the routers, including the Origin and the Target, maintain for a Hop-by-hop or Source Route discovered using P2P-RPL. Suppose this lifetime is 'X' seconds. As discussed above, any state created during the previous route discovery was likely created within "2*t" seconds of its initiation. Hence, it is sufficient that the Origin lets a time duration equal to "X+2*t" seconds pass since the initiation of the previous route discovery before initiating a new route discovery to the same Target using the same RPLInstanceID.
* 当启动到特定目标的新路由发现时，如果在前一路由发现期间创建的状态可能仍存在于某些路由器中，则源站不得将前一路由发现中使用的RPLInstanceID重用到此目标。请注意，以前的路由发现可能未成功，但某些路由器仍最终创建状态。DODAG配置选项中的默认生存期和生存期单元参数指定路由器（包括源和目标）为使用P2P-RPL发现的逐跳或源路由维护的状态的生存期。假设此生命周期为“X”秒。如上所述，在先前路由发现期间创建的任何状态都可能在其启动后的“2*t”秒内创建。因此，在使用相同的RPLInstanceID启动到相同目标的新路由发现之前，原点允许自上一个路由发现启动以来经过等于“X+2*t”秒的持续时间就足够了。
o Version Number: This field MUST be set to zero. The temporary DAG used for P2P-RPL route discovery does not exist long enough to have new versions.
o 版本号：此字段必须设置为零。用于P2P-RPL路由发现的临时DAG不存在足够长的时间，无法生成新版本。
o Grounded (G) Flag: This flag MUST be set to one. Unlike a global RPL instance, the concept of a floating DAG, used to provide connectivity within a sub-DAG detached from a grounded DAG, does not apply to a local RPL instance. Hence, an Origin MUST always set the G flag to one when initiating a P2P-RPL route discovery.
o 接地（G）标志：此标志必须设置为1。与全局RPL实例不同，用于在从固定DAG分离的子DAG内提供连接的浮动DAG的概念不适用于本地RPL实例。因此，在启动P2P-RPL路由发现时，源站必须始终将G标志设置为1。
Further, item 3 of Section 8.2.2.2 in [RFC6550] does not apply, and a node MUST NOT initiate a new DAG if it does not have any parent left in a P2P-RPL DAG.
此外，[RFC6550]中第8.2.2.2节的第3项不适用，如果节点在P2P-RPL DAG中没有任何父节点，则不得启动新的DAG。
o Mode of Operation (MOP): This field MUST be set to four, corresponding to P2P Route Discovery mode.
o 操作模式（MOP）：此字段必须设置为4，对应于P2P路由发现模式。
o Destination Advertisement Trigger Sequence Number (DTSN): This field MUST be set to zero on transmission and ignored on reception.
o 目的地广告触发序列号（DTSN）：此字段在传输时必须设置为零，在接收时必须忽略。
o DODAGPreference (Prf): This field MUST be set to zero (least preferred).
o DODAGPreference（Prf）：此字段必须设置为零（最低优先）。
o DODAGID: This field MUST be set to an IPv6 address of the Origin.
o DODAGID：此字段必须设置为源IPv6地址。
o The other fields in the DIO Base object can be set in the desired fashion as per the rules described in [RFC6550].
o DIO基本对象中的其他字段可以按照[RFC6550]中描述的规则以所需的方式设置。
A received P2P mode DIO MUST be discarded if it does not follow the above-listed rules regarding the RPLInstanceID, Version Number, G flag, MOP, and Prf fields inside the Base object.
如果接收到的P2P模式DIO不遵循上面列出的关于基本对象内RPLInstanceID、版本号、G标志、MOP和Prf字段的规则，则必须丢弃该DIO。
The DODAG Configuration Option inside a P2P mode DIO MUST be set in the following manner:
P2P模式DIO内的DODAG配置选项必须按以下方式设置：
o The Origin MUST set the MaxRankIncrease parameter to zero to disable local repair of the temporary DAG. A received P2P mode DIO MUST be discarded if the MaxRankIncrease parameter inside the DODAG Configuration Option is not zero.
o 原点必须将MaxRankIncrease参数设置为零，以禁用临时DAG的本地修复。如果DODAG配置选项中的MaxRankIncrease参数不为零，则必须丢弃接收到的P2P模式DIO。
o The Origin SHOULD set the Trickle parameters (DIOIntervalDoublings, DIOIntervalMin, DIORedundancyConstant) as recommended in Section 9.2.
o 原点应按照第9.2节中的建议设置涓流参数（DIOIntervalDoublings、DIOIntervalMin、DIORedundancyConstant）。
o The Origin sets the Default Lifetime and Lifetime Unit parameters to indicate the lifetime of the state that the routers, including the Origin and the Target(s), maintain for a Hop-by-hop or Source Route discovered using P2P-RPL.
o 原点设置默认生存期和生存期单位参数，以指示路由器（包括原点和目标）为使用P2P-RPL发现的逐跳或源路由维护的状态的生存期。
o The Origin sets the other fields in the DODAG Configuration Option, including the Objective Code Point (OCP) identifying the Objective Function, in the desired fashion as per the rules described in [RFC6550].
o 原点按照[RFC6550]中描述的规则，以所需方式设置DODAG配置选项中的其他字段，包括识别目标函数的目标代码点（OCP）。
o As discussed in Section 14, P2P-RPL does not distinguish between the "preinstalled" and "authenticated" security modes described in [RFC6550]. Consequently, the Origin MUST set the Authentication Enabled (A) flag to zero. A received P2P mode DIO MUST be discarded if the A flag inside the DODAG Configuration Option is not zero.
o 如第14节所述，P2P-RPL不区分[RFC6550]中所述的“预安装”和“认证”安全模式。因此，源站必须将身份验证启用（A）标志设置为零。如果DODAG配置选项中的A标志不为零，则必须丢弃接收到的P2P模式DIO。
o An Intermediate Router (or a Target) MUST set various fields in the DODAG Configuration Option in the outgoing P2P mode DIOs to the values they had in the incoming P2P mode DIOs for this DAG.
o 中间路由器（或目标）必须将传出P2P模式DIOs中DODAG配置选项中的各个字段设置为它们在传入P2P模式DIOs中为此DAG设置的值。
A default DODAG Configuration Option takes effect if a P2P mode DIO does not carry an explicit one. The default DODAG Configuration Option has the following parameter values:
如果P2P模式DIO没有显式配置，则默认的DODAG配置选项将生效。默认DODAG配置选项具有以下参数值：
o Authentication Enabled: 0
o 已启用身份验证：0
o DIOIntervalMin: 6, which translates to 64 ms as the value for the Imin parameter in a Trickle operation. This value is roughly one order of magnitude larger than the typical transmission delay on IEEE 802.15.4 links and corresponds to the recommendation in Section 9.2 for well-connected topologies.
o DIOIntervalMin:6，在涓流操作中转换为64 ms作为Imin参数的值。该值大约比IEEE 802.15.4链路上的典型传输延迟大一个数量级，对应于第9.2节中关于良好连接拓扑的建议。
o DIORedundancyConstant: 1. See the discussion in Section 9.2.
o 双余度常数：1。见第9.2节中的讨论。
o MaxRankIncrease: 0 (to disable local repair of the temporary DAG).
o MaxRankIncrease:0（用于禁用临时DAG的本地修复）。
o Default Lifetime: 0xFF, to correspond to infinity.
o 默认生存期：0xFF，对应于无穷大。
o Lifetime Unit: 0xFFFF, to correspond to infinity.
o 寿命单位：0xFFFF，对应无穷大。
o Objective Code Point: 0, i.e., OF0 [RFC6552] is the default Objective Function (OF).
o 目标代码点：0，即OF0[RFC6552]是默认的目标函数（OF）。
o The remaining parameters have default values as specified in [RFC6550].
o 其余参数具有[RFC6550]中指定的默认值。
Individual P2P-RPL deployments are encouraged to share their experience with these default values to help guide the development of a Standards Track version of the protocol.
鼓励个人P2P-RPL部署分享其使用这些默认值的经验，以帮助指导协议标准跟踪版本的开发。
The routing metrics and constraints [RFC6551] used in P2P-RPL route discovery are included in one or more Metric Container options [RFC6550] inside the P2P mode DIO. Note that a DIO need not include a Metric Container if OF0 is the Objective Function in effect. In that case, a P2P mode DIO may still specify an upper limit on the maximum rank, that a router may have in the temporary DAG, inside the P2P-RDO.
P2P-RPL路由发现中使用的路由度量和约束[RFC6551]包含在P2P模式DIO内的一个或多个度量容器选项[RFC6550]中。请注意，如果OF0是有效的目标函数，则DIO不需要包含度量容器。在这种情况下，P2P模式DIO仍然可以在P2P-RDO内指定路由器在临时DAG中可能具有的最大秩的上限。
A P2P mode DIO:
P2P模式DIO：
o MUST carry one (and only one) P2P-RDO. The P2P-RDO allows for the specification of one unicast or multicast address for the Target. A received P2P mode DIO MUST be discarded if it does not contain exactly one P2P-RDO.
o 必须携带一个（且仅一个）P2P-RDO。P2P-RDO允许为目标指定一个单播或多播地址。如果接收到的P2P模式DIO不包含一个P2P-RDO，则必须丢弃该DIO。
o MAY carry one or more RPL Target options to specify additional unicast/multicast addresses for the Target. If a unicast address is specified, it MUST be a global address or a unique-local address.
o 可以携带一个或多个RPL目标选项，为目标指定额外的单播/多播地址。如果指定了单播地址，则该地址必须是全局地址或唯一的本地地址。
o MAY carry one or more Metric Container options to specify routing metrics and constraints.
o 可以携带一个或多个度量容器选项来指定路由度量和约束。
o MAY carry one or more Route Information Options [RFC6550]. In the context of P2P-RPL, a Route Information Option advertises to the Target(s) the Origin's connectivity to the prefix specified in the option.
o 可携带一个或多个路线信息选项[RFC6550]。在P2P-RPL的上下文中，路由信息选项向目标播发源站到该选项中指定前缀的连接。
o MAY carry one DODAG Configuration Option. If a P2P mode DIO does not carry an explicit DODAG Configuration Option, the default DODAG Configuration Option defined in this section is considered to be in effect.
o 可携带一个DODAG配置选项。如果P2P模式DIO没有明确的DODAG配置选项，则本节中定义的默认DODAG配置选项视为有效。
A RPL option other than those listed above MUST be ignored when found inside a received P2P mode DIO and MUST NOT be included in the P2P mode DIOs that the receiving router generates.
当在接收到的P2P模式DIO中找到RPL选项时，必须忽略上面列出的选项以外的RPL选项，并且不得包含在接收路由器生成的P2P模式DIO中。
In accordance with core RPL, a P2P mode DIO MUST propagate via link-local multicast. The IPv6 source address in a P2P mode DIO MUST be a link-local address, and the IPv6 destination address MUST be the link-local multicast address all-RPL-nodes [RFC6550]. A P2P mode DIO MUST be transmitted on all interfaces the router has in this RPL routing domain [RFC6554].
根据核心RPL，P2P模式DIO必须通过链路本地多播进行传播。P2P模式DIO中的IPv6源地址必须是链路本地地址，IPv6目标地址必须是所有RPL节点的链路本地多播地址[RFC6550]。必须在路由器在此RPL路由域中的所有接口上传输P2P模式DIO[RFC6554]。
This section defines a new RPL control message option: the P2P Route Discovery Option (P2P-RDO).
本节定义了一个新的RPL控制消息选项：P2P路由发现选项（P2P-RDO）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x0a | Option Length |R|H| N | Compr | L |MaxRank/NH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| TargetAddr |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address[1..n] |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x0a | Option Length |R|H| N | Compr | L |MaxRank/NH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| TargetAddr |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address[1..n] |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format of the P2P Route Discovery Option (P2P-RDO)
图1:P2P路由发现选项（P2P-RDO）的格式
The format of a P2P Route Discovery Option (P2P-RDO) is illustrated in Figure 1. A P2P mode DIO and a P2P-DRO message (defined in Section 8) MUST carry exactly one P2P-RDO. A P2P-RDO consists of the following fields:
P2P路由发现选项（P2P-RDO）的格式如图1所示。P2P模式DIO和P2P-DRO消息（定义见第8节）必须正好携带一个P2P-RDO。P2P-RDO由以下字段组成：
o Option Type: 0x0a.
o 选项类型：0x0a。
o Option Length: This field is an 8-bit unsigned integer representing the length in octets of the option, not including the Option Type and Option Length fields.
o 选项长度：此字段是一个8位无符号整数，表示选项的长度（以八位字节为单位），不包括选项类型和选项长度字段。
o Reply (R): The Origin sets this flag to one to allow the Target(s) to send P2P-DRO messages back to the Origin. If this flag is set to zero, a Target MUST NOT generate any P2P-DRO messages.
o 回复（R）：源站将此标志设置为1，以允许目标站将P2P-DRO消息发送回源站。如果此标志设置为零，则目标不得生成任何P2P-DRO消息。
o Hop-by-hop (H): This flag is valid only if the R flag is set to one. The Origin sets this flag to one if it desires Hop-by-hop Routes. The Origin sets this flag to zero if it desires Source Routes. This specification allows for the establishment of one Hop-by-hop Route or up to four Source Routes per Target. The Hop-by-hop Route is established in the Forward direction, i.e., from the Origin to the Target. This specification does not allow for the establishment of Hop-by-hop Routes in the Reverse direction.
o 逐跳（H）：仅当R标志设置为1时，此标志才有效。如果需要逐跳路由，则原点将此标志设置为1。如果需要源路由，则原点将此标志设置为零。该规范允许为每个目标建立一个逐跳路由或最多四个源路由。逐跳路由在前进方向上建立，即从原点到目标。本规范不允许反向建立逐跳路由。
o Number of Routes (N): This field is valid only if the R flag is set to one and the H flag is set to zero, i.e., the Targets are allowed to generate P2P-DRO messages carrying discovered Source Routes back to the Origin. In this case, the value in the N field plus one indicates the number of Source Routes that each Target should convey to the Origin. When Hop-by-hop Routes are being discovered, the N field MUST be set to zero on transmission and ignored on reception.
o 路由数（N）：仅当R标志设置为1，H标志设置为0时，此字段才有效，即允许目标生成将发现的源路由带回源的P2P-DRO消息。在这种情况下，N字段中的值加上1表示每个目标应传送到原点的源路由数。当逐跳路由被发现时，N字段在传输时必须设置为零，在接收时必须忽略。
o Compr: This field is a 4-bit unsigned integer indicating the number of prefix octets that are elided from the Target field and the Address vector. For example, the Compr value will be zero if full IPv6 addresses are carried in the Target field and the Address vector.
o Compr：该字段是一个4位无符号整数，指示从目标字段和地址向量中删除的前缀八位字节数。例如，如果在目标字段和地址向量中包含完整的IPv6地址，则Compr值将为零。
o Lifetime (L): This is a 2-bit field that indicates the exact duration that a router joining the temporary DAG, including the Origin and the Target(s), MUST maintain its membership in the DAG. A router MUST leave the temporary DAG once the time elapsed since it joined reaches the value indicated by this field. The mapping between the value in this field and the duration of the router's membership in the temporary DAG is as follows:
o 生存期（L）：这是一个2位字段，指示加入临时DAG（包括原点和目标）的路由器必须保持其在DAG中的成员身份的确切持续时间。一旦路由器加入后经过的时间达到此字段指示的值，路由器必须离开临时DAG。此字段中的值与路由器在临时DAG中的成员身份持续时间之间的映射如下：
* 0x00: 1 second
* 0x00:1秒
* 0x01: 4 seconds
* 0x01:4秒
* 0x02: 16 seconds
* 0x02:16秒
* 0x03: 64 seconds
* 0x03:64秒
The Origin sets this field based on its expectation regarding the time required for the route discovery to complete, which includes the time required for the DIOs to reach the Target(s) and the P2P-DROs to travel back to the Origin. The time required for the DIOs to reach the Target(s) would in turn depend on the Trickle parameters (Imin and the redundancy constant) as well as the expected distance (in terms of hops and/or ETX) to the Target(s). While deciding on the value in this field, the Origin should also take into account the fact that all routers joining the temporary DAG would need to stay in the DAG for this much time.
源站根据其对完成路由发现所需时间的预期设置此字段，其中包括DIO到达目标和P2P DRO返回源站所需的时间。DIO到达目标所需的时间依次取决于涓流参数（Imin和冗余常数）以及到目标的预期距离（以跳数和/或ETX为单位）。在决定此字段中的值时，原点还应考虑以下事实：所有加入临时DAG的路由器都需要在DAG中停留这么长时间。
o MaxRank/NH:
o MaxRank/NH：
* When a P2P-RDO is included in a P2P mode DIO, this field indicates the upper limit on the integer portion of the rank (calculated using the DAGRank() macro defined in [RFC6550]) that a router may have in the temporary DAG being created. An Intermediate Router MUST NOT join a temporary DAG being created by a P2P mode DIO if the integer portion of its rank would be equal to or higher (in numerical value) than the MaxRank limit. A Target can join the temporary DAG at a rank whose integer portion is equal to the MaxRank. A router MUST discard a received P2P mode DIO if the integer part of the advertised rank equals or exceeds the MaxRank limit. A value of 0 in this field indicates that the MaxRank is infinity.
* 当P2P-RDO包含在P2P模式DIO中时，此字段表示路由器在创建的临时DAG中可能具有的秩整数部分的上限（使用[RFC6550]中定义的DAGRank（）宏计算）。如果中间路由器的秩的整数部分等于或高于MaxRank限制（数值），则中间路由器不得加入由P2P模式DIO创建的临时DAG。目标可以在整数部分等于MaxRank的秩处加入临时DAG。如果播发秩的整数部分等于或超过MaxRank限制，路由器必须丢弃接收到的P2P模式DIO。此字段中的值为0表示MaxRank为无穷大。
* When a P2P-RDO is included in a P2P-DRO message, this field indicates the index of the next-hop (NH) address inside the Address vector.
* 当P2P-RDO包含在P2P-DRO消息中时，此字段指示地址向量内下一跳（NH）地址的索引。
o TargetAddr: This is an IPv6 address of the Target after eliding Compr number of prefix octets. When the P2P-RDO is included in a P2P mode DIO, this field may contain a unicast address or a multicast address. If a unicast address is specified, it MUST be a global address or a unique-local address. Any additional Target addresses can be specified by including one or more RPL Target options [RFC6550] in the DIO. When the P2P-RDO is included in a P2P-DRO, this field MUST contain a unicast global or unique-local IPv6 address of the Target generating the P2P-DRO.
o TargetAddress：这是目标的IPv6地址，省略了前缀八位字节的Compr数。当P2P-RDO包括在P2P模式DIO中时，该字段可能包含单播地址或多播地址。如果指定了单播地址，则该地址必须是全局地址或唯一的本地地址。通过在DIO中包含一个或多个RPL目标选项[RFC6550]，可以指定任何其他目标地址。当P2P-RDO包含在P2P-DRO中时，此字段必须包含生成P2P-DRO的目标的单播全局或唯一本地IPv6地址。
o Address[1..n]: This is a vector of IPv6 addresses representing a complete route so far in the Forward direction:
o 地址[1..n]：这是一个IPv6地址向量，表示到目前为止在正向上的完整路由：
* Each element in the Address vector has size (16 - Compr) octets and MUST contain a valid global or unique-local IPv6 address with the first Compr octets elided.
* 地址向量中的每个元素都有大小（16-Compr）八位字节，并且必须包含一个有效的全局或唯一的本地IPv6地址，并省略第一个Compr八位字节。
* The total number of elements inside the Address vector is given by n = (Option Length - 2 - (16 - Compr))/(16 - Compr).
* 地址向量内的元素总数由n=（选项长度-2-（16-Compr））/（16-Compr）给出。
* The IPv6 address that a router adds to the vector MUST belong to the interface on which the router received the DIO containing this P2P-RDO. Further, this interface MUST NOT be an Ingress-only Interface. This allows the route accumulated in the Address vector to be a Bidirectional Route that can be used by a Target to send a P2P-DRO message to the Origin.
* 路由器添加到向量的IPv6地址必须属于路由器接收包含此P2P-RDO的DIO的接口。此外，该接口不得为仅入口接口。这使得地址向量中累积的路由成为双向路由，目标可以使用该双向路由向源发送P2P-DRO消息。
* The Address vector MUST carry the accumulated route in the Forward direction, i.e., the first element in the Address vector must contain the IPv6 address of the router next to the Origin, and so on.
* 地址向量必须在前进方向上承载累积路由，即地址向量中的第一个元素必须包含位于原点旁边的路由器的IPv6地址，依此类推。
* The Origin and Target addresses MUST NOT be included in the Address vector.
* 地址向量中不得包含源地址和目标地址。
* A router adding its address to the vector MUST ensure that none of its addresses already exist in the vector. A Target specifying a complete route in the Address vector MUST ensure that the vector does not contain any address more than once.
* 向向量添加其地址的路由器必须确保向量中不存在其地址。在地址向量中指定完整路由的目标必须确保该向量不多次包含任何地址。
* The Address vector MUST NOT contain any multicast addresses.
* 地址向量不得包含任何多播地址。
This section defines two new RPL control message types: the P2P Discovery Reply Object (P2P-DRO), with code 0x04; and the Secure P2P-DRO, with code 0x84. A P2P-DRO serves one of the following functions:
本节定义了两种新的RPL控制消息类型：P2P发现回复对象（P2P-DRO），代码为0x04；以及安全的P2P-DRO，代码为0x84。P2P-DRO具有以下功能之一：
o carries a discovered Source Route from a Target to the Origin;
o 携带从目标到原点的已发现源路由；
o establishes a Hop-by-hop Route as it travels from a Target to the Origin.
o 建立从目标到原点的逐跳路由。
A P2P-DRO message can also serve the function of letting the routers in the LLN know that a P2P-RPL route discovery is complete and no more DIO messages need to be generated for the corresponding temporary DAG. A P2P-DRO message MUST carry one (and only one) P2P-RDO whose TargetAddr field MUST contain a unicast IPv6 address of the Target that generates the P2P-DRO. A P2P-DRO message MUST travel from the Target to the Origin via link-local multicast along the route specified inside the Address vector in the P2P-RDO, as included in the P2P-DRO. The IPv6 source address in a P2P-DRO message MUST be a link-local address, and the IPv6 destination address MUST be the link-local multicast address all-RPL-nodes [RFC6550]. A P2P-DRO message MUST be transmitted on all interfaces the router has in this RPL routing domain [RFC6554].
P2P-DRO消息还可以用于让LLN中的路由器知道P2P-RPL路由发现已完成，并且不需要为相应的临时DAG生成更多的DIO消息。P2P-DRO消息必须携带一个（且仅一个）P2P-RDO，其targetAddress字段必须包含生成P2P-DRO的目标的单播IPv6地址。P2P-DRO消息必须沿着P2P-RDO中地址向量内指定的路由（如P2P-DRO中所包含的）通过链路本地多播从目标传输到源。P2P-DRO消息中的IPv6源地址必须是链路本地地址，IPv6目标地址必须是所有RPL节点的链路本地多播地址[RFC6550]。必须在路由器在此RPL路由域中的所有接口上传输P2P-DRO消息[RFC6554]。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID | Version |S|A|Seq| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| DODAGID |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID | Version |S|A|Seq| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| DODAGID |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
Figure 2: Format of the Base P2P Discovery Reply Object (P2P-DRO)
图2：基本P2P发现回复对象（P2P-DRO）的格式
The format of the base P2P Discovery Reply Object (P2P-DRO) is shown in Figure 2. A base P2P-DRO consists of the following fields:
基本P2P发现回复对象（P2P-DRO）的格式如图2所示。基本P2P-DRO由以下字段组成：
o RPLInstanceID: This field provides the RPLInstanceID of the temporary DAG used for route discovery.
o RPLInstanceID：此字段提供用于路由发现的临时DAG的RPLInstanceID。
o Version: This field provides the Version of the temporary DAG used for route discovery. Since a temporary DAG always has value zero for the Version, this field MUST always be set to zero.
o 版本：此字段提供用于路由发现的临时DAG的版本。由于版本的临时DAG值始终为零，因此此字段必须始终设置为零。
o Stop (S): This flag, when set to one by a Target, indicates that the P2P-RPL route discovery is over. All the routers receiving such a P2P-DRO, including those not listed in the route carried inside a P2P-RDO,
o 停止：当目标将此标志设置为1时，表示P2P-RPL路由发现已结束。接收此类P2P-DRO的所有路由器，包括P2P-RDO内携带的路由中未列出的路由器，
* SHOULD NOT process any more DIOs received for this temporary DAG;
* 不应再处理该临时DAG收到的任何DIO；
* SHOULD NOT generate any more DIOs for this temporary DAG;
* 不应为此临时DAG生成更多DIO；
* SHOULD cancel any pending DIO transmissions for this temporary DAG.
* 应取消此临时DAG的任何挂起的DIO传输。
Note that the Stop flag serves to stop further DIO generation/processing for a P2P-RPL route discovery but does not affect the processing of P2P-DRO messages at either the Origin or the Intermediate Routers. In other words, a router (the Origin or an Intermediate Router) MUST continue to process the P2P-DRO messages even if an earlier P2P-DRO message (with the same RPLInstanceID and DODAGID fields) had the Stop flag set to one. When set to zero, this flag does not imply anything and MUST be ignored on reception.
注意，停止标志用于停止P2P-RPL路由发现的进一步DIO生成/处理，但不影响源路由器或中间路由器处的P2P-DRO消息处理。换句话说，即使较早的P2P-DRO消息（具有相同的RPLInstanceID和DODAGID字段）的停止标志设置为1，路由器（源或中间路由器）也必须继续处理P2P-DRO消息。设置为零时，此标志不表示任何含义，在接收时必须忽略。
o Ack Required (A): This flag, when set to one by the Target, indicates that the Origin MUST unicast a P2P-DRO-ACK message (defined in Section 10) to the Target when it receives the P2P-DRO.
o Ack Required（A）：当目标将此标志设置为1时，表示源站在接收到P2P-DRO时必须单播P2P-DRO-Ack消息（定义见第10节）。
o Sequence Number (Seq): This 2-bit field indicates the sequence number for the P2P-DRO. This field is relevant when the A flag is set to one, i.e., the Target requests an acknowledgement from the Origin for a received P2P-DRO. The Origin includes the RPLInstanceID, the DODAGID, and the Sequence Number of the received P2P-DRO inside the P2P-DRO-ACK message it sends back to the Target.
o 序列号（Seq）：此2位字段表示P2P-DRO的序列号。当A标志设置为1时，该字段是相关的，即，目标为接收到的P2P-DRO请求来自源的确认。来源包括RPLInstanceID、DODAGID和它发送回目标的P2P-DRO-ACK消息中接收到的P2P-DRO的序列号。
o Reserved: These bits are reserved for future use. These bits MUST be set to zero on transmission and MUST be ignored on reception.
o 保留：这些位保留供将来使用。这些位在传输时必须设置为零，在接收时必须忽略。
o DODAGID: This field provides the DODAGID of the temporary DAG used for route discovery. The DODAGID also identifies the Origin. The RPLInstanceID, the Version, and the DODAGID together uniquely identify the temporary DAG used for route discovery and can be copied from the DIO message advertising the temporary DAG.
o DODAGID：此字段提供用于路由发现的临时DAG的DODAGID。DODAGID还标识了原点。RPLInstanceID、Version和DODAGID一起唯一标识用于路由发现的临时DAG，并且可以从发布临时DAG的DIO消息中复制。
o Options: The P2P-DRO message:
o 选项：P2P-DRO消息：
* MUST carry one (and only one) P2P-RDO that MUST specify a complete route between the Target and the Origin. A received P2P-DRO message MUST be discarded if it does not contain exactly one P2P-RDO.
* 必须携带一个（且仅一个）P2P-RDO，该P2P-RDO必须指定目标和源之间的完整路由。如果接收到的P2P-DRO消息不包含一个P2P-RDO，则必须丢弃该消息。
* MAY carry one or more Metric Container options that contain the aggregated routing metrics values for the route specified in the P2P-RDO.
* 可以携带一个或多个度量容器选项，其中包含P2P-RDO中指定的路由的聚合路由度量值。
A RPL option other than those listed above MUST be ignored when found inside a received P2P-DRO message.
当在接收到的P2P-DRO消息中找到RPL选项时，必须忽略上面列出的选项以外的其他选项。
A Secure P2P-DRO message follows the format shown in Figure 7 of [RFC6550], where the base format is the base P2P-DRO shown in Figure 2.
安全的P2P-DRO消息遵循[RFC6550]中图7所示的格式，其中基本格式是图2中所示的基本P2P-DRO。
A P2P Discovery Reply Object MUST carry one (and only one) P2P-RDO, which MUST be set as defined in Section 7. Specifically, the following fields MUST be set as follows:
P2P发现应答对象必须携带一个（并且只有一个）P2P-RDO，必须按照第7节中的定义进行设置。具体而言，必须按如下方式设置以下字段：
o Reply (R): This flag MUST be set to zero on transmission and ignored on reception.
o 回复（R）：此标志必须在传输时设置为零，在接收时忽略。
o Hop-by-Hop (H): The H flag in the P2P-RDO included in a P2P-DRO message MUST have the same value as the H flag in the P2P-RDO inside the corresponding DIO message.
o 逐跳（H）：P2P-DRO消息中包含的P2P-RDO中的H标志必须与相应DIO消息中的P2P-RDO中的H标志具有相同的值。
o Number of Routes (N): This field MUST be set to zero on transmission and ignored on reception.
o 路由数（N）：此字段在传输时必须设置为零，在接收时必须忽略。
o Lifetime (L): This field MUST be set to zero on transmission and ignored on reception.
o 寿命（L）：此字段在传输时必须设置为零，在接收时必须忽略。
o MaxRank/NH: This field indicates the index of the next-hop address in the Address vector. When a Target generates a P2P-DRO message, the NH field is set to n = (Option Length - 2 - (16 - Compr))/ (16 - Compr).
o MaxRank/NH：此字段指示地址向量中下一个跃点地址的索引。当目标生成P2P-DRO消息时，NH字段设置为n=（选项长度-2-（16-Compr））/（16-Compr）。
o TargetAddr: This field MUST contain a unicast global or unique-local IPv6 address of the Target generating the P2P-DRO.
o TargetAddress：此字段必须包含生成P2P-DRO的目标的单播全局或唯一本地IPv6地址。
o Address[1..n]: The Address vector MUST contain a complete route between the Origin and the Target such that the first element in the vector contains the IPv6 address of the router next to the Origin and the last element contains the IPv6 address of the router next to the Target.
o 地址[1..n]：地址向量必须包含源站和目标站之间的完整路由，以便向量中的第一个元素包含源站旁边路由器的IPv6地址，最后一个元素包含目标站旁边路由器的IPv6地址。
This section details the P2P-RPL route discovery operation.
本节详细介绍了P2P-RPL路由发现操作。
All the routers participating in a P2P-RPL route discovery, including the Origin and the Target(s), MUST join the temporary DAG being created for that purpose. When a router joins a temporary DAG advertised by a P2P mode DIO, it MUST maintain its membership in the temporary DAG for the duration indicated by the L field inside the P2P-RDO. The only purpose of a temporary DAG's existence is to facilitate the P2P-RPL route discovery process. The temporary DAG MUST NOT be used to route data packets. In other words, joining a temporary DAG does not allow a router to provision routing table
参与P2P-RPL路由发现的所有路由器，包括源和目标，必须加入为此目的创建的临时DAG。当路由器加入由P2P模式DIO公布的临时DAG时，它必须在P2P-RDO内的L字段指示的持续时间内保持其在临时DAG中的成员身份。临时DAG存在的唯一目的是促进P2P-RPL路由发现过程。临时DAG不得用于路由数据包。换句话说，加入临时DAG不允许路由器提供路由表
entries listing the router's parents in the temporary DAG as the next hops (i.e., the last bullet point in Section 3.2.8 of [RFC6550] is not applicable when the DAG is a temporary DAG created for the purpose of a P2P-RPL route discovery).
将临时DAG中的路由器父节点列为下一个跃点的条目（即，[RFC6550]第3.2.8节中的最后一个项目符号不适用于为P2P-RPL路由发现而创建的临时DAG）。
Given the nature of a temporary DAG created for a P2P-RPL route discovery, this document disallows the solicitation of P2P mode DIOs using DODAG Information Solicitation (DIS) messages as described in [RFC6550]. A router participating in a P2P-RPL route discovery MUST NOT reset its Trickle timer, which controls the transmission of P2P mode DIOs in response to a multicast DIS. Also, the router MUST NOT send a P2P mode DIO in response to a unicast DIS. In other words, the rules in Section 8.3 of [RFC6550] regarding a router's response to a multicast/unicast DIS are not applicable for P2P mode DIOs.
鉴于为P2P-RPL路由发现创建的临时DAG的性质，本文件不允许使用[RFC6550]中所述的DODAG信息请求（DIS）消息请求P2P模式DIO。参与P2P-RPL路由发现的路由器不得重置其涓流计时器，该计时器控制P2P模式DIO的传输以响应多播DIS。此外，路由器不得发送P2P模式DIO以响应单播DIS。换句话说，[RFC6550]第8.3节中关于路由器对多播/单播DIS的响应的规则不适用于P2P模式DIO。
A router MUST detach from the temporary DAG created for a P2P-RPL route discovery once the duration of its membership in the DAG has reached the value indicated by the L field inside the P2P-RDO. After receiving a P2P-DRO with the Stop flag set to one, a router SHOULD NOT send or process any more DIOs for this temporary DAG and SHOULD also cancel any pending DIO transmissions.
一旦路由器在DAG中的成员身份持续时间达到P2P-RDO中的L字段所指示的值，路由器必须与为P2P-RPL路由发现创建的临时DAG分离。在接收到停止标志设置为1的P2P-DRO后，路由器不应为此临时DAG发送或处理任何更多的DIO，还应取消任何挂起的DIO传输。
A RPL router uses a Trickle timer [RFC6206] to control DIO transmissions. The Trickle control of DIO transmissions provides quick resolution of any "inconsistency" while avoiding redundant DIO transmissions. The Trickle algorithm also imparts protection against loss of DIOs due to inherent lack of reliability in LLNs. When controlling the transmissions of a P2P mode DIO, a Trickle timer SHOULD follow the following rules:
RPL路由器使用涓流定时器[RFC6206]来控制DIO传输。DIO传输的涓流控制可快速解决任何“不一致”，同时避免冗余DIO传输。涓流算法还提供保护，防止由于LLN固有的可靠性不足而丢失DIO。控制P2P模式DIO的传输时，涓流计时器应遵循以下规则：
o The receipt of a P2P mode DIO that allows the router to advertise a better route (in terms of the routing metrics and the OF in use) than before is considered "inconsistent" and hence resets the Trickle timer. Note that the first receipt of a P2P mode DIO advertising a particular temporary DAG is always considered an "inconsistent" event.
o 接收到允许路由器公布比以前更好的路由的P2P模式DIO（就路由度量和使用中的of而言）被认为是“不一致的”，因此重置涓流计时器。请注意，第一次收到P2P模式DIO广告特定临时DAG始终被视为“不一致”事件。
o The receipt of a P2P mode DIO from a parent in the temporary DAG is considered neither "consistent" nor "inconsistent" if it does not allow the router to advertise a better route than before. Thus, the receipt of such DIOs has no impact on the Trickle operation. Note that this document does not impose any requirements on how a router might choose its parents in the temporary DAG.
o 如果不允许路由器公布比以前更好的路由，则从临时DAG中的父级接收到的P2P模式DIO既不“一致”，也不“不一致”。因此，收到此类DIO对涓流操作没有影响。请注意，本文档没有对路由器如何在临时DAG中选择其父级提出任何要求。
o The receipt of a P2P mode DIO is considered "consistent" if the source of the DIO is not a parent in the temporary DAG and either of the following conditions is true:
o 如果DIO的源不是临时DAG中的父级，并且以下任一条件为真，则P2P模式DIO的接收被视为“一致”：
* The DIO advertises a better route than the router but does not allow the router to advertise a better route itself; or
* DIO宣传比路由器更好的路由，但不允许路由器宣传更好的路由；或
* The DIO advertises a route as good as the route (to be) advertised by the router.
* DIO播发的路由与路由器播发的路由一样好。
Note that the Trickle algorithm's DIO suppression rules are in effect at all times. Hence, a P2P-RPL router may suppress a DIO transmission even if it has not made any DIO transmissions yet.
请注意，涓流算法的DIO抑制规则始终有效。因此，即使尚未进行任何DIO传输，P2P-RPL路由器也可以抑制DIO传输。
o The receipt of a P2P mode DIO that advertises a worse route than what the router advertises (or would advertise when it gets a chance to generate its DIO) is considered neither "consistent" nor "inconsistent", i.e., the receipt of such a DIO has no impact on the Trickle operation.
o 接收到的P2P模式DIO所播发的路由比路由器所播发的路由更差（或在有机会生成其DIO时会播发），既不被视为“一致”也不被视为“不一致”，即接收到这样的DIO对涓流操作没有影响。
o The Imin parameter SHOULD be set taking into account the connectivity within the network. For highly connected networks, a small Imin value (on the order of the typical transmission delay for a DIO) may lead to congestion in the network as a large number of routers reset their Trickle timers in response to the first receipt of a DIO from the Origin. These routers would generate their DIOs within the Imin interval and cause additional routers to reset their Trickle timers and generate more DIOs. Thus, for highly connected networks, the Imin parameter SHOULD be set to a value at least one order of magnitude larger than the typical transmission delay for a DIO. For sparsely connected networks, the Imin parameter can be set to a value that is a small multiple of the typical transmission delay for a DIO. Note that the Imin value has a direct impact on the time required for a P2P-RPL route discovery to complete. In general, the time required for a P2P-RPL route discovery would increase approximately linearly with the value of the Imin parameter. Since the route discovery must complete while the Origin still belongs to the temporary DAG created for that purpose, the Origin should set the time duration for which a router maintains its membership in the temporary DAG (indicated by the L field inside the P2P-RDO) to a large enough value, taking into account the Imin value as well as the expected distance (in terms of hops and/or ETX) to the Target(s).
o Imin参数的设置应考虑到网络内的连接性。对于高度连接的网络，较小的Imin值（相当于DIO的典型传输延迟的数量级）可能会导致网络拥塞，因为大量路由器会在第一次从源站接收到DIO时重置其涓流计时器。这些路由器将在Imin间隔内生成DIO，并导致其他路由器重置其滴流计时器并生成更多DIO。因此，对于高度连接的网络，Imin参数应设置为比DIO的典型传输延迟至少大一个数量级的值。对于稀疏连接的网络，Imin参数可以设置为DIO典型传输延迟的小倍数。请注意，Imin值直接影响完成P2P-RPL路由发现所需的时间。通常，P2P-RPL路由发现所需的时间将随着Imin参数的值近似线性增加。由于路由发现必须在源站仍然属于为此目的创建的临时DAG时完成，因此源站应将路由器在临时DAG中保持其成员身份的持续时间（由P2P-RDO中的L字段指示）设置为足够大的值，考虑Imin值以及到目标的预期距离（以跳数和/或ETX为单位）。
o The Imax parameter SHOULD be set to a large value (several orders of magnitude higher than the Imin value) and is unlikely to be critical for P2P-RPL operation. This is because the first receipt of a P2P mode DIO for a particular temporary DAG is considered an inconsistent event and would lead to the resetting of the Trickle timer duration to the Imin value. Given the temporary nature of the DAGs used in P2P-RPL, the Trickle timer may not get a chance to increase much.
o Imax参数应设置为一个较大的值（比Imin值高几个数量级），并且不太可能对P2P-RPL操作至关重要。这是因为针对特定临时DAG的P2P模式DIO的首次接收被视为不一致事件，并将导致涓流计时器持续时间重置为Imin值。鉴于P2P-RPL中使用的DAG的临时性，涓流计时器可能没有机会增加太多。
o The recommended value of redundancy constant "k" is 1. With this value of "k", a DIO transmission will be suppressed if the router receives even a single "consistent" DIO during a timer interval. This setting for the redundancy constant is designed to reduce the number of messages generated during a route discovery process and is suitable for environments with low or moderate packet loss rates. However, this setting may result in an increase in the time required for the route discovery process to complete. A higher value for the redundancy constant may be more suitable in
o 冗余常数“k”的建议值为1。使用该值“k”，如果路由器在定时器间隔期间接收到单个“一致”DIO，则DIO传输将被抑制。冗余常数的此设置旨在减少路由发现过程中生成的消息数量，适用于低或中等丢包率的环境。但是，此设置可能导致完成路由发现过程所需的时间增加。冗余常数的更高值可能更适合于以下情况：
* environments with high packet loss rates; or
* 具有高丢包率的环境；或
* deployments where the time required for the route discovery process to complete needs to be as small as possible; or
* 完成路由发现过程所需时间尽可能短的部署；或
* deployments where specific destinations are reachable only through specific Intermediate Routers (and hence these Intermediate Routers should not suppress their DIOs).
* 只有通过特定中间路由器才能到达特定目的地的部署（因此这些中间路由器不应抑制其DIO）。
A particular deployment should take into account the above-mentioned factors when deciding on the value of the redundancy constant.
在决定冗余常数的值时，特定部署应考虑上述因素。
Individual P2P-RPL deployments are encouraged to share their experience with these rules to help guide the development of a Standards Track version of the protocol. Applicability Statements that specify the use of P2P-RPL MUST provide guidance for setting Trickle parameters, particularly Imin and the redundancy constant.
鼓励个人P2P-RPL部署分享其使用这些规则的经验，以帮助指导协议标准跟踪版本的开发。指定使用P2P-RPL的适用性声明必须为设置涓流参数提供指导，特别是Imin和冗余常数。
The rules for DIO processing and transmission as described in Section 8 of RPL [RFC6550] apply to P2P mode DIOs as well, except as modified in this document. In particular, in accordance with Section 8.2.3 of RPL [RFC6550], a received P2P mode DIO MUST be discarded if it is malformed, according to the rules specified in this document and in [RFC6550].
RPL[RFC6550]第8节中描述的DIO处理和传输规则也适用于P2P模式DIO，本文件中修改的除外。特别是，根据RPL[RFC6550]第8.2.3节，如果收到的P2P模式DIO格式不正确，则必须根据本文件和[RFC6550]中规定的规则丢弃该DIO。
The following rules for processing a received P2P mode DIO apply to both Intermediate Routers and the Target.
以下处理接收到的P2P模式DIO的规则适用于中间路由器和目标路由器。
A router SHOULD discard a received P2P mode DIO with no further processing if it does not have bidirectional reachability with the neighbor that generated the received DIO. Note that bidirectional reachability does not mean that the link must have the same values for a routing metric in both directions. A router SHOULD calculate the values of the link-level routing metrics included in the received DIO, taking into account the metric's value in both Forward and Reverse directions. Bidirectional reachability along a discovered route allows the Target to use this route to reach the Origin. In particular, the P2P-DRO messages travel from the Target to the Origin along a discovered route.
如果路由器与生成接收到的DIO的邻居不具有双向可达性，则路由器应丢弃接收到的P2P模式DIO，而无需进一步处理。注意，双向可达性并不意味着链路必须在两个方向上具有相同的路由度量值。路由器应计算接收到的DIO中包含的链路级路由度量的值，同时考虑正向和反向的度量值。沿已发现路由的双向可达性允许目标使用此路由到达原点。特别是，P2P-DRO消息沿着发现的路由从目标传输到源。
A router MUST discard a received P2P mode DIO with no further processing:
路由器必须丢弃接收到的P2P模式DIO，无需进一步处理：
o if the DIO advertises INFINITE_RANK as defined in Section 17 of [RFC6550]
o 如果DIO宣传[RFC6550]第17节中定义的无限级
o if the integer part of the rank advertised in the DIO equals or exceeds the MaxRank limit listed in the P2P Route Discovery Option
o 如果DIO中公布的秩的整数部分等于或超过P2P路由发现选项中列出的MaxRank限制
o if the routing metric values do not satisfy one or more of the mandatory route constraints listed in the DIO or if the router cannot evaluate the mandatory route constraints, e.g., if the router does not support the metrics used in the constraints
o 如果路由度量值不满足DIO中列出的一个或多个强制路由约束，或者如果路由器无法评估强制路由约束，例如，如果路由器不支持约束中使用的度量
o if the router previously received a P2P-DRO message with the same RPLInstanceID and DODAGID as the received DIO and with the Stop flag set to one
o 如果路由器之前收到的P2P-DRO消息与接收到的DIO具有相同的RPLInstanceID和DODAGID，并且停止标志设置为1
The router MUST check the Target addresses listed in the P2P-RDO and any RPL Target options included in the received DIO. If one of its IPv6 addresses is listed as a Target address or if it belongs to the multicast group specified as one of the Target addresses, the router considers itself a Target and processes the received DIO as specified in Section 9.5. Otherwise, the router considers itself an Intermediate Router and processes the received DIO as specified in Section 9.4.
路由器必须检查P2P-RDO中列出的目标地址以及接收到的DIO中包含的任何RPL目标选项。如果其中一个IPv6地址被列为目标地址，或者如果它属于指定为目标地址之一的多播组，则路由器将自己视为目标，并按照第9.5节的规定处理接收到的DIO。否则，路由器将自己视为中间路由器，并按照第9.4节的规定处理接收到的DIO。
An Intermediate Router MUST discard a received P2P mode DIO with no further processing
中间路由器必须丢弃接收到的P2P模式DIO，无需进一步处理
o if the DIO is received on an Ingress-only Interface; or
o 如果在仅入口接口上接收到DIO；或
o if the receiving interface does not have a global or unique-local IPv6 address configured with the address prefix implied by the Compr field in the P2P-RDO inside the received DIO; or
o 如果接收接口没有全局或唯一的本地IPv6地址，该地址由接收到的DIO内的P2P-RDO中的Compr字段隐含的地址前缀配置；或
o if the router cannot uniquely identify the address prefix implied by the Compr field in the P2P-RDO (this might happen if the receiving interface has multiple global/unique-local IPv6 addresses, each configured with a different address prefix); or
o 如果路由器无法唯一标识P2P-RDO中的Compr字段所隐含的地址前缀（如果接收接口具有多个全局/唯一本地IPv6地址，每个地址都配置了不同的地址前缀，则可能发生这种情况）；或
o if adding its IPv6 address to the route in the Address vector inside the P2P-RDO would result in the route containing multiple addresses belonging to this router.
o 如果将其IPv6地址添加到P2P-RDO内地址向量中的路由，将导致该路由包含属于该路由器的多个地址。
On receiving a P2P mode DIO, an Intermediate Router MUST do the following. The router MUST determine whether this DIO advertises a better route than the router itself and whether the receipt of the DIO would allow the router to advertise a better route than before. Accordingly, the router SHOULD consider this DIO as consistent/inconsistent from the Trickle perspective, as described in Section 9.2. Note that the route comparison in a P2P-RPL route discovery is performed using the parent selection rules of the OF in use as specified in Section 14 of RPL [RFC6550]. If the received DIO would allow the router to advertise a better route, the router MUST add a unicast IPv6 address of the receiving interface (after eliding Compr prefix octets) to the route in the Address vector inside the P2P-RDO and remember this route for inclusion in its future DIOs.
在接收到P2P模式DIO时，中间路由器必须执行以下操作。路由器必须确定此DIO是否播发比路由器本身更好的路由，以及收到DIO是否允许路由器播发比以前更好的路由。因此，路由器应该考虑这个DIO从涓涓细流透视图中的一致性/不一致性，如第9.2节所述。请注意，P2P-RPL路由发现中的路由比较是使用RPL[RFC6550]第14节中规定的正在使用的of的父选择规则执行的。如果接收到的DIO允许路由器公布更好的路由，则路由器必须在P2P-RDO内的地址向量中将接收接口的单播IPv6地址（在省略Compr前缀八位字节后）添加到路由中，并记住该路由以包含在其未来的DIO中。
When an Intermediate Router adds an IPv6 address to a route, it MUST ensure that
当中间路由器向路由添加IPv6地址时，它必须确保
o the IPv6 address is a unicast global or unique-local IPv6 address assigned to the interface on which the DIO containing the route was received;
o IPv6地址是分配给接收包含路由的DIO的接口的单播全局或唯一本地IPv6地址；
o the IPv6 address was configured with the address prefix implied by the Compr field in the P2P-RDO inside the received DIO.
o IPv6地址配置为接收到的DIO内的P2P-RDO中的Compr字段隐含的地址前缀。
To improve the diversity of the routes being discovered, an Intermediate Router SHOULD keep track of multiple routes (as long as all these routes are the best seen so far), one of which SHOULD be selected in a uniform random manner for inclusion in the P2P-RDO
为了提高被发现的路由的多样性，中间路由器应该跟踪多个路由（只要所有这些路由都是迄今为止最好看到的），其中一个路由应该以统一的随机方式选择，以包含在P2P-RDO中
inside the router's next DIO. Note that the route accumulation in a P2P mode DIO MUST take place even if the Origin does not want any P2P-DRO messages to be generated (i.e., the R flag inside the P2P-RDO is set to zero). This is because the Target may still be able to use the accumulated route as a Source Route to reach the Origin.
在路由器的下一个DIO里。请注意，即使源站不希望生成任何P2P-DRO消息（即，P2P-RDO内的R标志设置为零），也必须在P2P模式DIO中进行路由累积。这是因为目标可能仍然能够使用累积路由作为源路由来到达原点。
The Target MAY remember the discovered route contained in the P2P-RDO in the received DIO for use as a Source Route to reach the Origin. The lifetime of this Source Route is specified by the Default Lifetime and Lifetime Unit parameters inside the DODAG Configuration Option currently in effect. This lifetime can be extended (or shortened) appropriately, following a hint from an upper-layer protocol.
目标可能会记住接收到的DIO中包含在P2P-RDO中的已发现路由，以用作到达原点的源路由。此源路由的生存期由当前有效的DODAG配置选项中的默认生存期和生存期单元参数指定。根据上层协议的提示，可以适当延长（或缩短）此生存期。
If the Reply flag inside the P2P-RDO in the received DIO is set to one, the Target MUST select one or more discovered routes and send one or more P2P-DRO messages, carrying one discovered route each, back to the Origin. If the H flag inside the P2P-RDO is set to one, the Target needs to select one route and send a P2P-DRO message along this route back to the Origin. As this P2P-DRO message travels back to the Origin, the routers on the path establish a hop-by-hop routing state, thereby establishing a Hop-by-hop Route in the Forward direction. If the H flag is set to zero, the number of Source Routes to be selected (and the number of P2P-DRO messages to be sent back) is given by one plus the value of the N field in the P2P-RDO. The Target may select the discovered route inside the received DIO as one or more of the routes that would be carried inside a P2P-DRO message back to the Origin. This document does not prescribe a particular method for the Target to select the routes. Example methods include selecting each route that meets the specified routing constraints until the desired number of routes has been selected, or selecting the best routes discovered over a certain time period. If multiple routes are to be selected, the Target SHOULD avoid selecting routes that have large segments in common.
如果接收到的DIO中的P2P-RDO内的应答标志设置为1，则目标必须选择一个或多个发现的路由，并将一个或多个P2P-DRO消息发送回源站，每个消息携带一个发现的路由。如果P2P-RDO内的H标志设置为1，则目标需要选择一条路由，并沿该路由将P2P-DRO消息发送回源站。当该P2P-DRO消息传回原点时，路径上的路由器建立逐跳路由状态，从而在前进方向上建立逐跳路由。如果H标志设置为零，则要选择的源路由数（以及要发送回的P2P-DRO消息数）由1加上P2P-RDO中N字段的值给出。目标可以选择接收到的DIO内发现的路由作为将在P2P-DRO消息内携带回源的一个或多个路由。本文件未规定目标公司选择路线的特定方法。示例方法包括选择满足指定路由约束的每条路由，直到选择了所需数量的路由，或者选择在特定时间段内发现的最佳路由。如果要选择多条管线，目标应避免选择具有大公共段的管线。
If the Target selects the route contained in the P2P-RDO in the received DIO, it sends a P2P-DRO message back to the Origin (identified by the DODAGID field in the DIO). The P2P-DRO message MUST include a P2P-RDO that contains the selected route inside the Address vector. Various fields inside the P2P-RDO MUST be set as specified in Section 8.2. The Target MAY set the A flag inside the P2P-DRO message to one if it desires the Origin to send back a P2P-DRO-ACK message on receiving the P2P-DRO. In this case, the Target waits for the duration of P2P_DRO_ACK_WAIT_TIME for the P2P-DRO-ACK message to arrive. Failure to receive the P2P-DRO-ACK message within this time duration causes the Target to retransmit the
如果目标在接收到的DIO中选择包含在P2P-RDO中的路由，它将P2P-DRO消息发送回源站（由DIO中的DODAGID字段标识）。P2P-DRO消息必须包括一个包含地址向量内所选路由的P2P-RDO。必须按照第8.2节的规定设置P2P-RDO内的各种字段。如果目标希望源站在接收到P2P-DRO时发回P2P-DRO-ACK消息，则可将P2P-DRO消息内的A标志设置为1。在这种情况下，目标等待P2P-DRO-ACK消息到达的持续时间。在此持续时间内未能接收P2P-DRO-ACK消息将导致目标重新传输该消息
P2P-DRO message. The Target MAY retransmit the P2P-DRO message in this fashion up to MAX_P2P_DRO_RETRANSMISSIONS times. Both P2P_DRO_ACK_WAIT_TIME and MAX_P2P_DRO_RETRANSMISSIONS are configurable parameters to be chosen based on the characteristics of individual deployments. Note that all P2P-DRO transmissions and retransmissions MUST take place while the Target is still a part of the temporary DAG created for the route discovery. A Target MUST NOT transmit a P2P-DRO if it no longer belongs to this DAG.
P2P-DRO消息。目标可以以这种方式重新传输P2P-DRO消息，最多可重新传输最多次。P2P_DRO_ACK_WAIT_TIME和MAX_P2P_DRO_reTransmission都是可配置的参数，可根据各个部署的特点进行选择。请注意，所有P2P-DRO传输和重传必须在目标仍然是为路由发现创建的临时DAG的一部分时进行。如果目标不再属于此DAG，则不得传输P2P-DRO。
The Target MAY set the Stop flag inside the P2P-DRO message to one if
如果出现以下情况，目标可能会将P2P-DRO消息内的停止标志设置为1
o this router is the only Target specified in the corresponding DIO, i.e., the corresponding DIO specified a unicast address of the router as the TargetAddr inside the P2P-RDO with no additional Targets specified via RPL Target options; and
o 该路由器是相应DIO中指定的唯一目标，即，相应DIO将路由器的单播地址指定为P2P-RDO内的TargetAddress，没有通过RPL目标选项指定其他目标；和
o the Target has already selected the desired number of routes.
o 目标已选择所需数量的路由。
The Target MAY include a Metric Container option in the P2P-DRO message. This Metric Container contains the end-to-end routing metric values for the route specified in the P2P-RDO. The Target MUST transmit the P2P-DRO message via a link-local multicast.
目标可以在P2P-DRO消息中包括度量容器选项。此度量容器包含P2P-RDO中指定的路由的端到端路由度量值。目标必须通过链路本地多播传输P2P-DRO消息。
A Target MUST NOT forward a P2P mode DIO any further if no other Targets are to be discovered, i.e., if a unicast IPv6 address (of this Target) is specified as the TargetAddr inside the P2P-RDO and no additional Targets are specified via RPL Target options inside the DIOs for this route discovery. Otherwise, the Target MUST generate DIOs for this route discovery as an Intermediate Router would.
如果没有发现其他目标，即，如果（该目标的）单播IPv6地址被指定为P2P-RDO内的TargetAddress，并且没有通过DIO内的RPL Target选项为该路由发现指定其他目标，则目标不得进一步转发P2P模式DIO。否则，目标必须像中间路由器一样为此路由发现生成DIO。
If the DODAGID field in the received P2P-DRO does not list a router's own IPv6 address, the router considers itself an Intermediate Router and MUST process the received message in the following manner:
如果收到的P2P-DRO中的DODAGID字段未列出路由器自己的IPv6地址，则路由器将自己视为中间路由器，并且必须以以下方式处理收到的消息：
o The router MUST discard the received P2P-DRO with no further processing if it does not belong to the temporary DAG identified by the RPLInstanceID and the DODAGID fields in the P2P-DRO.
o 如果接收到的P2P-DRO不属于由P2P-DRO中的RPLInstanceID和DODAGID字段标识的临时DAG，则路由器必须丢弃该P2P-DRO，而无需进一步处理。
o If the Stop flag inside the received P2P-DRO is set to one, the router SHOULD NOT send or receive any more DIOs for this temporary DAG and SHOULD cancel any pending DIO transmissions.
o 如果接收到的P2P-DRO内的Stop标志设置为1，则路由器不应为此临时DAG发送或接收任何更多DIO，并应取消任何挂起的DIO传输。
o The router MUST ignore any Metric Container options contained in the P2P-DRO message.
o 路由器必须忽略P2P-DRO消息中包含的任何度量容器选项。
o If an Address[NH] element inside the P2P-RDO lists the router's own unicast IPv6 address, the router is a part of the route carried in the P2P-RDO. In this case, the router MUST do the following:
o 如果P2P-RDO中的地址[NH]元素列出了路由器自己的单播IPv6地址，则路由器是P2P-RDO中承载的路由的一部分。在这种情况下，路由器必须执行以下操作：
* To prevent loops, the router MUST discard the P2P-DRO message with no further processing if the Address vector in the P2P-RDO includes multiple IPv6 addresses assigned to the router's interfaces.
* 为了防止循环，如果P2P-RDO中的地址向量包括分配给路由器接口的多个IPv6地址，则路由器必须丢弃P2P-DRO消息，而无需进一步处理。
* If the H flag inside the P2P-RDO is set to one, the router MUST store the state for the Forward Hop-by-hop Route carried inside the P2P-RDO. This state consists of:
* 如果P2P-RDO内的H标志设置为1，路由器必须存储P2P-RDO内携带的前向逐跳路由的状态。该州包括：
+ the RPLInstanceID and the DODAGID fields of the P2P-DRO
+ P2P-DRO的RPLInstanceID和DODAGID字段
+ the route's destination, the Target (identified by the TargetAddr field inside the P2P-RDO)
+ 路由的目的地，目标（由P2P-RDO中的targetAddress字段标识）
+ the IPv6 address of the next hop, Address[NH+1] (unless the NH value equals the number of elements in the Address vector, in which case the Target itself is the next hop)
+ 下一跳的IPv6地址，地址[NH+1]（除非NH值等于地址向量中的元素数，在这种情况下，目标本身就是下一跳）
This Hop-by-hop routing state MUST expire at the end of the lifetime specified by the Default Lifetime and Lifetime Unit parameters inside the DODAG Configuration Option used in P2P mode DIOs for this route discovery.
此逐跳路由状态必须在P2P模式DIOs中用于此路由发现的DODAG配置选项中的默认生存期和生存期单元参数指定的生存期结束时过期。
* If the router already maintains a Hop-by-hop state listing the Target as the destination and carrying the same RPLInstanceID and DODAGID fields as the received P2P-DRO, and the next-hop information in the state does not match the next hop indicated in the received P2P-DRO, the router MUST discard the P2P-DRO message with no further processing. Note that this situation would occur in the following two cases:
* 如果路由器已经保持逐跳状态，将目标列为目标，并携带与接收到的P2P-DRO相同的RPLInstanceID和DODAGID字段，并且该状态下的下一跳信息与接收到的P2P-DRO中指示的下一跳不匹配，则路由器必须丢弃P2P-DRO消息，而无需进一步处理。请注意，在以下两种情况下会出现这种情况：
+ When the route listed in the Address vector inside the P2P-RDO contains a previously undetected loop. In this case, this rule causes the P2P-DRO messages to be discarded.
+ 当P2P-RDO中地址向量中列出的路由包含以前未检测到的循环时。在这种情况下，此规则会导致丢弃P2P-DRO消息。
+ When a Hop-by-hop Route between the Origin and the Target, previously established using the same RPLInstanceID and DODAGID as the route currently being established, still exists and at least partially overlaps the route currently being established.
+ 当原点和目标之间的逐跳路由（先前使用与当前正在建立的路由相同的RPLInstanceID和DODAGID建立）仍然存在并且至少部分重叠当前正在建立的路由时。
* The router MUST decrement the NH field inside the P2P-RDO and send the P2P-DRO message further via link-local multicast.
* 路由器必须减少P2P-RDO中的NH字段，并通过链路本地多播进一步发送P2P-DRO消息。
When a router receives a P2P-DRO message that lists its IPv6 address in the DODAGID field, the router recognizes itself as the Origin for the corresponding P2P-RPL route discovery, notes the Target that originated this message (from the TargetAddr field inside the P2P-RDO), and processes the message in the following manner:
当路由器接收到在DODAGID字段中列出其IPv6地址的P2P-DRO消息时，路由器会将自身识别为相应P2P-RPL路由发现的来源，注意发出此消息的目标（来自P2P-RDO中的TargetAddress字段），并以以下方式处理该消息：
o The Origin MUST discard the received P2P-DRO with no further processing if it no longer belongs to the temporary DAG identified by the RPLInstanceID and the DODAGID fields in the P2P-DRO.
o 如果接收到的P2P-DRO不再属于由P2P-DRO中的RPLInstanceID和DODAGID字段标识的临时DAG，则源站必须丢弃该P2P-DRO，而无需进一步处理。
o If the Stop flag inside the received P2P-DRO is set to one, the Origin SHOULD NOT generate any more DIOs for this temporary DAG and SHOULD cancel any pending DIO transmissions.
o 如果接收到的P2P-DRO内的Stop标志设置为1，则源站不应为此临时DAG生成任何更多的DIO，并应取消任何挂起的DIO传输。
o If the P2P-RDO inside the P2P-DRO has the H flag set to zero, the Address vector inside the P2P-RDO contains a Source Route to this Target. The Origin MUST set the lifetime of this Source Route to the value specified by the Default Lifetime and Lifetime Unit parameters inside the DODAG Configuration Option in the P2P mode DIOs used for this route discovery. This lifetime could be extended (or shortened) appropriately, following a hint from an upper-layer protocol.
o 如果P2P-DRO中的P2P-RDO的H标志设置为零，则P2P-RDO中的地址向量包含指向该目标的源路由。源站必须将此源路由的生存期设置为用于此路由发现的P2P模式DIOs中DODAG配置选项内的默认生存期和生存期单位参数指定的值。根据上层协议的提示，可以适当延长（或缩短）此生命周期。
o If the P2P-RDO inside the P2P-DRO has the H flag set to one, the P2P-DRO message is establishing a Hop-by-hop Route to this Target, and the Origin MUST store in its memory the state for this Hop-by-hop Route in the manner described in Section 9.6. This Hop-by-hop routing state MUST expire at the end of the lifetime specified by the Default Lifetime and Lifetime Unit parameters inside the DODAG Configuration Option used in P2P mode DIOs for this route discovery. A Standards Track version of P2P-RPL may consider specifying a signaling mechanism that will allow the Origin to extend (or shorten) the lifetime of a P2P-RPL Hop-by-hop Route, following a suitable hint from an upper-layer protocol.
o 如果P2P-DRO内的P2P-RDO将H标志设置为1，则P2P-DRO消息将建立一个到该目标的逐跳路由，并且源站必须以第9.6节所述的方式在其内存中存储该逐跳路由的状态。此逐跳路由状态必须在P2P模式DIOs中用于此路由发现的DODAG配置选项中的默认生存期和生存期单元参数指定的生存期结束时过期。一个标准的跟踪版本的PIP-RPL可以考虑指定一个信令机制，它将允许原点扩展（或缩短）一个2P RPL逐跳路由的生命周期，遵循来自上层协议的适当提示。
o If the received P2P-DRO message contains one or more Metric Container options, the Origin MAY store the values of the routing metrics associated with the discovered route in its memory. This information may be useful in formulating the constraints for any future P2P-RPL route discovery to this Target.
o 如果接收到的P2P-DRO消息包含一个或多个度量容器选项，则源站可以将与发现的路由相关联的路由度量的值存储在其存储器中。该信息可能有助于制定任何未来到该目标的P2P-RPL路由发现的约束条件。
o If the A flag is set to one in the received P2P-DRO message, the Origin MUST generate a P2P-DRO-ACK message as described in Section 10 and unicast the message to the Target. The Origin MAY use the route just discovered to send the P2P-DRO-ACK message to the Target. Section 12 describes how a packet may be forwarded along a Source/Hop-by-hop Route discovered using P2P-RPL.
o 如果接收到的P2P-DRO消息中的A标志设置为1，则源站必须生成第10节所述的P2P-DRO-ACK消息，并将该消息单播给目标站。源站可以使用刚刚发现的路由将P2P-DRO-ACK消息发送到目标站。第12节描述了如何沿着使用P2P-RPL发现的源/逐跳路由转发数据包。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID | Version |Seq| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| DODAGID |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID | Version |Seq| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| DODAGID |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Format of the Base P2P Discovery Reply Object Acknowledgement (P2P-DRO-ACK)
图3：基本P2P发现应答对象确认（P2P-DRO-ACK）的格式
A P2P-DRO message may fail to reach the Origin due to a number of reasons. Unlike the DIO messages, which benefit from Trickle-controlled retransmissions, the P2P-DRO messages are prone to loss due to unreliable packet transmission in LLNs. Since a P2P-DRO message travels via link-local multicast, it cannot use link-level acknowledgements to improve the reliability of its transmission. Also, an Intermediate Router may drop the P2P-DRO message (e.g., because of its inability to store the state for the Hop-by-hop Route that the P2P-DRO is establishing). To protect against the potential failure of a P2P-DRO message to reach the Origin, the Target MAY request that the Origin send back a P2P-DRO Acknowledgement (P2P-DRO-ACK) message on receiving a P2P-DRO message. Failure to receive such an acknowledgement within the P2P_DRO_ACK_WAIT_TIME interval of sending the P2P-DRO message forces the Target to resend the message (as described in Section 9.5).
由于多种原因，P2P-DRO消息可能无法到达源站。与DIO消息（受益于涓流控制的重传）不同，P2P-DRO消息由于LLN中不可靠的数据包传输而容易丢失。由于P2P-DRO消息通过链路本地多播传输，因此无法使用链路级确认来提高其传输的可靠性。此外，中间路由器可以丢弃P2P-DRO消息（例如，由于其无法存储P2P-DRO正在建立的逐跳路由的状态）。为了防止P2P-DRO消息到达源站的潜在故障，目标站可以请求源站在接收P2P-DRO消息时发回P2P-DRO确认（P2P-DRO-ACK）消息。在发送P2P-DRO消息的P2P_-DRO_-ACK_-WAIT_时间间隔内未能接收到此类确认将迫使目标重新发送消息（如第9.5节所述）。
This section defines two new RPL control message types: the P2P-DRO Acknowledgement (P2P-DRO-ACK), with code 0x05; and the Secure P2P-DRO-ACK, with code 0x85. A P2P-DRO-ACK message MUST travel as a unicast message from the Origin to the Target. The IPv6 source and destination addresses used in a P2P-DRO-ACK message MUST be global or unique-local. The format of a base P2P-DRO-ACK message is shown in Figure 3. Various fields in a P2P-DRO-ACK message MUST have the same values as the corresponding fields in the P2P-DRO message. The field marked as "Reserved" MUST be set to zero on transmission and MUST be
本节定义了两种新的RPL控制消息类型：P2P-DRO确认（P2P-DRO-ACK），代码为0x05；以及安全的P2P-DRO-ACK，代码为0x85。P2P-DRO-ACK消息必须作为单播消息从源站传输到目标站。P2P-DRO-ACK消息中使用的IPv6源地址和目标地址必须是全局地址或唯一的本地地址。基本P2P-DRO-ACK消息的格式如图3所示。P2P-DRO-ACK消息中的各个字段必须与P2P-DRO消息中的相应字段具有相同的值。标记为“保留”的字段在传输时必须设置为零，并且必须
ignored on reception. A Secure P2P-DRO-ACK message follows the format shown in Figure 7 of [RFC6550], where the base format is the same as the base P2P-DRO-ACK shown in Figure 3.
接待时被忽略。安全P2P-DRO-ACK消息遵循[RFC6550]图7所示的格式，其中基本格式与图3所示的基本P2P-DRO-ACK相同。
Each RPL control message type, including those defined in this document, has a secure version. A secure RPL control message is identified by the value 1 in the most significant bit of the Code field. Each secure RPL control message contains a Security section (see Figures 7 and 8 of [RFC6550]) whose contents are described in Section 6.1 of [RFC6550]. Sections 6.1, 10, and 19 of [RFC6550] describe core RPL's security apparatus. These sections are applicable to P2P-RPL's secure operation as well, except as constrained in this section.
每个RPL控制消息类型（包括本文档中定义的类型）都有一个安全版本。安全RPL控制消息由代码字段最高有效位中的值1标识。每个安全RPL控制消息包含一个安全部分（参见[RFC6550]的图7和图8），其内容在[RFC6550]的第6.1节中描述。[RFC6550]第6.1、10和19节描述了核心RPL的安全装置。这些部分也适用于P2P-RPL的安全操作，除非本部分有限制。
Core RPL allows a router to decide locally on a per-packet basis whether to use security and, if yes, what Security Configuration (see definition in Section 3) to use (the only exception being the requirement to send a Secure DIO in response to a Secure DIS; see Section 10.2 of [RFC6550]). In contrast, this document requires that routers participating in a P2P-RPL route discovery follow the Origin's lead regarding security. The Origin decides whether to use security, and the particular Security Configuration to be used for this purpose. All the routers participating in this route discovery MUST generate only secure control messages if the Origin so decides and MUST use for this purpose the Security Configuration that the Origin chose. The Origin MUST NOT set the "Key Identifier Mode" field inside the chosen Security Configuration to value 1, since this setting indicates the use of a per-pair key, which is not suitable for securing messages that travel by (link-local) multicast (e.g., DIOs) or that travel over multiple hops (e.g., P2P-DROs). The Origin MUST use the chosen Security Configuration to secure all the control messages (DIOs and P2P-DRO-ACKs) it generates.
核心RPL允许路由器根据每个数据包在本地决定是否使用安全性，如果是，则决定使用何种安全配置（见第3节中的定义）（唯一的例外是要求发送安全DIO以响应安全DIS；见[RFC6550]第10.2节）。相比之下，本文档要求参与P2P-RPL路由发现的路由器在安全方面遵循源站的领导。原点决定是否使用安全性，以及用于此目的的特定安全配置。参与此路由发现的所有路由器必须仅生成安全控制消息（如果源站决定），并且必须为此目的使用源站选择的安全配置。源站不得将所选安全配置内的“密钥标识符模式”字段设置为值1，因为此设置指示使用每对密钥，这不适合保护通过（链路本地）多播（例如，DIO）或通过多跳（例如，P2P DRO）传输的消息。源站必须使用所选的安全配置来保护其生成的所有控制消息（DIO和P2P DRO ACK）。
A router MUST NOT join the temporary DAG being created for a P2P-RPL route discovery if:
在以下情况下，路由器不得加入为P2P-RPL路由发现创建的临时DAG：
o it receives both secure and unsecure DIOs or Secure DIOs with different Security Configurations pertaining to this route discovery (i.e., referring to the same RPLInstanceID and DODAGID combination) prior to joining; or
o 在加入之前，它接收安全和不安全的DIO或具有与此路由发现相关的不同安全配置的安全DIO（即，指相同的RPLInstanceID和DODAGID组合）；或
o it cannot use the Security Configuration found in the Secure DIOs pertaining to this route discovery.
o 它无法使用在与此路由发现相关的安全DIOs中找到的安全配置。
When a router (an Intermediate Router or a Target) joins a temporary DAG being created using Secure DIOs, it MUST remember the common Security Configuration used in the received Secure DIOs and MUST use this configuration to secure all the control messages (DIOs and P2P-DROs) it generates.
当路由器（中间路由器或目标）加入使用安全DIOs创建的临时DAG时，它必须记住接收到的安全DIOs中使用的通用安全配置，并且必须使用此配置来保护它生成的所有控制消息（DIO和P2P DRO）。
If an Intermediate Router (or a Target) encounters a control message (a DIO or a P2P-DRO or a P2P-DRO-ACK) pertaining to this route discovery that is either not secure or does not follow the Security Configuration the router remembers for this route discovery, the router MUST enter the "lock down" mode for the remainder of its stay in this temporary DAG. An Intermediate Router (or a Target) in the "lock down" mode MUST NOT generate or process any control messages (irrespective of the Security Configuration used) pertaining to this route discovery. If the Origin receives a control message (a P2P-DRO) that does not follow the Security Configuration the Origin has chosen for this route discovery, it MUST discard the received message with no further processing.
如果中间路由器（或目标）遇到与此路由发现相关的控制消息（DIO或P2P-DRO或P2P-DRO-ACK），该消息不安全或不符合路由器记住的用于此路由发现的安全配置，则路由器必须进入“锁定”此临时DAG中剩余停留时间的模式。处于“锁定”模式的中间路由器（或目标）不得生成或处理与此路由发现相关的任何控制消息（无论使用何种安全配置）。如果源站接收到的控制消息（P2P-DRO）不符合源站为此路由发现选择的安全配置，则必须丢弃接收到的消息，无需进一步处理。
An Origin uses the Source Routing Header (SRH) [RFC6554] to send a packet along a Source Route discovered using P2P-RPL.
源站使用源路由报头（SRH）[RFC6554]沿使用P2P-RPL发现的源路由发送数据包。
Travel along a Hop-by-hop Route, established using P2P-RPL, requires specifying the RPLInstanceID and the DODAGID (of the temporary DAG used for the route discovery) to identify the route. This is because a P2P-RPL route discovery does not use globally unique RPLInstanceID values, and hence both the RPLInstanceID (a local value assigned by the Origin) and the DODAGID (an IPv6 address of the Origin) are required to uniquely identify a P2P-RPL Hop-by-hop Route to a particular destination.
沿着使用P2P-RPL建立的逐跳路由旅行，需要指定RPLInstanceID和DODAGID（用于路由发现的临时DAG）来识别路由。这是因为P2P-RPL路由发现不使用全局唯一的RPLInstanceID值，因此需要RPLInstanceID（由源分配的本地值）和DODAGID（源的IPv6地址）来唯一标识到特定目的地的P2P-RPL逐跳路由。
An Origin includes a RPL option [RFC6553] inside the IPv6 Hop-by-Hop Options header of a packet to send it along a Hop-by-hop Route established using P2P-RPL. For this purpose, the Origin MUST set the DODAGID of the temporary DAG used for the route discovery as the source IPv6 address of the packet. Further, the Origin MUST specify inside the RPL option the RPLInstanceID of the temporary DAG used for the route discovery and set the O flag inside the RPL option to one. On receiving this packet, an Intermediate Router checks the O flag and correctly infers the source IPv6 address of the packet as the DODAGID of the Hop-by-hop Route. The router then uses the DODAGID, the RPLInstanceID, and the destination address to identify the routing state to be used to forward the packet further.
源站在数据包的IPv6逐跳选项报头中包含一个RPL选项[RFC6553]，用于沿使用P2P-RPL建立的逐跳路由发送数据包。为此，源站必须将用于路由发现的临时DAG的DODAGID设置为数据包的源IPv6地址。此外，原点必须在RPL选项内指定用于路由发现的临时DAG的RPLInstanceID，并将RPL选项内的O标志设置为1。在接收到此数据包时，中间路由器会检查O标志，并正确推断数据包的源IPv6地址为逐跳路由的DODAGID。然后，路由器使用DODAGID、RPLInstanceID和目标地址来标识用于进一步转发数据包的路由状态。
This section describes how RPL routers that implement P2P-RPL interact with RPL routers that do not. In general, P2P-RPL operation does not affect core RPL operation, and vice versa. However, core RPL does allow a router to join a DAG as a leaf node even if it does not understand the Mode of Operation (MOP) used in the DAG. Thus, a RPL router that does not implement P2P-RPL may conceivably join a temporary DAG being created for a P2P-RPL route discovery as a leaf node and maintain its membership even though the DAG no longer exists. This may impose a drain on the router's memory. However, such RPL-only leaf nodes do not interfere with P2P-RPL route discovery, since a leaf node may only generate a DIO advertising an INFINITE_RANK and all routers implementing P2P-RPL are required to discard such DIOs. Note that core RPL does not require that a router join a DAG whose MOP it does not understand. Moreover, RPL routers in a particular deployment may have strict restrictions on the DAGs they may join, thereby mitigating the problem.
本节介绍实现P2P-RPL的RPL路由器如何与不实现P2P-RPL的RPL路由器交互。一般来说，P2P-RPL操作不会影响核心RPL操作，反之亦然。然而，核心RPL允许路由器作为叶节点加入DAG，即使它不了解DAG中使用的操作模式（MOP）。因此，不实现P2P-RPL的RPL路由器可以想象地将为P2P-RPL路由发现创建的临时DAG加入为叶节点，并保持其成员资格，即使该DAG不再存在。这可能会对路由器的内存造成消耗。然而，这种仅限RPL的叶节点不会干扰P2P-RPL路由发现，因为叶节点可能只生成广告无限_秩的DIO，并且实现P2P-RPL的所有路由器都需要丢弃这种DIO。注意，核心RPL不要求路由器加入它不了解MOP的DAG。此外，特定部署中的RPL路由器可能对它们可能加入的DAG有严格限制，从而缓解问题。
The P2P-RPL mechanism described in this document works best when all the RPL routers in the LLN implement P2P-RPL. In general, the ability to discover routes, as well as the quality of discovered routes, would deteriorate with the fraction of RPL routers that implement P2P-RPL.
当LLN中的所有RPL路由器都实现P2P-RPL时，本文中描述的P2P-RPL机制最为有效。一般来说，发现路由的能力以及发现的路由的质量会随着实现P2P-RPL的RPL路由器的比例的增加而恶化。
In general, the security considerations for the operation of P2P-RPL are similar to those for the operation of RPL (as described in Section 19 of the RPL specification [RFC6550]). Sections 6.1 and 10 of [RFC6550] describe RPL's security framework, which provides data confidentiality, authentication, replay protection, and delay protection services. This security framework can also be used in P2P-RPL after taking into account the constraints specified in Section 11. P2P-RPL requires that all routers participating in a secure route discovery use the Security Configuration chosen by the Origin. The intention is to avoid compromising the overall security of a route discovery due to some routers using a weaker Security Configuration. With the "lock down" mechanism as described in Section 11 in effect, it is unlikely that an Origin would accept a route discovered under a Security Configuration other than the one it intended. Any attempt to use a different Security Configuration (than the one the Origin intended) is likely to result, in the worst case, in the failure of the route discovery process. In the best-case scenario, any such attempt by a rogue router would result in its neighbors entering the "lock down" mode and acting as firewalls to allow the route discovery to proceed in the remaining network.
一般来说，P2P-RPL操作的安全注意事项与RPL操作的安全注意事项类似（如RPL规范[RFC6550]第19节所述）。[RFC6550]第6.1节和第10节描述了RPL的安全框架，该框架提供数据保密性、身份验证、重播保护和延迟保护服务。在考虑了第11节中指定的约束条件后，该安全框架也可用于P2P-RPL。P2P-RPL要求参与安全路由发现的所有路由器使用源站选择的安全配置。其目的是避免由于某些路由器使用较弱的安全配置而影响路由发现的整体安全性。在第11节所述的“锁定”机制生效的情况下，源站不太可能接受在安全配置下发现的路由，而不是其预期的路由。在最坏的情况下，任何尝试使用不同的安全配置（与源站预期的配置不同）都可能导致路由发现过程失败。在最佳情况下，恶意路由器的任何此类尝试都会导致其邻居进入“锁定”模式并充当防火墙，以允许在剩余网络中继续路由发现。
The RPL specification [RFC6550] describes three modes of security: unsecured, preinstalled, and authenticated. In the unsecured mode, secure control messages are not used, and the only available security is the security provided by the link-layer protocols. In the preinstalled mode, all the nodes use a preinstalled group key to join a secure DAG as the "routers" or "hosts", where the term "router" means a node that is capable of forwarding packets received from its parents or children in the DAG, and the term "host" refers to nodes that cannot function as "routers". In the authenticated mode, the nodes can join a secure DAG as "hosts" using the preinstalled key but then need to authenticate themselves to a key server to obtain the key that will allow them to work as "routers". The temporary DAG created for a P2P-RPL discovery cannot be used for routing packets. Hence, it is not meaningful to say that a node joins this DAG as a "router" or a "host" in the sense defined above. Hence, in P2P-RPL, there is no distinction between the preinstalled and authenticated modes. A router can join a temporary DAG created for a secure P2P-RPL route discovery only if it can support the Security Configuration in use, which also specifies the key in use. It does not matter whether the key is preinstalled or dynamically acquired. The router must have the key in use before it can join the DAG being created for a secure P2P-RPL route discovery.
RPL规范[RFC6550]描述了三种安全模式：不安全、预安装和认证。在非安全模式下，不使用安全控制消息，唯一可用的安全性是链路层协议提供的安全性。在预安装模式中，所有节点使用预安装的组密钥作为“路由器”或“主机”加入安全DAG，其中术语“路由器”指能够转发从DAG中的其父节点或子节点接收的数据包的节点，术语“主机”指不能用作“路由器”的节点。在身份验证模式下，节点可以使用预安装的密钥作为“主机”加入安全DAG，但随后需要向密钥服务器进行身份验证，以获得允许其作为“路由器”工作的密钥。为P2P-RPL发现创建的临时DAG不能用于路由数据包。因此，说节点作为上文定义的“路由器”或“主机”加入该DAG是没有意义的。因此，在P2P-RPL中，预安装模式和认证模式之间没有区别。路由器可以加入为安全P2P-RPL路由发现创建的临时DAG，前提是它可以支持正在使用的安全配置，该配置还指定了正在使用的密钥。密钥是预安装的还是动态获取的并不重要。路由器必须先使用密钥，然后才能加入为安全P2P-RPL路由发现而创建的DAG。
If a rogue router can support the Security Configuration in use (in particular, if it knows the key in use), it can join the secure P2P-RPL route discovery and cause various types of damage. Such a rogue router could advertise false information in its DIOs in order to include itself in the discovered route(s). It could generate bogus P2P-DRO messages carrying bad routes or maliciously modify genuine P2P-DRO messages it receives. A rogue router acting as the Origin could launch denial-of-service attacks against the LLN deployment by initiating fake P2P-RPL route discoveries; in this type of scenario, RPL's authenticated mode of operation, where a node can obtain the key to use for a P2P-RPL route discovery only after proper authentication, would be useful.
如果流氓路由器可以支持使用中的安全配置（特别是，如果它知道使用中的密钥），它可以加入安全的P2P-RPL路由发现并造成各种类型的破坏。这样的恶意路由器可能会在其DIO中发布虚假信息，以便将自身包含在已发现的路由中。它可能会生成带有错误路由的虚假P2P-DRO消息，或者恶意修改它收到的真实P2P-DRO消息。充当始发站的恶意路由器可通过发起虚假的P2P-RPL路由发现，对LLN部署发起拒绝服务攻击；在这种情况下，RPL的身份验证操作模式非常有用，其中节点只有在正确身份验证后才能获得用于P2P-RPL路由发现的密钥。
Since a P2P-DRO message travels along a Source Route specified inside the message, some of the security concerns that led to the deprecation of Type 0 routing headers [RFC5095] may apply. To avoid the possibility of a P2P-DRO message traveling in a routing loop, this document requires that each Intermediate Router confirm that the Source Route listed inside the message does not contain any routing loop involving itself before the router could forward the message further. As specified in Section 9.6, this check involves the router making sure that its IPv6 addresses do not appear multiple times inside the Source Route with one or more other IPv6 addresses in between.
由于P2P-DRO消息沿着消息内部指定的源路由传输，因此可能会出现导致不推荐类型0路由头[RFC5095]的一些安全问题。为了避免P2P-DRO消息在路由循环中传播的可能性，本文档要求每个中间路由器在路由器进一步转发消息之前，确认消息中列出的源路由不包含任何涉及自身的路由循环。如第9.6节所述，此项检查涉及路由器，确保其IPv6地址不会在源路由内多次出现，且一个或多个其他IPv6地址介于两者之间。
This document defines a new Mode of Operation, entitled "P2P Route Discovery Mode of Operation" (see Section 6), assigned a value of 4 from the "Mode of Operation" space [RFC6550].
本文件定义了一种新的操作模式，名为“P2P路由发现操作模式”（见第6节），从“操作模式”空间[RFC6550]分配了一个值4。
+-------+---------------------------------------+---------------+
| Value | Description | Reference |
+-------+---------------------------------------+---------------+
| 4 | P2P Route Discovery Mode of Operation | This document |
+-------+---------------------------------------+---------------+
+-------+---------------------------------------+---------------+
| Value | Description | Reference |
+-------+---------------------------------------+---------------+
| 4 | P2P Route Discovery Mode of Operation | This document |
+-------+---------------------------------------+---------------+
Mode of Operation
运作模式
This document defines a new RPL option: "P2P Route Discovery" (see Section 7), assigned a value of 0x0a from the "RPL Control Message Options" space [RFC6550].
本文档定义了一个新的RPL选项：“P2P路由发现”（参见第7节），从“RPL控制消息选项”空间[RFC6550]分配了一个0x0a的值。
+-------+---------------------+---------------+
| Value | Meaning | Reference |
+-------+---------------------+---------------+
| 0x0a | P2P Route Discovery | This document |
+-------+---------------------+---------------+
+-------+---------------------+---------------+
| Value | Meaning | Reference |
+-------+---------------------+---------------+
| 0x0a | P2P Route Discovery | This document |
+-------+---------------------+---------------+
RPL Control Message Options
RPL控制消息选项
This document defines the following new RPL messages:
本文档定义了以下新的RPL消息：
o "P2P Discovery Reply Object" (see Section 8), assigned a value of 0x04 from the "RPL Control Codes" space [RFC6550].
o “P2P发现回复对象”（参见第8节），从“RPL控制代码”空间[RFC6550]分配了0x04的值。
o "Secure P2P Discovery Reply Object" (see Section 8.1), assigned a value of 0x84 from the "RPL Control Codes" space [RFC6550].
o “安全P2P发现回复对象”（参见第8.1节），从“RPL控制代码”空间[RFC6550]分配了0x84的值。
o "P2P Discovery Reply Object Acknowledgement" (see Section 10), assigned a value of 0x05 from the "RPL Control Codes" space [RFC6550].
o “P2P发现应答对象确认”（参见第10节），从“RPL控制代码”空间[RFC6550]分配了0x05的值。
o "Secure P2P Discovery Reply Object Acknowledgement" (see Section 10), assigned a value of 0x85 from the "RPL Control Codes" space [RFC6550].
o “安全P2P发现应答对象确认”（参见第10节），从“RPL控制代码”空间[RFC6550]分配了0x85的值。
+--------+----------------------------------------+-----------------+
| Code | Description | Reference |
+--------+----------------------------------------+-----------------+
| 0x04 | P2P Discovery Reply Object | This document |
| 0x84 | Secure P2P Discovery Reply Object | This document |
| 0x05 | P2P Discovery Reply Object | This document |
| | Acknowledgement | |
| 0x85 | Secure P2P Discovery Reply Object | This document |
| | Acknowledgement | |
+--------+----------------------------------------+-----------------+
+--------+----------------------------------------+-----------------+
| Code | Description | Reference |
+--------+----------------------------------------+-----------------+
| 0x04 | P2P Discovery Reply Object | This document |
| 0x84 | Secure P2P Discovery Reply Object | This document |
| 0x05 | P2P Discovery Reply Object | This document |
| | Acknowledgement | |
| 0x85 | Secure P2P Discovery Reply Object | This document |
| | Acknowledgement | |
+--------+----------------------------------------+-----------------+
RPL Control Codes
RPL控制代码
This document is presented as an Experimental specification to facilitate P2P-RPL's deployment in LLN scenarios where reactive P2P route discovery is considered useful or necessary. It is anticipated that, once sufficient operational experience has been gained, this specification will be revised to progress it on to the Standards Track. Experience reports regarding P2P-RPL implementation and deployment are encouraged, particularly with respect to:
本文档作为实验规范提供，以促进P2P-RPL在LLN场景中的部署，在LLN场景中，反应式P2P路由发现被认为是有用或必要的。预计，一旦获得足够的运行经验，将对本规范进行修订，使其进入标准轨道。鼓励提供关于P2P-RPL实施和部署的经验报告，特别是关于：
o Secure P2P-RPL operation (Section 11);
o 安全P2P-RPL操作（第11节）；
o Rules governing Trickle operation (Section 9.2);
o 涓流运行规则（第9.2节）；
o Values in the default DODAG Configuration Option (Section 6.1);
o 默认DODAG配置选项中的值（第6.1节）；
o The RPLInstanceID reuse policy (Section 6.1);
o RPLInstanceID重用策略（第6.1节）；
o Utility and implementation complexity of allowing multiple Target addresses in a P2P-RPL route discovery.
o 在P2P-RPL路由发现中允许多个目标地址的实用性和实现复杂性。
The authors gratefully acknowledge the contributions of the following individuals (in alphabetical order) in the development of this document: Dominique Barthel, Jakob Buron, Cedric Chauvenet, Thomas Clausen, Robert Cragie, Ralph Droms, Adrian Farrel, Stephen Farrell, Brian Haberman, Ted Humpal, Richard Kelsey, Phil Levis, Charles Perkins, Joseph Reddy, Michael Richardson, Zach Shelby, Martin Stiemerling, Pascal Thubert, Hristo Valev, and JP Vasseur.
作者衷心感谢以下个人（按字母顺序）在本文件编制过程中所做的贡献：多米尼克·巴塞尔、雅各布·布隆、塞德里克·乔维内、托马斯·克劳森、罗伯特·克拉吉、拉尔夫·德罗姆斯、阿德里安·法雷尔、斯蒂芬·法雷尔、布赖恩·哈伯曼、特德·汉帕尔、理查德·凯尔西、菲尔·列维斯、查尔斯·帕金斯、，Joseph Reddy、Michael Richardson、Zach Shelby、Martin Stiemerling、Pascal Thubert、Hristo Valev和JP Vasseur。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, "The Trickle Algorithm", RFC 6206, March 2011.
[RFC6206]Levis，P.，Clausen，T.，Hui，J.，Gnawali，O.，和J.Ko，“涓流算法”，RFC 62062011年3月。
[RFC6550] Winter, T., Thubert, P., 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, March 2012.
[RFC6550]温特，T.，苏伯特，P.，勃兰特，A.，许，J.，凯尔西，R.，列维斯，P.，皮斯特，K.，斯特鲁克，R.，瓦塞尔，JP.，和R.亚历山大，“RPL：低功耗和有损网络的IPv6路由协议”，RFC 65502012年3月。
[RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. Barthel, "Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks", RFC 6551, March 2012.
[RFC6551]Vasseur，JP.，Kim，M.，Pister，K.，Dejean，N.，和D.Barthel，“低功率和有损网络中用于路径计算的路由度量”，RFC 65512012年3月。
[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, March 2012.
[RFC6554]Hui，J.，Vasseur，JP.，Culler，D.，和V.Manral，“低功耗和有损网络（RPL）路由协议源路由的IPv6路由头”，RFC 65542012年3月。
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, December 2007.
[RFC5095]Abley，J.，Savola，P.，和G.Neville Neil，“IPv6中0型路由头的弃用”，RFC 5095，2007年12月。
[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5826, April 2010.
[RFC5826]Brandt，A.，Buron，J.，和G.Porcu，“低功率和有损网络中的家庭自动化路由要求”，RFC 5826，2010年4月。
[RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, "Building Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5867, June 2010.
[RFC5867]Martocci，J.，De Mil，P.，Riou，N.，和W.Vermeylen，“低功率和有损网络中的楼宇自动化路由要求”，RFC 58672010年6月。
[RFC6552] Thubert, P., "Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6552, March 2012.
[RFC6552]Thubert，P.，“低功耗和有损网络路由协议（RPL）的目标函数零”，RFC 6552，2012年3月。
[RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams", RFC 6553, March 2012.
[RFC6553]Hui，J.和JP。Vasseur，“在数据平面数据报中承载RPL信息的低功耗和有损网络路由协议（RPL）选项”，RFC 6553，2012年3月。
[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, August 2013.
[RFC6998]Goyal，M.，Ed.，Baccelli，E.，Brandt，A.，和J.Martocci，“在低功耗和有损网络中沿点对点路由测量路由度量的机制”，RFC 6998，2013年8月。
[ROLL-TERMS] Vasseur, JP., "Terminology in Low power And Lossy Networks", Work in Progress, March 2013.
[ROLL-TERMS]Vasseur，JP.，“低功耗和有损网络中的术语”，正在进行的工作，2013年3月。
Authors' Addresses
作者地址
Mukul Goyal (editor) University of Wisconsin Milwaukee 3200 N. Cramer St. Milwaukee, WI 53201 USA
Mukul Goyal（编辑）威斯康星大学密尔沃基3200 N.克莱默圣密尔沃基，WI 53201美国
Phone: +1-414-229-5001
EMail: mukul@uwm.edu
Phone: +1-414-229-5001
EMail: mukul@uwm.edu
Emmanuel Baccelli INRIA
伊曼纽尔杆菌
Phone: +33-169-335-511
EMail: Emmanuel.Baccelli@inria.fr
URI: http://www.emmanuelbaccelli.org/
Phone: +33-169-335-511
EMail: Emmanuel.Baccelli@inria.fr
URI: http://www.emmanuelbaccelli.org/
Matthias Philipp INRIA
马蒂亚斯·菲利普·因里亚
Phone: +33-169-335-511
EMail: matthias-philipp@gmx.de
Phone: +33-169-335-511
EMail: matthias-philipp@gmx.de
Anders Brandt Sigma Designs Emdrupvej 26A, 1. Copenhagen, Dk-2100 Denmark
Anders Brandt Sigma设计Emdrupvej 26A，1。丹麦哥本哈根，Dk-2100
Phone: +45-29609501
EMail: abr@sdesigns.dk
Phone: +45-29609501
EMail: abr@sdesigns.dk
Jerald Martocci Johnson Controls 507 E. Michigan Street Milwaukee, WI 53202 USA
Jerald Martocci Johnson Controls美国威斯康星州密尔沃基市密歇根街东507号，邮编53202
Phone: +1-414-524-4010
EMail: jerald.p.martocci@jci.com
Phone: +1-414-524-4010
EMail: jerald.p.martocci@jci.com