Experimental observation of RPL: routing protocol overhead and asymmetric links
draft-audeoudh-rpl-asymmetric-links-00

Abstract

This document summarizes our observations of the behavior of RPL on a testbed composed of tens of IEEE 802.15.4 nodes. Our first observation is that the continuous task of estimating the link metric to all candidate neighbors causes a significant background load. This traffic is persistent, even in a stable network where DIO transmissions are eventually widely spaced. Next, this document focuses on the case of the presence of an asymmetric link, due to either a muted or a deaf node. In these circumstances, the standard RPL mechanisms may well generate hundreds of routing messages per node and per hour.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on September 12, 2019.

Copyright Notice

Copyright (c) 2019 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

1. Introduction

We present three cases in which the RPL protocol [RFC6550] incurs a large number of routing message transmissions even though they correspond to expected situations in LLNs. This memo summarizes our observations on RPL that are part of a broader set of experiments [EXPE].

1.1. Convergence and background traffic

The maintenance traffic in RPL converges to a low rate of DIO generation when the topology is stable. Nevertheless, the proactive approach of RPL imposes that the nodes permanently gauge potential new alternative neighbors. This mechanism is not standardized, but it is necessary. Users need to be aware of its existence and its footprint.

1.2. Asymmetric links

The quality of radio transmissions depends on the environment and on the radio hardware. In particular, interferences do not have the same impact on all nodes. Also, the transmission conditions are different between devices due to the variability of the amplifier gain and sensitivity.

So a link between two nodes may be asymmetric, and not present the same packet delivery ratios (PDR) in both directions. In extreme cases, a node N may be “deaf” (i.e. other nodes receive N’s packets, but N does not receive anything back) or “muted” (i.e. N receives properly, but is not heard).

1.3. Experimental setup

Table 1 presents the parameters used in the experiments. The trickle settings match the recommended practice, with Imin more than one order of magnitude greater than the broadcast duration (125 milliseconds in ContikiMAC). We found that this setting effectively avoids DIO collisions in our experiments.

2. Background traffic in a standard scenario

On the IoT-LAB testbed, we start 40 client nodes and a sink during 2 hours. Each client sends one UDP packet every 5 minutes to the sink which replies with another UDP packet. For this experiment, the nodes are distributed in the DODAG at a mean distance of 3.1 hops to the sink (median of 3). There are 9 nodes at a distance of 1 hop, and 5 nodes at a distance greater or equal to 6. Table 2 presents the results numerically.

• The bulk of multicast messages are DIOs sent by the nodes following the trickle algorithm. As the network is stable, the network-wide multicast DIO generation intensity reduces gradually until all nodes use a DIO interval of Imax (which gives an average period of approximately 750s in the considered case, approx. 1 message every 20s for our 41-node network).
• An intense and continuous traffic of unicast DIOs. RPL makes no provision for Unicast DIOs; it turns out that these messages are used by Contiki to assess the link quality to the neighbors [FNINES].

So this latter traffic is a re-use of DIO messages for a task which is out of the scope of RPL. The objective of this document is not to discuss the arguments for and against this specific mechanism in Contiki. Nevertheless, such a mechanism is necessary to RPL: “RPL expects an external mechanism to be triggered during the parent selection phase in order to verify link properties and neighbor reachability” [RFC6550]. Also RFC 6719 states that: “A node should compute the path cost for the path through each candidate neighbor reachable through an interface” [RFC6719].

At the application layer, it works well; but the price to pay is very significant, even counting the same overhead for broadcast and unicast messages. There are 4869 RPL message exchanges over the course of the experiment. In our special case of an application traffic which consists in one request response from each end node to the sink, we witness only 5516 one-hop data message transmissions, so that about half of all MAC-layer frames are linked to the routing processes.

3. In presence of deaf nodes

When a RPL node is not associated with any DODAG, it broadcasts a DIS message. This message resets the trickle timer that schedules the DIO message emissions in its neighborhood, thus generating many DIO broadcasts. Although this mechanism is useful to speed up the insertion of new nodes into the network, it is very harmful when a node N is deaf. Indeed, as N keeps broadcasting DIS packets, its neighbors constantly send back DIOs.

On the IoT-LAB testbed, we start 11 client nodes and a sink during 1 hour. Each client sends one UDP packet every 5 minutes to the sink which replies with another UDP packet. One of the client nodes is deaf: its sensitivity is lowered and it does not receive any message from other nodes, whereas its packets are received by its neighbors.

Table 3 presents the results numerically. DIO packets are constantly broadcast at the average rate of 1 every 3 seconds for the whole network, i.e. approximately 2 broadcast packets per node per minute. This intensity per node is one order of magnitude more than in the previous experiment.

