ROLL                                                     P. Thubert, Ed.
Internet-Draft                                             Cisco Systems
Updates: 6554 (if approved)                                  R.A. Jadhav
Intended status: Standards Track                             Huawei Tech                             R.A. Jadhav
Expires: 28 January 25 March 2022                                       Huawei Tech
                                                             M. Gillmore
                                                                   Itron
                                                            27 July
                                                       21 September 2021

                  Root initiated routing state in RPL
                   draft-ietf-roll-dao-projection-19
                   draft-ietf-roll-dao-projection-20

Abstract

   This document extends RFC 6550 and 6550, RFC 6553 6553,and RFC 8138 to enable a RPL
   Root to install and maintain Projected Routes within its DODAG, along
   a selected set of nodes that may or may not include self, for a
   chosen duration.  This potentially enables routes that are more
   optimized or resilient than those obtained with the classical
   distributed operation of RPL, either in terms of the size of a
   Routing Header or in terms of path length, which impacts both the
   latency and the packet delivery ratio.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 28 January 25 March 2022.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.

   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5   4
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   5   4
     2.2.  Glossary  .  References  . . . . . . . . . . . . . . . . . . . . . . .   5   4
     2.3.  Other Terms  Glossary  . . . . . . . . . . . . . . . . . . . . . . .   6
     2.4.  References .   4
     2.4.  Domain Terms  . . . . . . . . . . . . . . . . . . . . . .   6   5
   3.  Extending RFC 6550  Context and Goal  . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Projected DAO . .  RPL Applicability . . . . . . . . . . . . . . . . . . . .   7
     3.2.  Sibling Information Option  RPL Routing Modes . . . . . . . . . . . . . . . . . . . .   8
     3.3.  P-DAO Request  On Tracks . . . . . . . . . . . . . . . . . . . . . . . .   9
     3.4.  Extending the RPI  Serial Track Signaling  . . . . . . . . . . . . . . . . .  10
       3.4.1.  Using Storing Mode Segments . . .   9
   4.  Extending RFC 6553 . . . . . . . . . .  11
       3.4.2.  Using Non-Storing Mode joining Tracks . . . . . . . .  17
     3.5.  Complex Tracks  . . .   9
   5.  Extending RFC 8138 . . . . . . . . . . . . . . . . . .  24
     3.6.  Scope and Expectations  . . .  10
   6.  New RPL Control Messages and Options . . . . . . . . . . . .  11
     6.1.  New P-DAO Request Control Message . .  26
   4.  Extending existing RFCs . . . . . . . . . .  11
     6.2.  New PDR-ACK Control Message . . . . . . . . .  28
     4.1.  Extending RFC 6550  . . . . . .  12
     6.3.  Via Information Options . . . . . . . . . . . . .  28
       4.1.1.  Projected DAO . . . .  13
     6.4.  Sibling Information Option . . . . . . . . . . . . . . .  16
   7.  Projected DAO .  28
       4.1.2.  Via Information Option  . . . . . . . . . . . . . . .  30
       4.1.3.  Sibling Information Option  . . . . . . . .  18
     7.1.  Requesting a Track . . . . .  30
       4.1.4.  P-DAO Request . . . . . . . . . . . . . .  19
     7.2.  Identifying a Track . . . . . .  30
       4.1.5.  Extending the RPI . . . . . . . . . . . . .  20
     7.3.  Installing a Track . . . . .  30
     4.2.  Extending RFC 6553  . . . . . . . . . . . . . .  21
       7.3.1.  Storing-Mode P-Route . . . . .  31
     4.3.  Extending RFC 8138  . . . . . . . . . . .  22
       7.3.2.  Non-Storing-Mode P-Route . . . . . . . .  32
   5.  New RPL Control Messages and Options  . . . . . .  24
     7.4.  Forwarding Along a Track . . . . . .  33
     5.1.  New P-DAO Request Control Message . . . . . . . . . .  26
   8.  Profiles . .  33
     5.2.  New PDR-ACK Control Message . . . . . . . . . . . . . . .  34
     5.3.  Via Information Options . . . . . . . . .  27
   9.  Example Track Signaling . . . . . . . .  36
     5.4.  Sibling Information Option  . . . . . . . . . . .  28
     9.1.  Using Storing-Mode Segments . . . .  39
   6.  Root Initiated Routing State  . . . . . . . . . . .  29
       9.1.1.  Stitched Segments . . . . .  41
     6.1.  Requesting a Track  . . . . . . . . . . . . .  29
       9.1.2.  External routes . . . . . .  41
     6.2.  Identifying a Track . . . . . . . . . . . . .  31
       9.1.3.  Segment Routing . . . . . .  42
     6.3.  Installing a Track  . . . . . . . . . . . . .  32
     9.2.  Using Non-Storing-Mode joining Tracks . . . . . . . . . .  34
       9.2.1.  Stitched Tracks . .  43
       6.3.1.  Signaling a Projected Route . . . . . . . . . . . . .  44
       6.3.2.  Installing a Track Segment with a Storing Mode
               P-Route . . . .  34
       9.2.2.  External routes . . . . . . . . . . . . . . . . . . .  36
       9.2.3.  Segment Routing  45
       6.3.3.  Installing a Track Leg with a Non-Storing Mode
               P-Route . . . . . . . . . . . . . . . . . . .  38
   10. Security Considerations . . . .  47
     6.4.  Tearing Down a P-Route  . . . . . . . . . . . . . . .  41
   11. IANA Considerations . .  49
     6.5.  Maintaining a Track . . . . . . . . . . . . . . . . . . .  41
     11.1.  New Elective 6LoWPAN Routing Header Type  49
       6.5.1.  Maintaining a Track Segment . . . . . . . .  41
     11.2.  New Critical 6LoWPAN Routing Header Type . . . . .  50
       6.5.2.  Maintaining a Track Leg . . .  42
     11.3.  New Subregistry For The RPL Option Flags . . . . . . . .  42
     11.4.  New RPL Control Codes . . . .  50
     6.6.  Encapsulating and Forwarding Along a Track  . . . . . . .  51
     6.7.  Compression of the RPL Artifacts  . . . . . .  43
     11.5.  New RPL Control Message Options . . . . . .  53
   7.  Lesser Constrained Variations . . . . . .  43
     11.6.  SubRegistry for the Projected DAO Request Flags . . . .  43
     11.7.  SubRegistry for the PDR-ACK Flags . . . . . .  55
     7.1.  Storing Mode Main DODAG . . . . .  44
     11.8.  Subregistry for the PDR-ACK Acceptance Status Values . .  44
     11.9.  Subregistry for the PDR-ACK Rejection Status Values . .  44
     11.10. SubRegistry for the Via Information Options Flags . . .  45
     11.11. SubRegistry for the Sibling Information Option Flags . .  45
     11.12. New Destination Advertisement Object Flag . . .  55
     7.2.  A Track as a Full DODAG . . . .  46
     11.13. Error in Projected Route ICMPv6 Code . . . . . . . . . .  46
   12. Acknowledgments . . .  57
   8.  Profiles  . . . . . . . . . . . . . . . . . . . .  46
   13. Normative References . . . . . .  58
   9.  Security Considerations . . . . . . . . . . . . . .  46
   14. Informative References . . . . .  60
   10. IANA Considerations . . . . . . . . . . . . . .  47
   Appendix A.  Applications . . . . . . .  60
     10.1.  New Elective 6LoWPAN Routing Header Type . . . . . . . .  61
     10.2.  New Critical 6LoWPAN Routing Header Type . . . . .  49
     A.1.  Loose Source Routing . . .  61
     10.3.  New Subregistry For The RPL Option Flags . . . . . . . .  61
     10.4.  New RPL Control Codes  . . . . . . .  49
     A.2.  Transversal Routes . . . . . . . . . .  62
     10.5.  New RPL Control Message Options  . . . . . . . . .  51
   Authors' Addresses . . .  62
     10.6.  SubRegistry for the Projected DAO Request Flags  . . . .  63
     10.7.  SubRegistry for the PDR-ACK Flags  . . . . . . . . . . .  63
     10.8.  Subregistry for the PDR-ACK Acceptance Status Values . .  63
     10.9.  Subregistry for the PDR-ACK Rejection Status Values  . .  64
     10.10. SubRegistry for the Via Information Options Flags  . . .  64
     10.11. SubRegistry for the Sibling Information Option Flags . .  65
     10.12. New destination Advertisement Object Flag  . . . . . . .  65
     10.13. New ICMPv6 Error Code  . . . . . . . . . . . . . . . . .  65
     10.14. New RPL Rejection Status values  . . . . . . . . . . . .  66
   11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  66
   12. Normative References  . . . . . . . . . . . . . . . . . . . .  66
   13. Informative References  . . . . . . . . . . . . . . . . . . .  68
   Appendix A.  Applications . . . . . . . . . . . . . . . . . . . .  70
     A.1.  Loose Source Routing  . . . . . . . . . . . . . . . . . .  70
     A.2.  East-West Routes  . . . . . . . . . . . . . . . . . . . .  72
   Authors' Addresses  . . . . . . . . .  52 . . . . . . . . . . . . . .  73

1.  Introduction

   RPL, the "Routing Protocol for Low Power and Lossy Networks" [RPL]
   (LLNs), is a generic an anisotropic Distance Vector protocol that is well well-
   suited for application in a variety of low energy Internet of Things
   (IoT)
   networks. networks where stretched P2P paths are acceptable vs. the
   signaling and state overhead involved in maintaining shortest paths
   across.

   RPL forms Destination destination Oriented Directed Acyclic Graphs (DODAGs) in
   which the Root often acts as the Border Router router to connect the RPL
   domain to the Internet.  The Root is responsible to select
   the RPL Instance IP backbone and routes along that is used to forward a packet coming from the
   Internet into graph up, towards the RPL domain
   Root, and set down towards the related RPL information nodes.

   With this specification, a Path Computation Element [PCE] in an
   external controller interacts with the packets. 6TiSCH uses RPL for its routing operations. Root to compute centrally
   shorter Peer to Peer (P2P) paths within a pre-existing RPL Main
   DODAG.  The "6TiSCH Architecture" [6TiSCH-ARCHI] also leverages the
   "Deterministic Networking Architecture" [RFC8655] centralized model
   whereby the device resources and capabilities are exposed topological information that is passed to an
   external controller which installs routing states into the network
   based on some objective functions PCE is
   derived from the DODAG that reside is already available at the Root in RPL
   Non-Storing Mode.  This specification introduces protocol extensions
   that external
   entity.  With DetNet and 6TiSCH, enrich the component of the controller topological information that is responsible of computing routes is called a Path Computation
   Element ([PCE]). available at the Root
   and passed to the PCE.

   Based on heuristics of usage, path length, and knowledge of device
   capacity and available resources
   such as battery levels and reservable buffers, buffers in the nodes, the PCE
   with a global visibility on the system can compute direct Peer to Peer (P2P) optimize the computed
   routes that are optimized for the needs expressed by an objective function. application needs, including the capability to provide
   path redundancy.  This document
   specifies specification also introduces protocol
   extensions to RPL [RPL] that enable the Root of a
   main DODAG to translates the computed paths into
   RPL and install centrally-computed routes them as Projected Routes (aka P-Routes) inside the
   DODAG on behalf of a PCE.

   This specification expects that the main RPL Instance is operated

2.  Terminology

2.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in
   RPL Non-Storing Mode of Operation (MOP) this document are to sustain the exchanges with
   the Root.  In that Mode, the Root has enough information to build a
   basic DODAG topology based on parents be interpreted as described in BCP
   14 [RFC2119][RFC8174] when, and children, but lacks the
   knowledge of siblings.  This document adds the capability for nodes
   to advertise sibling information only when, they appear in order to improve the topological
   awareness of the Root.

   As opposed to the classical RPL operations where routes all
   capitals, as shown here.

2.2.  References

   In this document, readers will encounter terms and concepts that are injected
   by the Target nodes,
   discussed in the protocol extensions enable "Routing Protocol for Low Power and Lossy Networks"
   [RPL], the Root of a
   DODAG to project "6TiSCH Architecture" [6TiSCH-ARCHI], the routes that are needed onto "Deterministic
   Networking Architecture" [RFC8655], the nodes where they
   should be installed. "Reliable and Available
   Wireless (RAW) Architecture/Framework" [RAW-ARCHI], and "Terminology
   in Low power And Lossy Networks" [RFC7102].

2.3.  Glossary

   This specification document often uses the term Projected
   Route to refer to those routes.  Projected Routes can be used to
   reduce the size of the source routing headers following acronyms:

   CMO:  Control Message Option
   DAO:  destination Advertisement Object
   DAG:  Directed Acyclic Graph
   DODAG:  destination-Oriented Directed Acyclic Graph; A DAG with loose source
   routing operations down the main RPL DODAG.  Projected Routes can
   also be used to build transversal routes for route optimization only
      one vertex (i.e., node) that has no outgoing edge (i.e., link)
   GUA:  IPv6 Global Unicast Address
   LLN:  Low-Power and
   Traffic Engineering purposes, between nodes Lossy Network
   MOP:  RPL Mode of the DODAG.

   A Operation
   P-DAO:  Projected DAO
   P-Route:  Projected Route may be installed in either Storing and Non-Storing
   Mode, potentially resulting in hybrid situations where the
   PDR:  P-DAO Request
   RAN:  RPL-Aware Node (either a RPL router or a RPL-Aware Leaf)
   RAL:  RPL-Aware Leaf
   RH:  Routing Header
   RPI:  RPL Packet Information
   RTO:  RPL Target Option
   RUL:  RPL-Unaware Leaf
   SIO:  RPL Sibling Information Option
   ULA:  IPv6 Unique Local Address
   NSM-VIO:  A Source-Routed Via Information Option, used in Non-Storing
      Mode of
   the Projected Route is different from that of the main P-DAO messages.
   TIO:  RPL Instance. Transit Information Option
   SM-VIO:  A Projected Route may strict Via Information Option, used in Storing Mode P-DAO
      messages.
   VIO:  A Via Information Option; it can be a stand-alone end-to-end path SM-VIO or an NSM-VIO.

