idnits 2.17.1 draft-ietf-roll-applicability-template-08.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 (November 3, 2015) is 3068 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 390, but no explicit reference was found in the text == Unused Reference: 'RFC6206' is defined on line 404, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-roll-security-threats-06 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Richardson 3 Internet-Draft SSW 4 Intended status: Informational November 3, 2015 5 Expires: May 6, 2016 7 ROLL Applicability Statement Template 8 draft-ietf-roll-applicability-template-08 10 Abstract 12 This document is a template applicability statement for the Routing 13 over Low-power and Lossy Networks (ROLL) WG. This document is not 14 for publication, but rather is to be used as a template. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on May 6, 2016. 33 Copyright Notice 35 Copyright (c) 2015 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Relationship to other documents . . . . . . . . . . . . . 3 52 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 53 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 54 1.4. Required Reading . . . . . . . . . . . . . . . . . . . . 4 55 1.5. Out of scope requirements . . . . . . . . . . . . . . . . 4 56 2. Deployment Scenario . . . . . . . . . . . . . . . . . . . . . 4 57 2.1. Network Topologies . . . . . . . . . . . . . . . . . . . 4 58 2.2. Traffic Characteristics . . . . . . . . . . . . . . . . . 4 59 2.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.2.2. Source-sink (SS) communication paradigm . . . . . . . 5 61 2.2.3. Publish-subscribe (PS, or pub/sub) communication 62 paradigm . . . . . . . . . . . . . . . . . . . . . . 5 63 2.2.4. Peer-to-peer (P2P) communication paradigm . . . . . . 5 64 2.2.5. Peer-to-multipeer (P2MP) communication paradigm . . . 5 65 2.2.6. Additional considerations: Duocast and N-cast . . . . 5 66 2.2.7. RPL applicability per communication paradigm . . . . 5 67 2.3. Layer-2 applicability. . . . . . . . . . . . . . . . . . 5 68 3. Using RPL to Meet Functional Requirements . . . . . . . . . . 5 69 4. RPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 4.1. RPL Features . . . . . . . . . . . . . . . . . . . . . . 5 71 4.1.1. RPL Instances . . . . . . . . . . . . . . . . . . . . 5 72 4.1.2. Storing vs. Non-Storing Mode . . . . . . . . . . . . 5 73 4.1.3. DAO Policy . . . . . . . . . . . . . . . . . . . . . 5 74 4.1.4. Path Metrics . . . . . . . . . . . . . . . . . . . . 6 75 4.1.5. Objective Function . . . . . . . . . . . . . . . . . 6 76 4.1.6. DODAG Repair . . . . . . . . . . . . . . . . . . . . 6 77 4.1.7. Multicast . . . . . . . . . . . . . . . . . . . . . . 6 78 4.1.8. Security . . . . . . . . . . . . . . . . . . . . . . 6 79 4.1.9. P2P communications . . . . . . . . . . . . . . . . . 6 80 4.1.10. IPv6 address configuration . . . . . . . . . . . . . 6 81 4.2. Layer-2 features . . . . . . . . . . . . . . . . . . . . 6 82 4.2.1. Specifics about layer-2 . . . . . . . . . . . . . . . 6 83 4.2.2. Services provided at layer-2 . . . . . . . . . . . . 6 84 4.2.3. 6LowPAN options assumed. . . . . . . . . . . . . . . 6 85 4.2.4. MLE and other things . . . . . . . . . . . . . . . . 6 86 4.3. Recommended Configuration Defaults and Ranges . . . . . . 6 87 4.3.1. Trickle Parameters . . . . . . . . . . . . . . . . . 6 88 4.3.2. Other Parameters . . . . . . . . . . . . . . . . . . 6 89 5. MPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 7 90 5.1. Recommended Configuration Defaults and Ranges . . . . . . 8 91 5.1.1. Trickle Parameters . . . . . . . . . . . . . . . . . 8 92 5.1.2. Other Parameters . . . . . . . . . . . . . . . . . . 8 93 6. Manageability Considerations . . . . . . . . . . . . . . . . 8 94 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 95 7.1. Security Considerations during initial deployment . . . . 8 96 7.2. Security Considerations during incremental deployment . . 8 97 7.3. Security Considerations for P2P uses . . . . . . . . . . 8 98 8. Other Related Protocols . . . . . . . . . . . . . . . . . . . 9 99 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 100 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 101 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 102 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 103 11.2. Informative References . . . . . . . . . . . . . . . . . 9 104 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 106 1. Introduction 108 This document describes a series of questions which should be 109 answered. This document is intended to remain as a Internet Draft. 111 The idea is that current and future Applicability statements will use 112 the table of contents provided. The goal is that all applicability 113 statements will have to cover the listed items as a minimum. 115 1.1. Relationship to other documents 117 EDITORIAL: The following should appear in all applicability 118 statements: 120 ROLL has specified a set of routing protocols for Lossy and Low- 121 resource Networks (LLN) [RFC6550]. This applicability text describes 122 a subset of these protocols and the conditions which make the subset 123 the correct choice. The text recommends and motivates the 124 accompanying parameter value ranges. Multiple applicability domains 125 are recognized including: Building and Home, and Advanced Metering 126 Infrastructure. The applicability domains distinguish themselves in 127 the way they are operated, their performance requirements, and the 128 most probable network structures. Each applicability statement 129 identifies the distinguishing properties according to a common set of 130 subjects described in as many sections. 132 A common set of security threats are described in 133 [I-D.ietf-roll-security-threats]. The applicability statements 134 complement the security threats document by describing preferred 135 security settings and solutions within the applicability statement 136 conditions. This applicability statements may recommend more light 137 weight security solutions and specify the conditions under which 138 these solutions are appropriate. 140 1.2. Requirements Language 142 (RFC2119 reference) 144 1.3. Terminology 146 A reference to draft-ietf-roll-terminology is appropriate. A 147 reference to layer-2 specific terminology and/or inclusion of any 148 terms that are normatively referenced is appropriate here. 150 1.4. Required Reading 152 References/Overview of requirements documents, both IETF and industry 153 group. (two pages maximum. This text should be (very) technical, 154 should be aimed at IETF *participants*, not industry group 155 participants, and should explain this industries' specific issues) 157 1.5. Out of scope requirements 159 This should list other documents (if any) which deal with situations 160 where things are not in scope for this document. 162 (For instance, the AMI document tries to cover both line-powered 163 urban metering networks, and energy-constrained metering networks, 164 and also tries to deal with rural requirements. This should be three 165 or four documents, so this section should list the limits of what 166 this document covers) 168 2. Deployment Scenario 170 2.1. Network Topologies 172 describe a single scenario, with possibly multiple topologies that a 173 single utility would employ. 175 2.2. Traffic Characteristics 177 Explain what kind of traffic is being transmitted, where it is 178 initiated, and what kinds of protocols (CoAP, multicast, HTTPS, etc.) 179 are being used. Explain what assumptions are being made about 180 authentication and authorization in those protocols. 182 2.2.1. General 183 2.2.2. Source-sink (SS) communication paradigm 185 2.2.3. Publish-subscribe (PS, or pub/sub) communication paradigm 187 2.2.4. Peer-to-peer (P2P) communication paradigm 189 2.2.5. Peer-to-multipeer (P2MP) communication paradigm 191 2.2.6. Additional considerations: Duocast and N-cast 193 2.2.7. RPL applicability per communication paradigm 195 2.3. Layer-2 applicability. 197 Explain what layer-2 technologies this statement applies to, and if 198 there are options, they should be listed generally here, and 199 specifically in section 4.2. 201 3. Using RPL to Meet Functional Requirements 203 This should explain in general terms how RPL is going to be used in 204 this network topology. If trees that are multiple layers deep are 205 expected, then this should be described so that the fan out is 206 understood. Some sample topologies (from simulations) should be 207 explained, perhaps with images references from other publications. 209 This section should tell an *implementer* in a lab, having a 210 simulation tool or a building/city/etc. to use as a testbed, how to 211 construct an LLN of sufficient complexity (but not too much) to 212 validate an implementation. 214 4. RPL Profile 216 This section should list the various features of RPL plus other 217 layers of the LLN, and how they will be used. 219 4.1. RPL Features 221 4.1.1. RPL Instances 223 4.1.2. Storing vs. Non-Storing Mode 225 4.1.3. DAO Policy 226 4.1.4. Path Metrics 228 4.1.5. Objective Function 230 4.1.6. DODAG Repair 232 4.1.7. Multicast 234 4.1.8. Security 236 4.1.9. P2P communications 238 4.1.10. IPv6 address configuration 240 4.2. Layer-2 features 242 4.2.1. Specifics about layer-2 244 this section should detail the specific layer-2 network technology 245 that this document applies to. A class of technologies is generally 246 not acceptable. 248 4.2.2. Services provided at layer-2 250 4.2.3. 6LowPAN options assumed. 252 4.2.4. MLE and other things 254 4.3. Recommended Configuration Defaults and Ranges 256 4.3.1. Trickle Parameters 258 This section is intended to document the specific value (or ranges) 259 appropriate for this kind of deployment. This includes trickle 260 specific parameters such as those of RFC6550, section 8.3.1: Imin 261 (DIOInternvalMin), Imax (DIOIntrevalDoublings), and k 262 (DIORedundancyConstant). While it is not necessary to hard code 263 these parameters into RPL nodes, as they are announced as part of the 264 DIO message, it is important for researchers who are trying to 265 validate the convergence properties of the resulting deployment to 266 understand what values have been selected. 268 4.3.2. Other Parameters 270 There are additional values which are present in the DODAG 271 Configuration option. The purpose of this section is to: a) document 272 what values are configured, b) if a default value is used, if it is 273 appropriate for this deployment. 275 These values include: MaxRankIncrease, MinHopRankIncrease, the 276 Objective Code Point to use, Default Lifetime, Lifetime Units... 278 In addition, the kinds of metrics which will be used (RFC6551) needs 279 to be specified. If Objective Function 0 (RFC6552) is used, then it 280 specifies a number of values, but also needs definitions of the 281 stretch_of_rank, and rank_factor. 283 If MRHOF (RFC6719) is used, then section 5 of this document requires 284 selection of: MAX_LINK_METRIC, MAX_PATH_COST, 285 PARENT_SWITCH_THRESHOLD, PARENT_SET_SIZE, and ALLOW_FLOATING_ROOT. 287 5. MPL Profile 289 This section should list the various features of MPL. In considering 290 the parameters, a number of questions come up: 292 1) What are the maximum and minimum 1-hop MPL router neighbours of 293 all the MPL routers? 295 2) what is the arrival rate of new packets that need repetition in 296 a MPL router 298 3) Is there a deadline associated with the packets 300 4) What is the shortest number of hops of the longest path between 301 sources and destinations 303 5) What are the values of the MAC: back-off values, retries, 304 buffer size. 306 6) What is the background load of other non MPL applications. 308 7) arrival probability of 1-hop packets 310 As the corresponding design space is incredibly large, probably only 311 a limited subset of the design space is viable. 313 Here is an example scenario: 315 o 5 neighbours 317 o once every 100 ms (rate at sources is once every 300-500 ms) 319 o yes, 200 ms 321 o 5 hops, with mostly 1 hop 322 o no buffer, retry 1, back-off 2 324 o absent 326 o 100-80% 328 leading to k=3-5, Imin =30-70 ms, repeat = 2, Imax n/a. 330 It is crital operational boundary conditions together with 331 appropriate MPL parameter values are published in this applicability 332 statements. All applicability statements together may give a good 333 hint which MPL parameters and boundary conditions to choose. 335 5.1. Recommended Configuration Defaults and Ranges 337 5.1.1. Trickle Parameters 339 5.1.1.1. Imin 341 5.1.1.2. Imax 343 5.1.2. Other Parameters 345 5.1.2.1. Hot Limit 347 6. Manageability Considerations 349 7. Security Considerations 351 7.1. Security Considerations during initial deployment 353 (This section explains how nodes get their initial trust anchors, 354 initial network keys. It explains if this happens at the factory, in 355 a deployment truck, if it is done in the field, perhaps like 356 http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/papers/ 357 CullenJennings.pdf) 359 7.2. Security Considerations during incremental deployment 361 (This section explains how that replaces a failed node takes on the 362 dead nodes' identity, or not. How are nodes retired. How are nodes 363 removed if they are compromised) 365 7.3. Security Considerations for P2P uses 367 (When layer-3 RPL security is used, P2P DODAGs are ephemeral, and may 368 have different security needs.) 370 8. Other Related Protocols 372 9. IANA Considerations 374 10. Acknowledgements 376 This document was created from a number source applicatbility 377 templates, including draft-ietf-roll-applicability-ami-06.txt, draft- 378 phinney-rpl-industrial-applicability-00.txt. 380 The document has benefitted from advance review by the IETF Security 381 Directorate. 383 A number of edits were contributed from Peter van der Stok, including 384 the MPL considerations/calculations 386 11. References 388 11.1. Normative References 390 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 391 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 392 RFC2119, March 1997, 393 . 395 [I-D.ietf-roll-security-threats] 396 Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 397 and M. Richardson, "A Security Threat Analysis for Routing 398 Protocol for Low-power and lossy networks (RPL)", draft- 399 ietf-roll-security-threats-06 (work in progress), December 400 2013. 402 11.2. Informative References 404 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 405 "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, 406 March 2011, . 408 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 409 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 410 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 411 Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/ 412 RFC6550, March 2012, 413 . 415 Author's Address 417 Michael C. Richardson 418 Sandelman Software Works 419 470 Dawson Avenue 420 Ottawa, ON K1Z 5V7 421 CA 423 Email: mcr+ietf@sandelman.ca 424 URI: http://www.sandelman.ca/