Draft: draft-ietf-roll-dao-projection

Commentary: Many Thanks  ! I 'll be responding on the ROLL ML : )
A Track that can be traverse via more than one path (e.g., a DODAG).
A Track that can be traversed via more than one path (e.g., a DODAG).
Each NSM-VIO for the same TrackId but a different Segment ID signals
a different leg that the Track Ingress adds to the topology.
Each NSM-VIO for the same TrackId but with a different Segment ID
signals a different leg that the Track Ingress adds to the topology.
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.
RPL first forms a default route in each node towards the Root, and
those routes together coalesce as a Directed Acyclic Graph oriented
upwards.  RPL then constructs routes to destinations signaled as
Targets in the reverse direction, down the same DODAG.  To do so, a
RPL Instance can be operated either in 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 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.
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 compared to Non-Storing MOP, for better
P2P connectivity.  However, a new route takes a longer time to
propagate to the Root, since it takes time for the Distance-Vector
protocol to operate hop-by-hop, and the Internet connectivity is
restored more slowly upon node movement.
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 operates in 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 Track that are local instances
overlaid on an existing main RPL Instance.
A P-Route may be installed in either Storing and Non-Storing Mode,
potentially resulting in hybrid situations where the Mode in which
the P-Route operates is different from that of the RPL Main Instance.
P-Routes can be used as stand-alone segments meant to reduce the size
of the source routing headers, thanks to loose source routing
operations down the main RPL DODAG.  P-Routes can also be combined
with other P-Routes to form a more complex Track, consisting of local
instances overlaid on an existing main RPL Instance.
A Track Leg may also be used as an alternative to a Segment in the
RPL main DODAG, causing an extra encapsulation to signal a source
route path between loose hops in the encapsulated source routing
header.  In that case, the TrackID in the outer header remains that
of 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 the Track Leg is not a
Root of the instance, and that the source address of the encapsulated
packet is not used to determine the Track.
A Track Leg may also be used as an alternative to a Segment in the
RPL main DODAG, causing an extra encapsulation to signal a source-
routed path between loose hops in the encapsulated source routing
header.  In that case, the TrackID in the outer header remains that
of 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 the Track Leg is
not a Root of the instance, and the source address of the
encapsulated packet is not used to determine the Track.
Note well: by design, the list of nodes in a VIO in Non-Storing Mode
is exactly the list that shows in the encapsulation SRH.  So in the
cases detailed below, if the Mode of the P-DAO is Non-Storing, then
the VIO row can be read as indicating the SRH as well.
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 algorithm to compute the paths, 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.
This specification Extends RPL RFC6550 to enable the Root to install
East-West routes inside a Main DODAG that is operated as Non-Storing
Mode.  The Root issues a Projected DAO (P-DAO) message (see extP-DAO)
to the Track Ingress; the P-DAO message contains a new Via
Information Option (VIO) that installs a strict or a loose sequence
of hops to form respectively a Track Segment or a Track Leg.
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.
This specification Extends RPL RFC6550 to enable the Root to install
East-West routes inside a Main DODAG that is operated as Non-Storing
Mode.  The Root issues a Projected DAO (P-DAO) message (see extP-DAO)
to the Track Ingress; the P-DAO message contains a new Via
Information Option (VIO) that installs a strict or a loose sequence
of hops to form a Track Segment or a Track Leg, respectively.
The 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
which it has not ascertained to implement this specification (by
means such as capabilities), then the Root SHOULD request a PDR-ACK.
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 Root sends the P-DAO directly to the Egress node of the Segment.
In that P-DAO, the destination IP address matches the last Via
Address in the SM-VIO.  This is how the Egress recognizes its role.
In a similar fashion, the Segment Ingress node recognizes its role
because it matches the first Via Address in the SM-VIO.
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.
The address of the predecessor to be used as destination of the
propagated DAO message is found in the Via Address list, at the
position preceeding the one that contains 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.
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.
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 appear in the SM-VIO
after its own address, if any, but in case of a conflict or a lack of
resource, the route(s) to the Target(s) are the ones that must be
installed in priority.
The process continues until the P-DAO is propagated to the Ingress
router of the Segment, which answers with a DAO-ACK to the Root.  The
Root always expects a DAO-ACK, either from the Track Ingress with a
positive status or from any node along the segment with a negative
status.  If the DAO-ACK is not received, the Root may retry the DAO
with the same TID, or tear down the route.
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.
To modify a section of a Segment between a first node and a second,
downstream node (which can be the Ingress and Egress, respectively),
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.
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 teardown.
After a reasonable time to enable the deprecated sections to drain
their traffic, the Root tears down the remaining section(s) of the
old segments as described in teardown.
This specification allows the Root 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 becoming excessively lossy,
and switch to the new Leg before removing the old.  Dropping a Track
before the new one is installed would reroute the traffic via the
root; this may augment the latency beyond acceptable thresholds, and
load the network near the root.  This may also cause loops in the
case of stitched Tracks; the packets that cannot be injected in the
second Track may be routed back at reinjected at the Ingress of the
first.
This specification allows the Root 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 becoming excessively lossy,
and switch to the new Leg before removing the old.  Dropping a Track
before the new one is installed would reroute the traffic via the
root; this may increase the latency beyond acceptable thresholds, and
overload the network near the root.  This may also cause loops in the
case of stitched Tracks: the packets that cannot be injected in the
second Track might be routed back and reinjected at the Ingress of
the first.
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 teardown.
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 drain their
traffic, the Root tears down those Segments as described in teardown.
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 inner from the second octet on.
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 starts with the SRH-6LoRH, and
is exactly the packet represented in inner, from the second octet
onward.
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.
On the other hand, since RPL is a Layer-3 routing protocol, its
applicability extends beyond LLNs to a generic IP network.  RPL
requires less resources 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 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.
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 Non-Storing DAO
messages are.
Note that the Path Sequence and Lifetime in the TIO are selected by
the Root, and that the Target/Transit information tupples in the
P-DAO are not those received by the Root in the DAO messages about
the said Targets.  The Track may follow sibling routes and does not
need to be congruent with the Main DODAG.
Note that the Path Sequence and Lifetime in the TIO are selected by
the Root, and that the Target/Transit information tuples in the P-DAO
are not those received by the Root in the DAO messages about the said
Targets.  The Track may follow sibling routes and does not need to be
congruent with the Main DODAG.