idnits 2.17.1 draft-richardson-roll-applicability-template-02.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 20, 2013) is 4083 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 245, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 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 February 20, 2013 5 Expires: August 24, 2013 7 ROLL Applicability Statement Template 8 draft-richardson-roll-applicability-template-02 10 Abstract 12 This document is a template applicability statement for the Routing 13 over Low-power and Lossy Networks (ROLL) WG. 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 http://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 August 24, 2013. 32 Copyright Notice 34 Copyright (c) 2013 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 51 1.2. Required Reading . . . . . . . . . . . . . . . . . . . . . 4 52 1.3. Out of scope requirements . . . . . . . . . . . . . . . . 4 53 2. Deployment Scenario . . . . . . . . . . . . . . . . . . . . . 5 54 2.1. Network Topologies . . . . . . . . . . . . . . . . . . . . 5 55 2.2. Network Topologies . . . . . . . . . . . . . . . . . . . . 5 56 2.2.1. Traffic Characteristics . . . . . . . . . . . . . . . 5 57 2.2.2. General . . . . . . . . . . . . . . . . . . . . . . . 5 58 2.2.3. Source-sink (SS) communication paradigm . . . . . . . 5 59 2.2.4. Publish-subscribe (PS, or pub/sub) communication 60 paradigm . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.2.5. Peer-to-peer (P2P) communication paradigm . . . . . . 5 62 2.2.6. Peer-to-multipeer (P2MP) communication paradigm . . . 5 63 2.2.7. Additional considerations: Duocast and N-cast . . . . 5 64 2.2.8. RPL applicability per communication paradigm . . . . . 5 65 2.3. Layer 2 applicability. . . . . . . . . . . . . . . . . . . 5 66 3. Using RPL to Meet Functional Requirements . . . . . . . . . . 6 67 4. RPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 4.1. RPL Features . . . . . . . . . . . . . . . . . . . . . . . 7 69 4.1.1. RPL Instances . . . . . . . . . . . . . . . . . . . . 7 70 4.1.2. Storing vs. Non-Storing Mode . . . . . . . . . . . . . 7 71 4.1.3. DAO Policy . . . . . . . . . . . . . . . . . . . . . . 7 72 4.1.4. Path Metrics . . . . . . . . . . . . . . . . . . . . . 7 73 4.1.5. Objective Function . . . . . . . . . . . . . . . . . . 7 74 4.1.6. DODAG Repair . . . . . . . . . . . . . . . . . . . . . 7 75 4.1.7. Multicast . . . . . . . . . . . . . . . . . . . . . . 7 76 4.1.8. Security . . . . . . . . . . . . . . . . . . . . . . . 7 77 4.1.9. P2P communications . . . . . . . . . . . . . . . . . . 7 78 4.2. Layer-two features . . . . . . . . . . . . . . . . . . . . 7 79 4.2.1. Need layer-2 expert here. . . . . . . . . . . . . . . 7 80 4.2.2. Security functions provided by layer-2. . . . . . . . 7 81 4.2.3. 6LowPAN options assumed. . . . . . . . . . . . . . . . 7 82 4.2.4. MLE and other things . . . . . . . . . . . . . . . . . 7 83 4.3. Recommended Configuration Defaults and Ranges . . . . . . 7 84 4.3.1. Trickle Parameters . . . . . . . . . . . . . . . . . . 7 85 4.3.2. Other Parameters . . . . . . . . . . . . . . . . . . . 7 86 5. Manageability Considerations . . . . . . . . . . . . . . . . . 8 87 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 88 6.1. Security Considerations during initial deployment . . . . 9 89 6.2. Security Considerations during incremental deployment . . 9 90 7. Other Related Protocols . . . . . . . . . . . . . . . . . . . 10 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 92 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 94 10.1. Informative References . . . . . . . . . . . . . . . . . . 13 95 10.2. Normative References . . . . . . . . . . . . . . . . . . . 13 96 11. Normative references . . . . . . . . . . . . . . . . . . . . . 14 97 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 99 1. Introduction 101 This document is intended to remain as a Internet Draft. 103 The idea is that current and future Applicability statements will use 104 the table of contents provided. The goal is that all applicability 105 statements will have to cover the listed items as a minimum. 107 1.1. Requirements Language 109 (RFC2119 reference) 111 1.2. Required Reading 113 References/Overview of requirements documents, both IETF and industry 114 group. (two pages maximum. This text should be (very) technical, 115 should be aimed at IETF *participants*, not industry group 116 participants, and should explain this industries' specific issues) 118 1.3. Out of scope requirements 120 This should list other documents (if any) which deal with situations 121 where things are not in scope for this document. 123 (For instance, the AMI document tries to cover both line-powered 124 urban metering networks, and energy-constrained metering networks, 125 and also tries to deal with rural requirements. This should be three 126 or four documents, so this section should list the limits of what 127 this document covers) 129 2. Deployment Scenario 131 2.1. Network Topologies 133 describe a single scenario, with possibly multiple topologies that a 134 single utility would employ. 136 2.2. Network Topologies 138 2.2.1. Traffic Characteristics 140 Explain what kind of traffic is being transmitted, where it is 141 initiated, and what kinds of protocols (CoAP, multicast, HTTPS, etc.) 142 are being used. Explain what assumptions are being made about 143 authentication and authorization in those protocols. 145 2.2.2. General 147 2.2.3. Source-sink (SS) communication paradigm 149 2.2.4. Publish-subscribe (PS, or pub/sub) communication paradigm 151 2.2.5. Peer-to-peer (P2P) communication paradigm 153 2.2.6. Peer-to-multipeer (P2MP) communication paradigm 155 2.2.7. Additional considerations: Duocast and N-cast 157 2.2.8. RPL applicability per communication paradigm 159 2.3. Layer 2 applicability. 161 Explain what layer-2 technologies this statement applies to, and if 162 there are options, they should be listed generally here, and 163 specifically in section 4.2. 165 3. Using RPL to Meet Functional Requirements 167 This should explain in general terms how RPL is going to be used in 168 this network topology. If trees that are multiple layers deep are 169 expected, then this should be described so that the fan out is 170 understood. Some sample topologies (from simulations) should be 171 explained, perhaps with images references from other publications. 173 This section should tell an *implementer* in a lab, having a 174 simulation tool or a building/city/etc. to use as a testbed, how to 175 construct an LLN of sufficient complexity (but not too much) to 176 validate an implementation. 178 4. RPL Profile 180 This section should list the various features of RPL plus other 181 layers of the LLN, and how they will be used. 183 4.1. RPL Features 185 4.1.1. RPL Instances 187 4.1.2. Storing vs. Non-Storing Mode 189 4.1.3. DAO Policy 191 4.1.4. Path Metrics 193 4.1.5. Objective Function 195 4.1.6. DODAG Repair 197 4.1.7. Multicast 199 4.1.8. Security 201 4.1.9. P2P communications 203 4.2. Layer-two features 205 4.2.1. Need layer-2 expert here. 207 4.2.2. Security functions provided by layer-2. 209 4.2.3. 6LowPAN options assumed. 211 4.2.4. MLE and other things 213 4.3. Recommended Configuration Defaults and Ranges 215 4.3.1. Trickle Parameters 217 4.3.2. Other Parameters 218 5. Manageability Considerations 219 6. Security Considerations 221 6.1. Security Considerations during initial deployment 223 (This section explains how nodes get their initial trust anchors, 224 initial network keys. It explains if this happens at the factory, in 225 a deployment truck, if it is done in the field, perhaps like http:// 226 www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/papers/ 227 CullenJennings.pdf) 229 6.2. Security Considerations during incremental deployment 231 (This section explains how that replaces a failed node takes on the 232 dead nodes' identity, or not. How are nodes retired. How are nodes 233 removed if they are compromised) 235 7. Other Related Protocols 236 8. IANA Considerations 237 9. Acknowledgements 238 10. References 240 10.1. Informative References 242 10.2. Normative References 243 11. Normative references 245 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 246 Requirement Levels", BCP 14, RFC 2119, March 1997. 248 Author's Address 250 Michael C. Richardson 251 Sandelman Software Works 252 470 Dawson Avenue 253 Ottawa, ON K1Z 5V7 254 CA 256 Email: mcr+ietf@sandelman.ca 257 URI: http://www.sandelman.ca/