idnits 2.17.1 draft-ietf-roll-mpl-parameter-configuration-04.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 (April 22, 2015) is 3291 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) == Outdated reference: A later version (-12) exists of draft-ietf-roll-trickle-mcast-11 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4242 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 roll Y. Doi 3 Internet-Draft TOSHIBA Corporation 4 Intended status: Standards Track M. Gillmore 5 Expires: October 24, 2015 Itron, Inc 6 April 22, 2015 8 MPL Parameter Configuration Option for DHCPv6 9 draft-ietf-roll-mpl-parameter-configuration-04 11 Abstract 13 This draft defines a way to configure a parameter set of MPL 14 (Multicast Protocol for Low power and Lossy Networks) via DHCPv6 15 option. MPL has a set of parameters to control its behavior, and the 16 parameter set is often configured as a network-wide parameter because 17 the parameter set should be identical for each MPL forwarder in an 18 MPL domain. Using the MPL Parameter Configuration Option defined in 19 this document, a network can be configured with a single set of MPL 20 parameter easily. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on October 24, 2015. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. MPL Parameter Configuration Option . . . . . . . . . . . . . 3 58 2.1. MPL Parameter Configuration Option Format . . . . . . . . 3 59 2.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 5 60 2.3. MPL Forwarder Behavior . . . . . . . . . . . . . . . . . 5 61 2.4. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 6 62 2.5. DHCPv6 Relay Behavior . . . . . . . . . . . . . . . . . . 6 63 2.6. Operational Considerations . . . . . . . . . . . . . . . 6 64 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 5.1. Normative References . . . . . . . . . . . . . . . . . . 7 68 5.2. Informative References . . . . . . . . . . . . . . . . . 7 69 Appendix A. Update History . . . . . . . . . . . . . . . . . . . 7 70 Appendix B. Considerations on Inconsistent Parameter Set . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 Multicast Protocol for Low power and Lossy Networks (MPL) 76 [I-D.ietf-roll-trickle-mcast] defines a protocol to make a multicast 77 network among low power and lossy network e.g. wireless mesh 78 networks. MPL has a set of parameters to control an MPL domain. The 79 parameter controls trade-off between end-to-end delay and network 80 utilization. In most environments, the default parameters are 81 acceptable. However, in some environments, the parameter set must be 82 configured carefully in order to meet the requirements of each 83 environment. According to the MPL draft section 5.4, each parameter 84 in the set should be same for all nodes within an MPL domain. And 85 the MPL draft does not define a method to configure the MPL parameter 86 set. 88 Some managed wireless mesh networks may have a DHCP server to 89 configure network parameters. MPL parameter set shall be considered 90 as a part of network parameters (nodes in an MPL domain should use an 91 identical parameter set). And a parameter set are required to 92 configure an MPL domain. 94 This document is to define the way to distribute parameter sets for 95 MPL forwarders as a DHCPv6 [RFC3315] option. This document is 96 intended to follow the guideline [RFC7227]. 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 2. MPL Parameter Configuration Option 104 Per MPL domain, there are following 10 parameters. An MPL domain is 105 defined by an MPL domain address. 107 o PROACTIVE_FORWARDING 109 o SEED_SET_ENTRY_LIFETIME 111 o DATA_MESSAGE_IMIN 113 o DATA_MESSAGE_IMAX 115 o DATA_MESSAGE_K 117 o DATA_MESSAGE_TIMER_EXPIRATIONS 119 o CONTROL_MESSAGE_IMIN 121 o CONTROL_MESSAGE_IMAX 123 o CONTROL_MESSAGE_K 125 o CONTROL_MESSAGE_TIMER_EXPIRATIONS 127 One network may have multiple MPL domains with different 128 configurations. To configure more than one MPL domain via DHCP, 129 there may be more than one MPL Parameter Configuration Option given 130 to DHCP clients from a DHCP server. 132 2.1. MPL Parameter Configuration Option Format 134 To distribute a configuration of an MPL domain or a default value for 135 all MPL domains (wildcard) under the network managed by the DHCP 136 server, this document defines a DHCPv6 option format as follows. 137 Short floating point format is used to describe wide range of timer 138 values. 140 0 1 2 3 141 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 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | OPTION_MPL_PARAMETERS | option_len | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 |P| Z | TUNIT | SE_LIFETIME | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | DM_K | DM_IMIN | DM_IMAX > 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 > (cont'ed) | DM_T_EXP | C_K | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | C_IMIN | C_IMAX | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | C_T_EXP | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 (if option_len = 34 ) 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | MPL Domain Address > 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 > MPL Domain Address (128bits) > 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 > (cont'ed) > 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 > (cont'ed) > 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 > (cont'ed) | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 OPTION_MPL_PARAMETERS: DHCPv6 option identifier (not yet assigned). 171 option_len: Length of the option. It SHOULD be 18 (without MPL 172 domain address) or 34 (with MPL domain address) 174 P (1 bit): A flag to indicate PROACTIVE_FORWARDING 176 Z (7 bits) Reserved. Should be 0. 178 TUNIT (unsigned 8 bit integer) Unit time of times in this option. 0 179 and 0xff are reserved and SHALL NOT be used. 181 SE_LIFETIME: SEED_SET_ENTRY_LIFETIME/TUNIT in milliseconds. 0 and 182 0xffff are reserved and SHALL NOT be used. 184 DM_K (unsigned 8 bit integer): DATA_MESSAGE_K. 186 DM_IMIN (unsigned 16 bit integer): DATA_MESSAGE_IMIN/TUNIT in 187 milliseconds. 0 and 0xffff are reserved and SHALL NOT be used. 189 DM_IMAX (unsigned 16 bit integer): DATA_MESSAGE_IMAX/TUNIT in 190 milliseconds. 0 and 0xffff are reserved and SHALL NOT be used. 192 DM_T_EXP (unsigned 16 bit integer): DATA_MESSAGE_TIMER_EXPIRATIONS/ 193 TUNIT in milliseconds. 0 and 0xffff are reserved and SHALL NOT be 194 used. 196 C_K (unsigned 8 bit integer): CONTROL_MESSAGE_K. 198 C_IMIN (unsigned 16 bit integer): CONTROL_MESSAGE_IMIN/TUNIT in 199 milliseconds. 0 and 0xffff are reserved and SHALL NOT be used. 201 C_IMAX: CONTROL_MESSAGE_IMAX/TUNIT in milliseconds. 0 and 0xffff are 202 reserved and SHALL NOT be used. 204 C_T_EXP: CONTROL_MESSAGE_TIMER_EXPIRATIONS/TUNIT in milliseconds. 0 205 and 0xffff are reserved and SHALL NOT be used. 207 Note that all time values (Trickle timers and expiration periods) are 208 in TUNIT milliseconds precision. For example, if TUNIT is 20 and the 209 data message interval minimum (DATA_MESSAGE_IMIN) is 1000ms, then 210 DM_IMIN shall be set to 50. 212 2.2. DHCPv6 Client Behavior 214 Clients MAY request MPL Parameter Configuration Option, as described 215 in RFC3315 [RFC3315], sections 17.1.1, 18.1.1, 18.1.3, 18.1.4, 18.1.5 216 and 22.7. As a convenience to the reader, we mention here that the 217 client includes requested option codes in Option Request Option. 219 Clients MUST discard MPL Parameter Configuration Option if it is 220 invalid (e.g. it sets reserved bits or it has timers with reserved 221 exp=7 in Unsigned Short Floating Point). 223 2.3. MPL Forwarder Behavior 225 If a DHCPv6 client requests and receives MPL Parameter Configuration 226 Option, the node MAY join the MPL domain given by the option and act 227 as an MPL forwarder. Each joining node SHOULD configure its MPL 228 forwarder with the given parameter set for the MPL domain. 230 The priority of MPL Parameter Configuration applied for an MPL Domain 231 is as follows (high to low). 233 o Specific MPL Parameter Configuration to the MPL Domain (optlen=34) 235 o Wildcard MPL Parameter Configuration (optlen=18) 237 o Default configuration given in the MPL specification. 239 There SHALL be no more than one MPL Parameter Configuration Option 240 for a MPL domain or the wildcard. Thus, the order of DHCPv6 options 241 in the packet has no effect on precedence. 243 A node MAY leave from an MPL domain if the following two conditions 244 are satisfied. 1) The MPL domain is configured by a DHCPv6 option 245 from a DHCPv6 server previously. 2) The node has received an updated 246 MPL Parameter Configuration Option without a configuration for the 247 MPL domain. 249 MPL parameter may be updated occasionally. With stateful DHCPv6, 250 updates can be done when the renewal timer expires. Information 251 Refresh Time Option [RFC4242] shall be used to keep each forwarders 252 updated. 254 To reduce periodical update traffic a node may try to use very long 255 interval between updates. In the case, reconfigure message may be 256 used to keep forwarder parameter sets synchronized. 258 2.4. DHCPv6 Server Behavior 260 Sections 17.2.2 and 18.2 of RFC3315 [RFC3315] govern server operation 261 in regards to option assignment. As a convenience to the reader, we 262 mention here that the server will send MPL Parameter Configuration 263 Option only if configured with specific value for MPL Parameter 264 Configuration Option and the client requested it. 266 Servers SHALL ignore incoming MPL Parameter Configuration Option. 268 2.5. DHCPv6 Relay Behavior 270 It's never appropriate for a relay agent to add options to a message 271 heading toward the client, and relay agents don't actually construct 272 Relay-Reply messages anyway. There are no additional requirements 273 for relays. 275 2.6. Operational Considerations 277 A parameter set for an MPL domain SHOULD NOT be updated more often 278 than two times of expected refresh interval. 280 If a node with MPL forwarder configured by MPL Parameter 281 configuration Option failed to refresh the option for two times of 282 information refresh time, it SHALL suspend the MPL forwarders of MPL 283 domains configured by the option. MPL forwarders configured by other 284 methods such as static configuration file SHALL NOT be suspended. 286 3. IANA Considerations 288 IANA is requested to assign one option code for OPTION_MPL_PARAMETERS 289 from the "DHCP Option Codes" table of the Dynamic Host Configuration 290 Protocol for IPv6 (DHCPv6) Registry. 292 4. Security Considerations 294 A forged option may cause excessive layer-2 broadcasting. 295 Implementations should set reasonable bounds for each parameter. For 296 example, not too high K, not too low IMIN, etc. These may be 297 implementation dependent or may be derived from MAC/PHY 298 specifications. DHCP server or the network itself shall be trusted 299 by some means including network access control or DHCP 300 authentications. 302 5. References 304 5.1. Normative References 306 [I-D.ietf-roll-trickle-mcast] 307 Hui, J. and R. Kelsey, "Multicast Forwarding Using 308 Trickle", draft-ietf-roll-trickle-mcast-11 (work in 309 progress), November 2014. 311 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 312 Requirement Levels", BCP 14, RFC 2119, March 1997. 314 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 315 and M. Carney, "Dynamic Host Configuration Protocol for 316 IPv6 (DHCPv6)", RFC 3315, July 2003. 318 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 319 Time Option for Dynamic Host Configuration Protocol for 320 IPv6 (DHCPv6)", RFC 4242, November 2005. 322 5.2. Informative References 324 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 325 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 326 BCP 187, RFC 7227, May 2014. 328 Appendix A. Update History 330 Updates on draft-ietf-roll-mpl-configuration-03 to draft-ietf-roll- 331 mpl-configuration-04: 333 o References updated (Non-normative -> Informative) 334 o IANA section is updated to make clear request of option ID 336 o Typo fixed 338 Updates on draft-ietf-roll-mpl-configuration-02 to draft-ietf-roll- 339 mpl-configuration-03: 341 o References updated 343 o Removed reference for DHCPv6 stateless reconfiguration as it has 344 expired 346 Updates on draft-ietf-roll-mpl-configuration-01 to draft-ietf-roll- 347 mpl-configuration-02: 349 o Short unsigned floating point is dropped (#159) 351 o Packed value is removed and now every value has its own byte(s) 352 (#159) 354 Updates on draft-ietf-roll-mpl-configuration-00 to draft-ietf-roll- 355 mpl-configuration-01: 357 o Operational considerations (normative) and appendix considerations 358 (non-normative) are added (Issue #157) 360 o More control on nodes / allow constrained nodes to ignore the 361 configuration: "the node s/SHOULD/MAY/ join the MPL domain given 362 by the option" (Issue #158) 364 Updates on draft-doi-roll-mpl-configuration-05 to draft-ietf-roll- 365 mpl-configuration-00: 367 o I-D renamed. 369 Appendix B. Considerations on Inconsistent Parameter Set 371 This draft introduces dynamic update of MPL parameters. Because the 372 update process is not synchronized, nodes may have inconsistent 373 parameter set. 375 Inconsistent parameter may reduce performance. On the other hand, it 376 shall work as long as both parameter set are reasonable parameter set 377 for a given communication load. As motivations for parameter update 378 are update on environment, node density, or communication load, 379 operators of MPL networks shall be aware of unupdated nodes and make 380 sure old and new parameter sets are reasonable for expected refresh 381 intervals. 383 Authors' Addresses 385 Yusuke Doi 386 TOSHIBA Corporation 387 Komukai Toshiba Cho 1 388 Saiwai-Ku 389 Kawasaki, Kanagawa 2128582 390 JAPAN 392 Phone: +81-45-342-7230 393 Email: yusuke.doi@toshiba.co.jp 395 Matthew Gillmore 396 Itron, Inc 397 2111 N Molter Rd. 398 Liberty Lake, WA 99019 399 USA 401 Email: matthew.gillmore@itron.com