<?xml version='1.0' encoding='utf-8'?>

<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="no"?>
<?rfc subcompact="no"?>
<?rfc authorship="yes"?>
<?rfc tocappendix="yes"?> encoding='UTF-8'?>

<!DOCTYPE rfc [
 <!ENTITY nbsp    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy   "&#8209;">
 <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" ipr='trust200902' tocInclude="true" indexInclude="true" obsoletes=""  consensus="true" submissionType="IETF" xml:lang="en" version="3" docName="draft-ietf-roll-dao-projection-40" number="9914" updates="6550, 6553, 8138"> 8138" symRefs="true" sortRefs="false">

<!--[rfced] Please note that the document title has been updated as
follows. Abbreviations have been expanded per Section 3.6 of RFC
7322 ("RFC Style Guide"). Please review.

The short title that spans the header of the PDF file has also been
updated to more closely match the document title. Please let us know
of any objection.

Original (document title):
   Root-initiated Routing State in RPL

Current:
   Root-Initiated Routing State in the Routing Protocol for
   Low-Power and Lossy Networks (RPL)

...
Original (short title):
   DAO Projection

Current:
   Root-Initiated Routing State in RPL
-->

<front>
   <title abbrev='DAO Projection'>Root-initiated abbrev='Root-Initiated Routing State in RPL'>Root-Initiated Routing State in RPL</title> the Routing Protocol for Low-Power and Lossy Networks (RPL)</title>
   <seriesInfo name="RFC" value="9914"/>
   <author initials='P' surname='Thubert' fullname='Pascal Thubert' role='editor'>
      <!-- <organization abbrev='Cisco Systems'>Cisco Systems, Inc</organization> -->
      <address>
         <postal>
            <city>Roquefort-les-Pins</city>
            <code>06330</code>
          <country>France</country>
         </postal>
         <email>pascal.thubert@gmail.com</email>
      </address>
   </author>

    <author fullname="Rahul Arvind Jadhav" initials="R.A." surname="Jadhav">
        <organization>AccuKnox</organization>
        <address>
            <postal>
                <street>Kundalahalli Village, Whitefield,</street> Whitefield</street>
                <city>Bangalore</city>
                <region>Karnataka</region>
                <code>560037</code>
                <country>India</country>
            </postal>
            <phone>+91-080-49160700</phone>
            <email>rahul.ietf@gmail.com</email>
        </address>
    </author>

    <author fullname="Michael C. Richardson" initials="M."
            surname="Richardson">
      <organization abbrev="Sandelman">Sandelman Software Works</organization>

      <address>
        <email>mcr+ietf@sandelman.ca</email>

        <uri>http://www.sandelman.ca/</uri>
      </address>
    </author>

        <date/>

	<area>Routing</area>

	<workgroup>ROLL</workgroup>

        <date month="February" year="2026"/>

	<area>RTG</area>
	<workgroup>roll</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

<!-- [rfced] Because this document updates RFCs 6550 and 8138,
please review the errata reported for RFC 6550
(https://www.rfc-editor.org/errata/rfc6550) and RFC 8138
(https://www.rfc-editor.org/errata/rfc8138) and let us know
if you confirm our opinion that none of them are relevant
to the content of this document.
-->

        <abstract>
	  <t>
The
	  <t>The Routing Protocol for Low-Power and Lossy Networks (RPL, RFC (RPL) (RFC
	  6550) enables data packet routing along a Destination-Oriented
	  Directed Acyclic Graph . (DODAG). However, the default route establishment
	  mechanism relies on hop-by-hop forwarding along the DODAG, which may
	  not always provide optimal routing efficiency. This document
	  introduces the concept of DAO Destination Advertisement Object (DAO) Projection,
	  a mechanism that allows a
	  RPL root or an external controller to install optimized routes
	  within the RPL domain. DAO Projections enable the creation of
	  optimized unicast or multicast routes that do not strictly follow
	  the DODAG structure, thereby improving routing efficiency,
	  reliability, availability, and resource utilization in the RPL
	  domain. The This document specifies two types of projected routes—storing mode Projected Routes (P-Routes) -- Storing
	  Mode and Non-Storing Mode -- and
non-storing mode projections—and outlines the signaling
	  procedures necessary to establish, maintain, and remove these
	  routes.

This document extends RFC updates RFCs 6550, RFC 6553, and RFC 8138.
	  </t>
	</abstract>
    </front>

    <middle>

	<!-- **************************************************************** -->
	<!-- **************************************************************** -->
	<!-- **************************************************************** -->
	<!-- **************************************************************** -->

      <section anchor='introduction'><name>Introduction</name>

	   <t>

<!-- [rfced] We have two questions about the text below.

First, we believe the intention is to cite RFC 6550 as a
reference for the term "RPL", so we have updated the text
accordingly. If that is not correct and you would like to include
the exact title of RFC 6550 in quote marks instead, please let us
know.

Second, would using "as opposed to" rather than "versus" be more clear
in this context? Note that we included parentheses around the phrase
starting with "versus" to improve readability of this long sentence.

Original:
   RPL, the <xref target='RFC6550'> "Routing Protocol for Low Power and Lossy Networks"</xref> Networks" [RPL]
   (LLNs), is a Distance Vector protocol, which is well-suited for
   application in a variety of low energy Internet of Things (IoT)
   networks where constrained nodes cannot maintain the full view of the
   topology, and stretched P2P paths are acceptable vs. the signaling
   and state overhead involved in maintaining the shortest paths across.

Current:
   The Routing Protocol for Low Power and Lossy Networks (RPL) [RPL]
   is a Distance Vector protocol that is well-suited for application
   in a variety of low-energy Internet of Things (IoT) networks where
   constrained nodes cannot maintain the full view of the topology
   and stretched P2P paths are acceptable (versus the signaling and
   state overhead involved in maintaining the shortest paths across).

Perhaps:
   The Routing Protocol for Low Power and Lossy Networks (RPL) [RPL]
   is a Distance Vector protocol that is well-suited for application
   in a variety of low-energy Internet of Things (IoT) networks where
   constrained nodes cannot maintain the full view of the topology
   and stretched P2P paths are acceptable (as opposed to the signaling and
   state overhead involved in maintaining the shortest paths across).
-->

	   <t> The Routing Protocol for Low-Power and Lossy Networks (RPL) <xref target='RFC6550'/>,
   is a Distance Vector protocol that is well-suited
   for application in a variety of low-energy Internet of Things (IoT)
   networks where constrained nodes cannot maintain the full view of the
   topology and stretched P2P paths are acceptable (versus the signaling
   and state overhead involved in maintaining the shortest paths across).
   Additionally, RPL is anisotropic, meaning that its operation
   depends on the orientation of the links, down from or up towards the
   Root, with the default route advertised down and more specific more-specific paths
   advertised up along a limited set of links.
    </t>
<t>
   RPL forms Destination Oriented Destination-Oriented Directed Acyclic Graphs (DODAGs) in which
   the Root often acts as the Border border router to connect the RPL domain to the
   IP backbone. Routers inside the DODAG route along that the graph up towards
   the Root for the default route and down towards destinations in the RPL
   domain for more specific more-specific routes.
   This
   As a prerequisite, this specification expects as a pre-requisite a pre-existing RPL Instance
   with an associated DODAG and RPL Root, which are referred to as the main Instance,
   main DODAG DODAG, and main Root Root, respectively. The main Instance is operated in RPL
   Non-Storing Mode of Operation (MOP).
    </t>
<t>
   With this specification, an abstract routing function called a Path
   Computation Element (PCE) (e.g., located in a central
   controller or collocated with the main Root) interacts with the main Root to
   compute additional paths between nodes in the main Instance. In Non-Storing
   Mode, the base topological information to be passed to the PCE, that is i.e., the
   knowledge of the main DODAG, is already available at the Root.
   This specification introduces protocol extensions that enrich the topological
   information available to the Root with sibling relationships that are usable
   but not leveraged to form the main DODAG.
    </t>
<t>
   Based on usage, path length, and knowledge of available resources such as
   battery levels and reservable buffers in the nodes, the PCE with PCE, which has a global visibility of the system system, can optimize the computed routes for the
   application needs, including the capability to provide path redundancy.
   This specification also introduces protocol extensions that enable the
   Root to project (i.e., advertise from a remote location) the computed
   paths in the RPL domain as
   Projected Routes (a.k.a. P-Routes) on behalf of the PCE.
    </t>
       <t>
    A P-Route may be installed in either Storing or Non-Storing Mode,
    potentially resulting in hybrid situations where the Mode in which
    the P-Route operates is different from that of the RPL main Instance.

    P-Routes can be used as stand-alone segments meant to reduce the size of the
    source routing headers,
    Source Routing Headers (SRHs), leveraging loose source routing operations down the
    main RPL DODAG.

    A P-Route can also be used as a protection path, and it can be combined and interleaved with
    other P-Routes to form a Recovery Graph recovery graph called a Track.
    A Track is signaled as a separate RPL Instance that is associated with
    a main RPL Instance, Instance such that the RPL routers that form the Track
    are also members of the main DODAG.
    The Track provides underlay shortcuts using its own RIB, that which
    is separate from the RIB of the main Instance and has a higher precedence.
    </t>
    </section>

	<!-- **************************************************************** -->
	<!-- **************************************************************** -->
	<!-- **************************************************************** -->
	<!-- **************************************************************** -->

<section><name>Terminology</name>
<section anchor='bcp'><name>Requirements Language</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<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='RFC2119'/><xref target='RFC8174'/> target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>
<t>
  In addition, the terms "Extends" and "Amends" are used as per
  <xref target="I-D.kuehlewind-update-tag" /> section 3.
</t> section="3" sectionFormat="comma" target="I-D.kuehlewind-rswg-updates-tag" />.</t>

</section>
<!-- end section "Requirements Language" [rfced] Section 2.2 is titled "References". This may cause
confusion with Section 13, which is also titled "References".
Would you like to title Section 2.2 as "Terms and Concepts" or
other for clarity?

Original:
   2.2  References

Perhaps:
   2.2 Terms and Concepts
-->
  <section anchor='lo'><name>References</name>
  <t>

<!-- [rfced] To improve readability, may we update this text to be an
unordered list?

Original:
   In this document, readers will encounter terms and concepts that are
   discussed in the <xref target='RFC6550'>"Routing "Routing Protocol for Low Power and Lossy Networks"</xref>, Networks"
   [RPL], the <xref target='RFC9030'> "6TiSCH Architecture"</xref>, Architecture" [RFC9030], the <xref target='RFC8655'> "Deterministic
   Networking Architecture"</xref>, Architecture" [RFC8655], the <xref target='RFC9008'> "Using RPI Option Type,
   Routing Header for Source Routes, and IP-in-IP Encapsulation in the
   RPL Data Plane"</xref>, Plane" [RFC9008], the <xref target='I-D.ietf-raw-architecture'>"Reliable "Reliable and Available Wireless (RAW) Architecture"</xref>,
   Architecture" [RAW-ARCHI], and
    <xref target='RFC7102'>"Terminology "Terminology in Low power And Lossy Networks"</xref>.
   Networks" [RFC7102].

Perhaps:
   In this document, readers will encounter terms and concepts that are
   discussed in the following:

   * "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks" [RPL]

   * "An Architecture for IPv6 over the Time-Slotted Channel Hopping Mode
     of IEEE 802.15.4 (6TiSCH)" [RFC9030]

   * "Deterministic Networking Architecture" [RFC8655]

   * "Using RPI Option Type, Routing Header for Source Routes, and IPv6-in-IPv6
     Encapsulation in the RPL Data Plane" [RFC9008]

   * "Reliable and Available Wireless (RAW) Architecture" [RAW-ARCH]

   * "Terms Used in Routing for Low-Power and Lossy Networks" [RFC7102]
-->

	In this document, readers will encounter terms and concepts
	that are discussed in "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks" <xref target='RFC6550'></xref>; "An Architecture for IPv6 over the Time-Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)" <xref target='RFC9030'></xref>; "Deterministic Networking Architecture" <xref target='RFC8655'></xref>;
    "Using RPI Option Type, Routing Header for Source Routes, and IPv6-in-IPv6 Encapsulation in the RPL Data Plane" <xref target='RFC9008'></xref>; "Reliable and Available Wireless (RAW) Architecture" <xref target='RFC9912'></xref>; and
    "Terms Used in Routing for Low-Power and Lossy Networks" <xref target='RFC7102'></xref>.
    The 6TiSCH 6TiSCH, Deterministic Networking (DetNet), and DetNet/RAW RAW architectures utilize
    the terms "Track" and
    "Recovery Graph" "recovery graph" to represent the same concept even though they are in different environments.
    This document uses "Track" to represent that concept, concept and only builds
    Tracks that are DODAGs, meaning that all links are oriented from Ingress to Egress.
    This specification also utilizes the terms segment "segment" and protection path that "protection path", which are also
    defined in the RAW Architecture. architecture.
    </t>
    <t>
    As opposed to routing trees, RPL DODAGs are typically constructed
    to provide redundancy and dynamically adapt the forwarding operation to the
    state of the LLN Low-Power and Lossy Network (LLN) links. Note that the plain forwarding operation over DODAGs
    does not provide redundancy for all nodes, since at least the node nearest
    to the Root does not have an alternate feasible successor.
    </t>
    <t>
    RAW solves that problem by defining Protection Paths protection paths that can be interleaved
    to form new paths that can be activated dynamically upon failures.

<!-- [rfced] Please clarify "to take the routing decision". Is the
intended meaning "in order to make the routing decision"?

Original:
    This requires additional control to take the routing decision
    early enough along the Track to route around the failure.

Perhaps:
    This requires additional control in order to make the routing
    decision early enough along the Track to route around the
    failure.
-->

    This requires
    additional control to take the routing decision early enough along the Track
    to route around the failure.
    </t>
    <t>
    RAW only uses single-ended DODAGs, meaning that they can be reversed in
    another DODAG by reversing all the links. The Ingress of the Track is the
    Root of the DODAG, whereas the Egress is the Root of the reversed DODAG.
    From the RAW perspective, single-ended DODAGs are special Tracks that only
    have forward links, and that can be leveraged to provide Protection protection
    services by defining destination-oriented Protection Paths protection paths within the DODAG.
    </t>
  </section>	<!-- end section "References" -->

  <section anchor='gloss'><name>Glossary</name>

<!--[rfced] Questions related to the Glossary

a) Should "DIO" be included in this glossary since SIO, TIO, and VIO are
listed?

b) FYI: We updated the expansions/descriptions of "NSM-VIO" and
"SM-VIO" for consistency with the other entries (i.e., expansion first
and then the description). Please let us know of any objection.

Also, is "Strict" VIO" correct, or should it be "Stateful VIO" per Table 26?

Original:
  NSM-VIO:  A Source-Routed Via Information Option, used in Non-Storing Mode
            P-DAO messages

  SM-VIO:   A strict Via Information Option, used in Storing Mode P-DAO messages

Current:
  NSM-VIO:  Non-Storing Mode Via Information Option.  Source-routed
            VIO used in Non-Storing Mode P-DAO messages.

  SM-VIO:   Storing Mode Via Information Option.  Strict VIO used
            in Storing Mode P-DAO messages.

c) FYI: For consistency, we removed a few instances of "RPL" and "IPv6" as they
were not a part of the expansions.
-->

    <t> This document often uses the following abbreviations:
       </t><dl spacing='compact'>
       </t>
       <dl spacing='normal' newline="false" indent="13">
       <dt>6LR:</dt><dd> 6LoWPAN Router , e.g., (e.g., a RPL router in an LLN </dd> LLN)</dd>
       <dt>6LoRH:</dt><dd> 6LoWPAN Routing Header</dd>
       <dt>ARQ:</dt><dd>Automatic Repeat Request, in Request (in other words retries</dd> words, retries)</dd>
       <dt>FEC:</dt><dd>Forward Error Correction</dd>
       <dt>HARQ:</dt><dd> Hybrid Automatic Repeat Request, combining Request (combines FEC and ARQ</dd> ARQ)</dd>
       <dt>CMO:</dt><dd>Control Message Option</dd>
       <dt>DAO:</dt><dd>Destination Advertisement Object</dd>
       <dt>DAG:</dt><dd>Directed Acyclic Graph</dd>
       <dt>DODAG:</dt><dd>Destination-Oriented Directed Acyclic Graph; Graph. A DAG
       with only one vertex (i.e., node) that has no outgoing edge (i.e., link)</dd>
       <dt>GUA:</dt><dd>IPv6 Global link).</dd>
       <dt>GUA:</dt><dd>Global Unicast Address</dd>
       <dt>LLN:</dt><dd>Low-Power and Lossy Network</dd>
       <dt>MOP:</dt><dd>RPL Mode
       <dt>MOP:</dt><dd>Mode of Operation</dd>
       <dt>P-DAO:</dt><dd>Projected DAO </dd>
       <dt>P-Route:</dt><dd>Projected Route</dd>
       <dt>PDR:</dt><dd>P-DAO Request</dd>
       <dt>PCE:</dt><dd>Path Computation Element</dd>
       <dt>PLR:</dt><dd>Point of Local Repair</dd>
       <dt>RAN:</dt><dd>RPL-Aware Node (either a RPL router or a RPL-Aware Leaf)</dd>
       <dt>RAL:</dt><dd>RPL-Aware Leaf</dd>
       <dt>RH:</dt><dd>Routing Header</dd>
       <dt>RIB:</dt><dd>Routing Information Base, i.e., Base (i.e., the routing table. table) </dd>
       <dt>RPI:</dt><dd>RPL Packet Information</dd>
       <dt>RPL:</dt><dd>IPv6 Routing
       <dt>RPL:</dt><dd>Routing Protocol for Low-Power and Lossy Networks </dd>
       <dt>RTO:</dt><dd>RPL Target Option</dd>
       <dt>RUL:</dt><dd>RPL-Unaware Leaf</dd>
       <dt>SIO:</dt><dd>RPL Sibling
       <dt>SIO:</dt><dd>Sibling Information Option</dd>
       <dt>ULA:</dt><dd>IPv6 Unique
       <dt>ULA:</dt><dd>Unique Local Address</dd>
       <dt>NSM-VIO:</dt><dd>A Source-Routed
       <dt>NSM-VIO:</dt><dd> Non-Storing Mode Via Information Option, Option. Source-routed VIO used in Non-Storing Mode P-DAO messages</dd> messages.</dd>
       <!--
       <dt>SubDAG:</dt><dd> A DODAG Rooted at a node which is a child of that
       node and a subset of a larger DAG</dd> -->
       <dt>SLO:</dt><dd>Service Level Objective</dd>
       <dt>SRH:</dt><dd>Source Routing Header, i.e., the Header (i.e., IPv6 RH type 3, 3); see <xref target="SRSRH"/></dd>
       <dt>SRH-6loRH:</dt><dd> Source target="SRSRH"/>.</dd>
       <dt>SRH-6LoRH:</dt><dd>Source Routing Header 6LoRH, a 6LoRH. A compressed form of SRH defined in "<xref format="title" target='RFC8138'/>" <xref target='RFC8138'>
    " IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header"</xref> target="RFC8138"/>. </dd>
       <dt>TIO:</dt><dd>RPL Transit
       <dt>TIO:</dt><dd>Transit Information Option</dd>
       <dt>SM-VIO:</dt><dd>A strict
       <dt>SM-VIO:</dt><dd>Storing Mode Via Information Option, Option. Strict VIO used in Storing Mode P-DAO messages</dd>
       <dt>VIO:</dt><dd>A Via messages.</dd>
       <dt>VIO:</dt><dd>Via Information Option; it Option. It can be an SM-VIO or a NSM-VIO</dd> NSM-VIO.</dd>
       </dl>

</section>	<!-- Glossary -->

<section anchor='new'><name>Domain Terms</name>
    <t>
    <!-- Removed reference from routing and 6tisch here to keep it simple -->
	 This specification uses the following terminology: terminology defined in the sections that follow.
    </t>
  <section><name>Projected Route</name><t>
	 A RPL P-Route is a RPL route that is computed remotely by a PCE, PCE and
    installed and maintained by a RPL Root on behalf of the PCE. It
    is installed as a state that signals that destinations (i.e., Targets)
    are reachable via or along a sequence of nodes.</t>

  </section>
  <section><name>Projected DAO</name>
    <t> A
    <t>A Projected DAO (P-DAO) is a DAO message that is used to install a P-Route. </t>
  </section>
  <section><name>Path</name>
    <t>Quoting (non-normatively) section 1.1.3 the definition of path in <xref target="RFC1122"/>:</t> target="RFC1122" section="1.3.3"/>:</t>
    <blockquote>
    At a given moment, all the IP datagrams from a particular source host to a
    particular destination host will typically traverse the same sequence of
    gateways.  We use the term "path" for this sequence.  Note that a path is
    uni-directional; it is not unusual to have different paths in the two
    directions between a given host pair.
    </blockquote>
    <t>
    <xref section="2" target="RFC9473"/> points to a longer, more modern definition of path:</t>

<!-- [rfced] Section 2.4.3. The definition of "path" has changed since
[I-D.irtf-panrg-path-properties] was published as RFC 9473. See Section 2
of <xref target="I-D.irtf-panrg-path-properties"/> RFC 9473 (https://www.rfc-editor.org/rfc/rfc9473.html#name-terminology)
and let us know if we may update this document to match RFC 9473.

Current:
   Section 2 of [I-D.irtf-panrg-path-properties] points to a longer,
   more modern definition of path, which begins as follows:</t> follows:

   |  A sequence of adjacent path elements over which a packet can be
   |  transmitted, starting and ending with a node.  A path is
   |  unidirectional.  Paths are time-dependent, i.e., the sequence of
   |  path elements over which packets are sent from one node to another
   |  may change.  A path is defined between two nodes.

Perhaps:
   Section 2 of [RFC9473] points to a longer, more modern definition of
   path:

   |  A sequence of adjacent path elements over which a packet can
   |  be transmitted, starting and ending with a node.
   |
   |  Paths are unidirectional and time dependent, i.e., there can be a
   |  variety of paths from one node to another, and the path over which
   |  packets are transmitted may change.  A path definition can be
   |  strict (i.e., the exact sequence of path elements remains the
   |  same) or loose (i.e., the start and end node remain the same, but
   |  the path elements between them may vary over time).
-->

<blockquote>
      A sequence of adjacent path elements over which a packet can
      be transmitted, starting and ending with a node.  A path is
      unidirectional.  Paths are time-dependent, i.e., the sequence of
      path elements over which packets are sent from one node to another
      may change.  A path is defined between two nodes.
    </blockquote>
    <t>
    It follows that the general acceptance of a path is a linear sequence of
    nodes, as opposed to a multi-dimensional graph. In the context of this
    document, a path is observed by following one copy of a packet that is
    injected in a Track and possibly replicated within.
    </t>
  </section>
  <section><name>Routing Stretch</name>

  <t>
    RPL is anisotropic, meaning that it is directional, or directional or, more exactly precisely, polar.

<!--[rfced] We are having trouble parsing this sentence. Should "and"
be "versus" (i.e., the RPL does not behave the same way "downwards"
versus "upwards")? If not, please let us know how we may update for
clarity.

Original:
   RPL does not behave the same way "downwards" (root towards
   leaves) with <em>multicast</em> _multicast_ DIO messages that form the DODAG and
   "upwards" (leaves towards root) with _unicast_ DAO messages that
   follow the DODAG.

Perhaps:
   RPL does not behave the same way "downwards" (root towards leaves)
   with _multicast_ DODAG Information Object (DIO) messages that form
   the DODAG versus "upwards" (leaves towards root) with _unicast_ DAO
   messages that follow the DODAG.
-->

    RPL does not behave the same way "downwards" (root towards leaves) with <em>multicast</em> DODAG Information Object (DIO) messages that
    form the DODAG and "upwards" (leaves towards root) with <em>unicast</em> DAO messages that follow the DODAG.
    This is in contrast with traditional IGPs that operate the same way in all
    directions and are thus called isotropic.
  </t>
  <t>The term Routing Stretch "routing stretch" denotes the length of a path, in comparison to the length of the
    shortest path, which can be an abstract concept in RPL when the metrics are
    statistical and dynamic, and the concept of distance varies with the Objective
    Function.
  </t>
  <t>
    The RPL DODAG optimizes the P2MP (Point-to-Multipoint) Point-to-Multipoint (P2MP) paths (from the Root) and MP2P (Multipoint-to-Point)
    Multipoint-to-Point (MP2P) paths (towards the Root) paths, Root), but
    the P2P (Point-to-Point) Point-to-Point (P2P) traffic has to follow the same DODAG. Following the
    DODAG, the RPL datapath passes via a common parent in Storing Mode and
    via the Root in Non-Storing Mode. This typically involves more hops and
    more latency than the minimum possible for a directional (i.e., forward) P2P path that an
    isotropic protocol would compute.
    We refer to this elongated path as stretched.
  </t>
  </section>
  <section><name>Track</name>
    <t>
    The concept of Track is inherited from the
    6TiSCH architecture <xref target='RFC9030'>
    "6TiSCH Architecture"</xref> target='RFC9030'></xref> and matches that of a Protection Path protection path in the
    <xref target='I-D.ietf-raw-architecture'>
     RAW Architecture"</xref>. architecture <xref target='RFC9912'></xref>. A Track
    is a networking graph that can be followed to transport packets with
    equivalent treatment; as opposed to the definition of a path above,
    a Track is not necessarily linear. It may contain multiple paths that
    may fork and rejoin, rejoin and that may enable the RAW Packet ARQ, Replication,
    Elimination, and Overhearing (PAREO) operations.
    </t>
    <t>
    <xref target='TRK'/> illustrates the mapping of the DODAG with the
    generic concept of a Track, with the DODAG Root acting as the Ingress
    for the Track, and the mapping of protection paths and segments, and i.e., only forward
    segments, meaning that they are directional and progressing towards the
    destination. Note that East is represented on the left since the
    packets are forwarded East-West.
    </t>

<!--[rfced] FYI: For Figure 1, we moved the information about the
segments and paths out of the figure. Please review and let us
know any concerns.
-->

<figure anchor='TRK'><name>A Track and its Its Components</name>
              <artwork align="center"><![CDATA[ ><![CDATA[
North East                                   North West

       A ==> B ==> C -=- F ==> G ==> H     T1       I: Ingress
     /              \   /              \ /          E: Egress
   I                  O                 E -=- T2    T1, T2, T3:
     \              /   \              / \            External
       P ==> Q ==> R -=- T ==> U ==> V     T3         Targets

South East                                   South West

      I

      I: Ingress
      E: Egress
      T1, T2, T3: external targets
]]></artwork>
</figure>

<t>Of note:</t>
<dl newline="false" spacing="normal">
<dt>I ==> A ==> B ==> C : a Segment C:</dt><dd>A segment to targets F and O

         I O</dd>
<dt>I --> F --> E : a E:</dt><dd>A protection path to targets T1, T2, T3

        I, T3</dd>
<dt>I, A, B, C, F, G, H, E : a E:</dt><dd>A path to T1, T2, T3

]]></artwork>
</figure> T3</dd>
</dl>

    <t>
    This specification builds Tracks that are DODAGs oriented towards a Track
    Ingress, and the forward direction for packets is from the
    Track Ingress to one of the possibly possible multiple Track Egress Nodes, which is
    also down the DODAG.
    </t>
    <t>
    The Track may be strictly connected, meaning that the vertices are adjacent, or loosely connected, meaning that the vertices are connected using segments that are associated to the same Track.
    </t>
  <section><name>TrackID</name>
    <t>
    A RPL InstanceID RPLInstanceID (typically of a Local Instance) that identifies a Track
    using the namespace owned by the Track Ingress. For Local Instances,
    the TrackID is associated with the IPv6 Address address of the Track Ingress that is
    used as the DODAGID, and together they form a unique identification of the Track
    (see the definition of DODAGID in section 2 of <xref target='RFC6550'/>. target='RFC6550' section="2"/>).
    </t>
  </section>
  <section><name>Namespace</name>
  <t>
    The term namespace "namespace" is used to refer to the scope of the TrackID.
    The TrackID is locally significant within its namespace.
    For Local Instances, the namespace is identified by the DODAGID for the
    Track
    Track, and the tuple (DODAGID, TrackID) is globally unique. For Global
    Instances, the namespace is the whole RPL domain.
    </t>

  </section>
  <section><name>Complex Track</name>
    <t>A complex Track is a Track that can be traversed via more than one path (e.g., a DODAG).
    </t>
  </section>
  <section><name>Stand-Alone</name>
  <section><name>Stand Alone</name>
    <t>
    Refers
    Stand alone refers to a segment or a protection path that is installed with a single P-DAO that
    fully defines the path, e.g., a stand-alone segment is installed
    with a single Storing Mode Via Information option Option (SM-VIO) all the way
    between the Ingress and Egress.
    </t>
  </section>
  <section><name>Stitching</name>
    <t>
    This specification uses the term stitching "stitching" to indicate that a track Track is
    piped to another one, meaning that traffic out of the first track Track is injected into
    the other track. Track.
    </t>
  </section>
  <section><name>Protection Path</name>
    <t> The concept of protection path is defined in the
    <xref target='I-D.ietf-raw-architecture'>
     RAW Architecture"</xref> architecture <xref target='RFC9912'></xref>
    as an end-to-end forward serial path.
    With this specification, a protection path is installed by the Root of the main
    DODAG using a Non-Storing Mode P-DAO message, e.g.,
    I --> F --> E in <xref target="TRK"/>.
    </t> <t>
    As the Non-Storing Mode Via Information option Option (NSM-VIO) can only signal
    sequences of nodes, it takes one Non-Storing Mode P-DAO message per protection path to
    signal the structure of a complex Track.
    </t> <t>
    Each NSM-VIO for the same
    TrackID but with a different Segment ID signals a different protection path that the
    Track Ingress adds to the topology.
    </t>
  </section>
  <section><name>Segment</name>
    <t>
    A segment is a serial path formed by a strict sequence of nodes, nodes along which a P-Route is
    installed, e.g.,
    I ==> A ==> B ==> C in <xref target="TRK"/>.
    With this specification, a segment is typically installed by the Root of the
    main DODAG using Storing Mode P-DAO messages. A segment is used as
    the topological edge of a Track joining the loose steps along the protection paths that
    form the structure of a complex Track. The same segment may be leveraged by
    more than one protection path where the protection paths overlap.
    </t> <t>
    Since this specification builds only DODAGs,
    all segments are oriented from the Ingress (East) to Egress (West), as opposed
    to the general Track model in the <xref target='I-D.ietf-raw-architecture'> RAW Architecture</xref>, architecture <xref target='RFC9912'/>, which allows North/South segments that can be
    bidirectional as well.
    </t>

  <section><name>Section of a Segment</name>
    <t>
    A
    The section of a segment refers to a continuous subset of a segment that may be replaced while the segment
    remains. For instance, in segment A=>B=>C=>D=>E=>F, say that the link C to
    D might be misbehaving. The section B=>C=>D=>E in the segment may be
    replaced by B=>C’=>D’=>E B=>C'=>D'=>E to route around the problem. The segment becomes
    A=>B=>C’=>D’=>E=>F.
    A=>B=>C'=>D'=>E=>F.
    </t>

  </section>
  <section anchor='SRSRH'><name>Segment Routing and SRH</name>
  <t>
   In a Non-Storing mode Mode RPL domain, the IPv6 RH used for source-routing source routing
   is the (RPL) SRH as defined in <xref target='RFC6554'/>.
   This specification operates in that context and uses the acronym SRH
   to mean the IPv6 RH type 3 3, as opposed to the IPv6 RH type 4 defined
   in <xref target='RFC8754'/> for the Segment Routing over IPv6 (SRv6) operation.
   </t>
   <t>
   If the network is a 6LoWPAN Network, network, the expectation is that the
   SRH is compressed and encoded as a 6LoWPAN Routing Header (6LoRH), as
   specified in section 5 of <xref target='RFC8138'/>. target='RFC8138' section="5"/>.
   </t>
   <t>
   This specification uses the term "Segment Routing" generically, generically to
   refer to using source-routing source routing to hop over segments. As such,
   forwarding along segments as specified hereafter can be seen as a
   form of Segment Routing <xref target='RFC8402'/>, but leveraging target='RFC8402'/> that leverages the
   (RPL) SRH for its operation.
   </t>
   <t>
   Outside of LLNs, the RPL Network network may be less constrained and operated
   in Storing Mode, as discussed in <xref target='smmd'/>. In that case,
   this specification could be extended to accommodate the SRv6 RH.
   </t>

</section>	<!-- end section "Segment Routing and SRH" -->
</section> <!-- Segment -->
</section>
</section>	<!-- end section "Domain Terms" -->

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

<section anchor='context'><name>Context and Goal</name>

<section anchor='onrpl'><name>RPL Applicability</name>
<t>
   RPL is optimized for situations where the power is scarce, the bandwidth is
   constrained
   constrained, and the transmissions are unreliable. This matches the use case of
   an IoT LLN where RPL is typically used today, but today and also situations of high relative
   mobility between the nodes in the network (a.k.a. swarming), e.g.,
   within a variable set of vehicles with a similar global motion, motion or a platoon of
   drones.
   In contrast, this specification only applies when the platoon has a relatively stable
   topology where the segments can be attributed a reliability and availability
   for a certain lifetime, lifetime; see <xref target='I-D.ietf-raw-architecture'/>.
</t><t> target='RFC9912'/>.
</t>
<!-- [rfced] How may we clarify what "and" is connecting in this sentence?

Original:
   To reach this goal, RPL is primarily designed to minimize the control
   plane activity, that is the relative amount of routing protocol
   exchanges vs. data traffic, and the amount of state that is
   maintained in each node.

Perhaps A:
   To reach this goal, RPL is primarily designed to minimize the control
   plane activity (i.e., the relative amount of routing protocol
   exchanges versus data traffic) and the amount of state that is
   maintained in each node.

or
Perhaps B:
   To reach this goal, RPL is primarily designed to minimize the control
   plane activity (i.e., the relative amount of routing protocol
   exchanges versus data traffic and the amount of state that is
   maintained in each node).
-->

<t>
   To reach this goal, RPL is primarily designed to minimize the control plane
   activity, i.e., the relative amount of routing protocol exchanges versus data
   traffic, and the amount of state that is maintained in each node. RPL does
   not need to converge, and it provides connectivity to most nodes most of the time.
</t><t>
    RPL may form multiple topologies called instances. Instances can be
    created to enforce various optimizations through objective functions, functions
    or to reach out through different Root Nodes.  The concept of objective
    function allows to adapt adapting the activity of the routing protocol to the use
    case, e.g., type, speed, and quality of the LLN links.
</t><t>
    RPL instances operate in parallel, unaware of one another. Yet,
    it is possible to define a model whereby if a route cannot be found
    in the current instance A where a packet is being forwarded, then
    the router may lookup look up the routing table (RIB) (i.e., the RIB) in an instance B and
    forward along instance B if the route is found there.
    To avoid loops, this must happen in such a way that the instances
    themselves form a directed acyclic graph Directed Acyclic Graph (DAG) leading to the last
    resort instance that instance, which is the "lowest" instance if instance A is considered
    "higher" then instance B. This specification uses underlay Tracks as
    "lower" instances, with the main instance being the "highest" of all.
</t><t>
    The RPL Root is responsible for selecting the RPL Instance that is used
    to forward a packet coming from the Backbone backbone into the RPL domain and for setting
    the related RPL information in the packets. Each Instance creates its own
    routing table (RIB) (i.e., a RIB) in participating nodes, and the RIB associated to the instance must be used end to end in the RPL domain. To that effect, RPL
    tags the packets with the Instance ID in a Hop-by-Hop extension Header. header.
    6TiSCH leverages RPL for its distributed routing operations.
</t><t>
   To reduce the routing exchanges, RPL leverages an anisotropic Distance Vector
   approach, which does not need a global knowledge of the topology, topology and only
   optimizes the routes to and from the RPL Root, allowing P2P paths to be
   stretched. Although RPL installs its routes proactively, it only maintains
   them lazily, in reaction to actual traffic, traffic or as a slow background activity.
</t><t>
   This is simple and efficient in situations where the traffic is mostly
   directed from or to a central node, such as the control traffic between
   routers and a controller of a Software Defined Software-Defined Networking (SDN) infrastructure or an Autonomic Control Plane (ACP).
