doc: Add RFC documents

1 files changed, 1459 insertions, 0 deletions

diff --git a/doc/rfc/rfc6687.txt b/doc/rfc/rfc6687.txt
new file mode 100644
index 0000000..9442f7a
--- /dev/null
+++ b/doc/rfc/rfc6687.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+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)
+
+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.
+
+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.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tripathi, et al.              Informational                     [Page 1]
+
+RFC 6687              Performance Evaluation of RPL         October 2012
+
+
+Copyright Notice
+
+   Copyright (c) 2012 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   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.
+
+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
+
+   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].
+
+   RPL is designed to meet the core requirements specified in [RFC5826],
+   [RFC5867], [RFC5673], and [RFC5548].
+
+
+
+Tripathi, et al.              Informational                     [Page 2]
+
+RFC 6687              Performance Evaluation of RPL         October 2012
+
+
+   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.
+
+   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  Control plane overhead;
+
+   o  End-to-end delay between nodes;
+
+   o  Ability to cope with unstable situations (link churns, node
+      dying);
+
+   o  Required resource constraints on nodes (routing table size).
+
+   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.
+
+   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.
+
+2.  Terminology
+
+   Please refer to [ROLL-TERMS] and [RFC6550] for terminology.  In
+   addition, the following terms are specified:
+
+   PDR:  Packet Delivery Ratio.
+
+   CDF:  Cumulative Distribution Function.
+
+
+
+Tripathi, et al.              Informational                     [Page 3]
+
+RFC 6687              Performance Evaluation of RPL         October 2012
+
+
+   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 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 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 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.
+
+   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.
+
+3.  Methodology and Simulation Setup
+
+   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].
+
+   Note that no versions of the NS itself are used in this simulation
+   study.  Only the visualization tool was borrowed for verification
+   purposes.
+
+
+
+
+
+Tripathi, et al.              Informational                     [Page 4]
+
+RFC 6687              Performance Evaluation of RPL         October 2012
+
+
+   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.
+
+   Figure 1 [See the PDF.]
+
+             Figure 1: Outdoor Network Topology with 45 Nodes.
+
+   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).
+
+
+
+
+Tripathi, et al.              Informational                     [Page 5]
+
+RFC 6687              Performance Evaluation of RPL         October 2012
+
+
+   Figure 2 [See the PDF.]
+
+                Figure 2: Example of Link Characteristics.
+
+   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].
+
+   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).
+
+   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.
+
+   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
+
+
+
+Tripathi, et al.              Informational                     [Page 6]
+
+RFC 6687              Performance Evaluation of RPL         October 2012
+
+
+   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.
+
+   The packets are routed through the DODAG built by RPL according to
+   the mechanisms specified in [RFC6550].
+
+   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.
+
+4.  Performance Metrics
+
+4.1.  Common Assumptions
+
+   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.
+
+   The link ETX (Expected Transmission Count) metric is used to build
+   the DODAG and is specified in [RFC6551].
+
+4.2.  Path Quality
+
+   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.
+
+   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
+
+
+
+Tripathi, et al.              Informational                     [Page 7]
+
+RFC 6687              Performance Evaluation of RPL         October 2012
+
+
+   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.
+
+   Figure 3 [See the PDF.]
+
+               Figure 3: CDF of Hop Count versus Hop Count.
+
+   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.
+
+   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.
+
+   Figure 4 [See the PDF.]
+
+   Figure 4: CDF of Total ETX Path Cost along Path versus ETX Path Cost.
+
+   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.
+
+   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.
+
+
+
+
+
+Tripathi, et al.              Informational                     [Page 8]
+
+RFC 6687              Performance Evaluation of RPL         October 2012
+
+
+   Figure 5 [See the PDF.]
+
+               Figure 5: CDF of Hop Distance Stretch versus
+                        Hop Distance Stretch Value.
+
+   Figure 6 [See the PDF.]
+
+     Figure 6: CDF of ETX Path Stretch versus ETX Path Stretch Value.
+
+   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.
+
+   +---------+--------+---------+-----------+------------+-------------+
+   |   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.
+
+   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
+
+
+
+Tripathi, et al.              Informational                     [Page 9]
+
+RFC 6687              Performance Evaluation of RPL         October 2012
+
+
+   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.
+
+4.3.  Routing Table Size
+
+   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.
+
+   Figure 7 [See the PDF.]
+
+   Figure 7: CDF of Routing Table Size with Respect to Number of Nodes.
+
+4.4.  Delay Bound for P2P Routing
+
+   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).
+
+   Figure 8 [See the PDF.]
+
+    Figure 8: Comparison of Packet Latency, for Different Path Lengths,
+                          Expressed in Hop Count.
+
+   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,
+
+
+
+Tripathi, et al.              Informational                    [Page 10]
+
+RFC 6687              Performance Evaluation of RPL         October 2012
+
+
+   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.
+
+4.5.  Control Packet Overhead
+
+   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.
+
+   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).
+
+   Figure 9 [See the PDF.]
+
+     Figure 9: Amount of Data and Control Packets Transmitted against
+                 Node Id Using Link ETX as Routing Metric.
+
+
+
+
+Tripathi, et al.              Informational                    [Page 11]
+
+RFC 6687              Performance Evaluation of RPL         October 2012
+
+
+   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.
+
+   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.
+
+
+
+
+
+
+Tripathi, et al.              Informational                    [Page 12]
+
+RFC 6687              Performance Evaluation of RPL         October 2012
+
+
+   Figure 10 [See the PDF.]
+
+         Figure 10: Amount of Data and Control Packets Transmitted
+                               for Node 12.
+
+   Figure 11 [See the PDF.]
+
+         Figure 11: Amount of Data and Control Packets Transmitted
+                               for Node 43.
+
+   Figure 12 [See the PDF.]
+
+         Figure 12: Amount of Data and Control Packets Transmitted
+                               for Node 31.
+
+4.6.  Loss of Connectivity
+
+   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.
+
+   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,
+
+
+
+
+
+
+Tripathi, et al.              Informational                    [Page 13]
+
+RFC 6687              Performance Evaluation of RPL         October 2012
+
+
+   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.
+
+   Figure 13 [See the PDF.]
+
+         Figure 13: CDF: Loss of Connectivity with Global Repair.
+
+   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.
+
+   Figure 14 [See the PDF.]
+
+            Figure 14: CDF: Loss of Connectivity for Different
+           Global Repair Period, Source Rate 20 Seconds/Packet.
+
+   Figure 15 [See the PDF.]
+
+            Figure 15: CDF: Loss of Connectivity for Different
+           Global Repair Period, Source Rate 10 Seconds/Packet.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tripathi, et al.              Informational                    [Page 14]
+
+RFC 6687              Performance Evaluation of RPL         October 2012
+
+
+   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.
+
+   +---------+------------------+------------------+-------------------+
+   |   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tripathi, et al.              Informational                    [Page 15]
+
+RFC 6687              Performance Evaluation of RPL         October 2012
+
+
+   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.
+
+   +---------+------------------+------------------+-------------------+
+   |   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.
+
+   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.
+
+   Figure 16 [See the PDF.]
+
+            Figure 16: Amount of Control Traffic for Different
+                          Global Repair Periods.
+
+
+
+
+
+Tripathi, et al.              Informational                    [Page 16]
+
+RFC 6687              Performance Evaluation of RPL         October 2012
+
+
+   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.
+
+   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.
+
+   Figure 17 [See the PDF.]
+
+    Figure 17: CDF: Loss of Connectivity for Different DAG Repair Timer
+      Values for Global+Local Repair, Source Rate 20 Seconds/Packet.
+
+   Figure 18 [See the PDF.]
+
+        Figure 18: CDF: Loss of Connectivity for Global Repair and
+            Global+Local Repair, Source Rate 10 Seconds/Packet.
+
+   Figure 19 [See the PDF.]
+
+        Figure 19: CDF: Loss of Connectivity for Global Repair and
+            Global+Local Repair, Source Rate 20 Seconds/Packet.
+
+   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.
+
+
+
+
+
+
+
+Tripathi, et al.              Informational                    [Page 17]
+
+RFC 6687              Performance Evaluation of RPL         October 2012
+
+
+   Figure 20 [See the PDF.]
+
+            Figure 20: Number of Control Packets for Different
+            DAG Sequence Number Period, for Both Global Repair
+                         and Global+Local Repair.
+
+5.  RPL in a Building Automation Routing Scenario
+
+   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.
+
+5.1.  Path Quality
+
+   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.
+
+   Figure 21 [See the PDF.]
+
+            Figure 21: CDF of End-to-End Hop Count for RPL and
+                   Ideal Shortest Path in Home Routing.
+
+   Figure 22 [See the PDF.]
+
+            Figure 22: CDF of ETX Path Cost Metric for RPL and
+                   Ideal Shortest Path in Home Routing.
+
+   Figure 23 [See the PDF.]
+
+     Figure 23: CDF of Hop Distance Stretch from Ideal Shortest Path.
+
+
+
+
+
+
+Tripathi, et al.              Informational                    [Page 18]
+
+RFC 6687              Performance Evaluation of RPL         October 2012
+
+
+   Figure 24 [See the PDF.]
+
+      Figure 24: CDF of ETX Metric Stretch from Ideal Shortest Path.
+
+5.2.  Delay
+
+   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.
+
+   Figure 25 [See the PDF.]
+
+        Figure 25: Packet Latency for Different Hop Counts in 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.
+
+6.  RPL in a Large-Scale Network
+
+   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.
+
+6.1.  Path Quality
+
+   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
+
+
+
+Tripathi, et al.              Informational                    [Page 19]
+
+RFC 6687              Performance Evaluation of RPL         October 2012
+
+
+   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.
+
+   The fractional hop distance stretch value, as defined in the
+   Terminology section, is shown in Figure 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.
+
+   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.
+
+   Figure 26 [See the PDF.]
+
+        Figure 26: CDF of Total ETX Path Cost versus ETX Path Cost.
+
+   Figure 27 [See the PDF.]
+
+              Figure 27: CDF of ETX Fractional Stretch versus
+                       ETX Fractional Stretch Value.
+
+
+
+
+
+Tripathi, et al.              Informational                    [Page 20]
+
+RFC 6687              Performance Evaluation of RPL         October 2012
+
+
+   Figure 28 [See the PDF.]
+
+              Figure 28: CDF of Fractional Hop Count Stretch.
+
+6.2.  Delay
+
+   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.
+
+   Figure 29 [See the PDF.]
+
+               Figure 29: End-to-End Packet Delivery Latency
+                         for Different Hop Counts.
+
+6.3.  Control Packet Overhead
+
+   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.
+
+   Figure 30 [See the PDF.]
+
+              Figure 30: Data and Control Packet Comparison.
+
+
+
+
+
+
+Tripathi, et al.              Informational                    [Page 21]
+
+RFC 6687              Performance Evaluation of RPL         October 2012
+
+
+   Figure 31 [See the PDF.]
+
+         Figure 31: Data and Control Packets over Time for Node 1.
+
+   Figure 32 [See the PDF.]
+
+        Figure 32: Data and Control Packets over Time for Node 78.
+
+   Figure 33 [See the PDF.]
+
+        Figure 33: Data and Control Packets over Time for Node 300.
+
+   In Figure 34, the effect of the global repair period timer on control
+   packet overhead is shown.
+
+   Figure 34 [See the PDF.]
+
+            Figure 34: Numbers of Control Packets for Different
+                       Global Repair Timer Periods.
+
+7.  Scaling Property and Routing Stability
+
+   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.
+
+   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.
+
+   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.
+
+   Figure 35 [See the PDF.]
+
+          Figure 35: Scaling Property of Maximum Control Packets
+                     Processed by Any Node over Time.
+
+
+
+Tripathi, et al.              Informational                    [Page 22]
+
+RFC 6687              Performance Evaluation of RPL         October 2012
+
+
+   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.
+
+   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:
+
+   o  No change in DAG depth of a node is ignored;
+
+   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  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  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.
+
+   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.
+
+   Figure 36 [See the PDF.]
+
+                 Figure 36: ETX Fractional Stretch Factor
+                      for Different Tolerance Levels.
+
+   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
+
+
+
+Tripathi, et al.              Informational                    [Page 23]
+
+RFC 6687              Performance Evaluation of RPL         October 2012
+
+
+   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).
+
+   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.
+
+   Figure 37 [See the PDF.]
+
+     Figure 37: Distribution of Fraction of Path Change for Network A.
+
+   Figure 38 [See the PDF.]
+
+            Figure 38: Distribution of Fraction of Path Change
+                           for Large Network 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.
+
+   Figure 39 [See the PDF.]
+
+     Figure 39: Comparison of Distribution of Fraction of Path Change.
+
+8.  Comments
+
+   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.
+
+
+
+
+
+Tripathi, et al.              Informational                    [Page 24]
+
+RFC 6687              Performance Evaluation of RPL         October 2012
+
+
+9.  Security Considerations
+
+   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.
+
+10.  Acknowledgements
+
+   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.
+
+11.  Informative References
+
+   [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.
+
+   [NS-2]     "The Network Simulator version 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.
+
+   [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.
+
+   [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.
+
+   [RFC5826]  Brandt, A., Buron, J., and G. Porcu, "Home Automation
+              Routing Requirements in Low-Power and Lossy Networks",
+              RFC 5826, April 2010.
+
+   [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.
+
+   [RFC6206]  Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
+              "The Trickle Algorithm", RFC 6206, March 2011.
+
+
+
+
+Tripathi, et al.              Informational                    [Page 25]
+
+RFC 6687              Performance Evaluation of RPL         October 2012
+
+
+   [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.
+
+   [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.
+
+   [ROLL-TERMS]
+              Vasseur, JP., "Terminology in Low power And Lossy
+              Networks", Work in Progress, September 2011.
+
+Authors' Addresses
+
+   Joydeep Tripathi (editor)
+   Drexel University
+   3141 Chestnut Street 7-313
+   Philadelphia, PA  19104
+   USA
+
+   EMail: jt369@drexel.edu
+
+
+   Jaudelice C. de Oliveira (editor)
+   Drexel University
+   3141 Chestnut Street 7-313
+   Philadelphia, PA  19104
+   USA
+
+   EMail: jau@coe.drexel.edu
+
+
+   JP. Vasseur (editor)
+   Cisco Systems, Inc.
+   11, Rue Camille Desmoulins
+   Issy Les Moulineaux  92782
+   France
+
+   EMail: jpv@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+Tripathi, et al.              Informational                    [Page 26]
+