2.4.  Domain Terms

   Projected Route:  A RPL P-Route is a Segment
   in RPL route that is computed
      remotely by a more complex forwarding graph called PCE, and installed and maintained by a Track.

   The concept RPL Root on
      behalf of a Track was introduced in the 6TiSCH architecture, PCE.  It is installed as a potentially complex path with redundant forwarding solutions state that signals that
      destinations (aka Targets) are reachable along
   the way.  With this specification, a Track is sequence of
      nodes.
   Projected DAO:  A DAO message used to install a DODAG formed by P-Route.
   Path:  Quoting section 1.1.3 of [INT-ARCHI]: "At a RPL
   local Instance that is rooted at given moment, all
      the Track Ingress.  If there is IP datagrams from a
   single Track Egress, then the Track is reversible particular source host to form another
   DODAG by reversing a particular
      destination host will typically traverse the direction same sequence of each edge.  A node at
      gateways.  We use the ingress
   of more than one Segment term "path" for this sequence.  Note that a
      path is uni-directional; it is not unusual to have different paths
      in the two directions between a Track may use one or more given host pair.".
      Section 2 of these
   Segments [I-D.irtf-panrg-path-properties] points to forward a packet inside the Track.

   The "Reliable 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 Available Wireless (RAW) Architecture/Framework"
   [RAW-ARCHI] defines ending with a node.  A path is
      unidirectional.  Paths are time-dependent, i.e., the Path Selection Engine (PSE) sequence of
      path elements over which packets are sent from one node to another
      may change.  A path is defined between two nodes.  "
      It follows that adapts the
   use general acceptance of the a path redundancy within is a Track linear
      sequence of nodes, as opposed to defeat a multi-dimensional graph.  In
      the diverse
   causes context of this document, a path is observed by following one
      copy of a packet loss.

   The PSE that is injected in a dataplane extension of the PCE; it controls Track and possibly
      replicated within.
   Track:  A networking graph that can be followed to transport packets
      with equivalent treatment; as opposed to the
   forwarding operation definition of the packets within a Track, using path
      above, a Track Track is not necessarily linear.  It may contain
      multiple paths that may fork and rejoin, and may enable the RAW
      Packet ARQ, Replication, Elimination, and Overhearing (PAREO) functions over the
   Track segments, to provide
      operations.
      This specification builds Tracks that are DODAGs oriented towards
      a dynamic balance between the reliability Track Ingress, and availability requirements of the flows and forward direction for packets is East-
      West from the need Track Ingress to conserve
   energy and spectrum.

   The time scale at which one of the PCE (re)computes possibly multiple Track
      Egress Nodes, which is also down the DODAG.
      The Track can may be long, strictly connected, meaning that the vertices are
      adjacent, or loosely connected, meaning that the vertices are
      connected using long-term statistical metrics Segments that are associated to perform global optimizations
   at the scale of same Track.
   TrackID:  A RPL Local InstanceID that identifies a Track using the whole network.  Conversely,
      namespace owned ny the PSE makes
   forwarding decisions at Track Ingress.  The TrackID is associated
      with the time scale of one or a small collection IPv6 Address of packets, based on a knowledge that is limited in scope to the Track itself, so it can be refreshed at a fast pace.

   Projected Routes must be Ingress that is used with as
      DODAGID, and together they form a unique identification of the parsimony to limit
      Track (see the amount definition of state DODAGID in section 2 of [RPL].
   Serial Track:  A Track that is has only one path.
   Stand-Alone:  A single P-DAO that fully defines a Track, e.g., a
      Serial Track installed in each device to fit with a single Storing Mode Via Information
      option (SM-VIO).
   subTrack:  A Track within a Track.  As the device
   resources, and to maintain the amount Non-Storing Mode Via
      Information option (NSM-VIO) can only signal a loose sequence of rerouted traffic within the
   capabilities
      nodes, it takes a number of the transmission links.  The methods used them to learn
   the node capabilities and the resources that are available in the
   devices and in the network are out of scope signal a complex Track.  Each
      NSM-VIO for this document.

   This specification uses the RPL Root as same TrackId but a proxy different Segment ID signals a
      different subTracks that the Track Ingress adds to the PCE.  The PCE
   may topology.
   Track Leg:  An end-to-end East-West serial path that can be collocated with the Root, a Track
      by itself or may reside in an external
   Controller.

   In that case, the PCE exchanges control messages with the Root over a
   Southbound API that is out subTrack of scope for a complex Track.  With this specification.  The
   algorithm to compute the paths and the protocol used
      specification, a Leg is is installed by an external
   PCE to obtain the topology of the network from the Root are also out of scope.

2.  Terminology

2.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119][RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.2.  Glossary

   This document often uses the following acronyms:

   CMO:  Control Message Option
   DAO:  Destination Advertisement Object
   DAG:  Directed Acyclic Graph
   DODAG:  Destination-Oriented Directed Acyclic Graph; A DAG with only
      one vertex (i.e., node) that has no outgoing edge (i.e., link)
   LLN:  Low-Power and Lossy Network
   MOP:  RPL Mode of Operation
   P-DAO:  Projected DAO
   P-Route:  Projected Route
   PDR:  P-DAO Request
   RAN:  RPL-Aware Node (either a RPL Router or a RPL-Aware Leaf)
   RAL:  RPL-Aware Leaf
   RH:  Routing Header
   RPI:  RPL Packet Information
   RTO:  RPL Target Option
   RUL:  RPL-Unaware Leaf
   SIO:  RPL Sibling Information Option
   SR-VIO:  A Source-Routed Via Information Option, used in Non-Storing- main DODAG
      using Non-Storing Mode P-DAO messages.
   TIO:  RPL Transit Information Option
   SF-VIO:  A Via Information Option, used in Storing-Mode P-DAO
      messages.
   VIO:  A Via Information Option; messages, and it can be a SF-VIO or an SR-VIO.

2.3.  Other Terms

   Projected Route:  A RPL Projected Route is expressed as a RPL route
      loose sequence of nodes that is
      computed remotely by a PCE, and installed and maintained are joined by a RPL
      Root on behalf of the PCE. Track Segments.
   Track Segment:  A serial path formed by a strict sequence of node nodes,
      along which a route P-Route is installed.  With this specification, a
      Segment is typically installed by the Root of the main DODAG using Storing-Mode
      Storing Mode P-DAO messages.
   Projected DAO:  A DAO message Segment used to install a Projected Route.
   Track:  A DODAG that provides as the topological
      edge of a complex path Track.  Since this specification builds only DODAGs, all
      Segments are oriented from or Ingress (East) to a Root Egress (West), as
      opposed to the general RAW model, which allows North/South
      Segments that can be bidirectional.

3.  Context and Goal
3.1.  RPL Applicability

   RPL is optimized for situations where the destination of the DODAG.  The Root power is scarce, the Track Ingress,
   bandwidth constrained and the forward direction for packets transmissions unreliable.  This matches
   the use case of an IoT LLN where RPL is down typically used today, but
   also situations of high relative mobility between the DODAG, from nodes in the
      Track Ingress
   network (aka swarming), e.g., within a variable set of vehicles with
   a similar global motion, or a toon of drones.

   To reach this goal, RPL is primarily designed to one minimize the control
   plane activity, that is the relative amount of routing protocol
   exchanges vs. data traffic, and the possibly amount of state that is
   maintained in each node.  RPL does not need converge, and provides
   connectivity to most nodes most of the time.

   RPL may form multiple Track Egress topologies called instances.  Instances can be
   created to enforce various optimizations through objective functions,
   or to reach out through different Root Nodes.  The DODAG may be strictly connected, meaning that concept of
   objective function allows to adapt the vertices are
      adjacent, or loosely connected, meaning that activity of the vertices are
      connected using Segments that are associated routing
   protocol to the same Track.
      With this specification, a Track is installed by the Root use case, e.g., type, speed, and quality of the
      main DODAG using Non-Storing-Mode P-DAO messages.
   TrackID:  A LLN
   links.

   RPL Local InstanceID with instances operate as ships in the D bit set to 0. night, unbeknownst of one
   another.  The
      TrackID RPL Root is associated with the IPv6 Address of responsible to select the Track Ingress RPL Instance that
   is used to signal forward a packet coming from the DODAG Root, Backbone into the RPL
   domain and together they form a
      unique identification of set the Track (see related RPL information in the definition of DODAGID
      in section 2 packets. 6TiSCH
   leverages RPL for its distributed routing operations.

   To reduce the routing exchanges, RPL leverages an anisotropic
   Distance Vector approach, which does not need a global knowledge of [RPL].

2.4.  References

   In this document, readers will encounter terms and concepts that are
   discussed in
   the "Routing Protocol for Low Power and Lossy Networks"
   [RPL] topology, and "Terminology in Low power And Lossy Networks" [RFC7102].

3.  Extending RFC 6550
3.1.  Projected DAO

   Section 6 of [RPL] introduces only optimizes the RPL Control Message Options (CMO),
   including routes to and from the RPL Target Option (RTO) and Transit Information Option
   (TIO), which can Root,
   allowing P2P paths to be placed in stretched.  Although RPL messages such installs its routes
   proactively, it only maintains them lazily, in reaction to actual
   traffic, or as the Destination
   Advertisement Object (DAO). a slow background activity.

   This specification extends the DAO
   message with is simple and efficient in situations where the Projected DAO (P-DAO); a P-DAO message signals a
   Projected Route to one traffic is
   mostly directed from or more Targets using the new CMOs presented
   therein.  This specification enables to combine one or more Projected
   Routes into a DODAG called central node, such as the control
   traffic between routers and a Track, that controller of a Software Defined
   Networking (SDN) infrastructure or an Autonomic Control Plane (ACP).

   But stretch in P2P routing is traversed counter-productive to reach the
   Targets.

   The Track is assimilated with the DODAG formed for a Local RPL
   Instance.  The local RPLInstanceID both reliability
   and latency as it introduces additional delay and chances of the Track loss.
   As a result, [RPL] is called the
   TrackID, more in Section 7.2.  A P-DAO message for not a Track signals
   the TrackID in good fit for the RPLInstanceID field.  The Track Ingress is
   signaled use cases listed in the DODAGID field of the Projected DAO Base Object; that
   field is elided
   RAW use cases document [USE-CASES], which demand high availability
   and reliability, and as a consequence require both short and diverse
   paths.

3.2.  RPL Routing Modes

   RPL first forms a default route in each node towards the case of a Root, and
   those routes together coalesce as a Directed Acyclic Graph upwards.
   RPL then constructs routes to so-called Targets in the main reverse
   direction, down the same DODAG.  So do so, a RPL Instance. Instance can be
   operated either in RPL Storing or Non-Storing Mode of Operation (MOP)
   The Track
   Ingress is default route towards the Root of is maintained aggressively and may
   change while a packet progresses without causing loops, so the Track, packet
   will still reach the Root.

   In Non-Storing Mode, each node advertises itself as shown in Figure 1.

   This specification defines a Target directly
   to the new "Projected DAO" (P) flag.  The 'P'
   flag is encoded in bit position 2 (to Root, indicating the parents that may be confirmed by IANA) used to reach self.
   Recursively, the Root builds and maintains an image of the
   Flags field whole
   DODAG in memory, and leverages that abstraction to compute source
   route paths for the DAO Base Object.  The Root MUST set it packets to 1 in their destinations down the DODAG.
   When a
   Projected DAO message.  Otherwise node changes its point(s) of attachment to the DODAG, it MUST be set takes
   single unicast packet to 0.  It is set the Root along the default route to
   0 in legacy implementations as specified respectively update
   it, and the connectivity is restored immediately; this mode is
   preferable for use cases where internet connectivity is dominant, or
   when, like here, the Root controls the network activity in Sections
   20.11 the nodes.

   In Storing Mode, the routing information percolates upwards, and 6.4 each
   node maintains the routes to the subDAG of [RPL]. .

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    TrackID    |K|D|P|  Flags  |   Reserved    | DAOSequence   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                                                               |
     +               IPv6 Address of the Track Ingress               +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Option(s)...
     +-+-+-+-+-+-+-+-+

                    Figure 1: Projected DAO Base Object

   New fields:

   TrackID:  In the case of a P-DAO, its descendants down the RPLInstanceID field is called
      TrackID.  This
   DODAG.  The maintenance is lazy, either reactive upon traffic or as a naming convenience but does not change
   slow background process.  Packets flow via the
      semantics common parent and format of the RPLInstanceID that
   routing stretch is used as TrackID.

   P:  1-bit flag (position to be confirmed by IANA).

      The 'P' flag reduced vs. Non-Storing, for a better P2P
   connectivity, while the internet connectivity is set restored more
   slowly, time for the DV operation to 1 operate hop-by-hop.

   Either way, the RPL routes are injected by the Root to signal Target nodes, in a Projected DAO,
      and it is set to 0 otherwise.

   In
   distributed fashion.  To complement RPL and eliminate routing
   stretch, this specification introduces an hybrid mode that combines
   Storing and Non-Storing Mode, operations to build and project routes onto
   the TIO nodes where they should be installed.  This specification uses
   the term P-Route to refer to those routes.

   A P-Route may be installed in either Storing and RTO are combined Non-Storing Mode,
   potentially resulting in a DAO
   message to inform hybrid situations where the DODAG Root Mode of all the edges in the DODAG, which
   are formed by P-
   Route is different from that of the directed parent-child relationships.  Options may RPL Main DODAG.  P-Routes can be factorized; multiple RTOs may be present
   used as stand-alone segments to signal a collection of
   children that can be reached via the parent(s) indicated in reduce the
   TIO(s) that follows size of the RTOs.  This specification generalizes source routing
   headers with loose source routing operations down the
   case of a parent that main RPL DODAG.
   P-Routes can also be used combined with other P-Routes to reach form a child with that of more
   complex forwarding graph called a
   whole Track.

3.3.  On Tracks

   A Track through which both children and siblings is typically a collection of the parallel loose source routed
   sequences of nodes from Ingress to Egress, forming so-called Track
   Egress
   Legs, that are reachable.

   New CMOs called the Via Information Options (VIO) joined with strict Segments of other nodes.  The Legs
   are introduced for
   use expressed in P-DAO messages as a multihop alternative RPL Non-Storing Modes and require an encapsulation
   to the TIO.  One VIO
   is the Stateful VIO (SF-VIO); the SF-VIO installs Storing-Mode
   Projected Route along a strict segment.  The other is the Source-
   Routed VIO (SR-VIO); the SR-VIO installs add a Non-Storing-Mode Projected Source Route at Header, whereas the Segments are expressed in
   Storing Mode.

   A Serial Track Ingress, which uses that state comprises provides only one path between Ingress and
   Egress.  It comprises at most one Leg. A Stand-Alone Segment defines
   implicitly a Serial Track from its Ingress to encapsulate Egress.

   A complex Track forms a
   packet with graph that provides a Routing Header (RH) collection of potential
   paths to provide redundancy for the Track Egress.

   Like in packets, either as a DAO message, the RTOs can collection
   of Legs that may be factorized in a P-DAO, but the
   Via Information Options cannot.  A P-DAO contains one parallel or cross at certain points, or as a more RTOs
   that indicate
   generic DODAG.

   The concept of a Track was introduced in the destinations "6TiSCH Architecture"
   [6TiSCH-ARCHI], as a collection of potential paths that can be reached via leverage
   redundant forwarding solutions along the Track, and
   exactly one VIO way.  With this
   specification, a Track forms DODAG that signals is directed towards a sequence of nodes.  In Non-Storing
   Mode, the Root sends the P-DAO to the Track Ingress where the source-
   routing state
   Ingress.  If there is stored.  In Storing Mode, a single Track Egress, then the P-DAO Track is sent
   reversible to form another DODAG by reversing the
   Track Egress and forwarded along direction of each
   edge.  A node at the Ingress of more than one Segment in the reverse
   direction, installing a Storing Mode state to the Track Egress at
   each hop.  In both cases the Track Ingress is may
   use one or more of these Segments to forward a packet inside the owner
   Track.

   Section 5.1. of [RPL] describes the Track, RPL Instance and it generates the P-DAO-ACK when the installation is successful.

3.2.  Sibling Information Option

   This specification adds another CMO called the Sibling Information
   Option (SIO) 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
   namespace that is used indexed by a RPL Aware Node (RAN) to advertise a
   selection of its candidate neighbors as siblings to DODAGID, where the Root, more in
   Section 6.4.  The sibling selection process is out of scope.  The
   expectation DODAGID is that a node reports a Sibling Unique
   Local Address in (ULA) or a SIO based
   on an active address registration [RFC8505] from that sibling for
   that address with the 'R' flag not set in the EARO.  The node may
   assess Global Unicast Address (GUA) of the liveliness Root of
   the sibling at any time by performing a
   registration for one of its own addresses, either a link local or DODAG.

   A Track is normally associated with a
   global one, depending on whether the node expects Local RPL Instance which
   RPLInstanceID is used as the sibling to
   perform a matching advertisement TrackID, more in its own SIO.

3.3.  P-DAO Request

   Two new RPL Control Messages are Section 6.2.  A Track
   Leg may also introduced, to enable be used as a RAN subTrack that extends the RPL main DODAG.
   In that case, the TrackID is set to
   request the establishment global RPLInstanceID of a Track between self as the Track
   Ingress Node and a Track Egress.  The RAN makes its request by
   sending a new P-DAO Request (PDR) Message
   main DODAG, which suffices to identify the Root.  The Root
   confirms with a new PDR-ACK message back routing topology.  As
   opposed to local RPL instances, the requester RAN, see
   Section 6.1 for more.  A positive PDR-ACK indicates Track Ingress that encapsulates
   the Track
   was built packets over a subtrack is not Root, and that the Roots commits source address
   of the encapsulated packet is not used to maintain determine the Track Track.

   A P-DAO message for a Track signals the
   negotiated lifetime. TrackID in the RPLInstanceID
   field.  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, local RPL Instance, the same, or longer than that address of the
   Track.  The Root may use an asynchronous PDR-ACK with an negative
   status Track
   Ingress to indicate that be used as source to encapsulated packets along the Track was terminated before its time.

3.4.  Extending the RPI

   Sending a Packet within a RPL Local Instance requires
   is signaled in the presence DODAGID field of the abstract RPL Packet Information (RPI) described in section 11.2.
   of [RPL] in the outer IPv6 Header chain (see [USEofRPLinfo]).  The
   RPI carries a local RPLInstanceID which, in association with either
   the source or the destination address Projected DAO Base Object;
   that field is elided in the IPv6 Header, indicates case of the RPL Instance that the packet follows. Main DODAG, see Figure 3.

3.4.  Serial Track Signaling

   This specification extends [RPL] to create a new flag that signals
   that introduces the concept of a packet is forwarded P-Route along either a projected route.

   Projected-Route 'P':  1-bit flag.  It is set to 1 if this packet is
      sent over
   Track Leg or a projected route Segment.  A P-Route is installed and set to 0 otherwise.

4.  Extending RFC 6553

   "The RPL Option for Carrying maintained using
   an extended RPL Information in Data-Plane Datagrams"
   [RFC6553]describes DAO message called a Projected DAO (P-DAO), and a
   Track is composed of the RPL Option for use among RPL routers to
   include combination of one or more P-Routes.  This
   specification introduces the abstract RPL Packet Via Information (RPI) described in
   section 11.2. of [RPL] in data packets.

   The RPL Option is commonly referred (VIO) to as the RPI though the RPI is
   really the abstract information that is transported signal a
   sequence of hops in a Leg or a Segment in the P-DAO messages, either
   in Storing Mode (SM-VIO) or NON-Storing Mode (NSM-VIO).  One P-DAO
   messages contains a single VIO, associated to one or more RPL
   Option.  [USEofRPLinfo] updated Target
   Options that signal the Option Type from 0x63 to 0x23.

   This specification modifies destination IPv6 addresses that can reached
   along the Track.

   Before diving deeper into Track Legs and Segments signaling and
   operation, this section provides examples of what how route
   projection works through variations of a simple example.  In this
   simple example we show host routes though RPL Option to encode the 'P' flag as
   follows:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     |  Option Type  |  Opt Data Len |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |O|R|F|P|0|0|0|0| RPLInstanceID |          SenderRank           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         (sub-TLVs)                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Targets can be
   prefixes.  Say we want to build a Serial Track from node A to E in
   Figure 2: Extended RPL Option Format

   Option Type:  0x23 or 0x63, see [USEofRPLinfo]

   Opt Data Len:  See [RFC6553]

   'O', 'R' 1, so A can route packets to E's neighbors F and 'F' flags:  See [RFC6553].  Those flags MUST be set G along A, B,
   C, D and E as opposed to 0
      by via the sender Root:

                                                 /===> F
                   A ===> B ===> C ===> D===> E <
                                                 \===> G

                         Figure 1: Reference Track

   Conventionally we use ==> to represent a strict hop and ignored by the receiver if the 'P' flag is set.

   Projected-Route 'P':  1-bit flag as defined --> for a
   loose hop.  We use -to- like in Section 3.4.

   RPLInstanceID:  See [RFC6553].  Indicates the TrackId if the 'P' flag
      is set.

   SenderRank:  See [RFC6553].  This field MUST be set C==>D==>E-to-F to 0 by represent coma-
   separated Targets, e.g., F is a Target for Segment C==>D==>E.  In
   this example, A is Track Ingress, E is Track Egress.  C is a
   stitching point.  F and G are "external" Targets for the
      sender Track, and ignored by
   become reachable from A via the receiver if Track A(ingress) to E (Egress and
   implicit Target in Non-Storing Mode) leading to F and G (explicit
   Targets).

   In a general manner the 'P'flag desired outcome is set.

5.  Extending RFC 8138

   Section 6.3 of [RFC8138] presents the formats of as follows:

   *  Targets are E, F, and G

   *  P-DAO 1 signals C==>D==>E
   *  P-DAO 2 signals A==>B==>C

   *  P-DAO 3 signals F and G via the 6LoWPAN Routing
   Header A-->E Track

   P-DAO 3 may be ommitted if P-DAO 1 and 2 signal F and G as Targets.

   Loose sequences of type 5 (RPI-6LoRH) that compresses hops must be expressed in Non-Storing Mode, so
   P-DAO 3 contains a NSM-VIO.  With this specification, the RPI for normal RPL
   operation.  The format of DODAGID to
   be used by the RPI-6LoRH Ingress as source address is not suited for Projected
   routes since signaled if needed in the O,R,F flags are not used
   DAO base object, the via list starts at the first loose hop and
   matches the Rank is unknown source route header, and
   ignored.

   This specification introduces a new 6LoRH, the P-RPI-6LoRH, with a
   type Egress of 7.  The P-RPI-6LoRH header is usually a a Critical 6LoWPAN
   Routing Header, but it can be elective as well if Non-Storing Mode
   P-DAO is an SRH-6LoRH implicit Target that is
   present not listed in the RTO.

3.4.1.  Using Storing Mode Segments

   A==>B==>C and controls C==>D==>E are segments of a same Track.  Note that the routing decision.

   The P-RPI-6LoRH is designed to compress
   Storing Mode signaling imposes strict continuity in a segment, since
   the RPI along RPL Projected
   Routes.  It sformat P-DAO is passed hop by hop, as follows:

                0 a classical DAO is, along the
   reverse datapath that it signals.  One benefit of strict routing is
   that loops are avoided along the Track.

3.4.1.1.  Stitched Segments

   In this formulation:

   *  P-DAO 1 signals C==>D==>E-to-F,G

   *  P-DAO 2
                0 signals A==>B==>C-to-F,G

   Storing Mode P-DAO 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 7  | RPLInstanceID |
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 3: P-RPI-6LoRH Format

   Elective 'E':  See [RFC8138].  The 'E' flag is set to 1 to indicate
      an Elective 6LoRH, meaning that it can be ignored when forwarding.

6.  New RPL Control Messages and Options

6.1.  New P-DAO Request Control Message

   The P-DAO Request (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
   this node is Track Ingress.  The source IPv6 address of the PDR
   signals the Track Ingress of the requested Track, E and the TrackID when it is
   indicated in the message itself.  One and only one RPL Target Option
   MUST be present in the message.  The RTO signals the Track Egress,
   more in Section 7.1.

   The RPL Control Code for the PDR succesfully
   acknowledged, Storing Mode P-DAO 2 is 0x09, sent to be confirmed by IANA.
   The format of PDR Base Object is C, as follows:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0

           +====================+==============+==============+
           |       Field        | P-DAO 1 to E | P-DAO 2 3 4 5 6 7 8 9 0 to C |
           +====================+==============+==============+
           |        Mode        | Storing      | Storing      |
           +--------------------+--------------+--------------+
           |   Track Ingress    | A            | A            |
           +--------------------+--------------+--------------+
           | (DODAGID, TrackID) | (A, 129)     | (A, 129)     |
           +--------------------+--------------+--------------+
           |     SegmentID      | 1            | 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+            |   TrackID     |K|R|   Flags
           +--------------------+--------------+--------------+
           |  ReqLifetime        VIO         | PDRSequence C, D, E      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A, B, C      |   Option(s)...
     +-+-+-+-+-+-+-+-+

                     Figure 4: New
           +--------------------+--------------+--------------+
           |      Targets       | F, G         | F, G         |
           +--------------------+--------------+--------------+

                         Table 1: P-DAO Request Format

   TrackID:  8-bit field indicating the RPLInstanceID associated with
      the Track.

   K:  The 'K' flag is set to indicate that the recipient is expected to
      send a PDR-ACK back.

   R:  The 'R' flag is set to request a Complex Track for redundancy.

   Flags:  Reserved.  The Flags field MUST initialized to zero by the
      sender and MUST be ignored by the receiver

   ReqLifetime:  8-bit unsigned integer.  The requested lifetime for the
      Track expressed in Lifetime Units (obtained from the DODAG
      Configuration option).

      A PDR with a fresher PDRSequence refreshes the lifetime, and a
      PDRLifetime of 0 indicates that the track should be destroyed.

   PDRSequence:  8-bit wrapping sequence number, obeying the operation
      in section 7.2 of [RPL].  The PDRSequence is used to correlate a
      PDR-ACK message with the PDR message that triggered it.  It is
      incremented at each PDR message and echoed in the PDR-ACK by the
      Root.

6.2.  New PDR-ACK Control Message

   The new PDR-ACK is sent as a response to Messages

   As a PDR message with the 'K'
   flag set.  The RPL Control Code for result the PDR-ACK is 0x0A, to be
   confirmed by IANA.  Its format is RIBs are set as follows:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         +======+=============+=========+=============+==========+
         |    TrackID Node |     Flags destination | Track Lifetime|  PDRSequence Origin  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Next Hop(s) | PDR-ACK Status|                Reserved TrackID  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         +======+=============+=========+=============+==========+
         |  Option(s)...
     +-+-+-+-+-+-+-+

                Figure 5: New PDR-ACK Control Message Format

   TrackID:  The RPLInstanceID of the Track that was created.  The value
      of 0x00 is used to when no Track was created.

   Flags:  Reserved.  The Flags field MUST initialized to zero  E   | F, G        | P-DAO 1 | Neighbor    | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  D   | E           | P-DAO 1 | Neighbor    | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  "   | F, G        | P-DAO 1 | E           | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  C   | D           | P-DAO 1 | Neighbor    | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  "   | F, G        | P-DAO 1 | D           | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  B   | C           | P-DAO 2 | Neighbor    | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  "   | F, G        | P-DAO 2 | C           | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  A   | B           | P-DAO 2 | Neighbor    | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  "   | F, G        | P-DAO 2 | B           | (A, 129) |
         +------+-------------+---------+-------------+----------+

                            Table 2: RIB setting

   Packets originated by A to F or G do not require an encapsulation as
   the
      sender and MUST RPI can be ignored by placed in the receiver

   Track Lifetime:  Indicates native header chain.  For packets that remaining Lifetime for
   it routes, A must encapsulate to add the Track,
      expressed in Lifetime Units; RPI that signals the value
   trackID; the outer headers of zero (0x00) indicates the packets that are forwarded along
   the Track was destroyed or not created.

   PDRSequence:  8-bit wrapping sequence number.  It is incremented at
      each PDR message and echoed in have the PDR-ACK.

   PDR-ACK Status:  8-bit field indicating the completion.  The PDR-ACK
      Status is substructured as indicated following settings:

    +========+===================+===================+================+
    | Header | IPv6 Source Addr. | IPv6 Dest.  Addr. | TrackID in Figure 6:

                                 0 1 2 3 4 5 6 7
                                +-+-+-+-+-+-+-+-+
                                |E|R|  Value RPI |
                                +-+-+-+-+-+-+-+-+

                       Figure 6: PDR-ACK status Format

      E:  1-bit flag.  Set to indicate
    +========+===================+===================+================+
    | Outer  |         A         |       F or G      |    (A, 129)    |
    +--------+-------------------+-------------------+----------------+
    | Inner  |       X != A      |       F or G      |      N/A       |
    +--------+-------------------+-------------------+----------------+

                      Table 3: Packet Header Settings

   As an example, say that A has a rejection.  When not set, packet for F.  Using the
         value of 0 indicates Success/Unqualified acceptance and other
         values indicate "not an outright rejection".
      R:  1-bit flag.  Reserved, MUST be set RIB above:

   *  From P-DAO 2: A forwards to 0 by the sender B and
         ignored by the receiver.
      Status Value:  6-bit unsigned integer.  Values depending on the
         setting of the 'E' flag, see Table 27 B forwards to C.

   *  From P-DAO 1: C forwards to D and Table 28.

   Reserved:  The Reserved field MUST initialized D forwards to zero by E.

   *  From Neighbor Cache Entry: C delivers the sender packet to F.

3.4.1.2.  External routes

   In this example, we consider F and MUST be ignored by the receiver

6.3.  Via Information Options

   A VIO signals the ordered list of IPv6 Via Addresses G as destinations that constitutes are
   external to the hops of either a Serial Track or as a Segment DODAG, as discussed in section 4.1.1. of a
   [RFC9008].  We then apply the directives for encapsulating in that
   case, more Complex
   Track.  A VIO MUST contain at least one Via Address, and a Via
   Address MUST NOT be present more than once, otherwise in Section 6.6.

   In this formulation, we set up the VIO MUST be
   ignored.  The format of Track Leg explicitly, which
   creates less routing state in intermediate hops at the Via Information Options is as follows:

        0                   1                   2                   3
        0 expense of
   larger packets to accommodate source routing:

   *  P-DAO 1 signals C==>D==>E-to-E

   *  P-DAO 2 signals A==>B==>C-to-E

   *  P-DAO 3 4 5 6 7 8 9 0 signals F and G via the A-->E-to-F,G Track

   Storing Mode P-DAO 1 2 3 4 5 6 7 8 9 0 and 2, and Non-Storing Mode P-DAO 3, are sent to
   E, C and A, respectively, as follows:

    +====================+==============+==============+==============+
    |                    | P-DAO 1 to E | P-DAO 2 to C | P-DAO 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ to A |   Type
    +====================+==============+==============+==============+
    | Option Length        Mode        |     Flags Storing      |   SegmentID Storing      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Segm. Sequence Non-Storing  | Seg. Lifetime
    +--------------------+--------------+--------------+--------------+
    |      SRH-6LoRH header   Track Ingress    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A            | A            |
       +                                                               +
       .                                                               .
       .                     Via Address 1                             .
       .                                                               .
       +                                                               + A            |
    +--------------------+--------------+--------------+--------------+
    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (DODAGID, TrackID) | (A, 129)     |
       .                              ....                             . (A, 129)     | (A, 129)     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    +--------------------+--------------+--------------+--------------+
    |     SegmentID      |
       +                                                               +
       .                                                               .
       .                     Via Address n                             .
       .                                                               .
       +                                                               + 1            | 2            | 3            |
    +--------------------+--------------+--------------+--------------+
    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 7:        VIO format (uncompressed form)

   Option Type:  0x0B for SF-VIO, 0x0C for SR-VIO (to be confirmed by
      IANA)

   Option Length:  In bytes; variable, depending on the number of Via
      Addresses and         | C, D, E      | A, B, C      | E            |
    +--------------------+--------------+--------------+--------------+
    |      Targets       | E            | E            | F, G         |
    +--------------------+--------------+--------------+--------------+

                          Table 4: P-DAO Messages

   Note in the compression.

   SegmentID:  8-bit field above that identifies a Segment within E is not an implicit Target in Storing mode,
   so it must be added in the RTO.

   As a Track or result the main DODAG RIBs are set as indicated by the follows:

         +======+=============+=========+=============+==========+
         | Node | destination | Origin  | Next Hop(s) | TrackID field.  The value of 0
      is used  |
         +======+=============+=========+=============+==========+
         |  E   | F, G        | P-DAO 1 | Neighbor    | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  D   | E           | P-DAO 1 | Neighbor    | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  C   | D           | P-DAO 1 | Neighbor    | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  "   | E           | P-DAO 1 | D           | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  B   | C           | P-DAO 2 | Neighbor    | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  "   | E           | P-DAO 2 | C           | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  A   | B           | P-DAO 2 | Neighbor    | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  "   | E           | P-DAO 2 | B           | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  "   | F, G        | P-DAO 3 | E           | (A, 129) |
         +------+-------------+---------+-------------+----------+

                            Table 5: RIB setting

   Packets from A to signal a Serial Track, i.e., made of a single segment.

   Segment Sequence:  8-bit unsigned integer. E do not require an encapsulation.  The Segment Sequence
      obeys the operation in section 7.2 outer
   headers of [RPL] and the lollipop
      starts at 255.

      When packets that are forwarded along the Root of Track have the DODAG needs to refresh or update a Segment
   following settings:

   +========+===================+====================+================+
   | Header | IPv6 Source Addr. | IPv6 Dest.  Addr.  | TrackID in
      a Track, it increments the Segment Sequence individually for RPI |
   +========+===================+====================+================+
   | Outer  |         A         |         E          |    (A, 129)    |
   +--------+-------------------+--------------------+----------------+
   | Inner  |         X         | E (X != A), F or G |      N/A       |
   +--------+-------------------+--------------------+----------------+

                     Table 6: Packet Header Settings

   As an example, say that
      Segment.

      The Segment information indicated in the VIO deprecates any state A has a packet for F.  Using the Segment indicated by RIB above:

   *  From P-DAO 3: A encapsulates the SegmentID within packet the indicated Track and sets up the new information.

      A VIO signaled by
      P-DAO 3, with a Segment Sequence that is not as fresh as the current
      one outer header above.  Now the packet destination
      is ignored. E.

   *  From P-DAO 2: A VIO for a given DODAGID with the same (TrackID, SegmentID,
      Segment Sequence) indicates a retry; it MUST NOT change the
      Segment forwards to B and MUST be propagated or answered as B forwards to C.

   *  From P-DAO 1: C forwards to D and D forwards to E; E decapsulates
      the first copy. packet.

   *  From Neighbor Cache Entry: C delivers packets to F or G.

3.4.1.3.  Segment Lifetime:  8-bit unsigned integer. Routing

   In this formulation leverages Track Legs to combine Segments and form
   a Graph.  The length of time in
      Lifetime Units (obtained packets are source routed from the Configuration option) that the
      Segment is usable.

      The period starts when a new Segment Sequence is seen.  The value
      of 255 (0xFF) represents infinity.  The value of zero (0x00)
      indicates to the next to
   adapt the path.  As such, this can be seen as a loss form of reachability.

      A P-DAO message that contains a VIO with a Segment Lifetime of
      zero is referred as a No-Path
   Routing [RFC8402]:

   *  P-DAO 1 signals C==>D==>E-to-E

   *  P-DAO in this document.

   SRH-6LoRH header:  The first 2 bytes of signals A==>B-to-B,C

   *  P-DAO 3 signals F and G via the (first) SRH-6LoRH A-->C-->E-to-F,G Track

   Storing Mode P-DAO 1 and 2, and Non-Storing Mode P-DAO 3, are sent to
   E, B and A, respectively, as
      shown in Figure 6 of [RFC8138]. follows:

    +====================+==============+==============+==============+
    |                    | P-DAO 1 to E | P-DAO 2 to B | P-DAO 3 to A 6LoRH Type of 4 means that the
      VIA Addresses are provided |
    +====================+==============+==============+==============+
    |        Mode        | Storing      | Storing      | Non-Storing  |
    +--------------------+--------------+--------------+--------------+
    |   Track Ingress    | A            | A            | A            |
    +--------------------+--------------+--------------+--------------+
    | (DODAGID, TrackID) | (A, 129)     | (A, 129)     | (A, 129)     |
    +--------------------+--------------+--------------+--------------+
    |     SegmentID      | 1            | 2            | 3            |
    +--------------------+--------------+--------------+--------------+
    |        VIO         | C, D, E      | A, B         | C, E         |
    +--------------------+--------------+--------------+--------------+
    |      Targets       | E            | C            | F, G         |
    +--------------------+--------------+--------------+--------------+

                          Table 7: P-DAO Messages

   Note in full with no compression.

   Via Address:  An IPv6 address along the Segment.

      In a SF-VIO, the list is a strict path between direct neighbors,
      from the Segment Ingress to Egress, both included.  The router above that processes an SF-VIO MAY create additional routing state
      towards the nodes after self via Segment can terminate at the node immediately after self loose hop as
   used in the SF-VIO, but in case example of memory shortage the routes to the
      Targets have precedence since they are the ones that the router
      commits to store.

      In an SR-VIO, the list includes the egress but not the ingress
      node.  It starts P-DAO 1 or at the first previous hop and ends at a Track Egress.  In
      that case, the Track Egress MUST be considered as an implicit
      Target, so it MUST NOT be listed it in a RPL Target Option.  The
      list in an SR-VIO may be loose, provided that each listed node has
      a path to the next listed node, e.g., via a segment or another
      Track.

      In the case of done with
   P-DAO 2.  Both methods are possible on any Segment joined by a SF-VIO, or if [RFC8138] is not used in the data
      packets, then the Root MUST use only one SRH-6LoRH per Via
      Information Option, and the compression is the same for all the
      addresses, as shown in Figure 7.

      In case of an SR-VIO, and if [RFC8138] is in use in the main
      DODAG, then the Root SHOULD optimize the size of the SR-VIO; loose
   Track Leg. P-DAO 1 generates more
      than one SRH-6LoRH may be present, e.g., if the compression level
      changes inside signaling since E is the Segment and different SRH-6LoRH Types are
      required.  The content of the SR-VIO starting at the first SRH-
      6LoRH header is thus verbatim
   Egress when D could be, but has the one benefit that the Track Ingress
      places in the packet encapsulation to reach the Track Ingress.

6.4.  Sibling Information Option

   The Sibling Information Option (SIO) provides indication on siblings it validates that could be used by
   the Root to form Projected Routes.  One or more
   SIO(s) may be placed in connectivity between D and E still exists.

   As a result the DAO messages that RIBs are sent to the Root in
   Non-Storing Mode.

   The format of the SIO is set as follows:

        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

         +======+=============+=========+=============+==========+
         | Node | destination | Origin  | Next Hop(s) | TrackID  |
         +======+=============+=========+=============+==========+
         |  E   | F, G        | P-DAO 1 2 3 4 5 6 7 8 9 0 | Neighbor    | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  D   | E           | P-DAO 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |   Type Neighbor    | Option Length |Comp.|B|D|Flags|    Opaque (A, 129) |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         +------+-------------+---------+-------------+----------+
         |            Step of Rank  C   |          Reserved D           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ P-DAO 1 | Neighbor    | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  "   | E           | P-DAO 1 |
       +                                                               +
       .                                                               .
       .       Sibling DODAGID (if the D flag not set)               .
       .                                                               .
       +                                                               +           | (A, 129) |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         +------+-------------+---------+-------------+----------+
         |  B   |
       +                                                               +
       .                                                               .
       .                     Sibling Address                           .
       .                                                               .
       +                                                               + C           | P-DAO 2 | Neighbor    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  A   | B           | P-DAO 2 | Neighbor    | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  "   | C           | P-DAO 2 | B           | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  "   | E, F, G     | P-DAO 3 | C, E        | (A, 129) |
         +------+-------------+---------+-------------+----------+

                            Table 8: Sibling Information Option Format

   Option Type:  0x0D (to be confirmed by IANA)

   Option Length:  In bytes, the size RIB setting

   Packets originated at A to E do not require an encapsulation, but
   carry a SRH via C.  The outer headers of the option.

   Compression Type:  3-bit unsigned integer.  This is the SRH-6LoRH
      Type as defined in figure 7 in section 5.1 of [RFC8138] packets that
      corresponds to are
   forwarded along the compression used for Track have the Sibling Address and
      its DODAGID if resent.  The Compression reference is following settings:

   +========+===================+====================+================+
   | Header | IPv6 Source Addr. | IPv6 Dest.  Addr.  | TrackID in RPI |
   +========+===================+====================+================+
   | Outer  |         A         |  C till C then E   |    (A, 129)    |
   +--------+-------------------+--------------------+----------------+
   | Inner  |         X         | E (X != A), F or G |      N/A       |
   +--------+-------------------+--------------------+----------------+

                     Table 9: Packet Header Settings

   As an example, say that A has a packet for F.  Using the Root of RIB above:

   *  From P-DAO 3: A encapsulates the main DODAG.

   Reserved for Flags:  MUST be set to zero by packet the sender and MUST be
      ignored Track signaled by
      P-DAO 3, with the receiver.

   B:  1-bit flag that is set to indicate that outer header above.  Now the connectivity to destination in the
      sibling
      IPv6 Header is bidirectional C, and roughly symmetrical.  In that case,
      only one of the siblings may report the SIO for a SRH signals the hop.  If 'B' final destination is not set then the SIO only indicates connectivity from the
      sibling E.

   *  From P-DAO 2: A forwards to this node, B and does not provide information on the hop
      from this node B forwards to C.

   *  From P-DAO 3: C processes the sibling.

   D:  1-bit flag that is set to indicate that sibling belongs to SRH and sets the
      same DODAG.  When not set, destination in the Sibling DODAGID is indicated.

   Flags:  Reserved.  The Flags field MUST initialized
      IPv6 Header to zero by the
      sender E.

   *  From P-DAO 1: C forwards to D and MUST be ignored by the receiver

   Opaque:  MAY be used D forwards to carry information that E; E decapsulates
      the node and packet.

   *  From the Root
      understand, e.g., a particular representation of the Link
      properties such as a proprietary Link Quality Information for Neighbor Cache Entry: C delivers packets received from the sibling.  An industrial Alliance that
      uses RPL for a particular use / environment MAY redefine the use
      of this field to fit its needs.

   Step of Rank:  16-bit unsigned integer.  This is the Step of Rank
      [RPL] as computed by the Objective Function between F or G.

3.4.2.  Using Non-Storing Mode joining Tracks

   In this node formulation:

   *  P-DAO 1 signals C==>D==>E-to-F,G

   *  P-DAO 2 signals A==>B==>C-to-C,F,G

   A==>B==>C and
      the sibling.

   Reserved:  The Reserved field MUST initialized to zero by the sender C==>D==>E are Tracks expressed as Non-Storing P-DAOs.

3.4.2.1.  Stitched Tracks

   Non-Storing Mode P-DAO 1 and MUST be ignored by the receiver

   Sibling DODAGID: 2 are sent to 16 bytes, the DODAGID of the sibling in a
      [RFC8138] compressed form as indicated by the Compression Type
      field.  This field is present if C and only if the D flag is not
      set.

   Sibling Address: A respectively, as
   follows:

           +====================+==============+==============+
           |                    | P-DAO 1 to C | P-DAO 2 to 16 bytes, an IPv6 Address of the sibling, with A |
           +====================+==============+==============+
           |        Mode        | Non-Storing  | Non-Storing  |
           +--------------------+--------------+--------------+
           |   Track Ingress    | C            | A            |
           +--------------------+--------------+--------------+
           | (DODAGID, TrackID) | (C, 131)     | (A, 131)     |
           +--------------------+--------------+--------------+
           |     SegmentID      | 1            | 1            |
           +--------------------+--------------+--------------+
           |        VIO         | D, E         | B, C         |
           +--------------------+--------------+--------------+
           |      Targets       | F, G         | E, F, G      |
           +--------------------+--------------+--------------+

                         Table 10: P-DAO Messages

   As a scope that MUST be make it reachable from result the Root, e.g., it
      cannot be a Link Local Address.  The IPv6 address RIBs are set as follows:

         +======+=============+=========+=============+==========+
         | Node | destination | Origin  | Next Hop(s) | TrackID  |
         +======+=============+=========+=============+==========+
         |  E   | F, G        | ND      | Neighbor    | Any      |
         +------+-------------+---------+-------------+----------+
         |  D   | E           | ND      | Neighbor    | Any      |
         +------+-------------+---------+-------------+----------+
         |  C   | D           | ND      | Neighbor    | Any      |
         +------+-------------+---------+-------------+----------+
         |  "   | E, F, G     | P-DAO 1 | D, E        | (C, 131) |
         +------+-------------+---------+-------------+----------+
         |  B   | C           | ND      | Neighbor    | Any      |
         +------+-------------+---------+-------------+----------+
         |  A   | B           | ND      | Neighbor    | Any      |
         +------+-------------+---------+-------------+----------+
         |  "   | C, E, F, G  | P-DAO 2 | B, C        | (A, 131) |
         +------+-------------+---------+-------------+----------+

                           Table 11: RIB setting

   Packets originated at A to E, F and G do not require an
   encapsulation, though it is encoded in
      the [RFC8138] compressed form indicated by the Compression Type
      field.

   An SIO MAY be immediately followed by a DAG Metric Container.  In preferred that case the DAG Metric Container provides additional metrics for
   the hop from the Sibling to this node.

7.  Projected DAO

   This draft adds A encapsulates and C
   decapsulates.  Either way, they carry a capability SRH via B and C, and C needs
   to RPL whereby the Root of a main DODAG
   installs a Track as a collection of Projected Routes, using a
   Projected-DAO (P-DAO) message encapsulate to maintain each individual route. E, F, or G to add an SRH via D and E.  The
   P-DAO signals a collection
   encapsulating headers of Targets in packets that are forwarded along the RPL Target Option(s)
   (RTO).  Those Targets can be reached via a sequence of routers
   indicated in a VIO.  A P-DAO message MUST contain exactly one VIO,
   which is either a SF-VIO or an SR-VIO, Track
   between C and MUST follow one E have the following settings:

    +========+===================+===================+================+
    | Header | IPv6 Source Addr. | IPv6 Dest.  Addr. | TrackID in RPI |
    +========+===================+===================+================+
    | Outer  |         C         |  D till D then E  |    (C, 131)    |
    +--------+-------------------+-------------------+----------------+
    | Inner  |         X         |     E, F, or more
   RTOs.  There can be at most one such sequence of RTO(s) G    |      N/A       |
    +--------+-------------------+-------------------+----------------+

              Table 12: Packet Header Settings between C and E

   As an Via
   Information Option. example, say that A track is identified by a tuple DODAGID,
   TrackID and each route within a Track is indexed by has a SegmentID.

   A packet for F.  Using the RIB above:

   *  From P-DAO MUST be sent from 2: A encapsulates the address packet with destination of F in
      the Root Track signaled by P-DAO 2.  The outer header has source A,
      destination B, an SRH that serves indicates C as
   DODAGID for the main DODAG.  It MUST be sent to next loose hop, and
      a GUA or RPI indicating a ULA of
   either the ingress or the egress TrackId of the Segment, more below.  If the
   'K' Flag 131 from A's namespace, which is present in
      distinct from TrackId of 131 from C's.

   *  From the P-DAO, SRH: Packets forwarded by B have source A, destination C,
      a consumed SRH, and unless the a RPI indicating a TrackId of 131 from A's
      namespace.  C decapsulates.

   *  From P-DAO does not reach
   it, 1: C encapsulates the ingress packet with destination of F in
      the Segment is the node that acknowledges the
   message, using a DAO-ACK that MUST be sent back to the address Track signaled by P-DAO 1.  The outer header has source C,
      destination D, an SRH that
   serves indicates E as DODAGID for the main DODAG.

   Like a classical DAO message, next loose hop, and
      a P-DAO causes RPI indicating a change of state only
   if it is "new" per section 9.2.2.  "Generation of DAO Messages" TrackId of
   the RPL specification [RPL]; this is determined using the Segment
   Sequence information from the VIO as opposed to the Path Sequence 131 from a TIO.  Also, a Segment Lifetime of 0 in a VIO indicates that
   the projected route associated to the Segment is to be removed.

   There are two kinds of operation for the Projected Routes, the
   Storing Mode C's namespace.  E
      decapsulates.

3.4.2.2.  External routes

   In this formulation:

   *  P-DAO 1 signals C==>D==>E-to-E

   *  P-DAO 2 signals A==>B==>C-to-C,E

   *  P-DAO 3 signals F and G via the Non-Storing Mode.

   *  The A-->E-to-F,G Track

   Non-Storing Mode P-DAO 1 is discussed in Section 7.3.2.  A sent to C and Non-Storing Mode P-DAO carries an SR-VIO with the loose list of Via Addresses
      that forms a source-routed Segment to the Track Egress.  The
      recipient of the 2
   and 3 are sent A, as follows:

    +====================+==============+==============+==============+
    |                    | P-DAO is the Track Ingress; it MUST install a
      source-routed state 1 to the Track Egress and reply C | P-DAO 2 to the Root
      directly using a DAO-ACK message if requested to.

   *  The Storing Mode is discussed in Section 7.3.1. A Storing Mode | P-DAO carries a SF-VIO with the strict list of Via Addresses from
      the ingress 3 to the egress of the Segment in the data path order.
      The routers listed in the Via Addresses, except the egress, MUST
      install A |
    +====================+==============+==============+==============+
    |        Mode        | Non-Storing  | Non-Storing  | Non-Storing  |
    +--------------------+--------------+--------------+--------------+
    |   Track Ingress    | C            | A            | A            |
    +--------------------+--------------+--------------+--------------+
    | (DODAGID, TrackID) | (C, 131)     | (A, 129)     | (A, 141)     |
    +--------------------+--------------+--------------+--------------+
    |     SegmentID      | 1            | 1            | 1            |
    +--------------------+--------------+--------------+--------------+
    |        VIO         | D, E         | B, C         | E            |
    +--------------------+--------------+--------------+--------------+
    |      Targets       | E            | E            | F, G         |
    +--------------------+--------------+--------------+--------------+

                          Table 13: P-DAO Messages

   As a routing state to the Target(s) via the next Via Address
      in the SF-VIO.  In normal operations, result the RIBs are set as follows:

         +======+=============+=========+=============+==========+
         | Node | destination | Origin  | Next Hop(s) | TrackID  |
         +======+=============+=========+=============+==========+
         |  E   | F, G        | ND      | Neighbor    | Any      |
         +------+-------------+---------+-------------+----------+
         |  D   | E           | ND      | Neighbor    | Any      |
         +------+-------------+---------+-------------+----------+
         |  C   | D           | ND      | Neighbor    | Any      |
         +------+-------------+---------+-------------+----------+
         |  "   | E           | P-DAO is propagated
      along the chain of Via Routers from the egress router 1 | D, E        | (C, 131) |
         +------+-------------+---------+-------------+----------+
         |  B   | C           | ND      | Neighbor    | Any      |
         +------+-------------+---------+-------------+----------+
         |  A   | B           | ND      | Neighbor    | Any      |
         +------+-------------+---------+-------------+----------+
         |  "   | C, E        | P-DAO 2 | B, C        | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  "   | F, G        | P-DAO 3 | E           | (A, 141) |
         +------+-------------+---------+-------------+----------+

                           Table 14: RIB setting

   The encapsulating headers of packets that are forwarded along the path
      till
   Track between C and E have the ingress one, which confirms the installation to the Root
      with a DAO-ACK message.

   In case of a forwarding error along a Projected Route, an ICMP error
   is sent to the Root with a new Code "Error following settings:

    +========+===================+===================+================+
    | Header | IPv6 Source Addr. | IPv6 Dest.  Addr. | TrackID in Projected Route" (See
   Section 11.13).  The Root can RPI |
    +========+===================+===================+================+
    | Outer  |         C         |  D till D then modify E  |    (C, 131)    |
    +--------+-------------------+-------------------+----------------+
    | Middle |         A         |         E         |    (A, 141)    |
    +--------+-------------------+-------------------+----------------+
    | Inner  |         X         |     E, F or remove the Projected
   Route.  The "Error in Projected Route" message G     |      N/A       |
    +--------+-------------------+-------------------+----------------+

                      Table 15: Packet Header Settings

   As an example, say that A has a packet for F.  Using the same format as
   the "Destination Unreachable Message", as specified in RFC 4443
   [RFC4443].

   The portion of RIB above:

   *  From P-DAO 3: A encapsulates the invoking packet that is sent back with destination of F in
      the ICMP
   message SHOULD record at least up to the RH if one is present, Track signaled by P-DAO 3.  The outer header has source A,
      destination E, and
   this hop a RPI indicating a TrackId of 141 from A's
      namespace.  This recurses with:

   *  From P-DAO 2: A encapsulates the RH SHOULD be consumed by this node so that the packet with destination of E in
      the IPv6 Track signaled by P-DAO 2.  The outer header is has source A,
      destination B, an SRH that indicates C as the next hop that this node could
   not reach.  if loose hop, and
      a 6LoWPAN Routing Header (6LoRH) [RFC8138] is used to
   carry the IPv6 routing information in the outer header then that
   whole 6LoRH information SHOULD be present in RPI indicating a TrackId of 129 from A's namespace.

   *  From the ICMP message.

   The sender SRH: Packets forwarded by B have source A, destination C
      , a consumed SRH, and exact operation depend on a RPI indicating a TrackId of 129 from A's
      namespace.  C decapsulates.

   *  From P-DAO 1: C encapsulates the Mode and is described packet with destination of E in
   Section 7.3.2 and Section 7.3.1 respectively.

7.1.  Requesting a Track

   A Node is free to ask
      the Root for a new Track for which it will be
   Ingress at any time.  This is done with a PDR message, signaled by P-DAO 1.  The outer header has source C,
      destination D, an SRH that indicates E as the desired TrackID next loose hop, and the duration for which the Track should be
   established.  Upon a PDR, the Root MAY install the necessary
   Segments, in which case it answers with
      a PDR-ACK RPI indicating the
   granted Track Lifetime.  All the Segments MUST be of a same mode,
   either Storing or Non-Storing.  All the Segments MUST be created with
   the same TrackID TrackId of 131 from C's namespace.  E
      decapsulates.

3.4.2.3.  Segment Routing

   In this formulation:

   *  P-DAO 1 signals C==>D==>E-to-E

   *  P-DAO 2 signals A==>B-to-C

   *  P-DAO 3 signals F and G via the same DODAGID signaled in the P-DAO.

   The Root A-->C-->E-to-F,G Track

   Non-Storing Mode P-DAO 1 is free sent to design the Track as it wishes, C and to change the
   Segments overtime to serve the Track Non-Storing Mode P-DAO 2
   and 3 are sent A, as needed, without notifying the
   resquesting Node.  The Segment Lifetime in the follows:

    +====================+==============+==============+==============+
    |                    | P-DAO messages does
   not need to be aligned 1 to the Requested Lifetime in the PDR, or
   between C | P-DAO messages for different Segments.  The Root may use
   shorter lifetimes for the Segments and renew them faster than the
   Track is, or longer lifetimes in which case it will need to tear down
   the Segments if the Track is not renewed.

   When the Track Lifetime that was returned in the PDR-ACK is close to
   elapse, the resquesting Node needs 2 to resend a PDR using the TrackID
   in the PDR-ACK A | P-DAO 3 to extend the lifetime of the Track, else the Track
   will time out and the Root will tear down the whole structure.

   If the Track fails and cannot be restored, the Root notifies the
   resquesting Node asynchronously with a PDR-ACK with a Track Lifetime
   of 0, indicating that the Track has failed, and a PDR-ACK Status
   indicating the reason of the fault.

7.2.  Identifying a A |
    +====================+==============+==============+==============+
    |        Mode        | Non-Storing  | Non-Storing  | Non-Storing  |
    +--------------------+--------------+--------------+--------------+
    |   Track

   RPL defines the concept of an Instance to signal an individual
   routing topology but does not have Ingress    | C            | A            | A            |
    +--------------------+--------------+--------------+--------------+
    | (DODAGID, TrackID) | (C, 131)     | (A, 129)     | (A, 141)     |
    +--------------------+--------------+--------------+--------------+
    |     SegmentID      | 1            | 1            | 1            |
    +--------------------+--------------+--------------+--------------+
    |        VIO         | D, E         | B            | C, E         |
    +--------------------+--------------+--------------+--------------+
    |      Targets       |              | C            | F, G         |
    +--------------------+--------------+--------------+--------------+

                          Table 16: P-DAO Messages

   As a concept of an administrative
   distance, which exists in certain proprietary implementations to sort
   out conflicts between multiple sources of routing information within
   one routing topology.

   This draft leverages result the RPL Instance model RIBs are set as follows:

   *  The Root MAY use

         +======+=============+=========+=============+==========+
         | Node | destination | Origin  | Next Hop(s) | TrackID  |
         +======+=============+=========+=============+==========+
         |  E   | F, G        | ND      | Neighbor    | Any      |
         +------+-------------+---------+-------------+----------+
         |  D   | E           | ND      | Neighbor    | Any      |
         +------+-------------+---------+-------------+----------+
         |  C   | D           | ND      | Neighbor    | Any      |
         +------+-------------+---------+-------------+----------+
         |  "   | E           | P-DAO messages to add better routes in the main
      (Global) Instance in conformance with the routing objectives in 1 | D, E        | (C, 131) |
         +------+-------------+---------+-------------+----------+
         |  B   | C           | ND      | Neighbor    | Any      |
         +------+-------------+---------+-------------+----------+
         |  A   | B           | ND      | Neighbor    | Any      |
         +------+-------------+---------+-------------+----------+
         |  "   | C           | P-DAO 2 | B, C        | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  "   | E, F, G     | P-DAO 3 | C, E        | (A, 141) |
         +------+-------------+---------+-------------+----------+

                           Table 17: RIB setting

   The encapsulating headers of packets that Instance.  To achieve this, the Root MAY install an Storing-
      Mode P-Route are forwarded along a path down the main Non-Storing Mode DODAG.
      This enables a loose source routing
   Track between A and reduces B have the size following settings:

    +========+===================+===================+================+
    | Header | IPv6 Source Addr. | IPv6 Dest.  Addr. | TrackID in RPI |
    +========+===================+===================+================+
    | Outer  |         A         |  B till D then E  |    (A, 129)    |
    +--------+-------------------+-------------------+----------------+
    | Middle |         A         |         C         |    (A, 141)    |
    +--------+-------------------+-------------------+----------------+
    | Inner  |         X         |     E, F or G     |      N/A       |
    +--------+-------------------+-------------------+----------------+

                      Table 18: Packet Header Settings

   The encapsulating headers of packets that are forwarded along the
      Routing Header, see Appendix A.1.

      When adding an Storing-Mode P-Route to the main RPL Instance, the
      Root MUST set the RPLInstanceID field of the P-DAO message (see
      section 6.4.1. of [RPL]) to
   Track between B and C have the RPLInstanceID following settings:

    +========+===================+===================+================+
    | Header | IPv6 Source Addr. | IPv6 Dest.  Addr. | TrackID in RPI |
    +========+===================+===================+================+
    | Outer  |         A         |         C         |    (A, 141)    |
    +--------+-------------------+-------------------+----------------+
    | Inner  |         X         |     E, F or G     |      N/A       |
    +--------+-------------------+-------------------+----------------+

                      Table 19: Packet Header Settings

   The encapsulating headers of packets that are forwarded along the main DODAG,
   Track between C and MUST NOT use E have the DODAGID field. following settings:

    +========+===================+===================+================+
    | Header | IPv6 Source Addr. | IPv6 Dest.  Addr. | TrackID in RPI |
    +========+===================+===================+================+
    | Outer  |         C         |  D till D then E  |    (C, 131)    |
    +--------+-------------------+-------------------+----------------+
    | Middle |         A Projected Route provides         |         E         |    (A, 141)    |
    +--------+-------------------+-------------------+----------------+
    | Inner  |         X         |     E, F or G     |      N/A       |
    +--------+-------------------+-------------------+----------------+

                      Table 20: Packet Header Settings

   As an example, say that A has a
      longer match to the Target Address than the default route via the
      Root, so it is preferred.

      Once the Projected Route is installed, the intermediate nodes
      listed in packet for F.  Using the SF-VIO after first one (i.e.  The ingress) can be
      elided from RIB above:

   *  From P-DAO 3: A encapsulates the RH packet with destination of F in packets sent along
      the Segment Track signaled in
      the P-DAO. by P-DAO 3.  The resulting loose source routing outer header has source A,
      destination C, an SRH that indicates
      (one of) the Target(s) E as the next entry after the ingress. loose hop, and
      a RPI indicating a TrackId of 141 from A's namespace.  This
      recurses with:

   *  The Root MAY also use  From P-DAO messages to install a specific (say,
      Traffic Engineered) path as 2: A encapsulates the packet with destination of C in
      the Track signaled by P-DAO 2.  The outer header has source A,
      destination B, and a Serial or as RPI indicating a Complex Track, TrackId of 129 from A's
      namespace.  B decapsulates forwards to C based on a
      particular endpoint that is sibling
      connected route.

   *  From the Track Egress.  In that case, SRH: C consumes the
      Root MUST install a Local RPL Instance (see section 5 of [RPL]), SRH and makes the Local RPLInstanceID is called TrackID.

      In that case, the TrackID MUST be unique for destination E.

   *  From P-DAO 1: C encapsulates the Global Unique
      IPv6 Address (GUA) or Unique-Local Address (ULA) packet with destination of E in
      the Track
      Ingress signaled by P-DAO 1.  The outer header has source C,
      destination D, an SRH that serves indicates E as DODAGID for the Track.  The Track Ingress
      owns the namespace of its TrackIDs, so it can pick any unused
      value to request next loose hop, and
      a new Track with RPI indicating a PDR.  The Root is aware TrackId of all
      the active Tracks, so it can also pick any unused value to form 131 from C's namespace.  E
      decapsulates.

3.5.  Complex Tracks without a PDR.

   To avoid a collision of increase the Root and reliability of the
      Track Ingress picking P2P transmission, this
   specification enables to build a collection of Legs between the same value at
   Ingress and Egress Nodes and combine them with the same time, it is
      RECOMMENDED TrackID, as
   shown in Figure 2.  Legs may cross at loose hops edges or remain
   parallel.

   The Segments that join the Track Ingress starts allocating the ID value
      of the Local RPLInstanceID (see section 5.1. loose hops of [RPL]) used as
      TrackIDs with the value 0 incrementing, while the Root starts with
      63 decrementing.

      This way, a Track is uniquely identified by the tuple (DODAGID,
      TrackID) where the TrackID is always represented Leg are installed with the D flag
      set to 0.

      The Track Egress Address and the
   same TrackID MUST be signaled in the
      P-DAO message as shown in Figure 1.

7.3.  Installing a Track

   A Storing-Mode P-DAO contains an SF-VIO that signals the strict
   sequence of consecutive nodes to form a segment between a segment
   ingress Leg. But each individual Leg and a segment egress (both included).  It installs a route of
   a higher precedence along the segment towards Segment has its
   own P-RouteID which allows to manage it separately.  When Legs cross
   within respsective Segment, the Targets indicated
   in next loose hop (the current
   destination of the Target Options.  The segment packet) indicates which Leg is included in being followed and
   a DODAG indicated
   by the P-DAO Base Object, Segment that may be the one formed by the main can reach that next loose hop is selected.

           CPF               CPF          CPF                 CPF

                          Southbound API

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

                         +----------+
                         | RPL
   Instance, or a Root |
                         +----------+
                           (      )
                 (                                  )
           (              DODAG                              )
             (                                           )
     (                                                         )
                                                                     )
     <-    Leg 1            B,                            E ->
     <--- Segment 1 A,B ---> <------- Segment 2 C,D,E ------->

                FWD  --z  Relay --z   FWD  --z   FWD          Target 1
            z-- Node  z--  Node  z--  Node  z--  Node --z     /
         --z    (A)        (B) \      (C)        (D)  z--    /
   Track associated with a local RPL Instance.  A                        \                       Track
   Ingress                    Segment 5                 Egress is signaled as a - Tgt 2
     (I)                           \                     (E)
         --z                        \                 z--    \
          z-- FWD   --z  FWD  --z  Relay --z  FWD  --z        \
              Node   z-- Node  z-- Node   z-- Node            Target in the P-DAO, 3
              (F)        (G)       (H)        (J)

     <------ Segment 3 F,G,H ------> <---- Segment 4 J,E ---->
     <-      Leg 2                  H,                    E ->

     <--- Segment 1 A,B ---> <- S5-> <---- Segment 4 J,E ---->
     <-      Leg 3          B,      H,                    E ->
                                                                     )
      (
                 (                                        )

                       Figure 2: Segments and as the last entry is
   an SF-VIO of a last segment towards Tracks

   Note that Egress.

   A Non-Storing-Mode P-DAO signals a strict or loose sequence of nodes
   between the Track Ingress (excluded) and a Track Egress (included).
   It installs a source-routed path of while this specification enables to build both Segments
   inside a higher precedence Leg (aka East-West), such as Segment 2 above which is within the
   Track indicated by the P-DAO Base Object, towards the Targets
   indicated in the Target Options.  The source-routed path requires a
   Source-Routing header
   Leg 1, and Inter-Leg Segments (aka North-South), such as Segment 2
   above which implies an encapsulation joins Leg 1 and Leg 2, it does not signal to add the SRH
   to an existing packet. Ingress
   which Inter-Leg Segments are available, so the use of North-South
   Segments and associated PAREO functions is curently limited.  The next entry
   only possibility available at this time is to define overlapping Legs
   as illustrated in Figure 2, with Leg 3 that is congruent with Leg 1
   till node B and congruent with Leg 2 from node H on, abstracting
   Segment 5 as an East-West Segment.

   DetNet Forwarding Nodes only understand the sequence must be either simple 1-to-1 forwarding
   sublayer transport operation along a neighbor of segment whereas the
   previous entry, or reachable more
   sophisticated Relay nodes can also provide service sublayer functions
   such as a Target via another Projected Route,
   either Storing or Non-Storing.  If it Replication and Elimination.  One possible mapping between
   DetNet and this specification is reachable over a Storing
   Mode Projected Route, the next entry in to signal the loose sequence is Relay Nodes as the
   Target
   hops of a previous segment Leg and the ingress of a next segment; forwarding Nodes as the
   segments are associated with hops in a Segment that
   join the same Track, which avoids Relay nodes as illustrated in Figure 2.

3.6.  Scope and Expectations

   This specification expects that the need of
   an encapsulation.  Conversely, if it RPL Main DODAG is reachable over a operated in RPL
   Non-Storing Mode Projected Route, to sustain the next loose source routed hop of exchanges with the inner
   Track is a Target Root.  Based on
   its comprehensive knowledge of a previous Track and the ingress parent-child relationship, the
   Root can form an abstracted view of a next
   Track, which requires a de- and a re-encapsulation.

   A Serial Track is installed by a single Projected Routes that signals the sequence whole DODAG topology.  This
   document adds the capability for nodes to advertise additional
   sibling information to complement the topological awareness of consecutive nodes, either in Storing or Non-Storing
   Mode.  If can be a loose Non-Storing Mode Projected Route, in which
   case the next loose entry must recursively be reached over a Serial
   Track.

   A Complex Track can
   Root to be installed passed on to the PCE, and enable the PCE to build more /
   better paths that traverse those siblings.

   P-Routes require resources such as a collection of Projected Routes
   with routing table space in the same DODAGID routers
   and Track ID.  The Ingress bandwidth on the links; the amount of a Non-Storing
   Mode Projected Route state that is installed in
   each node must be computed to fit within the owner of node's memory, and the DODAGID.  The Ingress
   amount of a Storing Mode Projected Route rerouted traffic must be either fit within the owner capabilities of the
   DODAGID, or the egress of a preceding Storing Mode Projected Route in
   transmission links.  The methods used to learn the same Track.  In node capabilities
   and the latter case, resources that are available in the Targets of devices and in the Projected
   Route must be Targets
   network are out of the preceding Projected Route scope for this document.  The method to ensure that
   they capture
   and report the LLN link capacity and reliability statistics are visible also
   out of scope.  They may be fetched from the track Ingress.

7.3.1.  Storing-Mode P-Route

   Profile 1 extends RPL operation in a Non-Storing Mode nodes through network with
   Storing-Mode Projected Routes
   management functions or other forms of telemetry such as OAM.

   The "6TiSCH Architecture" [6TiSCH-ARCHI] leverages a centralized
   model that install segments along is similar to that of "Deterministic Networking
   Architecture" [RFC8655], whereby the main
   DODAG device resources and enable
   capabilities are exposed to loose source an external controller which installs
   routing between states into the Root network based on its own objective functions
   that reside in that external entity.  With DetNet and 6TiSCH, the
   targets.

7.3.1.1.  Installing
   component of the controller that is responsible of computing routes
   is a Storing-Mode P-Route

   As illustrated PCE.  The PCE computes its routes based on its own objective
   functions such as described in Figure 9, a P-DAO that carries [RFC4655], and typically controls the
   routes using the PCE Protocol (PCEP) by [RFC5551].  While this
   specification expects a SF-VIO enables PCE and while PCEP might effectively be used
   between the Root to install and the PCE, the control protocol between the PCE
   and the Root is out of scope.

   This specification expects a stateful route towards single PCE with a collection full view of Targets
   along the
   network.  Distributing the PCE function for a Segment between large network is out of
   scope.  This specification uses the RPL Root as a Track Ingress proxy to the PCE.
   The PCE may be collocated with the Root, or may reside in an external
   Controller.  In that case, the protocol between the Root and a Track Egress using a
   projected DAO Message.

           ------+---------
                 |          Internet
                 |
              +-----+
              |     | Border Router
              |     |  (RPL Root)
              +-----+                      |     ^                   |
                 |                         | DAO | ACK               |
           o    o   o    o                 |     |                   |
       o o   o  o   o  o  o o   o          |  ^       | Projected    .
      o  o 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       v | DAO    v              .
     o          o   LLN   o   o     o                                |
         o o   o        o     o              Loose Source Route Path |
      o       o      o    o                 From Root To Destination v

                        Figure 9: Projecting a route

   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 routing Segment that PCE
   is being installed.  The P-DAO message
   contains a SF-VIO with the direct sequence out of Via Addresses.  The SF-
   VIO follows one or more RTOs indicating the Targets scope and abstracted by / mapped to which RPL inside the
   Track leads.  The SF-VIO contains a Segment Lifetime DODAG;
   one possibility is for which the
   state is to be maintained.

   The Root sends the P-DAO directly to transmit the egress node of RPL DAOs with the Segment.
   In
   SIOs that P-DAO, detail the destination IP address matches parent/child and sibling information.

   The algorithm to compute the last Via
   Address in paths and the SF-VIO.  This is how protocol used by the egress recognizes its role.
   In a similar fashion, PCE
   and the ingress node recognizes its role as it
   matches first Via Address metrics and link statistics involved in the SF-VIO. computation are
   also out of scope.  The Egress node effectiveness of the Segment is the only node in the path that does
   not install a route in response to the P-DAO; it is expected to be
   already able to route to computation by the Target(s)
   PCE depends on its own.  If one the quality of the
   Targets is not known, metrics that are reported from the node MUST answer to the Root with a
   negative DAO-ACK listing
   RPL network.  Which metrics are used and how they are reported is out
   of scope, but the Target(s) expectation is that could not be located
   (suggested status 10 to be confirmed by IANA).

   If the egress node can reach all the Targets, then it forwards the
   P-DAO with unchanged content to its loose predecessor in they are mostly of long-term,
   statistical nature, and provide visibility on link throughput,
   latency, stability and availability over relatively long periods.

   The "Reliable and Available Wireless (RAW) Architecture/Framework"
   [RAW-ARCHI] extends the Segment definition of Track, as indicated in the list being composed of Via Information options,
   East-West directional segments and recursively North-South bidirectional
   segments, to enable additional path diversity, using Packet ARQ,
   Replication, Elimination, and Overhearing (PAREO) functions over the message is propagated unchanged along
   available paths, to provide a dynamic balance between the sequence reliability
   and availability requirements of routers
   indicated in the P-DAO, but in flows and the reverse order, from egress need to
   ingress.

   The address of conserve
   energy and spectrum.. This specification prepares for RAW by setting
   up the predecessor to be used as destination Tracks, but only forms DODAGs, which are composed of
   aggregated end-to-end loose source routed Legs, joined by strict
   routed Segments, all oriented East-West.

   The RAW Architecture defines a dataplane extension of the
   propagated DAO message is found in PCE called
   the Via Address Path Selection Engine (PSE), that adapts the precedes use of the
   one that contain path
   redundancy within a Track to defeat the address diverse causes of packet
   loss.  The PSE controls the propagating node, which is used
   as source forwarding operation of the message.

   Upon receiving packets
   within a propagated DAO, all except the Egress Router MUST
   install Track This specification can use but does not impose a route towards PSE
   and does not provide the DAO Target(s) via their successor in the
   SF-VIO.  The router MAY install additional routes towards the VIA
   Addresses policies that wouldselect which packets are
   routed through which path within a Track, IOW, how the SF-VIO after PSE may use
   the next one, if any, but in case
   of a conflict or a lack path redundancy within the Track.  By default, the use of resource, the route(s)
   available redundancy is limited to simple load balancing, and all the Target(s)
   have precedence.

   If a router cannot reach its predecessor in
   segments are East-West unidirectional only.

   A Track may be set up to reduce the SF-VIO, load around the router
   MUST answer Root, or to
   enable urgent traffic to flow more directly.  This specification does
   not provide the Root with policies that would decide which flows are routed
   through which Track.  In a negative DAO-ACK indicating Non-Storing Mode RPL Instance, the
   successor that is unreachable (suggested status 11 to be confirmed by
   IANA).

   The process continues till Main
   DODAG provides a default route via the P-DAO is propagated Root, and the Tracks provide
   more specific routes to ingress router
   of the Segment, which answers with a DAO-ACK Track Targets.

4.  Extending existing RFCs

4.1.  Extending RFC 6550

   This specification extends RPL [RPL] to enable the Root.  The Root
   always expects to install
   East-West routes inside a DAO-ACK, either from the Track Ingress with Main DODAG that is operated as non-Storing
   Mode.  A Projected DAO (P-DAO) message (see Section 4.1.1) contains a
   positive status
   new Via Information Option that installs a strict or from any node along the segment with a negative
   status.  If loose sequence
   of hops to form respectively a Track Segment or a Track Leg.  A new
   P-DAO Request (PDR) message (see Section 5.1) enables a Track Ingress
   to request the DAO-ACK Track from the Root for which it is not received, the Root may retry and it
   owns the DAO
   with address that serves as TrackID, as well as the same TID, or tear down associated
   namespace from which it selects the route.

7.3.1.2.  Maintaining and Tearing Down a Storing-Mode P-Route

   A Segment Lifetime TrackID.  In the context of 0 in this
   specification, the installed route appears as a VIO is used more specific route
   to clean up the state.  The
   P-DAO is forwarded Track Targets, and the Track Ingress routes the packets
   towards the Targets via the Track using the longest match as described above, but usual.

   To ensure that the DAO PDR and P-DAO messages can flow at most times, it
   is interpreted as RECOMMENDED that the nodes involved in a No-Path DAO Track mantain multiple
   parents in the Main DODAG, advertise them all to the Root, and results use
   them in cleaning up existing state as opposed turn to
   refreshing an existing one or installing a new one.

   Note retry similar packets.  It is also RECOMMENDED that
   the continuity of Root uses diverse source route paths to retry similar messages ot
   the segment may be broken; this happens
   if nodes in the bidirectional connectivity between contiguous hops Track.

4.1.1.  Projected DAO

   Section 6 of [RPL] introduces the
   segment is lost.  In that case RPL Control Message Options (CMO),
   including the Root needs to send RPL Target Option (RTO) and Transit Information Option
   (TIO), which can be placed in RPL messages such as the projected destination
   Advertisement Object (DAO).  A DAO message signals routing
   information to one or more intermediate node(s) as opposed to the egress
   node, indicating a portion of segment that is being replaced or
   cleaned up.  At the extreme, the P-DAO updates only one node, Targets indicated in
   which case it contains only RTOs, providing one VIO.

   In case of
   hop information at a forwarding error along an Storing-Mode P-Route, time in the node
   that fails TIO.  A Projected DAO (P-DAO) is a
   special DAO message generated by the Root to forward SHOULD send an ICMP error with install a code "Error P-Route formed
   of multiple hops in
   Projected Route" its DODAG.  This provides a RPL-based method to
   install the Root.  Failure to do so may result Tracks as expected by the 6TiSCH Architecture
   [6TiSCH-ARCHI] as a collection of multiple P-Routes.

   The P-DAO is signaled with a new "Projected DAO" (P) flag, see
   Figure 3.  The 'P' flag is encoded in bit position 2 (to be confirmed
   by IANA) of the Flags field in packet
   loss and wasted resources along the DAO Base Object.  The Root MUST
   set it to 1 in a Projected Route that DAO message.  Otherwise it MUST be set to
   0.  It is broken.

7.3.2.  Non-Storing-Mode P-Route

   As illustrated set to 0 in Figure 10, a Legacy implementations as specified
   respectively in Sections 20.11 and 6.4 of [RPL]

   The P-DAO is control plane signaling and should not be stuck behind
   high traffic levels.  The expectation is that carries an SR-VIO enables the Root to install a source-routed path from a Track Ingress towards
   a Target along P-DAO message is
   sent as high QoS level, above that of data traffic, typically with
   the main DODAG.

              ------+--------- Network Control precedence.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Internet    TrackID    |K|D|P|  Flags  |
                 +-----+   Reserved    | DAOSequence   | Border Router
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |  (RPL Root)
                 +-----+
     +                                                               +
     |  P  ^ ACK                   DODAGID field set to the                    |
     +               IPv6 Address of the Track          | DAO |
              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  o    X  o  o           X Routed
         o   o    °  o     o   o   o X     o          X Segment
        o  o   o  o   o  o    o  o     X Track        X
           o  o  o  o             o     Egress

          o       o               o    o
        o          o             o     o
                                      destination

                          LLN

                 Figure 10: Projecting a Non-Storing Route

   When forwarding a packet              used to a destination for which source encapsulated packets              |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Option(s)...
     +-+-+-+-+-+-+-+-+

                    Figure 3: Projected DAO Base Object

   New fields:

   TrackID:  The local or global RPLInstanceID of the router
   determines DODAG that routing happens via a Track Target, the router
   inserts the Source Routing Header serves
      as Track, more in Section 6.2

   P:  1-bit flag (position to be confirmed by IANA).

      The 'P' flag is set to 1 by the packet with the final
   destination at the Track Egress.

   In order Root to signal the Segment, the router encapsulates the packet
   with an IP-in-IP header and a Routing Header as follows:

   * Projected DAO,
      and it is set to 0 otherwise.

   In RPL Non-Storing Mode, the uncompressed form TIO and RTO are combined in a DAO
   message to inform the source DODAG Root of all the packet is this router,
      the destination is the first Via Address edges in the SR-VIO, and DODAG, which
   are formed by the RH
      is directed parent-child relationships.  Options may
   be factorized; multiple RTOs may be present to signal a Source Routing Header (SRH) [RFC6554] collection of
   children that contains can be reached via the list
      of parent(s) indicated in the remaining Via Addresses terminating by
   TIO(s) that follows the Track Egress.

   *  The preferred alternate in RTOs.  This specification generalizes the
   case of a network where 6LoWPAN Header
      Compression [RFC6282] is parent that can be 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].

      In reach a child with that case, the source routed header is the exact copy of a
   whole Track through which children and siblings of the
      (chain of) SRH-6LoRH found Track Egress
   are reachable.