</t><t>
   But stretch in P2P routing is counter-productive to both reliability and
   latency as it introduces additional delay and chances of loss. As a result,
   <xref target='RFC6550'/> is not a good fit for the use cases listed in the
   RAW use cases document <xref target='RFC9450'/>, which demand
   high availability and reliability, and reliability and, as a consequence consequence, require both short
   and diverse paths.
</t>

</section>	<!-- end section "RPL Applicability" -->
<section anchor='onrplroute'><name>Multi-Topology Routing and Loop Avoidance</name>
<t>
   RPL first forms a default route in each node towards the Root, and those
   routes together coalesce as a Directed Acyclic Graph DAG oriented upwards.
   RPL then constructs routes to destinations signaled as Targets in the reverse direction,
   down the same DODAG.  To do so, a RPL Instance can be operated either in either RPL
   Storing Mode or Non-Storing Mode of Operation (MOP).
   The default route towards the Root is maintained aggressively and may change while a packet progresses without causing loops, so the packet will still reach the Root.
</t>
<t>In Non-Storing Mode, each node advertises itself as a Target directly to the
   Root, indicating the parents that may be used to reach itself. Recursively, the
   Root builds and maintains an image of the whole DODAG in memory, memory and
   leverages that abstraction to compute source route paths for the packets to
   their destinations down the DODAG. When a node changes its point(s)
   of attachment to the DODAG, it takes a single unicast packet to the Root along
   the default route to update it, and the connectivity to the node is restored
   immediately;
   this mode is preferable for use cases where internet connectivity is
   dominant,
   dominant or when the Root controls the network activity in the
   nodes, which is the case of in this specification.

</t>
<t>
   In Storing Mode, the routing information percolates upwards, and each
   node maintains the routes to the subDAG of its descendants down the
   DODAG.

<!--[rfced] Does "upon traffic" mean "upon receiving traffic"?

Current:
   The maintenance is lazy, either reactive upon traffic or as
   slow background process.

Perhaps:
   The maintenance is lazy; it is either reactive upon receiving
   traffic or a slow background process.
-->

   The maintenance is lazy, either reactive upon traffic or as a
   slow background process.  Packets flow via the common parent and the
   routing stretch is reduced reduced, compared to the Non-Storing MOP, for better P2P
   connectivity.  However, a new route takes a longer time to
   propagate to the Root, since it takes time for the Distance-Vector Distance Vector protocol to
   operate hop-by-hop, hop by hop, and the connectivity from the internet Internet to the node is
   restored more slowly upon node movement.
</t>

    <t>

    Either way, the RPL routes are injected by the Target nodes, nodes in a distributed fashion. To complement RPL and eliminate routing stretch, this specification introduces a hybrid mode that combines Storing and Non-Storing operations to build and project routes onto the nodes where they should be installed. This specification uses the term Projected Route (P-Route) "P-Route" to refer to those routes.
    </t>

    <t>

<!--[rfced] Does "join the dots" mean "connect" in these sentences? In
the second sentence, are Storing Mode P-Routes deployed to
connect segments to the Track Instance?

Original:
   In the simplest mode of this specification, Storing-Mode P-Routes
   can be deployed to join the dots of a loose source routing header
   (SRH) in the main DODAG.

Perhaps:
   In the simplest mode of this specification, Storing Mode P-Routes
   can be deployed to connect a loose SRH in the main DODAG.

...
Original:
   As for the main DODAG, segments associated to the Track
   Instance may be deployed to join the dots using Storing-Mode
   P-Routes.

Perhaps:
   As for the main DODAG, Storing Mode P-Routes may be deployed to
   connect segments to the Track Instance.
-->

   In the simplest mode of this specification, Storing Mode P-Routes can be
   deployed to join the dots of a loose SRH in the main
   DODAG. In that case, all the routes (source routed and P-Routes) belong to
   the Routing Information base Base (RIB) associated with the main Instance.
   Storing-Mode
   Storing Mode P-Routes are referred to as segments in this specification.

    </t>
<t>A set of P-Routes can also be projected to form a dotted-line underlay of the
    main Instance and provide Traffic Engineered Traffic-Engineered paths for an application.
   In that case, the P-Routes are installed in Non-Storing Mode Mode, and the set
   of P-Routes is called a Track.
   A Track is associated with its own RPL Instance, Instance and, as any RPL Instance,
   with its own Routing Information base (RIB). RIB. As a result, each Track defines
   a routing topology in the RPL domain. As for the main DODAG, segments
   associated to the Track Instance may be deployed to join the dots using
   Storing-Mode
   Storing Mode P-Routes.
    </t>
<t>
   Routing in a multi-topology domain may cause loops unless strict rules are
   applied. This specification defines two strict orders to ensure loop
   avoidance when projected routes P-Routes are used in a RPL domain, domain: one between
   forwarding methods and one between RPL Instances, seen as which are routing topologies.
</t>   <t>

<!-- [rfced] Should "The first and strict order" and "The second strict and
partial order" be updated as follows to "The first strict order" and "The
second strict order", respectively?

Original:
   The first and strict order relates to the forwarding method and the
   more specifically the origin of the information used in the next-hop
   computation.
   ...
   The second strict and partial order is between RPL Instances.

Perhaps:
   The first strict order relates to the forwarding method and, more
   specifically, the origin of the information used in the next-hop
   computation.
   ...
   The second strict order is between RPL Instances.
-->

<t>
   The first and strict order relates to the forwarding method and, more
   specifically, the origin of the information used in the next-hop computation.
   The possible forwarding methods are: 1) to a direct next hop, 2) to an indirect
   neighbor via a common neighbor, 3) along a segment, and 4) along a nested Track.
   The methods are strictly ordered as listed above, above; see more in <xref target = "routing"/>.
   A forwarding method may leverage any of the lower order lower-order ones, but never one
   with a higher order; for instance, when forwarding a packet along a segment,
   the router may use direct or indirect neighbors but cannot use a Track.
   The lower order lower-order methods have a strict precedence, so the router will always
   prefer a direct neighbor over an indirect one, one or a segment within the
   current RPL Instance vs. over another Track.

</t>   <t>

   The second strict and partial order is between RPL Instances. It allows the
   RPL node to detect an error in the state installed by the
   PCE, e.g., after a desynchronization.

<!--[rfced] We are having trouble parsing this sentence. Please
clarify what defines a DODAG of underlays with the main Instance
as the Root.

Original:
   That order must be defined by the administrator for the RPL domain
   and defines a DODAG of underlays with the main Instance as Root.
-->

   That order must be defined by the
   administrator for the RPL domain and
   defines a DODAG of underlays with the main Instance as Root.
   The relation of RPL instances may be represented as a DODAG of instances
   where the main instance is the Root. The rule is that a RPL Instance may leverage
   another RPL instance as an underlay if and only if
   that other Instance is one of its descendants in the graph.
   Supporting this method is OPTIONAL <bcp14>OPTIONAL</bcp14> for nested Tracks and REQUIRED <bcp14>REQUIRED</bcp14> between
   a Track instance and the main instance.

   <!-- The way this graph is communicated to the  RPL nodes is out of scope. -->
   It may be done using network management, management or future extensions to this
   specifications.

<!--[rfced] Please clarify what "it" refers to in "When it is not
communicated".

Original:
   When it is not communicated, then the RPL nodes consider by default
   that all Track instances are children of the main instance, and
   they do not attempt to validate the order for nested Tracks,
   trusting the PCE implicitly.
-->

   When it is not communicated, the RPL nodes consider by
   default that all Track instances are children of the main instance, and they do not
   attempt to validate the order for nested Tracks, trusting the PCE implicitly.
   As a result, a packet that is being forwarded along the main Instance may be
   encapsulated in any Track, but a packet that was forwarded along a Track MUST
   NOT <bcp14>MUST
   NOT</bcp14> be forwarded along the default route of the main Instance.
   </t>
</section>	<!-- end section "Multi-Topology Routing and Loop Avoidance" -->

	<section><name>Requirements</name>

       <section anchor='loose'><name>Loose Source Routing</name>

	  <t>A RPL implementation operating in a very constrained LLN typically uses
      the Non-Storing Mode of Operation as represented in <xref target='nost'/>.
      In that mode, a RPL node indicates a
      parent-child relationship to the Root, using a destination Destination Advertisement
      Object (DAO) that is unicast from the node directly to the Root,
      and the Root typically builds a source routed source-routed path to a destination down
      the DODAG by recursively concatenating this information.
      </t>

          <figure anchor='nost'><name>RPL Non-Storing Mode of operation Operation </name>
            <artwork>
            <artwork><![CDATA[
              +-----+
              |     | Border router Router
              |     |  (RPL Root)
              +-----+                      ^     |        |
                 |                         | DAO | ACK    |
           o    o   o    o                 |     |        | Strict
       o o   o  o   o  o  o o   o          |     |        | Source
      o  o o  o o    o   o   o  o  o       |     |        | Route
      o   o    o  o     o  o    o  o  o    |     |        |
     o  o   o  o   o         o   o o       |     v        v
     o          o             o     o
                       LLN
                       </artwork>
                       LLN]]></artwork>
          </figure>

 <t>
   Based on the parent-children relationships expressed in the Non-
   Storing DAO messages, the Root possesses topological information
   about the whole network, though this information is limited to the
   structure of the DODAG for which it is the destination.  A packet
   that is generated within the domain will always reach the Root, which
   can then apply a source routing information to reach the destination
   if the destination is also in the DODAG.  Similarly, a packet coming
   from the outside of the domain for a destination that is expected to
   be in a RPL domain reaches the Root.  This results in the wireless
   bandwidth near the Root being the limiting factor for all transmissions
   towards or within the domain, and that the Root is a single point of
   failure for all connectivity to nodes within its domain.

 </t>
 <t>
   The RPL Root must add a source routing header to all downward packets.
   As a network grows, the size of the source routing header increases
   with the depth of the network.  In some use cases, a RPL network forms
   long lines along physical structures such as like streets for with lighting.
   Limiting the packet size is beneficial to the energy budget, directly
   for the current transmission, but transmission and also indirectly since it reduces the
   chances of frame loss and energy spent in retries, e.g., by ARQ over one hop
   at Layer-2, Layer 2 or end-to-end end to end at upper layers.
   Using smaller packets also reduces the chances of
   packet fragmentation, which is highly detrimental to the LLN operation, in
   particular when fragments are forwarded but not recovered, recovered; see
   <xref target="RFC8930"/> vs. compared to <xref target="RFC8931"/> for more. more details.

 </t>
 <t>
   A limited amount of well-targeted routing state would allow the
   source routing operation to be loose as opposed to strict, strict and would reduce the
   overhead of routing information in packets.
   Because the capability to store routing state in every node
   is limited, the decision of which route is installed where can only
   be optimized with global knowledge of the system, knowledge that
   the Root or an associated PCE may possess by means that are outside
   the scope of this specification.
 </t>
 <t>
   Being on-path on path for all packets in Non-Storing mode, Mode, the Root may
   determine the number of P2P packets in its RPL domain per source and
   destination, the latency incurred, and the amount of energy and
   bandwidth that is consumed to reach itself and then back down, including
   possible fragmentation when encapsulating larger packets.  Enabling
   a shorter path that would not traverse the Root for select P2P
   source/destinations
   sources/destinations may improve the latency, lower the consumption of
   constrained resources, free bandwidth at the bottleneck near the
   Root, improve the delivery ratio ratio, and reduce the latency for those P2P
   flows with
   flows; this would be a global benefit for all flows by reducing the load at the
   Root.
 </t>

      <t>
      To limit the need for source route headers in deep networks, one possibility
      is to store a routing state associated with the main DODAG in select RPL
      routers down the path. The Root may elide the sequence of routers
      that is installed in the network from its source route header, which therefore
      becomes loose, in contrast to being strict in <xref target="RFC6550"/>.
      </t>

      </section> <!-- Loose Source Routing -->
    <section><name>forward
    <section><name>Forward Routes</name>

    <t>
      <xref target="RFC6550"/> optimizes P2MP routes from the Root, MP2P
      routes towards the
      Root, and as a consequence routes from/to the outside of the RPL domain when the Root
      also serves as Border Router. the border router.
      All routes are installed North-South (a.k.a. up/down) along the RPL DODAG.
      Peer to Peer
      Peer-to-Peer (P2P) forward routes in a RPL network will generally
      experience elongated (stretched) paths versus rather than direct (optimized)
      paths, since routing between two nodes always happens via a common
      parent, as illustrated in <xref target='stretch'/>:
        </t>

       <figure anchor='stretch'><name>Routing Stretch between Between S and D via common parent Common Parent X along Along North-South Paths</name>
            <artwork>
            <artwork><![CDATA[
              ------+---------
                    |          Internet
                 +-----+
                 |     | Border router Router
                 |     |  (RPL Root)
                 +-----+
                    X
              ^    v   o    o
          ^ o   o  v   o  o  o o   o
         ^  o o  o v    o   o   o  o  o
         ^   o    o  v     o  o    o  o  o
        S  o   o  o   D         o   o o
        o          o             o     o
                          LLN
       </artwork>
                          LLN]]></artwork>
          </figure>

     <t>As described in <xref target="RFC9008" />, the amount of stretch depends on the Mode of Operation: MOP: </t>
    <ul spacing='normal'>
        <li> in In Non-Storing Mode, all packets
     routed within the DODAG flow all the way up to the Root of the DODAG. If
     the destination is in the same DODAG, the Root must encapsulate the packet
     to place an RH that has the strict source route information down
     the DODAG to the destination. This will be the case even if the destination
     is relatively close to the source and the Root is relatively far off.
        </li>
        <li>In Storing Mode, unless the destination is a child of the source,
     the packets will follow the default route up the DODAG as well.
     If the destination is in the same DODAG, they will eventually reach a
     common parent that has a route to the destination; at worse, worst, the common
     parent may also be the Root. From that common parent, the packet will
     follow a path down the DODAG that is optimized for the Objective Function
     that was used to build the DODAG.</li>
        </ul>

     <t>
     It turns out that it is often beneficial to enable direct P2P routes,
     either routes if
     either the RPL route presents a stretch from the shortest path, path or if the
     new route is engineered with a different objective, and this is
     even more critical in Non-Storing Mode than it is in Storing Mode, Mode because
     the routing stretch is wider.
     For that reason, earlier work at within the IETF introduced was introduced: the
     "<xref format="title" target='RFC6997'/>" <xref target='RFC6997'>"Reactive Discovery of Point-to-Point Routes in
     Low Power and Lossy Networks"</xref>, target="RFC6997"/>, which specifies a distributed method for
     establishing optimized P2P routes.
     This specification  proposes an alternative based  on centralized
     route computation.
     </t>

        <figure anchor='opti2'><name>More direct forward Direct Forward Route between Between S and D</name>
            <artwork>
            <artwork><![CDATA[
                 +-----+
                 |     | Border router Router
                 |     |  (RPL Root)
                 +-----+
                    |
              o    o   o    o
          o o   o  o   o  o  o o   o
         o  o o  o o    o   o   o  o  o
         o   o    o  o     o  o    o  o  o
        S>>A>>>B>>C>>>D         o   o o
        o          o             o     o
                          LLN
       </artwork>
                          LLN]]></artwork>
          </figure>
            <t>
      The requirement is to install additional routes in the RPL routers,
      to reduce the stretch of some P2P routes and maintain the characteristics
      within a given SLO, Service Level Objective (SLO), e.g., in terms of latency and/or reliability.

      </t>
      </section>
      </section> <!-- Requirements -->

<section anchor='tracks'><name>On Tracks</name>
<section anchor='ctracks'><name>Building Tracks with RPL</name>

    <t>
    The concept of a Track was introduced in the
    6TiSCH architecture <xref target='RFC9030'>
    "6TiSCH Architecture"</xref>, target='RFC9030'></xref> as a collection of potential paths that
    leverage redundant forwarding solutions along the way. This can be a
    DODAG or a more complex structure that is only partially acyclic
    (e.g., per packet).
    </t>
<t>
    With this specification, a Track is shaped as a DODAG, and following the directed edges leads to a Track Ingress. Storing Mode P-DAO messages follow
    the direction of the edges to set up routes for traffic that flows the
    other way, towards the Track Egress(es). If there is a single Track Egress,
    then the Track is reversible to form so that another DODAG may be formed by reversing the
    direction of each edge. A node at the Ingress of more than one segment in a
    Track may use one or more of these segments to forward a packet inside the
    Track.
    </t>
<t>
   A RPL Track is a collection of (one or more) parallel loose source routed source-routed
   sequences of nodes ordered from Ingress to Egress, each forming a protection path.
   The nodes in a Track are directly connected, reachable via existing Tracks as
   illustrated in <xref target='nssr'/>  or joined with strict segments of
   other nodes as shown in <xref target='srpdao'/>.
   The protection paths are expressed in RPL Non-Storing Mode and require an encapsulation
   to add a Source Route Header, whereas the segments are expressed in RPL
   Storing Mode.
</t>
<t>
   A path provides only one path between the Ingress and Egress.
   It comprises exactly one protection path. A Stand-Alone stand-alone segment implicitly defines a
   path from its Ingress to Egress.
</t>

<t> A complex Track forms a graph that provides a collection of potential paths
    to provide redundancy for the packets, either as a collection of protection paths that
    may be parallel or interleaved at certain points, points or as a more generic DODAG.
</t>

</section><!-- Building Tracks -->

</section>
<section anchor='stracks'><name>Tracks and RPL Instances</name>

   <t>
   Section 5.1. of
   <xref target='RFC6550'/> target='RFC6550' section="5.1"/> describes the RPL Instance and
   its encoding. There can be up to 128 Global RPL Instances, for which there
   can be one or more DODAGs, and there can be 64 local Local RPL Instances, with a
   namespace that is indexed by a DODAGID, where the DODAGID is a Unique Local
   Address (ULA) or a Global Unicast Address (GUA) of the Root of the DODAG.
   Bit 0 (most significant) is set to 1 to signal a Local RPLInstanceID, as
   shown in <xref target='rpid'/>. By extension, this specification expresses
   the value of the RPLInstanceID as a single integer between 128 and 191,
   representing both the Local RPLInstanceID in 0..63 in the rightmost bits
   and Bit bit 0 set.
   </t>

<figure anchor='rpid'><name>Local RPLInstanceID Encoding</name>
              <artwork align="center"> ><![CDATA[
        0 1 2 3 4 5 6 7
       +-+-+-+-+-+-+-+-+
       |1|D|   ID      |  Local RPLInstanceID in 0..63
       +-+-+-+-+-+-+-+-+
        |  |
         \  \
          \   Bit 1 is set to 0 in Track IDs
           Bit 0 set to 1 signals a local RPLInstanceID
 </artwork> Local RPLInstanceID]]></artwork>
</figure>
   <t>
   A Track typically forms an underlay to the main Instance, Instance and is associated
   with a Local RPL Instance from which the RPLInstanceID is used as the TrackID.
   When a packet is placed on a Track, it is encapsulated IP-in-IP encapsulated with a
   RPL Option containing a RPI which RPL Packet Information (RPI) that signals the RPLInstanceID.
   The encapsulating source IP address and RPI Instance are set to the Track
   Ingress IP address and local Local RPLInstanceID, respectively, respectively; see more in
   <xref target='trkid'/>.
   </t>
   <t>
   A Track typically offers service protection across several protection paths.
   As a degraded form of a Track, a path made of a single protection path
   (i.e., offering no protection) can be used as an alternative to a segment for
   forwarding along a RPL Instance.
   In that case, instead of following native routes along the instance, the
   packets are encapsulated to signal a more specific more-specific source-routed path between
   the loose hops in the encapsulated source routing header.
   </t><t>
   If the
   encapsulated packet follows a global instance, then the protection path may be part of that
   global instance as well, for instance e.g., the global instance of the main DODAG.
   This can only be done for global instances because the Ingress node that
   encapsulates the packets over the protection path is not the Root of the instance,
   so the source address of the encapsulated packet cannot be used to determine
   the Track along the way.
   </t>

</section><!-- Tracks and RPL Instances -->
</section><!-- On tracks -->

    <section><name>path

</section>
</section>

    <section><name>Path Signaling</name>
<t>
   This specification enables setting up a P-Route along either a protection path or a
   segment. A P-Route is installed and maintained by the Root of the main DODAG
   using an extended RPL DAO message called a Projected DAO (P-DAO), P-DAO, and a Track
   is composed of the combination of one or more P-Routes. In order to clarify
   the techniques that may be used to install a P-Route, this section takes uses the
   simple case of the path illustrated in <xref target='reft'/>.
   So
   Thus, the goal is to build a path from node A to E for packets towards E's
   neighbors F and G along A, B, C, D D, and E as opposed to via the Root:
</t>

<figure anchor='reft'><name>Reference Track</name>
              <artwork align="center">
                              /===&gt; ><![CDATA[
                              /===> F
A ===&gt; ===> B ===&gt; ===> C ===&gt; D===&gt; ===> D===> E &lt;
                              \===&gt; G

 </artwork> <
                              \===> G]]></artwork>
</figure>

<t>
   A P-DAO message for a Track signals the TrackID in the RPLInstanceID field.
   In the case of a local Local RPL Instance, the address of the Track Ingress is
   used as the source to encapsulate packets along the Track. The Track is signaled
   in the DODAGID field of the Projected DAO P-DAO Base Object, Object;
   see <xref target='p-dao-fmt'/>.
</t><t>
   This specification introduces the Via Information Option (VIO) to signal a sequence of hops in a
   protection path or a segment in the P-DAO messages, either in Storing Mode (SM-VIO) or
   in Non-Storing Mode (NSM-VIO). One P-DAO message contains a single VIO,
   which is associated to one or more RPL Target Options that signal the destination
   IPv6 addresses that can reached along the Track (more (see more in <xref target='viof'/>).
</t>
<t>
   Before diving deeper into Track and segment signaling and operation,
   this section provides examples of how route projection works through
   variations of a simple example. This simple example illustrates the case of
   host routes, though RPL Targets can also be prefixes.
</t>

<!-- [rfced] Is "coma-" here is correct? Should this be updated to "comma-" or
something else?

Original:
   We use "-to-", such as in C==>D==>E-to-F to represent
   coma-separated Targets, e.g., F is a Target for segment C==>D==>E.
-->

<t>
   Conventionally
   Conventionally, we use  ==&gt; to represent a strict hop and --&gt; for a
   loose hop.
   We use "-to-", such as in C==&gt;D==&gt;E-to-F C==&gt;D==&gt;E-to-F, to represent coma-separated
   Targets, e.g., F is a Target for segment C==&gt;D==&gt;E.
   In this example, the example below, A is the Track Ingress and E is the Track Egress. C is a stitching
   point. F and G are "external” "external" Targets for the Track, Track and become reachable
   from A via the Track A (Ingress) to E (Egress and implicit Target in
   Non-Storing Mode) Mode), leading to F and G (explicit Targets).

</t>
<t>
In a general manner manner, the desired outcome is as follows:
</t>

<ul>
<li>Targets are E, F, and G </li>
<li>P-DAO 1 signals C==&gt;D==&gt;E</li>
<li>P-DAO 2 signals A==&gt;B==&gt;C</li>
<li>P-DAO 3 signals F and G via the A--&gt;E Track</li>
</ul>

<t>
   P-DAO 3 may be omitted if P-DAO P-DAOs 1 and 2 signal F and G as Targets.
</t>
<t>
   Loose sequences of hops are expressed in Non-Storing Mode; this is why P-DAO 3
   contains a an NSM-VIO. With this specification:
</t>
<ul>
<li>
   the
   The DODAGID to be used by the Ingress as the source address is signaled
   in the DAO base object Base Object (see <xref target='p-dao-fmt'/>) . target='p-dao-fmt'/>).
</li><li>
   the
   The via list in the VIO is encoded as an SRH-6LoRH (see <xref target='viao'/>),
   and it starts with the address of the first hop first-hop node after the Ingress node
   in the loose hop sequence.
</li><li>
the
The via list ends with the address of the Egress node.
</li>
</ul>
<t> Note well:
</t>
<blockquote>

<aside><t>Note 1: The Egress of a Non-Storing Mode P-Route is implicitly a
target; it is not listed in the RPL Target Options but is still accounted for as
if it was.  The only exception is when the Egress is the only address listed
in the VIO, in which case it would indicate via itself itself, which would be non-sensical.
   </blockquote>
<t>
Also:
</t>

<blockquote>
nonsensical.</t> </aside>

<aside><t>Note 2: By design, the list of nodes in a VIO in Non-Storing Mode is
exactly the list that shows in the encapsulation SRH. So in the cases detailed
below, if the Mode of the P-DAO is Non-Storing, then the VIO row can be read
as indicating the SRH as well.

</blockquote> well.</t></aside>

    <section anchor="usms"><name>Using Storing Mode Segments</name>
<t>
    A==&gt;B==&gt;C and C==&gt;D==&gt;E are segments of the same Track.
    Note that the Storing Mode signaling imposes strict continuity in a segment, since the P-DAO is passed hop by hop, as a classical DAO is,
    along the reverse datapath that it signals.
    One benefit of strict routing is that loops are avoided along the Track.
</t>

    <section><name>Stitched Segments</name>

<t>In this formulation:</t>

