<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">

<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="no"?>
<?rfc subcompact="no"?>
<?rfc authorship="yes"?>
<?rfc tocappendix="yes"?>
<rfc  xmlns:xi="http://www.w3.org/2001/XInclude" category="std" ipr='trust200902' tocInclude="true"  obsoletes="" consensus="true" submissionType="IETF" xml:lang="en" version="3" docName="draft-hushe-roll-dodag-metric-00">
<front>

   <title abbrev='DODAG size'>A DODAG Metric Used for DODAG Selection in Low-Power and Lossy Networks</title>



   <author initials="H" surname="She" fullname="Huimin She">
      <organization abbrev="Cisco Systems">Cisco Systems, Inc</organization>
      <address>
        <postal>
	    <street>Xinsi Building</street>
            <street>No. 926 Yishan Road, Xuhui District</street>
            <city>SHANGHAI</city>
            <code>200233</code>
            <country>CHINA</country>
         </postal>
         <email>hushe@cisco.com</email>
      </address>
   </author>


      <author initials='L' surname='Zhao' fullname='Li Zhao'>
          <organization abbrev='Cisco Systems'>Cisco Systems, Inc</organization>
          <address>
             <postal>
                <street>Xinsi Building</street>
                <street>No. 926 Yishan Road, Xuhui District </street>
                <city>SHANGHAI </city>
                <code>200233</code>
                <country>CHINA</country>
             </postal>
             <email>liz3@cisco.com</email>
          </address>
      </author>

   <author fullname='Pascal Thubert' initials='P.' surname='Thubert'>
      <organization abbrev='Cisco Systems'>Cisco Systems, Inc</organization>
      <address>
         <postal>
            <street>Building D</street>
            <street>45 Allee des Ormes - BP1200 </street>
            <city>MOUGINS - Sophia Antipolis</city>
            <code>06254</code>
            <country>FRANCE</country>
         </postal>
         <phone>+33 497 23 26 34</phone>
         <email>pthubert@cisco.com</email>
      </address>
   </author>

   <date/>
   <area>Routing Area</area>
   <workgroup>ROLL</workgroup>
   <keyword>Draft</keyword>
   <abstract>
      <t>
	This document extends <xref target='RFC6551'/> by defining a new DODAG metric called DODAG size, which
	can be used for DODAG selection in Low-Power and Lossy Networks (LLNs).
	DODAG size is an important metric for nodes to decide which DODAG to join, or which DODAG to migrate.
	This document proposes methods to disseminate DODAG size from the Root to all nodes in the DODAG,
	so that the DODAG size can be advertised to new joining nodes.
      </t>
   </abstract>
</front>

<middle>
   <section><name>Introduction</name>
<t>
  Low-power and Lossy Networks (LLNs) typically consist of large number of   nodes connected by lossy and unstable links.
  Such networks are typically compised of nodes that are constrained in CPU power, memory, and energy.
</t>
<t>
  RPL, the <xref target='RFC6550'>"Routing Protocol for LLNs"</xref>, is an
  IPv6 routing procotol with specific optimizations for such networks.
  RPL builds routes proactively but maintains them on-demand based on their
  utilization.
  Point-to-multipoint (P2MP) and multipoint-to-point (MP2P) routes to and from the Root are optimized, but other point-to-point (P2P) routes are stretched
  to minimize the control traffic and the state in every node.

</t>
<t>
  When used in conjunction with IEEE Std. 802.15.4 <xref target='IEEE802154'/>,
  RPL can be used to form a Personal Area Network (PAN) composed by a 6LoWPAN Border Router (6LBR) that is typically collocated with the DODAG Root, and multiple 6LoWPAN Nodes (6LN), that can be RPL routers of leaves.
</t>
<t>
  The PAN formation process starts from a DODAG Root.
  Before a node joins a PAN, it has no information regarding available neighbors or PANs.
  To discover available PANs, a joining node transmits PAN Advertisement
  Solicits and listens for PAN Advertisements from either the Root or
  other joined nodes.
</t>
<t>
  The PAN Advertisements contain minimum information (such as network name,
  DODAG size, etc.) for a node to select an appropriate PAN to join or migrate.
  The DODAG size is the number of nodes in the DODAG and communicating through
  the Root.  The DODAG size thus is an important metric for a node to decide
  which PAN to join. Therefore, it is essential to ensure the value of DODAG
  size advertised is up-to-date.