4.1.2.  Via Information Option

   New CMOs called the Via Information Options (VIO) are introduced for
   use in P-DAO messages as a multihop alternative to the SR-VIO, also terminating by TIO, more in
   Section 5.3.  One VIO is the stateful Storing Mode VIO (SM-VIO); an
   SM-VIO installs a strict hop-by-hop P-Route called a Track Egress. Segment.
   The RPI-6LoRH other is appended next, followed by an IP-
      in-IP 6LoRH Header that indicates the Ingress Router in the
      Encapsulator Address field, see as a similar case Figure 20 of
      [TURN-ON_RFC8138].

   In Non-Storing Mode VIO (NSM-VIO); the case of NSM-VIO installs
   a loose source-routed path, there MUST be either P-Route called a
   segment for the same Track to Leg at the loose next hop, on Track
   Ingress, which case the
   packet is forwarded to the next hop along uses that segment, state to encapsulate a common
   neighbor with the loose next hop, on which case the packet is
   forwarded to that neighbor, or another Track IPv6_in_IPv6
   with a new Routing Header (RH) to the loose next hop
   for which this node Track Egress, more in
   Section 6.6.

   A P-DAO contains one or a neighbor is Ingress.  In more RTOs to indicate the latter case,
   another encapsulation takes place and the process possibly recurses;
   otherwise the packet is dropped.

   In case of a forwarding error along a Source Route path, Target
   (destinations) that can be reached via the node P-Route, followed by
   exactly one VIO that fails to forward SHOULD send an ICMP error with a code "Error in
   Source Routing Header" back to signals the source sequence of the packet, as described nodes to be followed,
   more in section 11.2.2.3. Section 6.  There are two modes of [RPL].  Upon this message, operation for the encapsulating
   node SHOULD stop using
   P-Routes, the source route path for a period of time Storing Mode and
   it SHOULD send an ICMP message with a Code "Error in Projected Route"
   to the Root.  Failure to follow these steps may result in packet loss Non-Storing Mode, see
   Section 6.3.2 and wasted resources along Section 6.3.3 respectively for more.

