<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. --> encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced.
     An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC6550 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6550.xml">
<!ENTITY RFC8505 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8505.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="yes" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions --> "rfc2629-xhtml.ent">

<rfc category="std" xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-roll-efficient-npdao-18" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN"
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** --> number="9009" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the
         full title is longer than 39 characters -->
    <title abbrev="Efficient Route Invalidation">Efficient Route Invalidation</title>
    <seriesInfo name="RFC" value="9009"/>

    <author fullname="Rahul Arvind Jadhav" initials="R.A." role="editor" surname="Jadhav">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street>Kundalahalli Village, Whitefield,</street> Village</street>
          <extaddr>Whitefield</extaddr>
          <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="P" surname="Thubert" fullname="Pascal Thubert">
      <organization abbrev="Cisco">Cisco Systems, Inc</organization> Inc.</organization>
      <address>
        <postal>
            <street>Building D</street>
          <extaddr>Building D</extaddr>
          <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>
        <phone>+33-497-23-26-34</phone>
        <email>pthubert@cisco.com</email>
      </address>
    </author>
    <author fullname="Rabi Narayan Sahoo" initials="R.N." surname="Sahoo">
      <organization>Huawei</organization>
      <address>
        <postal>
          <extaddr>Whitefield</extaddr>
          <street>Kundalahalli Village, Whitefield, </street> Village</street>
          <city>Bangalore</city>
          <region>Karnataka</region>
          <code>560037</code>
          <country>India</country>
        </postal>
        <phone>+91-080-49160700</phone>
        <email>rabinarayans@huawei.com</email>
        <email>rabinarayans0828@gmail.com</email>
      </address>
    </author>
    <author initials="Z" surname="Cao" fullname="Zhen Cao">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street>W Chang'an Ave</street>
          <city>Beijing</city>
          <country>P.R. China</country>
          <country>China</country>
        </postal>
        <email>zhencao.ietf@gmail.com</email>
      </address>
    </author>

    <date/>

    <!-- If
    <date year="2021" month="April" />
    <keyword>NPDAO</keyword>
    <keyword>DCO</keyword>
    <keyword>no-path</keyword>
    <keyword>route</keyword>
    <keyword>cleanup</keyword>

    <abstract>
      <t>
        This document explains the month and year are both specified and are problems associated with the current ones, xml2rfc will fill use of
        No-Path Destination Advertisement Object (NPDAO) messaging in RFC 6550 and also discusses the current day requirements for you. If only the current year is specified, xml2rfc will fill
     in an optimized
        route invalidation messaging scheme. Further, this document specifies a new proactive route
        invalidation message called the current day and month "Destination Cleanup Object" (DCO),
        which fulfills requirements for you. If the year is not the current one, it is
     necessary to specify at least a month (xml2rfc assumes day="1" if not specified optimized route
        invalidation messaging.
      </t>
    </abstract>
  </front>
  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
      <t>
            RPL (the Routing Protocol for the
     purpose of calculating the expiry date). With drafts it is normally sufficient to
     specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>Routing</area>

    <workgroup>ROLL</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.
     If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>template</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>
        This document explains the problems associated with the current use of
        NPDAO messaging Low-Power and also discusses the requirements for an optimized
        route invalidation messaging scheme. Further a new proactive route
        invalidation message called Lossy Networks) as "Destination Cleanup Object" (DCO) is
        specified which fulfills requirements of an optimized route
        invalidation messaging.
      </t>
    </abstract>
  </front>

