<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'[
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4291 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml">
<!ENTITY RFC5614 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5614.xml">
<!ENTITY RFC6206 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6206.xml">
<!ENTITY RFC6130 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6130.xml">
<!ENTITY RFC6621 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6621.xml">
<!ENTITY RFC7049 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7049.xml">
<!ENTITY RFC7731 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7731.xml">
]>

<?rfc toc="yes"?>
<?rfc symrefs="yes" ?>

<rfc category="std" ipr="trust200902" docName="draft-vanderstok-roll-mpl-forw-select-00">
  <front>
    <title abbrev="MPLFS">MPL Forwarder Select (MPLFS)</title>

    <author initials="P." surname="van der Stok" fullname="Peter van der Stok">
      <organization abbrev="consultant">consultant</organization>
      <address>
        <phone>+31-492474673 (Netherlands), +33-966015248 (France)</phone>
        <email>consultancy@vanderstok.org</email>
        <uri>www.vanderstok.org</uri>
      </address>
    </author>
	
    <author fullname="Abdur Rashid Sangi" initials="AR." surname="Sangi">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street>No.156 Beiqing Rd. Haidian District</street>

          <!-- Reorder these if your country does things differently -->

          <city>Beijing</city>

          <region/>

          <code>100095</code>

          <country>P.R. China</country>
        </postal>

        <phone/>

        <email>rashid.sangi@huawei.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>	

    <date />
    <area>Routing</area>
    <workgroup>roll</workgroup>
    <abstract>
      <t>
        This document describes a Forwarder Selection (MPLFS) protocol for the Multicast Protocol for Low-Power and lossy Networks (MPL) to reduce the density of forwarders such that the number of forwarded messages is reduced.
The protocol uses Trickle to distribute link-local information about the identity of the neighbours of the nodes which are enabled for MPL. In the end-state all nodes are connected to a minimum number, N_DUPLICATE, of forwarders, where N_DUPLICATE is application dependent.
        
      </t>
    </abstract>
    <note title="Note">
      <t>
        Discussion and suggestions for improvement are requested,
        and should be sent to roll@ietf.org.
      </t>
    </note>
  </front>
  <middle>

<section anchor="introduction" title="Introduction">
<t>
The Multicast Protocol for Low-Power and Lossy Networks (MPL) <xref target="RFC7731"/> is designed for small devices interconnected by a lossy wireless network such as IEEE 802.15.4. A seed sends a multicast message with a realm-local scope, admin-local scope or higher <xref target="RFC4291"/>.
</t>
<t>
Forwarders forward these messages with an increasing interval size. When the density of forwarders is high, the message may be forwarded for a possibly unacceptable number of times. With extreme forwarder densities and small Trickle intervals, just sending one multicast message may lead to an overload of the communication medium.
</t><t>
The number of forwarded messages can be reduced by selecting a minimal set of forwarders. However, for large networks, manually selecting the forwarders is much work, and changing network conditions and configurations make the manual selection an unwanted burden to the network management.
</t><t>
This document specifies a protocol that selects the forwarders such that each MPL-enabled device is connected to N_DUPLICATE forwarders, where N_DUPLICATE &gt; 0 can be set. The parameter N_DUPLICATE determines how much path redundancy there is for each MPL message. The value of N_DUPLICATE should be at least 1, because a value of 0 has as result that no forwarder exists in the network during the protocol execution. Moreover, the approach is distributed and dynamic in nature to meet ever changing topology as well as rationally minimizing the selected forwarding nodes.
</t><t>
The protocol is inspired by the work described for NeighbourHood Discovery (NHDP) <xref target="RFC6130"/> and Simple Multicast Forwarding (SMF) <xref target="RFC6621"/>. In contrast to the "HELLO" messages described in <xref target="RFC6130"/>, this protocol uses the Trickle protocol <xref target="RFC6206"/> to multicast link-local messages, containing a CBOR payload <xref target="RFC7049"/>.
</t>

<section anchor="terminology" title="Terminology">
<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"/>.
</t>
<t>
Readers of this specification should be familiar with all the terms and concepts discussed in <xref target="RFC7731"/>.
  The following terms are defined in this document:
  <list style="hanging">
    <t hangText="TODO"> new terms used in this document </t>
  </list>
</t>
<t>
  The following list contains the abbreviations used in this document.
  <list style="hanging">
    <t hangText="XXXX:">TODO, and others to follow.</t>
  </list>