4.1.3.  Sibling Information Option

   This specification adds another CMO called the source route path Sibling Information
   Option (SIO) that is broken.

7.4.  Forwarding Along used by a Track

   This draft leverages the RPL Forwarding model follows:

   *  In the data packets, the Track DODAGID and the TrackID MUST be
      respectively signaled as the IPv6 Source Address and the
      RPLInstanceID field Aware Node (RAN) to advertise a
   selection of its candidate neighbors as siblings to the RPI that MUST be placed Root, more in the outer
      chain of IPv6 Headers.
   Section 5.4.  The RPI carries a local RPLInstanceID called the TrackID, which,
      in association with the DODAGID, indicates the Track along which
      the packet SIO is forwarded.

      The D flag placed in the RPLInstanceID MUST be set to 0 to indicate DAO messages that are sent
   directly to the source address in Root of the IPv6 header is set ot the DODAGID, more
      in Section 7.4.

   *  This draft conforms the principles of [USEofRPLinfo] with regards main DODAG.

4.1.4.  P-DAO Request

   Two new RPL Control Messages are also introduced, to packet forwarding and encapsulation along enable a Track.

      -  In that case, RPL-
   Aware Node to request the establishment of a Track is the DODAG, between self as
   the Track Ingress is the
         Root, Node and the Track Egress is a RAL, and neighbors of the Track
         Egress that can be reached via Egress.  The node makes its
   request by sending a new P-DAO Request (PDR) Message to the Track are RULs. Root.
   The
         encapsulation rules in [USEofRPLinfo] apply.

      -  If Root confirms with a new PDR-ACK message back to the Track Ingress is requester
   RAN, see Section 5.1 for more.

4.1.5.  Extending the originator RPI

   Sending a Packet within a RPL Local Instance requires the presence of
   the packet and abstract RPL Packet Information (RPI) described in section 11.2.
   of [RPL] in the
         Track Egress is outer IPv6 Header chain (see [RFC9008]).  The RPI
   carries a local RPLInstanceID which, in association with either the
   source or the destination of address in the packet, there is no need
         for an encapsulation.

      -  So IPv6 Header, indicates the Track Ingress must encapsulate
   RPL Instance that the traffic packet follows.

   This specification extends [RPL] to create a new flag that it did
         not originate, and add an signals
   that a packet is forwarded along a P-Route.

   Projected-Route 'P':  1-bit flag.  It is set to 1 in the RPI that is
      added in any fashion.

      A the encapsulation when a packet that is being routed sent over the RPL Instance associated a Track.  It
      is set to 0 when a first Non-Storing Mode Track MAY be placed (encapsulated) in a
      second Track to cover one loose hop of packet is forwarded along the first Track.  On main Track,
      including when the
      other hand, a Storing Mode Track must be strict and a packet that
      it placed in follows a Storing Mode Track MUST follow Segment that Track till the
      Track Egress.

      When a Track Egress extracts a packet from a Track (decapsulates
      the packet), the Destination joins loose hops
      of the inner packet MUST be either
      this node or a direct neighbor, or a Target of another Segment Main DODAG.  The flag is not mutable en-route.

   The encoding of the same Track for which this node 'P' flag in native format is ingress, otherwise shown in Section 4.2
   while the
      packet MUST be dropped.

   All properties of a Track operations are inherited form compressed format is indicated in Section 4.3.

