Independent Submission J. Tripathi, Ed.
Request for Comments: 6687 J. de Oliveira, Ed.
Category: Informational Drexel University
ISSN: 2070-1721 JP. Vasseur, Ed.
Cisco Systems, Inc.
October 2012
Independent Submission J. Tripathi, Ed.
Request for Comments: 6687 J. de Oliveira, Ed.
Category: Informational Drexel University
ISSN: 2070-1721 JP. Vasseur, Ed.
Cisco Systems, Inc.
October 2012
Performance Evaluation of the Routing Protocol for Low-Power and Lossy Networks (RPL)
低功耗有损网络路由协议（RPL）的性能评估
Abstract
摘要
This document presents a performance evaluation of the Routing Protocol for Low-Power and Lossy Networks (RPL) for a small outdoor deployment of sensor nodes and for a large-scale smart meter network. Detailed simulations are carried out to produce several routing performance metrics using these real-life deployment scenarios. Please refer to the PDF version of this document, which includes several plots for the performance metrics not shown in the plain-text version.
本文介绍了一种适用于小型户外传感器节点部署和大规模智能电表网络的低功耗有损网络（RPL）路由协议的性能评估。使用这些实际部署场景进行了详细的模拟，以生成若干路由性能指标。请参阅本文档的PDF版本，其中包括一些纯文本版本中未显示的性能指标图。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见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/rfc6687.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6687.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Methodology and Simulation Setup ................................4
4. Performance Metrics .............................................7
4.1. Common Assumptions .........................................7
4.2. Path Quality ...............................................7
4.3. Routing Table Size ........................................10
4.4. Delay Bound for P2P Routing ...............................10
4.5. Control Packet Overhead ...................................11
4.6. Loss of Connectivity ......................................13
5. RPL in a Building Automation Routing Scenario ..................18
5.1. Path Quality ..............................................18
5.2. Delay .....................................................19
6. RPL in a Large-Scale Network ...................................19
6.1. Path Quality ..............................................19
6.2. Delay .....................................................21
6.3. Control Packet Overhead ...................................21
7. Scaling Property and Routing Stability .........................22
8. Comments .......................................................24
9. Security Considerations ........................................25
10. Acknowledgements ..............................................25
11. Informative References ........................................25
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Methodology and Simulation Setup ................................4
4. Performance Metrics .............................................7
4.1. Common Assumptions .........................................7
4.2. Path Quality ...............................................7
4.3. Routing Table Size ........................................10
4.4. Delay Bound for P2P Routing ...............................10
4.5. Control Packet Overhead ...................................11
4.6. Loss of Connectivity ......................................13
5. RPL in a Building Automation Routing Scenario ..................18
5.1. Path Quality ..............................................18
5.2. Delay .....................................................19
6. RPL in a Large-Scale Network ...................................19
6.1. Path Quality ..............................................19
6.2. Delay .....................................................21
6.3. Control Packet Overhead ...................................21
7. Scaling Property and Routing Stability .........................22
8. Comments .......................................................24
9. Security Considerations ........................................25
10. Acknowledgements ..............................................25
11. Informative References ........................................25
Designing a routing protocol for Low-Power and Lossy Networks (LLNs) imposes great challenges, mainly due to low data rates, high probability of packet delivery failure, and strict energy constraints in the nodes. The IETF ROLL Working Group took on this task and specified the Routing Protocol for Low-Power and Lossy Networks (RPL) in [RFC6550].
为低功耗有损网络（LLN）设计路由协议带来了巨大的挑战，主要是由于低数据速率、高分组传送失败概率以及节点中严格的能量约束。IETF ROLL工作组承担了这项任务，并在[RFC6550]中规定了低功耗和有损网络（RPL）的路由协议。
RPL is designed to meet the core requirements specified in [RFC5826], [RFC5867], [RFC5673], and [RFC5548].
RPL旨在满足[RFC5826]、[RFC5867]、[RFC5673]和[RFC5548]中规定的核心要求。
This document's contribution is to provide a performance evaluation of RPL with respect to several metrics of interest. This is accomplished using real data and topologies in a discrete event simulator developed to reproduce the protocol behavior.
本文档的贡献是提供RPL在几个相关指标方面的性能评估。这是使用离散事件模拟器中的真实数据和拓扑实现的，该模拟器用于重现协议行为。
The following metrics are evaluated:
评估以下指标：
o Path quality metrics, such as ETX path cost, ETX path stretch, ETX fractional stretch, and hop distance stretch, as defined in Section 2 ("Terminology");
o 路径质量指标，如第2节（“术语”）中定义的ETX路径成本、ETX路径延伸、ETX分数延伸和跳距延伸；
o Control plane overhead;
o 头顶控制平面；
o End-to-end delay between nodes;
o 节点间的端到端延迟；
o Ability to cope with unstable situations (link churns, node dying);
o 能够应对不稳定的情况（链路混乱、节点死亡）；
o Required resource constraints on nodes (routing table size).
o 节点上所需的资源约束（路由表大小）。
Some of these metrics are mentioned in the aforementioned RFCs, whereas others have been introduced to consider the challenges and unique requirements of LLNs as discussed in [RFC6550]. For example, routing in a home automation deployment has strict time bounds on protocol convergence after any change in topology, as mentioned in Section 3.4 of [RFC5826]. [RFC5673] requires bounded and guaranteed end-to-end delay for routing in an industrial deployment, and [RFC5548] requires comparatively loose bounds on latency for end-to-end communication. [RFC5548] mandates scalability in terms of protocol performance for a network of size ranging from 10^2 to 10^4 nodes.
在上述RFC中提到了这些度量中的一些，而另一些则被引入来考虑在RFC650]中讨论的LLNS的挑战和独特要求。例如，如[RFC5826]第3.4节所述，在拓扑结构发生任何变化后，家庭自动化部署中的路由对协议收敛有严格的时间限制。[RFC5673]要求工业部署中的路由具有有界且有保证的端到端延迟，而[RFC5548]要求端到端通信具有相对宽松的延迟限制。[RFC5548]要求在10^2到10^4节点范围内的网络的协议性能方面具有可扩展性。
Although simulation cannot prove formally that a protocol operates properly in all situations, it can give a good level of confidence in protocol behavior in highly stressful conditions, if and only if real-life data are used. Simulation is particularly useful when theoretical model assumptions may not be applicable to such networks and scenarios. In this document, real deployed network data traces have been used to model link behaviors and network topologies.
尽管模拟不能正式证明协议在所有情况下都能正常运行，但只要使用真实数据，它可以在高压力条件下对协议行为提供良好的信心。当理论模型假设可能不适用于此类网络和场景时，模拟特别有用。在本文档中，实际部署的网络数据跟踪已用于建模链路行为和网络拓扑。
Please refer to [ROLL-TERMS] and [RFC6550] for terminology. In addition, the following terms are specified:
有关术语，请参考[ROLL-TERMS]和[RFC6550]。此外，还规定了以下术语：
PDR: Packet Delivery Ratio.
PDR：数据包交付率。
CDF: Cumulative Distribution Function.
CDF：累积分布函数。
Expected Transmission Count (ETX Metric): The expected number of transmissions to reach the next hop is determined as the inverse of the link PDR. Consequently, in every hop, if the link quality (PDR) is high, the expected number of transmissions to reach the next hop may be as low as 1. However, if the PDR for the particular link is low, multiple transmissions may be needed.
预期传输计数（ETX度量）：到达下一跳的预期传输数被确定为链路PDR的倒数。因此，在每一跳中，如果链路质量（PDR）高，则到达下一跳的预期传输数量可低至1。然而，如果特定链路的PDR低，则可能需要多个传输。
ETX Path Cost: The ETX path cost metric is determined as the summation of the ETX value for each link on the route a packet takes towards the destination.
ETX路径成本：ETX路径成本度量被确定为数据包到达目的地的路由上每个链路的ETX值的总和。
ETX Path Cost Stretch: The ETX path cost stretch is defined as the difference between the number of expected transmissions (ETX Metric) taken by a packet traveling from source to destination, following a route determined by RPL and a route determined by a hypothetical ideal shortest path routing protocol (using link ETX as the metric).
ETX路径成本延伸：ETX路径成本延伸定义为数据包按照RPL确定的路由从源传输到目的地的预期传输次数（ETX度量）与假设的理想最短路径路由协议（使用链路ETX作为度量）确定的路由之间的差。
ETX Fractional Stretch (fractional stretch factor of link ETX metric against ideal shortest path): The fractional path stretch is the ratio of ETX path stretch to ETX path cost for the shortest path route for the source-destination pair.
ETX分数拉伸（链路ETX度量相对于理想最短路径的分数拉伸因子）：分数路径拉伸是源-目的地对的最短路径路径的ETX路径拉伸与ETX路径成本的比率。
Hop Distance Stretch (stretch factor for node hop distance against ideal shortest path): The hop distance stretch is defined as the difference between the number of hops taken by a packet traveling from source to destination, following a route determined by RPL and by a hypothetical ideal shortest path algorithm, both using ETX as the link cost. The fractional hop distance stretch is computed as the ratio of path stretch to count value between a source-destination pair for the hypothetical shortest path route optimizing ETX path cost.
跳距延伸（节点跳距相对于理想最短路径的延伸系数）：跳距延伸定义为数据包按照RPL和假设的理想最短路径算法确定的路由从源到目的地的跳数之差，两者均使用ETX作为链路成本。分数跳距离延伸计算为假设最短路径路径优化ETX路径成本的源-目的地对之间的路径延伸与计数值之比。
In the context of this document, RPL has been simulated using OMNeT++ [OMNeTpp], a well-known discrete event-based simulator written in C++ and NEtwork Description (NED). Castalia-2.2 [Castalia-2.2] has been used as a Wireless Sensor Network Simulator framework within OMNeT++. The output and events in the simulation are visualized with the help of the Network AniMator, or NAM, which is distributed with the NS (Network Simulator) [NS-2].
在本文档的上下文中，使用OMNET++[OMNETPP]，一个著名的基于C++的离散事件模拟器和网络描述（NED）对RPL进行了仿真。Castalia-2.2[Castalia-2.2]已被用作OMNeT++中的无线传感器网络模拟器框架。模拟中的输出和事件在网络动画制作者（NAM）的帮助下可视化，NAM与NS（网络模拟器）[NS-2]一起分发。
Note that no versions of the NS itself are used in this simulation study. Only the visualization tool was borrowed for verification purposes.
请注意，本模拟研究中未使用NS本身的任何版本。仅借用可视化工具进行验证。
In contrast with theoretical models, which may have assumptions not applicable to lossy links, real-life data was used for two aspects of the simulations:
与理论模型（其假设可能不适用于有损链路）相比，真实数据用于模拟的两个方面：
* Link Failure Model: Derived from time-varying real network traces containing packet delivery probability for each link, over all channels, for both indoor network deployment and outdoor network deployment.
* 链路故障模型：从时变真实网络跟踪中导出，该跟踪包含室内网络部署和室外网络部署的所有信道上每条链路的数据包交付概率。
* Topology: Gathered from real-life deployment (traces mentioned above) as opposed to random topology simulations.
* 拓扑：从实际部署（上面提到的跟踪）收集，而不是随机拓扑模拟。
A 45-node topology, deployed as an outdoor network and shown in Figure 1, and a 2442-node topology, gathered from a smart meter network deployment, were used in the simulations. In Figure 1, links between a most preferred parent node and child nodes are shown in red. Links that are shown in black are also part of the topology but are not between a preferred parent and child node.
模拟中使用了一个45节点的拓扑（部署为室外网络，如图1所示）和一个2442节点的拓扑（收集自智能电表网络部署）。在图1中，最首选的父节点和子节点之间的链接显示为红色。以黑色显示的链接也是拓扑的一部分，但不在首选父节点和子节点之间。
Figure 1 [See the PDF.]
图1[参见PDF。]
Figure 1: Outdoor Network Topology with 45 Nodes.
图1：具有45个节点的室外网络拓扑。
Note that this is just a start to validate the simulation before using large-scale networks.
请注意，这只是在使用大规模网络之前验证模拟的一个开始。
A set of time-varying link quality data was gathered from a real network deployment to form a database used for the simulations. Each link in the topology randomly 'picks up' a link model (trace) from the database. Each link has a Packet Delivery Ratio (PDR) that varies with time (in the simulation, a new PDR is read from the database every 10 minutes) according to the gathered data. Packets are dropped randomly from that link with probability (1 - PDR). Each time a packet is about to be sent, the module generates a random number using the Mersenne Twister random number generation method. The random number is compared to the PDR to determine whether the packet should be dropped. Note that each link uses a different random number generator to maintain true randomness in the simulator and to avoid correlation between links. Also, the packet drop applies to all kinds of data and control packets (RPL), such as the DIO, DAO, and DIS packets defined in [RFC6550]. Figure 2 shows a typical temporal characteristic of links from the indoor network traces used in the simulations. The figure shows several links with perfect connectivity, some links with a PDR as low as 10%, and several for which the PDR may vary from 30% to 80%, sharply changing back and forth between a high value (strong connectivity) and a low value (weak connectivity).
从实际网络部署中收集一组时变链路质量数据，以形成用于模拟的数据库。拓扑中的每个链接从数据库中随机“拾取”一个链接模型（跟踪）。每个链路都有一个根据收集的数据随时间变化的数据包交付率（PDR）（在模拟中，每10分钟从数据库读取一个新的PDR）。数据包以概率（1-PDR）从该链路随机丢弃。每次即将发送数据包时，模块使用Mersenne Twister随机数生成方法生成一个随机数。将随机数与PDR进行比较，以确定是否应丢弃数据包。请注意，每个链接使用不同的随机数生成器来保持模拟器中的真实随机性，并避免链接之间的相关性。此外，数据包丢弃适用于所有类型的数据和控制数据包（RPL），如[RFC6550]中定义的DIO、DAO和DIS数据包。图2显示了模拟中使用的室内网络跟踪链路的典型时间特性。该图显示了几个具有完美连通性的链路，一些链路的PDR低至10%，一些链路的PDR可能在30%到80%之间变化，在高值（强连通性）和低值（弱连通性）之间来回急剧变化。
Figure 2 [See the PDF.]
图2[参见PDF。]
Figure 2: Example of Link Characteristics.
图2：链路特性示例。
In the RPL simulator, the LBR (LLN Border Router) or the Directed Acyclic Graph (DAG) root first initiates sending out DIO messages, and the DAG is gradually constructed. RPL makes use of trickle timers: the protocol sets a minimum time period with which the nodes start re-issuing DAOs, and this minimum period is denoted by the trickle parameter Imin. RPL also sets an upper limit on how many times this time period can be doubled; this is denoted by the parameter DIOIntervalDoublings, as defined in [RFC6550]. For the simulation, Imin is initially set to 1 second and DIOIntervalDoublings is equal to 16, and therefore the maximum time between two consecutive DIO emissions by a node (under a steady network condition) is 18.2 hours. The trickle time interval for emitting DIO messages assumes the initial value of 1 second and then changes over simulation time, as mentioned in [RFC6206].
在RPL仿真器中，LBR（LLN边界路由器）或有向无环图（DAG）根首先发起发送DIO消息，然后逐步构造DAG。RPL使用涓流计时器：协议设置了节点开始重新发出DAO的最短时间段，该最短时间段由涓流参数Imin表示。RPL还设定了一个上限，即这个时间段可以翻倍的次数；这由[RFC6550]中定义的参数DIOIntervalDoublings表示。对于模拟，Imin最初设置为1秒，DIOIntervalDoublings等于16，因此节点两次连续DIO发射之间的最大时间（在稳定网络条件下）为18.2小时。发射DIO消息的涓流时间间隔假定初始值为1秒，然后随着模拟时间的变化而变化，如[RFC6206]中所述。
Another objective of this study is to give insight to the network administrator on how to tweak the trickle values. These recommendations could then be used in applicability statement documents.
本研究的另一个目的是让网络管理员了解如何调整涓流值。这些建议可用于适用性声明文件中。
Each node in the network, other than the LBR or DAG root, also emits DAO messages as specified in [RFC6550], to initially populate the routing tables with the prefixes received from children via the DAO messages to support Point-to-Point (P2P) and Point-to-Multipoint (P2MP) traffic in the "down" direction. During these simulations, it is assumed that each node is capable of storing route information for other nodes in the network (storing mode of RPL).
除LBR或DAG根节点外，网络中的每个节点还发出[RFC6550]中指定的DAO消息，以使用通过DAO消息从子节点接收到的前缀来填充路由表，以支持“向下”方向的点对点（P2P）和点对多点（P2MP）通信。在这些模拟期间，假设每个节点能够存储网络中其他节点的路由信息（RPL存储模式）。
For nodes implementing RPL, as expected, the routing table memory requirement varies according to the position in the DODAG (Destination-Oriented DAG). The (worst-case) assumption is made that there is no route summarization (aggregation) in the network. Thus, a node closer to the DAG will have to store more entries in its routing table. It is also assumed that all nodes have equal memory capacity to store the routing states.
对于实现RPL的节点，正如预期的那样，路由表内存需求根据DODAG（面向目的地的DAG）中的位置而变化。（最坏情况）假设网络中没有路由摘要（聚合）。因此，靠近DAG的节点必须在其路由表中存储更多的条目。还假设所有节点具有相同的内存容量来存储路由状态。
For simulations of the indoor network, each node sends traffic according to a Constant Bit Rate (CBR) to all other nodes in the network, over the simulation period. Each node generates a new data packet every 10 seconds. Each data packet has a size of 127 bytes including 802.15.4 PHY/MAC headers and RPL packet headers. All control packets are also encapsulated with 802.15.4 PHY/MAC headers. To simulate a more realistic scenario, 80% of the packets generated by each node are destined to the root, and the remaining 20% of the
对于室内网络的模拟，每个节点在模拟期间根据恒定比特率（CBR）向网络中的所有其他节点发送流量。每个节点每10秒生成一个新的数据包。每个数据包的大小为127字节，包括802.15.4 PHY/MAC报头和RPL数据包报头。所有控制数据包也使用802.15.4 PHY/MAC头进行封装。为了模拟更现实的场景，每个节点生成的80%的数据包将发送到根节点，其余20%的数据包将发送到根节点
packets are uniformly assigned as destined to nodes other than the root. Therefore, the root receives a considerably larger amount of data than other nodes. These values may be revised when studying P2P traffic so as to have a majority of traffic going to all nodes as opposed to the root. In the later part of the simulation, a typical home/building routing scenario is also simulated, and different path quality metrics are computed for that traffic pattern.
数据包被统一分配为目的地，而不是根节点。因此，根节点接收的数据量比其他节点大得多。在研究P2P流量时，可以修改这些值，以使大部分流量流向所有节点，而不是根节点。在模拟的后面部分，还模拟了一个典型的住宅/建筑路由场景，并为该交通模式计算了不同的路径质量度量。
The packets are routed through the DODAG built by RPL according to the mechanisms specified in [RFC6550].
根据[RFC6550]中指定的机制，数据包通过RPL构建的DODAG路由。
A number of RPL parameters are varied (such as the packet rate from each source and the time period for emitting a new DAG sequence number) to observe their effect on the performance metric of interest.
许多RPL参数是变化的（例如来自每个源的分组速率和发出新DAG序列号的时间段），以观察它们对感兴趣的性能度量的影响。
As the DAO messages are used to feed the routing tables in the network, they grow with time and size of the network. Nevertheless, no constraint was imposed on the size of the routing table nor on how much information the node can store. The routing table size is not expressed in terms of Kbytes of memory usage but measured in terms of the number of entries for each node. Each entry has the next-hop node and path cost associated with the destination node.
当DAO消息被用于为网络中的路由表提供信息时，它们会随着网络的时间和大小而增长。然而，没有对路由表的大小或节点可以存储多少信息施加任何约束。路由表的大小不是用内存使用的KB表示的，而是用每个节点的条目数来度量的。每个条目都具有与目标节点关联的下一跳节点和路径开销。
The link ETX (Expected Transmission Count) metric is used to build the DODAG and is specified in [RFC6551].
链路ETX（预期传输计数）指标用于构建DODAG，并在[RFC6551]中指定。
Hop Count: For each source-destination pair, the number of hops for both RPL and shortest path routing is computed. Shortest path routing refers to a hypothetical ideal routing protocol that would always provide the shortest path in terms of ETX path cost (or whichever metric is used) in the network.
跳数：对于每个源-目的地对，计算RPL和最短路径路由的跳数。最短路径路由是指一种假设的理想路由协议，该协议将始终提供网络中ETX路径成本（或使用的任何度量）方面的最短路径。
The Cumulative Distribution Function (CDF) of the hop count for all paths (n * (n - 1) in an n-node network) in the network with respect to the hop count is plotted in Figure 3 for both RPL and shortest path routing. One can observe that the CDF corresponding to 4 hops is around 80% for RPL and 90% for shortest path routing. In other words, for the given topology, 90% of the paths have a path length of 4 hops or less with an ideal shortest path routing methodology, whereas in RPL P2P routing, 90% of the paths will have a length of no more than 5 hops. This result indicates that despite having a
对于RPL和最短路径路由，网络中所有路径（n节点网络中的n*（n-1））的跃点计数相对于跃点计数的累积分布函数（CDF）如图3所示。可以观察到，对于RPL，对应于4跳的CDF约为80%，对于最短路径路由，CDF约为90%。换句话说，对于给定的拓扑，90%的路径具有4跳或更少的路径长度，采用理想的最短路径路由方法，而在RPL P2P路由中，90%的路径的长度不超过5跳。这一结果表明，尽管
non-optimized P2P routing scheme, the path quality of RPL is close to an optimized P2P routing mechanism for the topology under consideration. Another reason for this may relate to the fact that the DAG root is at the center of the network; thus, routing through the DAG root is often close to an optimal (shortest path) routing. This result may be different in a topology where the DAG root is located at one end of the network.
非优化P2P路由方案，RPL的路径质量接近于所考虑拓扑的优化P2P路由机制。另一个原因可能与DAG根位于网络中心有关；因此，通过DAG根的路由通常接近最优（最短路径）路由。在DAG根位于网络一端的拓扑中，此结果可能不同。
Figure 3 [See the PDF.]
图3[参见PDF。]
Figure 3: CDF of Hop Count versus Hop Count.
图3：跳数与跳数的CDF。
ETX Path Cost: In the simulation, the total ETX path cost (defined in the Terminology section) from source to destination for each packet is computed.
ETX路径成本：在模拟中，计算每个数据包从源到目标的总ETX路径成本（在术语部分中定义）。
Figure 4 shows the CDF of the total ETX path cost, both with RPL and shortest path routing. Here also one can observe that the ETX path cost from all sources to all destinations is close to that of shortest path routing for the network.
图4显示了总ETX路径成本的CDF，包括RPL和最短路径路由。这里还可以观察到，从所有来源到所有目的地的ETX路径成本接近于网络的最短路径路由成本。
Figure 4 [See the PDF.]
图4[参见PDF。]
Figure 4: CDF of Total ETX Path Cost along Path versus ETX Path Cost.
图4:ETX路径总成本与ETX路径成本的CDF。
Path Stretch: The path stretch metric encompasses the stretch factor for both hop distance and ETX path cost (as defined in the Terminology section). The hop distance stretch, which is determined as the difference between the number of hops taken by a packet while following a route built via RPL and the number of hops taken by shortest path routing (using link ETX as the metric), is computed. The ETX path cost stretch is also provided.
路径拉伸：路径拉伸度量包含跳跃距离和ETX路径成本的拉伸因子（定义见术语部分）。计算跳距延伸，其被确定为遵循通过RPL构建的路由时数据包所采取的跳数与最短路径路由（使用链路ETX作为度量）所采取的跳数之间的差值。还提供了ETX路径成本延伸。
The CDF of both path stretch metrics is plotted against the value of the corresponding path stretch over all packets in Figures 5 and 6, for hop distance stretch and ETX path stretch, respectively. It can be observed that, for a few packets, the path built via RPL has fewer hops than the ideal shortest path where path ETX is minimized along the DAG. This is because there are a few source-destination pairs where the total ETX path cost is equal to or less than that of the ideal shortest path when the packet takes a longer hop count. As the RPL implementation ignores a 20% change in total ETX path cost before switching to a new parent or emitting a new DIO, it does not necessarily provide the shortest path in terms of total ETX path cost. Thus, this implementation yields a few paths with smaller hop counts but larger (or equal) total ETX path cost.
对于跳距离拉伸和ETX路径拉伸，两个路径拉伸度量的CDF分别与图5和图6中所有数据包上的相应路径拉伸值相对应。可以观察到，对于一些数据包，通过RPL构建的路径比理想的最短路径具有更少的跳数，其中路径ETX沿DAG最小化。这是因为当数据包需要更长的跳数时，有一些源-目的地对的总ETX路径成本等于或小于理想最短路径的成本。由于RPL实施在切换到新的父级或发出新的DIO之前忽略了ETX路径总成本的20%变化，因此它不一定提供ETX路径总成本方面的最短路径。因此，这种实现产生了一些跳数较小但总ETX路径成本较大（或相等）的路径。
Figure 5 [See the PDF.]
图5[参见PDF。]
Figure 5: CDF of Hop Distance Stretch versus Hop Distance Stretch Value.
图5：跳距拉伸与跳距拉伸值的CDF。
Figure 6 [See the PDF.]
图6[参见PDF。]
Figure 6: CDF of ETX Path Stretch versus ETX Path Stretch Value.
图6:ETX路径拉伸与ETX路径拉伸值的CDF。
The data for the CDF of the hop count and ETX path cost for the ideal shortest path (SP) and a path built via RPL, along with the CDF of the routing table size, is given below in Table 1. Figures 3 to 7 relate to the data in this table.
下表1给出了理想最短路径（SP）和通过RPL构建的路径的跳数和ETX路径成本的CDF数据，以及路由表大小的CDF。图3至图7与本表中的数据相关。
+---------+--------+---------+-----------+------------+-------------+
| CDF | Hop | Hop | ETX Cost | ETX Cost | Routing |
| (%age) | (SP) | (RPL) | (SP) | (RPL) | Table Size |
+---------+--------+---------+-----------+------------+-------------+
| 0 | 1.0 | 1.0 | 1 | 1.0 | 0 |
| 5 | 1.0 | 1.03 | 1 | 1.242 | 1 |
| 10 | 2.0 | 2.0 | 2 | 2.048 | 2 |
| 15 | 2.0 | 2.01 | 2 | 2.171 | 2 |
| 20 | 2.0 | 2.06 | 2 | 2.400 | 2 |
| 25 | 2.0 | 2.11 | 2 | 2.662 | 3 |
| 30 | 2.0 | 2.42 | 2 | 2.925 | 3 |
| 35 | 2.0 | 2.90 | 3 | 3.082 | 3 |
| 40 | 3.0 | 3.06 | 3 | 3.194 | 4 |
| 45 | 3.0 | 3.1 | 3 | 3.41 | 4 |
| 50 | 3.0 | 3.15 | 3 | 3.626 | 4 |
| 55 | 3.0 | 3.31 | 3 | 3.823 | 5 |
| 60 | 3.0 | 3.50 | 3 | 4.032 | 6 |
| 65 | 3.0 | 3.66 | 3 | 4.208 | 7 |
| 70 | 3.0 | 3.92 | 4 | 4.474 | 7 |
| 75 | 4.0 | 4.16 | 4 | 4.694 | 7 |
| 80 | 4.0 | 4.55 | 4 | 4.868 | 8 |
| 85 | 4.0 | 4.70 | 4 | 5.091 | 9 |
| 90 | 4.0 | 4.89 | 4 | 5.488 | 10 |
| 95 | 4.0 | 5.65 | 5 | 5.923 | 12 |
| 100 | 5.0 | 7.19 | 9 | 10.125 | 44 |
+---------+--------+---------+-----------+------------+-------------+
+---------+--------+---------+-----------+------------+-------------+
| CDF | Hop | Hop | ETX Cost | ETX Cost | Routing |
| (%age) | (SP) | (RPL) | (SP) | (RPL) | Table Size |
+---------+--------+---------+-----------+------------+-------------+
| 0 | 1.0 | 1.0 | 1 | 1.0 | 0 |
| 5 | 1.0 | 1.03 | 1 | 1.242 | 1 |
| 10 | 2.0 | 2.0 | 2 | 2.048 | 2 |
| 15 | 2.0 | 2.01 | 2 | 2.171 | 2 |
| 20 | 2.0 | 2.06 | 2 | 2.400 | 2 |
| 25 | 2.0 | 2.11 | 2 | 2.662 | 3 |
| 30 | 2.0 | 2.42 | 2 | 2.925 | 3 |
| 35 | 2.0 | 2.90 | 3 | 3.082 | 3 |
| 40 | 3.0 | 3.06 | 3 | 3.194 | 4 |
| 45 | 3.0 | 3.1 | 3 | 3.41 | 4 |
| 50 | 3.0 | 3.15 | 3 | 3.626 | 4 |
| 55 | 3.0 | 3.31 | 3 | 3.823 | 5 |
| 60 | 3.0 | 3.50 | 3 | 4.032 | 6 |
| 65 | 3.0 | 3.66 | 3 | 4.208 | 7 |
| 70 | 3.0 | 3.92 | 4 | 4.474 | 7 |
| 75 | 4.0 | 4.16 | 4 | 4.694 | 7 |
| 80 | 4.0 | 4.55 | 4 | 4.868 | 8 |
| 85 | 4.0 | 4.70 | 4 | 5.091 | 9 |
| 90 | 4.0 | 4.89 | 4 | 5.488 | 10 |
| 95 | 4.0 | 5.65 | 5 | 5.923 | 12 |
| 100 | 5.0 | 7.19 | 9 | 10.125 | 44 |
+---------+--------+---------+-----------+------------+-------------+
Table 1: Path Quality CDFs.
表1：路径质量CDF。
Overall, the path quality metrics give us important information about the protocol's performance when minimizing the ETX path cost is the objective to form the DAG. The protocol, as explained, does not always provide an optimum path, especially for peer-to-peer communication. However, it does end up reducing the control overhead
总的来说，当形成DAG的目标是最小化ETX路径成本时，路径质量度量为我们提供了有关协议性能的重要信息。正如所解释的，该协议并不总是提供最佳路径，特别是对于对等通信。然而，它最终确实减少了控制开销
cost, thereby reducing unnecessary parent selection and DIO message forwarding events, by choosing a non-optimized path. Despite this specific implementation technique, around 30% of the packets travel the same number of hops as an ideal shortest path routing mechanism, and 20% of the packets experience the same number of attempted transmissions to reach the destination. On average, this implementation costs only a few extra transmission attempts and saves a large number of control packet transmissions.
成本，从而通过选择非优化路径减少不必要的父选择和DIO消息转发事件。尽管有这种特定的实现技术，但大约30%的数据包与理想的最短路径路由机制具有相同的跳数，20%的数据包经历相同的尝试传输次数以到达目的地。平均而言，这种实现只需花费一些额外的传输尝试，并节省大量的控制数据包传输。
The objective of this metric is to observe the distribution of the number of entries per node. Figure 7 shows the CDF of the number of routing table entries for all nodes. Note that 90% of the nodes need to store less than 10 entries in their routing table for the topology under study. The LBR does not have the same power or memory constraints as regular nodes do, and hence it can accommodate entries for all the nodes in the network. The requirement to accommodate devices with low storage capacity has been mandated in [RFC5673], [RFC5826], and [RFC5867]. However, when RPL is implemented in storing mode, some nodes closer to the LBR or DAG root will require more memory to store larger routing tables.
此度量的目标是观察每个节点的条目数分布。图7显示了所有节点的路由表条目数的CDF。请注意，90%的节点需要在其路由表中为所研究的拓扑存储少于10个条目。LBR不像常规节点那样具有相同的功率或内存限制，因此它可以容纳网络中所有节点的条目。[RFC5673]、[RFC5826]和[RFC5867]中规定了容纳低存储容量设备的要求。但是，当以存储模式实现RPL时，靠近LBR或DAG根的一些节点将需要更多内存来存储更大的路由表。
Figure 7 [See the PDF.]
图7[参见PDF。]
Figure 7: CDF of Routing Table Size with Respect to Number of Nodes.
图7：路由表大小相对于节点数的CDF。
For delay-sensitive applications, such as home and building automation, it is critical to optimize the end-to-end delay. Figure 8 shows the upper bound and distributions of delay for paths between any two given nodes for different hop counts between the source and destination. Here, the hop count refers to the number of hops a packet travels to reach the destination when using RPL paths. This hop distance does not correspond to the shortest path distance between two nodes. Note that each packet has a length of 127 bytes, with a 240-kbps radio, which makes the transmission delay approximately 4 milliseconds (ms).
对于延迟敏感的应用，如家庭和楼宇自动化，优化端到端延迟至关重要。图8显示了源和目标之间不同跳数下任意两个给定节点之间路径的延迟上限和分布。这里，跳数是指当使用RPL路径时，数据包到达目的地的跳数。此跃点距离与两个节点之间的最短路径距离不对应。请注意，每个数据包的长度为127字节，使用240 kbps的无线电，这使得传输延迟约为4毫秒（ms）。
Figure 8 [See the PDF.]
图8[参见PDF。]
Figure 8: Comparison of Packet Latency, for Different Path Lengths, Expressed in Hop Count.
图8：不同路径长度的数据包延迟比较，以跳数表示。
RFCs 5673 [RFC5673] and 5548 [RFC5548] mention a requirement for the end-to-end delivery delay to remain within a bounded latency. For instance, according to the industrial routing requirement,
RFCs 5673[RFC5673]和5548[RFC5548]提到了端到端交付延迟保持在限定延迟内的要求。例如，根据工业布线要求，
non-critical closed-loop applications may have a latency requirement that can be as low as 100 ms, whereas monitoring services may tolerate a delay in the order of seconds. The results show that about 99% of the end-to-end communication (where the maximum hop count is 7 hops) is bounded within the 100-ms requirement, for the topology under study. It should be noted that due to poor link condition, there may be packet drops triggering retransmission, which may cause larger end-to-end delivery delays. Nodes in the proximity of the LBR may become congested at high traffic loads, which can also lead to higher end-to-end delay.
非关键闭环应用程序的延迟要求可能低至100毫秒，而监控服务可能会容忍秒级的延迟。结果表明，对于所研究的拓扑结构，约99%的端到端通信（最大跳数为7跳）限制在100ms的要求范围内。应当注意，由于不良链路条件，可能存在触发重传的分组丢弃，这可能导致更大的端到端递送延迟。LBR附近的节点可能在高流量负载下变得拥挤，这也可能导致更高的端到端延迟。
The control plane overhead is an important routing characteristic in LLNs. It is imperative to bound the control plane overhead. One of the distinctive characteristics of RPL is that it makes use of trickle timers so as to reduce the number of control plane packets by eliminating redundant messages. The aim of this performance metric is thus to analyze the control plane overhead both in stable conditions (no network element failure overhead) and in the presence of failures.
控制平面开销是LLN中一个重要的路由特性。必须将控制飞机绑在头顶上。RPL的一个显著特点是，它利用涓流定时器，通过消除冗余消息来减少控制平面数据包的数量。因此，该性能指标的目的是分析稳定条件（无网元故障开销）和存在故障时的控制平面开销。
Data and control plane traffic comparison for each node: Figure 9 shows the comparison between the amount of data packets transmitted (including forwarded packets) and control packets (DIO and DAO messages) transmitted for all individual nodes when link ETX is used to optimize the DAG. As mentioned earlier, each node generates a new data packet every 10 seconds. Here one can observe that a considerable amount of traffic is routed through the DAG root itself. The x axis indicates the node ID in the network. Also, as expected, the nodes that are closer to the DAG root and that act as routers (as opposed to leaves) handle much more data traffic than other nodes. Nodes 12, 36, and 38 are examples of nodes next to the DAG root, taking part in routing most of the data packets and hence having many more data packet transmissions than other nodes, as observed in Figure 9. We can also observe that the proportion of control traffic is negligible for those nodes. This result also reinforces the fact that the amount of control plane traffic generated by RPL is negligible on these topologies. Leaf nodes have comparable amounts of data and control packet transmissions (they do not take part in routing the data).
每个节点的数据和控制平面流量比较：图9显示了当使用链路ETX优化DAG时，为所有单个节点发送的数据包（包括转发的数据包）和控制包（DIO和DAO消息）数量之间的比较。如前所述，每个节点每10秒生成一个新的数据包。在这里，可以观察到相当数量的流量通过DAG根本身进行路由。x轴表示网络中的节点ID。此外，正如预期的那样，靠近DAG根并充当路由器（与叶相反）的节点比其他节点处理更多的数据流量。节点12、36和38是DAG根旁边的节点的示例，参与路由大多数数据分组，因此具有比其他节点多得多的数据分组传输，如图9所示。我们还可以观察到，对于这些节点，控制流量的比例可以忽略不计。这一结果还强化了这样一个事实，即在这些拓扑上，RPL生成的控制平面流量可以忽略不计。叶节点具有相当数量的数据并控制数据包传输（它们不参与数据路由）。
Figure 9 [See the PDF.]
图9[参见PDF。]
Figure 9: Amount of Data and Control Packets Transmitted against Node Id Using Link ETX as Routing Metric.
图9：使用链路ETX作为路由度量，根据节点Id传输的数据和控制数据包的数量。
Data and control packet transmission with respect to time: In Figures 10, 11, and 12, the amount of data and control packets transmitted for node 12 (low rank in DAG, closer to the root), node 43 (in the middle), and node 31 (leaf node) are shown, respectively. These values stand for the number of data and control packets transmitted for each 10-minute interval for the particular node, to help understand what the ratio is between data and control packets exchanged in the network. One can observe that nodes closer to the DAG root have a higher proportion of data packets (as expected), and the proportion of control traffic is negligible in comparison with the data traffic. Also, the amount of data traffic handled by a node within a given interval varies largely over time for a node closer to the DAG root, because in each interval the destination of the packets from the same source changes, while 20% of the packets are destined to the DAG root. As a result, the pattern of the traffic that is handled changes widely in each interval for the nodes closer to the DAG root. For the nodes that are farther away from the DAG root, the ratio of data traffic to control traffic is smaller, since the amount of data traffic is greatly reduced.
关于时间的数据和控制包传输：在图10、11和12中，分别显示了节点12（DAG中的低秩，更接近根）、节点43（中间）和节点31（叶节点）传输的数据和控制包的数量。这些值表示特定节点每10分钟发送的数据和控制数据包的数量，以帮助了解网络中交换的数据和控制数据包之间的比率。可以观察到，靠近DAG根的节点有更高比例的数据包（如预期的那样），与数据流量相比，控制流量的比例可以忽略不计。此外，对于更靠近DAG根的节点，节点在给定间隔内处理的数据通信量随着时间的推移而变化很大，因为在每个间隔中，来自同一源的数据包的目的地发生变化，而20%的数据包目的地是DAG根。因此，对于靠近DAG根的节点，处理的流量模式在每个间隔中都会发生很大的变化。对于距离DAG根较远的节点，数据通信量与控制通信量的比率较小，因为数据通信量大大减少。
The control traffic load exhibits a wave-like pattern. The amount of control packets for each node drops quickly as the DODAG stabilizes, due to the effect of trickle timers. However, when a new DODAG sequence is advertised (global repair of the DODAG), the trickle timers are reset and the nodes start emitting DIOs frequently again to rebuild the DODAG. For a node closer to the DAG root, the amount of data packets is much larger than that of control packets and somewhat oscillatory around a mean value. The amount of control packets exhibits a 'saw-tooth' behavior. In the case where the ETX link metric is used, when the PDR changes, the ETX link metric for a node to its child changes, which may lead to choosing a new parent and changing the DAG rank of the child. This event resets the trickle timer and triggers the emission of a new DIO. Also, the issue of a new DODAG sequence number triggers DODAG re-computation and resets the trickle timers. Therefore, one can observe that the number of control packets attains a high value for one interval and comes down to lower values for subsequent intervals. The interval with a high number of control packets denotes the interval where the timers to emit a new DIO are reset more frequently. As the network stabilizes, the control packets are less dense in volume. For leaf nodes, the amount of control packets is comparable to that of data packets, as leaf nodes are more prone to face changes in their DODAG rank as opposed to nodes closer to the DAG root when the link ETX value in the topology changes dynamically.
控制交通负荷呈波浪状分布。由于涓流计时器的影响，当DODAG稳定时，每个节点的控制数据包数量迅速下降。但是，当发布新的DODAG序列（DODAG的全局修复）时，涓流计时器将重置，节点将再次频繁地发射DIO以重建DODAG。对于靠近DAG根的节点，数据包的数量远大于控制包的数量，并且在平均值附近有些振荡。控制数据包的数量表现出“锯齿”行为。在使用ETX链路度量的情况下，当PDR改变时，节点到其子节点的ETX链路度量改变，这可能导致选择新的父节点并改变子节点的DAG秩。此事件重置涓流计时器并触发新DIO的发射。此外，发布新的DODAG序列号会触发DODAG重新计算并重置涓流计时器。因此，可以观察到，控制分组的数量在一个间隔中达到高值，在随后的间隔中下降到低值。具有大量控制数据包的间隔表示发送新DIO的计时器被更频繁地重置的间隔。随着网络的稳定，控制数据包的体积密度降低。对于叶节点，控制数据包的数量与数据包的数量相当，因为当拓扑中的链路ETX值动态变化时，叶节点更容易面临其DODAG秩的变化，而不是更接近DAG根的节点。
Figure 10 [See the PDF.]
图10[参见PDF。]
Figure 10: Amount of Data and Control Packets Transmitted for Node 12.
图10：为节点12传输的数据和控制数据包的数量。
Figure 11 [See the PDF.]
图11[参见PDF。]
Figure 11: Amount of Data and Control Packets Transmitted for Node 43.
图11：为节点43传输的数据和控制包的数量。
Figure 12 [See the PDF.]
图12[参见PDF。]
Figure 12: Amount of Data and Control Packets Transmitted for Node 31.
图12：为节点31传输的数据和控制包的数量。
Upon link failures, a node may lose its parents -- preferred and backup (if any) -- thus leading to a loss of connectivity (no path to the DAG root). RPL specifies two mechanisms for DODAG repairs, referred to as global repair and local repair. In this document, simulation results are presented to evaluate the amount of time data packets are dropped due to a loss of connectivity for the following two cases: a) when only using global repair (i.e., the DODAG is rebuilt thanks to the emission of new DODAG sequence numbers by the DAG root), and b) when using local repair (poisoning the sub-DAG in case of loss of connectivity) in addition to global repair. The idea is to tune the frequency at which new DODAG sequence numbers are generated by the DAG root, and also to observe the effect of varying the frequency for global repair and the concurrent use of global and local repair. It is expected that more frequent increments of DODAG sequence numbers will lead to a shorter duration of connectivity loss at a price of a higher rate of control packets in the network. For the use of both global and local repair, the simulation results show the trade-off in amount of time that a node may remain without service and total number of control packets.
链接失败时，节点可能会丢失其父节点（首选和备份（如果有）），从而导致连接丢失（没有到DAG根的路径）。RPL为DODAG修复指定了两种机制，称为全局修复和局部修复。在本文中，给出了模拟结果，以评估以下两种情况下由于连接丢失而丢弃数据包的时间量：a）仅使用全局修复时（即，由于DAG根发射新的DODAG序列号而重建DODAG），以及b）使用局部修复时（在连接中断的情况下使子DAG中毒）除了全局修复。该想法是调整DAG根生成新DODAG序列号的频率，并观察改变全局修复频率以及同时使用全局和局部修复的效果。预计更频繁的DODAG序列号增量将导致缩短r以网络中较高速率的控制数据包为代价的连接丢失持续时间。对于使用全局和本地修复，模拟结果显示了节点可能不提供服务的时间量和控制数据包总数的权衡。
Figure 13 shows the CDF of time spent by any node without service, when the data packet rate is one packet every 10 seconds and a new DODAG sequence number is generated every 10 minutes. This plot reflects the property of global repair without any local repair scheme. When all the parents are temporarily unreachable from a node, the time before it hears a DIO from another node is recorded, which gives the time without service. We define the DAG repair timer as the interval at which the LBR increments the DAG sequence number,
图13显示了当数据分组速率为每10秒一个分组，并且每10分钟生成一个新的DODAG序列号时，没有服务的任何节点所花费的时间CDF。此图反映了全局修复的特性，而没有任何局部修复方案。当一个节点暂时无法访问所有的父节点时，会记录它从另一个节点听到DIO之前的时间，这会给出没有服务的时间。我们将DAG修复计时器定义为LBR增加DAG序列号的间隔，
thus triggering a global re-optimization. In some cases, this value might go up to the DAG repair timer value, because until a DIO is heard, the node does not have a parent and hence no route to the LBR or other nodes not in its own sub-DAG. Clearly, this situation indicates a lack of connectivity and loss of service for the node.
从而触发一个全局重新优化。在某些情况下，此值可能上升到DAG修复计时器值，因为在听到DIO之前，节点没有父节点，因此没有到LBR或不在其自身子DAG中的其他节点的路由。显然，这种情况表明节点缺少连接和服务丢失。
Figure 13 [See the PDF.]
图13[参见PDF。]
Figure 13: CDF: Loss of Connectivity with Global Repair.
图13:CDF：失去与全局修复的连接。
The effect of the DAG repair timer on time without service is plotted in Figure 14, where the source rate is 20 seconds/packet and in Figure 15, where the source sends a packet every 10 seconds.
图14显示了DAG修复计时器对无服务时间的影响，其中源速率为20秒/包，图15显示源每隔10秒发送一个包。
Figure 14 [See the PDF.]
图14[参见PDF。]
Figure 14: CDF: Loss of Connectivity for Different Global Repair Period, Source Rate 20 Seconds/Packet.
图14:CDF：不同全局修复周期的连接丢失，源速率20秒/包。
Figure 15 [See the PDF.]
图15[参见PDF。]
Figure 15: CDF: Loss of Connectivity for Different Global Repair Period, Source Rate 10 Seconds/Packet.
图15:CDF：不同全局修复周期的连接丢失，源速率10秒/包。
The data for Figures 13 and 15 can be found in Table 2. The table shows how the CDF of time without connectivity to the LBR increases while we increase the time period to emit new DAG sequence numbers, when the nodes generate a packet every 10 seconds.
图13和图15的数据见表2。该表显示了当节点每10秒生成一个数据包时，当我们增加发送新DAG序列号的时间周期时，没有连接到LBR的时间CDF是如何增加的。
+---------+------------------+------------------+-------------------+
| CDF | Repair Period | Repair Period | Repair Period |
| (%age) | 10 Minutes | 30 Minutes | 60 Minutes |
+---------+------------------+------------------+-------------------+
| 0 | 0.464 | 0.045 | 0.027 |
| 5 | 0.609 | 0.424 | 0.396 |
| 10 | 1.040 | 1.451 | 0.396 |
| 15 | 1.406 | 3.035 | 0.714 |
| 20 | 1.934 | 3.521 | 0.714 |
| 25 | 2.113 | 5.461 | 1.856 |
| 30 | 3.152 | 5.555 | 1.856 |
| 35 | 3.363 | 7.756 | 6.173 |
| 40 | 4.9078 | 8.604 | 6.173 |
| 45 | 8.575 | 9.181 | 14.751 |
| 50 | 9.788 | 21.974 | 14.751 |
| 55 | 13.230 | 30.017 | 14.751 |
| 60 | 17.681 | 31.749 | 16.166 |
| 65 | 29.356 | 68.709 | 16.166 |
| 70 | 34.019 | 92.974 | 302.459 |
| 75 | 49.444 | 117.869 | 302.459 |
| 80 | 75.737 | 133.653 | 488.602 |
| 85 | 150.089 | 167.828 | 488.602 |
| 90 | 180.505 | 271.884 | 488.602 |
| 95 | 242.247 | 464.047 | 488.602 |
| 100 | 273.808 | 464.047 | 488.602 |
+---------+------------------+------------------+-------------------+
+---------+------------------+------------------+-------------------+
| CDF | Repair Period | Repair Period | Repair Period |
| (%age) | 10 Minutes | 30 Minutes | 60 Minutes |
+---------+------------------+------------------+-------------------+
| 0 | 0.464 | 0.045 | 0.027 |
| 5 | 0.609 | 0.424 | 0.396 |
| 10 | 1.040 | 1.451 | 0.396 |
| 15 | 1.406 | 3.035 | 0.714 |
| 20 | 1.934 | 3.521 | 0.714 |
| 25 | 2.113 | 5.461 | 1.856 |
| 30 | 3.152 | 5.555 | 1.856 |
| 35 | 3.363 | 7.756 | 6.173 |
| 40 | 4.9078 | 8.604 | 6.173 |
| 45 | 8.575 | 9.181 | 14.751 |
| 50 | 9.788 | 21.974 | 14.751 |
| 55 | 13.230 | 30.017 | 14.751 |
| 60 | 17.681 | 31.749 | 16.166 |
| 65 | 29.356 | 68.709 | 16.166 |
| 70 | 34.019 | 92.974 | 302.459 |
| 75 | 49.444 | 117.869 | 302.459 |
| 80 | 75.737 | 133.653 | 488.602 |
| 85 | 150.089 | 167.828 | 488.602 |
| 90 | 180.505 | 271.884 | 488.602 |
| 95 | 242.247 | 464.047 | 488.602 |
| 100 | 273.808 | 464.047 | 488.602 |
+---------+------------------+------------------+-------------------+
Table 2: Loss of Connectivity Time, Data Rate - 10 Seconds / Packet.
表2：连接丢失时间，数据速率-10秒/包。
The data for Figure 14 can be found in Table 3. The table shows how the CDF of time without connectivity to the LBR increases while we increase the time period to emit new DAG sequence numbers, when the nodes generate a packet every 20 seconds.
图14的数据可以在表3中找到。该表显示了当节点每20秒生成一个数据包时，当我们增加发送新DAG序列号的时间周期时，没有连接到LBR的时间CDF是如何增加的。
+---------+------------------+------------------+-------------------+
| CDF | Repair Period | Repair Period | Repair Period |
| (%age) | 10 Minutes | 30 Minutes | 60 Minutes |
+---------+------------------+------------------+-------------------+
| 0 | 0.071 | 0.955 | 0.167 |
| 5 | 0.126 | 2.280 | 1.377 |
| 10 | 0.403 | 2.926 | 1.409 |
| 15 | 0.902 | 3.269 | 1.409 |
| 20 | 1.281 | 16.623 | 3.054 |
| 25 | 2.322 | 21.438 | 5.175 |
| 30 | 2.860 | 48.479 | 5.175 |
| 35 | 3.316 | 49.495 | 10.30 |
| 40 | 3.420 | 93.700 | 25.406 |
| 45 | 6.363 | 117.594 | 25.406 |
| 50 | 11.500 | 243.429 | 34.379 |
| 55 | 19.703 | 277.039 | 102.141 |
| 60 | 22.216 | 284.660 | 102.141 |
| 65 | 39.211 | 285.101 | 328.293 |
| 70 | 63.197 | 376.549 | 556.296 |
| 75 | 88.986 | 443.450 | 556.296 |
| 80 | 147.509 | 452.883 | 1701.52 |
| 85 | 154.26 | 653.420 | 2076.41 |
| 90 | 244.241 | 720.032 | 2076.41 |
| 95 | 518.835 | 1760.47 | 2076.41 |
| 100 | 555.57 | 1760.47 | 2076.41 |
+---------+------------------+------------------+-------------------+
+---------+------------------+------------------+-------------------+
| CDF | Repair Period | Repair Period | Repair Period |
| (%age) | 10 Minutes | 30 Minutes | 60 Minutes |
+---------+------------------+------------------+-------------------+
| 0 | 0.071 | 0.955 | 0.167 |
| 5 | 0.126 | 2.280 | 1.377 |
| 10 | 0.403 | 2.926 | 1.409 |
| 15 | 0.902 | 3.269 | 1.409 |
| 20 | 1.281 | 16.623 | 3.054 |
| 25 | 2.322 | 21.438 | 5.175 |
| 30 | 2.860 | 48.479 | 5.175 |
| 35 | 3.316 | 49.495 | 10.30 |
| 40 | 3.420 | 93.700 | 25.406 |
| 45 | 6.363 | 117.594 | 25.406 |
| 50 | 11.500 | 243.429 | 34.379 |
| 55 | 19.703 | 277.039 | 102.141 |
| 60 | 22.216 | 284.660 | 102.141 |
| 65 | 39.211 | 285.101 | 328.293 |
| 70 | 63.197 | 376.549 | 556.296 |
| 75 | 88.986 | 443.450 | 556.296 |
| 80 | 147.509 | 452.883 | 1701.52 |
| 85 | 154.26 | 653.420 | 2076.41 |
| 90 | 244.241 | 720.032 | 2076.41 |
| 95 | 518.835 | 1760.47 | 2076.41 |
| 100 | 555.57 | 1760.47 | 2076.41 |
+---------+------------------+------------------+-------------------+
Table 3: Loss of Connectivity Time, Data Rate - 20 Seconds / Packet.
表3：连接丢失时间，数据速率-20秒/包。
Figure 16 shows the effect of the DAG global repair timer period on control traffic. As expected, as the frequency at which new DAG sequence numbers are generated increases, the amount of control traffic decreases because DIO messages are sent less frequently to rebuild the DODAG. However, reducing the control traffic comes at a price of increased loss of connectivity when only global repair is used.
图16显示了DAG全局修复计时器周期对控制流量的影响。正如预期的那样，随着新DAG序列号生成频率的增加，控制通信量减少，因为DIO消息在重建DODAG时发送的频率降低。然而，当仅使用全局修复时，减少控制流量的代价是连接损失增加。
Figure 16 [See the PDF.]
图16[参见PDF。]
Figure 16: Amount of Control Traffic for Different Global Repair Periods.
图16：不同全局修复周期的控制通信量。
From the above results, it is clear that the time the protocol takes to re-establish routes and to converge, after an unexpected link or device failure happens, is fairly long. [RFC5826] mandates that "the routing protocol MUST converge within 0.5 seconds if no nodes have moved". Clearly, implementation of a repair mechanism based on new DAG sequence numbers alone would not meet the requirements. Hence, a local repair mechanism, in the form of poisoning the sub-DAG and issuing a DIS, has been adopted.
从以上结果可以清楚地看出，在发生意外链路或设备故障后，协议重新建立路由和收敛所需的时间相当长。[RFC5826]要求“如果没有节点移动，路由协议必须在0.5秒内收敛”。显然，仅基于新的DAG序列号实施修复机制无法满足要求。因此，采用了一种局部修复机制，即对副DAG下毒并发出DIS。
The effect of the DAG repair timer on time without service when local repair is activated is now observed and plotted in Figure 17, where the source rate is 20 seconds/packet. A comparison of the CDF of loss of connectivity for the global repair mechanism and the global + local repair mechanism is shown in Figures 18 and 19 (semi-log plots, x axis in logarithmic scale and y axis in linear scale), where the source generates a packet every 10 seconds and 20 seconds, respectively. For these plots, the x axis shows time in log scale, and the y axis denotes the corresponding CDF in linear scale. One can observe that using local repair (with poisoning of the sub-DAG) greatly reduces loss of connectivity.
图17显示了激活本地修复时，DAG修复定时器对无服务时间的影响，其中源速率为20秒/包。图18和图19显示了全局修复机制和全局+局部修复机制的连接丢失CDF的比较（半对数图，对数比例的x轴和线性比例的y轴），其中源分别每10秒和20秒生成一个数据包。对于这些图，x轴以对数刻度表示时间，y轴以线性刻度表示相应的CDF。可以观察到，使用局部修复（子DAG中毒）可以大大减少连接损失。
Figure 17 [See the PDF.]
图17[见PDF。]
Figure 17: CDF: Loss of Connectivity for Different DAG Repair Timer Values for Global+Local Repair, Source Rate 20 Seconds/Packet.
图17:CDF：全局+本地修复的不同DAG修复计时器值的连接丢失，源速率20秒/包。
Figure 18 [See the PDF.]
图18[见PDF。]
Figure 18: CDF: Loss of Connectivity for Global Repair and Global+Local Repair, Source Rate 10 Seconds/Packet.
图18:CDF：全局修复和全局+本地修复的连接丢失，源速率10秒/包。
Figure 19 [See the PDF.]
图19[参见PDF。]
Figure 19: CDF: Loss of Connectivity for Global Repair and Global+Local Repair, Source Rate 20 Seconds/Packet.
图19:CDF：全局修复和全局+本地修复的连接丢失，源速率20秒/包。
A comparison between the amount of control plane overhead used for global repair only and for the global plus local repair mechanism is shown in Figure 20, which highlights the improved performance of RPL in terms of convergence time at very little extra overhead. From Figure 19, in 85% of the cases the protocol finds connectivity to the LBR for the concerned nodes within a fraction of seconds when local repair is employed. Using only global repair leads to repair periods of 150-154 seconds, as observed in Figures 13 and 14.
图20显示了仅用于全局修复和全局加局部修复机制的控制平面开销量之间的比较，它突出显示了RPL在很少额外开销的情况下在收敛时间方面的改进性能。从图19可以看出，在85%的情况下，当采用本地修复时，协议会在几秒钟内找到相关节点到LBR的连接。如图13和14所示，仅使用全局修复将导致150-154秒的修复周期。
Figure 20 [See the PDF.]
图20[参见PDF。]
Figure 20: Number of Control Packets for Different DAG Sequence Number Period, for Both Global Repair and Global+Local Repair.
图20：用于全局修复和全局+局部修复的不同DAG序列号周期的控制数据包数量。
Unlike the previous traffic pattern, where a majority of the total traffic generated by any node is destined to the root, this section considers a different traffic pattern, which is more prominent in a home or building routing scenario. In the simulations shown below, the nodes send 60% of their total generated traffic to the physically 1-hop distant node and 20% of traffic to a 2-hop distant node; the other 20% of traffic is distributed among other nodes in the network. The CDF of path quality metrics such as hop count, ETX path cost, average hop distance stretch, ETX path stretch, and delay for P2P routing for all pairs of nodes is calculated. Maintaining a low delay bound for P2P traffic is of high importance, as applications in home and building routing typically have low delay tolerance.
与之前的流量模式不同，任何节点生成的大部分总流量都是以根节点为目的地的，本节将考虑不同的流量模式，这在家庭或建筑路由场景中更为突出。在下面所示的模拟中，节点将其生成的总流量的60%发送到物理上1跳的远程节点，将20%的流量发送到2跳的远程节点；另外20%的流量分布在网络中的其他节点之间。计算了所有节点对的路径质量指标的CDF，如跳数、ETX路径成本、平均跳距延伸、ETX路径延伸和P2P路由延迟。保持P2P流量的低延迟边界非常重要，因为家庭和建筑路由中的应用程序通常具有低延迟容忍度。
Figure 21 shows the CDF of the hop count for both RPL and ideal shortest path routing for the traffic pattern described above. Figure 22 shows the CDF of the expected number of transmissions (ETX) for each packet to reach its destination. Figures 23 and 24 show the CDF of the stretch factor for these two metrics. To illustrate the stretch factor, an example from Figure 24 will be given next. For all paths built by RPL, 85% of the time, the path cost is less than the path cost for the ideal shortest path plus one.
图21显示了上述流量模式的RPL和理想最短路径路由的跳数CDF。图22显示了每个数据包到达其目的地的预期传输次数（ETX）的CDF。图23和24显示了这两个度量的拉伸因子的CDF。为了说明拉伸系数，下面将给出图24中的一个示例。对于由RPL构建的所有路径，85%的时间，路径成本小于理想最短路径加1的路径成本。
Figure 21 [See the PDF.]
图21[见PDF。]
Figure 21: CDF of End-to-End Hop Count for RPL and Ideal Shortest Path in Home Routing.
图21:RPL的端到端跳数CDF和主路由中的理想最短路径。
Figure 22 [See the PDF.]
图22[见PDF。]
Figure 22: CDF of ETX Path Cost Metric for RPL and Ideal Shortest Path in Home Routing.
图22:RPL和主路由中理想最短路径的ETX路径成本度量的CDF。
Figure 23 [See the PDF.]
图23[参见PDF。]
Figure 23: CDF of Hop Distance Stretch from Ideal Shortest Path.
图23：理想最短路径的跳距延伸CDF。
Figure 24 [See the PDF.]
图24[参见PDF。]
Figure 24: CDF of ETX Metric Stretch from Ideal Shortest Path.
图24:ETX公制从理想最短路径延伸的CDF。
To get an idea of maximum observable delay in the above-mentioned traffic pattern, the delay for different numbers of hops to the destination for RPL is considered. Figure 25 shows how the end-to-end packet latency is distributed for different packets with different hop counts in the network.
为了得到上述业务模式中最大可观测延迟的概念，考虑了RPL到达目的地的不同跳数的延迟。图25显示了如何为网络中具有不同跳数的不同数据包分配端到端数据包延迟。
Figure 25 [See the PDF.]
图25[参见PDF。]
Figure 25: Packet Latency for Different Hop Counts in RPL.
图25：RPL中不同跳数的数据包延迟。
For this deployment scenario, 60% of the traffic has been restricted to a 1-hop neighborhood. Hence, intuitively, the protocol is expected to yield path qualities that are close to those of ideal shortest path routing for most of the paths. From the CDF of the hop count and ETX path cost, it is clear that peer-to-peer paths are more often closer to an ideal shortest path. The end-to-end delay for distances within 2 hops is less than 60 ms for 99% of the delivered packets, while packets traversing 5 hops or more are delivered within 100 ms 99% of the time. These results demonstrate that for a normal routing scenario of an LLN deployment in a building, RPL performs fairly well without incurring much control plane overhead, and it can be applied for delay-critical applications as well.
对于此部署场景，60%的流量被限制在一个单跳邻居。因此，直观地说，该协议有望产生接近大多数路径的理想最短路径路由的路径质量。从跳数和ETX路径成本的CDF可以看出，对等路径通常更接近理想的最短路径。对于99%的已交付数据包，2跳以内距离的端到端延迟小于60 ms，而穿过5跳或以上的数据包在100 ms 99%的时间内交付。这些结果表明，对于建筑物中LLN部署的正常路由场景，RPL性能相当好，不会产生太多控制平面开销，并且它也可以应用于延迟关键应用。
In this section, we focus on simulating RPL in a large network and study its scalability by focusing on a few performance metrics: the latency and path cost stretch, and the amount of control packets. The 2442-node smart meter network with its corresponding link traces was used in this scalability study. To simulate a more realistic scenario for a smart meter network, 100% of the packets generated by each node are destined to the root. Therefore, no traffic is destined to nodes other than the root.
在本节中，我们将重点讨论在大型网络中模拟RPL，并通过关注几个性能指标来研究其可伸缩性：延迟和路径成本拉伸，以及控制数据包的数量。本次可扩展性研究使用了2442节点智能电表网络及其相应的链路跟踪。为了模拟智能电表网络的更现实场景，每个节点生成的100%数据包都将发送到根节点。因此，除了根节点之外，没有任何通信流发送到其他节点。
To investigate RPL's scalability, the CDF of the ETX path cost in the large-scale smart meter network is compared to a hypothetical ideal shortest path routing protocol that minimizes the total ETX path cost (Figure 26). In this simulation, the path stretch is also calculated for each packet that traverses the network. The path stretch is determined as the difference between the path cost taken by a packet
为了研究RPL的可扩展性，将大规模智能电表网络中ETX路径成本的CDF与假设的理想最短路径路由协议进行比较，该协议使ETX路径总成本最小化（图26）。在该模拟中，还为穿过网络的每个数据包计算路径拉伸。路径拉伸被确定为数据包采用的路径成本之间的差异
while following a route built via RPL and a path computed using an ideal shortest path routing protocol. The CDF of the ETX fractional stretch, which is determined as the ETX metric stretch value over the ETX path cost of an ideal shortest path, is plotted in Figure 27.
同时遵循通过RPL构建的路由和使用理想最短路径路由协议计算的路径。ETX部分拉伸的CDF（确定为理想最短路径ETX路径成本上的ETX公制拉伸值）如图27所示。
The fractional hop distance stretch value, as defined in the Terminology section, is shown in Figure 28.
术语部分中定义的分数跳跃距离拉伸值如图28所示。
Looking at the path quality plots, it is obvious that RPL works in a non-optimal fashion in this deployment scenario as well. However, on average, for each source-destination pair, the ETX fractional stretch is limited to 30% of the ideal shortest path cost. This fraction is higher for paths with shorter distances and lower for paths where the source and destination are far apart. The negative stretch factor for the hop count is an interesting feature of this deployment and is due to RPL's decision to not switch to another parent where the improvement in path quality is not significant. As mentioned previously, in this implementation, a node will only switch to a new parent if the advertised ETX path cost to the LBR through the new candidate parent is 20% better than the old one. The nodes tend to hear DIOs from a smaller hop count first, and later do not always shift to a larger hop count and smaller ETX path cost. As the traffic is mostly to the DAG root, some P2P paths built via RPL do yield a smaller hop count from source to destination, albeit at a larger ETX path cost.
查看路径质量图，显然RPL在该部署场景中也以非最佳方式工作。然而，平均而言，对于每个源-目的地对，ETX分数拉伸限制为理想最短路径成本的30%。对于距离较短的路径，该分数较高；对于源和目标相距较远的路径，该分数较低。跳数的负拉伸因子是此部署的一个有趣特性，这是由于RPL决定不切换到路径质量改善不显著的另一个父级。如前所述，在该实现中，如果通过新候选父节点到LBR的播发ETX路径成本比旧候选父节点高20%，则节点将仅切换到新父节点。节点倾向于先从较小的跳数听到DIO，然后不总是转移到较大的跳数和较小的ETX路径成本。由于流量主要流向DAG根，一些通过RPL构建的P2P路径确实会产生较小的从源到目标的跳数，尽管ETX路径成本较高。
As observed in Figure 26, 90% of the packets transmitted during the simulation have a (shortest) ETX path cost to destination less than or equal to 12. However, via RPL, 90% of the packets will follow paths that have a total ETX path cost of up to 14. Though all packets are destined to the LBR, it is to be noted that this implementation ignores a change of up to 20% in total ETX path cost. Figures 27 and 28 indicate that all paths have a very low ETX fractional stretch factor as far as the total ETX path cost is concerned, and some of the paths have lower hop counts to the LBR or DAG root as well when compared to the hop count of the ideal shortest path.
如图26所示，模拟期间传输的90%的数据包到目的地的（最短）ETX路径成本小于或等于12。然而，通过RPL，90%的数据包将遵循ETX路径总成本高达14的路径。尽管所有数据包都是以LBR为目的地的，但需要注意的是，该实现忽略了ETX路径总成本中高达20%的变化。图27和28表明，就总ETX路径成本而言，所有路径的ETX分数拉伸因子都非常低，并且与理想最短路径的跳数相比，一些路径到LBR或DAG根的跳数也较低。
Figure 26 [See the PDF.]
图26[参见PDF。]
Figure 26: CDF of Total ETX Path Cost versus ETX Path Cost.
图26:ETX路径总成本与ETX路径成本的CDF。
Figure 27 [See the PDF.]
图27[见PDF。]
Figure 27: CDF of ETX Fractional Stretch versus ETX Fractional Stretch Value.
图27:ETX分数拉伸与ETX分数拉伸值的CDF。
Figure 28 [See the PDF.]
图28[见PDF。]
Figure 28: CDF of Fractional Hop Count Stretch.
图28：分数跳数拉伸的CDF。
Figure 29 shows how end-to-end packet latency is distributed for different hop counts in the network. According to [RFC5548], Urban LLNs (U-LLNs) are delay tolerant, and the information, except for critical alarms, should arrive within a fraction of the reporting interval (within a few seconds). The packet generation for this deployment has been set higher than usual to incur high traffic volume, and nodes generate data once every 30 seconds. However, the end-to-end latency for most of the packets is condensed between 500 ms and 1 s, where the upper limit corresponds to packets traversing longer (greater than or equal to 6 hops) paths.
图29显示了如何为网络中的不同跳数分配端到端数据包延迟。根据[RFC5548]，城市LLN（U-LLN）具有延迟容忍能力，除严重警报外，信息应在报告间隔的一小部分（几秒钟内）内到达。此部署的数据包生成已设置为高于正常值，以产生高流量，节点每30秒生成一次数据。然而，大多数分组的端到端延迟在500 ms和1s之间压缩，其中上限对应于穿越更长（大于或等于6跳）路径的分组。
Figure 29 [See the PDF.]
图29[见PDF。]
Figure 29: End-to-End Packet Delivery Latency for Different Hop Counts.
图29：不同跳数的端到端数据包传递延迟。
Figure 30 shows the comparison between data packets (originated and forwarded) and control packets (DIO and DAO messages) transmitted by each node (link ETX is used as the routing metric). Here one can observe that in spite of the large scale of the network, the amount of control traffic in the protocol is negligible in comparison to data packet transmission. The smaller node ID for this network actually indicates closer proximity to the DAG root, and nodes with high ID numbers are actually farther away from the DAG root. Also, as expected, we can observe in Figures 31, 32, and 33 that the (non-leaf) nodes closer to the DAG root have many more data packet transmissions than other nodes. The leaf nodes have comparable amounts of data and control packet transmissions, as they do not take part in routing the data. As seen before, the data traffic for a child node has much less variation than the nodes that are closer to the DAG root. This variation decreases with increase in DAG depth. In this topology, Nodes 1, 2, and 3, etc., are direct children of the LBR.
图30显示了每个节点发送的数据包（原始和转发）和控制包（DIO和DAO消息）之间的比较（链路ETX用作路由度量）。这里可以观察到，尽管网络规模很大，但与数据分组传输相比，协议中的控制通信量可以忽略不计。该网络的较小节点ID实际上表示距离DAG根较近，ID号较高的节点实际上距离DAG根较远。此外，正如预期的那样，我们可以在图31、32和33中观察到靠近DAG根的（非叶）节点比其他节点具有更多的数据包传输。叶节点具有相当数量的数据并控制分组传输，因为它们不参与数据路由。如前所述，子节点的数据通信量比靠近DAG根的节点变化小得多。这种变化随着DAG深度的增加而减小。在此拓扑中，节点1、2和3等是LBR的直接子节点。
Figure 30 [See the PDF.]
图30[参见PDF。]
Figure 30: Data and Control Packet Comparison.
图30：数据包和控制包比较。
Figure 31 [See the PDF.]
图31[见PDF。]
Figure 31: Data and Control Packets over Time for Node 1.
图31：节点1随时间变化的数据和控制数据包。
Figure 32 [See the PDF.]
图32[参见PDF。]
Figure 32: Data and Control Packets over Time for Node 78.
图32：节点78随时间变化的数据和控制数据包。
Figure 33 [See the PDF.]
图33[见PDF。]
Figure 33: Data and Control Packets over Time for Node 300.
图33：节点300随时间变化的数据和控制数据包。
In Figure 34, the effect of the global repair period timer on control packet overhead is shown.
在图34中，显示了全局修复周期计时器对控制数据包开销的影响。
Figure 34 [See the PDF.]
图34[见PDF。]
Figure 34: Numbers of Control Packets for Different Global Repair Timer Periods.
图34：不同全局修复计时器周期的控制数据包数。
An important metric of interest is the maximum load experienced by any node (CPU usage) in terms of the number of control packets transmitted by the node. Also, to get an idea of scaling properties of RPL in large-scale networks, it is also key to analyze the number of packets handled by the RPL nodes for networks of different sizes.
感兴趣的一个重要度量是，根据节点传输的控制数据包的数量，任何节点所经历的最大负载（CPU使用）。此外，为了了解大规模网络中RPL的伸缩特性，分析不同规模网络中RPL节点处理的数据包数量也是关键。
In these simulations, at any given interval, the node with maximum control overhead load is identified. The amount of maximum control overhead processed by that node is plotted against time for three different networks under study. The first one is Network 'A', which has 45 nodes and is shown in Figure 1 (Section 3); the second is Network 'B', which is another deployed outdoor network with 86 nodes; and the third is Network 'C', which is the large deployed smart meter network with 2442 nodes as noted previously in this document.
在这些仿真中，在任何给定的时间间隔内，识别具有最大控制开销负载的节点。对于研究中的三个不同网络，该节点处理的最大控制开销量与时间成正比。第一个是网络“A”，它有45个节点，如图1（第3节）所示；第二个是网络“B”，这是另一个部署了86个节点的室外网络；第三个是网络“C”，这是一个大型部署的智能电表网络，具有2442个节点，如本文件前面所述。
In Figure 35, the comparison of maximum control loads is shown for different network sizes. For the network with 45 nodes, the maximum number of control packets in the network stays within a limit of 50 packets (per 1-minute interval), where for the networks with 86 and 2442 nodes, this limit stretches to 100 and 2 * 10^3 packets per 1-minute interval, respectively.
图35显示了不同网络规模的最大控制负载比较。对于具有45个节点的网络，网络中控制数据包的最大数量保持在50个数据包（每1分钟间隔）的限制范围内，其中对于具有86个和2442个节点的网络，该限制分别延伸到每1分钟间隔100和2*10^3个数据包。
Figure 35 [See the PDF.]
图35[见PDF。]
Figure 35: Scaling Property of Maximum Control Packets Processed by Any Node over Time.
图35：任意节点随时间处理的最大控制数据包的缩放特性。
For a network built with low-power devices interconnected by lossy links, it is of the utmost importance to ensure that routing packets are not flooded in the entire network and that the routing topology stays as stable as possible. Any change in routing information, especially parent-child relationships, would reset the timer, leading to emitting new DIOs, and would hence change the node's path metric to reach the root. This change will trigger a series of control plane messages (RPL packets) in the DODAG. Therefore, it is important to carefully control the triggering of DIO control packets via the use of thresholds.
对于由低功耗设备通过有损链路互连而成的网络，确保路由数据包不会淹没整个网络，并且路由拓扑尽可能保持稳定至关重要。路由信息（尤其是父子关系）的任何更改都将重置计时器，导致发出新的DIO，并因此更改节点的路径度量以到达根节点。此更改将触发DODAG中的一系列控制平面消息（RPL数据包）。因此，通过使用阈值仔细控制DIO控制数据包的触发非常重要。
In this study, the effect of the tolerance value that is considered before emitting a DIO reflecting a new path cost is analyzed. Four cases are considered:
在本研究中，分析了在发射反映新路径成本的DIO之前考虑的公差值的影响。考虑了四种情况：
o No change in DAG depth of a node is ignored;
o 不忽略节点DAG深度的任何更改；
o The implementation ignores a 10% change in the ETX path cost to the DAG root. That is, if the change in total path cost to the root/LBR -- due to DIO reception from the most preferred parent or due to shifting to another parent -- is less than 10%, the node will not advertise the new metric to the root;
o 该实现忽略了DAG根的ETX路径成本的10%变化。也就是说，如果根/LBR的总路径成本的变化——由于从最优选的父节点接收到DIO或由于转移到另一个父节点——小于10%，则节点将不向根节点通告新度量；
o The implementation ignores a 20% change in ETX path cost to the DAG root for any node before deciding to advertise a new depth;
o 在决定公布新深度之前，实现忽略任何节点的DAG根的ETX路径成本的20%变化；
o The implementation ignores a 30% change in the total ETX path cost to the DAG root of a node before deciding to advertise a new depth.
o 在决定公布新深度之前，该实现将忽略节点DAG根的总ETX路径成本的30%变化。
This decision does affect the optimum path quality to the DAG root. As observed in Figure 36, for 0% tolerance, 95% of paths used have an ETX fractional stretch factor of less than 10%. Similarly, for 10% and 20% tolerance levels, 95% of paths will have a 15% and 20% ETX fractional path stretch. However, the increased routing stability and decreased control overhead are the profit gained from the 10% extra increase in path length or ETX path cost, whichever is used as the metric to optimize the DAG.
此决定不会影响DAG根的最佳路径质量。如图36所示，对于0%公差，使用的95%路径的ETX分数拉伸系数小于10%。同样，对于10%和20%的公差水平，95%的路径将具有15%和20%的ETX分数路径拉伸。然而，增加的路由稳定性和减少的控制开销是从路径长度或ETX路径成本额外增加10%中获得的利润，以用作优化DAG的指标为准。
Figure 36 [See the PDF.]
图36[见PDF。]
Figure 36: ETX Fractional Stretch Factor for Different Tolerance Levels.
图36：不同公差水平的ETX分数拉伸系数。
As the above-mentioned threshold also affects the path taken by a packet, this study also demonstrates the effect of the threshold on routing stability (number of times P2P paths change between a source and a destination). For Network 'A' (shown in Figure 1) and the
由于上述阈值也会影响数据包所采用的路径，因此本研究还证明了阈值对路由稳定性的影响（源和目标之间P2P路径的变化次数）。对于网络“A”（如图1所示）和
large smart meter network 'C', the CDF of path change is plotted in Figures 37 and 38, respectively, against the fraction of path change for different thresholds (triggering the emission of a new DIO upon path cost change).
大型智能电表网络“C”，路径变化的CDF分别绘制在图37和图38中，与不同阈值的路径变化分数对比（在路径成本变化时触发新DIO的排放）。
If X packets are transferred from source A to destination B, and out of X times, Y times the path between this source-destination pair is changed, then we compute the fraction of path change as Y/X * 100%. This metric is computed over all source-destination pairs, and the CDF is plotted in the y axis.
如果X个数据包从源A传输到目的B，并且在X次中，Y次该源-目的地对之间的路径发生变化，那么我们计算路径变化的分数为Y/X*100%。在所有源-目标对上计算此度量，并在y轴上绘制CDF。
Figure 37 [See the PDF.]
图37[见PDF。]
Figure 37: Distribution of Fraction of Path Change for Network A.
图37：网络A的路径变化分数分布。
Figure 38 [See the PDF.]
图38[见PDF。]
Figure 38: Distribution of Fraction of Path Change for Large Network C.
图38：大型网络C的路径变化分数分布。
This document also compares the CDF of the fraction of path change for three different networks -- A, B, and C. Figure 39 shows how the three networks exhibit a change of P2P path when a 30% change in metric cost to the root is ignored before shifting to a new parent.
本文档还比较了三个不同网络（A、B和C）的路径变化分数CDF。图39显示了在转移到新的父网络之前，当忽略根节点30%的度量成本变化时，这三个网络如何表现出P2P路径的变化。
Figure 39 [See the PDF.]
图39[见PDF。]
Figure 39: Comparison of Distribution of Fraction of Path Change.
图39：路径变化分数分布的比较。
All the simulation results presented in this document corroborate the expected protocol behavior for the topologies and traffic model used in the study. For the particular discussed scenarios, the protocol is shown to meet the desired delay and convergency requirements and to exhibit self-healing properties without external intervention, incurring negligible control overhead (only a small fraction of data traffic). RPL provided near-optimum path quality for most of the packets in the scenarios considered here and is able to trade off control overhead for path quality via configurable parameters (such as decisions on when to switch to a new parent), as per the application and device requirements; thus, RPL can trade off routing stability for control overhead as well. Finally, as per the requirement of urban LLN deployments, the protocol is shown to scale to larger topologies (several thousand nodes), for the topologies considered in this implementation.
本文中给出的所有仿真结果证实了研究中使用的拓扑和流量模型的预期协议行为。对于所讨论的特定场景，该协议满足所需的延迟和收敛性要求，并且在没有外部干预的情况下表现出自愈特性，产生的控制开销可以忽略不计（仅占数据流量的一小部分）。在这里考虑的场景中，RPL为大多数数据包提供了接近最佳的路径质量，并且能够根据应用程序和设备要求，通过可配置参数（例如关于何时切换到新的父级的决定）来权衡路径质量的控制开销；因此，RPL也可以在路由稳定性和控制开销之间进行权衡。最后，根据城市LLN部署的要求，对于本实现中考虑的拓扑，该协议可以扩展到更大的拓扑（数千个节点）。
This document describes investigations performed in the Castalia wireless sensor network simulator; it does not consider packets on the Internet. [RFC6550] describes security considerations for RPL networks.
本文件描述了在Castalia无线传感器网络模拟器中进行的调查；它不考虑因特网上的数据包。[RFC6550]描述了RPL网络的安全注意事项。
The authors would like to acknowledge Jerald P. Martocci, Mukul Goyal, Emmanuel Monnerie, Philip Levis, Omprakash Gnawali, and Craig Partridge for their valuable and helpful suggestions over metrics to include and overall feedback.
作者要感谢Jerald P.Martocci、Mukul Goyal、Emmanuel Monnerie、Philip Levis、Omprakash Gnawali和Craig Partridge就指标和总体反馈提出的宝贵和有益建议。
[Castalia-2.2] Boulis, A., "Castalia: Revealing pitfalls in designing distributed algorithms in WSN", Proceedings of the 5th international conference on Embedded networked sensor systems (SenSys'07), pp. 407-408, 2007.
[Castalia-2.2]Boulis，A.，“Castalia:揭示无线传感器网络分布式算法设计中的陷阱”，第五届嵌入式网络传感器系统国际会议论文集（SenSys'07），第407-408页，2007年。
[NS-2] "The Network Simulator version 2 (ns-2)", <http://www.isi.edu/nsnam/ns/>.
[NS-2]“网络模拟器版本2（NS-2）”<http://www.isi.edu/nsnam/ns/>.
[OMNeTpp] Varga, A., "The OMNeT++ Discrete Event Simulation System", Proceedings of the European Simulation Multiconference (ESM'2001), June 2001.
[OMNeTpp]Varga，A.，“OMNeT++离散事件仿真系统”，欧洲仿真多冲突会议录（ESM'2001），2001年6月。
[RFC5548] Dohler, M., Ed., Watteyne, T., Ed., Winter, T., Ed., and D. Barthel, Ed., "Routing Requirements for Urban Low-Power and Lossy Networks", RFC 5548, May 2009.
[RFC5548]Dohler，M.，Ed.，Watteyne，T.，Ed.，Winter，T.，Ed.，和D.Barthel，Ed.，“城市低功率和有损网络的路由要求”，RFC 5548，2009年5月。
[RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T. Phinney, "Industrial Routing Requirements in Low-Power and Lossy Networks", RFC 5673, October 2009.
[RFC5673]Pister，K.，Ed.，Thubert，P.，Ed.，Dwars，S.，和T.Phinney，“低功率和有损网络中的工业路由要求”，RFC 5673，2009年10月。
[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., Ed., 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.，Ed.，De Mil，P.，Riou，N.，和W.Vermeylen，“低功率和有损网络中的楼宇自动化路由要求”，RFC 58672010年6月。
[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., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, March 2012.
[RFC6550]温特，T.，Ed.，Thubert，P.，Ed.，Brandt，A.，Hui，J.，Kelsey，R.，Levis，P.，Pister，K.，Struik，R.，Vasseur，JP.，和R.Alexander，“RPL:低功耗和有损网络的IPv6路由协议”，RFC 65502012年3月。
[RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., and D. Barthel, "Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks", RFC 6551, March 2012.
[RFC6551]Vasseur，JP.，Ed.，Kim，M.，Ed.，Pister，K.，Dejean，N.，和D.Barthel，“低功率和有损网络中用于路径计算的路由度量”，RFC 65512012年3月。
[ROLL-TERMS] Vasseur, JP., "Terminology in Low power And Lossy Networks", Work in Progress, September 2011.
[ROLL-TERMS]Vasseur，JP.，“低功耗和有损网络中的术语”，正在进行的工作，2011年9月。
Authors' Addresses
作者地址
Joydeep Tripathi (editor) Drexel University 3141 Chestnut Street 7-313 Philadelphia, PA 19104 USA
乔伊迪普·特里帕蒂（编辑）美国宾夕法尼亚州费城德雷塞尔大学3141号板栗街7-313号，邮编：19104
EMail: jt369@drexel.edu
EMail: jt369@drexel.edu
Jaudelice C. de Oliveira (editor) Drexel University 3141 Chestnut Street 7-313 Philadelphia, PA 19104 USA
Jaudelice C.de Oliveira（编辑）美国宾夕法尼亚州费城Chestnut街3141号，邮编：19104
EMail: jau@coe.drexel.edu
EMail: jau@coe.drexel.edu
JP. Vasseur (editor) Cisco Systems, Inc. 11, Rue Camille Desmoulins Issy Les Moulineaux 92782 France
JP。Vasseur（编辑）思科系统有限公司，法国卡米尔·德斯穆林斯街11号Issy Les Moulineaux 92782
EMail: jpv@cisco.com
EMail: jpv@cisco.com