</t>
<t>
  At this early stage, this document propose two methods to disserminates the DODAG size to the PAN.
  </t>

   </section><!-- title="Introduction"-->


<section><name>Terminology</name>

<section anchor='lo'><name>References</name>
<t>
   The terminology used in this document is consistent with and incorporates
   that described in <xref target='RFC7102'>"Terms Used in Routing for Low-Power
   and Lossy Networks (LLNs)"</xref>.
   Other terms in use in LLNs are found in <xref target='RFC7228'>
   "Terminology for Constrained-Node Networks"</xref>.
</t>

<t>"RPL", the "RPL Packet Information" (RPI), and "RPL Instance" (indexed by a
   RPLInstanceID) are defined in <xref target='RFC6550'>"RPL: IPv6 Routing
   Protocol for Low-Power and Lossy Networks"</xref>. The RPI is the abstract
   information that RPL defines to be placed in data packets, e.g., as the RPL
   Option <xref target='RFC6551'/> within the IPv6 Hop-By-Hop Header.
   By extension the term "RPI" is often used to refer to the RPL Option itself.
   The DODAG Information Solicitation (DIS), Destination Advertisement Object
   (DAO) and DODAG Information Object (DIO) messages are also specified in
   <xref target='RFC6550'/>.
</t>


</section>	<!-- end section "References" -->
<section anchor='gloss'><name>Glossary</name>
 <t> This document often uses the following acronyms:
    </t>
    <dl  spacing='compact'>
    <dt>6LoWPAN:</dt><dd>IPv6 over Low-Power Wireless Personal Area Network</dd>
    <dt>6LoRH:</dt><dd>6LoWPAN Routing Header</dd>
    <dt>DIO:</dt><dd> DODAG Information Object (a RPL message) </dd>
    <dt>DODAG:</dt><dd> Directed Acyclic Graph </dd>
    <dt>DODAG:</dt><dd> Destination-Oriented Directed Acyclic Graph </dd>
    <dt>LLN:</dt><dd> Low-Power and Lossy Network </dd>
    <dt>PAN:</dt><dd> Personal Area Network</dd>
    <dt>RPL:</dt><dd> IPv6 Routing Protocol for Low-Power and Lossy Networks </dd>
    </dl>
</section>	<!-- end section "Glossary" -->

<section anchor='bcp'><name>Requirements Language</name>
<t>

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
    "OPTIONAL" in this document are to be interpreted as described in BCP 14
 <xref target='RFC2119'/><xref target='RFC8174'/> when, and only when, they
    appear in all capitals, as shown here.

</t>
</section>	<!-- end section "Requirements Language" -->


</section>	<!-- end section "Terminology" -->


<section><name>Disseminating DODAG size</name>
<t>
  The value of DODAG size is collected by the Root, and disseminated to all nodes in the PAN.
  To ensure timely delivering of DODAG size, it has to be contained in periodic PAN-wide messages that can reach every node in the PAN.
</t>
<t>
  The DODAG size is defined by the DODAG Size Object and MAY be present in the DODAG Metric Container option <xref target='RFC6551'/>.
  </t>

  <section><name>DODAG Size Object</name>
<t>
<xref target='RFC6551'/> specifies a set of link and node routing metrics and constraints suitable
to LLNs. This document extends <xref target='RFC6551'/> by defining a new DODAG metric called DODAG size.
</t>

<t>
  The DODAG size object MAY be present in the DODAG Metric Container.
  There MUST NOT be more than one DODAG size object as a metric per DODAG
  Metric Container.
</t>
<t>
   The DODAG size object is made of DODAG size fields and MUST at least
   comprise one DODAG size field. Each DODAG size field has a fixed
   length of 16 bits.
</t>
<t>
  The DODAG size object does not contain any additional TLVs.
  </t>
<t>
  The DODAG size object Type has been assigned value TBD by IANA.
  </t>

 <t>
   The format of the ETX object body is as follows:
 </t>