4.2.  Extending RFC 6553

   "The RPL Option for Carrying RPL Information in Data-Plane Datagrams"
   [RFC6553]describes the main RPL
   Instance that Option for use among RPL routers to
   include the abstract RPL Packet Information (RPI) described in
   section 11.2. of [RPL] in data packets.

   The RPL Option is used commonly referred to install as the Track.  For instance, RPI though the use of
   compression per [RFC8138] RPI is determined by whether it
   really the abstract information that is used transported in the
   main instance, e.g., by setting RPL
   Option.  [RFC9008] updated the "T" flag [TURN-ON_RFC8138] in Option Type from 0x63 to 0x23.

   This specification modifies the RPL configuration option.

8.  Profiles

   This document provides a set of tools that may or may not be needed
   by an implementation depending on Option to encode the type of application it serves.
   This sections described profiles that can be implemented separately
   and can 'P' flag as
   follows:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     |  Option Type  |  Opt Data Len |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |O|R|F|P|0|0|0|0| RPLInstanceID |          SenderRank           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         (sub-TLVs)                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 4: Extended RPL Option Format

   Option Type:  0x23 or 0x63, see [RFC9008]

   Opt Data Len:  See [RFC6553]

   'O', 'R' and 'F' flags:  See [RFC6553].  Those flags MUST be used set to discriminate what an implementation can and cannot
   do.

   Profile 0  Profile 0
      by the sender and ignored by the receiver if the 'P' flag is set.

   Projected-Route 'P':  1-bit flag as defined in Section 4.1.5.

   RPLInstanceID:  See [RFC6553].  Indicates the legacy support of [RPL] Non-Storing Mode.
      It provides TrackId if the minimal common functionality that must be
      implemented 'P' flag
      is set, as a prerequisite discussed in Section 4.1.1.

   SenderRank:  See [RFC6553].  This field MUST be set to all the Track-supporting
      profiles.  The other Profiles extend Profile 0 with selected
      capabilities that this specification introduces on top.

   Profile 1 (Storing-Mode P-Route Segments along by the main DODAG)  Profi
      le 1 does not create new paths; it combines Storing
      sender and Non-
      Storing Modes to balance ignored by the size of receiver if the routing header 'P'flag is set.

4.3.  Extending RFC 8138

   The 6LoWPAN Routing Header [RFC8138] specification introduces a new
   IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN)
   [RFC6282] dispatch type for use in 6LoWPAN route-over topologies,
   which initially covers the needs of RPL data packet and compression.

   Section 4 of [RFC8138] presents the amount generic formats of state in the intermediate routers in a
      Non-Storing Mode RPL DODAG.

   Profile 2 (Non-Storing-Mode P-Route Segments along the main DODAG)  P
      rofile 2 extends Profile 0 6LoWPAN
   Routing Header (6LoRH) with Strict Source-Routing Non-Storing-
      Mode Projected Routes along two forms, one Elective that can be
   ignored and skipped when the main DODAG.  Profile 2 provides router does not understand it, and one
   Critical which causes the same capability packet to compress the SRH in packets down be dropped when the main
      DODAG as Profile 1, but it require an encapsulation, router cannot
   process it.  The 'E' Flag in order to
      insert an additional SRH between the loose source routing hops.

   Profile 3  Profile 3 and above build Tracks that do not necessarily
      follow the main DODAG. 6LoRH indicates its form.  In order
   to form skip the best path possible,
      those Profiles require Elective 6LoRHs, their format imposes a fixed expression
   of the support size, whereas the size of Sibling Information Option a Critical 6LoRH may be signaled in
   variable forms to inform enable additional optimizations.

   When the [RFC8138] compression is used, the Root of additional possible hops.  Profile 3 extends
      Profile 1 with additional Storing-Mode Projected Routes that
      install segments the Main DODAG
   that do not follow sets up the main DODAG.  If Track also constructs the
      Segment Ingress (in compressed routing header
   (SRH-6LoRH) on behalf of the SF-VIO) Track Ingress, which saves the
   complexities of optimizing the SRH-6LoRH encoding in constrained
   code.  The SRH-6LoRH is signaled in the same NSM-VIO, in a fashion that it
   is ready to be placed as is in the IPv6 Address of packet encapsulation by the Track Ingress (in
   Ingress.

   Section 6.3 of [RFC8138] presents the projected DAO base Object), formats of the P-DAO
      creates an implicit Track between 6LoWPAN Routing
   Header of type 5 (RPI-6LoRH) that compresses the Segment Ingress and RPI for normal RPL
   operation.  The format of the
      Segment Egress.

   Profile 4  Profile 4 extends Profile 2 with Strict Source-Routing
      Non-Storing-Mode Projected Routes to form Tracks inside the main
      DODAG.  A Track is formed as one or more strict source source
      routed paths between the Root that RPI-6LoRH is not suited for P-Routes
   since the Track Ingress, O,R,F flags are not used and the
      Track Egress that Rank is the last node

   Profile 5  Profile 5 Combines Profile 4 with Profile 1 unknown and enables to
      loose source routing between
   ignored.

   This specification introduces a new 6LoRH, the Ingress P-RPI-6LoRH that can
   be used in either Elective or Critical 6LoRH form, see Table 21 and
   Table 22 respectively.  The new 6LoRH MUST be used as a Critical
   6LoRH, unless an SRH-6LoRH is present and controls the Egress of the
      Track.  As routing
   decision, in Profile 1, Storing-Mode Projected Routes connect the
      dots which case it MAY be used in Elective form.

   The P-RPI-6LoRH is designed to compress the loose source route.

   Profile 6  Profile RPI along RPL P-Routes.
   Its format is as follows:

                0                   1                   2
                0 1 2 3 4 5 6 Combines Profile 7 8 9 0 1 2 3 4 with Profile 5 6 7 8 9 0 1 2 and also
      enables 3
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               |1|0|E| Length  |  6LoRH Type   | RPLInstanceID |
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        Figure 5: P-RPI-6LoRH Format

   Type:  IANA is requested to loose source routing between the Ingress and define the Egress same value of the Track.

9.  Example Track Signaling

   The remainder type for
      both Elective and Critical forms.  A type of the section provides 8 is suggested.

   Elective 'E':  See [RFC8138].  The 'E' flag is set to 1 to indicate
      an example of how a Track Elective 6LoRH, meaning that it can be signaled

                                                  ===> F
                   A ===> B ===> C ===> D===> E <
                                                  ===> G

                         Figure 11: Reference Track

   A is Track ingress, E is track Egress.  C is stitching point.  F and
   G are E's neighbors, "external" to ignored when forwarding.

   RPLInstanceID :  In the Track, and reachable from A
   over context of this specification, the Track A->E.

   In a general manner we want:

   *  P-DAO 1 signals C==>B==>E

   *  P-DAO 2 signals A==>B==>C
   *  P-DAO 3
      RPLInstanceID field signals F and G via the A==>E TrackID, see Section 3.3 and
      Section 6.2 .

   Section 6.7 details how a a Track

   P-DAO 3 being loose, it can only be non-storing.  Note that since Ingress leverages the
   Root is always P-RPI-6LoRH
   Header as part of the ingress encapsulation of a Track, packet to place it into a
   Track.

5.  New RPL Control Messages and all SR-VIOs are now Track,
   the Root being signaled in the DAO base object can now be elided in
   the VIA list in SR-VIO.  This enables the construction Options

5.1.  New P-DAO Request Control Message

   The P-DAO Request (PDR) message is sent by the main
   root of the RFC 8138 optimized SRH-6LoRH a Node in the SR-VIO, Main DODAG
   to be placed
   as is in the packet by the Root.

9.1.  Using Storing-Mode Segments

   A==>B==>C and C==>D==>E are segments of  It is a same Track.  Note that the
   storing mode signaling imposes strict continuity in request to establish or refresh a segment.  One
   benefit of strict routing Track where
   this node is Track Ingress, and signals whether an acknowledgment
   called PDR-ACK is requested or not.  A positive PDR-ACK indicates
   that loops are avoided along the Track.

9.1.1.  Stitched Segments

   Storing-Mode P-DAO 1 and 2 are sent to E Track was built and C, as follows:

              +===============+==============+==============+
              |     Field     | P-DAO 1 that the Roots commits to E | P-DAO 2 maintain the
   Track for the negotiated lifetime.

   The Root may use an asynchronous PDR-ACK with an negative status to C |
              +===============+==============+==============+
              |      Mode     | Storing      | Storing      |
              +---------------+--------------+--------------+
              |
   indicate that the Track Ingress | A            | was terminated before its time.  A            |
              +---------------+--------------+--------------+
              |    TrackID    | (A, 129)     | (A, 129)     |
              +---------------+--------------+--------------+
              |      VIO      | C, D, E      | A, B, C      |
              +---------------+--------------+--------------+
              |    Targets    | E, F, G      | E, F, G      |
              +---------------+--------------+--------------+

                          Table 1: P-DAO Messages

   As status of
   "Transient Failure" (see Section 10.9) is an indication that the PDR
   may be retried after a result reasonable time that depends on the RIBs are set
   deployment.  Other negative status values indicate a permanent error;
   the tentative must be abandoned until a corrective action is taken at
   the application layer or through network management.

   The source IPv6 address of the PDR signals the Track Ingress to-be of
   the requested Track, and the TrackID is indicated in the message
   itself.  One and only one RPL Target Option MUST be present in the
   message.  The RTO signals the Track Egress, more in Section 6.1.

   The RPL Control Code for the PDR is 0x09, to be confirmed by IANA.
   The format of PDR Base Object is as follows:

         +======+=============+=========+=============+==========+
         | Node | Destination | Origin  | Next Hop(s)

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    TrackID    |K|R|   Flags   |
         +======+=============+=========+=============+==========+  ReqLifetime  |  E PDRSequence   | F, G
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Option(s)...
     +-+-+-+-+-+-+-+-+

                     Figure 6: New P-DAO 1 | Neighbor    | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  D   | E           | P-DAO 1 | Neighbor    | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  "   | F, G        | P-DAO 1 | E           | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  C   | D           | P-DAO 1 | Neighbor    | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  "   | E, F, G     | P-DAO 1 | D           | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  B   | C           | P-DAO 2 | Neighbor    | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  "   | E, F, G     | P-DAO 2 | C           | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  A   | B           | P-DAO 2 | Neighbor    | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  A   | E, F, G     | P-DAO 2 | B           | (A, 129) |
         +------+-------------+---------+-------------+----------+

                            Table 2: RIB setting

   E recognizes Request Format

   TrackID:  8-bit field.  In the context of this specification, the
      TrackID field signals the RPLInstanceID of the DODAG formed by the
      Track, see Section 3.3 and Section 6.2.  To allocate a new Track,
      the Ingress Node must provide a value that it is not in use at this
      time.

   K:  The 'K' flag is set to indicate that the Track Egress because it recipient is both expected to
      send a Target
   and PDR-ACK back.

   R:  The 'R' flag is set to request a Segment Endpoint.

   Packets originated by A Complex Track for redundancy.

   Flags:  Reserved.  The Flags field MUST initialized to E, F, or G, do not require an
   encapsulation.  In any fashion, zero by the outer headers of
      sender and MUST be ignored by the packets that
   are forwarded along receiver

   ReqLifetime:  8-bit unsigned integer.  The requested lifetime for the
      Track have the following settings:

    +========+===================+===================+================+
    | Header | IPv6 Source Addr. | IPv6 Dest.  Addr. | TrackID expressed in RPI |
    +========+===================+===================+================+
    | Outer  |         A         |     E, F or G     |    (A, 129)    |
    +--------+-------------------+-------------------+----------------+
    | Inner  |       X != A      |     E, F or G     |      N/A       |
    +--------+-------------------+-------------------+----------------+

                      Table 3: Packet header settings

   As an example, say that Lifetime Units (obtained from the DODAG
      Configuration option).

      A has PDR with a packet for F.  Using fresher PDRSequence refreshes the RIB above:

   *  From P-DAO 2: A forwards to B and B forwards to C.

   *  From P-DAO 1: C forwards to D lifetime, and D forwards to E.

   *  From Neighbor Cache Entry: C delivers a
      PDRLifetime of 0 indicates that the packet Track should be destroyed,
      e.g., when the application that requested the Track terminates.

   PDRSequence:  8-bit wrapping sequence number, obeying the operation
      in section 7.2 of [RPL].  The PDRSequence is used to F.

9.1.2.  External routes

   Storing-Mode P-DAO 1 and 2, correlate a
      PDR-ACK message with the PDR message that triggered it.  It is
      incremented at each PDR message and Non-Storing-Mode P-DAO 3, are echoed in the PDR-ACK by the
      Root.

5.2.  New PDR-ACK Control Message

   The new PDR-ACK is sent as a response to
   E, C and A, respectively, a PDR message with the 'K'
   flag set.  The RPL Control Code for the PDR-ACK is 0x0A, to be
   confirmed by IANA.  Its format is as follows:

      +===============+==============+==============+==============+
      |               | P-DAO

      0                   1 to E | P-DAO                   2 to C | P-DAO                   3 to A |
      +===============+==============+==============+==============+
      |      Mode     | Storing      | Storing      | Non-Storing  |
      +---------------+--------------+--------------+--------------+
      | Track Ingress | A            | A            | A            |
      +---------------+--------------+--------------+--------------+
      |    TrackID    | (A, 129)     | (A, 129)     | (A, 129)     |
      +---------------+--------------+--------------+--------------+
      |      VIO      | C, D, E      | A, B, C      | E            |
      +---------------+--------------+--------------+--------------+
      |    Targets    | E            | E            | F, G         |
      +---------------+--------------+--------------+--------------+

                         Table 4: P-DAO Messages

   As a result the RIBs are set as follows:

         +======+=============+=========+=============+==========+
         | Node | Destination | Origin  | Next Hop(s) | TrackID  |
         +======+=============+=========+=============+==========+
         |  E   | F, G        | P-DAO 1 | Neighbor    | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  D   | E           | P-DAO 1 | Neighbor    | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  C   | D           | P-DAO 1 | Neighbor    | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  "   | E           | P-DAO
      0 1 | D           | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  B   | C           | P-DAO 2 | Neighbor    | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  "   | E           | P-DAO 2 | C           | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  A   | B           | P-DAO 3 4 5 6 7 8 9 0 1 2 | Neighbor    | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  A   | E           | P-DAO 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | B           | (A, 129) |
         +------+-------------+---------+-------------+----------+    TrackID    |  A     Flags     | F, G Track Lifetime|  PDRSequence  | P-DAO 3
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | E PDR-ACK Status|                Reserved                       | (A, 129)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |
         +------+-------------+---------+-------------+----------+

                            Table 5: RIB setting

   Packets from A  Option(s)...
     +-+-+-+-+-+-+-+

                Figure 7: New PDR-ACK Control Message Format

   TrackID:  Set to E do not require an encapsulation.  In any fashion, the outer headers TrackID indicated in the TrackID field of the packets
      PDR messages that are forwarded along the Track
   have this replies to.

   Flags:  Reserved.  The Flags field MUST initialized to zero by the following settings:

   +========+===================+====================+================+
   | Header | IPv6 Source Addr. | IPv6 Dest.  Addr.  | TrackID in RPI |
   +========+===================+====================+================+
   | Outer  |         A         |         E          |    (A, 129)    |
   +--------+-------------------+--------------------+----------------+
   | Inner  |         X         | E (X != A), F or G |      N/A       |
   +--------+-------------------+--------------------+----------------+

                     Table 6: Packet header settings

   As an example, say
      sender and MUST be ignored by the receiver

   Track Lifetime:  Indicates that A has a packet remaining Lifetime for F.  Using the RIB above:

   *  From P-DAO 3: A encapsulates Track,
      expressed in Lifetime Units; the packet value of zero (0x00) indicates
      that the Track signaled by
      P-DAO 3, with the outer header above.  Now the packet destination was destroyed or not created.

   PDRSequence:  8-bit wrapping sequence number.  It is E.

   *  From P-DAO 2: A forwards to B and B forwards to C.

   *  From P-DAO 1: C forwards to D incremented at
      each PDR message and D forwards to E; E decapsulates echoed in the packet.

   *  From Neighbor Cache Entry: C delivers packets to F or G.

9.1.3.  Segment Routing

   Storing-Mode P-DAO 1 and 2, and Non-Storing-Mode P-DAO 3, are sent to
   E, B and A, respectively, PDR-ACK.

   PDR-ACK Status:  8-bit field indicating the completion.  The PDR-ACK
      Status is substructured as follows:

      +===============+==============+==============+==============+
      |               | P-DAO indicated in Figure 8:

                                 0 1 to E | P-DAO 2 to B | P-DAO 3 to A |
      +===============+==============+==============+==============+
      |      Mode     | Storing      | Storing      | Non-Storing  |
      +---------------+--------------+--------------+--------------+
      | Track Ingress | A            | A            | A            |
      +---------------+--------------+--------------+--------------+ 4 5 6 7
                                +-+-+-+-+-+-+-+-+
                                |E|R|  Value    |    TrackID    | (A, 129)     | (A, 129)     | (A, 129)     |
      +---------------+--------------+--------------+--------------+
      |      VIO      | C, D, E      | A, B         | C, E         |
      +---------------+--------------+--------------+--------------+
      |    Targets    | E            | B, C         | F, G         |
      +---------------+--------------+--------------+--------------+

                         Table 7: P-DAO Messages

   As a result the RIBs are set as follows:

         +======+=============+=========+=============+==========+
         | Node | Destination | Origin  | Next Hop(s) | TrackID  |
         +======+=============+=========+=============+==========+
         |  E   | F, G        | P-DAO 1 | Neighbor    | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  D   | E           | P-DAO 1 | Neighbor    | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  C   | D           | P-DAO 1 | Neighbor    | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  "   | E           | P-DAO 1 | D           | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  B   | C           | P-DAO 2 | Neighbor    | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  A   | B           | P-DAO 2 | Neighbor    | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  "   | C           | P-DAO 2 | B           | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  "   | E, F, G     | P-DAO 3 | C, E        | (A, 129) |
         +------+-------------+---------+-------------+----------+

                            Table
                                +-+-+-+-+-+-+-+-+

                       Figure 8: RIB setting

   Packets from A PDR-ACK status Format

      E:  1-bit flag.  Set to E do not require an encapsulation, but carry indicate a SRH
   via C.  In any fashion, rejection.  When not set, the outer headers
         value of 0 indicates Success/Unqualified Acceptance and other
         values indicate "not an outright rejection".
      R:  1-bit flag.  Reserved, MUST be set to 0 by the packets that are
   forwarded along sender and
         ignored by the Track have receiver.
      Status Value:  6-bit unsigned integer.  Values depending on the following settings:

   +========+===================+====================+================+
   | Header | IPv6 Source Addr. | IPv6 Dest.  Addr.  | TrackID in RPI |
   +========+===================+====================+================+
   | Outer  |         A         |  C till C then E   |    (A, 129)    |
   +--------+-------------------+--------------------+----------------+
   | Inner  |         X         | E (X != A), F or G |      N/A       |
   +--------+-------------------+--------------------+----------------+
         setting of the 'E' flag, see Table 9: Packet header settings

   As an example, say that A has a packet for F.  Using 27 and Table 28.

   Reserved:  The Reserved field MUST initialized to zero by the RIB above:

   *  From P-DAO 3: sender
      and MUST be ignored by the receiver

5.3.  Via Information Options

   A encapsulates VIO signals the packet ordered list of IPv6 Via Addresses that constitutes
   the Track signaled by hops of either a Leg (using Non-Storing Mode) a Segment (using
   storing mode) of a Track.  A Storing Mode P-DAO 3, with the outer header above.  Now contains one Storing
   Mode VIO (SM-VIO) whereas a Non-Storing Mode P-DAO contains one Non-
   Storing Mode VIO (NSM-VIO)

   The duration of the destination validity of a VIO is indicated in the
      IPv6 Header a Segment
   Lifetime field.  A P-DAO message that contains a VIO with a Segment
   Lifetime of zero is C, referred as a No-Path P-DAO.

   The VIO contains one or more SRH-6LoRH header(s), each formed of a
   SRH-6LoRH head and a SRH signals collection of compressed Via Addresses, except
   in the final destination is E.

   *  From P-DAO 2: A forwards to B and B forwards to C.

   *  From case of a Non-Storing Mode No-Path P-DAO 3: C processes where the SRH and sets SRH-6LoRH
   header is not present.

   In the destination case of a SM-VIO, or if [RFC8138] is not used in the
      IPv6 Header to E.

   *  From P-DAO 1: C forwards to D data
   packets, then the Root MUST use only one SRH-6LoRH per Via
   Information Option, and D forwards to E; E decapsulates the packet.

   *  From compression is the Neighbor Cache Entry: C delivers packets to F or G.

9.2.  Using Non-Storing-Mode joining Tracks

   A==>B==>C and C==>D==>E are Tracks expressed same forall the
   addresses, as non-storing P-DAOs.

9.2.1.  Stitched Tracks

   Non-Storing Mode P-DAO 1 and 2 are sent to C shown in Figure 9, for simplicity.

   In case of an NSM-VIO and A respectively, if [RFC8138] is in use in the Main DODAG,
   the Root SHOULD optimize the size of the NSM-VIO if using different
   SRH-6LoRH Types make the VIO globally shorter; this means that more
   than one SRH-6LoRH may be present.

   The format of the Via Information Options is as follows:

              +===============+==============+==============+
              |               | P-DAO

        0                   1 to C | P-DAO                   2 to A |
              +===============+==============+==============+
              |      Mode     | Non-Storing  | Non-Storing  |
              +---------------+--------------+--------------+
              | Track Ingress | C            | A                   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        |    TrackID Option Length | (C, 131)     Flags     | (A, 129)   P-RouteID   |
              +---------------+--------------+--------------+
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Segm. Sequence |      VIO Seg. Lifetime | D, E        SRH-6LoRH head         | B, C
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |
              +---------------+--------------+--------------+                                                               |    Targets
       .           Via Address 1 (compressed by RFC 8138)              .
       | F, G                                                               | E, F, G
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |
              +---------------+--------------+--------------+

                          Table 10: P-DAO Messages

   As a result the RIBs are set as follows:

         +======+=============+=========+=============+==========+                                                               | Node
       .                              ....                             .
       | Destination                                                               | Origin
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Next Hop(s)                                                               | TrackID
       .           Via Address n (compressed by RFC 8138)              .
       |
         +======+=============+=========+=============+==========+                                                               |  E
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | F, G                                                               | ND
       .              Additional SRH-6LoRH Header(s)                   .
       | Neighbor                                                               | Any      |
         +------+-------------+---------+-------------+----------+
         |  D   | E           | ND      | Neighbor    | Any      |
         +------+-------------+---------+-------------+----------+
         |  C   | D           | ND      | Neighbor    | Any      |
         +------+-------------+---------+-------------+----------+
         |  "   | E, F, G     | P-DAO 1 | D, E        | (C, 131) |
         +------+-------------+---------+-------------+----------+
         |  B   | C           | ND      | Neighbor    | Any      |
         +------+-------------+---------+-------------+----------+
         |  A   | B           | ND      | Neighbor    | Any      |
         +------+-------------+---------+-------------+----------+
         |  "   | C, E, F, G  | P-DAO 2 | B, C        | (A, 129) |
         +------+-------------+---------+-------------+----------+

                           Table 11: RIB setting

   Packets from A to E, F and G do
       .                              ....                             .

                  Figure 9: VIO format (uncompressed form)

   Option Type:  0x0E for SM-VIO, 0x0F for NSM-VIO (to be confirmed by
      IANA), see =Table 25

   Option Length:  8-bit unsigned integer, representing the length in
      octets of the option, not require an encapsulation, though
   it including the Option Type and Length
      fields, see section 6.7.1. of [RPL]; the Option Length is preferred that A encapsulates
      variable, depending on the number of Via Addresses and C decapsulates.  Either way,
   they carry the
      compression applied.

   P-RouteID:  8-bit field that identifies a SRH via B and C, and C needs to encapsulate to E, F, component of a Track or
   G to add an SRH via D and E. the
      Main DODAG as indicated by the TrackID field.  The encapsulating headers value of packets 0 is
      used to signal a Serial Track, i.e., made of a single segment/Leg.
      In an SM-VIO, the P-RouteID indicates an actual Segment.  In an an
      NSM-VIO, it indicates a Leg, that are forwarded along is a serial subTrack that is
      added to the Track between C and E have overall topology of the following
   settings:

    +========+===================+===================+================+
    | Header | IPv6 Source Addr. | IPv6 Dest.  Addr. | TrackID Track.

   Segment Sequence:  8-bit unsigned integer.  The Segment Sequence
      obeys the operation in RPI |
    +========+===================+===================+================+
    | Outer  |         C         |  D till D then E  |    (C, 131)    |
    +--------+-------------------+-------------------+----------------+
    | Inner  |         X         |     E, F, section 7.2 of [RPL] and the lollipop
      starts at 255.

      When the Root of the DODAG needs to refresh or G    |      N/A       |
    +--------+-------------------+-------------------+----------------+

                      Table 12: Packet header settings

   As an example, say that A has update a packet Segment in
      a Track, it increments the Segment Sequence individually for F.  Using that
      Segment.

      The Segment information indicated in the RIB above:

   *  From P-DAO 2: A encapsulates VIO deprecates any state
      for the packet with destination of F in Segment indicated by the P-RouteID within the indicated
      Track signaled by P-DAO 2.  The outer header has source A,
      destination B, an SRH and sets up the new information.

      A VIO with a Segment Sequence that indicates C is not as fresh as the next loose hop, and
      a RPI indicating current
      one is ignored.

      A VIO for a TrackId of 129 from A's namespace.

   *  From given DODAGID with the SRH: Packets forwarded by B have source A, destination C
      , same (TrackID, P-RouteID,
      Segment Sequence) indicates a consumed SRH, retry; it MUST NOT change the
      Segment and a RPI indicating a TrackId of 129 from A's
      namespace.  C decapsulates.

   *  From P-DAO 1: C encapsulates MUST be propagated or answered as the packet with destination first copy.

   Segment Lifetime:  8-bit unsigned integer.  The length of F time in
      Lifetime Units (obtained from the Track signaled by P-DAO 1.  The outer header has source C,
      destination D, an SRH Configuration option) that indicates E as the next loose hop, and
      Segment is usable.

      The period starts when a RPI indicating new Segment Sequence is seen.  The value
      of 255 (0xFF) represents infinity.  The value of zero (0x00)
      indicates a TrackId loss of 131 from C's namespace.  E
      decapsulates.

