< draft-ietf-roll-dao-projection-22.txt   draft-ietf-roll-dao-projection-23.txt >
ROLL P. Thubert, Ed. ROLL P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track R.A. Jadhav Intended status: Standards Track R.A. Jadhav
Expires: 29 May 2022 Huawei Tech Expires: 17 July 2022 Huawei Tech
M. Gillmore 13 January 2022
Itron
25 November 2021
Root initiated routing state in RPL Root initiated routing state in RPL
draft-ietf-roll-dao-projection-22 draft-ietf-roll-dao-projection-23
Abstract Abstract
This document extends RFC 6550, RFC 6553, and RFC 8138 to enable a This document extends RFC 6550, RFC 6553, and RFC 8138 to enable a
RPL Root to install and maintain Projected Routes within its DODAG, RPL Root to install and maintain Projected Routes within its DODAG,
along a selected set of nodes that may or may not include self, for a along a selected set of nodes that may or may not include self, for a
chosen duration. This potentially enables routes that are more chosen duration. This potentially enables routes that are more
optimized or resilient than those obtained with the classical optimized or resilient than those obtained with the classical
distributed operation of RPL, either in terms of the size of a distributed operation of RPL, either in terms of the size of a
Routing Header or in terms of path length, which impacts both the Routing Header or in terms of path length, which impacts both the
skipping to change at page 1, line 40 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 29 May 2022. This Internet-Draft will expire on 17 July 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
skipping to change at page 2, line 43 skipping to change at page 2, line 40
3.5. Serial Track Signaling . . . . . . . . . . . . . . . . . 16 3.5. Serial Track Signaling . . . . . . . . . . . . . . . . . 16
3.5.1. Using Storing Mode Segments . . . . . . . . . . . . . 17 3.5.1. Using Storing Mode Segments . . . . . . . . . . . . . 17
3.5.2. Using Non-Storing Mode joining Tracks . . . . . . . . 24 3.5.2. Using Non-Storing Mode joining Tracks . . . . . . . . 24
3.6. Complex Tracks . . . . . . . . . . . . . . . . . . . . . 31 3.6. Complex Tracks . . . . . . . . . . . . . . . . . . . . . 31
3.7. Scope and Expectations . . . . . . . . . . . . . . . . . 33 3.7. Scope and Expectations . . . . . . . . . . . . . . . . . 33
3.7.1. External Dependencies . . . . . . . . . . . . . . . . 33 3.7.1. External Dependencies . . . . . . . . . . . . . . . . 33
3.7.2. Positioning vs. Related IETF Standards . . . . . . . 33 3.7.2. Positioning vs. Related IETF Standards . . . . . . . 33
4. Extending existing RFCs . . . . . . . . . . . . . . . . . . . 35 4. Extending existing RFCs . . . . . . . . . . . . . . . . . . . 35
4.1. Extending RFC 6550 . . . . . . . . . . . . . . . . . . . 35 4.1. Extending RFC 6550 . . . . . . . . . . . . . . . . . . . 35
4.1.1. Projected DAO . . . . . . . . . . . . . . . . . . . . 36 4.1.1. Projected DAO . . . . . . . . . . . . . . . . . . . . 36
4.1.2. Via Information Option . . . . . . . . . . . . . . . 37 4.1.2. Projected DAO-ACK . . . . . . . . . . . . . . . . . . 37
4.1.3. Sibling Information Option . . . . . . . . . . . . . 37 4.1.3. Via Information Option . . . . . . . . . . . . . . . 38
4.1.4. P-DAO Request . . . . . . . . . . . . . . . . . . . . 38 4.1.4. Sibling Information Option . . . . . . . . . . . . . 39
4.1.5. Extending the RPI . . . . . . . . . . . . . . . . . . 38 4.1.5. P-DAO Request . . . . . . . . . . . . . . . . . . . . 39
4.1.6. Additional Flag in the RPL DODAG Configuration 4.1.6. Extending the RPI . . . . . . . . . . . . . . . . . . 39
Option . . . . . . . . . . . . . . . . . . . . . . . 38 4.1.7. Additional Flag in the RPL DODAG Configuration
4.2. Extending RFC 6553 . . . . . . . . . . . . . . . . . . . 39 Option . . . . . . . . . . . . . . . . . . . . . . . 40
4.3. Extending RFC 8138 . . . . . . . . . . . . . . . . . . . 40 4.2. Extending RFC 6553 . . . . . . . . . . . . . . . . . . . 41
5. New RPL Control Messages and Options . . . . . . . . . . . . 41 4.3. Extending RFC 8138 . . . . . . . . . . . . . . . . . . . 41
5.1. New P-DAO Request Control Message . . . . . . . . . . . . 42 5. New RPL Control Messages and Options . . . . . . . . . . . . 43
5.2. New PDR-ACK Control Message . . . . . . . . . . . . . . . 43 5.1. New P-DAO Request Control Message . . . . . . . . . . . . 43
5.3. Via Information Options . . . . . . . . . . . . . . . . . 44 5.2. New PDR-ACK Control Message . . . . . . . . . . . . . . . 44
5.4. Sibling Information Option . . . . . . . . . . . . . . . 47 5.3. Via Information Options . . . . . . . . . . . . . . . . . 45
6. Root Initiated Routing State . . . . . . . . . . . . . . . . 49 5.4. Sibling Information Option . . . . . . . . . . . . . . . 48
6.1. RPL Network Setup . . . . . . . . . . . . . . . . . . . . 49 6. Root Initiated Routing State . . . . . . . . . . . . . . . . 50
6.2. Requesting a Track . . . . . . . . . . . . . . . . . . . 49 6.1. RPL Network Setup . . . . . . . . . . . . . . . . . . . . 50
6.3. Identifying a Track . . . . . . . . . . . . . . . . . . . 50 6.2. Requesting a Track . . . . . . . . . . . . . . . . . . . 51
6.4. Installing a Track . . . . . . . . . . . . . . . . . . . 51 6.3. Identifying a Track . . . . . . . . . . . . . . . . . . . 52
6.4.1. Signaling a Projected Route . . . . . . . . . . . . . 52 6.4. Installing a Track . . . . . . . . . . . . . . . . . . . 53
6.4.1. Signaling a Projected Route . . . . . . . . . . . . . 54
6.4.2. Installing a Track Segment with a Storing Mode 6.4.2. Installing a Track Segment with a Storing Mode
P-Route . . . . . . . . . . . . . . . . . . . . . . . 53
6.4.3. Installing a Track Leg with a Non-Storing Mode
P-Route . . . . . . . . . . . . . . . . . . . . . . . 55 P-Route . . . . . . . . . . . . . . . . . . . . . . . 55
6.5. Tearing Down a P-Route . . . . . . . . . . . . . . . . . 57 6.4.3. Installing a Track Leg with a Non-Storing Mode
6.6. Maintaining a Track . . . . . . . . . . . . . . . . . . . 57 P-Route . . . . . . . . . . . . . . . . . . . . . . . 57
6.6.1. Maintaining a Track Segment . . . . . . . . . . . . . 58 6.5. Tearing Down a P-Route . . . . . . . . . . . . . . . . . 59
6.6.2. Maintaining a Track Leg . . . . . . . . . . . . . . . 58 6.6. Maintaining a Track . . . . . . . . . . . . . . . . . . . 59
6.7. Encapsulating and Forwarding Along a Track . . . . . . . 59 6.6.1. Maintaining a Track Segment . . . . . . . . . . . . . 60
6.8. Compression of the RPL Artifacts . . . . . . . . . . . . 61 6.6.2. Maintaining a Track Leg . . . . . . . . . . . . . . . 60
7. Lesser Constrained Variations . . . . . . . . . . . . . . . . 63 6.7. Encapsulating and Forwarding Along a Track . . . . . . . 61
7.1. Storing Mode Main DODAG . . . . . . . . . . . . . . . . . 63 6.8. Compression of the RPL Artifacts . . . . . . . . . . . . 63
7.2. A Track as a Full DODAG . . . . . . . . . . . . . . . . . 65 7. Lesser Constrained Variations . . . . . . . . . . . . . . . . 65
8. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 66 7.1. Storing Mode Main DODAG . . . . . . . . . . . . . . . . . 65
9. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 68 7.2. A Track as a Full DODAG . . . . . . . . . . . . . . . . . 67
10. Security Considerations . . . . . . . . . . . . . . . . . . . 69 8. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 68
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69 9. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 70
11.1. RPL DODAG Configuration Option Flag . . . . . . . . . . 69 10. Security Considerations . . . . . . . . . . . . . . . . . . . 71
11.2. Elective 6LoWPAN Routing Header Type . . . . . . . . . . 70 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71
11.3. Critical 6LoWPAN Routing Header Type . . . . . . . . . . 70 11.1. RPL DODAG Configuration Option Flag . . . . . . . . . . 71
11.4. Subregistry For The RPL Option Flags . . . . . . . . . . 70 11.2. Elective 6LoWPAN Routing Header Type . . . . . . . . . . 72
11.5. RPL Control Codes . . . . . . . . . . . . . . . . . . . 71 11.3. Critical 6LoWPAN Routing Header Type . . . . . . . . . . 72
11.6. RPL Control Message Options . . . . . . . . . . . . . . 71 11.4. Subregistry For The RPL Option Flags . . . . . . . . . . 72
11.7. SubRegistry for the Projected DAO Request Flags . . . . 72 11.5. RPL Control Codes . . . . . . . . . . . . . . . . . . . 73
11.8. SubRegistry for the PDR-ACK Flags . . . . . . . . . . . 72 11.6. RPL Control Message Options . . . . . . . . . . . . . . 73
11.9. Subregistry for the PDR-ACK Acceptance Status Values . . 73 11.7. SubRegistry for the Projected DAO Request Flags . . . . 74
11.10. Subregistry for the PDR-ACK Rejection Status Values . . 73 11.8. SubRegistry for the PDR-ACK Flags . . . . . . . . . . . 74
11.11. SubRegistry for the Via Information Options Flags . . . 73 11.9. Subregistry for the PDR-ACK Acceptance Status Values . . 75
11.12. SubRegistry for the Sibling Information Option Flags . . 74 11.10. Subregistry for the PDR-ACK Rejection Status Values . . 75
11.13. destination Advertisement Object Flag . . . . . . . . . 74 11.11. SubRegistry for the Via Information Options Flags . . . 75
11.14. New ICMPv6 Error Code . . . . . . . . . . . . . . . . . 75 11.12. SubRegistry for the Sibling Information Option Flags . . 76
11.15. RPL Rejection Status values . . . . . . . . . . . . . . 75 11.13. Destination Advertisement Object Flag . . . . . . . . . 76
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 76 11.14. Destination Advertisement Object Acknowledgment Flag . . 77
13. Normative References . . . . . . . . . . . . . . . . . . . . 76 11.15. New ICMPv6 Error Code . . . . . . . . . . . . . . . . . 77
14. Informative References . . . . . . . . . . . . . . . . . . . 77 11.16. RPL Rejection Status values . . . . . . . . . . . . . . 77
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 80 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 78
13. Normative References . . . . . . . . . . . . . . . . . . . . 78
14. Informative References . . . . . . . . . . . . . . . . . . . 80
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 82
1. Introduction 1. Introduction
RPL, the "Routing Protocol for Low Power and Lossy Networks" [RPL] RPL, the "Routing Protocol for Low Power and Lossy Networks" [RPL]
(LLNs), is an anisotropic Distance Vector protocol that is well- (LLNs), is an anisotropic Distance Vector protocol that is well-
suited for application in a variety of low energy Internet of Things suited for application in a variety of low energy Internet of Things
(IoT) networks where stretched P2P paths are acceptable vs. the (IoT) networks where stretched P2P paths are acceptable vs. the
signaling and state overhead involved in maintaining shortest paths signaling and state overhead involved in maintaining shortest paths
across. across.
skipping to change at page 8, line 5 skipping to change at page 8, line 5
connected using Segments that are associated to the same Track. connected using Segments that are associated to the same Track.
2.4.5.1. TrackID 2.4.5.1. TrackID
A RPL Local InstanceID that identifies a Track using the namespace A RPL Local InstanceID that identifies a Track using the namespace
owned by the Track Ingress. The TrackID is associated with the IPv6 owned by the Track Ingress. The TrackID is associated with the IPv6
Address of the Track Ingress that is used as DODAGID, and together Address of the Track Ingress that is used as DODAGID, and together
they form a unique identification of the Track (see the definition of they form a unique identification of the Track (see the definition of
DODAGID in section 2 of [RPL]. DODAGID in section 2 of [RPL].
2.4.5.2. namespace 2.4.5.2. Namespace
The term namespace is used to refer to the scope of the TrackID. The The term namespace is used to refer to the scope of the TrackID. The
TrackID is locally significant within its namespace. The namespace TrackID is locally significant within its namespace. The namespace
is identified by the DODAGID for the Track. The tuple (DODAGID, is identified by the DODAGID for the Track. The tuple (DODAGID,
TrackID) is globally unique. TrackID) is globally unique.
2.4.5.3. Serial Track 2.4.5.3. Serial Track
A Track that has only one path. A Track that has only one path.
skipping to change at page 24, line 16 skipping to change at page 24, line 16
the packet. the packet.
* From the Neighbor Cache Entry: E delivers packets to F or G. * From the Neighbor Cache Entry: E delivers packets to F or G.
3.5.2. Using Non-Storing Mode joining Tracks 3.5.2. Using Non-Storing Mode joining Tracks
In this formulation: In this formulation:
* P-DAO 1 signals C==>D==>E-to-F,G * P-DAO 1 signals C==>D==>E-to-F,G
* P-DAO 2 signals A==>B==>C-to-C,F,G * P-DAO 2 signals A==>B==>C-to-E,F,G
A==>B==>C and C==>D==>E are Tracks expressed as Non-Storing P-DAOs. A==>B==>C and C==>D==>E are Tracks expressed as Non-Storing P-DAOs.
3.5.2.1. Stitched Tracks 3.5.2.1. Stitched Tracks
Non-Storing Mode P-DAO 1 and 2 are sent to C and A respectively, as Non-Storing Mode P-DAO 1 and 2 are sent to C and A respectively, as
follows: follows:
+====================+==============+==============+ +====================+==============+==============+
| | P-DAO 1 to C | P-DAO 2 to A | | | P-DAO 1 to C | P-DAO 2 to A |
skipping to change at page 35, line 29 skipping to change at page 35, line 29
through which Track. In a Non-Storing Mode RPL Instance, the Main through which Track. In a Non-Storing Mode RPL Instance, the Main
DODAG provides a default route via the Root, and the Tracks provide DODAG provides a default route via the Root, and the Tracks provide
more specific routes to the Track Targets. more specific routes to the Track Targets.
4. Extending existing RFCs 4. Extending existing RFCs
4.1. Extending RFC 6550 4.1. Extending RFC 6550
This specification extends RPL [RPL] to enable the Root to install This specification extends RPL [RPL] to enable the Root to install
East-West routes inside a Main DODAG that is operated as Non-Storing East-West routes inside a Main DODAG that is operated as Non-Storing
Mode. A Projected DAO (P-DAO) message (see Section 4.1.1) contains a Mode. The Root issues a Projected DAO (P-DAO) message (see
new Via Information Option that installs a strict or a loose sequence Section 4.1.1) to the Track Ingress; the P-DAO message contains a new
of hops to form respectively a Track Segment or a Track Leg. A new Via Information Option (VIO) that installs a strict or a loose
P-DAO Request (PDR) message (see Section 5.1) enables a Track Ingress sequence of hops to form respectively a Track Segment or a Track Leg.
to request the Track from the Root. The resulting Track is also a
DODAG for which the Track Ingress is the Root, the owner the address A new P-DAO Request (PDR) message (see Section 5.1) enables a Track
that serves as DODAGID and authoritative for the associated namespace Ingress to request the Track from the Root. The resulting Track is
from which the TrackID is selected. In the context of this also a DODAG for which the Track Ingress is the Root, the owner the
address that serves as DODAGID and authoritative for the associated
namespace from which the TrackID is selected. In the context of this
specification, the installed route appears as a more specific route specification, the installed route appears as a more specific route
to the Track Targets, and the Track Ingress routes the packets to the Track Targets, and the Track Ingress routes the packets
towards the Targets via the Track using the longest match as usual. towards the Targets via the Track using the longest match as usual.
To ensure that the PDR and P-DAO messages can flow at most times, it To ensure that the PDR and P-DAO messages can flow at most times, it
is RECOMMENDED that the nodes involved in a Track mantain multiple is RECOMMENDED that the nodes involved in a Track maintain multiple
parents in the Main DODAG, advertise them all to the Root, and use parents in the Main DODAG, advertise them all to the Root, and use
them in turn to retry similar packets. It is also RECOMMENDED that them in turn to retry similar packets. It is also RECOMMENDED that
the Root uses diverse source route paths to retry similar messages ot the Root uses diverse source route paths to retry similar messages to
the nodes in the Track. the nodes in the Track.
4.1.1. Projected DAO 4.1.1. Projected DAO
Section 6 of [RPL] introduces the RPL Control Message Options (CMO), Section 6 of [RPL] introduces the RPL Control Message Options (CMO),
including the RPL Target Option (RTO) and Transit Information Option including the RPL Target Option (RTO) and Transit Information Option
(TIO), which can be placed in RPL messages such as the destination (TIO), which can be placed in RPL messages such as the destination
Advertisement Object (DAO). A DAO message signals routing Advertisement Object (DAO). A DAO message signals routing
information to one or more Targets indicated in RTOs, providing one information to one or more Targets indicated in RTOs, providing one
hop information at a time in the TIO. A Projected DAO (P-DAO) is a hop information at a time in the TIO. A Projected DAO (P-DAO) is a
special DAO message generated by the Root to install a P-Route formed special DAO message generated by the Root to install a P-Route formed
of multiple hops in its DODAG. This provides a RPL-based method to of multiple hops in its DODAG. This provides a RPL-based method to
install the Tracks as expected by the 6TiSCH Architecture install the Tracks as expected by the 6TiSCH Architecture
[6TiSCH-ARCHI] as a collection of multiple P-Routes. [6TiSCH-ARCHI] as a collection of multiple P-Routes.
The Root MUST source the P-DAO message with its address that serves
as DODAGID for the main DODAG. The receiver MUST NOT accept a P-DAO
message that is not sent by the Root of its DODAG and MUST ignore
such message silently.
The P-DAO is signaled with a new "Projected DAO" (P) flag, see The P-DAO is signaled with a new "Projected DAO" (P) flag, see
Figure 8. The 'P' flag is encoded in bit position 2 (to be confirmed Figure 8. The 'P' flag is encoded in bit position 2 (to be confirmed
by IANA) of the Flags field in the DAO Base Object. The Root MUST by IANA) of the Flags field in the DAO Base Object. The Root MUST
set it to 1 in a Projected DAO message. Otherwise it MUST be set to set it to 1 in a Projected DAO message. Otherwise it MUST be set to
0. It is set to 0 in Legacy implementations as specified 0. It is set to 0 in Legacy implementations as specified
respectively in Sections 20.11 and 6.4 of [RPL] respectively in Sections 20.11 and 6.4 of [RPL].
The P-DAO is control plane signaling and should not be stuck behind The P-DAO is control plane signaling and should not be stuck behind
high traffic levels. The expectation is that the P-DAO message is high traffic levels. The expectation is that the P-DAO message is
sent as high QoS level, above that of data traffic, typically with sent as high QoS level, above that of data traffic, typically with
the Network Control precedence. the Network Control precedence.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TrackID |K|D|P| Flags | Reserved | DAOSequence | | TrackID |K|D|P| Flags | Reserved | DAOSequence |
skipping to change at page 37, line 10 skipping to change at page 37, line 15
New fields: New fields:
TrackID: The local or global RPLInstanceID of the DODAG that serves TrackID: The local or global RPLInstanceID of the DODAG that serves
as Track, more in Section 6.3 as Track, more in Section 6.3
P: 1-bit flag (position to be confirmed by IANA). P: 1-bit flag (position to be confirmed by IANA).
The 'P' flag is set to 1 by the Root to signal a Projected DAO, The 'P' flag is set to 1 by the Root to signal a Projected DAO,
and it is set to 0 otherwise. and it is set to 0 otherwise.
The D flag is set to one to signal that the DODAGID field is present.
It may be set to zero if and only if the destination address of the
P-DAO-ACK message is set to the IPv6 address that serves as DODAGID
and it MUST be set to one otherwise, meaning that the DODAGID field
MUST then be present.
In RPL Non-Storing Mode, the TIO and RTO are combined in a DAO In RPL Non-Storing Mode, the TIO and RTO are combined in a DAO
message to inform the DODAG Root of all the edges in the DODAG, which message to inform the DODAG Root of all the edges in the DODAG, which
are formed by the directed parent-child relationships. The DAO are formed by the directed parent-child relationships. The DAO
message signals to the Root that a given parent can be used to reach message signals to the Root that a given parent can be used to reach
a given child. The P-DAO message generalizes the DAO to signal to a given child. The P-DAO message generalizes the DAO to signal to
the Track Ingress that a Track for which it is Root can be used to the Track Ingress that a Track for which it is Root can be used to
reach children and siblings of the Track Egress. In both cases, reach children and siblings of the Track Egress. In both cases,
options may be factorized and multiple RTOs may be present to signal options may be factorized and multiple RTOs may be present to signal
a collection of children that can be reached through the parent or a collection of children that can be reached through the parent or
the Track, respectively. the Track, respectively.
4.1.2. Via Information Option 4.1.2. Projected DAO-ACK
The changes in the P-DAO messages are reflected on the P-DAO-ACK
message that is used to acknowledge a P-DAO, with the new P flag that
signal the projected form.
The format of the P-DAO-ACK message is thus as illustrated in
Figure 9:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TrackID |D|P| Reserved | DAOSequence | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| DODAGID field set to the |
+ IPv6 Address of the Track Ingress +
| used to source encapsulated packets |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)...
+-+-+-+-+-+-+-+-+
Figure 9: Projected DAO-ACK Base Object
New fields:
TrackID: The local or global RPLInstanceID of the DODAG that serves
as Track, more in Section 6.3
P: 1-bit flag (position to be confirmed by IANA).
The 'P' flag is set to 1 by the Root to signal a Projected DAO,
and it is set to 0 otherwise.
The D flag is set to one to signal that the DODAGID field is present.
It may be set to zero if and only if the source address of the P-DAO-
ACK message is set to the IPv6 address that serves as DODAGID and it
MUST be set to one otherwise, meaning that the DODAGID field MUST
then be present.
4.1.3. Via Information Option
New CMOs called the Via Information Options (VIO) are introduced for New CMOs called the Via Information Options (VIO) are introduced for
use in P-DAO messages as a multihop alternative to the TIO, more in use in P-DAO messages as a multihop alternative to the TIO, more in
Section 5.3. One VIO is the stateful Storing Mode VIO (SM-VIO); an Section 5.3. One VIO is the stateful Storing Mode VIO (SM-VIO); an
SM-VIO installs a strict hop-by-hop P-Route called a Track Segment. SM-VIO installs a strict hop-by-hop P-Route called a Track Segment.
The other is the Non-Storing Mode VIO (NSM-VIO); the NSM-VIO installs The other is the Non-Storing Mode VIO (NSM-VIO); the NSM-VIO installs
a loose source-routed P-Route called a Track Leg at the Track a loose source-routed P-Route called a Track Leg at the Track
Ingress, which uses that state to encapsulate a packet IPv6_in_IPv6 Ingress, which uses that state to encapsulate a packet IPv6_in_IPv6
with a new Routing Header (RH) to the Track Egress, more in with a new Routing Header (RH) to the Track Egress, more in
Section 6.7. Section 6.7.
A P-DAO contains one or more RTOs to indicate the Target A P-DAO contains one or more RTOs to indicate the Target
(destinations) that can be reached via the P-Route, followed by (destinations) that can be reached via the P-Route, followed by
exactly one VIO that signals the sequence of nodes to be followed, exactly one VIO that signals the sequence of nodes to be followed,
more in Section 6. There are two modes of operation for the more in Section 6. There are two modes of operation for the
P-Routes, the Storing Mode and the Non-Storing Mode, see P-Routes, the Storing Mode and the Non-Storing Mode, see
Section 6.4.2 and Section 6.4.3 respectively for more. Section 6.4.2 and Section 6.4.3 respectively for more.
4.1.3. Sibling Information Option 4.1.4. Sibling Information Option
This specification adds another CMO called the Sibling Information This specification adds another CMO called the Sibling Information
Option (SIO) that is used by a RPL Aware Node (RAN) to advertise a Option (SIO) that is used by a RPL Aware Node (RAN) to advertise a
selection of its candidate neighbors as siblings to the Root, more in selection of its candidate neighbors as siblings to the Root, more in
Section 5.4. The SIO is placed in DAO messages that are sent Section 5.4. The SIO is placed in DAO messages that are sent
directly to the Root of the main DODAG. directly to the Root of the main DODAG.
4.1.4. P-DAO Request 4.1.5. P-DAO Request
Two new RPL Control Messages are also introduced, to enable a RPL- Two new RPL Control Messages are also introduced, to enable a RPL-
Aware Node to request the establishment of a Track between self as Aware Node to request the establishment of a Track between self as
the Track Ingress Node and a Track Egress. The node makes its the Track Ingress Node and a Track Egress. The node makes its
request by sending a new P-DAO Request (PDR) Message to the Root. request by sending a new P-DAO Request (PDR) Message to the Root.
The Root confirms with a new PDR-ACK message back to the requester The Root confirms with a new PDR-ACK message back to the requester
RAN, see Section 5.1 for more. RAN, see Section 5.1 for more.
4.1.5. Extending the RPI 4.1.6. Extending the RPI
Sending a Packet within a RPL Local Instance requires the presence of Sending a Packet within a RPL Local Instance requires the presence of
the abstract RPL Packet Information (RPI) described in section 11.2. the abstract RPL Packet Information (RPI) described in section 11.2.
of [RPL] in the outer IPv6 Header chain (see [RFC9008]). The RPI of [RPL] in the outer IPv6 Header chain (see [RFC9008]). The RPI
carries a local RPLInstanceID which, in association with either the carries a local RPLInstanceID which, in association with either the
source or the destination address in the IPv6 Header, indicates the source or the destination address in the IPv6 Header, indicates the
RPL Instance that the packet follows. RPL Instance that the packet follows.
This specification extends [RPL] to create a new flag that signals This specification extends [RPL] to create a new flag that signals
that a packet is forwarded along a P-Route. that a packet is forwarded along a P-Route.
Projected-Route 'P': 1-bit flag. It is set to 1 in the RPI that is Projected-Route 'P': 1-bit flag. It is set to 1 in the RPI that is
added in the encapsulation when a packet is sent over a Track. It added in the encapsulation when a packet is sent over a Track. It
is set to 0 when a packet is forwarded along the main Track, is set to 0 when a packet is forwarded along the main Track,
including when the packet follows a Segment that joins loose hops including when the packet follows a Segment that joins loose hops
of the Main DODAG. The flag is not mutable en-route. of the Main DODAG. The flag is not mutable en-route.
The encoding of the 'P' flag in native format is shown in Section 4.2 The encoding of the 'P' flag in native format is shown in Section 4.2
while the compressed format is indicated in Section 4.3. while the compressed format is indicated in Section 4.3.
4.1.6. Additional Flag in the RPL DODAG Configuration Option 4.1.7. Additional Flag in the RPL DODAG Configuration Option
The DODAG Configuration Option is defined in Section 6.7.6 of [RPL]. The DODAG Configuration Option is defined in Section 6.7.6 of [RPL].
Its purpose is extended to distribute configuration information Its purpose is extended to distribute configuration information
affecting the construction and maintenance of the DODAG, as well as affecting the construction and maintenance of the DODAG, as well as
operational parameters for RPL on the DODAG, through the DODAG. This operational parameters for RPL on the DODAG, through the DODAG. This
Option was originally designed with 4 bit positions reserved for Option was originally designed with 4 bit positions reserved for
future use as Flags. future use as Flags.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x04 |Opt Length = 14|D| | | |A| ... | | Type = 0x04 |Opt Length = 14|D| | | |A| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
|4 bits | |4 bits |
Figure 9: DODAG Configuration Option (Partial View) Figure 10: DODAG Configuration Option (Partial View)
This specification defines a new flag "Projected Routes Support" (D). This specification defines a new flag "Projected Routes Support" (D).
The 'D' flag is encoded in bit position 0 of the reserved Flags in The 'D' flag is encoded in bit position 0 of the reserved Flags in
the DODAG Configuration Option (this is the most significant bit)(to the DODAG Configuration Option (this is the most significant bit)(to
be confirmed by IANA but there's little choice). It is set to 0 in be confirmed by IANA but there's little choice). It is set to 0 in
legacy implementations as specified respectively in Sections 20.14 legacy implementations as specified respectively in Sections 20.14
and 6.7.6 of [RPL]. and 6.7.6 of [RPL].
The 'D' flag is set to 1 to indicate that this specification is The 'D' flag is set to 1 to indicate that this specification is
enabled in the network and that the Root will install the requested enabled in the network and that the Root will install the requested
skipping to change at page 39, line 26 skipping to change at page 40, line 44
Section 4.1.2. of [RFC9008] updates [RPL] to indicate that the Section 4.1.2. of [RFC9008] updates [RPL] to indicate that the
definition of the Flags applies to Mode of Operation values from zero definition of the Flags applies to Mode of Operation values from zero
(0) to six (6) only. For a MOP value of 7, the implementation MUST (0) to six (6) only. For a MOP value of 7, the implementation MUST
consider that the Root accepts PDR messages and will install consider that the Root accepts PDR messages and will install
Projected Routes. Projected Routes.
The RPL DODAG Configuration option is typically placed in a DODAG The RPL DODAG Configuration option is typically placed in a DODAG
Information Object (DIO) message. The DIO message propagates down Information Object (DIO) message. The DIO message propagates down
the DODAG to form and then maintain its structure. The DODAG the DODAG to form and then maintain its structure. The DODAG
Configuration option is copied unmodified from parents to children. Configuration option is copied unmodified from parents to children.
xref target='RFC6550'/> states that:
[RPL] states that:
| Nodes other than the DODAG root MUST NOT modify this information | Nodes other than the DODAG root MUST NOT modify this information
| when propagating the DODAG Configuration option. | when propagating the DODAG Configuration option.
Therefore, a legacy parent propagates the 'D' flag as set by the Therefore, a legacy parent propagates the 'D' flag as set by the
root, and when the 'D' flag is set to 1, it is transparently flooded root, and when the 'D' flag is set to 1, it is transparently flooded
to all the nodes in the DODAG. to all the nodes in the DODAG.
4.2. Extending RFC 6553 4.2. Extending RFC 6553
skipping to change at page 40, line 15 skipping to change at page 41, line 29
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len | | Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O|R|F|P|0|0|0|0| RPLInstanceID | SenderRank | |O|R|F|P|0|0|0|0| RPLInstanceID | SenderRank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (sub-TLVs) | | (sub-TLVs) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Extended RPL Option Format Figure 11: Extended RPL Option Format
Option Type: 0x23 or 0x63, see [RFC9008] Option Type: 0x23 or 0x63, see [RFC9008]
Opt Data Len: See [RFC6553] Opt Data Len: See [RFC6553]
'O', 'R' and 'F' flags: See [RFC6553]. Those flags MUST be set to 0 'O', 'R' and 'F' flags: See [RFC6553]. Those flags MUST be set to 0
by the sender and ignored by the receiver if the 'P' flag is set. by the sender and ignored by the receiver if the 'P' flag is set.
Projected-Route 'P': 1-bit flag as defined in Section 4.1.5. Projected-Route 'P': 1-bit flag as defined in Section 4.1.6.
RPLInstanceID: See [RFC6553]. Indicates the TrackId if the 'P' flag RPLInstanceID: See [RFC6553]. Indicates the TrackId if the 'P' flag
is set, as discussed in Section 4.1.1. is set, as discussed in Section 4.1.1.
SenderRank: See [RFC6553]. This field MUST be set to 0 by the SenderRank: See [RFC6553]. This field MUST be set to 0 by the
sender and ignored by the receiver if the 'P'flag is set. sender and ignored by the receiver if the 'P'flag is set.
4.3. Extending RFC 8138 4.3. Extending RFC 8138
The 6LoWPAN Routing Header [RFC8138] specification introduces a new The 6LoWPAN Routing Header [RFC8138] specification introduces a new
skipping to change at page 41, line 34 skipping to change at page 42, line 43
The P-RPI-6LoRH is designed to compress the RPI along RPL P-Routes. The P-RPI-6LoRH is designed to compress the RPI along RPL P-Routes.
Its format is as follows: Its format is as follows:
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|E| Length | 6LoRH Type | RPLInstanceID | |1|0|E| Length | 6LoRH Type | RPLInstanceID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: P-RPI-6LoRH Format Figure 12: P-RPI-6LoRH Format
Type: IANA is requested to define the same value of the type for Type: IANA is requested to define the same value of the type for
both Elective and Critical forms. A type of 8 is suggested. both Elective and Critical forms. A type of 8 is suggested.
Elective 'E': See [RFC8138]. The 'E' flag is set to 1 to indicate Elective 'E': See [RFC8138]. The 'E' flag is set to 1 to indicate
an Elective 6LoRH, meaning that it can be ignored when forwarding. an Elective 6LoRH, meaning that it can be ignored when forwarding.
RPLInstanceID : In the context of this specification, the RPLInstanceID : In the context of this specification, the
RPLInstanceID field signals the TrackID, see Section 3.4 and RPLInstanceID field signals the TrackID, see Section 3.4 and
Section 6.3 . Section 6.3 .
skipping to change at page 42, line 4 skipping to change at page 43, line 12
RPLInstanceID : In the context of this specification, the RPLInstanceID : In the context of this specification, the
RPLInstanceID field signals the TrackID, see Section 3.4 and RPLInstanceID field signals the TrackID, see Section 3.4 and
Section 6.3 . Section 6.3 .
Section 6.8 details how a a Track Ingress leverages the P-RPI-6LoRH Section 6.8 details how a a Track Ingress leverages the P-RPI-6LoRH
Header as part of the encapsulation of a packet to place it into a Header as part of the encapsulation of a packet to place it into a
Track. Track.
5. New RPL Control Messages and Options 5. New RPL Control Messages and Options
5.1. New P-DAO Request Control Message 5.1. New P-DAO Request Control Message
The P-DAO Request (PDR) message is sent by a Node in the Main DODAG The P-DAO Request (PDR) message is sent by a Node in the Main DODAG
to the Root. It is a request to establish or refresh a Track where to the Root. It is a request to establish or refresh a Track where
this node is Track Ingress, and signals whether an acknowledgment this node is Track Ingress, and signals whether an acknowledgment
called PDR-ACK is requested or not. A positive PDR-ACK indicates called PDR-ACK is requested or not. A positive PDR-ACK indicates
that the Track was built and that the Roots commits to maintain the that the Track was built and that the Roots commits to maintain the
Track for the negotiated lifetime. Track for the negotiated lifetime.
The Root may use an asynchronous PDR-ACK with an negative status to The main Root MAY indicate to the Track Ingress that the Track was
indicate that the Track was terminated before its time. A status of terminated before its time and to do so, it MUST uses an asynchronous
"Transient Failure" (see Section 11.10) is an indication that the PDR PDR-ACK with an negative status. A status of "Transient Failure"
may be retried after a reasonable time that depends on the (see Section 11.10) is an indication that the PDR may be retried
deployment. Other negative status values indicate a permanent error; after a reasonable time that depends on the deployment. Other
the tentative must be abandoned until a corrective action is taken at negative status values indicate a permanent error; the tentative must
the application layer or through network management. be abandoned until a corrective action is taken at the application
layer or through network management.
The source IPv6 address of the PDR signals the Track Ingress to-be of The source IPv6 address of the PDR signals the Track Ingress to-be of
the requested Track, and the TrackID is indicated in the message the requested Track, and the TrackID is indicated in the message
itself. One and only one RPL Target Option MUST be present in the itself. One and only one RPL Target Option MUST be present in the
message. The RTO signals the Track Egress, more in Section 6.2. message. The RTO signals the Track Egress, more in Section 6.2.
The RPL Control Code for the PDR is 0x09, to be confirmed by IANA. The RPL Control Code for the PDR is 0x09, to be confirmed by IANA.
The format of PDR Base Object is as follows: The format of PDR Base Object is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TrackID |K|R| Flags | ReqLifetime | PDRSequence | | TrackID |K|R| Flags | ReqLifetime | PDRSequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)... | Option(s)...
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 12: New P-DAO Request Format Figure 13: New P-DAO Request Format
TrackID: 8-bit field. In the context of this specification, the TrackID: 8-bit field. In the context of this specification, the
TrackID field signals the RPLInstanceID of the DODAG formed by the TrackID field signals the RPLInstanceID of the DODAG formed by the
Track, see Section 3.4 and Section 6.3. To allocate a new Track, Track, see Section 3.4 and Section 6.3. To allocate a new Track,
the Ingress Node must provide a value that is not in use at this the Ingress Node must provide a value that is not in use at this
time. time.
K: The 'K' flag is set to indicate that the recipient is expected to K: The 'K' flag is set to indicate that the recipient is expected to
send a PDR-ACK back. send a PDR-ACK back.
skipping to change at page 43, line 35 skipping to change at page 44, line 47
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TrackID | Flags | Track Lifetime| PDRSequence | | TrackID | Flags | Track Lifetime| PDRSequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PDR-ACK Status| Reserved | | PDR-ACK Status| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)... | Option(s)...
+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+
Figure 13: New PDR-ACK Control Message Format Figure 14: New PDR-ACK Control Message Format
TrackID: Set to the TrackID indicated in the TrackID field of the TrackID: Set to the TrackID indicated in the TrackID field of the
PDR messages that this replies to. PDR messages that this replies to.
Flags: Reserved. The Flags field MUST initialized to zero by the Flags: Reserved. The Flags field MUST initialized to zero by the
sender and MUST be ignored by the receiver sender and MUST be ignored by the receiver
Track Lifetime: Indicates that remaining Lifetime for the Track, Track Lifetime: Indicates that remaining Lifetime for the Track,
expressed in Lifetime Units; the value of zero (0x00) indicates expressed in Lifetime Units; the value of zero (0x00) indicates
that the Track was destroyed or not created. that the Track was destroyed or not created.
PDRSequence: 8-bit wrapping sequence number. It is incremented at PDRSequence: 8-bit wrapping sequence number. It is incremented at
each PDR message and echoed in the PDR-ACK. each PDR message and echoed in the PDR-ACK.
PDR-ACK Status: 8-bit field indicating the completion. The PDR-ACK PDR-ACK Status: 8-bit field indicating the completion. The PDR-ACK
Status is substructured as indicated in Figure 14: Status is substructured as indicated in Figure 15:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|E|R| Value | |E|R| Value |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 14: PDR-ACK status Format Figure 15: PDR-ACK status Format
E: 1-bit flag. Set to indicate a rejection. When not set, the E: 1-bit flag. Set to indicate a rejection. When not set, the
value of 0 indicates Success/Unqualified Acceptance and other value of 0 indicates Success/Unqualified Acceptance and other
values indicate "not an outright rejection". values indicate "not an outright rejection".
R: 1-bit flag. Reserved, MUST be set to 0 by the sender and R: 1-bit flag. Reserved, MUST be set to 0 by the sender and
ignored by the receiver. ignored by the receiver.
Status Value: 6-bit unsigned integer. Values depending on the Status Value: 6-bit unsigned integer. Values depending on the
setting of the 'E' flag, see Table 28 and Table 29. setting of the 'E' flag, see Table 28 and Table 29.
Reserved: The Reserved field MUST initialized to zero by the sender Reserved: The Reserved field MUST initialized to zero by the sender
skipping to change at page 44, line 43 skipping to change at page 46, line 8
Lifetime of zero is referred as a No-Path P-DAO. Lifetime of zero is referred as a No-Path P-DAO.
The VIO contains one or more SRH-6LoRH header(s), each formed of a The VIO contains one or more SRH-6LoRH header(s), each formed of a
SRH-6LoRH head and a collection of compressed Via Addresses, except SRH-6LoRH head and a collection of compressed Via Addresses, except
in the case of a Non-Storing Mode No-Path P-DAO where the SRH-6LoRH in the case of a Non-Storing Mode No-Path P-DAO where the SRH-6LoRH
header is not present. header is not present.
In the case of a SM-VIO, or if [RFC8138] is not used in the data In the case of a SM-VIO, or if [RFC8138] is not used in the data
packets, then the Root MUST use only one SRH-6LoRH per Via packets, then the Root MUST use only one SRH-6LoRH per Via
Information Option, and the compression is the same forall the Information Option, and the compression is the same forall the
addresses, as shown in Figure 15, for simplicity. addresses, as shown in Figure 16, for simplicity.
In case of an NSM-VIO and if [RFC8138] is in use in the Main DODAG, In case of an NSM-VIO and if [RFC8138] is in use in the Main DODAG,
the Root SHOULD optimize the size of the NSM-VIO if using different the Root SHOULD optimize the size of the NSM-VIO if using different
SRH-6LoRH Types make the VIO globally shorter; this means that more SRH-6LoRH Types make the VIO globally shorter; this means that more
than one SRH-6LoRH may be present. than one SRH-6LoRH may be present.
The format of the Via Information Options is as follows: The format of the Via Information Options is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 45, line 29 skipping to change at page 46, line 41
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. Via Address n (compressed by RFC 8138) . . Via Address n (compressed by RFC 8138) .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. Additional SRH-6LoRH Header(s) . . Additional SRH-6LoRH Header(s) .
| | | |
. .... . . .... .
Figure 15: VIO format (uncompressed form) Figure 16: VIO format (uncompressed form)
Option Type: 0x0E for SM-VIO, 0x0F for NSM-VIO (to be confirmed by Option Type: 0x0E for SM-VIO, 0x0F for NSM-VIO (to be confirmed by
IANA), see =Table 26 IANA), see =Table 26
Option Length: 8-bit unsigned integer, representing the length in Option Length: 8-bit unsigned integer, representing the length in
octets of the option, not including the Option Type and Length octets of the option, not including the Option Type and Length
fields, see section 6.7.1. of [RPL]; the Option Length is fields, see section 6.7.1. of [RPL]; the Option Length is
variable, depending on the number of Via Addresses and the variable, depending on the number of Via Addresses and the
compression applied. compression applied.
skipping to change at page 47, line 23 skipping to change at page 48, line 35
The Sibling Information Option (SIO) provides indication on siblings The Sibling Information Option (SIO) provides indication on siblings
that could be used by the Root to form P-Routes. One or more SIO(s) that could be used by the Root to form P-Routes. One or more SIO(s)
may be placed in the DAO messages that are sent to the Root in Non- may be placed in the DAO messages that are sent to the Root in Non-
Storing Mode. Storing Mode.
To advertise a neighbor node, the router MUST have an active Address To advertise a neighbor node, the router MUST have an active Address
Registration from that sibling using [RFC8505], for an address (ULA Registration from that sibling using [RFC8505], for an address (ULA
or GUA) that serves as identifier for the node. If this router also or GUA) that serves as identifier for the node. If this router also
registers an address to that sibling, and the link has similar registers an address to that sibling, and the link has similar
properties in both directions, only the router with the lowest properties in both directions, only the router with the lowest
Interface ID in its registered address needs report the SIO, and the Interface ID in its registered address needs report the SIO, with the
Root will assume symmetry. B flag set, and the Root will assume symmetry.
The format of the SIO is as follows: The format of the SIO is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Option Length |S| Flags |Comp.| Opaque | | Type | Option Length |S|B|Flags|Comp.| Opaque |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Step in Rank | Reserved | | Step in Rank | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
. . . .
. Sibling DODAGID (if the D flag not set) . . Sibling DODAGID (if the D flag not set) .
. . . .
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
. . . .
. Sibling Address . . Sibling Address .
. . . .
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Sibling Information Option Format Figure 17: Sibling Information Option Format
Option Type: 0x10 for SIO (to be confirmed by IANA), see =Table 26 Option Type: 0x10 for SIO (to be confirmed by IANA), see =Table 26
Option Length: 8-bit unsigned integer, representing the length in Option Length: 8-bit unsigned integer, representing the length in
octets of the option, not including the Option Type and Length octets of the option, not including the Option Type and Length
fields, see section 6.7.1. of [RPL]. fields, see section 6.7.1. of [RPL].
Reserved for Flags: MUST be set to zero by the sender and MUST be Reserved for Flags: MUST be set to zero by the sender and MUST be
ignored by the receiver. ignored by the receiver.
B: 1-bit flag that is set to indicate that the connectivity to the
sibling is bidirectional and roughly symmetrical. In that case,
only one of the siblings may report the SIO for the hop. If 'B'
is not set then the SIO only indicates connectivity from the
sibling to this node, and does not provide information on the hop
from this node to the sibling.
S: 1-bit flag that is set to indicate that sibling belongs to the S: 1-bit flag that is set to indicate that sibling belongs to the
same DODAG. When not set, the Sibling DODAGID is indicated. same DODAG. When not set, the Sibling DODAGID is indicated.
Flags: Reserved. The Flags field MUST initialized to zero by the Flags: Reserved. The Flags field MUST initialized to zero by the
sender and MUST be ignored by the receiver sender and MUST be ignored by the receiver
Opaque: MAY be used to carry information that the node and the Root Opaque: MAY be used to carry information that the node and the Root
understand, e.g., a particular representation of the Link understand, e.g., a particular representation of the Link
properties such as a proprietary Link Quality Information for properties such as a proprietary Link Quality Information for
packets received from the sibling. An industrial Alliance that packets received from the sibling. An industrial Alliance that
skipping to change at page 49, line 43 skipping to change at page 51, line 28
The PDR signals the desired TrackID and the duration for which the The PDR signals the desired TrackID and the duration for which the
Track should be established. Upon a PDR, the Root MAY install the Track should be established. Upon a PDR, the Root MAY install the
Track as requested, in which case it answers with a PDR-ACK Track as requested, in which case it answers with a PDR-ACK
indicating the granted Track Lifetime. All the Segments MUST be of a indicating the granted Track Lifetime. All the Segments MUST be of a
same mode, either Storing or Non-Storing. All the Segments MUST be same mode, either Storing or Non-Storing. All the Segments MUST be
created with the same TrackID and the same DODAGID signaled in the created with the same TrackID and the same DODAGID signaled in the
P-DAO. P-DAO.
The Root designs the Track as it sees best, and updates / changes the The Root designs the Track as it sees best, and updates / changes the
Segments overtime to serve the Track as needed. There is no Segments overtime to serve the Track as needed. Note that there is
notification to the requesting node when those changes happen. The no protocol element to notify to the requesting Track Ingress when
Segment Lifetime in the P-DAO messages does not need to be aligned to changes happen deeper down the Track, so they are transparent to the
the Requested Lifetime in the PDR, or between P-DAO messages for Track Ingress. If the main Root cannot maintain an expected service
level, then it needs to tear down the Track completely. The Segment
Lifetime in the P-DAO messages does not need to be aligned to the
Requested Lifetime in the PDR, or between P-DAO messages for
different Segments. The Root may use shorter lifetimes for the different Segments. The Root may use shorter lifetimes for the
Segments and renew them faster than the Track is, or longer lifetimes Segments and renew them faster than the Track is, or longer lifetimes
in which case it will need to tear down the Segments if the Track is in which case it will need to tear down the Segments if the Track is
not renewed. not renewed.
When the Track Lifetime that was returned in the PDR-ACK is close to When the Track Lifetime that was returned in the PDR-ACK is close to
elapse - vs. the trip time from the node to the Root, the requesting elapse - vs. the trip time from the node to the Root, the requesting
node SHOULD resend a PDR using the TrackID in the PDR-ACK to extend node SHOULD resend a PDR using the TrackID in the PDR-ACK to extend
the lifetime of the Track, else the Track will time out and the Root the lifetime of the Track, else the Track will time out and the Root
will tear down the whole structure. will tear down the whole structure.
skipping to change at page 51, line 14 skipping to change at page 52, line 48
This way, a Track is uniquely identified by the tuple (DODAGID, This way, a Track is uniquely identified by the tuple (DODAGID,
TrackID) where the TrackID is always represented with the D flag TrackID) where the TrackID is always represented with the D flag
set to 0 (see also section 5.1. of [RPL]), indicating when used in set to 0 (see also section 5.1. of [RPL]), indicating when used in
an RPI that the source address of the IPv6 packet signals the an RPI that the source address of the IPv6 packet signals the
DODAGID. DODAGID.
The P-DAO Base Object MUST indicate the tuple (DODAGID, TrackID) The P-DAO Base Object MUST indicate the tuple (DODAGID, TrackID)
that identifies the Track as shown in Figure 8, and the P-RouteID that identifies the Track as shown in Figure 8, and the P-RouteID
that identifies the P-Route MUST be signaled in the VIO as shown that identifies the P-Route MUST be signaled in the VIO as shown
in Figure 15. in Figure 16.
The Track Ingress is the Root of the DODAG ID formed by the local The Track Ingress is the Root of the DODAG ID formed by the local
RPL Instance. It owns the namespace of its TrackIDs, so it can RPL Instance. It owns the namespace of its TrackIDs, so it can
pick any unused value to request a new Track with a PDR. In a pick any unused value to request a new Track with a PDR. In a
particular deployment where PDR are not used, the namespace can be particular deployment where PDR are not used, a portion of the
delegated to the main Root, which can assign the TrackIDs for the namespace can be administratively delegated to the main Root,
Tracks it creates without collision. meaning that the main Root is authoritative for assigning the
TrackIDs for the Tracks it creates.
With this specification, the Root is aware of all the active With this specification, the Root is aware of all the active
Tracks, so it can also pick any unused value to form Tracks Tracks, so it can also pick any unused value to form Tracks
without a PDR. To avoid a collision of the Root and the Track without a PDR. To avoid a collision of the Root and the Track
Ingress picking the same value at the same time, it is RECOMMENDED Ingress picking the same value at the same time, it is RECOMMENDED
that the Track Ingress starts allocating the ID value of the Local that the Track Ingress starts allocating the ID value of the Local
RPLInstanceID (see section 5.1. of [RPL]) used as TrackIDs with RPLInstanceID (see section 5.1. of [RPL]) used as TrackIDs with
the value 0 incrementing, while the Root starts with 63 the value 0 incrementing, while the Root starts with 63
decrementing. decrementing.
skipping to change at page 53, line 36 skipping to change at page 55, line 31
In a No-Path Non-Storing Mode P-DAO, the SRH-6LoRH MUST NOT be In a No-Path Non-Storing Mode P-DAO, the SRH-6LoRH MUST NOT be
present in the NSM-VIO; the state in the Ingress is erased present in the NSM-VIO; the state in the Ingress is erased
regardless. In all other cases, a VIO MUST contain at least one Via regardless. In all other cases, a VIO MUST contain at least one Via
Address, and a Via Address MUST NOT be present more than once, which Address, and a Via Address MUST NOT be present more than once, which
would create a loop. would create a loop.
A node that processes a VIO MAY verify whether one of these A node that processes a VIO MAY verify whether one of these
conditions happen, and when so, it MUST ignore the P-DAO and reject conditions happen, and when so, it MUST ignore the P-DAO and reject
it with a RPL Rejection Status of "Error in VIO" in the DAO-ACK, see it with a RPL Rejection Status of "Error in VIO" in the DAO-ACK, see
Section 11.15. Section 11.16.
Other errors than those discussed explicitely that prevent the Other errors than those discussed explicitely that prevent the
installing the route are acknowledged with a RPL Rejection Status of installing the route are acknowledged with a RPL Rejection Status of
"Unqualified Rejection" in the DAO-ACK. "Unqualified Rejection" in the DAO-ACK.
6.4.2. Installing a Track Segment with a Storing Mode P-Route 6.4.2. Installing a Track Segment with a Storing Mode P-Route
As illustrated in Figure 17, a Storing Mode P-DAO installs a route As illustrated in Figure 18, a Storing Mode P-DAO installs a route
along the Segment signaled by the SM-VIO towards the Targets along the Segment signaled by the SM-VIO towards the Targets
indicated in the Target Options. The Segment is to be included in a indicated in the Target Options. The Segment is to be included in a
DODAG indicated by the P-DAO Base Object, that may be the one formed DODAG indicated by the P-DAO Base Object, that may be the one formed
by the RPL Main DODAG, or a Track associated with a local RPL by the RPL Main DODAG, or a Track associated with a local RPL
Instance. Instance.
------+--------- ------+---------
| Internet | Internet
| |
+-----+ +-----+
skipping to change at page 54, line 22 skipping to change at page 56, line 22
| | DAO | ACK | | | DAO | ACK |
o o o o | | | o o o o | | |
o o o o o o o o o | ^ | Projected . o o o o o o o o o | ^ | Projected .
o o o o o o o o o o | | DAO | Route . o o o o o o o o o o | | DAO | Route .
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 v | DAO v . o o o o o o o o v | DAO v .
o o LLN o o o | o o LLN o o o |
o o o o o Loose Source Route Path | o o o o o Loose Source Route Path |
o o o o v o o o o v
Figure 17: Projecting a route Figure 18: Projecting a route
In order to install the relevant routing state along the Segment , In order to install the relevant routing state along the Segment ,
the Root sends a unicast P-DAO message to the Track Egress router of the Root sends a unicast P-DAO message to the Track Egress router of
the routing Segment that is being installed. The P-DAO message the routing Segment that is being installed. The P-DAO message
contains a SM-VIO with the strict sequence of Via Addresses. The SM- contains a SM-VIO with the strict sequence of Via Addresses. The SM-
VIO follows one or more RTOs indicating the Targets to which the VIO follows one or more RTOs indicating the Targets to which the
Track leads. The SM-VIO contains a Segment Lifetime for which the Track leads. The SM-VIO contains a Segment Lifetime for which the
state is to be maintained. state is to be maintained.
The Root sends the P-DAO directly to the Egress node of the Segment. The Root sends the P-DAO directly to the Egress node of the Segment.
skipping to change at page 55, line 34 skipping to change at page 57, line 34
The process continues till the P-DAO is propagated to Ingress router The process continues till the P-DAO is propagated to Ingress router
of the Segment, which answers with a DAO-ACK to the Root. The Root of the Segment, which answers with a DAO-ACK to the Root. The Root
always expects a DAO-ACK, either from the Track Ingress with a always expects a DAO-ACK, either from the Track Ingress with a
positive status or from any node along the segment with a negative positive status or from any node along the segment with a negative
status. If the DAO-ACK is not received, the Root may retry the DAO status. If the DAO-ACK is not received, the Root may retry the DAO
with the same TID, or tear down the route. with the same TID, or tear down the route.
6.4.3. Installing a Track Leg with a Non-Storing Mode P-Route 6.4.3. Installing a Track Leg with a Non-Storing Mode P-Route
As illustrated in Figure 18, a Non-Storing Mode P-DAO installs a As illustrated in Figure 19, a Non-Storing Mode P-DAO installs a
source-routed path within the Track indicated by the P-DAO Base source-routed path within the Track indicated by the P-DAO Base
Object, towards the Targets indicated in the Target Options. The Object, towards the Targets indicated in the Target Options. The
source-routed path requires a Source-Routing header which implies an source-routed path requires a Source-Routing header which implies an
IP-in-IP encapsulation to add the SRH to an existing packet. It is IP-in-IP encapsulation to add the SRH to an existing packet. It is
sent to the Track Ingress which creates a tunnel associated with the sent to the Track Ingress which creates a tunnel associated with the
Track, and connected routes over the tunnel to the Targets in the Track, and connected routes over the tunnel to the Targets in the
RTO. The tunnel encapsulation MUST incorporate a routing header via RTO. The tunnel encapsulation MUST incorporate a routing header via
the list addresses listed in the VIO in the same order. The content the list addresses listed in the VIO in the same order. The content
of the NSM-VIO starting at the first SRH-6LoRH header MUST be used of the NSM-VIO starting at the first SRH-6LoRH header MUST be used
verbatim by the Track Ingress when it encapsulates a packet to verbatim by the Track Ingress when it encapsulates a packet to
skipping to change at page 56, line 23 skipping to change at page 58, line 23
o o o o Ingress X V | X o o o o Ingress X V | X
o o o o o o o X o X Source o o o o o o o X o X Source
o o o o o o o o X o o X Routed o o o o o o o o X o o X Routed
o o ° o o o o X o X Segment o o ° o o o o X o X Segment
o o o o o o o o X Egress X o o o o o o o o X Egress X
o o o o o | o o o o o |
Target Target
o o LLN o o o o LLN o o
o o o o o o o o
Figure 18: Projecting a Non-Storing Route Figure 19: Projecting a Non-Storing Route
The next entry in the source-routed path must be either a neighbor of The next entry in the source-routed path must be either a neighbor of
the previous entry, or reachable as a Target via another P-Route, the previous entry, or reachable as a Target via another P-Route,
either Storing or Non-Storing, which implies that the nested P-Route either Storing or Non-Storing, which implies that the nested P-Route
has to be installed before the loose sequence is, and that P-Routes has to be installed before the loose sequence is, and that P-Routes
must be installed from the last to the first along the datapath. For must be installed from the last to the first along the datapath. For
instance, a Segment of a Track must be installed before the Leg(s) of instance, a Segment of a Track must be installed before the Leg(s) of
the same Track that use it, and stitched Segments must be installed the same Track that use it, and stitched Segments must be installed
in order from the last that reaches to the Targets to the first. in order from the last that reaches to the Targets to the first.
skipping to change at page 61, line 14 skipping to change at page 63, line 14
* When a Track Egress extracts a packet from a Track (decapsulates * When a Track Egress extracts a packet from a Track (decapsulates
the packet), the destination of the inner packet must be either the packet), the destination of the inner packet must be either
this node or a direct neighbor, or a Target of another Segment of this node or a direct neighbor, or a Target of another Segment of
the same Track for which this node is Ingress, otherwise the the same Track for which this node is Ingress, otherwise the
packet MUST be dropped. packet MUST be dropped.
In case of a failure forwarding a packet along a Segment, e.g., the In case of a failure forwarding a packet along a Segment, e.g., the
next hop is unreachable, the node that discovers the fault MUST send next hop is unreachable, the node that discovers the fault MUST send
an ICMPv6 Error message [RFC4443] to the Root, with a new Code "Error an ICMPv6 Error message [RFC4443] to the Root, with a new Code "Error
in P-Route" (See Section 11.14). The Root can then repair by in P-Route" (See Section 11.15). The Root can then repair by
updating the broken Segment and/or Tracks, and in the case of a updating the broken Segment and/or Tracks, and in the case of a
broken Segment, remove the leftover sections of the segment using SM- broken Segment, remove the leftover sections of the segment using SM-
VIOs with a lifetime of 0 indicating the section ot one or more nodes VIOs with a lifetime of 0 indicating the section ot one or more nodes
being removed (See Section 6.6). being removed (See Section 6.6).
In case of a permanent forwarding error along a Source Route path, In case of a permanent forwarding error along a Source Route path,
the node that fails to forward SHOULD send an ICMP error with a code the node that fails to forward SHOULD send an ICMP error with a code
"Error in Source Routing Header" back to the source of the packet, as "Error in Source Routing Header" back to the source of the packet, as
described in section 11.2.2.3. of [RPL]. Upon this message, the described in section 11.2.2.3. of [RPL]. Upon this message, the
encapsulating node SHOULD stop using the source route path for a encapsulating node SHOULD stop using the source route path for a
skipping to change at page 61, line 47 skipping to change at page 63, line 47
this hop of the RH SHOULD be consumed by this node so that the this hop of the RH SHOULD be consumed by this node so that the
destination in the IPv6 header is the next hop that this node could destination in the IPv6 header is the next hop that this node could
not reach. if a 6LoWPAN Routing Header (6LoRH) [RFC8138] is used to not reach. if a 6LoWPAN Routing Header (6LoRH) [RFC8138] is used to
carry the IPv6 routing information in the outer header then that carry the IPv6 routing information in the outer header then that
whole 6LoRH information SHOULD be present in the ICMP message. whole 6LoRH information SHOULD be present in the ICMP message.
6.8. Compression of the RPL Artifacts 6.8. Compression of the RPL Artifacts
When using [RFC8138] in the Main DODAG operated in Non-Storing Mode When using [RFC8138] in the Main DODAG operated in Non-Storing Mode
in a 6LoWPAN LLN, a typical packet that circulates in the Main DODAG in a 6LoWPAN LLN, a typical packet that circulates in the Main DODAG
is formatted as shown in Figure 19, representing the case where : is formatted as shown in Figure 20, representing the case where :
+-+ ... -+- ... -+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-... +-+ ... -+- ... -+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-...
|11110001| SRH- | RPI- | IP-in-IP | NH=1 |11110CPP| UDP | UDP |11110001| SRH- | RPI- | IP-in-IP | NH=1 |11110CPP| UDP | UDP
| Page 1 | 6LoRH | 6LoRH | 6LoRH |LOWPAN_IPHC| UDP | hdr |Payld | Page 1 | 6LoRH | 6LoRH | 6LoRH |LOWPAN_IPHC| UDP | hdr |Payld
+-+ ... -+- ... -+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-... +-+ ... -+- ... -+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-...
<= RFC 6282 => <= RFC 6282 =>
<================ Inner packet ==================== = = <================ Inner packet ==================== = =
Figure 19: A Packet as Forwarded along the Main DODAG Figure 20: A Packet as Forwarded along the Main DODAG
Since there is no page switch between the encapsulated packet and the Since there is no page switch between the encapsulated packet and the
encapsulation, the first octet of the compressed packet that acts as encapsulation, the first octet of the compressed packet that acts as
page selector is actually removed at encapsulation, so the inner page selector is actually removed at encapsulation, so the inner
packet used in the descriptions below start with the SRH-6LoRH, and packet used in the descriptions below start with the SRH-6LoRH, and
is verbatim the packet represented in Figure 19 from the second octet is verbatim the packet represented in Figure 20 from the second octet
on. on.
When encapsulating that inner packet to place it in the Track, the When encapsulating that inner packet to place it in the Track, the
first header that the Ingress appends at the head of the inner packet first header that the Ingress appends at the head of the inner packet
is an IP-in-IP 6LoRH Header; in that header, the encapsulator is an IP-in-IP 6LoRH Header; in that header, the encapsulator
address, which maps to the IPv6 source address in the uncompressed address, which maps to the IPv6 source address in the uncompressed
form, contains a GUA or ULA IPv6 address of the Ingress node that form, contains a GUA or ULA IPv6 address of the Ingress node that
serves as DODAG ID for the Track, expressed in the compressed form serves as DODAG ID for the Track, expressed in the compressed form
and using the DODAGID of the Main DODAG as compression reference. If and using the DODAGID of the Main DODAG as compression reference. If
the address is compressed to 2 bytes, the resulting value for the the address is compressed to 2 bytes, the resulting value for the
Length field shown in Figure 20 is 3, meaning that the SRH-6LoRH as a Length field shown in Figure 21 is 3, meaning that the SRH-6LoRH as a
whole is 5-octets long. whole is 5-octets long.
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
|1|0|1| Length | 6LoRH Type 6 | Hop Limit | Track DODAGID | |1|0|1| Length | 6LoRH Type 6 | Hop Limit | Track DODAGID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
Figure 20: The IP-in-IP 6LoRH Header Figure 21: The IP-in-IP 6LoRH Header
At the head of the resulting sequence of bytes, the track Ingress At the head of the resulting sequence of bytes, the track Ingress
then adds the RPI that carries the TrackID as RPLinstanceID as a P- then adds the RPI that carries the TrackID as RPLinstanceID as a P-
RPI-6LoRH Header, as illustrated in Figure 11, using the TrackID as RPI-6LoRH Header, as illustrated in Figure 12, using the TrackID as
RPLInstanceID. Combined with the IP-in-IP 6LoRH Header, this allows RPLInstanceID. Combined with the IP-in-IP 6LoRH Header, this allows
to identify the Track without ambiguity. to identify the Track without ambiguity.
The SRH-6LoRH is then added at the head of the resulting sequence of The SRH-6LoRH is then added at the head of the resulting sequence of
bytes as a verbatim copy of the content of the SR-VIO that signaled bytes as a verbatim copy of the content of the SR-VIO that signaled
the selected Track Leg. the selected Track Leg.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 .. .. .. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 .. .. ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+
|1|0|0| Size |6LoRH Type 0..4| Hop1 | Hop2 | | HopN | |1|0|0| Size |6LoRH Type 0..4| Hop1 | Hop2 | | HopN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+
Where N = Size + 1 Where N = Size + 1
Figure 21: The SRH 6LoRH Header Figure 22: The SRH 6LoRH Header
The format of the resulting encapsulated packet in [RFC8138] The format of the resulting encapsulated packet in [RFC8138]
compressed form is illustrated in Figure 22: compressed form is illustrated in Figure 23:
+-+ ... -+-+-+- ... -+-+-+- ... -+-+-+-+-+- ... +-+-+-+-+-+-+- ... +-+ ... -+-+-+- ... -+-+-+- ... -+-+-+-+-+- ... +-+-+-+-+-+-+- ...
| Page 1 | SRH-6LoRH | P-RPI-6LoRH | IP-in-IP 6LoRH | Inner Packet | Page 1 | SRH-6LoRH | P-RPI-6LoRH | IP-in-IP 6LoRH | Inner Packet
+-+ ... -+-+-+- ... -+-+-+- ... -+-+-+-+-+- ... +-+-+-+-+-+-+- ... +-+ ... -+-+-+- ... -+-+-+- ... -+-+-+-+-+- ... +-+-+-+-+-+-+- ...
Signals : Loose Hops : TrackID : Track DODAGID : Signals : Loose Hops : TrackID : Track DODAGID :
Figure 22: A Packet as Forwarded along a Track Figure 23: A Packet as Forwarded along a Track
7. Lesser Constrained Variations 7. Lesser Constrained Variations
7.1. Storing Mode Main DODAG 7.1. Storing Mode Main DODAG
This specification expects that the Main DODAG is operated in Non- This specification expects that the Main DODAG is operated in Non-
Storing Mode. The reasons for that limitation are mostly related to Storing Mode. The reasons for that limitation are mostly related to
LLN operations, power and spectrum conservation: LLN operations, power and spectrum conservation:
* In Non-Storing Mode The Root already possesses the DODAG topology, * In Non-Storing Mode The Root already possesses the DODAG topology,
skipping to change at page 66, line 51 skipping to change at page 68, line 51
do. This section describes profiles that enable to implement only a do. This section describes profiles that enable to implement only a
portion of this specification to meet a particular use case. portion of this specification to meet a particular use case.
Profiles 0 to 2 operate in the Main RPL Instance and do not require Profiles 0 to 2 operate in the Main RPL Instance and do not require
the support of local RPL Instances or the indication of the RPL the support of local RPL Instances or the indication of the RPL
Instance in the data plane. Profile 3 and above leverage Local RPL Instance in the data plane. Profile 3 and above leverage Local RPL
Instances to build arbitrary Tracks Rooted at the Track Ingress and Instances to build arbitrary Tracks Rooted at the Track Ingress and
using its namespace for TrackID. using its namespace for TrackID.
Profiles 0 and 1 are REQUIRED by all implementations that may be used Profiles 0 and 1 are REQUIRED by all implementations that may be used
in LLNs; this enables to use Storing Mode to reduce the size of the in LLNs; Profiles 1 leverages Storing Mode to reduce the size of the
Source Route Header in the most common LLN deployments. Profile 2 is Source Route Header in the most common LLN deployments. Profile 2 is
RECOMMENDED in high speed / wired environment to enable traffic RECOMMENDED in high speed / wired environment to enable traffic
Engineering and network automation. All the other profile / Engineering and network automation. All the other profile /
environment combinations are OPTIONAL. environment combinations are OPTIONAL.
Profile 0 Profile 0 is the Legacy support of [RPL] Non-Storing Mode, Profile 0 Profile 0 is the Legacy support of [RPL] Non-Storing Mode,
with default routing Northwards (up) and strict source routing with default routing Northwards (up) and strict source routing
Southwards (down the main DOAG). It provides the minimal common Southwards (down the main DOAG). It provides the minimal common
functionality that must be implemented as a prerequisite to all functionality that must be implemented as a prerequisite to all
the Track-supporting profiles. The other Profiles extend Profile the Track-supporting profiles. The other Profiles extend Profile
skipping to change at page 68, line 33 skipping to change at page 70, line 33
DODAG. DODAG.
Profile 9 Profile 9 combines profiles 7 and 8, operating the Track Profile 9 Profile 9 combines profiles 7 and 8, operating the Track
as a full DODAG within a Storing Mode Main DODAG, using only the as a full DODAG within a Storing Mode Main DODAG, using only the
Main DODAG RPLInstanceID as TrackID. Main DODAG RPLInstanceID as TrackID.
9. Backwards Compatibility 9. Backwards Compatibility
This specification can operate in a mixed network where some nodes This specification can operate in a mixed network where some nodes
support it and some do not. There are restructions, though. All support it and some do not. There are restructions, though. All
nodes that need to process a P-DAO must support this specification. nodes that need to process a P-DAO MUST support this specification.
As discussed in Section 3.7.1, how the root knows whether the nodes As discussed in Section 3.7.1, how the root knows whether the nodes
capabilities and whether it support this specification is out of capabilities and whether it support this specification is out of
scope. scope.
This specification defines the 'D' flag in the RPL DODAG This specification defines the 'D' flag in the RPL DODAG
Configuration Option (see Section 4.1.6) to signal that the RPL nodes Configuration Option (see Section 4.1.7) to signal that the RPL nodes
can request the creation of Tracks. The requester may not know can request the creation of Tracks. The requester may not know
whether the Track can effectively be constructed, and whether enough whether the Track can effectively be constructed, and whether enough
nodes along the preferred paths support this specification. nodes along the preferred paths support this specification.
Therefore it makes sense to only set the 'D' flags in DIO when the Therefore it makes sense to only set the 'D' flags in DIO when the
conditions of success are in place, in particular when all the nodes conditions of success are in place, in particular when all the nodes
that could be on path of tracks are upgraded. that could be on path of tracks are upgraded.
10. Security Considerations 10. Security Considerations
It is worth noting that with [RPL], every node in the LLN is RPL- It is worth noting that with [RPL], every node in the LLN is RPL-
aware and can inject any RPL-based attack in the network. This draft aware and can inject any RPL-based attack in the network. This draft
uses messages that are already present in RPL [RPL] with optional uses messages that are already present in RPL [RPL] with optional
secured versions. The same secured versions may be used with this secured versions. The same secured versions may be used with this
draft, and whatever security is deployed for a given network also draft, and whatever security is deployed for a given network also
applies to the flows in this draft. applies to the flows in this draft.
The LLN nodes depend on the 6LBR and the RPL participants for their The LLN nodes depend on the 6LBR and the RPL participants for their
operation. A trust model must be put in place to ensure that the operation. A trust model is necessary to ensure that the right
right devices are acting in these roles, so as to avoid threats such devices are acting in these roles, so as to avoid threats such as
as black-holing, (see [RFC7416] section 7). This trust model could black-holing, (see [RFC7416] section 7). This trust model could be
be at a minimum based on a Layer-2 Secure joining and the Link-Layer at a minimum based on a Layer-2 Secure joining and the Link-Layer
security. This is a generic 6LoWPAN requirement, see Req5.1 in security. This is a generic 6LoWPAN requirement, see Req5.1 in
Appendix B.5 of [RFC8505]. Appendix B.5 of [RFC8505].
In a general manner, the Security Considerations in [RPL], and In a general manner, the Security Considerations in [RPL], and
[RFC7416] apply to this specification as well. The Link-Layer [RFC7416] apply to this specification as well. The Link-Layer
security is needed in particular to prevent Denial-Of-Service attacks security is needed in particular to prevent Denial-Of-Service attacks
whereby a rogue router creates a high churn in the RPL network by whereby a rogue router creates a high churn in the RPL network by
constantly injected forged P-DAO messages and using up all the constantly injected forged P-DAO messages and using up all the
available storage in the attacked routers. available storage in the attacked routers.
skipping to change at page 70, line 49 skipping to change at page 72, line 49
+===============+=============+===============+ +===============+=============+===============+
| 8 (Suggested) | P-RPI-6LoRH | This document | | 8 (Suggested) | P-RPI-6LoRH | This document |
+---------------+-------------+---------------+ +---------------+-------------+---------------+
Table 23: New Critical 6LoWPAN Routing Table 23: New Critical 6LoWPAN Routing
Header Type Header Type
11.4. Subregistry For The RPL Option Flags 11.4. Subregistry For The RPL Option Flags
IANA is required to create a subregistry for the 8-bit RPL Option IANA is required to create a subregistry for the 8-bit RPL Option
Flags field, as detailed in Figure 10, under the "Routing Protocol Flags field, as detailed in Figure 11, under the "Routing Protocol
for Low Power and Lossy Networks (RPL)" registry. The bits are for Low Power and Lossy Networks (RPL)" registry. The bits are
indexed from 0 (leftmost) to 7. Each bit is Tracked with the indexed from 0 (leftmost) to 7. Each bit is Tracked with the
following qualities: following qualities:
* Bit number (counting from bit 0 as the most significant bit) * Bit number (counting from bit 0 as the most significant bit)
* Indication When Set * Indication When Set
* Reference * Reference
skipping to change at page 74, line 39 skipping to change at page 76, line 39
+===============+========================+===========+ +===============+========================+===========+
| Bit number | Capability description | Reference | | Bit number | Capability description | Reference |
+===============+========================+===========+ +===============+========================+===========+
| 0 (Suggested) | "S" flag: Sibling in | This | | 0 (Suggested) | "S" flag: Sibling in | This |
| | same DODAG as Self | document | | | same DODAG as Self | document |
+---------------+------------------------+-----------+ +---------------+------------------------+-----------+
Table 30: Initial SIO Flags Table 30: Initial SIO Flags
11.13. destination Advertisement Object Flag 11.13. Destination Advertisement Object Flag
This document modifies the "destination Advertisement Object (DAO) This document modifies the "Destination Advertisement Object (DAO)
Flags" registry initially created in Section 20.11 of [RPL] . Flags" registry initially created in Section 20.11 of [RPL] .
Section 4.1.1 also defines one new entry in the Registry as follows: Section 4.1.1 also defines one new entry in the Registry as follows:
+---------------+------------------------+-----------+ +---------------+------------------------+-----------+
| Bit Number | Capability Description | Reference | | Bit Number | Capability Description | Reference |
+---------------+------------------------+-----------+ +---------------+------------------------+-----------+
| 2 (Suggested) | Projected DAO (P) | THIS RFC | | 2 (Suggested) | Projected DAO (P) | THIS RFC |
+---------------+------------------------+-----------+ +---------------+------------------------+-----------+
Table 31: New destination Advertisement Object Table 31: New Destination Advertisement Object
(DAO) Flag (DAO) Flag
11.14. New ICMPv6 Error Code 11.14. Destination Advertisement Object Acknowledgment Flag
This document modifies the "Destination Advertisement Object (DAO)
Acknowledgment Flags" registry initially created in Section 20.12 of
[RPL] .
Section 4.1.2 also defines one new entry in the Registry as follows:
+---------------+------------------------+-----------+
| Bit Number | Capability Description | Reference |
+---------------+------------------------+-----------+
| 1 (Suggested) | Projected DAO-ACK (P) | THIS RFC |
+---------------+------------------------+-----------+
Table 32: New Destination Advertisement Object
Acknowledgment Flag
11.15. New ICMPv6 Error Code
In some cases RPL will return an ICMPv6 error message when a message In some cases RPL will return an ICMPv6 error message when a message
cannot be forwarded along a P-Route. cannot be forwarded along a P-Route.
IANA has defined an ICMPv6 "Code" Fields Registry for ICMPv6 Message IANA has defined an ICMPv6 "Code" Fields Registry for ICMPv6 Message
Types. ICMPv6 Message Type 1 describes "destination Unreachable" Types. ICMPv6 Message Type 1 describes "destination Unreachable"
codes. This specification requires that a new code is allocated from codes. This specification requires that a new code is allocated from
the ICMPv6 Code Fields Registry for ICMPv6 Message Type 1, for "Error the ICMPv6 Code Fields Registry for ICMPv6 Message Type 1, for "Error
in P-Route", with a suggested code value of 8, to be confirmed by in P-Route", with a suggested code value of 8, to be confirmed by
IANA. IANA.
11.15. RPL Rejection Status values 11.16. RPL Rejection Status values
This specification updates the Subregistry for the "RPL Rejection This specification updates the Subregistry for the "RPL Rejection
Status" values under the RPL registry, as follows: Status" values under the RPL registry, as follows:
+---------------+-------------------------+-----------+ +---------------+-------------------------+-----------+
| Value | Meaning | Reference | | Value | Meaning | Reference |
+---------------+-------------------------+-----------+ +---------------+-------------------------+-----------+
| 2 (Suggested) | Out of Resources | THIS RFC | | 2 (Suggested) | Out of Resources | THIS RFC |
+---------------+-------------------------+-----------+ +---------------+-------------------------+-----------+
| 3 (Suggested) | Error in VIO | THIS RFC | | 3 (Suggested) | Error in VIO | THIS RFC |
+---------------+-------------------------+-----------+ +---------------+-------------------------+-----------+
| 4 (Suggested) | Predecessor Unreachable | THIS RFC | | 4 (Suggested) | Predecessor Unreachable | THIS RFC |
+---------------+-------------------------+-----------+ +---------------+-------------------------+-----------+
| 5 (Suggested) | Unreachable Target | THIS RFC | | 5 (Suggested) | Unreachable Target | THIS RFC |
+---------------+-------------------------+-----------+ +---------------+-------------------------+-----------+
| 6..63 | Unassigned | | | 6..63 | Unassigned | |
+---------------+-------------------------+-----------+ +---------------+-------------------------+-----------+
Table 32: Rejection values of the RPL Status Table 33: Rejection values of the RPL Status
12. Acknowledgments 12. Acknowledgments
The authors wish to acknowledge JP Vasseur, Remy Liubing, James The authors wish to acknowledge JP Vasseur, Remy Liubing, James
Pylakutty, and Patrick Wetterwald for their contributions to the Pylakutty, and Patrick Wetterwald for their contributions to the
ideas developed here. Many thanks to Dominique Barthel and SVR Anand ideas developed here. Many thanks to Dominique Barthel and SVR Anand
for their global contribution to 6TiSCH, RAW and this document, as for their global contribution to 6TiSCH, RAW and this document, as
well as text suggestions that were incorporated, and to Michael well as text suggestions that were incorporated, and to Michael
Richardson for his useful recommendations based on his global view of Richardson for his useful recommendations based on his global view of
the system. Also special thanks Toerless Eckert for his deep review, the system all along the developement of this specification. Also
with many excellent suggestions that improved the readability and special thanks Toerless Eckert for his deep review, with many
well as the content of the specification. excellent suggestions that improved the readability and well as the
content of the specification. Many thanks to Remous-Aris
Koutsiamanis for his review during WGLC.
13. Normative References 13. Normative References
[INT-ARCHI] [INT-ARCHI]
Braden, R., Ed., "Requirements for Internet Hosts - Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>. <https://www.rfc-editor.org/info/rfc1122>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 78, line 24 skipping to change at page 80, line 40
(RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015,
<https://www.rfc-editor.org/info/rfc7416>. <https://www.rfc-editor.org/info/rfc7416>.
[6TiSCH-ARCHI] [6TiSCH-ARCHI]
Thubert, P., Ed., "An Architecture for IPv6 over the Time- Thubert, P., Ed., "An Architecture for IPv6 over the Time-
Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)", Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)",
RFC 9030, DOI 10.17487/RFC9030, May 2021, RFC 9030, DOI 10.17487/RFC9030, May 2021,
<https://www.rfc-editor.org/info/rfc9030>. <https://www.rfc-editor.org/info/rfc9030>.
[RAW-ARCHI] [RAW-ARCHI]
Thubert, P., Papadopoulos, G. Z., and L. Berger, "Reliable Thubert, P. and G. Z. Papadopoulos, "Reliable and
and Available Wireless Architecture/Framework", Work in Available Wireless Architecture", Work in Progress,
Progress, Internet-Draft, draft-ietf-raw-architecture-01, Internet-Draft, draft-ietf-raw-architecture-02, 29
28 July 2021, <https://datatracker.ietf.org/doc/html/ November 2021, <https://datatracker.ietf.org/doc/html/
draft-ietf-raw-architecture-01>. draft-ietf-raw-architecture-02>.
[USE-CASES] [USE-CASES]
Papadopoulos, G. Z., Thubert, P., Theoleyre, F., and C. J. Papadopoulos, G. Z., Thubert, P., Theoleyre, F., and C. J.
Bernardos, "RAW use cases", Work in Progress, Internet- Bernardos, "RAW use cases", Work in Progress, Internet-
Draft, draft-ietf-raw-use-cases-03, 20 October 2021, Draft, draft-ietf-raw-use-cases-03, 20 October 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-raw-use- <https://datatracker.ietf.org/doc/html/draft-ietf-raw-use-
cases-03>. cases-03>.
[TURN-ON_RFC8138] [TURN-ON_RFC8138]
Thubert, P., Ed. and L. Zhao, "A Routing Protocol for Low- Thubert, P., Ed. and L. Zhao, "A Routing Protocol for Low-
skipping to change at page 80, line 29 skipping to change at line 3701
Rahul Arvind Jadhav Rahul Arvind Jadhav
Huawei Tech Huawei Tech
Kundalahalli Village, Whitefield, Kundalahalli Village, Whitefield,
Bangalore 560037 Bangalore 560037
Karnataka Karnataka
India India
Phone: +91-080-49160700 Phone: +91-080-49160700
Email: rahul.ietf@gmail.com Email: rahul.ietf@gmail.com
Matthew Gillmore
Itron, Inc
Building D
2111 N Molter Road
Liberty Lake, 99019
United States
Phone: +1.800.635.5461
Email: matthew.gillmore@itron.com
 End of changes. 70 change blocks. 
146 lines changed or deleted 234 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/