<figure anchor="DODAGSOBF">
          <name>DODAG Size Object Body Format </name>
       <artwork align="center" name="" type="" alt=""><![CDATA[
    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  (field) .....       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ]]></artwork>
</figure>

<figure anchor="DODAGSSF">
          <name>DODAG Size field Format </name>
       <artwork align="center" name="" type="" alt=""><![CDATA[

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            DODAG Size           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   ]]></artwork>
</figure>

<t>
  DODAG Size: 16 bits. It is encoded using 16 bits in unsigned integer format.
</t>

</section>

<section><name>Disserminating DODAG size through DIO</name>
<t>
  According to <xref target='RFC6550'/>, the DIO message is periodically sent to the PAN, and it MAY
  carry an option called DODAG Metric Container. The DODAG size object can be present in this option.
  Through the DIO message, the DODAG size is gradually disseminated to nodes in the PAN
</t>
</section>

<section><name>Disserminating DODAG size through DAO-ACK</name>
<t>
  The DAO-ACK message <xref target='RFC6550'/> is sent as unicast packet by the DODAG Root in response to a unicast DAO message.
</t>
<t>
  It MAY carry the DODAG Metric Container option  <xref target='RFC6550'/>. The DODAG size MAY be present
  in the DODAG Metric Container option.
</t>
<t>
  The nodes in a PAN might be able to get the DODAG size timely through the DAO-ACK messsage..
  Compared with the DIO message, the DAO-ACK message is tyipcally sent more frequently. Moreover, nodes deep
  in the DODAG can get the DODAG size more quickly since the DAO-ACK is directly sent by the Root in unicast.
  </t>
</section>


   </section><!-- Disseminating DODAG size -->



   <section anchor="iana"><name>IANA Considerations</name>
       <t>
    This specification updates the "Routing Metric/Constraint Type" subregistry of the "Routing Protocol for Low Power and Lossy Networks (RPL) Routing Metric/Constraint" Registry that was created for <xref target='RFC6551'/>.
    </t><t>
    IANA is thereby requested to allocate one new value as follows:

    </t>

   <table  anchor="nexndopt"><name>New DODAG Metric Object Type</name>
   <thead>
      <tr><td>Value</td><td>Description</td><td>Reference</td></tr>
   </thead><tbody>
      <tr><td>9 (suggested)</td><td>DODAG size</td><td>This document</td></tr>
   </tbody>
   </table>

    <!--t>
    The DODAG Configuration Option Flags defined so far will be obsolete for
    RPL Mode of Operation (MOP) above and including 7.
    </t>
    <t>
    IANA is requested to update the name of the Registry from "DODAG Configuration Option Flags" to "DODAG Configuration Option Flags for RPL MOP 0..6".
    </t>
    <t>
    When MOP values of 7 and more are defined, a new registry will be needed.
    </t-->
   </section>

   <section anchor='sec'><name>Security Considerations</name>
    <t>
   It is worth noting that in RPL <xref target='RFC6550'/>, every node in the
   LLN that is RPL-aware and has access to the RPL domain can inject any RPL-based attack in the network, more in <xref target='RFC7416'/>.
   This document applies typically to an existing deployment and does not change
   its security requirements and operations.
   It is assumed that the security mechanisms as defined for RPL are followed.

 </t>
   </section>

   <section><name>Acknowledgments</name>
   <t>
   The authors wish to thank TBD.
   </t>
   </section><!-- ack -->
</middle>

<back>

    <references><name>Normative References</name>
	  <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml'/> <!-- BCP14 -->
	  <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml'/> <!-- BCP14 -->
	  <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6550.xml'/> <!-- RPL -->
          <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6551.xml'/> <!-- MC -->
  <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7102.xml'/> <!-- RPI -->


   </references>
   <references><name>Informative References</name>

      <reference anchor='IEEE802154'>
         <front>
            <title>IEEE Std. 802.15.4, Part. 15.4: Wireless Medium Access
            Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate
            Wireless Personal Area Networks
            </title>
            <author>
               <organization>IEEE standard for Information Technology</organization>
            </author>
            <date/>
         </front>
      </reference>

  <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7228.xml'/> <!-- termonology -->


	  <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7416.xml'/> <!-- Security Threat Analysis for RPL -->



   </references>


</back>
</rfc>
