eliding-dio-information.xml

<?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="" updates="6550" consensus="true" submissionType="IETF" xml:lang="en" version="3" docName="draft-thubert-roll-eliding-dio-information-04" >

<front>

   <title abbrev='Eliding RPL Info'>Eliding and Querying RPL Information</title>
   <author initials='P' surname='Thubert' fullname='Pascal Thubert' role='editor'>
      <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>


    <author fullname="Rahul Arvind Jadhav" initials="R.A." surname="Jadhav">
        <organization>Huawei Tech</organization>
        <address>
            <postal>
                <street>Kundalahalli Village, Whitefield,</street>
                <city>Bangalore</city>
                <region>Karnataka</region>
                <code>560037</code>
                <country>India</country>
            </postal>
            <phone>+91-080-49160700</phone>
            <email>rahul.ietf@gmail.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 Yi Shan Rd </street>
                <city>SHANGHAI </city>
                <code>200233</code>
                <country>CHINA</country>
             </postal>
             <email>liz3@cisco.com</email>
          </address>
       </author>

    <author initials="D." surname="Barthel" fullname="Dominique Barthel">
      <organization>Orange Labs</organization>
      <address>
        <postal>
          <street ascii="28 chemin du Vieux Chene">28 chemin du Vieux Chêne</street>
          <code>38243</code>
          <city>Meylan</city>
          <country>France</country>
        </postal>
        <email>dominique.barthel@orange.com</email>
      </address>
    </author>

   <date/>
   <area>Routing Area</area>
   <workgroup>ROLL</workgroup>
   <keyword>Draft</keyword>
   <abstract>
      <t>
      This document presents a method to safely elide a group of RPL options in
      a DIO message by synchronizing the state associated with each of
      these options between parent and child using a new sequence counter in DIO
      messages.  A child that missed a DIO message with an update of
      any of those protected options detects it by the change of sequence
      counter and queries the update with a DIS Message. The draft also provides
      a method to fully elide the options in a DAO message.
      </t>
   </abstract>
</front>

<middle>
<section><name>Introduction</name>
   <t>
   Classical Link State protocols synchronize their Link State Database (LSDB)
   by sequencing every change. Each interested node maintains the last sequence
   of the LSDB it is synchronizing with. If the last known sequence number is
   older than the current, the node needs to learn one by one all the state
   changes between the last known and the current state.
   </t><t>
   <xref target="RFC6550">"RPL: IPv6 Routing Protocol for Low-Power and Lossy
   Networks" (LLNs)</xref> does not operate that way. With RPL, the routing
   information is repeated over and over in DODAG Information Object (DIO) and
   Destination Advertisement Object (DAO) messages. There is no concept of
   synchronization. Still there is a concept of sequence to ensure that the most
   recent information is recognized and overrides a previous one. A stale state
   may exist in dead branches of the network and eventually time out.
   </t><t>
   The RPL way was designed to enable routing from most nodes to most nodes most
   of the time in a Low-Power Lossy Network (LLN) where the quality of the links
   and the cost of communications does not permit to maintain a permanent
   synchronization.
   This principle was applied to both the routing and non-routing information
   such as configuration settings, prefix information, and node capabilities.
   </t><t>
   This non-routing state is carried in RPL Messages as options. Some of the DIO
   options may be needed to decide whether a node can join a network as a leaf
   or as a router, and may affect the parent selection or the address selection.
   It is thus critical that each node maintains its state to the freshest and
   selects parents that are also synchronized to the freshest.
   </t><t>
   <xref target="RFC6550"/> allows a parent to elide options in the DIO messages
   that it sends repeatedly, to conserve battery and save bandwidth. When it
   does so, a newcomer child that missed DIOs that contained the configuration
   option may operate on default or partial information. If it is pessimistic,
   it may query all possible information even when it is not needed.
   Likewise, a node that slept may have missed a DIO with a change in some
   critical information and may not be even aware of it, so it may fail to query
   for the update and operate on deprecated parameters.
   </t><t>
   This document uses a new sequence counter called the RPL Configuration State
   Sequence (RCSS) to synchronize the
   state in a child node with that of its parent, and recursively with that of
   the whole network, to the latest setting from the Root.
   </t><t>
   The protected options are:
   </t>
   <ul spacing='compact'>
      <li>
      The Route Information Option (RIO) defined in section 6.7.5 of
      <xref target="RFC6550"/>
      </li><li>
      The DODAG Configuration Option (DCO) defined in section 6.7.6 of
      <xref target="RFC6550"/>
      </li><li>
      The Prefix Information Option (PIO) defined in section 6.7.10 of
      <xref target="RFC6550"/>
      </li><li>
      The Extended MOP Option (MOPex) defined in
      <xref target="I-D.jadhav-roll-mopex" format="default"/>
      </li><li>
      The Capability Option and TLVs defined in
      <xref target="I-D.ietf-roll-capabilities" format="default"/>
      </li>
   </ul>
   <t>
   Any change in those options causes an increment of the RCSS and enables a
   network-wide synchronization to the new state. If the change impacts the
   routing substantially, the Root should decide to increment the Version Number
   at the same time to fully rebuild the DODAG with the new settings of the
   options.
   It must be noted that rebuilding the DODAG does not guarantee that the
   non-routing state is fully synchronized unless all the options
   were present in all the DIO messages since the new Version is used.
   </t>
