Draft: draft-ietf-roll-dao-projection

Commentary: Section 4 tweaked to indicate which parts are extensions and which parts of amendments . 
 I 'm not sure that  's proposal is globally accepted , will trust you on that
In addition, the terms "Extends" and "Amends" are used as per I-
D.kuehlewind-update-tag section 3.
A new P-DAO Request (PDR) message (see P-DAOreq) enables a Track
Ingress to request the Track from the Root.  The resulting Track is
also a DODAG for which the Track Ingress is the Root, the owner the
address that serves as DODAGID and authoritative for the associated
namespace from which the TrackID is selected.  In the context of this
specification, the installed route appears as a more specific route
to the Track Targets, and the Track Ingress routes the packets
towards the Targets via the Track using the longest match as usual.
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.
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.
A P-DAO Request (PDR) message enables a Track Ingress to request the
Track from the Root.  The resulting Track is also a DODAG for which
the Track Ingress is the Root, the owner the address that serves as
DODAGID and authoritative for the associated namespace from which the
TrackID is selected.  In the context of this specification, the
installed route appears as a more specific route to the Track
Targets, and the Track Ingress routes the packets towards the Targets
via the Track using the longest match as usual.
Section 6 of RFC6550 introduces the RPL Control Message Options
(CMO), including the RPL Target Option (RTO) and Transit Information
Option (TIO), which can be placed in RPL messages such as the
destination Advertisement Object (DAO).  A DAO message signals
routing information to one or more Targets indicated in RTOs,
providing one hop information at a time in the TIO.  A Projected DAO
(P-DAO) is a special DAO message generated by the Root to install a
P-Route formed of multiple hops in its DODAG.  This provides a RPL-
based method to install the Tracks as expected by the 6TiSCH
Architecture RFC9030 as a collection of multiple P-Routes.
The P-DAO is signaled with a new "Projected DAO" (P) flag, see p-dao-
fmt.  The 'P' flag is encoded in bit position 2 (to be confirmed by
IANA) of the Flags field in the DAO Base Object.  The Root MUST set
it to 1 in a Projected DAO message.  Otherwise it MUST be set to 0.
It is set to 0 in Legacy implementations as specified respectively in
Sections 20.11 and 6.4 of RFC6550.
Section 6 of RFC6550 introduces the RPL Control Message Options
(CMO), including the RPL Target Option (RTO) and Transit Information
Option (TIO), which can be placed in RPL messages such as the
destination Advertisement Object (DAO).  A DAO message signals
routing information to one or more Targets indicated in RTOs,
providing one hop information at a time in the TIO.
This document Amends the specification of the DAO to create the P-DAO
message.  This Amended DAO is signaled with a new "Projected DAO" (P)
flag, see p-dao-fmt.
A Projected DAO (P-DAO) is a special DAO message generated by the
Root to install a P-Route formed of multiple hops in its DODAG.  This
provides a RPL-based method to install the Tracks as expected by the
6TiSCH Architecture RFC9030 as a collection of multiple P-Routes.
The 'P' flag is encoded in bit position 2 (to be confirmed by IANA)
of the Flags field in the DAO Base Object.  The Root MUST set it to 1
in a Projected DAO message.  Otherwise it MUST be set to 0.  It is
set to 0 in Legacy implementations as specified respectively in
Sections 20.11 and 6.4 of RFC6550.
The changes in the P-DAO messages are reflected on the P-DAO-ACK
message that is used to acknowledge a P-DAO, with the new P flag that
signal the projected form.
This document also Amends the DAO-ACK message.  The new P flag
signals the projected form.
New CMOs called the Via Information Options (VIO) are introduced for
use in P-DAO messages as a 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.
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.
This specification adds another CMO called the Sibling Information
Option (SIO) that 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.
Two new RPL Control Messages are also introduced, to enable a RPL-
Aware Node to request the establishment of a Track between self as
the Track Ingress Node and a Track Egress.  The node makes its
request by sending a new P-DAO Request (PDR) Message to the Root.
The Root confirms with a new PDR-ACK message back to the requester
RAN, see P-DAOreq 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.
The set of RPL Control Messages is Extended to include the P-DAO
Request (PDR) and P-DAO Request Acknowledgement (PDR-ACK).  These two
new RPL Control Messages enable an RPL-Aware Node to request the
establishment of a Track between itself as the Track Ingress Node and
a Track Egress.  The node makes its request by sending a new P-DAO
Request (PDR) Message to the Root.  The Root confirms with a new PDR-
ACK message back to the requester RAN, see P-DAOreq for more.
This specification extends RFC6550 to create a new flag that signals
that a packet is forwarded along a P-Route.
This specification Amends RFC6550 to create a new flag that signals
that a packet is forwarded along a P-Route.
This specification defines a new flag "Projected Routes Support" (D).
The 'D' flag is encoded in bit position 0 of the reserved Flags in
the DODAG Configuration Option (this is the most significant bit)(to
be confirmed by IANA but there's little choice).  It is set to 0 in
legacy implementations as specified respectively in Sections 20.14
and 6.7.6 of RFC6550.
This specification Amends the specification to define a new flag
"Projected Routes Support" (D).  The 'D' flag is encoded in bit
position 0 of the reserved Flags in the DODAG Configuration Option
(this is the most significant bit)(to be confirmed by IANA but
there's little choice).  It is set to 0 in legacy implementations as
specified respectively in Sections 20.14 and 6.7.6 of RFC6550.
This specification introduces a new 6LoRH, the P-RPI-6LoRH that can
be used in either Elective or Critical 6LoRH form, see elec6lorhtbl
and crit6lorhtbl respectively.  The new 6LoRH MUST be used as a
Critical 6LoRH, unless an SRH-6LoRH is present and controls the
routing decision, in which case it MAY be used in Elective form.
This specification extends RFC8138 to introduce a new 6LoRH, the P-
RPI-6LoRH that can be used in either Elective or Critical 6LoRH form,
see elec6lorhtbl and crit6lorhtbl respectively.  The new 6LoRH MUST
be used as a Critical 6LoRH, unless an SRH-6LoRH is present and
controls the routing decision, in which case it MAY be used in
Elective form.