</t>

</section>  <!-- Terminology -->

</section>  <!-- Introduction -->

<section anchor="overview" title="Protocol overview">
<t>
Nodes participating in MPLFS exchange messages with a format that is described in <xref target="payload"/>. A participating node communicates to all its neighbours with link-local multicast messages as described in <xref target="neigh-dist"/>. 
</t><t>
Failing links provide a lot of instability. Only messages sent over stable links are accepted. <xref target="neigh-dist"/> describes a mechanism to refuse messages from unstable links.
</t><t>
Each node maintains a set of 1-hop neighbours and a set of 2-hop neighbours. On the basis of the contents of the set, the node can decide to become a Forwarder or not, as explained in <xref target="select"/>.
</t><t>
The protocol never ends, with a minimum frequency of exchanging maintenance messages specified by an interval size of I_MAX_SELECT. When the set of links is stable, the protocol stabilizes such that every MPL-enabled node is connected to at least N_DUPLICATE MPL forwarders (when existing), where N_DUPLICATE &gt; 0. N_DUPLICATE can be set dependent on the application requirements. With N_DUPLICATE = 2, it is expected that a message does not arrive at an intended recipient with very low probability. 
</t><t>
Nodes have a state that determines whether they are forwarder or not. The state of a node can only be changed by the node itself. To avoid race conditions, (e.g. two nodes simultaneously decide to be no forwarder, while only one is intended) the node with the highest address of all 2-hop neighbours is the only one allowed to change state. Unlike <xref target="RFC5614"/>, that considers 3-tuple (Router Priority, MDR Level and Router ID) to allow self state change, this approach only takes into account the node address. Consequently, only k-hop neighbours, with k &gt; 2, can change state simultaneously, and the 1-hop and 2-hop neighbours of a given node can change state one by one.
</t>
</section>  <!-- Overview -->

<section anchor="data" title="Data sets">
<t>
Each node, n_0, maintains a state with three values: Possible Forwarder (PF), Fixed Forwarder (FF) and No Forwarder (NF).
Each node also maintains a set, S1_0, containing information about n_0's 1-hop neighbours and a set S2_0 containing information about n_0's 2-hop neighbours. Each entry, n_i, in S1_0 or S2_0 has the following attributes: 
<list style="hanging">
<t hangText="address of n_i: "> the address can be the 64 bit IPv6 address or the short 16 bit address. </t>
<t hangText= "average-rssi-in: ">  the average rssi of the messages received by n_0 from n_i.</t>
<t hangText= "average-rssi-out: ">  the average rssi of the messages received by n_i from n_0.</t>
<t hangText= "nr_FF: "> the number of n_i in S1_0 with state = FF. </t>
<t hangText= "nr_under: "> the number of neighbours of n_i in S1_0 with nr_FF &lt; N_DUPLICATE.</t>
<t hangText= "size: "> the size of S1_i, the set of 1-hop neighbours of n_i.</t>
<t hangText= "state: "> the state of n_i. </t>
</list>
</t><t>
During the protocol execution the state of the nodes change. Although the protocol never ends due to changes in configuration and link state, in a steady state, no node has the state PF.
</t>
</section> <!-- Data sets -->

<section anchor="neigh-dist" title="Neighbor distribution">
<t>
</t><t>
A participating node multicasts link-local so-called "neighbour messages" with the Trickle protocol. It uses the multicast address LINK_LOCAL_ALL_NODES as destination. The message sent by n_0 contains the contents of S1_0. The contents of a "neighbour message" from n_i received by n_0 is called M_i. The rssi value associated with the reception of the "neighbour message" is called new_rssi. The message M_i describes n_i followed by the neighbours of n_i with the following attributes:
<list style="symbols">
<t> address, is address of n_i</t>
<t> average-rssi-in </t>
<t> nr_FF </t>
<t> nr_Under </t>
<t> size </t>
<t> state </t>
</list>
</t><t>
On reception of M_i from n_i for the first time, the receiving node adds n_i to S1_0, and sets average-rssi-in to new_rssi. For all following messages from n_i, the average-rssi-in for n_i is calculated in the following way: average-rssi-in := (average-rssi-in*WEIGHT_AVERAGE + new_rssi)/(WEIGHT_AVERAGE+1).
</t><t>
The entries of M_i are called n_ij. For the entry n_ij with an address that is equal to the address of n_0: the value of average-rssi-out of n_i is set equal to the value of average-rssi-in of n_ij.
</t><t>
When the average-rssi-in and average-rssi-out values have been averaged over more than WEIGHT_AVERAGE messages, and the averaged RSSI values are smaller than MAXIMUM_RSSI, n_0 updates the contents of S1_0 and S2_0 with the contents of M_i.
<list style="symbols">
<t> Add n_i to S1_0, or refresh values of n_i. </t>
<t> For every entry n_ij in M_i that is not present in S1_0 add n_ij to S2_0.</t>
<t> Set size of n_i equal to the number of entries in M_i.</t>
</list>
</t><t>
Set nr_FF equal to the number of n_i in S1_0 with state is equal to FF. Set nr-Under equal to the the number of n_i with nr_FF &lt; N_DUPLICATE.
</t>
</section>  <!-- Neighbor Distribution -->