</section><!-- title="Introduction"-->

<section><name>Terminology</name>

   <section anchor='bcp'> <name>BCP 14</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> <!-- BCP 14 -->

   <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</xref>.
   </t><t>
   Other terms in use in LLNs are found in <xref target="RFC7228">
   Terminology for Constrained-Node Networks</xref>.
   </t><t>
   A glossary of classical RPL acronyms is given in <xref target="gloss"/>.
   </t><t>
   The term “byte” is used in its now customary sense as a synonym for “octet”.
   </t><t>
   "RPL", "RPL Packet Information" (RPI) and "RPL Instance", DIO, DAO and DIS
   messages are defined in the
   <xref target="RFC6550">"RPL: IPv6 Routing Protocol for Low-Power and Lossy
   Networks"</xref> specification.
   </t><t>
   This document uses the terms RPL Leaf, RPL Aware Leaf (RAL), RPL-Aware Node
   (RAN) and RPL-Unaware Leaf (RUL) as defined in section 2 of <xref target=
   "I-D.ietf-roll-useofrplinfo"/>.
   </t><t>
   A RPL-Unaware Leaf (RUL) thus refers to a host that does not understand
   RPL but uses a RPL router (without necessarily knowing it) as default gateway
   and depends on that router to obtain reachability for its addresses inside
   the RPL domain.
   Conversely, the term RPL-Aware Node (RAN) is used to refer to a node
   that participates to RPL and advertises its addresses or prefixes by itself.
   </t>
   </section>	<!-- end section "References" -->

   <section anchor='gloss'> <name>Glossary</name>
   <t> This document often uses the following acronyms:
   </t>
   <dl>
      <dt>DODAG:</dt><dd>Destination-Oriented Directed Acyclic Graph </dd>
      <dt>LLN:</dt><dd>Low-Power and Lossy Network </dd>
      <dt>RPI:</dt><dd>RPL Packet Information (an Option in the Hop-By_Hop Header)</dd>
      <dt>RAL:</dt><dd>RPL-Aware Leaf </dd>
      <dt>RAN:</dt><dd>RPL-Aware Node </dd>
      <dt>RS:</dt><dd>Router Solicitation</dd>
      <dt>RCSS:</dt><dd>RPL Configuration State Sequence</dd>
      <dt>RPL:</dt><dd>IPv6 Routing Protocol for LLNs (pronounced ripple) </dd>
      <dt>RUL:</dt><dd>RPL-Unaware Leaf</dd>
   </dl>
   </section>	<!-- end section Glossary" -->

</section>	<!-- end section "Terminology" -->



<section><name>Updating RFC 6550</name>
   <t>
   This document adds a new field called RCSS to the DIO message. The RCSS is
   a sequence counter that is set by the Root and incremented as specified in
   Section 7 of <xref target="RFC6550"/>, more in <xref target='rcss'/>.
   </t><t>
   This document also introduces a new RPL Control Message Option called the
   Abbreviated Option Option (AOO). The AOO is the compressed replacement of a
   protected option that indicates the RCSS of the last change of that option,
   but elides its content, more in <xref target='syopts'/>.
   </t><t>
   This document modifies the DIS Base Object to enable the individual query of
   the protected options by a node that missed a change, more in <xref target=
   'udis'/>.
   </t><t>
   This document also enables to abbreviate a full DAO message when all the
   options are unchanged from the most recent DAO message that was positively
   acknowledged. In that case the DAO is resent with the same DAOSequence
   and all the options are elided. A new flag in the DAO Base Object indicates
   that this is an abbreviated DAO message, more in <xref target='elidingDAO'/>.
   </t><t>
   The abbreviated DAO renews the lifetime of a DAO state but does not change
   any information therein.
   </t>
