One document matched: draft-ietf-roll-mpl-parameter-configuration-03.xml
<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc ipr="trust200902" category="std" docName="draft-ietf-roll-mpl-parameter-configuration-03" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
<?rfc toc="yes"?>
<!--generate a table of contents -->
<?rfc symrefs="yes"?>
<!--use anchors instead of numbers for references -->
<?rfc sortrefs="yes" ?>
<!--alphabetize the references -->
<?rfc compact="yes" ?>
<!--conserve vertical whitespace -->
<?rfc subcompact="no" ?>
<!--but keep a blank line between list items -->
<front>
<title abbrev="MPL Conf. for DHCPv6">MPL Parameter Configuration Option for DHCPv6</title>
<author initials="Y." surname="Doi" fullname="Yusuke Doi">
<organization>TOSHIBA Corporation</organization>
<address>
<postal>
<street>Komukai Toshiba Cho 1</street>
<street>Saiwai-Ku</street>
<city>Kawasaki</city>
<region>Kanagawa</region>
<code>2128582</code>
<country>JAPAN</country>
</postal>
<phone>+81-45-342-7230</phone>
<email>yusuke.doi@toshiba.co.jp</email>
<uri/>
</address>
</author>
<author initials="M." surname="Gillmore" fullname="Matthew Gillmore">
<organization>Itron, Inc</organization>
<address>
<postal>
<street>2111 N Molter Rd.</street>
<city>Liberty Lake</city>
<region>WA</region>
<code>99019</code>
<country>USA</country>
</postal>
<email>matthew.gillmore@itron.com</email>
</address>
</author>
<date month="January" year="2015"/>
<area>rtg</area>
<workgroup>roll</workgroup>
<keyword>MPL, DHCPv6</keyword>
<abstract>
<t>This draft defines a way to configure a parameter set of MPL (Multicast Protocol for Low power and Lossy Networks) via DHCPv6 option. MPL has a set of parameters to control its behavior, and the parameter set is often configured as a network-wide parameter because the parameter set should be identical for each MPL forwarder in an MPL domain. Using the MPL Parameter Configuration Option defined in this document, a network can be configured with a single set of MPL parameter easily. </t>
</abstract>
</front>
<middle>
<!--This document was prepared using Pandoc2rfc, https://github.com/miekg/pandoc2rfc -->
<section title="Introduction" anchor="introduction" toc="default">
<t>Multicast Protocol for Low power and Lossy Networks <xref target="I-D.ietf-roll-trickle-mcast" pageno="false" format="default">(MPL)</xref> defines a protocol to make a multicast network among low power and lossy network e.g. wireless mesh networks. MPL has a set of parameters to control an MPL domain. The parameter controls trade-off between end-to-end delay and network utilization. In most environments, the default parameters are acceptable. However, in some environments, the parameter set must be configured carefully in order to meet the requirements of each environment. According to the MPL draft section 5.4, each parameter in the set should be same for all nodes within an MPL domain. And the MPL draft does not define a method to configure the MPL parameter set. </t>
<t>Some managed wireless mesh networks may have a DHCP server to configure network parameters. MPL parameter set shall be considered as a part of network parameters (nodes in an MPL domain should use an identical parameter set). And a parameter set are required to configure an MPL domain. </t>
<t>This document is to define the way to distribute parameter sets for MPL forwarders as a <xref target="RFC3315" pageno="false" format="default">DHCPv6</xref> option. This document is intended to follow <xref target="RFC7227" pageno="false" format="default">the guideline</xref>. </t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119" pageno="false" format="default"/>. </t>
</section>
<section title="MPL Parameter Configuration Option" anchor="mpl-parameter-configuration-option" toc="default">
<t>Per MPL domain, there are following 10 parameters. An MPL domain is defined by an MPL domain address. </t>
<t>
<list style="symbols">
<t>PROACTIVE_FORWARDING </t>
<t>SEED_SET_ENTRY_LIFETIME </t>
<t>DATA_MESSAGE_IMIN </t>
<t>DATA_MESSAGE_IMAX </t>
<t>DATA_MESSAGE_K </t>
<t>DATA_MESSAGE_TIMER_EXPIRATIONS </t>
<t>CONTROL_MESSAGE_IMIN </t>
<t>CONTROL_MESSAGE_IMAX </t>
<t>CONTROL_MESSAGE_K </t>
<t>CONTROL_MESSAGE_TIMER_EXPIRATIONS </t>
</list>
</t>
<t>One network may have multiple MPL domains with different configurations. To configure more than one MPL domain via DHCP, there may be more than one MPL Parameter Configuration Option given to DHCP clients from a DHCP server. </t>
<section title="MPL Parameter Configuration Option Format" anchor="mpl-parameter-configuration-option-format" toc="default">
<t>To distribute a configuration of an MPL domain or a default value for all MPL domains (wildcard) under the network managed by the DHCP server, this document defines a DHCPv6 option format as follows. Short floating point format is used to describe wide range of timer values. </t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_MPL_PARAMETERS | option_len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P| Z | TUNIT | SE_LIFETIME |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DM_K | DM_IMIN | DM_IMAX >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> (cont'ed) | DM_T_EXP | C_K |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C_IMIN | C_IMAX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C_T_EXP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(if option_len = 34 )
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPL Domain Address >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> MPL Domain Address (128bits) >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> (cont'ed) >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> (cont'ed) >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> (cont'ed) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
<list style="hanging">
<t hangText="OPTION_MPL_PARAMETERS:">DHCPv6 option identifier (not yet assigned). </t>
<t hangText="option_len:">Length of the option. It SHOULD be 18 (without MPL domain address) or 34 (with MPL domain address) </t>
<t hangText="P (1 bit):">A flag to indicate PROACTIVE_FORWARDING </t>
<t hangText="Z (7 bits)">Reserved. Should be 0. </t>
<t hangText="TUNIT (unsigned 8 bit integer)">Unit time of times in this option. It SHALL NOT be 0 or 255. </t>
<t hangText="SE_LIFETIME:">SEED_SET_ENTRY_LIFETIME/TUNIT in milliseconds. It SHALL NOT be 0 or 0xffff. </t>
<t hangText="DM_K (unsigned 8 bit integer):">DATA_MESSAGE_K. </t>
<t hangText="DM_IMIN (unsigned 16 bit integer):">DATA_MESSAGE_IMIN/TUNIT in milliseconds. It SHALL NOT be 0 or 0xffff. </t>
<t hangText="DM_IMAX (unsigned 16 bit integer):">DATA_MESSAGE_IMAX/TUNIT in milliseconds. It SHALL NOT be 0 or 0xffff. </t>
<t hangText="DM_T_EXP (unsigned 16 bit integer):">DATA_MESSAGE_TIMER_EXPIRATIONS/TUNIT in milliseconds. It SHALL NOT be 0 or 0xffff. </t>
<t hangText="C_K (unsigned 8 bit integer):">CONTROL_MESSAGE_K. </t>
<t hangText="C_IMIN (unsigned 16 bit integer):">CONTROL_MESSAGE_IMIN/TUNIT in milliseconds. It SHALL NOT be 0 or 0xffff. </t>
<t hangText="C_IMAX:">CONTROL_MESSAGE_IMAX/TUNIT in milliseconds. It SHALL NOT be 0 or 0xffff. </t>
<t hangText="C_T_EXP:">CONTROL_MESSAGE_TIMER_EXPIRATIONS/TUNIT in milliseconds. It SHALL NOT be 0 or 0xffff. </t>
</list>
</t>
<t>Note that all time values (Trickle timers and expiration periods) are in TUNIT milliseconds precision. For example, if TUNIT is 20 and the data message interval minimum (DATA_MESSAGE_IMIN) is 1000ms, then DM_IMIN shall be set to 50. </t>
</section>
<section title="DHCPv6 Client Behavior" anchor="dhcpv6-client-behavior" toc="default">
<t>Clients MAY request MPL Parameter Configuration Option, as described in <xref target="RFC3315" pageno="false" format="default">RFC3315</xref>, sections 17.1.1, 18.1.1, 18.1.3, 18.1.4, 18.1.5 and 22.7. As a convenience to the reader, we mention here that the client includes requested option codes in Option Request Option. </t>
<t>Clients MUST discard MPL Parameter Configuration Option if it is invalid (e.g. it sets reserved bits or it has timers with reserved exp=7 in Unsigned Short Floating Point). </t>
</section>
<section title="MPL Forwarder Behavior" anchor="mpl-forwarder-behavior" toc="default">
<t>If a DHCPv6 client requests and receives MPL Parameter Configuration Option, the node MAY join the MPL domain given by the option and act as an MPL forwarder. Each joining node SHOULD configure its MPL forwarder with the given parameter set for the MPL domain. </t>
<t>The priority of MPL Parameter Configuration applied for an MPL Domain is as follows (high to low). </t>
<t>
<list style="symbols">
<t>Specific MPL Parameter Configuration to the MPL Domain (optlen=34) </t>
<t>Wildcard MPL Parameter Configuration (optlen=18) </t>
<t>Default configuration given in the MPL specification. </t>
</list>
</t>
<t>There SHALL be no more than one MPL Parameter Configuration Option for a MPL domain or the wildcard. Thus, the order of DHCPv6 options in the packet has no effect on precedence. </t>
<t>A node MAY leave from an MPL domain if the following two conditions are satisfied. 1) The MPL domain is configured by a DHCPv6 option from a DHCPv6 server previously. 2) The node has received an updated MPL Parameter Configuration Option without a configuration for the MPL domain. </t>
<t>MPL parameter may be updated occasionally. With stateful DHCPv6, updates can be done when the renewal timer expires. <xref target="RFC4242" pageno="false" format="default">Information Refresh Time Option</xref> shall be used to keep each forwarders updated. </t>
<t>To reduce periodical update traffic a node may try to use very long interval between updates. In the case, reconfigure message may be used to keep forwarder parameter sets synchronized. </t>
</section>
<section title="DHCPv6 Server Behavior" anchor="dhcpv6-server-behavior" toc="default">
<t>Sections 17.2.2 and 18.2 of <xref target="RFC3315" pageno="false" format="default">RFC3315</xref> govern server operation in regards to option assignment. As a convenience to the reader, we mention here that the server will send MPL Parameter Configuration Option only if configured with specific value for MPL Parameter Configuration Option and the client requested it. </t>
<t>Servers SHALL ignore incoming MPL Parameter Configuration Option. </t>
</section>
<section title="DHCPv6 Relay Behavior" anchor="dhcpv6-relay-behavior" toc="default">
<t>It's never appropriate for a relay agent to add options to a message heading toward the client, and relay agents don't actually construct Relay-Reply messages anyway. There are no additional requirements for relays. </t>
</section>
<section title="Operational Considerations" anchor="operational-considerations" toc="default">
<t>A parameter set for an MPL domain SHOULD NOT be updated more often than two times of expected refresh interval. </t>
<t>If a node with MPL forwarder configured by MPL Parameter configuration Option failed to refresh the option for two times of information refresh time, it SHALL suspend the MPL forwarders of MPL domains configured by the option. MPL forwarders configured by other methods such as static configuration file SHALL NOT be suspended. </t>
</section>
</section>
<section title="IANA Considerations" anchor="iana-considerations" toc="default">
<t>A DHCPv6 option code for MPL Parameter Configuration Option needs to be assigned from IANA. </t>
</section>
<section title="Security Considerations" anchor="security-considerations" toc="default">
<t>A forged option may cause excessive layer-2 broadcasting. Implementations should set reasonable bounds for each parameter. For example, not too high K, not too low IMIN, etc. These may be implementation dependent or may be derived from MAC/PHY specifications. DHCP server or the network itself shall be trusted by some means including network access control or DHCP authentications. </t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="Scott Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date year="1997" month="March"/>
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: <list><t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. </t></list></t>
<t>Note that the force of these words is modified by the requirement level of the document in which they are used. </t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<format type="TXT" octets="4723" target="http://www.rfc-editor.org/rfc/rfc2119.txt"/>
<format type="HTML" octets="17491" target="http://xml.resource.org/public/rfc/html/rfc2119.html"/>
<format type="XML" octets="5777" target="http://xml.resource.org/public/rfc/xml/rfc2119.xml"/>
</reference>
<reference anchor="RFC3315">
<front>
<title>Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</title>
<author initials="R." surname="Droms" fullname="R. Droms">
<organization/>
</author>
<author initials="J." surname="Bound" fullname="J. Bound">
<organization/>
</author>
<author initials="B." surname="Volz" fullname="B. Volz">
<organization/>
</author>
<author initials="T." surname="Lemon" fullname="T. Lemon">
<organization/>
</author>
<author initials="C." surname="Perkins" fullname="C. Perkins">
<organization/>
</author>
<author initials="M." surname="Carney" fullname="M. Carney">
<organization/>
</author>
<date year="2003" month="July"/>
</front>
<seriesInfo name="RFC" value="3315"/>
<format type="TXT" octets="231402" target="http://www.rfc-editor.org/rfc/rfc3315.txt"/>
</reference>
<reference anchor="RFC4242">
<front>
<title>Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</title>
<author initials="S." surname="Venaas" fullname="S. Venaas">
<organization/>
</author>
<author initials="T." surname="Chown" fullname="T. Chown">
<organization/>
</author>
<author initials="B." surname="Volz" fullname="B. Volz">
<organization/>
</author>
<date year="2005" month="November"/>
<abstract>
<t>This document describes a Dynamic Host Configuration Protocol for IPv6 (DHCPv6) option for specifying an upper bound for how long a client should wait before refreshing information retrieved from DHCPv6. It is used with stateless DHCPv6 as there are no addresses or other entities with lifetimes that can tell the client when to contact the DHCPv6 server to refresh its configuration. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4242"/>
<format type="TXT" octets="14759" target="http://www.rfc-editor.org/rfc/rfc4242.txt"/>
</reference>
<!--?rfc include="refs/reference.RFC.6282.xml"? -->
<reference anchor="I-D.ietf-roll-trickle-mcast">
<front>
<title>Multicast Forwarding Using Trickle</title>
<author initials="J" surname="Hui" fullname="Jonathan Hui">
<organization/>
</author>
<author initials="R" surname="Kelsey" fullname="Richard Kelsey">
<organization/>
</author>
<date month="November" day="24" year="2014"/>
<abstract>
<t>This document specifies the Multicast Protocol for Low power and Lossy Networks (MPL) that provides IPv6 multicast forwarding in constrained networks. MPL avoids the need to construct or maintain any multicast forwarding topology, disseminating messages to all MPL Forwarders in an MPL Domain. MPL uses the Trickle algorithm to manage message transmissions for both control and data-plane messages. Different Trickle parameter configurations allow MPL to trade between dissemination latency and transmission efficiency. </t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-roll-trickle-mcast-11"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-roll-trickle-mcast-11.txt"/>
</reference>
</references>
<references title="Non-Normative References">
<!--?rfc include="../refs/reference.I-D.draft-jiang-dhc-stateless-reconfiguration-01.xml"? -->
<reference anchor="RFC7227">
<front>
<title>Guidelines for Creating New DHCPv6 Options</title>
<author initials="D." surname="Hankins" fullname="D. Hankins">
<organization/>
</author>
<author initials="T." surname="Mrugalski" fullname="T. Mrugalski">
<organization/>
</author>
<author initials="M." surname="Siodelski" fullname="M. Siodelski">
<organization/>
</author>
<author initials="S." surname="Jiang" fullname="S. Jiang">
<organization/>
</author>
<author initials="S." surname="Krishnan" fullname="S. Krishnan">
<organization/>
</author>
<date year="2014" month="May"/>
<abstract>
<t>This document provides guidance to prospective DHCPv6 option developers to help them create option formats that are easily adoptable by existing DHCPv6 software. It also provides guidelines for expert reviewers to evaluate new registrations. This document updates RFC 3315.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="187"/>
<seriesInfo name="RFC" value="7227"/>
<format type="TXT" octets="83694" target="http://www.rfc-editor.org/rfc/rfc7227.txt"/>
</reference>
</references>
<!--This document was prepared using Pandoc2rfc, https://github.com/miekg/pandoc2rfc -->
<section title="Update History" anchor="update-history" toc="default">
<t>Updates on draft-ietf-roll-mpl-configuration-02 to draft-ietf-roll-mpl-configuration-03: </t>
<t>
<list style="symbols">
<t>References updated </t>
<t>Removed reference for DHCPv6 stateless reconfiguration as it has expired </t>
</list>
</t>
<t>Updates on draft-ietf-roll-mpl-configuration-01 to draft-ietf-roll-mpl-configuration-02: </t>
<t>
<list style="symbols">
<t>Short unsigned floating point is dropped (#159) </t>
<t>Packed value is removed and now every value has its own byte(s) (#159) </t>
</list>
</t>
<t>Updates on draft-ietf-roll-mpl-configuration-00 to draft-ietf-roll-mpl-configuration-01: </t>
<t>
<list style="symbols">
<t>Operational considerations (normative) and appendix considerations (non-normative) are added (Issue #157) </t>
<t>More control on nodes / allow constrained nodes to ignore the configuration: "the node s/SHOULD/MAY/ join the MPL domain given by the option" (Issue #158) </t>
</list>
</t>
<t>Updates on draft-doi-roll-mpl-configuration-05 to draft-ietf-roll-mpl-configuration-00: </t>
<t>
<list style="symbols">
<t>I-D renamed. </t>
</list>
</t>
</section>
<section title="Considerations on Inconsistent Parameter Set" anchor="considerations-on-inconsistent-parameter-set" toc="default">
<t>This draft introduces dynamic update of MPL parameters. Because the update process is not synchronized, nodes may have inconsistent parameter set. </t>
<t>Inconsistent parameter may reduce performance. On the other hand, it shall work as long as both parameter set are reasonable parameter set for a given communication load. As motivations for parameter update are update on environment, node density, or communication load, operators of MPL networks shall be aware of unupdated nodes and make sure old and new parameter sets are reasonable for expected refresh intervals. </t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:34:18 |