idnits 2.17.1 draft-papadopoulos-roll-dis-mods-use-cases-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2020) is 1510 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RAW G. Papadopoulos 3 Internet-Draft IMT Atlantique 4 Intended status: Standards Track March 9, 2020 5 Expires: September 10, 2020 7 Use cases for DIS Modifications 8 draft-papadopoulos-roll-dis-mods-use-cases-00 10 Abstract 12 This document presents some of the use-cases which call for DIS flags 13 and options modifications. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on September 10, 2020. 32 Copyright Notice 34 Copyright (c) 2020 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 51 3. Applications . . . . . . . . . . . . . . . . . . . . . . . . 2 52 3.1. A Leaf Node Joining a DAG . . . . . . . . . . . . . . . . 2 53 3.2. Identifying A Defunct DAG . . . . . . . . . . . . . . . . 3 54 3.3. Adjacencies probing with RPL . . . . . . . . . . . . . . 5 55 3.3.1. Deliberations . . . . . . . . . . . . . . . . . . . . 6 56 4. Informative References . . . . . . . . . . . . . . . . . . . 6 57 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 59 1. Introduction 61 2. Terminology 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in [RFC2119]. 67 3. Applications 69 This section details some use cases that require DIS modifications 70 compared to the behaviour currently defined in [RFC6550]. The first 71 use case is thatof a new leaf node joining an established DAG in an 72 energy efficient manner. The second use case describes why node 73 might want to use DIS to identify defunct DAGs for which it still 74 maintains state. The third use case describes the need for adjacency 75 probing and how DIS can used for that. 77 3.1. A Leaf Node Joining a DAG 79 This use case is typically of a smart meter being replaced in the 80 field, while a RPL network is operating and stable. The new smart 81 meter must join the network quickly, without draining the energy of 82 the surrounding nodes, be they battery-operated RPL routers or leaf 83 nodes. In this use case, the issues with the current RPL 84 specification are 86 o Just waiting for a gratuitous DIO may take a long time if the 87 Trickle timers have relaxed to the steady state. A technician who 88 has just installed the new meter needs to positively assess that 89 the meter has joined the network before it leaves the premise. It 90 is not economically viable to ask the technician to standby the 91 meter until a gratuitous DIO has arrived, which may take hours. 93 o If the meter sends a DIS, it needs to do so using multicast, 94 because it has no knowledge of its surroundings. Sending a 95 multicast DIS is considered an inconsistency by the nearby RPL 96 routers. They will reset their Trickle timer to the shortest 97 period. This will trigger sending a stream of DIOs until the 98 Trickle timers relax again. The DIOs will be sent in multicast, 99 which will trigger energy expenditure at nearby nodes, which had 100 no need for the DIOs. 102 A proposed solution could be the following. A new leaf node that 103 joins an established LLN runs an iterative algorithm in which it 104 requests (using multicast DIS) DIOs from routers belonging to the 105 desired DAG. 107 The DIS message has the "No Inconsistency" flag set to prevent 108 resetting of Trickle timer in responding routers, thereby keeping the 109 aggregated number of transmissions low. It also has the "DIO Type" 110 flag set to make responding routers send unicast DIOs back, thereby 111 not triggering full reception in nearby nodes that have state-of-the- 112 art radio receivers with hardware-based address filtering. 114 The DIS message can include a Response Spreading option prescribing a 115 suitable spreading interval based on the expected density of nearby 116 routers and on the expected Layer 2 technology. 118 The DIS will likely include a Metric Container listing the routing 119 constraints that the responding routers must satisfy in order to be 120 allowed to respond [RFC6551]. 122 At each iteration, the node multicasts such a DIS and waits for 123 forthcoming DIOs. After a time equal to the spreading interval, the 124 node considers the current iteration to be unsuccessful. The node 125 consequently relaxes the routing constraints somewhat and proceeds to 126 the next iteration. 128 The cycle repeats until the node receives one or more DIOs or until 129 it has relaxed the constraints to the lowest acceptable values. 131 This algorithm has been proven in the field to be extremely energy- 132 efficient, especially when routers have a wide communication range. 134 3.2. Identifying A Defunct DAG 136 A RPL node may remove a neighbor from its parent set for a DAG for a 137 number of reasons: 139 o The neighbor is no longer reachable, as determined using a 140 mechanism such as Neighbor Unreachanility Detection (NUD) 141 [RFC4861], Bidirectional Forwarding Detection (BFD) [RFC5881] or 142 L2 triggers [RFC5184]; or 144 o The neighbor advertises an infinite rank in the DAG; or 146 o Keeping the neighbor as a parent would required the node to 147 increase its rank beyond L + DAGMaxRankIncrease, where L is the 148 minimum rank the node has had in this DAG; or 150 o The neighbor advertises membership in a different DAG within the 151 same RPL Instance, where a different DAG is recognised by a 152 different DODAGID or a different DODAGVersionNumber. 154 Even if the conditions listed above exist, a RPL node may fail to 155 remove a neighbor from its parent set because: 157 o The node may fail to receive the neighbor's DIOs advertising an 158 increased rank or the neighbor's membership in a different DAG; 160 o The node may not check, and hence may not detect, the neighbor's 161 unreachability for a long time. For example, the node may not 162 have any data to send to this neighbor and hence may not encounter 163 any event (such as failure to send data to this neighbor) that 164 would trigger a check for the neighbor's reachability. 166 In such cases, a node would continue to consider itself attached to a 167 DAG even if all its parents in the DAG are unreachable or have moved 168 to different DAGs. Such a DAG can be characterized as being defunct 169 from the node's perspective. If the node maintains state about a 170 large number of defunct DAGs, such state may prevent a considerable 171 portion of the total memory in the node from being available for more 172 useful purposes. 174 To alleviate the problem described above, a RPL node may invoke the 175 following procedure to identify a defunct DAG and delete the state it 176 maintains for this DAG. Note that, given the proactive nature of RPL 177 protocol, the lack of data traffic using a DAG can not be considered 178 a reliable indication of the DAG's defunction. Further, the Trickle 179 timer based control of DIO transmissions means the possibility of an 180 indefinite delay in the receipt of a new DIO from a functional DAG 181 parent. Hence, the mechanism described here is based on the use of a 182 DIS message to solicit DIOs about a DAG suspected of defunction. 183 Further, a multicast DIS is used so as to avoid the need to query 184 each parent individually and also to discover other neighbor routers 185 that may serve as the node's new parents in the DAG. 187 When a RPL node has not received a DIO from any of its parents in a 188 DAG for more than a locally configured time duration: 190 o The node generates a multicast DIS message with: 192 * the "No Inconsistency" flag set so that the responding routers 193 do not reset their Trickle timers. 195 * the "DIO Type" flag not set so that the responding routers send 196 multicast DIOs and other nodes in the vicinity do not need to 197 invoke this procedure. 199 * a Solicited Information option to identify the DAG in question. 200 This option must have the I and D flags set and the 201 RPLInstanceID/DODAGID fields must be set to values identifying 202 the DAG. The V flag inside the Solicited Information option 203 should not be set so as to allow the neighbors to send DIOs 204 advertising the latest version of the DAG. 206 * a Response Spreading option specifying a suitable time interval 207 over which the DIO responses may arrive. 209 o After sending the DIS, the node waits for the duration specified 210 inside the Response Spreading option to receive the DIOs generated 211 by its neighbors. At the conclusion of the wait duration: 213 * If the node has received one or more DIOs advertising newer 214 version(s) of the DAG, it joins the latest version of the DAG, 215 selects a new parent set among the neighbors advertising the 216 latest DAG version and marks the DAG status as functional. 218 * Otherwise, if the node has not received a DIO advertising the 219 current version of the DAG from a neighbor in the parent set, 220 it removes that neighbor from the parent set. As a result, if 221 the node has no parent left in the DAG, it marks the DAG as 222 defunct and schedule the deletion of the state it has 223 maintained for the DAG after a locally configured "hold" 224 duration. (This is because, as per RPL specification, when a 225 node no longer has any parents left in a DAG, it is still 226 required to remember the DAG's identity (RPLInstanceID, 227 DODAGID, DODAGVersionNumber), the lowest rank (L) it has had in 228 this DAG and the DAGMaxRankIncrease value for the DAG for a 229 certain time interval to ensure that the node does not join an 230 earlier version of the DAG and does not rejoin the current 231 version of the DAG at a rank higher than L + 232 DAGMaxRankIncrease.) 234 3.3. Adjacencies probing with RPL 236 RPL avoids periodic hello messaging as compared to other distance 237 vector protocols. It uses trickle timer based mechanism to update 238 configuration parameters. This significantly reduces the RPL control 239 overhead. One of the fallout of this design choice is that, in the 240 absence of regular traffic, the adjacencies could not be tested and 241 repaired if broken. 243 RPL provides a mechanism in the form of unicast DIS to query a 244 particular node for its DIO. A node receiving a unicast DIS MUST 245 respond with a unicast DIO with Configuration Option. This mechanism 246 could as well be made use of for probing adjacencies and certain 247 implementations such as Contiki uses this. The periodicity of the 248 probing is implementation dependent, but the node is expected to 249 invoke probing only when 251 o There is no data traffic based on which the links could be tested. 253 o There is no L2 feedback. In some case, L2 might provide periodic 254 beacons at link layer and the absence of beacons could be used for 255 link tests. 257 3.3.1. Deliberations 259 o Should the probing scheme be standardized? In some cases using 260 multicast based probing may prove advantageous. 262 o In some cases using multicast based probing may prove 263 advantageous. Currently RPL does not have multicast based 264 probing. Multicast DIS/DIO may not be suitable for probing 265 because it could possibly lead to change of states. 267 4. Informative References 269 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 270 Requirement Levels", BCP 14, RFC 2119, 271 DOI 10.17487/RFC2119, March 1997, 272 . 274 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 275 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 276 DOI 10.17487/RFC4861, September 2007, 277 . 279 [RFC5184] Teraoka, F., Gogo, K., Mitsuya, K., Shibui, R., and K. 280 Mitani, "Unified Layer 2 (L2) Abstractions for Layer 3 281 (L3)-Driven Fast Handover", RFC 5184, 282 DOI 10.17487/RFC5184, May 2008, 283 . 285 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 286 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 287 DOI 10.17487/RFC5881, June 2010, 288 . 290 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 291 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 292 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 293 Low-Power and Lossy Networks", RFC 6550, 294 DOI 10.17487/RFC6550, March 2012, 295 . 297 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 298 and D. Barthel, "Routing Metrics Used for Path Calculation 299 in Low-Power and Lossy Networks", RFC 6551, 300 DOI 10.17487/RFC6551, March 2012, 301 . 303 Author's Address 305 Georgios Z. Papadopoulos 306 IMT Atlantique 307 Office B00 - 102A 308 2 Rue de la Chataigneraie 309 Cesson-Sevigne - Rennes 35510 310 FRANCE 312 Phone: +33 299 12 70 04 313 Email: georgios.papadopoulos@imt-atlantique.fr