9.2.2.  External routes

   Non-Storing Mode P-DAO 1 is sent to C and Non-Storing Mode P-DAO reachability.

   SRH-6LoRH head:  The first 2
   and 3 are sent A, bytes of the (first) SRH-6LoRH as follows:

      +===============+==============+==============+==============+
      |               | P-DAO 1 to C | P-DAO 2 to A | P-DAO 3 to A |
      +===============+==============+==============+==============+
      |      Mode     | Non-Storing  | Non-Storing  | Non-Storing  |
      +---------------+--------------+--------------+--------------+
      | Track Ingress | C            | A            | A            |
      +---------------+--------------+--------------+--------------+
      |    TrackID    | (C, 131)     | (A, 129)     | (A, 141)     |
      +---------------+--------------+--------------+--------------+
      |      VIO      | D, E         | B, C         | E            |
      +---------------+--------------+--------------+--------------+
      |    Targets    | E            | E            | F, G         |
      +---------------+--------------+--------------+--------------+

                         Table 13: P-DAO Messages shown
      in Figure 6 of [RFC8138].  As an example, a result 6LoRH Type of 4 means
      that the RIBs VIA Addresses are set provided in full with no compression.

   Via Address:  An IPv6 ULA or GUA of a node along the Segment.  The
      VIO contains one or more IPv6 Via Addresses listed in the datapath
      order from Ingress to Egress.  The list is expressed in a
      compressed form as follows:

         +======+=============+=========+=============+==========+
         | Node | Destination | Origin  | Next Hop(s) | TrackID  |
         +======+=============+=========+=============+==========+
         |  E   | F, G        | ND      | Neighbor    | Any      |
         +------+-------------+---------+-------------+----------+
         |  D   | E           | ND      | Neighbor    | Any      |
         +------+-------------+---------+-------------+----------+
         |  C   | D           | ND      | Neighbor    | Any      |
         +------+-------------+---------+-------------+----------+
         |  "   | E           | P-DAO 1 | D, E        | (C, 131) |
         +------+-------------+---------+-------------+----------+
         |  B   | C           | ND      | Neighbor    | Any      |
         +------+-------------+---------+-------------+----------+
         |  A   | B           | ND      | Neighbor    | Any      |
         +------+-------------+---------+-------------+----------+
         |  "   | C, E        | P-DAO 2 | B, C        | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  "   | F, G        | signaled by the preceding SRH-6LoRH header.

      In a Storing Mode P-DAO 3 | E           | (A, 141) |
         +------+-------------+---------+-------------+----------+

                           Table 14: RIB setting that updates or removes a section of an
      already existing Segment, the list in the SM-VIO may represent
      only the section of the Segment that is being updated; at the
      extreme, the SM-VIO updates only one node, in which case it
      contains only one IPv6 address.  In all other cases, the list in
      the VIO MUST be complete.

      In the case of an SM-VIO, the list indicates a sequential (strict)
      path through direct neighbors, the complete list starts at Ingress
      and ends at Egress, and the nodes listed in the VIO, including the
      Egress, MAY be considered as implicit Targets.

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

5.4.  Sibling Information Option

   The Sibling Information Option (SIO) provides indication on siblings
   that could be used by the Root to form P-Routes.  One or more SIO(s)
   may be placed in the DAO messages that are sent to the Root in Non-
   Storing Mode.

   To advertise a neighbor node, the router MUST have an active Address
   Registration from that sibling using [RFC8505], for an address (ULA
   or GUA) that serves as identifier for the node.  If this router also
   registers an address to that sibling, and the link has similar
   properties in both directions, only the router with the lowest
   Interface ID in its registered address needs report the SIO, and the
   Root will assume symmetry.

   The format of the SIO is as follows:

        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 |D| Flags |Comp.|    Opaque     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            Step of Rank       |          Reserved             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       .                                                               .
       .       Sibling DODAGID (if the D flag not set)               .
       .                                                               .
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       .                                                               .
       .                     Sibling Address                           .
       .                                                               .
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 10: Sibling Information Option Format

   Option Type:  0x10 for SIO (to be confirmed by IANA), see =Table 25

   Option Length:  8-bit unsigned integer, representing the length in
      octets of the option, not including the Option Type and Length
      fields, see section 6.7.1. of [RPL].

   Reserved for Flags:  MUST be set to zero by the sender and MUST be
      ignored by the receiver.

   D:  1-bit flag that is set to indicate that sibling belongs to the
      same DODAG.  When not set, the Sibling DODAGID is indicated.

   Flags:  Reserved.  The Flags field MUST initialized to zero by the
      sender and MUST be ignored by the receiver

   Opaque:  MAY be used to carry information that the node and the Root
      understand, e.g., a particular representation of the Link
      properties such as a proprietary Link Quality Information for
      packets received from the sibling.  An industrial Alliance that
      uses RPL for a particular use / environment MAY redefine the use
      of this field to fit its needs.

   Compression Type:  3-bit unsigned integer.  This is the SRH-6LoRH
      Type as defined in figure 7 in section 5.1 of [RFC8138] that
      corresponds to the compression used for the Sibling Address and
      its DODAGID if resent.  The Compression reference is the Root of
      the Main DODAG.

   Step of Rank:  16-bit unsigned integer.  This is the Step of Rank
      [RPL] as computed by the Objective Function between this node and
      the sibling.

   Reserved:  The Reserved field MUST initialized to zero by the sender
      and MUST be ignored by the receiver

   Sibling DODAGID:  2 to 16 bytes, the DODAGID of the sibling in a
      [RFC8138] compressed form as indicated by the Compression Type
      field.  This field is present if and only if the D flag is not
      set.

   Sibling Address:  2 to 16 bytes, an IPv6 Address of the sibling, with
      a scope that MUST be make it reachable from the Root, e.g., it
      cannot be a Link Local Address.  The IPv6 address is encoded in
      the [RFC8138] compressed form indicated by the Compression Type
      field.

   An SIO MAY be immediately followed by a DAG Metric Container.  In
   that case the DAG Metric Container provides additional metrics for
   the hop from the Sibling to this node.

6.  Root Initiated Routing State

6.1.  Requesting a Track

   This specification introduces the PDR message, used by an LLN node to
   request the formation of a new Track for which this node is Ingress.
   Note that the namespace for the TrackID is owned by the Ingress node,
   and in the absence of a PDR, there must be some procedure for the
   Root to assign TrackIDs in that namespace while avoiding collisions,
   more in Section 6.2.

   The PDR signals the desired TrackID and the duration for which the
   Track should be established.  Upon a PDR, the Root MAY install the
   Track as requested, in which case it answers with a PDR-ACK
   indicating the granted Track Lifetime.  All the Segments MUST be of a
   same mode, either Storing or Non-Storing.  All the Segments MUST be
   created with the same TrackID and the same DODAGID signaled in the
   P-DAO.

   The Root designs the Track as it sees best, and updates / changes the
   Segments overtime to serve the Track as needed.  There is no
   notification to the requesting node when those changes happen.  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 Segments.  The Root may use shorter lifetimes for the
   Segments and renew them faster than the Track is, or longer lifetimes
   in which case it will need to tear down the Segments if the Track is
   not renewed.

   When the Track Lifetime that was returned in the PDR-ACK is close to
   elapse - vs. the trip time from the node to the Root, the requesting
   node SHOULD resend a PDR using the TrackID in the PDR-ACK to extend
   the lifetime of the Track, else the Track will time out and the Root
   will tear down the whole structure.

   If the Track fails and cannot be restored, the Root notifies the
   requesting node asynchronously with a PDR-ACK with a Track Lifetime
   of 0, indicating that the Track has failed, and a PDR-ACK Status
   indicating the reason of the fault.

6.2.  Identifying a Track

   RPL defines the concept of an Instance to signal an individual
   routing topology, and multiple topologies can coexist in the same
   network.  The RPLInstanceID is tagged in the RPI of every packet to
   signal which topology the packet actually follows.

   This draft leverages the RPL Instance model as follows:

   *  The Root MAY use P-DAO messages to add better routes in the main
      (Global) RPL Instance in conformance with the routing objectives
      in that Instance.

      To achieve this, the Root MAY install a Segment along a path down
      the main Non-Storing Mode DODAG.  This enables a loose source
      routing and reduces the size of the Routing Header, see
      Appendix A.1.  The Root MAY also install a Track Leg across the
      Main DODAG to complement the routing topology.

      When adding a P-Route to the RPL Main DODAG, the Root MUST set the
      RPLInstanceID field of the P-DAO Base Object (see section 6.4.1.
      of [RPL]) to the RPLInstanceID of the Main DODAG, and MUST NOT use
      the DODAGID field.  A P-Route provides a longer match to the
      Target Address than the default route via the Root, so it is
      preferred.

   *  The Root MAY also use P-DAO messages to install a Track as an
      independent routing topology (say, Traffic Engineered) to achieve
      particular routing characteristics from an Ingress to an Egress
      Endpoints.  To achieve this, the Root MUST set up a local RPL
      Instance (see section 5 of [RPL]), and the Local RPLInstanceID
      serves as TrackID.  The TrackID MUST be unique for the IPv6 ULA or
      GUA of the Track Ingress that serves as DODAGID for the Track.

      This way, a Track is uniquely identified by the tuple (DODAGID,
      TrackID) where the TrackID is always represented with the D flag
      set to 0 (see also section 5.1. of [RPL]), indicating when used in
      an RPI that the source address of the IPv6 packet signals the
      DODAGID.

      The P-DAO Base Object MUST indicate the tuple (DODAGID, TrackID)
      that identifies the Track as shown in Figure 3, and the P-RouteID
      that identifies the P-Route MUST be signaled in the VIO as shown
      in Figure 9.

      The Track Ingress is the root of the DODAG ID formed by the local
      RPL Instance.  It owns the namespace of its TrackIDs, so it can
      pick any unused value to request a new Track with a PDR.  In a
      particular deployment where PDR are not used, the namespace can be
      delegated to the main Root, which can assign the TrackIDs for the
      Tracks it creates without collision.

      With this specification, the Root is aware of all the active
      Tracks, so it can also pick any unused value to form Tracks
      without a PDR.  To avoid a collision of the Root and the Track
      Ingress picking the same value at the same time, it is RECOMMENDED
      that the Track Ingress starts allocating the ID value of the Local
      RPLInstanceID (see section 5.1. of [RPL]) used as TrackIDs with
      the value 0 incrementing, while the Root starts with 63
      decrementing.

6.3.  Installing a Track

   A Serial Track can be installed by a single P-Route that signals the
   sequence of consecutive nodes, either in Storing Mode as a single-
   Segment Track, or in Non-Storing Mode as a single-Leg Track.  A
   single-Leg Track can be installed as a loose Non-Storing Mode
   P-Route, in which case the next loose entry must recursively be
   reached over a Serial Track.

   A Complex Track can be installed as a collection of P-Routes with the
   same DODAGID and Track ID.  The Ingress of a Non-Storing Mode P-Route
   is the owner and Root of the DODAGID.  The Ingress of a Storing Mode
   P-Route must be either the owner of the DODAGID, or a hop of a Leg of
   the same Track.  In the latter case, the Targets of the P-Route must
   include the next hop of the Leg if there is one, to ensure forwarding
   continuity.  In the case of a Complex Track, each Segment is
   maintained independently and asynchronously by the Root, with its own
   lifetime that may be shorter, the same, or longer than that of the
   Track.

   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 along the Main DODAG, meaning that:

   *  Longest match MUST be the prime comparison for routing.

   *  In case of equal length match, the route along the Track MUST be
      preferred vs. the one along the Main DODAG.

   *  There SHOULD NOT be 2 different Tracks leading to the same Target
      from same Ingress node, unless there's a policy for selecting
      which packets use which Track; such policy is out of scope.

   *  A packet that was routed along a Track MUST NOT be routed along
      the main DODAG again; if the destination is not reachable as a
      neighbor by the node where the packet exits the Track then the
      packet MUST be dropped.

6.3.1.  Signaling a Projected Route

   This draft adds a capability whereby the Root of a main RPL DODAG
   installs a Track as a collection of P-Routes, using a Projected-DAO
   (P-DAO) message for each individual Track Leg 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.

   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 RPL specification [RPL]; this is determined using the Segment
   Sequence information from the VIO as opposed to the Path Sequence
   from a TIO.  Also, a Segment Lifetime of 0 in a VIO indicates that
   the P-Route associated to the Segment is to be removed.  There are
   two Modes of operation for the P-Routes, the Storing and the Non-
   Storing Modes.

   A P-DAO message MUST be sent from the address of the Root that serves
   as DODAGID for the Main DODAG.  It MUST contain either exactly one
   sequence of one or more RTOs followed one VIO, or any number of
   sequences of one or more RTOs followed by one or more TIOs.  The
   former is the normal expression for this specification, where as the
   latter corresponds to the variation for lesser constrained
   environments described in Section 7.2.

   A P-DAO that creates or updates a Track Leg MUST be sent to a GUA or
   a ULA of the Ingress of the Leg; it must contain the full list of
   hops in the Leg unless the Leg 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
   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.

   In Non-Storing Mode, as discussed in Section 6.3.3, the Root 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 installed path and forwarded in the reverse direction,
   installing a Storing Mode state at each hop, as discussed in
   Section 6.3.2.  In both cases the Track Ingress is the owner of the
   Track, and it generates the P-DAO-ACK when the installation is
   successful.

   If the 'K' Flag is present in the P-DAO, the P-DAO must be
   acknowledged using a DAO-ACK that is sent back to the address of the
   Root from which the P-DAO was received.  In most cases, the first
   node of the Leg, Segment, or updated section of the Segment is the
   node that sends the acknowledgment.  The exception to the rule is
   when an intermediate node in a Segment fails to forward a Storing
   Mode P-DAO to the previous node in the SM-VIO.

   In a No-Path Non-Storing Mode P-DAO, the SRH-6LoRH MUST NOT be
   present in the 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 present more than once, which
   would create a loop.

   A node that processes a VIO MAY verify whether one of these
   conditions happen, and when so, it MUST ignore the P-DAO and reject
   it with a RPL Rejection Status of "Error in VIO" in the DAO-ACK, see
   Section 10.14.

   Other errors than those discussed explicitely that prevent the
   installing the route are acknowledged with a RPL Rejection Status of
   "Unqualified Rejection" in the DAO-ACK.

6.3.2.  Installing a Track Segment with a Storing Mode P-Route

   As illustrated in Figure 11, a Storing Mode P-DAO installs a route
   along the Segment signaled by the SM-VIO towards the Targets
   indicated in the Target Options.  The Segment is to be included in a
   DODAG indicated by the P-DAO Base Object, that may be the one formed
   by the RPL Main DODAG, or a Track associated with a local RPL
   Instance.

           ------+---------
                 |          Internet
                 |
              +-----+
              |     | Border router
              |     |  (RPL Root)
              +-----+                      |     ^                   |
                 |                         | DAO | ACK               |
           o    o   o    o                 |     |                   |
       o o   o  o   o  o  o o   o          |  ^       | Projected    .
      o  o 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       v | DAO    v              .
     o          o   LLN   o   o     o                                |
         o o   o        o     o              Loose Source Route Path |
      o       o      o    o                                          v

                       Figure 11: Projecting a route

   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 routing Segment that is being installed.  The P-DAO message
   contains a SM-VIO with the strict sequence of Via Addresses.  The SM-
   VIO follows one or more RTOs indicating the Targets to which the
   Track leads.  The SM-VIO contains a Segment Lifetime for which the
   state is to be maintained.

   The Root sends the P-DAO directly to the Egress node of the Segment.
   In that P-DAO, the destination IP address matches the last Via
   Address in the SM-VIO.  This is how the Egress recognizes its role.
   In a similar fashion, the Segment Ingress node recognizes its role as
   it matches first Via Address in the SM-VIO.

   The Egress node of the Segment is the only node in the path that does
   not install a route in response to the P-DAO; it is expected to be
   already able to route to the Target(s) based on its existing tables.
   If one of the Targets is not known, the node MUST answer to the Root
   with a DAO-ACK listing the unreachable Target(s) in an RTO and a
   rejection status of "Unreachable Target".

   If the Egress node can reach all the Targets, then it forwards the
   P-DAO with unchanged content to its predecessor in the Segment as
   indicated in the list of Via Information options, and recursively the
   message is propagated unchanged along the sequence of routers
   indicated in the P-DAO, but in the reverse order, from Egress to
   Ingress.

   The address of the predecessor to be used as destination of the
   propagated DAO message is found in the Via Address the precedes the
   one that contain the address of the propagating node, which is used
   as source of the message.

   Upon receiving a propagated DAO, all except the Egress router MUST
   install a route towards the DAO Target(s) via their successor in the
   SM-VIO.  A router that cannot store the routes to all the Targets in
   a P-DAO MUST reject the P-DAO by sending a DAO-ACK to the Root with a
   Rejection Status of "Out of Resources" as opposed to forwarding the
   DAO to its predecessor in the list.  The router MAY install
   additional routes towards the VIA Addresses that are the SM-VIO after
   self, if any, but in case of a conflict or a lack of resource, the
   route(s) to the Target(s) are the ones that must be installed in
   priority.

   If a router cannot reach its predecessor in the SM-VIO, the router
   MUST send the DAO-ACK to the Root with a Rejection Status of
   "Predecessor Unreachable".

   The process continues till the P-DAO is propagated to Ingress router
   of the Segment, which answers with a DAO-ACK to the Root.  The Root
   always expects a DAO-ACK, either from the Track Ingress with a
   positive status or from any node along the segment with a negative
   status.  If the DAO-ACK is not received, the Root may retry the DAO
   with the same TID, or tear down the route.

6.3.3.  Installing a Track Leg with a Non-Storing Mode P-Route

   As illustrated in Figure 12, a Non-Storing Mode P-DAO installs a
   source-routed path within the Track indicated by the P-DAO Base
   Object, towards the Targets indicated in the Target Options.  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 Track Ingress which creates a tunnel associated with the
   Track, and connected routes over the tunnel to the Targets in the
   RTO.  The tunnel encapsulation MUST incorporate a routing header via
   the list addresses listed in the VIO in the same order.  The content
   of the NSM-VIO starting at the first SRH-6LoRH header MUST be used
   verbatim by the Track Ingress when it encapsulates a packet to
   forward it over the Track.

              ------+---------
                    |          Internet
                    |
                 +-----+
                 |     | Border router
                 |     |  (RPL Root)
                 +-----+                    |  P  ^ ACK
                    |        Track          | DAO |
              o    o   o  o  Ingress X      V     |   X
          o o   o  o   o  o     o   X   o             X Source
         o  o o  o o    o   o  o    X  o  o           X Routed
         o   o    °  o     o   o   o X     o          X Segment
        o  o   o  o   o  o    o  o     X Egress       X
           o  o  o  o             o    |
                                     Target
          o       o     LLN          o    o
        o          o             o     o

                 Figure 12: Projecting a Non-Storing Route

   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 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 from the last to the first along the datapath.  For
   instance, a Segment of a Track must be installed before the Leg(s) of
   the same Track that use it, and stitched Segments must be installed
   in order from the last that reaches to the Targets to the first.

   If the next entry in the loose sequence is reachable over a Storing
   Mode P-Route, 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 Section 3.4.1.3, 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.

   Conversely, if it is reachable over a Non-Storing Mode P-Route, the
   next loose source-routed hop of the inner Track is a Target of a
   previously installed Track and the Ingress of a next Track, which
   requires a de- and a re-encapsulation when switching the outer Tracks
   that join the loose hops.  This is examplified in Section 3.4.2.3
   where Non-Storing Mode P-DAO 1 and 2 install strict Tracks that Non-
   Storing Mode P-DAO 3 joins as a super Track.  In such a case, packets
   are subject to double IP-in-IP encapsulation.

6.4.  Tearing Down a P-Route

   A P-DAO with a lifetime of 0 is interpreted as a No-Path DAO and
   results in cleaning up existing state as opposed to refreshing an
   existing one or installing a new one.  To tear down a Track, the Root
   must tear down all the Track Segments and Legs that compose it one by
   one.

   Since the state about a Leg of a Track is located only the Ingress
   Node, the Root cleans up the Leg by sending an NSM-VIO to the Ingress
   indicating the TrackID and the P-RouteID of the Leg being removed, a
   Segment Lifetime of 0 and a newer Segment Sequence.  The SRH-6LoRH
   with the Via Addresses in the NSM-VIO are not needed and MUST be
   omitted.  Upon that NSM-VIO, the Ingress node removes all state for
   that Track if any, and replies positively anyway.

   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 updated, a Segment Lifetime of zero (0) and a newer
   Segment Sequence.  The Via Addresses in the SM-VIO indicates the
   section of the Segment being modified, from the first to the last
   node that is impacted.  This can be the whole Segment if it is
   totally removed, or a sequence of one or more nodes that have been
   bypassed by a Segment update.

   The No-Path P-DAO is forwarded normally along the reverse list, even
   if the intermediate node does not find a Segment state to clean up.
   This results in cleaning up the existing Segment state if any, as
   opposed to refreshing an existing one or installing a new one.

6.5.  Maintaining a Track

   Repathing a Track Segment or Leg may cause jitter and packet
   misordering.  For critical flows that require timely and/or in-order
   delivery, it might be necessary to deploy the PAREO functions
   [RAW-ARCHI] over a highly redundant Track..  This specification
   allows to use more than one Leg for a Track, and 1+N packet
   redundancy.

   This section provides the steps to ensure that no packet is lost due
   to the operation itself.  This is ensured by installing the new
   section from its last node to the first, so when an intermediate node
   installs a route along the new section, all the downstream nodes in
   the section have already installed their own.  The disabled section
   is removed when the packets in-flight are forwarded along the new
   section as well.

6.5.1.  Maintaining a Track Segment

   To modify a section of a Segment between a first node and a second,
   downstream node (which can be the Ingress and Egress), while
   conserving those nodes in the Segment, the Root sends an SM-VIO to
   the second node indicating the sequence of nodes in the new section
   of the Segment.  The SM-VIO indicates the TrackID and the P-RouteID
   of the Segment being updated, and a newer 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 the
   new section of the Segment and creates a state in the new nodes.

   When the state is updated in an intermediate node, that node might
   still receive packets that were in flight from the Ingress to self
   over the old section of the Segment.  Since the remainder of the
   Segment is already updated, the packets are forwarded along the new
   version of the Segment from that node on.

   After a reasonable time to enable the deprecated sections to empty,
   the root tears down the remaining section(s) of the old segments are
   teared down as described in Section 6.4.

6.5.2.  Maintaining a Track Leg

   This specification allows to add Legs to a Track by sending a Non-
   Storing Mode P-DAO to the Ingress associated to the same TrackID, and
   a new Segment ID.  If the Leg is loose, then the Segments that join
   the hops must be created first.  It makes sense to add a new Leg
   before removing one that is misbehaving, and switch to the new Leg
   before removing the old.

   It is also possible to update a Track Leg by sending a Non-Storing
   Mode P-DAO to the Ingress with the same Segment ID, an incremented
   Segment Sequence, and the new complete listy of hops in the NSM-VIO.
   Updating a live Leg means changing one or more of the intermediate
   loose hops, and involves laying out new Segments from and to the new
   loose hops before the NSM-VIO for the new Leg is issued.

   Packets that are in flight over the old version of the Track Leg
   still follow the old source route path over the old Segments.  After
   a reasonable time to enable the deprecated Segments to empty, the
   root tears down those Segments as described in Section 6.4.