<middle>
    <section title="Introduction">
        <t>
            RPL defined in
            <xref target="RFC6550"/> (Routing Protocol for Low power and
            lossy networks) target="RFC6550" format="default"/>
            specifies a proactive distance-vector based distance-vector-based routing
            scheme. RPL has optional messaging in the form of DAO
            (Destination Advertisement Object) messages, which the 6LBR (6Lo (6LoWPAN Border Router) and 6LR (6Lo (6LoWPAN Router) can use to learn a route
            towards the downstream nodes. ("6LoWPAN" stands for "IPv6 over Low-Power Wireless Personal Area Network".) In storing Storing mode, DAO messages would
            result in routing entries being created on all intermediate 6LRs
            from the a node's parent all the way towards the 6LBR.
      </t>
      <t>
            RPL allows the use of No-Path DAO (NPDAO) messaging to invalidate a
            routing path corresponding to the given target, thus releasing
            resources utilized on that path. A An NPDAO is a DAO message with a
            route lifetime of zero, zero.  It originates at the target node and always
            flows upstream towards the 6LBR. This document explains the
            problems associated with the current use of NPDAO messaging in <xref target="RFC6550"/> and
            also discusses the requirements for an optimized route invalidation
            messaging scheme. Further Further, this document specifies a new proactive route invalidation
            message called as the "Destination Cleanup Object" (DCO) is specified (DCO),
            which fulfills requirements of an for optimized route invalidation
            messaging.
      </t>
      <t>
            The
            This document only caters to the RPL's storing mode Storing Mode of operation Operation
            (MOP). The non-storing Non-Storing MOP does not require the use of an NPDAO for route
            invalidation
            invalidation, since routing entries are not maintained on 6LRs.
      </t>
      <section title="Requirements numbered="true" toc="default">
        <name>Requirements Language and Terminology">
            <t>
                The Terminology</name>
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
                NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
                "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
        "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
        "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
        "<bcp14>SHOULD NOT</bcp14>",
        "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
        "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document
        are to be interpreted as described in BCP 14 BCP&nbsp;14
        <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
        when, they appear in all capitals, as shown here.
            </t> here.</t>
        <t>
                This specification requires readers to be familiar with all the
                terms and concepts that are discussed in "RPL: IPv6 Routing
                Protocol for Low-Power and Lossy Networks" <xref target="RFC6550"/>.
        </t>

            <t>
                <list style="hanging">
                    <t hangText="Low Power
        <dl newline="true" spacing="normal">
          <dt>Low-Power and Lossy Networks (LLN):"> <vspace /> Network (LLN):</dt>
          <dd>
              A network in which both the routers and their
                        interconnect
              interconnects are constrained. LLN routers typically
              operate with constraints on processing power, memory,
              and energy (batter (battery power). Their interconnects are
              characterized by high loss rates, low data rates, and
              instability.
                    </t>
                    <t hangText="6LoWPAN
          </dd>
          <dt>6LoWPAN Router (6LR):"> <vspace /> (6LR):</dt>
          <dd>
              An intermediate router that is able to send and receive Router
              Advertisements (RAs) and Router Solicitations (RSs) as well as
              forward and route IPv6 packets.
                    </t>
                    <t hangText="Directed
          </dd>
          <dt>Directed Acyclic Graph (DAG):"> <vspace /> (DAG):</dt>
          <dd>
              A directed graph having the property that all edges are
              oriented in such a way that no cycles exist.
                    </t>
                    <t hangText="Destination-Oriented
          </dd>
          <dt>Destination-Oriented DAG (DODAG):"> <vspace /> (DODAG):</dt>
          <dd>
              A DAG rooted at a single destination, i.e., at a single
              DAG root with no outgoing edges.
                    </t>
                    <t hangText="6LoWPAN
          </dd>
          <dt>6LoWPAN Border Router (6LBR):"> <vspace /> (6LBR):</dt>
          <dd>
              A border router which that is a DODAG root and is the edge
              node for traffic flowing in and out of the 6LoWPAN
                        network.
                    </t>
                    <t hangText="Destination 6LoWPAN.
          </dd>
          <dt>Destination Advertisement Object (DAO):"> <vspace /> (DAO):</dt>
          <dd>
              DAO messaging allows downstream routes to the nodes to
              be established.
                    </t>
                    <t hangText="DODAG
          </dd>
          <dt>DODAG Information Object (DIO):"> <vspace /> (DIO):</dt>
          <dd>
              DIO messaging allows upstream routes to the 6LBR to be
              established. DIO messaging is initiated at the DAO
              root.
                    </t>

                    <t hangText="Common Ancestor node"> <vspace />
          </dd>
          <dt>Common ancestor node:</dt>
          <dd>
              A 6LR/6LBR node which that is the first common node between
              two paths of a target node.
                    </t>

                    <t hangText="No-Path
          </dd>
          <dt>No-Path DAO (NPDAO):"> <vspace /> (NPDAO):</dt>
          <dd>
              A DAO message which that has a target with a lifetime 0 used of 0. Used for
              the purpose of route invalidation.
                    </t>

                    <t hangText="Destination
          </dd>
          <dt>Destination Cleanup Object (DCO):"> <vspace /> (DCO):</dt>
          <dd>
              A new RPL control message code defined by this
              document. DCO messaging improves proactive route
              invalidation in RPL.
                    </t>

                    <t hangText="Regular DAO:"> <vspace />
          </dd>
          <dt>Regular DAO:</dt>
          <dd>
              A DAO message with a non-zero lifetime. Routing
              adjacencies are created or updated based on this
              message.
                    </t>

                    <t hangText="Target node:"> <vspace />
          </dd>
          <dt>Target node:</dt>
          <dd>
              The node switching its parent whose routing adjacencies
              are updated (created/removed).
                    </t>
                </list>
            </t>
          </dd>
        </dl>
      </section>
      <section anchor="current_npdao" title="Current numbered="true" toc="default">
        <name>RPL NPDAO messaging"> Messaging</name>
        <t>
                RPL uses NPDAO messaging in the storing Storing mode so that the node
                changing its routing adjacencies can invalidate the previous
                route. This is needed so that nodes along the previous path can
                release any resources (such as the routing entry) they maintain
                on behalf of the target node.
        </t>
        <t>
                For the rest of
        Throughout this document consider document, we will refer to the following topology: topology shown in <xref target="sample_top"/>:
        </t>

            <t>
        <figure align="center" anchor="sample_top" title="Sample
                    topology"> anchor="sample_top">
          <name>Sample Topology</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
   (6LBR)
     |
     |
     |
    (A)
    / \
   /   \
  /     \
(G)     (H)
 |       |
 |       |
 |       |
(B)     (C)
  \      ;
   \    ;
    \  ;
     (D)
     / \
    /   \
   /     \
 (E)     (F)
                        ]]></artwork>     (F)]]></artwork>
        </figure> </t>
        <t>
                Node (D) D is connected via preferred parent (B). (D) B. D has an
                alternate path via (C) C towards the 6LBR. Node (A) A is the common
                ancestor for (D) D for paths through (B)-(G) B-G and (C)-(H). C-H. When
                (D)
                D switches from (B) B to (C), C, RPL allows sending an NPDAO to (B) B
                and a regular DAO to (C). C.
        </t>
      </section>

        <!--
        <section title="Cases when No-Path DAO may be used">
            <t> There are following cases in which a node switches its parent
                and may employ No-Path DAO messaging:</t>

            <t>Case I: Current parent becomes unavailable because of transient
                or permanent link or parent node failure.</t>

            <t>Case II: The node finds a better parent node i.e. the metrics of
                another parent is better than its current parent.</t>

            <t>Case III: The node switches to a new parent whom it "thinks" has
                a better metric but does not in reality.</t>

            <t>The usual steps of operation when the node switches the parent
                is that the node sends a No-Path DAO message via its current parent
                to invalidate its current route and subsequently it tries to
                establish a new routing path by sending a new DAO via its new
                parent.</t>
        </section>
        -->

        <section title="Why numbered="true" toc="default">
        <name>Why Is NPDAO Important?"> Messaging Important?</name>

        <t>
                Nodes
                Resources in LLNs may be resource LLN nodes are typically constrained. There is limited
                memory available available, and routing entry records are one of the
                primary elements occupying dynamic memory in the nodes. Route
                invalidation helps 6LR nodes to decide which routing entries could can be
                discarded to for better optimize resource utilization. Thus use of the limited resources. Thus, it
                becomes necessary to have an efficient route invalidation
                mechanism. Also note that a single parent switch may result in
                a "sub-tree" "subtree" switching from one parent to another. Thus Thus, the
                route invalidation needs to be done on behalf of the sub-tree subtree
                and not the switching node alone. In the above example, when
                Node (D) D switches its parent, the route updates needs need to be done
                for the routing tables table entries of (C),(H),(A),(G), C, H, A, G, and (B) B with
                destination (D),(E)
                destinations D, E, and (F). F. Without efficient route
                invalidation, a 6LR may have to hold a lot of stale route
                entries.
        </t>
      </section>
    </section>
    <section anchor="current_npdao_problems" title="Problems numbered="true" toc="default">
      <name>Problems with current the RPL NPDAO messaging"> Messaging</name>
      <section title="Lost numbered="true" toc="default">
        <name>Lost NPDAO due Due to link break Link Break to the previous parent"> Previous Parent</name>
        <t>
                When a node switches its parent, the NPDAO is to be sent to
                its previous parent and a regular DAO to its new parent. In
                cases where the node switches its parent because of transient
                or permanent parent link/node failure then failure, the NPDAO message is
                bound to fail.
            </t>
            <!--
            <t>
                RPL allows use of route lifetime to remove unwanted routes in
                case the routes could may
                not be refreshed. But route lifetimes in
                case of LLNs could be substantially high and thus received by the route
                entries would be stuck for longer times. parent.
        </t>
            -->
        </section>
      <section title="Invalidate numbered="true" toc="default">
        <name>Invalidating Routes of Dependent Nodes"> Nodes</name>
        <t>
                RPL does not specify how route invalidation will work for
                dependent nodes rooted at in the switching node, node subDAG, resulting in
                stale routing entries of the dependent nodes. The only way for a
                6LR to invalidate the route entries for dependent nodes would
                be to use route lifetime expiry expiry, which could be substantially
                high for LLNs.
        </t>
        <t>
                In the example topology, when Node (D) D switches its parent,
                Node (D) D generates an NPDAO on its own behalf. There is no NPDAO
                generated by the dependent child nodes (E) Nodes E and (F), F, through the
                previous path via (D) D to (B) B and (G), G, resulting in stale
                entries on nodes (B) Nodes B and (G) G for nodes (E) Nodes E and (F). F.
        </t>
      </section>
      <section title="Possible route downtime caused numbered="true" toc="default">
        <name>Possible Route Downtime Caused by asynchronous operation Asynchronous Operation of the NPDAO and DAO"> DAO</name>
        <t>
                A switching node may generate both an NPDAO and a DAO via two
                different paths at almost the same time. There It is a possibility possible
                that an the NPDAO generated may invalidate the previous route and
                the regular DAO sent via the new path gets lost on the way.
                This may result in route downtime downtime, impacting downward
                traffic for the switching node.
        </t>
        <t>
                In the example topology, consider say that Node (D) D switches from parent
                (B)
                B to (C). C. An NPDAO sent via the previous route may invalidate
                the previous route route, whereas there is no way to determine whether
                the new DAO has successfully updated the route entries on the
                new path.
        </t>
      </section>
    </section>
    <section title="Requirements anchor="requirements" numbered="true" toc="default">
      <name>Requirements for the NPDAO Optimization" anchor="requirements"> Optimization</name>
      <section title="Req#1: numbered="true" toc="default">
        <name>Req. #1: Remove messaging dependency Messaging Dependency on link the Link to the previous parent"> Previous  Parent</name>
        <t>
                When the switching node sends the NPDAO message to the previous
                parent, it is normal that the link to the previous parent is
                prone to failure (that's why the node decided to switch).
                Therefore, it is required that the route invalidation does not
                depend on the previous link which is prone to failure. The
                previous link referred here represents the link between the
                node and its previous parent (from whom the node is now
                disassociating).
            </t>
        </section>

        <section title="Req#2: Dependent nodes route invalidation on parent
            switching">
            <t>
                It should be possible to do route invalidation for dependent
                nodes rooted at the switching node.
            </t>
        </section>

        <section title="Req#3: Route invalidation should not impact data traffic">
            <t>
                While sending the NPDAO and DAO messages, it is possible that
                the NPDAO successfully invalidates the previous path, while the
                newly sent DAO gets lost (new path not set up successfully).
                This will result in downstream unreachability to the node
                switching paths. Therefore, it is desirable that the route
                invalidation is synchronized with the DAO to avoid the risk of
                route downtime.
            </t>
        </section>
    </section>

    <!--	Too Confusing section and may not be needed now... If required this can be added in Appendix.
    <section title="Existing Solution">
        <section title="NPDAO can be generated by the parent node who detects
        link failure to the child">
            <t>RPL states mechanisms which could be utilized to clear DAO
            states in a sub-DODAG. [RFC6550] Section 11.2.2.3 states "With DAO
            inconsistency loop recovery, a packet can be used to recursively
            explore and clean up the obsolete DAO states along a
            sub-DODAG".</t>

            <t>Thus in the sample topology in Figure 1, when Node (B) detects
            link failure to (D), (B) has an option of generating an NPDAO on
            behalf of Node (D) and its sub-childs, (E) and (F).</t>

            <t>This section explains why generation of an NPDAO in such cases
            may not function as desired. Primarily the DAO state information in
            the form of Path Sequence plays a major role here. Every target is
            associated with a Path Sequence number which relates to the latest
            state of the target. <xref target="RFC6550"/> Section 7.1 explains
            the semantics of Path Sequence number. The target node increments
            the Path Sequence number every time it generates a new DAO. The
            router nodes en-route utilize this Path Sequence number to decide
            the freshness of target information. If a non-target node has to
            generate an NPDAO then it could use following two possibilities
            with Path Sequence number: </t>

            <t>Let the Path Sequence number of old regular DAO that flowed
            through (B) be x. The subsequent regular DAO generated by Node (D)
            will have sequence number x+1.</t>

            <t>i. Node (B) uses the previous Path Sequence number from the
            regular DAO i.e. NPDAO(pathseq=x)</t>

            <t>ii. Node (B) increments the Path Sequence number i.e.
            NPDAO(pathseq=x+1)</t>

            <t>In case i, the NPDAO(pathseq=x) will be dropped by all the
            intermediate nodes since the semantics of Path Sequence number
            dictates that any DAO with an older Path Sequence number be
            dropped.</t>

            <t>In case ii, there is a risk that the NPDAO(pathseq=x+1)
            traverses up the DODAG and invalidates all the routes till the root
            and then the regular DAO(pathseq=x+1) from the target traverses
            upwards. In this case the regular DAO(pathseq=x+1) will be dropped
            from common ancestor node to the root. This will result in route
            downtime.</t>

            <t>Another problem with this scheme is its dependence on the
            upstream neighbor to detect that the downstream neighbor is
            unavailable. There are two possibilities by which such a detection
            might be put to work:</t>

            <t>i. There is P2P traffic from the previous sub-DODAG to any of
            nodes in the sub-tree which has switched the path. In the above
            example, lets consider that Node (G) has P2P traffic for either of
            nodes (D), (E), or (F). In this case, Node (B) will detect
            forwarding error while forwarding the packets from Node (B) node decided to (D).
            But dependence on P2P traffic may switch).
                Therefore, it is required that the route invalidation does not be an optimal way
                depend on the previous link, which is prone to solve
            this problem considering failure. The
                previous link referred to here represents the reactive approach of link between the scheme. The
            P2P traffic pattern might be sparse
                node and thus such a detection might
            kick-in too late.</t>

            <t>ii. The other case its previous parent (from which the node is where Node (B) explicitly employs some
            mechanism to probe directly attached downstream child nodes. Such
            kind of schemes are seldom used.</t> now
                disassociating).
        </t>
      </section>
      <section title="NPDAO can numbered="true" toc="default">
        <name>Req. #2: Route Invalidation for Dependent Nodes at the Parent Switching Node</name>
        <t>
                It should be generated once possible to do route invalidation for dependent
                nodes rooted at the link switching node.
        </t>
      </section>
      <section numbered="true" toc="default">
        <name>Req. #3: Route Invalidation Should Not Impact Data Traffic</name>
        <t>
                While sending the NPDAO and DAO messages, it is restored to possible that
                the NPDAO successfully invalidates the previous parent">
            <t>This scheme solves a specific scenario of transient links. The
            child path, while the
                newly sent DAO gets lost (new path not set up successfully).
                This will result in downstream unreachability to the node can detect
                switching paths. Therefore, it is desirable that the connection to previous parent route
                invalidation is
            restored and then transmit an NPDAO to synchronized with the previous parent DAO to
            invalidate avoid the route. This scheme is stateful, thus requires more
            memory and solves a specific scenario.</t> risk of
                route downtime.
        </t>
      </section>
    </section>
    -->
    <section title="Changes numbered="true" toc="default">
      <name>Changes to RPL signaling"> Signaling</name>
      <section title="Change numbered="true" toc="default">
        <name>Change in RPL route invalidation semantics"> Route Invalidation Semantics</name>
        <t>
                As described in <xref target="current_npdao"/>, target="current_npdao" format="default"/>, the NPDAO
                originates at the node changing to a new parent and traverses
                upstream towards the root. In order to solve the problems as
                mentioned
                discussed in <xref target="current_npdao_problems"/>, the target="current_npdao_problems" format="default"/>, this
                document adds a new proactive route invalidation message
                called the "Destination Cleanup Object" (DCO) that (DCO), which originates at a
                common ancestor node and flows downstream between the new and
                old path. The common ancestor node generates a DCO in when removing
                a next hop to a target -- for instance, as a delayed response to the change in the next-hop on
                receiving a regular DAO from another child node with
                updated a Path
                Sequence for the target. target that is the same or newer, in which case the DCO transmission is canceled.
        </t>
        <t>
                The 6LRs in the path for the DCO take action such action as route
                invalidation based on the DCO information and subsequently send
                another DCO with the same information downstream to the next
                hop.
                hop(s). This operation is similar to how the DAOs are handled on
                intermediate 6LRs in storing the Storing MOP in <xref target="RFC6550"/>. target="RFC6550" format="default"/>.
                Just like the DAO in storing the Storing MOP, the DCO is sent using link-local
                unicast source and destination IPv6 address. addresses. Unlike the DAO, which
                always travels upstream, the DCO always travels downstream.
        </t>
        <t>
                In <xref target="sample_top"/>, target="sample_top" format="default"/>, when node child Node D decides to
                switch the path from parent B to parent C, it sends a regular DAO to node Node C
                with reachability information containing the address of D as
                the target and an incremented Path Sequence. Node C will update
                the routing table based on the reachability information in the
                DAO and will in turn generate another DAO with the same reachability
                information and forward it to H. Node H also recursively follows the same
                procedure as Node C and forwards it to node Node A. When node Node A
                receives the regular DAO, it finds that it already has a
                routing table entry on behalf of the target address Target Address of node Node D.
                It finds however finds, however, that the next hop next-hop information for reaching
                node
                Node D has changed changed, i.e., node Node D has decided to change the
                paths. In this case, Node A A, which is the common ancestor node
                for node Node D along the two paths (previous and new), should can
                generate a DCO which that traverses the network downwards in over the
                old path to the network. target. Node A handles normal DAO forwarding to
                the 6LBR as required by <xref
                    target="RFC6550"/>. target="RFC6550" format="default"/>.
        </t>
      </section>
      <section title="Transit anchor="transit_opt_changes" numbered="true" toc="default">
        <name>Transit Information Option changes" anchor="transit_opt_changes"> Changes</name>
        <t>
                Every RPL message is divided into base message fields and
                additional Options options, as described in Section 6 of <xref
                target="RFC6550"/>. target="RFC6550" section="6" sectionFormat="of"/>. The base fields apply to the message as a
                whole
                whole, and options are appended to add message/use-case specific message-specific /
                use-case-specific
                attributes. As an example, a DAO message may be attributed by
                one or more "RPL Target" options which that specify that the reachability
                information is for the given targets. Similarly, a Transit
                Information option may be associated with a set of RPL Target
                options.
        </t>
        <t>
                This document specifies a change in the Transit Information Option option to
                contain the "Invalidate previous route" (I) flag. This 'I' flag signals
                the common ancestor node to generate a DCO on behalf of the
                target node with a RPL Status of 195 195, indicating that the address
                has moved. The 'I' flag is carried in the Transit Information
                Option
                option, which augments the reachability information for a given
                set of one or more RPL Target(s). Targets. A Transit Information Option option with the 'I' flag
                set should be carried in the DAO message when route
                invalidation is sought for the corresponding target(s). target or targets.
        </t>
        <t>
                Value 195 represents 'E' the 'U' and 'A' bit bits in RPL Status Status, to be set as
                per Figure 3 6 of <xref target="I-D.ietf-roll-unaware-leaves"/> target="RFC9010" format="default"/>,
                with the lower 6 bits with set to the 6LoWPAN Neighbor Discovery (ND)
                Extended Address Registration Option (EARO) Status value of 3
                indicating 'Moved' as per Table 1 of [RFC8505]. <xref target="RFC8505"/>.
        </t>
            <t>
        <figure align="center" anchor="transit_info_with_i"
                    title="Updated anchor="transit_info_with_i">
          <name>Updated Transit Information Option (New I flag
                    added)"> &apos;I&apos; Flag Added)</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type = 0x06 | Option Length |E|I|  Flags    | Path Control  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Sequence | Path Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        ]]></artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
        </figure> </t>
            <t>
                I

        <dl>
                <dt>I (Invalidate previous route) flag: The flag:</dt><dd>The 'I' flag is set by the
                target node to indicate to the common ancestor node that it
                wishes to invalidate any previous route between the two paths.
            </t>
              </dd>
        </dl>
        <t>
                <xref target="RFC6550"/> target="RFC6550" format="default"/> allows the parent address to be sent in
                the Transit Information Option option, depending on the mode of
                operation. MOP.
                In the case of storing mode of operation the Storing MOP, the field is
                usually not needed. In the case of a DCO, the parent address Parent Address field
                MUST NOT
                <bcp14>MUST NOT</bcp14> be included.
        </t>
        <t>
                The
                Upon receiving a DAO message with a Transit Information option that has the 'I' flag set,
                and as a delayed response removing a routing adjacency to the target indicated in the Transit Information option,
                the common ancestor node SHOULD <bcp14>SHOULD</bcp14> generate a DCO message in
                response
                to this 'I' flag when it sees that the routing
                adjacencies have changed for the target. next hop associated to that adjacency. The 'I' flag is
                intended to give the target node control over its own route
                invalidation, serving as a signal to request DCO generation.
        </t>
      </section>
      <section title="Destination numbered="true" toc="default">
        <name>Destination Cleanup Object (DCO)"> (DCO)</name>
        <t>
                A new ICMPv6 RPL control message code is defined by this
                specification and is referred to as the "Destination Cleanup Object"
                (DCO), which is used for proactive cleanup of state and routing
                information held on behalf of the target node by 6LRs. The DCO
                message always traverses downstream and cleans up route
                information and other state information associated with the
                given target.  The format of the DCO message is shown in
                <xref target="dco_obj"/>.
        </t>

            <t>
        <figure align="center" anchor="dco_obj"
                    title="DCO base object"> anchor="dco_obj">
          <name>DCO Base Object</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
 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|   Flags   |   RPL Status  | DCOSequence   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                            DODAGID(optional)                      DODAGID (optional)                       +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Option(s)...
