idnits 2.17.1 draft-audeoudh-rpl-asymmetric-links-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2019) is 1874 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Audeoud 3 Internet-Draft M. Heusse 4 Intended status: Informational LIG 5 Expires: September 12, 2019 March 11, 2019 7 Experimental observation of RPL: routing protocol overhead and 8 asymmetric links 9 draft-audeoudh-rpl-asymmetric-links-00 11 Abstract 13 This document summarizes our observations of the behavior of RPL on a 14 testbed composed of tens of IEEE 802.15.4 nodes. Our first 15 observation is that the continuous task of estimating the link metric 16 to all candidate neighbors causes a significant background load. 17 This traffic is persistent, even in a stable network where DIO 18 transmissions are eventually widely spaced. Next, this document 19 focuses on the case of the presence of an asymmetric link, due to 20 either a muted or a deaf node. In these circumstances, the standard 21 RPL mechanisms may well generate hundreds of routing messages per 22 node and per hour. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 12, 2019. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 1. Introduction 58 We present three cases in which the RPL protocol [RFC6550] incurs a 59 large number of routing message transmissions even though they 60 correspond to expected situations in LLNs. This memo summarizes our 61 observations on RPL that are part of a broader set of experiments 62 [EXPE]. 64 1.1. Convergence and background traffic 66 The maintenance traffic in RPL converges to a low rate of DIO 67 generation when the topology is stable. Nevertheless, the proactive 68 approach of RPL imposes that the nodes permanently gauge potential 69 new alternative neighbors. This mechanism is not standardized, but 70 it is necessary. Users need to be aware of its existence and its 71 footprint. 73 1.2. Asymmetric links 75 The quality of radio transmissions depends on the environment and on 76 the radio hardware. In particular, interferences do not have the 77 same impact on all nodes. Also, the transmission conditions are 78 different between devices due to the variability of the amplifier 79 gain and sensitivity. 81 So a link between two nodes may be asymmetric, and not present the 82 same packet delivery ratios (PDR) in both directions. In extreme 83 cases, a node N may be "deaf" (i.e. other nodes receive N's packets, 84 but N does not receive anything back) or "muted" (i.e. N receives 85 properly, but is not heard). 87 1.3. Experimental setup 89 Table 1 presents the parameters used in the experiments. The trickle 90 settings match the recommended practice, with Imin more than one 91 order of magnitude greater than the broadcast duration (125 92 milliseconds in ContikiMAC). We found that this setting effectively 93 avoids DIO collisions in our experiments. 95 +-----------------------------+-------------------------------------+ 96 | Parameter | Value | 97 +-----------------------------+-------------------------------------+ 98 | Platform | IoT-lab | 99 | | | 100 | Sensors | IoT-lab's M3 motes (ARM Cortex M3 | 101 | | STM32F103REY) | 102 | | | 103 | Sensor radio | 802.15.4 @2.4GHz (AT86RF231) | 104 | | | 105 | OS & RPL implementation | Contiki 3.0 | 106 | | | 107 | Radio Duty Cycling (RDC) | ContikiMAC | 108 | | | 109 | RDC Check interval | 125 ms | 110 | | | 111 | RPL Mode of Operation | Storing | 112 | | | 113 | Imin | 4 seconds | 114 | | | 115 | Imax | 1048 seconds | 116 | | | 117 | DIORedundancyConstant | 10 (standard's default) | 118 | | | 119 | DAO re-generation period | 15 to 22 minutes | 120 | | | 121 | Objective function | MRHOF with ETX | 122 | | | 123 | # UDP traffic intensity per | 1 request-response every 5 minutes | 124 | client | | 125 +-----------------------------+-------------------------------------+ 127 Table 1: Main parameters used during the experiments 129 2. Background traffic in a standard scenario 131 On the IoT-LAB testbed, we start 40 client nodes and a sink during 2 132 hours. Each client sends one UDP packet every 5 minutes to the sink 133 which replies with another UDP packet. For this experiment, the 134 nodes are distributed in the DODAG at a mean distance of 3.1 hops to 135 the sink (median of 3). There are 9 nodes at a distance of 1 hop, 136 and 5 nodes at a distance greater or equal to 6. Table 2 presents 137 the results numerically. 139 o The bulk of multicast messages are DIOs sent by the nodes 140 following the trickle algorithm. As the network is stable, the 141 network-wide multicast DIO generation intensity reduces gradually 142 until all nodes use a DIO interval of Imax (which gives an average 143 period of approximately 750s in the considered case, approx. 1 144 message every 20s for our 41-node network). 146 o An intense and continuous traffic of unicast DIOs. RPL makes no 147 provision for Unicast DIOs; it turns out that these messages are 148 used by Contiki to assess the link quality to the neighbors 149 [FNINES]. 151 So this latter traffic is a re-use of DIO messages for a task which 152 is out of the scope of RPL. The objective of this document is not to 153 discuss the arguments for and against this specific mechanism in 154 Contiki. Nevertheless, such a mechanism is necessary to RPL: "RPL 155 expects an external mechanism to be triggered during the parent 156 selection phase in order to verify link properties and neighbor 157 reachability" [RFC6550]. Also RFC 6719 states that: "A node should 158 compute the path cost for the path through each candidate neighbor 159 reachable through an interface" [RFC6719]. 161 At the application layer, it works well; but the price to pay is very 162 significant, even counting the same overhead for broadcast and 163 unicast messages. There are 4869 RPL message exchanges over the 164 course of the experiment. In our special case of an application 165 traffic which consists in one request response from each end node to 166 the sink, we witness only 5516 one-hop data message transmissions, so 167 that about half of all MAC-layer frames are linked to the routing 168 processes. 170 +--------------------------------------------+-----------------+ 171 | Message | # of occurrence | 172 +--------------------------------------------+-----------------+ 173 | DIS multicast | 26 | 174 | | | 175 | DIO multicast | 760 | 176 | | | 177 | DIO unicast | 2497 | 178 | | | 179 | DAO (unicast, counted on each hop) | 1407 | 180 | | | 181 | DAO No-Path (unicast, counted on each hop) | 179 | 182 | | | 183 | Data packet successfully routed end-to-end | 1795 (97%) | 184 | | | 185 | Data packet emitted (counted on each hop) | 5516 | 186 +--------------------------------------------+-----------------+ 188 Table 2: Number of messages sent during the experiment of background 189 traffic 191 3. In presence of deaf nodes 193 When a RPL node is not associated with any DODAG, it broadcasts a DIS 194 message. This message resets the trickle timer that schedules the 195 DIO message emissions in its neighborhood, thus generating many DIO 196 broadcasts. Although this mechanism is useful to speed up the 197 insertion of new nodes into the network, it is very harmful when a 198 node N is deaf. Indeed, as N keeps broadcasting DIS packets, its 199 neighbors constantly send back DIOs. 201 On the IoT-LAB testbed, we start 11 client nodes and a sink during 1 202 hour. Each client sends one UDP packet every 5 minutes to the sink 203 which replies with another UDP packet. One of the client nodes is 204 deaf: its sensitivity is lowered and it does not receive any message 205 from other nodes, whereas its packets are received by its neighbors. 207 Table 3 presents the results numerically. DIO packets are constantly 208 broadcast at the average rate of 1 every 3 seconds for the whole 209 network, i.e. approximately 2 broadcast packets per node per minute. 210 This intensity per node is one order of magnitude more than in the 211 previous experiment. 213 This scenario is not necessarily only a routing protocol problem, but 214 in part a question of neighbor management. One could expect that the 215 MAC layer would eventually detect that a neighbor is unresponsive and 216 blacklist it, for instance. However, here, the detection of the 217 asymmetry could not directly be done by the MAC layer, as DIS and DIO 218 packets are broadcast and thus, not acknowledged. There should be a 219 safeguard mechanism in RPL to break out of the DIS/DIO cycle in these 220 circumstances. 222 +----------------------------------------------------+--------------+ 223 | Message | # of | 224 | | occurrence | 225 +----------------------------------------------------+--------------+ 226 | DIS multicast (deaf node excluded) | 5 | 227 | | | 228 | DIO multicast | 1177 | 229 | | | 230 | DIO unicast | 315 | 231 | | | 232 | DAO (unicast, counted on each hop) | 202 | 233 | | | 234 | DAO No-Path (unicast, counted on each hop) | 40 | 235 | | | 236 | Data packet successfully routed end-to-end (deaf | 233 (99%) | 237 | node excluded) | | 238 | | | 239 | Data packet emitted (counted on each hop, deaf | 583 | 240 | node excluded) | | 241 +----------------------------------------------------+--------------+ 243 Table 3: Number of messages sent during the experiment with the deaf 244 node 246 4. In presence of muted nodes 248 We finally consider the case of a node that loses the ability to 249 reach some neighbors and, in particular, its preferred parent. On 250 the IoT-LAB testbed, we start 11 client nodes and a sink during 1 251 hour. Each client sends one UDP packet every 5 minutes to the sink 252 which replies with another UDP packet (there is no deaf node here). 253 Obviously, if we completely mute one node from the start, it will not 254 disturb its neighbors much as all its messages would be lost. So we 255 start a node (node 40 of Figure 1) with a regular setting and let it 256 associate itself with the network and communicate with other nodes. 257 Then, after 15 minutes, we reduce its transmission power: it is muted 258 and cannot reach its former neighbors anymore -- except one of them, 259 node 33, so that it is not totally isolated from the rest of the 260 network. After about 10 minutes, the network is completely repaired 261 and nodes are back to transmitting control messages at a normal rate. 263 (45) (45) 264 / | \ | \ 265 / | \ | \ 266 (40) (12) (18) (12) (18) 267 | | \ | \ 268 | | \ | \ 269 (33) (48) (10) (48) (10) 270 / | \ \ / | \ \ 271 / | \ \ / | \ \ 272 (57) (55) (30) (51) (57) (55) (30) (51) 273 \ / \ 274 \ / \ 275 ( 2) (33) ( 2) 276 | 277 | 278 (40) 280 Before node 40 is After node 40 is 281 muted muted 283 Figure 1: DODAG for the muted node experiment 285 Here, the scenario clearly shows the effect of a local repair of the 286 DODAG. Indeed, the link between node 33 and node 40 should be 287 reversed to reach the DODAG root again. We have a transient loop in 288 the network until node 33 is able to use node 55 as a successor: 289 node 40 uses node 33 as a successor, which in turn uses node 40 as a 290 successor -- but note that the traffic does not loop around, thanks 291 to the data path validation mechanism based on the RPL header. 293 Table 4 presents the results numerically. This experiment shows that 294 RPL handles this situation correctly: few data packets are lost and 295 the DODAG repair is relatively quick. Nevertheless, a naive user 296 could expect that only a few additional packets would be generated 297 for such a limited topology change as for most routing protocols. 298 But the repair traffic observed in this experiment is merely a 299 consequence of the constant background routing overhead that the 300 proactive approach and trickle imply. 302 +------------------+------------------+---------------------+-------+ 303 | Message | # of occurrence | # of occurrence | # | 304 | | between 15th and | except between 15th | total | 305 | | 25th minute | and 25th minute | | 306 +------------------+------------------+---------------------+-------+ 307 | DIS multicast | 0 | 3 | 3 | 308 | | | | | 309 | DIO multicast | 37 | 172 | 209 | 310 | | | | | 311 | DIO unicast | 58 | 313 | 371 | 312 | | | | | 313 | DAO (unicast) | 41 | 258 | 299 | 314 | | | | | 315 | DAO No-Path | 11 | 40 | 51 | 316 | (unicast) | | | | 317 | | | | | 318 | Data packet | 37 (90%) | 220 (99%) | 251 | 319 | successfully | | | (98%) | 320 | routed end-to- | | | | 321 | end | | | | 322 | | | | | 323 | Data packet | 103 | 598 | 701 | 324 | emitted (counted | | | | 325 | on each hop) | | | | 326 +------------------+------------------+---------------------+-------+ 328 Table 4: Number of messages sent during the experiment with the muted 329 node 331 5. Conclusion 333 First, we would like to emphasize the robustness of the Contiki 334 implementation of RPL, which also matches the RFC specification to 335 the extent of the points we checked. Our choice of Imin is 336 constrained by the broadcast transmission duration; however, the 337 choice of values Imax and DIORedundancyConstant could cause what one 338 could consider excessive DIO traffic over the long run, but this is 339 not the subject of our observations. 341 Secondly, the set of RPL-related documents leave aside the necessary 342 mechanism of link metric estimation. This is not unexpected as it 343 can be done without raising interoperability issues. Nevertheless, 344 users need to be aware of this necessity e.g. in the case of power- 345 constrained nodes. Also, as this task is closely related to the 346 routing process, it is tempting and practical to use routing packets 347 to the purpose of link metric estimation, as in Contiki. In this 348 specific case, it is unknown if all implementations tolerate to 349 receive unicast DIO, for instance. A possibility could be to reserve 350 a packet format for metric estimation or explicitely allow a possible 351 side-use of existing packets. 353 Pushing this line of thought a bit further, it could be of interest 354 to integrate (or combine) the broadcast DIS/DIO exchange to the link 355 metric estimation. This would allow the nodes to detect strongly 356 asymmetric links at an early stage, and treat the messages from the 357 corresponding neighbor knowingly. 359 6. IANA Considerations 361 This document includes no request to IANA. 363 7. Security Consideration 365 This is an information draft and does add any changes to the existing 366 specifications. 368 8. Acknowledgments 370 The authors would like to thank Dominique Barthel for encouraging us 371 to write this memo, for his guidance and his feedback. 373 9. References 375 9.1. Normative References 377 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 378 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 379 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 380 Low-Power and Lossy Networks", RFC 6550, 381 DOI 10.17487/RFC6550, March 2012, 382 . 384 [RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with 385 Hysteresis Objective Function", RFC 6719, 386 DOI 10.17487/RFC6719, September 2012, 387 . 389 9.2. Informative References 391 [EXPE] Audeoud, H. and M. Heusse, "Experimental Comparison of 392 Routing Protocols for Wireless Sensors Networks: Routing 393 Overhead and Asymmetric Links", in proceedings of the 29th 394 International Teletraffic Congress (ITC 29), Genoa, 395 DOI 10.23919/ITC.2017.8064339, 2017, 396 . 398 [FNINES] Duquennoy, S., Eriksson, J., and T. Voigt, "Five-Nines 399 Reliable Downward Routing in RPL", arXiv 1710.02324, 2017, 400 . 402 Authors' Addresses 404 Henry-Joseph Audeoud 405 Grenoble Informatics Laboratory 407 Email: henry-joseph.audeoud@univ-grenoble-alpes.fr 409 Martin Heusse 410 Grenoble Informatics Laboratory 412 Email: martin.heusse@univ-grenoble-alpes.fr