This scenario is not necessarily only a routing protocol problem, but in part a question of neighbor management. One could expect that the MAC layer would eventually detect that a neighbor is unresponsive and blacklist it, for instance. However, here, the detection of the asymmetry could not directly be done by the MAC layer, as DIS and DIO packets are broadcast and thus, not acknowledged. There should be a safeguard mechanism in RPL to break out of the DIS/DIO cycle in these circumstances.

4. In presence of muted nodes

We finally consider the case of a node that loses the ability to reach some neighbors and, in particular, its preferred parent. On the IoT-LAB testbed, we start 11 client nodes and a sink during 1 hour. Each client sends one UDP packet every 5 minutes to the sink which replies with another UDP packet (there is no deaf node here). Obviously, if we completely mute one node from the start, it will not disturb its neighbors much as all its messages would be lost. So we start a node (node 40 of Figure 1) with a regular setting and let it associate itself with the network and communicate with other nodes. Then, after 15 minutes, we reduce its transmission power: it is muted and cannot reach its former neighbors anymore — except one of them, node 33, so that it is not totally isolated from the rest of the network. After about 10 minutes, the network is completely repaired and nodes are back to transmitting control messages at a normal rate.

              (45)                            (45)
             /  | \                             | \
            /   |  \                            |  \
        (40)  (12)  (18)                      (12)  (18)
          |     | \                             | \
          |     |  \                            |  \
        (33)  (48)  (10)                      (48)  (10)
             /  | \     \                    /  | \     \
            /   |  \     \                  /   |  \     \
        (57)  (55)  (30)  (51)          (57)  (55)  (30)  (51)
                  \                          /    \
                   \                        /      \
                  ( 2)                  (33)      ( 2)
                                          |
                                          |
                                        (40)

           Before node 40 is              After node 40 is
                muted                         muted

Figure 1: DODAG for the muted node experiment

Here, the scenario clearly shows the effect of a local repair of the DODAG. Indeed, the link between node 33 and node 40 should be reversed to reach the DODAG root again. We have a transient loop in the network until node 33 is able to use node 55 as a successor: node 40 uses node 33 as a successor, which in turn uses node 40 as a successor — but note that the traffic does not loop around, thanks to the data path validation mechanism based on the RPL header.

Table 4 presents the results numerically. This experiment shows that RPL handles this situation correctly: few data packets are lost and the DODAG repair is relatively quick. Nevertheless, a naive user could expect that only a few additional packets would be generated for such a limited topology change as for most routing protocols. But the repair traffic observed in this experiment is merely a consequence of the constant background routing overhead that the proactive approach and trickle imply.

5. Conclusion

First, we would like to emphasize the robustness of the Contiki implementation of RPL, which also matches the RFC specification to the extent of the points we checked. Our choice of Imin is constrained by the broadcast transmission duration; however, the choice of values Imax and DIORedundancyConstant could cause what one could consider excessive DIO traffic over the long run, but this is not the subject of our observations.

Secondly, the set of RPL-related documents leave aside the necessary mechanism of link metric estimation. This is not unexpected as it can be done without raising interoperability issues. Nevertheless, users need to be aware of this necessity e.g. in the case of power-constrained nodes. Also, as this task is closely related to the routing process, it is tempting and practical to use routing packets to the purpose of link metric estimation, as in Contiki. In this specific case, it is unknown if all implementations tolerate to receive unicast DIO, for instance. A possibility could be to reserve a packet format for metric estimation or explicitely allow a possible side-use of existing packets.

Pushing this line of thought a bit further, it could be of interest to integrate (or combine) the broadcast DIS/DIO exchange to the link metric estimation. This would allow the nodes to detect strongly asymmetric links at an early stage, and treat the messages from the corresponding neighbor knowingly.

6. IANA Considerations

This document includes no request to IANA.

7. Security Consideration

This is an information draft and does add any changes to the existing specifications.

8. Acknowledgments

The authors would like to thank Dominique Barthel for encouraging us to write this memo, for his guidance and his feedback.

9. References

9.1. Normative References

9.2. Informative References

Authors' Addresses

Table of Contents

• 1. Introduction
• 1.1. Convergence and background traffic
• 1.2. Asymmetric links
• 1.3. Experimental setup
• 2. Background traffic in a standard scenario
• 3. In presence of deaf nodes
• 4. In presence of muted nodes
• 5. Conclusion
• 6. IANA Considerations
• 7. Security Consideration
• 8. Acknowledgments
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Authors' Addresses