Draft: draft-ietf-roll-dao-projection

Commentary: These are just the typos fixed . 
 Many thanks  ! This is very helpful , sorry for the hassle
This document extends RFC 6550, RFC 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.
This document extends RFC 6550, RFC 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 itself, 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.
RPL, the RFC6550 (LLNs), is an anisotropic Distance Vector protocol
that is well-suited for application in a variety of low energy
Internet of Things (IoT) networks where stretched P2P paths are
acceptable vs. the signaling and state overhead involved in
maintaining shortest paths across.
With this specification, an abstract routing function called a Path
Computation Element PCE (e.g., located in an central controller or
collocated with the Root) interacts with the RPL Root to compute Peer
to Peer (P2P) paths within a pre-existing RPL Main DODAG.  The
topological information that is passed to the PCE is derived from the
DODAG that is already available at the Root in RPL Non-Storing Mode.
This specification introduces protocol extensions that enrich the
topological information that is available at the Root and passed to
the PCE.
RPL, the RFC6550 (LLNs), is an anisotropic Distance Vector protocol
that is well-suited for application in a variety of low energy
Internet of Things (IoT) networks where stretched P2P paths are
acceptable vs. the signaling and state overhead involved in
maintaining the shortest paths across.
With this specification, an abstract routing function called a Path
Computation Element PCE (e.g., located in an central controller or
collocated with the Root) interacts with the RPL Root to compute
Peer-to-Peer (P2P) paths within a pre-existing RPL Main DODAG.  The
topological information that is passed to the PCE is derived from the
DODAG that is already available at the Root in RPL Non-Storing Mode.
This specification introduces protocol extensions that enrich the
topological information that is available at the Root and passed to
the PCE.
Based on usage, path length, and knowledge of available resources
such as battery levels and reservable buffers in the nodes, the PCE
with a global visibility on the system can optimize the computed
routes for the application needs, including the capability to provide
path redundancy.  This specification also introduces protocol
extensions that enable the Root to translates the computed paths into
RPL and install them as Projected Routes (aka P-Routes) inside the
DODAG on behalf of a PCE.
Based on usage, path length, and knowledge of available resources
such as battery levels and reservable buffers in the nodes, the PCE
with a global visibility of the system can optimize the computed
routes for the application needs, including the capability to provide
path redundancy.  This specification also introduces protocol
extensions that enable the Root to translate the computed paths into
RPL and install them as Projected Routes (aka P-Routes) inside the
DODAG on behalf of a PCE.
RPL is anisotropic, meaning that it is directional, or more exactly
polar.  RPL does not behave the same way "down" with multicast DIO
messages that form the DODAG and "up" with unicast DAO messages that
follow the DODAG.  This is in contrast with traditional IGPs that
operate the same in all directions and are thus called isotropic.
The term Routing Stretch denotes the length of a path, as compared
with a shortest path, which can be a abstract concepts in RPL when
the metrics are statistical and dynamic, and the concept of short
varies with the Objective Function.
The RPL DODAG optimizes the P2MP (from Root) and MP2P (to Root)
paths, but the P2P (node to node) traffic has to follow the same
DODAG.  Following the DODAG, the RPL datapath passes via a common
parent in Storing Mode and via the Root in Non-Storing Mode.  This
typically involves more hops and more latency than the minimum
possible for a direct P2P path that an isotropic protocol would
compute.  We refer to this elongated path as stretched.
DAO messages that follow the DODAG.  This is in contrast with
traditional IGPs that operate the same way in all directions and are
thus called isotropic.
The term Routing Stretch denotes the length of a path, in comparison
to the length of the shortest path, which can be an abstract concept
in RPL when the metrics are statistical and dynamic, and the concept
of distance varies with the Objective Function.
The RPL DODAG optimizes the P2MP (Point-to-MultiPoint) (from the
Root) and MP2P (MultiPoint-to-Point) (towards the Root) paths, but
the P2P (Point-to-Point) traffic has to follow the same DODAG.
Following the DODAG, the RPL datapath passes via a common parent in
Storing Mode and via the Root in Non-Storing Mode.  This typically
involves more hops and more latency than the minimum possible for a
direct P2P path that an isotropic protocol would compute.  We refer
to this elongated path as stretched.
This specification using the term stitching to indicate that a track
is piped to another one, meaning that traffic out of the first is
injected in the other.
An end-to-end East-West serial path.  A leg can be a serial Track by
itself or a subTrack of a complex Track with the same Ingress and
Egress Nodes.  With this specification, a Leg is is installed by the
Root of the main DODAG using a Non-Storing Mode P-DAO message, and it
is expressed as a loose sequence of nodes that are joined by Track
Segments.
This specification uses the term stitching to indicate that a track
is piped to another one, meaning that traffic out of the first track
is injected into the other track.
An end-to-end East-West serial path.  A leg can be a Serial Track by
itself or a subTrack of a complex Track with the same Ingress and
Egress Nodes.  With this specification, a Leg is installed by the
Root of the main DODAG using a Non-Storing Mode P-DAO message, and it
is expressed as a loose sequence of nodes that are joined by Track
Segments.
A Track within a Track, formed by a non-empty collection of Legs of
the Track.
A Track within a Track, formed by a non-empty set of Legs of the
Track.
A continuous subset of a segment that may be replaced while the
segment remains. for instance, in segment A=>B=>C=>D=>E=>F, say that
the link C to D might be misbehaving.  The section B=>C=>D=>E in the
segment may be replaced by B=>C'=>D'=>E to route around the problem.
The segment becomes A=>B=>C'=>D'=>E=>F.
A continuous subset of a segment that may be replaced while the
segment remains.  For instance, in segment A=>B=>C=>D=>E=>F, say that
the link C to D might be misbehaving.  The section B=>C=>D=>E in the
segment may be replaced by B=>C'=>D'=>E to route around the problem.
The segment becomes A=>B=>C'=>D'=>E=>F.
RPL is optimized for situations where the power is scarce, the
bandwidth constrained and the transmissions unreliable.  This matches
the use case of an IoT LLN where RPL is typically used today, but
also situations of high relative mobility between the nodes in the
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 minimize the control
plane activity, that is the relative amount of routing protocol
exchanges vs. data traffic, and the amount of state that is
maintained in each node.  RPL does not need converge, and provides
connectivity to most nodes most of the time.
RPL is optimized for situations where the power is scarce, the
bandwidth is constrained and the transmissions are unreliable.  This
matches the use case of an IoT LLN where RPL is typically used today,
but also situations of high relative mobility between the nodes in
the 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 minimize the control
plane activity, that is the relative amount of routing protocol
exchanges vs. data traffic, and the amount of state that is
maintained in each node.  RPL does not need to converge, and provides
connectivity to most nodes most of the time.
RPL instances operate as ships passing in the night, unbeknownst of
one another.  The RPL Root is responsible to select the RPL Instance
that is used to forward a packet coming from the Backbone into the
RPL domain and set the related RPL information in the packets. 6TiSCH
leverages RPL for its distributed routing operations.
RPL instances operate as ships passing in the night, unbeknownst of
one another.  The RPL Root is responsible for selecting the RPL
Instance that is used to forward a packet coming from the Backbone
into the RPL domain and for setting the related RPL information in
the packets. 6TiSCH leverages RPL for its distributed routing
operations.
RPL first forms a default route in each node towards the a Root, and
those routes together coalesce as a Directed Acyclic Graph upwards.
RPL then constructs routes to destinations signaled as Targets in the
reverse direction, down the same DODAG.  So do so, a RPL Instance can
be operated either in RPL Storing or Non-Storing Mode of Operation
(MOP).  The default route towards the Root is maintained aggressively
and may change while a packet progresses without causing loops, so
the packet will still reach the Root.
RPL first forms a default route in each node towards the Root, and
those routes together coalesce as a Directed Acyclic Graph upwards.
RPL then constructs routes to destinations signaled as Targets in the
reverse direction, down the same DODAG.  So do so, a RPL Instance can
be operated either in RPL Storing or Non-Storing Mode of Operation
(MOP).  The default route towards the Root is maintained aggressively
and may change while a packet progresses without causing loops, so
the packet will still reach the Root.
In Non-Storing Mode, each node advertises itself as a Target directly
to the Root, indicating the parents that may be used to reach self.
Recursively, the Root builds and maintains an image of the whole
DODAG in memory, and leverages that abstraction to compute source
route paths for the packets to their destinations down the DODAG.
When a node changes its point(s) of attachment to the DODAG, it takes
single unicast packet to the Root along the default route to 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 the nodes.
In Non-Storing Mode, each node advertises itself as a Target directly
to the Root, indicating the parents that may be used to reach itself.
Recursively, the Root builds and maintains an image of the whole
DODAG in memory, and leverages that abstraction to compute source
route paths for the packets to their destinations down the DODAG.
When a node changes its point(s) of attachment to the DODAG, it takes
a single unicast packet to the Root along the default route to update
it, and the connectivity 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 the nodes.
In Storing Mode, the routing information percolates upwards, and each
node maintains the routes to the subDAG of its descendants down the
DODAG.  The maintenance is lazy, either reactive upon traffic or as a
slow background process.  Packets flow via the common parent and the
routing stretch is reduced vs. Non-Storing, for a better P2P
connectivity.  On the other hand, a new route takes a longer time to
propagate to the Root, time for the Distance-Vector protocol to
operate hop-by-hop, and the Internet connectivity is restored more
slowly upon movement.
Either way, the RPL routes are injected by the Target nodes, in a
distributed fashion.  To complement RPL and eliminate routing
stretch, this specification introduces an hybrid mode that combines
Storing and Non-Storing operations to build and project routes onto
the nodes where they should be installed.  This specification uses
the term Projected Route (P-Route) to refer to those routes.
A P-Route may be installed in either Storing and Non-Storing Mode,
potentially resulting in hybrid situations where the Mode of the P-
Route is different from that of the RPL Main DODAG.  P-Routes can be
used as stand-alone segments to reduce the size of the source routing
headers with loose source routing operations down the main RPL DODAG.
P-Routes can also be combined with other P-Routes to form a more
complex forwarding graph called a Track.
In Storing Mode, the routing information percolates upwards, and each
node maintains the routes to the subDAG of its descendants down the
DODAG.  The maintenance is lazy, either reactive upon traffic or as a
slow background process.  Packets flow via the common parent and the
routing stretch is reduced vs. Non-Storing, for better P2P
connectivity.  On the other hand, a new route takes a longer time to
propagate to the Root, since it takes time for the Distance-Vector
protocol to operate hop-by-hop, and the Internet connectivity is
restored more slowly upon movement.
Either way, the RPL routes are injected by the Target nodes, in a
distributed fashion.  To complement RPL and eliminate routing
stretch, this specification introduces a hybrid mode that combines
Storing and Non-Storing operations to build and project routes onto
the nodes where they should be installed.  This specification uses
the term Projected Route (P-Route) to refer to those routes.
A P-Route may be installed in either Storing and Non-Storing Mode,
potentially resulting in hybrid situations where the Mode of the
P-Route is different from that of the RPL Main DODAG.  P-Routes can
be used as stand-alone segments to reduce the size of the source
routing headers with loose source routing operations down the main
RPL DODAG.  P-Routes can also be combined with other P-Routes to form
a more complex forwarding graph called a Track.
Based on the parent-children relationships expressed in the Non-
Storing DAO messages, the Root possesses topological information
about the whole network, though this information is limited to the
structure of the DODAG for which it is the destination.  A packet
that is generated within the domain will always reach the Root, which
can then apply a source routing information to reach the destination
if the destination is also in the DODAG.  Similarly, a packet coming
from the outside of the domain for a destination that is expected to
be in a RPL domain reaches the Root.  It results that the wireless
bandwidth near the Root is the gating factor for all transmissions
towards or within the domain, and that the Root is a single point of
failure for all connectivity to nodes within its domain.
The RPL Root must add a source routing header to all downward
packets.  As a network grows, the size of the source routing header
augments with the depth of the nodes.  In some use cases, a RPL
network forms long lines along physical structures such as streets
for lighting.  Limiting the packet size is directly beneficial to the
energy budget, but, mostly, it reduces the chances of frame loss and
packet fragmentation, which are highly detrimental to the LLN
operation.  A limited amount of well-targeted routing state would
allow the source routing operation to be loose as opposed to strict,
and save packet size.  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.
Being on path for all packets in Non-Storing mode, the Root may
determine the number of P2P packets in its RPL domain per source and
destination, the latency incurred, and the amount of energy and
bandwidth that is consumed to reach the self and then down, including
a possible fragmentation when encapsulating larger packets.  Enabling
a shorter path that would not traverse the Root for select P2P
source/destinations may improve the latency, lower the consumption of
constrained resources, free bandwidth at the bottleneck near the
Root, improve the delivery ratio and reduce the latency for those P2P
flows with a global benefit for all flows of reducing the load at the
Root.
This requirement is to store a routing state associated with the Main
DODAG in selected RPL routers, to limit the excursion of the source
route headers in deep networks.  The Root may elide the sequence of
routers that is installed in the network from its source route
header, which becomes loose while it is strict in RFC6550.
Based on the parent-children relationships expressed in the Non-
Storing DAO messages, the Root possesses topological information
about the whole network, though this information is limited to the
structure of the DODAG for which it is the destination.  A packet
that is generated within the domain will always reach the Root, which
can then apply a source routing information to reach the destination
if the destination is also in the DODAG.  Similarly, a packet coming
from the outside of the domain for a destination that is expected to
be in a RPL domain reaches the Root.  This results in the wireless
bandwidth near the Root being the limiting factor for all
transmissions towards or within the domain, and that the Root is a
single point of failure for all connectivity to nodes within its
domain.
The RPL Root must add a source routing header to all downward
packets.  As a network grows, the size of the source routing header
increases with the depth of the network.  In some use cases, a RPL
network forms long lines along physical structures such as streets
for lighting.  Limiting the packet size is directly beneficial to the
energy budget, but, mostly, it reduces the chances of frame loss and
packet fragmentation, which are highly detrimental to the LLN
operation.  A limited amount of well-targeted routing state would
allow the source routing operation to be loose as opposed to strict,
and reduce the overhead of routing information in packets.  Because
the capability to store routing state in every node is limited, the
decision of which route is installed where can only be optimized with
global knowledge of the system, knowledge that the Root or an
associated PCE may possess by means that are outside the scope of
this specification.
Being on-path for all packets in Non-Storing mode, the Root may
determine the number of P2P packets in its RPL domain per source and
destination, the latency incurred, and the amount of energy and
bandwidth that is consumed to reach itself and then back down,
including possible fragmentation when encapsulating larger packets.
Enabling a shorter path that would not traverse the Root for select
P2P source/destinations may improve the latency, lower the
consumption of constrained resources, free bandwidth at the
bottleneck near the Root, improve the delivery ratio and reduce the
latency for those P2P flows with a global benefit for all flows by
reducing the load at the Root.
This requirement is to store a routing state associated with the Main
DODAG in select RPL routers, in order to limit the need for source
route headers in deep networks.  The Root may elide the sequence of
routers that is installed in the network from its source route
header, which therefore becomes loose, in contrast to being strict in
RFC6550.
It results that it is often beneficial to enable 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 RFC6997, which specifies a
distributed method for establishing optimized P2P routes.  This draft
proposes an alternate based on a centralized route computation.
It turns out that it is often beneficial to enable East-West P2P
routes, either if the RPL route presents a stretch from the shortest
path, or if the new route is engineered with a different objective,
and this is even more critical in Non-Storing Mode than it is in
Storing Mode, because the routing stretch is wider.  For that reason,
earlier work at the IETF introduced the RFC6997, which specifies a
distributed method for establishing optimized P2P routes.  This draft
proposes an alternative based on centralized route computation.
A Serial Track comprises provides only one path between Ingress and
Egress.  It comprises at most one Leg. A Stand-Alone Segment
implicitly defines a Serial Track from its Ingress to Egress.
A Serial Track provides only one path between Ingress and Egress.  It
comprises at most one Leg. A Stand-Alone Segment implicitly defines a
Serial Track from its Ingress to Egress.
A Track is normally associated with a Local RPL Instance which
RPLInstanceID is used as the TrackID, more in trkid.  A Track Leg may
also be used as a subTrack that extends the RPL main DODAG.  In that
case, the TrackID is set to the global RPLInstanceID of the main
DODAG, which suffices to identify the routing topology.  As opposed
to local RPL instances, the Track Ingress that encapsulates the
packets over a subtrack is not Root, and that the source address of
the encapsulated packet is not used to determine the Track.
A Track is normally associated with a Local RPL Instance wherein the
RPLInstanceID is used as the TrackID (more in trkid).  A Track Leg
may also be used as a subTrack that extends the RPL main DODAG.  In
that case, the TrackID is set to the global RPLInstanceID of the main
DODAG, which suffices to identify the routing topology.  As opposed
to local RPL instances, the Track Ingress that encapsulates the
packets over a subtrack is not Root, and that the source address of
the encapsulated packet is not used to determine the Track.
This specification enables to set up a P-Route along either a Track
Leg or a Segment.  A P-Route is installed and maintained by the Root
of the main DODAG using an extended RPL DAO message called a
Projected DAO (P-DAO), and a Track is composed of the combination of
one or more P-Routes.
This specification enables setting up a P-Route along either a Track
Leg or a Segment.  A P-Route is installed and maintained by the Root
of the main DODAG using an extended RPL DAO message called a
Projected DAO (P-DAO), and a Track is composed of the combination of
one or more P-Routes.
This specification introduces the Via Information Option (VIO) to
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 Target Options that signal the destination IPv6 addresses
that can reached along the Track, more in vio.
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.  This simple
example illustrates the case of host routes, though RPL Targets can
be prefixes.
This specification introduces the Via Information Option (VIO) to
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 message contains a single VIO, associated to one or
more RPL Target Options that signal the destination IPv6 addresses
that can reached along the Track (more in vio).
Before diving deeper into Track Legs and Segments signaling and
operation, this section provides examples of how route projection
works through variations of a simple example.  This simple example
illustrates the case of host routes, though RPL Targets can also be
prefixes.
Conventionally we use ==> to represent a strict hop and --> for a
loose hop.  We use "-to-", such as in C==>D==>E-to-F to represent
coma-separated Targets, e.g., F is a Target for Segment C==>D==>E.
In this example, A is Track Ingress, E is Track Egress.  C is a
stitching point.  F and G are "external" Targets for the Track, and
become reachable from A via the Track A(ingress) to E (Egress and
implicit Target in Non-Storing Mode) leading to F and G (explicit
Targets).
rpid depicts the format of the RPLInstanceID encoding for a local
RPLInstanceID .
Conventionally we use ==> to represent a strict hop and --> for a
loose hop.  We use "-to-", such as in C==>D==>E-to-F to represent
coma-separated Targets, e.g., F is a Target for Segment C==>D==>E.
In this example, A is the Track Ingress and E is the Track Egress.  C
is a stitching point.  F and G are "external" Targets for the Track,
and become reachable from A via the Track A (Ingress) to E (Egress
and implicit Target in Non-Storing Mode) leading to F and G (explicit
Targets).
rpid depicts the format of the RPLInstanceID encoding for a local
RPLInstanceID.
Loose sequences of hops must be expressed in Non-Storing Mode, so
P-DAO 3 contains a NSM-VIO.  With this specification, the DODAGID to
be used by the Ingress as source address is signaled if needed in the
DAO base object, the via list starts at the first loose hop and
matches the source route header, and the Egress of a Non-Storing Mode
P-DAO is an implicit Target that is not listed in the RTO.
A==>B==>C and C==>D==>E are segments of a same Track.  Note that the
Storing Mode signaling imposes strict continuity in a segment, since
the P-DAO is passed hop by hop, as a classical DAO is, along the
reverse datapath that it signals.  One benefit of strict routing is
that loops are avoided along the Track.
Loose sequences of hops must be expressed in Non-Storing Mode, so
P-DAO 3 contains a NSM-VIO.  With this specification, the DODAGID to
be used by the Ingress as source address is signaled if needed in the
DAO base object, the via list starts at the first loose hop and
matches the source route header, and the Egress of a Non-Storing Mode
P-DAO is an implicit Target that is not listed in the RPL Target
Options.
A==>B==>C and C==>D==>E are segments of the same Track.  Note that
the Storing Mode signaling imposes strict continuity in a segment,
since the P-DAO is passed hop by hop, as a classical DAO is, along
the reverse datapath that it signals.  One benefit of strict routing
is that loops are avoided along the Track.
In this example, we consider F and G as destinations that are
external to the Track as a DODAG, as discussed in section 4.1.1. of
RFC9008.  We then apply the directives for encapsulating in that
case, more in routing.
In this example, we consider F and G as destinations that are
external to the Track as a DODAG, as discussed in section 4.1.1. of
RFC9008.  We then apply the directives for encapsulating in that case
(more in routing).
To increase the reliability of the P2P transmission, this
specification enables to build a collection of Legs between the same
Ingress and Egress Nodes and combine them with the same TrackID, as
shown in FigLegs.  Legs may cross at the edges of loose hops or
remain parallel.
To increase the reliability of the P2P transmission, this
specification enables building a collection of Legs between the same
Ingress and Egress Nodes and combining them within the same TrackID,
as shown in FigLegs.  Legs may cross at the edges of loose hops or
remain parallel.
The algorithm to compute the paths and the protocol used by the PCE
and the metrics and link statistics involved in the computation are
also out of scope.  The effectiveness of the route computation by the
PCE depends on the quality of the metrics that are reported from the
RPL network.  Which metrics are used and how they are reported is out
of scope, but the expectation is that they are mostly of long-term,
statistical nature, and provide visibility on link throughput,
latency, stability and availability over relatively long periods.
The algorithm to compute the paths and the protocol used by the PCE
and the metrics and link statistics involved in the computation are
also out of scope.  The effectiveness of the route computation by the
PCE depends on the quality of the metrics that are reported from the
RPL network.  Which metrics are used and how they are reported is out
of scope, but the expectation is that they are mostly of a long-term,
statistical nature, and provide visibility on link throughput,
latency, stability and availability over relatively long periods.
The RAW Architecture defines a dataplane extension of the PCE called
the Path Selection Engine (PSE), that adapts the use of the path
redundancy within a Track to defeat the diverse causes of packet
loss.  The PSE controls the forwarding operation of the packets
within a Track This specification can use but does not impose a PSE
and does not provide the policies that wouldselect which packets are
routed through which path within a Track, IOW, how the PSE may use
the path redundancy within the Track.  By default, the use of the
available redundancy is limited to simple load balancing, and all the
segments are East-West unidirectional only.
The RAW Architecture defines a dataplane extension of the PCE called
the Path Selection Engine (PSE), that adapts the use of the path
redundancy within a Track to defeat the diverse causes of packet
loss.  The PSE controls the forwarding operation of the packets
within a Track.  This specification can use but does not impose a PSE
and does not provide the policies that would select which packets are
routed through which path within a Track, in other words, how the PSE
may use the path redundancy within the Track.  By default, the use of
the available redundancy is limited to simple load balancing, and all
the segments are East-West unidirectional only.
This section explains which changes are extensions to existing
specifications, and which changes are amendments to existing
specification.  It is expected that extensions to existing
specifications do not cause existing code on legacy 6LRs to
malfunction, as the extensions will simply be ignored.  New code is
required for an extension.  Those 6LRs will be unable to participate
in the new mechanisms, but may also cause projected DAOs to be
impossible to install.  Amendments to existing specifications are
situations where there are semantic changes required to existing
code, and which may require new unit tests to confirm that legacy
operations will continue unaffected.
This section explains which changes are extensions to existing
specifications, and which changes are amendments to existing
specifications.  It is expected that extensions to existing
specifications do not cause existing code on legacy 6LRs to
malfunction, as the extensions will simply be ignored.  New code is
required for an extension.  Those 6LRs will be unable to participate
in the new mechanisms, but may also cause projected DAOs to be
impossible to install.  Amendments to existing specifications are
situations where there are semantic changes required to existing
code, and which may require new unit tests to confirm that legacy
operations will continue unaffected.
The new P-DAO Request (PDR) is a new message detailed in P-DAOreq.
As per RFC6550 section 6, if a node receives this message and it does
not understand this new Code, then discards the message.  When the
root initiates to a node that it has not communicated with before,
and to which it does not know if this specification has been
implemented (by means such as capabilities), then the root SHOULD
request a PDR-ACK.
The new P-DAO Request (PDR) is a new message detailed in P-DAOreq.
As per RFC6550 section 6, if a node receives this message and it does
not understand this new Code, it then discards the message.  When the
root initiates to a node that it has not communicated with before,
and to which it does not know if this specification has been
implemented (by means such as capabilities), then the root SHOULD
request a PDR-ACK.
The Root MUST source the P-DAO message with its address that serves
as DODAGID for the main DODAG.  The receiver MUST NOT accept a P-DAO
message that is not sent by the Root of its DODAG and MUST ignore
such message silently.
The Root MUST source the P-DAO message with its address that serves
as DODAGID for the main DODAG.  The receiver MUST NOT accept a P-DAO
message that is not sent by the Root of its DODAG and MUST ignore
such messages silently.
The P-DAO is control plane signaling and should not be stuck behind
high traffic levels.  The expectation is that the P-DAO message is
sent as high QoS level, above that of data traffic, typically with
the Network Control precedence.
The P-DAO is a part of control plane signaling and should not be
stuck behind high traffic levels.  The expectation is that the P-DAO
message is sent at high QoS level, above that of data traffic,
typically with the Network Control precedence.
This document Extends the CMO to create new objects called the Via
Information Options (VIO).  The VIOs are the multihop alternative to
the TIO, more in vio.  One VIO is the stateful Storing Mode VIO (SM-
VIO); an SM-VIO installs a strict hop-by-hop P-Route called a Track
Segment.  The other is the Non-Storing Mode VIO (NSM-VIO); the NSM-
VIO installs a loose source-routed P-Route called a Track Leg at the
Track Ingress, which uses that state to encapsulate a packet
IPv6_in_IPv6 with a new Routing Header (RH) to the Track Egress, more
in routing.
A P-DAO contains one or more RTOs to indicate the Target
(destinations) that can be reached via the P-Route, followed by
exactly one VIO that signals the sequence of nodes to be followed,
more in P-DAO.  There are two modes of operation for the P-Routes,
the Storing Mode and the Non-Storing Mode, see sP-DAO and nsP-DAO
respectively for more.
This document Extends the CMO to create new objects called the Via
Information Options (VIO).  The VIOs are the multihop alternative to
the TIO (more in vio).  One VIO is the stateful Storing Mode VIO (SM-
VIO); an SM-VIO installs a strict hop-by-hop P-Route called a Track
Segment.  The other is the Non-Storing Mode VIO (NSM-VIO); the NSM-
VIO installs a loose source-routed P-Route called a Track Leg at the
Track Ingress, which uses that state to encapsulate a packet
IPv6_in_IPv6 with a new Routing Header (RH) to the Track Egress (more
in routing).
A P-DAO contains one or more RTOs to indicate the Target
(destinations) that can be reached via the P-Route, followed by
exactly one VIO that signals the sequence of nodes to be followed
(more in P-DAO).  There are two modes of operation for the P-Routes,
the Storing Mode and the Non-Storing Mode, see sP-DAO and nsP-DAO
respectively for more.
This specification Extends the CMO to create the Sibling Information
Option (SIO).  The SIO is used by a RPL Aware Node (RAN) to advertise
a selection of its candidate neighbors as siblings to the Root, more
in rplsib.  The SIO is placed in DAO messages that are sent directly
to the Root of the main DODAG.
This specification Extends the CMO to create the Sibling Information
Option (SIO).  The SIO is used by a RPL Aware Node (RAN) to advertise
a selection of its candidate neighbors as siblings to the Root (more
in rplsib).  The SIO is placed in DAO messages that are sent directly
to the Root of the main DODAG.
RFC6553describes the RPL Option for use among RPL routers to include
the abstract RPL Packet Information (RPI) described in section 11.2.
of RFC6550 in data packets.
RFC6553 describes the RPL Option for use among RPL routers to include
the abstract RPL Packet Information (RPI) described in section 11.2.
of RFC6550 in data packets.
encompression details how a a Track Ingress leverages the P-RPI-6LoRH
Header as part of the encapsulation of a packet to place it into a
Track.
encompression details how a Track Ingress leverages the P-RPI-6LoRH
Header as part of the encapsulation of a packet to place it into a
Track.
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, and signals whether an acknowledgment
called PDR-ACK is requested or not.  A positive PDR-ACK indicates
that the Track was built and that the Roots commits to maintain the
Track for the negotiated lifetime.
The main Root MAY indicate to the Track Ingress that the Track was
terminated before its time and to do so, it MUST uses an asynchronous
PDR-ACK with an negative status.  A status of "Transient Failure"
(see iana-stats-rej) is an indication that the PDR may be retried
after a reasonable time that depends on the deployment.  Other
negative status values indicate a permanent error; the tentative must
be abandoned until a corrective action is taken at the application
layer or through network management.
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, and signals whether an acknowledgment
called PDR-ACK is requested or not.  A positive PDR-ACK indicates
that the Track was built and that the Root commits to maintaining the
Track for the negotiated lifetime.
The main Root MAY indicate to the Track Ingress that the Track was
terminated before its time and to do so, it MUST use an asynchronous
PDR-ACK with a negative status.  A status of "Transient Failure" (see
iana-stats-rej) is an indication that the PDR may be retried after a
reasonable time that depends on the deployment.  Other negative
status values indicate a permanent error; the attempt must be
abandoned until a corrective action is taken at the application layer
or through network management.
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.  At least one RPL Target Option MUST be present in the
message.  If more than one RPL Target Option is present, the Root
will provide a Track that reaches the first listed Target and a
subset of the other Targets; the details of the subset selection are
out of scope.  The RTO signals the Track Egress, more in req.
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.  At least one RPL Target Option MUST be present in the
message.  If more than one RPL Target Option is present, the Root
will provide a Track that reaches the first listed Target and a
subset of the other Targets; the details of the subset selection are
out of scope.  The RTO signals the Track Egress (more in req).
A VIO signals the ordered list of IPv6 Via Addresses that constitutes
the hops of either a Leg (using Non-Storing Mode) or a Segment (using
Storing mode) of a Track.  A Storing Mode P-DAO contains one Storing
Mode VIO (SM-VIO) whereas a Non-Storing Mode P-DAO contains one Non-
Storing Mode VIO (NSM-VIO).
In the case of a SM-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 forall the
addresses, as shown in viao, for simplicity.
In case of an NSM-VIO and 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 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, with the
B flag set, and the Root will assume symmetry.
The SIO carries a flag (B) that is set when similar performances can
be expected both directions, so the routing can consider that the
information provided for one direction is valid for both.  If the SIO
is effectively received from both sides then the B flag MUST be
ignored.  The policy that describes the performance criteria, and how
they are asserted is out of scope.  In the absence of an external
protocol to assert the link quality, the flag SHOULD NOT be set.
In the case of a SM-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 viao, for simplicity.
In case of an NSM-VIO and 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 would make the VIO globally shorter; this means that more
than one SRH-6LoRH may be present.
The Sibling Information Option (SIO) provides information about
siblings that could be used by the Root to form P-Routes.  One or
more SIO(s) 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 to report the SIO, with
the B flag set, and the Root will assume symmetry.
The SIO carries a flag (B) that is set when similar performance can
be expected in both directions, so the routing can consider that the
information provided for one direction is valid for both.  If the SIO
is effectively received from both sides then the B flag MUST be
ignored.  The policy that describes the performance criteria, and how
they are asserted is out of scope.  In the absence of an external
protocol to assert the link quality, the flag SHOULD NOT be set.
To avoid the need of Path MTU Discovery, 6LoWPAN links are normally
defined with a MTU of 1280 (see section 4 of RFC4944).  Injecting
packets in a Track typically involves an IP-in-IP encapsulation and
additional IPv6 Extension Headers.  This may cause a fragmentation if
the resulting packets exceeds the MTU that is defined for the RPL
domain.
Though fragmentation is possible in a 6LoWPAN LLN, e.g., using
RFC4944, 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.
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 trkid.
To avoid the need of Path MTU Discovery, 6LoWPAN links are normally
defined with a MTU of 1280 (see section 4 of RFC4944).  Injecting
packets in a Track typically involves an IP-in-IP encapsulation and
additional IPv6 Extension Headers.  This may cause fragmentation if
the resulting packets exceeds the MTU that is defined for the RPL
domain.
Though fragmentation is possible in a 6LoWPAN LLN, e.g., using
RFC4944, RFC8930, and/or RFC8931, it is RECOMMENDED to allow an MTU
that is larger than 1280 in the main DODAG and which allows for the
additional headers while exposing only 1280 to the 6LoWPAN Nodes.
This specification introduces the PDR message, used by an LLN node to
request the formation of a new Track for which this node is the
Ingress.  Note that the namespace for the TrackID is owned by the
Ingress node, and in the absence of a PDR, there must be some
procedure for the Root to assign TrackIDs in that namespace while
avoiding collisions (more in trkid).
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
iana-stats-rpl-rej.
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.
A node that processes a VIO MAY verify whether any of these
conditions happen, and when one does, it MUST ignore the P-DAO and
reject it with a RPL Rejection Status of "Error in VIO" in the DAO-
ACK, see iana-stats-rpl-rej.
Other errors than those discussed explicitly that prevent the
installation of the route are acknowledged with a RPL Rejection
Status of "Unqualified Rejection" in the DAO-ACK.
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.
The process continues until 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.
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 ICMPv6ErrPRoute).  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 maintain).
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 RFC6550.  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.
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 ICMPv6ErrPRoute).  The Root can then repair by
updating the broken Segment and/or Tracks, and in the case of a
broken Segment, remove the leftover sections of the segment using SM-
VIOs with a lifetime of 0 indicating the section to one or more nodes
being removed (See maintain).
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 RFC6550.  Upon receiving this
message, the encapsulating node SHOULD stop using the source route
path for a reasonable period of time which 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.
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 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 just like as Non-Storing
DAO messages are.
The I-D.ietf-raw-architecture 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 Service Level
Objective (SLO).
This section specifies the additions that are needed to turn the
Track into a full DODAG and enable the main Root to provide the
necessary topological information to the Track Ingress.  The
expectation is that the metrics that the PSE uses are of an order
other than that of the PCE, because of the difference of time scale
between routing and forwarding, mor e in I-D.ietf-raw-architecture.
It follows that the PSE will learn the metrics it needs from an
alternate source, e.g., OAM frames.
The I-D.ietf-raw-architecture 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 needs the full richness of a
DODAG to form any path that could meet the Service Level Objective
(SLO).
This section specifies the additions that are needed to turn the
Track into a full DODAG and enable the main Root to provide the
necessary topological information to the Track Ingress.  The
expectation is that the metrics that the PSE uses are of an order
other than that of the PCE, because of the difference of time scale
between routing and forwarding, more in I-D.ietf-raw-architecture.
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 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 destination, and can
report information on many Targets, possibly the full Track, with one
P-DAO.
To pass the topological information to the Ingress, the Root uses a
P-DAO messages that contains sequences of Target and Transit
Information options that collectively represent the Track, expressed
in the same fashion as in classical Non-Storing Mode.  The difference
is that the Root is the source as opposed to the destination, and can
report information on many Targets, possibly the full Track, with one
P-DAO.
This document provides a set of tools that may or may not be needed
by an implementation depending on the type of application it serves.
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
portion of this specification to meet a particular use case.
This document provides a set of tools that may or may not be needed
by an implementation depending on the type of application it serves.
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 implementing only a
portion of this specification to meet a particular use case.
Profiles 0 and 1 are REQUIRED by all implementations that may be used
in LLNs; Profiles 1 leverages Storing Mode to reduce the size of the
Source Route Header in the most common LLN deployments.  Profile 2 is
RECOMMENDED in high speed / wired environment to enable traffic
Engineering and network automation.  All the other profile /
environment combinations are OPTIONAL.
Profiles 0 and 1 are REQUIRED by all implementations that may be used
in LLNs; Profile 1 leverages Storing Mode to reduce the size of the
Source Route Header in the most common LLN deployments.  Profile 2 is
RECOMMENDED in high speed / wired environment to enable traffic
Engineering and network automation.  All the other profile /
environment combinations are OPTIONAL.
This specification can operate in a mixed network where some nodes
support it and some do not.  There are restructions, though.  All
nodes that need to process a P-DAO MUST support this specification.
As discussed in mtsch, how the root knows whether the nodes
capabilities and whether it support this specification is out of
scope.
This specification defines the 'D' flag in the RPL DODAG
Configuration Option (see dflag) to signal that the RPL nodes can
request the creation of Tracks.  The requester may not know whether
the Track can effectively be constructed, and whether enough nodes
along the preferred paths support this specification.  Therefore it
makes sense to only set the 'D' flags in DIO when the conditions of
success are in place, in particular when all the nodes that could be
on path of tracks are upgraded.
This specification can operate in a mixed network where some nodes
support it and some do not.  There are restrictions, though.  All
nodes that need to process a P-DAO MUST support this specification.
As discussed in mtsch, how the root knows the node capabilities and
whether they support this specification is out of scope.
This specification defines the 'D' flag in the RPL DODAG
Configuration Option (see dflag) to signal that the RPL nodes can
request the creation of Tracks.  The requester may not know whether
the Track can effectively be constructed, and whether enough nodes
along the preferred paths support this specification.  Therefore, it
makes sense to only set the 'D' flags in the DIO when the conditions
of success are in place, in particular when all the nodes that could
be on the path of tracks are upgraded.
In a general manner, the Security Considerations in RFC6550, 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.
With this specification, only the Root may generate P-DAO messages.
PDR messages may only be sent to the Root.  This specification
expects that the communication with the Root is authenticated but
does enforce which method is used.
In a general manner, the Security Considerations in RFC6550, 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
injecting forged P-DAO messages and using up all the available
storage in the attacked routers.
With this specification, only the Root may generate P-DAO messages.
PDR messages may only be sent to the Root.  This specification
expects that the communication with the Root is authenticated but
does not enforce which method is used.