rfc9914.original.xml   rfc9914.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<?rfc toc="yes"?> <!DOCTYPE rfc [
<?rfc tocompact="yes"?> <!ENTITY nbsp "&#160;">
<?rfc tocdepth="3"?> <!ENTITY zwsp "&#8203;">
<?rfc tocindent="yes"?> <!ENTITY nbhy "&#8209;">
<?rfc symrefs="yes"?> <!ENTITY wj "&#8288;">
<?rfc sortrefs="yes"?> ]>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="no"?>
<?rfc subcompact="no"?>
<?rfc authorship="yes"?>
<?rfc tocappendix="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" ipr='trust200902
' tocInclude="true" indexInclude="true" obsoletes="" consensus="true" submissio
nType="IETF" xml:lang="en" version="3" docName="draft-ietf-roll-dao-projection-4
0" updates="6550, 6553, 8138">
<front> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" ipr='trust200902' tocInclude="true" indexInclude="true" obsoletes="" consensus="true" submission Type="IETF" xml:lang="en" version="3" docName="draft-ietf-roll-dao-projection-40 " number="9914" updates="6550, 6553, 8138" symRefs="true" sortRefs="false">
<title abbrev='DAO Projection'>Root-initiated Routing State in RPL</title> <!--[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='Root-Initiated Routing State in RPL'>Root-Initiated Routing St
ate in 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 '> <author initials='P' surname='Thubert' fullname='Pascal Thubert' role='editor '>
<!-- <organization abbrev='Cisco Systems'>Cisco Systems, Inc</organization > -->
<address> <address>
<postal> <postal>
<city>Roquefort-les-Pins</city> <city>Roquefort-les-Pins</city>
<code>06330</code> <code>06330</code>
<country>France</country> <country>France</country>
</postal> </postal>
<email>pascal.thubert@gmail.com</email> <email>pascal.thubert@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Rahul Arvind Jadhav" initials="R.A." surname="Jadhav"> <author fullname="Rahul Arvind Jadhav" initials="R.A." surname="Jadhav">
<organization>AccuKnox</organization> <organization>AccuKnox</organization>
<address> <address>
<postal> <postal>
<street>Kundalahalli Village, Whitefield,</street> <street>Kundalahalli Village, Whitefield</street>
<city>Bangalore</city> <city>Bangalore</city>
<region>Karnataka</region> <region>Karnataka</region>
<code>560037</code> <code>560037</code>
<country>India</country> <country>India</country>
</postal> </postal>
<phone>+91-080-49160700</phone> <phone>+91-080-49160700</phone>
<email>rahul.ietf@gmail.com</email> <email>rahul.ietf@gmail.com</email>
</address> </address>
</author> </author>
skipping to change at line 58 skipping to change at line 75
surname="Richardson"> surname="Richardson">
<organization abbrev="Sandelman">Sandelman Software Works</organization> <organization abbrev="Sandelman">Sandelman Software Works</organization>
<address> <address>
<email>mcr+ietf@sandelman.ca</email> <email>mcr+ietf@sandelman.ca</email>
<uri>http://www.sandelman.ca/</uri> <uri>http://www.sandelman.ca/</uri>
</address> </address>
</author> </author>
<date/> <date month="February" year="2026"/>
<area>Routing</area> <area>RTG</area>
<workgroup>roll</workgroup>
<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> <abstract>
<t> <t>The Routing Protocol for Low-Power and Lossy Networks (RPL) (RFC
The Routing Protocol for Low-Power and Lossy Networks (RPL, RFC 6550) enables da 6550) enables data packet routing along a Destination-Oriented
ta packet Directed Acyclic Graph (DODAG). However, the default route establishmen
routing along a Destination-Oriented Directed Acyclic Graph . However, t
the default route establishment mechanism relies on hop-by-hop forwarding along mechanism relies on hop-by-hop forwarding along the DODAG, which may
the DODAG, which may not always provide optimal routing efficiency. This not always provide optimal routing efficiency. This document
document introduces the concept of DAO Projection, a mechanism that allows a introduces the concept of Destination Advertisement Object (DAO) Projec
RPL root or an external controller to install optimized routes within the RPL tion,
domain. DAO Projections enable the creation of optimized unicast or multicast a mechanism that allows a
routes that do not strictly follow the DODAG structure, thereby improving RPL root or an external controller to install optimized routes
routing efficiency, reliability, availability, and resource utilization in the R within the RPL domain. DAO Projections enable the creation of
PL optimized unicast or multicast routes that do not strictly follow
domain. The document specifies two types of projected routes—storing mode and the DODAG structure, thereby improving routing efficiency,
non-storing mode projections—and outlines the signaling procedures necessary to reliability, availability, and resource utilization in the RPL
establish, maintain, and remove these routes. domain. This document specifies two types of Projected Routes (P-Routes
This document extends RFC 6550, RFC 6553, and RFC 8138. ) -- Storing
Mode and Non-Storing Mode -- and outlines the signaling
procedures necessary to establish, maintain, and remove these
routes.
This document updates RFCs 6550, 6553, and 8138.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<!-- **************************************************************** --> <section anchor='introduction'><name>Introduction</name>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='introduction'><name>Introduction</name>
<t> RPL, the <xref target='RFC6550'> <!-- [rfced] We have two questions about the text below.
"Routing Protocol for Low Power and Lossy Networks"</xref> (LLNs),
is a Distance Vector protocol, which is well-suited First, we believe the intention is to cite RFC 6550 as a
for application in a variety of low energy Internet of Things (IoT) 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 "Routing Protocol for Low Power and Lossy 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 networks where constrained nodes cannot maintain the full view of the
topology, and stretched P2P paths are acceptable vs. the signaling topology, and stretched P2P paths are acceptable vs. the signaling
and state overhead involved in maintaining the shortest paths across. 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 Additionally, RPL is anisotropic, meaning that its operation
depends on the orientation of the links, down from or up towards the depends on the orientation of the links, down from or up towards the
Root, with the default route advertised down and more specific paths Root, with the default route advertised down and more-specific paths
advertised up along a limited set of links. advertised up along a limited set of links.
</t> </t>
<t> <t>
RPL forms Destination Oriented Directed Acyclic Graphs (DODAGs) in which RPL forms Destination-Oriented Directed Acyclic Graphs (DODAGs) in which
the Root often acts as the Border router to connect the RPL domain to the the Root often acts as the border router to connect the RPL domain to the
IP backbone. Routers inside the DODAG route along that graph up towards IP backbone. Routers inside the DODAG route along the graph up towards
the Root for the default route and down towards destinations in the RPL the Root for the default route and down towards destinations in the RPL
domain for more specific routes. domain for more-specific routes.
This specification expects as a pre-requisite a pre-existing RPL Instance As a prerequisite, this specification expects a pre-existing RPL Instance
with an associated DODAG and RPL Root, which are referred to as main Instance with an associated DODAG and RPL Root, which are referred to as the main Inst
, ance,
main DODAG and main Root respectively. The main Instance is operated in RPL main DODAG, and main Root, respectively. The main Instance is operated in RPL
Non-Storing Mode of Operation (MOP). Non-Storing Mode of Operation (MOP).
</t> </t>
<t> <t>
With this specification, an abstract routing function called a Path With this specification, an abstract routing function called a Path
Computation Element (PCE) (e.g., located in a central Computation Element (PCE) (e.g., located in a central
controller or collocated with the main Root) interacts with the main Root to 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 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 the Mode, the base topological information to be passed to the PCE, i.e., the
knowledge of the main DODAG, is already available at the Root. knowledge of the main DODAG, is already available at the Root.
This specification introduces protocol extensions that enrich the topological This specification introduces protocol extensions that enrich the topological
information available to the Root with sibling relationships that are usable information available to the Root with sibling relationships that are usable
but not leveraged to form the main DODAG. but not leveraged to form the main DODAG.
</t> </t>
<t> <t>
Based on usage, path length, and knowledge of available resources such as Based on usage, path length, and knowledge of available resources such as
battery levels and reservable buffers in the nodes, the PCE with a global battery levels and reservable buffers in the nodes, the PCE, which has a glob
visibility of the system can optimize the computed routes for the al visibility of the system, can optimize the computed routes for
application needs, including the capability to provide path redundancy. application needs, including the capability to provide path redundancy.
This specification also introduces protocol extensions that enable the This specification also introduces protocol extensions that enable the
Root to project (i.e., advertise from a remote location) the computed Root to project (i.e., advertise from a remote location) the computed
paths in the RPL domain as paths in the RPL domain as
Projected Routes (a.k.a. P-Routes) on behalf of the PCE. Projected Routes (a.k.a. P-Routes) on behalf of the PCE.
</t> </t>
<t> <t>
A P-Route may be installed in either Storing or Non-Storing Mode, A P-Route may be installed in either Storing or Non-Storing Mode,
potentially resulting in hybrid situations where the Mode in which potentially resulting in hybrid situations where the Mode in which
the P-Route operates is different from that of the RPL main Instance. 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 P-Routes can be used as stand-alone segments meant to reduce the size of the
source routing headers, leveraging loose source routing operations down the Source Routing Headers (SRHs), leveraging loose source routing operations do wn the
main RPL DODAG. main RPL DODAG.
A P-Route can also be used as a protection path, and it can be combined and interleaved with 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 called a Track. other P-Routes to form a recovery graph called a Track.
A Track is signaled as a separate RPL Instance that is associated with A Track is signaled as a separate RPL Instance that is associated with
a main RPL Instance, such that the RPL routers that form the Track a main RPL Instance such that the RPL routers that form the Track
are also members of the main DODAG. are also members of the main DODAG.
The Track provides underlay shortcuts using its own RIB, that The Track provides underlay shortcuts using its own RIB, which
is separate from the RIB of the main Instance and has a higher precedence. is separate from the RIB of the main Instance and has a higher precedence.
</t> </t>
</section> </section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section><name>Terminology</name> <section><name>Terminology</name>
<section anchor='bcp'><name>Requirements Language</name> <section anchor='bcp'><name>Requirements Language</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</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 "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<t> <t>
In addition, the terms "Extends" and "Amends" are used as per
<xref section="3" sectionFormat="comma" target="I-D.kuehlewind-rswg-updates-ta
g" />.</t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", </section>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <!-- [rfced] Section 2.2 is titled "References". This may cause
"OPTIONAL" in this document are to be interpreted as described in BCP 14 confusion with Section 13, which is also titled "References".
<xref target='RFC2119'/><xref target='RFC8174'/> when, and only when, they Would you like to title Section 2.2 as "Terms and Concepts" or
appear in all capitals, as shown here. other for clarity?
</t> Original:
2.2 References
<t> Perhaps:
In addition, the terms "Extends" and "Amends" are used as per 2.2 Terms and Concepts
<xref target="I-D.kuehlewind-update-tag" /> section 3. -->
</t> <section anchor='lo'><name>References</name>
<t>
</section> <!-- end section "Requirements Language" --> <!-- [rfced] To improve readability, may we update this text to be an
unordered list?
<section anchor='lo'><name>References</name> Original:
<t> In this document, readers will encounter terms and concepts that are
In this document, readers will encounter terms and concepts discussed in the "Routing Protocol for Low Power and Lossy Networks"
that are discussed in the <xref target='RFC6550'>"Routing Protocol for Lo [RPL], the "6TiSCH Architecture" [RFC9030], the "Deterministic
w Power and Lossy Networks"</xref>, the <xref target='RFC9030'> "6TiSCH Architec Networking Architecture" [RFC8655], the "Using RPI Option Type,
ture"</xref>, the <xref target='RFC8655'> Routing Header for Source Routes, and IP-in-IP Encapsulation in the
"Deterministic Networking Architecture"</xref>, the <xref target='RFC9008'> RPL Data Plane" [RFC9008], the "Reliable and Available Wireless (RAW)
"Using RPI Option Type, Routing Header for Source Routes, and IP-in-IP Architecture" [RAW-ARCHI], and "Terminology in Low power And Lossy
Encapsulation in the RPL Data Plane"</xref>, Networks" [RFC7102].
the <xref target='I-D.ietf-raw-architecture'>"Reliable and
Available Wireless (RAW) Architecture"</xref>,
and
<xref target='RFC7102'>"Terminology in Low power And Lossy Networks"</xref>.
The 6TiSCH and DetNet/RAW architectures utilize the terms "Track" and Perhaps:
"Recovery Graph" to represent the same concept though in different environme In this document, readers will encounter terms and concepts that are
nts. discussed in the following:
This document uses "Track" to represent that concept, and only builds
* "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 Ti
me-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 E
ncapsulation in the RPL Data Plane" <xref target='RFC9008'></xref>; "Reliable an
d Available Wireless (RAW) Architecture" <xref target='RFC9912'></xref>; and
"Terms Used in Routing for Low-Power and Lossy Networks" <xref target='RFC71
02'></xref>.
The 6TiSCH, Deterministic Networking (DetNet), and RAW architectures utilize
the terms "Track" and "recovery graph" to represent the same concept even th
ough they are in different environments.
This document uses "Track" to represent that concept and only builds
Tracks that are DODAGs, meaning that all links are oriented from Ingress to Egress. Tracks that are DODAGs, meaning that all links are oriented from Ingress to Egress.
This specification also utilizes the terms segment and protection path that This specification also utilizes the terms "segment" and "protection path",
are also which are also
defined in the RAW Architecture. defined in the RAW architecture.
</t> </t>
<t> <t>
As opposed to routing trees, RPL DODAGs are typically constructed As opposed to routing trees, RPL DODAGs are typically constructed
to provide redundancy and dynamically adapt the forwarding operation to the to provide redundancy and dynamically adapt the forwarding operation to the
state of the LLN links. Note that the plain forwarding operation over DODAGs state of the Low-Power and Lossy Network (LLN) links. Note that the plain fo rwarding operation over DODAGs
does not provide redundancy for all nodes, since at least the node nearest does not provide redundancy for all nodes, since at least the node nearest
to the Root does not have an alternate feasible successor. to the Root does not have an alternate feasible successor.
</t> </t>
<t> <t>
RAW solves that problem by defining Protection Paths that can be interleaved RAW solves that problem by defining protection paths that can be interleaved
to form new paths that can be activated dynamically upon failures. This requ to form new paths that can be activated dynamically upon failures.
ires
<!-- [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 additional control to take the routing decision early enough along the Track
to route around the failure. to route around the failure.
</t> </t>
<t> <t>
RAW only uses single-ended DODAGs, meaning that they can be reversed in 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 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. 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 From the RAW perspective, single-ended DODAGs are special Tracks that only
have forward links, and that can be leveraged to provide Protection have forward links, and that can be leveraged to provide protection
services by defining destination-oriented Protection Paths within the DODAG. services by defining destination-oriented protection paths within the DODAG.
</t> </t>
</section> <!-- end section "References" --> </section>
<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.
-->
-&gt;
<section anchor='gloss'><name>Glossary</name>
<t> This document often uses the following abbreviations: <t> This document often uses the following abbreviations:
</t><dl spacing='compact'> </t>
<dt>6LR:</dt><dd> 6LoWPAN Router , e.g., a RPL router in an LLN </dd> <dl spacing='normal' newline="false" indent="13">
<dt>6LR:</dt><dd> 6LoWPAN Router (e.g., a RPL router in an LLN)</dd>
<dt>6LoRH:</dt><dd> 6LoWPAN Routing Header</dd> <dt>6LoRH:</dt><dd> 6LoWPAN Routing Header</dd>
<dt>ARQ:</dt><dd>Automatic Repeat Request, in other words retries</dd> <dt>ARQ:</dt><dd>Automatic Repeat Request (in other words, retries)</dd>
<dt>FEC:</dt><dd>Forward Error Correction</dd> <dt>FEC:</dt><dd>Forward Error Correction</dd>
<dt>HARQ:</dt><dd> Hybrid Automatic Repeat Request, combining FEC and ARQ </dd> <dt>HARQ:</dt><dd> Hybrid Automatic Repeat Request (combines FEC and ARQ) </dd>
<dt>CMO:</dt><dd>Control Message Option</dd> <dt>CMO:</dt><dd>Control Message Option</dd>
<dt>DAO:</dt><dd>Destination Advertisement Object</dd> <dt>DAO:</dt><dd>Destination Advertisement Object</dd>
<dt>DAG:</dt><dd>Directed Acyclic Graph</dd> <dt>DAG:</dt><dd>Directed Acyclic Graph</dd>
<dt>DODAG:</dt><dd>Destination-Oriented Directed Acyclic Graph; A DAG <dt>DODAG:</dt><dd>Destination-Oriented Directed Acyclic Graph. A DAG
with only one vertex (i.e., node) that has no outgoing edge (i.e., link)< with only one vertex (i.e., node) that has no outgoing edge (i.e., link).
/dd> </dd>
<dt>GUA:</dt><dd>IPv6 Global Unicast Address</dd> <dt>GUA:</dt><dd>Global Unicast Address</dd>
<dt>LLN:</dt><dd>Low-Power and Lossy Network</dd> <dt>LLN:</dt><dd>Low-Power and Lossy Network</dd>
<dt>MOP:</dt><dd>RPL Mode of Operation</dd> <dt>MOP:</dt><dd>Mode of Operation</dd>
<dt>P-DAO:</dt><dd>Projected DAO </dd> <dt>P-DAO:</dt><dd>Projected DAO </dd>
<dt>P-Route:</dt><dd>Projected Route</dd> <dt>P-Route:</dt><dd>Projected Route</dd>
<dt>PDR:</dt><dd>P-DAO Request</dd> <dt>PDR:</dt><dd>P-DAO Request</dd>
<dt>PCE:</dt><dd>Path Computation Element</dd> <dt>PCE:</dt><dd>Path Computation Element</dd>
<dt>PLR:</dt><dd>Point of Local Repair</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>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>RAL:</dt><dd>RPL-Aware Leaf</dd>
<dt>RH:</dt><dd>Routing Header</dd> <dt>RH:</dt><dd>Routing Header</dd>
<dt>RIB:</dt><dd>Routing Information Base, i.e., the routing table. </dd> <dt>RIB:</dt><dd>Routing Information Base (i.e., the routing table) </dd>
<dt>RPI:</dt><dd>RPL Packet Information</dd> <dt>RPI:</dt><dd>RPL Packet Information</dd>
<dt>RPL:</dt><dd>IPv6 Routing Protocol for Low-Power and Lossy Networks < /dd> <dt>RPL:</dt><dd>Routing Protocol for Low-Power and Lossy Networks </dd>
<dt>RTO:</dt><dd>RPL Target Option</dd> <dt>RTO:</dt><dd>RPL Target Option</dd>
<dt>RUL:</dt><dd>RPL-Unaware Leaf</dd> <dt>RUL:</dt><dd>RPL-Unaware Leaf</dd>
<dt>SIO:</dt><dd>RPL Sibling Information Option</dd> <dt>SIO:</dt><dd>Sibling Information Option</dd>
<dt>ULA:</dt><dd>IPv6 Unique Local Address</dd> <dt>ULA:</dt><dd>Unique Local Address</dd>
<dt>NSM-VIO:</dt><dd>A Source-Routed Via Information Option, used in Non- <dt>NSM-VIO:</dt><dd> Non-Storing Mode Via Information Option. Source-rou
Storing Mode P-DAO messages</dd> ted VIO used in Non-Storing Mode P-DAO messages.</dd>
<!-- <!--
<dt>SubDAG:</dt><dd> A DODAG Rooted at a node which is a child of that <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> --> node and a subset of a larger DAG</dd> -->
<dt>SLO:</dt><dd>Service Level Objective</dd> <dt>SLO:</dt><dd>Service Level Objective</dd>
<dt>SRH:</dt><dd>Source Routing Header, i.e., the IPv6 RH type 3, see <xr <dt>SRH:</dt><dd>Source Routing Header (i.e., IPv6 RH type 3); see <xref
ef target="SRSRH"/></dd> target="SRSRH"/>.</dd>
<dt>SRH-6loRH:</dt><dd> Source Routing Header 6LoRH, a compressed form of <dt>SRH-6LoRH:</dt><dd>Source Routing Header 6LoRH. A compressed form of
SRH defined in <xref target='RFC8138'> SRH defined in "<xref format="title" target='RFC8138'/>" <xref target="RFC8138"/
" IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Heade >. </dd>
r"</xref> </dd> <dt>TIO:</dt><dd>Transit Information Option</dd>
<dt>TIO:</dt><dd>RPL Transit Information Option</dd> <dt>SM-VIO:</dt><dd>Storing Mode Via Information Option. Strict VIO used
<dt>SM-VIO:</dt><dd>A strict Via Information Option, used in Storing Mode in Storing Mode P-DAO messages.</dd>
P-DAO messages</dd> <dt>VIO:</dt><dd>Via Information Option. It can be an SM-VIO or NSM-VIO.<
<dt>VIO:</dt><dd>A Via Information Option; it can be an SM-VIO or a NSM-V /dd>
IO</dd>
</dl> </dl>
</section> <!-- Glossary --> </section>
<section anchor='new'><name>Domain Terms</name> <section anchor='new'><name>Domain Terms</name>
<t> <t>
<!-- Removed reference from routing and 6tisch here to keep it simple --> <!-- Removed reference from routing and 6tisch here to keep it simple -->
This specification uses the following terminology: This specification uses the terminology defined in the sections that fol low.
</t> </t>
<section><name>Projected Route</name><t> <section><name>Projected Route</name><t>
A RPL P-Route is a RPL route that is computed remotely by a PCE, and A RPL P-Route is a RPL route that is computed remotely by a PCE and
installed and maintained by a RPL Root on behalf of the PCE. It 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) is installed as a state that signals that destinations (i.e., Targets)
are reachable via or along a sequence of nodes.</t> are reachable via or along a sequence of nodes.</t>
</section> </section>
<section><name>Projected DAO</name> <section><name>Projected DAO</name>
<t> A DAO message used to install a P-Route. </t> <t>A Projected DAO (P-DAO) is a DAO message that is used to install a P-Rout e. </t>
</section> </section>
<section><name>Path</name> <section><name>Path</name>
<t>Quoting (non-normatively) section 1.1.3 of <xref target="RFC1122"/>:</t> <t>Quoting (non-normatively) the definition of path in <xref target="RFC1122 " section="1.3.3"/>:</t>
<blockquote> <blockquote>
At a given moment, all the IP datagrams from a particular source host to a 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 particular destination host will typically traverse the same sequence of
gateways. We use the term "path" for this sequence. Note that a path is 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 uni-directional; it is not unusual to have different paths in the two
directions between a given host pair. directions between a given host pair.
</blockquote> </blockquote>
<t> <t>
Section 2 of <xref target="I-D.irtf-panrg-path-properties"/> points to a lon <xref section="2" target="RFC9473"/> points to a longer, more modern definit
ger, more modern definition of path, which begins as follows:</t> ion of path:</t>
<blockquote>
<!-- [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 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:
| 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 A sequence of adjacent path elements over which a packet can
be transmitted, starting and ending with a node. A path is be transmitted, starting and ending with a node. A path is
unidirectional. Paths are time-dependent, i.e., the sequence of unidirectional. Paths are time-dependent, i.e., the sequence of
path elements over which packets are sent from one node to another path elements over which packets are sent from one node to another
may change. A path is defined between two nodes. may change. A path is defined between two nodes.
</blockquote> </blockquote>
<t> <t>
It follows that the general acceptance of a path is a linear sequence of 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 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 document, a path is observed by following one copy of a packet that is
injected in a Track and possibly replicated within. injected in a Track and possibly replicated within.
</t> </t>
</section> </section>
<section><name>Routing Stretch</name> <section><name>Routing Stretch</name>
<t> <t>
RPL is anisotropic, meaning that it is directional, or more exactly polar. RPL is anisotropic, meaning that it is directional or, more precisely, polar
RPL does not behave the same way "downwards" (root towards leaves) with <em> .
multicast</em> DIO messages that
<!--[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 _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. 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 This is in contrast with traditional IGPs that operate the same way in all
directions and are thus called isotropic. directions and are thus called isotropic.
</t> </t>
<t>The term Routing Stretch denotes the length of a path, in comparison to the length of the <t>The term "routing stretch" denotes the length of a path, in comparison to t he length of the
shortest path, which can be an abstract concept in RPL when the metrics are 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 Objecti ve statistical and dynamic, and the concept of distance varies with the Objecti ve
Function. Function.
</t> </t>
<t> <t>
The RPL DODAG optimizes the P2MP (Point-to-Multipoint) (from the Root) and M The RPL DODAG optimizes Point-to-Multipoint (P2MP) paths (from the Root) and
P2P (Multipoint-to-Point) (towards the Root) paths, but Multipoint-to-Point (MP2P) paths (towards the Root), but
the P2P (Point-to-Point) traffic has to follow the same DODAG. Following the the 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 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 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 more latency than the minimum possible for a directional (i.e., forward) P2P path that an
isotropic protocol would compute. isotropic protocol would compute.
We refer to this elongated path as stretched. We refer to this elongated path as stretched.
</t> </t>
</section> </section>
<section><name>Track</name> <section><name>Track</name>
<t> <t>
The concept of Track is inherited from the <xref target='RFC9030'> The concept of Track is inherited from the
"6TiSCH Architecture"</xref> and matches that of a Protection Path in the 6TiSCH architecture <xref target='RFC9030'></xref> and matches that of a pro
<xref target='I-D.ietf-raw-architecture'> RAW Architecture"</xref>. A Track tection path in the
RAW architecture <xref target='RFC9912'></xref>. A Track
is a networking graph that can be followed to transport packets with is a networking graph that can be followed to transport packets with
equivalent treatment; as opposed to the definition of a path above, equivalent treatment; as opposed to the definition of a path above,
a Track is not necessarily linear. It may contain multiple paths that a Track is not necessarily linear. It may contain multiple paths that
may fork and rejoin, and may enable the RAW Packet ARQ, Replication, may fork and rejoin and that may enable RAW Packet ARQ, Replication,
Elimination, and Overhearing (PAREO) operations. Elimination, and Overhearing (PAREO) operations.
</t> </t>
<t> <t>
<xref target='TRK'/> illustrates the mapping of the DODAG with the <xref target='TRK'/> illustrates the mapping of the DODAG with the
generic concept of a Track, with the DODAG Root acting as Ingress 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 only fo for the Track, and the mapping of protection paths and segments, i.e., only
rward forward
segments, meaning that they are directional and progressing towards the segments, meaning that they are directional and progressing towards the
destination. Note that East is represented on the left since the destination. Note that East is represented on the left since the
packets are forwarded East-West. packets are forwarded East-West.
</t> </t>
<figure anchor='TRK'><name>A Track and its Components</name>
<artwork align="center"><![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 <!--[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.
-->
I ==> A ==> B ==> C : a Segment to targets F and O <figure anchor='TRK'><name>A Track and Its Components</name>
<artwork ><![CDATA[
North East North West
I --> F --> E : a protection path to targets T1, T2, T3 A ==> B ==> C -=- F ==> G ==> H T1
/ \ / \ /
I O E -=- T2
\ / \ / \
P ==> Q ==> R -=- T ==> U ==> V T3
I, A, B, C, F, G, H, E : a path to T1, T2, T3 South East South West
I: Ingress
E: Egress
T1, T2, T3: external targets
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Of note:</t>
<dl newline="false" spacing="normal">
<dt>I ==> A ==> B ==> C:</dt><dd>A segment to targets F and O</dd>
<dt>I --> F --> E:</dt><dd>A protection path to targets T1, T2, T3</dd>
<dt>I, A, B, C, F, G, H, E:</dt><dd>A path to T1, T2, T3</dd>
</dl>
<t> <t>
This specification builds Tracks that are DODAGs oriented towards a Track This specification builds Tracks that are DODAGs oriented towards a Track
Ingress, and the forward direction for packets is from the Ingress, and the forward direction for packets is from the
Track Ingress to one of the possibly multiple Track Egress Nodes, which is Track Ingress to one of the possible multiple Track Egress Nodes, which is
also down the DODAG. also down the DODAG.
</t> </t>
<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 th at are associated to the same Track. The Track may be strictly connected, meaning that the vertices are adjacent, or loosely connected, meaning that the vertices are connected using segments th at are associated to the same Track.
</t> </t>
<section><name>TrackID</name> <section><name>TrackID</name>
<t> <t>
A RPL InstanceID (typically of a Local Instance) that identifies a Track A RPLInstanceID (typically of a Local Instance) identifies a Track
using the namespace owned by the Track Ingress. For Local Instances, using the namespace owned by the Track Ingress. For Local Instances,
the TrackID is associated with the IPv6 Address of the Track Ingress that is the TrackID is associated with the IPv6 address of the Track Ingress that is
used as DODAGID, and together they form a unique identification of the Track used as the DODAGID, and together they form a unique identification of the T
(see the definition of DODAGID in section 2 of <xref target='RFC6550'/>. rack
(see the definition of DODAGID in <xref target='RFC6550' section="2"/>).
</t> </t>
</section> </section>
<section><name>Namespace</name> <section><name>Namespace</name>
<t> <t>
The term namespace is used to refer to the scope of the TrackID. The term "namespace" is used to refer to the scope of the TrackID.
The TrackID is locally significant within its namespace. The TrackID is locally significant within its namespace.
For Local Instances, the namespace is identified by the DODAGID for the For Local Instances, the namespace is identified by the DODAGID for the
Track and the tuple (DODAGID, TrackID) is globally unique. For Global Track, and the tuple (DODAGID, TrackID) is globally unique. For Global
Instances, the namespace is the whole RPL domain. Instances, the namespace is the whole RPL domain.
</t> </t>
</section> </section>
<section><name>Complex Track</name> <section><name>Complex Track</name>
<t>A Track that can be traversed via more than one path (e.g., a DODAG). <t>A complex Track is a Track that can be traversed via more than one path ( e.g., a DODAG).
</t> </t>
</section> </section>
<section><name>Stand-Alone</name> <section><name>Stand Alone</name>
<t> <t>
Refers to a segment or a protection path that is installed with a single P-D AO that 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 fully defines the path, e.g., a stand-alone segment is installed
with a single Storing Mode Via Information option (SM-VIO) all the way with a single Storing Mode Via Information Option (SM-VIO) all the way
between Ingress and Egress. between the Ingress and Egress.
</t> </t>
</section> </section>
<section><name>Stitching</name> <section><name>Stitching</name>
<t> <t>
This specification uses the term stitching to indicate that a track is This specification uses the term "stitching" to indicate that a Track is
piped to another one, meaning that traffic out of the first track is injecte piped to another one, meaning that traffic out of the first Track is injecte
d into d into
the other track. the other Track.
</t> </t>
</section> </section>
<section><name>Protection Path</name> <section><name>Protection Path</name>
<t> The concept of protection path is defined in the <t> The concept of protection path is defined in the
<xref target='I-D.ietf-raw-architecture'> RAW Architecture"</xref> RAW architecture <xref target='RFC9912'></xref>
as an end-to-end forward serial path. as an end-to-end forward serial path.
With this specification, a protection path is installed by the Root of the m ain With this specification, a protection path is installed by the Root of the m ain
DODAG using a Non-Storing Mode P-DAO message, e.g., DODAG using a Non-Storing Mode P-DAO message, e.g.,
I --> F --> E in <xref target="TRK"/>. I --> F --> E in <xref target="TRK"/>.
</t> <t> </t> <t>
As the Non-Storing Mode Via Information option (NSM-VIO) can only signal As the Non-Storing Mode Via Information Option (NSM-VIO) can only signal
sequences of nodes, it takes one Non-Storing Mode P-DAO message per protecti on path to sequences of nodes, it takes one Non-Storing Mode P-DAO message per protecti on path to
signal the structure of a complex Track. signal the structure of a complex Track.
</t> <t> </t> <t>
Each NSM-VIO for the same Each NSM-VIO for the same
TrackID but with a different Segment ID signals a different protection path that the TrackID but with a different Segment ID signals a different protection path that the
Track Ingress adds to the topology. Track Ingress adds to the topology.
</t> </t>
</section> </section>
<section><name>Segment</name> <section><name>Segment</name>
<t> <t>
A serial path formed by a strict sequence of nodes, along which a P-Route is A segment is a serial path formed by a strict sequence of nodes along which a P-Route is
installed, e.g., installed, e.g.,
I ==> A ==> B ==> C in <xref target="TRK"/>. I ==> A ==> B ==> C in <xref target="TRK"/>.
With this specification, a segment is typically installed by the Root of the 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 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 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 form the structure of a complex Track. The same segment may be leveraged by
more than one protection path where the protection paths overlap. more than one protection path where the protection paths overlap.
</t> <t> </t> <t>
Since this specification builds only DODAGs, Since this specification builds only DODAGs,
all segments are oriented from Ingress (East) to Egress (West), as opposed all segments are oriented from the Ingress (East) to Egress (West), as oppos
to the general Track model in the <xref target='I-D.ietf-raw-architecture'> ed
RAW Architecture</xref>, which allows North/South segments that can be to the general Track model in the RAW architecture <xref target='RFC9912'/>,
which allows North/South segments that can be
bidirectional as well. bidirectional as well.
</t> </t>
<section><name>Section of a Segment</name> <section><name>Section of a Segment</name>
<t> <t>
A continuous subset of a segment that may be replaced while the segment The section of a segment refers to a continuous subset of a segment that may
remains. For instance, in segment A=>B=>C=>D=>E=>F, say that the link C to 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 D might be misbehaving. The section B=>C=>D=>E in the segment may be
replaced by B=>C’=>D’=>E to route around the problem. The segment becomes replaced by 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> </t>
</section> </section>
<section anchor='SRSRH'><name>Segment Routing and SRH</name> <section anchor='SRSRH'><name>Segment Routing and SRH</name>
<t> <t>
In a Non-Storing mode RPL domain, the IPv6 RH used for source-routing In a Non-Storing Mode RPL domain, the IPv6 RH used for source routing
is the (RPL) SRH as defined in <xref target='RFC6554'/>. is the (RPL) SRH as defined in <xref target='RFC6554'/>.
This specification operates in that context and uses the acronym SRH This specification operates in that context and uses the acronym SRH
to mean the IPv6 RH type 3 as opposed to the IPv6 RH type 4 defined to mean IPv6 RH type 3, as opposed to IPv6 RH type 4 defined
in <xref target='RFC8754'/> for the Segment Routing (SRv6) operation. in <xref target='RFC8754'/> for Segment Routing over IPv6 (SRv6) operation.
</t> </t>
<t> <t>
If the network is a 6LoWPAN Network, the expectation is that the If the network is a 6LoWPAN network, the expectation is that the
SRH is compressed and encoded as a 6LoWPAN Routing Header (6LoRH), as SRH is compressed and encoded as a 6LoWPAN Routing Header (6LoRH), as
specified in section 5 of <xref target='RFC8138'/>. specified in <xref target='RFC8138' section="5"/>.
</t> </t>
<t> <t>
This specification uses the term "Segment Routing" generically, to This specification uses the term "Segment Routing" generically to
refer to using source-routing to hop over segments. As such, refer to using source routing to hop over segments. As such,
forwarding along segments as specified hereafter can be seen as a forwarding along segments as specified hereafter can be seen as a
form of Segment Routing <xref target='RFC8402'/>, but leveraging the form of Segment Routing <xref target='RFC8402'/> that leverages the
(RPL) SRH for its operation. (RPL) SRH for its operation.
</t> </t>
<t> <t>
Outside of LLNs, the RPL Network may be less constrained and operated Outside of LLNs, the RPL network may be less constrained and operated
in Storing Mode, as discussed in <xref target='smmd'/>. In that case, in Storing Mode, as discussed in <xref target='smmd'/>. In that case,
this specification could be extended to accommodate the SRv6 RH. this specification could be extended to accommodate the SRv6 RH.
</t> </t>
</section> <!-- end section "Segment Routing and SRH" -->
</section> <!-- Segment -->
</section> </section>
</section> <!-- end section "Domain Terms" --> </section>
</section>
</section>
</section> <!-- end section "Terminology" --> </section>
<section anchor='context'><name>Context and Goal</name> <section anchor='context'><name>Context and Goal</name>
<section anchor='onrpl'><name>RPL Applicability</name> <section anchor='onrpl'><name>RPL Applicability</name>
<t> <t>
RPL is optimized for situations where the power is scarce, the bandwidth is RPL is optimized for situations where the power is scarce, the bandwidth is
constrained and the transmissions are unreliable. This matches the use case o constrained, and the transmissions are unreliable. This matches the use case
f of
an IoT LLN where RPL is typically used today, but also situations of high rel an IoT LLN where RPL is typically used today and also situations of high rela
ative tive
mobility between the nodes in the network (a.k.a. swarming), e.g., mobility between the nodes in the network (a.k.a. swarming), e.g.,
within a variable set of vehicles with a similar global motion, or a platoon of within a variable set of vehicles with a similar global motion or a platoon o f
drones. drones.
In contrast, this specification only applies when the platoon has a relativel y stable In contrast, this specification only applies when the platoon has a relativel y stable
topology where the segments can be attributed a reliability and availability topology where the segments can be attributed reliability and availability
for a certain lifetime, see <xref target='I-D.ietf-raw-architecture'/>. for a certain lifetime; see <xref target='RFC9912'/>.
</t><t> </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 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 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 traffic, and the amount of state that is maintained in each node. RPL does
not need to converge, and provides connectivity to most nodes most of the tim e. not need to converge, and it provides connectivity to most nodes most of the time.
</t><t> </t><t>
RPL may form multiple topologies called instances. Instances can be RPL may form multiple topologies called instances. Instances can be
created to enforce various optimizations through objective functions, created to enforce various optimizations through objective functions
or to reach out through different Root Nodes. The concept of objective or to reach out through different Root Nodes. The concept of objective
function allows to adapt the activity of the routing protocol to the use function allows adapting the activity of the routing protocol to the use
case, e.g., type, speed, and quality of the LLN links. case, e.g., type, speed, and quality of the LLN links.
</t><t> </t><t>
RPL instances operate in parallel, unaware of one another. Yet, RPL instances operate in parallel, unaware of one another. Yet,
it is possible to define a model whereby if a route cannot be found 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 in the current instance A where a packet is being forwarded, then
the router may lookup the routing table (RIB) in an instance B and the router may look up the routing table (i.e., the RIB) in instance B and
forward along instance B if the route is found there. forward along instance B if the route is found there.
To avoid loops, this must happen in such a way that the instances To avoid loops, this must happen in such a way that the instances
themselves form a directed acyclic graph (DAG) leading to the last themselves form a Directed Acyclic Graph (DAG) leading to the last
resort instance that is the "lowest" instance if instance A is considered resort instance, which is the "lowest" instance if instance A is considered
"higher" then instance B. This specification uses underlay Tracks as "higher" then instance B. This specification uses underlay Tracks as
"lower" instances, the main instance being the "highest" of all. "lower" instances, with the main instance being the "highest" of all.
</t><t> </t><t>
The RPL Root is responsible for selecting the RPL Instance that is used The RPL Root is responsible for selecting the RPL Instance that is used
to forward a packet coming from the Backbone into the RPL domain and for set ting to forward a packet coming from the backbone into the RPL domain and for set ting
the related RPL information in the packets. Each Instance creates its own the related RPL information in the packets. Each Instance creates its own
routing table (RIB) in participating nodes, and the RIB associated to the in routing table (i.e., a RIB) in participating nodes, and the RIB associated t
stance must be used end to end in the RPL domain. To that effect, RPL o 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. tags the packets with the Instance ID in a Hop-by-Hop extension header.
6TiSCH leverages RPL for its distributed routing operations. 6TiSCH leverages RPL for its distributed routing operations.
</t><t> </t><t>
To reduce the routing exchanges, RPL leverages an anisotropic Distance Vector To reduce the routing exchanges, RPL leverages an anisotropic Distance Vector
approach, which does not need a global knowledge of the topology, and only approach, which does not need global knowledge of the topology and only
optimizes the routes to and from the RPL Root, allowing P2P paths to be optimizes the routes to and from the RPL Root, allowing P2P paths to be
stretched. Although RPL installs its routes proactively, it only maintains stretched. Although RPL installs its routes proactively, it only maintains
them lazily, in reaction to actual traffic, or as a slow background activity. them lazily, in reaction to actual traffic or as a slow background activity.
</t><t> </t><t>
This is simple and efficient in situations where the traffic is mostly 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 directed from or to a central node, such as the control traffic between
routers and a controller of a Software Defined Networking (SDN) infrastructur e or an Autonomic Control Plane (ACP). routers and a controller of a Software-Defined Networking (SDN) infrastructur e or an Autonomic Control Plane (ACP).
</t><t> </t><t>
But stretch in P2P routing is counter-productive to both reliability and 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, 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 <xref target='RFC6550'/> is not a good fit for the use cases listed in the
RAW use cases document <xref target='RFC9450'/>, which demand RAW use cases document <xref target='RFC9450'/>, which demand
high availability and reliability, and as a consequence require both short high availability and reliability and, as a consequence, require both short
and diverse paths. and diverse paths.
</t> </t>
</section> <!-- end section "RPL Applicability" --> </section>
<section anchor='onrplroute'><name>Multi-Topology Routing and Loop Avoidance</na me> <section anchor='onrplroute'><name>Multi-Topology Routing and Loop Avoidance</na me>
<t> <t>
RPL first forms a default route in each node towards the Root, and those RPL first forms a default route in each node towards the Root, and those
routes together coalesce as a Directed Acyclic Graph oriented upwards. routes together coalesce as a DAG oriented upwards.
RPL then constructs routes to destinations signaled as Targets in the reverse direction, 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 RPL down the same DODAG. To do so, a RPL Instance can be operated in either RPL
Storing or Non-Storing Mode of Operation (MOP). 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. 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>
<t>In Non-Storing Mode, each node advertises itself as a Target directly to the <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, t he Root, indicating the parents that may be used to reach itself. Recursively, t he
Root builds and maintains an image of the whole DODAG in memory, and Root builds and maintains an image of the whole DODAG in memory and
leverages that abstraction to compute source route paths for the packets to leverages that abstraction to compute source route paths for the packets to
their destinations down the DODAG. When a node changes its point(s) 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 alon g of attachment to the DODAG, it takes a single unicast packet to the Root alon g
the default route to update it, and the connectivity to the node is restored the default route to update it, and the connectivity to the node is restored
immediately; immediately;
this mode is preferable for use cases where internet connectivity is this mode is preferable for use cases where internet connectivity is
dominant, or when the Root controls the network activity in the dominant or when the Root controls the network activity in the
nodes, which is the case of this specification. nodes, which is the case in this specification.
</t> </t>
<t> <t>
In Storing Mode, the routing information percolates upwards, and each In Storing Mode, the routing information percolates upwards, and each
node maintains the routes to the subDAG of its descendants down the node maintains the routes to the subDAG of its descendants down the
DODAG. The maintenance is lazy, either reactive upon traffic or as a 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 slow background process. Packets flow via the common parent and the
routing stretch is reduced compared to Non-Storing MOP, for better P2P routing stretch is reduced, compared to the Non-Storing MOP, for better P2P
connectivity. However, a new route takes a longer time to connectivity. However, a new route takes a longer time to
propagate to the Root, since it takes time for the Distance-Vector protocol t propagate to the Root, since it takes time for the Distance Vector protocol t
o o
operate hop-by-hop, and the connectivity from the internet to the node is operate hop by hop, and the connectivity from the Internet to the node is
restored more slowly upon node movement. restored more slowly upon node movement.
</t> </t>
<t> <t>
Either way, the RPL routes are injected by the Target nodes, in a distribute d fashion. To complement RPL and eliminate routing stretch, this specification i ntroduces a hybrid mode that combines Storing and Non-Storing operations to buil d and project routes onto the nodes where they should be installed. This specifi cation uses the term Projected Route (P-Route) to refer to those routes. Either way, the RPL routes are injected by the Target nodes in a distributed fashion. To complement RPL and eliminate routing stretch, this specification in troduces a hybrid mode that combines Storing and Non-Storing operations to build and project routes onto the nodes where they should be installed. This specific ation uses the term "P-Route" to refer to those routes.
</t> </t>
<t> <t>
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 <!--[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 DODAG. In that case, all the routes (source routed and P-Routes) belong to
the Routing Information base (RIB) associated with the main Instance. the Routing Information Base (RIB) associated with the main Instance.
Storing-Mode P-Routes are referred to as segments in this specification. Storing Mode P-Routes are referred to as segments in this specification.
</t> </t>
<t>A set of P-Routes can also be projected to form a dotted-line underlay of the <t>A set of P-Routes can also be projected to form a dotted-line underlay of the
main Instance and provide Traffic Engineered paths for an application. main Instance and provide Traffic-Engineered paths for an application.
In that case, the P-Routes are installed in Non-Storing Mode and the set In that case, the P-Routes are installed in Non-Storing Mode, and the set
of P-Routes is called a Track. of P-Routes is called a Track.
A Track is associated with its own RPL Instance, and, as any RPL Instance, A Track is associated with its own RPL Instance and, as any RPL Instance,
with its own Routing Information base (RIB). As a result, each Track defines with its own RIB. As a result, each Track defines
a routing topology in the RPL domain. As for the main DODAG, segments 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 associated to the Track Instance may be deployed to join the dots using
Storing-Mode P-Routes. Storing Mode P-Routes.
</t> </t>
<t> <t>
Routing in a multi-topology domain may cause loops unless strict rules are Routing in a multi-topology domain may cause loops unless strict rules are
applied. This specification defines two strict orders to ensure loop applied. This specification defines two strict orders to ensure loop
avoidance when projected routes are used in a RPL domain, one between avoidance when P-Routes are used in a RPL domain: one between
forwarding methods and one between RPL Instances, seen as routing topologies. forwarding methods and one between RPL Instances, which are routing topologie
</t> <t> s.
The first and strict order relates to the forwarding method and the more </t>
specifically the origin of the information used in the next-hop computation.
<!-- [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 indire ct The possible forwarding methods are: 1) to a direct next hop, 2) to an indire ct
neighbor via a common neighbor, 3) along a segment, and 4) along a nested Tra ck. neighbor via a common neighbor, 3) along a segment, and 4) along a nested Tra ck.
The methods are strictly ordered as listed above, more in <xref target = "rou The methods are strictly ordered as listed above; see more in <xref target =
ting"/>. "routing"/>.
A forwarding method may leverage any of the lower order ones, but never one A forwarding method may leverage any of the lower-order ones, but never one
with a higher order; for instance, when forwarding a packet along a segment, 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 router may use direct or indirect neighbors but cannot use a Track.
The lower order methods have a strict precedence, so the router will always The lower-order methods have a strict precedence, so the router will always
prefer a direct neighbor over an indirect one, or a segment within the prefer a direct neighbor over an indirect one or a segment within the
current RPL Instance vs. another Track. current RPL Instance over another Track.
</t> <t> </t> <t>
The second strict and partial order is between RPL Instances. It allows the 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 RPL node to detect an error in the state installed by the
PCE, e.g., after a desynchronization. PCE, e.g., after a desynchronization.
That order must be defined by the administrator for the RPL domain and
defines a DODAG of underlays with the main Instance as Root.
<!--[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 The relation of RPL instances may be represented as a DODAG of instances
where the main instance is Root. The rule is that a RPL Instance may leverage where the main instance is the Root. The rule is that a RPL Instance may leve
another RPL instance as underlay if and only if rage
another RPL instance as an underlay if and only if
that other Instance is one of its descendants in the graph. that other Instance is one of its descendants in the graph.
Supporting this method is <bcp14>OPTIONAL</bcp14> for nested Tracks and <bcp1
Supporting this method is OPTIONAL for nested Tracks and REQUIRED between 4>REQUIRED</bcp14> between
a Track instance and the main instance. a Track instance and the main instance.
<!-- The way this graph is communicated to the RPL nodes is out of scope. -- > <!-- The way this graph is communicated to the RPL nodes is out of scope. -- >
It may be done using network management, or future extensions to this It may be done using network management or future extensions to this
specifications. When it is not communicated, then the RPL nodes consider by specifications.
default that all Track instances are children of the main instance, and do no
t <!--[rfced] Please clarify what "it" refers to in "When it is not
communicated".
Original:
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.
-->
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. 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 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 encapsulated in any Track, but a packet that was forwarded along a Track <bcp
NOT be forwarded along the default route of main Instance. 14>MUST
NOT</bcp14> be forwarded along the default route of the main Instance.
</t> </t>
</section> <!-- end section "Multi-Topology Routing and Loop Avoidance" --> </section>
<section><name>Requirements</name> <section><name>Requirements</name>
<section anchor='loose'><name>Loose Source Routing</name> <section anchor='loose'><name>Loose Source Routing</name>
<t>A RPL implementation operating in a very constrained LLN typically u ses <t>A RPL implementation operating in a very constrained LLN typically u ses
the Non-Storing Mode of Operation as represented in <xref target='nost'/>. the Non-Storing Mode of Operation as represented in <xref target='nost'/>.
In that mode, a RPL node indicates a In that mode, a RPL node indicates a
parent-child relationship to the Root, using a destination Advertisement parent-child relationship to the Root, using a Destination Advertisement
Object (DAO) that is unicast from the node directly to the Root, Object (DAO) that is unicast from the node directly to the Root,
and the Root typically builds a source routed path to a destination down and the Root typically builds a source-routed path to a destination down
the DODAG by recursively concatenating this information. the DODAG by recursively concatenating this information.
</t> </t>
<figure anchor='nost'><name>RPL Non-Storing Mode of operation </name> <figure anchor='nost'><name>RPL Non-Storing Mode of Operation </name>
<artwork> <artwork><![CDATA[
+-----+ +-----+
| | Border router | | Border Router
| | (RPL Root) | | (RPL Root)
+-----+ ^ | | +-----+ ^ | |
| | DAO | ACK | | | DAO | ACK |
o o o o | | | Strict o o o o | | | Strict
o o o o o o o o o | | | Source 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 | | | Route
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 | v v o o o o o o o o | v v
o o o o o o o o
LLN LLN]]></artwork>
</artwork>
</figure> </figure>
<t> <t>
Based on the parent-children relationships expressed in the Non- Based on the parent-children relationships expressed in the Non-
Storing DAO messages, the Root possesses topological information Storing DAO messages, the Root possesses topological information
about the whole network, though this information is limited to the about the whole network, though this information is limited to the
structure of the DODAG for which it is the destination. A packet structure of the DODAG for which it is the destination. A packet
that is generated within the domain will always reach the Root, which that is generated within the domain will always reach the Root, which
can then apply a source routing information to reach the destination can then apply source routing information to reach the destination
if the destination is also in the DODAG. Similarly, a packet coming 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 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 be in a RPL domain reaches the Root. This results in the wireless
bandwidth near the Root being the limiting factor for all transmissions 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 towards or within the domain, and the Root is a single point of
failure for all connectivity to nodes within its domain. failure for all connectivity to nodes within its domain.
</t> </t>
<t> <t>
The RPL Root must add a source routing header to all downward packets. 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 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 with the depth of the network. In some use cases, a RPL network forms
long lines along physical structures such as streets for lighting. long lines along physical structures like streets with lighting.
Limiting the packet size is beneficial to the energy budget, directly Limiting the packet size is beneficial to the energy budget, directly
for the current transmission, but also indirectly since it reduces the for the current transmission and also indirectly since it reduces the
chances of frame loss and energy spent in retries, e.g., by ARQ over one hop chances of frame loss and energy spent in retries, e.g., by ARQ over one hop
at Layer-2, or end-to-end at upper layers. at Layer 2 or end to end at upper layers.
Using smaller packets also reduces the chances of Using smaller packets also reduces the chances of
packet fragmentation, which is highly detrimental to the LLN operation, in packet fragmentation, which is highly detrimental to the LLN operation, in
particular when fragments are forwarded but not recovered, see particular when fragments are forwarded but not recovered; see
<xref target="RFC8930"/> vs. <xref target="RFC8931"/> for more. <xref target="RFC8930"/> compared to <xref target="RFC8931"/> for more detail
s.
</t> </t>
<t> <t>
A limited amount of well-targeted routing state would allow the A limited amount of well-targeted routing state would allow the
source routing operation to be loose as opposed to strict, and reduce the source routing operation to be loose as opposed to strict and would reduce th e
overhead of routing information in packets. overhead of routing information in packets.
Because the capability to store routing state in every node Because the capability to store routing state in every node
is limited, the decision of which route is installed where can only is limited, the decision of which route is installed where can only
be optimized with global knowledge of the system, knowledge that be optimized with global knowledge of the system, knowledge that
the Root or an associated PCE may possess by means that are outside the Root or an associated PCE may possess by means that are outside
the scope of this specification. the scope of this specification.
</t> </t>
<t> <t>
Being on-path for all packets in Non-Storing mode, the Root may Being on path for all packets in Non-Storing Mode, the Root may
determine the number of P2P packets in its RPL domain per source and determine the number of P2P packets in its RPL domain per source and
destination, the latency incurred, and the amount of energy and destination, the latency incurred, and the amount of energy and
bandwidth that is consumed to reach itself and then back down, including bandwidth that is consumed to reach itself and then back down, including
possible fragmentation when encapsulating larger packets. Enabling possible fragmentation when encapsulating larger packets. Enabling
a shorter path that would not traverse the Root for select P2P a shorter path that would not traverse the Root for select P2P
source/destinations may improve the latency, lower the consumption of sources/destinations may improve the latency, lower the consumption of
constrained resources, free bandwidth at the bottleneck near the constrained resources, free bandwidth at the bottleneck near the
Root, improve the delivery ratio and reduce the latency for those P2P Root, improve the delivery ratio, and reduce the latency for those P2P
flows with a global benefit for all flows by reducing the load at the flows; this would be a global benefit for all flows by reducing the load at t
he
Root. Root.
</t> </t>
<t> <t>
To limit the need for source route headers in deep networks, one possibili ty To limit the need for source route headers in deep networks, one possibili ty
is to store a routing state associated with the main DODAG in select RPL 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 routers down the path. The Root may elide the sequence of routers
that is installed in the network from its source route header, which there fore that is installed in the network from its source route header, which there fore
becomes loose, in contrast to being strict in <xref target="RFC6550"/>. becomes loose, in contrast to being strict in <xref target="RFC6550"/>.
</t> </t>
</section> <!-- Loose Source Routing --> </section>
<section><name>forward Routes</name> <section><name>Forward Routes</name>
<t> <t>
<xref target="RFC6550"/> optimizes P2MP routes from the Root, MP2P routes <xref target="RFC6550"/> optimizes P2MP routes from the Root, MP2P
towards the routes towards the
Root, and as a consequence routes from/to the outside of the RPL domain wh Root, and routes from/to the outside of the RPL domain when the Root
en the Root also serves as Border Router. also serves as the border router.
All routes are installed North-South (a.k.a. up/down) along the RPL DODAG. All routes are installed North-South (a.k.a. up/down) along the RPL DODAG.
Peer to Peer (P2P) forward routes in a RPL network will generally Peer-to-Peer (P2P) forward routes in a RPL network will generally
experience elongated (stretched) paths versus direct (optimized) experience elongated (stretched) paths rather than direct (optimized)
paths, since routing between two nodes always happens via a common paths, since routing between two nodes always happens via a common
parent, as illustrated in <xref target='stretch'/>: parent, as illustrated in <xref target='stretch'/>:
</t> </t>
<figure anchor='stretch'><name>Routing Stretch between S and D via common <figure anchor='stretch'><name>Routing Stretch Between S and D via Common
parent X along North-South Paths</name> Parent X Along North-South Paths</name>
<artwork> <artwork><![CDATA[
------+--------- ------+---------
| Internet | Internet
+-----+ +-----+
| | Border router | | Border Router
| | (RPL Root) | | (RPL Root)
+-----+ +-----+
X X
^ v o o ^ v o o
^ o o v o o o o o ^ o o v o o o o 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 ^ o o v o o o o o
S o o o D o o o S o o o D o o o
o o o o o o o o
LLN LLN]]></artwork>
</artwork>
</figure> </figure>
<t>As described in <xref target="RFC9008" />, the amount of stretch depends on the Mode of Operation: </t> <t>As described in <xref target="RFC9008" />, the amount of stretch depends on the MOP: </t>
<ul spacing='normal'> <ul spacing='normal'>
<li> in Non-Storing Mode, all packets <li> In Non-Storing Mode, all packets
routed within the DODAG flow all the way up to the Root of the DODAG. If 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 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 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 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. is relatively close to the source and the Root is relatively far off.
</li> </li>
<li>In Storing Mode, unless the destination is a child of the source, <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. 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 If the destination is in the same DODAG, they will eventually reach a
common parent that has a route to the destination; at worse, the common common parent that has a route to the destination; at worst, the common
parent may also be the Root. From that common parent, the packet will 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 follow a path down the DODAG that is optimized for the Objective Function
that was used to build the DODAG.</li> that was used to build the DODAG.</li>
</ul> </ul>
<t> <t>
It turns out that it is often beneficial to enable direct P2P routes, It turns out that it is often beneficial to enable direct P2P routes if
either if the RPL route presents a stretch from the shortest path, or if th either the RPL route presents a stretch from the shortest path or the
e
new route is engineered with a different objective, and this is new route is engineered with a different objective, and this is
even more critical in Non-Storing Mode than it is in Storing Mode, because even more critical in Non-Storing Mode than it is in Storing Mode because
the routing stretch is wider. the routing stretch is wider.
For that reason, earlier work at the IETF introduced the For that reason, earlier work within the IETF was introduced: the
<xref target='RFC6997'>"Reactive Discovery of Point-to-Point Routes in "<xref format="title" target='RFC6997'/>" <xref target="RFC6997"/>, which s
Low Power and Lossy Networks"</xref>, which specifies a distributed method pecifies a distributed method for
for
establishing optimized P2P routes. establishing optimized P2P routes.
This specification proposes an alternative based on centralized This specification proposes an alternative based on centralized
route computation. route computation.
</t> </t>
<figure anchor='opti2'><name>More direct forward Route between S and D</ <figure anchor='opti2'><name>More Direct Forward Route Between S and D</
name> name>
<artwork> <artwork><![CDATA[
+-----+ +-----+
| | Border router | | Border Router
| | (RPL Root) | | (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 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 S>>A>>>B>>C>>>D o o o
o o o o o o o o
LLN LLN]]></artwork>
</artwork>
</figure> </figure>
<t> <t>
The requirement is to install additional routes in the RPL routers, The requirement is to install additional routes in the RPL routers,
to reduce the stretch of some P2P routes and maintain the characteristics to reduce the stretch of some P2P routes and maintain the characteristics
within a given SLO, e.g., in terms of latency and/or reliability. within a given Service Level Objective (SLO), e.g., in terms of latency an d/or reliability.
</t> </t>
</section> </section>
</section> <!-- Requirements --> </section>
<section anchor='tracks'><name>On Tracks</name> <section anchor='tracks'><name>On Tracks</name>
<section anchor='ctracks'><name>Building Tracks with RPL</name> <section anchor='ctracks'><name>Building Tracks with RPL</name>
<t> <t>
The concept of a Track was introduced in the <xref target='RFC9030'> The concept of a Track was introduced in the
"6TiSCH Architecture"</xref>, as a collection of potential paths that 6TiSCH architecture <xref target='RFC9030'></xref> as a collection of potent
ial paths that
leverage redundant forwarding solutions along the way. This can be a leverage redundant forwarding solutions along the way. This can be a
DODAG or a more complex structure that is only partially acyclic DODAG or a more complex structure that is only partially acyclic
(e.g., per packet). (e.g., per packet).
</t> </t>
<t> <t>
With this specification, a Track is shaped as a DODAG, and following the With this specification, a Track is shaped as a DODAG, and following the dir
directed edges leads to a Track Ingress. Storing Mode P-DAO messages follow ected 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 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, other way, towards the Track Egress(es). If there is a single Track Egress,
then the Track is reversible to form another DODAG by reversing the then the Track is reversible so that another DODAG may be formed by reversin g the
direction of each edge. A node at the Ingress of more than one segment in a 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 may use one or more of these segments to forward a packet inside the
Track. Track.
</t> </t>
<t> <t>
A RPL Track is a collection of (one or more) parallel loose source routed A RPL Track is a collection of (one or more) parallel loose source-routed
sequences of nodes ordered from Ingress to Egress, each forming a protection path. 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 The nodes in a Track are directly connected, reachable via existing Tracks as
illustrated in <xref target='nssr'/> or joined with strict segments of illustrated in <xref target='nssr'/> or joined with strict segments of
other nodes as shown in <xref target='srpdao'/>. other nodes as shown in <xref target='srpdao'/>.
The protection paths are expressed in RPL Non-Storing Mode and require an enc apsulation The protection paths are expressed in RPL Non-Storing Mode and require an enc apsulation
to add a Source Route Header, whereas the segments are expressed in RPL to add a Source Route Header, whereas the segments are expressed in RPL
Storing Mode. Storing Mode.
</t> </t>
<t> <t>
A path provides only one path between Ingress and Egress. A path provides only one path between the Ingress and Egress.
It comprises exactly one protection path. A Stand-Alone segment implicitly de It comprises exactly one protection path. A stand-alone segment implicitly de
fines a fines a
path from its Ingress to Egress. path from its Ingress to Egress.
</t> </t>
<t> A complex Track forms a graph that provides a collection of potential paths <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 to provide redundancy for the packets, either as a collection of protection paths that
may be parallel or interleaved at certain points, or as a more generic DODAG . may be parallel or interleaved at certain points or as a more generic DODAG.
</t> </t>
</section><!-- Building Tracks --> </section>
<section anchor='stracks'><name>Tracks and RPL Instances</name> <section anchor='stracks'><name>Tracks and RPL Instances</name>
<t> <t>
Section 5.1. of <xref target='RFC6550'/> describes the RPL Instance and <xref target='RFC6550' section="5.1"/> describes the RPL Instance and
its encoding. There can be up to 128 Global RPL Instances, for which there 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 RPL Instances, with a can be one or more DODAGs, and there can be 64 Local RPL Instances, with a
namespace that is indexed by a DODAGID, where the DODAGID is a Unique Local 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. 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 Bit 0 (most significant) is set to 1 to signal a Local RPLInstanceID, as
shown in <xref target='rpid'/>. By extension, this specification expresses shown in <xref target='rpid'/>. By extension, this specification expresses
the value of the RPLInstanceID as a single integer between 128 and 191, 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 representing both the Local RPLInstanceID in 0..63 in the rightmost bits
and Bit 0 set. and bit 0 set.
</t> </t>
<figure anchor='rpid'><name>Local RPLInstanceID Encoding</name> <figure anchor='rpid'><name>Local RPLInstanceID Encoding</name>
<artwork align="center"> <artwork ><![CDATA[
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|1|D| ID | Local RPLInstanceID in 0..63 |1|D| ID | Local RPLInstanceID in 0..63
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | | |
\ \ \ \
\ Bit 1 is set to 0 in Track IDs \ Bit 1 is set to 0 in Track IDs
Bit 0 set to 1 signals a local RPLInstanceID Bit 0 set to 1 signals a Local RPLInstanceID]]></artwork>
</artwork>
</figure> </figure>
<t> <t>
A Track typically forms an underlay to the main Instance, and is associated A Track typically forms an underlay to the main Instance and is associated
with a Local RPL Instance from which the RPLInstanceID is used as the TrackID . 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 with a When a packet is placed on a Track, it is IP-in-IP encapsulated with a
RPL Option containing a RPI which signals the RPLInstanceID. RPL Option containing RPL Packet Information (RPI) that signals the RPLInstan
ceID.
The encapsulating source IP address and RPI Instance are set to the Track The encapsulating source IP address and RPI Instance are set to the Track
Ingress IP address and local RPLInstanceID, respectively, more in Ingress IP address and Local RPLInstanceID, respectively; see more in
<xref target='trkid'/>. <xref target='trkid'/>.
</t> </t>
<t> <t>
A Track typically offers service protection across several protection paths. 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 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 (i.e., offering no protection) can be used as an alternative to a segment for
forwarding along a RPL Instance. forwarding along a RPL Instance.
In that case, instead of following native routes along the instance, the In that case, instead of following native routes along the instance, the
packets are encapsulated to signal a more specific source-routed path between packets are encapsulated to signal a more-specific source-routed path between
the loose hops in the encapsulated source routing header. the loose hops in the encapsulated source routing header.
</t><t> </t><t>
If the If the
encapsulated packet follows a global instance, then the protection path may b e part of that encapsulated packet follows a global instance, then the protection path may b e part of that
global instance as well, for instance the global instance of the main DODAG. global instance as well, e.g., the global instance of the main DODAG.
This can only be done for global instances because the Ingress node that 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 inst ance, encapsulates the packets over the protection path is not the Root of the inst ance,
so the source address of the encapsulated packet cannot be used to determine so the source address of the encapsulated packet cannot be used to determine
the Track along the way. the Track along the way.
</t> </t>
</section><!-- Tracks and RPL Instances --> </section>
</section><!-- On tracks --> </section>
<section><name>path Signaling</name> <section><name>Path Signaling</name>
<t> <t>
This specification enables setting up a P-Route along either a protection pat h or a This specification enables setting up a P-Route along either a protection pat h or a
segment. A P-Route is installed and maintained by the Root of the main DODAG 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), and a Track using an extended RPL DAO message called a P-DAO, and a Track
is composed of the combination of one or more P-Routes. In order to clarify 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 the the techniques that may be used to install a P-Route, this section uses the
simple case of the path illustrated in <xref target='reft'/>. simple case of the path illustrated in <xref target='reft'/>.
So the goal is to build a path from node A to E for packets towards E's 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 and E as opposed to via the Root: neighbors F and G along A, B, C, D, and E as opposed to via the Root:
</t> </t>
<figure anchor='reft'><name>Reference Track</name> <figure anchor='reft'><name>Reference Track</name>
<artwork align="center"> <artwork ><![CDATA[
/===&gt; F /===> F
A ===&gt; B ===&gt; C ===&gt; D===&gt; E &lt; A ===> B ===> C ===> D===> E <
\===&gt; G \===> G]]></artwork>
</artwork>
</figure> </figure>
<t> <t>
A P-DAO message for a Track signals the TrackID in the RPLInstanceID field. A P-DAO message for a Track signals the TrackID in the RPLInstanceID field.
In the case of a local RPL Instance, the address of the Track Ingress is In the case of a Local RPL Instance, the address of the Track Ingress is
used as source to encapsulate packets along the Track. The Track is signaled used as the source to encapsulate packets along the Track. The Track is signa
in the DODAGID field of the Projected DAO Base Object, led
in the DODAGID field of the P-DAO Base Object;
see <xref target='p-dao-fmt'/>. see <xref target='p-dao-fmt'/>.
</t><t> </t><t>
This specification introduces the Via Information Option (VIO) to signal a se quence of hops in a This specification introduces the Via Information Option (VIO) to signal a se quence of hops in a
protection path or a segment in the P-DAO messages, either in Storing Mode (S M-VIO) or protection path or a segment in the P-DAO messages, either in Storing Mode (S M-VIO) or
Non-Storing Mode (NSM-VIO). One P-DAO message contains a single VIO, in Non-Storing Mode (NSM-VIO). One P-DAO message contains a single VIO,
associated to one or more RPL Target Options that signal the destination which is associated to one or more RPL Target Options that signal the destina
IPv6 addresses that can reached along the Track (more in <xref target='viof'/ tion
>). IPv6 addresses that can reached along the Track (see more in <xref target='vi
of'/>).
</t> </t>
<t> <t>
Before diving deeper into Track and segment signaling and operation, Before diving deeper into Track and segment signaling and operation,
this section provides examples of how route projection works through this section provides examples of how route projection works through
variations of a simple example. This simple example illustrates the case of variations of a simple example. This simple example illustrates the case of
host routes, though RPL Targets can also be prefixes. host routes, though RPL Targets can also be prefixes.
</t> </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> <t>
Conventionally we use ==&gt; to represent a strict hop and --&gt; for a Conventionally, we use ==&gt; to represent a strict hop and --&gt; for a
loose hop. loose hop.
We use "-to-", such as in C==&gt;D==&gt;E-to-F to represent coma-separated We use "-to-", such as in 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. Targets, e.g., F is a Target for segment C==&gt;D==&gt;E.
In this example, A is the Track Ingress and E is the Track Egress. C is a sti In the example below, A is the Track Ingress and E is the Track Egress. C is
tching a stitching
point. F and G are "external” Targets for the Track, and become reachable point. F and G are "external" Targets for the Track and become reachable
from A via the Track A (Ingress) to E (Egress and implicit Target in from A via Track A (Ingress) to E (Egress and implicit Target in
Non-Storing Mode) leading to F and G (explicit Targets). Non-Storing Mode), leading to F and G (explicit Targets).
</t> </t>
<t> <t>
In a general manner the desired outcome is as follows: In a general manner, the desired outcome is as follows:
</t> </t>
<ul> <ul>
<li>Targets are E, F, and G </li> <li>Targets are E, F, and G </li>
<li>P-DAO 1 signals C==&gt;D==&gt;E</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 2 signals A==&gt;B==&gt;C</li>
<li>P-DAO 3 signals F and G via the A--&gt;E Track</li> <li>P-DAO 3 signals F and G via the A--&gt;E Track</li>
</ul> </ul>
<t> <t>
P-DAO 3 may be omitted if P-DAO 1 and 2 signal F and G as Targets. P-DAO 3 may be omitted if P-DAOs 1 and 2 signal F and G as Targets.
</t> </t>
<t> <t>
Loose sequences of hops are expressed in Non-Storing Mode; this is why P-DAO 3 Loose sequences of hops are expressed in Non-Storing Mode; this is why P-DAO 3
contains a NSM-VIO. With this specification: contains an NSM-VIO. With this specification:
</t> </t>
<ul> <ul>
<li> <li>
the DODAGID to be used by the Ingress as source address is signaled The DODAGID to be used by the Ingress as the source address is signaled
in the DAO base object (see <xref target='p-dao-fmt'/>) . in the DAO Base Object (see <xref target='p-dao-fmt'/>).
</li><li> </li><li>
the via list in the VIO is encoded as an SRH-6LoRH (see <xref target='viao'/ 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 node after the Ingress node and it starts with the address of the first-hop node after the Ingress node
in the loose hop sequence. in the loose hop sequence.
</li><li> </li><li>
the via list ends with the address of the Egress node. The via list ends with the address of the Egress node.
</li> </li>
</ul> </ul>
<t> Note well:
</t>
<blockquote>
The Egress of a Non-Storing Mode P-Route is implicitly a target; it is
not listed in the RPL Target Options but 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 which would be non-sensical.
</blockquote>
<t>
Also:
</t>
<blockquote> <aside><t>Note 1: The Egress of a Non-Storing Mode P-Route is implicitly a
By design, the list of nodes in a VIO in Non-Storing Mode is target; it is not listed in the RPL Target Options but is still accounted for as
exactly the list that shows in the encapsulation SRH. So in the cases if it was. The only exception is when the Egress is the only address listed
detailed below, if the Mode of the P-DAO is Non-Storing, then the VIO in the VIO, in which case it would indicate via itself, which would be
row can be read as indicating the SRH as well. nonsensical.</t> </aside>
</blockquote> <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.</t></aside>
<section anchor="usms"><name>Using Storing Mode Segments</name> <section anchor="usms"><name>Using Storing Mode Segments</name>
<t> <t>
A==&gt;B==&gt;C and C==&gt;D==&gt;E are segments of the same Track. 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, 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. along the reverse datapath that it signals.
One benefit of strict routing is that loops are avoided along the Track. One benefit of strict routing is that loops are avoided along the Track.
</t> </t>
<section><name>Stitched Segments</name> <section><name>Stitched Segments</name>
<t>In this formulation:</t> <t>In this formulation:</t>
<ul> <ul>
<li>P-DAO 1 signals C==&gt;D==&gt;E-to-F,G</li> <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> <li>P-DAO 2 signals A==&gt;B==&gt;C-to-F,G</li>
</ul> </ul>
<t>Storing Mode P-DAO 1 is sent to E and when it is successfully acknowledged, <t>Storing Mode P-DAO 1 is sent to E, and when it is successfully acknowledged,
Storing Mode P-DAO 2 is sent to C, as follows:</t> Storing Mode P-DAO 2 is sent to C as follows:</t>
<table anchor="PDAOcase11"><name>P-DAO Messages</name> <table anchor="PDAOcase11"><name>P-DAO Messages</name>
<thead> <thead>
<tr><th align='center'>Field</th> <tr><th>Field</th>
<th align='left'>P-DAO 1 to E</th> <th>P-DAO 1 to E</th>
<th align='left'>P-DAO 2 to C</th></tr> <th>P-DAO 2 to C</th></tr>
</thead> </thead>
<tbody> <tbody>
<tr><td align='center'>Mode</td> <tr><th>Mode</th>
<td align='left'>Storing</td> <td>Storing</td>
<td align='left'>Storing</td></tr> <td>Storing</td></tr>
<tr><td align='center'>Track Ingress</td> <tr><th>Track Ingress</th>
<td align='left'>A</td> <td>A</td>
<td align='left'>A</td></tr> <td>A</td></tr>
<tr><td align='center'>(DODAGID, TrackID)</td> <tr><th>(DODAGID, TrackID)</th>
<td align='left'>(A, 129)</td> <td>(A, 129)</td>
<td align='left'>(A, 129)</td></tr> <td>(A, 129)</td></tr>
<tr><td align='center'>SegmentID</td> <tr><th>SegmentID</th>
<td align='left'>1</td> <td>1</td>
<td align='left'>2</td></tr> <td>2</td></tr>
<tr><td align='center'>VIO</td> <tr><th>VIO</th>
<td align='left'>C, D, E</td> <td>C, D, E</td>
<td align='left'>A, B, C</td></tr> <td>A, B, C</td></tr>
<tr><td align='center'>Targets</td> <tr><th>Targets</th>
<td align='left'>F, G</td> <td>F, G</td>
<td align='left'>F, G</td></tr> <td>F, G</td></tr>
</tbody> </tbody>
</table> </table>
<t>As a result the RIBs are set as follows:</t> <t>As a result, the RIBs are set as follows:</t>
<!-- COMMENT: The acronym for RIB is not defined <!-- COMMENT: The acronym for RIB is not defined
AUTH: added AUTH: added
--> -->
<table anchor="RIBcase11"><name>RIB setting</name> <table anchor="RIBcase11"><name>RIB Settings</name>
<thead> <thead>
<tr><th align='center'>Node</th> <tr><th>Node</th>
<th align='left'>Destination</th> <th>Destination</th>
<th align='left'>Origin</th> <th>Origin</th>
<th align='left'>Next Hop(s)</th> <th>Next Hop(s)</th>
<th align='left'>TrackID</th></tr> <th>TrackID</th></tr>
</thead> </thead>
<tbody> <tbody>
<tr><td align='center'>E</td> <tr><td>E</td>
<td align='left'>F, G</td> <td>F, G</td>
<td align='left'>P-DAO 1</td> <td>P-DAO 1</td>
<td align='left'>Neighbor</td> <td>Neighbor</td>
<td align='left'>(A, 129)</td></tr> <td>(A, 129)</td></tr>
<tr><td align='center'>D</td> <tr><td>D</td>
<td align='left'>E</td> <td>E</td>
<td align='left'>P-DAO 1</td> <td>P-DAO 1</td>
<td align='left'>Neighbor</td> <td>Neighbor</td>
<td align='left'>(A, 129)</td></tr> <td>(A, 129)</td></tr>
<tr><td align='center'>"</td> <tr><td>"</td>
<td align='left'>F, G</td> <td>F, G</td>
<td align='left'>P-DAO 1</td> <td>P-DAO 1</td>
<td align='left'>E</td> <td>E</td>
<td align='left'>(A, 129)</td></tr> <td>(A, 129)</td></tr>
<tr><td align='center'>C</td> <tr><td>C</td>
<td align='left'>D</td> <td>D</td>
<td align='left'>P-DAO 1</td> <td>P-DAO 1</td>
<td align='left'>Neighbor</td> <td>Neighbor</td>
<td align='left'>(A, 129)</td></tr> <td>(A, 129)</td></tr>
<tr><td align='center'>"</td> <tr><td>"</td>
<td align='left'>F, G</td> <td>F, G</td>
<td align='left'>P-DAO 1</td> <td>P-DAO 1</td>
<td align='left'>D</td> <td>D</td>
<td align='left'>(A, 129)</td></tr> <td>(A, 129)</td></tr>
<tr><td align='center'>B</td> <tr><td>B</td>
<td align='left'>C</td> <td>C</td>
<td align='left'>P-DAO 2</td> <td>P-DAO 2</td>
<td align='left'>Neighbor</td> <td>Neighbor</td>
<td align='left'>(A, 129)</td></tr> <td>(A, 129)</td></tr>
<tr><td align='center'>"</td> <tr><td>"</td>
<td align='left'>F, G</td> <td>F, G</td>
<td align='left'>P-DAO 2</td> <td>P-DAO 2</td>
<td align='left'>C</td> <td>C</td>
<td align='left'>(A, 129)</td></tr> <td>(A, 129)</td></tr>
<tr><td align='center'>A</td> <tr><td>A</td>
<td align='left'>B</td> <td>B</td>
<td align='left'>P-DAO 2</td> <td>P-DAO 2</td>
<td align='left'>Neighbor</td> <td>Neighbor</td>
<td align='left'>(A, 129)</td></tr> <td>(A, 129)</td></tr>
<tr><td align='center'>"</td> <tr><td>"</td>
<td align='left'>F, G</td> <td>F, G</td>
<td align='left'>P-DAO 2</td> <td>P-DAO 2</td>
<td align='left'>B</td> <td>B</td>
<td align='left'>(A, 129)</td></tr> <td>(A, 129)</td></tr>
</tbody> </tbody>
</table> </table>
<t> <aside><t>Note: The " sign is used throughout the tables in this document to ind
Note: icate the same value as in the row above.</t></aside>
</t>
<blockquote>
the " sign is used throughout those tables to indicate the same value as
in the row above.
</blockquote>
<!-- <!--
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. 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 AUTH: yes that is what it means, and for the second point, I tried and that was really awful to read
--> -->
<t> <t>
Packets originating at A going to F or G do not require encapsulation 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 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; 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 outer headers of the packets that are forwarded along the Track have
the following settings: the following settings:
</t> </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> <table anchor="Packetcase11"><name>Packet Header Settings</name> <thead>
<tr><th align='center'>Header</th> <tr><th align="center">Header</th>
<th align='center'>IPv6 Source Addr.</th> <th align="center">IPv6 Source Address</th>
<th align='center'>IPv6 Dest. Addr.</th> <th align="center">IPv6 Destination Address</th>
<th align='center'>TrackID in RPI</th></tr> <th align="center">TrackID in RPI</th></tr>
</thead> </thead>
<tbody> <tbody>
<tr><td align='center'>Outer</td> <tr><td align="center">Outer</td>
<td align='center'>A</td> <td align="center">A</td>
<td align='center'>F or G</td> <td align="center">F or G</td>
<td align='center'>(A, 129)</td></tr> <td align="center">(A, 129)</td></tr>
<tr><td align='center'>Inner</td> <tr><td align="center">Inner</td>
<td align='center'>Any but A</td> <td align="center">Any but A</td>
<td align='center'>F or G</td> <td align="center">F or G</td>
<td align='center'>N/A</td></tr> <td align="center">N/A</td></tr>
</tbody> </tbody>
</table> </table>
<!-- COMMENT: The X != A is not very clear. I would guess it means "anything els e but A" but maybe a note will clarify this. <!-- COMMENT: The X != A is not very clear. I would guess it means "anything els e but A" but maybe a note will clarify this.
AUTH: replaced with "Any but A" AUTH: replaced with "Any but A"
--> -->
<t> <t>
As an example, say that A has a packet for F. Using the RIB in <xref target='RIB case11'/>: As an example, say that A has a packet for F. Using the RIB in <xref target='RIB case11'/>:
</t> </t>
<ul> <ul>
<li>From P-DAO 2: A forwards to B and B forwards to C.</li> <li>From P-DAO 2: A forwards to B, and B forwards to C.</li>
<li>From P-DAO 1: C forwards to D and D forwards to E.</li> <li>From P-DAO 1: C forwards to D, and D forwards to E.</li>
<li>From Neighbor Cache Entry: E delivers the packet to F.</li> <li>From Neighbor Cache Entry: E delivers the packet to F.</li>
</ul> </ul>
</section><!-- Stitched Segments --> </section>
<section><name>External Routes</name> <section><name>External Routes</name>
<t>In this example, we consider F and G as destinations that are external to the <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'/>. Track as a DODAG, as discussed in <xref target='RFC9008' section="4.1.1"/>.
We then apply the directives for encapsulating in that case (more in <xref We then apply the directives for encapsulating in that case (see more in <xre
f
target='routing'/>). target='routing'/>).
</t> </t>
<t>In this formulation, we set up the protection path explicitly, which creates less <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 routing state in intermediate hops at the expense of larger packets to
accommodate source routing:</t> accommodate source routing:</t>
<ul> <ul>
<li>P-DAO 1 signals C==&gt;D==&gt;E-to-E</li> <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 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> <li>P-DAO 3 signals F and G via the A--&gt;E-to-F,G Track</li>
</ul> </ul>
<t>Storing Mode P-DAO 1 and 2, and Non-Storing Mode P-DAO 3, are sent to E, C <t>Storing Mode P-DAOs 1 and 2 and Non-Storing Mode P-DAO 3 are sent to E, C,
and A, respectively, as follows:</t> and A, respectively, as follows:</t>
<table anchor="PDAOcase12"><name>P-DAO Messages</name> <table anchor="PDAOcase12"><name>P-DAO Messages</name>
<thead> <thead>
<tr><th align='center'> </th> <tr><th> </th>
<th align='left'>P-DAO 1 to E</th> <th>P-DAO 1 to E</th>
<th align='left'>P-DAO 2 to C</th> <th>P-DAO 2 to C</th>
<th align='left'>P-DAO 3 to A</th></tr> <th>P-DAO 3 to A</th></tr>
</thead> </thead>
<tbody> <tbody>
<tr><td align='center'>Mode</td> <tr><th>Mode</th>
<td align='left'>Storing</td> <td>Storing</td>
<td align='left'>Storing</td> <td>Storing</td>
<td align='left'>Non-Storing</td></tr> <td>Non-Storing</td></tr>
<tr><td align='center'>Track Ingress</td> <tr><th>Track Ingress</th>
<td align='left'>A</td> <td>A</td>
<td align='left'>A</td> <td>A</td>
<td align='left'>A</td></tr> <td>A</td></tr>
<tr><td align='center'>(DODAGID, TrackID)</td> <tr><th>(DODAGID, TrackID)</th>
<td align='left'>(A, 129)</td> <td>(A, 129)</td>
<td align='left'>(A, 129)</td> <td>(A, 129)</td>
<td align='left'>(A, 129)</td></tr> <td>(A, 129)</td></tr>
<tr><td align='center'>SegmentID</td> <tr><th>SegmentID</th>
<td align='left'>1</td> <td>1</td>
<td align='left'>2</td> <td>2</td>
<td align='left'>3</td></tr> <td>3</td></tr>
<tr><td align='center'>VIO</td> <tr><th>VIO</th>
<td align='left'>C, D, E</td> <td>C, D, E</td>
<td align='left'>A, B, C</td> <td>A, B, C</td>
<td align='left'>E</td></tr> <td>E</td></tr>
<tr><td align='center'>Targets</td> <tr><th>Targets</th>
<td align='left'>E</td> <td>E</td>
<td align='left'>E</td> <td>E</td>
<td align='left'>F, G</td></tr> <td>F, G</td></tr>
</tbody> </tbody>
</table> </table>
<t> <t>
Note in the above that E is not an implicit Target in Storing mode, so it mus t be added in the RTO for P-DAO 1 and 2. Note in the above that E is not an implicit Target in Storing Mode, so it mus t be added in the RPL Target Option (RTO) for 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. E is not an implicit Target for P-DAO 3 either, since E is the only entry in the VIO.
</t> </t>
<t>As a result the RIBs are set as follows:</t> <t>As a result, the RIBs are set as follows:</t>
<table anchor="RIBcase12"><name>RIB setting</name> <table anchor="RIBcase12"><name>RIB Settings</name>
<thead> <thead>
<tr><th align='center'>Node</th> <tr><th>Node</th>
<th align='left'>Destination</th> <th>Destination</th>
<th align='left'>Origin</th> <th>Origin</th>
<th align='left'>Next Hop(s)</th> <th>Next Hop(s)</th>
<th align='left'>TrackID</th></tr> <th>TrackID</th></tr>
</thead> </thead>
<tbody> <tbody>
<tr><td align='center'>E</td> <tr><td>E</td>
<td align='left'>F, G</td> <td>F, G</td>
<td align='left'>P-DAO 1</td> <td>P-DAO 1</td>
<td align='left'>Neighbor</td> <td>Neighbor</td>
<td align='left'>(A, 129)</td></tr> <td>(A, 129)</td></tr>
<tr><td align='center'>D</td> <tr><td>D</td>
<td align='left'>E</td> <td>E</td>
<td align='left'>P-DAO 1</td> <td>P-DAO 1</td>
<td align='left'>Neighbor</td> <td>Neighbor</td>
<td align='left'>(A, 129)</td></tr> <td>(A, 129)</td></tr>
<tr><td align='center'>C</td> <tr><td>C</td>
<td align='left'>D</td> <td>D</td>
<td align='left'>P-DAO 1</td> <td>P-DAO 1</td>
<td align='left'>Neighbor</td> <td>Neighbor</td>
<td align='left'>(A, 129)</td></tr> <td>(A, 129)</td></tr>
<tr><td align='center'>"</td> <tr><td>"</td>
<td align='left'>E</td> <td>E</td>
<td align='left'>P-DAO 1</td> <td>P-DAO 1</td>
<td align='left'>D</td> <td>D</td>
<td align='left'>(A, 129)</td></tr> <td>(A, 129)</td></tr>
<tr><td align='center'>B</td> <tr><td>B</td>
<td align='left'>C</td> <td>C</td>
<td align='left'>P-DAO 2</td> <td>P-DAO 2</td>
<td align='left'>Neighbor</td> <td>Neighbor</td>
<td align='left'>(A, 129)</td></tr> <td>(A, 129)</td></tr>
<tr><td align='center'>"</td> <tr><td>"</td>
<td align='left'>E</td> <td>E</td>
<td align='left'>P-DAO 2</td> <td>P-DAO 2</td>
<td align='left'>C</td> <td>C</td>
<td align='left'>(A, 129)</td></tr> <td>(A, 129)</td></tr>
<tr><td align='center'>A</td> <tr><td>A</td>
<td align='left'>B</td> <td>B</td>
<td align='left'>P-DAO 2</td> <td>P-DAO 2</td>
<td align='left'>Neighbor</td> <td>Neighbor</td>
<td align='left'>(A, 129)</td></tr> <td>(A, 129)</td></tr>
<tr><td align='center'>"</td> <tr><td>"</td>
<td align='left'>E</td> <td>E</td>
<td align='left'>P-DAO 2</td> <td>P-DAO 2</td>
<td align='left'>B</td> <td>B</td>
<td align='left'>(A, 129)</td></tr> <td>(A, 129)</td></tr>
<tr><td align='center'>"</td> <tr><td>"</td>
<td align='left'>F, G</td> <td>F, G</td>
<td align='left'>P-DAO 3</td> <td>P-DAO 3</td>
<td align='left'>E</td> <td>E</td>
<td align='left'>(A, 129)</td></tr> <td>(A, 129)</td></tr>
</tbody> </tbody>
</table> </table>
<t> <t>
Packets from A to E do not require an encapsulation. Packets from A to E do not require an encapsulation.
This is why in the tables below, E may show as IPv6 Destination Address only In the tables below, this is why E may show as an IPv6 destination address o
if the IPv6 Source Address X is different from A. nly
Conversely, the encapsulation is always done when the IPv6 Destination if the IPv6 source address X is different from A.
Address is F or G. Conversely, the encapsulation is always done when the IPv6 destination
address is F or G.
Other destination addresses do not match this P-Route and are not subject to Other destination addresses do not match this P-Route and are not subject to
encapsulation. encapsulation.
</t><t> </t><t>
The outer headers of The outer headers of
the packets that are forwarded along the Track have the following settings: the packets that are forwarded along the Track have the following settings:
</t> </t>
<table anchor="Packetcase12"><name>Packet Header Settings</name> <table anchor="Packetcase12"><name>Packet Header Settings</name>
<thead> <thead>
<tr><th align='center'>Header</th> <tr><th align="center">Header</th>
<th align='center'>IPv6 Source Addr.</th> <th align="center">IPv6 Source Address</th>
<th align='center'>IPv6 Dest. Addr.</th> <th align="center">IPv6 Destination Address</th>
<th align='center'>TrackID in RPI</th></tr> <th align="center">TrackID in RPI</th></tr>
</thead> </thead>
<tbody> <tbody>
<tr><td align='center'>Outer</td> <tr><td align="center">Outer</td>
<td align='center'>A</td> <td align="center">A</td>
<td align='center'>E</td> <td align="center">E</td>
<td align='center'>(A, 129)</td></tr> <td align="center">(A, 129)</td></tr>
<tr><td align='center'>Inner</td> <tr><td align="center">Inner</td>
<td align='center'>X</td> <td align="center">X</td>
<td align='center'>Either F or G. If X!=A, then E is also permitte <td>Either F or G. If X!=A, E is also permitted.</td>
d.</td> <td align="center">N/A</td></tr>
<td align='center'>N/A</td></tr>
</tbody> </tbody>
</table> </table>
<!-- COMMENT: The E (X != A) is not very clear. What is X? <!-- 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" AUTH: X was the node in the column left to this. Changed to "either E if(X != A), or F, or G"
--> -->
<t> <t>
As an example, say that A has a packet for F. Using the RIB in <xref target='RIB case12'/>: As an example, say that A has a packet for F. Using the RIB in <xref target='RIB case12'/>:
</t> </t>
<ul> <ul>
<li>From P-DAO 3: A encapsulates the packet and sends it down the Track signaled <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. by P-DAO 3, with the outer header above. Now the packet destination is E.</li>
Now the packet destination is E.</li> <li>From P-DAO 2: A forwards to B, and B forwards to C.</li>
<li>From P-DAO 2: A forwards to B and B forwards to C.</li> <li>From P-DAO 1: C forwards to D, and D forwards to E; E decapsulates the packe
<li>From P-DAO 1: C forwards to D and D forwards to E; E decapsulates the packet t.</li>
.</li>
<li>From Neighbor Cache Entry: E delivers packets to F or G.</li> <li>From Neighbor Cache Entry: E delivers packets to F or G.</li>
</ul> </ul>
</section><!-- External routes --> </section>
<section anchor="srpdao"><name>Segment Routing</name> <section anchor="srpdao"><name>Segment Routing</name>
<t>In this formulation protection paths are leveraged to combine segments and fo <t>In this formulation, protection paths are leveraged to combine segments and f
rm a orm a
Graph. The packets are source routed from a segment to the next to adapt graph. The packets are source routed from a segment to the next to adapt
the path:</t> the path:</t>
<ul> <ul>
<li>P-DAO 1 signals C==&gt;D==&gt;E-to-E</li> <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 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> <li>P-DAO 3 signals F and G via the A--&gt;C--&gt;E-to-(E),F,G Track</li>
</ul> </ul>
<t>Storing Mode P-DAO 1 and 2, and Non-Storing Mode P-DAO 3, are sent to E, B <t>Storing Mode P-DAOs 1 and 2 and Non-Storing Mode P-DAO 3 are sent to E, B,
and A, respectively, as follows:</t> and A, respectively, as follows:</t>
<table anchor="PDAOcase13"><name>P-DAO Messages</name> <table anchor="PDAOcase13"><name>P-DAO Messages</name>
<thead> <thead>
<tr><th align='center'> </th> <tr><th> </th>
<th align='left'>P-DAO 1 to E</th> <th>P-DAO 1 to E</th>
<th align='left'>P-DAO 2 to B</th> <th>P-DAO 2 to B</th>
<th align='left'>P-DAO 3 to A</th></tr> <th>P-DAO 3 to A</th></tr>
</thead> </thead>
<tbody> <tbody>
<tr><td align='center'>Mode</td> <tr><th>Mode</th>
<td align='left'>Storing</td> <td>Storing</td>
<td align='left'>Storing</td> <td>Storing</td>
<td align='left'>Non-Storing</td></tr> <td>Non-Storing</td></tr>
<tr><td align='center'>Track Ingress</td> <tr><th>Track Ingress</th>
<td align='left'>A</td> <td>A</td>
<td align='left'>A</td> <td>A</td>
<td align='left'>A</td></tr> <td>A</td></tr>
<tr><td align='center'>(DODAGID, TrackID)</td> <tr><th>(DODAGID, TrackID)</th>
<td align='left'>(A, 129)</td> <td>(A, 129)</td>
<td align='left'>(A, 129)</td> <td>(A, 129)</td>
<td align='left'>(A, 129)</td></tr> <td>(A, 129)</td></tr>
<tr><td align='center'>SegmentID</td> <tr><th>SegmentID</th>
<td align='left'>1</td> <td>1</td>
<td align='left'>2</td> <td>2</td>
<td align='left'>3</td></tr> <td>3</td></tr>
<tr><td align='center'>VIO</td> <tr><th>VIO</th>
<td align='left'>C, D, E</td> <td>C, D, E</td>
<td align='left'>A, B</td> <td>A, B</td>
<td align='left'>C, E</td></tr> <td>C, E</td></tr>
<tr><td align='center'>Targets</td> <tr><th>Targets</th>
<td align='left'>E</td> <td>E</td>
<td align='left'>B, C</td> <td>B, C</td>
<td align='left'>F, G</td></tr> <td>F, G</td></tr>
</tbody> </tbody>
</table> </table>
<t> <t>
Note in the above that the segment can terminate at the loose hop as used in Note in the table above that the segment can terminate at the loose hop as us ed in
the example of P-DAO 1 or at the previous hop as done with P-DAO 2. 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 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 generates more signaling since E is the segment Egress when D could be, but a
has the benefit that it validates that the connectivity between D and E still benefit is that it validates that the connectivity between D and E still
exists. exists.
</t> </t>
<t>As a result the RIBs are set as follows:</t> <t>As a result, the RIBs are set as follows:</t>
<table anchor="RIBcase13"><name>RIB setting</name> <table anchor="RIBcase13"><name>RIB Settings</name>
<thead> <thead>
<tr><th align='center'>Node</th> <tr><th>Node</th>
<th align='left'>Destination</th> <th>Destination</th>
<th align='left'>Origin</th> <th>Origin</th>
<th align='left'>Next Hop(s)</th> <th>Next Hop(s)</th>
<th align='left'>TrackID</th></tr> <th>TrackID</th></tr>
</thead> </thead>
<tbody> <tbody>
<tr><td align='center'>E</td> <tr><td>E</td>
<td align='left'>F, G</td> <td>F, G</td>
<td align='left'>P-DAO 1</td> <td>P-DAO 1</td>
<td align='left'>Neighbor</td> <td>Neighbor</td>
<td align='left'>(A, 129)</td></tr> <td>(A, 129)</td></tr>
<tr><td align='center'>D</td> <tr><td>D</td>
<td align='left'>E</td> <td>E</td>
<td align='left'>P-DAO 1</td> <td>P-DAO 1</td>
<td align='left'>Neighbor</td> <td>Neighbor</td>
<td align='left'>(A, 129)</td></tr> <td>(A, 129)</td></tr>
<tr><td align='center'>C</td> <tr><td>C</td>
<td align='left'>D</td> <td>D</td>
<td align='left'>P-DAO 1</td> <td>P-DAO 1</td>
<td align='left'>Neighbor</td> <td>Neighbor</td>
<td align='left'>(A, 129)</td></tr> <td>(A, 129)</td></tr>
<tr><td align='center'>"</td> <tr><td>"</td>
<td align='left'>E</td> <td>E</td>
<td align='left'>P-DAO 1</td> <td>P-DAO 1</td>
<td align='left'>D</td> <td>D</td>
<td align='left'>(A, 129)</td></tr> <td>(A, 129)</td></tr>
<tr><td align='center'>B</td> <tr><td>B</td>
<td align='left'>C</td> <td>C</td>
<td align='left'>P-DAO 2</td> <td>P-DAO 2</td>
<td align='left'>Neighbor</td> <td>Neighbor</td>
<td align='left'>(A, 129)</td></tr> <td>(A, 129)</td></tr>
<tr><td align='center'>A</td> <tr><td>A</td>
<td align='left'>B</td> <td>B</td>
<td align='left'>P-DAO 2</td> <td>P-DAO 2</td>
<td align='left'>Neighbor</td> <td>Neighbor</td>
<td align='left'>(A, 129)</td></tr> <td>(A, 129)</td></tr>
<tr><td align='center'>"</td> <tr><td>"</td>
<td align='left'>C</td> <td>C</td>
<td align='left'>P-DAO 2</td> <td>P-DAO 2</td>
<td align='left'>B</td> <td>B</td>
<td align='left'>(A, 129)</td></tr> <td>(A, 129)</td></tr>
<tr><td align='center'>"</td> <tr><td>"</td>
<td align='left'>E, F, G</td> <td>E, F, G</td>
<td align='left'>P-DAO 3</td> <td>P-DAO 3</td>
<td align='left'>C, E</td> <td>C, E</td>
<td align='left'>(A, 129)</td></tr> <td>(A, 129)</td></tr>
</tbody> </tbody>
</table> </table>
<t> <t>
Packets originated at A to E do not require an encapsulation, but Packets originated at A to E do not require an encapsulation, but
carry a SRH via C. they carry an SRH via C.
The outer headers of the packets that are forwarded along the Track have The outer headers of the packets that are forwarded along the Track have
the following settings: the following settings:
</t> </t>
<table anchor="Packetcase13"><name>Packet Header Settings</name> <table anchor="Packetcase13"><name>Packet Header Settings</name>
<thead> <thead>
<tr><th align='center'>Header</th> <tr><th align="center">Header</th>
<th align='center'>IPv6 Source Addr.</th> <th align="center">IPv6 Source Address</th>
<th align='center'>IPv6 Dest. Addr.</th> <th align="center">IPv6 Destination Address</th>
<th align='center'>TrackID in RPI</th></tr> <th align="center">TrackID in RPI</th></tr>
</thead> </thead>
<tbody> <tbody>
<tr><td align='center'>Outer</td> <tr><td align="center">Outer</td>
<td align='center'>A</td> <td align="center">A</td>
<td align='center'>C until C then E</td> <td align="center">C until C then E</td>
<td align='center'>(A, 129)</td></tr> <td align="center">(A, 129)</td></tr>
<tr><td align='center'>Inner</td> <tr><td align="center">Inner</td>
<td align='center'>X</td> <td align="center">X</td>
<td align='center'>Either F or G. If X!=A, then E is also permitte <td>Either F or G. If X!=A, E is also permitted.</td>
d.</td> <td align="center">N/A</td></tr>
<td align='center'>N/A</td></tr>
</tbody> </tbody>
</table> </table>
<!-- COMMENT: I know this may take some effort, sorry, but I think it would be r eally useful in the Packet Header Settings tables, here and further below, to al so 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 un derstand what's going on. <!-- COMMENT: I know this may take some effort, sorry, but I think it would be r eally useful in the Packet Header Settings tables, here and further below, to al so 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 un derstand what's going on.
AUTH: actually that was easy. Because it's already there. I added at the AUTH: actually that was easy. Because it's already there. I added at the
beginning of the section beginning of the section
Note well: by design, the list of nodes in a VIO in Non-Storing Mode is 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 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 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. row can be read as indicating the SRH as well.
--> -->
<t> <t>
As an example, say that A has a packet for F. Using the RIB in <xref target='RIB case13'/>: As an example, say that A has a packet for F. Using the RIB in <xref target='RIB case13'/>:
</t> </t>
<ul> <ul>
<li>From P-DAO 3: A encapsulates the packet the Track signaled by P-DAO 3, with <li>From P-DAO 3: A encapsulates the packet the Track signaled by P-DAO 3, with
the outer header above. the outer header above. Now the destination in the IPv6 header is C, and an SRH
Now the destination in the IPv6 Header is C, and a SRH signals the final destina signals that the final destination is E.</li>
tion is E.</li> <li>From P-DAO 2: A forwards to B, and B forwards to C.</li>
<li>From P-DAO 2: A forwards to B and B forwards to C.</li> <li>From P-DAO 3: C processes the SRH and sets the destination in the IPv6 heade
<li>From P-DAO 3: C processes the SRH and sets the destination in the IPv6 Heade r to E.</li>
r to E.</li> <li>From P-DAO 1: C forwards to D, and D forwards to E; E decapsulates the packe
<li>From P-DAO 1: C forwards to D and D forwards to E; E decapsulates the packet t.</li>
.</li>
<li>From the Neighbor Cache Entry: E delivers packets to F or G.</li> <li>From the Neighbor Cache Entry: E delivers packets to F or G.</li>
</ul> </ul>
</section><!-- Segment Routing --> </section>
</section><!-- Using Storing Mode Segments --> </section>
<section><name>Using Non-Storing Mode joining Tracks</name> <section><name>Using Non-Storing Mode Joining Tracks</name>
<t>In this formulation:</t> <t>In this formulation:</t>
<ul> <ul>
<li>P-DAO 1 signals C==&gt;D==&gt;E-to-(E),F,G</li> <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> <li>P-DAO 2 signals A==&gt;B==&gt;C-to-(C),E,F,G</li>
</ul> </ul>
<t> <t>
A==&gt;B==&gt;C and C==&gt;D==&gt;E are Tracks expressed as Non-Storing P-DA Os. A==&gt;B==&gt;C and C==&gt;D==&gt;E are Tracks expressed as Non-Storing Mode P-DAOs.
</t> </t>
<section><name>Stitched Tracks</name> <section><name>Stitched Tracks</name>
<t> <t>
Non-Storing Mode P-DAO 1 and 2 are sent to C and A respectively, as follows: Non-Storing Mode P-DAO 1 and 2 are sent to C and A, respectively, as follows :
</t> </t>
<table anchor="PDAOcase21"><name>P-DAO Messages</name> <table anchor="PDAOcase21"><name>P-DAO Messages</name>
<thead> <thead>
<tr><th align='center'> </th> <tr><th> </th>
<th align='left'>P-DAO 1 to C</th> <th>P-DAO 1 to C</th>
<th align='left'>P-DAO 2 to A</th></tr> <th>P-DAO 2 to A</th></tr>
</thead> </thead>
<tbody> <tbody>
<tr><td align='center'>Mode</td> <tr><th>Mode</th>
<td align='left'>Non-Storing</td> <td>Non-Storing</td>
<td align='left'>Non-Storing</td></tr> <td>Non-Storing</td></tr>
<tr><td align='center'>Track Ingress</td> <tr><th>Track Ingress</th>
<td align='left'>C</td> <td>C</td>
<td align='left'>A</td></tr> <td>A</td></tr>
<tr><td align='center'>(DODAGID, TrackID)</td> <tr><th>(DODAGID, TrackID)</th>
<td align='left'>(C, 131)</td> <td>(C, 131)</td>
<td align='left'>(A, 131)</td></tr> <td>(A, 131)</td></tr>
<tr><td align='center'>SegmentID</td> <tr><th>SegmentID</th>
<td align='left'>1</td> <td>1</td>
<td align='left'>1</td></tr> <td>1</td></tr>
<tr><td align='center'>VIO</td> <tr><th>VIO</th>
<td align='left'>D, E</td> <td>D, E</td>
<td align='left'>B, C</td></tr> <td>B, C</td></tr>
<tr><td align='center'>Targets</td> <tr><th>Targets</th>
<td align='left'>F, G</td> <td>F, G</td>
<td align='left'>E, F, G</td></tr> <td>E, F, G</td></tr>
</tbody> </tbody>
</table> </table>
<t>As a result the RIBs are set as follows (using ND to indicate that the addres s is discovered by IPv6 Neighbor Discovery <xref target='RFC4861'/><xref target= 'RFC8505'/> or an equivalent method:</t> <t>As a result, the RIBs are set as follows (using "ND" to indicate that the add ress is discovered by IPv6 Neighbor Discovery <xref target='RFC4861'/> <xref tar get='RFC8505'/> or an equivalent method):</t>
<table anchor="RIBcase21"><name>RIB setting</name> <table anchor="RIBcase21"><name>RIB Settings</name>
<thead> <thead>
<tr><th align='center'>Node</th> <tr><th>Node</th>
<th align='left'>Destination</th> <th>Destination</th>
<th align='left'>Origin</th> <th>Origin</th>
<th align='left'>Next Hop(s)</th> <th>Next Hop(s)</th>
<th align='left'>TrackID</th></tr> <th>TrackID</th></tr>
</thead> </thead>
<tbody> <tbody>
<tr><td align='center'>E</td> <tr><td>E</td>
<td align='left'>F, G</td> <td>F, G</td>
<td align='left'>ND</td> <td>ND</td>
<td align='left'>Neighbor</td> <td>Neighbor</td>
<td align='left'>Any</td></tr> <td>Any</td></tr>
<tr><td align='center'>D</td> <tr><td>D</td>
<td align='left'>E</td> <td>E</td>
<td align='left'>ND</td> <td>ND</td>
<td align='left'>Neighbor</td> <td>Neighbor</td>
<td align='left'>Any</td></tr> <td>Any</td></tr>
<tr><td align='center'>C</td> <tr><td>C</td>
<td align='left'>D</td> <td>D</td>
<td align='left'>ND</td> <td>ND</td>
<td align='left'>Neighbor</td> <td>Neighbor</td>
<td align='left'>Any</td></tr> <td>Any</td></tr>
<tr><td align='center'>"</td> <tr><td>"</td>
<td align='left'>E, F, G</td> <td>E, F, G</td>
<td align='left'>P-DAO 1</td> <td>P-DAO 1</td>
<td align='left'>D, E</td> <td>D, E</td>
<td align='left'>(C, 131)</td></tr> <td>(C, 131)</td></tr>
<tr><td align='center'>B</td> <tr><td>B</td>
<td align='left'>C</td> <td>C</td>
<td align='left'>ND</td> <td>ND</td>
<td align='left'>Neighbor</td> <td>Neighbor</td>
<td align='left'>Any</td></tr> <td>Any</td></tr>
<tr><td align='center'>A</td> <tr><td>A</td>
<td align='left'>B</td> <td>B</td>
<td align='left'>ND</td> <td>ND</td>
<td align='left'>Neighbor</td> <td>Neighbor</td>
<td align='left'>Any</td></tr> <td>Any</td></tr>
<tr><td align='center'>"</td> <tr><td>"</td>
<td align='left'>C, E, F, G</td> <td>C, E, F, G</td>
<td align='left'>P-DAO 2</td> <td>P-DAO 2</td>
<td align='left'>B, C</td> <td>B, C</td>
<td align='left'>(A, 131)</td></tr> <td>(A, 131)</td></tr>
</tbody> </tbody>
</table> </table>
<t> <t>
Packets originated at A to E, F and G could be generated with the RPI and th Packets originated at A to E, F, and G could be generated with the RPI and t
e SRH, and no encapsulation. he SRH and no encapsulation.
Alternatively, A may generate a native packet to the target, and then encaps Alternatively, A may generate a native packet to the target and then encapsu
ulate it with an RPI and an SRH indicating the source-routed path leading to E, late it with an RPI and an SRH indicating the source-routed path leading to E, a
as it would for a packet that it routes coming from another node. This is effect s it would for a packet that it routes coming from another node. This is effecti
ively the same case as for packets generated by the root in a RPL network in Non vely the same case as for packets generated by the root in a RPL network in Non-
-Storing mode, see section 8.1.3 of <xref target='RFC9008'/>. The latter is ofte Storing Mode; see <xref target='RFC9008' section="8.1.3"/>. The latter is often
n preferred since it leads to a single code path, and the destination when it is preferred since it leads to a single code path, and when the destination is F or
F or G, does not need to understand and process the RPI or the SRH. 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 the y reach C, C needs to encapsulate them again Either way, the packets to E, F, or G carry an SRH via B and C, and when the y reach C, C needs to encapsulate them again
to add an SRH via D and E. to add an SRH via D and E.
The encapsulating headers of packets that are forwarded along the Track The encapsulating headers of packets that are forwarded along the Track
between C and E have the following settings: between C and E have the following settings:
</t> </t>
<table anchor="Packetcase21"><name>Packet Header Settings between C and E</name> <table anchor="Packetcase21"><name>Packet Header Settings Between C and E</name>
<thead> <thead>
<tr><th align='center'>Header</th> <tr><th align="center">Header</th>
<th align='center'>IPv6 Source Addr.</th> <th align="center">IPv6 Source Address</th>
<th align='center'>IPv6 Dest. Addr.</th> <th align="center">IPv6 Destination Address</th>
<th align='center'>TrackID in RPI</th></tr> <th align="center">TrackID in RPI</th></tr>
</thead> </thead>
<tbody> <tbody>
<tr><td align='center'>Outer</td> <tr><td align="center">Outer</td>
<td align='center'>C</td> <td align="center">C</td>
<td align='center'>D until D then E</td> <td align="center">D until D then E</td>
<td align='center'>(C, 131)</td></tr> <td align="center">(C, 131)</td></tr>
<tr><td align='center'>Inner</td> <tr><td align="center">Inner</td>
<td align='center'>X</td> <td align="center">X</td>
<td align='center'>E, F, or G</td> <td align="center">E, F, or G</td>
<td align='center'>N/A</td></tr> <td align="center">N/A</td></tr>
</tbody> </tbody>
</table> </table>
<t>As an example, say that A has a packet for F. Using the RIB in <xref target= 'RIBcase21'/>:</t> <t>As an example, say that A has a packet for F. Using the RIB in <xref target= 'RIBcase21'/>:</t>
<ul> <ul>
<li>From P-DAO 2: <li>From P-DAO 2:
A encapsulates the packet with destination of F in the Track signaled by 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 P-DAO 2. The outer header has source A, destination B, an SRH that
indicates C as the next loose hop, and a RPI indicating a TrackID of 131 indicates C as the next loose hop, and an RPI indicating a TrackID of 131
from A's namespace, which is distinct from TrackID of 131 from C's. from A's namespace, which is distinct from a TrackID of 131 from C's.
</li> </li>
<li>From the SRH: <li>From the SRH:
Packets forwarded by B have source A, destination C, a consumed SRH, and a RPI i ndicating a TrackID of 131 from A's namespace. C decapsulates. Packets forwarded by B have source A, destination C, a consumed SRH, and an RPI indicating a TrackID of 131 from A's namespace. C decapsulates.
</li> </li>
<li> <li>
From P-DAO 1: From P-DAO 1:
C encapsulates the packet with 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 n ext loose hop, and a RPI indicating a TrackID of 131 from C's namespace. E decap sulates. 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 an RPI indicating a TrackID of 131 from C's namespace. E de capsulates.
</li> </li>
</ul> </ul>
</section><!-- Stitched Tracks --> </section>
<section><name>External Routes</name> <section><name>External Routes</name>
<t>In this formulation:</t> <t>In this formulation:</t>
<ul> <ul>
<li>P-DAO 1 signals C==&gt;D==&gt;E-to-(E)</li> <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 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> <li>P-DAO 3 signals F and G via the A--&gt;E-to-F,G Track</li>
</ul> </ul>
<t> <t>
Non-Storing Mode P-DAO 1 is sent to C and Non-Storing Mode P-DAO 2 and 3 are sent to A, as follows: Non-Storing Mode P-DAO 1 is sent to C, and Non-Storing Mode P-DAOs 2 and 3 a re sent to A, as follows:
</t> </t>
<table anchor="PDAOcase22"><name>P-DAO Messages</name> <table anchor="PDAOcase22"><name>P-DAO Messages</name>
<thead> <thead>
<tr><th align='center'> </th> <tr><th> </th>
<th align='left'>P-DAO 1 to C</th> <th>P-DAO 1 to C</th>
<th align='left'>P-DAO 2 to A</th> <th>P-DAO 2 to A</th>
<th align='left'>P-DAO 3 to A</th></tr> <th>P-DAO 3 to A</th></tr>
</thead> </thead>
<tbody> <tbody>
<tr><td align='center'>Mode</td> <tr><th>Mode</th>
<td align='left'>Non-Storing</td> <td>Non-Storing</td>
<td align='left'>Non-Storing</td> <td>Non-Storing</td>
<td align='left'>Non-Storing</td></tr> <td>Non-Storing</td></tr>
<tr><td align='center'>Track Ingress</td> <tr><th>Track Ingress</th>
<td align='left'>C</td> <td>C</td>
<td align='left'>A</td> <td>A</td>
<td align='left'>A</td></tr> <td>A</td></tr>
<tr><td align='center'>(DODAGID, TrackID)</td> <tr><th>(DODAGID, TrackID)</th>
<td align='left'>(C, 131)</td> <td>(C, 131)</td>
<td align='left'>(A, 129)</td> <td>(A, 129)</td>
<td align='left'>(A, 141)</td></tr> <td>(A, 141)</td></tr>
<tr><td align='center'>SegmentID</td> <tr><th>SegmentID</th>
<td align='left'>1</td> <td>1</td>
<td align='left'>1</td> <td>1</td>
<td align='left'>1</td></tr> <td>1</td></tr>
<tr><td align='center'>VIO</td> <tr><th>VIO</th>
<td align='left'>D, E</td> <td>D, E</td>
<td align='left'>B, C</td> <td>B, C</td>
<td align='left'>E</td></tr> <td>E</td></tr>
<tr><td align='center'>Targets</td> <tr><th>Targets</th>
<td align='left'></td> <td></td>
<td align='left'>E</td> <td>E</td>
<td align='left'>F, G</td></tr> <td>F, G</td></tr>
</tbody> </tbody>
</table> </table>
<t>Note in the above that E is an implicit Target in P-DAO 1 and so is C in P-DA <t>Note in the table above that E is an implicit Target in P-DAO 1 and so is C i
O 2. n P-DAO 2.
As Non-Storing Mode Egress nodes addresses, they not listed in the respective RT As Non-Storing Mode Egress node addresses, they are not listed in the respective
Os.</t> RTOs.</t>
<t>As a result the RIBs are set as follows:</t> <t>As a result, the RIBs are set as follows:</t>
<table anchor="RIBcase22"><name>RIB setting</name> <table anchor="RIBcase22"><name>RIB Settings</name>
<thead> <thead>
<tr><th align='center'>Node</th> <tr><th>Node</th>
<th align='left'>Destination</th> <th>Destination</th>
<th align='left'>Origin</th> <th>Origin</th>
<th align='left'>Next Hop(s)</th> <th>Next Hop(s)</th>
<th align='left'>TrackID</th></tr> <th>TrackID</th></tr>
</thead> </thead>
<tbody> <tbody>
<tr><td align='center'>E</td> <tr><td>E</td>
<td align='left'>F, G</td> <td>F, G</td>
<td align='left'>ND</td> <td>ND</td>
<td align='left'>Neighbor</td> <td>Neighbor</td>
<td align='left'>Any</td></tr> <td>Any</td></tr>
<tr><td align='center'>D</td> <tr><td>D</td>
<td align='left'>E</td> <td>E</td>
<td align='left'>ND</td> <td>ND</td>
<td align='left'>Neighbor</td> <td>Neighbor</td>
<td align='left'>Any</td></tr> <td>Any</td></tr>
<tr><td align='center'>C</td> <tr><td>C</td>
<td align='left'>D</td> <td>D</td>
<td align='left'>ND</td> <td>ND</td>
<td align='left'>Neighbor</td> <td>Neighbor</td>
<td align='left'>Any</td></tr> <td>Any</td></tr>
<tr><td align='center'>"</td> <tr><td>"</td>
<td align='left'>E</td> <td>E</td>
<td align='left'>P-DAO 1</td> <td>P-DAO 1</td>
<td align='left'>D, E</td> <td>D, E</td>
<td align='left'>(C, 131)</td></tr> <td>(C, 131)</td></tr>
<tr><td align='center'>B</td> <tr><td>B</td>
<td align='left'>C</td> <td>C</td>
<td align='left'>ND</td> <td>ND</td>
<td align='left'>Neighbor</td> <td>Neighbor</td>
<td align='left'>Any</td></tr> <td>Any</td></tr>
<tr><td align='center'>A</td> <tr><td>A</td>
<td align='left'>B</td> <td>B</td>
<td align='left'>ND</td> <td>ND</td>
<td align='left'>Neighbor</td> <td>Neighbor</td>
<td align='left'>Any</td></tr> <td>Any</td></tr>
<tr><td align='center'>"</td> <tr><td>"</td>
<td align='left'>C, E</td> <td>C, E</td>
<td align='left'>P-DAO 2</td> <td>P-DAO 2</td>
<td align='left'>B, C</td> <td>B, C</td>
<td align='left'>(A, 129)</td></tr> <td>(A, 129)</td></tr>
<tr><td align='center'>"</td> <tr><td>"</td>
<td align='left'>F, G</td> <td>F, G</td>
<td align='left'>P-DAO 3</td> <td>P-DAO 3</td>
<td align='left'>E</td> <td>E</td>
<td align='left'>(A, 141)</td></tr> <td>(A, 141)</td></tr>
</tbody> </tbody>
</table> </table>
<t> <t>
The encapsulating headers of packets that are forwarded along the Track The encapsulating headers of packets that are forwarded along the Track
between C and E have the following settings: between C and E have the following settings:
</t> </t>
<table anchor="Packetcase22"><name>Packet Header Settings</name> <table anchor="Packetcase22"><name>Packet Header Settings</name>
<thead> <thead>
<tr><th align='center'>Header</th> <tr><th align="center">Header</th>
<th align='center'>IPv6 Source Addr.</th> <th align="center">IPv6 Source Address</th>
<th align='center'>IPv6 Dest. Addr.</th> <th align="center">IPv6 Destination Address</th>
<th align='center'>TrackID in RPI</th></tr> <th align="center">TrackID in RPI</th></tr>
</thead> </thead>
<tbody> <tbody>
<tr><td align='center'>Outer</td> <tr><td align="center">Outer</td>
<td align='center'>C</td> <td align="center">C</td>
<td align='center'>D until D then E</td> <td align="center">D until D then E</td>
<td align='center'>(C, 131)</td></tr> <td align="center">(C, 131)</td></tr>
<tr><td align='center'>Middle</td> <tr><td align="center">Middle</td>
<td align='center'>A</td> <td align="center">A</td>
<td align='center'>E</td> <td align="center">E</td>
<td align='center'>(A, 141)</td></tr> <td align="center">(A, 141)</td></tr>
<tr><td align='center'>Inner</td> <tr><td align="center">Inner</td>
<td align='center'>X</td> <td align="center">X</td>
<td align='center'>E, F or G</td> <td align="center">E, F, or G</td>
<td align='center'>N/A</td></tr> <td align="center">N/A</td></tr>
</tbody> </tbody>
</table> </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 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 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 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. >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: This may recurse with:
>From P-DAO 2: A encapsulates packets with dest = E. The outer header has s ource = A, destination = B, SRH = C and RPI = 129. >From P-DAO 2: A encapsulates packets with dest = E. The outer header has s ource = A, destination = B, SRH = C and RPI = 129.
Packets forwarded by B have source= A, destination = C , SRH =, and RPI = 12 9. C decapsulates. Packets forwarded by B have source= A, destination = C , SRH =, and RPI = 12 9. 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. >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. E decapsulates if encapsulated.
--> -->
<t>As an example, say that A has a packet for F. Using the RIB in <xref target= 'RIBcase22'/>:</t> <t>As an example, say that A has a packet for F. Using the RIB in <xref target= 'RIBcase22'/>:</t>
<ul> <ul>
<li> <li>
From P-DAO 3: A encapsulates the packet with destination of F in the Track signa led by P-DAO 3. The outer header has source A, destination E, and a RPI indicati ng a TrackID of 141 from A's namespace. This recurses with: From P-DAO 3: A encapsulates the packet with a destination of F in the Track sig naled by P-DAO 3. The outer header has source A, destination E, and an RPI indic ating a TrackID of 141 from A's namespace. This recurses with the following.
</li> </li>
<li> <li>
From P-DAO 2: A encapsulates the packet with destination of E in the Track signa led by P-DAO 2. The outer header has source A, destination B, an SRH that indica tes C as the next loose hop, and a RPI indicating a TrackID of 129 from A's name space. From P-DAO 2: A encapsulates the packet with a destination of E in the Track sig naled by P-DAO 2. The outer header has source A, destination B, an SRH that indi cates C as the next loose hop, and an RPI indicating a TrackID of 129 from A's n amespace.
</li> </li>
<li> <li>
From the SRH: From the SRH:
Packets forwarded by B have source A, destination C , a consumed SRH, and a RPI indicating a TrackID of 129 from A's namespace. C decapsulates. Packets forwarded by B have source A, destination C, a consumed SRH, and an RPI indicating a TrackID of 129 from A's namespace. C decapsulates.
</li> </li>
<li> <li>
From P-DAO 1: From P-DAO 1:
C encapsulates the packet with 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 n ext loose hop, and a RPI indicating a TrackID of 131 from C's namespace. E decap sulates. 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 an RPI indicating a TrackID of 131 from C's namespace. E de capsulates.
</li> </li>
</ul> </ul>
</section><!-- External routes --> </section>
<section anchor="nssr"><name>Segment Routing</name> <section anchor="nssr"><name>Segment Routing</name>
<t>In this formulation:</t> <t>In this formulation:</t>
<ul> <ul>
<li>P-DAO 1 signals C==&gt;D==&gt;E-to-(E)</li> <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 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> <li>P-DAO 3 signals F and G via the A--&gt;C--&gt;E-to-(E),F,G Track</li>
</ul> </ul>
<t> <t>
Non-Storing Mode P-DAO 1 is sent to C and Non-Storing Mode P-DAO 2 and 3 are Non-Storing Mode P-DAO 1 is sent to C, and Non-Storing Mode P-DAOs 2 and 3 a re
sent to A, as follows: sent to A, as follows:
</t> </t>
<table anchor="PDAOcase23"><name>P-DAO Messages</name> <table anchor="PDAOcase23"><name>P-DAO Messages</name>
<thead> <thead>
<tr><th align='center'> </th> <tr><th> </th>
<th align='left'>P-DAO 1 to C</th> <th>P-DAO 1 to C</th>
<th align='left'>P-DAO 2 to A</th> <th>P-DAO 2 to A</th>
<th align='left'>P-DAO 3 to A</th></tr> <th>P-DAO 3 to A</th></tr>
</thead> </thead>
<tbody> <tbody>
<tr><td align='center'>Mode</td> <tr><th>Mode</th>
<td align='left'>Non-Storing</td> <td>Non-Storing</td>
<td align='left'>Non-Storing</td> <td>Non-Storing</td>
<td align='left'>Non-Storing</td></tr> <td>Non-Storing</td></tr>
<tr><td align='center'>Track Ingress</td> <tr><th>Track Ingress</th>
<td align='left'>C</td> <td>C</td>
<td align='left'>A</td> <td>A</td>
<td align='left'>A</td></tr> <td>A</td></tr>
<tr><td align='center'>(DODAGID, TrackID)</td> <tr><th>(DODAGID, TrackID)</th>
<td align='left'>(C, 131)</td> <td>(C, 131)</td>
<td align='left'>(A, 129)</td> <td>(A, 129)</td>
<td align='left'>(A, 141)</td></tr> <td>(A, 141)</td></tr>
<tr><td align='center'>SegmentID</td> <tr><th>SegmentID</th>
<td align='left'>1</td> <td>1</td>
<td align='left'>1</td> <td>1</td>
<td align='left'>1</td></tr> <td>1</td></tr>
<tr><td align='center'>VIO</td> <tr><th>VIO</th>
<td align='left'>D, E</td> <td>D, E</td>
<td align='left'>B</td> <td>B</td>
<td align='left'>C, E</td></tr> <td>C, E</td></tr>
<tr><td align='center'>Targets</td> <tr><th>Targets</th>
<td align='left'></td> <td></td>
<td align='left'>C</td> <td>C</td>
<td align='left'>F, G</td></tr> <td>F, G</td></tr>
</tbody> </tbody>
</table> </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. <!-- 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 implicitl y AUTH: this is NSM and in NSM the egress MUST be considered a target implicitl y
Quote from section 5.3 Quote from section 5.3
In the case of an NSM-VIO, the complete list can be loose and 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 excludes the Ingress node, starting at the first loose hop and
ending at a Track Egress; the Track Egress MUST be considered as 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 an implicit Target, so it MUST NOT be signaled in a RPL Target
Option. Option.
--> -->
<t>As a result the RIBs are set as follows:</t> <t>As a result, the RIBs are set as follows:</t>
<table anchor="RIBcase23"><name>RIB setting</name> <table anchor="RIBcase23"><name>RIB Settings</name>
<thead> <thead>
<tr><th align='center'>Node</th> <tr><th>Node</th>
<th align='left'>Destination</th> <th>Destination</th>
<th align='left'>Origin</th> <th>Origin</th>
<th align='left'>Next Hop(s)</th> <th>Next Hop(s)</th>
<th align='left'>TrackID</th></tr> <th>TrackID</th></tr>
</thead> </thead>
<tbody> <tbody>
<tr><td align='center'>E</td> <tr><td>E</td>
<td align='left'>F, G</td> <td>F, G</td>
<td align='left'>ND</td> <td>ND</td>
<td align='left'>Neighbor</td> <td>Neighbor</td>
<td align='left'>Any</td></tr> <td>Any</td></tr>
<tr><td align='center'>D</td> <tr><td>D</td>
<td align='left'>E</td> <td>E</td>
<td align='left'>ND</td> <td>ND</td>
<td align='left'>Neighbor</td> <td>Neighbor</td>
<td align='left'>Any</td></tr> <td>Any</td></tr>
<tr><td align='center'>C</td> <tr><td>C</td>
<td align='left'>D</td> <td>D</td>
<td align='left'>ND</td> <td>ND</td>
<td align='left'>Neighbor</td> <td>Neighbor</td>
<td align='left'>Any</td></tr> <td>Any</td></tr>
<tr><td align='center'>"</td> <tr><td>"</td>
<td align='left'>E</td> <td>E</td>
<td align='left'>P-DAO 1</td> <td>P-DAO 1</td>
<td align='left'>D, E</td> <td>D, E</td>
<td align='left'>(C, 131)</td></tr> <td>(C, 131)</td></tr>
<tr><td align='center'>B</td> <tr><td>B</td>
<td align='left'>C</td> <td>C</td>
<td align='left'>ND</td> <td>ND</td>
<td align='left'>Neighbor</td> <td>Neighbor</td>
<td align='left'>Any</td></tr> <td>Any</td></tr>
<tr><td align='center'>A</td> <tr><td>A</td>
<td align='left'>B</td> <td>B</td>
<td align='left'>ND</td> <td>ND</td>
<td align='left'>Neighbor</td> <td>Neighbor</td>
<td align='left'>Any</td></tr> <td>Any</td></tr>
<tr><td align='center'>"</td> <tr><td>"</td>
<td align='left'>B, C</td> <td>B, C</td>
<td align='left'>P-DAO 2</td> <td>P-DAO 2</td>
<td align='left'>C</td> <td>C</td>
<td align='left'>(A, 129)</td></tr> <td>(A, 129)</td></tr>
<tr><td align='center'>"</td> <tr><td>"</td>
<td align='left'>E, F, G</td> <td>E, F, G</td>
<td align='left'>P-DAO 3</td> <td>P-DAO 3</td>
<td align='left'>C, E</td> <td>C, E</td>
<td align='left'>(A, 141)</td></tr> <td>(A, 141)</td></tr>
</tbody> </tbody>
</table> </table>
<t> <t>
The encapsulating headers of packets that are forwarded along the Track The encapsulating headers of packets that are forwarded along the Track
between A and B have the following settings: between A and B have the following settings:
</t> </t>
<table anchor="Packetcase231"><name>Packet Header Settings</name> <table anchor="Packetcase231"><name>Packet Header Settings</name>
<thead> <thead>
<tr><th align='center'>Header</th> <tr><th align="center">Header</th>
<th align='center'>IPv6 Source Addr.</th> <th align="center">IPv6 Source Address</th>
<th align='center'>IPv6 Dest. Addr.</th> <th align="center">IPv6 Destination Address</th>
<th align='center'>TrackID in RPI</th></tr> <th align="center">TrackID in RPI</th></tr>
</thead> </thead>
<tbody> <tbody>
<tr><td align='center'>Outer</td> <tr><td align="center">Outer</td>
<td align='center'>A</td> <td align="center">A</td>
<td align='center'>B until D then E</td> <td align="center">B until D then E</td>
<td align='center'>(A, 129)</td></tr> <td align="center">(A, 129)</td></tr>
<tr><td align='center'>Middle</td> <tr><td align="center">Middle</td>
<td align='center'>A</td> <td align="center">A</td>
<td align='center'>C</td> <td align="center">C</td>
<td align='center'>(A, 141)</td></tr> <td align="center">(A, 141)</td></tr>
<tr><td align='center'>Inner</td> <tr><td align="center">Inner</td>
<td align='center'>X</td> <td align="center">X</td>
<td align='center'>E, F or G</td> <td align="center">E, F, or G</td>
<td align='center'>N/A</td></tr> <td align="center">N/A</td></tr>
</tbody> </tbody>
</table> </table>
<t> <t>
The encapsulating headers of packets that are forwarded along the Track The encapsulating headers of packets that are forwarded along the Track
between B and C have the following settings: between B and C have the following settings:
</t> </t>
<table anchor="Packetcase232"><name>Packet Header Settings</name> <table anchor="Packetcase232"><name>Packet Header Settings</name>
<thead> <thead>
<tr><th align='center'>Header</th> <tr><th align="center">Header</th>
<th align='center'>IPv6 Source Addr.</th> <th align="center">IPv6 Source Address</th>
<th align='center'>IPv6 Dest. Addr.</th> <th align="center">IPv6 Destination Address</th>
<th align='center'>TrackID in RPI</th></tr> <th align="center">TrackID in RPI</th></tr>
</thead> </thead>
<tbody> <tbody>
<tr><td align='center'>Outer</td> <tr><td align="center">Outer</td>
<td align='center'>A</td> <td align="center">A</td>
<td align='center'>C</td> <td align="center">C</td>
<td align='center'>(A, 141)</td></tr> <td align="center">(A, 141)</td></tr>
<tr><td align='center'>Inner</td> <tr><td align="center">Inner</td>
<td align='center'>X</td> <td align="center">X</td>
<td align='center'>E, F or G</td> <td align="center">E, F, or G</td>
<td align='center'>N/A</td></tr> <td align="center">N/A</td></tr>
</tbody> </tbody>
</table> </table>
<t> <t>
The encapsulating headers of packets that are forwarded along the Track The encapsulating headers of packets that are forwarded along the Track
between C and E have the following settings: between C and E have the following settings:
</t> </t>
<table anchor="Packetcase233"><name>Packet Header Settings</name> <table anchor="Packetcase233"><name>Packet Header Settings</name>
<thead> <thead>
<tr><th align='center'>Header</th> <tr><th align="center">Header</th>
<th align='center'>IPv6 Source Addr.</th> <th align="center">IPv6 Source Address</th>
<th align='center'>IPv6 Dest. Addr.</th> <th align="center">IPv6 Destination Address</th>
<th align='center'>TrackID in RPI</th></tr> <th align="center">TrackID in RPI</th></tr>
</thead> </thead>
<tbody> <tbody>
<tr><td align='center'>Outer</td> <tr><td align="center">Outer</td>
<td align='center'>C</td> <td align="center">C</td>
<td align='center'>D until D then E</td> <td align="center">D until D then E</td>
<td align='center'>(C, 131)</td></tr> <td align="center">(C, 131)</td></tr>
<tr><td align='center'>Middle</td> <tr><td align="center">Middle</td>
<td align='center'>A</td> <td align="center">A</td>
<td align='center'>E</td> <td align="center">E</td>
<td align='center'>(A, 141)</td></tr> <td align="center">(A, 141)</td></tr>
<tr><td align='center'>Inner</td> <tr><td align="center">Inner</td>
<td align='center'>X</td> <td align="center">X</td>
<td align='center'>E, F or G</td> <td align="center">E, F, or G</td>
<td align='center'>N/A</td></tr> <td align="center">N/A</td></tr>
</tbody> </tbody>
</table> </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) 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 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 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='Packet case231'/>:</t> <t>As an example, say that A has a packet for F. Using <xref target='Packetcase 231'/>:</t>
<ul> <ul>
<li>From P-DAO 3: A encapsulates the packet with destination of F in the Track s ignaled by P-DAO 3. The outer header has source A, destination C, an SRH that in dicates E as the next loose hop, and a RPI indicating a TrackID of 141 from A's namespace. This recurses with: <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 an RPI indicating a TrackID of 141 from A 's namespace. This recurses with the following.
</li> </li>
<li> <li>
From P-DAO 2: A encapsulates the packet with destination of C in the Track signa led by P-DAO 2. The outer header has source A, destination B, and a RPI indicati ng a TrackID of 129 from A's namespace. B decapsulates forwards to C based on a sibling connected route. From P-DAO 2: A encapsulates the packet with a destination of C in the Track sig naled by P-DAO 2. The outer header has source A, destination B, and an RPI indic ating a TrackID of 129 from A's namespace. B decapsulates forwards to C based on a sibling connected route.
</li> </li>
<li> <li>
From the SRH: C consumes the SRH and makes the destination E. From the SRH: C consumes the SRH and makes the destination E.
</li> </li>
<li> <li>
From P-DAO 1: From P-DAO 1:
C encapsulates the packet with 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 n ext loose hop, and a RPI indicating a TrackID of 131 from C's namespace. E decap sulates. 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 an RPI indicating a TrackID of 131 from C's namespace. E de capsulates.
</li> </li>
</ul> </ul>
</section><!-- Segment Routing --> </section>
</section><!-- Using Non-Storing Mode joining Tracks --> </section>
</section><!-- Example Track Signaling --> </section>
<section anchor='concepts'><name>Complex Tracks</name> <section anchor='concepts'><name>Complex Tracks</name>
<t>To increase the reliability of the P2P transmission, this specification <t>To increase the reliability of the P2P transmission, this specification
enables building a collection of protection paths between the same Ingress an d Egress enables building a collection of protection paths between the same Ingress an d Egress
Nodes and combining them within the same TrackID, as shown in <xref Nodes and combining them within the same TrackID, as shown in <xref
target="FigLegs"/>. target="FigLegs"/>.
Protection paths may be interleaved at the edges of loose hops or remain paralle l. Protection paths may be interleaved at the edges of loose hops or remain paralle l.
</t><t> </t><t>
The segments that join the loose hops of a protection path are installed with the same 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 segme nt has its own TrackID as the protection path. But each individual protection path and segme nt has its own
P-RouteID which allows it to be managed separately. Two protection paths of t P-RouteID that allows it to be managed separately.
he same
Track may cross at a common node that participates to a segment of Each <!--[rfced] Please clarify the meaning of "participates to" in the
protection path, or may be joined by additional segments. following sentence.
Current:
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.
-->
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 The final path of a packet may then be the result of interleaving
those two (and possibly more) protection paths. those two (and possibly more) protection paths.
In that case the common node has more than one next hop in its RIB In that case, the common node has more than one next hop in its RIB
associated to the Track, but no specific signal in the packet to indicate associated to the 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 which segment is being followed. A next hop that can reach the loose hop is
selected. selected.
</t> </t>
<figure anchor="FigLegs"> <figure anchor="FigLegs">
<name>Segments and Tracks</name> <name>Segments and Tracks</name>
<artwork align="center" name="" type="" alt=""> <artwork name="" type="" alt=""><![CDATA[
<![CDATA[ < Controller Plane Functions >
< Controller Plane Functions >
Southbound API Southbound API
_-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._- _-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-
_-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._- _-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-
+----------+ +----------+
| RPL Root | | RPL Root |
+----------+ +----------+
skipping to change at line 2231 skipping to change at line 2539
<------ Segment 3 F,G,H ------> <---- Segment 4 J,E ----> <------ Segment 3 F,G,H ------> <---- Segment 4 J,E ---->
<- Protection path 2 via H, E -> <- Protection path 2 via H, E ->
<--- Segment 1 A,B ---> <- S5-> <---- Segment 4 J,E ----> <--- Segment 1 A,B ---> <- S5-> <---- Segment 4 J,E ---->
<- Protection path 3 via B, H, E -> <- Protection path 3 via B, H, E ->
) )
( (
( ) ( )]]></artwork>
]]></artwork>
</figure> </figure>
<t> <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 Note that while this specification enables building both segments inside a
protection path, for instance segment 2 above which is within protection path 1, 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 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 wh ich Inter-protection-path segments protection path 1 and protection path 2, it does not signal to the Ingress wh ich Inter-protection-path segments
are available, so the use of North-South segments and associated path redunda ncy are available, so the use of North-South segments and associated path redunda ncy
functions is currently limited. The only possibility available at this time functions is currently limited. The only possibility available at this time
is to define overlapping protection paths as illustrated in <xref target="Fig Legs"/>, is to define overlapping protection paths as illustrated in <xref target="Fig Legs"/>,
with protection path 3 that is congruent with protection path 1 until node B and congruent with protection path 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. 2 from node H on, abstracting segment 5 as a forward segment.
</t> </t>
</section> <!-- Complex Tracks --> </section>
<section anchor='inandout'><name>Scope and Expectations</name> <section anchor='inandout'><name>Scope and Expectations</name>
<section anchor='mtsch'><name>External Dependencies</name> <section anchor='mtsch'><name>External Dependencies</name>
<t> <t>
This specification expects that the main DODAG is operated in RPL This specification expects that the main DODAG is operated in RPL
Non-Storing Mode to sustain the exchanges with the Root. Based on its Non-Storing Mode to sustain the exchanges with the Root. Based on its
comprehensive knowledge of the parent-child relationship, the Root can form comprehensive knowledge of the parent-child relationship, the Root can form
an abstracted view of the whole DODAG topology. This document adds the an abstracted view of the whole DODAG topology. This document adds the
capability for nodes to advertise additional sibling information to capability for nodes to advertise additional sibling information to
complement the topological awareness of the Root to be passed on to the PCE, complement the topological awareness of the Root to be passed on to the PCE
and enable the PCE to build more / better paths that traverse those siblings and enables the PCE to build more/better paths that traverse those siblings.
.
</t><t> </t><t>
P-Routes require resources such as routing table space in the P-Routes require resources such as routing table space in the
routers and bandwidth on the links; the amount of state that 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, 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 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 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 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 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 capacity and reliability statistics are also out of scope. They may be
fetched from the nodes through network management functions or other forms fetched from the nodes through network management functions or other forms
of telemetry such as OAM. of telemetry such as Operations, Administration, and Maintenance (OAM).
</t> </t>
</section><!-- External Dependencies --> </section>
<section anchor='ietfr'><name>Positioning vs. Related IETF Standards</name>
<!-- [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 Versus Related IETF Standards</name>
<section anchor='extdep'><name>Extending 6TiSCH</name> <section anchor='extdep'><name>Extending 6TiSCH</name>
<t> <t>
The <xref target='RFC9030'> "6TiSCH Architecture"</xref> leverages a central The 6TiSCH architecture <xref target='RFC9030'></xref> leverages a centraliz
ized model that is similar to that of <xref target='RFC8655'> ed model that is similar to that of the
"Deterministic Networking Architecture"</xref>, DetNet architecture <xref target='RFC8655'></xref>,
whereby the device resources and capabilities are exposed to an external whereby the device resources and capabilities are exposed to an external
controller which installs routing states into the network based on its own controller that installs routing states into the network based on its own
objective functions that reside in that external entity. objective functions that reside in that external entity.
</t> </t>
</section><!-- Extending 6TiSCH --> </section>
<section anchor='mdet'><name>Mapping to DetNet</name> <section anchor='mdet'><name>Mapping to DetNet</name>
<t> <t>
DetNet Forwarding Nodes only understand the simple 1-to-1 forwarding DetNet Forwarding Nodes only understand the simple 1-to-1 forwarding
sublayer transport operation along a segment whereas the more sophisticated sublayer transport operation along a segment whereas the more sophisticated
Relay nodes can also provide service sublayer functions such as Replication Relay nodes can also provide service sublayer functions such as Replication
and Elimination. and Elimination.
</t> </t>
<t> <t>
One possible mapping between DetNet and this specification One possible mapping between DetNet and this specification
is to signal the Relay Nodes as the hops of a protection path and the forward ing Nodes is to signal the Relay Nodes as the hops of a protection path and the forward ing nodes
as the hops in a segment that join the Relay nodes as illustrated in <xref as the hops in a segment that join the Relay nodes as illustrated in <xref
target="FigLegs"/>. target="FigLegs"/>.
</t> </t>
</section> <!-- Mapping to DetNet --> </section>
<section anchor='pmce'><name>Leveraging PCE</name> <section anchor='pmce'><name>Leveraging PCE</name>
<t> <t>
With DetNet and 6TiSCH, the component of the controller that is responsible With DetNet and 6TiSCH, the component of the controller that is responsible
of computing routes is a PCE. The PCE for computing routes is a PCE. The PCE
computes its routes based on its own objective functions such as described computes its routes based on its own objective functions, as described
in <xref target='RFC4655'/>, and typically controls the routes using the in <xref target='RFC4655'/>, and typically controls the routes using the
PCE Protocol (PCEP) by <xref target='RFC5440'/>. While this specification PCE Communication Protocol (PCEP) <xref target='RFC5440'/>. While this spec
expects a PCE and while PCEP might effectively be used between the Root and ification
expects a 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. the PCE, the control protocol between the PCE and the Root is out of scope.
</t> </t>
<t> <t>
This specification also expects a single PCE with a full view of the 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. 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. The PCE may be This specification uses the RPL Root as a proxy to the PCE.
collocated with the Root, or may reside in an external Controller.
<!--[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 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 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 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. including all the SIOs that detail the parent/child and sibling information.
</t> </t>
<t> <t>
The algorithm to compute the paths, the protocol used by the PCE The algorithm to compute the paths, the protocol used by the PCE,
and the metrics and link statistics involved in the computation are also out 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 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. the quality of the metrics that are reported from the RPL network.
Which metrics are used and how they are reported is out of scope, but the Which metrics are used and how they are reported are out of scope, but the
expectation is that they are mostly of a long-term, statistical nature, and expectation is that they are mostly of a long-term, statistical nature and
provide visibility on link throughput, latency, stability and availability provide visibility on link throughput, latency, stability, and availability
over relatively long periods. over relatively long periods.
</t> </t>
</section> <!-- Leveraging PCE --> </section>
<section anchor='mraw'><name>Providing for RAW</name> <section anchor='mraw'><name>Providing for RAW</name>
<t> <t>
The <xref target='I-D.ietf-raw-architecture'>RAW Architecture</xref> extends
the definition of <!--[rfced] May we revise this text to be two sentences to improve
readability?
Original:
The 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 o
f
Track, as being composed of forward directional segments and North-South Track, as being composed of forward directional segments and North-South
bidirectional segments, to enable additional path diversity, using Packet AR Q, Replication, Elimination, and Overhearing (PAREO) functions over the availabl e paths, to provide a dynamic balance between the reliability and availability r equirements of the flows and the need to conserve energy and spectrum. This spec ification prepares for RAW by setting up the Tracks, but only forms DODAGs, whic h are composed of aggregated end-to-end loose source routed protection paths, j oined by strict routed segments, all oriented forward. bidirectional segments, to enable additional path diversity, using PAREO fun ctions over the available paths, to provide a dynamic balance between the reliab ility 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 protection paths, joined by strict routed segments, all oriented forward.
</t> </t>
<t> <t>
The RAW Architecture defines a dataplane extension of the PCE called the Poi nt of Local Repair (PLR), that adapts the use of the path redundancy within a Tr ack to defeat the diverse causes of packet loss. The PLR controls the forwardin g operation of the packets within a Track. The RAW architecture defines a data plane extension of the PCE called the Po int of Local Repair (PLR) that adapts the use of the path redundancy within a Tr ack to defeat the diverse causes of packet loss. The PLR controls the forwardin g operation of the packets within a Track.
This specification can use but does not impose a PLR and does not provide 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 the policies that would select which packets are routed through which
path within a Track, in other words, how the PLR may use the path redundancy path within a Track (in other words, how the PLR may use the path redundancy
within within
the Track. By default, the use of the available redundancy is limited to sim the Track). By default, the use of the available redundancy is limited to si
ple load balancing, and all the segments are forward unidirectional only. mple load balancing, and all the segments are forward unidirectional only.
</t> </t>
<t> <t>
A Track may be set up to reduce the load around the Root, or to enable A Track may be set up to reduce the load around the Root or to enable
urgent traffic to flow more directly. This specification does not provide urgent traffic to flow more directly. This specification does not provide
the policies that would decide which flows are routed through which Track. 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 In a Non-Storing Mode RPL Instance, the main DODAG provides a default route
via the Root, and the Tracks provide more specific routes to the Track via the Root, and the Tracks provide more-specific routes to the Track
Targets. Targets.
</t> </t>
</section> <!-- Providing for RAW --> </section>
</section><!-- Positioning vs. Related IETF Standards --> </section>
</section><!-- Scope and Expectations --> </section>
</section ><!-- Context and Goal --> </section >
<section anchor='ext'><name>Extending existing RFCs </name> <!-- [rfced] Should the title of this section include "Amending" as the
section discusses how this document both "Extends" and "Amends"? Or is
the current okay?
Current
4. Extending Existing RFCs
Perhaps:
4. Extending and Amending Existing RFCs
-->
<section anchor='ext'><name>Extending Existing RFCs </name>
<t> <t>
This section explains which changes are extensions to existing This section explains which changes are extensions and which are amendments
specifications, and which changes are amendments to existing to existing
specifications. specifications.
It is expected that extensions to existing specifications do not cause It is expected that extensions to existing specifications will not cause
existing code on legacy 6LRs to malfunction, as the extensions will existing code on legacy 6LRs to malfunction, as the extensions will
simply be ignored. New code is required for an extension. simply be ignored. New code is required for an extension.
Those 6LRs will be unable to participate in the new mechanisms, but may
also cause projected DAOs to be impossible to install. <!--[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 Amendments to existing specifications are situations where there are
semantic changes required to existing code, and which may require new unit semantic changes required to existing code and where new unit tests may be r
tests to confirm that legacy operations will continue unaffected. equired to
confirm that legacy operations will continue unaffected.
</t> </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> <section anchor='ext6550'><name>Extending RPL RFC 6550</name>
<t> <t>
This specification Extends RPL <xref target='RFC6550'/> to enable the Root This specification Extends RPL <xref target='RFC6550'/> to enable the Root
to install forward routes inside a main DODAG that is operated as to install forward routes inside a main DODAG that is operated as
Non-Storing Mode. The Root issues a Projected DAO (P-DAO) message Non-Storing Mode. The Root issues a P-DAO message
(see <xref target='extP-DAO'/>) to the Track Ingress; the P-DAO message (see <xref target='extP-DAO'/>) to the Track Ingress; the P-DAO message
contains a new Via Information Option (VIO) that installs a strict contains a new VIO that installs a strict
or a loose sequence of hops to form a Track segment or a or a loose sequence of hops to form a Track segment or a
protection path, respectively. protection path, respectively.
</t> </t>
<t> <t>
The P-DAO Request (PDR) is a new message detailed in <xref target='P-DAOreq' />. The P-DAO Request (PDR) is a new message detailed in <xref target='P-DAOreq' />.
As per <xref target="RFC6550" /> section 6, if a node receives this message As per <xref target="RFC6550" section="6"/>, if a node receives this message
and and
it does not understand this new Code, it then discards the message. it does not understand this new code, it discards the message.
When the Root initiates communication to a node that it has not communicated When the Root initiates communication to a node that it has not communicated
with before and which it has not ascertained to implement this specification with before and that it has not ascertained to implement this specification
(by means such as capabilities), then the Root SHOULD request (by means such as capabilities), then the Root <bcp14>SHOULD</bcp14> request
a PDR-ACK. a PDR-ACK.
</t> </t>
<t> <t>
A P-DAO Request (PDR) message A PDR message
enables a Track Ingress to request the Track from the Root. The 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, resulting Track is also a DODAG for which the Track Ingress is the Root,
the owner the address that serves as DODAGID and authoritative for the 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 associated namespace from which the TrackID is selected. In the
context of this specification, the installed route appears as a more context of this specification, the installed route appears as a more-specifi
specific route to the Track Targets, and the Track Ingress forwards c
the packets towards the Targets via the Track using normal longest route to the Track Targets, and the Track Ingress forwards
the packets toward the Targets via the Track using normal longest
match IP forwarding. match IP forwarding.
</t> </t>
<t> <t>
To ensure that the PDR and P-DAO messages can flow at most times, To ensure that the PDR and P-DAO messages can flow at most times,
it is RECOMMENDED that the nodes involved in a Track maintain it is <bcp14>RECOMMENDED</bcp14> that the nodes involved in a Track maintain
multiple parents in the main DODAG, advertise them all to the Root, multiple parents in the main DODAG, advertise them all to the Root,
and use them in turn to retry similar packets. It is also and use them in turn to retry similar packets. It is also
RECOMMENDED that the Root uses diverse source route paths to retry <bcp14>RECOMMENDED</bcp14> that the Root uses diverse source route paths to retry
similar messages to the nodes in the Track. similar messages to the nodes in the Track.
</t> </t>
<section anchor='extP-DAO'><name>Projected DAO</name> <section anchor='extP-DAO'><name>Projected DAO</name>
<t> <t>
Section 6 of <xref target='RFC6550'/> introduces the RPL Control Message <xref target='RFC6550' section="6"/> introduces the RPL Control Message
Options (CMO), including the RPL Target Option (RTO) and Transit Information Options (CMOs), including the RPL Target Option (RTO) and Transit Information
Option (TIO), which can be placed in RPL messages such as the destination Option (TIO), which can be placed in RPL messages such as the DAO. A DAO messag
Advertisement Object (DAO). A DAO message signals routing information to one e signals routing information to one
or more Targets indicated in RTOs, and provides one and only one via-node in or more Targets indicated in the RTOs and provides one and only one via-node
the TIO, the via-node being the tunnel end-point to reach the targets. in
the TIO, with the via-node being the tunnel endpoint to reach the targets.
</t> </t>
<t> <t>
This document Amends the specification of the DAO to create the P-DAO This document Amends the specification of the DAO to create the P-DAO
message. message.
This Amended DAO is signaled with a new "Projected DAO" (P) flag, see <xref target= This Amended DAO is signaled with a new "Projected DAO" (P) flag; see <xref target=
'p-dao-fmt'/>. 'p-dao-fmt'/>.
</t> </t>
<t> <t>
A Projected DAO (P-DAO) is a special DAO message generated by the A 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 Root to install a P-Route formed of multiple hops in its DODAG. This provides
a RPL-based method to install the Tracks as expected by the 6TiSCH a RPL-based method to install the Tracks as a collection of multiple
Architecture <xref target='RFC9030'/> as a collection of multiple P-Routes. P-Routes as expected by the 6TiSCH
architecture <xref target='RFC9030'/>.
</t> </t>
<t> <t>
The Root MUST source the P-DAO message with its address that serves as The Root <bcp14>MUST</bcp14> source the P-DAO message with its address that s
DODAGID for the main DODAG. The receiver MUST NOT accept a P-DAO message that erves as
is not sent by the Root of its DODAG and MUST ignore such messages silently. the DODAGID for the main DODAG. The receiver <bcp14>MUST NOT</bcp14> accept a
P-DAO message that
is not sent by the Root of its DODAG and <bcp14>MUST</bcp14> ignore such mess
ages silently.
</t> </t>
<t> <t>
The 'P' flag is encoded in bit position 2 (to be confirmed by The 'P' flag is encoded in bit position 2 of the Flags field in the DAO Base
IANA) of the Flags field in the DAO Base Object. The Root MUST set it to 1 in Object. The Root <bcp14>MUST</bcp14> set it to 1 in
a Projected DAO message. Otherwise it MUST be set to 0. It is set to 0 in a P-DAO message. Otherwise, it <bcp14>MUST</bcp14> be set to 0. It is set to
Legacy implementations as specified respectively in Sections 20.11 and 6.4 of 0 in
legacy implementations as specified, respectively, in Sections <xref target="
RFC6550" sectionFormat="bare" section="20.11"/> and <xref target="RFC6550" secti
onFormat="bare" section="6.4"/> of
<xref target='RFC6550'/>. <xref target='RFC6550'/>.
</t> </t>
<t> <t>
The P-DAO is a part of control plane signaling and should not be stuck behind high 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 sent at high traffic levels. The expectation is that the P-DAO message be sent at a high
QoS level, above that of data traffic, typically with the Network Control QoS level, above that of data traffic, typically with the Network Control
precedence. precedence.
</t> </t>
<figure anchor='p-dao-fmt'><name>Projected DAO Base Object</name> <figure anchor='p-dao-fmt'><name>Projected DAO Base Object</name>
<artwork align="center"> <artwork ><![CDATA[
0 1 2 3 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 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 | | TrackID |K|D|P| Flags | Reserved | DAOSequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| DODAGID field set to the | | DODAGID field is set to the |
+ IPv6 Address of the Track Ingress + + IPv6 address of the Track Ingress +
| used to source encapsulated packets | | used to source encapsulated packets |
IPv6 <span class="insert">address</span> of the Track Ingress +
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)... | Option(s)...
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+]]></artwork>
</artwork>
</figure> </figure>
<t> New fields:</t> <t> New fields:</t>
<dl spacing='normal'> <dl spacing='normal'>
<dt>TrackID:</dt>
<dt>TrackID:</dt> <dd> The Local or Global RPLInstanceID of the DODAG that serves as the Track
<dd> The local or global RPLInstanceID of the DODAG that serves as Track (see more in <xref target="trkid"/>).</dd>
(more in <xref target="trkid"/>). <dt>P:</dt>
<dd><t>1-bit flag.</t>
</dd> <t>The 'P' flag is set to 1 by the Root to signal a P-DAO; otherwise, it
is set to 0.</t></dd>
<dt>P:</dt>
<dd> <t>1-bit flag (position to be confirmed by IANA).</t>
<t>
The 'P' flag is set to 1 by the Root to signal a Projected DAO,
and it is set to 0 otherwise.
</t>
</dd>
</dl> </dl>
<t> <t>
The D flag is set to one to signal that the DODAGID field is present. The D flag is set to 1 to signal that the DODAGID field is present.
It may be set to zero if and only if the destination address of the P-DAO-ACK It may be set to 0 if and only if the destination address of the
message is set to the IPv6 address that serves as DODAGID and it MUST be set P-DAO-ACK message is set to the IPv6 address that serves as the DODAGID, and
to one otherwise, meaning that the DODAGID field MUST then be present. it <bcp14>MUST</bcp14> be set
to one otherwise, meaning that the DODAGID field <bcp14>MUST</bcp14> then be
present.
</t> </t>
<t> <t>
In RPL Non-Storing Mode, the TIO and RTO are combined in a DAO message to 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 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 directed parent-child relationships. The DAO message signals to the Root
that a given parent can be used to reach a given child. The P-DAO message 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 generalizes the DAO to signal to the Track Ingress that a Track for which it
is Root can be used to reach children and siblings of the Track Egress. 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 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 signal a collection of children that can be reached through the parent or
the Track, respectively. the Track, respectively.
</t> </t>
</section> <!-- Projected DAO --> </section>
<section anchor='extP-DAO-ACK'><name>Projected DAO-ACK</name> <section anchor='extP-DAO-ACK'><name>Projected DAO-ACK</name>
<t> This document also Amends the DAO-ACK message. <t> This document also Amends the DAO-ACK message.
The new P flag signals the projected form. The new P flag signals the projected form.
</t> </t>
<t> <t>
The format of the P-DAO-ACK message is thus as illustrated in The format of the P-DAO-ACK message is thus illustrated in
<xref target='p-dao-ack-fmt'/>: <xref target='p-dao-ack-fmt'/>:
</t> </t>
<figure anchor='p-dao-ack-fmt'><name>Projected DAO-ACK Base Object</name> <figure anchor='p-dao-ack-fmt'><name>Projected DAO-ACK Base Object</name>
<artwork align="center"> <artwork ><![CDATA[
0 1 2 3 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 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 | | TrackID |D|P| Reserved | DAOSequence | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| DODAGID field set to the | | DODAGID field is set to the |
+ IPv6 Address of the Track Ingress + + IPv6 address of the Track Ingress +
| used to source encapsulated packets | | used to source encapsulated packets |
IPv6 <span class="insert">address</span> of the Track Ingress +
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)... | Option(s)...
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+]]></artwork>
</artwork>
</figure> </figure>
<t> New fields:</t> <t> New fields:</t>
<dl spacing='normal'> <dl spacing='normal'>
<dt>TrackID:</dt>
<dt>TrackID:</dt> <dd> The Local or Global RPLInstanceID of the DODAG that serves as the Track
<dd> The local or global RPLInstanceID of the DODAG that serves as Track (see more in <xref target="trkid"/>).</dd>
(more in <xref target="trkid"/>). <dt>P:</dt>
<dd><t>1-bit flag.</t>
</dd> <t> The 'P' flag is set to 1 by the Root to signal a P-DAO; otherwise, it
is set to 0.</t></dd>
<dt>P:</dt>
<dd> <t>1-bit flag (position to be confirmed by IANA).</t>
<t>
The 'P' flag is set to 1 by the Root to signal a Projected DAO,
and it is set to 0 otherwise.
</t>
</dd>
</dl> </dl>
<t> <t>
The D flag is set to one to signal that the DODAGID field is present. The D flag is set to 1 to signal that the DODAGID field is present.
It may be set to zero if and only if the source address of the P-DAO-ACK It may be set to 0 if and only if the source address of the P-DAO-ACK
message is set to the IPv6 address that serves as DODAGID and it MUST be set message is set to the IPv6 address that serves as the DODAGID, and it <bcp14>
to one otherwise, meaning that the DODAGID field MUST then be present. MUST</bcp14> be set
to one otherwise, meaning that the DODAGID field <bcp14>MUST</bcp14> then be
present.
</t> </t>
</section> <!-- Projected DAO-ACK --> </section>
<section anchor='extVIO'><name>Via Information Option</name> <section anchor='extVIO'><name>Via Information Option</name>
<t> <t>
This document Extends the CMO to create new objects called the Via This document Extends the CMO to create new objects called Via
Information Options (VIO). Information Options (VIOs).
The VIOs are the multihop alternative to the TIO (more in <xref target= The VIOs are the multi-hop alternative to the TIOs (see more in <xref targ
et=
'viof'/>). 'viof'/>).
One VIO is the stateful Storing Mode VIO (SM-VIO); an SM-VIO 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 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 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 P-Route called a protection path at the Track Ingress, which uses that state to
encapsulate a packet IP-in-IP with a new Routing Header (RH) to the encapsulate an IP-in-IP packet with a new Routing Header (RH) to the
Track Egress (more in <xref target= 'routing'/>). Track Egress (see more in <xref target= 'routing'/>).
</t> </t>
<t> <t>
A P-DAO contains one or more RTOs to indicate the Target (destinations) that 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 can be reached via the P-Route, followed by exactly one VIO that signals the
sequence of nodes to be followed (more in <xref target= 'P-DAO'/>). sequence of nodes to be followed (see more in <xref target= 'P-DAO'/>).
There are two modes of operation for the P-Routes, the Storing Mode There are two modes of operation for the P-Routes: Storing Mode
and the Non-Storing Mode, see <xref target= 'sP-DAO'/> and and Non-Storing Mode (see more in Sections <xref target= 'sP-DAO' format="cou
<xref target='nsP-DAO'/> respectively for more. nter"/> and
<xref target='nsP-DAO' format="counter"/>, respectively).
</t> </t>
</section> <!-- VIA Information Option --> </section>
<section anchor='extSIO'><name>Sibling Information Option</name> <section anchor='extSIO'><name>Sibling Information Option</name>
<t> <t>
This specification Extends the CMO to create the Sibling Information Option This specification Extends the CMO to create the Sibling Information Option
(SIO). (SIO).
The SIO is used by a RPL Aware Node (RAN) to advertise a selection of its The SIO is used by a RPL-Aware Node (RAN) to advertise a selection of its
candidate neighbors as siblings to the Root (more in <xref target='rplsib'/>) candidate neighbors as siblings to the Root (see more in <xref target='rplsib
. '/>).
The SIO is placed in DAO messages that are sent directly to the main Root, 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'/>). including multicast DAO (see <xref target='RFC6550' section="9.10"/>).
</t> </t>
<t> <t>
This specification AMENDS rules 1 and 2 listed in section 9.10 of <xref targe t='RFC6550'/>) for the multicast DAO operation as follows: This specification Amends rules 1 and 2 listed in <xref target='RFC6550' sect ion="9.10"/> for the multicast DAO operation as follows:
</t> </t>
<t>OLD:</t> <t>OLD:</t>
<ol>
<li>
A node MAY multicast a DAO message to the link-local scope all-RPL-nodes m
ulticast address.
</li>
<li> A multicast DAO message MUST be used only to advertise <blockquote>
information about the node itself, i.e., prefixes directly <ol>
connected to or owned by the node, such as a multicast group that <li>A node <bcp14>MAY</bcp14> multicast a DAO message to the link-local
the node is subscribed to or a global address owned by the node scope all-RPL-nodes multicast address.</li>
</li> <li>A multicast DAO message <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>
</ol> </ol>
</blockquote>
<t>NEW:</t> <t>NEW:</t>
<ol>
<li>
A multicast DAO message MUST be used only to advertise information about
the node (using the Target Option), and direct Link Neighbors such as learned
by Neighbor Discovery (using the Sibling Information Option).
</li>
<blockquote>
<ol>
<li>A multicast DAO message <bcp14>MUST</bcp14> be used only to advertise
information about the node (using the Target Option) and direct Link
Neighbors such as learned by Neighbor Discovery (using the SIO).</li>
<li>The multicast DAO may be used to enable direct and indirect (via a common <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. 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 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 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 the sender is willing to act as a relay between those of its
neighbors that are too far apart. neighbors that are too far apart.</li>
</li>
</ol> </ol>
</blockquote>
</section> <!-- Sibling Information Option --> </section>
<section anchor='extPDR'><name>P-DAO Request</name> <section anchor='extPDR'><name>P-DAO Request</name>
<t> <t>
The set of RPL Control Messages is Extended to include the P-DAO Request (P The set of RPL Control Messages is Extended to include the PDR and P-DAO Re
DR) and P-DAO Request Acknowledgement (PDR-ACK). quest Acknowledgement (PDR-ACK).
These two new RPL Control Messages enable an RPL-Aware Node These two new RPL Control Messages enable a RAN
to request the establishment of a Track between itself as the Track Ingress to request the establishment of a Track between itself (as the Track Ingres
Node and a Track Egress. s
The node makes its request by sending a new P-DAO Request (PDR) Message to Node) and a Track Egress.
The node makes its request by sending a new PDR message to
the Root. The Root confirms with a new PDR-ACK message back to the requester the Root. The Root confirms with a new PDR-ACK message back to the requester
RAN, see <xref target='P-DAOreq'/> for more. RAN; see <xref target='P-DAOreq'/> for more.
</t> </t>
</section><!-- P-DAO Request --> </section>
<section anchor='extRPI'><name>Amending the RPI</name> <section anchor='extRPI'><name>Amending the RPI</name>
<t> <t>
Sending a Packet within a RPL Local Instance requires the presence of the Sending a packet within a RPL Local Instance requires the presence of the
abstract RPL Packet Information (RPI) described in section 11.2. of abstract RPI described in
<xref target='RFC6550'/> in the outer IPv6 Header chain <xref target='RFC6550' section="11.2"/> in the outer IPv6 header chain
(see <xref target='RFC9008'/>). (see <xref target='RFC9008'/>).
The RPI carries a local RPLInstanceID which, in association with either the The RPI carries a Local RPLInstanceID that, in association with either the
source or the destination address in the IPv6 Header, indicates the RPL source or the destination address in the IPv6 header, indicates the RPL
Instance that the packet follows. Instance that the packet follows.
</t> </t>
<t> <t>
This specification Amends <xref target='RFC6550'/> to create a new flag that signals that a packet is forwarded along a P-Route. This specification Amends <xref target='RFC6550'/> to create a new flag that signals when a packet is forwarded along a P-Route.
</t> </t>
<dl> <dl>
<dt> Projected-Route 'P':</dt><dd> 1-bit flag. It is set to 1 in the RPI <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. 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 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 Track), including when the packet follows a segment that joins loose hops
of the main DODAG. The flag is not mutable en-route.</dd> of the main DODAG. The flag is not mutable en route.</dd>
</dl> </dl>
<t>The encoding of the 'P' flag in native format is shown in <xref target='e xt6553'/> while the compressed format is indicated in <xref target='ext8138'/>. <t>The encoding of the 'P' flag in native format is shown in <xref target='e xt6553'/> while the compressed format is indicated in <xref target='ext8138'/>.
</t> </t>
</section> <!-- Extending the RPI --> </section>
<section anchor='dflag'><name>Additional Flag in the RPL DODAG Configuration Option</name> <section anchor='dflag'><name>Additional Flag in the RPL DODAG Configuration Option</name>
<t> <t>
The DODAG Configuration Option is defined in Section 6.7.6 of <xref target= The DODAG Configuration option is defined in <xref target=
'RFC6550'/>. Its purpose is extended to distribute configuration 'RFC6550' section="6.7.6"/>. Its purpose is extended to distribute configurat
ion
information affecting the construction and maintenance of the DODAG, as information affecting the construction and maintenance of the DODAG, as
well as operational parameters for RPL on the DODAG, through the DODAG. well as operational parameters for RPL on the DODAG, through the DODAG.
This Option was originally designed with 4 bit positions reserved for future use as Flags. This option was originally designed with four bit positions reserved for futu re use as Flags.
</t> </t>
<figure anchor="RPLDCO"> <figure anchor="RPLDCO">
<name>DODAG Configuration Option (Partial View) </name> <name>DODAG Configuration Option (Partial View) </name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork name="" type="" alt=""><![CDATA[
0 1 2 3 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 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| ... | | Type = 0x04 |Opt Length = 14|D| | | |A| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
|4 bits | |4 bits |]]></artwork>
]]></artwork>
</figure> </figure>
<t> <t>
This specification Amends the specification to define a new flag "Projected R
outes Support" (D). This specification Amends <xref target='RFC6550'/> to define the new "Project
ed Routes Support" (D) flag.
The 'D' flag is encoded in bit position 0 of the reserved Flags in the DODAG The 'D' flag is encoded in bit position 0 of the reserved Flags in the DODAG
Configuration Option (this is the most significant bit)(to be confirmed by Configuration option (this is the most significant bit). It is set to 0 in le
IANA but there's little choice). It is set to 0 in legacy implementations as gacy implementations as
specified respectively in Sections 20.14 and 6.7.6 of <xref target='RFC6550'/ specified respectively in Sections <xref target='RFC6550' sectionFormat="bare
>. " section="20.14"/> and <xref target='RFC6550' sectionFormat="bare" section="6.7
.6"/> of <xref target='RFC6550'/>.
</t> </t>
<t> <t>
The 'D' flag is set to 1 to indicate that this specification is enabled in 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 the network and that the Root will install the requested Tracks when feasible
upon a PDR message. upon receiving a PDR message.
</t> </t>
<t> <t>
Section 4.1.2. of <xref target='RFC9008'/> Amends <xref target='RFC9008' section="4.1.2"/> Amends
<xref target='RFC6550'/> to indicate that the definition of the Flags applies <xref target='RFC6550'/> to indicate that the definition of the Flags applies
to Mode of Operation values from zero (0) to six (6) only. to MOP values from zero (0) to six (6) only.
For a MOP value of 7, the implementation MUST consider that the Root For a MOP value of 7, the implementation <bcp14>MUST</bcp14> consider that th
accepts PDR messages and will install Projected Routes. e Root
accepts PDR messages and will install P-Routes.
</t> </t>
<t> <t>
The RPL DODAG Configuration option is typically placed in a DODAG The RPL DODAG Configuration option is typically placed in a DIO message. The
Information Object (DIO) message. The DIO message propagates down DIO message propagates down
the DODAG to form and then maintain its structure. The DODAG the DODAG to form and then maintain its structure. The DODAG
Configuration option is copied unmodified from parents to children. Configuration option is copied unmodified from parents to children.
</t> </t>
<t> <t>
<xref target='RFC6550'/> states that: <xref target='RFC6550'/> states that:
</t> </t>
<blockquote> <blockquote>
Nodes other than the DODAG root MUST NOT modify this information when propaga ting the DODAG Configuration option. Nodes other than the DODAG root <bcp14>MUST NOT</bcp14> modify this informati on when propagating the DODAG Configuration option.
</blockquote> </blockquote>
<t> <t>
Therefore, a legacy parent propagates the 'D' flag as set 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 by the root, and when the 'D' flag is set to 1, it is transparently
flooded to all the nodes in the DODAG. flooded to all the nodes in the DODAG.
</t> </t>
</section><!-- New Flag in the RPL DODAG Configuration Option --> </section>
</section> <!-- Extending RFC 6550 --> </section>
<section anchor='ext6553'><name>Extending RPL RFC 6553</name> <section anchor='ext6553'><name>Extending RPL RFC 6553</name>
<t> <t>
<xref target='RFC6553'>"The RPL Option for Carrying RPL Information in Data- "The Routing Protocol for Low-Power and Lossy Networks (RPL) Option
Plane Datagrams"</xref> describes the RPL Option for use among RPL routers to in for Carrying RPL Information in Data-Plane Datagrams" <xref target="RFC6553"/
clude the abstract RPL Packet Information (RPI) described in section 11.2. of <x > describes the RPL Option for use among RPL routers to include the abstract RPI
ref target='RFC6550'/> in data packets. described in <xref target='RFC6550' section="11.2"/> in data packets.
</t> <t> </t> <t>
The RPL Option is commonly referred to as the RPI though the RPI is really t he abstract information that is transported in the RPL Option. <xref target='RFC 9008'/> updated the Option Type from 0x63 to 0x23. The RPL Option is commonly referred to as the RPI even though the RPI is rea lly the abstract information that is transported in the RPL Option. <xref target ='RFC9008'/> updated the Option Type from 0x63 to 0x23.
</t> <t> </t> <t>
This specification Extends the RPL Option to encode the 'P' flag as follows: This specification Extends the RPL Option to encode the 'P' flag as follows:
</t> </t>
<figure anchor='Rpifmt'><name>Amended RPL Option Format</name> <figure anchor='Rpifmt'><name>Amended RPL Option Format</name>
<artwork align="center"> <artwork ><![CDATA[
0 1 2 3 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 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 | | Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O|R|F|P|0|0|0|0| RPLInstanceID | SenderRank | |O|R|F|P|0|0|0|0| RPLInstanceID | SenderRank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (sub-TLVs) | | (sub-TLVs) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</artwork>
</figure> </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'> <dl spacing='normal'>
<dt>Option Type:</dt><dd>0x23 or 0x63, see <xref target='RFC9008'/ > <dt>Option Type:</dt><dd>0x23 or 0x63; see <xref target='RFC9008'/ >.
</dd> </dd>
<dt>Opt Data Len:</dt><dd> See <xref target='RFC6553'/> <dt>Opt Data Len:</dt><dd> See <xref target='RFC6553'/>.
</dd> </dd>
<dt>'O', 'R' and 'F' flags:</dt><dd> See <xref target='RFC6553'/>. <dt>'O', 'R', and 'F' flags:</dt><dd> See <xref target='RFC6553'/>
Those flags MUST be set to 0 by the sender and ignored by the .
These flags <bcp14>MUST</bcp14> be set to 0 by the sender and igno
red by the
receiver if the 'P' flag is set. receiver if the 'P' flag is set.
</dd> </dd>
<dt> Projected-Route 'P':</dt><dd> 1-bit flag as defined in <xref target='extRPI'/>. <dt> Projected-Route 'P':</dt><dd> 1-bit flag as defined in <xref target='extRPI'/>.
</dd> </dd>
<dt>RPLInstanceID:</dt><dd> See <xref target='RFC6553'/>. Indicate s the TrackID if the 'P' flag is set, as discussed in <xref target='extP-DAO'/>. <dt>RPLInstanceID:</dt><dd> See <xref target='RFC6553'/>. Indicate s the TrackID if the 'P' flag is set, as discussed in <xref target='extP-DAO'/>.
</dd> </dd>
<dt>SenderRank:</dt><dd> See <xref target='RFC6553'/>. This <dt>SenderRank:</dt><dd> See <xref target='RFC6553'/>. This
field MUST be set to 0 by the sender and ignored by the receiver field <bcp14>MUST</bcp14> be set to 0 by the sender and ignored by the receiver
if the 'P' flag is set. if the 'P' flag is set.
</dd> </dd>
</dl> </dl>
</section> <!-- Extending RFC 6553 --> </section>
<section anchor='ext8138'><name>Extending RPL RFC 8138</name> <section anchor='ext8138'><name>Extending RPL RFC 8138</name>
<t> The <xref target='RFC8138'>6LoWPAN Routing Header</xref> specification
introduces a new IPv6 over Low-Power Wireless Personal Area Network <t> The 6LoWPAN Routing Header specification <xref target='RFC8138'/>
(6LoWPAN) <xref target='RFC6282'/> dispatch type for use in 6LoWPAN introduces a new 6LoWPAN <xref target='RFC6282'/> dispatch type for use in 6
LoWPAN
route-over topologies, which initially covers the needs of RPL data packet route-over topologies, which initially covers the needs of RPL data packet
compression. compression.
</t> </t>
<t>Section 4 of <xref target='RFC8138'/> presents the generic formats of <t><xref target='RFC8138' section="4"/> presents the generic formats of
the 6LoWPAN Routing Header (6LoRH) with two forms, one Elective that can the 6LoRH in two forms: Elective, which can
be ignored and skipped when the router does not understand it, and one be ignored and skipped when the router does not understand it, and
Critical which causes the packet to be dropped when the router cannot Critical, which causes the packet to be dropped when the router cannot
process it. The 'E' Flag in the 6LoRH indicates its form. In order to skip process it. The 'E' flag in the 6LoRH indicates its form. In order to skip
the Elective 6LoRHs, their format imposes a fixed expression of the size, 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 whereas the size of a Critical 6LoRH may be signaled in variable forms to
enable additional optimizations. enable additional optimizations.
</t> </t>
<t>When the <xref target='RFC8138'/> compression is used, the Root of the <t>When compression as described in <xref target='RFC8138'/> is used, the Ro ot of the
main DODAG that sets up the Track also constructs the compressed routing main DODAG that sets up the Track also constructs the compressed routing
header (SRH-6LoRH) on behalf of the Track Ingress, which saves the header (SRH-6LoRH) on behalf of the Track Ingress, which avoids the
complexities of optimizing the SRH-6LoRH encoding in constrained code. complexities of optimizing 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 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. to be placed as is in the packet encapsulation by the Track Ingress.
</t> </t>
<t>Section 6.3 of <xref target='RFC8138'/> presents the formats of the <t><xref target='RFC8138' section="6.3"/> presents the formats of the
6LoWPAN Routing Header of type 5 (RPI-6LoRH) that compresses the RPI for 6LoWPAN RH of type 5 (RPI-6LoRH) that compresses the RPI for
normal RPL operation. The format of the RPI-6LoRH is not suited for normal RPL operation. The format of the RPI-6LoRH is not suited for
P-Routes since the O,R,F flags are not used and the Rank is unknown and P-Routes since the O, R, and F flags are not used and the Rank is unknown an d
ignored. ignored.
</t><t> </t><t>
This specification extends <xref target="RFC8138" /> to introduce a new 6LoR This specification Extends <xref target="RFC8138"/> to introduce a new 6LoRH
H, the P-RPI-6LoRH that can be , the P-RPI-6LoRH, that can be
used in either Elective or Critical 6LoRH form, used in either Elective or Critical 6LoRH form;
see <xref target='elec6lorhtbl'/> and <xref target='crit6lorhtbl'/> see Tables <xref target='elec6lorhtbl' format="counter"/> and <xref target='
respectively. The new 6LoRH MUST be used as a Critical 6LoRH, unless an SRH- crit6lorhtbl' format="counter"/>,
6LoRH is present and controls the routing decision, in which case it respectively. The new 6LoRH <bcp14>MUST</bcp14> be used as a Critical 6LoRH,
MAY be used in Elective form. unless an SRH-6LoRH is present and controls the routing decision, in which case
it
<bcp14>MAY</bcp14> be used in Elective form.
</t> </t>
<t> <t>
The P-RPI-6LoRH is designed to compress the RPI along RPL P-Routes. The P-RPI-6LoRH is designed to compress the RPI along RPL P-Routes.
Its format is as follows: Its format is as follows:
</t> </t>
<figure anchor='PRpifmt'><name>P-RPI-6LoRH Format</name> <figure anchor='PRpifmt'><name>P-RPI-6LoRH Format</name>
<artwork align="center"> <artwork ><![CDATA[
0 1 2 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 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 | |1|0|E| Length | 6LoRH Type | RPLInstanceID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</artwork>
</figure> </figure>
<!--[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'> <dl spacing='normal'>
<dt> Type:</dt><dd> IANA is requested to define the same value of <dt>6LoRH Type:</dt><dd> IANA has defined the value 8
the type for both Elective and Critical forms. A type of 8 is sugg for both the Elective and Critical forms.
ested.
</dd> </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 w hen forwarding. <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 w hen forwarding.
</dd> </dd>
<dt> RPLInstanceID :</dt><dd> In the context of this specification , the RPLInstanceID field signals the TrackID, see <xref target='tracks'/> and < xref target='trkid'/> . <dt> RPLInstanceID :</dt><dd> In the context of this specification , the RPLInstanceID field signals the TrackID; see Sections <xref target='tracks ' format="counter"/> and <xref target='trkid' format="counter"/>.
</dd> </dd>
</dl> </dl>
<t> <xref target='encompression'/> details how a Track Ingress leverages <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 the P-RPI-6LoRH Header as part of the encapsulation of a packet to place it
into a Track. into a Track.
</t> </t>
</section> <!-- Extending RFC 8138 --> </section>
</section><!-- Extending existing RFCs --> </section>
<section anchor='rplccmo'><name>New RPL Control Messages and Options</name> <section anchor='rplccmo'><name>New RPL Control Messages and Options</name>
<section anchor='P-DAOreq'><name>New P-DAO Request Control Message</name> <section anchor='P-DAOreq'><name>New P-DAO Request Control Message</name>
<t> <t>
The P-DAO Request (PDR) message is sent by a Node in the main DODAG to the The PDR message is sent by a node in the main DODAG to the
Root. It is a request to establish or refresh a Track where the node Root. It is a request to establish or refresh a Track where the node
sending the PDR is sending the PDR is the
Track Ingress, and signals whether an acknowledgment called PDR-ACK is Track Ingress, and it signals whether or not an acknowledgment called PDR-ACK
requested or not. A positive PDR-ACK indicates that the Track was built is
requested. A positive PDR-ACK indicates that the Track was built
and that the Root commits to maintaining the Track for the negotiated lifetim e. and that the Root commits to maintaining the Track for the negotiated lifetim e.
</t> </t>
<t> <t>
The main Root MAY indicate to the Track Ingress that the Track was terminated The main Root <bcp14>MAY</bcp14> indicate to the Track Ingress that the Track
before its time and to do so, it MUST use an asynchronous PDR-ACK with a was terminated
before its time; to do so, it <bcp14>MUST</bcp14> use an asynchronous PDR-ACK
with a
negative status. negative status.
A status of "Transient Failure" (see <xref target= A status of "Transient Failure" (see <xref target=
"iana-stats-rej"/>) is an indication that the PDR may be retried after a "iana-stats-rej"/>) is an indication that the PDR may be retried after a
reasonable time that depends on the deployment. Other negative status reasonable time that depends on the deployment. Other negative status
values indicate a permanent error; the attempt must be abandoned until values indicate a permanent error; the attempt must be abandoned until
a corrective action is taken at the application layer or through network a corrective action is taken at the application layer or through network
management. management.
</t> </t>
<t> <t>
The Track Ingress to-be of the requested Track is indicated in the source IP v6 The Track Ingress to be of the requested Track is indicated in the source IP v6
address of the PDR, and the TrackID is indicated in the message itself. address of the PDR, and the TrackID is indicated in the message itself.
At least one RPL Target Option MUST be present in the message. If more than At least one RPL Target Option <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 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 the first listed Target and a subset of the other Targets; the details of the
subset selection are out of scope. subset selection are out of scope.
The RTO signals the Track Egress (more in <xref target='req'/>). The RTO signals the Track Egress (see more in <xref target='req'/>).
<!-- <!--
TODO: A P-DAO parameter option MAY be present as well to provide additional TODO: A P-DAO parameter option MAY be present as well to provide additional
information on the requested path. information on the requested path.
--> -->
</t> </t>
<t> <t>
The RPL Control Code for the PDR is 0x09, to be confirmed by IANA. The RPL Control Code for the PDR is 0x09.
The format of PDR Base Object is as follows: The format of the PDR Base Object is as follows:
</t> </t>
<figure anchor='disupdfmt'><name>New P-DAO Request Format</name> <figure anchor='disupdfmt'><name>New P-DAO Request Format</name>
<artwork align="center"> <artwork ><![CDATA[
0 1 2 3 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 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 | | TrackID |K|R| Flags | ReqLifetime | PDRSequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)... | Option(s)...
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+]]></artwork>
</artwork>
</figure> </figure>
<dl spacing='normal'> <dl spacing='normal'>
<dt>TrackID:</dt><dd>8-bit field. <dt>TrackID:</dt><dd>8-bit field.
In the context of this specification, the TrackID field signals th e RPLInstanceID of the DODAG formed by the Track, see <xref target='tracks'/> an d <xref target='trkid'/>. To allocate a In the context of this specification, the TrackID field signals th e RPLInstanceID of the DODAG formed by the Track; see Sections <xref target='tra cks' format="counter"/> and <xref target='trkid' format="counter"/>. To allocate a
new Track, the Ingress Node must provide a value that is not in new Track, the Ingress Node must provide a value that is not in
use at this time. use at this time.
</dd> </dd>
<dt>K:</dt><dd>The 'K' flag is set to indicate that the recipient <dt>K:</dt><dd>The 'K' flag is set to indicate that the recipient
is expected to send a PDR-ACK back. is expected to send a PDR-ACK back.
</dd> </dd>
<dt>R:</dt><dd>The 'R' flag is set to request a Complex Track <dt>R:</dt><dd>The 'R' flag is set to request a Complex Track
for redundancy. for redundancy.
</dd> </dd>
<dt>Flags:</dt><dd>Reserved. The Flags field MUST be initialized t o zero by the sender and MUST be ignored by the receiver. <dt>Flags:</dt><dd>Reserved. The Flags field <bcp14>MUST</bcp14> b e initialized to zero by the sender and <bcp14>MUST</bcp14> be ignored by the re ceiver.
</dd> </dd>
<dt>ReqLifetime:</dt><dd> <t>8-bit unsigned integer. <dt>ReqLifetime:</dt><dd> <t>8-bit unsigned integer.
The requested lifetime for the Track expressed in Lifetime Units The requested lifetime for the Track expressed in Lifetime Units
(obtained from the DODAG Configuration option). The value (obtained from the DODAG Configuration option). The value
of 255 (0xFF) represents infinity (never time out). of 255 (0xFF) represents infinity (never time out).
</t><t> </t><t>
A PDR with a fresher A PDR with a fresher
PDRSequence refreshes the lifetime, and a PDRLifetime of 0 PDRSequence refreshes the lifetime, and a PDRLifetime of 0
indicates that the Track MUST be destroyed, e.g., when the indicates that the Track <bcp14>MUST</bcp14> be destroyed, e.g., w hen the
application that requested the Track terminates. application that requested the Track terminates.
</t> </t>
</dd> </dd>
<dt>PDRSequence:</dt><dd> <dt>PDRSequence:</dt><dd>
<t>8-bit wrapping sequence number, <t>8-bit wrapping sequence number,
obeying the operation in section 7.2 of obeying the operation in
<xref target='RFC6550'/>. <xref target='RFC6550' section="7.2"/>.
The PDRSequence is used to correlate a PDR-ACK message with the The PDRSequence is used to correlate a PDR-ACK message with the
PDR message that triggered it. It is incremented at each PDR PDR message that triggered it. It is incremented at each PDR
message and echoed in the PDR-ACK by the Root. message and echoed in the PDR-ACK by the Root.
</t> </t>
</dd> </dd>
</dl> </dl>
</section> <!-- New P-DAO Request Control Message --> </section>
<section anchor='rpldisackl'><name>New PDR-ACK Control Message</name> <section anchor='rpldisackl'><name>New PDR-ACK Control Message</name>
<t> <t>
The new PDR-ACK is sent as a response to a PDR message with the 'K' flag The new PDR-ACK is sent as a response to a PDR message with the 'K' flag
set. set.
The RPL Control Code for the PDR-ACK is 0x0A, to be confirmed by IANA. The RPL Control Code for the PDR-ACK is 0x0A.
Its format is as follows: Its format is as follows:
</t> </t>
<figure anchor='disackfmt'><name>New PDR-ACK Control Message Format</name> <figure anchor='disackfmt'><name>New PDR-ACK Control Message Format</name>
<artwork align="center"> <artwork ><![CDATA[
0 1 2 3 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 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 | | TrackID | Flags | Track Lifetime| PDRSequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PDR-ACK Status| Reserved | | PDR-ACK Status| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)... | Option(s)...
+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+]]></artwork>
</artwork>
</figure> </figure>
<dl spacing='normal'> <dl spacing='normal'>
<dt>TrackID:</dt><dd> <dt>TrackID:</dt><dd>
Set to the TrackID indicated in the TrackID field of the PDR Set to the TrackID indicated in the TrackID field of the PDR
messages that this replies to. messages that this replies to.
</dd> </dd>
<dt>Flags:</dt><dd>Reserved. The Flags field MUST be initialized t o zero by the sender and MUST be ignored by the receiver. <dt>Flags:</dt><dd>Reserved. The Flags field <bcp14>MUST</bcp14> b e initialized to zero by the sender and <bcp14>MUST</bcp14> be ignored by the re ceiver.
</dd> </dd>
<dt>Track Lifetime:</dt><dd> <dt>Track Lifetime:</dt><dd>
Indicates the remaining Lifetime for the Track, expressed in Indicates the remaining lifetime for the Track, expressed in
Lifetime Units; The value Lifetime Units. The value
of 255 (0xFF) represents infinity. The value of zero (0x00) of 255 (0xFF) represents infinity. The value of zero (0x00)
indicates that the Track was destroyed or not created. indicates that the Track was destroyed or not created.
</dd> </dd>
<dt>PDRSequence:</dt><dd> 8-bit wrapping sequence number. <dt>PDRSequence:</dt><dd> 8-bit wrapping sequence number.
It is incremented at each PDR message and echoed in the PDR-ACK. It is incremented at each PDR message and echoed in the PDR-ACK.
</dd> </dd>
<dt>PDR-ACK Status:</dt><dd> <t>8-bit field indicating <dt>PDR-ACK Status:</dt><dd> <t>8-bit field indicating
the completion. the completion.
The PDR-ACK Status is substructured as indicated in <xref target='rp st'/>:</t> The PDR-ACK Status is substructured as indicated in <xref target='rp st'/>:</t>
<figure anchor='rpst' suppress-title='false'><name>PDR-ACK status Format</name> <figure anchor='rpst' suppress-title='false'><name>PDR-ACK Status Format</name>
<artwork align="center" name="" type="" alt=""> <artwork name="" type="" alt=""><![CDATA[
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|E|R| Value | |E|R| Value |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+]]></artwork>
</artwork>
</figure> </figure>
<dl spacing='compact'> <dl 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 <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 and other values indicate "not an indicates Success/Unqualified Acceptance, and other values indicate "not an
outright rejection".</dd> outright rejection".</dd>
<dt>R:</dt><dd> 1-bit flag. Reserved, MUST be set to 0 by the sender and <dt>R:</dt><dd> 1-bit flag. Reserved; <bcp14>MUST</bcp14> be set to 0 by the sender and
ignored by the receiver.</dd> ignored by the receiver.</dd>
<dt>Status Value:</dt><dd> 6-bit unsigned integer. Values depending on th <dt>Status Value:</dt><dd> 6-bit unsigned integer. Values depend on the
e setting of the 'E' flag; see Tables
setting of the 'E' flag, see <xref target='iana-ack-status' format="counter"/> and <xref target='iana-nac
<xref target='iana-ack-status'/> and <xref target='iana-nack-status'/>. k-status' format="counter"/>.
</dd> </dd>
</dl> </dl>
</dd> </dd>
<dt>Reserved:</dt><dd>The Reserved field MUST be initialized to zero by the <dt>Reserved:</dt><dd>The Reserved field <bcp14>MUST</bcp14> be initialized
sender and MUST be ignored by the receiver. to zero by the
sender and <bcp14>MUST</bcp14> be ignored by the receiver.
</dd> </dd>
</dl> </dl>
</section> <!-- New PDR-ACK Control Message --> </section>
<section anchor='viof'><name>Via Information Options</name> <section anchor='viof'><name>Via Information Options</name>
<t>A VIO signals the ordered list of IPv6 Via Addresses that constitutes <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 the hops of either a protection path (using Non-Storing Mode) or a segment ( using Storing
mode) of a Track. A Storing Mode P-DAO contains one Storing Mode VIO Mode) of a Track. A Storing Mode P-DAO contains one
(SM-VIO) whereas a Non-Storing Mode P-DAO contains one Non-Storing Mode VIO SM-VIO whereas a Non-Storing Mode P-DAO contains one
(NSM-VIO). NSM-VIO.
</t><t> </t><t>
The duration of the validity of a VIO is indicated in a segment Lifetime The duration of the validity of a VIO is indicated in a Segment Lifetime
field. A P-DAO message that contains a VIO with a segment Lifetime of zero field. A P-DAO message that contains a VIO with a Segment Lifetime of 0
is referred as a No-Path P-DAO. is referred as a No-Path P-DAO.
</t><t> </t><t>
The VIO contains one or more SRH-6LoRH header(s), each formed of a The VIO contains one or more SRH-6LoRH headers, each formed of an
SRH-6LoRH head and a collection of compressed Via Addresses, except in the 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 case of a Non-Storing Mode No-Path P-DAO where the SRH-6LoRH header is not
present. present.
</t><t> </t><t>
In the case of a SM-VIO, or if <xref target='RFC8138'/> is not used in the d ata packets, then the Root MUST use only one SRH-6LoRH per Via Information Optio n, and the compression is the same for all the addresses, as shown in <xref targ et='viao'/>, for simplicity. In the case of an SM-VIO, or if <xref target='RFC8138'/> is not used in the data packets, then the Root <bcp14>MUST</bcp14> use only one SRH-6LoRH per Via I nformation Option, and the compression is the same for all the addresses, as sho wn in <xref target='viao'/>, for simplicity.
</t><t> </t><t>
In case of an NSM-VIO and if <xref target='RFC8138'/> is in use in the main In case of an NSM-VIO, and if <xref target='RFC8138'/> is in use in the main
DODAG, the Root SHOULD optimize the size of the NSM-VIO if using different DODAG, the Root <bcp14>SHOULD</bcp14> optimize the size of the NSM-VIO if us
ing different
SRH-6LoRH Types would make the VIO globally shorter; this means that more th an one SRH-6LoRH may be present. SRH-6LoRH Types would make the VIO globally shorter; this means that more th an one SRH-6LoRH may be present.
</t> </t>
<t> <t>
The format of the Via Information Option is as follows: The format of the VIO is as follows:
</t> </t>
<figure anchor='viao'><name>VIO format</name> <figure anchor='viao'><name>VIO Format</name>
<artwork align="center"> <artwork ><![CDATA[
0 1 2 3 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 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 | | Option Type | Option Length | Flags | P-RouteID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Segm. Sequence | Seg. Lifetime | SRH-6LoRH head | | Seg. Sequence | Seg. Lifetime | SRH-6LoRH head |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. Via Address 1 (compressed by RFC 8138) . . Via Address 1 (compressed by RFC 8138) .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. .... . . .... .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. Via Address n (compressed by RFC 8138) . . Via Address n (compressed by RFC 8138) .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. Additional SRH-6LoRH Header(s) . . Additional SRH-6LoRH header(s) .
| | | |
. .... . . .... .]]></artwor
k>
</artwork>
</figure> </figure>
<dl spacing='normal'> <dl spacing='normal'>
<dt>Option Type:</dt><dd>0x0E for SM-VIO, 0x0F for NSM-VIO
(to be confirmed by IANA) (see <xref target <dt>Option Type:</dt><dd>0x0F for SM-VIO and 0x10 for NSM-VIO
="ianaRPLCtrlMsgopttbl"/>).</dd> (see <xref target="ianaRPLCtrlMsgopttbl"/>).</dd>
<dt>Option Length:</dt><dd>8-bit unsigned integer, representing th e length in octets of the option, not including the Option <dt>Option Length:</dt><dd>8-bit unsigned integer, representing th e length in octets of the option, not including the Option
Type and Length fields (see section 6.7.1. of <xref target= Type and Length fields (see <xref target=
'RFC6550'/>); 'RFC6550' section="6.7.1"/>);
the Option Length is variable, depending on the number of Via the Option Length is variable, depending on the number of Via
Addresses and the compression applied.</dd> Addresses and the compression applied.</dd>
<dt>Flags:</dt><dd>8-bit field. No flag is defined in this <dt>Flags:</dt><dd>8-bit field. No flag is defined in this
specification. The field MUST be set to 0 by the sender and specification. The field <bcp14>MUST</bcp14> be set to 0 by the s ender and
ignored by the receiver.</dd> ignored by the receiver.</dd>
<dt>P-RouteID:</dt><dd>8-bit field that identifies a component <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. 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 The value of 0 is used to signal a path, i.e., made of a
single segment/protection path. single segment/protection path.
In an SM-VIO, the P-RouteID indicates a Segment ID. 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 a dded In an NSM-VIO, it indicates the ID of a protection path that is a dded
(or updated) to the overall topology of the Track. (or updated) to the overall topology of the Track.
</dd> </dd>
<dt>Segment Sequence:</dt><dd> <dt>Segment Sequence:</dt><dd>
<t>8-bit unsigned integer. <t>8-bit unsigned integer.
The Segment Sequence obeys the operation in section 7.2 of The Segment Sequence obeys the operation in
<xref target='RFC6550'/> and the initial value is 255. <xref target='RFC6550' section="7.2"/>, and the initial value is 2
55.
</t><t> </t><t>
When the When the
Root of the DODAG needs to refresh or update a segment in a Track, Root of the DODAG needs to refresh or update a segment in a Track,
it increments the Segment Sequence individually for that segment. it increments the Segment Sequence individually for that segment.
</t><t> </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 The segment information indicated in the VIO deprecates any state
for the segment indicated by the P-RouteID within the indicated for the segment indicated by the P-RouteID within the indicated
Track and sets up the new information. Track and sets up the new information.
</t><t> </t><t>
A VIO with a Segment Sequence that is not as fresh as the current A VIO with a Segment Sequence that is not as fresh as the current
one is ignored. one is ignored.
</t><t> </t><t>
A VIO for a given DODAGID with the same (TrackID, A VIO for a given DODAGID with the same (TrackID,
P-RouteID, Segment Sequence) indicates a retry; it MUST NOT P-RouteID, Segment Sequence) indicates a retry; it <bcp14>MUST NOT
change the segment and MUST be propagated or answered as the first </bcp14>
change the segment and <bcp14>MUST</bcp14> be propagated or answer
ed as the first
copy. copy.
</t> </t>
</dd> </dd>
<dt>Segment Lifetime:</dt><dd> <dt>Segment Lifetime:</dt><dd>
<t>8-bit unsigned integer. The length <t>8-bit unsigned integer. The length
of time in Lifetime Units (obtained from the Configuration of time in Lifetime Units (obtained from the Configuration
option) that the segment is usable. option) that the segment is usable.
</t><t> </t><t>
skipping to change at line 3138 skipping to change at line 3597
<t>8-bit unsigned integer. The length <t>8-bit unsigned integer. The length
of time in Lifetime Units (obtained from the Configuration of time in Lifetime Units (obtained from the Configuration
option) that the segment is usable. option) that the segment is usable.
</t><t> </t><t>
The period starts when a new Segment Sequence is seen. The value The period starts when a new Segment Sequence is seen. The value
of 255 (0xFF) represents infinity. The value of zero (0x00) of 255 (0xFF) represents infinity. The value of zero (0x00)
indicates a loss of reachability. indicates a loss of reachability.
</t> </t>
</dd> </dd>
<dt>SRH-6LoRH head:</dt><dd>The first 2 bytes of the (first) <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 SRH-6LoRH as shown in Figure 6 of <xref target='RFC8138'/>. As an
example, a 6LoRH Type of 4 means that the VIA Addresses are example, a 6LoRH Type of 4 means that the Via Addresses are
provided in full with no compression. provided in full with no compression.
</dd> </dd>
<dt>Via Address:</dt><dd> <dt>Via Address:</dt><dd>
<t>An IPv6 ULA or GUA of a node along the segment. <t>An IPv6 ULA or GUA of a node along the segment.
The VIO contains one or The VIO contains one or
more IPv6 Via Addresses listed in the datapath order from Ingress more IPv6 Via Addresses listed in the datapath order from Ingress
to Egress. The list is expressed in a compressed form as signaled to Egress. The list is expressed in a compressed form as signaled
by the preceding SRH-6LoRH header. by the preceding SRH-6LoRH header.
</t><t> </t><t>
In a Storing Mode P-DAO that updates or removes a section of an 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 already existing segment, the list in the SM-VIO may represent
only the section of the segment that is being updated; at the only the section of the segment that is being updated; at the
extreme, the SM-VIO updates only one node, in which case it extreme, the SM-VIO updates only one node, in which case it
contains only one IPv6 address. contains only one IPv6 address.
In all other cases, the list in the VIO MUST be complete. In all other cases, the list in the VIO <bcp14>MUST</bcp14> be com plete.
</t><t> In the case of an SM-VIO, the list indicates a sequential </t><t> In the case of an SM-VIO, the list indicates a sequential
(strict) path through direct neighbors, the complete list starts (strict) path through direct neighbors; the complete list starts
at Ingress and ends at Egress, and the nodes listed in the VIO, at the Ingress and ends at the Egress, and the nodes listed in the
including the Egress, MAY be considered as implicit Targets. VIO,
including the Egress, <bcp14>MAY</bcp14> be considered as implicit
Targets.
</t><t> </t><t>
In the case of an NSM-VIO, the complete list can be loose and 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 excludes the Ingress node, starting at the first loose hop and
ending at a Track Egress; the Track Egress MUST be considered as ending at a Track Egress; the Track Egress <bcp14>MUST</bcp14> be
an implicit Target, so it MUST NOT be signaled in a RPL Target considered as
an implicit Target, so it <bcp14>MUST NOT</bcp14> be signaled in a
RPL Target
Option. Option.
</t> </t>
</dd> </dd>
</dl> </dl>
</section> <!-- Via Information Options --> </section>
<section anchor='rplsib'><name>Sibling Information Option</name> <section anchor='rplsib'><name>Sibling Information Option</name>
<t> <t>
The Sibling Information Option (SIO) provides information about siblings tha t The Sibling Information Option (SIO) provides information about siblings tha t
could be used by the Root to form P-Routes. One or more SIO(s) may be placed could be used by the Root to form P-Routes. One or more SIOs may be placed
in the DAO messages that are sent to the Root in Non-Storing Mode. in the DAO messages that are sent to the Root in Non-Storing Mode.
</t> </t>
<t> <t>
To advertise a neighbor node, the router MUST have an active Address To advertise a neighbor node, the router <bcp14>MUST</bcp14> have an active A
Registration from that sibling using <xref target='RFC8505'/>, for an address ddress
(ULA or GUA) that serves as identifier for the node. If this router also Registration from that sibling per <xref 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 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 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 registered address needs to report the SIO, with the B flag set, and the Root
will assume symmetry. will assume symmetry.
</t> </t>
<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 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 informatio n expected in both directions, so the routing can consider that the informatio n
provided for one direction is valid for both. If the SIO is effectively provided for one direction is valid for both. If the SIO is effectively
received from both sides then the B flag MUST be ignored. received from both sides, then the B flag <bcp14>MUST</bcp14> be ignored.
The policy that describes the The policy that describes the
performance criteria, and how they are asserted is out of scope. performance criteria and how they are asserted is out of scope.
In the absence of an external protocol to assert the link quality, the flag In the absence of an external protocol to assert the link quality, the flag
SHOULD NOT be set. <bcp14>SHOULD NOT</bcp14> be set.
</t> </t>
<t> <t>
The format of the SIO is as follows: The format of the SIO is as follows:
</t> </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> <figure anchor='siof'><name>Sibling Information Option Format</name>
<artwork align="center"> <artwork ><![CDATA[
0 1 2 3 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 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 | | Type | Option Length |S|B|Flags|Comp.| Opaque |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Step in Rank | Reserved | | Step in Rank | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
. . . .
. Sibling DODAGID (if the D flag not set) . . Sibling DODAGID (if the D flag is not set) .
. . . .
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
. . . .
. Sibling Address . . Sibling Address .
. . . .
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwor
</artwork> k>
</figure> </figure>
<dl spacing='normal'> <dl spacing='normal'>
<dt>Option Type:</dt><dd>0x10 for SIO (to be confirmed by IANA) <dt>Option Type:</dt><dd>0x11 for SIO
(see <xref target="ianaRPLCtrlMsgopttbl"/>).</dd> (see <xref target="ianaRPLCtrlMsgopttbl"/>).</dd>
<dt>Option Length:</dt><dd>8-bit unsigned integer, representing th e length in octets of the option, not including the Option <dt>Option Length:</dt><dd>8-bit unsigned integer, representing th e length in octets of the option, not including the Option
Type and Length fields (see section 6.7.1. of <xref target= Type and Length fields (see <xref target=
'RFC6550'/>).</dd> 'RFC6550' section="6.7.1"/>).</dd>
<dt>Reserved for Flags:</dt><dd>MUST be set to zero by the sender <dt>Reserved for Flags:</dt><dd><bcp14>MUST</bcp14> be set to 0 by
and MUST be ignored by the receiver. the sender
and <bcp14>MUST</bcp14> be ignored by the receiver.
</dd> </dd>
<dt>B:</dt><dd> <dt>B:</dt><dd>
1-bit flag that is set to indicate that the connectivity to the si bling 1-bit flag that is set to indicate that the connectivity to the si bling
is bidirectional and roughly symmetrical. is bidirectional and roughly symmetrical.
In that case, only one of the siblings needs report the SIO for th In that case, only one of the siblings needs to report the SIO for
e hop. the hop.
If 'B' is not set then the SIO only indicates connectivity from th If 'B' is not set, then the SIO only indicates connectivity from t
e sibling to this node, and does not provide information on the he sibling to this node, and it does not provide information on the
hop from this node to the sibling. hop from this node to the sibling.
</dd> </dd>
<dt>S:</dt><dd> <dt>S:</dt><dd>
1-bit flag that is set to indicate that sibling belongs to the 1-bit flag that is set to indicate that the sibling belongs to the
same DODAG. When not set, the Sibling DODAGID is indicated. same DODAG. When not set, the Sibling DODAGID is indicated.
</dd> </dd>
<dt>Flags:</dt><dd>Reserved. The Flags field MUST be initialized t o zero by the sender and MUST be ignored by the receiver. <dt>Flags:</dt><dd>Reserved. The Flags field <bcp14>MUST</bcp14> b e initialized to zero by the sender and <bcp14>MUST</bcp14> be ignored by the re ceiver.
</dd> </dd>
<dt>Comp.:</dt><dd>Compression Type, a 3-bit unsigned integer. Thi <dt>Comp.:</dt><dd>Compression Type; a 3-bit unsigned integer. Thi
s is the s is the
SRH-6LoRH Type as defined in figure 7 in section 5.1 of SRH-6LoRH Type as defined in Figure 7 in
<xref target='RFC8138'/> that corresponds to the compression used <xref target='RFC8138' section="5.1"/> that corresponds to the com
pression used
for the Sibling Address and its DODAGID if present. The Compressio n for the Sibling Address and its DODAGID if present. The Compressio n
reference is the Root of the main DODAG. reference is the Root of the main DODAG.
</dd> </dd>
<dt>Opaque:</dt><dd>MAY be used to carry information that the node <dt>Opaque:</dt><dd><bcp14>MAY</bcp14> be used to carry informatio n that the node
and the Root understand, e.g., a particular representation of the and the Root understand, e.g., a particular representation of the
Link properties such as a proprietary Link Quality Information link properties such as a proprietary Link Quality Information
for packets received from the sibling. for packets received from the sibling.
In some scenarios such as the case of an Industrial Alliances that In some scenarios such as Industrial Alliances that
uses RPL for a particular use / environment, this field MAY be use RPL for a particular use/environment, this field <bcp14>MAY</b
redefined to fit the needs of that case. cp14> be
redefined to fit the needs of the case.
</dd> </dd>
<dt>Step in Rank:</dt><dd>16-bit unsigned integer. This is the <dt>Step in Rank:</dt><dd>16-bit unsigned integer. This is the
Step in Rank <xref target='RFC6550'/> as computed by the Objective Step in Rank <xref target='RFC6550'/> as computed by the Objective
Function between this node and the sibling, that reflects the Function between this node and the sibling, which reflects the
abstract Rank increment that would be computed by the OF if the abstract Rank increment that would be computed by the Objective Fu
nction if the
sibling was the preferred parent. sibling was the preferred parent.
</dd> </dd>
<dt>Reserved:</dt><dd>The Reserved field MUST be initialized to ze <dt>Reserved:</dt><dd>The Reserved field <bcp14>MUST</bcp14> be in
ro itialized to zero
by the sender and MUST be ignored by the receiver by the sender and <bcp14>MUST</bcp14> be ignored by the receiver
</dd> </dd>
<dt>Sibling DODAGID:</dt><dd>2 to 16 bytes, the DODAGID of the <dt>Sibling DODAGID:</dt><dd>2 to 16 bytes. The DODAGID of the
sibling in a <xref target='RFC8138'/> compressed form as indicated sibling in a compressed form <xref target='RFC8138'/> as indicated
by the Compression Type field. This field is present if and only by the Compression Type field. This field is present if and only
if the D flag is not set. if the D flag is not set.
</dd> </dd>
<dt>Sibling Address:</dt><dd>2 to 16 bytes, an IPv6 Address of the <dt>Sibling Address:</dt><dd>2 to 16 bytes. An IPv6 address of the
sibling, with a scope that MUST make it reachable from the Root, sibling with a scope that <bcp14>MUST</bcp14> make it reachable fr
om the Root,
e.g., it cannot be a Link Local Address. The IPv6 address is e.g., it cannot be a Link Local Address. The IPv6 address is
encoded in the <xref target='RFC8138'/> compressed form encoded in the compressed form <xref target='RFC8138'/>
indicated by the Compression Type field. indicated by the Compression Type field.
</dd> </dd>
</dl> <t> </dl> <t>
An SIO MAY be immediately followed by a DAG Metric Container. In that case An SIO <bcp14>MAY</bcp14> be immediately followed by a DAG Metric Container. In that case,
the DAG Metric Container provides additional metrics for the hop from the the DAG Metric Container provides additional metrics for the hop from the
Sibling to this node. Sibling to this node.
</t> </t>
</section> <!-- Sibling Information Option --> </section>
</section> <!-- New RPL Control Messages and Options --> </section>
<section anchor='P-DAO'><name>Root Initiated Routing State</name> <section anchor='P-DAO'><name>Root-Initiated Routing State</name>
<section anchor='setup'><name>RPL Network Setup</name> <section anchor='setup'><name>RPL Network Setup</name>
<t> <t>
To avoid the need of Path MTU Discovery by 6LoWPAN end-points, To avoid the need of Path MTU Discovery by 6LoWPAN endpoints,
6LoWPAN links are normally defined 6LoWPAN links are normally defined
with a MTU of 1280 (see section 4 of <xref target='RFC4944'/>). with an MTU of 1280 (see <xref target='RFC4944' section="4"/>).
Injecting packets in a Track typically involves an IP-in-IP encapsulation and Injecting packets in a Track typically involves an IP-in-IP encapsulation and
additional IPv6 Extension Headers. This may cause fragmentation if the additional IPv6 extension headers. This may cause fragmentation if the
resulting packets exceed the MTU that is defined for the RPL domain. resulting packets exceed the MTU that is defined for the RPL domain.
</t> </t>
<t> <t>
Though fragmentation is possible in a 6LoWPAN LLN, e.g., using <xref Though fragmentation is possible in a 6LoWPAN LLN, e.g., using <xref
target='RFC4944'/>, <xref target='RFC8930'/>, and/or <xref target='RFC8931'/> , target='RFC4944'/>, <xref target='RFC8930'/>, and/or <xref target='RFC8931'/> ,
it is RECOMMENDED to define an MTU that is larger than 1280 between RPL it is <bcp14>RECOMMENDED</bcp14> to define an MTU that is larger than 1280 be tween the RPL
routers that form the main DODAG to allow for the necessary header additions, routers that form the main DODAG to allow for the necessary header additions,
while still exposing 1280 to the 6LoWPAN end-point stacks. while still exposing 1280 to the 6LoWPAN endpoint stacks.
</t> </t>
</section><!-- RPL Network Setup --> </section>
<section anchor='req'><name>Requesting a Track</name> <section anchor='req'><name>Requesting a Track</name>
<t> <t>
This specification introduces the PDR message, used by an LLN node to This specification introduces the PDR message, which is used by an LLN nod
request the formation of a new Track for which this node is the Ingress. e to
request the formation of a new Track for which the LLN node is the Ingress
.
Note that the namespace for the TrackID is owned by the Ingress node, 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 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 in assign TrackIDs in that namespace while avoiding collisions (see more in
<xref target='trkid'/>). <xref target='trkid'/>).
</t> </t>
<t> <t>
The PDR signals the desired TrackID and the duration for which the Track s hould be established. Upon a PDR, the Root MAY install the Track as requested, i n which case it answers with a PDR-ACK indicating the granted The PDR signals the desired TrackID and the duration for which the Track s hould be established. Upon a PDR, the Root <bcp14>MAY</bcp14> install the Track as requested, in which case it answers with a PDR-ACK indicating the granted
Track Lifetime. Track Lifetime.
All the segments MUST be of a same mode, either Storing or Non-Storing. All the segments <bcp14>MUST</bcp14> be of the same mode, either Storing o
All the segments MUST be created with the same TrackID and the same DODAGI r Non-Storing.
D signaled in the P-DAO. All the segments <bcp14>MUST</bcp14> be created with the same TrackID and
the same DODAGID signaled in the P-DAO.
</t> </t>
<t> <t>
The Root designs the Track as it sees best, and updates / changes the segm ents over time to serve the The Root designs the Track as it sees fit and updates/changes the segments over time to serve the
Track as needed. Track as needed.
Note that there is no protocol element to notify to the requesting Track Note that there is no protocol element to notify the requesting Track
Ingress when changes happen deeper down the Track, so they are transparent 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 to the Track Ingress. If the main Root cannot maintain an expected service
level, then it needs to tear down the Track completely. 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 Segment Lifetime in the P-DAO messages does not need to be aligned to
the Requested Lifetime in the PDR, or between P-DAO messages for different the Requested Lifetime in the PDR or between P-DAO messages for different
segments. segments.
E.g., The Root may use shorter lifetimes for the segments For example, the Root may use shorter lifetimes for the segments
and renew them or change them during the lifetime of the Track. and renew them or change them during the lifetime of the Track.
All the components (protection paths and segments) of a Track MUST be dest royed All the components (protection paths and segments) of a Track <bcp14>MUST< /bcp14> be destroyed
(or have their lifetime elapsed) before the TrackID can be reused. (or have their lifetime elapsed) before the TrackID can be reused.
</t> </t>
<t> <t>
When the Track Lifetime is relatively close to elapse - meaning in 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 the order of the trip time from the node to the Root -- the requesting nod
SHOULD resend a PDR using the TrackID in the PDR-ACK to extend the e
lifetime of the Track, else the Track will time out and the Root will tear <bcp14>SHOULD</bcp14> resend a PDR using the TrackID in the PDR-ACK to ext
end the
lifetime of the Track; otherwise, the Track will time out, and the Root wi
ll tear
down the whole structure. down the whole structure.
</t> </t>
<t> <t>
If the Track fails and cannot be restored, the If the Track fails and cannot be restored, the
Root notifies the requesting node asynchronously with a PDR-ACK Root notifies the requesting node asynchronously with a PDR-ACK
with a Track Lifetime of 0, indicating that the Track has failed, and with a Track Lifetime of 0, indicating that the Track has failed, and
a PDR-ACK Status indicating the reason of the fault. a PDR-ACK Status, indicating the reason of the fault.
</t> </t>
</section><!-- Requesting a Track --> </section>
<section anchor='trkid'><name>Identifying a Track</name> <section anchor='trkid'><name>Identifying a Track</name>
<t> <t>
RPL defines the concept of an Instance to signal an individual RPL defines the concept of an Instance to signal an individual
routing topology, and multiple topologies can coexist in the same network. routing topology, and multiple topologies can coexist in the same network.
The RPLInstanceID is tagged in the RPI of every packet to signal which The RPLInstanceID is tagged in the RPI of every packet to signal which
topology the packet actually follows. topology the packet actually follows.
</t> </t>
<t> <t>
This specification leverages the RPL Instance model as follows: This specification leverages the RPL Instance model as follows:
</t> </t>
<ul spacing='normal'> <ul spacing='normal'>
<li> <li>
<t> <t>
The main Root MAY use P-DAO messages to add better routes in the main The main Root <bcp14>MAY</bcp14> use P-DAO messages to add better routes in the main
Instance in conformance with the routing objectives in that Instance. Instance in conformance with the routing objectives in that Instance.
</t> </t>
<t> <t>
To achieve this, the main Root MAY install a segment along a path down the To achieve this, the main Root <bcp14>MAY</bcp14> install a segment along a
main DODAG, which is operated in Non-Storing Mode. This enables a loose path down the
source routing and reduces the size of the Routing Header, main DODAG, which is operated in Non-Storing Mode. This enables loose
source routing and reduces the size of the Routing Header;
see <xref target='loose'/>. see <xref target='loose'/>.
The main Root MAY also install a protection path across the main DODAG to The main Root <bcp14>MAY</bcp14> also install a protection path across the main DODAG to
complement the routing topology. complement the routing topology.
</t> </t>
<t> <t>
When adding a P-Route to the RPL main DODAG, the main Root MUST set the When adding a P-Route to the RPL main DODAG, the main Root <bcp14>MUST</bcp
RPLInstanceID field of the P-DAO Base Object (see section 6.4.1. of <xref 14> set the
target='RFC6550'/>) to the RPLInstanceID of the main DODAG, and MUST NOT RPLInstanceID field of the P-DAO Base Object (see <xref
target='RFC6550' section="6.4.1"/>) to the RPLInstanceID of the main DODAG,
and it <bcp14>MUST NOT</bcp14>
use the DODAGID field. A P-Route provides a longer match to the Target 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. Address than the default route via the main Root, so it is preferred.
</t> </t>
</li> </li>
<li> <li>
<t> <t>
The main Root MAY also use P-DAO messages to install a Track as an The main Root <bcp14>MAY</bcp14> also use P-DAO messages to install a Track as an
independent routing topology (say, Traffic Engineered) to achieve independent routing topology (say, Traffic Engineered) to achieve
particular routing characteristics from an Ingress to Egress Endpoints. particular routing characteristics from Ingress to Egress endpoints.
To achieve this, the main Root MUST set up a Local RPL Instance (see To achieve this, the main Root <bcp14>MUST</bcp14> set up a Local RPL Insta
section 5 of <xref target='RFC6550'/>), and the Local RPLInstanceID serves nce (see
<xref target='RFC6550' section="5"/>), and the Local RPLInstanceID serves
as the TrackID. as the TrackID.
The TrackID MUST be unique for the IPv6 ULA or GUA of the Track Ingress The TrackID <bcp14>MUST</bcp14> be unique for the IPv6 ULA or GUA of the Tr
that serves as DODAGID for the Track. ack Ingress
that serves as the DODAGID for the Track.
</t> </t>
<t> <t>
This way, a Track is uniquely identified by the tuple (DODAGID, TrackID) 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 where the TrackID is always represented with the D flag set to 0 (see
also section 5.1. of <xref target='RFC6550'/>), indicating when used in an also <xref target='RFC6550' section="5.1"/>), indicating that when used in
RPI that the source address of the IPv6 packet signals the DODAGID. an RPI, the source address of the IPv6 packet signals the DODAGID.
</t> </t>
<t> <t>
The P-DAO Base Object MUST indicate the tuple (DODAGID, TrackID) that The P-DAO Base Object <bcp14>MUST</bcp14> indicate the tuple (DODAGID, Trac kID) that
identifies the Track as shown in <xref target='p-dao-fmt'/>, and the identifies the Track as shown in <xref target='p-dao-fmt'/>, and the
P-RouteID that identifies the P-Route MUST be signaled in the VIO as shown P-RouteID that identifies the P-Route <bcp14>MUST</bcp14> be signaled in th e VIO as shown
in <xref target='viao'/>. in <xref target='viao'/>.
</t> </t>
<t> <t>
The Track Ingress is the Root of the DODAG ID formed by the local RPL The Track Ingress is the Root of the DODAGID formed by the Local RPL
Instance. It owns the namespace of its TrackIDs, so it can pick any 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 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 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 delegated to the main Root, meaning that the main Root is authoritative for
assigning the TrackIDs for the Tracks it creates. assigning the TrackIDs for the Tracks it creates.
</t> </t>
<t> <t>
With this specification, the main Root is aware of all the active Tracks, 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 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 a collision of the main Root and the Track Ingress picking the same value
at the same time, it is RECOMMENDED that the Track Ingress starts at the same time, it is <bcp14>RECOMMENDED</bcp14> that the Track Ingress s
allocating the ID value of the Local RPLInstanceID (see section 5.1. of tarts
<xref target='RFC6550'/>) used as TrackIDs with the value 0 incrementing, allocating the ID value of the Local RPLInstanceID (see
<xref target='RFC6550' section="5.1"/>) used as TrackIDs with the value 0 i
ncrementing,
while the Root starts with 63 decrementing. while the Root starts with 63 decrementing.
</t> </t>
</li> </li>
</ul> </ul>
</section><!-- Identifying a Track --> </section>
<section anchor='inst'><name>Installing a Track</name> <section anchor='inst'><name>Installing a Track</name>
<t> <t>
A path can be installed by a single P-Route that signals the sequence of cons ecutive nodes, either in Storing Mode as a single-segment Track, or in Non-Stori ng 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 ent ry must recursively be reached over a path. A path can be installed by a single P-Route that signals the sequence of cons ecutive nodes either in Storing Mode as a single-segment Track or in Non-Storing Mode as a single-protection-path Track. A single-protection-path Track can be i nstalled as a loose Non-Storing Mode P-Route, in which case the next loose entry must recursively be reached over a path.
</t> </t>
<t> <t>
A Complex Track can be installed as a collection of P-Routes with the same DO DAGID and Track ID. The Ingress of a Non-Storing Mode P-Route is the owner and R oot of the DODAGID. The Ingress of a Storing Mode P-Route must be either the own er of the DODAGID, or a hop of a protection path of the same Track. In the latte r case, the Targets of the P-Route must include the next hop of the protection p ath if there is one, to ensure forwarding continuity. A Complex Track can be installed as a collection of P-Routes with the same DO DAGID and Track ID. The Ingress of a Non-Storing Mode P-Route is the owner and R oot of the DODAGID. The Ingress of a Storing Mode P-Route must be either the own er of the 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 pa th if there is one to ensure forwarding continuity.
In the case of a Complex Track, each segment is maintained independently and 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 asynchronously by the Root, with its own lifetime that may be shorter, the
same, or longer than that of the Track. same, or longer than that of the Track.
</t> </t>
<t>A route along a Track for which the TrackID is not the RPLInstanceID of <t>A route along a Track for which the TrackID is not the RPLInstanceID of
the main DODAG MUST be installed with a higher precedence than the routes the main DODAG <bcp14>MUST</bcp14> be installed with a higher precedence than the routes
along the main DODAG, meaning that: along the main DODAG, meaning that:
</t> </t>
<ul> <ul>
<li>Longest match MUST be the prime comparison for routing. <li>The longest match <bcp14>MUST</bcp14> be the prime comparison for routing .
</li> </li>
<li>In case of equal length match, the route along the Track MUST be <li>For an equal-length match, the route along the Track <bcp14>MUST</bcp14>
preferred vs. the one along the main DODAG. be
preferred over the one along the main DODAG.
</li> </li>
<li>There SHOULD NOT be 2 different Tracks leading to the same Target from <li>There <bcp14>SHOULD NOT</bcp14> be two different Tracks leading to the sa me Target from
same Ingress node, unless there's a policy for selecting which packets use same Ingress node, unless there's a policy for selecting which packets use
which Track; such a policy is out of scope. which Track; such a policy is out of scope.
</li> </li>
<li>A packet that was routed along a Track MUST NOT be routed along the main <li>A packet that was routed along a Track <bcp14>MUST NOT</bcp14> be routed along the main
DODAG again; if the destination is not reachable as a neighbor by the node DODAG again; if the destination is not reachable as a neighbor by the node
where the packet exits the Track then the packet MUST be dropped. where the packet exits the Track, then the packet <bcp14>MUST</bcp14> be drop ped.
</li> </li>
</ul> </ul>
<section anchor='trkpdao'><name>Signaling a Projected Route</name> <section anchor='trkpdao'><name>Signaling a Projected Route</name>
<t> <t>
This specification adds a capability whereby the Root of a main DODAG instal ls This specification adds a capability whereby the Root of a main DODAG instal ls
a Track as a collection of P-Routes, using a Projected-DAO (P-DAO) message a Track as a collection of P-Routes, using a P-DAO message
for each individual protection path or segment. for each individual protection path or segment.
The P-DAO signals a collection of Targets in the RPL Target Option(s) (RTO). Those Targets can be reached via a sequence of routers indicated in a VIO. The P-DAO signals a collection of Targets in one or more RTOs. Those Targets can be reached via a sequence of routers indicated in a VIO.
</t> <t> </t> <t>
Like a classical DAO message, a P-DAO causes a change of state only if it is Like a classical DAO message, a P-DAO causes a change of state only if it is
"new" per section 9.2.2. "Generation of DAO Messages" of the <xref target='R FC6550'> RPL specification</xref>; this is determined using "new" per Section <xref target="RFC6550" sectionFormat="bare" section="9.2.2 "/> ("Generation of DAO Messages") of the RPL specification <xref target='RFC655 0'></xref>; this is determined using
the Segment Sequence information from the VIO as opposed to the Path 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 t he P-Route associated to the segment is to be removed. There are two Modes Sequence from a TIO. Also, a Segment Lifetime of 0 in a VIO indicates that t he P-Route associated to the segment is to be removed. There are two Modes
of operation for the P-Routes, the Storing and the Non-Storing Modes. of operation for the P-Routes: Storing and Non-Storing.
</t> <t> </t> <t>
A P-DAO message MUST be sent from the address of the Root that serves A P-DAO message <bcp14>MUST</bcp14> be sent from the address of the Root tha
as DODAGID for the main DODAG. It MUST contain either exactly one t serves
sequence of one or more RTOs followed by one VIO, or any number of as the DODAGID for the main DODAG. It <bcp14>MUST</bcp14> contain either exa
ctly one
sequence of one or more RTOs followed by one VIO or any number of
sequences of one or more RTOs followed by one or more TIOs. sequences of one or more RTOs followed by one or more TIOs.
The former is the normal expression for this specification, whereas The former is the normal expression for this specification, whereas
the latter corresponds to the variation for less-constrained the latter corresponds to the variation for less-constrained
environments described in <xref target='bfd'/>. environments described in <xref target='bfd'/>.
</t> <t> </t> <t>
A P-DAO that creates or updates a protection path MUST be sent to a GUA or a A P-DAO that creates or updates a protection path <bcp14>MUST</bcp14> be sen
ULA t to a GUA or a ULA
of the Ingress of the protection path; it MUST contain the full list of hops of the Ingress of the protection path; it <bcp14>MUST</bcp14> contain the fu
in the ll list of hops in the
protection path unless the protection path is being removed. protection path unless the protection path is being removed.
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 <!--[rfced] Should "MUST" be added to the latter part of this sentence
P-DAO that updates (including deletes) a section of a segment MUST be (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 GU
A or a ULA
of the segment Egress and <bcp14>MUST</bcp14> signal the full list of hops i
n a segment; a
P-DAO that updates (including deletes) a section of a segment <bcp14>MUST</b
cp14> be
sent to the first node after the modified segment and signal the full 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 list of hops in the section starting at the node that immediately
precedes the modified section. precedes the modified section.
</t> <t> </t> <t>
In Non-Storing Mode, as discussed in <xref target='nsP-DAO'/>, the Root 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 state is sends the P-DAO to the Track Ingress where the source routing state is
applied, whereas in Storing Mode, the P-DAO is sent to the last node on the 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 installed path and forwarded in the reverse direction, installing a Storing
Mode state at each hop, as discussed in <xref target='sP-DAO'/>. Mode state at each hop, as discussed in <xref target='sP-DAO'/>.
In both cases the Track Ingress is the owner of the Track, and it generates the P-DAO-ACK when the installation is successful. In both cases, the Track Ingress is the owner of the Track, and it generates the P-DAO-ACK when the installation is successful.
</t> </t>
<t> <t>
If the 'K' Flag is present in the P-DAO, the P-DAO MUST be acknowledged If the 'K' flag is present in the P-DAO, the P-DAO <bcp14>MUST</bcp14> be ac knowledged
using a DAO-ACK that is sent back to the address of the Root from which the 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, se gment, P-DAO was received. In most cases, the first node of the protection path, se gment,
or updated section of the segment is the node that sends the acknowledgment. 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 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. to forward a Storing Mode P-DAO to the previous node in the SM-VIO.
</t> </t>
<t> <t>
In a No-Path Non-Storing Mode P-DAO, the SRH-6LoRH MUST NOT be present in the In a No-Path Non-Storing Mode P-DAO, the SRH-6LoRH <bcp14>MUST NOT</bcp14> be present in the
NSM-VIO; the state in the Ingress is erased regardless. In all other cases, a NSM-VIO; the state in the Ingress is erased regardless. In all other cases, a
VIO MUST contain at least one Via Address, and a Via Address MUST NOT be VIO <bcp14>MUST</bcp14> contain at least one Via Address, and a Via Address < bcp14>MUST NOT</bcp14> be
present more than once, which would create a loop. present more than once, which would create a loop.
</t> </t>
<t> <t>
A node that processes a VIO MAY verify whether any of these conditions A node that processes a VIO <bcp14>MAY</bcp14> verify whether any of these co
happen, and when one does, it MUST ignore the P-DAO and reject it with a RPL nditions
Rejection Status of "Error in VIO" in the DAO-ACK, see <xref target='iana-sta happen, and when one does, it <bcp14>MUST</bcp14> ignore the P-DAO and reject
ts-rpl-rej'/>. it with a RPL
Rejection Status of "Error in VIO" in the DAO-ACK; see <xref target='iana-sta
ts-rpl-rej'/>.
</t><t> </t><t>
Other errors than those discussed explicitly that prevent the installation of the Errors, other than those discussed explicitly, that prevent the installation of the
route are acknowledged with a RPL Rejection Status of "Unqualified Rejection" in the DAO-ACK. route are acknowledged with a RPL Rejection Status of "Unqualified Rejection" in the DAO-ACK.
</t> </t>
</section><!-- Signaling a Projected Route --> </section>
<section anchor='sP-DAO'><name>Installing a Track Segment with a Storing Mod e P-Route</name> <section anchor='sP-DAO'><name>Installing a Track Segment with a Storing Mod e P-Route</name>
<t>As illustrated in <xref target='sdf'/>, a Storing Mode P-DAO installs a <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. 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, The segment is to be included in a DODAG indicated by the P-DAO Base Object,
that may be the one formed by the main DODAG, or a Track associated which may be the one formed by the main DODAG, or a Track associated
with a local RPL Instance. with a Local RPL Instance.
</t> </t>
<figure anchor='sdf'><name>Projecting a route</name> <figure anchor='sdf'><name>Projecting a Route</name>
<artwork> <artwork><![CDATA[
------+--------- ------+---------
| Internet | Internet
| |
+-----+ +-----+
| | Border router | | Border Router
| | (RPL Root) | | (RPL Root)
+-----+ | ^ | +-----+ | ^ |
| | DAO | ACK | | | DAO | ACK |
o o o o | | | o o o o | | |
o o o o Ingress o o o | ^ | Projected . 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 | | DAO | Route .
o o o o \\ o o o o | ^ | . o o o o \\ o o o o | ^ | .
o o o o o Egress o o v | DAO v . o o o o o Egress o o v | DAO v .
o o LLN o o o | o o LLN o o o |
o o o o o Loose Source Route Path | o o o o o Loose Source Route Path |
o o o o v o o o o v]]></artwork>
</artwork>
</figure> </figure>
<t> <t>
In order to install the relevant routing state along the segment , In order to install the relevant routing state along the segment,
the Root sends a unicast P-DAO message to the Track Egress router of the ro the Root sends a unicast P-DAO message to the Track Egress router of the ro
uting segment that is being installed. The P-DAO message contains a SM-VIO with uting segment that is being installed. The P-DAO message contains an SM-VIO with
the strict sequence of Via Addresses. The SM-VIO follows a strict sequence of Via Addresses. The SM-VIO follows
one or more RTOs indicating the Targets to which the Track leads. The SM-VI O contains a Segment Lifetime for which the state is to be maintained. one or more RTOs indicating the Targets to which the Track leads. The SM-VI O contains a Segment Lifetime for which the state is to be maintained.
</t><t> </t><t>
The Root sends the P-DAO directly to the Egress node of the segment. 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 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 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 th e first fashion, the segment Ingress node recognizes its role because it matches th e first
Via Address in the SM-VIO. Via Address in the SM-VIO.
</t><t> </t><t>
The Egress node of the segment is the only node in the path that does not 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 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. to route to the Target(s) based on its existing tables.
If one of the Targets is not known, the node MUST answer to the Root If one of the Targets is not known, the node <bcp14>MUST</bcp14> answer to the Root
with a DAO-ACK listing the unreachable Target(s) in an RTO and a rejection with a DAO-ACK listing the unreachable Target(s) in an RTO and a rejection
status of "Unreachable Target". status of "Unreachable Target".
</t><t> </t><t>
If the Egress node can reach all the Targets, then it forwards the P-DAO If the Egress node can reach all the Targets, it forwards the P-DAO
with unchanged content to its predecessor in the segment as indicated in with unchanged content to its predecessor in the segment as indicated in
the list of Via Information options, and recursively the message is the list of VIOs, and the message is recursively propagated
propagated
unchanged along the sequence of routers indicated in the P-DAO, but in the unchanged along the sequence of routers indicated in the P-DAO, but in the
reverse order, from Egress to Ingress. reverse order, from Egress to Ingress.
</t><t> </t><t>
The address of the predecessor to be used as destination of the propagated The address of the predecessor to be used as the destination of the propaga
DAO message is found in the Via Address list, at the position preceding the ted
one DAO message is found in the Via Address list at the position preceding the
that contains the address of the propagating node, which is used as source one
that contains the address of the propagating node, which is used as the sou
rce
of the message. of the message.
</t><t> </t><t>
Upon receiving a propagated DAO, all except the Egress router MUST install a Upon receiving a propagated DAO, all except the Egress router <bcp14>MUST</b cp14> install a
route towards the DAO Target(s) via their successor in the SM-VIO. A router 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 reject the that cannot store the routes to all the Targets in a P-DAO <bcp14>MUST</bcp1 4> reject the
P-DAO by sending a DAO-ACK to the Root with a Rejection Status of "Out of 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. Resources" as opposed to forwarding the DAO to its predecessor in the list.
The router MAY install additional routes towards the Via Addresses that appe ar in The router <bcp14>MAY</bcp14> install additional routes towards the Via Addr esses that appear in
the SM-VIO after its own address, if any, but in case of a conflict or a lac k of the SM-VIO after its own address, if any, but in case of a conflict or a lac k of
resource, the route(s) to the Target(s) are the ones that MUST be installed resource, the route(s) to the Target(s) <bcp14>MUST</bcp14>
in priority. be installed in priority.
</t> </t>
<t> <t>
If a router cannot reach its predecessor in the SM-VIO, the router MUST sen d the DAO-ACK to the Root with a Rejection Status of "Predecessor Unreachable". If a router cannot reach its predecessor in the SM-VIO, the router <bcp14>M UST</bcp14> send the DAO-ACK to the Root with a Rejection Status of "Predecessor Unreachable".
</t> </t>
<t> <t>
The process continues until the P-DAO is propagated to the Ingress router o f The process continues until the P-DAO is propagated to the Ingress router o f
the segment, which answers with a DAO-ACK to the Root. The Root always 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 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 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, or tear is not received, the Root may retry the DAO with the same TID or tear
down the route. down the route.
</t> </t>
</section> <!-- Installing a Track segment with a Storing Mode P-Route --> </section>
<section anchor='nsP-DAO'><name>Installing a protection path with a Non-Stor ing Mode P-Route</name> <section anchor='nsP-DAO'><name>Installing a Protection Path with a Non-Stor ing Mode P-Route</name>
<t>As illustrated in <xref target='nsdf'/>, <t>As illustrated in <xref target='nsdf'/>,
a Non-Storing Mode P-DAO installs a source-routed path within the Track indic a Non-Storing Mode P-DAO installs a source-routed path within the Track indic
ated by the P-DAO Base Object, towards the Targets indicated in the Target Optio ated by the P-DAO Base Object towards the Targets indicated in the Target Option
ns. The source-routed path requires a Source-Routing header which implies an IP- s. The source-routed path requires a Source Routing Header, which implies an IP-
in-IP encapsulation to add the SRH to an existing packet. It is sent to the Trac in-IP encapsulation is needed to add the SRH to an existing packet. It is sent t
k Ingress which creates a tunnel associated with the Track, and o the Track Ingress, which creates a tunnel associated with the Track and
connected routes over the tunnel to the Targets in the RTO. The tunnel encaps connected routes over the tunnel to the Targets in the RTO. The tunnel encaps
ulation MUST incorporate a routing header via the list addresses listed in the V ulation <bcp14>MUST</bcp14> incorporate a routing header via the list addresses
IO in the same order. The content of the NSM-VIO starting at the first SRH-6LoRH listed in the VIO in the same order. The content of the NSM-VIO starting at the
header MUST be used verbatim by the Track Ingress when it encapsulates a packet first SRH-6LoRH header <bcp14>MUST</bcp14> be used verbatim by the Track Ingress
to forward it over the Track. when it encapsulates a packet to forward it over the Track.
</t> </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> <figure anchor='nsdf'><name>Projecting a Non-Storing Route</name>
<artwork> <artwork><![CDATA[
------+--------- ------+---------
| Internet | Internet
| |
+-----+ +-----+
| | Border router | | Border Router
| | (RPL Root) | | (RPL Root)
+-----+ | P ^ ACK +-----+ | P ^ ACK
| Track | DAO | | Track | DAO |
o o o o Ingress X V | X o o o o Ingress X V | X
o o o o o o o X o X Source o o o o o o o X o X Source-
o o o o o o o o X o o X Routed 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 X o X Segment
o o o o o o o o X Egress X o o o o o o o o X Egress X
o o o o o | o o o o o |
Target Target
o o LLN o o o o LLN o o
o o o o o o o o]]></artwork>
</artwork>
</figure> </figure>
<t> <t>
The next entry in the source-routed path must be either a neighbor of the The next entry in the source-routed path must be either a neighbor of the
previous entry, or reachable as a Target via another P-Route, either previous 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 Storing or Non-Storing, which implies that the nested P-Route has to be
installed before the loose sequence is, and that P-Routes must be installed installed before the loose sequence is and that P-Routes must be installed
from the last to the first along the datapath. from the last to the first along the datapath.
For instance, a segment of a Track must be installed before the protection pa th(s) of For instance, a segment of a Track must be installed before the protection pa th(s) of
the same Track that use it, and stitched segments must be installed in the same Track that uses it, and stitched segments must be installed in
order from the last that reaches to the Targets to the first. order from the last to the first to reach the Targets.
</t> </t>
<t> <t>
If the next entry in the loose sequence is reachable over a Storing Mode P-Ro ute, it MUST be the Target of a segment and the Ingress of a next segment, both already setup; the segments are associated with the same Track, which avoids the need of an additional encapsulation. For instance, in If the next entry in the loose sequence is reachable over a Storing Mode P-Ro ute, it <bcp14>MUST</bcp14> be the Target of a segment and the Ingress of a next segment, which are both already set up; the segments are associated with the sa me Track, which avoids needing an additional encapsulation. For instance, in
<xref target="srpdao"/>, segments A==>B-to-C and C==>D==>E-to-F must be <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. 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>
<t> <t>
Conversely, if it is reachable over a Non-Storing Mode P-Route, the next 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 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 installed Track and the Ingress of a next Track, which requires de- and
re-encapsulation when switching the outer Tracks that join the loose hops. re-encapsulation when switching the outer Tracks that join the loose hops.
This is examplified in <xref target="nssr"/> where Non-Storing Mode P-DAO 1 This is exemplified in <xref target="nssr"/> where Non-Storing Mode P-DAOs 1
and 2 install strict Tracks that Non-Storing Mode P-DAO 3 joins as a super 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. Track. In such a case, packets are subject to double IP-in-IP encapsulation.
</t> </t>
</section> <!-- Installing a Track Segment with a Storing Mode P-Route --> </section>
</section><!-- Installing a Track --> </section>
<section anchor='teardown'><name>Tearing Down a P-Route</name> <section anchor='teardown'><name>Tearing Down a P-Route</name>
<t> <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 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 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 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. Track segments and protection paths that compose it one by one.
</t> </t>
<t> <t>
Since the state about a protection path of a Track is located only on the In Since the protection path state of a Track is located only on the Ingress No
gress Node, de,
the Root cleans up the protection path by sending an NSM-VIO to the Ingress 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 Segmen t Lifetime the TrackID and the P-RouteID of the protection path being removed, a Segmen t Lifetime
of 0 and a newer Segment Sequence. The SRH-6LoRH with the Via Addresses in of 0, and a newer Segment Sequence. The SRH-6LoRH with Via Addresses in
the NSM-VIO are not needed; it SHOULD NOT be placed in the message and MUST the NSM-VIO is not needed; it <bcp14>SHOULD NOT</bcp14> be placed in the mes
sage and <bcp14>MUST</bcp14>
be ignored by the receiver. Upon that NSM-VIO, the Ingress node removes all be ignored by the receiver. Upon that NSM-VIO, the Ingress node removes all
state for that Track if any, and replies positively anyway. state for that Track, if any, and replies positively anyway.
</t> </t>
<t> <t>
The Root cleans up a section of a segment by sending an SM-VIO to the last The Root cleans up a section of a segment by sending an SM-VIO to the last
node of the segment, with the TrackID and the P-RouteID of the segment being node of the segment with an updated TrackID and P-RouteID,
updated, a Segment Lifetime of zero (0) and a newer Segment Sequence. a Segment Lifetime of 0, and a newer Segment Sequence.
The Via Addresses in the SM-VIO indicates the section of the segment being The Via Addresses in the SM-VIO indicate the section of the segment being
modified, from the first to the last node that is impacted. This can be the modified, from the first to the last node that is impacted. This can be the
whole segment if it is totally removed, or a sequence of one or more nodes whole segment if it is totally removed or a sequence of one or more nodes
that have been bypassed by a segment update. that have been bypassed by a segment update.
</t> </t>
<t> <t>
The No-Path P-DAO is forwarded normally along the reverse list, even if the 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 intermediate node does not find a segment state to clean up. This results in
cleaning up the existing segment state if any, as opposed to refreshing an cleaning up the existing segment state, if any, as opposed to refreshing an
existing one or installing a new one. existing one or installing a new one.
</t> </t>
</section><!-- Tearing Down a P-Route --> </section>
<section anchor='maintain'><name>Maintaining a Track</name> <section anchor='maintain'><name>Maintaining a Track</name>
<t> <t>
Repathing a Track segment or protection path may cause jitter and packet mi sordering. Repathing a Track segment or protection path may cause jitter and packet mi sordering.
For critical flows that require timely and/or For critical flows that require timely and/or
in-order delivery, it might be necessary to deploy the PAREO functions in-order delivery, it might be necessary to deploy the PAREO functions
<xref target='I-D.ietf-raw-architecture'/> over a highly redundant Track. <xref target='RFC9912'/> over a highly redundant Track.
This specification allows to use more than one protection path for a Track, This specification allows the use of more than one protection path for a Tr
and 1+N ack and 1+N
packet redundancy. packet redundancy.
</t> </t>
<t> <t>
This section provides the steps to ensure that no packet is lost due to This section provides the steps to ensure that no packet is lost due to
the operation itself. the operation itself.
This is ensured by installing the new section from its last node to the 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, 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. all the downstream nodes in the section have already installed their own.
The disabled section is removed when the packets in-flight are forwarded The disabled section is removed as well when the in-flight packets are forw
along the new section as well. arded
along the new section.
</t> </t>
<section anchor='maintainS'><name>Maintaining a Track Segment</name> <section anchor='maintainS'><name>Maintaining a Track Segment</name>
<t> <t>
To modify a section of a segment between a first node and a second, downstre To modify a section of a segment between the first node and a second downstr
am eam
node (which can be the Ingress and Egress, respectively), while retaining th node (which can be the Ingress and Egress, respectively) while retaining tho
ose nodes se nodes
in the segment, the Root sends an SM-VIO to the second node indicating the 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 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, and a newer the TrackID and the P-RouteID of the segment being updated and a newer
Segment Sequence. The P-DAO is propagated from the second to the first node Segment Sequence. The P-DAO is propagated from the second to the first node,
and on the way, it updates the state on the nodes that are common to the old 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. and new section of the segment and creates a state in the new nodes.
</t> </t>
<t> <t>
When the state is updated in an intermediate node, that node might still 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 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 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 updated, the packets are forwarded along the new version of the segment from
that node on. that node on.
</t> </t>
<t> <t>
After a reasonable time to enable the deprecated sections to drain their tra ffic, the Root After a reasonable amount of time, the Root
tears down the remaining section(s) of the old segments as tears down the remaining section(s) of the old segments as
described in <xref target='teardown'/>. described in <xref target='teardown'/> to enable the deprecated sections to drain their traffic.
</t> </t>
</section> <!-- Maintaining a Track Segment --> </section>
<section anchor='maintainT'><name>Maintaining a protection path</name> <section anchor='maintainT'><name>Maintaining a Protection Path</name>
<t>This specification allows the Root to add protection paths to a Track by sending <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, a Non-Storing Mode P-DAO to the Ingress associated to the same TrackID
and a new Segment ID. If the protection path is loose, then the segments th at join and a new Segment ID. If the protection path is loose, then the segments th at join
the hops must be created first. It makes sense to add a new protection pat h before the hops must be created first. It makes sense to add a new protection pat h before
removing one that is becoming excessively lossy, and switch to the new removing one that is becoming excessively lossy and switch to the new
protection path before removing the old. Dropping a Track before the new on e is protection path before removing the old. Dropping a Track before the new on e is
installed would reroute the traffic via the root; this may increase the installed would reroute the traffic via the root; this may increase the
latency beyond acceptable thresholds, and overload the network near the roo latency beyond acceptable thresholds and overload the network near the root
t. .
This may also cause loops in the case of stitched Tracks: the packets that This may also cause loops in the case of stitched Tracks: The packets that
cannot be injected in the second Track might be routed back and reinjected cannot be injected in the second Track might be routed back and reinjected
at the Ingress of the first. at the Ingress of the first Track.
</t> </t>
<t> <t>
It is also possible to update a protection path by sending a Non-Storing Mo de It is also possible to update a protection path by sending a Non-Storing Mo de
P-DAO to the Ingress with the same Segment ID, an incremented Segment 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. Sequence, and the new complete list of hops in the NSM-VIO.
Updating a live protection path means changing one or more of the intermedi ate loose Updating a live protection path means changing one or more of the intermedi ate loose
hops, and involves laying out new segments from and to the new loose hops hops, and it involves laying out new segments from and to the new loose hop
before the NSM-VIO for the new protection path is issued. s
before the NSM-VIO is issued for the new protection path.
</t> </t>
<t> <t>
Packets that are in flight over the old version of the protection path still Packets that are in flight over the old version of the protection path still
follow the old source route path over the old segments. follow the old source route path over the old segments.
After a reasonable time to enable the deprecated segments to drain their tra After a reasonable time, the Root
ffic, the Root tears down those segments as described in <xref target='teardown'/> to enabl
tears down those segments as described in <xref target='teardown'/>. e the deprecated segments to drain their traffic.
</t> </t>
</section> <!-- Maintaining a protection path --> </section>
</section> <!-- Maintaining a Track --> </section>
<section anchor='routing'><name>Encapsulating and Forwarding Along a Track</n ame> <section anchor='routing'><name>Encapsulating and Forwarding Along a Track</n ame>
<t> <t>
When injecting a packet in a Track, the Ingress router must 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 encapsulate the packet using IP-in-IP to add the Source Routing Header with
the final destination set to the Track Egress. the final destination set to the Track Egress.
</t> </t>
<t> <t>
All properties of a Track's operations are inherited form the main All properties of a Track's operations are inherited from the main
Instance that is used to install the Track. For instance, the use of Instance that is used to install the Track. For instance, the use of
compression per <xref target='RFC8138'/> is determined by whether it is compression per <xref target='RFC8138'/> is determined by whether it is
used in the RPL main DODAG, e.g., by setting the "T" flag <xref target= used in the RPL main DODAG, e.g., by setting the 'T' flag <xref target=
'RFC9035'/> in the RPL configuration option. 'RFC9035'/> in the RPL configuration option.
</t> </t>
<t> <t>
The Track Ingress that places a packet in a Track encapsulates it with an When the Track Ingress places a packet in a Track, it encapsulates it with a n
additional IPv6 header, a Routing Header, and an IPv6 Hop-by-Hop Option Head er that additional IPv6 header, a Routing Header, and an IPv6 Hop-by-Hop Option Head er that
contains the RPL Packet Information (RPI) as follows: contains the RPI as follows:
</t> </t>
<ul> <ul>
<li> <li>
In the uncompressed form, the source of the packet is the address that In the uncompressed form, the source of the packet is the address that
this router uses as DODAGID for the Track, the destination is the first this router uses as the DODAGID for the Track, the destination is the firs
Via Address in the NSM-VIO, and the RH is a t
Source Routing Header (SRH) <xref target='RFC6554'/> that contains the Via Address in the NSM-VIO, and the RH is an
SRH <xref target='RFC6554'/> that contains the
list of the remaining Via Addresses, ending with the Track Egress. list of the remaining Via Addresses, ending with the Track Egress.
</li> </li>
<li> <li>
<!--[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 [RFC6282] is used is to leverage "IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Paging 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> <t>
The preferred alternative in a network where 6LoWPAN Header Compression To compress RPL artifacts in data packets as indicated in
<xref target='RFC6282'/> is used is to leverage <xref target='RFC8025'> <xref target='RFC8138'/>, the preferred alternative in a network where 6LoWP
"IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging AN header compression
Dispatch"</xref> to compress the RPL artifacts as indicated in <xref target='RFC6282'/> is used is to implement "<xref format="title" targe
<xref target='RFC8138'/>. t='RFC8025'/>" <xref target="RFC8025"/>.
</t> </t>
<t> <t>
In that case, the source routed header is the exact copy of the (chain of) S In that case, the source-routed header is the exact copy of the (chain of) S
RH-6LoRH found in the NSM-VIO, also ending with the Track Egress. RH-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 i The RPI-6LoRH is appended next, followed by an IP-in-IP 6LoRH Header that in
ndicates the Ingress router in the Encapsulator Address field, see as a similar dicates the Ingress router in the Encapsulator Address field; see a similar case
case Figure 20 of <xref target='RFC8138'/>. in Figure 20 of <xref target='RFC8138'/>.
</t> </t>
</li> </li>
</ul> </ul>
<t> <t>
To signal the Track in the packet, this specification leverages the RPL To signal the Track in the packet, this specification leverages the RPL
Forwarding model as follows: Forwarding model as follows:
</t> </t>
<ul spacing='normal'> <ul spacing='normal'>
<li> <li>
<t> <t>
In the data packets, the Track DODAGID and the TrackID MUST be respectively In the data packets, the Track DODAGID and the TrackID <bcp14>MUST</bcp14>
signaled as the IPv6 Source Address and the RPLInstanceID field of the RPI be respectively
that MUST be placed in the outer chain of IPv6 Headers. signaled as the IPv6 source address, and the RPLInstanceID field of the RPI
<bcp14>MUST</bcp14> be placed in the outer chain of IPv6 headers.
</t> </t>
<t> <t>
The RPI carries a local RPLInstanceID called the TrackID, which, in associa tion with the DODAGID, indicates the Track along which the packet is forwarded. The RPI carries a Local RPLInstanceID called the TrackID, which, in associa tion with the DODAGID, indicates the Track along which the packet is forwarded.
</t> </t>
<t> <t>
The D flag in the RPLInstanceID MUST be set to 0 to indicate that the sourc e address in the IPv6 header is set to the DODAGID (more The D flag in the RPLInstanceID <bcp14>MUST</bcp14> be set to 0 to indicate that the source address in the IPv6 header is set to the DODAGID (see more
in <xref target='trkid'/>). in <xref target='trkid'/>).
</t> </t>
</li> </li>
<li> <li>
<t> <t>
This specification conforms to the principles of <xref target='RFC9008'/> with regards to packet forwarding and encapsulation along a Track, as follows: This specification conforms to the principles of <xref target='RFC9008'/> with regard to packet forwarding and encapsulation along a Track as follows:
</t> </t>
<ul> <ul>
<li> <li>
With this specification, the Track is a RPL DODAG. From the perspective of that 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 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, 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 but are external to it, are external destinations and treated as
RPL-Unaware Leaves (RULs). The encapsulation rules in <xref target= RPL-Unaware Leaves (RULs). The encapsulation rules in <xref target=
'RFC9008'/> apply. 'RFC9008'/> apply.
</li><li> </li><li>
If the Track Ingress is the originator of the packet and the Track Egress 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. is the destination of the packet, there is no need for an encapsulation.
</li><li> </li><li>
So the Track Ingress must encapsulate the traffic that it did not originat e, Thus, the Track Ingress must encapsulate the traffic that it did not origi nate,
and it must include an RPI in the encapsulation to signal the TrackID. and it must include an RPI in the encapsulation to signal the TrackID.
</li> </li>
</ul> </ul>
<t> <t>
A packet that is being routed over the RPL Instance associated to a first A packet that is being routed over the RPL Instance associated to a first
Non-Storing Mode Track MAY be placed recursively in a second Track to Non-Storing Mode Track <bcp14>MAY</bcp14> be placed recursively in a second
cover one loose hop of the first Track as discussed in more detail <xref Track to
target="nssr"/>. cover one loose hop of the first Track, as discussed in more detail in <xre
On the other hand, a Storing Mode segment must be strict and a packet that f
it placed in a Storing Mode segment MUST follow that segment till the segme target="nssr"/>. On the other hand, a Storing Mode segment must be strict,
nt and a packet that
it placed in a Storing Mode segment <bcp14>MUST</bcp14> follow that segment
till the segment
Egress. Egress.
</t> </t>
</li> </li>
</ul> </ul>
<t> <t>
It is known that a packet is forwarded along a Track by the source address It is known that a packet is forwarded along a Track by the source address
and the RPI in the encapsulation. and the RPI in the encapsulation.
The Track ID is used to identify the RIB entries associated to that Track, The Track ID is used to identify the RIB entries associated to that Track,
which, in intermediate nodes, correspond to the P-routes for the segments of which, in intermediate nodes, correspond to the P-Routes for the segments of
the Track that the forwarding router is aware of. the Track that the forwarding router is aware of.
The packet processing uses a precedence that favors self delivery or routing
<!--[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 header handling when one is present, then
delivery to direct neighbors, then to indirect neighbors, then routing delivery to direct neighbors, then to indirect neighbors, then routing
along a segment along the Track, and finally as a last resort injecting along a segment along the Track, and finally as a last resort injecting
the packet in another Track. the packet in another Track.
</t><t> </t><t>
To achieve this, the packet handling logic MUST happen in the following orde r: To achieve this, the packet handling logic <bcp14>MUST</bcp14> happen in the following order:
</t> </t>
<ul> <ul>
<li> <li>
<t> <t>
If the destination of the packet is self: If the destination of the packet is self:
</t> </t>
<ol> <ol>
<li> <li>
if the header chain contains a If the header chain contains a
RPL Source Route Header that is not fully consumed, then the packet is RPL Source Route Header that is not fully consumed, then the packet is
forwarded along the Track as prescribed by <xref target='RFC6554'/>, meaning forwarded along the Track as prescribed by <xref target='RFC6554'/>, meaning
that the next entry in the routing header becomes the destination; that the next entry in the routing header becomes the destination.
</li><li> otherwise: </li><li> Otherwise,
if the packet was encapsulated, then the packet is decapsulated and the if the packet was encapsulated, then the packet is decapsulated and the
forwarding process recurses; else the packet is delivered to the stack. forwarding process recurses; else, the packet is delivered to the stack.
</li> </li>
</ol> </ol>
<!-- If the only route in the RIB was created by an NSM-VIO, this is achieve d by encapsulating the packet, else by forwarding and / or delivering the packet as indicated below. --> <!-- If the only route in the RIB was created by an NSM-VIO, this is achieve d by encapsulating the packet, else by forwarding and / or delivering the packet as indicated below. -->
</li> </li>
<li> <li>
<t>Otherwise, the packet is forwarded as follows: </t> <t>Otherwise, the packet is forwarded as follows: </t>
<ol> <ol>
<li> <li>
If the destination of the packet is a direct neighbor, e.g., installed If the destination of the packet is a direct neighbor, e.g., installed
by IPv6 Neighbor Discovery, then the packet MUST be by IPv6 Neighbor Discovery, then the packet <bcp14>MUST</bcp14> be
forwarded to that neighbor; forwarded to that neighbor.
</li><li> </li><li>
Else If the destination of the packet is an indirect neighbor, e.g., Else, if the destination of the packet is an indirect neighbor, e.g.,
installed by a multicast DAO message from a common neighbor, installed by a multicast DAO message from a common neighbor
see <xref target='extSIO'/>, then the packet MUST be forwarded to the common (see <xref target='extSIO'/>), then the packet <bcp14>MUST</bcp14> be forwar
neighbor; ded to the common neighbor.
</li><li> </li><li>
Else, if there is a RIB entry for the same Track (e.g., installed by an 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), and the next hop in SM-VIO in a DAO message with the destination as the target) and the next hop
the RIB entry is a direct neighbor, then the packet is passed to that neighb in
or; the RIB entry is a direct neighbor, then the packet is passed to that neighb
or.
</li><li> </li><li>
Else, if there is a RIB entry for the different Track (e.g., installed by an 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 target), then the packet is NSM-VIO in a DAO message with the destination as the target), then the packe t is
encapsulated to be forwarded along that Track and the forwarding encapsulated to be forwarded along that Track and the forwarding
process recurses; otherwise the packet is dropped. process recurses; otherwise, the packet is dropped.
<!-- <!--
</li><li> </li><li>
The longest match in the RIB indicates the next hop, and whether the route The longest match in the RIB indicates the next hop, and whether the route
is installed by neighbor discovery (for direct neighbors), learned through is installed by neighbor discovery (for direct neighbors), learned through
an SIO in a multicast DAO message (for indirect neighbors see <xref target=' extSIO'/>), 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). 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 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. the RIB, meaning that the Track continuity is broken.
--> -->
</li><li> </li><li>
To avoid loops, and as opposed to packets that were not encapsulated, a To avoid loops, and as opposed to packets that were not encapsulated, a
packet that was decapsulated from a Track MUST NOT be routed along the packet that was decapsulated from a Track <bcp14>MUST NOT</bcp14> be routed along the
default route of the main DODAG; this would mean that the end-to-end path is default route of the main DODAG; this would mean that the end-to-end path is
uncontrolled. The node that discovers the fault MUST discard the packet. uncontrolled. The node that discovers the fault <bcp14>MUST</bcp14> discard the packet.
</li> </li>
</ol> </ol>
</li> </li>
</ul> </ul>
<!-- [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 [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> <t>
The node that drops a packet for either of the reasons above MUST The node that drops a packet for either of the reasons above <bcp14>MUST</bc
send an ICMPv6 Error message <xref target='RFC4443'/> to the Root, p14>
with a new Code "Error in P-Route" (See <xref target='ICMPv6ErrPRoute'/>). send an ICMPv6 error message <xref target='RFC4443'/> to the Root,
with the new code "Error in P-Route" (see <xref target='ICMPv6ErrPRoute'/>).
The Root can then repair by updating the broken segment and/or Tracks, and <!--[rfced] May we revise this text into two sentences for easier
in the case of a broken segment, remove the leftover sections of the segment 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 i
n 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 using SM-VIOs with a lifetime of 0 indicating the section to one or more
nodes being removed (See <xref target='maintain'/>). nodes being removed (see <xref target='maintain'/>).
</t> </t>
<t>In case of a permanent forwarding error along a Source Route path, the <t>In case of a permanent forwarding error along a source route path, the
node that fails to forward SHOULD send an ICMP error with a code "Error node that fails to forward <bcp14>SHOULD</bcp14> send an ICMP error with the
code "Error
in Source Routing Header" back to the source of the packet, as described in Source Routing Header" back to the source of the packet, as described
in section 11.2.2.3. of <xref target='RFC6550'/>. Upon receiving this messag in <xref target='RFC6550' section="11.2.2.3"/>. Upon receiving this message,
e, the the
encapsulating node SHOULD stop using the source route path for a encapsulating node <bcp14>SHOULD</bcp14> stop using the source route path fo
reasonable period of time which depends on the deployment, and r a
it SHOULD send an ICMP message with a Code "Error in P-Route" to the reasonable period of time, which depends on the deployment, and
it <bcp14>SHOULD</bcp14> send an ICMP message with the code "Error in P-Rout
e" to the
Root. Failure to follow these steps may result Root. Failure to follow these steps may result
in packet loss and wasted resources along the source route path that in packet loss and wasted resources along the source route path that
is broken. is broken.
</t> </t>
<t> <t>
Either way, the ICMP message MUST be throttled in case of consecutive Either way, the ICMP message <bcp14>MUST</bcp14> be throttled in case of con
occurrences. It MUST be sourced at the ULA or a GUA that is used in this secutive
occurrences. It <bcp14>MUST</bcp14> be sourced at the ULA or GUA that is use
d in this
Track for the source node, so the Root can establish where the error Track for the source node, so the Root can establish where the error
happened. happened.
</t> </t>
<t> <t>
The portion of the invoking packet that is sent back in the ICMP message The portion of the invoking packet that is sent back in the ICMP message
SHOULD record at least up to the RH if one is present, and this hop of the <bcp14>SHOULD</bcp14> record at least up to the RH if one is present, and th
RH SHOULD be consumed by this node so that the destination in e hop of the
RH <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. the IPv6 header is the next hop that this node could not reach.
If a 6LoWPAN Routing Header (6LoRH) <xref target='RFC8138'/> is used to If a 6LoRH <xref target='RFC8138'/> is used to
carry the IPv6 routing information in the outer header then that whole carry the IPv6 routing information in the outer header, then the whole
6LoRH information SHOULD be present in the ICMP message. 6LoRH information <bcp14>SHOULD</bcp14> be present in the ICMP message.
</t> </t>
</section><!-- Encapsulating and Forwarding along a Track --> </section>
<section anchor='encompression'><name>Compression of the RPL Artifacts</name> <section anchor='encompression'><name>Compression of RPL Artifacts</name>
<t> <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 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 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 formatted as shown in <xref target='inner'/>, representing the case where
an IP-in-IP encapsulation is needed an IP-in-IP encapsulation is needed
(see Table 19 of <xref target='RFC9008'/>): (see Table 19 of <xref target='RFC9008'/>):
</t> </t>
<figure anchor='inner'><name>A Packet as Forwarded along the main DODAG</name> <figure anchor='inner'><name>A Packet as Forwarded Along the Main DODAG</name>
<artwork align="center"> <artwork ><![CDATA[
+-+ ... -+- ... -+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-... +-+ ... -+- ... -+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-...
|11110001| SRH- | RPI- | IP-in-IP | NH=1 |11110CPP| UDP | UDP |11110001| SRH- | RPI- | IP-in-IP | NH=1 |11110CPP| UDP | UDP
| Page 1 | 6LoRH | 6LoRH | 6LoRH |LOWPAN_IPHC| UDP | hdr |Payld | Page 1 | 6LoRH | 6LoRH | 6LoRH |LOWPAN_IPHC| UDP | hdr |Payld
+-+ ... -+- ... -+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-... +-+ ... -+- ... -+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-...
&lt;= RFC 6282 =&gt; <= RFC 6282 =>
&lt;================ Inner packet ==================== = = <================ Inner packet ==================== = =]]></artwork>
</artwork>
</figure> </figure>
<t> <t>
Since there is no page switch between the encapsulated packet and the Since there is no page switch between the encapsulated packet and the
encapsulation, the first octet of the compressed packet that acts as page encapsulation, the first octet of the compressed packet that acts as the page
selector is actually removed at encapsulation, so the inner packet used in selector is actually removed at encapsulation; therefore, the inner packet us
the descriptions below starts with the SRH-6LoRH, and is exactly the packet ed in
the descriptions below starts with the SRH-6LoRH and is exactly the packet
represented in <xref target='inner'/>, from the second octet onward. represented in <xref target='inner'/>, from the second octet onward.
</t> </t>
<t>When encapsulating that inner packet to place it in the Track, the first <t>When encapsulating the inner packet to place in the Track, the first
header that the Ingress appends at the head of the inner packet is an 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 t o the IPv6 source address in the uncompressed form, contains a GUA or ULA IPv6 a ddress of the Ingress node that serves as DODAG ID for the Track, expressed in t he compressed form and using the DODAGID of the main DODAG as compression refere nce. If the address is compressed to 2 bytes, the resulting value for the Length field shown in <xref target='ipinip'/> is 3, meaning that the SRH-6LoRH as a wh ole is 5-octets long. IP-in-IP 6LoRH Header; in that header, the encapsulator address, which maps t o the IPv6 source address in the uncompressed form, contains a GUA or ULA IPv6 a ddress of the Ingress node that serves as the DODAGID for the Track, expressed i n a compressed form using the DODAGID of the main DODAG as a reference for the c ompression. If the address is compressed to 2 bytes, the resulting value for the Length field (shown in <xref target='ipinip'/>) is 3, meaning that the SRH-6LoR H as a whole is 5 octets long.
</t> </t>
<figure anchor='ipinip'><name>The IP-in-IP 6LoRH Header</name> <figure anchor='ipinip'><name>The IP-in-IP 6LoRH Header</name>
<artwork align="center"> <artwork ><![CDATA[
0 1 2 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 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 | |1|0|1| Length | 6LoRH Type 6 | Hop Limit | Track DODAGID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+]]></artwork>
</artwork>
</figure> </figure>
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... <span class="inser t">-+]]&gt;&lt;/artwork&gt;</span>
<t> At the head of the resulting sequence of bytes, the track Ingress then adds <!--[rfced] This sentence is hard to parse. Please let us know if the
the RPI that carries the TrackID as RPLinstanceID as a P-RPI-6LoRH Header, as suggested update captures the intended meaning or if you prefer
illustrated in <xref target='PRpifmt'/>, using the TrackID as 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. RPLInstanceID.
<!-- DB: I can't make sense of this sentence, too many "as". Looks like a qui ck edit gone bad. --> <!-- DB: I can't make sense of this sentence, too many "as". Looks like a qui ck edit gone bad. -->
Combined with the IP-in-IP 6LoRH Header, this allows to identify the Track wi thout ambiguity. Combined with the IP-in-IP 6LoRH Header, this allows identifying the Track wi thout ambiguity.
</t> </t>
<t> The SRH-6LoRH is then added at the head of the resulting sequence of bytes <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 that signaled the selected as a verbatim copy of the content of the SM-VIO that signaled the selected
protection path. protection path.
</t> </t>
<figure anchor='srh6lorh'><name>The SRH 6LoRH Header</name> <figure anchor='srh6lorh'><name>The SRH-6LoRH Header</name>
<artwork align="center"> <artwork ><![CDATA[
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 .. .. .. 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 | |1|0|0| Size |6LoRH Type 0..4| Hop1 | Hop2 | | HopN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+
Where N = Size + 1 Where N = Size + 1]]></artwork>
</artwork>
</figure> </figure>
<t> <t>
The format of the resulting encapsulated packet in <xref target='RFC8138'/> The format of the resulting encapsulated packet, which is in
compressed form is illustrated in <xref target='respac'/>: compressed form per <xref target='RFC8138'/>, is illustrated in <xref target=
'respac'/>:
</t> </t>
<figure anchor='respac'><name>A Packet as Forwarded along a Track</name> <figure anchor='respac'><name>A Packet as Forwarded Along a Track</name>
<artwork align="center"> <artwork ><![CDATA[
+-+ ... -+-+-+- ... -+-+-+- ... -+-+-+-+-+- ... +-+-+-+-+-+-+- ... +-+ ... -+-+-+- ... -+-+-+- ... -+-+-+-+-+- ... +-+-+-+-+-+-+- ...
| Page 1 | SRH-6LoRH | P-RPI-6LoRH | IP-in-IP 6LoRH | Inner Packet | Page 1 | SRH-6LoRH | P-RPI-6LoRH | IP-in-IP 6LoRH | Inner Packet
+-+ ... -+-+-+- ... -+-+-+- ... -+-+-+-+-+- ... +-+-+-+-+-+-+- ... +-+ ... -+-+-+- ... -+-+-+- ... -+-+-+-+-+- ... +-+-+-+-+-+-+- ...
Signals : Loose Hops : TrackID : Track DODAGID : Signals : Loose Hops : TrackID : Track DODAGID :]]></artwork>
</artwork>
</figure> </figure>
</section><!-- Compression of the RPL Artifacts --> </section>
</section><!-- Root Initiated Routing State --> </section>
<section anchor="ov"><name>Less-Constrained Variations</name> <section anchor="ov"><name>Less-Constrained Variations</name>
<section anchor="smmd"><name>Storing Mode main DODAG</name> <section anchor="smmd"><name>Storing Mode Main DODAG</name>
<t>This specification expects that the main DODAG is operated in Non-Storing <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, Mode. The reasons for that limitation are mostly related to LLN operations,
power and spectrum conservation:</t> power, and spectrum conservation:</t>
<ul> <ul>
<li>In Non-Storing Mode, the Root already knowns the DODAG topology, so the <li>In Non-Storing Mode, the Root already knows the DODAG topology, so the
additional topological information is reduced to the siblings. additional topological information is reduced to the siblings.
</li> </li>
<li>The downward routes are updated with unicast messages to the Root, which <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 ensures that the Root can reach back to the LLN nodes after a repair faster
than in the case of Storing Mode. Also the Root can control the use of the than in the case of Storing Mode. Also, the Root can control the use of
path diversity in the DODAG to reach the LLN nodes. For both reasons, 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 Non-Storing Mode provides better capabilities for the Root to maintain the
P-Routes. P-Routes.
</li> </li>
<li> <li>
When the main DODAG is operated in Non-Storing Mode, P-Routes enable When the main DODAG is operated in Non-Storing Mode, P-Routes enable
loose Source Routing, which is only an advantage in that mode. Storing Mode loose source routing, which is only an advantage in that mode. Storing Mode
does not use Source Routing Headers, and does not derive the same benefits does not use Source Routing Headers and does not derive the same benefits
from this capability. from this capability.
<!-- DB: unclear to me what benefis and what capability are being referred to here. Can you be more explicit? --> <!-- DB: unclear to me what benefis and what capability are being referred to here. Can you be more explicit? -->
</li> </li>
</ul> </ul>
<t>On the other hand, since RPL is a Layer-3 routing protocol, its applicability <t>On the other hand, since RPL is a Layer 3 routing protocol, its applicability
extends beyond LLNs to a generic IP network. RPL requires less resources extends beyond LLNs to a generic IP network.
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 <!--[rfced] Please clarify "at the expense of". Does this mean that
protocols compute. P-Routes add the capability to install shortest route stretch is used rather than the shortest path routes?
and/or constrained routes to special destinations such as discussed in
section A.9.4. of the ANIMA ACP <xref target='RFC8994'/>. 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 Rout
ing Protocol (EIGRP), BABEL, or RIP at the expense
of a route stretch versus the shortest path routes to a destination that thos
e
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 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"/>.
</t> </t>
<t> <t>
In a powered and wired network, when enough memory to store the needed 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 routes is available, the RPL Storing Mode proposes a better trade-off than
the Non-Storing, as it reduces the route stretch and lowers the load on the the 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 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, 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 and the nodes can be reached to maintain the P-Routes at most times for
a finer and more reactive control. a finer and more reactive control.
</t> </t>
<t> <t>
This section specifies the additions that are needed to support Projected This section specifies the additions that are needed to support P-Routes
Routes when the main DODAG is operated in Storing Mode. when the main DODAG is operated in Storing Mode.
As long as the RPI can be processed adequately by the dataplane, the As long as the RPI can be processed adequately by the data plane, the
changes to this specification are limited to the DAO message. changes in this specification are limited to the DAO message.
The Track structure, routes and forwarding operations remain the same. The Track structure, routes, and forwarding operations remain the same.
Since there is no capability negotiation, the expectation is that all the nod Since there is no capability negotiation, the expectation is that all the nod
es in the network support this specification in the same fashion, or are configu es in the network support this specification in the same fashion or are configur
red the same way through management. ed the same way through management.
</t> </t>
<t> <t>
In Storing Mode, the Root misses the Child to Parent relationship that forms In Storing Mode, the Root misses the Child-to-Parent relationship that forms
the main DODAG, as well as the sibling information. To provide that knowledge the main DODAG as well as the sibling information. To provide that knowledge,
the nodes in the network MUST send additional DAO messages that are unicast the nodes in the network <bcp14>MUST</bcp14> send additional DAO messages tha
t are unicast
to the Root just like Non-Storing DAO messages are. to the Root just like Non-Storing DAO messages are.
</t> </t>
<t>In the DAO message, the originating router advertises a set of neighbor <t>In the DAO message, the originating router advertises a set of neighbor
nodes using Sibling Information Options (SIO)s, regardless of the relative nodes using SIOs, regardless of the relative
position in the DODAG of the advertised node vs. this router. position in the DODAG of the advertised node versus this router.
</t> </t>
<t>The DAO message MUST be formed as follows: <t>The DAO message <bcp14>MUST</bcp14> be formed as follows:
</t> </t>
<ul> <ul>
<li> <li>
The originating router is identified by the source address of the DAO. That The originating router is identified by the source address of the DAO. That
address MUST be the one that this router registers to neighbor routers address <bcp14>MUST</bcp14> be the one that this router registers to the neig hbor routers
so the Root can correlate the DAOs from those routers when they advertise 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 this router as their neighbor. The DAO contains one or more sequences of one
Transit Information Option and one or more Sibling Information Options. TIO and one or more SIOs.
There is no RPL Target Option so the Root is not confused into adding a There is no RPL Target Option so that the Root is not confused into adding a
Storing Mode route to the Target. Storing Mode route to the Target.
</li> </li>
<li> <li>
The TIO is formed as in Storing Mode, and the Parent Address is not present. The TIO is formed as in Storing Mode, and the Parent Address is not present.
The Path Sequence and Path Lifetime fields The Path Sequence and Path Lifetime fields
are aligned with the values used in the Address Registration of the node(s) a are aligned with the values used in the Address Registration of the node(s) a
dvertised in the SIO, as explained in Section 9.1. of dvertised in the SIO, as explained in
<xref target='RFC9010'/>. <xref target='RFC9010' section="9.1"/>.
Having similar values in all nodes allows factorising the TIO for multiple Having similar values in all nodes allows factorizing the TIO for multiple
SIOs as done with <xref target='RFC6550'/>. SIOs as done in <xref target='RFC6550'/>.
</li> </li>
<!-- <!--
<li> <li>
The TIO is followed by one RPL Target Option that signals the router that 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 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 full and the "Advertiser address in Full" (F) <xref target='RFC9010'/> flag
is set to 1. is set to 1.
</li> </li>
--> -->
<li>The TIO is followed by one or more SIOs that provide an address (ULA or G UA) of the advertised neighbor node. <li>The TIO is followed by one or more SIOs that provide an address (ULA or G UA) of the advertised neighbor node.
</li> </li>
</ul> </ul>
<t> <t>
But the RPL routing information headers may not be supported on all type of However, the RPL routing information headers may not be supported on all type s of
routed network infrastructures, especially not in high-speed routers. routed network infrastructures, especially not in high-speed routers.
When the RPI is not supported in the dataplane, there cannot be local RPL When the RPI is not supported in the data plane, there cannot be Local RPL
Instances and RPL can only operate as a single topology (the main DODAG). Instances and RPL can only operate as a single topology (the main DODAG).
The RPL Instance is that of the main DODAG and the Ingress node that encapsul
ates is not the Root. <!--[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, 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 encapsu
lates is not the Root.
The routes along the Tracks are alternate routes to those available along The routes along the Tracks are alternate routes to those available along
the main DODAG. They MAY conflict with routes to children and MUST take the main DODAG. They <bcp14>MAY</bcp14> conflict with routes to children and
precedence in the routing table. The Targets MUST be adjacent <bcp14>MUST</bcp14> take
precedence in the routing table. The Targets <bcp14>MUST</bcp14> be adjacent
to the Track Egress to avoid loops that may form if the packet is reinjected to the Track Egress to avoid loops that may form if the packet is reinjected
in the main DODAG. in the main DODAG.
</t> </t>
</section><!-- Storing Mode main DODAG --> </section>
<section anchor="bfd"><name>A Track as a Full DODAG</name> <section anchor="bfd"><name>A Track as a Full DODAG</name>
<t>This specification builds Tracks with parallel or interleaved protection paths as opposed <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 to a more complex DODAG with interconnections at any place desirable. The
reason for that limitation is related to constrained node operations, and the reason for that limitation is related to constrained node operations and the
capability to store large amount of topological information and compute capability to store a large amount of topological information and compute
complex paths:</t> complex paths:</t>
<ul> <ul>
<li>With this specification, the node in the LLN has no topological <li>With this specification, the node in the LLN has no topological
awareness, and does not need to maintain dynamic information about the link awareness and does not need to maintain dynamic information about the link
quality and availability. quality and availability.
</li> </li>
<li>The Root has a complete topological information and statistical metrics <li>The Root has complete topological information and statistical metrics
that allow it or its PCE to perform a global optimization of all Tracks in that allow it, or its PCE, to perform a global optimization of all Tracks in
its DODAG. Based on that information, the Root computes the protection path a nd produces the source route paths. its DODAG. Based on that information, the Root computes the protection path a nd produces the source route paths.
</li> </li>
<li> <li>
The node merely selects one of the proposed paths and applies the associated The node merely selects one of the proposed paths and applies the associated
pre-computed routing header in the encapsulation. This alleviates both the pre-computed routing header in the encapsulation. This alleviates both the
complexity of computing a path and the compressed form of the routing header. complexity of computing a path and the compressed form of the routing header.
</li> </li>
</ul> </ul>
<t>The <xref target='I-D.ietf-raw-architecture'>RAW Architecture</xref> <t>The RAW architecture <xref target='RFC9912'></xref>
actually expects the PLR at actually expects the PLR at
the Track Ingress to react to changes in the forwarding conditions along the the Track Ingress to react to changes in the forwarding conditions along the
Track, and reroute packets to maintain the required degree of reliability. 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 To achieve this, the PLR needs the full richness of a DODAG to form any path
that could meet the Service Level Objective (SLO). that could meet the SLO.
</t> </t>
<t> <t>
This section specifies the additions that are needed to turn the Track 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 into a full DODAG and enable the main Root to provide the necessary
topological information to the Track Ingress. The expectation is that the 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, metrics that the PLR uses are of an order other than that of the PCE,
<!-- DB: not sure what "of an order other" means --> <!-- DB: not sure what "of an order other" means -->
because of the difference of time scale between routing and forwarding, more because of the difference of timescale between routing and forwarding; see mo
in <xref target='I-D.ietf-raw-architecture'/>. It follows that the PLR re
in <xref target='RFC9912'/>. It follows that the PLR
will learn the metrics it needs from an alternate source, e.g., OAM frames. will learn the metrics it needs from an alternate source, e.g., OAM frames.
</t> </t>
<t> <t>
To pass the topological information to the Ingress, the Root uses a P-DAO To pass the topological information to the Ingress, the Root uses a P-DAO
messages that contains sequences of Target and Transit Information options message that contains sequences of Targets and TIOs
that collectively represent the Track, expressed in the same fashion as in 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 can report information on many Targets, possibly the full Track, with one P-DAO. 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> </t>
<t>Note that the Path Sequence and Lifetime in the TIO are selected by the Root,
<!--[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
and that the Target/Transit information tuples in the P-DAO are not those 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 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 DOD AG. may follow sibling routes and does not need to be congruent with the main DOD AG.
</t> </t>
</section><!-- A Track as a Full DODAG --> </section>
</section><!-- Least Constrained Variations --> </section>
<section anchor='prof'><name>Profiles</name> <section anchor='prof'><name>Profiles</name>
<t> <t>
This document provides a set of tools that may or may not be needed by 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. 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 This section describes profiles that can be implemented separately and
can be used to discriminate what an implementation can and cannot do. can be used to discriminate what an implementation can and cannot do.
<!-- DB: the above sentence is grammatically incorrect and seems somewhat re dundant with the one preceeding it. <!-- DB: the above sentence is grammatically incorrect and seems somewhat re dundant with the one preceeding it.
Was the preceeding one meant to superseede the second one? --> Was the preceeding one meant to superseede the second one? -->
This section describes profiles that enable implementing only a portion This section describes profiles that enable implementing only a portion
of this specification to meet a particular use case. of this specification to meet a particular use case.
</t><t> </t><t>
Profiles 0 to 2 operate in the main Instance and do not require the Profiles 0 to 2 operate in the main Instance and do not require the
support of local RPL Instances or the indication of the RPL Instance in the support of Local RPL Instances or the indication of the RPL Instance in the
data plane. Profile 3 and above leverage Local RPL Instances to build data plane.
arbitrary Tracks Rooted at the Track Ingress and using its namespace for
TrackID. <!--[rfced] Please clarify what "its" is referring to in the
</t><t> following.
Profiles 0 and 1 are REQUIRED by all implementations that may be used in
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>
<!-- [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 <bcp14>REQUIRED</bcp14> by all implementations that may
be used in
LLNs; Profile 1 leverages Storing Mode to reduce the size of the Source 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 Route Header in the most common LLN deployments. Profile 2 is <bcp14>RECOMME
in high speed / wired environment to enable traffic Engineering and NDED</bcp14>
network automation. All the other profile / environment combinations are in a high-speed or wired environment to enable Traffic Engineering and
OPTIONAL. network automation. All the other profile/environment combinations are
<bcp14>OPTIONAL</bcp14>.
</t> </t>
<dl> <dl newline="true">
<dt> Profile 0 </dt><dd> <dt> Profile 0: </dt><dd>
Profile 0 is the Legacy support of <xref target='RFC6550'/> Non-Storing Profile 0 is the legacy support of <xref target='RFC6550'/> Non-Storing
Mode, with default routing Northwards (up) and strict source routing Mode, with default routing Northwards (up) and strict source routing
Southwards (down the main DODAG). It provides the minimal common Southwards (down the main DODAG). It provides the minimal common
functionality that must be functionality that must be
implemented as a prerequisite to all the Track-supporting profiles. implemented as a prerequisite to all the Track-supporting profiles.
The other Profiles extend Profile 0 with selected capabilities that this
<!--[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. specification introduces on top.
</dd> </dd>
<dt> Profile 1 (Storing Mode P-Route segments along the main DODAG) </dt><dd > <dt> Profile 1 (Storing Mode P-Route segments along the main DODAG): </dt><d d>
Profile 1 does not create new paths; compared to Profile 0, it combines 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 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 in the packet and the amount of state in the intermediate routers in a
Non-Storing Mode RPL DODAG. Non-Storing Mode RPL DODAG.
</dd> </dd>
<dt> Profile 2 (Non-Storing Mode P-Route segments along the main DODAG)</dt>
<dd> <!--[rfced] Is "source routing" correct in these sentences, or should
Profile 2 extends Profile 0 with Strict Source-Routing Non-Storing Mode 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>
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 P-Routes along the main DODAG, which is the same as Profile 1 but using
NSM VIOs as opposed to SM VIOs. Profile 2 provides the same capability to NSM-VIOs as opposed to SM-VIOs. Profile 2 provides the same capability to
compress the SRH in packets down the main DODAG as Profile 1, but it compress the SRH in packets down the main DODAG as Profile 1, but it
requires an encapsulation, in order to insert an additional SRH between requires an encapsulation in order to insert an additional SRH between
the loose source routing hops. the loose source routing hops.
In that case, the Tracks MUST be installed as subTracks of the main DODAG,
<!--[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 o
f the main DODAG,
<!-- DB: not sure what "In that case," refers to. Do you mean "With Profil e 2,? --> <!-- DB: not sure what "In that case," refers to. Do you mean "With Profil e 2,? -->
the main Instance MUST be used as TrackID. Note that the Ingress node and the main Instance <bcp14>MUST</bcp14> be used as the TrackID. Note tha t the Ingress node
encapsulates but is not the Root, as it does not own the DODAGID. encapsulates but is not the Root, as it does not own the DODAGID.
</dd> </dd>
<dt> Profile 3 </dt><dd> <dt> Profile 3: </dt><dd>
In order to In order to
form the best path possible, this Profile requires the support of form the best path possible, this profile requires the support of
Sibling Information Option to inform the Root of additional possible hops. an SIO to inform the Root of additional possible hops.
Profile 3 extends Profile 1 with additional Storing Mode P-Routes Profile 3 extends Profile 1 with additional Storing Mode P-Routes
that install segments that do not follow the main DODAG. 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 of If the segment Ingress (in the SM-VIO) is the same as the IPv6 address of
the Track Ingress (in the projected DAO base Object), the P-DAO creates an the Track Ingress (in the Projected DAO Base Object), the P-DAO creates an
implicit Track between the segment Ingress and the segment Egress. implicit Track between the segment Ingress and the segment Egress.
</dd> </dd>
<dt> Profile 4 </dt><dd> <dt> Profile 4: </dt><dd>
Profile 4 extends Profile 2 with Strict Source-Routing Non-Storing Mode 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 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 not necessarily follow it. A Track is formed as one or more strict source-
routed paths between the Root that is the Track Ingress, and the routed
paths between the Root that is the Track Ingress and the
Track Egress that is the last node. Track Egress that is the last node.
</dd> </dd>
<dt> Profile 5 </dt><dd> <dt> Profile 5: </dt><dd>
Profile 5 Combines Profile 4 with Profile 1 and enables loose source Profile 5 combines Profile 4 with Profile 1 and enables loose source
routing between the Ingress and the Egress of the Track. As in Profile 1, 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. Storing Mode P-Routes form the connections in the loose source route.
</dd> </dd>
<dt> Profile 6 </dt><dd> <dt> Profile 6: </dt><dd>
Profile 6 Combines Profile 4 with Profile 2 and also enables loose Profile 6 combines Profile 4 with Profile 2 and enables loose
source routing between the Ingress and the Egress of the Track. source routing between the Ingress and the Egress of the Track.
</dd> </dd>
<dt> Profile 7 </dt><dd> <dt> Profile 7: </dt><dd>
Profile 7 implements Profile 5 in a main DODAG that is operated in Profile 7 implements Profile 5 in a main DODAG that is operated in
Storing Mode as presented in <xref target='smmd'/>. As in Profile 1 and 2, Storing Mode as presented in <xref target='smmd'/>. As in Profiles 1 and 2 ,
the TrackID is the RPLInstanceID of the main DODAG. Longest match rules 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 decide whether a packet is sent along the main DODAG or rerouted in a
track. Track.
</dd> </dd>
<dt> Profile 8 </dt><dd> <dt> Profile 8: </dt><dd>
Profile 8 is offered in preparation of the RAW work, and for use cases Profile 8 is offered in preparation of the RAW work and for use cases
where an arbitrary node in the network can afford the same code 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 complexity as the RPL Root in a traditional deployment. It offers a full
DODAG visibility to the Track Ingress as specified in <xref target='bfd'/> DODAG visibility to the Track Ingress, as specified in <xref target='bfd'/ >,
in a Non-Storing Mode main DODAG. in a Non-Storing Mode main DODAG.
</dd> </dd>
<dt> Profile 9 </dt><dd> <dt> Profile 9: </dt><dd>
Profile 9 combines profiles 7 and 8, operating the Track as a full DODAG Profile 9 combines Profiles 7 and 8, operating the Track as a full DODAG
within a Storing Mode main DODAG, using only the main DODAG RPLInstanceID within a Storing Mode main DODAG, using only the main DODAG RPLInstanceID
as TrackID. as the TrackID.
</dd> </dd>
</dl> </dl>
</section><!-- Profiles --> </section>
<section anchor='back'><name>Backwards Compatibility</name> <section anchor='back'><name>Backwards Compatibility</name>
<t> <t>
This specification can operate in a mixed network where some nodes support 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 it and some do not. There are restrictions, though. All nodes that need to
process a P-DAO MUST support this specification. process a P-DAO <bcp14>MUST</bcp14> support this specification.
As discussed in <xref target='mtsch'/>, how the root knows the As discussed in <xref target='mtsch'/>, how the root knows the
node capabilities and whether they support this specification is out of scop e. node capabilities and whether they support this specification are out of sco pe.
</t> </t>
<t> <t>
This specification defines the 'D' flag in the RPL DODAG Configuration This specification defines the 'D' flag in the RPL DODAG Configuration
Option (see <xref target='dflag'/>) to signal that the RPL nodes can request 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 the creation of Tracks. The requester may not know whether the Track can
effectively be constructed, and whether enough nodes along the preferred effectively be constructed or whether enough nodes along the preferred
paths support this specification. Therefore, it makes sense to only set the paths support this specification. Therefore, it makes sense to only set the
'D' flags in the DIO when the conditions of success are in place, in particu 'D' flags in the DIO when the conditions for success are in place, in partic
lar ular
when all the nodes that could be on the path of tracks are upgraded. when all the nodes that could be on the path of the Tracks are upgraded.
</t> </t>
</section><!-- Backwards Compatibility --> </section>
<section><name>Security Considerations</name> <section><name>Security Considerations</name>
<t> <t>
It is worth noting that with <xref target='RFC6550'/>, every
It is worth noting that per <xref target='RFC6550'/>, every
node in the LLN is RPL-aware and can inject any RPL-based attack in the 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 network. This specification uses messages that are already present in RPL
<xref target='RFC6550'/> with optional secured versions. The same secured <xref target='RFC6550'/> with optional secured versions. The same secured
versions may be used with this specification, and whatever security is deploy ed for versions may be used with this specification, and whatever security is deploy ed for
a given network also applies to the flows in this specification. a given network also applies to the flows in this specification.
</t> </t>
<t> <t>
The LLN nodes depend on the RPL Root and the RANs for their operation. The LLN nodes depend on the RPL Root and RANs for their operation.
A trust model is necessary to ensure that the right devices are A trust model is necessary to ensure that the right devices are
acting in these roles, avoiding sinkhole attacks (as is done in acting in these roles, avoiding sinkhole attacks (as is done in
<xref target='RFC7416'/> section 7). This trust model could be <xref target='RFC7416' section="7"/>). This trust model could be,
at a minimum based on a Layer-2 Secure joining and the Link-Layer security. at a minimum, based on a Layer 2 secure joining and link-layer security.
This is a generic 6LoWPAN requirement, see Req5.1 in Appendix B.5 of <xref ta This is a generic 6LoWPAN requirement; see Req-5.1 in <xref section="B.5" tar
rget='RFC8505'/>. get='RFC8505'/>.
</t><t> </t><t>
In a general manner, the Security Considerations in <xref target='RFC6550'/> , In a general manner, the Security Considerations in <xref target='RFC6550'/>
and <xref target='RFC7416'/> apply to this specification as well. and <xref target='RFC7416'/> apply to this specification as well.
The Link-Layer security is needed in particular to prevent In particular, link-layer security is needed to prevent
Denial-Of-Service attacks whereby a rogue router creates a high churn in the denial-of-service attacks, whereby a rogue router creates a high churn in th
e
RPL network by constantly injecting forged P-DAO messages and using up all RPL network by constantly injecting forged P-DAO messages and using up all
the available storage in the attacked routers. the available storage in the attacked routers.
</t><t> </t><t>
When applied to radio LLNs such as IEEE std 802.15.4, the lower-layer When applied to radio LLNs such as IEEE Std 802.15.4, the lower-layer
frame protection can be leveraged with an appropriate join protocol. 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 6TiSCH defined <xref target='RFC9031'/> with the RPL Root acting as
6LBR. 6LBR.
The join protocol could be extended to provide additional key material The join protocol could be extended to provide additional key material
for pledge to 6LBR communication when additional end-to-end security for pledges to 6LBR communication when additional end-to-end security
is desired beyond the hop-by-hop security from the lower layer. is desired beyond the hop-by-hop security from the lower layer.
</t><t> </t><t>
With this specification, the Root MAY generate P-DAO messages but With this specification, the Root <bcp14>MAY</bcp14> generate P-DAO messages
other nodes MUST NOT do so. PDR messages MUST be sent to the Root. but
other nodes <bcp14>MUST NOT</bcp14> do so. PDR messages <bcp14>MUST</bcp14> b
e sent to the Root.
This specification expects that the This specification expects that the
communication with the Root is authenticated but does not enforce which metho d communication with the Root is authenticated but does not enforce which metho d
is used. is used.
</t><t> </t><t>
Additionally, the trust model could include a role validation (e.g., using a Additionally, the trust model could include a role validation (e.g., using a
role-based authorization) to ensure that the node that role-based authorization) to ensure that the node that
claims to be a RPL Root is entitled to do so. That trust should propagate 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. from Egress to Ingress in the case of a Storing Mode P-DAO.
</t><t> </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 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 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 protection. Arguably, an attacker that can inject P-DAOs can reroute any
traffic and deplete critical resources such as spectrum and battery in traffic and rapidly deplete critical resources such as the spectrum and batt
the LLN rapidly. ery in
the LLN.
</t> </t>
</section> </section>
<section anchor='IANAcon'><name>IANA Considerations</name> <section anchor='IANAcon'><name>IANA Considerations</name>
<section anchor="iana-d"><name>RPL DODAG Configuration Option Flag</name> <section anchor="iana-d"><name>RPL DODAG Configuration Option Flag</name>
<t> <t>
IANA is requested to assign a flag from the "DODAG Configuration Option
Flags for MOP 0..6" <xref target='RFC9010'/> registry under the heading <!-- [rfced] We have included some specific questions about the IANA
"Routing Protocol for Low Power and Lossy Networks (RPL)" text below. In addition to 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 in the "DODAG Configuration Option
Flags for MOP 0..6" registry <xref target='RFC9008'/> under the
"Routing Protocol for Low Power and Lossy Networks (RPL)" registry group
<xref target='IANA-RPL'/> <xref target='IANA-RPL'/>
as follows: as follows:
</t> </t>
<table anchor="nexndopt"><name>New DODAG Configuration Option Flag</name> <table anchor="nexndopt"><name>New DODAG Configuration Option Flag</name>
<thead> <thead>
<tr><td>Bit Number</td><td>Capability Description</td><td>Reference</td></ <tr><th>Bit Number</th>
tr> <th>Capability Description</th><th>Reference</th></tr>
</thead><tbody> </thead><tbody>
<tr><td>0 (suggested)</td><td>Projected Routes Support (D)</td><td>THIS RF <tr><td align="center">0</td>
C</td></tr> <td>Projected Routes Support (D)</td><td>RFC 9914</td></tr>
</tbody> </tbody>
</table> </table>
<t> <t>
IANA is requested to add [THIS RFC] as a reference for MOP 7 in the IANA has added this RFC as an additional reference for MOP 7 in the
Mode of Operation registry that is part of "Mode of Operation" registry under
the Routing Protocol for Low Power and Lossy Networks (RPL) registry group the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry gro
up
<xref target='IANA-RPL'/>. <xref target='IANA-RPL'/>.
</t> </t>
</section><!-- RPL DODAG Configuration Option Flag --> </section>
<section anchor='elec6lorh'><name>Elective 6LoWPAN Routing Header Type</name> <section anchor='elec6lorh'><name>Elective 6LoWPAN Routing Header Type</name>
<t> <t>
IANA is requested to update the "Elective 6LoWPAN Routing Header Type" regist IANA has updated the "Elective 6LoWPAN Routing Header Type" registry <xref ta
ry that rget='RFC8138'/> under the "IPv6 Low Power Personal Area Network Parameters" reg
was created for <xref target='RFC8138'/> under the heading istry group
"Elective 6LoWPAN Routing Header Type" <xref target='IANA-6LO'/> as follows:
in the "IPv6 Low Power Personal Area Network Parameters" registry group
<xref target='IANA-6LO'/> and assign the following value:
</t> </t>
<table anchor="elec6lorhtbl"><name>New Elective 6LoWPAN Routing Header T ype</name> <table anchor="elec6lorhtbl"><name>New Elective 6LoWPAN Routing Header T ype</name>
<thead> <thead>
<tr><th align='center'>Value</th> <tr><th>Value</th>
<th align='left'>Description</th> <th>Description</th>
<th align='left'>Reference</th></tr> <th>Reference</th></tr>
</thead><tbody> </thead><tbody>
<tr><td align='center'>8 (Suggested)</td> <tr><td align="center">8</td>
<td align='left'>P-RPI-6LoRH</td> <td>P-RPI-6LoRH</td>
<td align='left'>THIS RFC</td></tr> <td>RFC 9914</td></tr>
</tbody> </tbody>
</table> </table>
</section><!-- Elective 6LoWPAN Routing Header Type --> </section>
<section anchor='crit6lorh'><name>Critical 6LoWPAN Routing Header Type</name> <section anchor='crit6lorh'><name>Critical 6LoWPAN Routing Header Type</name>
<t> <t>
IANA is requested to update the "Critical 6LoWPAN Routing Header Type" regist IANA has updated the "Critical 6LoWPAN Routing Header Type" registry <xref ta
ry that was created for <xref target='RFC8138'/> under the heading "Critical 6Lo rget='RFC8138'/>
WPAN Routing Header Type" under the "IPv6 Low Power Personal Area Network Parameters" registry group
<xref target='IANA-6LO'/> as follows:
in the "IPv6 Low Power Personal Area Network Parameters" registry group
<xref target='IANA-6LO'/> and assign the following value:
</t> </t>
<table anchor="crit6lorhtbl"><name>New Critical 6LoWPAN Routing Header T ype</name> <table anchor="crit6lorhtbl"><name>New Critical 6LoWPAN Routing Header T ype</name>
<thead> <thead>
<tr><th align='center'>Value</th> <tr><th>Value</th>
<th align='left'>Description</th> <th>Description</th>
<th align='left'>Reference</th></tr> <th>Reference</th></tr>
</thead><tbody> </thead><tbody>
<tr><td align='center'>8 (Suggested)</td> <tr><td align="center">8</td>
<td align='left'>P-RPI-6LoRH</td> <td>P-RPI-6LoRH</td>
<td align='left'>THIS RFC</td></tr> <td>RFC 9914</td></tr>
</tbody> </tbody>
</table> </table>
</section><!-- Critical 6LoWPAN Routing Header Type --> </section>
<section anchor='RPIIANA'><name>Registry For The RPL Option Flags</name> <section anchor='RPIIANA'><name>Registry for RPL Option Flags</name>
<t> <t>
IANA is requested to create a registry for the 8-bit "RPL Option Flags" field IANA has created the "RPL Option Flags" registry, for the 8-bit RPL Option fl
, as detailed in <xref target='Rpifmt'/>, under the heading "Routing Protocol fo ags field as detailed in <xref target='Rpifmt'/>, under the "Routing Protocol fo
r Low Power and Lossy Networks (RPL)" r Low Power and Lossy Networks (RPL)"
<xref target='IANA-RPL'/>. registry group <xref target='IANA-RPL'/>.
The bits are indexed from 0 (leftmost) to 7. Each bit is tracked with the fol lowing qualities: The bits are indexed from 0 (leftmost) to 7. Each bit is tracked with the fol lowing qualities:
</t> </t>
<ul> <ul>
<li>Bit number (counting from bit 0 as the most significant bit)</li> <li>Bit number (counting from bit 0 as the most significant bit)</li>
<li>Indication When Set</li> <li>Indication when set</li>
<li>Reference</li> <li>Reference</li>
</ul> </ul>
<t> Registration procedure is "Standards Action" <xref target='RFC8126'/>. <t> The registration procedure is Standards Action <xref target='RFC8126'/>.
The initial allocation is as indicated in <xref target='RPLoptFlagtbl'/>: The initial allocation is as indicated in <xref target='RPLoptFlagtbl'/>:
</t> </t>
<table anchor="RPLoptFlagtbl"><name>Initial PDR Flags</name> <table anchor="RPLoptFlagtbl"><name>Initial PDR Flags</name>
<thead> <thead>
<tr><th align='center'>Bit number</th> <tr><th>Bit Number</th>
<th align='left'>Indication When Set</th> <th>Indication When Set</th>
<th align='left'>Reference</th></tr> <th>Reference</th></tr>
</thead><tbody> </thead><tbody>
<tr><td align='center'>0</td> <tr><td align="center">0</td>
<td align='left'>Down 'O'</td> <td>Down (O)</td>
<td align='left'><xref target='RFC6553'/> </td></tr> <td><xref target='RFC6553'/> </td></tr>
<tr><td align='center'>1</td> <tr><td align="center">1</td>
<td align='left'>Rank-Error (R)</td> <td>Rank-Error (R)</td>
<td align='left'><xref target='RFC6553'/> </td></tr> <td><xref target='RFC6553'/> </td></tr>
<tr><td align='center'>2</td> <tr><td align="center">2</td>
<td align='left'>Forwarding-Error (F)</td> <td>Forwarding-Error (F)</td>
<td align='left'><xref target='RFC6553'/> </td></tr> <td><xref target='RFC6553'/> </td></tr>
<tr><td align='center'>3 (Suggested)</td> <tr><td align="center">3</td>
<td align='left'>Projected-Route (P)</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> <tr><td align="center">4..255</td>
<td align='left'>Unassigned</td> <td>Unassigned</td>
<td align='left'> </td></tr> <td> </td></tr>
</tbody> </tbody>
</table> </table>
</section><!-- Registry For The RPL Option Flags --> </section>
<section anchor='RPLCtrlMsgReg'><name>RPL Control Codes</name> <section anchor='RPLCtrlMsgReg'><name>RPL Control Codes</name>
<t> IANA is requested to update the "RPL Control Codes" registry under the h eading "Routing Protocol for Low Power and Lossy Networks (RPL)" <xref target=' IANA-RPL'/> <t> IANA has updated the "RPL Control Codes" registry under the "Routing Pro tocol for Low Power and Lossy Networks (RPL)" registry group <xref target='IANA- RPL'/>
as indicated in <xref target="ianaRPLCtrlMsgtbl"/>:</t> as indicated in <xref target="ianaRPLCtrlMsgtbl"/>:</t>
<table anchor="ianaRPLCtrlMsgtbl"><name>New RPL Control Codes</name> <table anchor="ianaRPLCtrlMsgtbl"><name>New RPL Control Codes</name>
<thead> <thead>
<tr><th align='center'>Code</th> <tr><th>Code</th>
<th align='left'>Description</th> <th>Description</th>
<th align='left'>Reference</th></tr> <th>Reference</th></tr>
</thead><tbody> </thead><tbody>
<tr><td align='center'>0x09 (Suggested)</td> <tr><td align="center">0x09</td>
<td align='left'>Projected DAO Request (PDR)</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> <tr><td align="center">0x0A</td>
<td align='left'>PDR-ACK</td> <td>PDR-ACK</td>
<td align='left'>THIS RFC</td></tr> <td>RFC 9914</td></tr>
</tbody> </tbody>
</table> </table>
</section> <!-- "RPL Control Codes" --> </section>
<section anchor='RPLCtrlMsgOptionsReg'><name>RPL Control Message Options</nam e> <section anchor='RPLCtrlMsgOptionsReg'><name>RPL Control Message Options</nam e>
<t> IANA is requested to update the "RPL Control Message Options" registry u nder the heading "Routing Protocol for Low Power and Lossy Networks (RPL)" <xref target='IANA-RPL'/> <t> IANA has updated the "RPL Control Message Options" registry under the "R outing Protocol for Low Power and Lossy Networks (RPL)" registry group <xref tar get='IANA-RPL'/>
as indicated in <xref target="ianaRPLCtrlMsgopttbl"/>:</t> as indicated in <xref target="ianaRPLCtrlMsgopttbl"/>:</t>
<table anchor="ianaRPLCtrlMsgopttbl"><name>RPL Control Message Options</ name> <table anchor="ianaRPLCtrlMsgopttbl"><name>RPL Control Message Options</ name>
<thead> <thead>
<tr><th align='center'>Value</th> <tr><th>Value</th>
<th align='left'>Meaning</th> <th>Meaning</th>
<th align='left'>Reference</th></tr> <th>Reference</th></tr>
</thead><tbody> </thead><tbody>
<tr><td align='center'>0x0E (Suggested)</td> <tr><td align="center">0x0F</td>
<td align='left'>Stateful VIO (SM-VIO)</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> <tr><td align="center">0x10</td>
<td align='left'>Source-Routed VIO (NSM-VIO)</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> <tr><td align="center">0x11</td>
<td align='left'>Sibling Information option</td> <td>Sibling Information Option (SIO)</td>
<td align='left'>THIS RFC</td></tr> <td>RFC 9914</td></tr>
</tbody> </tbody>
</table> </table>
</section> <!-- "RPL Control Message Options" --> </section>
<section anchor='RPLPDRflagReg'> <section anchor='RPLPDRflagReg'>
<name>SubRegistry for the Projected DAO Request Flags</name> <name>Registry for Projected DAO Request Flags</name>
<t> <t>
IANA is requested to create a registry for the 8-bit "Projected DAO Reques t (PDR)" field under the heading "Routing Protocol for Low Power and Lossy Netwo rks (RPL)" <xref target='IANA-RPL'/>. The bits are indexed from 0 (leftmost) to 7. Each bit is tracked with the following qualities: IANA has created the "Projected DAO Request (PDR) Flags" registry under th e "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 t racked with the following qualities:
</t> </t>
<ul> <ul>
<li>Bit number (counting from bit 0 as the most significant bit)</li> <li>Bit number (counting from bit 0 as the most significant bit)</li>
<li>Capability description</li> <li>Capability description</li>
<li>Reference</li> <li>Reference</li>
</ul> </ul>
<t> Registration procedure is "Standards Action" <xref target='RFC8126'/>. <t> The registration procedure is Standards Action <xref target='RFC8126'/>.
The initial allocation is as indicated in <xref target='RPLPDRflagRegtbl'/>: The initial allocation is as indicated in <xref target='RPLPDRflagRegtbl'/>:
</t> </t>
<table anchor="RPLPDRflagRegtbl"><name>Initial PDR Flags</name> <table anchor="RPLPDRflagRegtbl"><name>Initial PDR Flags</name>
<thead> <thead>
<tr><th align='center'>Bit number</th> <tr><th>Bit Number</th>
<th align='left'>Capability description</th> <th>Capability Description</th>
<th align='left'>Reference</th></tr> <th>Reference</th></tr>
</thead><tbody> </thead><tbody>
<tr><td align='center'>0</td> <tr><td align="center">0</td>
<td align='left'>PDR-ACK request (K)</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> <tr><td align="center">1</td>
<td align='left'>Requested path should be redundant (R)</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> <tr><td align="center">2..255</td>
<td align='left'>Unassigned</td> <td>Unassigned</td>
<td align='left'></td></tr> <td></td></tr>
</tbody> </tbody>
</table> </table>
</section> <!-- SubRegistry for the Projected DAO Request Flags --> </section>
<section anchor='RPLPDRackflagReg'> <section anchor='RPLPDRackflagReg'>
<name>SubRegistry for the PDR-ACK Flags</name> <name>Registry for PDR-ACK Flags</name>
<t> <t>
IANA is requested to create a registry for the 8-bit "PDR-ACK Flags" field un der the heading "Routing Protocol for Low Power and Lossy Networks (RPL)" <xref target='IANA-RPL'/>. The bits are indexed from 0 (leftmost) to 7. Each bit is tr acked with the following qualities: IANA has created the "PDR-ACK Flags" registry under the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry group <xref target='IANA-RPL'/>. T he bits are indexed from 0 (leftmost) to 7. Each bit is tracked with the followi ng qualities:
</t> </t>
<ul> <ul>
<li>Bit number (counting from bit 0 as the most significant bit)</li> <li>Bit number (counting from bit 0 as the most significant bit)</li>
<li>Capability description</li> <li>Capability description</li>
<li>Reference</li> <li>Reference</li>
</ul> </ul>
<t>Registration procedure is "Standards Action" <xref target='RFC8126'/>. <t>The registration procedure is Standards Action <xref target='RFC8126'/>.
No bit is currently assigned for the PDR-ACK Flags. At the time of publication of this document, no bit has been assigned in this
registry.
</t> </t>
</section> <!-- SubRegistry for the PDR-ACK Flags --> </section>
<section anchor='iana-stats-nonrej'> <section anchor='iana-stats-nonrej'>
<name>Registry for the PDR-ACK Acceptance Status Values </name> <name>Registry for PDR-ACK Acceptance Status Values </name>
<t> <t>
IANA is requested to create a registry for the 8-bit "PDR-ACK Acceptance IANA has created the "PDR-ACK Acceptance
Status Values" under the heading "Routing Protocol for Low Power and Lossy N Status Values" registry under the "Routing Protocol for Low Power and Lossy
etworks (RPL)" <xref target='IANA-RPL'/>. Networks (RPL)" registry group <xref target='IANA-RPL'/>.
Each value is tracked with the following qualities: Each value is tracked with the following qualities:
</t> </t>
<ul> <ul>
<li>Value</li> <li>Value</li>
<li>Meaning</li> <li>Meaning</li>
<li>Reference</li> <li>Reference</li>
</ul> </ul>
<t> the possible values are expressed as a 6-bit unsigned integer (0..63). <t> The possible values are expressed as a 6-bit unsigned integer (0..63).
the registration procedure is "Standards Action" <xref target='RFC8126'/>. The registration procedure is Standards Action <xref target='RFC8126'/>.
</t> The initial allocation is as indicated in <xref target='iana-ack-status'/>:
<t> The (suggested) initial allocation is as indicated in <xref target='iana-a
ck-status'/>:
</t> </t>
<table anchor='iana-ack-status'><name>Acceptance values of the PDR-ACK Status </name> <table anchor='iana-ack-status'><name>Acceptance Values of the PDR-ACK Status </name>
<thead> <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> </thead><tbody>
<tr><td>0</td><td>Unqualified Acceptance</td><td>THIS RFC</td></tr> <tr><td align="center">0</td>
<tr><td>1..63</td><td>Unassigned</td><td></td></tr> <td>Unqualified Acceptance</td><td>RFC 9914</td></tr>
<tr><td align="center">1..63</td>
<td>Unassigned</td><td></td></tr>
</tbody> </tbody>
</table> </table>
</section><!-- Registry for the PDR-ACK Acceptance Status Values --> </section>
<section anchor='iana-stats-rej'> <section anchor='iana-stats-rej'>
<name>Registry for the PDR-ACK Rejection Status Values</name> <name>Registry for PDR-ACK Rejection Status Values</name>
<t> <t>
IANA is requested to create a registry for the 6-bit "PDR-ACK Rejection Stat IANA has created the "PDR-ACK Rejection Status Values" registry
us Values" under the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry
under the heading "Routing Protocol for Low Power and Lossy Networks (RPL)" group <xref target='IANA-RPL'/>.
<xref target='IANA-RPL'/>.
Each value is tracked with the following qualities: Each value is tracked with the following qualities:
</t> </t>
<ul> <ul>
<li>Value</li> <li>Value</li>
<li>Meaning</li> <li>Meaning</li>
<li>Reference</li> <li>Reference</li>
</ul> </ul>
<t> the possible values are expressed as a 6-bit unsigned integer (0..63). <t>The possible values are expressed as a 6-bit unsigned integer (0..63).
the registration procedure is "Standards Action" <xref target='RFC8126'/>. The registration procedure is Standards Action <xref target='RFC8126'/>.
</t> The initial allocation is as indicated in <xref target='iana-nack-status'/>:
<t> The (suggected) initial allocation is as indicated in <xref target='iana-n
ack-status'/>:
</t> </t>
<table anchor='iana-nack-status'><name>Rejection values of the PDR-ACK Status </name> <table anchor='iana-nack-status'><name>PDR-ACK Rejection Status Values</name>
<thead> <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> </thead><tbody>
<tr><td>0</td><td>Unqualified Rejection</td><td>THIS RFC</td></tr> <tr><td align="center">0</td><td>Unqualified Rejection</td><td>RFC 9914</t
<tr><td>1</td><td>Transient Failure</td><td>THIS RFC</td></tr> d></tr>
<tr><td>2..63</td><td>Unassigned</td><td></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> </tbody>
</table> </table>
</section><!-- Registry for the PDR-ACK Rejection Status Values --> </section>
<section anchor='RPLVIOflagReg'> <section anchor='RPLVIOflagReg'>
<name>SubRegistry for the Via Information Options Flags</name> <name>Registry for Via Information Options Flags</name>
<t> <t>
IANA is requested to create a registry for the 8-bit "Via Information Options IANA has created the "Via Information Options
(VIO) Flags" field under the heading "Routing Protocol for Low Power and Loss (VIO) Flags" registry under the "Routing Protocol for Low Power and Lossy Net
y Networks (RPL)" <xref target='IANA-RPL'/>. The bits are indexed from 0 (leftmo works (RPL)" registry group <xref target='IANA-RPL'/>. The bits are indexed from
st) to 7. Each bit is tracked with the following qualities: 0 (leftmost) to 7. Each bit is tracked with the following qualities:
</t> </t>
<ul> <ul>
<li>Bit number (counting from bit 0 as the most significant bit)</li> <li>Bit number (counting from bit 0 as the most significant bit)</li>
<li>Capability description</li> <li>Capability description</li>
<li>Reference</li> <li>Reference</li>
</ul> </ul>
<t>Registration procedure is "Standards Action" <xref target='RFC8126'/>. <t>The registration procedure is Standards Action <xref target='RFC8126'/>.
No bit is currently assigned for the VIO Flags, more in <xref target="viof"/ At the time of publication of this document, no bit has been assigned in this
>. registry (see more in <xref target="viof"/>).
</t> </t>
</section> <!-- SubRegistry for the Via Information Options Flags --> </section>
<section anchor='RPLSIOflagReg'> <section anchor='RPLSIOflagReg'>
<name>SubRegistry for the Sibling Information Option Flags</name> <name>Registry for Sibling Information Option Flags</name>
<t> <t>
IANA is requested to create a registry for the 5-bit "Sibling Information IANA has created the "Sibling Information
Option (SIO) Flags" field under the heading "Routing Protocol for Low Power a Option (SIO) Flags" registry under the "Routing Protocol for Low Power and Lo
nd Lossy Networks (RPL)" <xref target='IANA-RPL'/>. The bits are indexed from 0 ssy Networks (RPL)" registry group <xref target='IANA-RPL'/>. The bits are index
(leftmost) to 4. Each bit is tracked with the following qualities: ed from 0 (leftmost) to 4. Each bit is tracked with the following qualities:
</t> </t>
<ul> <ul>
<li>Bit number (counting from bit 0 as the most significant bit)</li> <li>Bit number (counting from bit 0 as the most significant bit)</li>
<li>Capability description</li> <li>Capability description</li>
<li>Reference</li> <li>Reference</li>
</ul> </ul>
<t> Registration procedure is "Standards Action" <xref target='RFC8126'/>. The initial allocation is as indicated in <xref target='RPLSIORegtbl'/>, more in <xr ef target="siof"/>: <t> The registration procedure is Standards Action <xref target='RFC8126'/>. Th e initial allocation is as indicated in <xref target='RPLSIORegtbl'/> (see more in <xref target="siof"/>):
</t> </t>
<table anchor="RPLSIORegtbl"><name>Initial SIO Flags</name> <table anchor="RPLSIORegtbl"><name>Initial SIO Flags</name>
<thead> <thead>
<tr><th align='center'>Bit number</th> <tr><th>Bit Number</th>
<th align='left'>Capability description</th> <th>Capability Description</th>
<th align='left'>Reference</th></tr> <th>Reference</th></tr>
</thead><tbody> </thead><tbody>
<tr><td align='center'>0 (Suggested)</td> <tr><td align="center">0</td>
<td align='left'>"S" flag: Sibling in same DODAG as Self</td> <td>'S' flag: Sibling in same DODAG as self</td>
<td align='left'>THIS RFC</td></tr> <td>RFC 9914</td></tr>
<tr><td align='center'>1..4</td> <tr><td align="center">1..4</td>
<td align='left'>Unassigned</td> <td>Unassigned</td>
<td align='left'></td></tr> <td></td></tr>
</tbody> </tbody>
</table> </table>
</section> <!-- SubRegistry for the Sibling Information Option Flags --> </section>
<section anchor="iana-P-DAO"><name>Destination Advertisement Object Flag</name> <section anchor="iana-P-DAO"><name>Destination Advertisement Object Flag</name>
<t> <t>
IANA is requested to update the "Destination Advertisement Object (DAO) Flag IANA has updated the "Destination Advertisement Object (DAO) Flags"
s" registry, created in <xref target='RFC6550' section="20.11"/>, under the
registry created in Section 20.11 of <xref target='RFC6550'/> under the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry group <xr
heading "Routing Protocol for Low Power and Lossy Networks (RPL)" <xref targ ef target='IANA-RPL'/> as
et='IANA-RPL'/> as indicated in <xref target="iana-P-DAOtbl"/> (see more in <xref target="extP-
indicated in <xref target="iana-P-DAOtbl"/>, DAO"/>):
more in <xref target="extP-DAO"/>:
</t> </t>
<table anchor="iana-P-DAOtbl"> <table anchor="iana-P-DAOtbl">
<name>New Destination Advertisement Object (DAO) Flag</name> <name>New Destination Advertisement Object (DAO) Flag</name>
<thead> <thead>
<tr><td>Bit Number</td><td>Capability Description</td><td>Reference</td></ <tr><th>Bit Number</th>
tr> <th>Capability Description</th><th>Reference</th></tr>
</thead><tbody> </thead><tbody>
<tr><td>2 (Suggested)</td><td>Projected DAO (P)</td><td>THIS RFC</td></tr> <tr><td align="center">2</td>
<td>Projected DAO (P)</td><td>RFC 9914</td></tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="iana-P-DAO-aCK"><name>Destination Advertisement Object Acknowle dgment Flag</name> <section anchor="iana-P-DAO-aCK"><name>Destination Advertisement Object Acknowle dgment Flag</name>
<t> IANA is requested to update the "Destination Advertisement Object (DAO) <t> IANA has updated the "Destination Advertisement Object (DAO) Acknowledgm
Acknowledgment Flags" registry created in Section 20.12 of <xref target='RFC6550 ent Flags" registry, created in <xref target='RFC6550' section="20.12"/>, under
'/> under the heading "Routing Protocol for Low Power and Lossy Networks (RPL)" the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry group <xr
<xref target='IANA-RPL'/> as indicated in <xref target="iana-P-DAO-ACKtbl"/>, ef target='IANA-RPL'/> as indicated in <xref target="iana-P-DAO-ACKtbl"/> (see
more in <xref target='extP-DAO-ACK'/>: more in <xref target='extP-DAO-ACK'/>):
</t> </t>
<table anchor="iana-P-DAO-ACKtbl"> <table anchor="iana-P-DAO-ACKtbl">
<name>New Destination Advertisement Object Acknowledgment Flag</name> <name>New Destination Advertisement Object Acknowledgment Flag</name>
<thead> <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> </thead><tbody>
<tr><td>1 (Suggested)</td><td>Projected DAO-ACK (P)</td><td>THIS RFC</td>< /tr> <tr><td align="center">1</td><td>Projected DAO-ACK (P)</td><td>RFC 9914</t d></tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor='ICMPv6ErrPRoute'> <section anchor='ICMPv6ErrPRoute'>
<name>New ICMPv6 Error Code</name> <name>ICMPv6 Error Code</name>
<t>In some cases RPL will return an ICMPv6 error message when a <t>In some cases, RPL will return an ICMPv6 error message when a
message cannot be forwarded along a P-Route.</t> message cannot be forwarded along a P-Route.</t>
<t> This specification requires that a new code is allocated from the <t>Per this specification, IANA has updated the
'ICMPv6 "Code" Fields' heading of the "Internet Control Message Protocol "Type 1 - Destination Unreachable" registry, in the
version 6 (ICMPv6) Parameters" <xref target='IANA-ICMP'/> Registry for "ICMPv6 'Code' Fields" registry, under the "Internet Control Message Prot
"Type 1 - Destination Unreachable", ocol
with a suggested code value of 9, to be confirmed by IANA to indicate an version 6 (ICMPv6) Parameters" registry group <xref target='IANA-ICMP'/>
"Error in P-Route".</t> as indicated in <xref target="iana-ICMPv6_error_code"/>.</t>
</section> <!--"ICMPv6: Error in a P-Route" -->
<section anchor='iana-stats-rpl-rej'><name>RPL Rejection Status values </name> <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 P-Route</td><td>RFC 9914</td></tr>
</tbody>
</table>
<t> IANA is requested to update the "RPL Rejection Status" registry </section>
under the heading "Routing Protocol for Low Power and Lossy Networks (RPL)"
<xref target='IANA-RPL'/> <section anchor='iana-stats-rpl-rej'><name>RPL Rejection Status Values </name>
<t> IANA has updated the "RPL Rejection Status" registry
under the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry
group <xref target='IANA-RPL'/>
as indicated in <xref target="iana-nack-Status"/>: as indicated in <xref target="iana-nack-Status"/>:
</t> </t>
<table anchor='iana-nack-Status'><name>Rejection values of the RPL Status </n ame> <table anchor='iana-nack-Status'><name>RPL Rejection Status Values </name>
<thead> <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> </thead><tbody>
<tr><td>2 (Suggested)</td><td>Out of Resources</td><td>THIS RFC</td></tr> <tr><td align="center">2</td><td>Out of Resources</td><td>RFC 9914</td></t
<tr><td>3 (Suggested)</td><td>Error in VIO</td><td>THIS RFC</td></tr> r>
<tr><td>4 (Suggested)</td><td>Predecessor Unreachable</td><td>THIS RFC <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> </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> </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> </tbody>
</table> </table>
</section> <!-- Registry for RPL Rejection Status values --> </section>
</section> <!-- "IANA Considerations"-->
<section><name>Acknowledgments</name>
<t>The authors wish to acknowledge JP Vasseur, Remy Liubing, James Pylakutty,
and Patrick Wetterwald for their contributions to the ideas developed here.
Many thanks to Dominique Barthel and SVR Anand for their global contribution
to 6TiSCH, RAW and this RFC, as well as text suggestions that were
incorporated.
Also special thanks to Remous-Aris Koutsiamanis, Li Zhao, Dominique Barthel,
and 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 for his review during WGLC and to
Ines Robles for her shepherding and thorough review.
Many thanks to Warren Kumari, Ran Chen, Murray Kucherawy, Roman Danyliw, Klaa
s Wierenga, Deb Cooley, Eric Vyncke, Gunter Van de Velde, Sue Hares and John Scu
dder for their comments and suggestions during the IETF last call and IESG revie
w cycle.
</t>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="RFC1122" to="INT-ARCHI"/> <displayreference target="RFC1122" to="INT-ARCH"/>
<displayreference target="RFC4944" to="6LoWPAN"/> <displayreference target="RFC4944" to="6LoWPAN"/>
<displayreference target="RFC6550" to="RPL"/> <displayreference target="RFC6550" to="RPL"/>
<displayreference target="I-D.ietf-raw-architecture" to="RAW-ARCHI"/> <displayreference target="I-D.kuehlewind-rswg-updates-tag" to="NEW-TAGS"/>
<displayreference target="RFC9912" to="RAW-ARCH"/>
<references> <references>
<name>References</name>
<!-- [rfced] Would you like the references to be alphabetized
or left in their current order?
-->
<references>
<name>Normative References</name> <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'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe <!-- [RAW-ARCHI] /[RFC9912] - in AUTH48 as of 2/9/2026
rence.RFC.2119.xml'/> draft-ietf-raw-architecture-30
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe companion doc RFC 9912
rence.RFC.4443.xml'/> -->
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe <reference anchor="RFC9912" target="https://www.rfc-editor.org/info/rfc9912">
rence.RFC.6282.xml'/> <front>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe <title>Reliable and Available Wireless (RAW) Architecture</title>
rence.RFC.6550.xml'/> <author initials="P." surname="Thubert" fullname="Pascal
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe Thubert" role="editor">
rence.RFC.6553.xml'/> <organization>Without Affiliation</organization>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe </author>
rence.RFC.6554.xml'/> <date month='February' year='2026'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe </front>
rence.RFC.8126.xml'/> <seriesInfo name="RFC" value="9912"/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe <seriesInfo name="DOI" value="10.17487/RFC9912"/>
rence.RFC.8138.xml'/> </reference>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.8174.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.9008.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.9030.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
nce.I-D.ietf-raw-architecture.xml'/>
</references><references> </references><references>
<name>Informative References</name> <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'/>
<!-- 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'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe <!--[rfced] FYI: "draft-kuehlewind-update-tag" has been replaced by
rence.RFC.1122.xml'/> "draft-kuehlewind-rswg-updates-tag", so we have updated this
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe reference entry accordingly. Please let us know of any objection.
rence.RFC.4655.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.4861.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.4944.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.5440.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.6997.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.7102.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.7416.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.8025.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.8402.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.8505.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.8754.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.8655.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.8930.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.8931.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refe
rence.RFC.8994.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.9010.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.9031.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.9035.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.9450.xml'/>
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refere
nce.I-D.kuehlewind-update-tag.xml'/>
<xi:include href="http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/referenc Original:
e.I-D.irtf-panrg-path-properties.xml"/> [I-D.kuehlewind-update-tag]
Kühlewind, M. and S. Krishnan, "Definition of new tags for
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>.
<reference anchor='IANA-6LO' target='https://www.iana.org/assignment Current:
s/icmpv6-parameters/'> [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>.
-->
<!-- [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.kuehlewi
nd-rswg-updates-tag.xml'/>
<reference anchor='IANA-6LO' target='https://www.iana.org/assignment
s/_6lowpan-parameters'>
<front> <front>
<title>IPv6 Low Power Personal Area Network Parameters registry</tit le> <title>IPv6 Low Power Personal Area Network Parameters</title>
<author> <author>
<organization>IETF</organization> <organization>IANA</organization>
</author> </author>
<date/> <date/>
</front> </front>
</reference> </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/assignment s/rpl/'> <reference anchor='IANA-RPL' target='https://www.iana.org/assignment s/rpl/'>
<front> <front>
<title>Routing Protocol for Low Power and Lossy Networks (RPL) regis try group</title> <title>Routing Protocol for Low Power and Lossy Networks (RPL)</titl e>
<author> <author>
<organization>IETF</organization> <organization>IANA</organization>
</author> </author>
<date/> <date/>
</front> </front>
</reference> </reference>
<reference anchor='IANA-ICMP' target='https://www.iana.org/assignmen ts/icmpv6-parameters/'> <reference anchor='IANA-ICMP' target='https://www.iana.org/assignmen ts/icmpv6-parameters/'>
<front> <front>
<title>Internet Control Message Protocol version 6 (ICMPv6) Paramete rs registry group</title> <title>Internet Control Message Protocol version 6 (ICMPv6) Paramete rs</title>
<author> <author>
<organization>IETF</organization> <organization>IANA</organization>
</author> </author>
<date/> <date/>
</front> </front>
</reference> </reference>
</references> </references>
</references>
</back> <section numbered="false">
<name>Acknowledgments</name>
<t>The authors wish to acknowledge <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 <contact fullname="Dominique Barthel"/> and <contact
fullname="S.V.R. Anand"/> for their global contribution to 6TiSCH, RAW, and this
RFC, as well as text suggestions that were incorporated. Also, special thanks
to <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 the content of the
specification. Many thanks to <contact fullname="Remous-Aris Koutsiamanis"/>
for his review during WG Last Call and to <contact fullname="Maria Ines Robles"/
> for her
thorough shepherd review. Many thanks to <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"/>, <contact fullname="Sue
Hares"/>, and <contact fullname="John Scudder"/> for their comments and
suggestions during the IETF Last Call and IESG review cycle.
</t>
</section>
</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 -> 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-archite
cture-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) [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 (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#tab
le1>
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> </rfc>
 End of changes. 941 change blocks. 
2152 lines changed or deleted 3522 lines changed or added

This html diff was produced by rfcdiff 1.48.