idnits 2.17.1 draft-ietf-roll-mpl-parameter-configuration-03.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 (January 21, 2015) is 3383 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: July 25, 2015 Itron, Inc 6 January 21, 2015 8 MPL Parameter Configuration Option for DHCPv6 9 draft-ietf-roll-mpl-parameter-configuration-03 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 July 25, 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. Non-Normative References . . . . . . . . . . . . . . . . 7 69 Appendix A. Update History . . . . . . . . . . . . . . . . . . . 7 70 Appendix B. Considerations on Inconsistent Parameter Set . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 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. 179 It SHALL NOT be 0 or 255. 181 SE_LIFETIME: SEED_SET_ENTRY_LIFETIME/TUNIT in milliseconds. It 182 SHALL NOT be 0 or 0xffff. 184 DM_K (unsigned 8 bit integer): DATA_MESSAGE_K. 186 DM_IMIN (unsigned 16 bit integer): DATA_MESSAGE_IMIN/TUNIT in 187 milliseconds. It SHALL NOT be 0 or 0xffff. 189 DM_IMAX (unsigned 16 bit integer): DATA_MESSAGE_IMAX/TUNIT in 190 milliseconds. It SHALL NOT be 0 or 0xffff. 192 DM_T_EXP (unsigned 16 bit integer): DATA_MESSAGE_TIMER_EXPIRATIONS/ 193 TUNIT in milliseconds. It SHALL NOT be 0 or 0xffff. 195 C_K (unsigned 8 bit integer): CONTROL_MESSAGE_K. 197 C_IMIN (unsigned 16 bit integer): CONTROL_MESSAGE_IMIN/TUNIT in 198 milliseconds. It SHALL NOT be 0 or 0xffff. 200 C_IMAX: CONTROL_MESSAGE_IMAX/TUNIT in milliseconds. It SHALL NOT be 201 0 or 0xffff. 203 C_T_EXP: CONTROL_MESSAGE_TIMER_EXPIRATIONS/TUNIT in milliseconds. 204 It SHALL NOT be 0 or 0xffff. 206 Note that all time values (Trickle timers and expiration periods) are 207 in TUNIT milliseconds precision. For example, if TUNIT is 20 and the 208 data message interval minimum (DATA_MESSAGE_IMIN) is 1000ms, then 209 DM_IMIN shall be set to 50. 211 2.2. DHCPv6 Client Behavior 213 Clients MAY request MPL Parameter Configuration Option, as described 214 in RFC3315 [RFC3315], sections 17.1.1, 18.1.1, 18.1.3, 18.1.4, 18.1.5 215 and 22.7. As a convenience to the reader, we mention here that the 216 client includes requested option codes in Option Request Option. 218 Clients MUST discard MPL Parameter Configuration Option if it is 219 invalid (e.g. it sets reserved bits or it has timers with reserved 220 exp=7 in Unsigned Short Floating Point). 222 2.3. MPL Forwarder Behavior 224 If a DHCPv6 client requests and receives MPL Parameter Configuration 225 Option, the node MAY join the MPL domain given by the option and act 226 as an MPL forwarder. Each joining node SHOULD configure its MPL 227 forwarder with the given parameter set for the MPL domain. 229 The priority of MPL Parameter Configuration applied for an MPL Domain 230 is as follows (high to low). 232 o Specific MPL Parameter Configuration to the MPL Domain (optlen=34) 234 o Wildcard MPL Parameter Configuration (optlen=18) 236 o Default configuration given in the MPL specification. 238 There SHALL be no more than one MPL Parameter Configuration Option 239 for a MPL domain or the wildcard. Thus, the order of DHCPv6 options 240 in the packet has no effect on precedence. 242 A node MAY leave from an MPL domain if the following two conditions 243 are satisfied. 1) The MPL domain is configured by a DHCPv6 option 244 from a DHCPv6 server previously. 2) The node has received an updated 245 MPL Parameter Configuration Option without a configuration for the 246 MPL domain. 248 MPL parameter may be updated occasionally. With stateful DHCPv6, 249 updates can be done when the renewal timer expires. Information 250 Refresh Time Option [RFC4242] shall be used to keep each forwarders 251 updated. 253 To reduce periodical update traffic a node may try to use very long 254 interval between updates. In the case, reconfigure message may be 255 used to keep forwarder parameter sets synchronized. 257 2.4. DHCPv6 Server Behavior 259 Sections 17.2.2 and 18.2 of RFC3315 [RFC3315] govern server operation 260 in regards to option assignment. As a convenience to the reader, we 261 mention here that the server will send MPL Parameter Configuration 262 Option only if configured with specific value for MPL Parameter 263 Configuration Option and the client requested it. 265 Servers SHALL ignore incoming MPL Parameter Configuration Option. 267 2.5. DHCPv6 Relay Behavior 269 It's never appropriate for a relay agent to add options to a message 270 heading toward the client, and relay agents don't actually construct 271 Relay-Reply messages anyway. There are no additional requirements 272 for relays. 274 2.6. Operational Considerations 276 A parameter set for an MPL domain SHOULD NOT be updated more often 277 than two times of expected refresh interval. 279 If a node with MPL forwarder configured by MPL Parameter 280 configuration Option failed to refresh the option for two times of 281 information refresh time, it SHALL suspend the MPL forwarders of MPL 282 domains configured by the option. MPL forwarders configured by other 283 methods such as static configuration file SHALL NOT be suspended. 285 3. IANA Considerations 287 A DHCPv6 option code for MPL Parameter Configuration Option needs to 288 be assigned from IANA. 290 4. Security Considerations 292 A forged option may cause excessive layer-2 broadcasting. 293 Implementations should set reasonable bounds for each parameter. For 294 example, not too high K, not too low IMIN, etc. These may be 295 implementation dependent or may be derived from MAC/PHY 296 specifications. DHCP server or the network itself shall be trusted 297 by some means including network access control or DHCP 298 authentications. 300 5. References 302 5.1. Normative References 304 [I-D.ietf-roll-trickle-mcast] 305 Hui, J. and R. Kelsey, "Multicast Forwarding Using 306 Trickle", draft-ietf-roll-trickle-mcast-11 (work in 307 progress), November 2014. 309 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 310 Requirement Levels", BCP 14, RFC 2119, March 1997. 312 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 313 and M. Carney, "Dynamic Host Configuration Protocol for 314 IPv6 (DHCPv6)", RFC 3315, July 2003. 316 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 317 Time Option for Dynamic Host Configuration Protocol for 318 IPv6 (DHCPv6)", RFC 4242, November 2005. 320 5.2. Non-Normative References 322 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 323 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 324 BCP 187, RFC 7227, May 2014. 326 Appendix A. Update History 328 Updates on draft-ietf-roll-mpl-configuration-02 to draft-ietf-roll- 329 mpl-configuration-03: 331 o References updated 332 o Removed reference for DHCPv6 stateless reconfiguration as it has 333 expired 335 Updates on draft-ietf-roll-mpl-configuration-01 to draft-ietf-roll- 336 mpl-configuration-02: 338 o Short unsigned floating point is dropped (#159) 340 o Packed value is removed and now every value has its own byte(s) 341 (#159) 343 Updates on draft-ietf-roll-mpl-configuration-00 to draft-ietf-roll- 344 mpl-configuration-01: 346 o Operational considerations (normative) and appendix considerations 347 (non-normative) are added (Issue #157) 349 o More control on nodes / allow constrained nodes to ignore the 350 configuration: "the node s/SHOULD/MAY/ join the MPL domain given 351 by the option" (Issue #158) 353 Updates on draft-doi-roll-mpl-configuration-05 to draft-ietf-roll- 354 mpl-configuration-00: 356 o I-D renamed. 358 Appendix B. Considerations on Inconsistent Parameter Set 360 This draft introduces dynamic update of MPL parameters. Because the 361 update process is not synchronized, nodes may have inconsistent 362 parameter set. 364 Inconsistent parameter may reduce performance. On the other hand, it 365 shall work as long as both parameter set are reasonable parameter set 366 for a given communication load. As motivations for parameter update 367 are update on environment, node density, or communication load, 368 operators of MPL networks shall be aware of unupdated nodes and make 369 sure old and new parameter sets are reasonable for expected refresh 370 intervals. 372 Authors' Addresses 373 Yusuke Doi 374 TOSHIBA Corporation 375 Komukai Toshiba Cho 1 376 Saiwai-Ku 377 Kawasaki, Kanagawa 2128582 378 JAPAN 380 Phone: +81-45-342-7230 381 Email: yusuke.doi@toshiba.co.jp 383 Matthew Gillmore 384 Itron, Inc 385 2111 N Molter Rd. 386 Liberty Lake, WA 99019 387 USA 389 Email: matthew.gillmore@itron.com