-
Notifications
You must be signed in to change notification settings - Fork 4
/
draft-ietf-roll-dao-projection.txt
4928 lines (3432 loc) · 211 KB
/
draft-ietf-roll-dao-projection.txt
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
ROLL P. Thubert, Ed.
Internet-Draft
Updates: 6550, 6553, 8138 (if approved) R.A. Jadhav
Intended status: Standards Track Huawei Tech
Expires: 2 June 2024 M. Richardson
Sandelman
30 November 2023
Root initiated routing state in RPL
draft-ietf-roll-dao-projection-34
Abstract
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 2 June 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Thubert, et al. Expires 2 June 2024 [Page 1]
Internet-Draft DAO Projection November 2023
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2.2. References . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Domain Terms . . . . . . . . . . . . . . . . . . . . . . 6
2.4.1. Projected Route . . . . . . . . . . . . . . . . . . . 6
2.4.2. Projected DAO . . . . . . . . . . . . . . . . . . . . 7
2.4.3. Path . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.4. Routing Stretch . . . . . . . . . . . . . . . . . . . 7
2.4.5. Track . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Context and Goal . . . . . . . . . . . . . . . . . . . . . . 10
3.1. RPL Applicability . . . . . . . . . . . . . . . . . . . . 11
3.2. Multi-Topology Routing and Loop Avoidance . . . . . . . . 12
3.3. Requirements . . . . . . . . . . . . . . . . . . . . . . 14
3.3.1. Loose Source Routing . . . . . . . . . . . . . . . . 14
3.3.2. forward Routes . . . . . . . . . . . . . . . . . . . 16
3.4. On Tracks . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4.1. Building Tracks With RPL . . . . . . . . . . . . . . 17
3.4.2. Tracks and RPL Instances . . . . . . . . . . . . . . 18
3.5. path Signaling . . . . . . . . . . . . . . . . . . . . . 19
3.5.1. Using Storing Mode Segments . . . . . . . . . . . . . 21
3.5.2. Using Non-Storing Mode joining Tracks . . . . . . . . 27
3.6. Complex Tracks . . . . . . . . . . . . . . . . . . . . . 34
3.7. Scope and Expectations . . . . . . . . . . . . . . . . . 36
3.7.1. External Dependencies . . . . . . . . . . . . . . . . 36
3.7.2. Positioning vs. Related IETF Standards . . . . . . . 36
4. Extending existing RFCs . . . . . . . . . . . . . . . . . . . 38
4.1. Extending RFC 6550 . . . . . . . . . . . . . . . . . . . 38
4.1.1. Projected DAO . . . . . . . . . . . . . . . . . . . . 39
4.1.2. Projected DAO-ACK . . . . . . . . . . . . . . . . . . 41
4.1.3. Via Information Option . . . . . . . . . . . . . . . 42
4.1.4. Sibling Information Option . . . . . . . . . . . . . 42
4.1.5. P-DAO Request . . . . . . . . . . . . . . . . . . . . 43
4.1.6. Amending the RPI . . . . . . . . . . . . . . . . . . 43
4.1.7. Additional Flag in the RPL DODAG Configuration
Option . . . . . . . . . . . . . . . . . . . . . . . 43
4.2. Extending RFC 6553 . . . . . . . . . . . . . . . . . . . 44
4.3. Extending RFC 8138 . . . . . . . . . . . . . . . . . . . 45
5. New RPL Control Messages and Options . . . . . . . . . . . . 46
Thubert, et al. Expires 2 June 2024 [Page 2]
Internet-Draft DAO Projection November 2023
5.1. New P-DAO Request Control Message . . . . . . . . . . . . 47
5.2. New PDR-ACK Control Message . . . . . . . . . . . . . . . 48
5.3. Via Information Options . . . . . . . . . . . . . . . . . 49
5.4. Sibling Information Option . . . . . . . . . . . . . . . 52
6. Root Initiated Routing State . . . . . . . . . . . . . . . . 54
6.1. RPL Network Setup . . . . . . . . . . . . . . . . . . . . 54
6.2. Requesting a Track . . . . . . . . . . . . . . . . . . . 55
6.3. Identifying a Track . . . . . . . . . . . . . . . . . . . 56
6.4. Installing a Track . . . . . . . . . . . . . . . . . . . 57
6.4.1. Signaling a Projected Route . . . . . . . . . . . . . 58
6.4.2. Installing a Track Segment with a Storing Mode
P-Route . . . . . . . . . . . . . . . . . . . . . . . 59
6.4.3. Installing a lane with a Non-Storing Mode P-Route . . 61
6.5. Tearing Down a P-Route . . . . . . . . . . . . . . . . . 63
6.6. Maintaining a Track . . . . . . . . . . . . . . . . . . . 63
6.6.1. Maintaining a Track Segment . . . . . . . . . . . . . 64
6.6.2. Maintaining a lane . . . . . . . . . . . . . . . . . 64
6.7. Encapsulating and Forwarding Along a Track . . . . . . . 65
6.8. Compression of the RPL Artifacts . . . . . . . . . . . . 68
7. Lesser Constrained Variations . . . . . . . . . . . . . . . . 70
7.1. Storing Mode main DODAG . . . . . . . . . . . . . . . . . 70
7.2. A Track as a Full DODAG . . . . . . . . . . . . . . . . . 72
8. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 73
9. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 75
10. Security Considerations . . . . . . . . . . . . . . . . . . . 75
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 76
11.1. RPL DODAG Configuration Option Flag . . . . . . . . . . 76
11.2. Elective 6LoWPAN Routing Header Type . . . . . . . . . . 76
11.3. Critical 6LoWPAN Routing Header Type . . . . . . . . . . 77
11.4. Registry For The RPL Option Flags . . . . . . . . . . . 77
11.5. RPL Control Codes . . . . . . . . . . . . . . . . . . . 78
11.6. RPL Control Message Options . . . . . . . . . . . . . . 78
11.7. SubRegistry for the Projected DAO Request Flags . . . . 78
11.8. SubRegistry for the PDR-ACK Flags . . . . . . . . . . . 79
11.9. Registry for the PDR-ACK Acceptance Status Values . . . 79
11.10. Registry for the PDR-ACK Rejection Status Values . . . . 80
11.11. SubRegistry for the Via Information Options Flags . . . 80
11.12. SubRegistry for the Sibling Information Option Flags . . 81
11.13. Destination Advertisement Object Flag . . . . . . . . . 81
11.14. Destination Advertisement Object Acknowledgment Flag . . 82
11.15. New ICMPv6 Error Code . . . . . . . . . . . . . . . . . 82
11.16. RPL Rejection Status values . . . . . . . . . . . . . . 82
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 83
13. Normative References . . . . . . . . . . . . . . . . . . . . 83
14. Informative References . . . . . . . . . . . . . . . . . . . 85
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 87
Thubert, et al. Expires 2 June 2024 [Page 3]
Internet-Draft DAO Projection November 2023
1. Introduction
RPL, the "Routing Protocol for Low Power and Lossy Networks" [RPL]
(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.
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).
With this specification, an abstract routing function called a Path
Computation Element [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.
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.
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.
Thubert, et al. Expires 2 June 2024 [Page 4]
Internet-Draft DAO Projection November 2023
2. Terminology
2.1. Requirements Language
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 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here.
In addition, the terms "Extends" and "Amends" are used as per
[I-D.kuehlewind-update-tag] section 3.
2.2. References
In this document, readers will encounter terms and concepts that are
discussed in the "Routing Protocol for Low Power and Lossy Networks"
[RPL], the "6TiSCH Architecture" [RFC9030], the "Deterministic
Networking Architecture" [RFC8655], the "Using RPI Option Type,
Routing Header for Source Routes, and IPv6-in-IPv6 Encapsulation in
the RPL Data Plane" [RFC9008], the "Reliable and Available Wireless
(RAW) Architecture" [RAW-ARCHI], and "Terminology in Low power And
Lossy Networks" [RFC7102]. 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.
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.
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.
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.
Thubert, et al. Expires 2 June 2024 [Page 5]
Internet-Draft DAO Projection November 2023
2.3. Glossary
This document often uses the following acronyms:
ARQ: Automatic Repeat Request, in other words retries
FEC: Forward Error Correction
HARQ: Hybrid Automatic Repeat Request, combining FEC and ARQ
CMO: Control Message Option
DAO: Destination Advertisement Object
DAG: Directed Acyclic Graph
DODAG: Destination-Oriented Directed Acyclic Graph; A DAG with only
one vertex (i.e., node) that has no outgoing edge (i.e., link)
GUA: IPv6 Global Unicast Address
LLN: Low-Power and Lossy Network
MOP: RPL Mode of Operation
P-DAO: Projected DAO
P-Route: Projected Route
PDR: P-DAO Request
PCE: Path Computation Element
PLR: Point of Local Repair
RAN: RPL-Aware Node (either a RPL router or a RPL-Aware Leaf)
RAL: RPL-Aware Leaf
RH: Routing Header
RIB: Routing Information Base, aka the routing table.
RPI: RPL Packet Information
RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks
RTO: RPL Target Option
RUL: RPL-Unaware Leaf
SIO: RPL Sibling Information Option
ULA: IPv6 Unique Local Address
NSM-VIO: A Source-Routed Via Information Option, used in Non-Storing
Mode P-DAO messages
SLO: Service Level Objective
TIO: RPL Transit Information Option
SM-VIO: A strict Via Information Option, used in Storing Mode P-DAO
messages
VIO: A Via Information Option; it can be an SM-VIO or a NSM-VIO
2.4. Domain Terms
This specification uses the following terminology:
2.4.1. Projected Route
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.
Thubert, et al. Expires 2 June 2024 [Page 6]
Internet-Draft DAO Projection November 2023
2.4.2. Projected DAO
A DAO message used to install a P-Route.
2.4.3. Path
Quoting section 1.1.3 of [INT-ARCHI]:
| 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.
Section 2 of [I-D.irtf-panrg-path-properties] points to a longer,
more modern definition of path, which begins as follows:
| 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.
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.
2.4.4. Routing Stretch
RPL is anisotropic, meaning that it is directional, or more exactly
polar. RPL does not behave the same way "downwards" (root towards
leaves) with _multicast_ DIO messages that form the DODAG and
"upwards" (leaves towards root) with _unicast_ 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.
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.
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
Thubert, et al. Expires 2 June 2024 [Page 7]
Internet-Draft DAO Projection November 2023
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.
2.4.5. Track
The concept of Track is inherited from the "6TiSCH Architecture"
[RFC9030] and matches that of a Protection Path in the RAW
Architecture" [RAW-ARCHI]. 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.
Figure 1 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.
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
Figure 1: A Track and its Components
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.
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.
Thubert, et al. Expires 2 June 2024 [Page 8]
Internet-Draft DAO Projection November 2023
2.4.5.1. TrackID
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 [RPL].
2.4.5.2. Namespace
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.
2.4.5.3. Complex Track
A Track that can be traversed via more than one path (e.g., a DODAG).
2.4.5.4. Stand-Alone
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.
2.4.5.5. Stitching
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.
2.4.5.6. Lane
The concept of Lane is defined in the RAW Architecture" [RAW-ARCHI]
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 Figure 1.
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.
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.
Thubert, et al. Expires 2 June 2024 [Page 9]
Internet-Draft DAO Projection November 2023
2.4.5.7. Segment
A serial path formed by a strict sequence of nodes, along which a
P-Route is installed, e.g., I ==> A ==> B ==> C in Figure 1. 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.
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 RAW Architecture [RAW-ARCHI], which allows
North/South Segments that can be bidirectional as well.
2.4.5.7.1. Section of a Segment
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.
2.4.5.7.2. Segment Routing and SRH
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 [RFC6554].
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 [RFC8138].
On the other hand, if the RPL Network is less constrained and
operated in Storing Mode, as discussed in Section 7.1, the Segment
Routing operation and the SRH could be as specified in [RFC8754].
This specification applies equally to both forms of source routing
and SRH.
3. Context and Goal
Thubert, et al. Expires 2 June 2024 [Page 10]
Internet-Draft DAO Projection November 2023
3.1. RPL Applicability
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.
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.
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.
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.
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.
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).
Thubert, et al. Expires 2 June 2024 [Page 11]
Internet-Draft DAO Projection November 2023
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, [RPL] is not a good fit for the use cases listed in the
RAW use cases document [RFC9450], which demand high availability and
reliability, and as a consequence require both short and diverse
paths.
3.2. Multi-Topology Routing and Loop Avoidance
RPL first forms a default route in each node towards the Root, and
those routes together coalesce as a Directed Acyclic Graph oriented
upwards. RPL then constructs routes to destinations signaled as
Targets in the reverse direction, down the same DODAG. To do so, a
RPL Instance can be operated either in RPL Storing or Non-Storing
Mode of Operation (MOP). The default route towards the Root is
maintained aggressively and may change while a packet progresses
without causing loops, so the packet will still reach the Root.
In 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.
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.
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.
Thubert, et al. Expires 2 June 2024 [Page 12]
Internet-Draft DAO Projection November 2023
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.
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.
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.
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 Section 6.7. 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.
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. It may
be done using network management, or future extensions to this
specifications. When it is not communicated, then the RPL nodes
Thubert, et al. Expires 2 June 2024 [Page 13]
Internet-Draft DAO Projection November 2023
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.
3.3. Requirements
3.3.1. Loose Source Routing
A RPL implementation operating in a very constrained LLN typically
uses the Non-Storing Mode of Operation as represented in Figure 2.
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.
+-----+
| | 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
Figure 2: RPL Non-Storing Mode of operation
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.
Thubert, et al. Expires 2 June 2024 [Page 14]
Internet-Draft DAO Projection November 2023
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
[RFC8930] vs. [RFC8931] for more.
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.
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.
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 [RPL].
Thubert, et al. Expires 2 June 2024 [Page 15]
Internet-Draft DAO Projection November 2023
3.3.2. forward Routes
[RPL] 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 Figure 3:
------+---------
| 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
Figure 3: Routing Stretch between S and D via common parent X
along North-South Paths
As described in [RFC9008], the amount of stretch depends on the Mode
of Operation:
* 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.
* 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.
Thubert, et al. Expires 2 June 2024 [Page 16]
Internet-Draft DAO Projection November 2023
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 "Reactive Discovery of
Point-to-Point Routes in Low Power and Lossy Networks" [RFC6997],
which specifies a distributed method for establishing optimized P2P
routes. This draft proposes an alternative based on centralized
route computation.
+-----+
| | 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
Figure 4: More direct forward Route between S and D
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.
3.4. On Tracks
3.4.1. Building Tracks With RPL
The concept of a Track was introduced in the "6TiSCH Architecture"
[RFC9030], 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).
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.
Thubert, et al. Expires 2 June 2024 [Page 17]
Internet-Draft DAO Projection November 2023
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 Section 3.5.2.3 or joined with
strict Segments of other nodes as shown in Section 3.5.1.3. 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.
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.
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.
3.4.2. Tracks and RPL Instances
Section 5.1. of [RPL] 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 Figure 5. 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.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1|D| ID | Local RPLInstanceID in 0..63
+-+-+-+-+-+-+-+-+
Figure 5: Local RPLInstanceID Encoding
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