6.6.  Encapsulating and Forwarding Along a Track

   When forwarding a packet to a destination for which a router
   determines that routing happens via a Track for which it is Ingress,
   the router must encapsulated the packet using IP-in-IP to add the
   Source Routing Header with the final destination set to the Track
   Egress.  Though fragmentation is possible in a 6LoWPAN LLN, e.g.,
   using [6LoWPAN], [RFC8930], and/or [RFC8931], it is RECOMMENDED to
   allow an MTU that is larger than 1280 in the main DODAG and allows
   for the additional headers while exposing only 1280 to the 6LoWPAN
   Nodes as indicated by section 4 of [6LoWPAN].

   All properties of a Track operations are inherited form the main RPL
   Instance that is used to install the Track.  For instance, the use of
   compression per [RFC8138] is determined by whether it is used in the
   RPL Main DODAG, e.g., by setting the "T" flag [TURN-ON_RFC8138] in
   the RPL configuration option.

   The Track Ingress that places a packet in a Track encapsulates it
   with an IP-in-IP header, a Routing Header, and an IPv6 Hop-by-Hop
   Option Header that contains the RPL Packet Information (RPI) as
   follows:

   *  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 Via Address in the NSM-VIO, and the RH is a Source
      Routing Header (SRH) [RFC6554] that contains the list of the
      remaining Via Addresses terminating by the Track Egress.

   *  The preferred alternate 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].

      In that case, the source routed header is the exact copy of the
      (chain of) SRH-6LoRH found in the NSM-VIO, also terminating by the
      Track Egress.  The RPI-6LoRH is appended next, followed by an IP-
      in-IP 6LoRH Header that indicates the Ingress router in the
      Encapsulator Address field, see as a similar case Figure 20 of
      [TURN-ON_RFC8138].

   To signal the Track in the packet, this specification leverages the
   RPL Forwarding model follows:

   *  In the data packets, the Track DODAGID and the TrackID MUST be
      respectively signaled as the IPv6 Source Address and the
      RPLInstanceID field of the RPI that MUST be placed in the outer
      chain of IPv6 Headers.

      The RPI carries a local RPLInstanceID called the TrackID, which,
      in association with the DODAGID, indicates the Track along which
      the packet is forwarded.

      The D flag in the RPLInstanceID MUST be set to 0 to indicate that
      the source address in the IPv6 header is set ot the DODAGID, more
      in Section 6.2.

   *  This draft conforms to the principles of [RFC9008] with regards to
      packet forwarding and encapsulation along a Track, as follows:

      -  With this draft, the Track is a RPL DODAG.  From the
         perspective of that DODAG, the Track Ingress is the Root, the
         Track Egress is a RPL-Aware 6LR, and neighbors of the Track
         Egress that can be reached via the Track, but are external to
         it, are external destinations and treated as RPL-Unaware Leaves
         (RULs).  The encapsulation rules in [RFC9008] apply.

      -  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.

      -  So the Track Ingress must encapsulate the traffic that it did
         not originate, and add an RPI.

      A packet that is being routed over the RPL Instance associated to
      a first Non-Storing Mode Track MAY be placed (encapsulated) in a
      second Track to cover one loose hop of the first Track as
      discussed in more details Section 3.4.2.3.  On the other hand, a
      Storing Mode Track must be strict and a packet that it placed in a
      Storing Mode Track MUST follow that Track till the Track Egress.

   The forwarding of a packet along a track will fail if the Track
   continuity is broken,e.g.:

   *  In the case of a strict path along a Segment, if the next strict
      hop is not reachable, the packet is dropped.

   *  In the case of a loose source-routed path, when the loose next hop
      is not a neighbor, there must be a Segment of the same Track to
      that loose next hop.  When that is the case the packet is
      forwarded to the next hop along that segment, or a common neighbor
      with the loose next hop, on which case the packet is forwarded to
      that neighbor, or another Track to the loose next hop for which
      this node or a neighbor is Ingress; in the last case, another
      encapsulation takes place and the process possibly recurses;
      otherwise the packet is dropped.

   *  When a Track Egress extracts a packet from a Track (decapsulates
      the packet), the destination of the inner packet must be either
      this node or a direct neighbor, or a Target of another Segment of
      the same Track for which this node is Ingress, otherwise the
      packet MUST be dropped.

   In case of a failure forwarding a packet along a Segment, e.g., the
   next hop is unreachable, the node that discovers the fault MUST send
   an ICMPv6 Error message [RFC4443] to the Root, with a new Code "Error
   in P-Route" (See Section 10.13).  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 ot one or more nodes
   being removed (See Section 6.5).

   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 in Source Routing Header" back to the source of the packet, as
   described in section 11.2.2.3. of [RPL].  Upon this message, the
   encapsulating node SHOULD stop using the source route path for a
   reasonable period of time which duration depends on the deployment,
   and it SHOULD send an ICMP message with a Code "Error in P-Route" to
   the Root.  Failure to follow these steps may result in packet loss
   and wasted resources along the source route path that is broken.

   Either way, the ICMP message MUST be throttled in case of consecutive
   occurrences.  It MUST be sourced at the ULA or a GUA that is used in
   this Track for the source node, so the Root can establish where the
   error happened.

   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 RH SHOULD be consumed by this node so that the
   destination in the IPv6 header is the next hop that this node could
   not reach.  if a 6LoWPAN Routing Header (6LoRH) [RFC8138] is used to
   carry the IPv6 routing information in the outer header then that
   whole 6LoRH information SHOULD be present in the ICMP message.

6.7.  Compression of the RPL Artifacts

   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 13, representing the case where :

   +-+ ... -+- ... -+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-...
   |11110001|  SRH- | RPI-  | IP-in-IP | NH=1      |11110CPP| UDP | UDP
   | Page 1 | 6LoRH | 6LoRH |  6LoRH   |LOWPAN_IPHC| UDP    | hdr |Payld
   +-+ ... -+- ... -+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-...
                                        <=        RFC 6282      =>
             <================ Inner packet ==================== = =

           Figure 13: A Packet as Forwarded along the Main DODAG

   Since there is no page switch between the encapsulated packet and the
   encapsulation, the first octet of the compressed packet that acts as
   page selector is actually removed at encapsulation, so the inner
   packet used in the descriptions below start with the SRH-6LoRH, and
   is verbatim the packet represented in Figure 13 from the second octet
   on.

   When encapsulating that inner packet to place it in the Track, the
   first header that the Ingress appends at the head of the inner packet
   is an IP-in-IP 6LoRH Header; in that header, the encapsulator
   address, which maps to the IPv6 source address in the uncompressed
   form, contains a GUA or ULA IPv6 address of the Ingress node that
   serves as DODAG ID for the Track, expressed in the compressed form
   and using the DODAGID of the Main DODAG as compression reference.  If
   the address is compressed to 2 bytes, the resulting value for the
   Length field shown in Figure 14 is 3, meaning that the SRH-6LoRH as a
   whole is 5-octets long.

      0                   1                   2
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-     ...     -+
     |1|0|1| Length  | 6LoRH Type 6  |  Hop Limit    | Track DODAGID |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-     ...     -+

                    Figure 14: The IP-in-IP 6LoRH Header

   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 5, using the TrackID as
   RPLInstanceID.  Combined with the IP-in-IP 6LoRH Header, this allows
   to identify the Track without ambiguity.

   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 Track Leg.

        0                   1
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5  ..         ..        ..
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-    -+-    -+ ... +-    -+
       |1|0|0|  Size   |6LoRH Type 0..4| Hop1 | Hop2 |     | HopN |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-    -+-    -+ ... +-    -+
                                                 Where N = Size + 1

                      Figure 15: The SRH 6LoRH Header

   The format of the resulting encapsulated packet in [RFC8138]
   compressed form is illustrated in Figure 16:

   +-+ ... -+-+-+- ... -+-+-+- ... -+-+-+-+-+- ... +-+-+-+-+-+-+- ...
   | Page 1 |  SRH-6LoRH  | P-RPI-6LoRH | IP-in-IP 6LoRH | Inner Packet
   +-+ ... -+-+-+- ... -+-+-+- ... -+-+-+-+-+- ... +-+-+-+-+-+-+- ...

    Signals :  Loose Hops :    TrackID  :  Track DODAGID :

               Figure 16: A Packet as Forwarded along a Track

7.  Lesser Constrained Variations

7.1.  Storing Mode Main DODAG

   This specification expects that the Main DODAG is operated in Non-
   Storing Mode.  The reasons for that limitation are mostly related to
   LLN operations, power and spectrum conservation:

   *  In Non-Storing Mode The Root already possesses the DODAG topology,
      so the additional topological information is reduced to the
      siblings.

   *  The downwards routes are updated with unicast messages to the
      Root, which ensures that the Root can reach back to the LLN nodes
      after a repair faster than in the case of Storing Mode.  Also the
      Root can control the use of the path diversity in the DODAG to
      reach to the LLN nodes.  For both reasons, Non-Storing Mode
      provides better capabilities for the Root to maintain the
      P-Routes.

   *  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 does not use Source Routing Headers, and does
      not derive the same benefits from this capability.

   On the other hand, since RPL is a Layer-3 routing protocol, its
   applicability extends beyond LLNs to a generic IP network.  RPL
   requires fewer 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.
   P-Routes add the capability to install shortest and/or constrained
   routes to special destinations such as discussed in section A.9.4. of
   the ANIMA ACP [RFC8994].

   In a powered and wired network, when enough memory to store the
   needed routes is available, the RPL Storing Mode proposes a better
   trade-off than the Non-Storing, as it reduces the route stretch and
   lowers the load on the Root.  In that case, the control path between
   the Root and the LLN nodes is highly available compared to LLNs, and
   the nodes can be reached to maintain the P-Routes at most times.

   This section specifies the additions that are needed to support
   Projected Routes when the Main DODAG is operated in Storing Mode.  As
   long as the RPI can be processed adequately by the dataplane, the
   changes to this specification are limited to the DAO message.  The
   Track structure, routes and forwarding operations remain the same.

   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 nodes in the network MUST send additional
   DAO messages that are unicast to the Root as Non-Storing DAO messages
   are.

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

   The DAO message MUST be formed as follows:

   *  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 so the Root can correlate the DAOs from those
      routers when they advertise this router as their neighbor.  The
      DAO contains one or more sequences of one Transit Information
      Option and one or more Sibling Information Options.  There is no
      RPL Target Option so the Root is not confused into adding a
      Storing Mode route to the Target.

   *  The TIO is formed as in Storing Mode, and the Parent Address is
      not present.  The Path Sequence and Path Lifetime fields are
      aligned with the values used in the Address Registration of the
      node(s) advertised in the SIO, as explained in Section 9.1. of
      [RFC9010].  Having similar values in all nodes allows to factorise
      the TIO for multiple SIOs as done with [RPL].

   *  The encapsulating TIO is followed by one or more SIOs that provide an address
      (ULA or GUA) of the advertised neighbor node.

   But the RPL routing information headers may not be supported on all
   type of routed network infrastructures, especially not in high-speed
   routers.  When the RPI is not be supported in the dataplane, there
   cannot be local RPL 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 encapsulates is not the Root.  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 precedence in the routing table.  The Targets MUST be adjacent
   to the Track Egress to avoid loops that may form if the packet is
   reinjected in the Main DODAG.

7.2.  A Track as a Full DODAG

   This specification builds parallel or crossing Track Legs as opposed
   to a more complex DODAG with interconnections at any place desirable.
   The reason for that limitation is related to constrained node
   operations, and capability to store large amount of topological
   information and compute complex paths:

   *  With this specification, the node in the LLN has no topological
      awareness, and does not need to maintain dynamic information about
      the link quality and availability.

   *  The Root has a complete topological information and statistical
      metrics 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 Track Leg and predigest the source route paths.

   *  The node merely selects one of the proposed paths and applies the
      associated pre-computed routing header in the encapsulation.  This
      alleviates both the complexity of computing a path and the
      compressed form of the routing header.

   The "Reliable and Available Wireless (RAW) Architecture/Framework"
   [RAW-ARCHI] actually expects the PSE at the Track Ingress to react to
   changes in the forwarding conditions along the Track, and reroute
   packets to maintain the required degree of reliability.  To achieve
   this, the PSE need the full richness of a DODAG to form any path that
   could make meet the SLAs.

   This section specifies the additions that are forwarded along needed to turn the
   Track between C into a full DODAG and E have enable the following settings:

    +========+===================+===================+================+
    | Header | IPv6 Source Addr. | IPv6 Dest.  Addr. | TrackID in RPI |
    +========+===================+===================+================+
    | Outer  |         C         |  D till D then E  |    (C, 131)    |
    +--------+-------------------+-------------------+----------------+
    | Middle |         A         |         E         |    (A, 141)    |
    +--------+-------------------+-------------------+----------------+
    | Inner  |         X         |     E, F or G     |      N/A       |
    +--------+-------------------+-------------------+----------------+

                      Table 15: Packet header settings

   As main Root to provide the
   necessary topological information to the Track Ingress.  The
   expectation is that the metrics that the PSE uses are of an example, say order
   other than that A has a packet for F.  Using of the RIB above:

   *  From PCE, because of the difference of time scale
   between routing and forwarding, mor e in [RAW-ARCHI].  It follows
   that the PSE will learn the metrics it needs from an alternate
   source, e.g., OAM frames.

   To pass the topological information to the Ingress, the Root uses a
   P-DAO 3: A encapsulates messages that contains sequences of Target and Transit
   Information options that collectively represent the Track, expressed
   in the same fashion as in classical Non-Storing Mode.  The difference
   as that the Root is the source as opposed to the packet destination, and can
   report information on many Targets, possibly the full Track, with destination of F one
   P-DAO.

   Note that the Path Sequence and Lifetime in the Track signaled TIO are selected by P-DAO 3.  The outer header has source A,
      destination E,
   the Root, and a RPI indicating a TrackId of 141 from A's
      namespace.  This recurses with:

   *  From that the Target/Transit information tupples in the
   P-DAO 2: A encapsulates are not those received by the packet with destination of E Root in the DAO messages about
   the said Targets.  The Track signaled may follow sibling routes and does not
   need to be congruent with the Main DODAG.

8.  Profiles

   This document provides a set of tools that may or may not be needed
   by P-DAO 2.  The outer header has source A,
      destination B, an SRH that indicates C as implementation depending on the next loose hop, type of application it serves.
   This sections described 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 to implement only a RPI indicating a TrackId
   portion of 129 from A's namespace.

   *  From the SRH: Packets forwarded by B have source A, destination C
      , this specification to meet a consumed SRH, particular use case.

   Profiles 0 to 2 operate in the Main RPL Instance and a RPI indicating a TrackId do not require
   the support of 129 from A's
      namespace.  C decapsulates.

   *  From P-DAO 1: C encapsulates local RPL Instances or the packet with destination indication of E in the Track signaled by P-DAO 1.  The outer header has source C,
      destination D, an SRH that indicates E as RPL
   Instance in the next loose hop, data plane.  Profile 3 and
      a RPI indicating a TrackId of 131 from C's namespace.  E
      decapsulates.

9.2.3.  Segment Routing

   Non-Storing Mode P-DAO 1 is sent above leverage Local RPL
   Instances to C build arbitrary Tracks rooted at the Track Ingress and Non-Storing Mode P-DAO 2
   using its namespace for TrackID.

   Profiles 0 and 3 are sent A, as follows:

      +===============+==============+==============+==============+
      |               | P-DAO 1 are REQUIRED by all implementations that may be used
   in LLNs; this enables to C | P-DAO 2 to A | P-DAO 3 to A |
      +===============+==============+==============+==============+
      | use Storing Mode     | Non-Storing  | Non-Storing  | Non-Storing  |
      +---------------+--------------+--------------+--------------+
      | Track Ingress | C            | A            | A            |
      +---------------+--------------+--------------+--------------+
      |    TrackID    | (C, 131)     | (A, 129)     | (A, 141)     |
      +---------------+--------------+--------------+--------------+
      |      VIO      | D, E         | B            | C, E         |
      +---------------+--------------+--------------+--------------+
      |    Targets    |              | C            | F, G         |
      +---------------+--------------+--------------+--------------+

                         Table 16: P-DAO Messages

   As a result to reduce the RIBs are set as follows:

         +======+=============+=========+=============+==========+
         | Node | Destination | Origin  | Next Hop(s) | TrackID  |
         +======+=============+=========+=============+==========+
         |  E   | F, G        | ND      | Neighbor    | Any      |
         +------+-------------+---------+-------------+----------+
         |  D   | E           | ND      | Neighbor    | Any      |
         +------+-------------+---------+-------------+----------+
         |  C   | D           | ND      | Neighbor    | Any      |
         +------+-------------+---------+-------------+----------+
         |  "   | E           | P-DAO 1 | D, E        | (C, 131) |
         +------+-------------+---------+-------------+----------+
         |  B   | C           | ND      | Neighbor    | Any      |
         +------+-------------+---------+-------------+----------+
         |  A   | B           | ND      | Neighbor    | Any      |
         +------+-------------+---------+-------------+----------+
         |  "   | C           | P-DAO size of the
   Source Route Header in the most common LLN deployments.  Profile 2 | B, C        | (A, 129) |
         +------+-------------+---------+-------------+----------+
         |  "   | E, F, G     | P-DAO 3 | C, E        | (A, 141) |
         +------+-------------+---------+-------------+----------+

                           Table 17: RIB setting

   The encapsulating headers is
   RECOMMENDED in high speed / wired environment to enable traffic
   Engineering and network automation.  All the other profile /
   environment combinations are OPTIONAL.

   Profile 0  Profile 0 is the Legacy support of packets [RPL] Non-Storing Mode,
      with default routing Northwards (up) and strict source routing
      Southwards (down the main DOAG).  It provides the minimal common
      functionality that are forwarded must be implemented as a prerequisite to all
      the Track-supporting profiles.  The other Profiles extend Profile
      0 with selected capabilities that this specification introduces on
      top.

   Profile 1 (Storing Mode P-Route Segments along the
   Track between A Main DODAG)  Profi
      le 1 does not create new paths; compared to Profile 0, it combines
      Storing and B have Non-Storing Modes to balance the following settings:

    +========+===================+===================+================+
    | size of the Routing
      Header | IPv6 Source Addr. | IPv6 Dest.  Addr. | TrackID in RPI |
    +========+===================+===================+================+
    | Outer  |         A         |  B till D then E  |    (A, 129)    |
    +--------+-------------------+-------------------+----------------+
    | Middle |         A         |         C         |    (A, 141)    |
    +--------+-------------------+-------------------+----------------+
    | Inner  |         X         |     E, F or G     |      N/A       |
    +--------+-------------------+-------------------+----------------+

                      Table 18: Packet header settings

   The encapsulating headers the packet and the amount of packets that are forwarded state in the intermediate
      routers in a Non-Storing Mode RPL DODAG.

   Profile 2 (Non-Storing Mode P-Route Segments along the Main DODAG)  P
      rofile 2 extends Profile 0 with Strict Source-Routing Non-Storing
      Mode P-Routes along the
   Track between B and C have 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 compress the following settings:

    +========+===================+===================+================+
    | Header | IPv6 Source Addr. | IPv6 Dest.  Addr. | TrackID SRH in RPI |
    +========+===================+===================+================+
    | Outer  |         A         |         C         |    (A, 141)    |
    +--------+-------------------+-------------------+----------------+
    | Inner  |         X         |     E, F or G     |      N/A       |
    +--------+-------------------+-------------------+----------------+

                      Table 19: Packet header settings

   The encapsulating headers of packets that are forwarded along the
   Track between C and E have down the following settings:

    +========+===================+===================+================+
    | Header | IPv6 Source Addr. | IPv6 Dest.  Addr. | TrackID Main DODAG
      as Profile 1, but it require an encapsulation, in RPI |
    +========+===================+===================+================+
    | Outer  |         C         |  D till D then E  |    (C, 131)    |
    +--------+-------------------+-------------------+----------------+
    | Middle |         A         |         E         |    (A, 141)    |
    +--------+-------------------+-------------------+----------------+
    | Inner  |         X         |     E, F or G     |      N/A       |
    +--------+-------------------+-------------------+----------------+

                      Table 20: Packet header settings

   As order to insert
      an example, say additional SRH between the loose source routing hops.  In that A has a packet for F.  Using
      case, the RIB above:

   *  From P-DAO 3: A Tracks MUST be installed as subTracks of the Main DODAG,
      the main RPL Instance MUST be used as TrackID, and the Ingress
      node that encapsulates is not the Root as it does not own the
      DODAGID.

   Profile 3  In order to form the best path possible, those Profiles
      require the support of Sibling Information Option to inform the
      Root of additional possible hops.  Profile 3 extends Profile 1
      with additional Storing Mode P-Routes that install segments that
      do not follow the Main DODAG.  If the Segment Ingress (in the packet with destination SM-
      VIO) is the same as the IPv6 Address of F in the Track signaled by Ingress (in the
      projected DAO base Object), the P-DAO 3.  The outer header has source A,
      destination C, creates an SRH implicit Track
      between the Segment Ingress and the Segment Egress.

   Profile 4  Profile 4 extends Profile 2 with Strict Source-Routing
      Non-Storing Mode P-Routes to form East-West Tracks that indicates E are inside
      the Main DODAG but do not necessarily follow it.  A Track is
      formed as one or more strict source source routed paths between
      the next loose hop, Root that is the Track Ingress, and
      a RPI indicating a TrackId of 141 from A's namespace.  This
      recurses with:

   *  From P-DAO 2: A encapsulates the packet Track Egress that is
      the last node.

   Profile 5  Profile 5 Combines Profile 4 with destination Profile 1 and enables to
      loose source routing between the Ingress and the Egress of C the
      Track.  As in Profile 1, Storing Mode P-Routes connect the Track signaled by P-DAO 2.  The outer header has dots in
      the loose source A,
      destination B, route.

   Profile 6  Profile 6 Combines Profile 4 with Profile 2 and also
      enables to loose source routing between the Ingress and the Egress
      of the Track.

   Profile 7  Profile 7 implements profile 5 in a RPI indicating a TrackId Main DODAG that is
      operated in Storing Mode as presented in Section 7.1.  As in
      Profile 1 and 2, the TrackID is the RPLInstanceID of 129 from A's
      namespace.  B decapsulates forwards to C based on the Main
      DODAG.  Longest match rules decide whether a sibling
      connected route.

   *  From packet is sent along
      the SRH: C consumes Main DODAG or rerouted in a track.

   Profile 8  Profile 8 is offered in preparation of the SRH RAW work, and makes
      for use cases where an arbitrary node in the destination E.

   *  From P-DAO 1: C encapsulates network can afford
      the packet with destination of E same code complexity as the RPL Root in a traditional
      deployment.  It offers a full DODAG visibility to the Track signaled by P-DAO 1.  The outer header has source C,
      destination D, an SRH that indicates E
      Ingress as the next loose hop, specified in Section 7.2 in a Non-Storing Mode Main
      DODAG.

   Profile 9  Profile 9 combines profiles 7 and 8, operating the Track
      as a RPI indicating full DODAG within a TrackId of 131 from C's namespace.  E
      decapsulates.

10. Storing Mode Main DODAG, using only the
      Main DODAG RPLInstanceID as TrackID.

9.  Security Considerations

   It is worth noting that with [RPL], every node in the LLN is RPL-
   aware and can inject any RPL-based attack in the network.  This draft
   uses messages that are already present in RPL [RPL] with optional
   secured versions.  The same secured versions may be used with this
   draft, and whatever security is deployed for a given network also
   applies to the flows in this draft.

   The LLN nodes depend on the 6LBR and the RPL participants for their
   operation.  A trust model must be put in place to ensure that the
   right devices are acting in these roles, so as to avoid threats such
   as black-holing, (see [RFC7416] section 7).  This trust model could
   be at a minimum based on a Layer-2 Secure joining and the Link-Layer
   security.  This is a generic 6LoWPAN requirement, see Req5.1 in
   Appendix B.5 of [RFC8505].

   In a general manner, the Security Considerations in [RPL], and
   [RFC7416] apply to this specification as well.  The Link-Layer
   security is needed in particular to prevent Denial-Of-Service attacks
   whereby a rogue router creates a high churn in the RPL network by
   constantly injected forged P-DAO messages and using up all the
   available storage in the attacked routers.

   Additionally, the trust model could include a role validation (e.g.,
   using a role-based authorization) to ensure that the node that claims
   to be a RPL Root is entitled to do so.  That trust should propagate
   from egress Egress to ingress Ingress in the case of a Storing Mode P-DAO.

11.

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

10.  IANA Considerations

11.1.
10.1.  New Elective 6LoWPAN Routing Header Type

   This document updates the IANA registry titled "Elective 6LoWPAN
   Routing Header Type" that was created for [RFC8138] and assigns the
   following value:

                  +=======+=============+===============+

              +===============+=============+===============+
              |     Value     | Description | Reference     |
                  +=======+=============+===============+
              +===============+=============+===============+
              |   7 8 (Suggested) | P-RPI-6LoRH | This document |
                  +-------+-------------+---------------+
              +---------------+-------------+---------------+

                   Table 21: New Elective 6LoWPAN Routing
                                Header Type

