< draft-ietf-roll-dao-projection-17.txt   draft-ietf-roll-dao-projection-18.txt >
ROLL P. Thubert, Ed. ROLL P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Updates: 6554 (if approved) R.A. Jadhav Updates: 6554 (if approved) R.A. Jadhav
Intended status: Standards Track Huawei Tech Intended status: Standards Track Huawei Tech
Expires: 5 December 2021 M. Gillmore Expires: 13 January 2022 M. Gillmore
Itron Itron
3 June 2021 12 July 2021
Root initiated routing state in RPL Root initiated routing state in RPL
draft-ietf-roll-dao-projection-17 draft-ietf-roll-dao-projection-18
Abstract Abstract
This document extends RFC 6550 and RFC 6553 to enable a RPL Root to This document extends RFC 6550 and RFC 6553 to enable a RPL Root to
install and maintain Projected Routes within its DODAG, along a install and maintain Projected Routes within its DODAG, along a
selected set of nodes that may or may not include self, for a chosen selected set of nodes that may or may not include self, for a chosen
duration. This potentially enables routes that are more optimized or duration. This potentially enables routes that are more optimized or
resilient than those obtained with the classical distributed resilient than those obtained with the classical distributed
operation of RPL, either in terms of the size of a Routing Header or operation of RPL, either in terms of the size of a Routing Header or
in terms of path length, which impacts both the latency and the in terms of path length, which impacts both the latency and the
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 5 December 2021. This Internet-Draft will expire on 13 January 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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.
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2.2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Other Terms . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Other Terms . . . . . . . . . . . . . . . . . . . . . . . 6
2.4. References . . . . . . . . . . . . . . . . . . . . . . . 6 2.4. References . . . . . . . . . . . . . . . . . . . . . . . 6
3. Extending RFC 6550 . . . . . . . . . . . . . . . . . . . . . 6 3. Extending RFC 6550 . . . . . . . . . . . . . . . . . . . . . 6
3.1. Projected DAO . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Projected DAO . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Sibling Information Option . . . . . . . . . . . . . . . 8 3.2. Sibling Information Option . . . . . . . . . . . . . . . 8
3.3. P-DAO Request . . . . . . . . . . . . . . . . . . . . . . 8 3.3. P-DAO Request . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Extending the RPI . . . . . . . . . . . . . . . . . . . . 9 3.4. Extending the RPI . . . . . . . . . . . . . . . . . . . . 9
4. Extending RFC 6553 . . . . . . . . . . . . . . . . . . . . . 9 4. Extending RFC 6553 . . . . . . . . . . . . . . . . . . . . . 9
5. Extending RFC 8138 . . . . . . . . . . . . . . . . . . . . . 10 5. Extending RFC 8138 . . . . . . . . . . . . . . . . . . . . . 10
6. New RPL Control Messages and Options . . . . . . . . . . . . 10 6. New RPL Control Messages and Options . . . . . . . . . . . . 11
6.1. New P-DAO Request Control Message . . . . . . . . . . . . 11 6.1. New P-DAO Request Control Message . . . . . . . . . . . . 11
6.2. New PDR-ACK Control Message . . . . . . . . . . . . . . . 12 6.2. New PDR-ACK Control Message . . . . . . . . . . . . . . . 12
6.3. Via Information Options . . . . . . . . . . . . . . . . . 13 6.3. Via Information Options . . . . . . . . . . . . . . . . . 13
6.4. Sibling Information Option . . . . . . . . . . . . . . . 15 6.4. Sibling Information Option . . . . . . . . . . . . . . . 16
7. Projected DAO . . . . . . . . . . . . . . . . . . . . . . . . 17 7. Projected DAO . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Requesting a Track . . . . . . . . . . . . . . . . . . . 19 7.1. Requesting a Track . . . . . . . . . . . . . . . . . . . 19
7.2. Identifying a Track . . . . . . . . . . . . . . . . . . . 19 7.2. Identifying a Track . . . . . . . . . . . . . . . . . . . 20
7.3. Installing a Track . . . . . . . . . . . . . . . . . . . 21 7.3. Installing a Track . . . . . . . . . . . . . . . . . . . 21
7.3.1. Storing-Mode P-Route . . . . . . . . . . . . . . . . 22 7.3.1. Storing-Mode P-Route . . . . . . . . . . . . . . . . 22
7.3.2. Non-Storing-Mode P-Route . . . . . . . . . . . . . . 24 7.3.2. Non-Storing-Mode P-Route . . . . . . . . . . . . . . 24
7.4. Forwarding Along a Track . . . . . . . . . . . . . . . . 25 7.4. Forwarding Along a Track . . . . . . . . . . . . . . . . 26
8. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 26 8. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 27
9. Example Track Signaling . . . . . . . . . . . . . . . . . . . 27 9. Example Track Signaling . . . . . . . . . . . . . . . . . . . 28
9.1. Using Storing-Mode Segments . . . . . . . . . . . . . . . 28 9.1. Using Storing-Mode Segments . . . . . . . . . . . . . . . 29
9.1.1. Stitched Segments . . . . . . . . . . . . . . . . . . 28 9.1.1. Stitched Segments . . . . . . . . . . . . . . . . . . 29
9.1.2. External routes . . . . . . . . . . . . . . . . . . . 30 9.1.2. External routes . . . . . . . . . . . . . . . . . . . 31
9.1.3. Segment Routing . . . . . . . . . . . . . . . . . . . 31 9.1.3. Segment Routing . . . . . . . . . . . . . . . . . . . 32
9.2. Using Non-Storing-Mode joining Tracks . . . . . . . . . . 33 9.2. Using Non-Storing-Mode joining Tracks . . . . . . . . . . 34
9.2.1. Stitched Tracks . . . . . . . . . . . . . . . . . . . 33 9.2.1. Stitched Tracks . . . . . . . . . . . . . . . . . . . 34
9.2.2. External routes . . . . . . . . . . . . . . . . . . . 35 9.2.2. External routes . . . . . . . . . . . . . . . . . . . 36
9.2.3. Segment Routing . . . . . . . . . . . . . . . . . . . 37 9.2.3. Segment Routing . . . . . . . . . . . . . . . . . . . 38
10. Security Considerations . . . . . . . . . . . . . . . . . . . 40 10. Security Considerations . . . . . . . . . . . . . . . . . . . 41
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
11.1. New Elective 6LoWPAN Routing Header Type . . . . . . . . 40 11.1. New Elective 6LoWPAN Routing Header Type . . . . . . . . 41
11.2. New Critical 6LoWPAN Routing Header Type . . . . . . . . 40 11.2. New Critical 6LoWPAN Routing Header Type . . . . . . . . 42
11.3. New Subregistry For The RPL Option Flags . . . . . . . . 41 11.3. New Subregistry For The RPL Option Flags . . . . . . . . 42
11.4. New RPL Control Codes . . . . . . . . . . . . . . . . . 41 11.4. New RPL Control Codes . . . . . . . . . . . . . . . . . 43
11.5. New RPL Control Message Options . . . . . . . . . . . . 42 11.5. New RPL Control Message Options . . . . . . . . . . . . 43
11.6. SubRegistry for the Projected DAO Request Flags . . . . 42 11.6. SubRegistry for the Projected DAO Request Flags . . . . 43
11.7. SubRegistry for the PDR-ACK Flags . . . . . . . . . . . 42 11.7. SubRegistry for the PDR-ACK Flags . . . . . . . . . . . 44
11.8. Subregistry for the PDR-ACK Acceptance Status Values . . 43 11.8. Subregistry for the PDR-ACK Acceptance Status Values . . 44
11.9. Subregistry for the PDR-ACK Rejection Status Values . . 43 11.9. Subregistry for the PDR-ACK Rejection Status Values . . 44
11.10. SubRegistry for the Via Information Options Flags . . . 44 11.10. SubRegistry for the Via Information Options Flags . . . 45
11.11. SubRegistry for the Sibling Information Option Flags . . 44 11.11. SubRegistry for the Sibling Information Option Flags . . 45
11.12. New Destination Advertisement Object Flag . . . . . . . 44 11.12. New Destination Advertisement Object Flag . . . . . . . 46
11.13. Error in Projected Route ICMPv6 Code . . . . . . . . . . 45 11.13. Error in Projected Route ICMPv6 Code . . . . . . . . . . 46
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46
13. Normative References . . . . . . . . . . . . . . . . . . . . 45 13. Normative References . . . . . . . . . . . . . . . . . . . . 46
14. Informative References . . . . . . . . . . . . . . . . . . . 46 14. Informative References . . . . . . . . . . . . . . . . . . . 47
Appendix A. Applications . . . . . . . . . . . . . . . . . . . . 48 Appendix A. Applications . . . . . . . . . . . . . . . . . . . . 49
A.1. Loose Source Routing . . . . . . . . . . . . . . . . . . 48 A.1. Loose Source Routing . . . . . . . . . . . . . . . . . . 49
A.2. Transversal Routes . . . . . . . . . . . . . . . . . . . 49 A.2. Transversal Routes . . . . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52
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 a generic Distance Vector protocol that is well suited for (LLNs), is a generic Distance Vector protocol that is well suited for
application in a variety of low energy Internet of Things (IoT) application in a variety of low energy Internet of Things (IoT)
networks. RPL forms Destination Oriented Directed Acyclic Graphs networks. RPL forms Destination Oriented Directed Acyclic Graphs
(DODAGs) in which the Root often acts as the Border Router to connect (DODAGs) in which the Root often acts as the Border Router to connect
the RPL domain to the Internet. The Root is responsible to select the RPL domain to the Internet. The Root is responsible to select
the RPL Instance that is used to forward a packet coming from the the RPL Instance that is used to forward a packet coming from the
skipping to change at page 6, line 20 skipping to change at page 6, line 20
TIO: RPL Transit Information Option TIO: RPL Transit Information Option
SF-VIO: A Via Information Option, used in Storing-Mode P-DAO SF-VIO: A Via Information Option, used in Storing-Mode P-DAO
messages. messages.
VIO: A Via Information Option; it can be a SF-VIO or an SR-VIO. VIO: A Via Information Option; it can be a SF-VIO or an SR-VIO.
2.3. Other Terms 2.3. Other Terms
Projected Route: A RPL Projected Route is a RPL route that is Projected Route: A RPL Projected Route is a RPL route that is
computed remotely by a PCE, and installed and maintained by a RPL computed remotely by a PCE, and installed and maintained by a RPL
Root on behalf of the PCE. Root on behalf of the PCE.
Segment: A strict sequence of node along which a route is installed.
With this specification, a Segment is installed by the Root of the
main DODAG using Storing-Mode P-DAO messages.
Projected DAO: A DAO message used to install a Projected Route. Projected DAO: A DAO message used to install a Projected Route.
Track: A DODAG that provides a complex path from or to a Root that Track: A DODAG that provides a complex path from or to a Root that
is the destination of the DODAG. The Root is the Track Ingress, is the destination of the DODAG. The Root is the Track Ingress,
and the forward direction for packets is down the DODAG, from the and the forward direction for packets is down the DODAG, from the
Track Ingress to one of the possibly multiple Track Egress Nodes. Track Ingress to one of the possibly multiple Track Egress Nodes.
The DODAG may be strictly connected, meaning that the vertices are
adjacent, or loosely connected, meaning that the vertices are
connected using Segments that are associated to the same Track.
With this specification, a Track is installed by the Root of the
main DODAG using Non-Storing-Mode P-DAO messages.
TrackID: A RPL Local InstanceID with the D bit set to 0. The TrackID: A RPL Local InstanceID with the D bit set to 0. The
TrackID is associated with the IPv6 Address of the Track Ingress TrackID is associated with the IPv6 Address of the Track Ingress
that is used to signal the DODAG Root. The owner of the namespace that is used to signal the DODAG Root, and together they form a
is the Track Ingress. unique identification of the Track (see the definition of DODAGID
in section 2 of [RPL].
2.4. References 2.4. References
In this document, readers will encounter terms and concepts that are In this document, readers will encounter terms and concepts that are
discussed in the "Routing Protocol for Low Power and Lossy Networks" discussed in the "Routing Protocol for Low Power and Lossy Networks"
[RPL] and "Terminology in Low power And Lossy Networks" [RFC7102]. [RPL] and "Terminology in Low power And Lossy Networks" [RFC7102].
3. Extending RFC 6550 3. Extending RFC 6550
3.1. Projected DAO 3.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). This specification extends the DAO Advertisement Object (DAO). This specification extends the DAO
message with the Projected DAO (P-DAO); a P-DAO message signals a message with the Projected DAO (P-DAO); a P-DAO message signals a
Projected Route to one or more Targets using the new CMOs presented Projected Route to one or more Targets using the new CMOs presented
therein. This specification enables to combine one or more Projected therein. This specification enables to combine one or more Projected
Routes into a DODAG called a Track, that is traversed to reach the Routes into a DODAG called a Track, that is traversed to reach the
skipping to change at page 8, line 12 skipping to change at page 8, line 24
are formed by the directed parent-child relationships. Options may are formed by the directed parent-child relationships. Options may
be factorized; multiple RTOs may be present to signal a collection of be factorized; multiple RTOs may be present to signal a collection of
children that can be reached via the parent(s) indicated in the children that can be reached via the parent(s) indicated in the
TIO(s) that follows the RTOs. This specification generalizes the TIO(s) that follows the RTOs. This specification generalizes the
case of a parent that can be used to reach a child with that of a case of a parent that can be used to reach a child with that of a
whole Track through which both children and siblings of the Track whole Track through which both children and siblings of the Track
Egress are reachable. Egress are reachable.
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. One VIO use in P-DAO messages as a multihop alternative to the TIO. One VIO
is the Stateful VIO(SF-VIO); the SF-VIO installs Storing-Mode is the Stateful VIO (SF-VIO); the SF-VIO installs Storing-Mode
Projected Route along a strict segment. The other is the Source- Projected Route along a strict segment. The other is the Source-
Routed VIO (SR-VIO); the SR-VIO installs a Non-Storing-Mode Projected Routed VIO (SR-VIO); the SR-VIO installs a Non-Storing-Mode Projected
Route at the Track Ingress, which uses that state to encapsulate a Route at the Track Ingress, which uses that state to encapsulate a
packet with a Routing Header (RH) to the Track Egress. packet with a Routing Header (RH) to the Track Egress.
Like in a DAO message, the RTOs can be factorized in a P-DAO, but the Like in a DAO message, the RTOs can be factorized in a P-DAO, but the
Via Information Options cannot. A P-DAO contains one or more RTOs Via Information Options cannot. A P-DAO contains one or more RTOs
that indicate the destinations that can be reached via the Track, and that indicate the destinations that can be reached via the Track, and
exactly one VIOthat signals a sequence of nodes. In Non-Storing exactly one VIO that signals a sequence of nodes. In Non-Storing
Mode, the Root sends the P-DAO to the Track Ingress where the source- Mode, the Root sends the P-DAO to the Track Ingress where the source-
routing state is stored. In Storing Mode, the P-DAO is sent to the routing state is stored. In Storing Mode, the P-DAO is sent to the
Track Egress and forwarded along the Segment in the reverse Track Egress and forwarded along the Segment in the reverse
direction, installing a Storing Mode state to the Track Egress at direction, installing a Storing Mode state to the Track Egress at
each hop. In both cases the Track Ingress is the owner of the Track, each hop. In both cases the Track Ingress is the owner of the Track,
and it generates the P-DAO-ACK when the installation is successful. and it generates the P-DAO-ACK when the installation is successful.
3.2. Sibling Information Option 3.2. Sibling Information Option
This specification adds another CMO called the Sibling Information This specification adds another CMO called the Sibling Information
skipping to change at page 13, line 10 skipping to change at page 13, line 25
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 27 and Table 28. setting of the 'E' flag, see Table 27 and Table 28.
Reserved: The Reserved field MUST initialized to zero by the sender Reserved: The Reserved field MUST initialized to zero by the sender
and MUST be ignored by the receiver and MUST be ignored by the receiver
6.3. Via Information Options 6.3. Via Information Options
An VIOsignals the ordered list of IPv6 Via Addresses that constitutes A VIO signals the ordered list of IPv6 Via Addresses that constitutes
the hops of either a Serial Track or a Segment of a more Complex the hops of either a Serial Track or a Segment of a more Complex
Track. An VIOMUST contain at least one Via Address, and a Via Track. A VIO MUST contain at least one Via Address, and a Via
Address MUST NOT be present more than once, otherwise the VIOMUST be Address MUST NOT be present more than once, otherwise the VIO MUST be
ignored. The format of the Via Information Options is as follows: ignored. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Option Length | Flags | SegmentID | | Type | Option Length | Flags | SegmentID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Segm. Sequence | Seg. Lifetime | SRH-6LoRH header | |Segm. Sequence | Seg. Lifetime | SRH-6LoRH header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 13, line 44 skipping to change at page 14, line 33
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
. . . .
. Via Address n . . Via Address n .
. . . .
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: VIOformat (uncompressed form) Figure 7: VIO format (uncompressed form)
Option Type: 0x0B for SF-VIO, 0x0C for SR-VIO (to be confirmed by Option Type: 0x0B for SF-VIO, 0x0C for SR-VIO (to be confirmed by
IANA) IANA)
Option Length: In bytes; variable, depending on the number of Via Option Length: In bytes; variable, depending on the number of Via
Addresses and the compression. Addresses and the compression.
SegmentID: 8-bit field that identifies a Segment within a Track or SegmentID: 8-bit field that identifies a Segment within a Track or
the main DODAG as indicated by the TrackID field. The value of 0 the main DODAG as indicated by the TrackID field. The value of 0
is used to signal a Serial Track, i.e., made of a single segment. is used to signal a Serial Track, i.e., made of a single segment.
Segment Sequence: 8-bit unsigned integer. The Segment Sequence Segment Sequence: 8-bit unsigned integer. The Segment Sequence
obeys the operation in section 7.2 of [RPL] and the lollipop obeys the operation in section 7.2 of [RPL] and the lollipop
starts at 255. starts at 255.
When the Root of the DODAG needs to refresh or update a Segment in When the Root of the DODAG needs to refresh or update a Segment in
a Track, it increments the Segment Sequence individually for that a Track, it increments the Segment Sequence individually for that
Segment. Segment.
The Segment information indicated in the VIOdeprecates any state The Segment information indicated in the VIO deprecates any state
for the Segment indicated by the SegmentID within the indicated for the Segment indicated by the SegmentID within the indicated
Track and sets up the new information. Track and sets up the new information.
An VIOwith a Segment Sequence that is not as fresh as the current A VIO with a Segment Sequence that is not as fresh as the current
one is ignored. one is ignored.
A VIO for a given DODAGID with the same (TrackID, SegmentID, A VIO for a given DODAGID with the same (TrackID, SegmentID,
Segment Sequence) indicates a retry; it MUST NOT change the Segment Sequence) indicates a retry; it MUST NOT change the
Segment and MUST be propagated or answered as the first copy. Segment and MUST be propagated or answered as the first copy.
Segment Lifetime: 8-bit unsigned integer. The length of time in Segment Lifetime: 8-bit unsigned integer. The length of time in
Lifetime Units (obtained from the Configuration option) that the Lifetime Units (obtained from the Configuration option) that the
Segment is usable. Segment is usable.
The period starts when a new Segment Sequence is seen. The value The period starts when a new Segment Sequence is seen. The value
of 255 (0xFF) represents infinity. The value of zero (0x00) of 255 (0xFF) represents infinity. The value of zero (0x00)
indicates a loss of reachability. indicates a loss of reachability.
A P-DAO message that contains a VIOwith a Segment Lifetime of zero A P-DAO message that contains a VIO with a Segment Lifetime of
is referred as a No-Path P-DAO in this document. zero is referred as a No-Path P-DAO in this document.
SRH-6LoRH header: The first 2 bytes of the (first) SRH-6LoRH as SRH-6LoRH header: The first 2 bytes of the (first) SRH-6LoRH as
shown in Figure 6 of [RFC8138]. A 6LoRH Type of 4 means that the shown in Figure 6 of [RFC8138]. A 6LoRH Type of 4 means that the
VIA Addresses are provided in full with no compression. VIA Addresses are provided in full with no compression.
Via Address: An IPv6 address along the Segment. Via Address: An IPv6 address along the Segment.
In a SF-VIO, the list is a strict path between direct neighbors, In a SF-VIO, the list is a strict path between direct neighbors,
from the Segment Ingress to Egress, both included. The router from the Segment Ingress to Egress, both included. The router
that processes an SF-VIO MAY create additional routing state that processes an SF-VIO MAY create additional routing state
towards the nodes after self via the node immediatelt after self towards the nodes after self via the node immediately after self
in the SF-VIO, but in case of memory shortage the routes to the in the SF-VIO, but in case of memory shortage the routes to the
Targets have precedence since they are the ones that the router Targets have precedence since they are the ones that the router
commits to store. commits to store.
In an SR-VIO, the list starts at the first hop and ends at a Track In an SR-VIO, the list includes the egress but not the ingress
Egress. In that case, the Track Egress MUST be considered as an node. It starts at the first hop and ends at a Track Egress. In
implicit Target, so it MUST NOT be listed it in a RPL Target that case, the Track Egress MUST be considered as an implicit
Option. The list in an SR-VIO may be loose, provided that each Target, so it MUST NOT be listed it in a RPL Target Option. The
listed node has a path to the next listed node, e.g., via a list in an SR-VIO may be loose, provided that each listed node has
segment or another Track. a path to the next listed node, e.g., via a segment or another
Track.
In the case of a SF-VIO, or if [RFC8138] is not used in the data In the case of a SF-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 for all the Information Option, and the compression is the same for all the
addresses, as shown in Figure 7. addresses, as shown in Figure 7.
In case of an SR-VIO, and if [RFC8138] is in use in the main In case of an SR-VIO, and if [RFC8138] is in use in the main
DODAG, then the Root SHOULD optimize the size of the SR-VIO; more DODAG, then the Root SHOULD optimize the size of the SR-VIO; more
than one SRH-6LoRH may be present, e.g., if the compression level than one SRH-6LoRH may be present, e.g., if the compression level
changes inside the Segment and different SRH-6LoRH Types are changes inside the Segment and different SRH-6LoRH Types are
skipping to change at page 17, line 44 skipping to change at page 18, line 16
that case the DAG Metric Container provides additional metrics for that case the DAG Metric Container provides additional metrics for
the hop from the Sibling to this node. the hop from the Sibling to this node.
7. Projected DAO 7. Projected DAO
This draft adds a capability to RPL whereby the Root of a main DODAG This draft adds a capability to RPL whereby the Root of a main DODAG
installs a Track as a collection of Projected Routes, using a installs a Track as a collection of Projected Routes, using a
Projected-DAO (P-DAO) message to maintain each individual route. The Projected-DAO (P-DAO) message to maintain each individual route. The
P-DAO signals a collection of Targets in the RPL Target Option(s) P-DAO signals a collection of Targets in the RPL Target Option(s)
(RTO). Those Targets can be reached via a sequence of routers (RTO). Those Targets can be reached via a sequence of routers
indicated in a VIO(VIO). A P-DAO message MUST contain exactly one indicated in a VIO. A P-DAO message MUST contain exactly one VIO,
VIO, which is either a SF-VIO or an SR-VIO, and MUST follow one or which is either a SF-VIO or an SR-VIO, and MUST follow one or more
more RTOs. There can be at most one such sequence of RTO(s) and an RTOs. There can be at most one such sequence of RTO(s) and an Via
Via Information Option. A track is indentified by a tupple DODAGID, Information Option. A track is identified by a tuple DODAGID,
TrackID and each route within a Track is indexed by a SegmentID. TrackID and each route within a Track is indexed by a SegmentID.
A P-DAO MUST be sent from the address of the Root that serves as A P-DAO MUST be sent from the address of the Root that serves as
DODAGID for the main DODAG. It MUST be sent to a GUA or a ULA of DODAGID for the main DODAG. It MUST be sent to a GUA or a ULA of
either the ingress or the egress of the Segment, more below. If the either the ingress or the egress of the Segment, more below. If the
'K' Flag is present in the P-DAO, and unless the P-DAO does not reach 'K' Flag is present in the P-DAO, and unless the P-DAO does not reach
it, the ingress of the Segment is the node that acknowledges the it, the ingress of the Segment is the node that acknowledges the
message, using a DAO-ACK that MUST be sent back to the address that message, using a DAO-ACK that MUST be sent back to the address that
serves as DODAGID for the main DODAG. serves as DODAGID for the main DODAG.
Like a classical DAO message, a P-DAO causes a change of state only Like a classical DAO message, a P-DAO causes a change of state only
if it is "new" per section 9.2.2. "Generation of DAO Messages" of if it is "new" per section 9.2.2. "Generation of DAO Messages" of
the RPL specification [RPL]; this is determined using the Segment the RPL specification [RPL]; this is determined using the Segment
Sequence information from the VIOas opposed to the Path Sequence from Sequence information from the VIO as opposed to the Path Sequence
a TIO. Also, a Segment Lifetime of 0 in an VIOindicates that the from a TIO. Also, a Segment Lifetime of 0 in a VIO indicates that
projected route associated to the Segment is to be removed. the projected route associated to the Segment is to be removed.
There are two kinds of operation for the Projected Routes, the There are two kinds of operation for the Projected Routes, the
Storing Mode and the Non-Storing Mode. Storing Mode and the Non-Storing Mode.
* The Non-Storing Mode is discussed in Section 7.3.2. A Non-Storing * The Non-Storing Mode is discussed in Section 7.3.2. A Non-Storing
Mode P-DAO carries an SR-VIO with the loose list of Via Addresses Mode P-DAO carries an SR-VIO with the loose list of Via Addresses
that forms a source-routed Segment to the Track Egress. The that forms a source-routed Segment to the Track Egress. The
recipient of the P-DAO is the Track Ingress; it MUST install a recipient of the P-DAO is the Track Ingress; it MUST install a
source-routed state to the Track Egress and reply to the Root source-routed state to the Track Egress and reply to the Root
directly using a DAO-ACK message if requested to. directly using a DAO-ACK message if requested to.
skipping to change at page 22, line 7 skipping to change at page 22, line 22
with the same DODAGID and Track ID. The Ingress of a Non-Storing with the same DODAGID and Track ID. The Ingress of a Non-Storing
Mode Projected Route must be the owner of the DODAGID. The Ingress Mode Projected Route must be the owner of the DODAGID. The Ingress
of a Storing Mode Projected Route must be either the owner of the of a Storing Mode Projected Route must be either the owner of the
DODAGID, or the egress of a preceding Storing Mode Projected Route in DODAGID, or the egress of a preceding Storing Mode Projected Route in
the same Track. In the latter case, the Targets of the Projected the same Track. In the latter case, the Targets of the Projected
Route must be Targets of the preceding Projected Route to ensure that Route must be Targets of the preceding Projected Route to ensure that
they are visible from the track Ingress. they are visible from the track Ingress.
7.3.1. Storing-Mode P-Route 7.3.1. Storing-Mode P-Route
Profile 1 extends RPL opertation in a Non-Storing Mode network with Profile 1 extends RPL operation in a Non-Storing Mode network with
Storing-Mode Projected Routes that install segments along the main Storing-Mode Projected Routes that install segments along the main
DODAG and enable to loose source routing between the Root and the DODAG and enable to loose source routing between the Root and the
targets. targets.
7.3.1.1. Installing a Storing-Mode P-Route
As illustrated in Figure 9, a P-DAO that carries a SF-VIO enables the As illustrated in Figure 9, a P-DAO that carries a SF-VIO enables the
Root to install a stateful route towards a collection of Targets Root to install a stateful route towards a collection of Targets
along a Segment between a Track Ingress and a Track Egress. along a Segment between a Track Ingress and a Track Egress using a
projected DAO Message.
------+--------- ------+---------
| Internet | Internet
| |
+-----+ +-----+
| | Border Router | | Border Router
| | (RPL Root) | | (RPL Root)
+-----+ | ^ | +-----+ | ^ |
| | DAO | ACK | | | DAO | ACK |
o o o o | | | o o o o | | |
skipping to change at page 23, line 37 skipping to change at page 23, line 51
Addresses that are the SF-VIO after the next one, if any, but in case Addresses that are the SF-VIO after the next one, if any, but in case
of a conflict or a lack of resource, the route(s) to the Target(s) of a conflict or a lack of resource, the route(s) to the Target(s)
have precedence. have precedence.
If a router cannot reach its predecessor in the SF-VIO, the router If a router cannot reach its predecessor in the SF-VIO, the router
MUST answer to the Root with a negative DAO-ACK indicating the MUST answer to the Root with a negative DAO-ACK indicating the
successor that is unreachable (suggested status 11 to be confirmed by successor that is unreachable (suggested status 11 to be confirmed by
IANA). IANA).
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. 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
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
with the same TID, or tear down the route.
A Segment Lifetime of 0 in a VIOis used to clean up the state. The 7.3.1.2. Maintaining and Tearing Down a Storing-Mode P-Route
A Segment Lifetime of 0 in a VIO is used to clean up the state. The
P-DAO is forwarded as described above, but the DAO is interpreted as P-DAO is forwarded as described above, but the DAO is interpreted as
a No-Path DAO and results in cleaning up existing state as opposed to a No-Path DAO and results in cleaning up existing state as opposed to
refreshing an existing one or installing a new one. refreshing an existing one or installing a new one.
Note that the continuity of the segment may be broken; this happens
if the bidirectional connectivity between contiguous hops of the
segment is lost. In that case the Root needs to send the projected
DAO to one or more intermediate node(s) as opposed to the egress
node, indicating a portion of segment that is being replaced or
cleaned up. At the extreme, the P-DAO updates only one node, in
which case it contains only one VIO.
In case of a forwarding error along an Storing-Mode P-Route, the node In case of a forwarding error along an Storing-Mode P-Route, the node
that fails to forward SHOULD send an ICMP error with a code "Error in that fails to forward SHOULD send an ICMP error with a code "Error in
Projected Route" to the Root. Failure to do so may result in packet Projected Route" to the Root. Failure to do so may result in packet
loss and wasted resources along the Projected Route that is broken. loss and wasted resources along the Projected Route that is broken.
7.3.2. Non-Storing-Mode P-Route 7.3.2. Non-Storing-Mode P-Route
As illustrated in Figure 10, a P-DAO that carries an SR-VIO enables As illustrated in Figure 10, a P-DAO that carries an SR-VIO enables
the Root to install a source-routed path from a Track Ingress towards the Root to install a source-routed path from a Track Ingress towards
a Target along the main DODAG. a Target along the main DODAG.
skipping to change at page 40, line 7 skipping to change at page 41, line 7
* From the SRH: C consumes the SRH and makes the destination E. * From the SRH: C consumes the SRH and makes the destination E.
* From P-DAO 1: C encapsulates the packet with destination of E in * From P-DAO 1: C encapsulates the packet with destination of E in
the Track signaled by P-DAO 1. The outer header has source C, the Track signaled by P-DAO 1. The outer header has source C,
destination D, an SRH that indicates E as the next loose hop, and destination D, an SRH that indicates E as the next loose hop, and
a RPI indicating a TrackId of 131 from C's namespace. E a RPI indicating a TrackId of 131 from C's namespace. E
decapsulates. decapsulates.
10. Security Considerations 10. Security Considerations
This draft uses messages that are already present in RPL [RPL] with It is worth noting that with [RPL], every node in the LLN is RPL-
optional secured versions. The same secured versions may be used aware and can inject any RPL-based attack in the network. This draft
with this draft, and whatever security is deployed for a given uses messages that are already present in RPL [RPL] with optional
network also applies to the flows in this draft. secured versions. The same secured versions may be used with this
draft, and whatever security is deployed for a given network also
applies to the flows in this draft.
TODO: should probably consider how P-DAO messages could be abused by The LLN nodes depend on the 6LBR and the RPL participants for their
a) rogue nodes b) via replay of messages c) if use of P-DAO messages operation. A trust model must be put in place to ensure that the
could in fact deal with any threats? right devices are acting in these roles, so as to avoid threats such
as black-holing, (see [RFC7416] section 7). This trust model could
be 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
Appendix B.5 of [RFC8505].
In a general manner, the Security Considerations in [RPL], and
[RFC7416] apply to this specification as well. The Link-Layer
security is needed in particular to prevent Denial-Of-Service attacks
whereby a rogue router creates a high churn in the RPL network by
constantly injected forged P-DAO messages and using up all the
available storage in the attacked routers.
Additionally, the trust model could include a role validation (e.g.,
using a role-based authorization) to ensure that the node that claims
to be a RPL Root is entitled to do so. That trust should propagate
from egress to ingress in the case of a Storing Mode P-DAO.
11. IANA Considerations 11. IANA Considerations
11.1. New Elective 6LoWPAN Routing Header Type 11.1. New Elective 6LoWPAN Routing Header Type
This document updates the IANA registry titled "Elective 6LoWPAN This document updates the IANA registry titled "Elective 6LoWPAN
Routing Header Type" that was created for [RFC8138] and assigns the Routing Header Type" that was created for [RFC8138] and assigns the
following value: following value:
+=======+=============+===============+ +=======+=============+===============+
skipping to change at page 42, line 13 skipping to change at page 43, line 28
Table 24: New RPL Control Codes Table 24: New RPL Control Codes
11.5. New RPL Control Message Options 11.5. New RPL Control Message Options
This document extends the IANA Subregistry created by RFC 6550 for This document extends the IANA Subregistry created by RFC 6550 for
RPL Control Message Options as indicated in Table 25: RPL Control Message Options as indicated in Table 25:
+=======+============================+===============+ +=======+============================+===============+
| Value | Meaning | Reference | | Value | Meaning | Reference |
+=======+============================+===============+ +=======+============================+===============+
| 0x0B | Stateful VIO(SF-VIO) | This document | | 0x0B | Stateful VIO (SF-VIO) | This document |
+-------+----------------------------+---------------+ +-------+----------------------------+---------------+
| 0x0C | Source-Routed VIO(SR-VIO) | This document | | 0x0C | Source-Routed VIO (SR-VIO) | This document |
+-------+----------------------------+---------------+ +-------+----------------------------+---------------+
| 0x0D | Sibling Information option | This document | | 0x0D | Sibling Information option | This document |
+-------+----------------------------+---------------+ +-------+----------------------------+---------------+
Table 25: RPL Control Message Options Table 25: RPL Control Message Options
11.6. SubRegistry for the Projected DAO Request Flags 11.6. SubRegistry for the Projected DAO Request Flags
IANA is required to create a registry for the 8-bit Projected DAO IANA is required to create a registry for the 8-bit Projected DAO
Request (PDR) Flags field. Each bit is tracked with the following Request (PDR) Flags field. Each bit is tracked with the following
skipping to change at page 46, line 45 skipping to change at page 48, line 15
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
2014, <https://www.rfc-editor.org/info/rfc7102>. 2014, <https://www.rfc-editor.org/info/rfc7102>.
[RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and
J. Martocci, "Reactive Discovery of Point-to-Point Routes J. Martocci, "Reactive Discovery of Point-to-Point Routes
in Low-Power and Lossy Networks", RFC 6997, in Low-Power and Lossy Networks", RFC 6997,
DOI 10.17487/RFC6997, August 2013, DOI 10.17487/RFC6997, August 2013,
<https://www.rfc-editor.org/info/rfc6997>. <https://www.rfc-editor.org/info/rfc6997>.
[RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A.,
and M. Richardson, Ed., "A Security Threat Analysis for
the Routing Protocol for Low-Power and Lossy Networks
(RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015,
<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 R. Buddenberg, Thubert, P., Papadopoulos, G. Z., and R. Buddenberg,
"Reliable and Available Wireless Architecture/Framework", "Reliable and Available Wireless Architecture/Framework",
Work in Progress, Internet-Draft, draft-pthubert-raw- Work in Progress, Internet-Draft, draft-pthubert-raw-
architecture-05, 15 November 2020, architecture-05, 15 November 2020,
<https://tools.ietf.org/html/draft-pthubert-raw- <https://datatracker.ietf.org/doc/html/draft-pthubert-raw-
architecture-05>. architecture-05>.
[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-
Power and Lossy Networks (RPL) Destination-Oriented Power and Lossy Networks (RPL) Destination-Oriented
Directed Acyclic Graph (DODAG) Configuration Option for Directed Acyclic Graph (DODAG) Configuration Option for
the 6LoWPAN Routing Header", RFC 9035, the 6LoWPAN Routing Header", RFC 9035,
DOI 10.17487/RFC9035, April 2021, DOI 10.17487/RFC9035, April 2021,
<https://www.rfc-editor.org/info/rfc9035>. <https://www.rfc-editor.org/info/rfc9035>.
 End of changes. 38 change blocks. 
84 lines changed or deleted 134 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/