idnits 2.17.00 (12 Aug 2021) /tmp/idnits32168/draft-dejean-roll-selective-dis-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 abstract seems to contain references ([I-D.ietf-roll-rpl]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 7, 2011) is 4086 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) == Unused Reference: 'RFC5226' is defined on line 382, but no explicit reference was found in the text == Outdated reference: draft-ietf-roll-rpl has been published as RFC 6550 == Outdated reference: draft-ietf-roll-trickle has been published as RFC 6206 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: draft-ietf-roll-terminology has been published as RFC 7102 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL Working Group N. Dejean 3 Internet-Draft Elster SAS 4 Intended status: Standards Track D. Barthel 5 Expires: September 8, 2011 France Telecom Orange 6 March 7, 2011 8 Selective DIS for RPL 9 draft-dejean-roll-selective-dis-00 11 Abstract 13 This document specifies DIS options that enrich the potential 14 behavior of the Routing Protocol for Low Power and Lossy Networks 15 (RPL) specified in [I-D.ietf-roll-rpl]. 17 The goal is to enable new leaf nodes to quickly discover and attach 18 to the routing structure, without having to wait for spontaneous DIO 19 transmissions by neighbour routers and without causing them to reset 20 their DIO timers. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 8, 2011. 45 Copyright Notice 47 Copyright (c) 2011 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Leaf Node bit . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. DIS Options . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.1. Metric Container . . . . . . . . . . . . . . . . . . . . . 5 66 3.2. Response Spreading . . . . . . . . . . . . . . . . . . . . 5 67 4. Example of use . . . . . . . . . . . . . . . . . . . . . . . . 6 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 5.1. DIS Flag Field . . . . . . . . . . . . . . . . . . . . . . 9 70 5.2. RPL Control Message Options . . . . . . . . . . . . . . . 9 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 8.1. Normative references . . . . . . . . . . . . . . . . . . . 9 75 8.2. Informative references . . . . . . . . . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 This document makes use of the terminology defined in 81 [I-D.ietf-roll-terminology]. 83 Low power and Lossy Networks (LLNs) have specific routing 84 characteristics compared with traditional wired or ad-hoc networks 85 that have been spelled out in [RFC5548], [RFC5673], [RFC5826] and 86 [RFC5867]. 88 [I-D.ietf-roll-rpl] has specified the minimally viable core of 89 mechanisms for a routing protocol, called Routing Protocol for Low 90 Power and Lossy Networks (RPL), specifically designed for LLNs. 92 This document specifies DIS options that enrich the behavior of RPL 93 and that were left out of [I-D.ietf-roll-rpl] in the interest of 94 time. 96 The goal is to enable new leaf nodes to quickly discover and attach 97 to the routing structure, without having to wait for spontaneous DIO 98 transmissions by neighbour routers and without causing them to reset 99 their DIO timers. 101 Indeed, with RPL as defined in [I-D.ietf-roll-rpl], a leaf node that 102 wants to join an already deployed LLN is confronted with the 103 following dilemna: 105 o It can either wait for DIOs to be sent by neighbor routers. These 106 transmissions may happen after a very long time, since the Trickle 107 timers of the neighbor routers may have increased their period to 108 a very large value, in order to save energy in a stable network. 109 Furthermore, the transmission of a DIO packet by a neighbor router 110 is not even guaranteed to happen during a Trickle timer period, 111 since transmission suppression may happen (see 112 [I-D.ietf-roll-trickle]). 114 o Or it elects to proactively send a DIS (DODAG Information 115 Sollicitation). This DIS can only be sent in broadcast, since the 116 new node does know which router to ask for. Under the 117 specification of [I-D.ietf-roll-rpl], all routers that receive a 118 broadcast DIS packet will reset their Trickle timer. The time to 119 their next spontaneous DIO transmission will indeed be 120 dramatically shortened, which is desirable, although it will not 121 prevent potential transmission suppression. But an undesired 122 effect is that this will induce a large energy consumption in the 123 network for two compounding reasons: first, all neighbour routeurs 124 will respond, irrespective of their relevance to the new node, and 125 second, each neighbor router will send frequent DIOs until its 126 Trickle timer relaxes to the maximum period, even though only the 127 first DIO is useful. 129 None of the choices above matches the requirements of [RFC5548]. 131 This document defines a way to broadcast a DIS message that includes 132 selective options and a flag in order to query responses by neighbor 133 routers such that: 135 o responses are sent promptly, reducing the time the technician has 136 to sit waiting at the customer premises to check the result of the 137 joining process 139 o responses are DIOs sent using unicast, reducing the overhearing 140 energy cost in the router neighborhood when modern MAC 141 technologies are used 143 o each neighbor router only responds with a single DIO for each DIS, 144 reducing the reception cost at the destination 146 o the DIO is only sent if the neighbor router matches the criteria 147 specified in the DIS selective options, reducing the reception, 148 collision and overhearing energy costs 150 Admitedly, requesting an unknown population of neighbor routers to 151 promptly send even a single DIO may be a cause for multiple 152 collisions. This risk is mitigated by the use of good access 153 contention methods at the link layer and by the wise use of the DIS 154 options. However, both conditions are beyond the control of this 155 specification. This document therefore specifies an optional 156 collision mitigation mechanism of its own. 158 2. Leaf Node bit 160 In the format of the DIS base object, bit 0 of the Flag field is 161 defined as the "Leaf Node" bit. 163 0 1 2 164 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 |L| Flags | Reserved | Option(s)... 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 Figure 1: The DIS Base Object 171 A node that receives a DIS with the "Leaf Node" bit set MUST NOT 172 reset its DIO Trickle timer, even if it matches the options carried 173 by the DIS. 175 A node that receives a DIS message with the "Leaf Node" bit set and 176 that matches the options carried in the DIS MUST reply with a unicast 177 DIO, using the mechanism described in Section 3.2. 179 3. DIS Options 181 3.1. Metric Container 183 In addition to those already listed in [I-D.ietf-roll-rpl], the 184 following option is declared valid for a DIS message: 186 0x02 Metric Container 188 A node that receives a DIS with a Metric Container option MUST ignore 189 any Metric object in it, and MUST parse the Contraint objects in it, 190 if any. The constraint values are compared to the values of the 191 corresponding metrics known to the node. If both a Solicited 192 Information option and a Metric Container option are present in a DIS 193 message, they combine in a logical AND fashion, i.e. all predicates 194 MUST match for the DIS to globally match. 196 If a Constraint objects carries a constraint for a metric the value 197 of which is unknown to the node, it is RECOMMENDED that the node 198 considers the constraint a match. 200 3.2. Response Spreading 202 With a wise use of the DIS options, our experience is that the 203 population of responding routers is small enough for modern medium 204 access techniques to efficiently resolve contention at the link 205 layer. However, for those systems in which either above-mentioned 206 postulate can't be met, an optional DIO response spreading mechanism 207 is specified here. 209 A new RPL control message option is defined, called "Response 210 Spreading", with a recommended Type value of 0x0A (to be confirmed by 211 IANA). Its format complies with the general format of RPL options, 212 and is described in Figure 2. 214 0 1 2 215 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Type = 0x0A | Length | Spread. Inter.| 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 Figure 2: The Response Spreading option 222 A node that responds to a broadcast DIS in observance of Section 2 223 MUST, if that DIS includes a Response Spreading option, wait for a 224 time uniformely drawn in the interval [O..2^SpreadingInterval], 225 expressed in ms, before attempting to transmit its DIO. If the DIS 226 does not include a Response Spreading option, the node is free to 227 transmit the DIO as it otherwise would. 229 4. Example of use 231 A new leaf node that joins an established network runs an iterative 232 algorithm by which it requests (using broadcast) network information 233 from routers belonging to the desired network ID and which match some 234 constraint values passed as parameters of the request. At each 235 unsuccessful iteration, the requirements are relaxed, until one or 236 several answers are received, or until the maximum number of 237 iterations is reached. The answers from the routers can 238 advantageously contain the values for other metrics than those by 239 which the request was qualified, so that the router selection takes 240 place based on more metrics. 242 The following example shows requests iterating on two constraint 243 values (on Hop Count and Link Quality Level) and makes use of a third 244 metric value (Node Energy) provided into the answers. 246 With Hop Count iterating through four different values (0-3) and Link 247 Quality Level iterating through three possible values (2,4,6), a 248 maximum of twelve DIS packets can be broadcast per joining node, in 249 the following order: 251 o Soliciting info from routers with max Hop Count 0 and max LQL 2 253 o Soliciting info from routers with max Hop Count 0 and max LQL 4 254 o Soliciting info from routers with max Hop Count 0 and max LQL 6 256 o Soliciting info from routers with max Hop Count 1 and max LQL 2 258 o Soliciting info from routers with max Hop Count 1 and max LQL 4 260 o Soliciting info from routers with max Hop Count 1 and max LQL 6 262 o Soliciting info from routers with max Hop Count 2 and max LQL 2 264 o Soliciting info from routers with max Hop Count 2 and max LQL 4 266 o Soliciting info from routers with max Hop Count 2 and max LQL 6 268 o Soliciting info from routers with max Hop Count 3 and max LQL 2 270 o Soliciting info from routers with max Hop Count 3 and max LQL 4 272 o Soliciting info from routers with max Hop Count 3 and max LQL 6 274 Receiving any answer stops the iteration. Per our example, the new 275 node then selects its parent router, based on the Node Energy and the 276 Link Quality Level, according to the following algorithm: 278 o Reject router(s) with asymmetric connectivity (LQL seen from new 279 node does not match the constraint value issued in the DIS 280 request) 282 o Retain the router(s) that advertise the best Node Energy level 284 o In case of equality, select the router that boasts the best Link 285 Quality Level. 287 0 1 2 3 288 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 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | 155 | 0x00 | Checksum | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | DIS BASE | Solicited Information | 293 |L| Flags | Reserved | Type | Opt Length | 294 |1| 0 | 0x00 | 7 | 19 | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Solicited Information | 297 | RPLInstanceID |V|I|D| Flags | DODAG ID | 298 | =0x66 |0|1|0| 0 | 0x0000 | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Solicited Information | 301 | DODAG ID | 302 | 0x00000000 | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Solicited Information | 305 | DODAG ID | 306 | 0x00000000 | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Solicited Information | 309 | DODAG ID | 310 | 0x00000000 | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Solicited Information |MetricContainer| 313 | DODAG ID |Version Number | Type | 314 | 0x0000 | 0x00 | 2 | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Metric Container | 317 | Opt Length |Routing-MC-Type|Res Flags|P|C|O|R| A | Prec | 318 | 12 | 3 (HC) | 0 |0|1|0|0| 000 | 000 | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Metric Container | 321 | Length (bytes)| Res | Flags | Hop Count |Routing-MC-Type| 322 | 2 | 0 | 0 | 0 | 6 | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Metric Container | 325 |Res Flags|P|C|O|R| A | Prec | Length (bytes)| Res | 326 | 0 |0|1|0|0| 000 | 000 | 2 | 0x00 | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 |MetricContainer| 329 | Val | Counter | 330 | 2 | 0 | 331 +-+-+-+-+-+-+-+-+ 332 Packet dump of DIS with Hop Count = 0, LQL <= 2 334 5. IANA Considerations 336 5.1. DIS Flag Field 338 IANA is requested to allocate bit O of the DIS Flag Field to become 339 the "Leaf Node" bit, the functionality of which is described in 340 Section 2 of this document. 342 Value Meaning Reference 343 0 Leaf Node This document 345 5.2. RPL Control Message Options 347 IANA is requested to allocate a new code point in the "RPL Control 348 Message Options" registry for the "Response Spreading" option, the 349 behavior of which is described in Section 3.2. 351 +-------+-----------------------+---------------+ 352 | Value | Meaning | Reference | 353 +-------+-----------------------+---------------+ 354 | 0x0A | Response Spreading | This document | 355 +-------+-----------------------+---------------+ 357 RPL Control Message Options 359 6. Security Considerations 361 7. Acknowledgements 363 8. References 365 8.1. Normative references 367 [I-D.ietf-roll-rpl] 368 Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., 369 Kelsey, R., Levis, P., Pister, K., Struik, R., and J. 370 Vasseur, "RPL: IPv6 Routing Protocol for Low power and 371 Lossy Networks", draft-ietf-roll-rpl-18 (work in 372 progress), February 2011. 374 [I-D.ietf-roll-trickle] 375 Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 376 "The Trickle Algorithm", draft-ietf-roll-trickle-08 (work 377 in progress), January 2011. 379 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 380 Requirement Levels", BCP 14, RFC 2119, March 1997. 382 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 383 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 384 May 2008. 386 8.2. Informative references 388 [I-D.ietf-roll-terminology] 389 Vasseur, J., "Terminology in Low power And Lossy 390 Networks", draft-ietf-roll-terminology-04 (work in 391 progress), September 2010. 393 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 394 "Routing Requirements for Urban Low-Power and Lossy 395 Networks", RFC 5548, May 2009. 397 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 398 "Industrial Routing Requirements in Low-Power and Lossy 399 Networks", RFC 5673, October 2009. 401 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 402 Routing Requirements in Low-Power and Lossy Networks", 403 RFC 5826, April 2010. 405 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 406 "Building Automation Routing Requirements in Low-Power and 407 Lossy Networks", RFC 5867, June 2010. 409 Authors' Addresses 411 Nicolas Dejean 412 Elster SAS 413 Espace Concorde, 120 impasse JB Say 414 Perols, 34470 415 France 417 Email: nicolas.dejean@coronis.com 418 Dominique Barthel 419 France Telecom Orange 420 28 chemin du Vieux Chene, BP 98 421 Meylan, 38243 422 France 424 Email: dominique.barthel@orange-ftgroup.com