<section anchor="select" title="Selection Algorithm">
<t>
The protocol allocates forwarders in the densest part of the network. A dense network is characterized by a high number of neighbours. Therefore, the protocol attempts to assign status FF to the nodes with the highest number of neighbours that have less than N_DUPLICATE neighbours with state = FF.
</t><t>
At the start of the selection protocol every node sets its state to Possible Forwarder (PF). It sets the Trickle timer to its minimum interval, I_MIN_SELECT, and starts multicasting M_0 to its neighbours. Every time entries are added to, or removed from, S1_0 or S2_0, the Trickle interval timer is set to I_MIN_SELECT.
</t><t>
The executing node, n_0, calculates for all entries of S1_0 and S2_0 with state PF: 
<list style="symbols">
<t>max-under is the maximum of the nr_Under attribute.</t>
<t>max_address is the maximum of the addresses of the entries with nr_Under =max-under.</t>
</list>
To calculate its new state, n_0 does the following at the next synchronization moment:
</t><t>
When the state is not equal to FF and nr_Under = max-under and address = max-address: set state to FF.
</t><t>
Discussion:
</t><t>
The information about the state and the nr_under value of the neighbours comes in asynchronously. A criterion must be defined, called synchronization moment, that these values can be trusted to represent the state of the neighbours at this moment of time. 
</t>
</section>  <!-- Selection Algorithm -->

<section anchor="payload" title="CBOR payload">
<t>
The payload format is /application/cbor <xref target="RFC7049"/>. The contents of the message is the rssi value of messages received by the neighbour, followed by a list of lists composed of neighbour address, rssi value, size of S1_i, forwarder state, nr_FF, and nr_Under. 
Assuming two neighbours, in diagnostic JSON the payload looks like:
</t>
<figure anchor="pl" title="CBOR payload">
<artwork align="left"><![CDATA[
[
[address_1, average-rssi-in_1, size_1, state_1, nr_FF_1, nr_Under_1],
[address_2, average-rssi-in_2, size_2, state_2, nr_FF_2, nr_Under_2]
]
]]></artwork></figure>

</section>  <!-- CBOR payload -->

<section anchor="default" title="Default parameter values">
<t>
The following text recommends default values for the MPLFS protocols.
<list style="hanging"> 
<t hangText="I_MIN_SELECT"> = 0,2; minimum Trickle timer interval. </t>
<t hangText="I_MAX_SELECT">  = 10; maximum Trickle timer interval. </t>
<t hangText="WEIGHT_AVERAGE"> = 10; number of values to average rssi. </t>
<t hangText="MAXIMUM_RSSI"> = 3; maximum acceptable average rssi value. </t>
<t hangText="N_DUPLICATE"> = 2; requested number of MPL forwarder neighbours for every MPL enabled node. </t>
</list>
</t>
</section>

<section title="Acknowledgements">
<t>
We are very grateful to 
</t>
</section>

<section title="Changelog">
<t>
Changes from version 00 to version 01
<list style="symbols">
<t> Not yet relevant </t>
</list>
</t>

</section>

</middle>
  <back>
    <references title="Normative References">
      &RFC2119;
      &RFC6206;
      &RFC7049;
	 &RFC7731;
    </references>

    <references title="Informative References">
      &RFC4291;
      &RFC5614;
      &RFC6130;
      &RFC6621;
    </references>  

       
  


</back>

</rfc>
