-
Notifications
You must be signed in to change notification settings - Fork 0
/
rfc6550bis.xml
18496 lines (14044 loc) · 689 KB
/
rfc6550bis.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">
<!-- Compiles with XML2RFC v3 https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc-dev.cgi -->
<?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" docName="draft-pthubert-roll-rfc6550bis-00"
ipr="trust200902" obsoletes="" updates="6550" submissionType="IETF" xml:lang="en" version="3">
<front>
<title abbrev="RPL">RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks</title>
<author initials="P" surname="Thubert" fullname="Pascal Thubert" role="editor">
<organization abbrev="Cisco Systems">Cisco Systems, Inc</organization>
<address>
<postal>
<street>Building D</street>
<street>45 Allee des Ormes - BP1200 </street>
<city>MOUGINS - Sophia Antipolis</city>
<code>06254</code>
<country>France</country>
</postal>
<phone>+33 497 23 26 34</phone>
<email>pthubert@cisco.com</email>
</address>
</author>
<author fullname="Tim Winter" initials="T" role="editor" surname="Winter">
<organization></organization>
<address>
<email>wintert@acm.org</email>
</address>
</author>
<date/>
<area>Routing Area</area>
<workgroup>ROLL</workgroup>
<keyword>Draft</keyword>
<abstract>
<t>
Low-Power and Lossy Networks (LLNs) are a class of network in which
both the routers and their interconnect are constrained. LLN routers
typically operate with constraints on processing power, memory, and
energy (battery power). Their interconnects are characterized by
high loss rates, low data rates, and instability. LLNs are comprised
of anything from a few dozen to thousands of routers. Supported
traffic flows include point-to-point (between devices inside the
LLN), point-to-multipoint (from a central control point to a subset
of devices inside the LLN), and multipoint-to-point (from devices
inside the LLN towards a central control point). This document
specifies the IPv6 Routing Protocol for Low-Power and Lossy Networks
(RPL), which provides a mechanism whereby multipoint-to-point traffic
from devices inside the LLN towards a central control point as well
as point-to-multipoint traffic from the central control point to the
devices inside the LLN are supported. Support for point-to-point
traffic is also available.
</t>
</abstract>
</front>
<middle>
<section numbered="true" toc="default">
<name>Introduction</name>
<t>
Low-power and Lossy Networks (LLNs) consist largely of constrained
nodes (with limited processing power, memory, and sometimes energy
when they are battery operated or energy scavenging). These routers
are interconnected by lossy links, typically supporting only low data
rates, that are usually unstable with relatively low packet delivery
rates. Another characteristic of such networks is that the traffic
patterns are not simply point-to-point, but in many cases point-to-
multipoint or multipoint-to-point. Furthermore, such networks may
potentially comprise up to thousands of nodes. These characteristics
offer unique challenges to a routing solution: the IETF ROLL working
group has defined application-specific routing requirements for a
Low-power and Lossy Network (LLN) routing protocol, specified in
<xref target='RFC5867'/>,
<xref target='RFC5826'/>,
<xref target='RFC5673'/>, and
<xref target='RFC5548'/>.
</t>
<t>
This document specifies the IPv6 Routing Protocol for LLNs (RPL).
Note that although RPL was specified according to the requirements
set forth in the aforementioned requirement documents, its use is in
no way limited to these applications.
</t>
<section numbered="true" toc="default">
<name>Design Principles</name>
<t>
RPL was designed with the objective to meet the requirements spelled
out in
<xref target='RFC5867'/>,
<xref target='RFC5826'/>,
<xref target='RFC5673'/>, and
<xref target='RFC5548'/>.
</t>
<t>
A network may run multiple instances of RPL concurrently. Each such
instance may serve different and potentially antagonistic constraints
or performance criteria. This document defines how a single instance
operates.
</t>
<t>
In order to be useful in a wide range of LLN application domains, RPL
separates packet processing and forwarding from the routing
optimization objective. Examples of such objectives include
minimizing energy, minimizing latency, or satisfying constraints.
This document describes the mode of operation of RPL. Other
companion documents specify routing Objective Functions. A RPL
implementation, in support of a particular LLN application, will
include the necessary Objective Function(s) as required by the
application.
</t>
<t>
RPL operations require bidirectional links. In some LLN scenarios,
those links may exhibit asymmetric properties. It is required that
the reachability of a router be verified before the router can be
used as a parent. RPL expects an external mechanism to be triggered
during the parent selection phase in order to verify link properties
and neighbor reachability. Neighbor Unreachability Detection (NUD)
is such a mechanism, but alternates are possible, including
<!-- [8] -->
Bidirectional Forwarding Detection (BFD) <xref target='RFC5881'/> and hints from
lower layers via Layer 2 (L2) triggers like <xref target='RFC5184'/>. In a general
fashion, a detection mechanism that is reactive to traffic is favored
in order to minimize the cost of monitoring links that are not being
used.
</t>
<t>
RPL also expects an external mechanism to access and transport some
control information, referred to as the "RPL Packet Information", in
data packets. The RPL Packet Information is defined in <xref target='LAAD'/>
and enables the association of a data packet with a RPL Instance and
the validation of RPL routing states. The RPL option <xref target='RFC6553'/> is an
example of such mechanism. The mechanism is required for all packets
except when strict source routing is used (that is for packets going
Downward in Non-Storing mode as detailed further in <xref target='DownwardRoutes'/>), which
by nature prevents endless loops and alleviates the need for the RPL
Packet Information. Future companion specifications may propose
alternate ways to carry the RPL Packet Information in the IPv6
packets and may extend the RPL Packet Information to support
additional features.
</t>
<t>
RPL provides a mechanism to disseminate information over the
dynamically formed network topology. This dissemination enables
minimal configuration in the nodes, allowing nodes to operate mostly
autonomously. This mechanism uses Trickle <xref target='RFC6206'/> to optimize the
dissemination as described in <xref target='DIOTransmission'/>.
</t>
<t>
In some applications, RPL assembles topologies of routers that own
independent prefixes. Those prefixes may or may not be aggregatable
depending on the origin of the routers. A prefix that is owned by a
router is advertised as on-link.
</t>
<t>
RPL also introduces the capability to bind a subnet together with a
common prefix and to route within that subnet. A source can inject
information about the subnet to be disseminated by RPL, and that
source is authoritative for that subnet. Because many LLN links have
non-transitive properties, a common prefix that RPL disseminates over
the subnet must not be advertised as on-link.
</t>
<t>
In particular, RPL may disseminate IPv6 Neighbor Discovery (ND)
information such as the <xref target='RFC4861'/> Prefix Information Option (PIO) and
the <xref target='RFC4191'/> Route Information Option (RIO). ND information that is
disseminated by RPL conserves all its original semantics for router
to host, with limited extensions for router to router, though it is
not to be confused with routing advertisements and it is never to be
directly redistributed in another routing protocol. A RPL node often
combines host and router behaviors. As a host, it will process the
options as specified in <xref target='RFC4191'/>, <xref target='RFC4861'/>, <xref target='RFC4862'/>, and
<xref target='RFC6275'/>. As a router, the RPL node may advertise the information
<!-- [9] -->
from the options as required for the specific link, for instance, in
an ND Router Advertisement (RA) message, though the exact operation
is out of scope.
</t>
<t>
A set of companion documents to this specification will provide
further guidance in the form of applicability statements specifying a
set of operating points appropriate to the Building Automation, Home
Automation, Industrial, and Urban application scenarios.
</t>
</section>
<!-- Design Principles -->
<section numbered="true" toc="default">
<name>Expectations of Link-Layer Type</name>
<t>
In compliance with the layered architecture of IP, RPL does not rely
on any particular features of a specific link-layer technology. RPL
is designed to be able to operate over a variety of different link
layers, including ones that are constrained, potentially lossy, or
typically utilized in conjunction with highly constrained host or
router devices, such as but not limited to, low-power wireless or PLC
(Power Line Communication) technologies.
</t>
<t>
Implementers may find <xref target='RFC3819'/> a useful reference when designing a
link-layer interface between RPL and a particular link-layer
technology.
</t>
</section>
<!-- Expectations of Link-Layer Type -->
</section>
<!-- Introduction -->
<section numbered="true" toc="default">
<name>Terminology</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 RFC
2119 <xref target='RFC2119'/>.
</t>
<t>
Additionally, this document uses terminology from <xref target='RFC7102'/>, and
introduces the following terminology:
</t>
<dl newline="false" indent="6">
<dt>DAG:</dt>
<dd>Directed Acyclic Graph. A directed graph having the property
that all edges are oriented in such a way that no cycles exist.
All edges are contained in paths oriented toward and
terminating at one or more root nodes.
</dd>
<dt>DAG root:</dt>
<dd>A DAG root is a node within the DAG that has no outgoing
edge. Because the graph is acyclic, by definition, all DAGs
must have at least one DAG root and all paths terminate at a
DAG root.</dd>
<dt>Destination-Oriented DAG (DODAG):</dt>
<dd>A DAG rooted at a single
destination, i.e., at a single DAG root (the DODAG root) with
no outgoing edges.</dd>
<!-- 10 -->
<dt>DODAG root:</dt>
<dd>A DODAG root is the DAG root of a DODAG. The DODAG root
may act as a border router for the DODAG; in particular, it may
aggregate routes in the DODAG and may redistribute DODAG routes
into other routing protocols.</dd>
<dt>Virtual DODAG root:</dt>
<dd>A Virtual DODAG root is the result of two or more
RPL routers, for instance, 6LoWPAN Border Routers (6LBRs),
coordinating to synchronize DODAG state and act in concert as
if they are a single DODAG root (with multiple interfaces),
with respect to the LLN. The coordination most likely occurs
between powered devices over a reliable transit link, and the
details of that scheme are out of scope for this specification
(to be defined in future companion specifications).</dd>
<dt>Up:</dt>
<dd>Up refers to the direction from leaf nodes towards DODAG roots,
following DODAG edges. This follows the common terminology
used in graphs and depth-first-search, where vertices further
from the root are "deeper" or "down" and vertices closer to the
root are "shallower" or "up".</dd>
<dt>Down:</dt>
<dd>Down refers to the direction from DODAG roots towards leaf
nodes, in the reverse direction of DODAG edges. This follows
the common terminology used in graphs and depth-first-search,
where vertices further from the root are "deeper" or "down" and
vertices closer to the root are "shallower" or "up".</dd>
<dt>Rank:</dt>
<dd>A node's Rank defines the node's individual position relative
to other nodes with respect to a DODAG root. Rank strictly
increases in the Down direction and strictly decreases in the
Up direction. The exact way Rank is computed depends on the
DAG's Objective Function (OF). The Rank may analogously track
a simple topological distance, may be calculated as a function
of link metrics, and may consider other properties such as
constraints.</dd>
<dt>Objective Function (OF):</dt>
<dd>An OF defines how routing metrics,
optimization objectives, and related functions are used to
compute Rank. Furthermore, the OF dictates how parents in the
DODAG are selected and, thus, the DODAG formation.</dd>
<dt>Objective Code Point (OCP):</dt>
<dd>An OCP is an identifier that indicates
which Objective Function the DODAG uses.</dd>
<dt>RPLInstanceID:</dt>
<dd>A RPLInstanceID is a unique identifier within a
network. DODAGs with the same RPLInstanceID share the same
Objective Function.</dd>
<!-- 11 -->
<dt>RPL Instance:</dt>
<dd>A RPL Instance is a set of one or more DODAGs that
share a RPLInstanceID. At most, a RPL node can belong to one
DODAG in a RPL Instance. Each RPL Instance operates
independently of other RPL Instances. This document describes
operation within a single RPL Instance.</dd>
<dt>DODAGID:</dt>
<dd>A DODAGID is the identifier of a DODAG root. The DODAGID is
unique within the scope of a RPL Instance in the LLN. The
tuple (RPLInstanceID, DODAGID) uniquely identifies a DODAG.</dd>
<dt>DODAG Version:</dt>
<dd>A DODAG Version is a specific iteration ("Version") of
a DODAG with a given DODAGID.</dd>
<dt>DODAGVersionNumber:</dt>
<dd>A DODAGVersionNumber is a sequential counter that
is incremented by the root to form a new Version of a DODAG. A
DODAG Version is identified uniquely by the (RPLInstanceID,
DODAGID, DODAGVersionNumber) tuple.</dd>
<dt>Goal:</dt>
<dd>The Goal is an application-specific goal that is defined
outside the scope of RPL. Any node that roots a DODAG will
need to know about this Goal to decide whether or not the Goal
can be satisfied. A typical Goal is to construct the DODAG
according to a specific Objective Function and to keep
connectivity to a set of hosts (e.g., to use an Objective
Function that minimizes a metric and is connected to a specific
database host to store the collected data).</dd>
<dt>Grounded:</dt>
<dd>A DODAG is grounded when the DODAG root can satisfy the
Goal.</dd>
<dt>Floating:</dt>
<dd>A DODAG is floating if it is not grounded. A floating
DODAG is not expected to have the properties required to
satisfy the goal. It may, however, provide connectivity to
other nodes within the DODAG.</dd>
<dt>DODAG parent:</dt>
<dd>A parent of a node within a DODAG is one of the
immediate successors of the node on a path towards the DODAG
root. A DODAG parent's Rank is lower than the node's. (See
<xref target='rankcomp'/>).</dd>
<dt>Sub-DODAG:</dt>
<dd>The sub-DODAG of a node is the set of other nodes whose
paths to the DODAG root pass through that node. Nodes in the
sub-DODAG of a node have a greater Rank than that node. (See
<xref target='rankcomp'/>).</dd>
<dt>Local DODAG:</dt>
<dd>Local DODAGs contain one and only one root node, and
they allow that single root node to allocate and manage a RPL
Instance, identified by a local RPLInstanceID, without
<!-- 12 -->
coordination with other nodes. Typically, this is done in
order to optimize routes to a destination within the LLN. (See
<xref target='rplinst'/>).</dd>
<dt>Global DODAG:</dt>
<dd>A Global DODAG uses a global RPLInstanceID that may be
coordinated among several other nodes. (See <xref target='rplinst'/>).</dd>
<dt>DIO:</dt>
<dd>DODAG Information Object (see <xref target='dio'/>)</dd>
<dt>DAO:</dt>
<dd>Destination Advertisement Object (see <xref target='dao'/>)</dd>
<dt>DIS:</dt>
<dd>DODAG Information Solicitation (see <xref target='dis'/>)</dd>
<dt>CC:</dt>
<dd>Consistency Check (see <xref target='cc'/>)</dd>
</dl>
<t>
As they form networks, LLN devices often mix the roles of host and
router when compared to traditional IP networks. In this document,
"host" refers to an LLN device that can generate but does not forward
RPL traffic; "router" refers to an LLN device that can forward as
well as generate RPL traffic; and "node" refers to any RPL device,
either a host or a router.
</t>
</section>
<!-- Terminology -->
<section numbered="true" toc="default">
<name>Protocol Overview</name>
<t>
The aim of this section is to describe RPL in the spirit of
<xref target='RFC4101'/>. Protocol details can be found in further sections.
</t>
<section numbered="true" toc="default">
<name>Topologies</name>
<t>
This section describes the basic RPL topologies that may be formed,
and the rules by which these are constructed, i.e., the rules
governing DODAG formation.
</t>
<section numbered="true" toc="default">
<name>Constructing Topologies</name>
<t>
LLNs, such as Radio Networks, do not typically have predefined
topologies, for example, those imposed by point-to-point wires, so
RPL has to discover links and then select peers sparingly.
</t>
<t>
In many cases, because Layer 2 ranges overlap only partially, RPL
forms non-transitive / Non-Broadcast Multi-Access (NBMA) network
topologies upon which it computes routes.
</t>
<t>
RPL routes are optimized for traffic to or from one or more roots
that act as sinks for the topology. As a result, RPL organizes a
topology as a Directed Acyclic Graph (DAG) that is partitioned into
<!-- Page 13 -->
one or more Destination Oriented DAGs (DODAGs), one DODAG per sink.
If the DAG has multiple roots, then it is expected that the roots are
federated by a common backbone, such as a transit link.
</t>
</section>
<!-- Constructing Topologies -->
<section numbered="true" toc="default">
<name>RPL Identifiers</name>
<t>
RPL uses four values to identify and maintain a topology:
</t>
<ul>
<li>
The first is a RPLInstanceID. A RPLInstanceID identifies a set of
one or more Destination Oriented DAGs (DODAGs). A network may
have multiple RPLInstanceIDs, each of which defines an independent
set of DODAGs, which may be optimized for different Objective
Functions (OFs) and/or applications. The set of DODAGs identified
by a RPLInstanceID is called a RPL Instance. All DODAGs in the
same RPL Instance use the same OF.
</li><li>
The second is a DODAGID. The scope of a DODAGID is a RPL
Instance. The combination of RPLInstanceID and DODAGID uniquely
identifies a single DODAG in the network. A RPL Instance may have
multiple DODAGs, each of which has an unique DODAGID.
</li><li>
The third is a DODAGVersionNumber. The scope of a
DODAGVersionNumber is a DODAG. A DODAG is sometimes reconstructed
from the DODAG root, by incrementing the DODAGVersionNumber. The
combination of RPLInstanceID, DODAGID, and DODAGVersionNumber
uniquely identifies a DODAG Version.
</li><li>
The fourth is Rank. The scope of Rank is a DODAG Version. Rank
establishes a partial order over a DODAG Version, defining
individual node positions with respect to the DODAG root.
</li>
</ul>
</section>
<!-- RPL Identifiers -->
<section numbered="true" toc="default">
<name>Instances, DODAGs, and DODAG Versions</name>
<t>
A RPL Instance contains one or more DODAG roots. A RPL Instance may
provide routes to certain destination prefixes, reachable via the
DODAG roots or alternate paths within the DODAG. These roots may
operate independently, or they may coordinate over a network that is
not necessarily as constrained as an LLN.
</t>
<t>
A RPL Instance may comprise:
</t>
<ul>
<li> <t>a single DODAG with a single root</t>
<ul>
<li>
For example, a DODAG optimized to minimize latency rooted at a
single centralized lighting controller in a Home Automation
application.
</li>
</ul>
<!-- Page 14 -->
</li>
<li> <t>multiple uncoordinated DODAGs with independent roots (differing
DODAGIDs) </t>
<ul>
<li>
For example, multiple data collection points in an urban data
collection application that do not have suitable connectivity
to coordinate with each other or that use the formation of
multiple DODAGs as a means to dynamically and autonomously
partition the network.
</li>
</ul>
</li>
<li> <t> a single DODAG with a virtual root that coordinates LLN sinks
(with the same DODAGID) over a backbone network. </t>
<ul>
<li>
For example, multiple border routers operating with a reliable
transit link, e.g., in support of an IPv6 Low-Power Wireless
Personal Area Network (6LoWPAN) application, that are capable
of acting as logically equivalent interfaces to the sink of the
same DODAG.
</li>
</ul>
</li>
<li> a combination of the above as suited to some application scenario.
</li>
</ul>
<t>
Each RPL packet is associated with a particular RPLInstanceID (see
<xref target='loopa'/> ) and, therefore, RPL Instance (<xref target='rplinst'/>). The
provisioning or automated discovery of a mapping between a
RPLInstanceID and a type or service of application traffic is out of
scope for this specification (to be defined in future companion
specifications).
</t>
<t>
<xref target='figrpli'/> depicts an example of a RPL Instance comprising three DODAGs
with DODAG roots R1, R2, and R3. Each of these DODAG roots
advertises the same RPLInstanceID. The lines depict connectivity
between parents and children.
</t>
<t>
<xref target='figdov'/> depicts how a DODAGVersionNumber increment leads to a new
DODAG Version. This depiction illustrates a DODAGVersionNumber
increment that results in a different DODAG topology. Note that a
new DODAG Version does not always imply a different DODAG topology.
To accommodate certain topology changes requires a new DODAG Version,
as described later in this specification.
</t>
<t>
In the following examples, please note that tree-like structures are
depicted for simplicity, although the DODAG structure allows for each
node to have multiple parents when the connectivity supports it.
</t>
<!-- Page 15 -->
<figure anchor='figrpli'> <name>RPL Instance</name>
<artwork><![CDATA[
+----------------------------------------------------------------+
| |
| +--------------+ |
| | | |
| | (R1) | (R2) (R3) |
| | / \ | /| \ / | \ |
| | / \ | / | \ / | \ |
| | (A) (B) | (C) | (D) ... (F) (G) (H) |
| | /|\ |\ | / | / |\ |\ | | |
| | : : : : : | : (E) : : : `: : |
| | | / \ |
| +--------------+ : : |
| DODAG |
| |
+----------------------------------------------------------------+
RPL Instance
]]></artwork>
</figure>
<figure anchor='figdov'> <name>DODAG Version</name>
<artwork><![CDATA[
+----------------+ +----------------+
| | | |
| (R1) | | (R1) |
| / \ | | / |
| / \ | | / |
| (A) (B) | \ | (A) |
| /|\ / |\ | ------\ | /|\ |
| : : (C) : : | \ | : : (C) |
| | / | \ |
| | ------/ | \ |
| | / | (B) |
| | | |\ |
| | | : : |
| | | |
+----------------+ +----------------+
Version N Version N+1
]]></artwork>
</figure>
</section>
<!-- Instances, DODAGs, and DODAG Versions -->
</section>
<!-- Topologies -->
<section numbered="true" toc="default">
<name>Upward Routes and DODAG Construction</name>
<t>
RPL provisions routes Up towards DODAG roots, forming a DODAG
optimized according to an Objective Function (OF). RPL nodes
construct and maintain these DODAGs through DODAG Information Object
(DIO) messages.
</t>
<section numbered="true" toc="default">
<name>Objective Function (OF)</name>
<t>
The Objective Function (OF) defines how RPL nodes select and optimize
routes within a RPL Instance. The OF is identified by an Objective
Code Point (OCP) within the DIO Configuration option. An OF defines
how nodes translate one or more metrics and constraints, which are
themselves defined in <xref target='RFC6551'/>, into a value called Rank,
which
approximates the node's distance from a DODAG root. An OF also
defines how nodes select parents. Further details may be found in
<xref target='guideof'/>, <xref target='RFC6551'/>, <xref target='RFC6552'/>, and related companion
specifications.
</t>
</section>
<!-- Objective Function (OF) -->
<section anchor="DODAGRepair" numbered="true" toc="default">
<name>DODAG Repair</name>
<t>
A DODAG root institutes a global repair operation by incrementing the
DODAGVersionNumber. This initiates a new DODAG Version. Nodes in
the new DODAG Version can choose a new position whose Rank is not
constrained by their Rank within the old DODAG Version.
</t>
<t>
RPL also supports mechanisms that may be used for local repair within
the DODAG Version. The DIO message specifies the necessary
parameters as configured from and controlled by policy at the DODAG
root.
</t>
</section>
<!-- DODAG Repair -->
<section numbered="true" toc="default">
<name>Security</name>
<t>
RPL supports message confidentiality and integrity. It is designed
such that link-layer mechanisms can be used when available and
appropriate; yet, in their absence, RPL can use its own mechanisms.
RPL has three basic security modes.
</t>
<t>
In the first, called "unsecured", RPL control messages are sent
without any additional security mechanisms. Unsecured mode does not
imply that the RPL network is unsecure: it could be using other
present security primitives (e.g., link-layer security) to meet
application security requirements.
</t>
<t>
In the second, called "preinstalled", nodes joining a RPL Instance
have preinstalled keys that enable them to process and generate
secured RPL messages.
</t>
<t>
The third mode is called "authenticated". In authenticated mode,
nodes have preinstalled keys as in preinstalled mode, but the
preinstalled key may only be used to join a RPL Instance as a leaf.
Joining an authenticated RPL Instance as a router requires obtaining
a key from an authentication authority. The process by which this
key is obtained is out of scope for this specification. Note that
this specification alone does not provide sufficient detail for a RPL
<!-- Page 17 -->
implementation to securely operate in authenticated mode. For a RPL
implementation to operate securely in authenticated mode, it is
necessary for a future companion specification to detail the
mechanisms by which a node obtains/requests the authentication
material (e.g., key, certificate) and to determine from where that
material should be obtained. See also <xref target='InstallingKeys'/>.
</t>
</section>
<!-- Security -->
<section numbered="true" toc="default">
<name>Grounded and Floating DODAGs</name>
<t>
DODAGs can be grounded or floating: the DODAG root advertises which
is the case. A grounded DODAG offers connectivity to hosts that are
required for satisfying the application-defined goal. A floating
DODAG is not expected to satisfy the goal; in most cases, it only
provides routes to nodes within the DODAG. Floating DODAGs may be
used, for example, to preserve interconnectivity during repair.
</t>
</section>
<!-- Grounded and Floating DODAGs -->
<section numbered="true" toc="default">
<name>Local DODAGs</name>
<t>
RPL nodes can optimize routes to a destination within an LLN by
forming a Local DODAG whose DODAG root is the desired destination.
Unlike global DAGs, which can consist of multiple DODAGs, local DAGs
have one and only one DODAG and therefore one DODAG root. Local
DODAGs can be constructed on demand.
</t>
</section>
<!-- Local DODAGs -->
<section numbered="true" toc="default">
<name>Administrative Preference</name>
<t>
An implementation/deployment may specify that some DODAG roots should
be used over others through an administrative preference.
Administrative preference offers a way to control traffic and
engineer DODAG formation in order to better support application
requirements or needs.
</t>
</section>
<!-- Administrative Preference -->
<section numbered="true" toc="default">
<name>Data-Path Validation and Loop Detection</name>
<t>
The low-power and lossy nature of LLNs motivates RPL's use of on-
demand loop detection using data packets. Because data traffic can
be infrequent, maintaining a routing topology that is constantly up
to date with the physical topology can waste energy. Typical LLNs
exhibit variations in physical connectivity that are transient and
innocuous to traffic, but that would be costly to track closely from
the control plane. Transient and infrequent changes in connectivity
need not be addressed by RPL until there is data to send. This
aspect of RPL's design draws from existing, highly used LLN protocols
as well as extensive experimental and deployment evidence on its
efficacy.
</t>
<!-- Page 18 -->
<t>
The RPL Packet Information that is transported with data packets
includes the Rank of the transmitter. An inconsistency between the
routing decision for a packet (Upward or Downward) and the Rank
relationship between the two nodes indicates a possible loop. On
receiving such a packet, a node institutes a local repair operation.
</t>
<t>
For example, if a node receives a packet flagged as moving in the
Upward direction, and if that packet records that the transmitter is
of a lower (lesser) Rank than the receiving node, then the receiving
node is able to conclude that the packet has not progressed in the
Upward direction and that the DODAG is inconsistent.
</t>
</section>
<!-- Data-Path Validation and Loop Detection -->
<section anchor="distal" numbered="true" toc="default">
<name>Distributed Algorithm Operation</name>
<t>
A high-level overview of the distributed algorithm, which constructs
the DODAG, is as follows:
</t>
<ul>
<li> Some nodes are configured to be DODAG roots, with associated DODAG
configurations.
</li>
<li> Nodes advertise their presence, affiliation with a DODAG, routing
cost, and related metrics by sending link-local multicast DIO
messages to all-RPL-nodes.
</li>
<li> Nodes listen for DIOs and use their information to join a new
DODAG (thus, selecting DODAG parents), or to maintain an existing
DODAG, according to the specified Objective Function and Rank of
their neighbors.
</li>
<li> Nodes provision routing table entries, for the destinations
specified by the DIO message, via their DODAG parents in the DODAG
Version. Nodes that decide to join a DODAG can provision one or
more DODAG parents as the next hop for the default route and a
number of other external routes for the associated instance.
</li>
</ul>
</section>
<!-- Distributed Algorithm Operation -->
</section>
<!-- Upward Routes and DODAG Construction -->
<section anchor="downr" numbered="true" toc="default">
<name>Downward Routes and Destination Advertisement</name>
<t>
RPL uses Destination Advertisement Object (DAO) messages to establish
Downward routes. DAO messages are an optional feature for
applications that require point-to-multipoint (P2MP) or point-to-
point (P2P) traffic. RPL supports two modes of Downward traffic:
Storing (fully stateful) or Non-Storing (fully source routed); see
<xref target="DownwardRoutes"/>. Any given RPL Instance is either storing or non-storing.
In both cases, P2P packets travel Up toward a DODAG root then Down to
the final destination (unless the destination is on the Upward
route). In the Non-Storing case, the packet will travel all the way
to a DODAG root before traveling Down. In the Storing case, the
<!-- Page 19 -->
packet may be directed Down towards the destination by a common
ancestor of the source and the destination prior to reaching a DODAG
root.
</t>
<t>
As of the writing of this specification, no implementation is
expected to support both Storing and Non-Storing modes of operation.
Most implementations are expected to support either no Downward
routes, Non-Storing mode only, or Storing mode only. Other modes of
operation, such as a hybrid mix of Storing and Non-Storing mode, are
out of scope for this specification and may be described in other
companion specifications.
</t>
<t>
This specification describes a basic mode of operation in support of
P2P traffic. Note that more optimized P2P solutions may be described
in companion specifications.
</t>
</section>
<!-- Downward Routes and Destination Advertisement -->
<section numbered="true" toc="default">
<name>Local DODAGs Route Discovery</name>
<t>
Optionally, a RPL network can support on-demand discovery of DODAGs
to specific destinations within an LLN. Such Local DODAGs behave
slightly differently than Global DODAGs: they are uniquely defined by
the combination of DODAGID and RPLInstanceID. The RPLInstanceID
denotes whether a DODAG is a Local DODAG.
</t>
</section>
<!-- Local DODAGs Route Discovery -->
<section numbered="true" toc="default">
<name>Rank Properties</name>
<t>
The Rank of a node is a scalar representation of the location of that
node within a DODAG Version. The Rank is used to avoid and detect
loops and, as such, must demonstrate certain properties. The exact
calculation of the Rank is left to the Objective Function. Even
though the specific computation of the Rank is left to the Objective
Function, the Rank must implement generic properties regardless of
the Objective Function.
</t>
<t>
In particular, the Rank of the nodes must monotonically decrease as
the DODAG Version is followed towards the DODAG destination. In that
regard, the Rank can be considered a scalar representation of the
location or radius of a node within a DODAG Version.
</t>
<t>
The details of how the Objective Function computes Rank are out of
scope for this specification, although that computation may depend,
for example, on parents, link metrics, node metrics, and the node
configuration and policies. See <xref target="guideof"/> for more information.
</t>
<t>
The Rank is not a path cost, although its value can be derived from
and influenced by path metrics. The Rank has properties of its own
that are not necessarily those of all metrics:
</t>
<!-- Page 20 -->
<dl newline="false" indent="6">
<dt>Type:</dt>
<dd>The Rank is an abstract numeric value.</dd>
<dt>Function:</dt>
<dd>The Rank is the expression of a relative position within a
DODAG Version with regard to neighbors, and it is not
necessarily a good indication or a proper expression of a
distance or a path cost to the root.</dd>
<dt>Stability:</dt>
<dd>The stability of the Rank determines the stability of the
routing topology. Some dampening or filtering is RECOMMENDED
to keep the topology stable; thus, the Rank does not
necessarily change as fast as some link or node metrics would.
A new DODAG Version would be a good opportunity to reconcile