[Iot-directorate] IOTdir Review of draft-ietf-roll-dao-projection-19
Toerless Eckert <tte@cs.fau.de> Mon, 13 September 2021 21:02 UTC
Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: iot-directorate@ietfa.amsl.com
Delivered-To: iot-directorate@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6FF3A0DC7 for <iot-directorate@ietfa.amsl.com>; Mon, 13 Sep 2021 14:02:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlPvOec5fTBT for <iot-directorate@ietfa.amsl.com>; Mon, 13 Sep 2021 14:02:46 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16EE93A0DB6 for <iot-directorate@ietf.org>; Mon, 13 Sep 2021 14:02:42 -0700 (PDT)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 75AB5548053 for <iot-directorate@ietf.org>; Mon, 13 Sep 2021 23:02:35 +0200 (CEST)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 650FD4E1603; Mon, 13 Sep 2021 23:02:35 +0200 (CEST)
Resent-From: Toerless Eckert <tte@cs.fau.de>
Resent-Date: Mon, 13 Sep 2021 23:02:35 +0200
Resent-Message-ID: <YT+8ax83cKgRjdHe@faui48e.informatik.uni-erlangen.de>
Resent-To: iot-directorate@ietf.org
Date: Mon, 30 Aug 2021 00:26:20 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Routing Over Low power and Lossy networks <roll@ietf.org>, draft-ietf-roll-dao-projection.all@ietf.org
Message-ID: <20210829222620.GA6858@faui48f.informatik.uni-erlangen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-directorate/H3fBK8W7OIRiHjgfv34Eygd-FGc>
Subject: [Iot-directorate] IOTdir Review of draft-ietf-roll-dao-projection-19
X-BeenThere: iot-directorate@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Mailing list for the IoT Directorate Members <iot-directorate.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iot-directorate>, <mailto:iot-directorate-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iot-directorate/>
List-Post: <mailto:iot-directorate@ietf.org>
List-Help: <mailto:iot-directorate-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iot-directorate>, <mailto:iot-directorate-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Sep 2021 21:02:58 -0000
draft: draft-ietf-roll-dao-projection-19
Review-source: IOTdir
Reviewer: Toerless Eckert
Review result: Technology ready, Text has various issues, mostly difficult to understand.
Dear Authors
Thanks a lot for this work. This is cool technology, it has the
ability to provide very flexible and wide range of path steering
and header optimizations for RPL networks.
Overview:
I am not sure i understand all finer details due likely
to some impedance mismatch between the expected RPL expertise of the text
and mine, but i think that the proposed technology is sound
and has on the technoloy (not text) side only few details that may
need to be added (missing guidance or references on timers,
maybe MTU handling if that is not supposed to be well-known, etc.).
If there is any technological gap, then it is me hoping that this
could be a solution for the RFC8994 A.9.4 problem, but alas this
solution does not support establishment of additional routes for
storage mode DODAGs. Too bad. Especially because its not quite clear
to me why that would not be possible to easily do as well. But
in understand how that RPL profile may not have been of any interest
for this work.
As i am not an expert for RPL, but mostly familia with only
basic use of RPL, i am not sure how much of an expert a reader of this
document is expected to be to be able to read, understand and vet this text.
I think i and other RPL beginners would be able to understand the text
and vet potential gotches better if more explanations where given,
and my feedback indicates this accordingly. But i will not claim
whether such explanations are always deemed necessary for the target
audience.
The mayor issue in the text is that it front-loads a lot of details
that are then hard to understand and open questions are only answered
much later. For example, packet encoding is put first in the document,
as opposed to (as i have observed it in more RFCs) at the end. Then
the text follows with processing description, and only finally with
what i consider to be a complete description of how the pieces
interact through examples. As mentioned in the details, i think the order should
be as much as possible top-down, starting with sufficienly complex
examples that introduce the technology to the extend that the
main concepts are used in the example. E.g.: sequential or complex track,
sements, destinations, targets.
I only performed very opportunistic spell check, please do one yourself.
Please run idnits check too, it complains about the abstract for me.
Appended draft with numbered lines and non-numbered line feedback/comments.
Cheers & thanks again
Toerless
5 ROLL P. Thubert, Ed.
6 Internet-Draft Cisco Systems
7 Updates: 6554 (if approved) R.A. Jadhav
8 Intended status: Standards Track Huawei Tech
9 Expires: 28 January 2022 M. Gillmore
10 Itron
11 27 July 2021
12
13
14 Root initiated routing state in RPL
15 draft-ietf-roll-dao-projection-19
...
135 1. Introduction
136
137 RPL, the "Routing Protocol for Low Power and Lossy Networks" [RPL]
138 (LLNs), is a generic Distance Vector protocol that is well suited for
139 application in a variety of low energy Internet of Things (IoT)
140 networks. RPL forms Destination Oriented Directed Acyclic Graphs
141 (DODAGs) in which the Root often acts as the Border Router to connect
142 the RPL domain to the Internet. The Root is responsible to select
^^^^^^^^^^^^^^^
Really ? What is the "often" case where e.g.: at least nodes in the RPL network
can reach nodes across the Internet ? Aka: from my understanding, the common
deployment would attach to other limited domain (RFC8799) networks, for example
if i correctly glean from rfc9030, but not "the Internet". Otherwise, please
provide a reference to justify "often ... to the Internet".
Aka: suggest to replace Internet with "other network" or maybe "a backbone".
142 the RPL domain to the Internet. The Root is responsible to select
143 the RPL Instance that is used to forward a packet coming from the
144 Internet into the RPL domain and set the related RPL information in
Same comments about "the Internet".
147 The "6TiSCH Architecture" [6TiSCH-ARCHI] also leverages the
148 "Deterministic Networking Architecture" [RFC8655] centralized model
149 whereby the device resources and capabilities are exposed to an
150 external controller which installs routing states into the network
151 based on some objective functions that reside in that external
152 entity. With DetNet and 6TiSCH, the component of the controller that
The DetNet architecture has a lot more aspects for which i am not sure, that
6TiSCH matches them (have not gone fully through 6TiSCH-ARCHI). Aka: DetNet as
of today implies the per-hop,per-flow IntServ architecture, but no DiffServ
for DetNet service hops. Is this what 6TiSCH-ARCHI does as well ?
If not, then maybe change to "levereges the aspects of the ..." to make
the claim more scoped to what the paragraph describes.
152 entity. With DetNet and 6TiSCH, the component of the controller that
153 is responsible of computing routes is called a Path Computation
154 Element ([PCE]).
155
156 Based on heuristics of usage, path length, and knowledge of device
157 capacity and available resources such as battery levels and
158 reservable buffers, the PCE with a global visibility on the system
159 can compute direct Peer to Peer (P2P) routes that are optimized for
160 the needs expressed by an objective function. This document
"Based on heuristics" has one doubt whether the result is deerministic. Not
saying heuristics may not play a role, but maybe fnd a better wording.
"global visibility" sounds like weather satellites. More specifically when
reading, i wonder if the scope of the discussion in this document can be
constraint to a single RPL network, or if it is important to understand
that the mechanisms of this document a also enabling more "interesting" paths.
Aka: If the following is one of the cases for which this drafts work is
in support of, then i would really like to see this type of picture and
explanation added as something like a reference picture with explanation:
Client11 Client21 ClientN1
| | |
PCE RPL-network1 RPL-network2 RPL-networkN
| Root1 Rtr1b Root2 Rtr2b ... RootN RtrNb
| | | | | | |
..................................................................
Backbone Network, L2 / L3, e.g.:
-+----------+---------+----------+--------+-----------+-------+----
Aka: The PCE can calculate paths between clients in this internetwork.
An example path between Client11 and ClientN1 is composed of the
projected path between Client11 and one of the nodes connecting RPL-network1
to the backbone, e.g.: Rtr1b, a path through the backbone, and finally
a path through RPL-networkN, again including the choice of edge
router to the backbone, e.g.: RtrNb.
I guess if the solution does not support RtrIb, then its explanation
could more easily be constrained to just a single RPL-network.
160 the needs expressed by an objective function. This document
This statement is confusing.
Without this draft, the objective functions result in specific paths,
and these paths are insufficient, so the PCE also uses this drafts
mechanism to achieve better paths. So the objective function clearly
was not sufficient. Besides, the objective function is very specific
to parameters used in distributed path calculation, not PCE.
In my mind, there is some goal/objective for the path to be calculated,
and this objective is achieved by OF to create DODAG and paths, and if
those paths are insufficient, then
and a controller can achieve that objective by defining a
but when the controller determinses that it can not solely be achieved
through objective function parameters, then it starts using this drafts
mechanism...
160 the needs expressed by an objective function. This document
Suggest new paragraph before "This"
161 specifies protocol extensions to RPL [RPL] that enable the Root of a
162 main DODAG to install centrally-computed routes inside the DODAG on
163 behalf of a PCE.
172
173 This specification expects that the main RPL Instance is operated in
174 RPL Non-Storing Mode of Operation (MOP) to sustain the exchanges with
175 the Root. In that Mode, the Root has enough information to build a
^ Only ?
176 basic DODAG topology based on parents and children, but lacks the
^ still
177 knowledge of siblings. This document adds the capability for nodes
Aka: in storing mode the root would even have less information, right ?
178 to advertise sibling information in order to improve the topological
179 awareness of the Root.
180
181 As opposed to the classical RPL operations where routes are injected
182 by the Target nodes, the protocol extensions enable the Root of a
183 DODAG to project the routes that are needed onto the nodes where they
184 should be installed. This specification uses the term Projected
185 Route to refer to those routes. Projected Routes can be used to
186 reduce the size of the source routing headers with loose source
187 routing operations down the main RPL DODAG. Projected Routes can
188 also be used to build transversal routes for route optimization and
189 Traffic Engineering purposes, between nodes of the DODAG.
190
191 A Projected Route may be installed in either Storing and Non-Storing
192 Mode, potentially resulting in hybrid situations where the Mode of
193 the Projected Route is different from that of the main RPL Instance.
194 A Projected Route may be a stand-alone end-to-end path or a Segment
195 in a more complex forwarding graph called a Track.
197 The concept of a Track was introduced in the 6TiSCH architecture, as
198 a potentially complex path with redundant forwarding solutions along
199 the way.
Please add a reference to the spec that introduced Track.
Where is "stand-alone" introduced ? If elswhere, add reference, otherwise
say its introduced here. Also, everything else is capitalized, maybe you want
to capitalize also Stand Alone.
199 With this specification, a Track is a DODAG formed by a RPL
200 local Instance that is rooted at the Track Ingress. If there is a
201 single Track Egress, then the Track is reversible to form another
202 DODAG by reversing the direction of each edge. A node at the ingress
203 of more than one Segment in a Track may use one or more of these
204 Segments to forward a packet inside the Track.
The last sentence is using the term Segment to explain something new, but the
term Segment was not sufficiently defined in before. Other than that a Segment
can be or is always (?) a Projected Route, but Projected Route is also undefined.
206 The "Reliable and Available Wireless (RAW) Architecture/Framework"
207 [RAW-ARCHI] defines the Path Selection Engine (PSE) that adapts the
208 use of the path redundancy within a Track to defeat the diverse
209 causes of packet loss.
210
211 The PSE is a dataplane extension of the PCE; it controls the
212 forwarding operation of the packets within a Track, using Packet ARQ,
213 Replication, Elimination, and Overhearing (PAREO) functions over the
214 Track segments, to provide a dynamic balance between the reliability
215 and availability requirements of the flows and the need to conserve
216 energy and spectrum.
217
218 The time scale at which the PCE (re)computes the Track can be long,
219 using long-term statistical metrics to perform global optimizations
220 at the scale of the whole network. Conversely, the PSE makes
229 forwarding decisions at the time scale of one or a small collection
230 of packets, based on a knowledge that is limited in scope to the
231 Track itself, so it can be refreshed at a fast pace.
I would suggest to restructure this. Before going into the RPL details as you do
in before, maybe start with the problem to be solved. Which seems to be a
mechanism to support packet replication, traversal over alternative paths and
duplicate elimination (and seemingly more). 6TiSCH introduced Tracks as the
concept for redundant paths, RAW inroduced PAREO. This document introduces
one solution to to build Tracks with RPL und a mechanism called Projected Routes.
Something like that to have a more logical sequence of explanations, top to bottom.
233 Projected Routes must be used with the parsimony to limit the amount
Parsimony in he sense you use it, was never used in RFCs, rc871 used law of parsimony.
Suggest to reword for easier reading. For example, "Care must be taken that state installed for
projected routes fit in each devices resources".
Is the amount of traffic solely a responsibility of the installation of projected
routes ? Isn't this also responsibility of the PSE ? (just guessing, haven't read
up on it).
234 of state that is installed in each device to fit within the device
235 resources, and to maintain the amount of rerouted traffic within the
237 capabilities of the transmission links. The methods used to learn
237 the node capabilities and the resources that are available in the
238 devices and in the network are out of scope for this document.
239
240 This specification uses the RPL Root as a proxy to the PCE. The PCE
241 may be collocated with the Root, or may reside in an external
242 Controller.
243
244 In that case, the PCE exchanges control messages with the Root over a
^^^^ the latter
245 Southbound API that is out of scope for this specification. The
^ PCE
246 algorithm to compute the paths and the protocol used by an external
247 PCE to obtain the topology of the network from the Root are also out
248 of scope.
In his AD review for draft-ietf-bier-te-arch, Alvaro asked me to provide examples
for such topology discovery. YOu can of course wait out if this will happen for
his doc too, i personally have no strong opinions, but if you need example
text, see draft-ietf-bier-te-arch, 3.2.1.1, Third paragraph.
Personally, i do not like the conditioning that a southbound API is supposedly
only necessary when the PCE is external from the RPL Root. IMHO, there always
needs to be at least an informat model for Projected Routes. Which you may
agree on, but its not mentioned. PCE and RPL Root can just be independent
software entities on the same node.
260 2.2. Glossary
261
262 This document often uses the following acronyms:
263
264 CMO: Control Message Option
265 DAO: Destination Advertisement Object
266 DAG: Directed Acyclic Graph
267 DODAG: Destination-Oriented Directed Acyclic Graph; A DAG with only
268 one vertex (i.e., node) that has no outgoing edge (i.e., link)
269 LLN: Low-Power and Lossy Network
270 MOP: RPL Mode of Operation
271 P-DAO: Projected DAO
272 P-Route: Projected Route
273 PDR: P-DAO Request
274 RAN: RPL-Aware Node (either a RPL Router or a RPL-Aware Leaf)
275 RAL: RPL-Aware Leaf
276 RH: Routing Header
285 RPI: RPL Packet Information
286 RTO: RPL Target Option
287 RUL: RPL-Unaware Leaf
288 SIO: RPL Sibling Information Option
289 SR-VIO: A Source-Routed Via Information Option, used in Non-Storing-
290 Mode P-DAO messages.
291 TIO: RPL Transit Information Option
292 SF-VIO: A Via Information Option, used in Storing-Mode P-DAO
293 messages.
294 VIO: A Via Information Option; it can be a SF-VIO or an SR-VIO.
I had a hard time remembering SR-VIO and SF-VIO throughout the text. Maybe
SM-VIO and NSM-VIO would be easier to remember and better because they explicitly
refer to the explanation (Storing Mode, Non-Storing Mode).
I'll spare you the request for a full Terminology section for these terms with
references, maybe others will do so.
It would make sense though to move the terms newly introduced in this doc,
such as P-Route , P-DAO and the like into section 2.3 and rename 2.3 to "New terms".
Derived terms like P-Route can of course stay concise.
296 2.3. Other Terms
...
327 3. Extending RFC 6550
You have tagged this draft as an Update to RFC6550. You should IMHO have a
section where you summarize what that exactly entails, ideally call "Updated to RFC6550".
AFAIK, we do not have a good formal structure for such update description, Mirja
tried to propose some more keywords, but so far, Update can mean anything.
I would suggest to summarize what type of update this is by making statements
answering the following type of questions (maybe i forgot some). These statements
are also useful when they are answering the questions below with No. I leave it up to
you if you feel this would be good to go here in the beginnin, or if you'd rather
want to summarize it in the end of the document.
Questions:
Does this document specify any functionality that is REQUIREDS or RECOMMENDED
for implementations of RFC6550 ? If so, please detail them. Else, this can be called
a fully OPTIONAL update for RFC6550.
Will implementations supporting this RFC continue to be backward compatible with
all prior RFCs, RFC6550 and related ? If not, please describe any changes in
interoperability.
Does this RFC introduce any functional extensions to RFC6550 or other RFC
through mechanisms other than pre-defined extension points ?
Are any pre-defined extension points of RFC6550 or other RFC used, which are not
already IANA registries ? If so, please include references to the original RFC
section where that extension point was described.
(first time i am trying to formalize these type of question...)
IMHO outside the scope of documenting the "Update" flag is mixed deployment.
If there is no text for that, would be good to add that somehwere. Update section
wouldn't be a bad place.
341 3.1. Projected DAO
At this point i am worried whether i am correctly guessing at the forwarding
plane behavior of projected routes, because i felt it was presented in the
Intro section mostly en-passant, but it is hard to follow the document with
the correct explanation of how forwarding works.
What i figured from the Intro is that Projected Routes would allow the root
to specify a loose path in the RH, even though only non-storing mode is used.
Whenever a RPL node then sees a next-op in the RH it looks for a projected
Route towards that next-hop and hmm... just forwards the packet to the
first next hop on the projeted route ? Or it needs to change the routing
header to prepend the projected route ?
And i have absolutely no idea what interactions there are between PSE and
Projected routes in the forwarding plane..
Section 9 has some signalling examples. Maybe it would be good to create
some introductory example that shows the relevant forwarding plane aspects.
343 Section 6 of [RPL] introduces the RPL Control Message Options (CMO),
344 including the RPL Target Option (RTO) and Transit Information Option
345 (TIO), which can be placed in RPL messages such as the Destination
346 Advertisement Object (DAO).
346 This specification extends the DAO
347 message with the Projected DAO (P-DAO); a P-DAO message signals a
348 Projected Route to one or more Targets using the new CMOs presented
349 therein.
This is confusing. If i am guessing right, i would suggest to write:
This specification defines a new CMO carrying a Projected Route. When this
Projected Route CMO is included in a DAO message, this is called a Projected DAO (P-DAO).
I do not get the "signals _a_ Projected Route to one or _more_ Targets". How can
a single P-DAO be signalled to more than one recipient ?
349 This specification enables to combine one or more Projected
350 Routes into a DODAG called a Track, that is traversed to reach the
351 Targets.
352
353 The Track is assimilated with the DODAG formed for a Local RPL
354 Instance. The local RPLInstanceID of the Track is called the
355 TrackID, more in Section 7.2. A P-DAO message for a Track signals
356 the TrackID in the RPLInstanceID field. The Track Ingress is
357 signaled in the DODAGID field of the Projected DAO Base Object; that
358 field is elided in the case of the main RPL Instance. The Track
359 Ingress is the Root of the Track, as shown in Figure 1.
How about the text here first finishes up the specification of the P-DAO CMO
before explaining some, but likely not all details of how this stuff
works together ?
360
361 This specification defines the new "Projected DAO" (P) flag. The 'P'
362 flag is encoded in bit position 2 (to be confirmed by IANA) of the
363 Flags field in the DAO Base Object. The Root MUST set it to 1 in a
364 Projected DAO message. Otherwise it MUST be set to 0. It is set to
365 0 in legacy implementations as specified respectively in Sections
366 20.11 and 6.4 of [RPL]. .
367
368 0 1 2 3
369 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
371 | TrackID |K|D|P| Flags | Reserved | DAOSequence |
372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
373 | |
374 + +
375 | |
376 + IPv6 Address of the Track Ingress +
377 | |
378 + +
379 | |
380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
381 | Option(s)...
382 +-+-+-+-+-+-+-+-+
383
384 Figure 1: Projected DAO Base Object
385
386 New fields:
387
388 TrackID: In the case of a P-DAO, the RPLInstanceID field is called
397 TrackID. This is a naming convenience but does not change the
398 semantics and format of the RPLInstanceID that is used as TrackID.
Maybe then stick to calling it RPLInstanceID in the ASCII and not calling it
a new field (nitpicking).
400 P: 1-bit flag (position to be confirmed by IANA).
401
402 The 'P' flag is set to 1 by the Root to signal a Projected DAO,
403 and it is set to 0 otherwise.
404
405 In RPL Non-Storing Mode, the TIO and RTO are combined in a DAO
406 message to inform the DODAG Root of all the edges in the DODAG, which
407 are formed by the directed parent-child relationships. Options may
408 be factorized; multiple RTOs may be present to signal a collection of
409 children that can be reached via the parent(s) indicated in the
410 TIO(s) that follows the RTOs. This specification generalizes the
411 case of a parent that can be used to reach a child with that of a
412 whole Track through which both children and siblings of the Track
413 Egress are reachable.
This again seems to be mixing larger logical behavior explanation into what
probably should be just the spec for the new message encodings here. See how
you can decouple the larger system explamnations from the encoding spec.
415 New CMOs called the Via Information Options (VIO) are introduced for
416 use in P-DAO messages as a multihop alternative to the TIO. One VIO
a) Add forward pointer to section defining VIO
b I get the feeling as if the whole mentioning of TIO and RTO above should simply
go in a separate chapter for RPL experts with a title like "Why are TIO and RTO
not sufficient". Or "How to combine TIO/RTO with SF-VIO" etc.. but try to
stick to topic at hand here. Feeble minded readers like myself can only balance
a limited number of partially understood terms in the air at the same time.
417 is the Stateful VIO (SF-VIO); the SF-VIO installs Storing-Mode
^ a ?
418 Projected Route along a strict segment. The other is the Source-
^ s ?
419 Routed VIO (SR-VIO); the SR-VIO installs a Non-Storing-Mode Projected
420 Route at the Track Ingress, which uses that state to encapsulate a
421 packet with a Routing Header (RH) to the Track Egress.
Question... If i just use basic RPL with non-storing mode, i already
need an RH. And that is let's say a strict path. So after the first hop of that
RH, my next hop is actually a track ingres for which i have SR-VIO. Does this
mean i need to do a full new IPv6 encap of the packet to insert the new
RH for the track ? If so:
a) i'd say: "to encapsulate the packet into an IPv6 packe with a new RH to the track egress.
b) What about MTU issues due to the encap ? Can not find word MTU in text.
423 Like in a DAO message, the RTOs can be factorized in a P-DAO, but the
424 Via Information Options cannot.
424 A P-DAO contains one or more RTOs
^ MUST/SHOULD/MAY ?
425 that indicate the destinations that can be reached via the Track, and
426 exactly one VIO that signals a sequence of nodes . In Non-Storing
^ That form the track ?
root ....... Track-Ingres ...(Track Midpoints)... Track-Egres ..... Destination1
...
... DestinationN
P-DAO has:
one RTO for each DestinationI
one VIO for the Track: Midpoints,Egres
Semantic: When packet reaches Track-Ingres, it checks whether destination or
next-hop is one of the DestinationI, if so, then use the track. If SR-VIO,
then encap IPv6/RH, if SF-VIO, then just forward to first hop on track,
which will also have installed the right state for the track...
Something like this with picture would make the whole concept so much
easier to understand (to me).
427 Mode, the Root sends the P-DAO to the Track Ingress where the source-
428 routing state is stored. In Storing Mode, the P-DAO is sent to the
429 Track Egress and forwarded along the Segment in the reverse
430 direction, installing a Storing Mode state to the Track Egress at
431 each hop. In both cases the Track Ingress is the owner of the Track,
432 and it generates the P-DAO-ACK when the installation is successful.
How would the root know whether in storing node all the track midpoints
did successfully install the necessary track state ? If not, hen it would be
worth pointing out how storing mode may end up being less reliable ?
434 3.2. Sibling Information Option
Is there any reason why we wouldn't first want to have the VIO section here
so a feeble minded reader could pop off some open definitions of the stack
and declare understanding victory on whats explaind so far ?
To answe my own question, i think your structure is around whatever RFC
is supposedly extended by a new semantic introduced, but that results in
terrible flow of reading. I would strongly suggest to reshuffle the
text from the most simple cases to the most complex cases and have
separate short sections summarizing for each affected RFC how it is
extended usin the template questions above, using references to the main
specification part.
436 This specification adds another CMO called the Sibling Information
437 Option (SIO) that is used by a RPL Aware Node (RAN) to advertise a
438 selection of its candidate neighbors as siblings to the Root, more in
439 Section 6.4. The sibling selection process is out of scope. The
440 expectation is that a node reports a Sibling Address in a SIO based
441 on an active address registration [RFC8505] from that sibling for
442 that address with the 'R' flag not set in the EARO. The node may
443 assess the liveliness of the sibling at any time by performing a
444 registration for one of its own addresses, either a link local or a
453 global one, depending on whether the node expects the sibling to
454 perform a matching advertisement in its own SIO.
I am not even going to try to understand this without a prior graphical
example use case on how this would be used.
456 3.3. P-DAO Request
457
458 Two new RPL Control Messages are also introduced, to enable a RAN to
459 request the establishment of a Track between self as the Track
460 Ingress Node and a Track Egress. The RAN makes its request by
461 sending a new P-DAO Request (PDR) Message to the Root. The Root
462 confirms with a new PDR-ACK message back to the requester RAN, see
463 Section 6.1 for more.
The split between this text and 6.1 is weird and IMHO not helpfull. Merge.
WHats ven the logic to split some explanations out into section 6 and leave
others (P-DAO for example) here ?
I would also like some motivational example of what would make a RAN send
out a P-DAO Request. Could it be that the RAN is a PSE ingres ? I am asking,
because this looks like a request where it might be highly desirable to have
more contextual information in the request than just the few fields defined in
6.1. How about a 32 bit policy-ID field or the like.. But just guessing.
Something for the PCE to match up PSE stuff it established with P-DAO
requests it receives later. Unless you feel strongly that association is
unambiguous now.
463 A positive PDR-ACK indicates that the Track
464 was built and that the Roots commits to maintain the Track for the
465 negotiated lifetime. In the case of a complex Track, each Segment is
466 maintained independently and asynchronously by the Root, with its own
467 lifetime that may be shorter, the same, or longer than that of the
468 Track.
I guess those different liftimes are not meant to make the solution more fragile
by randomnly expiring timers for different parts of a track, but because the
the parts of a projected routes affected can only change when they expire ?
In any case, an explanation of the semantic impact of lifetimes would be
useful.
468 The Root may use an asynchronous PDR-ACK with an negative
469 status to indicate that the Track was terminated before its time.
And if that happens, what should a RAN do that has some configuration telling
it to request the P-DAO ? Sounds like the need for the definition of some
exponential back-off re-request scheme ?
Also, when the request is just renewed upon timeout, but the reply changes,
i figure that the impact in stateful mode may be some inconsistent forwarding
while the track midpoints update their routes. No issue i guess in stateless.
Would be useful to mention. Not sure if/what countermeasures for consistency
RPL already provides. If it does, would be good to mention.
471 3.4. Extending the RPI
472
473 Sending a Packet within a RPL Local Instance requires the presence of
474 the abstract RPL Packet Information (RPI) described in section 11.2.
475 of [RPL] in the outer IPv6 Header chain (see [USEofRPLinfo]). The
476 RPI carries a local RPLInstanceID which, in association with either
477 the source or the destination address in the IPv6 Header, indicates
478 the RPL Instance that the packet follows.
479
480 This specification extends [RPL] to create a new flag that signals
481 that a packet is forwarded along a projected route.
482
483 Projected-Route 'P': 1-bit flag. It is set to 1 if this packet is
484 sent over a projected route and set to 0 otherwise.
This leaves me guessing when and how this applied. I can see how this would be
applicable to both stateful and stateless Projected route operastions, but in
either case, the forwarding plane behavior needs to be explained, ideall with
example for each (of the two?) cases.
Also: Please add forward pointer to next section saying "For concrete encoding
of the P flag, see section 4.".
486 4. Extending RFC 6553
I think this RFC MUST claim to be an update to RFC6553, because the P-flag
added to this concrete RPI RFC exhausts a non-IANA extension point, and
the only way to formally avoid that any other RFCs could collide (and allocate
the same bit) is to make this RFC an update to RFC6553. Same logic also
applies to update for RFC6550 and P-DAO P flag.
Just to be save, claim also update to RFC9008 to given how you mention it,
and we obviously want this RFC to also apply to RPI headers with 0x23.
511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
512 | Option Type | Opt Data Len |
513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
514 |O|R|F|P|0|0|0|0| RPLInstanceID | SenderRank |
515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
516 | (sub-TLVs) |
517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
518
519 Figure 2: Extended RPL Option Format
520
521 Option Type: 0x23 or 0x63, see [USEofRPLinfo]
522
523 Opt Data Len: See [RFC6553]
^ unchanged,
524
525 'O', 'R' and 'F' flags: See [RFC6553]. Those flags MUST be set to 0
526 by the sender and ignored by the receiver if the 'P' flag is set.
527
528 Projected-Route 'P': 1-bit flag as defined in Section 3.4.
529
530 RPLInstanceID: See [RFC6553]. Indicates the TrackId if the 'P' flag
531 is set.
Add 'see also section 3.1' ?
533 SenderRank: See [RFC6553]. This field MUST be set to 0 by the
534 sender and ignored by the receiver if the 'P'flag is set.
Would you mind to add expanation as to what can happen when this passes via a router not supporting
this RFC and therefore ignoring the P flag but interpreting the other fields ?
536 5. Extending RFC 8138
537
538 Section 6.3 of [RFC8138] presents the formats of the 6LoWPAN Routing
539 Header of type 5 (RPI-6LoRH) that compresses the RPI for normal RPL
^
in the IANA "Critical 6LoWPAN Routing Header Type Registry"
540 operation. The format of the RPI-6LoRH is not suited for Projected
541 routes since the O,R,F flags are not used and the Rank is unknown and
542 ignored.
543
544 This specification introduces a new 6LoRH, the P-RPI-6LoRH, with a
545 type of 7. The P-RPI-6LoRH header is usually a a Critical 6LoWPAN
^ ^^^
|
in the IANA "Critical 6LoWPAN Routing Header Type Registry"
546 Routing Header, but it can be elective as well if an SRH-6LoRH is
^^^^^^^^^^^^^^^^^^^
also use type TBD1 from the IANA "Electivce 6LoWPAN Routing Header Type Registry"
https://www.iana.org/assignments/_6lowpan-parameters/_6lowpan-parameters.xhtml#critical-6lowpan-routing-header-type
Elective Type 7 is already gone. If you want to get the same numbers for
elective and critical yo may want to also revisit to choose 7 for critical.
Who made you be so adventerous to write an actual number 7 into the draft without an
early allocation anyhow ? How about asking for an early allocation ?
547 present and controls the routing decision.
548
549 The P-RPI-6LoRH is designed to compress the RPI along RPL Projected
550 Routes. It sformat is as follows:
^^^
551
565 0 1 2
566 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
568 |1|0|E| Length | 6LoRH Type 7 | RPLInstanceID |
569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
570
571
572 Figure 3: P-RPI-6LoRH Format
573
574 Elective 'E': See [RFC8138]. The 'E' flag is set to 1 to indicate
575 an Elective 6LoRH, meaning that it can be ignored when forwarding.
Please explain length or point to RFC8138 (inchanged from RFC8318, section XX.YY).
Please DO NEVER include the assicned number into the field, just write "6LoRH Type".
Explain in text that is the assined type for criical or elective depending on E flag.
Explain that RPLInstanceID is the TrackID (see section 3.1 ?) Or if not, what it is.
577 6. New RPL Control Messages and Options
578
579 6.1. New P-DAO Request Control Message
580
581 The P-DAO Request (PDR) message is sent by a Node in the main DODAG
582 to the Root. It is a request to establish or refresh a Track where
583 this node is Track Ingress. The source IPv6 address of the PDR
584 signals the Track Ingress of the requested Track, and the TrackID is
585 indicated in the message itself. One and only one RPL Target Option
586 MUST be present in the message. The RTO signals the Track Egress,
587 more in Section 7.1.
588
589 The RPL Control Code for the PDR is 0x09, to be confirmed by IANA.
Correct form is TBDi (TBD2 ?) instead of 0x09.
If you are not in a hurry, all TBDi can be resolved during IANA/RFC-editor procss.
If you want to lock in a number get an early allocation first.
590 The format of PDR Base Object is as follows:
591
592 0 1 2 3
593 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
595 | TrackID |K|R| Flags | ReqLifetime | PDRSequence |
596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
597 | Option(s)...
598 +-+-+-+-+-+-+-+-+
599
600 Figure 4: New P-DAO Request Format
601
602 TrackID: 8-bit field indicating the RPLInstanceID associated with
603 the Track.
604
605 K: The 'K' flag is set to indicate that the recipient is expected to
606 send a PDR-ACK back.
607
608 R: The 'R' flag is set to request a Complex Track for redundancy.
609
610 Flags: Reserved. The Flags field MUST initialized to zero by the
611 sender and MUST be ignored by the receiver
612
613
614
615
616 Thubert, et al. Expires 28 January 2022 [Page 11]
617
618 Internet-Draft DAO Projection July 2021
619
620
621 ReqLifetime: 8-bit unsigned integer. The requested lifetime for the
622 Track expressed in Lifetime Units (obtained from the DODAG
623 Configuration option).
624
625 A PDR with a fresher PDRSequence refreshes the lifetime, and a
626 PDRLifetime of 0 indicates that the track should be destroyed.
... It would be sent for example when the function for which the Node requested
the track is deactivated. ?!
628 PDRSequence: 8-bit wrapping sequence number, obeying the operation
629 in section 7.2 of [RPL]. The PDRSequence is used to correlate a
630 PDR-ACK message with the PDR message that triggered it. It is
631 incremented at each PDR message and echoed in the PDR-ACK by the
632 Root.
633
634 6.2. New PDR-ACK Control Message
635
636 The new PDR-ACK is sent as a response to a PDR message with the 'K'
637 flag set. The RPL Control Code for the PDR-ACK is 0x0A, to be
638 confirmed by IANA. Its format is as follows:
Same IANA/TBD concern as above.
639
640 0 1 2 3
641 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
643 | TrackID | Flags | Track Lifetime| PDRSequence |
644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
645 | PDR-ACK Status| Reserved |
646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
647 | Option(s)...
648 +-+-+-+-+-+-+-+
649
650 Figure 5: New PDR-ACK Control Message Format
651
652 TrackID: The RPLInstanceID of the Track that was created. The value
653 of 0x00 is used to when no Track was created.
^^
Same question as in before. Any standardized logic what to do in case of 0x00 failure,
if not, then why not.
654
655 Flags: Reserved. The Flags field MUST initialized to zero by the
656 sender and MUST be ignored by the receiver
657
658 Track Lifetime: Indicates that remaining Lifetime for the Track,
659 expressed in Lifetime Units; the value of zero (0x00) indicates
660 that the Track was destroyed or not created.
661
662 PDRSequence: 8-bit wrapping sequence number. It is incremented at
663 each PDR message and echoed in the PDR-ACK.
according to section 7.2 of [RPL] ?!
665 PDR-ACK Status: 8-bit field indicating the completion. The PDR-ACK
^ status
666 Status is substructured as indicated in Figure 6:
676
677 0 1 2 3 4 5 6 7
678 +-+-+-+-+-+-+-+-+
679 |E|R| Value |
680 +-+-+-+-+-+-+-+-+
681
682 Figure 6: PDR-ACK status Format
683
684 E: 1-bit flag. Set to indicate a rejection. When not set, the
685 value of 0 indicates Success/Unqualified acceptance and other
686 values indicate "not an outright rejection".
687 R: 1-bit flag. Reserved, MUST be set to 0 by the sender and
688 ignored by the receiver.
689 Status Value: 6-bit unsigned integer. Values depending on the
690 setting of the 'E' flag, see Table 27 and Table 28.
691
692 Reserved: The Reserved field MUST initialized to zero by the sender
^ be
693 and MUST be ignored by the receiver
694
695 6.3. Via Information Options
696
697 A VIO signals the ordered list of IPv6 Via Addresses that constitutes
698 the hops of either a Serial Track or a Segment of a more Complex
699 Track. A VIO MUST contain at least one Via Address, and a Via
700 Address MUST NOT be present more than once, otherwise the VIO MUST be
701 ignored.
If i understand it correctly, for the SR-VIO, the sequence of addresses would
ultimately end up in the RPL steering header of packets. I browsed through
RFC8754 and think i can not find a similar exclusion. So a justification
why this optimization is done for SF-VIO would be good if you really want to keep it.
For SF-VIO, this seems to be taken apart and every node listed creates a
next-hop route. So if the same node is addressed twice, it could become
confused, which instance of its own address to choose to install the route, right ?
And what does "ignore" mean anyhow, e.g.: would the Target Options still be acted
upon ? It rather sounds to me as if you would want the whole Projected DAO message
to be rejected ?
Is duplicate address the only case of a "broken" projected DAO that you can
discover and reject ? E.g.: can nodes have multiple addresses ? Such as
anycast addresses ?
Would be good to elaborate about such "broken" projected DAO more if there are different
cases of it.
701 The format of the Via Information Options is as follows:
732
733 0 1 2 3
734 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
736 | Type | Option Length | Flags | SegmentID |
737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
738 |Segm. Sequence | Seg. Lifetime | SRH-6LoRH header |
739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
740 | |
741 + +
742 . .
743 . Via Address 1 .
744 . .
745 + +
746 | |
747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
748 | |
749 . .... .
752 | |
751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
752 | |
753 + +
754 . .
755 . Via Address n .
add (n <= 15) ?
756 . .
757 + +
758 | |
759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
760
761
762 Figure 7: VIO format (uncompressed form)
763
764 Option Type: 0x0B for SF-VIO, 0x0C for SR-VIO (to be confirmed by
765 IANA)
Same concern as prior illegal occupations of IANA codepoints in this spec ;-))
767 Option Length: In bytes; variable, depending on the number of Via
768 Addresses and the compression.
Something like total size of the Option ... in bytes ?
Is this semantic mandated by prior RFC ? If it could count differently,
it could allow for more than 15 hops, although i have no idea if that would
be relevant.
770 SegmentID: 8-bit field that identifies a Segment within a Track or
771 the main DODAG as indicated by the TrackID field. The value of 0
772 is used to signal a Serial Track, i.e., made of a single segment.
Another basic signaling element not yet explained, so somewhat mysterious here
774 Segment Sequence: 8-bit unsigned integer. The Segment Sequence
775 obeys the operation in section 7.2 of [RPL] and the lollipop
776 starts at 255.
777
778 When the Root of the DODAG needs to refresh or update a Segment in
779 a Track, it increments the Segment Sequence individually for that
780 Segment.
781
789 The Segment information indicated in the VIO deprecates any state
790 for the Segment indicated by the SegmentID within the indicated
791 Track and sets up the new information.
792
793 A VIO with a Segment Sequence that is not as fresh as the current
794 one is ignored.
795
796 A VIO for a given DODAGID with the same (TrackID, SegmentID,
797 Segment Sequence) indicates a retry; it MUST NOT change the
798 Segment and MUST be propagated or answered as the first copy.
799
800 Segment Lifetime: 8-bit unsigned integer. The length of time in
801 Lifetime Units (obtained from the Configuration option) that the
802 Segment is usable.
803
804 The period starts when a new Segment Sequence is seen. The value
805 of 255 (0xFF) represents infinity. The value of zero (0x00)
806 indicates a loss of reachability.
807
808 A P-DAO message that contains a VIO with a Segment Lifetime of
809 zero is referred as a No-Path P-DAO in this document.
810
811 SRH-6LoRH header: The first 2 bytes of the (first) SRH-6LoRH as
812 shown in Figure 6 of [RFC8138]. A 6LoRH Type of 4 means that the
813 VIA Addresses are provided in full with no compression.
814
815 Via Address: An IPv6 address along the Segment.
816
817 In a SF-VIO, the list is a strict path between direct neighbors,
818 from the Segment Ingress to Egress, both included. The router
819 that processes an SF-VIO MAY create additional routing state
820 towards the nodes after self via the node immediately after self
821 in the SF-VIO, but in case of memory shortage the routes to the
822 Targets have precedence since they are the ones that the router
823 commits to store.
Again, i am at a lack of understanding the base theory of operations of forwarding,
I have Track Ingres, Track Egres, Destinations, Target and somehow i have
Segments with addresses, wheree i do not know how Segment Ingres and Segment Egres
may or may not map to Track Ingres/Egres, Destinations or Targets.
Picture me this, please ? ;-))
So, what exactly does the routing state look like ? whats the lookup ?
Something like (RPLInstanceID==TrackID, Destination) ? Or rather: What is
the example scenario when a the above described additional routing state
to the nodes after self would would be used ?
825 In an SR-VIO, the list includes the egress but not the ingress
826 node. It starts at the first hop and ends at a Track Egress. In
Seems like a mayor difference in flexiblity of stateful vs. stateless operations than ?
No segment layer with SR-VIO ?
827 that case, the Track Egress MUST be considered as an implicit
828 Target, so it MUST NOT be listed it in a RPL Target Option. The
829 list in an SR-VIO may be loose, provided that each listed node has
830 a path to the next listed node, e.g., via a segment or another
831 Track.
But you are not telling me you would want to create the freedom to have stateless
operation rely on routing state created by SF-VIO where you said it might
not exist in case of memory shortage which the stateless encapsulator would
know nothing about, right ?
833 In the case of a SF-VIO, or if [RFC8138] is not used in the data
834 packets, then the Root MUST use only one SRH-6LoRH per Via
835 Information Option, and the compression is the same for all the
836 addresses, as shown in Figure 7.
I do not see any address compression in Figure 7, nor was compression mentioned
so far.
Do you mean figure 7 in section 5.1 of [RFC8138] ?
845 In case of an SR-VIO, and if [RFC8138] is in use in the main
846 DODAG, then the Root SHOULD optimize the size of the SR-VIO;
Any example how ?
846 more
847 than one SRH-6LoRH may be present, e.g., if the compression level
848 changes inside the Segment and different SRH-6LoRH Types are
849 required.
That rather sounds as if those are cases where optimiation would no be possible ?
849 The content of the SR-VIO starting at the first SRH-
850 6LoRH header is thus verbatim the one that the Track Ingress
851 places in the packet encapsulation to reach the Track Ingress.
Example with picture would help.
853 6.4. Sibling Information Option
854
855 The Sibling Information Option (SIO) provides indication on siblings
856 that could be used by the Root to form Projected Routes. One or more
857 SIO(s) may be placed in the DAO messages that are sent to the Root in
858 Non-Storing Mode.
Is this some poor-mans (little signaling) form of signaling to help the
root do some topology discovery ? If so, then it probably would be something
that needs to go to the PCE, right ? Maybe this type of high level
explanation in the tex would be helpful. If i am guessing wrong then i even understand
less.
859
860 The format of the SIO is as follows:
861
862 0 1 2 3
863 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
865 | Type | Option Length |Comp.|B|D|Flags| Opaque |
866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
867 | Step of Rank | Reserved |
868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
869 | |
870 + +
871 . .
872 . Sibling DODAGID (if the D flag not set) .
873 . .
874 + +
875 | |
876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
877 | |
878 + +
879 . .
880 . Sibling Address .
881 . .
882 + +
883 | |
884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
885
886 Figure 8: Sibling Information Option Format
887
888 Option Type: 0x0D (to be confirmed by IANA)
You're maxing out your repeat offender penalty of illegal IANA code point misappropriation ;-)
890 Option Length: In bytes, the size of the option.
891
892 Compression Type: 3-bit unsigned integer. This is the SRH-6LoRH
901 Type as defined in figure 7 in section 5.1 of [RFC8138] that
902 corresponds to the compression used for the Sibling Address and
903 its DODAGID if resent. The Compression reference is the Root of
^ p ?
904 the main DODAG.
905
906 Reserved for Flags: MUST be set to zero by the sender and MUST be
907 ignored by the receiver.
908
909 B: 1-bit flag that is set to indicate that the connectivity to the
910 sibling is bidirectional and roughly symmetrical. In that case,
911 only one of the siblings may report the SIO for the hop. If 'B'
How would they do that (decide which one reports the SIO ?).
911 only one of the siblings may report the SIO for the hop. If 'B'
912 is not set then the SIO only indicates connectivity from the
913 sibling to this node, and does not provide information on the hop
914 from this node to the sibling.
I hope there is a simple way to do 'B' or more of a benefit than just cutting
down reporting data by 50%. Any standardized mechanism ?
916 D: 1-bit flag that is set to indicate that sibling belongs to the
917 same DODAG. When not set, the Sibling DODAGID is indicated.
918
919 Flags: Reserved. The Flags field MUST initialized to zero by the
^ be
920 sender and MUST be ignored by the receiver
921
922 Opaque: MAY be used to carry information that the node and the Root
923 understand, e.g., a particular representation of the Link
924 properties such as a proprietary Link Quality Information for
925 packets received from the sibling. An industrial Alliance that
926 uses RPL for a particular use / environment MAY redefine the use
927 of this field to fit its needs.
Is there a prior RPL example of such a field ? Pointer to that wold be
useful. I hav a hard time seeing how this would not result in all type of
misinterpretation unless the industrial alliance whose registration space
is to be used for Upaque is unambigously derivable from the device (type)
or link (type).
I would prefer to add MUST be set to 0 and be ignored upon receiving and
go on saying, IETF specification MUST NOT use or define this field, but
non-IETF specification may use it. Aka: why not give such external specs
the same starting ground (0-filled) that we give our own extension points.
But again: pre-existing examples of BCP spec text for such an Opaque field would
be helpful.
929 Step of Rank: 16-bit unsigned integer. This is the Step of Rank
930 [RPL] as computed by the Objective Function between this node and
931 the sibling.
932
933 Reserved: The Reserved field MUST initialized to zero by the sender
934 and MUST be ignored by the receiver
935
936 Sibling DODAGID: 2 to 16 bytes, the DODAGID of the sibling in a
937 [RFC8138] compressed form as indicated by the Compression Type
938 field. This field is present if and only if the D flag is not
939 set.
940
941 Sibling Address: 2 to 16 bytes, an IPv6 Address of the sibling, with
942 a scope that MUST be make it reachable from the Root, e.g., it
943 cannot be a Link Local Address. The IPv6 address is encoded in
944 the [RFC8138] compressed form indicated by the Compression Type
945 field.
956
957 An SIO MAY be immediately followed by a DAG Metric Container. In
^ "A for consonant start of TLA"
958 that case the DAG Metric Container provides additional metrics for
959 the hop from the Sibling to this node.
960
961 7. Projected DAO
Given how this section seems to describe what the title of the doc is,
maybe it should also be named that way "Root initiated routing state".
962
963 This draft adds a capability to RPL whereby the Root of a main DODAG
Define what a "main DODAG" is. I guess its a DODAG not created by the
mechanisms of this draft, but also: what are non-main DODAGs ? Or is the
opposite just the projected DAO ?
964 installs a Track as a collection of Projected Routes, using a
965 Projected-DAO (P-DAO) message to maintain each individual route. The
What is an individual route ?
966 P-DAO signals a collection of Targets in the RPL Target Option(s)
967 (RTO). Those Targets can be reached via a sequence of routers
968 indicated in a VIO. A P-DAO message MUST contain exactly one VIO,
969 which is either a SF-VIO or an SR-VIO, and MUST follow one or more
970 RTOs. There can be at most one such sequence of RTO(s) and an Via
971 Information Option. A track is identified by a tuple DODAGID,
^ in a P-DAO
Also, is "at most" correct ?
How about there MUST be exactly one sequece of one or more RTO followed vy one VIO ?
Or is it valid to have no RTO, or no VIO ?
972 TrackID and each route within a Track is indexed by a SegmentID.
So, IMHO, this whole section 7 needs to come before section 3, because it is
here where you start defining the functionality from higher layer, but then
section 3 goes into the encoding details. I observe that all RFCs i remember
have the order of starting wih the overall functionality and bring the encoding
details of messages later (but then i am forgetfull of what i have read and
also say this because as my comments before will show, i struggled to make
head & tails out of how the pieces fit together).
973
974 A P-DAO MUST be sent from the address of the Root that serves as
975 DODAGID for the main DODAG. It MUST be sent to a GUA or a ULA of
Expand GUA, ULA, provide reference for ULA, and/or add to initial list of terms in doc.
976 either the ingress or the egress of the Segment, more below. If the
977 'K' Flag is present in the P-DAO, and unless the P-DAO does not reach
978 it, the ingress of the Segment is the node that acknowledges the
979 message, using a DAO-ACK that MUST be sent back to the address that
980 serves as DODAGID for the main DODAG.
Sentence too convoluted. Try to make two out of it.
You are not using the same term here as in 974, so this makes one wonder if
the DAO-ACK is to be sent back to the same address it was sent from or not.
If it is meant to be sent back to the same address, why not say "sent back to
the address of the root, which the P-DAO was sent from".
982 Like a classical DAO message, a P-DAO causes a change of state only
983 if it is "new" per section 9.2.2. "Generation of DAO Messages" of
984 the RPL specification [RPL]; this is determined using the Segment
985 Sequence information from the VIO as opposed to the Path Sequence
^ in the P-DAO
986 from a TIO. Also, a Segment Lifetime of 0 in a VIO indicates that
^ in the DAO.
987 the projected route associated to the Segment is to be removed.
988
989 There are two kinds of operation for the Projected Routes, the
990 Storing Mode and the Non-Storing Mode.
991
992 * The Non-Storing Mode is discussed in Section 7.3.2. A Non-Storing
993 Mode P-DAO carries an SR-VIO with the loose list of Via Addresses
^ steering
994 that forms a source-routed Segment to the Track Egress. The
995 recipient of the P-DAO is the Track Ingress; it MUST install a
996 source-routed state to the Track Egress and reply to the Root
997 directly using a DAO-ACK message if requested to.
998
999 * The Storing Mode is discussed in Section 7.3.1. A Storing Mode
1000 P-DAO carries a SF-VIO with the strict list of Via Addresses from
^n ^ steering
1001 the ingress to the egress of the Segment in the data path order.
1002 The routers listed in the Via Addresses, except the egress, MUST
1003 install a routing state to the Target(s) via the next Via Address
1004 in the SF-VIO. In normal operations, the P-DAO is propagated
1013 along the chain of Via Routers from the egress router of the path
1014 till the ingress one, which confirms the installation to the Root
1015 with a DAO-ACK message.
In 976 you point to further below as to where the P-DAO is to be sent. But hen
in the bullet points 992 and 999 you do not explicitly say tha the SR-VIO is sent
to the track ingres and that the SF-VIO is sent to the track egres. Please
add such sentences accordingly.
I think the description of ACK processing from 976++ fits better here after, given
how its an additional detail happening after the P-DAO is processed according
to the two bullet points above.
Q: If in the SF-VIO case, the egress does not install any state, then why send
the P-DAO to it instead of to the pre-ultimate hop ? Explanation might be helpful
in the text.
1016
1017 In case of a forwarding error along a Projected Route, an ICMP error
Arre we talking about the forwaring of data packets that are following a projected route,
or processing error of the P-DAO ? Please be specific. An example of a forwarding
error would help.
I suspect it is the data packets. Is there also any other error for processing of
the P-DAO other than missing ACK ? Aka: wha exactly happens in the duplicate address
in VIO If lets say the root was too stsupid to figure it out ?
1018 is sent to the Root with a new Code "Error in Projected Route" (See
1019 Section 11.13). The Root can then modify or remove the Projected
1020 Route. The "Error in Projected Route" message has the same format as
1021 the "Destination Unreachable Message", as specified in RFC 4443
1022 [RFC4443].
1023
1024 The portion of the invoking packet that is sent back in the ICMP
1025 message SHOULD record at least up to the RH if one is present, and
1026 this hop of the RH SHOULD be consumed by this node so that the
^^^^ ^^^^
which hop ? The hop that has problems and wants to generate the ICMP error?
1027 destination in the IPv6 header is the next hop that this node could
1028 not reach. if a 6LoWPAN Routing Header (6LoRH) [RFC8138] is used to
So ultimately, you want the root to be able to figure out from the ICMP,
which nodeA can not reach a next-hop nodeB, right ? WOuld be good to say that,
but the description of how to achieve this by messing with the ICMP error
reported original packet stub still escapes me. Is that "consumed by" procedure
already done some place else ? If so, hen a reference to prior way how this is
done would be good. If not, then elaborating a bit more to make it easier to
understand would help.
1028 not reach. if a 6LoWPAN Routing Header (6LoRH) [RFC8138] is used to
1029 carry the IPv6 routing information in the outer header then that
1030 whole 6LoRH information SHOULD be present in the ICMP message.
How would a root then figure out nodeA/nodeB ?
1031
1032 The sender and exact operation depend on the Mode and is described in
1033 Section 7.3.2 and Section 7.3.1 respectively.
1034
1035 7.1. Requesting a Track
1036
1037 A Node is free to ask the Root for a new Track for which it will be
1038 Ingress at any time. This is done with a PDR message, that indicates
for which it wants to be ingres ? E.g.: no idea what "will be at any time" means.
1039 the desired TrackID and the duration for which the Track should be
1040 established. Upon a PDR, the Root MAY install the necessary
An example of why the node would generate it, and where it has the TrackID from
would help here.
1041 Segments, in which case it answers with a PDR-ACK indicating the
1042 granted Track Lifetime. All the Segments MUST be of a same mode,
1043 either Storing or Non-Storing. All the Segments MUST be created with
1044 the same TrackID and the same DODAGID signaled in the P-DAO.
1045
1046 The Root is free to design the Track as it wishes, and to change the
1047 Segments overtime to serve the Track as needed, without notifying the
1048 resquesting Node. The Segment Lifetime in the P-DAO messages does
^
Presumably, a requesting node would likely also be the ingres of one P-DAO of
the track, right ? But establishment of the track via P-DAO is only related to
the PDR/PDR-ACK in the root ?
Might be useful to have some place a higher level description of "initiation" models,
and point to it. Aka: the way i figure, initiation can come from PCE and go through root,
no other nodes involved. Or it comes somehow via PDR initiaor... but how/why.
Also "free to " is a bit of a misnomer, right ? Aka: If the root is free, then it
should also be able to notify the requesting node, but there really is no other
notification than acknowledging in PDR-ACK acceptance to take care of the request
or to indicate failure of it. Aka, write maybe: "The root designs the Track as it wishes....
there are no notifications to the requesting node when changing the track".
1049 not need to be aligned to the Requested Lifetime in the PDR, or
1050 between P-DAO messages for different Segments. The Root may use
1051 shorter lifetimes for the Segments and renew them faster than the
1052 Track is, or longer lifetimes in which case it will need to tear down
1053 the Segments if the Track is not renewed.
1054
1055 When the Track Lifetime that was returned in the PDR-ACK is close to
1056 elapse, the resquesting Node needs to resend a PDR using the TrackID
1057 in the PDR-ACK to extend the lifetime of the Track, else the Track
1058 will time out and the Root will tear down the whole structure.
How close ? Any guidance ?
1068
1069 If the Track fails and cannot be restored, the Root notifies the
1070 resquesting Node asynchronously with a PDR-ACK with a Track Lifetime
^
1071 of 0, indicating that the Track has failed, and a PDR-ACK Status
1072 indicating the reason of the fault.
1073
1074 7.2. Identifying a Track
1075
1076 RPL defines the concept of an Instance to signal an individual
1077 routing topology but does not have a concept of an administrative
1078 distance, which exists in certain proprietary implementations to sort
1079 out conflicts between multiple sources of routing information within
1080 one routing topology.
1081
1082 This draft leverages the RPL Instance model as follows:
... to sort out conflicts between multiple sources of routing information ??
aka: tie the text together, the way it is written it is confusing.
It also seems as if it would be better to high level answer how P-DAO avoids
the need for administrative distances here, instead of letting readers try to figure it
out from all the details of the following bullet points, because those bullet points
explain a lot more, so the whole administative distance stuff will get lost.
The way i see it is that P-DAO do not require administrative distance because
a) They will be preferred because of prefixlength vs. default route to root when
used within pre-existing RPLinstance.
b) They can be explicitly indicated through their own RPLinstance called TrackID
in the RPL packet header, therefore not colliding with routes from pre-existing
RPLinstances.
1083
1084 * The Root MAY use P-DAO messages to add better routes in the main
1085 (Global) Instance in conformance with the routing objectives in
1086 that Instance. To achieve this, the Root MAY install an Storing-
What actually happens if those P-DAO routes are not in conformance with the routing
objectives of that instance ? Anything worse than that the routing objective does
not well express what the routes are doing ?
I am asking, because i would assume that the routing objectives likely will never
be able to express all the characteristics that may come out of a bunch of Tracks.
Therefore i fear that this conformance sentence is somewhat career limiting to
P-DAOs.
But i am not sure about the overall framework. Is there some form of policy framework,
whereby traffic may choose one out of multiple instances, and what you really want
to say is that Tracks should be assigned to the track that best matches what the
Track attempts to improve upon so that traffic choosing one out of multiple
insances can continue to do so, and track will improve the desired outcome ?
Aka: Motivating this setnence, maybe in the way i am imagining it (if correct) might
help. And it might also better capture the goal of choosing a particular instance
for a track than referring to the formal routing objectives instead of maybe
the informal intent of an instance, which may be constituted from the routing
objectives of DAOs and the traffic engineered objectives of P-DAOs.
1086 that Instance. To achieve this, the Root MAY install an Storing-
^ just a - storing is spoken with consonant first.
1087 Mode P-Route along a path down the main Non-Storing Mode DODAG.
1088 This enables a loose source routing and reduces the size of the
1089 Routing Header, see Appendix A.1.
1090
1091 When adding an Storing-Mode P-Route to the main RPL Instance, the
^ just a
1092 Root MUST set the RPLInstanceID field of the P-DAO message (see
1093 section 6.4.1. of [RPL]) to the RPLInstanceID of the main DODAG,
1094 and MUST NOT use the DODAGID field. A Projected Route provides a
Whats the significance of the DODAGID here ? What would happen if it was set ?
1095 longer match to the Target Address than the default route via the
1096 Root, so it is preferred.
1097
1098 Once the Projected Route is installed, the intermediate nodes
1099 listed in the SF-VIO after first one (i.e. The ingress) can be
1100 elided from the RH in packets sent along the Segment signaled in
1101 the P-DAO. The resulting loose source routing header indicates
1102 (one of) the Target(s) as the next entry after the ingress.
1103
1104 * The Root MAY also use P-DAO messages to install a specific (say,
1105 Traffic Engineered) path as a Serial or as a Complex Track, to a
Serial Track and Complex Track are not defined/explained yet. See comments
earlier that you need to start off with pictured examples from which to
much more easily define such terms.
1106 particular endpoint that is the Track Egress. In that case, the
1107 Root MUST install a Local RPL Instance (see section 5 of [RPL]),
1108 and the Local RPLInstanceID is called TrackID.
Do i need a separate RPL instance to loosely tie together multiple sequential
SF-VIO ? Lets say i have 20 hops in stateless. I figure i have 3 segments of
5 hops each that ae often used. So i establish separate tracks for each of
them, and then my routing headers in the future would be able to be reduced
by 3 * 5 = 15 hops, aka: having 3 loose hops tied together by 5 strict hops.
1109
1110 In that case, the TrackID MUST be unique for the Global Unique
1111 IPv6 Address (GUA) or Unique-Local Address (ULA) of the Track
You where missing those expansions in before, so here they would now be redundant
when you fix them up in before.
1112 Ingress that serves as DODAGID for the Track. The Track Ingress
1113 owns the namespace of its TrackIDs, so it can pick any unused
1114 value to request a new Track with a PDR. The Root is aware of all
The root of the main DODAG, or main RPL instance or the like ? Aka: There may be
multiple roots for different instances/dodags, right ?
1115 the active Tracks, so it can also pick any unused value to form
1116 Tracks without a PDR. To avoid a collision of the Root and the
1125 Track Ingress picking the same value at the same time, it is
1126 RECOMMENDED that the Track Ingress starts allocating the ID value
1127 of the Local RPLInstanceID (see section 5.1. of [RPL]) used as
1128 TrackIDs with the value 0 incrementing, while the Root starts with
1129 63 decrementing.
1131 This way, a Track is uniquely identified by the tuple (DODAGID,
1132 TrackID) where the TrackID is always represented with the D flag
1133 set to 0.
Explain where the D flag is, first time i think its used in the text.
I think i may be confused about the namespace and its limitations or at least
not well educaed by the text ;-)
So the track ingres IPv6 serves as DODAGID. So every node can have up to 64 - N Tracks,
where N is the number of non-rack RPL instances for which the node is the root ?
Would be good to write this out explicitly (or accordingly corrected if wrong).
1135 The Track Egress Address and the TrackID MUST be signaled in the
1136 P-DAO message as shown in Figure 1.
1137
1138 7.3. Installing a Track
1139
1140 A Storing-Mode P-DAO contains an SF-VIO that signals the strict
1141 sequence of consecutive nodes to form a segment between a segment
1142 ingress and a segment egress (both included). It installs a route of
1143 a higher precedence along the segment towards the Targets indicated
1144 in the Target Options. The segment is included in a DODAG indicated
Ok, now i am getting confused again by this text.
"higher precendence - than what ? Also, is there a definition of precedence in the
context of RPL ? If so, reference to definition would be good.
Previously you only used precedence related to priority to store/maintain
a route, which i guess is a differrent meaning of the word than here.
In 7.2, it sounded as if there would be no pre-existing route to the target
other than through the root because of prefix-length. If that is what you mean
here, and unless precedence has a well defined meaning, maybe just replace precedence
with prefix-length.
It is also not quite clear to me if tracks can never be installed into storing-mode
RPL instances where they could not conflict with equal-prefix-length "native" routes.
AFAIK, the spec only said the main RPLinstance must be non-storing mode. Can there nit
be other, storing mode RPL instances ?
But of course, i am likely confused...
1144 in the Target Options. The segment is included in a DODAG indicated
1145 by the P-DAO Base Object, that may be the one formed by the main RPL
1146 Instance, or a Track associated with a local RPL Instance. A Track
1147 Egress is signaled as a Target in the P-DAO, and as the last entry is
1148 an SF-VIO of a last segment towards that Egress.
1149
1150 A Non-Storing-Mode P-DAO signals a strict or loose sequence of nodes
^ contains an SR-VIO to...
1151 between the Track Ingress (excluded) and a Track Egress (included).
1152 It installs a source-routed path of a higher precedence within the
^^^^^^^^^^ same consideration as above
1153 Track indicated by the P-DAO Base Object, towards the Targets
1154 indicated in the Target Options. The source-routed path requires a
1155 Source-Routing header which implies an encapsulation to add the SRH
^^^^^^^^^^^
Same consideration as much earlier, e.g.: encapsulate into new IPv4 with SRH ?!
1156 to an existing packet.
1157
1158 The next entry in the sequence must be either a neighbor of the
1159 previous entry, or reachable as a Target via another Projected Route,
1160 either Storing or Non-Storing. If it is reachable over a Storing
1161 Mode Projected Route, the next entry in the loose sequence is the
1162 Target of a previous segment and the ingress of a next segment; the
1163 segments are associated with the same Track, which avoids the need of
1164 an encapsulation. Conversely, if it is reachable over a Non-Storing
1165 Mode Projected Route, the next loose source routed hop of the inner
1166 Track is a Target of a previous Track and the ingress of a next
1167 Track, which requires a de- and a re-encapsulation.
This is a game of blindfold chess. Pictured examples of the two cases described
would help a lot to understand and verify the points made/claimed here.
1181 A Serial Track is installed by a single Projected Routes that signals
^
1182 the sequence of consecutive nodes, either in Storing or Non-Storing
1183 Mode. If can be a loose Non-Storing Mode Projected Route, in which
^
1184 case the next loose entry must recursively be reached over a Serial
1185 Track.
Please check whats standard *-Storing-Mode or *-Storing Mode - and make text
consistent.
1186
1187 A Complex Track can be installed as a collection of Projected Routes
1188 with the same DODAGID and Track ID. The Ingress of a Non-Storing
If this is turned around, does it become the still missing definition of a
complex track ?
Multiple projected routes can be installed into a single (DODAGID,TrackID).
This leads to Sequential or Complex Tracks ??
1188 with the same DODAGID and Track ID. The Ingress of a Non-Storing
1189 Mode Projected Route must be the owner of the DODAGID. The Ingress
1190 of a Storing Mode Projected Route must be either the owner of the
1191 DODAGID, or the egress of a preceding Storing Mode Projected Route in
1192 the same Track. In the latter case, the Targets of the Projected
1193 Route must be Targets of the preceding Projected Route to ensure that
1194 they are visible from the track Ingress.
1195
1196 7.3.1. Storing-Mode P-Route
Please go back through the text and replace all instances of Projected Route
after the first occurance with P-Route. You use both terms randomnly interchanged,
which is confusing. Better to stick to the abbreviation only.
I also observe, that i would be much less confused about the text if this high-level
explanation was preceeding the detailed explanation earlier in the beginning of section 7.
Please think how to resort the text of section 7 so it starts with the pictures
and high-level explanation and then goes into the more formal detail spec.
1198 Profile 1 extends RPL operation in a Non-Storing Mode network with
Without further explanation, the first unexplained use of Profile is derailing and
confusing. Suggest to just delete the mentioning of profiles and just define them
in Section 8.
1199 Storing-Mode Projected Routes that install segments along the main
1200 DODAG and enable to loose source routing between the Root and the
1201 targets.
1202
1203 7.3.1.1. Installing a Storing-Mode P-Route
1204
1205 As illustrated in Figure 9, a P-DAO that carries a SF-VIO enables the
1206 Root to install a stateful route towards a collection of Targets
1207 along a Segment between a Track Ingress and a Track Egress using a
1208 projected DAO Message.
1209
1210 ------+---------
1211 | Internet
1212 |
1213 +-----+
1214 | | Border Router
1215 | | (RPL Root)
1216 +-----+ | ^ |
1217 | | DAO | ACK |
1218 o o o o | | |
1219 o o o o o o o o o | ^ | Projected .
1220 o o o o o o\ o o o o | | DAO | Route .
1221 o o o o \o--o o o o | ^ | .
1222 o o o o o \o o o v | DAO v .
1223 o o LLN T1 T2 o |
1224 o o o o o Loose Source Route Path |
1225 o o o o From Root To Destination v
1226
1227 Figure 9: Projecting a route
Do you think you can visualise an example P-route into the picture ?
I started a bit of bit of it above..
1228
1237 In order to install the relevant routing state along the Segment ,
1238 the Root sends a unicast P-DAO message to the Track Egress router of
1239 the routing Segment that is being installed. The P-DAO message
1240 contains a SF-VIO with the direct sequence of Via Addresses. The SF-
^^^^^^ strict
1241 VIO follows one or more RTOs indicating the Targets to which the
1242 Track leads. The SF-VIO contains a Segment Lifetime for which the
In this explanation it would be helpful to explain conditions for targets, e.g.:
Target must either be direc neighbor of the P-Route egres, or be Target of some
P-Route2 with the P-Route egres as its ingres. Right ?
1243 state is to be maintained.
1244
1245 The Root sends the P-DAO directly to the egress node of the Segment.
1246 In that P-DAO, the destination IP address matches the last Via
1247 Address in the SF-VIO. This is how the egress recognizes its role.
1248 In a similar fashion, the ingress node recognizes its role as it
1249 matches first Via Address in the SF-VIO.
1250
1251 The Egress node of the Segment is the only node in the path that does
1252 not install a route in response to the P-DAO; it is expected to be
1253 already able to route to the Target(s) on its own. If one of the
1254 Targets is not known, the node MUST answer to the Root with a
1255 negative DAO-ACK listing the Target(s) that could not be located
1256 (suggested status 10 to be confirmed by IANA).
So complex/sequential Tracks need to be established from destination to source.
What happens with a track when th egress looses routing information for a destination ?
(if thats answere elsehwhere, a pointer to that section would be helpfull here).
1258 If the egress node can reach all the Targets, then it forwards the
1259 P-DAO with unchanged content to its loose predecessor in the Segment
Shouldn't that be strict instead of loose ? If it was loose, how would that loose
predecessor know how to send the data packets to the successor without adding
another encap/RH if the underlying main RPL instance was NSM ?
1260 as indicated in the list of Via Information options, and recursively
1261 the message is propagated unchanged along the sequence of routers
1262 indicated in the P-DAO, but in the reverse order, from egress to
1263 ingress.
1264
1265 The address of the predecessor to be used as destination of the
1266 propagated DAO message is found in the Via Address the precedes the
1267 one that contain the address of the propagating node, which is used
1268 as source of the message.
1269
1270 Upon receiving a propagated DAO, all except the Egress Router MUST
1271 install a route towards the DAO Target(s) via their successor in the
1272 SF-VIO. The router MAY install additional routes towards the VIA
1273 Addresses that are the SF-VIO after the next one, if any, but in case
1274 of a conflict or a lack of resource, the route(s) to the Target(s)
1275 have precedence.
1276
1277 If a router cannot reach its predecessor in the SF-VIO, the router
1278 MUST answer to the Root with a negative DAO-ACK indicating the
1279 successor that is unreachable (suggested status 11 to be confirmed by
1280 IANA).
1281
1282 The process continues till the P-DAO is propagated to ingress router
^until
1283 of the Segment, which answers with a DAO-ACK to the Root. The Root
1284 always expects a DAO-ACK, either from the Track Ingress with a
1293 positive status or from any node along the segment with a negative
1294 status. If the DAO-ACK is not received, the Root may retry the DAO
1295 with the same TID, or tear down the route.
1296
1297 7.3.1.2. Maintaining and Tearing Down a Storing-Mode P-Route
1298
1299 A Segment Lifetime of 0 in a VIO is used to clean up the state. The
^
P-route state
1300 P-DAO is forwarded as described above, but the DAO is interpreted as
1301 a No-Path DAO and results in cleaning up existing state as opposed to
1302 refreshing an existing one or installing a new one.
1303
1304 Note that the continuity of the segment may be broken; this happens
1305 if the bidirectional connectivity between contiguous hops of the
1306 segment is lost. In that case the Root needs to send the projected
1307 DAO to one or more intermediate node(s) as opposed to the egress
1308 node, indicating a portion of segment that is being replaced or
1309 cleaned up. At the extreme, the P-DAO updates only one node, in
1310 which case it contains only one VIO.
Hmm... how does this work given how the egres is meant to not install route state,
so if you want to fix up some intermediate segments, then the egres of that
fixup VIO, which is not the final egres of the full VIO would from the prior
explanation have to invoke its function of checking the targets reachability,
but not to establish storing mode state. Some more explanation here might be
helpful. I think his can work, but i think the egres of a fixup VIO needs to
be careful and behave differently to a non-fixup actual track egres.
1311
1312 In case of a forwarding error along an Storing-Mode P-Route, the node
1313 that fails to forward SHOULD send an ICMP error with a code "Error in
1314 Projected Route" to the Root. Failure to do so may result in packet
1315 loss and wasted resources along the Projected Route that is broken.
1316
1317 7.3.2. Non-Storing-Mode P-Route
1318
1319 As illustrated in Figure 10, a P-DAO that carries an SR-VIO enables
1320 the Root to install a source-routed path from a Track Ingress towards
1321 a Target along the main DODAG.
1349
1349 ------+---------
1350 | Internet
1351 |
1352 +-----+
1353 | | Border Router
1354 | | (RPL Root)
1355 +-----+ | P ^ ACK
1356 | Track | DAO |
1357 o o o o Ingress X V | X
1358 o o o o o o o X o X Source
1359 o o o o o o o o X o o X Routed
1360 o o ° o o o o X o X Segment
1361 o o o o o o o o X Track X
1362 o o o o o Egress
1363
1364 o o o o
1365 o o o o
1366 destination
1367
1368 LLN
1369
1370 Figure 10: Projecting a Non-Storing Route
So there is some attempt here to visualize the P-Route, but it mentions destination
and not target, so i am again confused about the difference of those terms...
Would be good to show Target(s) in the picture.
1372 When forwarding a packet to a destination for which the router
which router ? The Track ingres ?
1373 determines that routing happens via a Track Target, the router
"via a track target" sounds as if destination is different from trac target.
What is the routing information from which that router can determine that
a destination is reachable via a target ? The P-Route only signals targets, right ?
1374 inserts the Source Routing Header in the packet with the final
1375 destination at the Track Egress.
encapsulates the packet with a new IPv6/SRH header ?
Now it sounds as if final destination is the same as track egres, so not even target...
even more confused now.
1376
1377 In order to signal the Segment, the router encapsulates the packet
1378 with an IP-in-IP header and a Routing Header as follows:
It seems as if we're not discussing installation of non-storing P-Routes at all,
but immediately skip to data-plane for non-storing P-Routes ?
I would suggest to have even if a very short section for installation of the non-storing
P-Route in one subsection and then aother subsection for the data-plane.
The storing mode text above does not seem to have a dedicated data-plane subsecton too,
so quite inconsistent...
1379
1380 * In the uncompressed form the source of the packet is this router,
this router...
1381 the destination is the first Via Address in the SR-VIO, and the RH
1382 is a Source Routing Header (SRH) [RFC6554] that contains the list
1383 of the remaining Via Addresses terminating by the Track Egress.
1384
1385 * The preferred alternate in a network where 6LoWPAN Header
1386 Compression [RFC6282] is used is to leverage "IPv6 over Low-Power
1387 Wireless Personal Area Network (6LoWPAN) Paging Dispatch"
1388 [RFC8025] to compress the RPL artifacts as indicated in [RFC8138].
1389
1390 In that case, the source routed header is the exact copy of the
1391 (chain of) SRH-6LoRH found in the SR-VIO, also terminating by the
1392 Track Egress. The RPI-6LoRH is appended next, followed by an IP-
1393 in-IP 6LoRH Header that indicates the Ingress Router in the
1394 Encapsulator Address field, see as a similar case Figure 20 of
1395 [TURN-ON_RFC8138].
I will trust this is correct, as i can not verify this quickly due to my lack of
this encap details.
1404
1405 In the case of a loose source-routed path, there MUST be either a
1406 segment for the same Track to the loose next hop, on which case the
1407 packet is forwarded to the next hop along that segment, a common
1408 neighbor with the loose next hop, on which case the packet is
1409 forwarded to that neighbor, or another Track to the loose next hop
1410 for which this node or a neighbor is Ingress. In the latter case,
1411 another encapsulation takes place and the process possibly recurses;
1412 otherwise the packet is dropped.
I can not comment on this because i am still lost as to the semantic of segment given
he absence of any illustrative pictures for multi-segment Tracks so far in the document.
1414 In case of a forwarding error along a Source Route path, the node
1415 that fails to forward SHOULD send an ICMP error with a code "Error in
1416 Source Routing Header" back to the source of the packet, as described
1417 in section 11.2.2.3. of [RPL]. Upon this message, the encapsulating
1418 node SHOULD stop using the source route path for a period of time and
How long should that period be. Elaborate for how the encapsulating node
should determine the period.
1419 it SHOULD send an ICMP message with a Code "Error in Projected Route"
1420 to the Root. Failure to follow these steps may result in packet loss
1421 and wasted resources along the source route path that is broken.
1422
1423 7.4. Forwarding Along a Track
In 7.3.2 you already detail parts of this. Again, i would strongly suggest
to revert order, with this section first, before getting into the currently
earlier stated details.
1425 This draft leverages the RPL Forwarding model follows:
1426
1427 * In the data packets, the Track DODAGID and the TrackID MUST be
1428 respectively signaled as the IPv6 Source Address and the
1429 RPLInstanceID field of the RPI that MUST be placed in the outer
1430 chain of IPv6 Headers.
I think an outer chain(mail) can be found as an armor on medieval knights, but in our
case i think it is the outer header of the packets chain of IPv6 headers.
1432 The RPI carries a local RPLInstanceID called the TrackID, which,
1433 in association with the DODAGID, indicates the Track along which
1434 the packet is forwarded.
1435
1436 The D flag in the RPLInstanceID MUST be set to 0 to indicate that
1437 the source address in the IPv6 header is set ot the DODAGID, more
^^
1438 in Section 7.4.
This is section 7.4.
1439
1440 * This draft conforms the principles of [USEofRPLinfo] with regards
^ to
1441 to packet forwarding and encapsulation along a Track.
1442
1443 - In that case, the Track is the DODAG, the Track Ingress is the
In the case where the Track is the main DODAG ... ?
1444 Root, and the Track Egress is a RAL, and neighbors of the Track
Is there any reason why to say RAL instead of node ? First time you use RAL, so wondering.
1445 Egress that can be reached via the Track are RULs. The
1446 encapsulation rules in [USEofRPLinfo] apply.
Not sure what RFC editor says, but given how RAL/RUL are first mentioned here,
even though they are listed in glossary, expanding them here can not hurt.
I think you may want to find a place early in he document where you want to say
that "node" without qualification in this doc mean RAN, maybe also add to glossary.
It would be helpfull to clariy what i think this section wants to say without hoping that
readers can / want to deduce it from [UseofRPLinfo]. How about the following table:
Node role Supported node type
Track ingres RAN
Track midpoint RAN
Track egres RAN, RAL
Neighbor of track egres RAN, RAL, RUL
(hope this is roughly ok, else fix up).
1448 - If the Track Ingress is the originator of the packet and the
1449 Track Egress is the destination of the packet, there is no need
1450 for an encapsulation.
1451
1459
1460
1461 - So the Track Ingress must encapsulate the traffic that it did
1462 not originate, and add an RPI in any fashion.
1463
1464 A packet that is being routed over the RPL Instance associated to
1465 a first Non-Storing Mode Track MAY be placed (encapsulated) in a
1466 second Track to cover one loose hop of the first Track. On the
I can not follow this explanation without an example picture. When reading it,
the first thing that comes to mind is that it sounds as if i could have sequential
second Tracks in different RPL Instances, but it is unclear whether this is
is a predondition of this case of whether its irrelevant.
1466 second Track to cover one loose hop of the first Track. On the
1467 other hand, a Storing Mode Track must be strict and a packet that
1468 it placed in a Storing Mode Track MUST follow that Track till the
:%s/\<till\>/until/g
Don't speak emacs.
1469 Track Egress.
1470
1471 When a Track Egress extracts a packet from a Track (decapsulates
1472 the packet), the Destination of the inner packet MUST be either
1473 this node or a direct neighbor, or a Target of another Segment of
1474 the same Track for which this node is ingress, otherwise the
1475 packet MUST be dropped.
.... and (see reference) ICMP must be raied according to... etc. pp ?!
This last paragraph should really be as early in the document as possible.
1476
1477 All properties of a Track operations are inherited form the main RPL
1478 Instance that is used to install the Track. For instance, the use of
1479 compression per [RFC8138] is determined by whether it is used in the
1480 main instance, e.g., by setting the "T" flag [TURN-ON_RFC8138] in the
1481 RPL configuration option.
Can there be multiple main instances ? If so, that should be mentioned and
maybe an example given.
1482
1483 8. Profiles
1484
1485 This document provides a set of tools that may or may not be needed
1486 by an implementation depending on the type of application it serves.
1487 This sections described profiles that can be implemented separately
1488 and can be used to discriminate what an implementation can and cannot
1489 do.
1490
1491 Profile 0 Profile 0 is the legacy support of [RPL] Non-Storing Mode.
1492 It provides the minimal common functionality that must be
1493 implemented as a prerequisite to all the Track-supporting
1494 profiles. The other Profiles extend Profile 0 with selected
1495 capabilities that this specification introduces on top.
Is this profile a term estblished outside this document already, then please
do provide reference. If it is only introuced in this document, then what
exactly needs to be implemented for it ?
Let me guss: This is a new definition in this document, and it refers to nodes
that do not implement anything from this draft, but only RPL NSM acccording to
(fill in, best with section), and to deploy any of this documents technology,
ALL RAL in the network MUST implement Profile 0 or better. Or maybe not...
Maybe only RAL that are used to pass P-Route traffic MUST be Profile 0 or better ?!
If i am guessing right than my prior paragraphs text might be a better starting
point with less gussing.
1496
1497 Profile 1 (Storing-Mode P-Route Segments along the main DODAG) Profi
1498 le 1 does not create new paths; it combines Storing and Non-
1499 Storing Modes to balance the size of the routing header in the
1500 packet and the amount of state in the intermediate routers in a
1501 Non-Storing Mode RPL DODAG.
You should be able to state exactly what part of this spec a node MUST/SHOULD
implement to be in compliance with Profile 1. Same is true for the other profiles.
Might be difficult to structure the documents into subsections such that
you can list those subsections that are required (incrementally) for each Profile,
but otherwise its really hard to figure out if or if not an implementation is
compliant with a profile.
1503 Profile 2 (Non-Storing-Mode P-Route Segments along the main DODAG) P
1504 rofile 2 extends Profile 0 with Strict Source-Routing Non-Storing-
Can you try to persuade tools to not split words (P rofile) ?
1505 Mode Projected Routes along the main DODAG. Profile 2 provides
1506 the same capability to compress the SRH in packets down the main
1507 DODAG as Profile 1, but it require an encapsulation, in order to
1508 insert an additional SRH between the loose source routing hops.
1509
1517 Profile 3 Profile 3 and above build Tracks that do not necessarily
1518 follow the main DODAG. In order to form the best path possible,
^ ?
DODAG ? "best possible" is unexplained. Might be good to give (maybe textual is
sufficient) the most simple example of how an additional DODAG/TrackID would
be limited if it can not support Sibling Information Option. This might be
obvious to RPL experts of course..
1519 those Profiles require the support of Sibling Information Option
1520 to inform the Root of additional possible hops. Profile 3 extends
1521 Profile 1 with additional Storing-Mode Projected Routes that
1522 install segments that do not follow the main DODAG. If the
1523 Segment Ingress (in the SF-VIO) is the same as the IPv6 Address of
1524 the Track Ingress (in the projected DAO base Object), the P-DAO
1525 creates an implicit Track between the Segment Ingress and the
1526 Segment Egress.
1527
1528 Profile 4 Profile 4 extends Profile 2 with Strict Source-Routing
1529 Non-Storing-Mode Projected Routes to form Tracks inside the main
1530 DODAG. A Track is formed as one or more strict source source
1531 routed paths between the Root that is the Track Ingress, and the
1532 Track Egress that is the last node
Why is this Profile 4 when Profile 3 says that all further profiles
do not necessarily follow the main DODAG ? Aka: What would not work if
you where to make 4 become eg.: 2.5 ?
1534 Profile 5 Profile 5 Combines Profile 4 with Profile 1 and enables to
1535 loose source routing between the Ingress and the Egress of the
1536 Track. As in Profile 1, Storing-Mode Projected Routes connect the
1537 dots in the loose source route.
1538
1539 Profile 6 Profile 6 Combines Profile 4 with Profile 2 and also
1540 enables to loose source routing between the Ingress and the Egress
1541 of the Track.
How about a table where rows are features, columns profiles and intersections
checkmarks ? Right now i am lost in the details.
1542
1543 9. Example Track Signaling
1544
1545 The remainder of the section provides an example of how a Track can
1546 be signaled
1547
1548 ===> F
1549 A ===> B ===> C ===> D===> E <
1550 ===> G
1551
1552
1553 Figure 11: Reference Track
1554
1555 A is Track ingress, E is track Egress. C is stitching point. F and
First time "stitching point" is used. Can you avoid a new term here ? Else explain.
1556 G are E's neighbors, "external" to the Track, and reachable from A
1557 over the Track A->E.
I guess this is a two-segment Track with one segment A-...>C and one segment C-...>E.
What is the "<" after E good for ?
Why use the same symbol ===> for track and for getting from E to F, G ?
Are F and G Targets and/or destinations ? Please introduce those terms into the example.
How about indicating both the physical connectivity with "---" and the track with "===>"
Also show / disinguish the two segments accordingly through better ASCII graphics.
1558
1559 In a general manner we want:
1560
1561 * P-DAO 1 signals C==>B==>E
I hope B should be D, else i am heck more confused.
Please say what this signaling establishes. We learned in before that a P-DAO
has not only a VIO, but also some targets. So what are the targets of this P-DAO ?
1562
1563 * P-DAO 2 signals A==>B==>C
Likewise
1573 * P-DAO 3 signals F and G via the A==>E Track
What does hthis mean ? Whats the entry, whats the exit ? whats the VIO, whats the
target of P-DAO 3 ?
1575 P-DAO 3 being loose, it can only be non-storing. Note that since the
1576 Root is always the ingress of a Track, and all SR-VIOs are now Track,
^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^
Which root ? the root of the main DODA ?
I don't parse the second ^^^^ either.
1577 the Root being signaled in the DAO base object can now be elided in
1578 the VIA list in SR-VIO. This enables the construction by the main
1579 root of the RFC 8138 optimized SRH-6LoRH in the SR-VIO, to be placed
1580 as is in the packet by the Root.
I can not follow that paragraph. Would it be posible to constrain the example
to not also include the SRH-6LoRH complexity, given how its an option ? One
step at a time ?
1581
1582 9.1. Using Storing-Mode Segments
1583
1584 A==>B==>C and C==>D==>E are segments of a same Track. Note that the
See above. his explanation comes too late.
1585 storing mode signaling imposes strict continuity in a segment. One
^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^ steering
So i am confused if actually the storing mode signaling imposes that strict
steering. I guess if i start from the egres, and it wants to forward the P-DAO
to the prior hop node in the VIO, if that prior hop is a neighbor, then it
would send the P-DAO directly to that neighbor, but if it is not a direct
neighbor, it would need to go through the root. I guess this is 101 knowledge
from RFC6550, so if i had the time to read anothe 150 pages, i might be able
to deduce that, but i guess it wouldn't hurt to put the same explanation into
th text, e.g.: P-DAO must be sent directly from each segment node to its
prior segment node, and in a non-storing DODAG, this is only possible if
they are neighbors.
Also:
One of the fundamental explanations missing is the definition of the relationship
between a segment and a P-Route. The way i figure, a P-DAO is (segment, {targets})
and represents a set of P-routes { targetI -> segment } targetI in {targets}).
And then definition of tracks as composed of sequences of P-routes constructed
from likely trees of P-DAO
Or something like that...
1586 benefit of strict routing is that loops are avoided along the Track.
As long as the underlying topology does not change and direct neigbors start
to becom non-diret neighbors. In which case i think the segment wold need
to be immediately invalidated. But the question raised in before about
ICMP errors is valid, especially when i think about path divesity forwarding.
In path diversity you often do NOT want to have traffic triggered errors, but
jus sit out the error, even if that trafic gets dropped somehwere along the path.
Any desirable repair to do on the topolocy could/should come ffom non-traffic
trigers, such as neighbor tracking to the management plane.
Is there any way for traffic itself in the Routing information header to indicate
if it does or does not want to get ICMP indications when it fails to get forwarded ?
That would be ideal to distingish between non-redundant and redundant traffic
ICMP reaction...
1587
1588 9.1.1. Stitched Segments
Sequential ?
1589
1590 Storing-Mode P-DAO 1 and 2 are sent to E and C, as follows:
1591
1592 +===============+==============+==============+
1593 | Field | P-DAO 1 to E | P-DAO 2 to C |
1594 +===============+==============+==============+
1595 | Mode | Storing | Storing |
1596 +---------------+--------------+--------------+
1597 | Track Ingress | A | A |
1598 +---------------+--------------+--------------+
1599 | TrackID | (A, 129) | (A, 129) |
1600 +---------------+--------------+--------------+
1601 | VIO | C, D, E | A, B, C |
1602 +---------------+--------------+--------------+
1603 | Targets | E, F, G | E, F, G |
1604 +---------------+--------------+--------------+
1605
1606 Table 1: P-DAO Messages
Please add a line showing the SegmentID of the VIO so its clear how
the P-DAO are distinguished. I guess that is the identifier used, right ?
If this example is pimped up as asked for above, it would make a good
intro example, although it does not cover all options. But at last the
fact that the track ingres for the secnd (C,D,E) segment is still A
was not clear to me in before.
Also, i guess that if the track was more of a tree, then the targets
of some earlier segments wold be a superset of the targets of later
segments at a branching point.
1608 As a result the RIBs are set as follows:
1609
1629 +======+=============+=========+=============+==========+
1630 | Node | Destination | Origin | Next Hop(s) | TrackID |
1631 +======+=============+=========+=============+==========+
1632 | E | F, G | P-DAO 1 | Neighbor | (A, 129) |
But E would know about F and G alrady before P-DAO 1, so i wonder...
he example didn't call out which DODAG we're forwarding across. I guess this
is a sequental Track, which the example also does not say.
In any case, instead of saying just "Destination", it would be good to
say Destination in which context in the table. "Destination in RPLInstance TrackID1 ???"
Q: If this is not in the main DODAG, but in that TrackID1 DODAG,
and we didn't send any P-DAO yet. Can we actually send/deliver packets ?
I guess no, right ? So what seems to happen is that we first have some
F, G neighbor information from the main DODAG, and because of P-DAO 1,
this information is inherited into the forwarding for TrackID1 DODAG ?
That would be good to show, or explain.
Also, given how you previously whee pointing out that these routes
are used over routes to the node because of prefix-length, should the
entries in the destination not rather read F/128, G/128, likewise for all the
other entries below ? Or does RPL imply fixed /128 unless its a /0 ? default
route to the root ?
Also: TrackID is 129 i think. (A, 129) seems to be the DODAG (Identifier?).
So maybe rename or rewrite accordingly.
1633 +------+-------------+---------+-------------+----------+
1634 | D | E | P-DAO 1 | Neighbor | (A, 129) |
1635 +------+-------------+---------+-------------+----------+
1636 | " | F, G | P-DAO 1 | E | (A, 129) |
1637 +------+-------------+---------+-------------+----------+
1638 | C | D | P-DAO 1 | Neighbor | (A, 129) |
1639 +------+-------------+---------+-------------+----------+
1640 | " | E, F, G | P-DAO 1 | D | (A, 129) |
1641 +------+-------------+---------+-------------+----------+
1642 | B | C | P-DAO 2 | Neighbor | (A, 129) |
1643 +------+-------------+---------+-------------+----------+
1644 | " | E, F, G | P-DAO 2 | C | (A, 129) |
1645 +------+-------------+---------+-------------+----------+
1646 | A | B | P-DAO 2 | Neighbor | (A, 129) |
1647 +------+-------------+---------+-------------+----------+
1648 | A | E, F, G | P-DAO 2 | B | (A, 129) |
1649 +------+-------------+---------+-------------+----------+
1650
1651 Table 2: RIB setting
1652
1653 E recognizes that it is the Track Egress because it is both a Target
1654 and a Segment Endpoint.
... of P-DAO 1 ?
What would happen if E was not listed as a Target in P-DAO 2 ?
Would that impact the ability to deliver packets to F, G via (A, 129) ?
If so, why ? If its possible to deliver to (F,G) without indicating E in
target list, hen i think the statement is wrong.
And i can't see how the logic works. Lets assume C has a neighbor H,
so now we set the targets for P-DAO 2 to E,F,G,H. How would the notion
of including C into this target list help C to decide wheher to deliver
packets to H directly instead of leting them maybe go through further
segments ? Aka: It seems to me that if the logic is that if you are
sement endpoint, and any track egres for that segments P-DAO is a neighbor
in the main dodag, then you do forward directly to that target.
Yes/No/Maybe ? ;-))
Also: I think there should be some "Punt" line in the FIB on E for E as
a target. And it seems to me that that Punt line would be created
by including the segment endpoint into the target list. Maybe one
does not want to be able to address a segment endpoint via the Track DODAG...
1656 Packets originated by A to E, F, or G, do not require an
^^^ from a source X via
1657 encapsulation. In any fashion, the outer headers of the packets that
^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ remove
how about "any additional encapsulation beside the one outer encapsulation
required for non-storage-mode" ?
Because immediately following you do write and show that outer encapsulation header.
1657 encapsulation. In any fashion, the outer headers of the packets that
1658 are forwarded along the Track have the following settings:
1659
1660 +========+===================+===================+================+
1661 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI |
1662 +========+===================+===================+================+
1663 | Outer | A | E, F or G | (A, 129) |
1664 +--------+-------------------+-------------------+----------------+
1665 | Inner | X != A | E, F or G | N/A |
1666 +--------+-------------------+-------------------+----------------+
Maybe add note: The Inner header is only required for X != A.
1667
1668 Table 3: Packet header settings
1669
1670 As an example, say that A has a packet for F. Using the RIB above:
1671
1672 * From P-DAO 2: A forwards to B and B forwards to C.
1673
1674 * From P-DAO 1: C forwards to D and D forwards to E.
1675
1676 * From Neighbor Cache Entry: C delivers the packet to F.
^ E ?
But see above, your FIB shows that E -> F as part of (A, 129), whereas the neighbor
cache entry is probably independent of 129, right ? So one of those statements
(table or neighbor-cache-entry) is wrong.
1685 9.1.2. External routes
^^^^^^^^^^^^^^^
New term not used in before. Explain.
1687 Storing-Mode P-DAO 1 and 2, and Non-Storing-Mode P-DAO 3, are sent to
1688 E, C and A, respectively, as follows:
1689
1690 +===============+==============+==============+==============+
1691 | | P-DAO 1 to E | P-DAO 2 to C | P-DAO 3 to A |
1692 +===============+==============+==============+==============+
1693 | Mode | Storing | Storing | Non-Storing |
1694 +---------------+--------------+--------------+--------------+
1695 | Track Ingress | A | A | A |
1696 +---------------+--------------+--------------+--------------+
1697 | TrackID | (A, 129) | (A, 129) | (A, 129) |
1698 +---------------+--------------+--------------+--------------+
1699 | VIO | C, D, E | A, B, C | E |
1700 +---------------+--------------+--------------+--------------+
1701 | Targets | E | E | F, G |
1702 +---------------+--------------+--------------+--------------+
Some explanation about the purpose of this example would be useful.
Seems to be something like. In this example, we want to avoid creating
state for F,G on B,C,D. We do this by using the two storing mode segmnts
P-DAO1 and P-DAO 2 to reach E and a non-storing segment P-DAO 3 to reach F
and G.
I am not clear why P-DAO 3 needs to be non-storing though. What would happen
if the only change to above was to indicate P-DAO 3 as storing ? aka: why
would B,C,D need to bother about any Target list of segments that they are not on ?
1704 Table 4: P-DAO Messages
1705
1706 As a result the RIBs are set as follows:
1707
1708 +======+=============+=========+=============+==========+
1709 | Node | Destination | Origin | Next Hop(s) | TrackID |
1710 +======+=============+=========+=============+==========+
1711 | E | F, G | P-DAO 1 | Neighbor | (A, 129) |
^^^^^^^
Shouldn't this be P-DAO 3 ??
1712 +------+-------------+---------+-------------+----------+
1713 | D | E | P-DAO 1 | Neighbor | (A, 129) |
1714 +------+-------------+---------+-------------+----------+
1715 | C | D | P-DAO 1 | Neighbor | (A, 129) |
1716 +------+-------------+---------+-------------+----------+
1717 | " | E | P-DAO 1 | D | (A, 129) |
1718 +------+-------------+---------+-------------+----------+
1719 | B | C | P-DAO 2 | Neighbor | (A, 129) |
1720 +------+-------------+---------+-------------+----------+
1721 | " | E | P-DAO 2 | C | (A, 129) |
1722 +------+-------------+---------+-------------+----------+
1723 | A | B | P-DAO 2 | Neighbor | (A, 129) |
1724 +------+-------------+---------+-------------+----------+
1725 | A | E | P-DAO 2 | B | (A, 129) |
1726 +------+-------------+---------+-------------+----------+
1727 | A | F, G | P-DAO 3 | E | (A, 129) |
1728 +------+-------------+---------+-------------+----------+
1729
1730 Table 5: RIB setting
1731
1741 Packets from A to E do not require an encapsulation. In any fashion,
^^^^^^^^^^^^^ ^^^^^^^^^^^^^^ delete
Inner Header
1742 the outer headers of the packets that are forwarded along the Track
1743 have the following settings:
1744
1745 +========+===================+====================+================+
1746 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI |
1747 +========+===================+====================+================+
1748 | Outer | A | E | (A, 129) |
1749 +--------+-------------------+--------------------+----------------+
1750 | Inner | X | E (X != A), F or G | N/A |
1751 +--------+-------------------+--------------------+----------------+
1752
1753 Table 6: Packet header settings
1754
1755 As an example, say that A has a packet for F. Using the RIB above:
1756
1757 * From P-DAO 3: A encapsulates the packet the Track signaled by
^ for ^ (A,129)
1758 P-DAO 3, with the outer header above. Now the packet destination
1759 is E.
^ of the Outer Header
1760
1761 * From P-DAO 2: A forwards to B and B forwards to C.
1762
1763 * From P-DAO 1: C forwards to D and D forwards to E; E decapsulates
1764 the packet.
^ because it is the destination of the Outer Header
?? AND ? a valid target for (A, 129) ??? (see question above
1765
1766 * From Neighbor Cache Entry: C delivers packets to F or G.
1767
1768 9.1.3. Segment Routing
New term not used in before in this doc, define, reference (RFC8402 ?), etc. pp.
1770 Storing-Mode P-DAO 1 and 2, and Non-Storing-Mode P-DAO 3, are sent to
1771 E, B and A, respectively, as follows:
Again: Please add purpose/goal of this example.
If you did improve initial picture to show segments, then of course these
ar different now.
1773 +===============+==============+==============+==============+
1774 | | P-DAO 1 to E | P-DAO 2 to B | P-DAO 3 to A |
1775 +===============+==============+==============+==============+
1776 | Mode | Storing | Storing | Non-Storing |
1777 +---------------+--------------+--------------+--------------+
1778 | Track Ingress | A | A | A |
1779 +---------------+--------------+--------------+--------------+
1780 | TrackID | (A, 129) | (A, 129) | (A, 129) |
1781 +---------------+--------------+--------------+--------------+
1782 | VIO | C, D, E | A, B | C, E |
1783 +---------------+--------------+--------------+--------------+
1784 | Targets | E | B, C | F, G |
1785 +---------------+--------------+--------------+--------------+
1786
1787 Table 7: P-DAO Messages
Does this example only work with B being the exit node for P-DAO2, or could
it equally work if we kept P-DAO 2 unchanged, ending at C, but the target only being C ?
I am guessing it could be, given how C would also need to look into P-DAO1 route
towards E, right ? Aka: Minimal change over prior example might make it easier..
1797 As a result the RIBs are set as follows:
1798
1799 +======+=============+=========+=============+==========+
1800 | Node | Destination | Origin | Next Hop(s) | TrackID |
1801 +======+=============+=========+=============+==========+
1802 | E | F, G | P-DAO 1 | Neighbor | (A, 129) |
1803 +------+-------------+---------+-------------+----------+
1804 | D | E | P-DAO 1 | Neighbor | (A, 129) |
1805 +------+-------------+---------+-------------+----------+
1806 | C | D | P-DAO 1 | Neighbor | (A, 129) |
1807 +------+-------------+---------+-------------+----------+
1808 | " | E | P-DAO 1 | D | (A, 129) |
1809 +------+-------------+---------+-------------+----------+
1810 | B | C | P-DAO 2 | Neighbor | (A, 129) |
1811 +------+-------------+---------+-------------+----------+
1812 | A | B | P-DAO 2 | Neighbor | (A, 129) |
1813 +------+-------------+---------+-------------+----------+
1814 | " | C | P-DAO 2 | B | (A, 129) |
1815 +------+-------------+---------+-------------+----------+
1816 | " | E, F, G | P-DAO 3 | C, E | (A, 129) |
1817 +------+-------------+---------+-------------+----------+
1818
1819 Table 8: RIB setting
1820
1821 Packets from A to E do not require an encapsulation, but carry a SRH
a third header instead of encap ?
1822 via C. In any fashion, the outer headers of the packets that are
1823 forwarded along the Track have the following settings:
1824
1825 +========+===================+====================+================+
1826 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI |
^^^^^^^^^^^^^^^^^
the SRH for th Outer Header is not just an Pv6 Dest. Addr.
1827 +========+===================+====================+================+
1828 | Outer | A | C till C then E | (A, 129) |
1829 +--------+-------------------+--------------------+----------------+
1830 | Inner | X | E (X != A), F or G | N/A |
1831 +--------+-------------------+--------------------+----------------+
1832
1833 Table 9: Packet header settings
1834
1835 As an example, say that A has a packet for F. Using the RIB above:
1836
1837 * From P-DAO 3: A encapsulates the packet the Track signaled by
1838 P-DAO 3, with the outer header above. Now the destination in the
1839 IPv6 Header is C, and a SRH signals the final destination is E.
1840
1841 * From P-DAO 2: A forwards to B and B forwards to C.
1842
1843 * From P-DAO 3: C processes the SRH and sets the destination in the
1844 IPv6 Header to E.
1845
1853 * From P-DAO 1: C forwards to D and D forwards to E; E decapsulates
1854 the packet.
1855
1856 * From the Neighbor Cache Entry: C delivers packets to F or G.
1857
1858 9.2. Using Non-Storing-Mode joining Tracks
1859
1860 A==>B==>C and C==>D==>E are Tracks expressed as non-storing P-DAOs.
1861
1862 9.2.1. Stitched Tracks
sequential Tracks ?
1864 Non-Storing Mode P-DAO 1 and 2 are sent to C and A respectively, as
1865 follows:
1866
1867 +===============+==============+==============+
1868 | | P-DAO 1 to C | P-DAO 2 to A |
1869 +===============+==============+==============+
1870 | Mode | Non-Storing | Non-Storing |
1871 +---------------+--------------+--------------+
1872 | Track Ingress | C | A |
1873 +---------------+--------------+--------------+
1874 | TrackID | (C, 131) | (A, 129) |
1875 +---------------+--------------+--------------+
1876 | VIO | D, E | B, C |
1877 +---------------+--------------+--------------+
1878 | Targets | F, G | E, F, G |
1879 +---------------+--------------+--------------+
WOuld it be possible for both DAO to have the same number (129) given how
they are disambiguated by the source address ? If so i think it would strenthen
the example by doing so and highlighting that these are not the same Tracks anymore,
even if they reuse the same TrackID.
1880
1881 Table 10: P-DAO Messages
1882
1883 As a result the RIBs are set as follows:
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904 Thubert, et al. Expires 28 January 2022 [Page 34]
1905
1906 Internet-Draft DAO Projection July 2021
1907
1908
1909 +======+=============+=========+=============+==========+
1910 | Node | Destination | Origin | Next Hop(s) | TrackID |
1911 +======+=============+=========+=============+==========+
1912 | E | F, G | ND | Neighbor | Any |
1913 +------+-------------+---------+-------------+----------+
1914 | D | E | ND | Neighbor | Any |
1915 +------+-------------+---------+-------------+----------+
1916 | C | D | ND | Neighbor | Any |
1917 +------+-------------+---------+-------------+----------+
1918 | " | E, F, G | P-DAO 1 | D, E | (C, 131) |
1919 +------+-------------+---------+-------------+----------+
1920 | B | C | ND | Neighbor | Any |
1921 +------+-------------+---------+-------------+----------+
1922 | A | B | ND | Neighbor | Any |
1923 +------+-------------+---------+-------------+----------+
1924 | " | C, E, F, G | P-DAO 2 | B, C | (A, 129) |
1925 +------+-------------+---------+-------------+----------+
1926
1927 Table 11: RIB setting
1928
1929 Packets from A to E, F and G do not require an encapsulation, though
1930 it is preferred that A encapsulates and C decapsulates. Either way,
1931 they carry a SRH via B and C, and C needs to encapsulate to E, F, or
1932 G to add an SRH via D and E. The encapsulating headers of packets
1933 that are forwarded along the Track between C and E have the following
1934 settings:
1935
1936 +========+===================+===================+================+
1937 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI |
1938 +========+===================+===================+================+
1939 | Outer | C | D till D then E | (C, 131) |
1940 +--------+-------------------+-------------------+----------------+
1941 | Inner | X | E, F, or G | N/A |
1942 +--------+-------------------+-------------------+----------------+
1943
1944 Table 12: Packet header settings
1945
1946 As an example, say that A has a packet for F. Using the RIB above:
1947
1948 * From P-DAO 2: A encapsulates the packet with destination of F in
1949 the Track signaled by P-DAO 2. The outer header has source A,
1950 destination B, an SRH that indicates C as the next loose hop, and
1951 a RPI indicating a TrackId of 129 from A's namespace.
1952
1953 * From the SRH: Packets forwarded by B have source A, destination C
1954 , a consumed SRH, and a RPI indicating a TrackId of 129 from A's
1955 namespace. C decapsulates.
1956
1965 * From P-DAO 1: C encapsulates the packet with destination of F in
1966 the Track signaled by P-DAO 1. The outer header has source C,
1967 destination D, an SRH that indicates E as the next loose hop, and
1968 a RPI indicating a TrackId of 131 from C's namespace. E
1969 decapsulates.
1970
1971 9.2.2. External routes
sequential tracks with external routes ?
1972
1973 Non-Storing Mode P-DAO 1 is sent to C and Non-Storing Mode P-DAO 2
1974 and 3 are sent A, as follows:
1975
1976 +===============+==============+==============+==============+
1977 | | P-DAO 1 to C | P-DAO 2 to A | P-DAO 3 to A |
1978 +===============+==============+==============+==============+
1979 | Mode | Non-Storing | Non-Storing | Non-Storing |
1980 +---------------+--------------+--------------+--------------+
1981 | Track Ingress | C | A | A |
1982 +---------------+--------------+--------------+--------------+
1983 | TrackID | (C, 131) | (A, 129) | (A, 141) |
1984 +---------------+--------------+--------------+--------------+
1985 | VIO | D, E | B, C | E |
1986 +---------------+--------------+--------------+--------------+
1987 | Targets | E | E | F, G |
1988 +---------------+--------------+--------------+--------------+
1989
1990 Table 13: P-DAO Messages
1991
1992 As a result the RIBs are set as follows:
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016 Thubert, et al. Expires 28 January 2022 [Page 36]
2017
2018 Internet-Draft DAO Projection July 2021
2019
2020
2021 +======+=============+=========+=============+==========+
2022 | Node | Destination | Origin | Next Hop(s) | TrackID |
2023 +======+=============+=========+=============+==========+
2024 | E | F, G | ND | Neighbor | Any |
2025 +------+-------------+---------+-------------+----------+
2026 | D | E | ND | Neighbor | Any |
2027 +------+-------------+---------+-------------+----------+
2028 | C | D | ND | Neighbor | Any |
2029 +------+-------------+---------+-------------+----------+
2030 | " | E | P-DAO 1 | D, E | (C, 131) |
2031 +------+-------------+---------+-------------+----------+
2032 | B | C | ND | Neighbor | Any |
2033 +------+-------------+---------+-------------+----------+
2034 | A | B | ND | Neighbor | Any |
2035 +------+-------------+---------+-------------+----------+
2036 | " | C, E | P-DAO 2 | B, C | (A, 129) |
2037 +------+-------------+---------+-------------+----------+
2038 | " | F, G | P-DAO 3 | E | (A, 141) |
2039 +------+-------------+---------+-------------+----------+
2040
2041 Table 14: RIB setting
2042
2043 The encapsulating headers of packets that are forwarded along the
2044 Track between C and E have the following settings:
2045
2046 +========+===================+===================+================+
2047 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI |
2048 +========+===================+===================+================+
2049 | Outer | C | D till D then E | (C, 131) |
2050 +--------+-------------------+-------------------+----------------+
2051 | Middle | A | E | (A, 141) |
2052 +--------+-------------------+-------------------+----------------+
2053 | Inner | X | E, F or G | N/A |
2054 +--------+-------------------+-------------------+----------------+
2055
2056 Table 15: Packet header settings
2057
2058 As an example, say that A has a packet for F. Using the RIB above:
2059
2060 * From P-DAO 3: A encapsulates the packet with destination of F in
2061 the Track signaled by P-DAO 3. The outer header has source A,
2062 destination E, and a RPI indicating a TrackId of 141 from A's
2063 namespace. This recurses with:
2064
2065 * From P-DAO 2: A encapsulates the packet with destination of E in
2066 the Track signaled by P-DAO 2. The outer header has source A,
2067 destination B, an SRH that indicates C as the next loose hop, and
2068 a RPI indicating a TrackId of 129 from A's namespace.
2069
2070
2071
2072 Thubert, et al. Expires 28 January 2022 [Page 37]
2073
2074 Internet-Draft DAO Projection July 2021
2075
2076
2077 * From the SRH: Packets forwarded by B have source A, destination C
2078 , a consumed SRH, and a RPI indicating a TrackId of 129 from A's
2079 namespace. C decapsulates.
2080
2081 * From P-DAO 1: C encapsulates the packet with destination of E in
2082 the Track signaled by P-DAO 1. The outer header has source C,
2083 destination D, an SRH that indicates E as the next loose hop, and
2084 a RPI indicating a TrackId of 131 from C's namespace. E
2085 decapsulates.
2086
2087 9.2.3. Segment Routing
segment routing with exernal routes ?
2088
2089 Non-Storing Mode P-DAO 1 is sent to C and Non-Storing Mode P-DAO 2
2090 and 3 are sent A, as follows:
2091
2092 +===============+==============+==============+==============+
2093 | | P-DAO 1 to C | P-DAO 2 to A | P-DAO 3 to A |
2094 +===============+==============+==============+==============+
2095 | Mode | Non-Storing | Non-Storing | Non-Storing |
2096 +---------------+--------------+--------------+--------------+
2097 | Track Ingress | C | A | A |
2098 +---------------+--------------+--------------+--------------+
2099 | TrackID | (C, 131) | (A, 129) | (A, 141) |
2100 +---------------+--------------+--------------+--------------+
2101 | VIO | D, E | B | C, E |
2102 +---------------+--------------+--------------+--------------+
2103 | Targets | | C | F, G |
2104 +---------------+--------------+--------------+--------------+
2105
2106 Table 16: P-DAO Messages
2107
2108 As a result the RIBs are set as follows:
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128 Thubert, et al. Expires 28 January 2022 [Page 38]
2129
2130 Internet-Draft DAO Projection July 2021
2131
2132
2133 +======+=============+=========+=============+==========+
2134 | Node | Destination | Origin | Next Hop(s) | TrackID |
2135 +======+=============+=========+=============+==========+
2136 | E | F, G | ND | Neighbor | Any |
2137 +------+-------------+---------+-------------+----------+
2138 | D | E | ND | Neighbor | Any |
2139 +------+-------------+---------+-------------+----------+
2140 | C | D | ND | Neighbor | Any |
2141 +------+-------------+---------+-------------+----------+
2142 | " | E | P-DAO 1 | D, E | (C, 131) |
2143 +------+-------------+---------+-------------+----------+
2144 | B | C | ND | Neighbor | Any |
2145 +------+-------------+---------+-------------+----------+
2146 | A | B | ND | Neighbor | Any |
2147 +------+-------------+---------+-------------+----------+
2148 | " | C | P-DAO 2 | B, C | (A, 129) |
2149 +------+-------------+---------+-------------+----------+
2150 | " | E, F, G | P-DAO 3 | C, E | (A, 141) |
2151 +------+-------------+---------+-------------+----------+
2152
2153 Table 17: RIB setting
2154
2155 The encapsulating headers of packets that are forwarded along the
2156 Track between A and B have the following settings:
2157
2158 +========+===================+===================+================+
2159 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI |
2160 +========+===================+===================+================+
2161 | Outer | A | B till D then E | (A, 129) |
2162 +--------+-------------------+-------------------+----------------+
2163 | Middle | A | C | (A, 141) |
2164 +--------+-------------------+-------------------+----------------+
2165 | Inner | X | E, F or G | N/A |
2166 +--------+-------------------+-------------------+----------------+
2167
2168 Table 18: Packet header settings
2169
2170 The encapsulating headers of packets that are forwarded along the
2171 Track between B and C have the following settings:
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184 Thubert, et al. Expires 28 January 2022 [Page 39]
2185
2186 Internet-Draft DAO Projection July 2021
2187
2188
2189 +========+===================+===================+================+
2190 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI |
2191 +========+===================+===================+================+
2192 | Outer | A | C | (A, 141) |
2193 +--------+-------------------+-------------------+----------------+
2194 | Inner | X | E, F or G | N/A |
2195 +--------+-------------------+-------------------+----------------+
2196
2197 Table 19: Packet header settings
2198
2199 The encapsulating headers of packets that are forwarded along the
2200 Track between C and E have the following settings:
2201
2202 +========+===================+===================+================+
2203 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI |
2204 +========+===================+===================+================+
2205 | Outer | C | D till D then E | (C, 131) |
2206 +--------+-------------------+-------------------+----------------+
2207 | Middle | A | E | (A, 141) |
2208 +--------+-------------------+-------------------+----------------+
2209 | Inner | X | E, F or G | N/A |
2210 +--------+-------------------+-------------------+----------------+
2211
2212 Table 20: Packet header settings
2213
2214 As an example, say that A has a packet for F. Using the RIB above:
2215
2216 * From P-DAO 3: A encapsulates the packet with destination of F in
2217 the Track signaled by P-DAO 3. The outer header has source A,
2218 destination C, an SRH that indicates E as the next loose hop, and
2219 a RPI indicating a TrackId of 141 from A's namespace. This
2220 recurses with:
2221
2222 * From P-DAO 2: A encapsulates the packet with destination of C in
2223 the Track signaled by P-DAO 2. The outer header has source A,
2224 destination B, and a RPI indicating a TrackId of 129 from A's
2225 namespace. B decapsulates forwards to C based on a sibling
2226 connected route.
2227
2228 * From the SRH: C consumes the SRH and makes the destination E.
2229
2230 * From P-DAO 1: C encapsulates the packet with destination of E in
2231 the Track signaled by P-DAO 1. The outer header has source C,
2232 destination D, an SRH that indicates E as the next loose hop, and
2233 a RPI indicating a TrackId of 131 from C's namespace. E
2234 decapsulates.
2235
Sorry, i skipped mostly across 1883 to here, running out of time.
2245 10. Security Considerations
2246
2247 It is worth noting that with [RPL], every node in the LLN is RPL-
2248 aware and can inject any RPL-based attack in the network. This draft
I guss even RUL nodes, which i think came after rfc6550 could be nasty too and
inject RPL messages.
2249 uses messages that are already present in RPL [RPL] with optional
2250 secured versions. The same secured versions may be used with this
2251 draft, and whatever security is deployed for a given network also
2252 applies to the flows in this draft.
2253
2254 The LLN nodes depend on the 6LBR and the RPL participants for their
2255 operation. A trust model must be put in place to ensure that the
2256 right devices are acting in these roles, so as to avoid threats such
2257 as black-holing, (see [RFC7416] section 7). This trust model could
2258 be at a minimum based on a Layer-2 Secure joining and the Link-Layer
2259 security. This is a generic 6LoWPAN requirement, see Req5.1 in
2260 Appendix B.5 of [RFC8505].
2261
2262 In a general manner, the Security Considerations in [RPL], and
2263 [RFC7416] apply to this specification as well. The Link-Layer
2264 security is needed in particular to prevent Denial-Of-Service attacks
2265 whereby a rogue router creates a high churn in the RPL network by
2266 constantly injected forged P-DAO messages and using up all the
2267 available storage in the attacked routers.
Seems like the answer is no.
2268
2269 Additionally, the trust model could include a role validation (e.g.,
2270 using a role-based authorization) to ensure that the node that claims
2271 to be a RPL Root is entitled to do so. That trust should propagate
2272 from egress to ingress in the case of a Storing Mode P-DAO.
In ANIMA i am pondering to get role-based certificates to enable something like this.
Is there any existing solution for this ? If not, then it would be good to mention this
as a gap. In general, the whole PCE based routing model does put more reliance of a
trustworthy PCE into the solution, but it eliminates a lot of security attacks
coming from the normal peer-2-peer routing model (i am just making this argument
in my bier-te draft, ask me again, when i have read BenK's feedback ;-).
But when
like it seems in this solution, one mixes the tradtional non-role based signaling
with PCE input then it looks like a bigge gap than in before, because now these
new routes allow to potentially create even more black holes than may have been
possible in before (not quite sure).
In any case, you can also mention that you did try to eliminate one new type of
attack by injection of duplicate addresses in tracks by mandating to discover such
issue. Not sure though if this is the best set of heuristics that nodes could
apply to self-defend themslfes and further hops from incorrect new messages. Miht
be worth to ponder.
2273
2274 11. IANA Considerations
I am not going to read this (out of time). I would suggest as mentione din before to replace
all numbers with TBDi and then strongly consider early IANA allocation. That would
also help a lot to resolve any possible issues with any of the registration asks by
mean of the IANA/expert review ensueing.
2276 11.1. New Elective 6LoWPAN Routing Header Type
2277
2278 This document updates the IANA registry titled "Elective 6LoWPAN
2279 Routing Header Type" that was created for [RFC8138] and assigns the
2280 following value:
2281
2282 +=======+=============+===============+
2283 | Value | Description | Reference |
2284 +=======+=============+===============+
2285 | 7 | P-RPI-6LoRH | This document |
2286 +-------+-------------+---------------+
2287
2288 Table 21: New Elective 6LoWPAN
2289 Routing Header Type
2290
2291
2292
2293
2294
2295
2296 Thubert, et al. Expires 28 January 2022 [Page 41]
2297
2298 Internet-Draft DAO Projection July 2021
2299
2300
2301 11.2. New Critical 6LoWPAN Routing Header Type
2302
2303 This document updates the IANA registry titled "Critical 6LoWPAN
2304 Routing Header Type" that was created for [RFC8138] and assigns the
2305 following value:
2306
2307 +=======+=============+===============+
2308 | Value | Description | Reference |
2309 +=======+=============+===============+
2310 | 7 | P-RPI-6LoRH | This document |
2311 +-------+-------------+---------------+
2312
2313 Table 22: New Critical 6LoWPAN
2314 Routing Header Type
2315
2316 11.3. New Subregistry For The RPL Option Flags
2317
2318 IANA is required to create a subregistry for the 8-bit RPL Option
2319 Flags field, as detailed in Figure 2, under the "Routing Protocol for
2320 Low Power and Lossy Networks (RPL)" registry. The bits are indexed
2321 from 0 (leftmost) to 7. Each bit is tracked with the following
2322 qualities:
2323
2324 * Bit number (counting from bit 0 as the most significant bit)
2325
2326 * Indication When Set
2327
2328 * Reference
2329
2330 Registration procedure is "Standards Action" [RFC8126]. The initial
2331 allocation is as indicated in Table 26:
2332
2333 +============+======================+===============+
2334 | Bit number | Indication When Set | Reference |
2335 +============+======================+===============+
2336 | 0 | Down 'O' | [RFC6553] |
2337 +------------+----------------------+---------------+
2338 | 1 | Rank-Error (R) | [RFC6553] |
2339 +------------+----------------------+---------------+
2340 | 2 | Forwarding-Error (F) | [RFC6553] |
2341 +------------+----------------------+---------------+
2342 | 3 | Projected-Route (P) | This document |
2343 +------------+----------------------+---------------+
2344
2345 Table 23: Initial PDR Flags
2346
2347
2348
2349
2350
2351
2352 Thubert, et al. Expires 28 January 2022 [Page 42]
2353
2354 Internet-Draft DAO Projection July 2021
2355
2356
2357 11.4. New RPL Control Codes
2358
2359 This document extends the IANA Subregistry created by RFC 6550 for
2360 RPL Control Codes as indicated in Table 24:
2361
2362 +======+=============================+===============+
2363 | Code | Description | Reference |
2364 +======+=============================+===============+
2365 | 0x09 | Projected DAO Request (PDR) | This document |
2366 +------+-----------------------------+---------------+
2367 | 0x0A | PDR-ACK | This document |
2368 +------+-----------------------------+---------------+
2369
2370 Table 24: New RPL Control Codes
2371
2372 11.5. New RPL Control Message Options
2373
2374 This document extends the IANA Subregistry created by RFC 6550 for
2375 RPL Control Message Options as indicated in Table 25:
2376
2377 +=======+============================+===============+
2378 | Value | Meaning | Reference |
2379 +=======+============================+===============+
2380 | 0x0B | Stateful VIO (SF-VIO) | This document |
2381 +-------+----------------------------+---------------+
2382 | 0x0C | Source-Routed VIO (SR-VIO) | This document |
2383 +-------+----------------------------+---------------+
2384 | 0x0D | Sibling Information option | This document |
2385 +-------+----------------------------+---------------+
2386
2387 Table 25: RPL Control Message Options
2388
2389 11.6. SubRegistry for the Projected DAO Request Flags
2390
2391 IANA is required to create a registry for the 8-bit Projected DAO
2392 Request (PDR) Flags field. Each bit is tracked with the following
2393 qualities:
2394
2395 * Bit number (counting from bit 0 as the most significant bit)
2396
2397 * Capability description
2398
2399 * Reference
2400
2401 Registration procedure is "Standards Action" [RFC8126]. The initial
2402 allocation is as indicated in Table 26:
2403
2404
2405
2406
2407
2408 Thubert, et al. Expires 28 January 2022 [Page 43]
2409
2410 Internet-Draft DAO Projection July 2021
2411
2412
2413 +============+========================+===============+
2414 | Bit number | Capability description | Reference |
2415 +============+========================+===============+
2416 | 0 | PDR-ACK request (K) | This document |
2417 +------------+------------------------+---------------+
2418 | 1 | Requested path should | This document |
2419 | | be redundant (R) | |
2420 +------------+------------------------+---------------+
2421
2422 Table 26: Initial PDR Flags
2423
2424 11.7. SubRegistry for the PDR-ACK Flags
2425
2426 IANA is required to create an subregistry for the 8-bit PDR-ACK Flags
2427 field. Each bit is tracked with the following qualities:
2428
2429 * Bit number (counting from bit 0 as the most significant bit)
2430
2431 * Capability description
2432
2433 * Reference
2434
2435 Registration procedure is "Standards Action" [RFC8126]. No bit is
2436 currently defined for the PDR-ACK Flags.
2437
2438 11.8. Subregistry for the PDR-ACK Acceptance Status Values
2439
2440 IANA is requested to create a Subregistry for the PDR-ACK Acceptance
2441 Status values.
2442
2443 * Possible values are 6-bit unsigned integers (0..63).
2444
2445 * Registration procedure is "Standards Action" [RFC8126].
2446
2447 * Initial allocation is as indicated in Table 27:
2448
2449 +-------+------------------------+---------------+
2450 | Value | Meaning | Reference |
2451 +-------+------------------------+---------------+
2452 | 0 | Unqualified acceptance | This document |
2453 +-------+------------------------+---------------+
2454
2455 Table 27: Acceptance values of the PDR-ACK Status
2456
2457 11.9. Subregistry for the PDR-ACK Rejection Status Values
2458
2459 IANA is requested to create a Subregistry for the PDR-ACK Rejection
2460 Status values.
2461
2462
2463
2464 Thubert, et al. Expires 28 January 2022 [Page 44]
2465
2466 Internet-Draft DAO Projection July 2021
2467
2468
2469 * Possible values are 6-bit unsigned integers (0..63).
2470
2471 * Registration procedure is "Standards Action" [RFC8126].
2472
2473 * Initial allocation is as indicated in Table 28:
2474
2475 +-------+-----------------------+---------------+
2476 | Value | Meaning | Reference |
2477 +-------+-----------------------+---------------+
2478 | 0 | Unqualified rejection | This document |
2479 +-------+-----------------------+---------------+
2480
2481 Table 28: Rejection values of the PDR-ACK Status
2482
2483 11.10. SubRegistry for the Via Information Options Flags
2484
2485 IANA is requested to create a Subregistry for the 5-bit Via
2486 Information Options (Via Information Option) Flags field. Each bit
2487 is tracked with the following qualities:
2488
2489 * Bit number (counting from bit 0 as the most significant bit)
2490
2491 * Capability description
2492
2493 * Reference
2494
2495 Registration procedure is "Standards Action" [RFC8126]. No bit is
2496 currently defined for the Via Information Options (Via Information
2497 Option) Flags.
2498
2499 11.11. SubRegistry for the Sibling Information Option Flags
2500
2501 IANA is required to create a registry for the 5-bit Sibling
2502 Information Option (SIO) Flags field. Each bit is tracked with the
2503 following qualities:
2504
2505 * Bit number (counting from bit 0 as the most significant bit)
2506
2507 * Capability description
2508
2509 * Reference
2510
2511 Registration procedure is "Standards Action" [RFC8126]. The initial
2512 allocation is as indicated in Table 29:
2513
2514
2515
2516
2517
2518
2519
2520 Thubert, et al. Expires 28 January 2022 [Page 45]
2521
2522 Internet-Draft DAO Projection July 2021
2523
2524
2525 +============+===================================+===============+
2526 | Bit number | Capability description | Reference |
2527 +============+===================================+===============+
2528 | 0 | Connectivity is bidirectional (B) | This document |
2529 +------------+-----------------------------------+---------------+
2530
2531 Table 29: Initial SIO Flags
2532
2533 11.12. New Destination Advertisement Object Flag
2534
2535 This document modifies the "Destination Advertisement Object (DAO)
2536 Flags" registry initially created in Section 20.11 of [RPL] .
2537
2538 Section 3.1 also defines one new entry in the Registry as follows:
2539
2540 +---------------+------------------------+-----------+
2541 | Bit Number | Capability Description | Reference |
2542 +---------------+------------------------+-----------+
2543 | 2 (suggested) | Projected DAO (P) | THIS RFC |
2544 +---------------+------------------------+-----------+
2545
2546 Table 30: New Destination Advertisement Object
2547 (DAO) Flag
2548
2549 11.13. Error in Projected Route ICMPv6 Code
2550
2551 In some cases RPL will return an ICMPv6 error message when a message
2552 cannot be forwarded along a Projected Route. This ICMPv6 error
2553 message is "Error in Projected Route".
2554
2555 IANA has defined an ICMPv6 "Code" Fields Registry for ICMPv6 Message
2556 Types. ICMPv6 Message Type 1 describes "Destination Unreachable"
2557 codes. This specification requires that a new code is allocated from
2558 the ICMPv6 Code Fields Registry for ICMPv6 Message Type 1, for "Error
2559 in Projected Route", with a suggested code value of 8, to be
2560 confirmed by IANA.
2561
2562 12. Acknowledgments
2563
2564 The authors wish to acknowledge JP Vasseur, Remy Liubing, James
2565 Pylakutty and Patrick Wetterwald for their contributions to the ideas
2566 developed here.
2567
2568 13. Normative References
2569
2570
2571
2572
2573
2574
2575
2576 Thubert, et al. Expires 28 January 2022 [Page 46]
2577
2578 Internet-Draft DAO Projection July 2021
2579
2580
2581 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2582 Requirement Levels", BCP 14, RFC 2119,
2583 DOI 10.17487/RFC2119, March 1997,
2584 <https://www.rfc-editor.org/info/rfc2119>.
2585
2586 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
2587 Control Message Protocol (ICMPv6) for the Internet
2588 Protocol Version 6 (IPv6) Specification", STD 89,
2589 RFC 4443, DOI 10.17487/RFC4443, March 2006,
2590 <https://www.rfc-editor.org/info/rfc4443>.
2591
2592 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
2593 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
2594 DOI 10.17487/RFC6282, September 2011,
2595 <https://www.rfc-editor.org/info/rfc6282>.
2596
2597 [RPL] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
2598 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
2599 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
2600 Low-Power and Lossy Networks", RFC 6550,
2601 DOI 10.17487/RFC6550, March 2012,
2602 <https://www.rfc-editor.org/info/rfc6550>.
2603
2604 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low-
2605 Power and Lossy Networks (RPL) Option for Carrying RPL
2606 Information in Data-Plane Datagrams", RFC 6553,
2607 DOI 10.17487/RFC6553, March 2012,
2608 <https://www.rfc-editor.org/info/rfc6553>.
2609
2610 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
2611 Routing Header for Source Routes with the Routing Protocol
2612 for Low-Power and Lossy Networks (RPL)", RFC 6554,
2613 DOI 10.17487/RFC6554, March 2012,
2614 <https://www.rfc-editor.org/info/rfc6554>.
2615
2616 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2617 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
2618 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
2619
2620 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
2621 Writing an IANA Considerations Section in RFCs", BCP 26,
2622 RFC 8126, DOI 10.17487/RFC8126, June 2017,
2623 <https://www.rfc-editor.org/info/rfc8126>.
2624
2625 14. Informative References
2626
2627
2628
2629
2630
2631
2632 Thubert, et al. Expires 28 January 2022 [Page 47]
2633
2634 Internet-Draft DAO Projection July 2021
2635
2636
2637 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
2638 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
2639 2014, <https://www.rfc-editor.org/info/rfc7102>.
2640
2641 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and
2642 J. Martocci, "Reactive Discovery of Point-to-Point Routes
2643 in Low-Power and Lossy Networks", RFC 6997,
2644 DOI 10.17487/RFC6997, August 2013,
2645 <https://www.rfc-editor.org/info/rfc6997>.
2646
2647 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A.,
2648 and M. Richardson, Ed., "A Security Threat Analysis for
2649 the Routing Protocol for Low-Power and Lossy Networks
2650 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015,
2651 <https://www.rfc-editor.org/info/rfc7416>.
2652
2653 [6TiSCH-ARCHI]
2654 Thubert, P., Ed., "An Architecture for IPv6 over the Time-
2655 Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)",
2656 RFC 9030, DOI 10.17487/RFC9030, May 2021,
2657 <https://www.rfc-editor.org/info/rfc9030>.
2658
2659 [RAW-ARCHI]
2660 Thubert, P., Papadopoulos, G. Z., and L. Berger, "Reliable
2661 and Available Wireless Architecture/Framework", Work in
2662 Progress, Internet-Draft, draft-ietf-raw-architecture-00,
2663 12 July 2021, <https://datatracker.ietf.org/doc/html/
2664 draft-ietf-raw-architecture-00>.
2665
2666 [TURN-ON_RFC8138]
2667 Thubert, P., Ed. and L. Zhao, "A Routing Protocol for Low-
2668 Power and Lossy Networks (RPL) Destination-Oriented
2669 Directed Acyclic Graph (DODAG) Configuration Option for
2670 the 6LoWPAN Routing Header", RFC 9035,
2671 DOI 10.17487/RFC9035, April 2021,
2672 <https://www.rfc-editor.org/info/rfc9035>.
2673
2674 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas,
2675 "Deterministic Networking Architecture", RFC 8655,
2676 DOI 10.17487/RFC8655, October 2019,
2677 <https://www.rfc-editor.org/info/rfc8655>.
2678
2679 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power
2680 Wireless Personal Area Network (6LoWPAN) Paging Dispatch",
2681 RFC 8025, DOI 10.17487/RFC8025, November 2016,
2682 <https://www.rfc-editor.org/info/rfc8025>.
2683
2684
2685
2686
2687
2688 Thubert, et al. Expires 28 January 2022 [Page 48]
2689
2690 Internet-Draft DAO Projection July 2021
2691
2692
2693 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,
2694 "IPv6 over Low-Power Wireless Personal Area Network
2695 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,
2696 April 2017, <https://www.rfc-editor.org/info/rfc8138>.
2697
2698 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
2699 Perkins, "Registration Extensions for IPv6 over Low-Power
2700 Wireless Personal Area Network (6LoWPAN) Neighbor
2701 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
2702 <https://www.rfc-editor.org/info/rfc8505>.
2703
2704 [USEofRPLinfo]
2705 Robles, M.I., Richardson, M., and P. Thubert, "Using RPI
2706 Option Type, Routing Header for Source Routes, and IPv6-
2707 in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008,
2708 DOI 10.17487/RFC9008, April 2021,
2709 <https://www.rfc-editor.org/info/rfc9008>.
2710
2711 [PCE] IETF, "Path Computation Element",
2712 <https://datatracker.ietf.org/doc/charter-ietf-pce/>.
2713
2714 Appendix A. Applications
I wouldn't call this applications, its more like optimiations goals or the like
2715
2716 A.1. Loose Source Routing
Optimizing packet size vs. routing state via Loose Source Routing
2718 A RPL implementation operating in a very constrained LLN typically
2719 uses the Non-Storing Mode of Operation as represented in Figure 12.
2720 In that mode, a RPL node indicates a parent-child relationship to the
2721 Root, using a Destination Advertisement Object (DAO) that is unicast
2722 from the node directly to the Root, and the Root typically builds a
2723 source routed path to a destination down the DODAG by recursively
2724 concatenating this information.
2725
2726 ------+---------
2727 | Internet
2728 |
2729 +-----+
2730 | | Border Router
2731 | | (RPL Root)
2732 +-----+ ^ | |
2733 | | DAO | ACK |
2734 o o o o | | | Strict
2735 o o o o o o o o o | | | Source
2736 o o o o o o o o o o | | | Route
2737 o o o o o o o o o | | |
2738 o o o o o o o o | v v
2739 o o o o
2740 LLN
2741
2742
2743
2744 Thubert, et al. Expires 28 January 2022 [Page 49]
2745
2746 Internet-Draft DAO Projection July 2021
2747
2748
2749 Figure 12: RPL Non-Storing Mode of operation
2750
2751 Based on the parent-children relationships expressed in the non-
2752 storing DAO messages,the Root possesses topological information about
2753 the whole network, though this information is limited to the
2754 structure of the DODAG for which it is the destination. A packet
2755 that is generated within the domain will always reach the Root, which
2756 can then apply a source routing information to reach the destination
2757 if the destination is also in the DODAG. Similarly, a packet coming
2758 from the outside of the domain for a destination that is expected to
2759 be in a RPL domain reaches the Root.
2760
2761 It results that the Root, or then some associated centralized
2762 computation engine such as a PCE, can determine the amount of packets
2763 that reach a destination in the RPL domain, and thus the amount of
2764 energy and bandwidth that is wasted for transmission, between itself
2765 and the destination, as well as the risk of fragmentation, any
2766 potential delays because of a paths longer than necessary (shorter
2767 paths exist that would not traverse the Root).
2768
2769 As a network gets deep, the size of the source routing header that
2770 the Root must add to all the downward packets becomes an issue for
2771 nodes that are many hops away. In some use cases, a RPL network
2772 forms long lines and a limited amount of well-Targeted routing state
2773 would allow to make the source routing operation loose as opposed to
2774 strict, and save packet size.
Maybe ad to be more explicit:
And example of such well-targeted routing state is what is needed to reach the
neared loose steerig hops.
2774 Limiting the packet size is directly
2775 beneficial to the energy budget, but, mostly, it reduces the chances
2776 of frame loss and/or packet fragmentation, which is highly
2777 detrimental to the LLN operation. Because the capability to store a
2778 routing state in every node is limited, the decision of which route
2779 is installed where can only be optimized with a global knowledge of
2780 the system, a knowledge that the Root or an associated PCE may
2781 possess by means that are outside of the scope of this specification.
2782
2783 This specification enables to store a Storing Mode state in
2784 intermediate routers, which enables to limit the excursion of the
2785 source route headers in deep networks. Once a P-DAO exchange has
2786 taken place for a given Target, if the Root operates in non Storing
2787 Mode, then it may elide the sequence of routers that is installed in
2788 the network from its source route headers to destination that are
2789 reachable via that Target, and the source route headers effectively
2790 become loose.
2791
2792
2793
2794
2795
2796
2797
2798
2799
2800 Thubert, et al. Expires 28 January 2022 [Page 50]
2801
2802 Internet-Draft DAO Projection July 2021
2803
2804
2805 A.2. Transversal Routes
2806
2807 RPL is optimized for Point-to-Multipoint (P2MP) and Multipoint-to-
2808 Point (MP2P), whereby routes are always installed along the RPL DODAG
2809 respectively from and towards the DODAG Root. Transversal Peer to
2810 Peer (P2P) routes in a RPL network will generally suffer from some
2811 elongated (stretched) path versus the best possible path, since
2812 routing between 2 nodes always happens via a common parent, as
2813 illustrated in Figure 13:
That figure needs to be improved if anyone who doesn't know what a transversal
route is is expected to understand it. Just paint a picture with the minimum
number of nodes to show a transversal route not part of the DODAG.
Figure 14 is kinda ok., but in 13 its really unclear where traffic flows and why.
Also: Is there any RPL messaging that would allow for the Root to have enough
knowledge about transversal connectibity not part of the DODAG, which it could
then tell the PCE ? If not, then for fairness, it would be good to highlight this as
a gap for the solution.
2815 * In Storing Mode, unless the destination is a child of the source,
2816 the packets will follow the default route up the DODAG as well.
2817 If the destination is in the same DODAG, they will eventually
2818 reach a common parent that has a route to the destination; at
2819 worse, the common parent may also be the Root. From that common
2820 parent, the packet will follow a path down the DODAG that is
2821 optimized for the Objective Function that was used to build the
2822 DODAG.
2823
2824 * in Non-Storing Mode, all packets routed within the DODAG flow all
2825 the way up to the Root of the DODAG. If the destination is in the
2826 same DODAG, the Root must encapsulate the packet to place an RH
2827 that has the strict source route information down the DODAG to the
2828 destination. This will be the case even if the destination is
2829 relatively close to the source and the Root is relatively far off.
2830
2831
2832 ------+---------
2833 | Internet
2834 |
2835 +-----+
2836 | | Border Router
2837 | | (RPL Root)
2838 +-----+
2839 X
2840 ^ v o o
2841 ^ o o v o o o o o
2842 ^ o o o v o o o o o
2843 ^ o o v o o o o o
2844 S o o o D o o o
2845 o o o o
2846 LLN
2847
2848 Figure 13: Routing Stretch between S and D via common parent X
2849
2850 It results that it is often beneficial to enable transversal P2P
2851 routes, either if the RPL route presents a stretch from shortest
2852 path, or if the new route is engineered with a different objective,
2853
2854
2855
2856 Thubert, et al. Expires 28 January 2022 [Page 51]
2857
2858 Internet-Draft DAO Projection July 2021
2859
2860
2861 and that it is even more critical in Non-Storing Mode than it is in
2862 Storing Mode, because the routing stretch is wider. For that reason,
2863 earlier work at the IETF introduced the "Reactive Discovery of
2864 Point-to-Point Routes in Low Power and Lossy Networks" [RFC6997],
2865 which specifies a distributed method for establishing optimized P2P
2866 routes. This draft proposes an alternate based on a centralized
2867 route computation.
2868
2869 ------+---------
2870 | Internet
2871 |
2872 +-----+
2873 | | Border Router
2874 | | (RPL Root)
2875 +-----+
2876 |
2877 o o o o
2878 o o o o o o o o o
2879 o o o o o o o o o o
2880 o o o o o o o o o
2881 S>>A>>>B>>C>>>D o o o
2882 o o o o
2883 LLN
2884
2885 Figure 14: Projected Transversal Route
2886
2887 This specification enables to store source-routed or Storing Mode
2888 state in intermediate routers, which enables to limit the stretch of
2889 a P2P route and maintain the characteristics within a given SLA. An
2890 example of service using this mechanism oculd be a control loop that
2891 would be installed in a network that uses classical RPL for
2892 asynchronous data collection. In that case, the P2P path may be
2893 installed in a different RPL Instance, with a different objective
2894 function.
2895
2896 Authors' Addresses
2897
2898 Pascal Thubert (editor)
2899 Cisco Systems, Inc
2900 Building D
2901 45 Allee des Ormes - BP1200
2902 06254 Mougins - Sophia Antipolis
2903 France
2904
2905 Phone: +33 497 23 26 34
2906 Email: pthubert@cisco.com
2907
2908
2909
2910
2911
2912 Thubert, et al. Expires 28 January 2022 [Page 52]
2913
2914 Internet-Draft DAO Projection July 2021
2915
2916
2917 Rahul Arvind Jadhav
2918 Huawei Tech
2919 Kundalahalli Village, Whitefield,
2920 Bangalore 560037
2921 Karnataka
2922 India
2923
2924 Phone: +91-080-49160700
2925 Email: rahul.ietf@gmail.com
2926
2927
2928 Matthew Gillmore
2929 Itron, Inc
2930 Building D
2931 2111 N Molter Road
2932 Liberty Lake, 99019
2933 United States
2934
2935 Phone: +1.800.635.5461
2936 Email: matthew.gillmore@itron.com
2937
2938
2939
2940
2941
2942
2943
2944
2945
2946
2947
2948
2949
2950
2951
2952
2953
2954
2955
2956
2957
2958
2959
2960
2961
2962
2963
2964
2965
2966
2967
2968 Thubert, et al. Expires 28 January 2022 [Page 53]
- [Iot-directorate] IOTdir Review of draft-ietf-rol… Toerless Eckert