+-+-+-+-+-+-+-+-+
                        ]]></artwork>
+-+-+-+-+-+-+-+-+]]></artwork>
        </figure> </t>

            <t>
                RPLInstanceID: 8-bit
        <dl>
               <dt> RPLInstanceID:</dt><dd>8-bit field indicating the topology instance
                associated with the DODAG, as learned from the DIO.
            </t>
            <t>
                K: The
        </dd>
        <dt>
                K:</dt><dd>The 'K' flag indicates that the recipient of a DCO message is
                expected to send a DCO-ACK back. If the DCO-ACK is not received
                even after setting the 'K' flag, an implementation may retry
                the DCO at a later time. The number of retries are is
                implementation and deployment dependent and are is expected to be
                kept similar with those used in to the number of DAO retries in <xref
                    target="RFC6550"/>. target="RFC6550" format="default"/>. <xref target="dco_retry"/> target="dco_retry" format="default"/> specifies
                the considerations for DCO retry. retries. A node receiving a DCO
                message without the 'K' flag set MAY <bcp14>MAY</bcp14> respond with a DCO-ACK,
                especially to report an error condition. An example error
                condition could be that the node sending the DCO-ACK does not
                find the routing entry for the indicated target. When the
                sender does not set the 'K' flag flag, it is an indication that the
                sender does not expect a response, and the sender SHOULD NOT <bcp14>SHOULD NOT</bcp14>
                retry the DCO.
            </t>
            <t>
                D: The
        </dd>
        <dt>
                D:</dt><dd>The 'D' flag indicates that the DODAGID field is present.
                This flag MUST <bcp14>MUST</bcp14> be set when a local RPLInstanceID is used.
            </t>
            <t>
                Flags: The
        </dd>
        <dt>
                Flags:</dt><dd>The 6 bits remaining unused in the Flags field are
                reserved for future use. These bits MUST <bcp14>MUST</bcp14> be initialized to zero by
                the sender and MUST <bcp14>MUST</bcp14> be ignored by the receiver.
            </t>
            <t>
        </dd>
        <dt>
                RPL Status: As Status:</dt><dd>As defined in <xref target="RFC6550"/> target="RFC6550" format="default"/> and updated
                in <xref target="I-D.ietf-roll-unaware-leaves"/>. target="RFC9010" format="default"/>. The root or
                common parent that generates a DCO is authoritative for setting
                the status information information, and the information is unchanged as
                propagated down the DODAG. This document does not specify a
                differentiated action based on the RPL status.
            </t>
            <t>
                DCOSequence: 8-bit Status.
        </dd>
        <dt>
                DCOSequence:</dt><dd>8-bit field incremented at each unique DCO message
                from a node and echoed in the DCO-ACK message. The initial
                DCOSequence can be chosen randomly by the node. <xref
                    target="base_rules"/> target="base_rules" format="default"/> explains the handling of the
                DCOSequence.
            </t>
            <t>
        </dd>
        <dt>
                DODAGID (optional): 128-bit (optional):</dt><dd>128-bit unsigned integer set by a DODAG
                root that uniquely identifies a DODAG. This field MUST <bcp14>MUST</bcp14> be
                present when the 'D' flag is set and MUST NOT <bcp14>MUST NOT</bcp14> be present if the 'D'
                flag is not set. The DODAGID is used when a local RPLInstanceID is
                in use, in order to identify the DODAGID that is associated
                with the RPLInstanceID.
            </t>
              </dd>
        </dl>
        <section title="Secure DCO"> numbered="true" toc="default">
          <name>Secure DCO</name>
          <t>
          A Secure DCO message follows the format shown in <xref
                        target="RFC6550"/> target="RFC6550" format="default"/>, Figure 7, where the base message
          format is the DCO message shown in <xref
                        target="dco_obj"/>. target="dco_obj" format="default"/>
          of this document.
          </t>
        </section>
        <section title="DCO Options"> numbered="true" toc="default">
          <name>DCO Options</name>
          <t>
          The DCO message MUST <bcp14>MUST</bcp14> carry at least one RPL Target and the
          Transit Information Option option and MAY <bcp14>MAY</bcp14> carry other valid
          options. This specification allows for the DCO message to
          carry the following options:
                    <list>
                        <t>0x00 Pad1</t>
                        <t>0x01 PadN</t>
                        <t>0x05 RPL Target</t>
                        <t>0x06 Transit Information</t>
                        <t>0x09 RPL
          </t>
          <dl newline="false" spacing="compact">
            <dt>0x00</dt><dd>Pad1</dd>
            <dt>0x01</dt><dd>PadN</dd>
            <dt>0x05</dt><dd>RPL Target</dd>
            <dt>0x06</dt><dd>Transit Information</dd>
            <dt>0x09</dt><dd>RPL Target Descriptor</t>
                    </list>
                    Section 6.7 of Descriptor</dd>
          </dl>
          <t>
          <xref target="RFC6550"/> target="RFC6550" section="6.7" sectionFormat="of"/> defines all the
                    above mentioned
          above-mentioned options. The DCO carries an a RPL Target
                    Option
          option and an associated Transit Information Option option with a
          lifetime of 0x00000000 to indicate a loss of reachability
          to that Target. target.
          </t>
        </section>
        <section title="Path numbered="true" toc="default">
          <name>Path Sequence number in the DCO"> DCO</name>
          <t>
          A DCO message may contain includes a Transit Information option for each invalidated path.
          The value of the Path Sequence counter in the Transit Information Option to identify option allows identification of the freshness of the DCO
                    message. The Path Sequence
          message versus the newest known to the 6LRs along the path being removed.
          If the DCO is generated by a common parent in response to a DAO message, then the Transit Information option in
          the DCO MUST <bcp14>MUST</bcp14> use the same value of the Path Sequence number present as found
          in the regular DAO message
                    when newest Transit Information option that was received for that target by the common parent.
          If a 6LR down the path receives a DCO with a Path Sequence that is generated not newer than
          the Path Sequence as known from a Transit Information option in response to a DAO message.
                    Thus if message, then the 6LR
          <bcp14>MUST NOT</bcp14> remove its current routing state, and it <bcp14>MUST NOT</bcp14> forward the DCO
          down a path where it is not newer. If the DCO is received by a newer, the 6LR and subsequently may
          retain a temporary state to ensure that a DAO that is received later
          with a Transit Information option with an old older sequence number, then number is ignored. A Transit Information option in a DAO message
          that is as new as or newer than that in a DCO wins, meaning that the path indicated in the DAO
                    MUST be ignored. is installed and the DAO is propagated. When the DCO is generated in response to propagated upon a
          DCO from an upstream parent, the Path Sequence MUST <bcp14>MUST</bcp14> be copied
          from the received DCO.
          </t>
        </section>
        <section title="Destination numbered="true" toc="default">
          <name>Destination Cleanup Option Acknowledgment (DCO-ACK)"> (DCO-ACK)</name>
          <t>
          The DCO-ACK message SHOULD <bcp14>SHOULD</bcp14> be sent as a unicast packet by a
          DCO recipient in response to a unicast DCO message with the 'K'
          flag set. If the 'K' flag is not set set, then the receiver of the
          DCO message MAY <bcp14>MAY</bcp14> send a DCO-ACK, especially to report an error
          condition. The format of the DCO-ACK message is shown in
          <xref target="dco_ack"/>.
          </t>
                <t>
          <figure align="center" anchor="dco_ack" title="DCO-ACK base
                        object"> anchor="dco_ack">
            <name>DCO-ACK Base Object</name>
            <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
 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 |D|   Flags     |  DCOSequence  | DCO-ACK Status|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                            DODAGID(optional)                      DODAGID (optional)                       +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                            ]]></artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
          </figure> </t>

                <t>
                    RPLInstanceID: 8-bit
          <dl>
          <dt>
          RPLInstanceID:</dt><dd>8-bit field indicating the topology instance
          associated with the DODAG, as learned from the DIO.
                </t>
                <t>
                    D: The
          </dd>
          <dt>
          D:</dt><dd>The 'D' flag indicates that the DODAGID field is present.
          This flag MUST <bcp14>MUST</bcp14> be set when a local RPLInstanceID is used.
                </t>
                <t>
                    Flags: 7-bit
          </dd>
          <dt>
          Flags:</dt><dd>7-bit unused field. The field MUST <bcp14>MUST</bcp14> be initialized to
          zero by the sender and MUST <bcp14>MUST</bcp14> be ignored by the receiver.
                </t>
                <t>
                    DCOSequence: 8-bit
          </dd>
          <dt>
          DCOSequence:</dt><dd>8-bit field. The DCOSequence in the DCO-ACK is
          copied from the DCOSequence received in the DCO message.
                </t>
                <t>
          </dd>
          <dt>
          DCO-ACK Status:</dt><dd>Indicates completion status. The DCO-ACK Status: Indicates Status field is defined based on Figure 6 of <xref target="RFC9010" format="default"/> defining the completion. RPL Status Format. A value StatusValue of 0 is
                    defined as
                    unqualified along with the 'U' bit set to 0 indicates Success / Unqualified acceptance in this specification. as per Figure 6 of <xref target="RFC9010" format="default"/>. A value StatusValue of 1
                    is
                    defined as "No routing-entry for with the Target found". The
                    remaining status values are reserved 'U' bit set to 1 indicates 'No routing entry' as rejection codes.
                </t>
                <t> defined in <xref target="rpl_reject_status" format="default"/> of this document.
          </dd>
          <dt>
          DODAGID (optional): 128-bit (optional):</dt><dd>128-bit unsigned integer set by a DODAG
          root that uniquely identifies a DODAG. This field MUST <bcp14>MUST</bcp14> be
          present when the 'D' flag is set and MUST NOT <bcp14>MUST NOT</bcp14> be present
          when the 'D' flag is not set. The DODAGID is used when a local
          RPLInstanceID is in use, in order to identify the DODAGID
          that is associated with the RPLInstanceID.
                </t>
                  </dd>
          </dl>
        </section>
        <section title="Secure DCO-ACK"> numbered="true" toc="default">
          <name>Secure DCO-ACK</name>
          <t>
          A Secure DCO-ACK message follows the format shown in <xref
                        target="RFC6550"/> target="RFC6550" format="default"/>, Figure 7, where the base message
          format is the DCO-ACK message shown in <xref
                        target="dco_ack"/>. target="dco_ack" format="default"/> of this document.
          </t>
        </section>
      </section>
      <section title="DCO anchor="base_rules" numbered="true" toc="default">
        <name>DCO Base Rules" anchor="base_rules">
            <t>
                <list style="numbers">
                    <t> Rules</name>
        <ol spacing="normal" type="1"><li>
              If a node sends a DCO message with newer or different
              information than the prior DCO message transmission, it
                        MUST
              <bcp14>MUST</bcp14> increment the DCOSequence field by at least one.
              A DCO message transmission that is identical to the
              prior DCO message transmission MAY <bcp14>MAY</bcp14> increment the
              DCOSequence field. The DCOSequence counter follows the
              sequence counter operation as defined in Section 7.2 of
              <xref target="RFC6550"/>.
                    </t>
                    <t> target="RFC6550" section="7.2" sectionFormat="of"/>.
          </li>
          <li>
              The RPLInstanceID and DODAGID fields of a DCO message
                        MUST be
              <bcp14>MUST</bcp14> have the same value values as that of those contained in the DAO message in
              response to which the DCO is generated on the common
              ancestor node.
                    </t>
                    <t>
          </li>
          <li>
              A node MAY <bcp14>MAY</bcp14> set the 'K' flag in a unicast DCO message to
              solicit a unicast DCO-ACK in response response, in order to
              confirm the attempt.
                    </t>
                    <t>
          </li>
          <li>
              A node receiving a unicast DCO message with the 'K'
              flag set SHOULD <bcp14>SHOULD</bcp14> respond with a DCO-ACK. A node
              receiving a DCO message without the 'K' flag set MAY <bcp14>MAY</bcp14>
              respond with a DCO-ACK, especially to report an error
              condition.
                    </t>
                    <t>
          </li>
          <li>
              A node receiving a unicast DCO message MUST <bcp14>MUST</bcp14> verify the
              stored Path Sequence in context to the given target. If
              the stored Path Sequence is more fresh, as new as or newer than
              the Path Sequence received in the DCO, then the DCO
                        MUST
              <bcp14>MUST</bcp14> be dropped.
                    </t>
                    <t>
          </li>
          <li>
              A node that sets the 'K' flag in a unicast DCO message
              but does not receive a DCO-ACK in response MAY <bcp14>MAY</bcp14> reschedule
              the DCO message transmission for another attempt, up
              until an implementation specific implementation-specific number of retries.
                    </t>
                    <t>
          </li>
          <li>
              A node receiving a unicast DCO message with its own
              address in the RPL Target Option MUST strip-off option <bcp14>MUST</bcp14> strip off that
              Target Option. option. If this Target Option option is the only one in
              the DCO message message, then the DCO message MUST <bcp14>MUST</bcp14> be dropped.
                    </t>
                </list>
            </t>
          </li>
        </ol>
        <t>
                The scope of DCOSequence values is unique to the node which that
                generates it. them.
        </t>
      </section>
      <section title="Unsolicited DCO"> numbered="true" toc="default">
        <name>Unsolicited DCO</name>
        <t>
                A 6LR may generate an unsolicited DCO to unilaterally cleanup clean up
                the path on behalf of the target entry. The 6LR has all the
                state information, namely, the Target address Address and the Path
                Sequence, required for generating a DCO in its routing table.
                The conditions why under which a 6LR may generate an unsolicited DCO are
                beyond the scope of this document document, but some possible reasons
                could be:
                <list style="numbers">
                    <t> be as follows:
        </t>
        <ol spacing="normal" type="1"><li>
              On route expiry of an entry, a 6LR may decide to
              graciously cleanup clean up the entry by initiating a DCO.
                    </t>
                    <t>
          </li>
          <li>
              A 6LR needs to entertain higher priority higher-priority entries in case
              the routing table is full, thus resulting in eviction
              of an existing routing entry. In this case case, the eviction
              can be handled graciously by using a DCO.
                    </t>
                </list>
            </t>
          </li>
        </ol>
        <t>
          A DCO that is generated asynchronously to a DAO message and is meant to
          discard all state along the path regardless of the Path Sequence <bcp14>MUST</bcp14>
          use a Path Sequence value of 240 (see <xref target="RFC6550" section="7.2" sectionFormat="of"/>).
          This value allows the DCO to win against any established DAO path but
          to lose against a DAO path that is being installed.
          Note that if the 6LR an ancestor initiates a unilateral path cleanup on an
          established path using a DCO and if it has the latest state for the target then with a Path Sequence value of 240, the
          DCO
                would finally will eventually reach the target node. Thus the target node would node, which will thus be informed
          of its the path invalidation.
        </t>
      </section>
      <section title="Other considerations">
            <section title="Dependent Nodes invalidation"> numbered="true" toc="default">
        <name>Other Considerations</name>
        <section numbered="true" toc="default">
          <name>Invalidation of Dependent Nodes</name>
          <t>
                    Current
          The RPL specification <xref target="RFC6550"/> target="RFC6550" format="default"/> does not provide a
          mechanism for route invalidation for dependent nodes. This
          document allows the invalidation of dependent nodes invalidation. nodes. Dependent
          nodes will generate their respective DAOs to update their
          paths, and the previous route invalidation for those nodes
          should work in the similar a manner similar to what is described for a switching
          node. The dependent node may set the 'I' flag in the Transit
          Information Option option as part of a regular DAO so as to
          request invalidation of the previous route from the common
          ancestor node.
          </t>
          <t>
          Dependent nodes do not have any indication regarding if whether any
          of their parents have in turn have decided to switch their
          parent. Thus Thus, for route invalidation invalidation, the dependent nodes may
          choose to always set the 'I' flag in all its their DAO message's messages'
          Transit Information Option. options. Note that setting the 'I' flag is
          not counterproductive even if there is no previous
          route to be invalidated.
          </t>
        </section>
        <section title="NPDAO numbered="true" toc="default">
          <name>NPDAO and DCO in the same network"> Same Network</name>
          <t>
          The current NPDAO mechanism provided in <xref target="RFC6550"/> target="RFC6550" format="default"/> can
          still be used in the same network where a DCO is used. The
          NPDAO messaging can be used, for example, on route lifetime
          expiry of the target or when the node simply decides to
          gracefully terminate the RPL session on graceful node
          shutdown. Moreover, a deployment can have a mix of nodes
          supporting the DCO and the existing NPDAO mechanism. It is
          also possible that the same node supports both the NPDAO
          and DCO signaling for route invalidation.
          </t>
          <t>
                    Section 9.8 of
          <xref target="RFC6550"/> target="RFC6550" section="9.8" sectionFormat="of"/> states, "When a
          node removes a node from its DAO parent set, it SHOULD <bcp14>SHOULD</bcp14>
          send a No-Path DAO message (Section 6.4.3) to that removed DAO parent to
          invalidate the existing router". route." This document introduces
          an alternative and more optimized way of to perform route invalidation invalidation,
          but it also allows existing NPDAO messaging to work. Thus Thus,
          an implementation has two choices to make when a route
          invalidation is to be initiated:
          </t>
                <t>
                    <list style="numbers">
                        <t>
          <ol spacing="normal" type="1"><li>
                  Use an NPDAO to invalidate the previous route route, and
                  send a regular DAO on the new path.
                        </t>
                        <t>
              </li>
            <li>
                  Send a regular DAO on the new path with the 'I'
                  flag set in the Transit Information Option option such
                  that the common ancestor node initiates the DCO
                  message downstream to invalidate the previous
                  route.
                        </t>
                    </list>
                </t>
              </li>
          </ol>
          <t>
          This document recommends using option 2 2, for the reasons
          specified in <xref target="requirements"/> in target="requirements" format="default"/>
          of this document.
          </t>
          <t>
          This document assumes that all the 6LRs in the network
          support this specification. If there are 6LRs en-route DCO
                    message path which there are 6LR nodes that do not support this document, document that are in the path of the DCO message transmission, then the
          route invalidation for the corresponding targets (targets that are in the DCO message) may not work
          or may work partially i.e., only part of the path
                    supporting DCO may be invalidated. partially. Alternatively, a node
          could generate an NPDAO if it does not receive a DCO with
          itself as the target within a specified time limit. The specified
          time limit is deployment specific and depends upon the
          maximum depth of the network and per hop per-hop average latency.
          Note that sending an NPDAO and a DCO for the same operation
          would not result in unwanted side-effects side effects because the
          acceptability of an NPDAO or a DCO depends upon the Path
          Sequence freshness.
          </t>
        </section>
        <section title="Considerations anchor="dco_retry" numbered="true" toc="default">
          <name>Considerations for DCO retry" anchor="dco_retry"> Retries</name>
          <t>
          A DCO message could be retried by a sender if it sets the
          'K' flag and does not receive a DCO-ACK. The DCO retry time
          could be dependent on the maximum depth of the network and
          average per hop per-hop latency. This could range from 2 seconds to
          120 seconds seconds, depending on the deployment. In case If the
          latency limits are not known, an implementation MUST NOT <bcp14>MUST NOT</bcp14>
          retry more than once in 3 seconds and MUST NOT <bcp14>MUST NOT</bcp14> retry more
          than 3 three times.
          </t>
          <t>
          The number of retries could also be set depending on how
          critical the route invalidation could be for the deployment
          and the link layer link-layer retry configuration. For networks
          supporting only MP2P Multi-Point to Point (MP2P) and P2MP Point-to-Multipoint (P2MP) flows, such as in AMI Advanced Metering Infrastructure (AMI) and
          telemetry applications, the 6LRs may not be very keen to
          invalidate routes, unless they are highly
                    memory-constrained.
          memory constrained. For home and building automation
          networks which that may have substantial P2P traffic, the 6LRs
          might be keen to invalidate efficiently because it may
          additionally impact the forwarding efficiency.
          </t>
        </section>
        <section title="DCO with multiple preferred parents"> numbered="true" toc="default">
          <name>DCO with Multiple Preferred Parents</name>
          <t>
          <xref target="RFC6550"/> target="RFC6550" format="default"/> allows a node to select multiple
          preferred parents for route establishment. Section 9.2.1
                    of
          <xref target="RFC6550"/> target="RFC6550" section="9.2.1" sectionFormat="of"/> specifies, "All DAOs generated
          at the same time for the same Target MUST target <bcp14>MUST</bcp14> be sent with the
          same Path Sequence in the Transit Information".
                    Subsequently Information."
          Subsequently, when route invalidation has to be initiated,
                    RPL mentions use of NPDAO
          an NPDAO, which can be initiated with an
          updated Path Sequence to all the parent nodes through which
          the route is to be invalidated. invalidated, can be used; see <xref target="RFC6550"/>.
          </t>
          <t>
          With a DCO, the Target target node itself does not initiate the
          route invalidation and it invalidation; this is left to the common ancestor
          node. A common ancestor node when it discovers an updated
          DAO from a new next-hop, next hop, it initiates a DCO. With multiple
                    preferred parents, this handling does not change. But in
                    this case it It is recommended
          that an implementation
                    initiates initiate a DCO after a time period (DelayDCO) such that
          the common ancestor node may receive updated DAOs from all
          possible next-hops. next hops. This will help to reduce DCO control
                    overhead
          overhead, i.e., the common ancestor can wait for updated
          DAOs from all possible directions before initiating a DCO
          for route invalidation. After timeout, the DCO needs to be
          generated for all the next-hops next hops for whom which the route
          invalidation needs to be done.
          </t>
          <t>
          This document recommends using a DelayDCO timer value of
                    1sec.
          1 second. This value is inspired by the default DelayDAO timer value
          of 1sec in 1 second <xref target="RFC6550"/>. Here target="RFC6550" format="default"/>. Here, the hypothesis is
          that the DAOs from all possible parent sets would be
          received on the common ancestor within this time period.
          </t>
          <t>
          It is still possible that a DCO is generated before all the
          updated DAOs from all the paths are received. In this case,
          the ancestor node would start the invalidation procedure
          for paths from which the updated DAO is not received. The
          DCO generated in this case would start invalidating the
          segments along these paths on which the updated DAOs are
          not received. But once the DAO reaches these segments, the
          routing state would be updated along these segments and segments; this
          should not lead to any inconsistent routing state. states.
          </t>
          <t>
          Note that there is no requirement for synchronization
          between a DCO and DAOs. The DelayDCO timer simply ensures
          that the DCO control overhead can be reduced and is only
          needed when the network contains nodes using multiple
          preferred parent. parents.
          </t>
        </section>
      </section>
    </section>
    <section anchor="Acknowledgments" title="Acknowledgments">
        <t>
            Many thanks to Alvaro Retana, Cenk Gundogan, Simon Duquennoy, Georgios
            Papadopoulous, Peter Van Der Stok for their review and comments.
            Alvaro Retana helped shape this document's final version with
            critical review comments.
        </t>
    </section>

    <!-- Possibly a 'Contributors' section ... -->

    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
      IANA is requested to allocate new has allocated codes for the DCO and DCO-ACK
      messages from the RPL "RPL Control Codes Codes" registry.
      </t>

        <texttable title="">
            <ttcol align='center'>Code</ttcol>
            <ttcol align='center'>Description</ttcol>
            <ttcol align='center'>Reference</ttcol>

            <c>TBD1</c>
            <c>Destination
      <table align="center">
        <name>New Codes for DCO and DCO-ACK Messages</name>
        <thead>
          <tr>
            <th align="center">Code</th>
            <th align="center">Description</th>
            <th align="center">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="center">0x07</td>
            <td align="center">Destination Cleanup Object</c>
            <c>This document</c>
            <c>TBD2</c>
            <c>Destination Object</td>
            <td align="center">This document</td>
          </tr>
          <tr>
            <td align="center">0x08</td>
            <td align="center">Destination Cleanup Object Acknowledgment</c>
            <c>This document</c>
            <c>TBD3</c>
            <c>Secure Acknowledgment</td>
            <td align="center">This document</td>
          </tr>
          <tr>
            <td align="center">0x87</td>
            <td align="center">Secure Destination Cleanup Object</c>
            <c>This document</c>
            <c>TBD4</c>
            <c>Secure Object</td>
            <td align="center">This document</td>
          </tr>
          <tr>
            <td align="center">0x88</td>
            <td align="center">Secure Destination Cleanup Object Acknowledgment</c>
            <c>This document</c>
        </texttable> Acknowledgment</td>
            <td align="center">This document</td>
          </tr>
        </tbody>
      </table>

      <t>
            IANA is requested to allocate has allocated bit 1 from the Transit "Transit Information
            Option Flags Flags" registry for the 'I' flag (<xref target="transit_opt_changes"/>) (Invalidate previous route; see <xref target="transit_opt_changes" format="default"/>).
      </t>
      <section title="New numbered="true" toc="default">
        <name>New Registry for the Destination Cleanup Object (DCO) Flags">
            <t>
                IANA is requested to create a registry for the 8-bit Destination Cleanup
                Object (DCO) Flags field. This registry should be located in
                existing category of "Routing Protocol for Low Power and Lossy
                Networks (RPL)".
            </t>
            <t>
                New bit numbers may be allocated only by an IETF Review. Each
                bit is tracked with the following qualities:
            </t>
            <t>
                <list style="symbols">
                    <t>Bit number (counting from bit 0 as the most significant bit)</t>
                    <t>Capability description</t>
                    <t>Defining RFC</t>
                </list>
            </t>
            <t>
                The following bits are currently defined:
            </t>
            <texttable title="DCO Base Flags">
                <ttcol align='center'>Bit number</ttcol>
                <ttcol align='center'>Description</ttcol>
                <ttcol align='center'>Reference</ttcol>
                <c>0</c>
                <c>DCO-ACK request (K)</c>
                <c>This document</c>

                <c>1</c>
                <c>DODAGID field is present (D)</c>
                <c>This document</c>
            </texttable>
        </section>
        <section title="New Registry for the Destination Cleanup Object Acknowledgment (DCO-ACK) Status field"> Flags</name>
        <t>
                IANA is requested to create
                IANA has created a registry for the 8-bit Destination Cleanup
                Object Acknowledgment (DCO-ACK) Status (DCO) Flags field. This The "Destination Cleanup Object
                (DCO) Flags" registry
                should be is located in existing category of the "Routing Protocol for
                Low Power and Lossy Networks (RPL)". (RPL)" registry.
        </t>
        <t>
                New Status values bit numbers may be allocated only by an IETF Review. Review
                <xref target="RFC8126"/>. Each
                value
                bit is tracked with the following qualities:
        </t>
            <t>
                <list style="symbols">
                    <t>Status Code</t>
                    <t>Description</t>
                    <t>Defining RFC</t>
                </list>
            </t>
        <ul spacing="normal">
          <li>Bit number (counting from bit 0 as the most significant bit)</li>
          <li>Capability description</li>
          <li>Defining RFC</li>
        </ul>
        <t>
                The following values bits are currently defined:
        </t>
            <texttable title="DCO-ACK Status Codes">
                <ttcol align='center'>Status Code</ttcol>
                <ttcol align='center'>Description</ttcol>
                <ttcol align='center'>Reference</ttcol>
                <c>0</c>
                <c>Unqualified acceptance</c>
                <c>This document</c>
                <c>1</c>
                <c>No routing-entry for the indicated Target found</c>
                <c>This document</c>
            </texttable>
        <table align="center">
          <name>DCO Base Flags</name>
          <thead>
            <tr>
              <th align="center">Bit number</th>
              <th align="center">Description</th>
              <th align="center">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">0</td>
              <td align="center">DCO-ACK request (K)</td>
              <td align="center">This document</td>
            </tr>
            <tr>
              <td align="center">1</td>
              <td align="center">DODAGID field is present (D)</td>
              <td align="center">This document</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section title="New numbered="true" toc="default">
        <name>New Registry for the Destination Cleanup Object (DCO) Acknowledgment Flags"> Flags</name>
        <t>
                IANA is requested to create has created a registry for the 8-bit
                Destination Cleanup Object (DCO) Acknowledgment Flags field.
                This
                The "Destination Cleanup Object (DCO) Acknowledgment Flags" registry should be
                is located in existing category of the
                "Routing Protocol for Low Power and Lossy Networks (RPL)". (RPL)" registry.
        </t>
        <t>
                New bit numbers may be allocated only by an IETF Review. Review
                <xref target="RFC8126"/>. Each
                bit is tracked with the following qualities:
        </t>
            <t>
                <list style="symbols">
                    <t>Bit
        <ul spacing="normal">
          <li>Bit number (counting from bit 0 as the most significant bit)</t>
                    <t>Capability description</t>
                    <t>Defining RFC</t>
                </list>
            </t> bit)</li>
          <li>Capability description</li>
          <li>Defining RFC</li>
        </ul>
        <t>
                The following bits are bit is currently defined:
        </t>
            <texttable title="DCO-ACK
        <table align="center">
          <name>DCO-ACK Base Flags">
                <ttcol align='center'>Bit number</ttcol>
                <ttcol align='center'>Description</ttcol>
                <ttcol align='center'>Reference</ttcol>
                <c>0</c>
                <c>DODAGID Flag</name>
          <thead>
            <tr>
              <th align="center">Bit number</th>
              <th align="center">Description</th>
              <th align="center">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">0</td>
              <td align="center">DODAGID field is present (D)</c>
                <c>This document</c>
            </texttable> (D)</td>
              <td align="center">This document</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="rpl_reject_status" numbered="true" toc="default">
        <name>RPL Rejection Status Values</name>
        <t>
           This document adds a new status value to the "RPL Rejection Status" subregistry initially created per <xref target="RFC9010" sectionFormat="of" section="12.6"/>.
        </t>
        <table align="center">
          <name>Rejection Value of the RPL Status</name>
          <thead>
            <tr>
              <th align="center">Value</th>
              <th align="center">Meaning</th>
              <th align="center">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">1</td>
              <td align="center">No routing entry</td>
              <td align="center">This document</td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
            This document introduces the ability for a common ancestor node to
            invalidate a route on behalf of the target node. The common
            ancestor node could be directed to do so by the target node node, using
            the 'I' flag in a DCO's Transit Information Option. option. However, the common
            ancestor node is in a position to unilaterally initiate the route
            invalidation
            invalidation, since it possesses all the required state information,
            namely, the Target address Address and the corresponding Path Sequence.
            Thus
            Thus, a rogue common ancestor node could initiate such an
            invalidation and impact the traffic to the target node.
      </t>
      <t> The DCO carries a RPL Status value, which is informative. New Status
            values may be created over time time, and a node will ignore an unknown
            Status value. This enables the RPL Status field to be
            used as a cover channel. But the channel only works once once, since the
            message destroys its own medium, that is i.e., the existing route that it
            is removing.
      </t>
      <t>
            This document also introduces an 'I' flag flag, which is set by the target
            node and used by the ancestor node to initiate a DCO if the
            ancestor sees an update in the route routing adjacency. However,
            this flag could be spoofed by a malicious 6LR in the path and can
            cause invalidation of an existing active path. Note that invalidation
            will happen work only if the other conditions such as Path Sequence condition is also met. met for the
            target for which the invalidation is attempted. Having said that, such a malicious 6LR may
            spoof a DAO on behalf of the (sub) child with the 'I' flag set and
            can cause route invalidation on behalf of the (sub) child node.
            Note that, that by using existing mechanisms offered by <xref
                target="RFC6550"/>, target="RFC6550" format="default"/>, a malicious 6LR might also spoof a DAO with a
            lifetime of zero or otherwise cause denial of service by dropping
            traffic entirely, so the new mechanism described in this document
            does not present a substantially increased risk of disruption.
      </t>
      <t>
            This document assumes that the security mechanisms as defined in
            <xref target="RFC6550"/> target="RFC6550" format="default"/> are followed, which means that the common
            ancestor node and all the 6LRs are part of the RPL network because
            they have the required credentials. A non-secure RPL network needs
            to take into consideration the risks highlighted in this section as
            well as those highlighted in <xref target="RFC6550"/>. target="RFC6550" format="default"/>.
      </t>
      <t>
            All RPL messages support a secure version of messages which messages; this allows
            integrity protection using either a MAC Message Authentication Code (MAC) or a signature. Optionally,
            secured RPL messages also have encryption protection for
            confidentiality.
      </t>
      <t>
            The
            This document adds new messages (DCO, (DCO and DCO-ACK) which that are
            syntactically similar to existing RPL messages such as DAO, DAO and
            DAO-ACK. Secure versions of DCO and DCO-ACK messages are added in a way that is similar to the technique used for other RPL messages (such as DAO, DAO and DAO-ACK).
      </t>
      <t>
            RPL supports three security modes modes, as mentioned in Section 10.1 of
            <xref target="RFC6550"/>:
            <list style="numbers">
                <t>
                    Unsecured: In target="RFC6550" section="10.1" sectionFormat="of"/>:
      </t>

      <dl newline="false" spacing="normal">
          <dt>Unsecured:</dt><dd>In this mode, it is expected that the RPL control messages
          are secured by other security mechanisms, such as
          link-layer security. In this mode, the RPL control messages,
          including DCO, DCO-ACK, DCO and DCO-ACK messages, do not have Security sections.
          Also note that unsecured mode does not imply that all
          messages are sent without any protection.
                </t>
                <t>
                    Preinstalled: In this mode, RPL uses secure messages. Thus
                    secure versions of DCO, DCO-ACK MUST be used in this mode.
                </t>
                <t>
                    Authenticated: In protection.</dd>
          <dt>Preinstalled:</dt><dd>In this mode, RPL uses secure messages. Thus
                    secure versions of DCO, DCO-ACK MUST be used in this mode.
                </t>
            </list>
        </t>
    </section>
</middle>

<back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set uses secure messages. Thus,
          secure versions of directories to search. These can DCO and DCO-ACK messages <bcp14>MUST</bcp14> be either used in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">
        <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
        &RFC6550;
        &RFC2119;
        &RFC8174;
    <?rfc include='reference.I-D.ietf-roll-unaware-leaves.xml'?> this mode.</dd>
          <dt>Authenticated:</dt><dd>In this mode, RPL uses secure messages. Thus,
          secure versions of DCO and DCO-ACK messages <bcp14>MUST</bcp14> be used in this mode.</dd>
      </dl>
    </section>
  </middle>
  <back>
    <references>
      <name>Normative References</name>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6550.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8505.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>

<!-- draft-ietf-roll-unaware-leaves (RFC 9010) -->
<reference anchor='RFC9010' target="https://www.rfc-editor.org/info/rfc9010">
<front>
<title>Routing for RPL (Routing Protocol for Low-Power and Lossy Networks) Leaves</title>
<author initials='P' surname='Thubert' fullname='Pascal Thubert' role="editor">
    <organization />
</author>
<author initials='M' surname='Richardson' fullname='Michael Richardson'>
    <organization />
</author>
<date month='April' year='2021' />
</front>
<seriesInfo name="RFC" value="9010"/>
<seriesInfo name="DOI" value="10.17487/RFC9010"/>
</reference>

    </references>
    <section anchor="app-additional" title="Example Messaging">
        <section title="Example numbered="true" toc="default">
      <name>Example Messaging</name>
      <section numbered="true" toc="default">
        <name>Example DCO Messaging"> Messaging</name>
        <t>
            In <xref target="sample_top"/>, node (D) this example, Node D (<xref target="sample_top" format="default"/>)
            switches its parent from
            (B)
            B to (C). C. This example assumes that Node D has already
            established its own route via Node B-G-A-6LBR using pathseq=x. The
            example uses DAO and DCO messaging convention conventions and specifies only
            the required parameters to explain the example example, namely, the
            parameter 'tgt', which stands for Target Option and "Target option"; the value of this
            parameter specifies the address of the target node. The parameter
            'pathseq', which
            'pathseq' specifies the Path Sequence value carried in the
            Transit Information Option. The option, and the parameter 'I_flag' specifies the
            'I' flag in the Transit Information Option. option. The
            sequence of actions is as follows:
            <list style="numbers">
                <t>Node
        </t>
        <ol spacing="normal" type="1"><li>Node D switches its parent from node Node B to node C</t>

                <t>D Node C.</li>
          <li>D sends a regular DAO(tgt=D,pathseq=x+1,I_flag=1) in the
          updated path to C</t>

                <t>C C.</li>
          <li>C checks for a routing entry on behalf of D, D; since it cannot
          find an entry on behalf of D D, it creates a new routing entry
          and forwards the reachability information of the target D
          to H in a DAO(tgt=D,pathseq=x+1,I_flag=1).</t>

                <t>Similar DAO(tgt=D,pathseq=x+1,I_flag=1).</li>
          <li>Similar to C, node Node H checks for a routing entry on behalf of
          D, cannot find an entry entry, and hence creates a new routing
          entry and forwards the reachability information of the
          target D to A in a DAO(tgt=D,pathseq=x+1,I_flag=1).</t>

                <t> DAO(tgt=D,pathseq=x+1,I_flag=1).</li>
          <li>
          Node A receives the DAO(tgt=D,pathseq=x+1,I_flag=1), DAO(tgt=D,pathseq=x+1,I_flag=1) and
          checks for a routing entry on behalf of D. It finds a
          routing entry but checks that the next hop for target D is
          different (i.e., Node G). Node A checks the I_flag and
          generates the DCO(tgt=D,pathseq=x+1) to the previous next hop for
          target D D, which is G. Subsequently, Node A updates the
          routing entry and forwards the reachability information of
          target D upstream using the DAO(tgt=D,pathseq=x+1,I_flag=1).
                </t>

                <t>
                </li>
          <li>
          Node G receives the DCO(tgt=D,pathseq=x+1). It checks to see if
          the received path sequence Path Sequence is later than the stored path
                    sequence. Path
          Sequence. If it is later, Node G invalidates the routing entry
          of target D and forwards the (un)reachability information
          downstream to B in the DCO(tgt=D,pathseq=x+1).
                </t>

                <t>
                </li>
          <li>
          Similarly, B processes the DCO(tgt=D,pathseq=x+1) by
          invalidating the routing entry of target D and forwards the
          (un)reachability information downstream to D.
                </t>

                <t>
                </li>
          <li>
          D ignores the DCO(tgt=D,pathseq=x+1) DCO(tgt=D,pathseq=x+1), since the target is
          itself.
                </t>

                <t>
                </li>
          <li>
          The propagation of the DCO will stop at any node where the
          node does not have an routing information associated with
          the target. If cached routing information is present and
          the cached Path Sequence is higher than the value in the
          DCO, then the DCO is dropped.
                </t>

            </list>
            </t>
                </li>
        </ol>
      </section>
      <section title="Example numbered="true" toc="default">
        <name>Example DCO Messaging with Multiple Preferred Parents</name>

        <t>
                As shown in <xref target="sample_top_mpp" format="default"/>, node (N41) selects multiple
                preferred parents">
            <t> parents (N32) and (N33).
                The sequence of actions is listed below the figure.
        </t>

        <figure align="center" anchor="sample_top_mpp" title="Sample
                    topology 2"> anchor="sample_top_mpp">
          <name>Sample Topology 2</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
       (6LBR)
         |
         |
         |
       (N11)
        / \
       /   \
      /     \
   (N21)   (N22)
     /      / \
    /      /   \
   /      /     \
(N31)  (N32)  (N33)
    :    |    /
     :   |   /
      :  |  /
        (N41)
                        ]]></artwork>
       (N41)]]></artwork>
        </figure> </t>
            <t>
                In <xref target="sample_top_mpp"/>, node (N41) selects multiple
                preferred parents (N32) and (N33).
                The sequence of actions is as follows:
                <list style="numbers">
                    <t>
        <ol spacing="normal" type="1"><li>
              (N41) sends a DAO(tgt=N41,PS=x,I_flag=1) to (N32) and (N33).
                        Here I_flag
              Here, 'I_flag' refers to the Invalidation flag flag, and PS 'PS' refers to
              the Path Sequence in the Transit Information option.
                    </t>

                    <t>
          </li>
          <li>
              (N32) sends the DAO(tgt=N41,PS=x,I_flag=1) to (N22). (N33) also
              sends the DAO(tgt=N41,PS=x,I_flag=1) to (N22). (N22) learns
              multiple routes for the same destination (N41) through
              multiple next-hops. next hops. (N22) may receive the DAOs from
              (N32) and (N33) in any order with the I_flag set. The
              implementation should use the DelayDCO timer to wait to
              initiate the DCO. If (N22) receives an updated DAO from
              all the paths paths, then the DCO need not be initiated in
              this case. Thus Thus, the route routing table at N22 should contain
              (Dst,NextHop,PS): { (N41,N32,x), (N41,N33,x) }.
                    </t>

                    <t>
          </li>
          <li>
              (N22) sends the DAO(tgt=N41,PS=x,I_flag=1) to (N11).
                    </t>

                    <t>
          </li>
          <li>
              (N11) sends the DAO(tgt=N41,PS=x,I_flag=1) to (6LBR). Thus Thus, the
              complete path is established.
                    </t>

                    <t>
          </li>
          <li>
              (N41) decides to change the preferred parent set from {
                        N32, N33 }
              {&nbsp;N32,&nbsp;N33&nbsp;} to { N31, N32 }.
                    </t>

                    <t>
          </li>
          <li>
              (N41) sends the DAO(tgt=N41,PS=x+1,I_flag=1) to (N32). (N41)
              sends the DAO(tgt=N41,PS=x+1,I_flag=1) to (N31).
                    </t>

                    <t>
          </li>
          <li>
              (N32) sends the DAO(tgt=N41,PS=x+1,I_flag=1) to (N22).
              (N22) has multiple routes to destination (N41). It sees
              that a new Path Sequence for Target=N41 is received and
              thus it waits for pre-determined a predetermined time period (DelayDCO (the DelayDCO
              time period) to invalidate another route
                        {(N41),(N33),x}. After
              { (N41),(N33),x }. &nbsp;After the time period, (N22) sends the
              DCO(tgt=N41,PS=x+1) to (N33). Also (N22) sends the
              regular DAO(tgt=N41,PS=x+1,I_flag=1) to (N11).
                    </t>

                    <t>
          </li>
          <li>
              (N33) receives the DCO(tgt=N41,PS=x+1). The received Path
              Sequence is the latest and thus it invalidates the entry
              associated with the target (N41). (N33) then sends the
              DCO(tgt=N41,PS=x+1) to (N41). (N41) sees itself as the
              target and drops the DCO.
                    </t>

                    <t>
          </li>
          <li>
              From Step 6 above, (N31) receives the
              DAO(tgt=N41,PS=x+1,I_flag=1). It creates a routing
              entry and sends the DAO(tgt=N41,PS=x+1,I_flag=1) to
              (N21). Similarly Similarly, (N21) receives the DAO and
              subsequently sends the DAO(tgt=N41,PS=x+1,I_flag=1) to
              (N11).
                    </t>

                    <t>
          </li>
          <li>
              (N11) receives the DAO(tgt=N41,PS=x+1,I_flag=1) from (N21).
              It waits for the DelayDCO timer timer, since it has multiple
              routes to (N41). (N41) will receive the
              DAO(tgt=N41,PS=x+1,I_flag=1) from (N22) from Step 7
              above. Thus Thus, (N11) has received the regular
              DAO(tgt=N41,PS=x+1,I_flag=1) from all paths and thus
              does not initiate the DCO.
                    </t>

                    <t>
          </li>
          <li>
              (N11) forwards the DAO(tgt=N41,PS=x+1,I_flag=1) to 6LBR (6LBR),
              and the full path is established.
                    </t>

            </list></t>
          </li>
        </ol>
      </section>
    </section>
    <section anchor="Acknowledgments" numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>
      Many thanks to <contact fullname="Alvaro Retana"/>, <contact fullname="Cenk Gundogan"/>, <contact fullname="Simon Duquennoy"/>, <contact fullname="Georgios Papadopoulos"/>, and <contact fullname="Peter van der Stok"/> for their review and comments.
            <contact fullname="Alvaro Retana"/> helped shape this document's final version with
            critical review comments.
      </t>
    </section>
  </back>
</rfc>