Draft: draft-ietf-roll-dao-projection

Commentary: Many thanks  ! This is now in . I realize that I never accepted Rahul 's pull request ! ! ! Let me have a look asap . Keep safe ;   jeu . 18 nov . 2021 à 00:50 ,   écrit :
RPL instances operate as ships 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 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 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 so-called 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 a Root, and
those routes together coalesce as a Directed Acyclic Graph upwards.
RPL then constructs routes to so-called 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.
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 P-Route to refer to those routes.
Either way, the RPL routes are injected by the Target nodes, in a
distributed fashion.  To complement RPL and eliminate routing
stretch, this specification 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.
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 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.
It results that the Root, or then some associated centralized
computation engine such as a PCE, can determine the number of packets
that reach a destination in the RPL domain.  Based upon this metric
the amount of energy and bandwidth that is wasted on 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).
The RPL root must add a source routing header to all downward
packets.  As a network gets deep, the size of this header 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
routing state would allow the source routing operation to be 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.
A Serial Track 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 Egress.
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.
The concept of a Track was introduced in the RFC9030, as a collection
of potential paths that leverage redundant forwarding solutions along
the way.  With this specification, a Track forms DODAG that is
directed towards a Track Ingress.  If there is a single Track Egress,
then the Track is reversible to form another DODAG by reversing the
direction of each edge.  A node at the Ingress of more than one
Segment in a Track may use one or more of these Segments to forward a
packet inside the Track.
The concept of a Track was introduced in the RFC9030, as a collection
of potential paths that leverage redundant forwarding solutions along
the way.  With this specification, a Track forms a DODAG that is
directed towards a Track Ingress.  If there is a single Track Egress,
then the Track is reversible to form another DODAG by reversing the
direction of each edge.  A node at the Ingress of more than one
Segment in a Track may use one or more of these Segments to forward a
packet inside the Track.
A P-DAO message for a Track signals the TrackID in the RPLInstanceID
field.  In the case of a local RPL Instance, the address of the Track
Ingress is used as source to encapsulated packets along the Track is
signaled in the DODAGID field of the Projected DAO Base Object, see
p-dao-fmt.
A P-DAO message for a Track signals the TrackID in the RPLInstanceID
field.  In the case of a local RPL Instance, the address of the Track
Ingress is used as source to encapsulate packets along the Track.
The Track is signaled in the DODAGID field of the Projected DAO Base
Object, see p-dao-fmt.
Conventionally we use ==> to represent a strict hop and --> for a
loose hop.  We use -to- like 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).
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).
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 loose hops edges or remain
parallel.
The Segments that join the loose hops of a Leg are installed with the
same TrackID as the Leg. But each individual Leg and Segment has its
own P-RouteID which allows to manage it separately.  When Legs cross
within respsective Segment, the next loose hop (the current
destination of the packet) indicates which Leg is being followed and
a Segment that can reach that next loose hop is selected.
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.
The Segments that join the loose hops of a Leg are installed with the
same TrackID as the Leg.  But each individual Leg and Segment has its
own P-RouteID which allows it to be managed separately.  When Legs
cross within respsective Segment, the next loose hop (the current
destination of the packet) indicates which Leg is being followed and
a Segment that can reach that next loose hop is selected.
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.
Since the state about a Leg of a Track is located only on 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.
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.
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 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 list 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.
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.
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 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.