</section><!-- end section Updating RFC 6550 -->


<section  anchor='form'> <name>Message Formats</name>

   <section  anchor='udio'> <name>Updated DIO Base Object</name>
   <t>
   The format of the DIO Base Object is defined in section 6.3.1 of
   <xref target="RFC6550"/>.
   This specification uses the 8th octet, which was reserved in
   <xref target="RFC6550"/>, to transport the RCSS.
   </t>
       <figure anchor="FigDIO">
              <name>Updated DIO Base Object</name>
       <artwork align="center" name="" type="" alt="">
  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | RPLInstanceID |Version Number |             Rank              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |G|0| MOP | Prf |     DTSN      |     Flags     |      RCSS     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 +                                                               +
 |                                                               |
 +                            DODAGID                            +
 |                                                               |
 +                                                               +
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Option(s)...
 +-+-+-+-+-+-+-+-+
       </artwork>
       </figure>

   <t>
   Updated fields:
   </t>
   <dl newline="true" spacing="normal" indent="3">
          <dt>RCSS:</dt>
          <dd>One Byte, the RPL Configuration State Sequence </dd>
   </dl>
   </section> <!-- end section Updated DIO Base Object -->


   <section  anchor='udis'> <name>Updated DIS Base Object</name>
   <t>
   The DIS Base Object is use by a child to query from a parent the most
   recent changes in protected options. This specification adds flags to
   indicate which options are requested and the freshest RCSS to which the
   querying node was synchronized.
   </t>

  <figure anchor="FigDIS"><name>Updated DIS Base Object</name>
  <artwork align="center" name="" type="" alt="">
  0                   1                   2
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |R|D|P[M|O| Flg | LastSync RCSS |   Option(s)...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   </artwork>
   </figure>

   <t>
   Updated fields:
   </t>
   <dl newline="true" spacing="normal" indent="3">
          <dt>R:</dt>
          <dd>One Bit, indicates that the RIO is requested</dd>
          <dt>D:</dt>
          <dd>One Bit, indicates that the DCO is requested</dd>
          <dt>P:</dt>
          <dd>One Bit, indicates that the PIO(s) is(are) requested</dd>
          <dt>M:</dt>
          <dd>One Bit, indicates that the MOPex is requested</dd>
          <dt>O:</dt>
          <dd>One Bit, indicates that the GCO is requested</dd>
          <dt>Last Synchronized RCSS:</dt>
          <dd>One Byte, the freshest RCSS to which the sender was synchronized</dd>
   </dl>

   </section> <!-- end section Updated DIS Base Object -->

   <section  anchor='udao'> <name>Updated DAO Base Object</name>
   <t>
   The format of the DAO Base Object is defined in section 6.4.1 of
   <xref target="RFC6550"/>. This specification adds the 'A' flag to indicate
   that the DAO options are elided.
   </t>
       <figure anchor="FigDAO">
              <name>Updated DAO Base Object</name>
       <artwork align="center" name="" type="" alt="">
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID |K|D|A| Flags   |   Reserved    | DAOSequence   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                            DODAGID*                           +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Option(s)...
+-+-+-+-+-+-+-+-+
       </artwork>
       </figure>
   <t>
   Updated fields:
   </t>
   <dl newline="true" spacing="normal" indent="3">
          <dt>A:</dt>
          <dd>One Bit, indicates DAO in abbreviated version</dd>
   </dl>

   </section> <!-- end section Updated DAO Base Object -->

   <section  anchor='syopts'> <name>New Abbreviated Option Option</name>

   <t>
   The Abbreviated Option Option (AOO) is a generic replacement for an option
   that only indicates the sender's value of the RCSS for that option.
   The format of the AOO is represented in <xref target="FigABB"/>:
   </t>
       <figure anchor="FigABB">
              <name>Abbreviated Option Option Format</name>
       <artwork align="center" name="" type="" alt="">
  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 Type  | Option Length | Abbrev. opt.  | Last Mod RCSS |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       </artwork>
       </figure>
   <t>
   Option fields:
   </t>
   <dl newline="true" spacing="normal" indent="3">
          <dt>Option Type:</dt>
          <dd>One byte indicating "Abbreviated Option", see <xref target=
          "ianaopttypetbl"/> in <xref target="ianaopttype"/></dd>
          <dt>Option Length:</dt>
          <dd>MUST be set to 2 indicating Option data of 2 bytes</dd>
          <dt>Abbreviated Option:</dt>
          <dd>The Option Type of the option being abbreviated </dd>
          <dt>Last Modification RCSS:</dt>
          <dd>The RCSS at which the option was last modified</dd>
   </dl>
   </section> <!-- end section New Abbreviated Option Option -->


</section> <!-- Message Formats -->

<section  anchor='rcss'> <name>RCSS Operation</name>

   <t>
   Settings and updates to network-wide parameters are initiated by the Root and
   propagated down the DODAG in RPL Control Message Options in DIO messages. The
   DIO messages arrive asynchronously via different parents and may confuse a
   child when they are not ordered.
   </t><t>
   The RCSS is a sequence number that is operated as specified in section 7.2 of
   <xref target="RFC6550"/>.
   The RCSS sequences the atomic state that is transported in the protected
   options in one or a burst of DIO Messages. The same value of the RCSS is used
   in the initial burst and in the subsequent DIO
   messages that are sent with no change in the protected options.
   </t><t>
   The Root of the DODAG is autoritative to set and update the RCSS and the
   options that it protects. The scope of an RCSS is one DODAG within one RPL
   Instance.
   </t><t>
   The RCSS and the sequenced state in the protected options are propagated
   together down the DODAG without a change, more in <xref target='updcss'/>.
   </t><t>
   The RCSS allows a child to remain synchronized to a most recent settings of
   the network-wide parameters that are propagated in the protected options.
   The child recognizes stale DIO message(s) and only uses parents with a
   consistent state, more in <xref target='freshrcss'/>.
   </t><t>
   By extension, the RCSS is also defined for each protected option. A child
   associates an option with the values of the RCSS indicated in DIO Messages in
   which the option was advertised and uses it to assess the relative freshness
   of different versions of an option, more in <xref target='optrcss'/>.
   </t><t>
   Unchanged options may be sent in full, elided, or in the abbreviated form
   specified in <xref target="syopts"/>. Which form to use depends on the RCSS,
   more in <xref target='optrcss'/>
   </t>
   <t>
   If the link MTU does not permit to send a single DIO message with all the
   options packaged then the options may be spread over multiple consecutive
   DIO messages with the same RCSS that are sent in a rapid sequence.
   </t>

   <section  anchor='updcss'> <name>Updating the RCSS</name>
   <t>
   The RCSS is incremented by the Root using a lollipop technique as specified
   in section 7.2 of <xref target="RFC6550"/>. RCSS values are comparable if
   they are within a window of comparison of SEQUENCE_WINDOW increments or one
   indicates a reboot.
   A reboot of the Root is detected when the RCSS moves from the circular to the
   straight part of the lollipop.
   </t><t>
   During the straight part of the lollipop, a second reboot of the Root might
   not be recognized and a same value of the RCSS may reappear with different
   settings in the protected options. For that reason the protected options MUST
   be provided in full with each increment on the RCSS during the straight part
   of the lollipop.
   </t><t>
   The straight part should be kept short with a RECOMMENDED initial value of
   252 or above.
   The Root SHOULD jump rapidly away from the straight part once the network has
   sufficiently settled by resetting the RCSS to 0, which places the RCSS in the
   circular region of the lollipop, where the protected options MAY be elided or
   abbreviated.
   </t><t>
   When a field is modified in one of the protected options, the Root MUST send
   a DIO with the RCSS incremented and the modified protected option(s) in full.
   The Root MAY also update the Version Number to form a new DODAG altogether.
   </t><t>
   </t>
    </section> <!-- Updating the RCSS -->

   <section  anchor='freshrcss'> <name>RCSS Freshness and Parent selection</name>
   <t>
   A child node maintains the freshest RCSS received from its parents in each of
   the RPL Instances that it participates to, and uses that RCSS for its own DIO
   messages once it has synchronized all the protected options to that RCSS.
   </t><t>
   A child and a candidate parent are out-of-sync when the RCSS values that they
   maintain for a RPL Instance are not comparable. A child MUST NOT use a parent
   that is out-of-sync unless no other parent is available, in which case it MAY
   align its RCSS and synchronize to that parent.
   </t><t>
   When a child receives from a candidate parent a DIO with an RCSS that is
   fresher than the one it is using, the child MUST synchronize the state
   relative to the protected options with that parent. The child node MUST
   refrain from using that parent and the new state including the RCSS, until
   it has synchronized all of the protected options to that RCSS. When it is
   fully synchronized, the child may then use that parent and the new RCSS.
   </t><t>
   Using a back-level parent may cause packets to be dropped, misunderstood or
   misrouted. The child SHOULD refrain from using a parent that exposes an older
   RCSS if the change causes an incompatibility issue.
   </t>
   </section> <!-- Freshness and Parent selection -->


   <section  anchor='optrcss'> <name>RCSS of an Option</name>
   <t>
   By extension, the RCSS of an option is maintained by all nodes and is defined
   for all but the Root as the freshest RCSS indicated by a DIO message from a
   candidate parent in which the option was present, in the abbreviated form or
   in full. A child maintains a state for the RCSS of each of the protected
   options and synchronizes its state for the options by comparing that RCSS
   with the one found in new DIO messages for the option.
   </t><t>
   Protected options may be sent in full, elided, or in the abbreviated form.
   Which form to use depends on the RCSS of the option that a parent maintains:
   </t>
   <ul>
      <li>
      A parent MAY use either form when the RCSS is not changed from a previous
      DIO; eliding options is PREFERRED in stable conditions to save resources.
      </li><li>
      When a protected option is updated, the RCSS is mechanically incremented,
      and the new option MUST be sent in full on the first DIO that advertises
      that new RCSS and the corresponding AOO SHOULD NOT be added.
      </li><li>
      When the RCSS is updated but a protected option is unchanged, the parent
      SHOULD NOT fully elide the option as it may cause multiple children to
      synchronize it to no avail. The use of AOO is RECOMMENDED unless it may
      cause a desynchronization for that option, in which case the option SHOULD
      be placed in full, more in <xref target='optrcss'/>.
      </li>
   </ul>
   <t>
   When a child receives a DIO from a candidate parent, for each option:
   </t>
   <dl>
      <dt>If the Option is advertised in the abbreviated form,</dt><dd>then the
      RCSS that the DIO advertises for the option is the Last Modification RCSS
      of the AOO, else</dd>
      <dt>If the Option is advertised in full,</dt><dd>then the RCSS that the DIO
      advertises for the option is the RCSS of the DIO, else</dd>
      <dt>If the Option is elided,</dt><dd>then the RCSS is unspecified but it is
      at most as fresh as the RCSS of the DIO, and the RCSS of the DIO is
      assumed for the comparison</dd>
   </dl>
   <t>
   This means that if an Option is advertised in both the abbreviated form and
   in full in a same DIO message then the RCSS in the AOO has precedence.
   </t><t>
   To keep the RCSS comparable for each option, the RCSS of an option must
   lazily progress along with the global RCSS even if there was no change in the
   options. Each parent including the Root MUST advertise a new RCSS for each of
   the protected options at least once within a sliding window of
   SEQUENCE_WINDOW increments.
   </t><t>
   When an option was not changed for a new RCSS, one parent may advertise it in
   the abbreviated form while another sends the option in full only, e.g., in
   response to a DIS message. A fresher RCSS indicates that the option is either
   the same or carries a more recent update than the one with an older RCSS.
   </t><t>
   The RCSS of an option may be obtained from a DIO message that carries the
   option in full even if the RCSS of the DIO is not the freshest across
   parents, as long as the RCSS of the DIO is fresher than the current one for
   that option.
   </t><t>
   If the current value of the maintained RCSS for a given option is not fresher
   or as fresh as that advertised in a DIO message, then the child MUST update
   its state for that option as specified in <xref target="sync"/>.
   </t>

   </section> <!--end section RCSS of an Option -->

</section> <!-- end section RCSS Operation -->

<section  anchor='sync'> <name>Synchronizing Options</name>

   <t>
   As the value of the RCSS progresses, a child MUST NOT attempt to synchronize
   its state with a parent that advertises a value of RCSS that is out-of-sync
   with self, or that is already back level vs. the most recent known RCSS for
   each protected option, unless it lost reachability to all the candidate
   parents that advertise a fresher and not out-of-sync value of RCSS.
   </t><t>
   A child can synchronize any of the protected options to the latest RCSS by
   sending a DIS Message to a candidate parent that advertises that RCSS in DIO
   messages. The child MUST set the desired combination of 'R', 'D', 'P', 'M'
   and 'O' flags to indicate the option(s) that it needs updated. The child MUST
   signal in the Last Synchronized RCSS field of the DIS the freshest value of
   RCSS for which it was fully synchronized, or a conventional value of
   OUT-OF-SYNC-RCSS of 129 if it was never synchronized or is out-of-sync with
   the parent.
   </t><t>
   The DIO message that is sent in response MUST contain in full all the options
   that are requested and that were updated since the Last Synchronized RCSS in
   the DIS Message. This means all of the protected options if the child was
   never synchronized or is out-of-sync with the parent. The other options MUST
   be added in the abbreviated form.
   </t><t>
   The options MAY be spread over more than
   one DIO message sent in a quick sequence. It is possible that the DIS is not
   received by the parent or that a DIO that carries all or subset of the
   requested options is lost in return. In that case the child MUST resend a DIS
   with the bits associated to the options that are still missing after a
   reasonable technology-dependent time before it retries the request. The child
   MAY use any parent that advertises the RCSS to get any of the options up to
   that level.
   </t>

</section> <!-- Synchronizing Options -->


<section anchor="elidingDAO" numbered="true" toc="default">
       <name>Abbreviating the DAO Message</name>
   <t>
   When a node receives a positive DAO-ACK upon a DAO message for a given
   DAOSequence, The DAO-ACK indicates that the DAO was fully processed by its
   destination (parent or Root).
   </t><t>
   Until there is a change in one of the DAO
   options since that DAOSequence, the next DAO messages merely refresh the
   lifetime of the routes. In that case, increasing the DAOSequence creates
   undesirable churn up the DODAG for no added value.
   This specification enables a node to refresh the state in a destination that
   is associated to one or more DAO message(s) that were acknowledged by that
   destination without resending the DAO message(s) in full.
   </t><t>
   Instead, the
   node MAY use a single abbreviated DAO message that is sent to the same
   destination and with the same DAOSequence as the DAO message(s) that it
   refreshes, and with the 'A' flag set (see <xref target='udao'/>) to signal
   it is an abbreviated DAO.
   </t><t>
   This can be more than one message if the node could not package all its state
   in a single message, e.g., due to MTU restrictions. In that case the DAO
   state that is refreshed is the aggregation of the DAO messages that were
   acknowledged for the provided DAOSequence by that destination.
   </t><t>
   Upon the abbreviated DAO, the destination refreshes the state associated to
   the original DAO message(s) received with that DAOSequence, typically by
   extending the lifetimes of the routes that were advertised with the same
   duration.
   </t><t>
   A node MAY also unset ‘K’ flag in the abbreviated DAP message and not expect
   a DAO-ACK, if the node can assume the risk that the DAO is lost, e.g., if the
   routes will be refreshed again before the lifetime expires.
   </t><t>
   Only the DAO message(s) with the last (freshest) DAOSequence can be a
   abbreviated. A nod MUST NOT use an abbreviated DAO with a DAOSequence that is
   not the freshest and it MUST NOT use the abbreviated form of the DAO until
   the destination has acknowledged all state associated with that DAOSequence.
   If a destination receives an abbreviated DAO with a DAOSequence that is not
   the freshest from that node, or the destination does not have a state for
   that node, then MUST send a DAO-ACK with a DAO Status indicating an error.
   The destination MAY use a new Status of 'Out-of-Sync' in which case the node
   MUST resent the DAO Message(s) in full with its freshest DAOSequence and the
   destination synchronizes to that level.
   </t><t>
   It is RECOMMENDED to use an abbreviated DAO messages whenever possible,
   because a smaller DAO message consumes less energy and  bandwidth and has
   better chances of delivery. In Non-Storing Mode the benefits increases
   with the number of hops to the Root, and in Storing Mode with the amount of
   state that is implicitely refreshed.
   </t>
</section> <!-- Abbreviated DAO Message -->


<section anchor="SecurityConsiderations" numbered="true" toc="default">
       <name>Security Considerations</name>
   <t>TBD
   </t>
</section> <!-- Security Considerations -->

<section numbered="true" toc="default">
<name>IANA Considerations</name>

   <section anchor="ianadisflags" numbered="true" toc="default">
   <name>New DODAG Information Solicitation Flags</name>
   <t>
   5 new bits are allocated in the Registry for the DODAG Information Solicitation
   (DIS) Flags defined for <xref target="RFC6550"/>.
   </t>

   <table anchor="ianadisflagstbl"><name>New DIS Flags</name>
   <thead>
      <tr><td>Bit Number</td><td>Capability description</td><td>Reference</td></tr>
   </thead><tbody>
      <tr><td>0</td><td>'R' bit "RIO requested"</td><td>THIS RFC</td></tr>
      <tr><td>1</td><td>'D' bit "DCO requested"</td><td>THIS RFC</td></tr>
      <tr><td>2</td><td>'P' bit "PIO(s) requested"</td><td>THIS RFC</td></tr>
      <tr><td>3</td><td>'M' bit "MOPex requested"</td><td>THIS RFC</td></tr>
      <tr><td>4</td><td>'O' bit "GCO irequested"</td><td>THIS RFC</td></tr>
   </tbody>

   </table>

    </section><!-- end section  DODAG Information Solicitation Flags -->

   <section anchor="ianadaoflags" numbered="true" toc="default">
   <name>New DODAG Advertisement Object Flag</name>
   <t>
   1 new bit is allocated in the Registry for the Destination
   Advertisement Object(DAO) Flags defined for<xref target="RFC6550"/>.
   </t>

   <table anchor="ianadaoflagstbl"><name>New DAO Flag</name>
   <thead>
      <tr><td>Bit Number</td><td>Capability description</td><td>Reference</td></tr>
   </thead><tbody>
      <tr><td>2</td><td>'A' bit "DAO abbreviated"</td><td>THIS RFC</td></tr>
   </tbody>

   </table>

    </section><!-- end section Destination Advertisement Object Flags -->

   <section anchor="ianaopttype" numbered="true" toc="default">
   <name>New RPL Control Message Option</name>
   <t>
   A new entry is required for the new option of type "Abbreviated Option",
   from the "RPL Control Message Options" space defined for
   <xref target="RFC6550"/>.
   </t>

   <table anchor="ianaopttypetbl"><name>New Option Type</name>
   <thead>
      <tr><td>Code</td><td>Description</td><td>Reference</td></tr>
   </thead><tbody>
      <tr><td>TBD IANA</td><td>Abbreviated Option</td><td>THIS RFC</td></tr>
   </tbody>

   </table>

    </section><!-- end section  New RPL Control Message Option -->


</section><!-- end section  IANA Considerations -->


<section><name>Acknowledgments</name>
		<t>

   		</t>
</section><!-- ack -->


</middle>


<back>

   <displayreference   target="I-D.ietf-roll-useofrplinfo"           to="USE_OF_RPL_INFO"/>
   <displayreference   target="RFC6550"                              to="RPL"/>
   <displayreference   target="I-D.ietf-roll-capabilities"           to="CAPABILITIES"/>
   <displayreference   target="I-D.jadhav-roll-mopex"                to="MOPEX"/>

   <references><name>Normative References</name>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml'/> <!-- BCP 14 -->
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml'/> <!-- BCP 14 update -->
      <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.7228.xml'/> <!-- Terminology for Constrained-Node Networks -->
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7102.xml'/> <!-- Terms Used in Routing for Low-Power and Lossy Networks -->
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-roll-useofrplinfo.xml'/>
     <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-roll-capabilities.xml'/>
     <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.jadhav-roll-mopex.xml'/>
   </references>
   <references><name>Informative References</name>


   </references>
</back>

</rfc>

<!-- CONVERT WARNING: wide character found at character 2041 of the output -->