<ul>
<li>P-DAO 1 signals C==&gt;D==&gt;E-to-F,G</li>
<li>P-DAO 2 signals A==&gt;B==&gt;C-to-F,G</li>
</ul>
<t>Storing Mode P-DAO 1 is sent to E E, and when it is successfully acknowledged,
   Storing Mode P-DAO 2 is sent to C, C as follows:</t>

        <table anchor="PDAOcase11"><name>P-DAO Messages</name>
   <thead>

          <tr><th align='center'>Field</th>
              <th align='left'>P-DAO

          <tr><th>Field</th>
              <th>P-DAO 1 to E</th>
              <th align='left'>P-DAO
              <th>P-DAO 2 to C</th></tr>

   </thead>
   <tbody>

          <tr><td align='center'>Mode</td>
              <td align='left'>Storing</td>
              <td align='left'>Storing</td></tr>
          <tr><td align='center'>Track Ingress</td>
              <td align='left'>A</td>
              <td align='left'>A</td></tr>
          <tr><td align='center'>(DODAGID, TrackID)</td>
              <td align='left'>(A,

          <tr><th>Mode</th>
              <td>Storing</td>
              <td>Storing</td></tr>
          <tr><th>Track Ingress</th>
              <td>A</td>
              <td>A</td></tr>
          <tr><th>(DODAGID, TrackID)</th>
              <td>(A, 129)</td>
              <td align='left'>(A,
              <td>(A, 129)</td></tr>
          <tr><td align='center'>SegmentID</td>
              <td align='left'>1</td>
              <td align='left'>2</td></tr>
          <tr><td align='center'>VIO</td>
              <td align='left'>C,
          <tr><th>SegmentID</th>
              <td>1</td>
              <td>2</td></tr>
          <tr><th>VIO</th>
              <td>C, D, E</td>
              <td align='left'>A,
              <td>A, B, C</td></tr>
          <tr><td align='center'>Targets</td>
              <td align='left'>F,
          <tr><th>Targets</th>
              <td>F, G</td>
              <td align='left'>F,
              <td>F, G</td></tr>

    </tbody>
        </table>

<t>As a result result, the RIBs are set as follows:</t>
<!-- COMMENT: The acronym for RIB is not defined
     AUTH: added
     -->

        <table anchor="RIBcase11"><name>RIB setting</name> Settings</name>
   <thead>

          <tr><th align='center'>Node</th>
              <th align='left'>Destination</th>
              <th align='left'>Origin</th>
              <th align='left'>Next

          <tr><th>Node</th>
              <th>Destination</th>
              <th>Origin</th>
              <th>Next Hop(s)</th>
              <th align='left'>TrackID</th></tr>
              <th>TrackID</th></tr>

   </thead>
   <tbody>

          <tr><td align='center'>E</td>
              <td align='left'>F,

          <tr><td>E</td>
              <td>F, G</td>
              <td align='left'>P-DAO
              <td>P-DAO 1</td>
              <td align='left'>Neighbor</td>
              <td align='left'>(A,
              <td>Neighbor</td>
              <td>(A, 129)</td></tr>

          <tr><td align='center'>D</td>
              <td align='left'>E</td>
              <td align='left'>P-DAO

          <tr><td>D</td>
              <td>E</td>
              <td>P-DAO 1</td>
              <td align='left'>Neighbor</td>
              <td align='left'>(A,
              <td>Neighbor</td>
              <td>(A, 129)</td></tr>

          <tr><td align='center'>"</td>
              <td align='left'>F,

          <tr><td>"</td>
              <td>F, G</td>
              <td align='left'>P-DAO
              <td>P-DAO 1</td>
              <td align='left'>E</td>
              <td align='left'>(A,
              <td>E</td>
              <td>(A, 129)</td></tr>

          <tr><td align='center'>C</td>
              <td align='left'>D</td>
              <td align='left'>P-DAO

          <tr><td>C</td>
              <td>D</td>
              <td>P-DAO 1</td>
              <td align='left'>Neighbor</td>
              <td align='left'>(A,
              <td>Neighbor</td>
              <td>(A, 129)</td></tr>

          <tr><td align='center'>"</td>
              <td align='left'>F,

          <tr><td>"</td>
              <td>F, G</td>
              <td align='left'>P-DAO
              <td>P-DAO 1</td>
              <td align='left'>D</td>
              <td align='left'>(A,
              <td>D</td>
              <td>(A, 129)</td></tr>

          <tr><td align='center'>B</td>
              <td align='left'>C</td>
              <td align='left'>P-DAO

          <tr><td>B</td>
              <td>C</td>
              <td>P-DAO 2</td>
              <td align='left'>Neighbor</td>
              <td align='left'>(A,
              <td>Neighbor</td>
              <td>(A, 129)</td></tr>

          <tr><td align='center'>"</td>
              <td align='left'>F,

          <tr><td>"</td>
              <td>F, G</td>
              <td align='left'>P-DAO
              <td>P-DAO 2</td>
              <td align='left'>C</td>
              <td align='left'>(A,
              <td>C</td>
              <td>(A, 129)</td></tr>

          <tr><td align='center'>A</td>
              <td align='left'>B</td>
              <td align='left'>P-DAO

          <tr><td>A</td>
              <td>B</td>
              <td>P-DAO 2</td>
              <td align='left'>Neighbor</td>
              <td align='left'>(A,
              <td>Neighbor</td>
              <td>(A, 129)</td></tr>

          <tr><td align='center'>"</td>
              <td align='left'>F,

          <tr><td>"</td>
              <td>F, G</td>
              <td align='left'>P-DAO
              <td>P-DAO 2</td>
              <td align='left'>B</td>
              <td align='left'>(A,
              <td>B</td>
              <td>(A, 129)</td></tr>

    </tbody>
        </table>

 <t>
Note:
 </t>
<blockquote>
        the

<aside><t>Note: The " sign is used throughout those the tables in this document to indicate the same value as in the row above.
</blockquote> above.</t></aside>

        <!--
    COMMENT: What does the double quote (") stand for? "Same as above"? If yes, maybe it better to just be explicit and repeat the Node value.
    AUTH: yes that is what it means, and for the second point, I tried and that was really awful to read

    -->

<t>
    Packets originating at A and going to F or G do not require encapsulation
    as the RPI can be placed in the native header chain. For packets that
    it routes, A must encapsulate to add the RPI that signals the TrackID;
    the outer headers of the packets that are forwarded along the Track have
    the following settings:
</t>

<!--[rfced] We note that several of the tables have the same title;
will this be confusing for readers? For instance, Tables 3, 6, 9,
15, 18, 19, and 20 are all titled "Packet Header Settings".
Would you like to make these titles more descriptive like Table
12, which is titled "Packet Header Settings Between C and E"? If
so, please provide the wording. If not, should the title of Table 12
be updated for consistency with the other titles (i.e., update
as "Packet Header Settings")?

Note that Tables 2, 5, 8, 11, 14, and 17 are all titled "RIB Settings",
and Tables 1, 4, 7, 10, 13, and 16 are all titled "P-DAO Messages".
-->
   <table anchor="Packetcase11"><name>Packet Header Settings</name>  <thead>

          <tr><th align='center'>Header</th> align="center">Header</th>
          <th align='center'>IPv6 align="center">IPv6 Source Addr.</th> Address</th>
              <th align='center'>IPv6 Dest. Addr.</th> align="center">IPv6 Destination Address</th>
              <th align='center'>TrackID align="center">TrackID in RPI</th></tr>

   </thead>
   <tbody>
          <tr><td align='center'>Outer</td> align="center">Outer</td>
              <td align='center'>A</td> align="center">A</td>
              <td align='center'>F align="center">F or G</td>
              <td align='center'>(A, align="center">(A, 129)</td></tr>
          <tr><td align='center'>Inner</td> align="center">Inner</td>
              <td align='center'>Any align="center">Any but A</td>
              <td align='center'>F align="center">F or G</td>
              <td align='center'>N/A</td></tr> align="center">N/A</td></tr>
    </tbody>
        </table>
<!-- COMMENT: The X != A is not very clear. I would guess it means "anything else but A" but maybe a note will clarify this.
    AUTH: replaced with "Any but A"
-->
<t>
As an example, say that A has a packet for F. Using the RIB in <xref target='RIBcase11'/>:
</t>
<ul>
<li>From P-DAO 2: A forwards to B B, and B forwards to C.</li>
<li>From P-DAO 1: C forwards to D D, and D forwards to E.</li>
<li>From Neighbor Cache Entry: E delivers the packet to F.</li>
</ul>

    </section><!-- Stitched Segments -->

    </section>

    <section><name>External Routes</name>

<t>In this example, we consider F and G as destinations that are external to the
   Track as a DODAG, as discussed in section 4.1.1. of <xref target='RFC9008'/>. target='RFC9008' section="4.1.1"/>.
   We then apply the directives for encapsulating in that case (more (see more in <xref
   target='routing'/>).
</t>
<t>In this formulation, we set up the protection path explicitly, which creates less
   routing state in intermediate hops at the expense of larger packets to
   accommodate source routing:</t>
<ul>
<li>P-DAO 1 signals C==&gt;D==&gt;E-to-E</li>
<li>P-DAO 2 signals A==&gt;B==&gt;C-to-E</li>
<li>P-DAO 3 signals F and G via the A--&gt;E-to-F,G Track</li>
</ul>
<t>Storing Mode P-DAO P-DAOs 1 and 2, 2 and Non-Storing Mode P-DAO 3, 3 are sent to E, C C,
 and A, respectively, as follows:</t>

        <table anchor="PDAOcase12"><name>P-DAO Messages</name>
   <thead>

          <tr><th align='center'>

          <tr><th> </th>
              <th align='left'>P-DAO
              <th>P-DAO 1 to E</th>
              <th align='left'>P-DAO
              <th>P-DAO 2 to C</th>
              <th align='left'>P-DAO
              <th>P-DAO 3 to A</th></tr>

   </thead>
   <tbody>

          <tr><td align='center'>Mode</td>
              <td align='left'>Storing</td>
              <td align='left'>Storing</td>
              <td align='left'>Non-Storing</td></tr>
          <tr><td align='center'>Track Ingress</td>
              <td align='left'>A</td>
              <td align='left'>A</td>
              <td align='left'>A</td></tr>
          <tr><td align='center'>(DODAGID, TrackID)</td>
              <td align='left'>(A,

          <tr><th>Mode</th>
              <td>Storing</td>
              <td>Storing</td>
              <td>Non-Storing</td></tr>
          <tr><th>Track Ingress</th>
              <td>A</td>
              <td>A</td>
              <td>A</td></tr>
          <tr><th>(DODAGID, TrackID)</th>
              <td>(A, 129)</td>
              <td align='left'>(A,
              <td>(A, 129)</td>
              <td align='left'>(A,
              <td>(A, 129)</td></tr>
          <tr><td align='center'>SegmentID</td>
              <td align='left'>1</td>
              <td align='left'>2</td>
              <td align='left'>3</td></tr>
          <tr><td align='center'>VIO</td>
              <td align='left'>C,
          <tr><th>SegmentID</th>
              <td>1</td>
              <td>2</td>
              <td>3</td></tr>
          <tr><th>VIO</th>
              <td>C, D, E</td>
              <td align='left'>A,
              <td>A, B, C</td>
              <td align='left'>E</td></tr>
          <tr><td align='center'>Targets</td>
              <td align='left'>E</td>
              <td align='left'>E</td>
              <td align='left'>F,
              <td>E</td></tr>
          <tr><th>Targets</th>
              <td>E</td>
              <td>E</td>
              <td>F, G</td></tr>

    </tbody>
        </table>

<t>
   Note in the above that E is not an implicit Target in Storing mode, Mode, so it must be added in the RTO RPL Target Option (RTO) for P-DAO P-DAOs 1 and 2.
   E is not an implicit Target for P-DAO 3 either, since E is the only entry in the VIO.
</t>

<t>As a result result, the RIBs are set as follows:</t>

        <table anchor="RIBcase12"><name>RIB setting</name> Settings</name>
   <thead>

          <tr><th align='center'>Node</th>
              <th align='left'>Destination</th>
              <th align='left'>Origin</th>
              <th align='left'>Next

          <tr><th>Node</th>
              <th>Destination</th>
              <th>Origin</th>
              <th>Next Hop(s)</th>
              <th align='left'>TrackID</th></tr>
              <th>TrackID</th></tr>

   </thead>
      <tbody>

          <tr><td align='center'>E</td>
              <td align='left'>F,

          <tr><td>E</td>
              <td>F, G</td>
              <td align='left'>P-DAO
              <td>P-DAO 1</td>
              <td align='left'>Neighbor</td>
              <td align='left'>(A,
              <td>Neighbor</td>
              <td>(A, 129)</td></tr>

          <tr><td align='center'>D</td>
              <td align='left'>E</td>
              <td align='left'>P-DAO

          <tr><td>D</td>
              <td>E</td>
              <td>P-DAO 1</td>
              <td align='left'>Neighbor</td>
              <td align='left'>(A,
              <td>Neighbor</td>
              <td>(A, 129)</td></tr>

          <tr><td align='center'>C</td>
              <td align='left'>D</td>
              <td align='left'>P-DAO

          <tr><td>C</td>
              <td>D</td>
              <td>P-DAO 1</td>
              <td align='left'>Neighbor</td>
              <td align='left'>(A,
              <td>Neighbor</td>
              <td>(A, 129)</td></tr>

          <tr><td align='center'>"</td>
              <td align='left'>E</td>
              <td align='left'>P-DAO

          <tr><td>"</td>
              <td>E</td>
              <td>P-DAO 1</td>
              <td align='left'>D</td>
              <td align='left'>(A,
              <td>D</td>
              <td>(A, 129)</td></tr>

          <tr><td align='center'>B</td>
              <td align='left'>C</td>
              <td align='left'>P-DAO

          <tr><td>B</td>
              <td>C</td>
              <td>P-DAO 2</td>
              <td align='left'>Neighbor</td>
              <td align='left'>(A,
              <td>Neighbor</td>
              <td>(A, 129)</td></tr>

          <tr><td align='center'>"</td>
              <td align='left'>E</td>
              <td align='left'>P-DAO

          <tr><td>"</td>
              <td>E</td>
              <td>P-DAO 2</td>
              <td align='left'>C</td>
              <td align='left'>(A,
              <td>C</td>
              <td>(A, 129)</td></tr>

          <tr><td align='center'>A</td>
              <td align='left'>B</td>
              <td align='left'>P-DAO

          <tr><td>A</td>
              <td>B</td>
              <td>P-DAO 2</td>
              <td align='left'>Neighbor</td>
              <td align='left'>(A,
              <td>Neighbor</td>
              <td>(A, 129)</td></tr>

          <tr><td align='center'>"</td>
              <td align='left'>E</td>
              <td align='left'>P-DAO

          <tr><td>"</td>
              <td>E</td>
              <td>P-DAO 2</td>
              <td align='left'>B</td>
              <td align='left'>(A,
              <td>B</td>
              <td>(A, 129)</td></tr>

          <tr><td align='center'>"</td>
              <td align='left'>F,

          <tr><td>"</td>
              <td>F, G</td>
              <td align='left'>P-DAO
              <td>P-DAO 3</td>
              <td align='left'>E</td>
              <td align='left'>(A,
              <td>E</td>
              <td>(A, 129)</td></tr>

    </tbody>
        </table>

<t>
    Packets from A to E do not require an encapsulation.
    This is why in
    In the tables below, this is why E may show as an IPv6 Destination Address destination address only
    if the IPv6 Source Address source address X is different from A.
    Conversely, the encapsulation is always done when the IPv6 Destination
    Address destination
    address is F or G.
    Other destination addresses do not match this P-Route and are not subject to
    encapsulation.
</t><t>
    The outer headers of
    the packets that are forwarded along the Track have the following settings:
</t>

        <table anchor="Packetcase12"><name>Packet Header Settings</name>
   <thead>

          <tr><th align='center'>Header</th> align="center">Header</th>
          <th align='center'>IPv6 align="center">IPv6 Source Addr.</th> Address</th>
              <th align='center'>IPv6 Dest. Addr.</th> align="center">IPv6 Destination Address</th>
              <th align='center'>TrackID align="center">TrackID in RPI</th></tr>

   </thead>
   <tbody>
          <tr><td align='center'>Outer</td> align="center">Outer</td>
              <td align='center'>A</td> align="center">A</td>
              <td align='center'>E</td> align="center">E</td>
              <td align='center'>(A, align="center">(A, 129)</td></tr>
          <tr><td align='center'>Inner</td> align="center">Inner</td>
              <td align='center'>X</td>
              <td align='center'>Either align="center">X</td>
              <td>Either F or G. If X!=A, then E is also permitted.</td>
              <td align='center'>N/A</td></tr> align="center">N/A</td></tr>
    </tbody>
        </table>
<!-- COMMENT: The E (X != A) is not very clear. What is X?
     AUTH: X was the node in the column left to this. Changed to "either E if(X != A), or F, or G"
 -->
<t>
As an example, say that A has a packet for F. Using the RIB in <xref target='RIBcase12'/>:
</t>
<ul>
<li>From P-DAO 3: A encapsulates the packet and sends it down the Track signaled by P-DAO 3, with the outer header above. Now the packet destination is E.</li>
<li>From P-DAO 2: A forwards to B B, and B forwards to C.</li>
<li>From P-DAO 1: C forwards to D D, and D forwards to E; E decapsulates the packet.</li>
<li>From Neighbor Cache Entry: E delivers packets to F or G.</li>
</ul>
    </section><!-- External routes -->
    </section>

    <section anchor="srpdao"><name>Segment Routing</name>

<t>In this formulation formulation, protection paths are leveraged to combine segments and form a
   Graph.
   graph. The packets are source routed from a segment to the next to adapt
   the path:</t>

<ul>
<li>P-DAO 1 signals C==&gt;D==&gt;E-to-E</li>
<li>P-DAO 2 signals A==&gt;B-to-B,C</li>
<li>P-DAO 3 signals F and G via the A--&gt;C--&gt;E-to-(E),F,G Track</li>
</ul>

<t>Storing Mode P-DAO P-DAOs 1 and 2, 2 and Non-Storing Mode P-DAO 3, 3 are sent to E, B B,
 and A, respectively, as follows:</t>

        <table anchor="PDAOcase13"><name>P-DAO Messages</name>
   <thead>

          <tr><th align='center'>

          <tr><th> </th>
              <th align='left'>P-DAO
              <th>P-DAO 1 to E</th>
              <th align='left'>P-DAO
              <th>P-DAO 2 to B</th>
              <th align='left'>P-DAO
              <th>P-DAO 3 to A</th></tr>

   </thead>
   <tbody>

          <tr><td align='center'>Mode</td>
              <td align='left'>Storing</td>
              <td align='left'>Storing</td>
              <td align='left'>Non-Storing</td></tr>
          <tr><td align='center'>Track Ingress</td>
              <td align='left'>A</td>
              <td align='left'>A</td>
              <td align='left'>A</td></tr>
          <tr><td align='center'>(DODAGID, TrackID)</td>
              <td align='left'>(A,

          <tr><th>Mode</th>
              <td>Storing</td>
              <td>Storing</td>
              <td>Non-Storing</td></tr>
          <tr><th>Track Ingress</th>
              <td>A</td>
              <td>A</td>
              <td>A</td></tr>
          <tr><th>(DODAGID, TrackID)</th>
              <td>(A, 129)</td>
              <td align='left'>(A,
              <td>(A, 129)</td>
              <td align='left'>(A,
              <td>(A, 129)</td></tr>
          <tr><td align='center'>SegmentID</td>
              <td align='left'>1</td>
              <td align='left'>2</td>
              <td align='left'>3</td></tr>
          <tr><td align='center'>VIO</td>
              <td align='left'>C,
          <tr><th>SegmentID</th>
              <td>1</td>
              <td>2</td>
              <td>3</td></tr>
          <tr><th>VIO</th>
              <td>C, D, E</td>
              <td align='left'>A,
              <td>A, B</td>
              <td align='left'>C,
              <td>C, E</td></tr>
          <tr><td align='center'>Targets</td>
              <td align='left'>E</td>
              <td align='left'>B,
          <tr><th>Targets</th>
              <td>E</td>
              <td>B, C</td>
              <td align='left'>F,
              <td>F, G</td></tr>

    </tbody>
        </table>

<t>
   Note in the table above that the segment can terminate at the loose hop as used in
   the example of P-DAO 1 or at the previous hop as done with P-DAO 2.
   Both methods are possible on any segment joined by a loose protection path. P-DAO 1
   generates more signaling since E is the segment Egress when D could be, but
   has the a
   benefit is that it validates that the connectivity between D and E still
   exists.
</t>

<t>As a result result, the RIBs are set as follows:</t>

        <table anchor="RIBcase13"><name>RIB setting</name> Settings</name>
           <thead>

          <tr><th align='center'>Node</th>
              <th align='left'>Destination</th>
              <th align='left'>Origin</th>
              <th align='left'>Next

          <tr><th>Node</th>
              <th>Destination</th>
              <th>Origin</th>
              <th>Next Hop(s)</th>
              <th align='left'>TrackID</th></tr>
              <th>TrackID</th></tr>

   </thead>
      <tbody>

          <tr><td align='center'>E</td>
              <td align='left'>F,

          <tr><td>E</td>
              <td>F, G</td>
              <td align='left'>P-DAO
              <td>P-DAO 1</td>
              <td align='left'>Neighbor</td>
              <td align='left'>(A,
              <td>Neighbor</td>
              <td>(A, 129)</td></tr>

          <tr><td align='center'>D</td>
              <td align='left'>E</td>
              <td align='left'>P-DAO

          <tr><td>D</td>
              <td>E</td>
              <td>P-DAO 1</td>
              <td align='left'>Neighbor</td>
              <td align='left'>(A,
              <td>Neighbor</td>
              <td>(A, 129)</td></tr>

          <tr><td align='center'>C</td>
              <td align='left'>D</td>
              <td align='left'>P-DAO

          <tr><td>C</td>
              <td>D</td>
              <td>P-DAO 1</td>
              <td align='left'>Neighbor</td>
              <td align='left'>(A,
              <td>Neighbor</td>
              <td>(A, 129)</td></tr>

          <tr><td align='center'>"</td>
              <td align='left'>E</td>
              <td align='left'>P-DAO

          <tr><td>"</td>
              <td>E</td>
              <td>P-DAO 1</td>
              <td align='left'>D</td>
              <td align='left'>(A,
              <td>D</td>
              <td>(A, 129)</td></tr>

          <tr><td align='center'>B</td>
              <td align='left'>C</td>
              <td align='left'>P-DAO

          <tr><td>B</td>
              <td>C</td>
              <td>P-DAO 2</td>
              <td align='left'>Neighbor</td>
              <td align='left'>(A,
              <td>Neighbor</td>
              <td>(A, 129)</td></tr>

          <tr><td align='center'>A</td>
              <td align='left'>B</td>
              <td align='left'>P-DAO

          <tr><td>A</td>
              <td>B</td>
              <td>P-DAO 2</td>
              <td align='left'>Neighbor</td>
              <td align='left'>(A,
              <td>Neighbor</td>
              <td>(A, 129)</td></tr>

          <tr><td align='center'>"</td>
              <td align='left'>C</td>
              <td align='left'>P-DAO

          <tr><td>"</td>
              <td>C</td>
              <td>P-DAO 2</td>
              <td align='left'>B</td>
              <td align='left'>(A,
              <td>B</td>
              <td>(A, 129)</td></tr>

          <tr><td align='center'>"</td>
              <td align='left'>E,

          <tr><td>"</td>
              <td>E, F, G</td>
              <td align='left'>P-DAO
              <td>P-DAO 3</td>
              <td align='left'>C,
              <td>C, E</td>
              <td align='left'>(A,
              <td>(A, 129)</td></tr>

    </tbody>
        </table>

<t>
    Packets originated at A to E do not require an encapsulation, but
    they carry a an SRH via C.
    The outer headers of the packets that are forwarded along the Track have
    the following settings:
</t>
        <table anchor="Packetcase13"><name>Packet Header Settings</name>
   <thead>

          <tr><th align='center'>Header</th> align="center">Header</th>
              <th align='center'>IPv6 align="center">IPv6 Source Addr.</th> Address</th>
              <th align='center'>IPv6 Dest. Addr.</th> align="center">IPv6 Destination Address</th>
              <th align='center'>TrackID align="center">TrackID in RPI</th></tr>

   </thead>
   <tbody>
          <tr><td align='center'>Outer</td> align="center">Outer</td>
              <td align='center'>A</td> align="center">A</td>
              <td align='center'>C align="center">C until C then E</td>
              <td align='center'>(A, align="center">(A, 129)</td></tr>
          <tr><td align='center'>Inner</td>
              <td align='center'>X</td> align="center">Inner</td>
              <td align='center'>Either align="center">X</td>
              <td>Either F or G. If X!=A, then E is also permitted.</td>
              <td align='center'>N/A</td></tr> align="center">N/A</td></tr>
    </tbody>
        </table>
<!-- COMMENT: I know this may take some effort, sorry, but I think it would be really useful in the Packet Header Settings tables, here and further below, to also include a column indicating the contents of the SRH. The lack of this made it more complicated, especially in the more complicated cases further along, to understand what's going on.

   AUTH: actually that was easy. Because it's already there. I added at the
   beginning of the section
      Note well: by design, the list of nodes in a VIO in Non-Storing Mode is
   exactly the list that shows in the encapsulation SRH. So in the cases
   detailed below, if the Mode of the P-DAO is Non-Storing, then the VIO
   row can be read as indicating the SRH as well.
-->
<t>
As an example, say that A has a packet for F. Using the RIB in <xref target='RIBcase13'/>:
</t>
<ul>
<li>From P-DAO 3: A encapsulates the packet the Track signaled by P-DAO 3, with the outer header above. Now the destination in the IPv6 Header header is C, and a an SRH signals that the final destination is E.</li>
<li>From P-DAO 2: A forwards to B B, and B forwards to C.</li>
<li>From P-DAO 3: C processes the SRH and sets the destination in the IPv6 Header header to E.</li>
<li>From P-DAO 1: C forwards to D D, and D forwards to E; E decapsulates the packet.</li>
<li>From the Neighbor Cache Entry: E delivers packets to F or G.</li>
</ul>

    </section><!-- Segment Routing -->

    </section><!-- Using Storing Mode Segments -->

    </section>

    </section>

    <section><name>Using Non-Storing Mode joining Joining Tracks</name>

<t>In this formulation:</t>

<ul>
<li>P-DAO 1 signals C==&gt;D==&gt;E-to-(E),F,G</li>
<li>P-DAO 2 signals A==&gt;B==&gt;C-to-(C),E,F,G</li>
</ul>

<t>
    A==&gt;B==&gt;C and C==&gt;D==&gt;E are Tracks expressed as Non-Storing Mode P-DAOs.

</t>

    <section><name>Stitched Tracks</name>

    <t>
    Non-Storing Mode P-DAO 1 and 2 are sent to C and A A, respectively, as follows:
    </t>

        <table anchor="PDAOcase21"><name>P-DAO Messages</name>
   <thead>

          <tr><th align='center'>

          <tr><th> </th>
              <th align='left'>P-DAO
              <th>P-DAO 1 to C</th>
              <th align='left'>P-DAO
              <th>P-DAO 2 to A</th></tr>

   </thead>
   <tbody>

          <tr><td align='center'>Mode</td>
              <td align='left'>Non-Storing</td>
              <td align='left'>Non-Storing</td></tr>
          <tr><td align='center'>Track Ingress</td>
              <td align='left'>C</td>
              <td align='left'>A</td></tr>
          <tr><td align='center'>(DODAGID, TrackID)</td>
              <td align='left'>(C,

          <tr><th>Mode</th>
              <td>Non-Storing</td>
              <td>Non-Storing</td></tr>
          <tr><th>Track Ingress</th>
              <td>C</td>
              <td>A</td></tr>
          <tr><th>(DODAGID, TrackID)</th>
              <td>(C, 131)</td>
              <td align='left'>(A,
              <td>(A, 131)</td></tr>
          <tr><td align='center'>SegmentID</td>
              <td align='left'>1</td>
              <td align='left'>1</td></tr>
          <tr><td align='center'>VIO</td>
              <td align='left'>D,
          <tr><th>SegmentID</th>
              <td>1</td>
              <td>1</td></tr>
          <tr><th>VIO</th>
              <td>D, E</td>
              <td align='left'>B,
              <td>B, C</td></tr>
          <tr><td align='center'>Targets</td>
              <td align='left'>F,
          <tr><th>Targets</th>
              <td>F, G</td>
              <td align='left'>E,
              <td>E, F, G</td></tr>

    </tbody>
        </table>

<t>As a result result, the RIBs are set as follows (using ND "ND" to indicate that the address is discovered by IPv6 Neighbor Discovery <xref target='RFC4861'/><xref target='RFC4861'/> <xref target='RFC8505'/> or an equivalent method:</t> method):</t>

        <table anchor="RIBcase21"><name>RIB setting</name> Settings</name>
           <thead>

          <tr><th align='center'>Node</th>
              <th align='left'>Destination</th>
              <th align='left'>Origin</th>
              <th align='left'>Next

          <tr><th>Node</th>
              <th>Destination</th>
              <th>Origin</th>
              <th>Next Hop(s)</th>
              <th align='left'>TrackID</th></tr>
              <th>TrackID</th></tr>

   </thead>
      <tbody>

          <tr><td align='center'>E</td>
              <td align='left'>F,

          <tr><td>E</td>
              <td>F, G</td>
              <td align='left'>ND</td>
              <td align='left'>Neighbor</td>
              <td align='left'>Any</td></tr>

          <tr><td align='center'>D</td>
              <td align='left'>E</td>
              <td align='left'>ND</td>
              <td align='left'>Neighbor</td>
              <td align='left'>Any</td></tr>

          <tr><td align='center'>C</td>
              <td align='left'>D</td>
              <td align='left'>ND</td>
              <td align='left'>Neighbor</td>
              <td align='left'>Any</td></tr>

          <tr><td align='center'>"</td>
              <td align='left'>E,
              <td>ND</td>
              <td>Neighbor</td>
              <td>Any</td></tr>

          <tr><td>D</td>
              <td>E</td>
              <td>ND</td>
              <td>Neighbor</td>
              <td>Any</td></tr>

          <tr><td>C</td>
              <td>D</td>
              <td>ND</td>
              <td>Neighbor</td>
              <td>Any</td></tr>

          <tr><td>"</td>
              <td>E, F, G</td>
              <td align='left'>P-DAO
              <td>P-DAO 1</td>
              <td align='left'>D,
              <td>D, E</td>
              <td align='left'>(C,
              <td>(C, 131)</td></tr>

          <tr><td align='center'>B</td>
              <td align='left'>C</td>
              <td align='left'>ND</td>
              <td align='left'>Neighbor</td>
              <td align='left'>Any</td></tr>

          <tr><td align='center'>A</td>
              <td align='left'>B</td>
              <td align='left'>ND</td>
              <td align='left'>Neighbor</td>
              <td align='left'>Any</td></tr>

          <tr><td align='center'>"</td>
              <td align='left'>C,

          <tr><td>B</td>
              <td>C</td>
              <td>ND</td>
              <td>Neighbor</td>
              <td>Any</td></tr>

          <tr><td>A</td>
              <td>B</td>
              <td>ND</td>
              <td>Neighbor</td>
              <td>Any</td></tr>

          <tr><td>"</td>
              <td>C, E, F, G</td>
              <td align='left'>P-DAO
              <td>P-DAO 2</td>
              <td align='left'>B,
              <td>B, C</td>
              <td align='left'>(A,
              <td>(A, 131)</td></tr>

    </tbody>
        </table>

<t>
    Packets originated at A to E, F F, and G could be generated with the RPI and the SRH, SRH and no encapsulation.
    Alternatively, A may generate a native packet to the target, target and then encapsulate it with an RPI and an SRH indicating the source-routed path leading to E, as it would for a packet that it routes coming from another node. This is effectively the same case as for packets generated by the root in a RPL network in Non-Storing mode, Mode; see section 8.1.3 of <xref target='RFC9008'/>. target='RFC9008' section="8.1.3"/>. The latter is often preferred since it leads to a single code path, and when the destination when it is F or G, it does not need to understand and process the RPI or the SRH.

    Either way, the packets to E, F, or G carry an SRH via B and C, and when they reach C, C needs to encapsulate them again
    to add an SRH via D and E.
    The encapsulating headers of packets that are forwarded along the Track
    between C and E have the following settings:
</t>

        <table anchor="Packetcase21"><name>Packet Header Settings between Between C and E</name>
   <thead>

          <tr><th align='center'>Header</th> align="center">Header</th>
              <th align='center'>IPv6 align="center">IPv6 Source Addr.</th> Address</th>
              <th align='center'>IPv6 Dest. Addr.</th> align="center">IPv6 Destination Address</th>
              <th align='center'>TrackID align="center">TrackID in RPI</th></tr>

   </thead>
   <tbody>
          <tr><td align='center'>Outer</td> align="center">Outer</td>
              <td align='center'>C</td> align="center">C</td>
              <td align='center'>D align="center">D until D then E</td>
              <td align='center'>(C, align="center">(C, 131)</td></tr>
          <tr><td align='center'>Inner</td> align="center">Inner</td>
              <td align='center'>X</td> align="center">X</td>
              <td align='center'>E, align="center">E, F, or G</td>
              <td align='center'>N/A</td></tr> align="center">N/A</td></tr>
    </tbody>
        </table>

<t>As an example, say that A has a packet for F.  Using the RIB in <xref target='RIBcase21'/>:</t>
<ul>
<li>From P-DAO 2:
   A encapsulates the packet with a destination of F in the Track signaled by
   P-DAO 2. The outer header has source A, destination B, an SRH that
   indicates C as the next loose hop, and a an RPI indicating a TrackID of 131
   from A's namespace, which is distinct from a TrackID of 131 from C's.
</li>
<li>From the SRH:
Packets forwarded by B have source A, destination C, a consumed SRH, and a an RPI indicating a TrackID of 131 from A's namespace. C decapsulates.
</li>
<li>
From P-DAO 1:
C encapsulates the packet with a destination of F in the Track signaled by P-DAO 1. The outer header has source C, destination D, an SRH that indicates E as the next loose hop, and a an RPI indicating a TrackID of 131 from C's namespace. E decapsulates.
</li>
</ul>

    </section><!-- Stitched Tracks -->

    </section>

    <section><name>External Routes</name>

<t>In this formulation:</t>

<ul>
<li>P-DAO 1 signals C==&gt;D==&gt;E-to-(E)</li>
<li>P-DAO 2 signals A==&gt;B==&gt;C-to-(C),E</li>
<li>P-DAO 3 signals F and G via the A--&gt;E-to-F,G Track</li>
</ul>

    <t>
    Non-Storing Mode P-DAO 1 is sent to C C, and Non-Storing Mode P-DAO P-DAOs 2 and 3 are sent to A, as follows:
    </t>

        <table anchor="PDAOcase22"><name>P-DAO Messages</name>
   <thead>

          <tr><th align='center'>

          <tr><th> </th>
              <th align='left'>P-DAO
              <th>P-DAO 1 to C</th>
              <th align='left'>P-DAO
              <th>P-DAO 2 to A</th>
              <th align='left'>P-DAO
              <th>P-DAO 3 to A</th></tr>

   </thead>
   <tbody>

          <tr><td align='center'>Mode</td>
              <td align='left'>Non-Storing</td>
              <td align='left'>Non-Storing</td>
              <td align='left'>Non-Storing</td></tr>
          <tr><td align='center'>Track Ingress</td>
              <td align='left'>C</td>
              <td align='left'>A</td>
              <td align='left'>A</td></tr>
          <tr><td align='center'>(DODAGID, TrackID)</td>
              <td align='left'>(C,

          <tr><th>Mode</th>
              <td>Non-Storing</td>
              <td>Non-Storing</td>
              <td>Non-Storing</td></tr>
          <tr><th>Track Ingress</th>
              <td>C</td>
              <td>A</td>
              <td>A</td></tr>
          <tr><th>(DODAGID, TrackID)</th>
              <td>(C, 131)</td>
              <td align='left'>(A,
              <td>(A, 129)</td>
              <td align='left'>(A,
              <td>(A, 141)</td></tr>
          <tr><td align='center'>SegmentID</td>
              <td align='left'>1</td>
              <td align='left'>1</td>
              <td align='left'>1</td></tr>
          <tr><td align='center'>VIO</td>
              <td align='left'>D,
          <tr><th>SegmentID</th>
              <td>1</td>
              <td>1</td>
              <td>1</td></tr>
          <tr><th>VIO</th>
              <td>D, E</td>
              <td align='left'>B,
              <td>B, C</td>
              <td align='left'>E</td></tr>
          <tr><td align='center'>Targets</td>
              <td align='left'></td>
              <td align='left'>E</td>
              <td align='left'>F,
              <td>E</td></tr>
          <tr><th>Targets</th>
              <td></td>
              <td>E</td>
              <td>F, G</td></tr>

    </tbody>
        </table>
<t>Note in the table above that E is an implicit Target in P-DAO 1 and so is C in P-DAO 2.
As Non-Storing Mode Egress nodes node addresses, they are not listed in the respective RTOs.</t>
<t>As a result result, the RIBs are set as follows:</t>

        <table anchor="RIBcase22"><name>RIB setting</name> Settings</name>
                   <thead>

          <tr><th align='center'>Node</th>
              <th align='left'>Destination</th>
              <th align='left'>Origin</th>
              <th align='left'>Next

          <tr><th>Node</th>
              <th>Destination</th>
              <th>Origin</th>
              <th>Next Hop(s)</th>
              <th align='left'>TrackID</th></tr>
              <th>TrackID</th></tr>

   </thead>
      <tbody>

          <tr><td align='center'>E</td>
              <td align='left'>F,

          <tr><td>E</td>
              <td>F, G</td>
              <td align='left'>ND</td>
              <td align='left'>Neighbor</td>
              <td align='left'>Any</td></tr>

          <tr><td align='center'>D</td>
              <td align='left'>E</td>
              <td align='left'>ND</td>
              <td align='left'>Neighbor</td>
              <td align='left'>Any</td></tr>

          <tr><td align='center'>C</td>
              <td align='left'>D</td>
              <td align='left'>ND</td>
              <td align='left'>Neighbor</td>
              <td align='left'>Any</td></tr>

          <tr><td align='center'>"</td>
              <td align='left'>E</td>
              <td align='left'>P-DAO
              <td>ND</td>
              <td>Neighbor</td>
              <td>Any</td></tr>

          <tr><td>D</td>
              <td>E</td>
              <td>ND</td>
              <td>Neighbor</td>
              <td>Any</td></tr>

          <tr><td>C</td>
              <td>D</td>
              <td>ND</td>
              <td>Neighbor</td>
              <td>Any</td></tr>

          <tr><td>"</td>
              <td>E</td>
              <td>P-DAO 1</td>
              <td align='left'>D,
              <td>D, E</td>
              <td align='left'>(C,
              <td>(C, 131)</td></tr>

          <tr><td align='center'>B</td>
              <td align='left'>C</td>
              <td align='left'>ND</td>
              <td align='left'>Neighbor</td>
              <td align='left'>Any</td></tr>

          <tr><td align='center'>A</td>
              <td align='left'>B</td>
              <td align='left'>ND</td>
              <td align='left'>Neighbor</td>
              <td align='left'>Any</td></tr>

          <tr><td align='center'>"</td>
              <td align='left'>C,

          <tr><td>B</td>
              <td>C</td>
              <td>ND</td>
              <td>Neighbor</td>
              <td>Any</td></tr>

          <tr><td>A</td>
              <td>B</td>
              <td>ND</td>
              <td>Neighbor</td>
              <td>Any</td></tr>

          <tr><td>"</td>
              <td>C, E</td>
              <td align='left'>P-DAO
              <td>P-DAO 2</td>
              <td align='left'>B,
              <td>B, C</td>
              <td align='left'>(A,
              <td>(A, 129)</td></tr>

          <tr><td align='center'>"</td>
              <td align='left'>F,

          <tr><td>"</td>
              <td>F, G</td>
              <td align='left'>P-DAO
              <td>P-DAO 3</td>
              <td align='left'>E</td>
              <td align='left'>(A,
              <td>E</td>
              <td>(A, 141)</td></tr>

    </tbody>
        </table>

<t>
    The encapsulating headers of packets that are forwarded along the Track
    between C and E have the following settings:
</t>

        <table anchor="Packetcase22"><name>Packet Header Settings</name>
   <thead>

          <tr><th align='center'>Header</th> align="center">Header</th>
              <th align='center'>IPv6 align="center">IPv6 Source Addr.</th> Address</th>
              <th align='center'>IPv6 Dest. Addr.</th> align="center">IPv6 Destination Address</th>
              <th align='center'>TrackID align="center">TrackID in RPI</th></tr>

   </thead>
   <tbody>
          <tr><td align='center'>Outer</td> align="center">Outer</td>
              <td align='center'>C</td> align="center">C</td>
              <td align='center'>D align="center">D until D then E</td>
              <td align='center'>(C, align="center">(C, 131)</td></tr>
          <tr><td align='center'>Middle</td> align="center">Middle</td>
              <td align='center'>A</td> align="center">A</td>
              <td align='center'>E</td> align="center">E</td>
              <td align='center'>(A, align="center">(A, 141)</td></tr>
          <tr><td align='center'>Inner</td> align="center">Inner</td>
              <td align='center'>X</td> align="center">X</td>
              <td align='center'>E, F align="center">E, F, or G</td>
              <td align='center'>N/A</td></tr> align="center">N/A</td></tr>
    </tbody>
        </table>

    <!--
          1.  non Storing Mode P-DAO 1 is sent to C. It has Root = C, SRVIO = D, E, Track ID 131 from C's namespace, Target = E
      2.  non Storing Mode P-DAO 2 is then sent to A. It has Root = A, SRVIO = B, C, Track ID 129 from A's namespace, Target = E
      3.  non Storing Mode P-DAO 3 is then sent to A. It has Root = A, SRVIO = E, Track ID 141 from A's namespace, Target = F, G

    >From P-DAO 3: A encapsulates packets with dest =   F | G. The outer header has source = A, destination = E, and RPI = 141.
    This may recurse with:
    >From P-DAO 2: A encapsulates packets with dest =  E. The outer header has source = A, destination = B, SRH = C and RPI = 129.
    Packets forwarded by B have source= A, destination = C , SRH =, and RPI = 129. C decapsulates.
    >From P-DAO 1: C  encapsulates packets with dest =  E. The outer header has source= C, destination = D, SRH = E and RPI = 131.
    E decapsulates if encapsulated.
    -->

<t>As an example, say that A has a packet for F.  Using the RIB in <xref target='RIBcase22'/>:</t>
<ul>
<li>
From P-DAO 3: A encapsulates the packet with a destination of F in the Track signaled by P-DAO 3. The outer header has source A, destination E, and a an RPI indicating a TrackID of 141 from A's namespace. This recurses with: with the following.
</li>
<li>
From P-DAO 2: A encapsulates the packet with a destination of E in the Track signaled by P-DAO 2. The outer header has source A, destination B, an SRH that indicates C as the next loose hop, and a an RPI indicating a TrackID of 129 from A's namespace.
</li>
<li>
From the SRH:
Packets forwarded by B have source A, destination C , C, a consumed SRH, and a an RPI indicating a TrackID of 129 from A's namespace. C decapsulates.
</li>
<li>
From P-DAO 1:
C encapsulates the packet with a destination of E in the Track signaled by P-DAO 1. The outer header has source C, destination D, an SRH that indicates E as the next loose hop, and a an RPI indicating a TrackID of 131 from C's namespace. E decapsulates.
</li>
</ul>

    </section><!-- External routes -->

    </section>

    <section anchor="nssr"><name>Segment Routing</name>

<t>In this formulation:</t>

<ul>
<li>P-DAO 1 signals C==&gt;D==&gt;E-to-(E)</li>
<li>P-DAO 2 signals A==&gt;B-to-C</li>
<li>P-DAO 3 signals F and G via the A--&gt;C--&gt;E-to-(E),F,G Track</li>
</ul>

    <t>
    Non-Storing Mode P-DAO 1 is sent to C C, and Non-Storing Mode P-DAO P-DAOs 2 and 3 are
    sent to A, as follows:
    </t>

        <table anchor="PDAOcase23"><name>P-DAO Messages</name>
   <thead>

          <tr><th align='center'>

          <tr><th> </th>
              <th align='left'>P-DAO
              <th>P-DAO 1 to C</th>
              <th align='left'>P-DAO
              <th>P-DAO 2 to A</th>
              <th align='left'>P-DAO
              <th>P-DAO 3 to A</th></tr>

   </thead>
   <tbody>

          <tr><td align='center'>Mode</td>
              <td align='left'>Non-Storing</td>
              <td align='left'>Non-Storing</td>
              <td align='left'>Non-Storing</td></tr>
          <tr><td align='center'>Track Ingress</td>
              <td align='left'>C</td>
              <td align='left'>A</td>
              <td align='left'>A</td></tr>
          <tr><td align='center'>(DODAGID, TrackID)</td>
              <td align='left'>(C,

          <tr><th>Mode</th>
              <td>Non-Storing</td>
              <td>Non-Storing</td>
              <td>Non-Storing</td></tr>
          <tr><th>Track Ingress</th>
              <td>C</td>
              <td>A</td>
              <td>A</td></tr>
          <tr><th>(DODAGID, TrackID)</th>
              <td>(C, 131)</td>
              <td align='left'>(A,
              <td>(A, 129)</td>
              <td align='left'>(A,
              <td>(A, 141)</td></tr>
          <tr><td align='center'>SegmentID</td>
              <td align='left'>1</td>
              <td align='left'>1</td>
              <td align='left'>1</td></tr>
          <tr><td align='center'>VIO</td>
              <td align='left'>D,
          <tr><th>SegmentID</th>
              <td>1</td>
              <td>1</td>
              <td>1</td></tr>
          <tr><th>VIO</th>
              <td>D, E</td>
              <td align='left'>B</td>
              <td align='left'>C,
              <td>B</td>
              <td>C, E</td></tr>
          <tr><td align='center'>Targets</td>
              <td align='left'></td>
              <td align='left'>C</td>
              <td align='left'>F,
          <tr><th>Targets</th>
              <td></td>
              <td>C</td>
              <td>F, G</td></tr>

    </tbody>
        </table>

<!-- COMMENT: Is it correct that in the P-DAO 1 to C the target is empty? Maybe I misunderstood, but I would expect the target to be E.
   AUTH: this is NSM and in NSM the egress MUST be considered a target implicitly

   Quote from section 5.3

      In the case of an NSM-VIO, the complete list can be loose and
      excludes the Ingress node, starting at the first loose hop and
      ending at a Track Egress; the Track Egress MUST be considered as
      an implicit Target, so it MUST NOT be signaled in a RPL Target
      Option.

-->

<t>As a result result, the RIBs are set as follows:</t>

        <table anchor="RIBcase23"><name>RIB setting</name> Settings</name>
                   <thead>

          <tr><th align='center'>Node</th>
              <th align='left'>Destination</th>
              <th align='left'>Origin</th>
              <th align='left'>Next

          <tr><th>Node</th>
              <th>Destination</th>
              <th>Origin</th>
              <th>Next Hop(s)</th>
              <th align='left'>TrackID</th></tr>
              <th>TrackID</th></tr>

   </thead>
      <tbody>

          <tr><td align='center'>E</td>
              <td align='left'>F,

          <tr><td>E</td>
              <td>F, G</td>
              <td align='left'>ND</td>
              <td align='left'>Neighbor</td>
              <td align='left'>Any</td></tr>

          <tr><td align='center'>D</td>
              <td align='left'>E</td>
              <td align='left'>ND</td>
              <td align='left'>Neighbor</td>
              <td align='left'>Any</td></tr>

          <tr><td align='center'>C</td>
              <td align='left'>D</td>
              <td align='left'>ND</td>
              <td align='left'>Neighbor</td>
              <td align='left'>Any</td></tr>

          <tr><td align='center'>"</td>
              <td align='left'>E</td>
              <td align='left'>P-DAO
              <td>ND</td>
              <td>Neighbor</td>
              <td>Any</td></tr>

          <tr><td>D</td>
              <td>E</td>
              <td>ND</td>
              <td>Neighbor</td>
              <td>Any</td></tr>

          <tr><td>C</td>
              <td>D</td>
              <td>ND</td>
              <td>Neighbor</td>
              <td>Any</td></tr>

          <tr><td>"</td>
              <td>E</td>
              <td>P-DAO 1</td>
              <td align='left'>D,
              <td>D, E</td>
              <td align='left'>(C,
              <td>(C, 131)</td></tr>

          <tr><td align='center'>B</td>
              <td align='left'>C</td>
              <td align='left'>ND</td>
              <td align='left'>Neighbor</td>
              <td align='left'>Any</td></tr>

          <tr><td align='center'>A</td>
              <td align='left'>B</td>
              <td align='left'>ND</td>
              <td align='left'>Neighbor</td>
              <td align='left'>Any</td></tr>

          <tr><td align='center'>"</td>
              <td align='left'>B,

          <tr><td>B</td>
              <td>C</td>
              <td>ND</td>
              <td>Neighbor</td>
              <td>Any</td></tr>

          <tr><td>A</td>
              <td>B</td>
              <td>ND</td>
              <td>Neighbor</td>
              <td>Any</td></tr>

          <tr><td>"</td>
              <td>B, C</td>
              <td align='left'>P-DAO
              <td>P-DAO 2</td>
              <td align='left'>C</td>
              <td align='left'>(A,
              <td>C</td>
              <td>(A, 129)</td></tr>

          <tr><td align='center'>"</td>
              <td align='left'>E,

          <tr><td>"</td>
              <td>E, F, G</td>
              <td align='left'>P-DAO
              <td>P-DAO 3</td>
              <td align='left'>C,
              <td>C, E</td>
              <td align='left'>(A,
              <td>(A, 141)</td></tr>

    </tbody>
        </table>

<t>
    The encapsulating headers of packets that are forwarded along the Track
    between A and B have the following settings:
</t>

        <table anchor="Packetcase231"><name>Packet Header Settings</name>
   <thead>

          <tr><th align='center'>Header</th> align="center">Header</th>
              <th align='center'>IPv6 align="center">IPv6 Source Addr.</th> Address</th>
              <th align='center'>IPv6 Dest. Addr.</th> align="center">IPv6 Destination Address</th>
              <th align='center'>TrackID align="center">TrackID in RPI</th></tr>

   </thead>
   <tbody>
          <tr><td align='center'>Outer</td> align="center">Outer</td>
              <td align='center'>A</td> align="center">A</td>
              <td align='center'>B align="center">B until D then E</td>
              <td align='center'>(A, align="center">(A, 129)</td></tr>
          <tr><td align='center'>Middle</td> align="center">Middle</td>
              <td align='center'>A</td> align="center">A</td>
              <td align='center'>C</td> align="center">C</td>
              <td align='center'>(A, align="center">(A, 141)</td></tr>
          <tr><td align='center'>Inner</td> align="center">Inner</td>
              <td align='center'>X</td> align="center">X</td>
              <td align='center'>E, F align="center">E, F, or G</td>
              <td align='center'>N/A</td></tr> align="center">N/A</td></tr>
    </tbody>
        </table>

 <t>
    The encapsulating headers of packets that are forwarded along the Track
    between B and C have the following settings:
</t>

        <table anchor="Packetcase232"><name>Packet Header Settings</name>
   <thead>

          <tr><th align='center'>Header</th> align="center">Header</th>
              <th align='center'>IPv6 align="center">IPv6 Source Addr.</th> Address</th>
              <th align='center'>IPv6 Dest. Addr.</th> align="center">IPv6 Destination Address</th>
              <th align='center'>TrackID align="center">TrackID in RPI</th></tr>

   </thead>
   <tbody>
          <tr><td align='center'>Outer</td> align="center">Outer</td>
              <td align='center'>A</td> align="center">A</td>
              <td align='center'>C</td> align="center">C</td>
              <td align='center'>(A, align="center">(A, 141)</td></tr>
          <tr><td align='center'>Inner</td> align="center">Inner</td>
              <td align='center'>X</td> align="center">X</td>
              <td align='center'>E, F align="center">E, F, or G</td>
              <td align='center'>N/A</td></tr> align="center">N/A</td></tr>
    </tbody>
        </table>

<t>
    The encapsulating headers of packets that are forwarded along the Track
    between C and E have the following settings:
</t>

        <table anchor="Packetcase233"><name>Packet Header Settings</name>
   <thead>

          <tr><th align='center'>Header</th> align="center">Header</th>
              <th align='center'>IPv6 align="center">IPv6 Source Addr.</th> Address</th>
              <th align='center'>IPv6 Dest. Addr.</th> align="center">IPv6 Destination Address</th>
              <th align='center'>TrackID align="center">TrackID in RPI</th></tr>

   </thead>
   <tbody>
          <tr><td align='center'>Outer</td> align="center">Outer</td>
              <td align='center'>C</td> align="center">C</td>
              <td align='center'>D align="center">D until D then E</td>
              <td align='center'>(C, align="center">(C, 131)</td></tr>
          <tr><td align='center'>Middle</td> align="center">Middle</td>
              <td align='center'>A</td> align="center">A</td>
              <td align='center'>E</td> align="center">E</td>
              <td align='center'>(A, align="center">(A, 141)</td></tr>
          <tr><td align='center'>Inner</td> align="center">Inner</td>
              <td align='center'>X</td> align="center">X</td>
              <td align='center'>E, F align="center">E, F, or G</td>
              <td align='center'>N/A</td></tr> align="center">N/A</td></tr>
    </tbody>
        </table>

    <!--

      1.  non Storing Mode P-DAO 1 is sent to C. It has Root = C, SRVIO = D, E, Track ID 131 from C's namespace, (Target = E is implicit)
      2.  non Storing Mode P-DAO 2 is then sent to A. It has Root = A, SRVIO = B,  Track ID 129 from A's namespace, Target = C
      3.  non Storing Mode P-DAO 3 is then sent to A. It has Root = A, SRVIO = C, E, Track ID 141 from A's namespace, Target = F, G

  -->

<t>As an example, say that A has a packet for F.  Using the <xref target='Packetcase231'/>:</t>
<ul>
<li>From P-DAO 3: A encapsulates the packet with a destination of F in the Track signaled by P-DAO 3. The outer header has source A, destination C, an SRH that indicates E as the next loose hop, and a an RPI indicating a TrackID of 141 from A's namespace. This recurses with: with the following.
</li>
<li>
From P-DAO 2: A encapsulates the packet with a destination of C in the Track signaled by P-DAO 2. The outer header has source A, destination B, and a an RPI indicating a TrackID of 129 from A's namespace. B decapsulates forwards to C based on a sibling connected route.
</li>
<li>
From the SRH: C consumes the SRH and makes the destination E.
</li>
<li>
From P-DAO 1:
C encapsulates the packet with a destination of E in the Track signaled by P-DAO 1. The outer header has source C, destination D, an SRH that indicates E as the next loose hop, and a an RPI indicating a TrackID of 131 from C's namespace. E decapsulates.
</li>
</ul>

    </section><!-- Segment Routing -->

  </section><!-- Using Non-Storing Mode joining Tracks -->

</section><!-- Example Track Signaling -->

    </section>

  </section>

</section>

<section anchor='concepts'><name>Complex Tracks</name>

<t>To increase the reliability of the P2P transmission, this specification
   enables building a collection of protection paths between the same Ingress and Egress
   Nodes and combining them within the same TrackID, as shown in <xref
   target="FigLegs"/>.
Protection paths may be interleaved at the edges of loose hops or remain parallel.
</t><t>
   The segments that join the loose hops of a protection path are installed with the same
   TrackID as the protection path. But each individual protection path and segment has its own
   P-RouteID which that allows it to be managed separately.

<!--[rfced] Please clarify the meaning of "participates to" in the
following sentence.

Current:
   Two protection paths of the same Track may cross at a common node
   that participates to a segment of Each each protection path, path or that
   may be joined by additional segments.
-->

   Two protection paths of the same
   Track may cross at a common node that participates to a segment of each
   protection path or that may be joined by additional segments.
   The final path of a packet may then be the result of interleaving
   those two (and possibly more) protection paths.
   In that case case, the common node has more than one next hop in its RIB
   associated to the Track, Track but no specific signal in the packet to indicate
   which segment is being followed. A next hop that can reach the loose hop is
   selected.
</t>
<figure anchor="FigLegs">
          <name>Segments and Tracks</name>
       <artwork align="center"  name="" type="" alt="">
<![CDATA[ alt=""><![CDATA[
                 < Controller Plane Functions >

                       Southbound API

   _-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-
 _-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-

                      +----------+
                      | RPL Root |
                      +----------+

         (           main  DODAG                  )

  (                    all around                             )

  <-    Protection path 1   via      B,   E              ->
  <--- Segment 1 A,B ---> <------- Segment 2 C,D,E ------->

             FWD  --   Relay --    FWD  --    FWD           Target 1
         /-- Node   --  Node   --  Node   --  Node \       /
      --/    (A)        (B) \      (C)        (D)   \     /
Track                        \                       Track
Ingress                    Segment 5                Egress -- Target
  (I)                           \                 --  (E)       2
      \                        \                 /        \
       \ FWD   --   FWD  --   Relay --   FWD  --/          \
         Node    -- Node   -- Node    -- Node               Target 3
         (F)        (G)       (H)        (J)

  <------ Segment 3 F,G,H ------> <---- Segment 4 J,E ---->
  <-      Protection path 2  via     H,   E              ->

  <--- Segment 1 A,B ---> <- S5-> <---- Segment 4 J,E ---->
  <-      Protection path 3  via   B,    H,    E         ->

                                                                  )
   (

             (                                   )
]]></artwork>                                   )]]></artwork>
</figure>

<t>

<!--[rfced] The following text is difficult to read. May we add
parentheses as shown below for clarity?

Original:
   Note that while this specification enables building both segments
   inside a protection path, for instance segment 2 above which is
   within protection path 1, and Inter-protection-path segments (i.e.,
   North-South), for instance segment 5 above which joins protection
   path 1 and protection path 2, it does not signal to the Ingress which
   Inter-protection-path segments are available, so the use of North-
   South segments and associated path redundancy functions is currently
   limited.

Perhaps:
   Note that while this specification enables building both segments
   inside a protection path, for instance, segment 2 above (which is
   within protection path 1) and Inter-protection-path segments (i.e.,
   North-South) such as segment 5 above (which joins protection paths
   1 and 2), it does not signal which Inter-protection-path segments
   are available to the Ingress, so the use of North-South segments
   and associated path redundancy functions is currently limited.
-->

   Note that while this specification enables building both segments inside a
   protection path, for instance segment 2 above which is within protection path 1,
   and Inter-protection-path segments (i.e., North-South), for instance segment 5 above which joins
   protection path 1 and protection path 2, it does not signal to the Ingress which Inter-protection-path segments
   are available, so the use of North-South segments and associated path redundancy
   functions is currently limited. The only possibility available at this time
   is to define overlapping protection paths as illustrated in <xref target="FigLegs"/>,
   with protection path 3 that is congruent with protection path 1 until node B and that is congruent with protection path
   2 from node H on, abstracting segment 5 as a forward segment.
 </t>

</section>	<!-- Complex Tracks -->

<section anchor='inandout'><name>Scope and Expectations</name>

<section anchor='mtsch'><name>External Dependencies</name>
<t>
    This specification expects that the main DODAG is operated in RPL
    Non-Storing Mode to sustain the exchanges with the Root. Based on its
    comprehensive knowledge of the parent-child relationship, the Root can form
    an abstracted view of the whole DODAG topology. This document adds the
    capability for nodes to advertise additional sibling information to
    complement the topological awareness of the Root to be passed on to the PCE, PCE
    and enable enables the PCE to build more / better more/better paths that traverse those siblings.
 </t><t>
    P-Routes require resources such as routing table space in the
    routers and bandwidth on the links; the amount of state that
    is installed in each node must be computed to fit within the node's memory,
    and the amount of rerouted traffic must fit within the capabilities of
    the transmission links. The methods used to learn the node capabilities and
    the resources that are available in the devices and in the network are out
    of scope for this document. The method to capture and report the LLN link
    capacity and reliability statistics are also out of scope. They may be
    fetched from the nodes through network management functions or other forms
    of telemetry such as OAM. Operations, Administration, and Maintenance (OAM).
</t>
</section><!-- External Dependencies
</section>

<!-- [rfced] Please clarify this section title. We are unsure what
"Positioning" refers to. In addition, not all of the RFCs mentioned in
the section are Standards Track documents, so another term like
"Specifications" is more accurate.

Original:
  3.7.2. Positioning vs. Related IETF Standards

Perhaps A:
  3.7.2. Related IETF Specifications

or
Perhaps B:
  3.7.2. Relationship to Other IETF Specifications
-->

<section anchor='ietfr'><name>Positioning vs. Versus Related IETF Standards</name>
<section anchor='extdep'><name>Extending 6TiSCH</name>
<t>
    The 6TiSCH architecture <xref target='RFC9030'> "6TiSCH Architecture"</xref> target='RFC9030'></xref> leverages a centralized model that is similar to that of the
    DetNet architecture <xref target='RFC8655'>
    "Deterministic Networking Architecture"</xref>, target='RFC8655'></xref>,
    whereby the device resources and capabilities are exposed to an external
    controller which that installs routing states into the network based on its own
    objective functions that reside in that external entity.
</t>

</section><!-- Extending 6TiSCH -->

</section>

<section anchor='mdet'><name>Mapping to DetNet</name>

<t>
   DetNet Forwarding Nodes only understand the simple 1-to-1 forwarding
   sublayer transport operation along a segment whereas the more sophisticated
   Relay nodes can also provide service sublayer functions such as Replication
   and Elimination.
</t>
<t>
   One possible mapping between DetNet and this specification
   is to signal the Relay Nodes as the hops of a protection path and the forwarding Nodes nodes
   as the hops in a segment that join the Relay nodes as illustrated in <xref
   target="FigLegs"/>.
</t>

</section> <!-- Mapping to DetNet -->
<section anchor='pmce'><name>Leveraging PCE</name>
<t>
    With DetNet and 6TiSCH, the component of the controller that is responsible
    of
    for computing routes is a PCE. The PCE
    computes its routes based on its own objective functions such functions, as described
    in <xref target='RFC4655'/>, and typically controls the routes using the
    PCE Communication Protocol (PCEP) by <xref target='RFC5440'/>.  While this specification
    expects a PCE PCE, and while PCEP might effectively be used between the Root and
    the PCE, the control protocol between the PCE and the Root is out of scope.
</t>
    <t>
    This specification also expects a single PCE with a full view of the
    network. Distributing the PCE function for a large network is out of scope.
    This specification uses the RPL Root as a proxy to the PCE.

<!--[rfced] Does "In that case" refer to when the PCE is collocated
with the Root or when it resides in an external controller? What
does "one possibility" refer to?

Original:
   The PCE may be collocated with the Root, or may reside in an
   external Controller. In that case, the protocol between the Root
   and the PCE is out of scope and mapped to RPL inside the DODAG; one
   possibility is for the Root to transmit to the PCEs the information
   it received in RPL DAOs including all the SIOs that detail the
   parent/child and sibling information.
-->

    The PCE may be
    collocated with the Root or reside in an external controller.
    In that case, the protocol between the Root and the PCE is out of scope
    and mapped to RPL inside the DODAG; one possibility is for
    the Root to transmit to the PCEs the information it received in RPL DAOs
    including all the SIOs that detail the parent/child and sibling information.
    </t>

    <t>
    The algorithm to compute the paths, the protocol used by the PCE PCE,
    and the metrics and link statistics involved in the computation are also out
    of scope. The effectiveness of the route computation by the PCE depends on
    the quality of the metrics that are reported from the RPL network.
    Which metrics are used and how they are reported is are out of scope, but the
    expectation is that they are mostly of a long-term, statistical nature, nature and
    provide visibility on link throughput, latency, stability stability, and availability
    over relatively long periods.
    </t>
</section> <!-- Leveraging PCE -->
<section anchor='mraw'><name>Providing for RAW</name>
<t>

<!--[rfced] May we revise this text to be two sentences to improve
readability?

Original:
   The <xref target='I-D.ietf-raw-architecture'>RAW Architecture</xref> RAW Architecture [RAW-ARCHI] extends the definition of Track,
   as being composed of forward directional segments and North-South
   bidirectional segments, to enable additional path diversity, using
   Packet ARQ, Replication, Elimination, and Overhearing (PAREO)
   functions over the available paths, to provide a dynamic balance
   between the reliability and availability requirements of the flows
   and the need to conserve energy and spectrum.

Perhaps:
   The RAW architecture [RAW-ARCH] extends the definition of Track as
   being composed of forward directional segments and North-South
   bidirectional segments to enable additional path diversity using
   PAREO functions over the available paths. This provides a dynamic
   balance between the reliability and availability requirements of
   the flows and the need to conserve energy and spectrum.
-->

    The RAW architecture <xref target='RFC9912'></xref> extends the definition of
    Track, as being composed of forward directional segments and North-South
    bidirectional segments, to enable additional path diversity, using PAREO functions over the available paths, to provide a dynamic balance between the reliability and availability requirements of the flows and the need to conserve energy and spectrum. This specification prepares for RAW by setting up the Tracks, but it only forms DODAGs, which are composed of aggregated end-to-end loose source routed source-routed protection paths, joined by strict routed segments, all oriented forward.
     </t>
    <t>
    The RAW Architecture architecture defines a dataplane data plane extension of the PCE called the Point of Local Repair (PLR), (PLR) that adapts the use of the path redundancy within a Track to defeat the diverse causes of packet loss.  The PLR controls the forwarding operation of the packets within a Track.
    This specification can use but does not impose a PLR and does not provide
    the policies that would select which packets are routed through which
    path within a Track, in Track (in other words, how the PLR may use the path redundancy within
    the Track. Track). By default, the use of the available redundancy is limited to simple load balancing, and all the segments are forward unidirectional only.
    </t>
    <t>
    A Track may be set up to reduce the load around the Root, Root or to enable
    urgent traffic to flow more directly. This specification does not provide
    the policies that would decide which flows are routed through which Track.
    In a Non-Storing Mode RPL Instance, the main DODAG provides a default route
    via the Root, and the Tracks provide more specific more-specific routes to the Track
    Targets.
    </t>

</section>

</section>

</section>

</section >

<!-- Providing for RAW -->

</section><!-- Positioning vs. Related IETF Standards -->

</section><!-- Scope [rfced] Should the title of this section include "Amending" as the
section discusses how this document both "Extends" and Expectations -->

</section ><!-- Context "Amends"? Or is
the current okay?

Current
  4.  Extending Existing RFCs

Perhaps:
  4.  Extending and Goal Amending Existing RFCs
-->

  <section anchor='ext'><name>Extending existing Existing RFCs </name>

  <t>
    This section explains which changes are extensions to existing
    specifications, and which changes are amendments to existing
    specifications.
    It is expected that extensions to existing specifications do will not cause
    existing code on legacy 6LRs to malfunction, as the extensions will
    simply be ignored. New code is required for an extension.

<!--[rfced] Is "participate" the intended word or would "function" be
clearer/correct?

Original:
   Those 6LRs will be unable to participate in the new mechanisms,
   but may also cause projected DAOs to be impossible to install.

Perhaps:
   Those 6LRs will be unable to function in the new mechanisms
   and may also make the P-DAOs impossible to install.
-->

    Those 6LRs will be unable to participate in the new mechanisms and may
    also cause P-DAOs to be impossible to install.
    Amendments to existing specifications are situations where there are
    semantic changes required to existing code, code and which may require where new unit tests may be required to
    confirm that legacy operations will continue unaffected.
  </t>

<!--[rfced] The titles of Sections 4.1, 4.2, and 4.3 do not parse. How
may we update this for clarity? Is "RPL" necessary to include?

Original:
   4.1. Extending RPL RFC 6550
   4.2  Extending RPL RFC 6553
   4.3  Extending RPL RFC 8138

Perhaps:
   4.1. Extending RFC 6550
   4.2  Extending RFC 6553
   4.3  Extending RFC 8138
-->

    <section anchor='ext6550'><name>Extending RPL RFC 6550</name>
    <t>
    This specification Extends RPL <xref target='RFC6550'/> to enable the Root
    to install forward routes inside a main DODAG that is operated as
    Non-Storing Mode. The Root issues a Projected DAO (P-DAO) P-DAO message
    (see <xref target='extP-DAO'/>) to the Track Ingress; the P-DAO message
    contains a new Via Information Option (VIO) VIO that installs a strict
    or a loose sequence of hops to form a Track segment or a
    protection path, respectively.
    </t>
    <t>
    The P-DAO Request (PDR) is a new message detailed in <xref target='P-DAOreq'/>.
    As per <xref target="RFC6550" /> section 6, section="6"/>, if a node receives this message and
    it does not understand this new Code, code, it then discards the message.
    When the Root initiates communication to a node that it has not communicated
    with before and which that it has not ascertained to implement this specification
    (by means such as capabilities), then the Root SHOULD <bcp14>SHOULD</bcp14> request
    a PDR-ACK.
    </t>

    <t>
    A P-DAO Request (PDR) PDR message
    enables a Track Ingress to request the Track from the Root. The
    resulting Track is also a DODAG for which the Track Ingress is the Root,
    and the owner is the address that serves as the DODAGID and is authoritative for the
    associated namespace from which the TrackID is selected. In the
    context of this specification, the installed route appears as a more
    specific more-specific
    route to the Track Targets, and the Track Ingress forwards
    the packets towards toward the Targets via the Track using normal longest
	match IP forwarding.
    </t>
    <t>
    To ensure that the PDR and P-DAO messages can flow at most times,
    it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the nodes involved in a Track maintain
    multiple parents in the  main DODAG, advertise them all to the Root,
    and use them in turn to retry similar packets. It is also
    RECOMMENDED
    <bcp14>RECOMMENDED</bcp14> that the Root uses diverse source route paths to retry
    similar messages to the nodes in the Track.
    </t>
    <section anchor='extP-DAO'><name>Projected DAO</name>

   <t>
   Section 6 of
   <xref target='RFC6550'/> target='RFC6550' section="6"/> introduces the RPL Control Message
   Options (CMO), (CMOs), including the RPL Target Option (RTO) and Transit Information Option (TIO), which can be placed in RPL messages such as the destination
   Advertisement Object (DAO). DAO. A DAO message signals routing information to one
   or more Targets indicated in RTOs, the RTOs and provides one and only one via-node in
   the TIO, with the via-node being the tunnel end-point endpoint to reach the targets.
   </t>
   <t>
     This document Amends the specification of the DAO to create the P-DAO
     message.
     This Amended DAO is signaled with a new "Projected DAO" (P) flag, flag; see <xref target=
     'p-dao-fmt'/>.
   </t>
   <t>
   A Projected DAO (P-DAO) P-DAO is a special DAO message generated by the
   Root to install a P-Route formed of multiple hops in its DODAG. This provides
   a RPL-based method to install the Tracks as a collection of multiple
   P-Routes as expected by the 6TiSCH
   Architecture
   architecture  <xref target='RFC9030'/> as a collection of multiple P-Routes. target='RFC9030'/>.
   </t>
   <t>
   The Root MUST <bcp14>MUST</bcp14> source the P-DAO message with its address that serves as
   the DODAGID for the main DODAG. The receiver MUST NOT <bcp14>MUST NOT</bcp14> accept a P-DAO message that
   is not sent by the Root of its DODAG and MUST <bcp14>MUST</bcp14> ignore such messages silently.
   </t>
   <t>
   The 'P' flag is encoded in bit position 2 (to be confirmed by
   IANA) of the Flags field in the DAO Base Object. The Root MUST <bcp14>MUST</bcp14> set it to 1 in
   a Projected DAO P-DAO message. Otherwise Otherwise, it MUST <bcp14>MUST</bcp14> be set to 0. It is set to 0 in
   Legacy
   legacy implementations as specified respectively specified, respectively, in Sections 20.11 <xref target="RFC6550" sectionFormat="bare" section="20.11"/> and 6.4 <xref target="RFC6550" sectionFormat="bare" section="6.4"/> of
   <xref target='RFC6550'/>.
   </t>
   <t>
   The P-DAO is a part of control plane signaling and should not be stuck behind high
   traffic levels. The expectation is that the P-DAO message is be sent at a high
   QoS level, above that of data traffic, typically with the Network Control
   precedence.
   </t>
<figure anchor='p-dao-fmt'><name>Projected DAO Base Object</name>
              <artwork align="center"> ><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    TrackID    |K|D|P|  Flags  |   Reserved    | DAOSequence   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                   DODAGID field is set to the                 |
+               IPv6 Address address of the Track Ingress               +
|              used to source encapsulated packets              |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Option(s)...
+-+-+-+-+-+-+-+-+
 </artwork>
+-+-+-+-+-+-+-+-+]]></artwork>
</figure>

  <t> New fields:</t>
  <dl spacing='normal'>
    <dt>TrackID:</dt>
    <dd> The local Local or global Global RPLInstanceID of the DODAG that serves as the Track
    (more
    (see more in <xref target="trkid"/>).

    </dd> target="trkid"/>).</dd>
    <dt>P:</dt>
    <dd> <t>1-bit flag (position to be confirmed by IANA).</t>
          <t>
          The
    <dd><t>1-bit flag.</t>
    <t>The 'P' flag is set to 1 by the Root to signal a Projected DAO,
          and P-DAO; otherwise, it
    is set to 0 otherwise.
          </t>
          </dd> 0.</t></dd>
  </dl>

    <t>
   The D flag is set to one 1 to signal that the DODAGID field is present.
   It may be set to zero 0 if and only if the destination address of the
   P-DAO-ACK message is set to the IPv6 address that serves as DODAGID the DODAGID, and it MUST <bcp14>MUST</bcp14> be set
   to one otherwise, meaning that the DODAGID field MUST <bcp14>MUST</bcp14> then be present.
   </t>
  <t>
   In RPL Non-Storing Mode, the TIO and RTO are combined in a DAO message to
   inform the DODAG Root of all the edges in the DODAG, which are formed by the
   directed parent-child relationships. The DAO message signals to the Root
   that a given parent can be used to reach a given child.

<!--[rfced] Does "it" refer to the DAO? If so, may we rephrase the
text as shown below for clarity?

Original:
   The P-DAO message generalizes the DAO to signal to the Track
   Ingress that a Track for which it is the Root can be used to
   reach children and siblings of the Track Egress.

Perhaps:
   The P-DAO message generalizes the DAO to signal the Track Ingress
   that a track, for which the DAO is the root, can be used to reach
   children and siblings of the Track Egress.
 -->

   The P-DAO message
   generalizes the DAO to signal to the Track Ingress that a Track for which it
   is the Root can be used to reach children and siblings of the Track Egress.
   In both cases, options may be factorized and multiple RTOs may be present to
   signal a collection of children that can be reached through the parent or
   the Track, respectively.
   </t>

    </section> <!-- Projected DAO -->
    <section anchor='extP-DAO-ACK'><name>Projected DAO-ACK</name>
    <t> This document also Amends the DAO-ACK message.
    The new P flag signals the projected form.
   </t>
    <t>
   The format of the P-DAO-ACK message is thus as illustrated in
   <xref target='p-dao-ack-fmt'/>:
   </t>

<figure anchor='p-dao-ack-fmt'><name>Projected DAO-ACK Base Object</name>
              <artwork align="center"> ><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    TrackID    |D|P| Reserved  |  DAOSequence  |    Status     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                   DODAGID field is set to the                 |
+               IPv6 Address address of the Track Ingress               +
|              used to source encapsulated packets              |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Option(s)...
+-+-+-+-+-+-+-+-+
 </artwork>
+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
  <t> New fields:</t>
  <dl spacing='normal'>
    <dt>TrackID:</dt>
    <dd> The local Local or global Global RPLInstanceID of the DODAG that serves as the Track
    (more
    (see more in <xref target="trkid"/>).

    </dd> target="trkid"/>).</dd>
    <dt>P:</dt>
    <dd> <t>1-bit flag (position to be confirmed by IANA).</t>
    <dd><t>1-bit flag.</t>
    <t> The 'P' flag is set to 1 by the Root to signal a Projected DAO,
          and P-DAO; otherwise, it
    is set to 0 otherwise.
          </t>
          </dd> 0.</t></dd>
  </dl>

    <t>
   The D flag is set to one 1 to signal that the DODAGID field is present.
   It may be set to zero 0 if and only if the source address of the P-DAO-ACK
   message is set to the IPv6 address that serves as DODAGID the DODAGID, and it MUST <bcp14>MUST</bcp14> be set
   to one otherwise, meaning that the DODAGID field MUST <bcp14>MUST</bcp14> then be present.
   </t>
    </section> <!-- Projected DAO-ACK -->
    <section anchor='extVIO'><name>Via Information Option</name>
    <t>
      This document Extends the CMO to create new objects called the Via
      Information Options (VIO). (VIOs).
      The VIOs are the multihop multi-hop alternative to the TIO (more TIOs (see more in <xref target=
   'viof'/>).
   One VIO is the stateful Storing Mode VIO (SM-VIO); an SM-VIO
   installs a strict hop-by-hop P-Route called a Track segment. The other is the
   Non-Storing Mode VIO (NSM-VIO); the NSM-VIO installs a loose source-routed
   P-Route called a protection path at the Track Ingress, which uses that state to
   encapsulate a packet an IP-in-IP packet with a new Routing Header (RH) to the
   Track Egress (more (see more in <xref target= 'routing'/>).
   </t>
   <t>
   A P-DAO contains one or more RTOs to indicate the Target (destinations) that
   can be reached via the P-Route,  followed by exactly one VIO that signals the
   sequence of nodes to be followed (more (see more in <xref target= 'P-DAO'/>).
   There are two modes of operation for the P-Routes, the P-Routes: Storing Mode
   and the Non-Storing Mode, see Mode (see more in Sections <xref target= 'sP-DAO'/> 'sP-DAO' format="counter"/> and
   <xref target='nsP-DAO'/> respectively for more. target='nsP-DAO' format="counter"/>, respectively).
   </t>

    </section> <!-- VIA Information Option -->
    <section anchor='extSIO'><name>Sibling Information Option</name>
   <t>
   This specification Extends the CMO to create the Sibling Information Option
   (SIO).
   The SIO is used by a RPL Aware RPL-Aware Node (RAN) to advertise a selection of its
   candidate neighbors as siblings to the Root (more (see more in <xref target='rplsib'/>).
   The SIO is placed in DAO messages that are sent directly to the main Root,
   including multicast DAO (see section 9.10 of <xref target='RFC6550'/>). target='RFC6550' section="9.10"/>).
   </t>
   <t>
   This specification AMENDS Amends rules 1 and 2 listed in section 9.10 of <xref target='RFC6550'/>) target='RFC6550' section="9.10"/> for the multicast DAO operation as follows:
   </t>
   <t>OLD:</t>

<blockquote>
   <ol>
   <li>
      A
   <li>A node MAY <bcp14>MAY</bcp14> multicast a DAO message to the link-local
   scope all-RPL-nodes multicast address.
   </li>

   <li> A address.</li>
   <li>A multicast DAO message MUST <bcp14>MUST</bcp14> be used only to advertise
   information about the node itself, i.e., prefixes directly connected to or
   owned by the node, such as a multicast group that the node is subscribed to
   or a global address owned by the node
   </li> node</li>
   </ol>
</blockquote>

   <t>NEW:</t>

<blockquote>
   <ol>
   <li>
     A
   <li>A multicast DAO message MUST <bcp14>MUST</bcp14> be used only to advertise
   information about the node (using the Target Option), Option) and direct Link
   Neighbors such as learned by Neighbor Discovery (using the Sibling Information Option).
   </li> SIO).</li>
   <li>The multicast DAO may be used to enable direct and indirect (via a common
   neighbor) P2P communication without needing the DODAG to relay the packets.
   The multicast DAO exposes the sender's addresses as Targets in RTOs and the
   sender's neighbors addresses as siblings in SIOs; this tells the sender's
   neighbors that the sender is willing to act as a relay between those of its
   neighbors that are too far apart.
   </li> apart.</li>
   </ol>
</blockquote>
    </section> <!-- Sibling Information Option -->
    <section anchor='extPDR'><name>P-DAO Request</name>
   <t>
     The set of RPL Control Messages is Extended to include the P-DAO Request (PDR) PDR and P-DAO Request Acknowledgement (PDR-ACK).
     These two new RPL Control Messages enable an RPL-Aware Node a RAN
     to request the establishment of a Track between itself as (as the Track Ingress
     Node
     Node) and a Track Egress.
   The node makes its request by sending a new P-DAO Request (PDR) Message PDR message to
   the Root. The Root confirms with a new PDR-ACK message back to the requester
   RAN,
   RAN; see <xref target='P-DAOreq'/> for more.
   </t>
    </section><!-- P-DAO Request -->
    </section>

    <section anchor='extRPI'><name>Amending the RPI</name>
         <t>
     Sending a Packet packet within a RPL Local Instance requires the presence of the
     abstract RPL Packet Information (RPI) RPI described in section 11.2. of
     <xref target='RFC6550'/> target='RFC6550' section="11.2"/> in the outer IPv6 Header header chain
     (see <xref target='RFC9008'/>).
     The RPI carries a local Local RPLInstanceID which, that, in association with either the
     source or the destination address in the IPv6 Header, header, indicates the RPL
     Instance that the packet follows.

    </t>
    <t>
    This specification Amends <xref target='RFC6550'/> to create a new flag that signals that when a packet is forwarded along a P-Route.

    </t>
    <dl>

       <dt> Projected-Route 'P':</dt><dd> 1-bit flag. It is set to 1 in the RPI
       that is added in the encapsulation when a packet is sent over a Track.
       It is set to 0 when a packet is forwarded along the main DODAG (as a
       Track), including when the packet follows a segment that joins loose hops
       of the main DODAG. The flag is not mutable en-route.</dd> en route.</dd>
    </dl>
    <t>The encoding of the 'P' flag in native format is shown in <xref target='ext6553'/> while the compressed format is indicated in <xref target='ext8138'/>.
    </t>
    </section> <!-- Extending the RPI -->

   <section anchor='dflag'><name>Additional Flag in the RPL DODAG Configuration Option</name>

   <t>
   The DODAG Configuration Option option is defined in Section 6.7.6 of <xref target=
   'RFC6550'/>.
   'RFC6550' section="6.7.6"/>. Its purpose is extended to distribute configuration
   information affecting the construction and maintenance of the DODAG, as
   well as operational parameters for RPL on the DODAG, through the DODAG.

   This Option option was originally designed with 4 four bit positions reserved for future use as Flags.
   </t>

<figure anchor="RPLDCO">
          <name>DODAG Configuration Option (Partial View) </name>
       <artwork 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 = 0x04 |Opt Length = 14|D| | | |A|       ...           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                     +
                                |4 bits |
]]></artwork> |]]></artwork>
</figure>

<t>

   This specification Amends the specification <xref target='RFC6550'/> to define a the new flag "Projected Routes Support" (D). (D) flag.
   The 'D' flag is encoded in bit position 0 of the reserved Flags in the DODAG
   Configuration Option option (this is the most significant bit)(to be confirmed by
   IANA but there's little choice). bit). It is set to 0 in legacy implementations as
   specified respectively in Sections 20.14 <xref target='RFC6550' sectionFormat="bare" section="20.14"/> and 6.7.6 <xref target='RFC6550' sectionFormat="bare" section="6.7.6"/> of <xref target='RFC6550'/>.
   </t>
   <t>
   The 'D' flag is set to 1 to indicate that this specification is enabled in
   the network and that the Root will install the requested Tracks when feasible
   upon receiving a PDR message.
   </t>
   <t>
   Section 4.1.2. of
    <xref target='RFC9008'/> target='RFC9008' section="4.1.2"/> Amends
   <xref target='RFC6550'/> to indicate that the definition of the Flags applies
   to Mode of Operation MOP values from zero (0) to six (6) only.
   For a MOP value of 7, the implementation MUST <bcp14>MUST</bcp14> consider that the Root
   accepts PDR messages and will install Projected Routes. P-Routes.
   </t>
      <t>
   The RPL DODAG Configuration option is typically placed in a DODAG
   Information Object (DIO) DIO message.  The DIO message propagates down
   the DODAG to form and then maintain its structure.  The DODAG
   Configuration option is copied unmodified from parents to children.
   </t>
      <t>
   <xref target='RFC6550'/> states that:
</t>
<blockquote>
   Nodes other than the DODAG root MUST NOT <bcp14>MUST NOT</bcp14> modify this information when propagating the DODAG Configuration option.
</blockquote>
   <t>
   Therefore, a legacy parent propagates the 'D' flag as set
   by the root, and when the 'D' flag is set to 1, it is transparently
   flooded to all the nodes in the DODAG.
  </t>

   </section><!-- New Flag in the RPL DODAG Configuration Option -->

   </section> <!-- Extending RFC 6550 -->
  </section>

    <section anchor='ext6553'><name>Extending RPL RFC 6553</name>
    <t>
    <xref target='RFC6553'>"The RPL
    "The Routing Protocol for Low-Power and Lossy Networks (RPL) Option
   for Carrying RPL Information in Data-Plane Datagrams"</xref> Datagrams" <xref target="RFC6553"/> describes the RPL Option for use among RPL routers to include the abstract RPL Packet Information (RPI) RPI described in section 11.2. of <xref target='RFC6550'/> target='RFC6550' section="11.2"/> in data packets.

    </t>    <t>

    The RPL Option is commonly referred to as the RPI even though the RPI is really the abstract information that is transported in the RPL Option. <xref target='RFC9008'/> updated the Option Type from 0x63 to 0x23.

    </t>    <t>

    This specification Extends the RPL Option to encode the 'P' flag as follows:
    </t>
<figure anchor='Rpifmt'><name>Amended RPL Option Format</name>
              <artwork align="center"> ><![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
                                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                |  Option Type  |  Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O|R|F|P|0|0|0|0| RPLInstanceID |          SenderRank           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         (sub-TLVs)                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 </artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>

<!--[rfced] We note the following variation - "MUST" occurs once in
the first sentence and twice in the second. May we update the
latter sentences to reflect two instances of "MUST" for
consistency and clarity (i.e., update to "MUST be set to 0 by the
sender and MUST be ignored by the receiver")?

Original:

 (6 instances)
   ... MUST be set to 0 by the sender and MUST be ignored by the receiver ...

 (4 instances)
   ... MUST be set to 0 by the sender and ignored by the receiver ...
-->

          <dl spacing='normal'>
              <dt>Option Type:</dt><dd>0x23 or 0x63, 0x63; see <xref target='RFC9008'/> target='RFC9008'/>.
              </dd>
              <dt>Opt Data Len:</dt><dd> See <xref target='RFC6553'/> target='RFC6553'/>.
              </dd>
              <dt>'O', 'R' 'R', and 'F' flags:</dt><dd> See <xref target='RFC6553'/>.
              Those
              These flags MUST <bcp14>MUST</bcp14> be set to 0 by the sender and ignored by the
              receiver if the 'P' flag is set.
              </dd>
              <dt> Projected-Route 'P':</dt><dd> 1-bit flag as defined in <xref target='extRPI'/>.
              </dd>
              <dt>RPLInstanceID:</dt><dd> See <xref target='RFC6553'/>. Indicates the TrackID if the 'P' flag is set, as discussed in <xref target='extP-DAO'/>.
              </dd>
              <dt>SenderRank:</dt><dd> See <xref target='RFC6553'/>. This
              field MUST <bcp14>MUST</bcp14> be set to 0 by the sender and ignored by the receiver
              if the 'P' flag is set.
              </dd>

            </dl>

 </section> <!-- Extending RFC 6553 -->
 <section anchor='ext8138'><name>Extending RPL RFC 8138</name>

    <t> The <xref target='RFC8138'>6LoWPAN 6LoWPAN Routing Header</xref> Header specification <xref target='RFC8138'/>
    introduces a new IPv6 over Low-Power Wireless Personal Area Network
    (6LoWPAN) 6LoWPAN <xref target='RFC6282'/> dispatch type for use in 6LoWPAN
    route-over topologies, which initially covers the needs of RPL data packet
    compression.
    </t>
    <t>Section 4 of <xref target='RFC8138'/>
    <t><xref target='RFC8138' section="4"/> presents the generic formats of
    the 6LoWPAN Routing Header (6LoRH) with 6LoRH in two forms, one Elective that forms: Elective, which can
    be ignored and skipped when the router does not understand it, and one
    Critical
    Critical, which causes the packet to be dropped when the router cannot
    process it. The 'E' Flag flag in the 6LoRH indicates its form. In order to skip
    the Elective 6LoRHs, their format imposes a fixed expression of the size,
    whereas the size of a Critical 6LoRH may be signaled in variable forms to
    enable additional optimizations.
    </t>
    <t>When the compression as described in <xref target='RFC8138'/> compression is used, the Root of the
    main DODAG that sets up the Track also constructs the compressed routing
    header (SRH-6LoRH) on behalf of the Track Ingress, which saves avoids the
    complexities of optimizing the SRH-6LoRH encoding in constrained code.

<!--[rfced] FYI: We updated this sentence for clarity. Please let us
know of any objection.

Original:
    The SRH-6LoRH is signaled in the NSM-VIO, in a fashion that it is ready
    to be placed as is in the packet encapsulation by the Track Ingress.

Perhaps:
    When the SRH-6LoRH is signaled in the NSM-VIO, it is ready to be
    placed as is in the packet encapsulation by the Track Ingress.
-->

    The SRH-6LoRH is signaled in the NSM-VIO, in a fashion that it is ready
    to be placed as is in the packet encapsulation by the Track Ingress.
    </t>

    <t>Section 6.3 of <xref target='RFC8138'/>

    <t><xref target='RFC8138' section="6.3"/> presents the formats of the
    6LoWPAN Routing Header RH of type 5 (RPI-6LoRH) that compresses the RPI for
    normal RPL operation. The format of the RPI-6LoRH is not suited for
    P-Routes since the O,R,F O, R, and F flags are not used and the Rank is unknown and
    ignored.
    </t><t>
    This specification extends Extends <xref target="RFC8138" /> target="RFC8138"/> to introduce a new 6LoRH, the P-RPI-6LoRH P-RPI-6LoRH, that can be
    used in either Elective or Critical 6LoRH form, form;
    see Tables <xref target='elec6lorhtbl'/> target='elec6lorhtbl' format="counter"/> and <xref target='crit6lorhtbl'/> target='crit6lorhtbl' format="counter"/>,
    respectively. The new 6LoRH MUST <bcp14>MUST</bcp14> be used as a Critical 6LoRH, unless an SRH-6LoRH is present and controls the routing decision, in which case it
    MAY
    <bcp14>MAY</bcp14> be used in Elective form.
    </t>
    <t>
    The P-RPI-6LoRH is designed to compress the RPI along RPL P-Routes.
    Its format is as follows:
    </t>

<figure anchor='PRpifmt'><name>P-RPI-6LoRH Format</name>
              <artwork align="center"> ><![CDATA[
     0                   1                   2
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |1|0|E| Length  |  6LoRH Type   | RPLInstanceID |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 </artwork>
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
          <dl spacing='normal'>
              <dt> Type:</dt><dd>

<!--[rfced] FYI: We updated "Type" to "6LoRH Type" in Section 4.3 to match the
name of the field in Figure 12. Please let us know if that is incorrect.

Original:
   Type:  IANA is requested to define the same value of the type for
      both Elective and Critical forms.  A type of 8 is suggested.

Current:
   6LoRH Type:  IANA has defined the value 8
      for both the Elective and Critical forms.
-->

          <dl spacing='normal'>
              <dt>6LoRH Type:</dt><dd> IANA has defined the value 8
              for both the Elective and Critical forms.
              </dd>
              <dt> Elective 'E':</dt><dd> See <xref target='RFC8138'/>. The 'E' flag is set to 1 to indicate an Elective 6LoRH, meaning that it can be ignored when forwarding.
              </dd>
              <dt> RPLInstanceID :</dt><dd> In the context of this specification, the RPLInstanceID field signals the TrackID, TrackID; see Sections <xref target='tracks'/> target='tracks' format="counter"/> and <xref target='trkid'/> . target='trkid' format="counter"/>.
              </dd>

            </dl>

    <t> <xref target='encompression'/> details how a Track Ingress leverages
    the P-RPI-6LoRH Header as part of the encapsulation of a packet to place it
    into a Track.
    </t>
    </section> <!-- Extending RFC 8138 -->

  </section><!-- Extending existing RFCs  -->

  </section>
    <section anchor='rplccmo'><name>New RPL Control Messages and Options</name>

    <section anchor='P-DAOreq'><name>New P-DAO Request Control Message</name>

               <t>
   The P-DAO Request (PDR) PDR message is sent by a Node node in the main DODAG to the
   Root. It is a request to establish or refresh a Track where the node
   sending the PDR is the
   Track Ingress, and it signals whether or not an acknowledgment called PDR-ACK is
   requested or not.
   requested.  A positive PDR-ACK indicates that the Track was built
   and that the Root commits to maintaining the Track for the negotiated lifetime.
   </t>
   <t>
   The main Root MAY <bcp14>MAY</bcp14> indicate to the Track Ingress that the Track was terminated
   before its time and time; to do so, it MUST <bcp14>MUST</bcp14> use an asynchronous PDR-ACK with a
   negative status.
   A status of "Transient Failure" (see <xref target=
   "iana-stats-rej"/>) is an indication that the PDR may be retried after a
   reasonable time that depends on the deployment. Other negative status
   values indicate a permanent error; the attempt must be abandoned until
   a corrective action is taken at the application layer or through network
   management.
   </t>
   <t>

    The Track Ingress to-be to be of the requested Track is indicated in the source IPv6
    address of the PDR, and the TrackID is indicated in the message itself.

   At least one RPL Target Option MUST <bcp14>MUST</bcp14> be present in the message. If more than
   one RPL Target Option is present, the Root will provide a Track that reaches
   the first listed Target and a subset of the other Targets; the details of the
   subset selection are out of scope.
   The RTO signals the Track Egress (more (see more in <xref target='req'/>).
    <!--
    TODO: A P-DAO parameter option MAY be present as well to provide additional
    information on the requested path.
    -->
    </t>
    <t>
    The RPL Control Code for the PDR is 0x09, to be confirmed by IANA. 0x09.
    The format of the PDR Base Object is as follows:
    </t>

<figure anchor='disupdfmt'><name>New P-DAO Request Format</name>
              <artwork align="center"> ><![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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    TrackID    |K|R|   Flags   |  ReqLifetime  | PDRSequence   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   Option(s)...
 +-+-+-+-+-+-+-+-+
 </artwork>
 +-+-+-+-+-+-+-+-+]]></artwork>
</figure>

          <dl spacing='normal'>
              <dt>TrackID:</dt><dd>8-bit field.
              In the context of this specification, the TrackID field signals the RPLInstanceID of the DODAG formed by the Track, Track; see Sections <xref target='tracks'/> target='tracks' format="counter"/> and <xref target='trkid'/>. target='trkid' format="counter"/>. To allocate a
              new Track, the Ingress Node must provide a value that is not in
              use at this time.
              </dd>
              <dt>K:</dt><dd>The 'K' flag is set to indicate that the recipient
              is expected to send a PDR-ACK back.
              </dd>
              <dt>R:</dt><dd>The 'R' flag is set to request a Complex Track
              for redundancy.
              </dd>
              <dt>Flags:</dt><dd>Reserved. The Flags field MUST <bcp14>MUST</bcp14> be initialized to zero by the sender and MUST <bcp14>MUST</bcp14> be ignored by the receiver.
              </dd>
              <dt>ReqLifetime:</dt><dd> <t>8-bit unsigned integer.
              The requested lifetime for the Track expressed in Lifetime Units
              (obtained from the DODAG Configuration option). The value
              of 255 (0xFF) represents infinity (never time out).
              </t><t>
              A PDR with a fresher
              PDRSequence refreshes the lifetime, and a PDRLifetime of 0
              indicates that the Track MUST <bcp14>MUST</bcp14> be destroyed, e.g., when the
              application that requested the Track terminates.
              </t>
              </dd>
              <dt>PDRSequence:</dt><dd>
              <t>8-bit wrapping sequence number,
              obeying the operation in section 7.2 of
              <xref target='RFC6550'/>. target='RFC6550' section="7.2"/>.
              The PDRSequence is used to correlate a PDR-ACK message with the
              PDR message that triggered it. It is incremented at each PDR
              message and echoed in the PDR-ACK by the Root.
              </t>
              </dd>

            </dl>

    </section> <!-- New P-DAO Request Control Message -->

    <section anchor='rpldisackl'><name>New PDR-ACK Control Message</name>
    <t>
    The new PDR-ACK is sent as a response to a PDR message with the 'K' flag
    set.
    The RPL Control Code for the PDR-ACK is 0x0A, to be confirmed by IANA. 0x0A.
    Its format is as follows:
    </t>

<figure anchor='disackfmt'><name>New PDR-ACK Control Message Format</name>
              <artwork align="center"> ><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    TrackID    |     Flags     | Track Lifetime|  PDRSequence  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PDR-ACK Status|                Reserved                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Option(s)...
+-+-+-+-+-+-+-+
 </artwork>
+-+-+-+-+-+-+-+]]></artwork>
</figure>

          <dl spacing='normal'>
              <dt>TrackID:</dt><dd>
             Set to the TrackID indicated in the TrackID field of the PDR
             messages that this replies to.
              </dd>

              <dt>Flags:</dt><dd>Reserved. The Flags field MUST <bcp14>MUST</bcp14> be initialized to zero by the sender and MUST <bcp14>MUST</bcp14> be ignored by the receiver.
              </dd>

              <dt>Track Lifetime:</dt><dd>
             Indicates the remaining Lifetime lifetime for the Track, expressed in
             Lifetime Units; Units. The value
              of 255 (0xFF) represents infinity. The value of zero (0x00)
              indicates that the Track was destroyed or not created.
              </dd>

              <dt>PDRSequence:</dt><dd> 8-bit wrapping sequence number.
              It is incremented at each PDR message and echoed in the PDR-ACK.
              </dd>

              <dt>PDR-ACK Status:</dt><dd> <t>8-bit field indicating
            the completion.
            The PDR-ACK Status is substructured as indicated in <xref target='rpst'/>:</t>

 <figure anchor='rpst' suppress-title='false'><name>PDR-ACK status Status Format</name>
       <artwork align="center"  name="" type="" alt=""> alt=""><![CDATA[
    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |E|R|  Value    |
   +-+-+-+-+-+-+-+-+
</artwork>
   +-+-+-+-+-+-+-+-+]]></artwork>
 </figure>

    <dl  spacing='compact'> spacing='normal'>
	<dt>E:</dt><dd> 1-bit flag. Set to indicate a rejection. When not set, a Value field that is set to 0
    indicates Success/Unqualified Acceptance Acceptance, and other values indicate "not an
    outright rejection".</dd>
	<dt>R:</dt><dd> 1-bit flag. Reserved, MUST Reserved; <bcp14>MUST</bcp14> be set to 0 by the sender and
    ignored by the receiver.</dd>
	<dt>Status Value:</dt><dd> 6-bit unsigned integer. Values depending depend on the
    setting of the 'E' flag, flag; see Tables
    <xref target='iana-ack-status'/> target='iana-ack-status' format="counter"/> and <xref target='iana-nack-status'/>. target='iana-nack-status' format="counter"/>.
    </dd>

	</dl>

    </dd>

    <dt>Reserved:</dt><dd>The Reserved field MUST <bcp14>MUST</bcp14> be initialized to zero by the
    sender and MUST <bcp14>MUST</bcp14> be ignored by the receiver.
    </dd>

	</dl>

    </section> <!-- New PDR-ACK Control Message -->

     <section anchor='viof'><name>Via Information Options</name>

    <t>A VIO signals the ordered list of IPv6 Via Addresses that constitutes
    the hops of either a protection path (using Non-Storing Mode) or a segment (using Storing
    mode)
    Mode) of a Track.  A Storing Mode P-DAO contains one Storing Mode VIO
    (SM-VIO)
    SM-VIO whereas a Non-Storing Mode P-DAO contains one Non-Storing Mode VIO
    (NSM-VIO).
    NSM-VIO.
    </t><t>
    The duration of the validity of a VIO is indicated in a segment Segment Lifetime
    field. A P-DAO message that contains a VIO with a segment Segment Lifetime of zero 0
    is referred as a No-Path P-DAO.
    </t><t>
    The VIO contains one or more SRH-6LoRH header(s), headers, each formed of a an
    SRH-6LoRH head and a collection of compressed Via Addresses, except in the
    case of a Non-Storing Mode No-Path P-DAO where the SRH-6LoRH header is not
    present.
    </t><t>
    In the case of a an SM-VIO, or if <xref target='RFC8138'/> is not used in the data packets, then the Root MUST <bcp14>MUST</bcp14> use only one SRH-6LoRH per Via Information Option, and the compression is the same for all the addresses, as shown in <xref target='viao'/>, for simplicity.
    </t><t>
    In case of an NSM-VIO NSM-VIO, and if <xref target='RFC8138'/> is in use in the main
    DODAG, the Root SHOULD <bcp14>SHOULD</bcp14> optimize the size of the NSM-VIO if using different
    SRH-6LoRH Types would make the VIO globally shorter; this means that more than one SRH-6LoRH may be present.
    </t>
    <t>
    The format of the Via Information Option VIO is as follows:
    </t>
<figure anchor='viao'><name>VIO format</name> Format</name>
              <artwork align="center"> ><![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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Option Type  | Option Length |     Flags     |   P-RouteID   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Segm.
    | Seg. Sequence | Seg. Lifetime |        SRH-6LoRH head         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .           Via Address 1 (compressed by RFC 8138)              .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                              ....                             .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .           Via Address n (compressed by RFC 8138)              .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .              Additional SRH-6LoRH Header(s) header(s)                   .
    |                                                               |
    .                              ....                             .

 </artwork>                             .]]></artwork>
</figure>

<dl spacing='normal'>

              <dt>Option Type:</dt><dd>0x0E Type:</dt><dd>0x0F for SM-VIO, 0x0F SM-VIO and 0x10 for NSM-VIO
                                     (to be confirmed by IANA)
              (see <xref target="ianaRPLCtrlMsgopttbl"/>).</dd>

              <dt>Option Length:</dt><dd>8-bit unsigned integer, representing the length in octets of the option, not including the Option
              Type and Length fields (see section 6.7.1. of <xref target=
              'RFC6550'/>);
              'RFC6550' section="6.7.1"/>);
              the Option Length is variable, depending on the number of Via
              Addresses and the compression applied.</dd>

               <dt>Flags:</dt><dd>8-bit field. No flag is defined in this
               specification. The field MUST <bcp14>MUST</bcp14> be set to 0 by the sender and
               ignored by the receiver.</dd>

              <dt>P-RouteID:</dt><dd>8-bit field that identifies a component
               of a Track or the main DODAG as indicated by the TrackID field.
               The value of 0 is used to signal a path, i.e., made of a
               single segment/protection path.
               In an SM-VIO, the P-RouteID indicates a Segment ID.
               In an NSM-VIO, it indicates the ID of a protection path that is added
               (or updated) to the overall topology of the Track.
              </dd>

              <dt>Segment Sequence:</dt><dd>
              <t>8-bit unsigned integer.
              The Segment Sequence obeys the operation in section 7.2 of
              <xref target='RFC6550'/> target='RFC6550' section="7.2"/>, and the initial value is 255.
              </t><t>
              When the
              Root of the DODAG needs to refresh or update a segment in a Track,
              it increments the Segment Sequence individually for that segment.
              </t><t>

<!--[rfced] Please clarify "sets up the new information" in this sentence.

Original:
   The segment information indicated in the VIO deprecates any state
   for the segment indicated by the P-RouteID within the indicated
   Track and sets up the new information.
-->

              The segment information indicated in the VIO deprecates any state
              for the segment indicated by the P-RouteID within the indicated
              Track and sets up the new information.

              </t><t>
              A VIO with a Segment Sequence that is not as fresh as the current
              one is ignored.
              </t><t>
              A VIO for a given DODAGID with the same (TrackID,
              P-RouteID, Segment Sequence) indicates a retry; it MUST NOT <bcp14>MUST NOT</bcp14>
              change the segment and MUST <bcp14>MUST</bcp14> be propagated or answered as the first
              copy.
              </t>
              </dd>

              <dt>Segment Lifetime:</dt><dd>
              <t>8-bit unsigned integer. The length
              of time in Lifetime Units (obtained from the Configuration
              option) that the segment is usable.

              </t><t>
              The period starts when a new Segment Sequence is seen. The value
              of 255 (0xFF) represents infinity. The value of zero (0x00)
              indicates a loss of reachability.
              </t>
              </dd>
              <dt>SRH-6LoRH head:</dt><dd>The first 2 bytes of the (first)
              SRH-6LoRH as shown in Figure 6 of <xref target='RFC8138'/>. As an
              example, a 6LoRH Type of 4 means that the VIA Via Addresses are
              provided in full with no compression.
              </dd>

              <dt>Via Address:</dt><dd>
              <t>An IPv6 ULA or GUA of a node along the segment.
              The VIO contains one or
              more IPv6 Via Addresses listed in the datapath order from Ingress
              to Egress. The list is expressed in a compressed form as signaled
              by the preceding SRH-6LoRH header.
              </t><t>
              In a Storing Mode P-DAO that updates or removes a section of an
              already existing segment, the list in the SM-VIO may represent
              only the section of the segment that is being updated; at the
              extreme, the SM-VIO updates only one node, in which case it
              contains only one IPv6 address.
              In all other cases, the list in the VIO MUST <bcp14>MUST</bcp14> be complete.
              </t><t> In the case of an SM-VIO, the list indicates a sequential
              (strict) path through direct neighbors, neighbors; the complete list starts
              at the Ingress and ends at the Egress, and the nodes listed in the VIO,
              including the Egress, MAY <bcp14>MAY</bcp14> be considered as implicit Targets.
              </t><t>
              In the case of an NSM-VIO, the complete list can be loose and
              excludes the Ingress node, starting at the first loose hop and
              ending at a Track Egress; the Track Egress MUST <bcp14>MUST</bcp14> be considered as
              an implicit Target, so it MUST NOT <bcp14>MUST NOT</bcp14> be signaled in a RPL Target
              Option.
              </t>
              </dd>
            </dl>
    </section> <!-- Via Information Options -->
    <section anchor='rplsib'><name>Sibling Information Option</name>

    <t>
    The Sibling Information Option (SIO) provides information about siblings that
    could be used by the Root to form P-Routes. One or more SIO(s) SIOs may be placed
    in the DAO messages that are sent to the Root in Non-Storing Mode.
    </t>
    <t>
   To advertise a neighbor node, the router MUST <bcp14>MUST</bcp14> have an active Address
   Registration from that sibling using per <xref target='RFC8505'/>, target='RFC8505'/> for an address
   (ULA or GUA) that serves as an identifier for the node. If this router also
   registers an address to that sibling, and the link has similar properties in
   both directions, only the router with the lowest Interface ID in its
   registered address needs to report the SIO, with the B flag set, and the Root
   will assume symmetry.
    </t>
    <t>

<!--[rfced] Is "so the routing can consider" the intending wording
or would one of the following suggestions be more clear?

Original:
   The SIO carries a flag (B) that is set when similar performance can be
   expected in both directions, so the routing can consider that the
   information provided for one direction is valid for both.

Perhaps A:
   The SIO carries a flag (B) that is set when similar performance can
   be expected in both directions, so the routing can identify that
   the information provided for one direction is valid for both.

or
Perhaps B:
   The SIO carries a flag (B) that is set when similar performance can
   be expected in both directions; this flag indicates to the routing that
   the information provided for one direction is valid for both.
-->

    The SIO carries a flag (B) that is set when similar performance can be
    expected in both directions, so the routing can consider that the information
    provided for one direction is valid for both. If the SIO is effectively
    received from both sides sides, then the B flag MUST <bcp14>MUST</bcp14> be ignored.
    The policy that describes the
    performance criteria, criteria and how they are asserted is out of scope.
    In the absence of an external protocol to assert the link quality, the flag
    SHOULD NOT
    <bcp14>SHOULD NOT</bcp14> be set.
    </t>
    <t>
    The format of the SIO is as follows:
    </t>

<!--[rfced] We note "Type" in Figure 17 but "Option Type" in the
corresponding description in the running text. Should Figure 17
be updated to reflect "Option Type" for consistency with the
running text?

Current:
    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        | Option Length |S|B|Flags|Comp.|    Opaque     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Option Type:  0x11 for SIO (see Table 26).

Perhaps:
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Option Type  | Option Length |S|B|Flags|Comp.|    Opaque     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Option Type:  0x11 for SIO (see Table 26).
-->

<figure anchor='siof'><name>Sibling Information Option Format</name>
              <artwork align="center"> ><![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        | Option Length |S|B|Flags|Comp.|    Opaque     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Step in Rank       |          Reserved             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    .                                                               .
    .       Sibling DODAGID (if the D flag is not set)              .
    .                                                               .
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    .                                                               .
    .                     Sibling Address                           .
    .                                                               .
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 </artwork>
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>

          <dl spacing='normal'>
              <dt>Option Type:</dt><dd>0x10 Type:</dt><dd>0x11 for SIO (to be confirmed by IANA)
              (see <xref target="ianaRPLCtrlMsgopttbl"/>).</dd>

              <dt>Option Length:</dt><dd>8-bit unsigned integer, representing the length in octets of the option, not including the Option
              Type and Length fields (see section 6.7.1. of <xref target=
              'RFC6550'/>).</dd>
              'RFC6550' section="6.7.1"/>).</dd>

              <dt>Reserved for Flags:</dt><dd>MUST Flags:</dt><dd><bcp14>MUST</bcp14> be set to zero 0 by the sender
              and MUST <bcp14>MUST</bcp14> be ignored by the receiver.
              </dd>
              <dt>B:</dt><dd>
              1-bit flag that is set to indicate that the connectivity to the sibling
              is bidirectional and roughly symmetrical.
              In that case, only one of the siblings needs to report the SIO for the hop.
              If 'B' is not set set, then the SIO only indicates connectivity from the sibling to this node, and it does not provide information on the
              hop from this node to the sibling.
              </dd>
              <dt>S:</dt><dd>
              1-bit flag that is set to indicate that the sibling belongs to the
              same DODAG. When not set, the Sibling DODAGID is indicated.

              </dd>

              <dt>Flags:</dt><dd>Reserved. The Flags field MUST <bcp14>MUST</bcp14> be initialized to zero by the sender and MUST <bcp14>MUST</bcp14> be ignored by the receiver.
              </dd>

              <dt>Comp.:</dt><dd>Compression Type, Type; a 3-bit unsigned integer. This is the
              SRH-6LoRH Type as defined in figure Figure 7 in section 5.1 of
              <xref target='RFC8138'/> target='RFC8138' section="5.1"/> that corresponds to the compression used
              for the Sibling Address and its DODAGID if present. The Compression
              reference is the Root of the main DODAG.
              </dd>

              <dt>Opaque:</dt><dd>MAY

              <dt>Opaque:</dt><dd><bcp14>MAY</bcp14> be used to carry information that the node
              and the Root understand, e.g., a particular representation of the
              Link
              link properties such as a proprietary Link Quality Information
              for packets received from the sibling.
              In some scenarios such as the case of an Industrial Alliances that
              uses
              use RPL for a particular use / environment, use/environment, this field MAY <bcp14>MAY</bcp14> be
              redefined to fit the needs of that the case.

              </dd>

              <dt>Step in Rank:</dt><dd>16-bit unsigned integer. This is the
              Step in Rank <xref target='RFC6550'/> as computed by the Objective
              Function between this node and the sibling, that which reflects the
              abstract Rank increment that would be computed by the OF Objective Function if the
              sibling was the preferred parent.
              </dd>

              <dt>Reserved:</dt><dd>The Reserved field MUST <bcp14>MUST</bcp14> be initialized to zero
              by the sender and MUST <bcp14>MUST</bcp14> be ignored by the receiver
              </dd>

              <dt>Sibling DODAGID:</dt><dd>2 to 16 bytes, the bytes. The DODAGID of the
              sibling in a <xref target='RFC8138'/> compressed form <xref target='RFC8138'/> as indicated
              by the Compression Type field. This field is present if and only
              if  the D flag is not set.
              </dd>
              <dt>Sibling Address:</dt><dd>2 to 16 bytes, an bytes. An IPv6 Address address of the
              sibling,
              sibling with a scope that MUST <bcp14>MUST</bcp14> make it reachable from the Root,
              e.g., it cannot be a Link Local Address. The IPv6 address is
              encoded in the <xref target='RFC8138'/> compressed form <xref target='RFC8138'/>
              indicated by the Compression Type field.
              </dd>
            </dl>               <t>
    An SIO MAY <bcp14>MAY</bcp14> be immediately followed by a DAG Metric Container. In that case case,
    the DAG Metric Container provides additional metrics for the hop from the
    Sibling to this node.
    </t>
    </section> <!-- Sibling Information Option -->

    </section> <!-- New RPL Control Messages and Options -->

    <section anchor='P-DAO'><name>Root Initiated anchor='P-DAO'><name>Root-Initiated Routing State</name>

<section anchor='setup'><name>RPL Network Setup</name>
<t>

   To avoid the need of Path MTU Discovery by 6LoWPAN end-points, endpoints,
   6LoWPAN links are normally defined
   with a an MTU of 1280 (see section 4 of <xref target='RFC4944'/>). target='RFC4944' section="4"/>).
   Injecting packets in a Track typically involves an IP-in-IP encapsulation and
   additional IPv6 Extension Headers. extension headers. This may cause fragmentation if the
   resulting packets exceed the MTU that is defined for the RPL domain.
</t>
 <t>
   Though fragmentation is possible in a 6LoWPAN LLN, e.g., using <xref
   target='RFC4944'/>, <xref target='RFC8930'/>, and/or <xref target='RFC8931'/>,
   it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> to define an MTU that is larger than 1280 between the RPL
   routers that form the main DODAG to allow for the necessary header additions,
   while still exposing 1280 to the 6LoWPAN end-point endpoint stacks.
</t>
</section><!--  RPL Network Setup -->
</section>
<section anchor='req'><name>Requesting a Track</name>

      <t>
      This specification introduces the PDR message, which is used by an LLN node to
      request the formation of a new Track for which this the LLN node is the Ingress.
      Note that the namespace for the TrackID is owned by the Ingress node,
      and in the absence of a PDR, there must be some procedure for the Root to
      assign TrackIDs in that namespace while avoiding collisions (more (see more in
      <xref target='trkid'/>).
      </t>
      <t>
      The PDR signals the desired TrackID and the duration for which the Track should be established. Upon a PDR, the Root MAY <bcp14>MAY</bcp14> install the Track as requested, in which case it answers with a PDR-ACK indicating the granted
      Track Lifetime.
      All the segments MUST <bcp14>MUST</bcp14> be of a the same mode, either Storing or Non-Storing.
      All the segments MUST <bcp14>MUST</bcp14> be created with the same TrackID and the same DODAGID signaled in the P-DAO.
      </t>
      <t>
      The Root designs the Track as it sees best, fit and updates / changes updates/changes the segments over time to serve the
      Track as needed.
      Note that there is no protocol element to notify to the requesting Track
      Ingress when changes happen deeper down the Track, so they are transparent
      to the Track Ingress. If the main Root cannot maintain an expected service
      level, then it needs to tear down the Track completely.
      The Segment Lifetime in the P-DAO messages does not need to be aligned to
      the Requested Lifetime in the PDR, PDR or between P-DAO messages for different segments.
      E.g., The
      For example, the Root may use shorter lifetimes for the segments
      and renew them or change them during the lifetime of the Track.
      All the components (protection paths and segments) of a Track MUST <bcp14>MUST</bcp14> be destroyed
      (or have their lifetime elapsed) before the TrackID can be reused.
      </t>
      <t>
      When the Track Lifetime is relatively close to elapse - -- meaning in
      the order of the trip time from the node to the Root - -- the requesting node
      SHOULD
      <bcp14>SHOULD</bcp14> resend a PDR using the TrackID in the PDR-ACK to extend the
      lifetime of the Track, else Track; otherwise, the Track will time out out, and the Root will tear
      down the whole structure.
      </t>
      <t>
      If the Track fails and cannot be restored, the
      Root notifies the requesting node asynchronously with a PDR-ACK
      with a Track Lifetime of 0, indicating that the Track has failed, and
      a PDR-ACK Status Status, indicating the reason of the fault.
      </t>
      </section><!-- Requesting a Track  -->
      </section>

     <section anchor='trkid'><name>Identifying a Track</name>

     <t>
     RPL defines the concept of an Instance to signal an individual
     routing topology, and multiple topologies can coexist in the same network.
     The RPLInstanceID is tagged in the RPI of every packet to signal which
     topology the packet actually follows.
     </t>
     <t>
     This specification leverages the RPL Instance model as follows:
     </t>
   <ul spacing='normal'>
     <li>
     <t>
     The main Root MAY <bcp14>MAY</bcp14> use P-DAO messages to add better routes in the main
     Instance in conformance with the routing objectives in that Instance.
     </t>
     <t>
     To achieve this, the main Root MAY <bcp14>MAY</bcp14> install a segment along a path down the
     main DODAG, which is operated in Non-Storing Mode. This enables a loose
     source routing and reduces the size of the Routing Header, Header;
     see <xref target='loose'/>.
     The main Root MAY <bcp14>MAY</bcp14> also install a protection path across the main DODAG to
     complement the routing topology.
     </t>
     <t>
     When adding a P-Route to the RPL main DODAG, the main Root MUST <bcp14>MUST</bcp14> set the
     RPLInstanceID field of the P-DAO Base Object (see section 6.4.1. of <xref
     target='RFC6550'/>)
     target='RFC6550' section="6.4.1"/>) to the RPLInstanceID of the main DODAG, and MUST NOT it <bcp14>MUST NOT</bcp14>
     use the DODAGID field. A P-Route provides a longer match to the Target
     Address than the default route via the main Root, so it is preferred.
     </t>
     </li>
     <li>
     <t>
     The main Root MAY <bcp14>MAY</bcp14> also use P-DAO messages to install a Track as an
     independent routing topology (say, Traffic Engineered) to achieve
     particular routing characteristics from an Ingress to Egress Endpoints. endpoints.
     To achieve this, the main Root MUST <bcp14>MUST</bcp14> set up a Local RPL Instance (see
     section 5 of
     <xref target='RFC6550'/>), target='RFC6550' section="5"/>), and the Local RPLInstanceID serves
     as the TrackID.
     The TrackID MUST <bcp14>MUST</bcp14> be unique for the IPv6 ULA or GUA of the Track Ingress
     that serves as the DODAGID for the Track.
     </t>
     <t>
     This way, a Track is uniquely identified by the tuple (DODAGID, TrackID)
     where the TrackID is always represented with the D flag set to 0 (see
     also section 5.1. of <xref target='RFC6550'/>), target='RFC6550' section="5.1"/>), indicating that when used in an
     RPI that RPI, the source address of the IPv6 packet signals the DODAGID.
     </t>
     <t>
     The P-DAO Base Object MUST <bcp14>MUST</bcp14> indicate the tuple (DODAGID, TrackID) that
     identifies the Track as shown in <xref target='p-dao-fmt'/>, and the
     P-RouteID that identifies the P-Route MUST <bcp14>MUST</bcp14> be signaled in the VIO as shown
     in <xref target='viao'/>.
     </t>
     <t>
     The Track Ingress is the Root of the DODAG ID DODAGID formed by the local Local RPL
     Instance. It owns the namespace of its TrackIDs, so it can pick any
     unused value to request a new Track with a PDR. In a particular deployment
     where PDRs are not used, a portion of the namespace can be administratively
     delegated to the main Root, meaning that the main Root is authoritative for
     assigning the TrackIDs for the Tracks it creates.
    </t>
     <t>
     With this specification, the main Root is aware of all the active Tracks,
     so it can also pick any unused value to form Tracks without a PDR. To avoid
     a collision of the main Root and the Track Ingress picking the same value
     at the same time, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the Track Ingress starts
     allocating the ID value of the Local RPLInstanceID (see section 5.1. of
     <xref target='RFC6550'/>) target='RFC6550' section="5.1"/>) used as TrackIDs with the value 0 incrementing,
     while the Root starts with 63 decrementing.
     </t>

     </li>

  </ul>
     </section><!-- Identifying a Track -->
     </section>

      <section anchor='inst'><name>Installing a Track</name>

 <t>
   A path can be installed by a single P-Route that signals the sequence of consecutive nodes, nodes either in Storing Mode as a single-segment Track, Track or in Non-Storing Mode as a single-protection-path Track. A single-protection-path Track can be installed as a loose Non-Storing Mode P-Route, in which case the next loose entry must recursively be reached over a path.
   </t>
   <t>
   A Complex Track can be installed as a collection of P-Routes with the same DODAGID and Track ID. The Ingress of a Non-Storing Mode P-Route is the owner and Root of the DODAGID. The Ingress of a Storing Mode P-Route must be either the owner of the DODAGID, DODAGID or a hop of a protection path of the same Track. In the latter case, the Targets of the P-Route must include the next hop of the protection path if there is one, one to ensure forwarding continuity.
   In the case of a Complex Track, each segment is maintained independently and
   asynchronously by the Root, with its own lifetime that may be shorter, the
   same, or longer than that of the Track.
   </t>

   <t>A route along a Track for which the TrackID is not the RPLInstanceID of
   the main DODAG MUST <bcp14>MUST</bcp14> be installed with a higher precedence than the routes
   along the main DODAG, meaning that:
   </t>
   <ul>
   <li>Longest
   <li>The longest match MUST <bcp14>MUST</bcp14> be the prime comparison for routing.
   </li>
   <li>In case of equal length
   <li>For an equal-length match, the route along the Track MUST <bcp14>MUST</bcp14> be
   preferred vs. over the one along the main DODAG.
   </li>
   <li>There SHOULD NOT <bcp14>SHOULD NOT</bcp14> be 2 two different Tracks leading to the same Target from
   same Ingress node, unless there's a policy for selecting which packets use
   which Track; such a policy is out of scope.
   </li>
   <li>A packet that was routed along a Track MUST NOT <bcp14>MUST NOT</bcp14> be routed along the main
   DODAG again; if the destination is not reachable as a neighbor by the node
   where the packet exits the Track Track, then the packet MUST <bcp14>MUST</bcp14> be dropped.
   </li>
   </ul>

     <section anchor='trkpdao'><name>Signaling a Projected Route</name>
         <t>
    This specification adds a capability whereby the Root of a main DODAG installs
    a Track as a collection of P-Routes, using a Projected-DAO (P-DAO) P-DAO message
    for each individual protection path or segment.
    The P-DAO signals a collection of Targets in the RPL Target Option(s) (RTO). one or more RTOs. Those Targets can be reached via a sequence of routers indicated in a VIO.
     </t> <t>
    Like a classical DAO message, a P-DAO causes a change of state only if it is
    "new" per section 9.2.2. "Generation Section <xref target="RFC6550" sectionFormat="bare" section="9.2.2"/> ("Generation of DAO Messages" Messages") of the <xref target='RFC6550'> RPL specification</xref>; specification <xref target='RFC6550'></xref>; this is determined using
    the Segment Sequence information from the VIO as opposed to the Path
    Sequence from a TIO. Also, a Segment Lifetime of 0 in a VIO indicates that the P-Route associated to the segment is to be removed. There are two Modes
    of operation for the P-Routes, the P-Routes: Storing and the Non-Storing Modes. Non-Storing.
     </t> <t>
    A P-DAO message MUST <bcp14>MUST</bcp14> be sent from the address of the Root that serves
    as the DODAGID for the main DODAG. It MUST <bcp14>MUST</bcp14> contain either exactly one
    sequence of one or more RTOs followed by one VIO, VIO or any number of
    sequences of one or more RTOs followed by one or more TIOs.
    The former is the normal expression for this specification, whereas
    the latter corresponds to the variation for less-constrained
    environments described in <xref target='bfd'/>.

    </t> <t>
    A P-DAO that creates or updates a protection path MUST <bcp14>MUST</bcp14> be sent to a GUA or a ULA
    of the Ingress of the protection path; it MUST <bcp14>MUST</bcp14> contain the full list of hops in the
    protection path unless the protection path is being removed.

<!--[rfced] Should "MUST" be added to the latter part of this sentence
(e.g., a P-DAO "MUST signal the full list of hops")?  This would
make it parallel with the first part of the sentence.

Original:
   A P-DAO that creates a new Track segment MUST be sent to a GUA or a
   ULA of the segment Egress and MUST signal the full list of hops in
   segment; a P-DAO that updates (including deletes) a section of a
   segment MUST be sent to the first node after the modified segment and
   signal the full list of hops in the section starting at the node that
   immediately precedes the modified section.

Perhaps:
   A P-DAO that creates a new Track segment MUST be sent to a GUA or a
   ULA of the segment Egress and MUST signal the full list of hops in
   a segment; a P-DAO that updates (including deletes) a section of a
   segment MUST be sent to the first node after the modified segment and
   MUST signal the full list of hops in the section starting at the node
   that immediately precedes the modified section.
-->

    A P-DAO that creates a new Track segment <bcp14>MUST</bcp14> be sent to a GUA or a ULA
    of the segment Egress and <bcp14>MUST</bcp14> signal the full list of hops in a segment; a
    P-DAO that updates (including deletes) a section of a segment <bcp14>MUST</bcp14> be
    sent to the first node after the modified segment and signal the full
    list of hops in the section starting at the node that immediately
    precedes the modified section.
    </t> <t>
    In Non-Storing Mode, as discussed in <xref target='nsP-DAO'/>, the Root
    sends the P-DAO to the Track Ingress where the source-routing source routing state is
    applied, whereas in Storing Mode, the P-DAO is sent to the last node on the
    installed path and forwarded in the reverse direction, installing a Storing
    Mode state at each hop, as discussed in <xref target='sP-DAO'/>.
    In both cases cases, the Track Ingress is the owner of the Track, and it generates the P-DAO-ACK when the installation is successful.
    </t>
     <t>
    If the 'K' Flag flag is present in the P-DAO, the P-DAO MUST <bcp14>MUST</bcp14> be acknowledged
    using a DAO-ACK that is sent back to the address of the Root from which the
    P-DAO was received. In most cases, the first node of the protection path, segment,
    or updated section of the segment is the node that sends the acknowledgment.
    The exception to the rule is when an intermediate node in a segment fails
    to forward a Storing Mode P-DAO to the previous node in the SM-VIO.
   </t>
    <t>
   In a No-Path Non-Storing Mode P-DAO, the SRH-6LoRH MUST NOT <bcp14>MUST NOT</bcp14> be present in the
   NSM-VIO; the state in the Ingress is erased regardless. In all other cases, a
   VIO MUST <bcp14>MUST</bcp14> contain at least one Via Address, and a Via Address MUST NOT <bcp14>MUST NOT</bcp14> be
   present more than once, which would create a loop.
   </t>
   <t>
   A node that processes a VIO MAY <bcp14>MAY</bcp14> verify whether any of these conditions
   happen, and when one does, it MUST <bcp14>MUST</bcp14> ignore the P-DAO and reject it with a RPL
   Rejection Status of "Error in VIO" in the DAO-ACK, DAO-ACK; see <xref target='iana-stats-rpl-rej'/>.
   </t><t>
   Other errors
   Errors, other than those discussed explicitly explicitly, that prevent the installation of the
   route are acknowledged with a RPL Rejection Status of "Unqualified Rejection" in the DAO-ACK.
    </t>
      </section><!-- Signaling a Projected Route -->
      </section>

    <section anchor='sP-DAO'><name>Installing a Track Segment with a Storing Mode P-Route</name>

   <t>As illustrated in <xref target='sdf'/>, a Storing Mode P-DAO installs a
   route along the segment signaled by the SM-VIO towards the Targets indicated in the Target Options.
   The segment is to be included in a DODAG indicated by the P-DAO Base Object,
   that
   which may be the one formed by the main DODAG, or a Track associated
   with a local Local RPL Instance.
   </t>

      <figure anchor='sdf'><name>Projecting a route</name>
        <artwork> Route</name>
        <artwork><![CDATA[
        ------+---------
              |          Internet
              |
           +-----+
           |     | Border router Router
           |     |  (RPL Root)
           +-----+                      |     ^                   |
              |                         | DAO | ACK               |
        o    o   o    o                 |     |                   |
    o o   o  o Ingress  o  o  o         |  ^       | Projected    .
   o  o o  o    o  \\  o  o    o        |  | DAO   | Route        .
   o   o    o  o    \\  o    o  o  o    | ^        |              .
  o  o   o  o   o    Egress   o o       v | DAO    v              .
  o          o   LLN   o   o     o                                |
      o o   o        o     o              Loose Source Route Path |
   o       o      o    o                                          v
    </artwork>                                          v]]></artwork>
         </figure>

    <t>
     In order to install the relevant routing state along the segment , segment,
     the Root sends a unicast P-DAO message to the Track Egress router of the routing segment that is being installed. The P-DAO message contains a an SM-VIO with the a strict sequence of Via Addresses. The SM-VIO follows
     one or more RTOs indicating the Targets to which the Track leads. The SM-VIO contains a Segment Lifetime for which the state is to be maintained.
     </t><t>
     The Root sends the P-DAO directly to the Egress node of the segment.
     In that P-DAO, the destination IP address matches the last Via Address in
     the SM-VIO. This is how the Egress recognizes its role. In a similar
     fashion, the segment Ingress node recognizes its role because it matches the first
     Via Address in the SM-VIO.
     </t><t>
     The Egress node of the segment is the only node in the path that does not
     install a route in response to the P-DAO; it is expected to be already able
     to route to the Target(s) based on its existing tables.
     If one of the Targets is not known, the node MUST <bcp14>MUST</bcp14> answer to the Root
     with a DAO-ACK listing the unreachable Target(s) in an RTO and a rejection
     status of "Unreachable Target".
    </t><t>
     If the Egress node can reach all the Targets, then it forwards the P-DAO
     with unchanged content to its predecessor in the segment as indicated in
     the list of Via Information options, VIOs, and recursively the message is recursively propagated
     unchanged along the sequence of routers indicated in the P-DAO, but in the
     reverse order, from Egress to Ingress.
     </t><t>
     The address of the predecessor to be used as the destination of the propagated
     DAO message is found in the Via Address list, list at the position preceding the one
     that contains the address of the propagating node, which is used as the source
     of the message.
    </t><t>
    Upon receiving a propagated DAO, all except the Egress router MUST <bcp14>MUST</bcp14> install a
    route towards the DAO Target(s) via their successor in the SM-VIO. A router
    that cannot store the routes to all the Targets in a P-DAO MUST <bcp14>MUST</bcp14> reject the
    P-DAO by sending a DAO-ACK to the Root with a Rejection Status of "Out of
    Resources" as opposed to forwarding the DAO to its predecessor in the list.
    The router MAY <bcp14>MAY</bcp14> install additional routes towards the Via Addresses that appear in
    the SM-VIO after its own address, if any, but in case of a conflict or a lack of
    resource, the route(s) to the Target(s) are the ones that MUST <bcp14>MUST</bcp14>
    be installed in priority.
    </t>
     <t>
     If a router cannot reach its predecessor in the SM-VIO, the router MUST <bcp14>MUST</bcp14> send the DAO-ACK to the Root with a Rejection Status of "Predecessor Unreachable".
    </t>
    <t>
     The process continues until the P-DAO is propagated to the Ingress router of
     the segment, which answers with a DAO-ACK to the Root. The Root always
     expects a DAO-ACK, either from the Track Ingress with a positive status
     or from any node along the segment with a negative status. If the DAO-ACK
     is not received, the Root may retry the DAO with the same TID, TID or tear
     down the route.
    </t>
    </section>  <!-- Installing a Track segment with a Storing Mode P-Route -->

    <section anchor='nsP-DAO'><name>Installing a protection path Protection Path with a Non-Storing Mode P-Route</name>

   <t>As illustrated in <xref target='nsdf'/>,
   a Non-Storing Mode P-DAO installs a source-routed path within the Track indicated by the P-DAO Base Object, Object towards the Targets indicated in the Target Options. The source-routed path requires a Source-Routing header Source Routing Header, which implies an IP-in-IP encapsulation is needed to add the SRH to an existing packet. It is sent to the Track Ingress Ingress, which creates a tunnel associated with the Track, Track and
   connected routes over the tunnel to the Targets in the RTO. The tunnel encapsulation MUST <bcp14>MUST</bcp14> incorporate a routing header via the list addresses listed in the VIO in the same order. The content of the NSM-VIO starting at the first SRH-6LoRH header MUST <bcp14>MUST</bcp14> be used verbatim by the Track Ingress when it encapsulates a packet to forward it over the Track.
   </t>

<!-- [rfced] Figure 19 contains the non-ASCII character "°". Is this
intentional/significant? Or should it be updated to "o", which is used in
the rest of the figure?
-->

          <figure anchor='nsdf'><name>Projecting a Non-Storing Route</name>
            <artwork>
            <artwork><![CDATA[
           ------+---------
                 |          Internet
                 |
              +-----+
              |     | Border router Router
              |     |  (RPL Root)
              +-----+                    |  P  ^ ACK
                 |        Track          | DAO |
           o    o   o  o  Ingress X      V     |   X
       o o   o  o   o  o     o   X   o             X Source Source-
      o  o o  o o    o   o  o    X  o  o           X Routed
      o   o    °  o     o   o   o X     o          X Segment
     o  o   o  o   o  o    o  o     X Egress       X
        o  o  o  o             o    |
                                  Target
       o       o     LLN          o    o
     o          o             o     o
</artwork>     o]]></artwork>
          </figure>
   <t>
   The next entry in the source-routed path must be either a neighbor of the
   previous entry, entry or reachable as a Target via another P-Route, either
   Storing or Non-Storing, which implies that the nested P-Route has to be
   installed before the loose sequence is, is and that P-Routes must be installed
   from the last to the first along the datapath.
   For instance, a segment of a Track must be installed before the protection path(s) of
   the same Track that use uses it, and stitched segments must be installed in
   order from the last that reaches to the Targets first to reach the first. Targets.
   </t>
   <t>
   If the next entry in the loose sequence is reachable over a Storing Mode P-Route, it MUST <bcp14>MUST</bcp14> be the Target of a segment and the Ingress of a next segment, which are both already setup; set up; the segments are associated with the same Track, which avoids the need of needing an additional encapsulation. For instance, in
   <xref target="srpdao"/>, segments A==>B-to-C and C==>D==>E-to-F must be
   installed with Storing Mode P-DAO messages 1 and 2 before the Track A-->C-->E-to-F that joins them can be installed with Non-Storing Mode P-DAO 3.
   </t>
   <t>
   Conversely, if it is reachable over a Non-Storing Mode P-Route, the next
   loose source-routed hop of the inner Track is a Target of a previously
   installed Track and the Ingress of a next Track, which requires a de- and a
   re-encapsulation when switching the outer Tracks that join the loose hops.
   This is examplified exemplified in <xref target="nssr"/> where Non-Storing Mode P-DAO P-DAOs 1
   and 2 install strict Tracks that Non-Storing Mode P-DAO 3 joins as a super
   Track. In such a case, packets are subject to double IP-in-IP encapsulation.
  </t>
  </section> <!-- Installing a Track Segment with a Storing Mode P-Route -->

      </section><!-- Installing a Track  -->

      </section>

    <section anchor='teardown'><name>Tearing Down a P-Route</name>
    <t>

<!--[rfced] Is "and results in" the intended wording here, or may we
revise the sentence as shown below and use "Its function" instead
for clarity?

Original:
   A P-DAO with a lifetime of 0 is interpreted as a No-Path DAO and results in
   cleaning up existing state as opposed to refreshing an existing one or
   installing a new one.

Perhaps:
   A P-DAO with a lifetime of 0 is interpreted as a No-Path DAO. Its
   function is to clean up an existing state as opposed to refreshing it
   or installing a new one.
-->

    A P-DAO with a lifetime of 0 is interpreted as a No-Path DAO and results in
    cleaning up existing state as opposed to refreshing an existing one or
    installing a new one. To tear down a Track, the Root must tear down all the
    Track segments and protection paths that compose it one by one.
    </t>
    <t>
    Since the state about a protection path state of a Track is located only on the Ingress Node,
    the Root cleans up the protection path by sending an NSM-VIO to the Ingress indicating to indicate
    the TrackID and the P-RouteID of the protection path being removed, a Segment Lifetime
    of 0 0, and a newer Segment Sequence. The SRH-6LoRH with the Via Addresses in
    the NSM-VIO are is not needed; it SHOULD NOT <bcp14>SHOULD NOT</bcp14> be placed in the message and MUST <bcp14>MUST</bcp14>
    be ignored by the receiver. Upon that NSM-VIO, the Ingress node removes all
    state for that Track Track, if any, and replies positively anyway.
    </t>
    <t>
    The Root cleans up a section of a segment by sending an SM-VIO to the last
    node of the segment, segment with the an updated TrackID and the P-RouteID of the segment being
    updated, P-RouteID,
    a Segment Lifetime of zero (0) 0, and a newer Segment Sequence.
    The Via Addresses in the SM-VIO indicates indicate the section of the segment being
    modified, from the first to the last node that is impacted. This can be the
    whole segment if it is totally removed, removed or a sequence of one or more nodes
    that have been bypassed by a segment update.
    </t>
    <t>
    The No-Path P-DAO is forwarded normally along the reverse list, even if the
    intermediate node does not find a segment state to clean up. This results in
    cleaning up the existing segment state state, if any, as opposed to refreshing an
    existing one or installing a new one.
    </t>
    </section><!-- Tearing Down a P-Route -->
    </section>

     <section anchor='maintain'><name>Maintaining a Track</name>
     <t>
     Repathing a Track segment or protection path may cause jitter and packet misordering.
     For critical flows that require timely and/or
     in-order delivery, it might be necessary to deploy the PAREO functions
     <xref target='I-D.ietf-raw-architecture'/> target='RFC9912'/> over a highly redundant Track.
     This specification allows to the use of more than one protection path for a Track, Track and 1+N
     packet redundancy.
     </t>
    <t>
     This section provides the steps to ensure that no packet is lost due to
     the operation itself.
     This is ensured by installing the new section from its last node to the
     first, so when an intermediate node installs a route along the new section,
     all the downstream nodes in the section have already installed their own.
     The disabled section is removed as well when the packets in-flight packets are forwarded
     along the new section as well. section.
     </t>
    <section anchor='maintainS'><name>Maintaining a Track Segment</name>

    <t>
    To modify a section of a segment between a the first node and a second, second downstream
    node (which can be the Ingress and Egress, respectively), respectively) while retaining those nodes
    in the segment, the Root sends an SM-VIO to the second node indicating the
    sequence of nodes in the new section of the segment. The SM-VIO indicates
    the TrackID and the P-RouteID of the segment being updated, updated and a newer
    Segment Sequence. The P-DAO is propagated from the second to the first node node,
    and on the way, it updates the state on the nodes that are common to the old
    and the new section of the segment and creates a state in the new nodes.
    </t>
    <t>
    When the state is updated in an intermediate node, that node might still
    receive packets that were in flight from the Ingress to self over the
    old section of the segment. Since the remainder of the segment is already
    updated, the packets are forwarded along the new version of the segment from
    that node on.
    </t>
    <t>
    After a reasonable time to enable the deprecated sections to drain their traffic, amount of time, the Root
    tears down the remaining section(s) of the old segments as
    described in <xref target='teardown'/>. target='teardown'/> to enable the deprecated sections to drain their traffic.
    </t>
    </section>  <!-- Maintaining a Track Segment -->

    <section anchor='maintainT'><name>Maintaining a protection path</name> Protection Path</name>

     <t>This specification allows the Root to add protection paths to a Track by sending
     a Non-Storing Mode P-DAO to the Ingress associated to the same TrackID, TrackID
     and a new Segment ID. If the protection path is loose, then the segments that join
     the hops must be created first.  It makes sense to add a new protection path before
     removing one that is becoming excessively lossy, lossy and switch to the new
     protection path before removing the old. Dropping a Track before the new one is
     installed would reroute the traffic via the root; this may increase the
     latency beyond acceptable thresholds, thresholds and overload the network near the root.
     This may also cause loops in the case of stitched Tracks: the The packets that
     cannot be injected in the second Track might be routed back and reinjected
     at the Ingress of the first. first Track.

     </t>
     <t>
     It is also possible to update a protection path by sending a Non-Storing Mode
     P-DAO to the Ingress with the same Segment ID, an incremented Segment
     Sequence, and the new complete list of hops in the NSM-VIO.
     Updating a live protection path means changing one or more of the intermediate loose
     hops, and it involves laying out new segments from and to the new loose hops
     before the NSM-VIO is issued for the new protection path is issued. path.
     </t>
    <t>
    Packets that are in flight over the old version of the protection path still
    follow the old source route path over the old segments.
    After a reasonable time to enable the deprecated segments to drain their traffic, time, the Root
    tears down those segments as described in <xref target='teardown'/>. target='teardown'/> to enable the deprecated segments to drain their traffic.
    </t>

    </section>  <!-- Maintaining a protection path -->

    </section> <!-- Maintaining a Track -->

   <section anchor='routing'><name>Encapsulating and Forwarding Along a Track</name>

    <t>
   When injecting a packet in a Track, the Ingress router must
   encapsulate the packet using IP-in-IP to add the Source Routing Header with
   the final destination set to the Track Egress.
   </t>

    <t>
     All properties of a Track's operations are inherited form from the main
     Instance that is used to install the Track. For instance, the use of
     compression per <xref target='RFC8138'/> is determined by whether it is
     used in the RPL main DODAG, e.g., by setting the "T" 'T' flag <xref target=
     'RFC9035'/> in the RPL configuration option.
   </t>
    <t>
    The
    When the Track Ingress that places a packet in a Track Track, it encapsulates it with an
    additional IPv6 header, a Routing Header, and an IPv6 Hop-by-Hop Option Header that
    contains the RPL Packet Information (RPI) RPI as follows:
    </t>
    <ul>
    <li>
      In the uncompressed form, the source of the packet is the address that
      this router uses as the DODAGID for the Track, the destination is the first
      Via Address in the NSM-VIO, and the RH is a
      Source Routing Header (SRH) an
      SRH <xref target='RFC6554'/> that contains the
      list of the remaining Via Addresses, ending with the Track Egress.
    </li>
    <li>
    <t>

<!--[rfced] In Section 6.7, we rephrased the second bullet point in
order to connect it more clearly to the lead-in sentence.  Please
let us know if the update is agreeable or if you prefer otherwise.

Original:
   * The preferred alternative in a network where 6LoWPAN Header
     Compression
    <xref target='RFC6282'/> [RFC6282] is used is to leverage <xref target='RFC8025'> "IPv6 over Low-Power
     Wireless Personal Area Network (6LoWPAN) Paging
    Dispatch"</xref> Dispatch"
     [RFC8025] to compress the RPL artifacts as indicated in [RFC8138].

Current:
   * To compress RPL artifacts in data packets as indicated in
     [RFC8138], the preferred alternative in a network where 6LoWPAN
     header compression [RFC6282] is used is to implement the method
     described in "IPv6 over Low-Power Wireless Personal Area Network
     (6LoWPAN) Paging Dispatch" [RFC8025].
-->

    <t>
    To compress RPL artifacts in data packets as indicated in
    <xref target='RFC8138'/>. target='RFC8138'/>, the preferred alternative in a network where 6LoWPAN header compression
    <xref target='RFC6282'/> is used is to implement "<xref format="title" target='RFC8025'/>" <xref target="RFC8025"/>.
    </t>
    <t>
    In that case, the source routed source-routed header is the exact copy of the (chain of) SRH-6LoRH found in the NSM-VIO, also ending with the Track Egress.
    The RPI-6LoRH is appended next, followed by an IP-in-IP 6LoRH Header that indicates the Ingress router in the Encapsulator Address field, field; see as a similar case in Figure 20 of <xref target='RFC8138'/>.

    </t>
    </li>
    </ul>

     <t>
     To signal the Track in the packet, this specification leverages the RPL
     Forwarding model as follows:
     </t>

     <ul spacing='normal'>
     <li>
       <t>
     In the data packets, the Track DODAGID and the TrackID MUST <bcp14>MUST</bcp14> be respectively
     signaled as the IPv6 Source Address source address, and the RPLInstanceID field of the RPI
     that MUST
     <bcp14>MUST</bcp14> be placed in the outer chain of IPv6 Headers. headers.
      </t>
      <t>
     The RPI carries a local Local RPLInstanceID called the TrackID, which, in association with the DODAGID, indicates the Track along which the packet is forwarded.
      </t>
     <t>
     The D flag in the RPLInstanceID MUST <bcp14>MUST</bcp14> be set to 0 to indicate that the source address in the IPv6 header is set to the DODAGID (more (see more
     in <xref target='trkid'/>).
     </t>
     </li>
     <li>
      <t>
      This specification conforms to the principles of <xref target='RFC9008'/> with regards regard to packet forwarding and encapsulation along a Track, Track as follows:
      </t>

      <ul>
      <li>
      With this specification, the Track is a RPL DODAG. From the perspective of that
      DODAG, the Track Ingress is the Root, the Track Egress is a RPL-Aware
      6LR, and neighbors of the Track Egress that can be reached via the Track,
      but are external to it, are external destinations and treated as
      RPL-Unaware Leaves (RULs). The encapsulation rules in <xref target=
      'RFC9008'/> apply.
      </li><li>
      If the Track Ingress is the originator of the packet and the Track Egress
      is the destination of the packet, there is no need for an encapsulation.
      </li><li>
      So
      Thus, the Track Ingress must encapsulate the traffic that it did not originate,
      and it must include an RPI in the encapsulation to signal the TrackID.
      </li>
      </ul>

     <t>
     A packet that is being routed over the RPL Instance associated to a first
     Non-Storing Mode Track MAY <bcp14>MAY</bcp14> be placed recursively in a second Track to
     cover one loose hop of the first Track Track, as discussed in more detail in <xref
     target="nssr"/>. On the other hand, a Storing Mode segment must be strict strict, and a packet that
     it placed in a Storing Mode segment MUST <bcp14>MUST</bcp14> follow that segment till the segment
     Egress.
     </t>

     </li>

    </ul>
    <t>
    It is known that a packet is forwarded along a Track by the source address
    and the RPI in the encapsulation.
    The Track ID is used to identify the RIB entries associated to that Track,
    which, in intermediate nodes, correspond to the P-routes P-Routes for the segments of
    the Track that the forwarding router is aware of.

<!--[rfced] May we update this sentence as shown below for clarity and
easier readability?

Original:
   The packet processing uses a precedence that favors self delivery
   or routing header handling when one is present, then delivery to
   direct neighbors, then to indirect neighbors, then routing along a
   segment along the Track, and finally as a last resort injecting the
   packet in another Track.

Perhaps:
   Packet processing uses the following precedence: 1) self-delivery
   or routing header handling when one is present, 2) delivery to
   direct neighbors, 3) delivery to indirect neighbors, 4) routing
   along a segment along the Track, and 5) injecting the packet in
   another Track, as a last resort.
-->

    The packet processing uses a precedence that favors self-delivery or routing
    header handling when one is present, then
    delivery to direct neighbors, then to indirect neighbors, then routing
    along a segment along the Track, and finally as a last resort injecting
    the packet in another Track.
    </t><t>
    To achieve this, the packet handling logic MUST <bcp14>MUST</bcp14> happen in the following order:
    </t>
    <ul>
     <li>
    <t>
    If the destination of the packet is self:
    </t>
    <ol>
    <li>
    if
    If the header chain contains a
    RPL Source Route Header that is not fully consumed, then the packet is
    forwarded along the Track as prescribed by <xref target='RFC6554'/>, meaning
    that the next entry in the routing header becomes the destination; destination.
    </li><li> otherwise: Otherwise,
    if the packet was encapsulated, then the packet is decapsulated and the
    forwarding process recurses; else else, the packet is delivered to the stack.
    </li>
    </ol>
    <!-- If the only route in the RIB was created by an NSM-VIO, this is achieved by encapsulating the packet, else by forwarding and / or delivering the packet as indicated below. -->

    </li>

    <li>
    <t>Otherwise, the packet is forwarded as follows: </t>

    <ol>
    <li>
    If the destination of the packet is a direct neighbor, e.g., installed
    by IPv6 Neighbor Discovery, then the packet MUST <bcp14>MUST</bcp14> be
    forwarded to that neighbor; neighbor.
    </li><li>
    Else If
    Else, if the destination of the packet is an indirect neighbor, e.g.,
    installed by a multicast DAO message from a common neighbor,
    see neighbor
    (see <xref target='extSIO'/>, target='extSIO'/>), then the packet MUST <bcp14>MUST</bcp14> be forwarded to the common neighbor; neighbor.
    </li><li>
    Else, if there is a RIB entry for the same Track (e.g., installed by an
    SM-VIO in a DAO message with the destination as target), the target) and the next hop in
    the RIB entry is a direct neighbor, then the packet is passed to that neighbor; neighbor.
    </li><li>
    Else, if there is a RIB entry for the different Track (e.g., installed by an
    NSM-VIO in a DAO message with the destination as the target), then the packet is
    encapsulated to be forwarded along that Track and the forwarding
    process recurses; otherwise otherwise, the packet is dropped.

 <!--
    </li><li>

    The longest match in the RIB indicates the next hop, and whether the route
    is installed by neighbor discovery (for direct neighbors), learned through
    an SIO in a multicast DAO message (for indirect neighbors see <xref target='extSIO'/>),
    as the target of a segment P-Route (meaning strict and Storing Mode).

    Forwarding of a packet along a track will fail if there is no such match in
    the RIB, meaning that the Track continuity is broken.
-->

    </li><li>
    To avoid loops, and as opposed to packets that were not encapsulated, a
    packet that was decapsulated from a Track MUST NOT <bcp14>MUST NOT</bcp14> be routed along the
    default route of the main DODAG; this would mean that the end-to-end path is
    uncontrolled. The node that discovers the fault MUST <bcp14>MUST</bcp14> discard the packet.
    </li>
    </ol>
  </li>
    </ul>
    <t>

<!-- [rfced] Will "either of the reasons above" be clear to readers? Does this
mean "in any of the steps above"?

Original:
   The node that drops a packet for either of the reasons above MUST
   send an ICMPv6 Error message <xref target='RFC4443'/> [RFC4443] to the Root, with a new Code
   "Error in P-Route" (See Section 11.15).

Perhaps:
   The node that drops a packet in any of the steps above MUST
   send an ICMPv6 Error message [RFC4443] to the Root, with a new Code
   "Error in P-Route" (See Section 11.15).
-->

    <t>
    The node that drops a packet for either of the reasons above <bcp14>MUST</bcp14>
    send an ICMPv6 error message <xref target='RFC4443'/> to the Root,
    with the new code "Error in P-Route" (see <xref target='ICMPv6ErrPRoute'/>).

<!--[rfced] May we revise this text into two sentences for easier
readability and update "remove the leftover" to "the Root can
remove the leftover" for clarity?

Original:
   The Root can then repair by updating the broken segment and/or
   Tracks, and in the case of a broken segment, remove the leftover
   sections of the segment using SM-VIOs with a lifetime of 0
   indicating the section to one or more nodes being removed (See
   Section 6.6).

Perhaps:
   The Root can then repair by updating the broken segment and/or
   Tracks. In the case of a broken segment, the Root can remove the
   leftover sections of the segment using SM-VIOs with a lifetime of
   0, indicating the section where one or more nodes are being removed
   (see Section 6.6).
-->

    The Root can then repair by updating the broken segment and/or Tracks, and in the case of a broken segment, remove the leftover sections of the segment
    using SM-VIOs with a lifetime of 0 indicating the section to one or more
    nodes being removed (see <xref target='maintain'/>).
    </t>

    <t>In case of a permanent forwarding error along a Source Route source route path, the
    node that fails to forward SHOULD <bcp14>SHOULD</bcp14> send an ICMP error with a the code "Error
    in Source Routing Header" back to the source of the packet, as described
    in section 11.2.2.3. of <xref target='RFC6550'/>. target='RFC6550' section="11.2.2.3"/>. Upon receiving this message, the
    encapsulating node SHOULD <bcp14>SHOULD</bcp14> stop using the source route path for a
    reasonable period of time time, which depends on the deployment, and
    it SHOULD <bcp14>SHOULD</bcp14> send an ICMP message with a Code the code "Error in P-Route" to the
    Root. Failure to follow these steps may result
    in packet loss and wasted resources along the source route path that
    is broken.
    </t>
    <t>
    Either way, the ICMP message MUST <bcp14>MUST</bcp14> be throttled in case of consecutive
    occurrences. It MUST <bcp14>MUST</bcp14> be sourced at the ULA or a GUA that is used in this
    Track for the source node, so the Root can establish where the error
    happened.

      </t>
      <t>

    The portion of the invoking packet that is sent back in the ICMP message
    SHOULD
    <bcp14>SHOULD</bcp14> record at least up to the RH if one is present, and this the hop of the
    RH SHOULD <bcp14>SHOULD</bcp14> be consumed by this node so that the destination in
    the IPv6 header is the next hop that this node could not reach.
    If a 6LoWPAN Routing Header (6LoRH) 6LoRH <xref target='RFC8138'/> is used to
    carry the IPv6 routing information in the outer header header, then that the whole
    6LoRH information SHOULD <bcp14>SHOULD</bcp14> be present in the ICMP message.
       </t>

    </section><!-- Encapsulating and Forwarding along a Track -->

    </section>

<section anchor='encompression'><name>Compression of the RPL Artifacts</name>

<t>
<!--[rfced] We find "using [RFC8138] in the main DODAG" unclear.
Please clarify what is being applied from RFC 8138 in the main
DODAG.

Original:
   When using [RFC8138] in the main DODAG operated in Non-Storing Mode
   in a 6LoWPAN LLN, a typical packet that circulates in the main DODAG
   is formatted as shown in Figure 20, representing the case where an
   IP-in-IP encapsulation is needed (see Table 19 of [RFC9008]):
-->

   When using <xref target='RFC8138'/> in the main DODAG operated in Non-Storing
   Mode in a 6LoWPAN LLN, a typical packet that circulates in the main DODAG is
   formatted as shown in <xref target='inner'/>, representing the case where
   an IP-in-IP encapsulation is needed
   (see Table 19 of  <xref target='RFC9008'/>):
</t>

<figure anchor='inner'><name>A Packet as Forwarded along Along the main Main DODAG</name>
              <artwork align="center"> ><![CDATA[
+-+ ... -+- ... -+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-...
|11110001|  SRH- | RPI-  | IP-in-IP | NH=1      |11110CPP| UDP | UDP
| Page 1 | 6LoRH | 6LoRH |  6LoRH   |LOWPAN_IPHC| UDP    | hdr |Payld
+-+ ... -+- ... -+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-...
                                     &lt;=
                                     <=        RFC 6282      =&gt;
          &lt;================      =>
          <================ Inner packet ==================== = =
</artwork> =]]></artwork>
</figure>
<t>
   Since there is no page switch between the encapsulated packet and the
   encapsulation, the first octet of the compressed packet that acts as the page
   selector is actually removed at encapsulation, so encapsulation; therefore, the inner packet used in
   the descriptions below starts with the SRH-6LoRH, SRH-6LoRH and is exactly the packet
   represented in <xref target='inner'/>, from the second octet onward.
</t>

<t>When encapsulating that the inner packet to place it in the Track, the first
   header that the Ingress appends at the head of the inner packet is an
   IP-in-IP 6LoRH Header; in that header, the encapsulator address, which maps to the IPv6 source address in the uncompressed form, contains a GUA or ULA IPv6 address of the Ingress node that serves as DODAG ID the DODAGID for the Track, expressed in the a compressed form and using the DODAGID of the main DODAG as compression reference. a reference for the compression. If the address is compressed to 2 bytes, the resulting value for the Length field shown (shown in <xref target='ipinip'/> target='ipinip'/>) is 3, meaning that the SRH-6LoRH as a whole is 5-octets 5 octets long.
</t>
<figure anchor='ipinip'><name>The IP-in-IP 6LoRH Header</name>
              <artwork align="center"> ><![CDATA[
 0                   1                   2
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-     ...     -+
|1|0|1| Length  | 6LoRH Type 6  |  Hop Limit    | Track DODAGID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-     ...     -+
</artwork>     -+]]></artwork>
</figure>

<t>

<!--[rfced] This sentence is hard to parse. Please let us know if the
suggested update captures the intended meaning or if you prefer
otherwise.

Original:
   At the head of the resulting sequence of bytes, the track Ingress
   then adds the RPI that carries the TrackID as RPLinstanceID as a P-
   RPI-6LoRH Header, as illustrated in Figure 12, using the TrackID as
   RPLInstanceID.

Perhaps:
   At the head of the resulting sequence of bytes, the Track Ingress
   then adds the RPI that carries the P-RPI-6LoRH Header (as
   illustrated in Figure 12) and uses the TrackID as the RPLInstanceID.
-->

<t> At the head of the resulting sequence of bytes, the Track Ingress then adds
   the RPI that carries the TrackID as RPLInstanceID as a P-RPI-6LoRH Header, as illustrated in <xref target='PRpifmt'/>, using the TrackID as
   RPLInstanceID.
   <!-- DB: I can't make sense of this sentence, too many "as". Looks like a quick edit gone bad. -->
   Combined with the IP-in-IP 6LoRH Header, this allows to identify identifying the Track without ambiguity.
</t>
<t> The SRH-6LoRH is then added at the head of the resulting sequence of bytes
   as a verbatim copy of the content of the SR-VIO SM-VIO that signaled the selected
   protection path.
</t>
<figure anchor='srh6lorh'><name>The SRH 6LoRH SRH-6LoRH Header</name>
              <artwork align="center"> ><![CDATA[
 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5  ..         ..        ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-    -+-    -+ ... +-    -+
|1|0|0|  Size   |6LoRH Type 0..4| Hop1 | Hop2 |     | HopN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-    -+-    -+ ... +-    -+
                                          Where N = Size + 1
</artwork> 1]]></artwork>
</figure>

<t>
   The format of the resulting encapsulated packet packet, which is in <xref target='RFC8138'/>
   compressed form per <xref target='RFC8138'/>, is illustrated in <xref target='respac'/>:
</t>

<figure anchor='respac'><name>A Packet as Forwarded along Along a Track</name>
              <artwork align="center"> ><![CDATA[
+-+ ... -+-+-+- ... -+-+-+- ... -+-+-+-+-+- ... +-+-+-+-+-+-+- ...
| Page 1 |  SRH-6LoRH  | P-RPI-6LoRH | IP-in-IP 6LoRH | Inner Packet
+-+ ... -+-+-+- ... -+-+-+- ... -+-+-+-+-+- ... +-+-+-+-+-+-+- ...

 Signals :  Loose Hops :    TrackID  :  Track DODAGID :
</artwork> :]]></artwork>
</figure>
</section><!-- Compression of the RPL Artifacts -->
    </section><!-- Root Initiated Routing State -->
</section>
    </section>

    <section anchor="ov"><name>Less-Constrained Variations</name>
    <section anchor="smmd"><name>Storing Mode main Main DODAG</name>

<t>This specification expects that the main DODAG is operated in Non-Storing
   Mode. The reasons for that limitation are mostly related to LLN operations,
   power
   power, and spectrum conservation:</t>
   <ul>
   <li>In Non-Storing Mode, the Root already knowns knows the DODAG topology, so the
   additional topological information is reduced to the siblings.
   </li>
   <li>The downward routes are updated with unicast messages to the Root, which
   ensures that the Root can reach back to the LLN nodes after a repair faster
   than in the case of Storing Mode. Also Also, the Root can control the use of the
   path diversity in the DODAG to reach the LLN nodes. For both reasons,
   Non-Storing Mode provides better capabilities for the Root to maintain the
   P-Routes.
   </li>
   <li>
   When the main DODAG is operated in Non-Storing Mode, P-Routes enable
   loose Source Routing, source routing, which is only an advantage in that mode. Storing Mode
   does not use Source Routing Headers, Headers and does not derive the same benefits
   from this capability.
   <!-- DB: unclear to me what benefis and what capability are being referred to here. Can you be more explicit? -->
   </li>
   </ul>

<t>On the other hand, since RPL is a Layer-3 Layer 3 routing protocol, its applicability
extends beyond LLNs to a generic IP network.

<!--[rfced] Please clarify "at the expense of". Does this mean that
route stretch is used rather than the shortest path routes?

Original:
   RPL requires less resources than alternative IGPs like OSPF, ISIS,
   EIGRP, BABEL or RIP at the expense of a route stretch vs. the
   shortest path routes to a destination that those protocols compute.

Perhaps:
   RPL requires fewer resources than alternative IGPs such as OSPF, IS-IS,
   the Enhanced Interior Gateway Routing Protocol (EIGRP), BABEL, or RIP
   when using route stretch rather than the shortest path routes to a
   destination that those protocols compute.
-->

RPL requires fewer resources
   than alternative IGPs such as OSPF, IS-IS, the Enhanced Interior Gateway Routing Protocol (EIGRP), BABEL, or RIP at the expense
   of a route stretch versus the shortest path routes to a destination that those
   protocols compute.

<!--[rfced] Is "ANIMA" needed in this sentence or can it be removed or
replaced with the title of RFC 8994? We note that the title of
RFC 8994 is "An Autonomic Control Plane (ACP)", so we are not
sure how "ANIMA" relates as it is not mentioned in Appendix
A.9.4.

Current:
   P-Routes add the capability to install shortest and/or constrained
   routes to special destinations such as discussed in
   section A.9.4. Appendix A.9.4
   of the ANIMA ACP [RFC8994].

Perhaps A:
   P-Routes add the capability to install the shortest and/or constrained
   routes to special destinations as discussed in Appendix A.9.4
   of [RFC8994].

or
Perhaps B:
   P-Routes add the capability to install the shortest and/or constrained
   routes to special destinations as discussed in Appendix A.9.4 of
   "An Autonomic Control Plane (ACP)" [RFC8994].
-->

   P-Routes add the capability to install the shortest
   and/or constrained routes to special destinations as discussed in
   Appendix <xref section="A.9.4" sectionFormat="bare" target="RFC8994"/> of the ANIMA ACP <xref target='RFC8994'/>. target="RFC8994"/>.
</t>
<t>
   In a powered and wired network, when enough memory to store the needed
   routes is available, the RPL Storing Mode proposes a better trade-off than
   the Non-Storing, Non-Storing Mode, as it reduces the route stretch and lowers the load on the
   Root. In that case, the control path between the Root and the RPL nodes can
   be maintained more aggressively and with more redundancy than in LLNs,
   and the nodes can be reached to maintain the P-Routes at most times for
   a finer and more reactive control.
   </t>

<t>
   This section specifies the additions that are needed to support Projected
   Routes P-Routes
   when the main DODAG is operated in Storing Mode.
   As long as the RPI can be processed adequately by the dataplane, data plane, the
   changes to in this specification are limited to the DAO message.
   The Track structure, routes routes, and forwarding operations remain the same.
   Since there is no capability negotiation, the expectation is that all the nodes in the network support this specification in the same fashion, fashion or are configured the same way through management.
   </t>
<t>
   In Storing Mode, the Root misses the Child to Parent Child-to-Parent relationship that forms
   the main DODAG, DODAG as well as the sibling information. To provide that knowledge knowledge,
   the nodes in the network MUST <bcp14>MUST</bcp14> send additional DAO messages that are unicast
   to the Root just like Non-Storing DAO messages are.
   </t>

<t>In the DAO message, the originating router advertises a set of neighbor
   nodes using Sibling Information Options (SIO)s, SIOs, regardless of the relative
   position in the DODAG of the advertised node vs. versus this router.
   </t>

<t>The DAO message MUST <bcp14>MUST</bcp14> be formed as follows:
   </t>
   <ul>
   <li>
   The originating router is identified by the source address of the DAO. That
   address MUST <bcp14>MUST</bcp14> be the one that this router registers to the neighbor routers
   so the Root can correlate the DAOs from those routers when they advertise
   this router as their neighbor. The DAO contains one or more sequences of one
   Transit Information Option
   TIO and one or more Sibling Information Options. SIOs.
   There is no RPL Target Option so that the Root is not confused into adding a
   Storing Mode route to the Target.
   </li>
   <li>
   The TIO is formed as in Storing Mode, and the Parent Address is not present.
   The Path Sequence and Path Lifetime fields
   are aligned with the values used in the Address Registration of the node(s) advertised in the SIO, as explained in Section 9.1. of
   <xref target='RFC9010'/>. target='RFC9010' section="9.1"/>.
   Having similar values in all  nodes allows factorising factorizing the TIO for multiple
   SIOs as done with in <xref target='RFC6550'/>.
   </li>
   <!--
   <li>
   The TIO is followed by one RPL Target Option that signals the router that
   sends the information.  The Target Prefix in the RTO contains the address in
   full and the "Advertiser address in Full" (F) <xref target='RFC9010'/> flag
   is set to 1.
   </li>
   -->
   <li>The TIO is followed by one or more SIOs that provide an address (ULA or GUA) of the advertised neighbor node.
   </li>
   </ul>

<t>
   But
   However, the RPL routing information headers may not be supported on all type types of
   routed network infrastructures, especially not in high-speed routers.
   When the RPI is not supported in the dataplane, data plane, there cannot be local Local RPL
   Instances and RPL can only operate as a single topology (the main DODAG).

<!--[rfced] Does "is that of" mean "a part of"? And does the Ingress
node encapsulate the RPL Instance or the main DODAG?

Original:
   The RPL Instance is that of the main DODAG DODAG, and the Ingress
   node that encapsulates is not the Root.

Perhaps:
   The RPL Instance is a part of the main DODAG, and the Ingress
   node that encapsulates the RPL Instance is not the Root.
-->

   The RPL Instance is that of the main DODAG, and the Ingress node that encapsulates is not the Root.
   The routes along the Tracks are alternate routes to those available along
   the main DODAG. They MAY <bcp14>MAY</bcp14> conflict with routes to children and MUST <bcp14>MUST</bcp14> take
   precedence in the routing table. The Targets MUST <bcp14>MUST</bcp14> be adjacent
   to the Track Egress to avoid loops that may form if the packet is reinjected
   in the main DODAG.
  </t>
</section><!-- Storing Mode main DODAG -->
</section>

    <section anchor="bfd"><name>A Track as a Full DODAG</name>

    <t>This specification builds Tracks with parallel or interleaved protection paths as opposed
   to a more complex DODAG with interconnections at any place desirable. The
   reason for that limitation is related to constrained node operations, operations and the
   capability to store a large amount of topological information and compute
   complex paths:</t>
   <ul>
   <li>With this specification, the node in the LLN has no topological
   awareness,
   awareness and does not need to maintain dynamic information about the link
   quality and availability.
   </li>
   <li>The Root has a complete topological information and statistical metrics
   that allow it it, or its PCE PCE, to perform a global optimization of all Tracks in
   its DODAG. Based on that information, the Root computes the protection path and produces the source route paths.
   </li>
   <li>
   The node merely selects one of the proposed paths and applies the associated
   pre-computed routing header in the encapsulation. This alleviates both the
   complexity of computing a path and the compressed form of the routing header.
   </li>
   </ul>
   <t>The RAW architecture <xref target='I-D.ietf-raw-architecture'>RAW Architecture</xref> target='RFC9912'></xref>
   actually expects the PLR at
   the Track Ingress to react to changes in the forwarding conditions along the
   Track,
   Track and reroute packets to maintain the required degree of reliability.
   To achieve this, the PLR needs the full richness of a DODAG to form any path
   that could meet the Service Level Objective (SLO). SLO.
   </t>
<t>
   This section specifies the additions that are needed to turn the Track
   into a full DODAG and enable the main Root to provide the necessary
   topological information to the Track Ingress.

<!--[rfced] How may we clarify "an order other than that of"? Is the
intended meaning that the PLR's metrics are in a different order
than the PCE's metrics?

Original:
   The expectation is that the metrics that the PLR uses are of an
   order other than that of the PCE, because of the difference of
   time scale between routing and forwarding, more in [RAW-ARCHI].

Perhaps:
   The expectation is that the PLR's metrics will be in a different order
   than the PCE's metrics because of the difference in the timescale
   between routing and forwarding; see more in [RAW-ARCH].
-->

   The expectation is that the
   metrics that the PLR uses are of an order other than that of the PCE,
   <!-- DB: not sure what "of an order other" means -->
   because of the difference of time scale timescale between routing and forwarding, forwarding; see more
   in <xref target='I-D.ietf-raw-architecture'/>. target='RFC9912'/>. It follows that the PLR
   will learn the metrics it needs from an alternate source, e.g., OAM frames.
   </t>
<t>
   To pass the topological information to the Ingress, the Root uses a P-DAO
   messages
   message that contains sequences of Target Targets and Transit Information options TIOs
   that collectively represent the Track, expressed in the same fashion as in
   classical Non-Storing Mode. The difference is that the Root is the source as opposed to the destination, and the Root can report information on many Targets, possibly the full Track, with one P-DAO.

</t>

<!--[rfced] Is "Target/Transit information tuples" correct, or should
it be "Target/TIO tuples" for consistency?

Original:
   Note that the Path Sequence and Lifetime in the TIO are selected by
   the Root and that the Target/Transit information tuples in the
   P-DAO are not those received by the Root in the DAO messages about
   the said Targets.

Perhaps:
   Note that the Path Sequence and Lifetime in the TIO are selected by
   the Root and that the Target/TIO tuples in the P-DAO are not those
   received by the Root in the DAO messages about the said Targets.
-->

<t>Note that the Path Sequence and Lifetime in the TIO are selected by the Root, Root
   and that the Target/Transit information tuples in the P-DAO are not those
   received by the Root in the DAO messages about the said Targets. The Track
   may follow sibling routes and does not need to be congruent with the main DODAG.
   </t>
    </section><!-- A Track as a Full DODAG -->

    </section><!-- Least Constrained Variations -->
    </section>

    </section>

    <section anchor='prof'><name>Profiles</name>
    <t>
    This document provides a set of tools that may or may not be needed by
    an implementation depending on the type of application it serves.

<!--[rfced] Can these sentences be combined to reduce redundancy?

Original:
   This section describes profiles that can be implemented separately
   and can be used to discriminate what an implementation can and cannot
   do.  This section describes profiles that enable implementing only a
   portion of this specification to meet a particular use case.

Perhaps:
   This section describes profiles that can be implemented separately,
   e.g., using only a portion of this specification to meet a particular use
   case, and can be used to discriminate what an implementation can
   and cannot do.
-->

    This section describes profiles that can be implemented separately and
    can be used to discriminate what an implementation can and cannot do.
    <!-- DB: the above sentence is grammatically incorrect and seems somewhat redundant with the one preceeding it.
    Was the preceeding one meant to superseede the second one? -->
    This section describes profiles that enable implementing only a portion
    of this specification to meet a particular use case.
    </t><t>
    Profiles 0 to 2 operate in the main Instance and do not require the
    support of local Local RPL Instances or the indication of the RPL Instance in the
    data plane.

<!--[rfced] Please clarify what "its" is referring to in the
following.

Original:
   Profile 3 and above leverage Local RPL Instances to build arbitrary
   Tracks Rooted at the Track Ingress and using its namespace for
   TrackID

Perhaps:
   Profile 3 and above leverage Local RPL Instances to build arbitrary
   Tracks rooted at the Track Ingress, using the namespace of the
   Track Ingress for the TrackID.
-->

    Profile 3 and above leverage Local RPL Instances to build
    arbitrary Tracks rooted at the Track Ingress and using its namespace for
    the TrackID.
    </t><t>
  </t>

<!-- [rfced] FYI - We updated the "/" here to "or". Let us know if another
meaning is intended.

Original:
   Profile 2 is
   RECOMMENDED in a high speed / wired environment to enable Traffic
   Engineering and network automation.

Perhaps:
   Profile 2 is
   RECOMMENDED in a high-speed or wired environment to enable Traffic
   Engineering and network automation.
-->

  <t>
    Profiles 0 and 1 are REQUIRED <bcp14>REQUIRED</bcp14> by all implementations that may be used in
    LLNs; Profile 1 leverages Storing Mode to reduce the size of the Source
    Route Header in the most common LLN deployments. Profile 2 is RECOMMENDED <bcp14>RECOMMENDED</bcp14>
    in high speed / a high-speed or wired environment to enable traffic Traffic Engineering and
    network automation. All the other profile / environment profile/environment combinations are
    OPTIONAL.
    <bcp14>OPTIONAL</bcp14>.
    </t>

    <dl>

    <dl newline="true">
    <dt> Profile 0 0: </dt><dd>
      Profile 0 is the Legacy legacy support of <xref target='RFC6550'/> Non-Storing
      Mode, with default routing Northwards (up) and strict source routing
      Southwards (down the main DODAG). It provides the minimal common
      functionality that must be
      implemented as a prerequisite to all the Track-supporting profiles.

<!--[rfced] Please clarify "on top". Is it necessary to include in
this sentence?

Original:
   The other Profiles extend Profile 0 with selected capabilities
   that this specification introduces on top.

Perhaps:
   The other profiles extend Profile 0 with selected capabilities
   that this specification introduces.
-->

      The other profiles extend Profile 0 with selected capabilities that this
      specification introduces on top.
    </dd>
    <dt> Profile 1 (Storing Mode P-Route segments along the main DODAG) DODAG): </dt><dd>
      Profile 1 does not create new paths; compared to Profile 0, it combines
      Storing and Non-Storing Modes to balance the size of the Routing Header
      in the packet and the amount of state in the intermediate routers in a
      Non-Storing Mode RPL DODAG.
    </dd>

<!--[rfced] Is "source routing" correct in these sentences, or should
it be "source-routed" per Table 26?

Current:
   Profile 2 extends Profile 0 with strict source routing Non-Storing
   Mode P-Routes along the main DODAG, which is the same as Profile 1
   but using NSM-VIOs as opposed to SM-VIOs.

   Profile 4 extends Profile 2 with strict source routing Non-Storing
   Mode P-Routes to form forward Tracks that are inside the main
   DODAG but do not necessarily follow it.

Perhaps:
   Profile 2 extends Profile 0 with strict source-routed Non-Storing
   Mode P-Routes along the main DODAG, which is the same as Profile 1
   but using NSM-VIOs as opposed to SM-VIOs.

   Profile 4 extends Profile 2 with strict source-routed Non-Storing
   Mode P-Routes to form forward Tracks that are inside the main
   DODAG but do not necessarily follow it.
-->

    <dt> Profile 2 (Non-Storing Mode P-Route segments along the main DODAG)</dt><dd> DODAG):</dt><dd>
      Profile 2 extends Profile 0 with Strict Source-Routing strict source routing Non-Storing Mode
      P-Routes along the main DODAG, which is the same as Profile 1 but using
      NSM VIOs
      NSM-VIOs as opposed to SM VIOs. SM-VIOs. Profile 2 provides the same capability to
      compress the SRH in packets down the main DODAG as Profile 1, but it
      requires an encapsulation, encapsulation in order to insert an additional SRH between
      the loose source routing hops.

<!--[rfced] FYI: We updated "In that case" to "With Profile 2" for
clarity. Please let us know if that is not correct.

Original:
   In that case, the Tracks MUST be installed as subTracks of the main
   DODAG, the main Instance MUST be used as TrackID.

Current:
   With Profile 2, the Tracks MUST be installed as subTracks of the main
   DODAG, and the main Instance MUST be used as the TrackID.
-->

      With Profile 2, the Tracks <bcp14>MUST</bcp14> be installed as subTracks of the main DODAG,
      <!-- DB: not sure what "In that case," refers to. Do you mean "With Profile 2,? -->
      and the main Instance MUST <bcp14>MUST</bcp14> be used as the TrackID. Note that the Ingress node
      encapsulates but is not the Root, as it does not own the DODAGID.
    </dd>
    <dt> Profile 3 3: </dt><dd>
      In order to
      form the best path possible, this Profile profile requires the support of
      Sibling Information Option
      an SIO to inform the Root of additional possible hops.
      Profile 3 extends Profile 1 with additional Storing Mode P-Routes
      that install segments that do not follow the main DODAG.
      If the segment Ingress (in the SM-VIO) is the same as the IPv6 Address address of
      the Track Ingress (in the projected Projected DAO base Base Object), the P-DAO creates an
      implicit Track between the segment Ingress and the segment Egress.
      </dd>
    <dt> Profile 4 4: </dt><dd>
      Profile 4 extends Profile 2 with Strict Source-Routing strict source routing Non-Storing Mode
      P-Routes to form forward Tracks that are inside the main DODAG but do
      not necessarily follow it. A Track is formed as one or more strict source
      routed source-routed
      paths between the Root that is the Track Ingress, Ingress and the
      Track Egress that is the last node.
    </dd>
    <dt> Profile 5 5: </dt><dd>
      Profile 5 Combines combines Profile 4 with Profile 1 and enables loose source
      routing between the Ingress and the Egress of the Track. As in Profile 1,
      Storing Mode P-Routes form the connections in the loose source route.
    </dd>
    <dt> Profile 6 6: </dt><dd>
      Profile 6 Combines combines Profile 4 with Profile 2 and also enables loose
      source routing between the Ingress and the Egress of the Track.

    </dd>
    <dt> Profile 7 7: </dt><dd>
      Profile 7 implements Profile 5 in a main DODAG that is operated in
      Storing Mode as presented in <xref target='smmd'/>. As in Profile Profiles 1 and 2,
      the TrackID is the RPLInstanceID of the main DODAG. Longest match rules
      decide whether a packet is sent along the main DODAG or rerouted in a
      track.
      Track.
    </dd>
    <dt> Profile 8 8: </dt><dd>
      Profile 8 is offered in preparation of the RAW work, work and for use cases
      where an arbitrary node in the network can afford the same code
      complexity as the RPL Root in a traditional deployment. It offers a full
      DODAG visibility to the Track Ingress Ingress, as specified in <xref target='bfd'/> target='bfd'/>,
      in a Non-Storing Mode main DODAG.
    </dd>
    <dt> Profile 9 9: </dt><dd>
      Profile 9 combines profiles Profiles 7 and 8, operating the Track as a full DODAG
      within a Storing Mode main DODAG, using only the main DODAG RPLInstanceID
      as the TrackID.
    </dd>
    </dl>

    </section><!-- Profiles -->

    </section>

    <section anchor='back'><name>Backwards Compatibility</name>

    <t>
    This specification can operate in a mixed network where some nodes support
    it and some do not. There are restrictions, though. All nodes that need to
    process a P-DAO MUST <bcp14>MUST</bcp14> support this specification.
    As discussed in <xref target='mtsch'/>, how the root knows the
    node capabilities and whether they support this specification is are out of scope.
    </t>
    <t>
    This specification defines the 'D' flag in the  RPL DODAG Configuration
    Option
    option (see <xref target='dflag'/>) to signal that the RPL nodes can request
    the creation of Tracks. The requester may not know whether the Track can
    effectively be constructed, and constructed or whether enough nodes along the preferred
    paths support this specification. Therefore, it makes sense to only set the
    'D' flags in the DIO when the conditions of for success are in place, in particular
    when all the nodes that could be on the path of tracks the Tracks are upgraded.
    </t>
    </section><!-- Backwards Compatibility -->
    </section>
    <section><name>Security Considerations</name>

    <t>

   It is worth noting that with per <xref target='RFC6550'/>, every
   node in the LLN is RPL-aware and can inject any RPL-based attack in the
   network. This specification uses messages that are already present in RPL
   <xref target='RFC6550'/> with optional secured versions. The same secured
   versions may be used with this specification, and whatever security is deployed for
     a given network also applies to the flows in this specification.

 </t>
 <t>
	The LLN nodes depend on the RPL Root and the RANs for their operation.
	A trust model is necessary to ensure that the right devices are
	acting in these roles, avoiding sinkhole attacks (as is done in
   <xref target='RFC7416'/> section 7). target='RFC7416' section="7"/>). This trust model could be be,
   at a minimum minimum, based on a Layer-2 Secure Layer 2 secure joining and the Link-Layer link-layer security.
   This is a generic 6LoWPAN requirement, requirement; see Req5.1 Req-5.1 in Appendix B.5 of <xref section="B.5" target='RFC8505'/>.
 </t><t>
    In a general manner, the Security Considerations in <xref target='RFC6550'/>, target='RFC6550'/>
    and <xref target='RFC7416'/> apply to this specification as well.
    The Link-Layer
    In particular, link-layer security is needed in particular to prevent
    Denial-Of-Service attacks
    denial-of-service attacks, whereby a rogue router creates a high churn in the
    RPL network by constantly injecting forged P-DAO messages and using up all
    the available storage in the attacked routers.

 </t><t>
   When applied to radio LLNs such as IEEE std Std 802.15.4, the lower-layer
   frame protection can be leveraged with an appropriate join protocol.

<!--[rfced] We are having trouble parsing this sentence; it reads as
if 6TiSCH defined RFC 9031. Is the intended meaning that 6TiSCH
is defined in RFC 9031? Please let us know how we may clarify the
text.

Original:
   6TiSCH defined [RFC9031] with the RPL Root acting as 6LBR.
-->

   6TiSCH defined <xref target='RFC9031'/> with the RPL Root acting as
   6LBR.
   The join protocol could be extended to provide additional key material
   for pledge pledges to 6LBR communication when additional end-to-end security
   is desired beyond the hop-by-hop security from the lower layer.
 </t><t>
   With this specification, the Root MAY <bcp14>MAY</bcp14> generate P-DAO messages but
   other nodes MUST NOT <bcp14>MUST NOT</bcp14> do so. PDR messages MUST <bcp14>MUST</bcp14> be sent to the Root.
   This specification expects that the
   communication with the Root is authenticated but does not enforce which method
   is used.
</t><t>
    Additionally, the trust model could include a role validation (e.g., using a
    role-based authorization) to ensure that the node that
    claims to be a RPL Root is entitled to do so. That trust should propagate
    from Egress to Ingress in the case of a Storing Mode P-DAO.

    </t><t>

<!--[rfced] We are having trouble parsing the latter part of this
sentence (i.e., "by avoiding that a node appears twice"). How may
we update this for clarity?

Original:
   This specification suggests some validation of the VIO to prevent
   basic loops by avoiding that a node appears twice.

Perhaps A:
   This specification suggests some validation of the VIO to prevent
   basic loops when a node appears twice.

or
Perhaps B:
   This specification suggests some validation of the VIO to prevent
   basic loops, i.e., by avoiding a node that appears twice.
-->

    This specification suggests some validation of the VIO to prevent basic
    loops by avoiding that a node appears twice. But that is only a minimal
    protection. Arguably, an attacker that can inject P-DAOs can reroute any
    traffic and rapidly deplete critical resources such as the spectrum and battery in
    the LLN rapidly. LLN.
	</t>

</section>
<section anchor='IANAcon'><name>IANA Considerations</name>

   <section anchor="iana-d"><name>RPL DODAG Configuration Option Flag</name>
   <t>

<!-- [rfced] We have included some specific questions about the IANA is requested
text below. In addition to assign responding to those questions, please
review all of the IANA-related updates carefully and let us know
if any further updates are needed.

a) Text relating to the "Mode of Operation" registry appears in Section 11.1
after the information for the "DODAG Configuration Option Flags for MOP 0..6"
registry. May we create a new subsection for this text, perhaps titled "Mode of
Operation"?

Current:
   IANA has added this RFC as an additional reference for MOP 7 in the
   "Mode of Operation" registry under the "Routing Protocol for Low
   Power and Lossy Networks (RPL)" registry group [IANA-RPL].

b) In Table 26, may we include the expansions of "SM-VIO" and "NSM-VIO" for
clarity and consistency with the running text? Note that we will communicate
any updates to IANA.

Current:
   0x0F  Stateful VIO (SM-VIO)
   0x10  Source-Routed VIO (NSM-VIO)

Perhaps:
   0x0F  Stateful Storing Mode VIO (SM-VIO)
   0x10  Source-Routed Non-Storing Mode VIO (NSM-VIO)

c) In Section 5.3, should "stateful" and "source-routed" be included
in the description for "Option Type" per Table 26?

Original:
   Option Type:  0x0F for SM-VIO and 0x10 for NSM-VIO (see Table 26).

Perhaps:
   Option Type:  0x0F for stateful SM-VIO and 0x10 for source-routed
                 NSM-VIO (see Table 26).

d) In both the "PDR-ACK Acceptance Status Values" and "PDR-ACK Rejection
Status Values" registries <https://www.iana.org/assignments/rpl/>, the first
column is titled "Bit Number"; however, in Tables 28 and 29 of this document,
the first column is titled "Value". Please let us know which term you prefer
("Bit Number" or "Value") and we will make the document and registries
consistent.
-->

    IANA has assigned a flag from in the "DODAG Configuration Option
    Flags for MOP 0..6" <xref target='RFC9010'/> registry <xref target='RFC9008'/> under the heading
    "Routing Protocol for Low Power and Lossy Networks (RPL)" registry group
    <xref target='IANA-RPL'/>
    as follows:
    </t>

   <table  anchor="nexndopt"><name>New DODAG Configuration Option Flag</name>
   <thead>
      <tr><td>Bit Number</td><td>Capability Description</td><td>Reference</td></tr>
     <tr><th>Bit Number</th>
     <th>Capability Description</th><th>Reference</th></tr>
   </thead><tbody>
      <tr><td>0 (suggested)</td><td>Projected
   <tr><td align="center">0</td>
   <td>Projected Routes Support (D)</td><td>THIS RFC</td></tr> (D)</td><td>RFC 9914</td></tr>
   </tbody>
   </table>

<t>
      IANA is requested to add [THIS RFC] has added this RFC as a an additional reference for MOP 7 in the
      Mode
      "Mode of Operation Operation" registry that is part of under
      the Routing "Routing Protocol for Low Power and Lossy Networks (RPL) (RPL)" registry group
      <xref target='IANA-RPL'/>.
</t>
</section><!-- RPL DODAG Configuration Option Flag -->
</section>

   <section anchor='elec6lorh'><name>Elective 6LoWPAN Routing Header Type</name>

   <t>
   IANA is requested to update has updated the "Elective 6LoWPAN Routing Header Type" registry that
   was created for <xref target='RFC8138'/> under the heading
   "Elective 6LoWPAN Routing Header Type"
   in the "IPv6 Low Power Personal Area Network Parameters" registry group
    <xref target='IANA-6LO'/> and assign the following value: as follows:
</t>
        <table anchor="elec6lorhtbl"><name>New Elective 6LoWPAN Routing Header Type</name>
   <thead>

          <tr><th align='center'>Value</th>

          <th align='left'>Description</th>

          <th align='left'>Reference</th></tr>

          <tr><th>Value</th>

          <th>Description</th>

          <th>Reference</th></tr>

   </thead><tbody>

          <tr><td align='center'>8 (Suggested)</td>

          <td align='left'>P-RPI-6LoRH</td>

          <td align='left'>THIS RFC</td></tr> align="center">8</td>

          <td>P-RPI-6LoRH</td>

          <td>RFC 9914</td></tr>

    </tbody>
        </table>
   </section><!-- Elective 6LoWPAN Routing Header Type -->
   </section>

   <section anchor='crit6lorh'><name>Critical 6LoWPAN Routing Header Type</name>
   <t>
   IANA is requested to update has updated the "Critical 6LoWPAN Routing Header Type" registry that was created for <xref target='RFC8138'/>
   under the heading "Critical 6LoWPAN Routing Header Type"

   in the "IPv6 Low Power Personal Area Network Parameters" registry group
   <xref target='IANA-6LO'/> and assign the following value: as follows:
</t>
        <table anchor="crit6lorhtbl"><name>New Critical 6LoWPAN Routing Header Type</name>
   <thead>

          <tr><th align='center'>Value</th>

          <th align='left'>Description</th>

          <th align='left'>Reference</th></tr>

          <tr><th>Value</th>

          <th>Description</th>

          <th>Reference</th></tr>

   </thead><tbody>

          <tr><td align='center'>8 (Suggested)</td>

          <td align='left'>P-RPI-6LoRH</td>

          <td align='left'>THIS RFC</td></tr> align="center">8</td>

          <td>P-RPI-6LoRH</td>

          <td>RFC 9914</td></tr>

    </tbody>
        </table>
   </section><!-- Critical 6LoWPAN Routing Header Type -->
   </section>

   <section anchor='RPIIANA'><name>Registry For The for RPL Option Flags</name>
    <t>
   IANA is requested to create a registry for has created the 8-bit "RPL Option Flags" field, registry, for the 8-bit RPL Option flags field as detailed in <xref target='Rpifmt'/>, under the heading "Routing Protocol for Low Power and Lossy Networks (RPL)"
   registry group <xref target='IANA-RPL'/>.

   The bits are indexed from 0 (leftmost) to 7. Each bit is tracked with the following qualities:
   </t>
   <ul>
     <li>Bit number (counting from bit 0 as the most significant bit)</li>
     <li>Indication When Set</li> when set</li>
     <li>Reference</li>
   </ul>

 <t> Registration The registration procedure is "Standards Action" Standards Action <xref target='RFC8126'/>.
     The initial allocation is as indicated in <xref target='RPLoptFlagtbl'/>:
 </t>

        <table anchor="RPLoptFlagtbl"><name>Initial PDR Flags</name>
   <thead>

          <tr><th align='center'>Bit number</th>

          <th align='left'>Indication

          <tr><th>Bit Number</th>

          <th>Indication When Set</th>

          <th align='left'>Reference</th></tr>

          <th>Reference</th></tr>

   </thead><tbody>

          <tr><td align='center'>0</td>

          <td align='left'>Down 'O'</td>

          <td align='left'><xref align="center">0</td>

          <td>Down (O)</td>

          <td><xref target='RFC6553'/> </td></tr>

          <tr><td align='center'>1</td>

          <td align='left'>Rank-Error align="center">1</td>

          <td>Rank-Error (R)</td>

          <td align='left'><xref

          <td><xref target='RFC6553'/> </td></tr>

          <tr><td align='center'>2</td>

          <td align='left'>Forwarding-Error align="center">2</td>

          <td>Forwarding-Error (F)</td>

          <td align='left'><xref

          <td><xref target='RFC6553'/> </td></tr>

          <tr><td align='center'>3 (Suggested)</td>

          <td align='left'>Projected-Route align="center">3</td>

          <td>Projected-Route (P)</td>

          <td align='left'>THIS RFC</td></tr>

          <td>RFC 9914</td></tr>

          <tr><td align='center'>4..255</td>

          <td align='left'>Unassigned</td>

          <td align='left'> align="center">4..255</td>

          <td>Unassigned</td>

          <td> </td></tr>
    </tbody>
        </table>
   </section><!-- Registry For The RPL Option Flags -->
   </section>

   <section anchor='RPLCtrlMsgReg'><name>RPL Control Codes</name>

    <t> IANA is requested to update has updated the "RPL Control Codes" registry under the heading "Routing Protocol for Low Power and Lossy Networks (RPL)" registry group <xref target='IANA-RPL'/>
   as indicated in <xref target="ianaRPLCtrlMsgtbl"/>:</t>

        <table anchor="ianaRPLCtrlMsgtbl"><name>New RPL Control Codes</name>
   <thead>
          <tr><th align='center'>Code</th>

          <th align='left'>Description</th>

          <th align='left'>Reference</th></tr>
          <tr><th>Code</th>

          <th>Description</th>

          <th>Reference</th></tr>

   </thead><tbody>

          <tr><td align='center'>0x09 (Suggested)</td>

          <td align='left'>Projected align="center">0x09</td>

          <td>Projected DAO Request (PDR)</td>

          <td align='left'>THIS RFC</td></tr>

          <td>RFC 9914</td></tr>

          <tr><td align='center'>0x0A (Suggested)</td>

          <td align='left'>PDR-ACK</td>

          <td align='left'>THIS RFC</td></tr> align="center">0x0A</td>

          <td>PDR-ACK</td>

          <td>RFC 9914</td></tr>
   </tbody>
        </table>

   </section> <!-- "RPL Control Codes" -->

   <section anchor='RPLCtrlMsgOptionsReg'><name>RPL Control Message Options</name>

    <t> IANA is requested to update has updated the "RPL Control Message Options" registry under the heading "Routing Protocol for Low Power and Lossy Networks (RPL)" registry group <xref target='IANA-RPL'/>
 as indicated in <xref target="ianaRPLCtrlMsgopttbl"/>:</t>

        <table anchor="ianaRPLCtrlMsgopttbl"><name>RPL Control Message Options</name>
   <thead>
          <tr><th align='center'>Value</th>

          <th align='left'>Meaning</th>

          <th align='left'>Reference</th></tr>
          <tr><th>Value</th>

          <th>Meaning</th>

          <th>Reference</th></tr>

   </thead><tbody>

          <tr><td align='center'>0x0E (Suggested)</td>

          <td align='left'>Stateful align="center">0x0F</td>

          <td>Stateful VIO (SM-VIO)</td>

          <td align='left'>THIS RFC</td></tr>

          <td>RFC 9914</td></tr>

          <tr><td align='center'>0x0F (Suggested)</td>

          <td align='left'>Source-Routed align="center">0x10</td>

          <td>Source-Routed VIO (NSM-VIO)</td>

          <td align='left'>THIS RFC</td></tr>

          <td>RFC 9914</td></tr>

          <tr><td align='center'>0x10 (Suggested)</td>

          <td align='left'>Sibling align="center">0x11</td>

          <td>Sibling Information option</td>

          <td align='left'>THIS RFC</td></tr> Option (SIO)</td>

          <td>RFC 9914</td></tr>
   </tbody>
        </table>

   </section> <!-- "RPL Control Message Options" -->

   <section anchor='RPLPDRflagReg'>
   <name>SubRegistry
   <name>Registry for the Projected DAO Request Flags</name>
   <t>
      IANA is requested to create a registry for has created the 8-bit "Projected DAO Request (PDR)" field (PDR) Flags" registry under the heading "Routing Protocol for Low Power and Lossy Networks (RPL)" registry group <xref target='IANA-RPL'/>. The bits are indexed from 0 (leftmost) to 7. Each bit is tracked with the following qualities:

   </t>
   <ul>
     <li>Bit number (counting from bit 0 as the most significant bit)</li>
     <li>Capability description</li>
     <li>Reference</li>
   </ul>

 <t> Registration The registration procedure is "Standards Action" Standards Action <xref target='RFC8126'/>.
 The initial allocation is as indicated in <xref target='RPLPDRflagRegtbl'/>:
 </t>

        <table anchor="RPLPDRflagRegtbl"><name>Initial PDR Flags</name>
   <thead>

          <tr><th align='center'>Bit number</th>

          <th align='left'>Capability description</th>

          <th align='left'>Reference</th></tr>

          <tr><th>Bit Number</th>

          <th>Capability Description</th>

          <th>Reference</th></tr>

   </thead><tbody>

          <tr><td align='center'>0</td>

          <td align='left'>PDR-ACK align="center">0</td>

          <td>PDR-ACK request (K)</td>

          <td align='left'>THIS RFC</td></tr>

          <td>RFC 9914</td></tr>

          <tr><td align='center'>1</td>

          <td align='left'>Requested align="center">1</td>

          <td>Requested path should be redundant (R)</td>

          <td align='left'>THIS RFC</td></tr>

          <td>RFC 9914</td></tr>
          <tr><td align='center'>2..255</td>

          <td align='left'>Unassigned</td>

          <td align='left'></td></tr> align="center">2..255</td>

          <td>Unassigned</td>

          <td></td></tr>
    </tbody>
        </table>

   </section> <!-- SubRegistry for the Projected DAO Request Flags -->

   <section anchor='RPLPDRackflagReg'>
   <name>SubRegistry
   <name>Registry for the PDR-ACK Flags</name>

   <t>
   IANA is requested to create a registry for has created the 8-bit "PDR-ACK Flags" field registry under the heading "Routing Protocol for Low Power and Lossy Networks (RPL)" registry group <xref target='IANA-RPL'/>. The bits are indexed from 0 (leftmost) to 7. Each bit is tracked with the following qualities:
   </t>
   <ul>
     <li>Bit number (counting from bit 0 as the most significant bit)</li>
     <li>Capability description</li>
     <li>Reference</li>
   </ul>

 <t>Registration

 <t>The registration procedure is "Standards Action" Standards Action <xref target='RFC8126'/>.
    No
 At the time of publication of this document, no bit is currently has been assigned for the PDR-ACK Flags. in this
 registry.
   </t>

   </section> <!-- SubRegistry for the PDR-ACK Flags -->

<section anchor='iana-stats-nonrej'>
<name>Registry for the PDR-ACK Acceptance Status Values </name>
 <t>

     IANA is requested to create a registry for has created the 8-bit "PDR-ACK Acceptance
    Status Values" registry under the heading "Routing Protocol for Low Power and Lossy Networks (RPL)" registry group <xref target='IANA-RPL'/>.

     Each value is tracked with the following qualities:
   </t>
   <ul>
     <li>Value</li>
     <li>Meaning</li>
     <li>Reference</li>
   </ul>

<t> the The possible values are expressed as a 6-bit unsigned integer (0..63).
  the
  The registration procedure is "Standards Action" Standards Action <xref target='RFC8126'/>.
  </t>
  <t>
  The (suggested) initial allocation is as indicated in <xref target='iana-ack-status'/>:
  </t>

   <table anchor='iana-ack-status'><name>Acceptance values Values of the PDR-ACK Status</name>
   <thead>
      <tr><td>Value</td><td>Meaning</td><td>Reference</td></tr>
     <tr><th>Value</th>
     <th>Meaning</th><th>Reference</th></tr>
   </thead><tbody>
      <tr><td>0</td><td>Unqualified Acceptance</td><td>THIS RFC</td></tr>
      <tr><td>1..63</td><td>Unassigned</td><td></td></tr>
   <tr><td align="center">0</td>
   <td>Unqualified Acceptance</td><td>RFC 9914</td></tr>
   <tr><td align="center">1..63</td>
   <td>Unassigned</td><td></td></tr>
   </tbody>

   </table>

</section><!-- Registry for the PDR-ACK Acceptance Status Values -->

</section>

<section anchor='iana-stats-rej'>
<name>Registry for the PDR-ACK Rejection Status Values</name>

   <t>
    IANA is requested to create a registry for has created the 6-bit "PDR-ACK Rejection Status Values" registry
    under the heading "Routing Protocol for Low Power and Lossy Networks (RPL)" registry group <xref target='IANA-RPL'/>.
     Each value is tracked with the following qualities:
   </t>
   <ul>
     <li>Value</li>
     <li>Meaning</li>
     <li>Reference</li>
   </ul>

<t> the

<t>The possible values are expressed as a 6-bit unsigned integer (0..63).
  the
  The registration procedure is "Standards Action" Standards Action <xref target='RFC8126'/>.
  </t>
  <t>
  The (suggected) initial allocation is as indicated in <xref target='iana-nack-status'/>:
  </t>

   <table anchor='iana-nack-status'><name>Rejection values of the PDR-ACK Status</name> anchor='iana-nack-status'><name>PDR-ACK Rejection Status Values</name>
   <thead>
      <tr><td>Value</td><td>Meaning</td><td>Reference</td></tr>
      <tr><th>Value</th><th>Meaning</th><th>Reference</th></tr>
   </thead><tbody>
      <tr><td>0</td><td>Unqualified Rejection</td><td>THIS RFC</td></tr>
      <tr><td>1</td><td>Transient Failure</td><td>THIS RFC</td></tr>
      <tr><td>2..63</td><td>Unassigned</td><td></td></tr>
      <tr><td align="center">0</td><td>Unqualified Rejection</td><td>RFC 9914</td></tr>
      <tr><td align="center">1</td><td>Transient Failure</td><td>RFC 9914</td></tr>
      <tr><td align="center">2..63</td><td>Unassigned</td><td></td></tr>
   </tbody>

   </table>

</section><!-- Registry for the PDR-ACK Rejection Status Values -->

</section>

   <section anchor='RPLVIOflagReg'>
   <name>SubRegistry
   <name>Registry for the Via Information Options Flags</name>

   <t>
   IANA is requested to create a registry for has created the 8-bit "Via Information Options
   (VIO) Flags" field registry under the heading "Routing Protocol for Low Power and Lossy Networks (RPL)" registry group <xref target='IANA-RPL'/>. The bits are indexed from 0 (leftmost) to 7. Each bit is tracked with the following qualities:
   </t>
   <ul>
     <li>Bit number (counting from bit 0 as the most significant bit)</li>
     <li>Capability description</li>
     <li>Reference</li>
   </ul>

 <t>Registration

 <t>The registration procedure is "Standards Action" Standards Action <xref target='RFC8126'/>.
    No
 At the time of publication of this document, no bit is currently has been assigned for the VIO Flags, in this
 registry (see more in <xref target="viof"/>. target="viof"/>).
   </t>

   </section> <!-- SubRegistry for the Via Information Options Flags -->

   <section anchor='RPLSIOflagReg'>
   <name>SubRegistry
   <name>Registry for the Sibling Information Option Flags</name>

   <t>
   IANA is requested to create a registry for has created the 5-bit "Sibling Information
   Option (SIO) Flags" field registry under the heading "Routing Protocol for Low Power and Lossy Networks (RPL)" registry group <xref target='IANA-RPL'/>. The bits are indexed from 0 (leftmost) to 4. Each bit is tracked with the following qualities:
   </t>
   <ul>
     <li>Bit number (counting from bit 0 as the most significant bit)</li>
     <li>Capability description</li>
     <li>Reference</li>
   </ul>

 <t> Registration The registration procedure is "Standards Action" Standards Action <xref target='RFC8126'/>. The initial allocation is as indicated in <xref target='RPLSIORegtbl'/>, target='RPLSIORegtbl'/> (see more in <xref target="siof"/>: target="siof"/>):
 </t>

        <table anchor="RPLSIORegtbl"><name>Initial SIO Flags</name>
   <thead>

          <tr><th align='center'>Bit number</th>

          <th align='left'>Capability description</th>

          <th align='left'>Reference</th></tr>

          <tr><th>Bit Number</th>

          <th>Capability Description</th>

          <th>Reference</th></tr>

   </thead><tbody>

          <tr><td align='center'>0 (Suggested)</td>

          <td align='left'>"S" align="center">0</td>

          <td>'S' flag: Sibling in same DODAG as Self</td>

          <td align='left'>THIS RFC</td></tr>
          <tr><td align='center'>1..4</td>

          <td align='left'>Unassigned</td>

          <td align='left'></td></tr> self</td>

          <td>RFC 9914</td></tr>
          <tr><td align="center">1..4</td>

          <td>Unassigned</td>

          <td></td></tr>

    </tbody>
        </table>

   </section> <!-- SubRegistry for the Sibling Information Option Flags -->

<section anchor="iana-P-DAO"><name>Destination Advertisement Object Flag</name>

    <t>
    IANA is requested to update has updated the "Destination Advertisement Object (DAO) Flags"
    registry
    registry, created in Section 20.11 of <xref target='RFC6550'/> target='RFC6550' section="20.11"/>, under the
    heading
    "Routing Protocol for Low Power and Lossy Networks (RPL)" registry group <xref target='IANA-RPL'/> as
    indicated in <xref target="iana-P-DAOtbl"/>, target="iana-P-DAOtbl"/> (see more in <xref target="extP-DAO"/>: target="extP-DAO"/>):
    </t>

   <table  anchor="iana-P-DAOtbl">
      <name>New Destination Advertisement Object (DAO) Flag</name>
   <thead>
      <tr><td>Bit Number</td><td>Capability Description</td><td>Reference</td></tr>
     <tr><th>Bit Number</th>
     <th>Capability Description</th><th>Reference</th></tr>
   </thead><tbody>
      <tr><td>2 (Suggested)</td><td>Projected
   <tr><td align="center">2</td>
   <td>Projected DAO (P)</td><td>THIS RFC</td></tr> (P)</td><td>RFC 9914</td></tr>
   </tbody>
   </table>

   </section>

<section anchor="iana-P-DAO-aCK"><name>Destination Advertisement Object Acknowledgment Flag</name>

    <t> IANA is requested to update has updated the "Destination Advertisement Object (DAO) Acknowledgment Flags" registry registry, created in Section 20.12 of <xref target='RFC6550'/> target='RFC6550' section="20.12"/>, under the heading "Routing Protocol for Low Power and Lossy Networks (RPL)" registry group <xref target='IANA-RPL'/> as indicated in <xref target="iana-P-DAO-ACKtbl"/>, target="iana-P-DAO-ACKtbl"/> (see
    more in <xref target='extP-DAO-ACK'/>: target='extP-DAO-ACK'/>):
    </t>

   <table  anchor="iana-P-DAO-ACKtbl">
      <name>New Destination Advertisement Object Acknowledgment Flag</name>
   <thead>
      <tr><td>Bit Number</td><td>Capability Description</td><td>Reference</td></tr>
      <tr><th>Bit Number</th><th>Capability Description</th><th>Reference</th></tr>
   </thead><tbody>
      <tr><td>1 (Suggested)</td><td>Projected
      <tr><td align="center">1</td><td>Projected DAO-ACK (P)</td><td>THIS RFC</td></tr> (P)</td><td>RFC 9914</td></tr>
   </tbody>
   </table>

   </section>

   <section anchor='ICMPv6ErrPRoute'>
        <name>New ICMPv6
        <name>ICMPv6 Error Code</name>
        <t>In some cases cases, RPL will return an ICMPv6 error message when a
        message cannot be forwarded along a P-Route.</t>

        <t> This specification requires that a new code is allocated from

        <t>Per this specification, IANA has updated the
        'ICMPv6 "Code" Fields' heading of
        "Type 1 - Destination Unreachable" registry, in the
	"ICMPv6 'Code' Fields" registry, under the "Internet Control Message Protocol
        version 6 (ICMPv6) Parameters" registry group <xref target='IANA-ICMP'/> Registry for
        "Type 1 - Destination Unreachable",
        with a suggested code value of 9, to be confirmed by IANA to indicate an
        "Error as indicated in P-Route".</t>
   </section> <!--"ICMPv6: <xref target="iana-ICMPv6_error_code"/>.</t>

    <table  anchor="iana-ICMPv6_error_code">
      <name>New ICMPv6 Error Code</name>
   <thead>
     <tr><th>Code</th>
     <th>Name</th><th>Reference</th></tr>
   </thead><tbody>
   <tr><td align="center">9</td>
   <td>Error in a P-Route" --> P-Route</td><td>RFC 9914</td></tr>
   </tbody>
   </table>

   </section>

<section anchor='iana-stats-rpl-rej'><name>RPL Rejection Status values Values </name>

    <t> IANA is requested to update has updated the "RPL Rejection Status" registry
    under the heading "Routing Protocol for Low Power and Lossy Networks (RPL)" registry group <xref target='IANA-RPL'/>
    as indicated in <xref target="iana-nack-Status"/>:
</t>

   <table anchor='iana-nack-Status'><name>Rejection values of the RPL anchor='iana-nack-Status'><name>RPL Rejection Status Values </name>
   <thead>
      <tr><td>Value</td><td>Meaning</td><td>Reference</td></tr>
      <tr><th>Value</th><th>Meaning</th><th>Reference</th></tr>
   </thead><tbody>
      <tr><td>2 (Suggested)</td><td>Out
      <tr><td align="center">2</td><td>Out of Resources</td><td>THIS RFC</td></tr>
      <tr><td>3 (Suggested)</td><td>Error in VIO</td><td>THIS RFC</td></tr>
      <tr><td>4 (Suggested)</td><td>Predecessor Unreachable</td><td>THIS RFC Resources</td><td>RFC 9914</td></tr>
      <tr><td align="center">3</td><td>Error in VIO</td><td>RFC 9914</td></tr>
      <tr><td align="center">4</td><td>Predecessor Unreachable</td><td>RFC 9914
      </td></tr>
      <tr><td>5 (Suggested)</td><td>Unreachable Target</td><td>THIS RFC
      <tr><td align="center">5</td><td>Unreachable Target</td><td>RFC 9914
      </td></tr>
      <tr><td>6..63</td><td>Unassigned</td><td></td></tr>
      <tr><td align="center">6..63</td><td>Unassigned</td><td></td></tr>
   </tbody>

   </table>

</section>

</section>

    </middle>
    <back>

   <displayreference   target="RFC1122"    to="INT-ARCH"/>
   <displayreference   target="RFC4944"        to="6LoWPAN"/>
   <displayreference   target="RFC6550"        to="RPL"/>
   <displayreference   target="I-D.kuehlewind-rswg-updates-tag" to="NEW-TAGS"/>
   <displayreference   target="RFC9912"   to="RAW-ARCH"/>

<references>
  <name>References</name>

<!-- [rfced] Would you like the references to be alphabetized
or left in their current order?
-->

  <references>
    <name>Normative References</name>
    <xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml'/>
    <xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4443.xml'/>
    <xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6282.xml'/>
    <xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6550.xml'/>
    <xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6553.xml'/>
    <xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6554.xml'/>
    <xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml'/>
    <xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8138.xml'/>
    <xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml'/>
    <xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9008.xml'/>
    <xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9030.xml'/>

<!-- [RAW-ARCHI] /[RFC9912] - in AUTH48 as of 2/9/2026
draft-ietf-raw-architecture-30
companion doc RFC 9912
-->
<reference anchor="RFC9912" target="https://www.rfc-editor.org/info/rfc9912">
  <front>
    <title>Reliable and Available Wireless (RAW) Architecture</title>
    <author initials="P." surname="Thubert" fullname="Pascal
                                                      Thubert" role="editor">
      <organization>Without Affiliation</organization>
    </author>
    <date month='February' year='2026'/>
  </front>
  <seriesInfo name="RFC" value="9912"/>
  <seriesInfo name="DOI" value="10.17487/RFC9912"/>
</reference>

    </references><references>
    <name>Informative References</name>
    <xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1122.xml'/>
    <xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4655.xml'/>
    <xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml'/>
    <xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4944.xml'/>
    <xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5440.xml'/>
    <xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6997.xml'/>
    <xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7102.xml'/>
    <xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7416.xml'/>
    <xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8025.xml'/>
    <xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml'/>
    <xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8505.xml'/>
    <xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8754.xml'/>
    <xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8655.xml'/>
    <xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8930.xml'/>
    <xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8931.xml'/>
    <xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8994.xml'/>
    <xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9010.xml'/>
    <xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9031.xml'/>
    <xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9035.xml'/>
    <xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9450.xml'/>
<!-- Registry Note: Updated draft-irtf-panrg-path-properties-08 to RFC 9473 -->
    <xi:include href='https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9473.xml'/>

<!--[rfced] FYI: "draft-kuehlewind-update-tag" has been replaced by
"draft-kuehlewind-rswg-updates-tag", so we have updated this
reference entry accordingly. Please let us know of any objection.

Original:
   [I-D.kuehlewind-update-tag]
       Kühlewind, M. and S. Krishnan, "Definition of new tags for RPL Rejection Status values
       relations between RFCs", Work in Progress, Internet-Draft,
       draft-kuehlewind-update-tag-04, 12 July 2021,
       <https://datatracker.ietf.org/doc/html/draft-kuehlewind-
       update-tag-04>.

Current:
   [NEW-TAGS]
       Kühlewind, M. and S. Krishnan, "Definition of new tags for
       relations between RFCs", Work in Progress, Internet-Draft,
       draft-kuehlewind-rswg-updates-tag-02, 8 July 2024,
       <https://datatracker.ietf.org/doc/html/draft-kuehlewind-
       rswg-updates-tag-02>.
-->

</section>

<!-- "IANA Considerations"-->

<section><name>Acknowledgments</name> [I-D.kuehlewind-update-tag]
draft-kuehlewind-update-tag-04
IESG State: Replaced by draft-kuehlewind-rswg-updates-tag
-->
    <!--<xi:include href='https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.kuehlewind-update-tag.xml'/>-->

<xi:include href='https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.kuehlewind-rswg-updates-tag.xml'/>

            <reference anchor='IANA-6LO' target='https://www.iana.org/assignments/_6lowpan-parameters'>
         <front>
            <title>IPv6 Low Power Personal Area Network Parameters</title>
            <author>
               <organization>IANA</organization>
            </author>
            <date/>
         </front>
      </reference>

<!-- [rfced] FYI: We have updated this reference's URL to use the
following URL, which points to the "IPv6 Low Power Personal Area
Network Parameters" registry:
<https://www.iana.org/assignments/_6lowpan-parameters>. Please
let us know if this is incorrect.

Original:
  [IANA-6LO] IETF, "IPv6 Low Power Personal Area Network Parameters registry",
             <https://www.iana.org/assignments/icmpv6-parameters/>.

Current:
  [IANA-6LO] IANA, "IPv6 Low Power Personal Area Network Parameters",
             <https://www.iana.org/assignments/_6lowpan-parameters>.
-->

            <reference anchor='IANA-RPL' target='https://www.iana.org/assignments/rpl/'>
         <front>
            <title>Routing Protocol for Low Power and Lossy Networks (RPL)</title>
            <author>
               <organization>IANA</organization>
            </author>
            <date/>
         </front>
      </reference>

            <reference anchor='IANA-ICMP' target='https://www.iana.org/assignments/icmpv6-parameters/'>
         <front>
            <title>Internet Control Message Protocol version 6 (ICMPv6) Parameters</title>
            <author>
               <organization>IANA</organization>
            </author>
            <date/>
         </front>
      </reference>

    </references>
  </references>

  <section numbered="false">
    <name>Acknowledgments</name>
<t>The authors wish to acknowledge JP Vasseur, Remy Liubing, James Pylakutty,
   and Patrick Wetterwald <contact fullname="JP. Vasseur"/>, <contact
fullname="Remy Liubing"/>, <contact fullname="James Pylakutty"/>, and <contact
fullname="Patrick Wetterwald"/> for their contributions to the ideas developed
here.  Many thanks to Dominique Barthel and SVR Anand <contact fullname="Dominique Barthel"/> and <contact
fullname="S.V.R. Anand"/> for their global contribution to 6TiSCH, RAW RAW, and this
RFC, as well as text suggestions that were incorporated.
   Also  Also, special thanks
to Remous-Aris Koutsiamanis, Li Zhao, Dominique Barthel,
   and Toerless Eckert <contact fullname="Remous-Aris Koutsiamanis"/>, <contact fullname="Li
Zhao"/>, <contact fullname="Dominique Barthel"/>, and <contact
fullname="Toerless Eckert"/> for their in-depth reviews, with many excellent
suggestions that improved the readability and well as the content of the
specification.  Many thanks to Remous-Aris Koutsiamanis <contact fullname="Remous-Aris Koutsiamanis"/>
for his review during WGLC WG Last Call and to <contact fullname="Maria Ines Robles Robles"/> for her shepherding and
thorough shepherd review.  Many thanks to Warren Kumari, Ran Chen, Murray Kucherawy, Roman Danyliw, Klaas Wierenga, Deb Cooley, Eric Vyncke, Gunter <contact fullname="Warren
Kumari"/>, <contact fullname="Ran Chen"/>, <contact fullname="Murray
Kucherawy"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Klaas
Wierenga"/>, <contact fullname="Deb Cooley"/>, <contact fullname="Éric
Vyncke"/>, <contact fullname="Gunter Van de Velde, Sue Hares and John Scudder Velde"/>, <contact fullname="Sue
Hares"/>, and <contact fullname="John Scudder"/> for their comments and
suggestions during the IETF last call Last Call and IESG review cycle.
  </t>
</section>

    </middle>
    <back>

   <displayreference   target="RFC1122"    to="INT-ARCHI"/>
   <displayreference   target="RFC4944"        to="6LoWPAN"/>
   <displayreference   target="RFC6550"        to="RPL"/>
   <displayreference   target="I-D.ietf-raw-architecture"   to="RAW-ARCHI"/>

    <references>
    <name>Normative References</name>

	  <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml'/>
	  <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4443.xml'/>
	  <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6282.xml'/>
	  <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6550.xml'/>
	  <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6553.xml'/>
	  <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6554.xml'/>
	  <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml'/>
	  <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8138.xml'/>
	  <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml'/>
	  <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9008.xml'/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9030.xml'/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-raw-architecture.xml'/>

    </references><references>
    <name>Informative References</name>

	  <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1122.xml'/>
	  <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4655.xml'/>
	  <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml'/>
	  <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4944.xml'/>
	  <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5440.xml'/>
	  <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6997.xml'/>
	  <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7102.xml'/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7416.xml'/>
	  <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8025.xml'/>
	  <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml'/>
	  <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8505.xml'/>
	  <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8754.xml'/>
	  <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8655.xml'/>
	  <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8930.xml'/>
	  <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8931.xml'/>
	  <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8994.xml'/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9010.xml'/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9031.xml'/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9035.xml'/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9450.xml'/>
      <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.kuehlewind-update-tag.xml'/>

     <xi:include href="http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.irtf-panrg-path-properties.xml"/>

            <reference anchor='IANA-6LO' target='https://www.iana.org/assignments/icmpv6-parameters/'>
         <front>
            <title>IPv6 Low Power Personal Area

</back>

<!-- [rfced] Some author comments are present in the XML. Please confirm that
no updates related to these comments are outstanding. Note that the
comments will be deleted prior to publication.
-->

<!-- [rfced] Terminology

a) Throughout the text, the following terminology appears to be used
inconsistently. Please review these occurrences and let us know if/how they
may be made consistent.

  Complex Track vs. complex Track

  Objective Function vs. objective function

  Instance vs. instance
    [Note: is "topologies called instances" correct or should it be
    "Instances"? Should any other lowercase occurrences be uppercase?]
  Global Instance vs. global instance
    [Note: "Global RPL Instance" and "Global instance" used in RFC 6550
     and "Global Instance 0" used in RFC 8138]
  Local Instance
  main Instance vs. main instance
  RPL Instance vs. RPL instance
    [Note: "RPL Instance" used in RFCs 6550, 6553, and 8138 and
    companion document draft-ietf-raw-technologies-17]
  Track Instance vs. Track instance

  Rejection Status vs. rejection status
    [Note: "rejection status" used in RFC 6550)

  Root vs. root
    [Note: There are 7 lowercase instances, plus one within quoted text.
    Aside from the quoted text, should any of these be made uppercase
    for consistency?]

  Routing Header vs. routing header
    [Note: "Routing Header" used in RFC 8138. Also, after the first
    expansion, may we replace this term with "RH"?]

  Segment ID (4) vs. SegmentID (6)

  Track ID (3) vs. TrackID (90)

  Target (77) vs. target (11)

  Type of 4 vs. type 4 (also, type 3 and type 5)

b) FYI: We updated the following terms to reflect the forms on the
right for consistency. Please let us know of any objection.

 6LoWPAN Header Compression -> 6LoWPAN header compression (per RFC 8138)
 6LoWPAN Network Parameters registry</title>
            <author>
               <organization>IETF</organization>
            </author>
            <date/>
         </front>
      </reference>

            <reference anchor='IANA-RPL' target='https://www.iana.org/assignments/rpl/'>
         <front>
            <title>Routing -> 6LoWPAN network
 6TiSCH Architecture -> 6TiSCH architecture
 Backbone -> backbone (per RFC 6550)
 base Object and base object -> Base Object
 Border Router and Border router -> border router (per RFC 6550)
 Code -> code (per RFC 6550)
 dataplane -> data plane (per companion document draft-ietf-raw-technologies-17)
 Destination Address -> destination address
 DODAG Configuration Option -> DODAG Configuration option (per RFC 6550)
 DODAG ID -> DODAGID
 Extension Header and extension Header -> extension header
 external Controller -> external controller
 global RPLInstanceID -> Global RPLInstanceID
 IPv6 Address -> IPv6 address
 IPv6 Header -> IPv6 header (per RFC 8138)
 Legacy -> legacy (per companion document draft-ietf-raw-technologies-17)
 Link-Layer security -> link-layer security (per RFC 9010)
 local RPL Instance ->  Local RPL Instance (per RFC 6550 and companion
   document draft-ietf-raw-technologies-17)
 local RPLInstanceID -> Local RPLInstanceID (per companion document
   draft-ietf-raw-technologies-17)
 loose Source Routing -> loose source routing
 multihop -> multi-hop (per RFC 8930 and companion documents)
 Non-Storing mode and non-storing mode -> Non-Storing Mode
 Non-Storing P-DAO -> Non-Storing Mode P-DAO
 P-route -> P-Route
 Protection Path -> protection path (to match companion documents)
 Protection service -> protection service
 RAW Architecture -> RAW architecture (to match companion documents)
 Recovery Graph -> recovery graph (per companion document draft-ietf-raw-architecture-30)
 Routing Stretch -> routing stretch
 RPL InstanceID and RPLinstanceID -> RPLInstanceID
 RPL Network -> RPL network
 segment Lifetime of zero -> Segment Lifetime of 0
 Sibling Information option -> Sibling Information Option
 Source Address -> source address (per RFC 6550)
 Source Route path -> source route path (per RFCs 6550 and 8138)
 Stand-Alone -> stand-alone
 Storing mode and storing mode -> Storing Mode
 Strict -> strict
 time scale -> timescale (per companion document draft-ietf-raw-architecture-30)
 track -> Track (5 instances)
 traffic Engineering -> Traffic Engineering (per companion documents)
 VIA Address -> Via address
 Via Information option -> Via Information Option

c) Please review the following capitalization inconsistencies in the names of
nodes and let us know how to update for consistency. Note that the first three
terms below appeared in the companion document draft-ietf-raw-architecture-30,
and the author chose to use "egress node", "ingress node", and "relay node"
(all lowercase). If you would like to follow this pattern in this document,
please also review instances of "Egress" and "Ingress" when not in the
context of "Egress Node" and "Ingress Node" (e.g., "the Track Egress", "from
Ingress to Egress") and let us know they should be lowercased as well.

Note that "Root Node" and "Forwarding Node" did not appear in the companion
documents.

 Egress Node vs. Egress node
 Ingress Node vs. Ingress node
 Relay Node vs. Relay node
    [Note: "relay node" used in RFC 8655]

 Root Node
 Forwarding Node vs. forwarding Node

d) Please let us know if/how we may make these terms consistent.

 Projected DAO-ACK vs. P-DAO-ACK
   [Note: Is "P-DAO-ACK" short for "Projected DAO-ACK" or are these
   different terms? In Section 4.1.1, should the first mention of
   "P-DAO-ACK" be updated as "Projected DAO-ACK (P-DAO-ACK)"?]

 routing stretch vs. route stretch

 RPL DODAG Configuration option vs. RPL configuration option vs.
   DODAG Configuration option

 RPL Storing Mode vs. Storing Mode

e.1) Please let us know if/how we may make the case for these terms
consistent.

  Source Routing Header vs.
  source routing header
    [Note: Suggest uppercase to match RFCs 6554 and 8138.]

  Source Route Header vs.
  source route header vs.
  source-routed header
    [Note: Suggest uppercase.
    - Should "RPL" precede these instances to match use in
      RFC 6554 (e.g., "RPL Source Route Header"), or should any
      of these instances be "Source Routing Header" or "SRH"?]

e.2) Is the use of "(RPL) SRH" correct in the sentences below, or
should it be "RPL Source Route Header" per RFC 6554?

Original:
   In a Non-Storing mode RPL domain, the IPv6 RH used for source routing
   is the (RPL) SRH as defined in [RFC6554].

Perhaps:
   In a Non-Storing Mode RPL domain, the IPv6 RH used for source routing
   is the RPL Source Route Header as defined in [RFC6554].

...
Original:
   As such, forwarding along segments as specified hereafter can be seen
   as a form of Segment Routing [RFC8402], but leveraging the (RPL) SRH
   for its operation.

Perhaps:
   As such, forwarding along segments as specified hereafter can be seen
   as a form of Segment Routing [RFC8402] that leverages the RPL Source
   Route Header for its operation.

f) Regarding "Non-Storing Mode" vs. "Non-Storing Mode of Operation
(MOP)" and "Non-Storing MOP", should any of the instances below be
"Non-Storing Mode" or are they correct as is?

We note that RFC 6550 uses "Non-Storing mode" and "Non-Storing
Mode of Operation". Please let us know if any further changes are
needed to the case of "Mode" throughout the document.

Current:
 Section 1:   ... operated in RPL Non-Storing Mode of Operation (MOP)
 Section 3.2: ... RPL Storing Mode or Non-Storing Mode of Operation (MOP)
              ... compared to Non-Storing MOP

g) May we make "Header" lowercase (form on the right) for the following
terms to match use in RFC 8138?

 IP-in-IP 6LoRH Header -> IP-in-IP 6LoRH header
 P-RPI-6LoRH Header -> P-RPI-6LoRH header
 RPI-6LoRH Header -> RPI-6LoRH header

h) We note the inconsistent use of quote marks around flag names.
Please review and let us know if you prefer single quotes or no
quotes for consistency.

Some examples:
  'D' flag vs. D flag
  'P' flag vs. P flag
  'O', 'R', and 'F' flags vs. O, R, and F flags
-->

<!-- [rfced] Abbreviations

a) FYI - We have added expansions for the following abbreviations per
Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review these and
each expansion in the document carefully to ensure correctness.

  Deterministic Networking (DetNet)
  Enhanced Interior Gateway Routing Protocol (EIGRP)
  Operations, Administration, and Maintenance (OAM)

b) How may we expand the first mention of "P2P" below (in Section 1)?

We note "P2P (Point-to-Point)" in Section 2.4.4 and "P2P (Peer-to-
Peer)" in Section 3.3.2. Do all instances of "P2P" refer to
"Point-to-Point" except for Section 3.3.2, or should "P2P" in Section
3.3.2 (and/or elsewhere) be made consistent? Please clarify.

Current:
   The Routing Protocol for Low Power and Lossy Networks (RPL) registry group</title>
            <author>
               <organization>IETF</organization>
            </author>
            <date/>
         </front>
      </reference>

            <reference anchor='IANA-ICMP' target='https://www.iana.org/assignments/icmpv6-parameters/'>
         <front>
            <title>Internet Control Message [RPL]
   is a Distance Vector protocol, which is well-suited for application
   in a variety of low energy Internet of Things (IoT) networks where
   constrained nodes cannot maintain the full view of the topology,
   and stretched P2P paths are acceptable versus the signaling and
   state overhead involved in maintaining the shortest paths across.

c) How may we expand one instance of "TID"? Perhaps "Transaction ID",
"Track ID", or "TrackID"?

Current:
   If the DAO-ACK is not received, the Root may retry the DAO with the
   same TID or tear down the route.

d) FYI: We updated the following expansions to the forms on the
right for consistency. Please let us know of any objection.

   PCE Protocol version 6 (ICMPv6) Parameters registry group</title>
            <author>
               <organization>IETF</organization>
            </author>
            <date/>
         </front>
      </reference>

    </references>

    </back> (PCEP) -> PCE Communication Protocol (PCEP) (per RFC 5440)
   Segment Routing (SRv6) -> Segment Routing over IPv6 (SRv6) (per RFC 8754)

e) We note the following inconsistencies with the companion
document. Please review and let us know if any changes to this
document are necessary or if these variations are okay.

  "packet delivery ratio (PDR)" (in draft-ietf-raw-architecture-30) vs.
    "P-DAO Request (PDR)" (in this document)

  "Radio Access Network (RAN)" (in draft-ietf-raw-architecture-30) vs.
    "RPL-Aware Node (RAN)" (in this document)
-->

<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.  Updates of this nature typically
result in more precise language, which is helpful for readers.

For example, please consider whether the following should be updated:
 - native

In addition, please consider whether "traditional" (2 instances)
should be updated for clarity.  While the NIST website
<https://web.archive.org/web/20250214092458/https://www.nist.gov/
nist-research-library/nist-technical-series-publications-author-instructions#table1>
indicates that this term is potentially biased, it is also ambiguous.
"Tradition" is a subjective term, as it is not the same for everyone.
-->

</rfc>