idnits 2.17.00 (12 Aug 2021) /tmp/idnits31903/draft-goyal-roll-dis-modifications-01.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 (October 12, 2012) is 3501 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- 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 Internet Engineering Task Force M. Goyal 3 Internet-Draft University of Wisconsin 4 Intended status: Experimental Milwaukee 5 Expires: April 15, 2013 D. Barthel 6 France Telecom Orange 7 E. Baccelli 8 INRIA 9 October 12, 2012 11 DIS Modifications 12 draft-goyal-roll-dis-modifications-01 14 Abstract 16 This document specifies the DIS flags and options that allow an RPL 17 node to control how neighbor RPL routers respond to its solicitiation 18 for DIOs. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 15, 2013. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. New Flags in the DIS Base Object . . . . . . . . . . . . . . . 4 57 4. DIS Options . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4.1. Metric Container . . . . . . . . . . . . . . . . . . . . . 5 59 4.2. Response Spreading Option . . . . . . . . . . . . . . . . 5 60 5. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 5.1. A Leaf Node Joining a DAG . . . . . . . . . . . . . . . . 6 62 5.2. Identifying A Defunct DAG . . . . . . . . . . . . . . . . 6 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 64 6.1. DIS Flags . . . . . . . . . . . . . . . . . . . . . . . . 8 65 6.2. RPL Control Message Options . . . . . . . . . . . . . . . 9 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 69 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 72 1. Introduction 74 An RPL node can use a DODAG Information Solicitation (DIS) message to 75 solicit DODAG Information Object (DIO) messages from its neighbor RPL 76 routers. A DIS may carry a Solicited Information option that 77 specifies the predicates of the DAG(s) the node is interested in. In 78 the absence of a Solicited Information option, it is assumed that the 79 node generating the DIS is interested in receiving DIOs for all the 80 DAGs. A DIS can be multicast to all the in-range routers or it can 81 be unicast to a specific neighbor router. RPL requires a router to 82 consider the receipt of a multicast DIS as an inconsistency and hence 83 reset its Trickle timers [RFC6206] for the matching DAGs. The 84 receipt of a unicast DIS causes an RPL router to generate the DIOs 85 for all the matching DAGs without resetting the Trickle timers. 87 Consider an RPL leaf node that desires to join a certain DAG. This 88 node can either wait for its neighbor RPL routers to voluntarily 89 transmit DIOs or it can proactively solicit DIOs using a DIS message. 90 Voluntary DIO transmissions may happen after a very long time if the 91 network is stable and the Trickle timer intervals have reached large 92 values. Thus, proactively seeking DIOs using a DIS may be the only 93 reasonable option. Since the node does not know which neighbor 94 routers belong to the DAG, it must solicit the DIOs using a multicast 95 DIS (with predicates of the desired DAG specified inside a Solicited 96 Information option). On receiving this DIS, the neighbor routers 97 that belong to the desired DAG will reset their Trickle timers and 98 quickly transmit their DIOs. The downside of resetting Trickle 99 timers is that the routers would continue to transmit the DIOs 100 frequently for a considerable time interval. These DIO transmissions 101 are unnecessary, consume precious energy and may contribute to 102 congestion in the network. 104 There are other scenarios where resetting of Trickle timer following 105 the receipt of a multicast DIS is not appropriate. For example, 106 consider an RPL router that desires to free up memory by deleting 107 state for the defunct DAGs it belongs to. Identifying a defunct DAG 108 may require the node to solicit DIOs from its DAG parents using a 109 multicast DIS. 111 To deal with the situations described above, this document specifies 112 the DIS flags and options that allow an RPL node to control how 113 neighbor RPL routers respond to its solicitiation for DIOs: 115 o Using routing constraints to limit the number of responding 116 routers; 118 o Whether the responding routers should reset their Trickle timers; 119 o Whether the responding routers should send a unicast DIO or a 120 multicast one; 122 o The time interval over which the responding routers must schedule 123 their DIO transmissions. 125 2. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in 130 [RFC2119]. 132 Additionally, this document uses terminology from [RFC6550]. 133 Specifically, the term RPL node refers to an RPL router or an RPL 134 host as defined in [RFC6550]. 136 3. New Flags in the DIS Base Object 138 0 1 2 3 139 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | Flags |N|T| Reserved | Option(s)... 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 Figure 1: Modified DIS Base Object 146 This document defines two new flags inside the DIS base object: 148 o "No Inconsistency" (N) flag: On receiving a unicast/multicast DIS 149 with N flag set, an RPL router MUST NOT reset the Trickle timers 150 for the matching DAGs. Also, a DIO generated in response to a DIS 151 with N flag set MUST always contain a Configuration option. 153 o "DIO Type" (T) flag: This flag specifies whether the responding 154 routers should transmit a multicast DIO or a unicast one. The 155 responding router MUST transmit a multicast DIO if this flag is 156 set. 158 The modified DIS base object is shown in Figure 1. 160 4. DIS Options 161 4.1. Metric Container 163 In order to limit the number of routers that will respond to a 164 multicast DIS, this document allows the specification of routing 165 constraints inside a DIS that a router must satisfy in order to 166 respond to the DIS. These routing constraints are specified inside a 167 Metric Container option contained in the DIS. Thus, this document 168 allows the inclusion of a Metric Container option inside a DIS. An 169 RPL router that receives a DIS with a Metric Container option MUST 170 ignore any Metric object in it, and MUST evaluate the "mandatory" 171 Constraint objects in it by comparing the constraint value to the 172 aggregated value of the corresponding routing metric that the router 173 maintains for the matching DAG(s). The aggregated routing metric 174 values MUST satisfy all the mandatory constraints in order for the 175 router to generate DIOs for the matching DAG(s). 177 4.2. Response Spreading Option 179 0 1 2 180 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Type = 0x0A | Length | Spread. Inter.| 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 Figure 2: The Response Spreading Option 187 A multicast DIS may lead to a large number of RPL routers responding 188 with DIOs. Concurrent transmissions by multiple routers are not 189 desirable. Such transmissions may end up in collisions. Unicast 190 DIOs may be able to avail of link-level retransmissions. However, 191 multicast DIOs have no such protection. These transmissions and 192 retransmissions may also cause congestion in the network. To avoid 193 such problems, this document specifies an optional DIO response 194 spreading mechanism. 196 This document defines a new RPL control message option called 197 "Response Spreading", shown in Figure 2, with a recommended Type 198 value 0x0A (to be confirmed by IANA). A Response Spreading option 199 may be included only inside a multicast DIS message. An RPL router 200 that responds to a multicast DIS, that includes a Response Spreading 201 option, MUST wait for a time uniformly chosen in the interval 202 [O..2^SpreadingInterval], expressed in ms, before attempting to 203 transmit its DIO. If the DIS does not include a Response Spreading 204 option, the node is free to transmit the DIO as it otherwise would. 206 5. Applications 208 This section details two example mechanisms that use the DIS flags 209 and options defined in this document. The first mechanism describes 210 how a leaf node may join a desired DAG. The second mechanism details 211 how a node may identify defunct DAGs for which it still maintains 212 state. 214 5.1. A Leaf Node Joining a DAG 216 A new leaf node that joins an established LLN runs an iterative 217 algorithm in which it requests (using multicast DIS) DIOs from 218 routers belonging to the desired DAG. The DIS message has the "No 219 Inconsistency" flag set (to prevent resetting of Trickle timer in 220 responding routers) and the "DIO Type" flag reset (to make responding 221 routers send unicast DIOs back). The DIS message can include a 222 Response Spreading option listing a suitable spreading interval and a 223 Metric Container listing the routing constraints that the responding 224 routers must satisfy. In each iteration, the node multicasts such a 225 DIS and waits for the DIOs. Once the spreading interval has expired, 226 the node considers the current iteration to be unsuccessful. Now the 227 node relaxes the routing constraints somewhat and proceeds to the 228 next iteration. The cycle repeats until the node receives one or 229 more DIOs in a particular iteration or if maximum number of 230 iterations have been reached. 232 5.2. Identifying A Defunct DAG 234 An RPL node may remove a neighbor from its parent set for a DAG for a 235 number of reasons: 237 o The neighbor is no longer reachable, as determined using a 238 mechanism such as Neighbor Unreachanility Detection (NUD) 239 [RFC4861], Bidirectional Forwarding Detection (BFD) [RFC5881] or 240 L2 triggers [RFC5184]; or 242 o The neighbor advertises an infinite rank in the DAG; or 244 o Keeping the neighbor as a parent would required the node to 245 increase its rank beyond L + DAGMaxRankIncrease, where L is the 246 minimum rank the node has had in this DAG; or 248 o The neighbor advertises membership in a different DAG within the 249 same RPL Instance, where a different DAG is recognised by a 250 different DODAGID or a different DODAGVersionNumber. 252 Even if the conditions listed above exist, an RPL node may fail to 253 remove a neighbor from its parent set because: 255 o The node may fail to receive the neighbor's DIOs advertising an 256 increased rank or the neighbor's membership in a different DAG; 258 o The node may not check, and hence may not detect, the neighbor's 259 unreachability for a long time. For example, the node may not 260 have any data to send to this neighbor and hence may not encounter 261 any event (such as failure to send data to this neighbor) that 262 would trigger a check for the neighbor's reachability. 264 In such cases, a node would continue to consider itself attached to a 265 DAG even if all its parents in the DAG are unreachable or have moved 266 to different DAGs. Such a DAG can be characterized as being defunct 267 from the node's perspective. If the node maintains state about a 268 large number of defunct DAGs, such state may prevent a considerable 269 portion of the total memory in the node from being available for more 270 useful purposes. 272 To alleviate the problem described above, an RPL node may invoke the 273 following procedure to identify a defunct DAG and delete the state it 274 maintains for this DAG. Note that, given the proactive nature of RPL 275 protocol, the lack of data traffic using a DAG can not be considered 276 a reliable indication of the DAG's defunction. Further, the Trickle 277 timer based control of DIO transmissions means the possibility of an 278 indefinite delay in the receipt of a new DIO from a functional DAG 279 parent. Hence, the mechanism described next is based on the use of a 280 DIS message to solicit DIOs about a DAG suspected of defunction. 281 Further, a multicast DIS is used so as to avoid the need to query 282 each parent individually and also to discover other neighbor routers 283 that may serve as the node's new parents in the DAG. 285 When an RPL node has not received a DIO from any of its parents in a 286 DAG for more than a locally configured time duration: 288 o The node generates a multicast DIS message with: 290 * "No Inconsistency" flag set so that the responding routers do 291 not reset their Trickle timers. 293 * "DIO Type" flag set so that the responding routers send 294 multicast DIOs and other nodes in the vicinity do not need to 295 invoke this procedure. 297 * A Solicited Information option to identify the DAG in question. 298 This option must have the I and D flags set and the 299 RPLInstanceID/DODAGID fields must be set to values identifying 300 the DAG. The V flag inside the Solicited Information option 301 should not be set so as to allow the neighbors to send DIOs 302 advertising the latest version of the DAG. 304 * A Response Spreading option specifying a suitable time interval 305 over which the DIO responses may arrive. 307 o After sending the DIS, the node waits for the duration specified 308 inside the Response Spreading option to receive the DIOs generated 309 by its neighbors. At the conclusion of the wait duration: 311 * If the node has received one or more DIOs advertising newer 312 version(s) of the DAG, it joins the latest version of the DAG, 313 selects a new parent set among the neighbors advertising the 314 latest DAG version and marks the DAG status as functional. 316 * Otherwise, if the node has not received a DIO advertising the 317 current version of the DAG from a neighbor in the parent set, 318 it removes that neighbor from the parent set. As a result, if 319 the node has no parent left in the DAG, it marks the DAG as 320 defunct and schedule the deletion of the state it has 321 maintained for the DAG after a locally configured "hold" 322 duration. (This is because, as per RPL specification, when a 323 node no longer has any parents left in a DAG, it is still 324 required to remember the DAG's identity (RPLInstanceID, 325 DODAGID, DODAGVersionNumber), the lowest rank (L) it has had in 326 this DAG and the DAGMaxRankIncrease value for the DAG for a 327 certain time interval to ensure that the node does not join an 328 earlier version of the DAG and does not rejoin the current 329 version of the DAG at a rank higher than L + 330 DAGMaxRankIncrease.) 332 6. IANA Considerations 334 6.1. DIS Flags 336 IANA is requested to allocate bits 6 and 7 of the DIS Flag Field to 337 become the "No Inconsistency" and "DIO Type" bits, the functionality 338 of which is described in Section 3 of this document. 340 +-------+------------------+---------------+ 341 | Value | Meaning | Reference | 342 +-------+------------------+---------------+ 343 | 6 | No Inconsistency | This document | 344 | 7 | DIO Type | This document | 345 +-------+------------------+---------------+ 347 6.2. RPL Control Message Options 349 IANA is requested to allocate a new code point in the "RPL Control 350 Message Options" registry for the "Response Spreading" option, the 351 behavior of which is described in Section 4.2. 353 +-------+--------------------+---------------+ 354 | Value | Meaning | Reference | 355 +-------+--------------------+---------------+ 356 | 0x0A | Response Spreading | This document | 357 +-------+--------------------+---------------+ 359 RPL Control Message Options 361 7. Security Considerations 363 TBA 365 8. References 367 8.1. Normative References 369 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 370 Requirement Levels", BCP 14, RFC 2119, March 1997. 372 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 373 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 374 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 375 Lossy Networks", RFC 6550, March 2012. 377 8.2. Informative References 379 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 380 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 381 September 2007. 383 [RFC5184] Teraoka, F., Gogo, K., Mitsuya, K., Shibui, R., and K. 384 Mitani, "Unified Layer 2 (L2) Abstractions for Layer 3 385 (L3)-Driven Fast Handover", RFC 5184, May 2008. 387 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 388 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 389 June 2010. 391 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 392 "The Trickle Algorithm", RFC 6206, March 2011. 394 Authors' Addresses 396 Mukul Goyal 397 University of Wisconsin Milwaukee 398 3200 N Cramer St 399 Milwaukee, WI 53201 400 USA 402 Phone: +1 414 2295001 403 Email: mukul@uwm.edu 405 Dominique Barthel 406 France Telecom Orange 407 28 Chemin Du Vieux Chene, BP 98 408 Meylan, 38243 409 France 411 Email: dominique.barthel@orange-ftgroup.com 413 Emmanuel Baccelli 414 INRIA 416 Phone: +33-169-335-511 417 Email: Emmanuel.Baccelli@inria.fr 418 URI: http://www.emmanuelbaccelli.org/