-
Notifications
You must be signed in to change notification settings - Fork 4
/
draft-ietf-roll-dao-projection.xml
5161 lines (4363 loc) · 228 KB
/
draft-ietf-roll-dao-projection.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="no"?>
<?rfc subcompact="no"?>
<?rfc authorship="yes"?>
<?rfc tocappendix="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" ipr='trust200902' tocInclude="true" indexInclude="true" obsoletes="" consensus="true" submissionType="IETF" xml:lang="en" version="3" docName="draft-ietf-roll-dao-projection-35" updates="6550, 6553, 8138">
<front>
<title abbrev='DAO Projection'>Root initiated routing state in RPL</title>
<author initials='P' surname='Thubert' fullname='Pascal Thubert' role='editor'>
<!-- <organization abbrev='Cisco Systems'>Cisco Systems, Inc</organization> -->
<address>
<postal>
<city>Roquefort-les-Pins</city>
<code>06330</code>
<country>France</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Rahul Arvind Jadhav" initials="R.A." surname="Jadhav">
<organization>Huawei Tech</organization>
<address>
<postal>
<street>Kundalahalli Village, Whitefield,</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560037</code>
<country>India</country>
</postal>
<phone>+91-080-49160700</phone>
<email>[email protected]</email>
</address>
</author>
<author fullname="Michael C. Richardson" initials="M."
surname="Richardson">
<organization abbrev="Sandelman">Sandelman Software Works</organization>
<address>
<email>[email protected]</email>
<uri>http://www.sandelman.ca/</uri>
</address>
</author>
<date/>
<area>Routing</area>
<workgroup>ROLL</workgroup>
<abstract>
<t>
This document extends RFC 6550, RFC 6553, and RFC 8138 to enable a RPL Root
to install and maintain Projected Routes within its DODAG, along a selected
set of nodes that may or may not include itself, for a chosen duration.
This potentially enables routes
that are more optimized or resilient than those obtained with the
classical distributed operation of RPL, either in terms of the size of a
Routing Header or in terms of path length, which impacts both the
latency and the packet delivery ratio.
</t>
</abstract>
</front>
<middle>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='introduction'><name>Introduction</name>
<t> RPL, the <xref target='RFC6550'>
"Routing Protocol for Low Power and Lossy Networks"</xref> (LLNs),
is an anisotropic Distance Vector protocol that is well-suited
for application in a variety of low energy Internet of Things (IoT)
networks where stretched P2P paths are acceptable vs. the signaling
and state overhead involved in maintaining the shortest paths across.
</t>
<t>
RPL forms Destination Oriented Directed Acyclic Graphs (DODAGs) in which
the Root often acts as the Border router to connect the RPL domain to the
IP backbone. Routers inside the DODAG route along that graph up towards
the Root for the default route and down towards destinations in the RPL
domain for more specific routes.
This specification expects as a pre-requisite a pre-existing RPL Instance
with an associated DODAG and RPL Root, which are referred to as main Instance,
main DODAG and main Root respectively. The main Instance is operated in RPL
Non-Storing Mode of Operation (MOP).
</t>
<t>
With this specification, an abstract routing function called a Path
Computation Element <xref target='PCE'/> (e.g., located in an central
controller or collocated with the main Root) interacts with the main Root to
compute Peer-to-Peer (P2P) paths within the main Instance. In Non-Storing
Mode, the base topological information to be passed to the PCE, that is the
knowledge of the main DODAG, is already available at the Root.
This specification introduces protocol extensions that enrich the topological
information available to the Root with sibling relationships that are usable
but not leveraged to form the main DODAG.
</t>
<t>
Based on usage, path length, and knowledge of available resources such as
battery levels and reservable buffers in the nodes, the PCE with a global
visibility of the system can optimize the computed routes for the
application needs, including the capability to provide path redundancy.
This specification also introduces protocol extensions that enable the
Root to translate the computed paths into RPL and install them as
Projected Routes (aka P-Routes) inside the DODAG on behalf of a PCE.
</t>
<t>
A P-Route may be installed in either Storing and Non-Storing Mode,
potentially resulting in hybrid situations where the Mode in which the P-Route operates
is different from that of the RPL main Instance.
P-Routes can be used as stand-alone Segments meant to reduce the size of the
source routing headers, leveraging loose source routing operations down the
main RPL DODAG.
P-Routes can also be combined with other P-Routes to form a protection Path
called a Track and signaled as a RPL Instance. A Track provides underlay
shortcuts in an existing main Instance, each with its own RIB.
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section><name>Terminology</name>
<section anchor='bcp'><name>Requirements Language</name>
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP 14
<xref target='RFC2119'/><xref target='RFC8174'/> when, and only when, they
appear in all capitals, as shown here.
</t>
<t>
In addition, the terms "Extends" and "Amends" are used as per
<xref target="I-D.kuehlewind-update-tag" /> section 3.
</t>
</section> <!-- end section "Requirements Language" -->
<section anchor='lo'><name>References</name>
<t>
In this document, readers will encounter terms and concepts
that are discussed in the <xref target='RFC6550'>"Routing Protocol for Low Power and Lossy Networks"</xref>, the <xref target='RFC9030'> "6TiSCH Architecture"</xref>, the <xref target='RFC8655'>
"Deterministic Networking Architecture"</xref>, the <xref target='RFC9008'>
"Using RPI Option Type, Routing Header for Source Routes, and IPv6-in-IPv6
Encapsulation in the RPL Data Plane"</xref>,
the <xref target='I-D.ietf-raw-architecture'>"Reliable and
Available Wireless (RAW) Architecture"</xref>,
and
<xref target='RFC7102'>"Terminology in Low power And Lossy Networks"</xref>.
Both architecture documents define the concept of Track in a compatible
fashion. This documents only builds Tracks that are DODAGs, meaning that all
links are oriented From Ingress to Egress.
This specification also utilizes the terms Segment and Lane that are also
defined in the RAW Architecture.
</t>
<t>
As opposed to routing trees, RPL DODAGs are typically constructed
to provide redundancy and dynamically adapt the forwarding operation to the
state of the LLN links. Note that the plain forwarding operation over DODAGs
does not provide redundancy for all nodes, since at least the node nearest
to the Root does not have an alternate feasible successor.
</t>
<t>
RAW solves that problem by defining Protection Paths that can be fully
non-congruent and can be activated dynamically upon failures. This requires
additional control to take the routing decision early enough along the Track
to route around the failure.
</t>
<t>
RAW only uses single-ended DODAGs, meaning that they can be reversed in
another DODAG by reversing all the links. The Ingress of the Track is the
Root of the DODAG, whereas the Egress is the Root of the reversed DODAG.
From the RAW perspective, single-ended DODAGs are special Tracks that only
have forward links, and that can be leveraged to provide Protection
services by defining destination-oriented Protection Paths within the DODAG.
</t>
</section> <!-- end section "References" -->
<section anchor='gloss'><name>Glossary</name>
<t> This document often uses the following acronyms:
</t><dl spacing='compact'>
<dt>ARQ:</dt><dd>Automatic Repeat Request, in other words retries</dd>
<dt>FEC:</dt><dd>Forward Error Correction</dd>
<dt>HARQ:</dt><dd> Hybrid Automatic Repeat Request, combining FEC and ARQ</dd>
<dt>CMO:</dt><dd>Control Message Option</dd>
<dt>DAO:</dt><dd>Destination Advertisement Object</dd>
<dt>DAG:</dt><dd>Directed Acyclic Graph</dd>
<dt>DODAG:</dt><dd>Destination-Oriented Directed Acyclic Graph; A DAG
with only one vertex (i.e., node) that has no outgoing edge (i.e., link)</dd>
<dt>GUA:</dt><dd>IPv6 Global Unicast Address</dd>
<dt>LLN:</dt><dd>Low-Power and Lossy Network</dd>
<dt>MOP:</dt><dd>RPL Mode of Operation</dd>
<dt>P-DAO:</dt><dd>Projected DAO </dd>
<dt>P-Route:</dt><dd>Projected Route</dd>
<dt>PDR:</dt><dd>P-DAO Request</dd>
<!--
COMMENT: The PDR acronym is not great, since there is the often-used packet delivery rate as well, but a) it is used consistently in this document, and b) it's still much better than my initially proposed no-so-well thought-out PNS extension
AUTH: OK, non actionable
-->
<dt>PCE:</dt><dd>Path Computation Element</dd>
<dt>PLR:</dt><dd>Point of Local Repair</dd>
<dt>RAN:</dt><dd>RPL-Aware Node (either a RPL router or a RPL-Aware Leaf)</dd>
<dt>RAL:</dt><dd>RPL-Aware Leaf</dd>
<dt>RH:</dt><dd>Routing Header</dd>
<dt>RIB:</dt><dd>Routing Information Base, aka the routing table. </dd>
<dt>RPI:</dt><dd>RPL Packet Information</dd>
<dt>RPL:</dt><dd>IPv6 Routing Protocol for Low-Power and Lossy Networks </dd>
<dt>RTO:</dt><dd>RPL Target Option</dd>
<dt>RUL:</dt><dd>RPL-Unaware Leaf</dd>
<dt>SIO:</dt><dd>RPL Sibling Information Option</dd>
<dt>ULA:</dt><dd>IPv6 Unique Local Address</dd>
<dt>NSM-VIO:</dt><dd>A Source-Routed Via Information Option, used in Non-Storing Mode P-DAO messages</dd>
<!--
<dt>SubDAG:</dt><dd> A DODAG Rooted at a node which is a child of that
node and a subset of a larger DAG</dd> -->
<dt>SLO:</dt><dd>Service Level Objective</dd>
<dt>TIO:</dt><dd>RPL Transit Information Option</dd>
<dt>SM-VIO:</dt><dd>A strict Via Information Option, used in Storing Mode P-DAO messages</dd>
<dt>VIO:</dt><dd>A Via Information Option; it can be an SM-VIO or a NSM-VIO</dd>
</dl>
</section> <!-- Glossary -->
<section anchor='new'><name>Domain Terms</name>
<t>
<!-- Removed reference from routing and 6tisch here to keep it simple -->
This specification uses the following terminology:
</t>
<section><name>Projected Route</name><t>
A RPL P-Route is a RPL route that is computed remotely by a PCE, and installed and maintained by a RPL Root on behalf of the PCE. It
is installed as a state that signals that destinations (aka Targets)
are reachable along a sequence of nodes.</t>
</section>
<section><name>Projected DAO</name>
<t> A DAO message used to install a P-Route. </t>
</section>
<section><name>Path</name>
<t>Quoting section 1.1.3 of <xref target="RFC1122"/>:</t>
<blockquote>
At a given moment, all the IP datagrams from a particular source host to a
particular destination host will typically traverse the same sequence of
gateways. We use the term "path" for this sequence. Note that a path is
uni-directional; it is not unusual to have different paths in the two
directions between a given host pair.
</blockquote>
<t>
Section 2 of <xref target="I-D.irtf-panrg-path-properties"/> points to a longer, more modern definition of path, which begins as follows:</t>
<blockquote>
A sequence of adjacent path elements over which a packet can
be transmitted, starting and ending with a node. A path is
unidirectional. Paths are time-dependent, i.e., the sequence of
path elements over which packets are sent from one node to another
may change. A path is defined between two nodes.
</blockquote>
<t>
It follows that the general acceptance of a path is a linear sequence of
nodes, as opposed to a multi-dimensional graph. In the context of this
document, a path is observed by following one copy of a packet that is
injected in a Track and possibly replicated within.
</t>
</section>
<section><name>Routing Stretch</name>
<t>
RPL is anisotropic, meaning that it is directional, or more exactly polar.
RPL does not behave the same way "downwards" (root towards leaves) with <em>multicast</em> DIO messages that
form the DODAG and "upwards" (leaves towards root) with <em>unicast</em> DAO messages that follow the DODAG.
This is in contrast with traditional IGPs that operate the same way in all
directions and are thus called isotropic.
</t>
<t>The term Routing Stretch denotes the length of a path, in comparison to the length of the
shortest path, which can be an abstract concept in RPL when the metrics are
statistical and dynamic, and the concept of distance varies with the Objective
Function.
</t>
<t>
The RPL DODAG optimizes the P2MP (Point-to-MultiPoint) (from the Root) and MP2P (MultiPoint-to-Point) (towards the Root) paths, but
the P2P (Point-to-Point) traffic has to follow the same DODAG. Following the
DODAG, the RPL datapath passes via a common parent in Storing Mode and
via the Root in Non-Storing Mode. This typically involves more hops and
more latency than the minimum possible for a direct P2P path that an
isotropic protocol would compute.
We refer to this elongated path as stretched.
</t>
</section>
<section><name>Track</name>
<t>
The concept of Track is inherited from the <xref target='RFC9030'>
"6TiSCH Architecture"</xref> and matches that of a Protection Path in the
<xref target='I-D.ietf-raw-architecture'> RAW Architecture"</xref>. A Track
is a networking graph that can be followed to transport packets with
equivalent treatment; as opposed to the definition of a path above,
a Track is not necessarily linear. It may contain multiple paths that
may fork and rejoin, and may enable the RAW Packet ARQ, Replication,
Elimination, and Overhearing (PAREO) operations.
</t>
<t>
<xref target='TRK'/> illustrates the mapping of the DODAG with the
generic concept of a Track, with the DODAG Root acting as Ingress
for the Track, and the mapping of Lanes and Segments, and only forward
Segments, meaning that they are directional and progressing towards the
destination.
</t>
<figure anchor='TRK'><name>A Track and its Components</name>
<artwork align="center"><![CDATA[
North East North West
A ==> B ==> C -=- F ==> G ==> H T1 I: Ingress
/ \ / \ / E: Egress
I O E -=- T2 T1, T2, T3:
\ / \ / \ External
P ==> Q ==> R -=- T ==> U ==> V T3 Targets
South East South West
I ==> A ==> B ==> C : a Segment to targets F and O
I --> F --> E : a Lane to targets T1, T2, T3
I, A, B, C, F, G, H, E : a path to T1, T2, T3
]]></artwork>
</figure>
<t>
This specification builds Tracks that are DODAGs oriented towards a Track
Ingress, and the forward direction for packets (aka forward) is from the
Track Ingress to one of the possibly multiple Track Egress Nodes, which is
also down the DODAG.
</t>
<t>
The Track may be strictly connected, meaning that the vertices are adjacent, or loosely connected, meaning that the vertices are connected using Segments that are associated to the same Track.
</t>
<section><name>TrackID</name>
<t>
A RPL InstanceID (typically of a Local Instance) that identifies a Track
using the namespace owned by the Track Ingress. For Local Instances,
the TrackID is associated with the IPv6 Address of the Track Ingress that is
used as DODAGID, and together they form a unique identification of the Track
(see the definition of DODAGID in section 2 of <xref target='RFC6550'/>.
</t>
</section>
<section><name>Namespace</name>
<t>
The term namespace is used to refer to the scope of the TrackID.
The TrackID is locally significant within its namespace.
For Local Instances, the namespace is identified by the DODAGID for the
Track and the tuple (DODAGID, TrackID) is globally unique. For Global
Instances, the namespace is the whole RPL domain.
</t>
</section>
<section><name>Complex Track</name>
<t>A Track that can be traversed via more than one path (e.g., a DODAG).
</t>
</section>
<section><name>Stand-Alone</name>
<t>
Refers to a Segment or a Lane that is installed with a single P-DAO that
fully defines the path, e.g., a stand-alone segment is installed
with a single Storing Mode Via Information option (SM-VIO) all the way
between Ingress and Egress.
</t>
</section>
<section><name>Stitching</name>
<t>
This specification uses the term stitching to indicate that a track is
piped to another one, meaning that traffic out of the first track is injected into
the other track.
</t>
</section>
<section><name>Lane</name>
<t> The concept of Lane is defined in the
<xref target='I-D.ietf-raw-architecture'> RAW Architecture"</xref>
as an end-to-end forward serial path.
With this specification, a Lane is installed by the Root of the main
DODAG using a Non-Storing Mode P-DAO message, e.g.,
I --> F --> E in <xref target="TRK"/>.
</t> <t>
As the Non-Storing Mode Via Information option (NSM-VIO) can only signal
sequences of nodes, it takes one Non-Storing Mode P-DAO message per Lane to
signal the structure of a complex Track.
</t> <t>
Each NSM-VIO for the same
TrackId but with a different Segment ID signals a different Lane that the
Track Ingress adds to the topology.
</t>
</section>
<section><name>Segment</name>
<t>
A serial path formed by a strict sequence of nodes, along which a P-Route is
installed, e.g.,
I ==> A ==> B ==> C in <xref target="TRK"/>.
With this specification, a Segment is typically installed by the Root of the
main DODAG using Storing Mode P-DAO messages. A Segment is used as
the topological edge of a Track joining the loose steps along the Lanes that
form the structure of a complex Track. The same Segment may be leveraged by
more than one Lane where the Lanes overlap.
</t> <t>
Since this specification builds only DODAGs,
all Segments are oriented from Ingress (East) to Egress (West), as opposed
to the general Track model in the <xref target='I-D.ietf-raw-architecture'>
RAW Architecture</xref>, which allows North/South Segments that can be
bidirectional as well.
</t>
<section><name>Section of a Segment</name>
<t>
A continuous subset of a Segment that may be replaced while the Segment
remains. For instance, in Segment A=>B=>C=>D=>E=>F, say that the link C to
D might be misbehaving. The section B=>C=>D=>E in the Segment may be
replaced by B=>C’=>D’=>E to route around the problem. The Segment becomes
A=>B=>C’=>D’=>E=>F.
</t>
</section>
<section><name>Segment Routing and SRH</name>
<t>
The terms Segment Routing and SRH refer to using source-routing to hop over Segments. In a Non-Storing mode RPL domain, the SRH is typically a RPL Source
Route Header (the IPv6 RH of type 3) as defined in <xref target='RFC6554'/>.
</t>
<t>
If the network is a 6LoWPAN Network, the expectation is that the
SRH is compressed and encoded as a 6LoWPAN Routing Header (6LoRH), as
specified in section 5 of <xref target='RFC8138'/>.
</t>
<t>
On the other hand, if the RPL Network is less constrained and operated in
Storing Mode, as discussed in <xref target='smmd'/>, the Segment Routing
operation and the SRH could be as specified in <xref target='RFC8754'/>.
This specification applies equally to both forms of source routing and SRH.
</t>
</section> <!-- end section "Segment Routing and SRH" -->
</section> <!-- Segment -->
</section>
</section> <!-- end section "Domain Terms" -->
</section> <!-- end section "Terminology" -->
<section anchor='context'><name>Context and Goal</name>
<section anchor='onrpl'><name>RPL Applicability</name>
<t>
RPL is optimized for situations where the power is scarce, the bandwidth is
constrained and the transmissions are unreliable. This matches the use case of
an IoT LLN where RPL is typically used today, but also situations of high relative mobility between the nodes in the network (aka swarming), e.g.,
within a variable set of vehicles with a similar global motion, or a platoon of
drones.
</t><t>
To reach this goal, RPL is primarily designed to minimize the control plane
activity, that is the relative amount of routing protocol exchanges vs. data
traffic, and the amount of state that is maintained in each node. RPL does
not need to converge, and provides connectivity to most nodes most of the time.
</t><t>
RPL may form multiple topologies called instances. Instances can be
created to enforce various optimizations through objective functions,
or to reach out through different Root Nodes. The concept of objective
function allows to adapt the activity of the routing protocol to the use
case, e.g., type, speed, and quality of the LLN links.
</t><t>
RPL instances operate as ships passing in the night, unbeknownst of one another.
The RPL Root is responsible for selecting the RPL Instance that is used
to forward a packet coming from the Backbone into the RPL domain and for setting
the related RPL information in the packets. Each Instance creates its own
routing table (RIB) in participating nodes, and the RIB associated to the instance must be used end to end in the RPL domain. To that effect, RPL
tags the packets with the Instance ID in a Hop-by-Hop extension Header.
6TiSCH leverages RPL for its distributed routing operations.
</t><t>
To reduce the routing exchanges, RPL leverages an anisotropic Distance Vector
approach, which does not need a global knowledge of the topology, and only
optimizes the routes to and from the RPL Root, allowing P2P paths to be
stretched. Although RPL installs its routes proactively, it only maintains
them lazily, in reaction to actual traffic, or as a slow background activity.
</t><t>
This is simple and efficient in situations where the traffic is mostly
directed from or to a central node, such as the control traffic between
routers and a controller of a Software Defined Networking (SDN) infrastructure or an Autonomic Control Plane (ACP).
</t><t>
But stretch in P2P routing is counter-productive to both reliability and
latency as it introduces additional delay and chances of loss. As a result,
<xref target='RFC6550'/> is not a good fit for the use cases listed in the
RAW use cases document <xref target='RFC9450'/>, which demand
high availability and reliability, and as a consequence require both short
and diverse paths.
</t>
</section> <!-- end section "RPL Applicability" -->
<section anchor='onrplroute'><name>Multi-Topology Routing and Loop Avoidance</name>
<t>
RPL first forms a default route in each node towards the Root, and those
routes together coalesce as a Directed Acyclic Graph oriented upwards.
RPL then constructs routes to destinations signaled as Targets in the reverse direction,
down the same DODAG. To do so, a RPL Instance can be operated either in RPL
Storing or Non-Storing Mode of Operation (MOP).
The default route towards the Root is maintained aggressively and may change while a packet progresses without causing loops, so the packet will still reach the Root.
</t>
<t>In Non-Storing Mode, each node advertises itself as a Target directly to the
Root, indicating the parents that may be used to reach itself. Recursively, the
Root builds and maintains an image of the whole DODAG in memory, and
leverages that abstraction to compute source route paths for the packets to
their destinations down the DODAG. When a node changes its point(s)
of attachment to the DODAG, it takes a single unicast packet to the Root along
the default route to update it, and the connectivity to the node is restored
immediately;
this mode is preferable for use cases where internet connectivity is
dominant, or when the Root controls the network activity in the
nodes, which is the case of this draft.
</t>
<t>
In Storing Mode, the routing information percolates upwards, and each
node maintains the routes to the subDAG of its descendants down the
DODAG. The maintenance is lazy, either reactive upon traffic or as a
slow background process. Packets flow via the common parent and the
routing stretch is reduced compared to Non-Storing MOP, for better P2P
connectivity. However, a new route takes a longer time to
propagate to the Root, since it takes time for the Distance-Vector protocol to
operate hop-by-hop, and the connectivity from the internet to the node is
restored more slowly upon node movement.
</t>
<t>
Either way, the RPL routes are injected by the Target nodes, in a distributed fashion. To complement RPL and eliminate routing stretch, this specification introduces a hybrid mode that combines Storing and Non-Storing operations to build and project routes onto the nodes where they should be installed. This specification uses the term Projected Route (P-Route) to refer to those routes.
</t>
<t>
In the simplest mode of this specification, Storing-Mode P-Routes can be
deployed to join the dots of a loose source routing header (SRH) in the main
DODAG. In that case, all the routes (source routed and P-Routes) belong to
the Routing Information base (RIB) associated with the main Instance.
Storing-Mode P-Routes are referred to as Segments in this specification.
</t>
<t>A set of P-Routes can also be projected to form a dotted-line underlay of the
main Instance and provide Traffic Engineered paths for an application.
In that case, the P-Routes are installed in Non-Storing Mode and the set
of P-Routes is called a Track.
A Track is associated with its own RPL Instance, and, as any RPL Instance,
with its own Routing Information base (RIB). As a result, each Track defines
a routing topology in the RPL domain. As for the main DODAG, Segments
associated to the Track Instance may be deployed to join the dots using
Storing-Mode P-Routes.
</t>
<t>
Routing in a multi-topology domain may cause loops unless strict rules are
applied. This specification defines two strict orders to ensure loop
avoidance when projected routes are used in a RPL domain, one between
forwarding methods and one between RPL Instances, seen as routing topologies.
</t> <t>
The first and strict order relates to the forwarding method and the more
specifically the origin of the information used in the next-hop computation.
The possible forwarding methods are: 1) to a direct next hop, 2) to an indirect
neighbor via a common neighbor, 3) along a Segment, and 4) along a nested Track.
The methods are strictly ordered as listed above, more in <xref target = "routing"/>.
A forwarding method may leverage any of the lower order ones, but never one
with a higher order; for instance, when forwarding a packet along a Segment,
the router may use direct or indirect neighbors but cannot use a Track.
The lower order methods have a strict precedence, so the router will always
prefer a direct neighbor over an indirect one, or a Segment within the
current RPL Instance vs. another Track.
</t> <t>
The second strict and partial order is between RPL Instances. It allows the
RPL node to detect an error in the state installed by the
PCE, e.g., after a desynchronization.
That order must be defined by the administrator for his RPL domain and
defines a DODAG of underlays with the main Instance as Root.
The relation of RPL instances may be represented as a DODAG of instances
where the main instance is Root. The rule is that a RPL Instance may leverage
another RPL instance as underlay if and only if
that other Instance is one of its descendants in the graph.
Supporting this method is OPTIONAL for nested Tracks and REQUIRED between
a Track instance and the main instance.
<!-- The way this graph is communicated to the RPL nodes is out of scope. -->
It may be done using network management, or future extensions to this
specifications. When it is not communicated, then the RPL nodes consider by
default that all Track instances are children of the main instance, and do not
attempt to validate the order for nested Tracks, trusting the PCE implicitly.
As a result, a packet that is being forwarded along the main Instance may be
encapsulated in any Track, but a packet that was forwarded along a Track MUST
NOT be forwarded along the default route of main Instance.
</t>
</section> <!-- end section "Multi-Topology Routing and Loop Avoidance" -->
<section><name>Requirements</name>
<section anchor='loose'><name>Loose Source Routing</name>
<t>A RPL implementation operating in a very constrained LLN typically uses
the Non-Storing Mode of Operation as represented in <xref target='nost'/>.
In that mode, a RPL node indicates a
parent-child relationship to the Root, using a destination Advertisement
Object (DAO) that is unicast from the node directly to the Root,
and the Root typically builds a source routed path to a destination down
the DODAG by recursively concatenating this information.
</t>
<figure anchor='nost'><name>RPL Non-Storing Mode of operation </name>
<artwork>
+-----+
| | Border router
| | (RPL Root)
+-----+ ^ | |
| | DAO | ACK |
o o o o | | | Strict
o o o o o o o o o | | | Source
o o o o o o o o o o | | | Route
o o o o o o o o o | | |
o o o o o o o o | v v
o o o o
LLN
</artwork>
</figure>
<t>
Based on the parent-children relationships expressed in the Non-
Storing DAO messages, the Root possesses topological information
about the whole network, though this information is limited to the
structure of the DODAG for which it is the destination. A packet
that is generated within the domain will always reach the Root, which
can then apply a source routing information to reach the destination
if the destination is also in the DODAG. Similarly, a packet coming
from the outside of the domain for a destination that is expected to
be in a RPL domain reaches the Root. This results in the wireless
bandwidth near the Root being the limiting factor for all transmissions
towards or within the domain, and that the Root is a single point of
failure for all connectivity to nodes within its domain.
</t>
<t>
The RPL Root must add a source routing header to all downward packets.
As a network grows, the size of the source routing header increases
with the depth of the network. In some use cases, a RPL network forms
long lines along physical structures such as streets for lighting.
Limiting the packet size is beneficial to the energy budget, directly
for the current transmission, but also indirectly since it reduces the
chances of frame loss and energy spent in retries, e.g., by ARQ over one hop
at Layer-2, or end-to-end at upper layers.
Using smaller packets also reduces the chances of
packet fragmentation, which is highly detrimental to the LLN operation, in
particular when fragments are forwarded but not recovered, see
<xref target="RFC8930"/> vs. <xref target="RFC8931"/> for more.
</t>
<t>
A limited amount of well-targeted routing state would allow the
source routing operation to be loose as opposed to strict, and reduce the
overhead of routing information in packets.
Because the capability to store routing state in every node
is limited, the decision of which route is installed where can only
be optimized with global knowledge of the system, knowledge that
the Root or an associated PCE may possess by means that are outside
the scope of this specification.
</t>
<t>
Being on-path for all packets in Non-Storing mode, the Root may
determine the number of P2P packets in its RPL domain per source and
destination, the latency incurred, and the amount of energy and
bandwidth that is consumed to reach itself and then back down, including
possible fragmentation when encapsulating larger packets. Enabling
a shorter path that would not traverse the Root for select P2P
source/destinations may improve the latency, lower the consumption of
constrained resources, free bandwidth at the bottleneck near the
Root, improve the delivery ratio and reduce the latency for those P2P
flows with a global benefit for all flows by reducing the load at the
Root.
</t>
<t>
To limit the need for source route headers in deep networks, one possibility
is to store a routing state associated with the main DODAG in select RPL
routers down the path. The Root may elide the sequence of routers
that is installed in the network from its source route header, which therefore
becomes loose, in contrast to being strict in <xref target="RFC6550"/>.
</t>
</section> <!-- Loose Source Routing -->
<section><name>forward Routes</name>
<t>
<xref target="RFC6550"/> optimizes Point-to-Multipoint (P2MP) routes from
the Root, Multipoint-to-Point (MP2P) routes to the DODAG Root, and
Internet access when the Root also serves as Border Router.
All routes are installed North-South (aka up/down) along the RPL DODAG.
Peer to Peer (P2P) forward routes in a RPL network will generally
experience elongated (stretched) paths versus direct (optimized)
paths, since routing between two nodes always happens via a common
parent, as illustrated in <xref target='stretch'/>:
</t>
<figure anchor='stretch'><name>Routing Stretch between S and D via common parent X along North-South Paths</name>
<artwork>
------+---------
| Internet
+-----+
| | Border router
| | (RPL Root)
+-----+
X
^ v o o
^ o o v o o o o o
^ o o o v o o o o o
^ o o v o o o o o
S o o o D o o o
o o o o
LLN
</artwork>
</figure>
<t>As described in <xref target="RFC9008" />, the amount of stretch depends on the Mode of Operation: </t>
<ul spacing='normal'>
<li> in Non-Storing Mode, all packets
routed within the DODAG flow all the way up to the Root of the DODAG. If
the destination is in the same DODAG, the Root must encapsulate the packet
to place an RH that has the strict source route information down
the DODAG to the destination. This will be the case even if the destination
is relatively close to the source and the Root is relatively far off.
</li>
<li>In Storing Mode, unless the destination is a child of the source,
the packets will follow the default route up the DODAG as well.
If the destination is in the same DODAG, they will eventually reach a
common parent that has a route to the destination; at worse, the common
parent may also be the Root. From that common parent, the packet will
follow a path down the DODAG that is optimized for the Objective Function
that was used to build the DODAG.</li>
</ul>
<t>
It turns out that it is often beneficial to enable forward P2P routes,
either if the RPL route presents a stretch from the shortest path, or if the
new route is engineered with a different objective, and this is
even more critical in Non-Storing Mode than it is in Storing Mode, because
the routing stretch is wider.
For that reason, earlier work at the IETF introduced the
<xref target='RFC6997'>"Reactive Discovery of Point-to-Point Routes in
Low Power and Lossy Networks"</xref>, which specifies a distributed method for
establishing optimized P2P routes. This draft proposes an alternative based
on centralized route computation.
</t>
<figure anchor='opti2'><name>More direct forward Route between S and D</name>
<artwork>
+-----+
| | Border router
| | (RPL Root)
+-----+
|
o o o o
o o o o o o o o o
o o o o o o o o o o
o o o o o o o o o
S>>A>>>B>>C>>>D o o o
o o o o
LLN
</artwork>
</figure>
<t>
The requirement is to install additional routes in the RPL routers,
to reduce the stretch of some P2P routes and maintain the characteristics
within a given SLO, e.g., in terms of latency and/or reliability.
</t>
</section>
</section> <!-- Requirements -->
<section anchor='tracks'><name>On Tracks</name>
<section anchor='ctracks'><name>Building Tracks With RPL</name>
<t>
The concept of a Track was introduced in the <xref target='RFC9030'>
"6TiSCH Architecture"</xref>, as a collection of potential paths that
leverage redundant forwarding solutions along the way. This can be a
DODAG or a more complex structure that is only partially acyclic
(e.g., per packet).
</t>
<t>
With this specification, a Track is shaped as a DODAG, and following the
directed edges leads to a Track Ingress. Storing Mode P-DAO messages follow
the direction of the edges to set up routes for traffic that flows the
other way, towards the Track Egress(es). If there is a single Track Egress,
then the Track is reversible to form another DODAG by reversing the
direction of each edge. A node at the Ingress of more than one Segment in a
Track may use one or more of these Segments to forward a packet inside the
Track.
</t>
<t>
A RPL Track is a collection of (one or more) parallel loose source routed
sequences of nodes ordered from Ingress to Egress, each forming a lane.
The nodes that are directly connected, reachable via existing Tracks as
illustrated in <xref target='nssr'/> or joined with strict Segments of
other nodes as shown in <xref target='srpdao'/>.
The Lanes are expressed in RPL Non-Storing Mode and require an encapsulation
to add a Source Route Header, whereas the Segments are expressed in RPL
Storing Mode.
</t>
<t>
A path provides only one path between Ingress and Egress.
It comprises at most one Lane. A Stand-Alone Segment implicitly defines a
path from its Ingress to Egress.
</t>
<t> A complex Track forms a graph that provides a collection of potential paths
to provide redundancy for the packets, either as a collection of Lanes that
may be parallel or cross at certain points, or as a more generic DODAG.
</t>
</section><!-- Building Tracks -->
<section anchor='stracks'><name>Tracks and RPL Instances</name>
<t>
Section 5.1. of <xref target='RFC6550'/> describes the RPL Instance and
its encoding. There can be up to 128 Global RPL Instances, for which there
can be one or more DODAGs, and there can be 64 local RPL Instances, with a
namespace that is indexed by a DODAGID, where the DODAGID is a Unique Local
Address (ULA) or a Global Unicast Address (GUA) of the Root of the DODAG.
Bit 0 (most significant) is set to 1 to signal a Local RPLInstanceID, as
shown in <xref target='rpid'/>. By extension, this specification expresses
the value of the RPLInstanceID as a single integer between 128 and 191,
representing both the Local RPLInstanceID in 0..63 in the rightmost bits
and Bit 0 set.
</t>
<figure anchor='rpid'><name>Local RPLInstanceID Encoding</name>
<artwork align="center">
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1|D| ID | Local RPLInstanceID in 0..63
+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
A Track typically forms an underlay to the main Instance, and is associated
with a Local RPL Instance from which the RPLInstanceID is used as the TrackID.
When a packet is placed on a Track, it is encapsulated IP-in-IP with a
RPL Option containing a RPI which signals the RPLInstanceID.
The encapsulating source IP address and RPI Instance are set to the Track
Ingress IP address and local RPLInstanceID, respectively, more in
<xref target='trkid'/>.
</t>
<t>
A Track typically offers service protection across several lanes.
As a degraded form of a Track, a path made of a single lane
(i.e., offering no protection) can be used as an alternative to a Segment for
forwarding along a RPL Instance.
In that case, instead of following native routes along the instance, the
packets are encapsulated to signal a more specific source-routed path between
the loose hops in the encapsulated source routing header.
</t><t>
If the
encapsulated packet follows a global instance, then the lane may be part that
global instance as well, for instance the global instance of the main DODAG.
This can only be done for global instances because the Ingress node that
encapsulates the packets over the lane is not the Root of the instance,
so the source address of the encapsulated packet cannot be used to determine
the Track along the way.
</t>
</section><!-- Tracks and RPL Instances -->
</section><!-- On tracks -->
<section><name>path Signaling</name>
<t>
This specification enables setting up a P-Route along either a lane or a
Segment. A P-Route is installed and maintained by the Root of the main DODAG
using an extended RPL DAO message called a Projected DAO (P-DAO), and a Track
is composed of the combination of one or more P-Routes. In order to clarify
the techniques that may be used to install a P-Route, this section takes the
simple case of the path illustrated in <xref target='reft'/>.
So the goal is to build a path from node A to E for packets towards E's
neighbors F and G along A, B, C, D and E as opposed to via the Root:
</t>
<figure anchor='reft'><name>Reference Track</name>
<artwork align="center">
/===> F
A ===> B ===> C ===> D===> E <
\===> G
</artwork>
</figure>
<t>
A P-DAO message for a Track signals the TrackID in the RPLInstanceID field.
In the case of a local RPL Instance, the address of the Track Ingress is
used as source to encapsulate packets along the Track. The Track is signaled
in the DODAGID field of the Projected DAO Base Object,
see <xref target='p-dao-fmt'/>.
</t><t>
This specification introduces the Via Information Option (VIO) to signal a sequence of hops in a
Lane or a Segment in the P-DAO messages, either in Storing Mode (SM-VIO) or
Non-Storing Mode (NSM-VIO). One P-DAO message contains a single VIO,
associated to one or more RPL Target Options that signal the destination
IPv6 addresses that can reached along the Track (more in <xref target='viof'/>).
</t>
<t>
Before diving deeper into Track Lanes and Segments signaling and operation,
this section provides examples of how route projection works through
variations of a simple example. This simple example illustrates the case of
host routes, though RPL Targets can also be prefixes.
</t>
<t>
Conventionally we use ==> to represent a strict hop and --> for a
loose hop.
We use "-to-", such as in C==>D==>E-to-F to represent coma-separated
Targets, e.g., F is a Target for Segment C==>D==>E.
In this example, A is the Track Ingress and E is the Track Egress. C is a stitching
point. F and G are "external” Targets for the Track, and become reachable
from A via the Track A (Ingress) to E (Egress and implicit Target in
Non-Storing Mode) leading to F and G (explicit Targets).
</t>
<t>
In a general manner the desired outcome is as follows:
</t>
<ul>
<li>Targets are E, F, and G </li>
<li>P-DAO 1 signals C==>D==>E</li>
<li>P-DAO 2 signals A==>B==>C</li>
<li>P-DAO 3 signals F and G via the A-->E Track</li>
</ul>
<t>
P-DAO 3 may be ommitted if P-DAO 1 and 2 signal F and G as Targets.
</t>
<t>
Loose sequences of hops are expressed in Non-Storing Mode; this is why P-DAO 3
contains a NSM-VIO. With this specification:
</t>
<ul>
<li>
the DODAGID to be used by the Ingress as source address is signaled
in the DAO base object (see <xref target='p-dao-fmt'/>) .
</li><li>
the via list in the VIO is encoded as an SRH-6LoRH (see <xref target='viao'/>),
and it starts with the address of the first hop node after the Ingress node
in the loose hop sequence.
</li><li>
the via list ends with the address of the Egress node.
</li>
</ul>
<t> Note well:
</t>
<blockquote>
The Egress of a Non-Storing Mode P-Route is implicitly a target; it is
not listed in the RPL Target Options but still accounted for as if it was.
The only exception is when the Egress is the only address listed in the
VIO, in which case it would indicate via itself which would be non-sensical.
</blockquote>
<t>
Also:
</t>