11.2.

10.2.  New Critical 6LoWPAN Routing Header Type

   This document updates the IANA registry titled "Critical 6LoWPAN
   Routing Header Type" that was created for [RFC8138] and assigns the
   following value:

                  +=======+=============+===============+

              +===============+=============+===============+
              |     Value     | Description | Reference     |
                  +=======+=============+===============+
              +===============+=============+===============+
              |   7 8 (Suggested) | P-RPI-6LoRH | This document |
                  +-------+-------------+---------------+
              +---------------+-------------+---------------+

                   Table 22: New Critical 6LoWPAN Routing
                                Header Type

11.3.

10.3.  New Subregistry For The RPL Option Flags

   IANA is required to create a subregistry for the 8-bit RPL Option
   Flags field, as detailed in Figure 2, 4, under the "Routing Protocol for
   Low Power and Lossy Networks (RPL)" registry.  The bits are indexed
   from 0 (leftmost) to 7.  Each bit is tracked Tracked with the following
   qualities:

   *  Bit number (counting from bit 0 as the most significant bit)

   *  Indication When Set

   *  Reference

   Registration procedure is "Standards Action" [RFC8126].  The initial
   allocation is as indicated in Table 26:

           +============+======================+===============+

         +===============+======================+===============+
         |   Bit number  | Indication When Set  | Reference     |
           +============+======================+===============+
         +===============+======================+===============+
         |       0       | Down 'O'             | [RFC6553]     |
           +------------+----------------------+---------------+
         +---------------+----------------------+---------------+
         |       1       | Rank-Error (R)       | [RFC6553]     |
           +------------+----------------------+---------------+
         +---------------+----------------------+---------------+
         |       2       | Forwarding-Error (F) | [RFC6553]     |
           +------------+----------------------+---------------+
         +---------------+----------------------+---------------+
         | 3 (Suggested) | Projected-Route (P)  | This document |
           +------------+----------------------+---------------+
         +---------------+----------------------+---------------+

                       Table 23: Initial PDR Flags

11.4.

10.4.  New RPL Control Codes

   This document extends the IANA Subregistry created by RFC 6550 for
   RPL Control Codes as indicated in Table 24:

          +======+=============================+===============+

    +==================+=============================+===============+
    |       Code       | Description                 | Reference     |
          +======+=============================+===============+
    +==================+=============================+===============+
    | 0x09 (Suggested) | Projected DAO Request (PDR) | This document |
          +------+-----------------------------+---------------+
    +------------------+-----------------------------+---------------+
    | 0x0A (Suggested) | PDR-ACK                     | This document |
          +------+-----------------------------+---------------+
    +------------------+-----------------------------+---------------+

                     Table 24: New RPL Control Codes

11.5.

10.5.  New RPL Control Message Options

   This document extends the IANA Subregistry created by RFC 6550 for
   RPL Control Message Options as indicated in Table 25:

          +=======+============================+===============+

    +==================+=============================+===============+
    |      Value       | Meaning                     | Reference     |
          +=======+============================+===============+
    +==================+=============================+===============+
    |  0x0B 0x0E (Suggested) | Stateful VIO (SF-VIO) (SM-VIO)       | This document |
          +-------+----------------------------+---------------+
    +------------------+-----------------------------+---------------+
    |  0x0C 0x0F (Suggested) | Source-Routed VIO (SR-VIO) (NSM-VIO) | This document |
          +-------+----------------------------+---------------+
    +------------------+-----------------------------+---------------+
    |  0x0D 0x10 (Suggested) | Sibling Information option  | This document |
          +-------+----------------------------+---------------+
    +------------------+-----------------------------+---------------+

                  Table 25: RPL Control Message Options

11.6.

10.6.  SubRegistry for the Projected DAO Request Flags

   IANA is required to create a registry for the 8-bit Projected DAO
   Request (PDR) Flags field.  Each bit is tracked Tracked with the following
   qualities:

   *  Bit number (counting from bit 0 as the most significant bit)

   *  Capability description

   *  Reference

   Registration procedure is "Standards Action" [RFC8126].  The initial
   allocation is as indicated in Table 26:

          +============+========================+===============+
          | Bit number | Capability description | Reference     |
          +============+========================+===============+
          |     0      | PDR-ACK request (K)    | This document |
          +------------+------------------------+---------------+
          |     1      | Requested path should  | This document |
          |            | be redundant (R)       |               |
          +------------+------------------------+---------------+

                        Table 26: Initial PDR Flags

11.7.

10.7.  SubRegistry for the PDR-ACK Flags

   IANA is required to create an subregistry for the 8-bit PDR-ACK Flags
   field.  Each bit is tracked Tracked with the following qualities:

   *  Bit number (counting from bit 0 as the most significant bit)

   *  Capability description

   *  Reference

   Registration procedure is "Standards Action" [RFC8126].  No bit is
   currently defined for the PDR-ACK Flags.

11.8.

10.8.  Subregistry for the PDR-ACK Acceptance Status Values

   IANA is requested to create a Subregistry for the PDR-ACK Acceptance
   Status values.

   *  Possible values are 6-bit unsigned integers (0..63).

   *  Registration procedure is "Standards Action" [RFC8126].

   *  Initial allocation is as indicated in Table 27:

            +-------+------------------------+---------------+
            | Value | Meaning                | Reference     |
            +-------+------------------------+---------------+
            | 0     | Unqualified acceptance Acceptance | This document |
            +-------+------------------------+---------------+

            Table 27: Acceptance values of the PDR-ACK Status

11.9.

10.9.  Subregistry for the PDR-ACK Rejection Status Values

   IANA is requested to create a Subregistry for the PDR-ACK Rejection
   Status values.

   *  Possible values are 6-bit unsigned integers (0..63).

   *  Registration procedure is "Standards Action" [RFC8126].

   *  Initial allocation is as indicated in Table 28:

             +-------+-----------------------+---------------+
             | Value | Meaning               | Reference     |
             +-------+-----------------------+---------------+
             | 0     | Unqualified rejection Rejection | This document |
             +-------+-----------------------+---------------+
             | 1     | Transient Failure     | This document |
             +-------+-----------------------+---------------+

              Table 28: Rejection values of the PDR-ACK Status

11.10.

10.10.  SubRegistry for the Via Information Options Flags

   IANA is requested to create a Subregistry for the 5-bit Via
   Information Options (Via Information Option) Flags field.  Each bit
   is tracked Tracked with the following qualities:

   *  Bit number (counting from bit 0 as the most significant bit)

   *  Capability description

   *  Reference

   Registration procedure is "Standards Action" [RFC8126].  No bit is
   currently defined for the Via Information Options (Via Information
   Option) Flags.

11.11.

10.11.  SubRegistry for the Sibling Information Option Flags

   IANA is required to create a registry for the 5-bit Sibling
   Information Option (SIO) Flags field.  Each bit is tracked Tracked with the
   following qualities:

   *  Bit number (counting from bit 0 as the most significant bit)

   *  Capability description

   *  Reference

   Registration procedure is "Standards Action" [RFC8126].  The initial
   allocation is as indicated in Table 29:

    +============+===================================+===============+

          +===============+========================+===========+
          |   Bit number  | Capability description | Reference |
    +============+===================================+===============+
          +===============+========================+===========+
          | 0 (Suggested) | Connectivity is bidirectional (B) "D" flag: Sibling in   | This      |
          |               | same DODAG as Self     | document  |
    +------------+-----------------------------------+---------------+
          +---------------+------------------------+-----------+

                       Table 29: Initial SIO Flags

11.12.

10.12.  New Destination destination Advertisement Object Flag

   This document modifies the "Destination "destination Advertisement Object (DAO)
   Flags" registry initially created in Section 20.11 of [RPL] .

   Section 3.1 4.1.1 also defines one new entry in the Registry as follows:

          +---------------+------------------------+-----------+
          | Bit Number    | Capability Description | Reference |
          +---------------+------------------------+-----------+
          | 2 (suggested) (Suggested) | Projected DAO (P)      | THIS RFC  |
          +---------------+------------------------+-----------+

              Table 30: New Destination destination Advertisement Object
                                (DAO) Flag

11.13.  Error in Projected Route

10.13.  New ICMPv6 Error Code

   In some cases RPL will return an ICMPv6 error message when a message
   cannot be forwarded along a Projected Route.  This ICMPv6 error
   message is "Error in Projected Route". P-Route.

   IANA has defined an ICMPv6 "Code" Fields Registry for ICMPv6 Message
   Types.  ICMPv6 Message Type 1 describes "Destination "destination Unreachable"
   codes.  This specification requires that a new code is allocated from
   the ICMPv6 Code Fields Registry for ICMPv6 Message Type 1, for "Error
   in Projected Route", P-Route", with a suggested code value of 8, to be
   confirmed by IANA.

12. 8, to be confirmed by
   IANA.

10.14.  New RPL Rejection Status values

   This specification updates the Subregistry for the "RPL Rejection
   Status" values under the RPL registry, as follows:

          +---------------+-------------------------+-----------+
          | Value         | Meaning                 | Reference |
          +---------------+-------------------------+-----------+
          | 2 (Suggested) | Out of Resources        | THIS RFC  |
          +---------------+-------------------------+-----------+
          | 3 (Suggested) | Error in VIO            | THIS RFC  |
          +---------------+-------------------------+-----------+
          | 4 (Suggested) | Predecessor Unreachable | THIS RFC  |
          +---------------+-------------------------+-----------+
          | 5 (Suggested) | Unreachable Target      | THIS RFC  |
          +---------------+-------------------------+-----------+
          | 6..63         | Unassigned              |           |
          +---------------+-------------------------+-----------+

                Table 31: Rejection values of the RPL Status

11.  Acknowledgments

   The authors wish to acknowledge JP Vasseur, Remy Liubing, James
   Pylakutty
   Pylakutty, and Patrick Wetterwald for their contributions to the
   ideas developed here.

13.  Many thanks to Dominique Barthel and SVR Anand
   for their global contribution to 6TiSCH, RAW and this document, as
   well as text suggestions that were incorporated, and to Michael
   Richardson for his useful recommendations based on his global view of
   the system.  Also special thanks Toerless Eckert for his deep review,
   with many excellent suggestions that improved the readability and
   well as the content of the specification.

12.  Normative References

   [INT-ARCHI]
              Braden, R., Ed., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122,
              DOI 10.17487/RFC1122, October 1989,
              <https://www.rfc-editor.org/info/rfc1122>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4443]  Conta, A., Deering, S., and M. Gupta, Ed., "Internet
              Control Message Protocol (ICMPv6) for the Internet
              Protocol Version 6 (IPv6) Specification", STD 89,
              RFC 4443, DOI 10.17487/RFC4443, March 2006,
              <https://www.rfc-editor.org/info/rfc4443>.

   [RFC4655]  Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
              Computation Element (PCE)-Based Architecture", RFC 4655,
              DOI 10.17487/RFC4655, August 2006,
              <https://www.rfc-editor.org/info/rfc4655>.

   [RFC5551]  Gellens, R., Ed., "Lemonade Notifications Architecture",
              RFC 5551, DOI 10.17487/RFC5551, August 2009,
              <https://www.rfc-editor.org/info/rfc5551>.

   [RFC6282]  Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
              Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
              DOI 10.17487/RFC6282, September 2011,
              <https://www.rfc-editor.org/info/rfc6282>.

   [RPL]      Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
              Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
              JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
              Low-Power and Lossy Networks", RFC 6550,
              DOI 10.17487/RFC6550, March 2012,
              <https://www.rfc-editor.org/info/rfc6550>.

   [RFC6553]  Hui, J. and JP. Vasseur, "The Routing Protocol for Low-
              Power and Lossy Networks (RPL) Option for Carrying RPL
              Information in Data-Plane Datagrams", RFC 6553,
              DOI 10.17487/RFC6553, March 2012,
              <https://www.rfc-editor.org/info/rfc6553>.

   [RFC6554]  Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
              Routing Header for Source Routes with the Routing Protocol
              for Low-Power and Lossy Networks (RPL)", RFC 6554,
              DOI 10.17487/RFC6554, March 2012,
              <https://www.rfc-editor.org/info/rfc6554>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

14.

13.  Informative References

   [6LoWPAN]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
              "Transmission of IPv6 Packets over IEEE 802.15.4
              Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
              <https://www.rfc-editor.org/info/rfc4944>.

   [RFC7102]  Vasseur, JP., "Terms Used in Routing for Low-Power and
              Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
              2014, <https://www.rfc-editor.org/info/rfc7102>.

   [RFC6997]  Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and
              J. Martocci, "Reactive Discovery of Point-to-Point Routes
              in Low-Power and Lossy Networks", RFC 6997,
              DOI 10.17487/RFC6997, August 2013,
              <https://www.rfc-editor.org/info/rfc6997>.

   [RFC7416]  Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A.,
              and M. Richardson, Ed., "A Security Threat Analysis for
              the Routing Protocol for Low-Power and Lossy Networks
              (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015,
              <https://www.rfc-editor.org/info/rfc7416>.

   [6TiSCH-ARCHI]
              Thubert, P., Ed., "An Architecture for IPv6 over the Time-
              Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)",
              RFC 9030, DOI 10.17487/RFC9030, May 2021,
              <https://www.rfc-editor.org/info/rfc9030>.

   [RAW-ARCHI]
              Thubert, P., Papadopoulos, G. Z., and L. Berger, "Reliable
              and Available Wireless Architecture/Framework", Work in
              Progress, Internet-Draft, draft-ietf-raw-architecture-00,
              12 draft-ietf-raw-architecture-01,
              28 July 2021, <https://datatracker.ietf.org/doc/html/
              draft-ietf-raw-architecture-00>.
              draft-ietf-raw-architecture-01>.

   [USE-CASES]
              Papadopoulos, G. Z., Thubert, P., Theoleyre, F., and C. J.
              Bernardos, "RAW use cases", Work in Progress, Internet-
              Draft, draft-ietf-raw-use-cases-02, 12 July 2021,
              <https://datatracker.ietf.org/doc/html/draft-ietf-raw-use-
              cases-02>.

   [TURN-ON_RFC8138]
              Thubert, P., Ed. and L. Zhao, "A Routing Protocol for Low-
              Power and Lossy Networks (RPL) Destination-Oriented
              Directed Acyclic Graph (DODAG) Configuration Option for
              the 6LoWPAN Routing Header", RFC 9035,
              DOI 10.17487/RFC9035, April 2021,
              <https://www.rfc-editor.org/info/rfc9035>.

   [RFC8025]  Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power
              Wireless Personal Area Network (6LoWPAN) Paging Dispatch",
              RFC 8025, DOI 10.17487/RFC8025, November 2016,
              <https://www.rfc-editor.org/info/rfc8025>.

   [RFC8138]  Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,
              "IPv6 over Low-Power Wireless Personal Area Network
              (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,
              April 2017, <https://www.rfc-editor.org/info/rfc8138>.

   [RFC8505]  Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
              Perkins, "Registration Extensions for IPv6 over Low-Power
              Wireless Personal Area Network (6LoWPAN) Neighbor
              Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
              <https://www.rfc-editor.org/info/rfc8505>.

   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

   [RFC8655]  Finn, N., Thubert, P., Varga, B., and J. Farkas,
              "Deterministic Networking Architecture", RFC 8655,
              DOI 10.17487/RFC8655, October 2019,
              <https://www.rfc-editor.org/info/rfc8655>.

   [RFC8025]

   [RFC8930]  Watteyne, T., Ed., Thubert, P., Ed. Ed., and R. Cragie, "IPv6 C. Bormann, "On
              Forwarding 6LoWPAN Fragments over Low-Power
              Wireless Personal Area Network (6LoWPAN) Paging Dispatch", a Multi-Hop IPv6
              Network", RFC 8025, 8930, DOI 10.17487/RFC8025, 10.17487/RFC8930, November 2016,
              <https://www.rfc-editor.org/info/rfc8025>.

   [RFC8138] 2020,
              <https://www.rfc-editor.org/info/rfc8930>.

   [RFC8931]  Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, "IPv6 over Low-Power Wireless Personal
              Area Network (6LoWPAN) Routing Header", Selective Fragment Recovery",
              RFC 8138, 8931, DOI 10.17487/RFC8138,
              April 2017, <https://www.rfc-editor.org/info/rfc8138>.

   [RFC8505]  Thubert, P., 10.17487/RFC8931, November 2020,
              <https://www.rfc-editor.org/info/rfc8931>.

   [RFC8994]  Eckert, T., Ed., Behringer, M., Ed., Nordmark, E., Chakrabarti, S., and C.
              Perkins, "Registration Extensions for IPv6 over Low-Power
              Wireless Personal Area Network (6LoWPAN) Neighbor
              Discovery", S. Bjarnason, "An
              Autonomic Control Plane (ACP)", RFC 8505, 8994,
              DOI 10.17487/RFC8505, November 2018,
              <https://www.rfc-editor.org/info/rfc8505>.

   [USEofRPLinfo] 10.17487/RFC8994, May 2021,
              <https://www.rfc-editor.org/info/rfc8994>.

   [RFC9008]  Robles, M.I., Richardson, M., and P. Thubert, "Using RPI
              Option Type, Routing Header for Source Routes, and IPv6-
              in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008,
              DOI 10.17487/RFC9008, April 2021,
              <https://www.rfc-editor.org/info/rfc9008>.

   [RFC9010]  Thubert, P., Ed. and M. Richardson, "Routing for RPL
              (Routing Protocol for Low-Power and Lossy Networks)
              Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021,
              <https://www.rfc-editor.org/info/rfc9010>.

   [I-D.irtf-panrg-path-properties]
              Enghardt, T. and C. Krähenbühl, "A Vocabulary of Path
              Properties", Work in Progress, Internet-Draft, draft-irtf-
              panrg-path-properties-03, 9 July 2021,
              <https://datatracker.ietf.org/doc/html/draft-irtf-panrg-
              path-properties-03>.

   [PCE]      IETF, "Path Computation Element",
              <https://datatracker.ietf.org/doc/charter-ietf-pce/>.
              <https://dataTracker.ietf.org/doc/charter-ietf-pce/>.

Appendix A.  Applications

A.1.  Loose Source Routing

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

              ------+---------
                    |          Internet
                    |
                 +-----+
                 |     | Border Router router
                 |     |  (RPL Root)
                 +-----+                      ^     |        |
                    |                         | DAO | ACK    |
              o    o   o    o                 |     |        | Strict
          o o   o  o   o  o  o o   o          |     |        | Source
         o  o o  o o    o   o   o  o  o       |     |        | Route
         o   o    o  o     o  o    o  o  o    |     |        |
        o  o   o  o   o         o   o o       |     v        v
        o          o             o     o
                          LLN

                Figure 12: 17: RPL Non-Storing Mode of operation

   Based on the parent-children relationships expressed in the non-
   storing Non-
   Storing DAO messages,the Root possesses topological information about
   the whole network, though this information is limited to the
   structure of the DODAG for which it is the destination.  A packet
   that is generated within the domain will always reach the Root, which
   can then apply a source routing information to reach the destination
   if the destination is also in the DODAG.  Similarly, a packet coming
   from the outside of the domain for a destination that is expected to
   be in a RPL domain reaches the Root.

   It results that the Root, or then some associated centralized
   computation engine such as a PCE, can determine the amount of packets
   that reach a destination in the RPL domain, and thus the amount of
   energy and bandwidth that is wasted for transmission, between itself
   and the destination, as well as the risk of fragmentation, any
   potential delays because of a paths longer than necessary (shorter
   paths exist that would not traverse the Root).

   As a network gets deep, the size of the source routing header that
   the Root must add to all the downward packets becomes an issue for
   nodes that are many hops away.  In some use cases, a RPL network
   forms long lines and a limited amount of well-Targeted well-targeted routing state
   would allow to make the source routing operation loose as opposed to
   strict, and save packet size.  Limiting the packet size is directly
   beneficial to the energy budget, but, mostly, it reduces the chances
   of frame loss and/or packet fragmentation, which is highly
   detrimental to the LLN operation.  Because the capability to store a
   routing state in every node is limited, the decision of which route
   is installed where can only be optimized with a global knowledge of
   the system, a knowledge that the Root or an associated PCE may
   possess by means that are outside of the scope of this specification.

   This specification enables to store a Storing Mode state in
   intermediate routers, which enables to limit the excursion of the
   source route headers in deep networks.  Once a P-DAO exchange has
   taken place for a given Target, if the Root operates in non Storing
   Mode, then it may elide the sequence of routers that is installed in
   the network from its source route headers to destination that are
   reachable via that Target, and the source route headers effectively
   become loose.

A.2.  Transversal  East-West Routes

   RPL is optimized for Point-to-Multipoint (P2MP) and Multipoint-to-
   Point (MP2P), whereby routes are always installed North-South (aka
   up/down) along the RPL DODAG respectively from and towards the DODAG
   Root.  Transversal  Peer to Peer (P2P) East-West routes in a RPL network will
   generally suffer from some elongated (stretched) path versus the best possible a direct
   (optimized) path, since routing between 2 two nodes always happens via
   a common parent, as illustrated in Figure 13: 18:

                      ------+---------
                       |          Internet
                       |
                    +-----+
                    |     | Border router
                    |     |  (RPL Root)
                    +-----+
                       X
                 ^    v   o    o
             ^ o   o  v   o  o  o o   o
            ^  o o  o v    o   o   o  o  o
            ^   o    o  v     o  o    o  o  o
           S  o   o  o   D         o   o o
           o          o             o     o
                             LLN

       Figure 18: Routing Stretch between S and D via common parent X
                          along North-South Paths

   *  In Storing Mode, unless the destination is a child of the source,
      the packets will follow the default route up the DODAG as well.
      If the destination is in the same DODAG, they will eventually
      reach a common parent that has a route to the destination; at
      worse, the common parent may also be the Root.  From that common
      parent, the packet will follow a path down the DODAG that is
      optimized for the Objective Function that was used to build the
      DODAG.

   *  in Non-Storing Mode, all packets routed within the DODAG flow all
      the way up to the Root of the DODAG.  If the destination is in the
      same DODAG, the Root must encapsulate the packet to place an RH
      that has the strict source route information down the DODAG to the
      destination.  This will be the case even if the destination is
      relatively close to the source and the Root is relatively far off.

                      ------+---------
                       |          Internet
                       |
                    +-----+
                    |     | Border Router
                    |     |  (RPL Root)
                    +-----+
                       X
                 ^    v   o    o
             ^ o   o  v   o  o  o o   o
            ^  o o  o v    o   o   o  o  o
            ^   o    o  v     o  o    o  o  o
           S  o   o  o   D         o   o o
           o          o             o     o
                             LLN

       Figure 13: Routing Stretch between S and D via common parent X

   It results that it is often beneficial to enable transversal East-West P2P
   routes, either if the RPL route presents a stretch from shortest
   path, or if the new route is engineered with a different objective,
   and that it is even more critical in Non-Storing Mode than it is in
   Storing Mode, because the routing stretch is wider.  For that reason,
   earlier work at the IETF introduced the "Reactive Discovery of
   Point-to-Point Routes in Low Power and Lossy Networks" [RFC6997],
   which specifies a distributed method for establishing optimized P2P
   routes.  This draft proposes an alternate based on a centralized
   route computation.

                 ------+---------
                       |          Internet
                       |
                    +-----+
                    |     | Border Router router
                    |     |  (RPL Root)
                    +-----+
                       |
                 o    o   o    o
             o o   o  o   o  o  o o   o
            o  o o  o o    o   o   o  o  o
            o   o    o  o     o  o    o  o  o
           S>>A>>>B>>C>>>D         o   o o
           o          o             o     o
                             LLN

           Figure 14: Projected Transversal 19: More direct East-West Route between S and D

   This specification enables to store source-routed or Storing Mode
   state in intermediate routers, which enables to limit the stretch of
   a P2P route and maintain the characteristics within a given SLA.  An
   example of service using this mechanism oculd be a control loop that
   would be installed in a network that uses classical RPL for
   asynchronous data collection.  In that case, the P2P path may be
   installed in a different RPL Instance, with a different objective
   function.

Authors' Addresses

   Pascal Thubert (editor)
   Cisco Systems, Inc
   Building D
   45 Allee des Ormes - BP1200
   06254 Mougins - Sophia Antipolis
   France

   Phone: +33 497 23 26 34
   Email: pthubert@cisco.com
   Rahul Arvind Jadhav
   Huawei Tech
   Kundalahalli Village, Whitefield,
   Bangalore 560037
   Karnataka
   India

   Phone: +91-080-49160700
   Email: rahul.ietf@gmail.com

   Matthew Gillmore
   Itron, Inc
   Building D
   2111 N Molter Road
   Liberty Lake,  99019
   United States

   Phone: +1.800.635.5461
   Email: matthew.gillmore@itron.com