< draft-ietf-roll-dao-projection-20.txt   draft-ietf-roll-dao-projection-21.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: 25 March 2022 Huawei Tech Expires: 31 March 2022 Huawei Tech
M. Gillmore M. Gillmore
Itron Itron
21 September 2021 27 September 2021
Root initiated routing state in RPL Root initiated routing state in RPL
draft-ietf-roll-dao-projection-20 draft-ietf-roll-dao-projection-21
Abstract Abstract
This document extends RFC 6550, RFC 6553,and RFC 8138 to enable a RPL This document extends RFC 6550, RFC 6553,and RFC 8138 to enable a RPL
Root to install and maintain Projected Routes within its DODAG, along 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 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 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 25 March 2022. This Internet-Draft will expire on 31 March 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 22 skipping to change at page 2, line 22
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2.2. References . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. References . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4. Domain Terms . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Domain Terms . . . . . . . . . . . . . . . . . . . . . . 5
3. Context and Goal . . . . . . . . . . . . . . . . . . . . . . 6 3. Context and Goal . . . . . . . . . . . . . . . . . . . . . . 6
3.1. RPL Applicability . . . . . . . . . . . . . . . . . . . . 7 3.1. RPL Applicability . . . . . . . . . . . . . . . . . . . . 7
3.2. RPL Routing Modes . . . . . . . . . . . . . . . . . . . . 8 3.2. RPL Routing Modes . . . . . . . . . . . . . . . . . . . . 8
3.3. On Tracks . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Requirements . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Serial Track Signaling . . . . . . . . . . . . . . . . . 10 3.3.1. Loose Source Routing . . . . . . . . . . . . . . . . 9
3.4.1. Using Storing Mode Segments . . . . . . . . . . . . . 11 3.3.2. East-West Routes . . . . . . . . . . . . . . . . . . 10
3.4.2. Using Non-Storing Mode joining Tracks . . . . . . . . 17 3.4. On Tracks . . . . . . . . . . . . . . . . . . . . . . . . 12
3.5. Complex Tracks . . . . . . . . . . . . . . . . . . . . . 24 3.5. Serial Track Signaling . . . . . . . . . . . . . . . . . 13
3.6. Scope and Expectations . . . . . . . . . . . . . . . . . 26 3.5.1. Using Storing Mode Segments . . . . . . . . . . . . . 14
4. Extending existing RFCs . . . . . . . . . . . . . . . . . . . 28 3.5.2. Using Non-Storing Mode joining Tracks . . . . . . . . 20
4.1. Extending RFC 6550 . . . . . . . . . . . . . . . . . . . 28 3.6. Complex Tracks . . . . . . . . . . . . . . . . . . . . . 27
4.1.1. Projected DAO . . . . . . . . . . . . . . . . . . . . 28 3.7. Scope and Expectations . . . . . . . . . . . . . . . . . 29
4.1.2. Via Information Option . . . . . . . . . . . . . . . 30 4. Extending existing RFCs . . . . . . . . . . . . . . . . . . . 31
4.1.3. Sibling Information Option . . . . . . . . . . . . . 30 4.1. Extending RFC 6550 . . . . . . . . . . . . . . . . . . . 31
4.1.4. P-DAO Request . . . . . . . . . . . . . . . . . . . . 30 4.1.1. Projected DAO . . . . . . . . . . . . . . . . . . . . 31
4.1.5. Extending the RPI . . . . . . . . . . . . . . . . . . 30 4.1.2. Via Information Option . . . . . . . . . . . . . . . 33
4.2. Extending RFC 6553 . . . . . . . . . . . . . . . . . . . 31 4.1.3. Sibling Information Option . . . . . . . . . . . . . 33
4.3. Extending RFC 8138 . . . . . . . . . . . . . . . . . . . 32 4.1.4. P-DAO Request . . . . . . . . . . . . . . . . . . . . 33
5. New RPL Control Messages and Options . . . . . . . . . . . . 33 4.1.5. Extending the RPI . . . . . . . . . . . . . . . . . . 33
5.1. New P-DAO Request Control Message . . . . . . . . . . . . 33 4.2. Extending RFC 6553 . . . . . . . . . . . . . . . . . . . 34
5.2. New PDR-ACK Control Message . . . . . . . . . . . . . . . 34 4.3. Extending RFC 8138 . . . . . . . . . . . . . . . . . . . 35
5.3. Via Information Options . . . . . . . . . . . . . . . . . 36 5. New RPL Control Messages and Options . . . . . . . . . . . . 36
5.4. Sibling Information Option . . . . . . . . . . . . . . . 39 5.1. New P-DAO Request Control Message . . . . . . . . . . . . 36
6. Root Initiated Routing State . . . . . . . . . . . . . . . . 41 5.2. New PDR-ACK Control Message . . . . . . . . . . . . . . . 37
6.1. Requesting a Track . . . . . . . . . . . . . . . . . . . 41 5.3. Via Information Options . . . . . . . . . . . . . . . . . 39
6.2. Identifying a Track . . . . . . . . . . . . . . . . . . . 42 5.4. Sibling Information Option . . . . . . . . . . . . . . . 42
6.3. Installing a Track . . . . . . . . . . . . . . . . . . . 43 6. Root Initiated Routing State . . . . . . . . . . . . . . . . 44
6.3.1. Signaling a Projected Route . . . . . . . . . . . . . 44 6.1. Requesting a Track . . . . . . . . . . . . . . . . . . . 44
6.2. Identifying a Track . . . . . . . . . . . . . . . . . . . 45
6.3. Installing a Track . . . . . . . . . . . . . . . . . . . 46
6.3.1. Signaling a Projected Route . . . . . . . . . . . . . 47
6.3.2. Installing a Track Segment with a Storing Mode 6.3.2. Installing a Track Segment with a Storing Mode
P-Route . . . . . . . . . . . . . . . . . . . . . . . 45 P-Route . . . . . . . . . . . . . . . . . . . . . . . 48
6.3.3. Installing a Track Leg with a Non-Storing Mode 6.3.3. Installing a Track Leg with a Non-Storing Mode
P-Route . . . . . . . . . . . . . . . . . . . . . . . 47 P-Route . . . . . . . . . . . . . . . . . . . . . . . 50
6.4. Tearing Down a P-Route . . . . . . . . . . . . . . . . . 49 6.4. Tearing Down a P-Route . . . . . . . . . . . . . . . . . 52
6.5. Maintaining a Track . . . . . . . . . . . . . . . . . . . 49 6.5. Maintaining a Track . . . . . . . . . . . . . . . . . . . 52
6.5.1. Maintaining a Track Segment . . . . . . . . . . . . . 50 6.5.1. Maintaining a Track Segment . . . . . . . . . . . . . 53
6.5.2. Maintaining a Track Leg . . . . . . . . . . . . . . . 50 6.5.2. Maintaining a Track Leg . . . . . . . . . . . . . . . 53
6.6. Encapsulating and Forwarding Along a Track . . . . . . . 51 6.6. Encapsulating and Forwarding Along a Track . . . . . . . 54
6.7. Compression of the RPL Artifacts . . . . . . . . . . . . 53 6.7. Compression of the RPL Artifacts . . . . . . . . . . . . 56
7. Lesser Constrained Variations . . . . . . . . . . . . . . . . 55 7. Lesser Constrained Variations . . . . . . . . . . . . . . . . 58
7.1. Storing Mode Main DODAG . . . . . . . . . . . . . . . . . 55 7.1. Storing Mode Main DODAG . . . . . . . . . . . . . . . . . 58
7.2. A Track as a Full DODAG . . . . . . . . . . . . . . . . . 57 7.2. A Track as a Full DODAG . . . . . . . . . . . . . . . . . 60
8. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 58 8. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 61
9. Security Considerations . . . . . . . . . . . . . . . . . . . 60 9. Security Considerations . . . . . . . . . . . . . . . . . . . 63
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63
10.1. New Elective 6LoWPAN Routing Header Type . . . . . . . . 61 10.1. New Elective 6LoWPAN Routing Header Type . . . . . . . . 64
10.2. New Critical 6LoWPAN Routing Header Type . . . . . . . . 61 10.2. New Critical 6LoWPAN Routing Header Type . . . . . . . . 64
10.3. New Subregistry For The RPL Option Flags . . . . . . . . 61 10.3. New Subregistry For The RPL Option Flags . . . . . . . . 64
10.4. New RPL Control Codes . . . . . . . . . . . . . . . . . 62 10.4. New RPL Control Codes . . . . . . . . . . . . . . . . . 65
10.5. New RPL Control Message Options . . . . . . . . . . . . 62 10.5. New RPL Control Message Options . . . . . . . . . . . . 65
10.6. SubRegistry for the Projected DAO Request Flags . . . . 63 10.6. SubRegistry for the Projected DAO Request Flags . . . . 66
10.7. SubRegistry for the PDR-ACK Flags . . . . . . . . . . . 63 10.7. SubRegistry for the PDR-ACK Flags . . . . . . . . . . . 66
10.8. Subregistry for the PDR-ACK Acceptance Status Values . . 63 10.8. Subregistry for the PDR-ACK Acceptance Status Values . . 66
10.9. Subregistry for the PDR-ACK Rejection Status Values . . 64 10.9. Subregistry for the PDR-ACK Rejection Status Values . . 67
10.10. SubRegistry for the Via Information Options Flags . . . 64 10.10. SubRegistry for the Via Information Options Flags . . . 67
10.11. SubRegistry for the Sibling Information Option Flags . . 65 10.11. SubRegistry for the Sibling Information Option Flags . . 68
10.12. New destination Advertisement Object Flag . . . . . . . 65 10.12. New destination Advertisement Object Flag . . . . . . . 68
10.13. New ICMPv6 Error Code . . . . . . . . . . . . . . . . . 65 10.13. New ICMPv6 Error Code . . . . . . . . . . . . . . . . . 68
10.14. New RPL Rejection Status values . . . . . . . . . . . . 66 10.14. New RPL Rejection Status values . . . . . . . . . . . . 69
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 66 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 69
12. Normative References . . . . . . . . . . . . . . . . . . . . 66 12. Normative References . . . . . . . . . . . . . . . . . . . . 69
13. Informative References . . . . . . . . . . . . . . . . . . . 68 13. Informative References . . . . . . . . . . . . . . . . . . . 71
Appendix A. Applications . . . . . . . . . . . . . . . . . . . . 70
A.1. Loose Source Routing . . . . . . . . . . . . . . . . . . 70
A.2. East-West Routes . . . . . . . . . . . . . . . . . . . . 72
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73
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 5, line 18 skipping to change at page 5, line 18
RAN: RPL-Aware Node (either a RPL router or a RPL-Aware Leaf) RAN: RPL-Aware Node (either a RPL router or a RPL-Aware Leaf)
RAL: RPL-Aware Leaf RAL: RPL-Aware Leaf
RH: Routing Header RH: Routing Header
RPI: RPL Packet Information RPI: RPL Packet Information
RTO: RPL Target Option RTO: RPL Target Option
RUL: RPL-Unaware Leaf RUL: RPL-Unaware Leaf
SIO: RPL Sibling Information Option SIO: RPL Sibling Information Option
ULA: IPv6 Unique Local Address ULA: IPv6 Unique Local Address
NSM-VIO: A Source-Routed Via Information Option, used in Non-Storing NSM-VIO: A Source-Routed Via Information Option, used in Non-Storing
Mode P-DAO messages. Mode P-DAO messages.
SLO: Service Level Objective
TIO: RPL Transit Information Option TIO: RPL Transit Information Option
SM-VIO: A strict Via Information Option, used in Storing Mode P-DAO SM-VIO: A strict Via Information Option, used in Storing Mode P-DAO
messages. messages.
VIO: A Via Information Option; it can be a SM-VIO or an NSM-VIO. VIO: A Via Information Option; it can be a SM-VIO or an NSM-VIO.
2.4. Domain Terms 2.4. Domain Terms
Projected Route: A RPL P-Route is a RPL route that is computed Projected Route: A RPL P-Route is a RPL route that is computed
remotely by a PCE, and installed and maintained by a RPL Root on remotely by a PCE, and installed and maintained by a RPL Root on
behalf of the PCE. It is installed as a state that signals that behalf of the PCE. It is installed as a state that signals that
skipping to change at page 9, line 5 skipping to change at page 9, line 5
the term P-Route to refer to those routes. the term P-Route to refer to those routes.
A P-Route may be installed in either Storing and Non-Storing Mode, A P-Route may be installed in either Storing and Non-Storing Mode,
potentially resulting in hybrid situations where the Mode of the P- potentially resulting in hybrid situations where the Mode of the P-
Route is different from that of the RPL Main DODAG. P-Routes can be Route is different from that of the RPL Main DODAG. P-Routes can be
used as stand-alone segments to reduce the size of the source routing used as stand-alone segments to reduce the size of the source routing
headers with loose source routing operations down the main RPL DODAG. headers with loose source routing operations down the main RPL DODAG.
P-Routes can also be combined with other P-Routes to form a more P-Routes can also be combined with other P-Routes to form a more
complex forwarding graph called a Track. complex forwarding graph called a Track.
3.3. On Tracks 3.3. Requirements
3.3.1. Loose Source Routing
A RPL implementation operating in a very constrained LLN typically
uses the Non-Storing Mode of Operation as represented in Figure 1.
In that mode, a RPL node indicates a parent-child relationship to the
Root, using a destination Advertisement Object (DAO) that is unicast
from the node directly to the Root, and the Root typically builds a
source routed path to a destination down the DODAG by recursively
concatenating this information.
+-----+
| | Border router
| | (RPL Root)
+-----+ ^ | |
| | DAO | ACK |
o o o o | | | Strict
o o o o o o o o o | | | Source
o o o o o o o o o o | | | Route
o o o o o o o o o | | |
o o o o o o o o | v v
o o o o
LLN
Figure 1: RPL Non-Storing Mode of operation
Based on the parent-children relationships expressed in the Non-
Storing DAO messages,the Root possesses topological information about
the whole network, though this information is limited to the
structure of the DODAG for which it is the destination. A packet
that is generated within the domain will always reach the Root, which
can then apply a source routing information to reach the destination
if the destination is also in the DODAG. Similarly, a packet coming
from the outside of the domain for a destination that is expected to
be in a RPL domain reaches the Root.
It results that the Root, or then some associated centralized
computation engine such as a PCE, can determine the amount of packets
that reach a destination in the RPL domain, and thus the amount of
energy and bandwidth that is wasted for transmission, between itself
and the destination, as well as the risk of fragmentation, any
potential delays because of a paths longer than necessary (shorter
paths exist that would not traverse the Root).
As a network gets deep, the size of the source routing header that
the Root must add to all the downward packets becomes an issue for
nodes that are many hops away. In some use cases, a RPL network
forms long lines and a limited amount of well-targeted routing state
would allow to make the source routing operation loose as opposed to
strict, and save packet size. Limiting the packet size is directly
beneficial to the energy budget, but, mostly, it reduces the chances
of frame loss and/or packet fragmentation, which is highly
detrimental to the LLN operation. Because the capability to store a
routing state in every node is limited, the decision of which route
is installed where can only be optimized with a global knowledge of
the system, a knowledge that the Root or an associated PCE may
possess by means that are outside of the scope of this specification.
This requirement is to store a routing state associated with the Main
DODAG in selected RPL routers, to limit the excursion of the source
route headers in deep networks. The Root may elide the sequence of
routers that is installed in the network from its source route
header, which becomes loose while it is strict in [RPL].
3.3.2. East-West Routes
RPL is optimized for INternet access, with Point-to-Multipoint (P2MP)
and Multipoint-to-Point (MP2P), whereby routes are always installed
North-South (aka up/down) along the RPL DODAG respectively from and
towards the Border Router that also serves as DODAG Root. Peer to
Peer (P2P) East-West routes in a RPL network will generally suffer
from some elongated (stretched) path versus a direct (optimized)
path, since routing between two nodes always happens via a common
parent, as illustrated in Figure 2:
------+---------
| Internet
+-----+
| | Border router
| | (RPL Root)
+-----+
X
^ v o o
^ o o v o o o o o
^ o o o v o o o o o
^ o o v o o o o o
S o o o D o o o
o o o o
LLN
Figure 2: Routing Stretch between S and D via common parent X
along North-South Paths
The amount of stretch depends on the Mode of Operation:
* in Non-Storing Mode, all packets routed within the DODAG flow all
the way up to the Root of the DODAG. If the destination is in the
same DODAG, the Root must encapsulate the packet to place an RH
that has the strict source route information down the DODAG to the
destination. This will be the case even if the destination is
relatively close to the source and the Root is relatively far off.
* In Storing Mode, unless the destination is a child of the source,
the packets will follow the default route up the DODAG as well.
If the destination is in the same DODAG, they will eventually
reach a common parent that has a route to the destination; at
worse, the common parent may also be the Root. From that common
parent, the packet will follow a path down the DODAG that is
optimized for the Objective Function that was used to build the
DODAG.
It results that it is often beneficial to enable East-West P2P
routes, either if the RPL route presents a stretch from shortest
path, or if the new route is engineered with a different objective,
and that it is even more critical in Non-Storing Mode than it is in
Storing Mode, because the routing stretch is wider. For that reason,
earlier work at the IETF introduced the "Reactive Discovery of
Point-to-Point Routes in Low Power and Lossy Networks" [RFC6997],
which specifies a distributed method for establishing optimized P2P
routes. This draft proposes an alternate based on a centralized
route computation.
+-----+
| | Border router
| | (RPL Root)
+-----+
|
o o o o
o o o o o o o o o
o o o o o o o o o o
o o o o o o o o o
S>>A>>>B>>C>>>D o o o
o o o o
LLN
Figure 3: More direct East-West Route between S and D
The requirement is to install additional routes in the RPL routers,
to reduce the stretch of some P2P routes and maintain the
characteristics within a given SLO, e.g., in terms of latency and/or
reliability.
3.4. On Tracks
A Track is typically a collection of parallel loose source routed A Track is typically a collection of parallel loose source routed
sequences of nodes from Ingress to Egress, forming so-called Track sequences of nodes from Ingress to Egress, forming so-called Track
Legs, that are joined with strict Segments of other nodes. The Legs Legs, that are joined with strict Segments of other nodes. The Legs
are expressed in RPL Non-Storing Modes and require an encapsulation are expressed in RPL Non-Storing Modes and require an encapsulation
to add a Source Route Header, whereas the Segments are expressed in to add a Source Route Header, whereas the Segments are expressed in
Storing Mode. Storing Mode.
A Serial Track comprises provides only one path between Ingress and A Serial Track comprises provides only one path between Ingress and
Egress. It comprises at most one Leg. A Stand-Alone Segment defines Egress. It comprises at most one Leg. A Stand-Alone Segment defines
skipping to change at page 10, line 5 skipping to change at page 13, line 5
A Track is normally associated with a Local RPL Instance which A Track is normally associated with a Local RPL Instance which
RPLInstanceID is used as the TrackID, more in Section 6.2. A Track RPLInstanceID is used as the TrackID, more in Section 6.2. A Track
Leg may also be used as a subTrack that extends the RPL main DODAG. Leg may also be used as a subTrack that extends the RPL main DODAG.
In that case, the TrackID is set to the global RPLInstanceID of the In that case, the TrackID is set to the global RPLInstanceID of the
main DODAG, which suffices to identify the routing topology. As main DODAG, which suffices to identify the routing topology. As
opposed to local RPL instances, the Track Ingress that encapsulates opposed to local RPL instances, the Track Ingress that encapsulates
the packets over a subtrack is not Root, and that the source address the packets over a subtrack is not Root, and that the source address
of the encapsulated packet is not used to determine the Track. of the encapsulated packet is not used to determine the Track.
3.5. Serial Track Signaling
This specification enables to set up a P-Route along either a Track
Leg or a Segment. A P-Route is installed and maintained using an
extended RPL DAO message called a Projected DAO (P-DAO), and a Track
is composed of the combination of one or more P-Routes.
A P-DAO message for a Track signals the TrackID in the RPLInstanceID A P-DAO message for a Track signals the TrackID in the RPLInstanceID
field. In the case of a local RPL Instance, the address of the Track field. In the case of a local RPL Instance, the address of the Track
Ingress to be used as source to encapsulated packets along the Track Ingress is used as source to encapsulated packets along the Track is
is signaled in the DODAGID field of the Projected DAO Base Object; signaled in the DODAGID field of the Projected DAO Base Object, see
that field is elided in the case of the RPL Main DODAG, see Figure 3. Figure 6.
3.4. Serial Track Signaling
This specification introduces the concept of a P-Route along either a This specification introduces the Via Information Option (VIO) to
Track Leg or a Segment. A P-Route is installed and maintained using signal a sequence of hops in a Leg or a Segment in the P-DAO
an extended RPL DAO message called a Projected DAO (P-DAO), and a messages, either in Storing Mode (SM-VIO) or NON-Storing Mode (NSM-
Track is composed of the combination of one or more P-Routes. This VIO). One P-DAO messages contains a single VIO, associated to one or
specification introduces the Via Information Option (VIO) to signal a more RPL Target Options that signal the destination IPv6 addresses
sequence of hops in a Leg or a Segment in the P-DAO messages, either that can reached along the Track, more in Section 5.3.
in Storing Mode (SM-VIO) or NON-Storing Mode (NSM-VIO). One P-DAO
messages contains a single VIO, associated to one or more RPL Target
Options that signal the destination IPv6 addresses that can reached
along the Track.
Before diving deeper into Track Legs and Segments signaling and Before diving deeper into Track Legs and Segments signaling and
operation, this section provides examples of what how route operation, this section provides examples of what how route
projection works through variations of a simple example. In this projection works through variations of a simple example. This simple
simple example we show host routes though RPL Targets can be example illustrates the case of host routes, though RPL Targets can
prefixes. Say we want to build a Serial Track from node A to E in be prefixes.
Figure 1, so A can route packets to E's neighbors F and G along A, B,
C, D and E as opposed to via the Root: Say we want to build a Serial Track from node A to E in Figure 4, so
A can route packets to E's neighbors F and G along A, B, C, D and E
as opposed to via the Root:
/===> F /===> F
A ===> B ===> C ===> D===> E < A ===> B ===> C ===> D===> E <
\===> G \===> G
Figure 1: Reference Track Figure 4: Reference Track
Conventionally we use ==> to represent a strict hop and --> for a Conventionally we use ==> to represent a strict hop and --> for a
loose hop. We use -to- like in C==>D==>E-to-F to represent coma- loose hop. We use -to- like in C==>D==>E-to-F to represent coma-
separated Targets, e.g., F is a Target for Segment C==>D==>E. In separated Targets, e.g., F is a Target for Segment C==>D==>E. In
this example, A is Track Ingress, E is Track Egress. C is a this example, A is Track Ingress, E is Track Egress. C is a
stitching point. F and G are "external" Targets for the Track, and stitching point. F and G are "external" Targets for the Track, and
become reachable from A via the Track A(ingress) to E (Egress and become reachable from A via the Track A(ingress) to E (Egress and
implicit Target in Non-Storing Mode) leading to F and G (explicit implicit Target in Non-Storing Mode) leading to F and G (explicit
Targets). Targets).
skipping to change at page 11, line 4 skipping to change at page 14, line 8
stitching point. F and G are "external" Targets for the Track, and stitching point. F and G are "external" Targets for the Track, and
become reachable from A via the Track A(ingress) to E (Egress and become reachable from A via the Track A(ingress) to E (Egress and
implicit Target in Non-Storing Mode) leading to F and G (explicit implicit Target in Non-Storing Mode) leading to F and G (explicit
Targets). Targets).
In a general manner the desired outcome is as follows: In a general manner the desired outcome is as follows:
* Targets are E, F, and G * Targets are E, F, and G
* P-DAO 1 signals C==>D==>E * P-DAO 1 signals C==>D==>E
* P-DAO 2 signals A==>B==>C * P-DAO 2 signals A==>B==>C
* P-DAO 3 signals F and G via the A-->E Track * P-DAO 3 signals F and G via the A-->E Track
P-DAO 3 may be ommitted if P-DAO 1 and 2 signal F and G as Targets. P-DAO 3 may be ommitted if P-DAO 1 and 2 signal F and G as Targets.
Loose sequences of hops must be expressed in Non-Storing Mode, so Loose sequences of hops must be expressed in Non-Storing Mode, so
P-DAO 3 contains a NSM-VIO. With this specification, the DODAGID to P-DAO 3 contains a NSM-VIO. With this specification, the DODAGID to
be used by the Ingress as source address is signaled if needed in the be used by the Ingress as source address is signaled if needed in the
DAO base object, the via list starts at the first loose hop and DAO base object, the via list starts at the first loose hop and
matches the source route header, and the Egress of a Non-Storing Mode matches the source route header, and the Egress of a Non-Storing Mode
P-DAO is an implicit Target that is not listed in the RTO. P-DAO is an implicit Target that is not listed in the RTO.
3.4.1. Using Storing Mode Segments 3.5.1. Using Storing Mode Segments
A==>B==>C and C==>D==>E are segments of a same Track. Note that the A==>B==>C and C==>D==>E are segments of a same Track. Note that the
Storing Mode signaling imposes strict continuity in a segment, since Storing Mode signaling imposes strict continuity in a segment, since
the P-DAO is passed hop by hop, as a classical DAO is, along the the P-DAO is passed hop by hop, as a classical DAO is, along the
reverse datapath that it signals. One benefit of strict routing is reverse datapath that it signals. One benefit of strict routing is
that loops are avoided along the Track. that loops are avoided along the Track.
3.4.1.1. Stitched Segments 3.5.1.1. Stitched Segments
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-F,G * P-DAO 2 signals A==>B==>C-to-F,G
Storing Mode P-DAO 1 is sent to E and when it is succesfully Storing Mode P-DAO 1 is sent to E and when it is succesfully
acknowledged, Storing Mode P-DAO 2 is sent to C, as follows: acknowledged, Storing Mode P-DAO 2 is sent to C, as follows:
skipping to change at page 13, line 29 skipping to change at page 16, line 29
Table 3: Packet Header Settings Table 3: Packet Header Settings
As an example, say that A has a packet for F. Using the RIB above: As an example, say that A has a packet for F. Using the RIB above:
* From P-DAO 2: A forwards to B and B forwards to C. * From P-DAO 2: A forwards to B and B forwards to C.
* From P-DAO 1: C forwards to D and D forwards to E. * From P-DAO 1: C forwards to D and D forwards to E.
* From Neighbor Cache Entry: C delivers the packet to F. * From Neighbor Cache Entry: C delivers the packet to F.
3.4.1.2. External routes 3.5.1.2. External routes
In this example, we consider F and G as destinations that are In this example, we consider F and G as destinations that are
external to the Track as a DODAG, as discussed in section 4.1.1. of external to the Track as a DODAG, as discussed in section 4.1.1. of
[RFC9008]. We then apply the directives for encapsulating in that [RFC9008]. We then apply the directives for encapsulating in that
case, more in Section 6.6. case, more in Section 6.6.
In this formulation, we set up the Track Leg explicitly, which In this formulation, we set up the Track Leg explicitly, which
creates less routing state in intermediate hops at the expense of creates less routing state in intermediate hops at the expense of
larger packets to accommodate source routing: larger packets to accommodate source routing:
skipping to change at page 15, line 32 skipping to change at page 18, line 32
P-DAO 3, with the outer header above. Now the packet destination P-DAO 3, with the outer header above. Now the packet destination
is E. is E.
* From P-DAO 2: A forwards to B and B forwards to C. * From P-DAO 2: A forwards to B and B forwards to C.
* From P-DAO 1: C forwards to D and D forwards to E; E decapsulates * From P-DAO 1: C forwards to D and D forwards to E; E decapsulates
the packet. the packet.
* From Neighbor Cache Entry: C delivers packets to F or G. * From Neighbor Cache Entry: C delivers packets to F or G.
3.4.1.3. Segment Routing 3.5.1.3. Segment Routing
In this formulation leverages Track Legs to combine Segments and form In this formulation leverages Track Legs to combine Segments and form
a Graph. The packets are source routed from a Segment to the next to a Graph. The packets are source routed from a Segment to the next to
adapt the path. As such, this can be seen as a form of Segment adapt the path. As such, this can be seen as a form of Segment
Routing [RFC8402]: Routing [RFC8402]:
* P-DAO 1 signals C==>D==>E-to-E * P-DAO 1 signals C==>D==>E-to-E
* P-DAO 2 signals A==>B-to-B,C * P-DAO 2 signals A==>B-to-B,C
skipping to change at page 17, line 35 skipping to change at page 20, line 35
* From P-DAO 2: A forwards to B and B forwards to C. * From P-DAO 2: A forwards to B and B forwards to C.
* From P-DAO 3: C processes the SRH and sets the destination in the * From P-DAO 3: C processes the SRH and sets the destination in the
IPv6 Header to E. IPv6 Header to E.
* From P-DAO 1: C forwards to D and D forwards to E; E decapsulates * From P-DAO 1: C forwards to D and D forwards to E; E decapsulates
the packet. the packet.
* From the Neighbor Cache Entry: C delivers packets to F or G. * From the Neighbor Cache Entry: C delivers packets to F or G.
3.4.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-C,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.4.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 |
+====================+==============+==============+ +====================+==============+==============+
| Mode | Non-Storing | Non-Storing | | Mode | Non-Storing | Non-Storing |
+--------------------+--------------+--------------+ +--------------------+--------------+--------------+
| Track Ingress | C | A | | Track Ingress | C | A |
skipping to change at page 19, line 33 skipping to change at page 22, line 33
* From the SRH: Packets forwarded by B have source A, destination C, * From the SRH: Packets forwarded by B have source A, destination C,
a consumed SRH, and a RPI indicating a TrackId of 131 from A's a consumed SRH, and a RPI indicating a TrackId of 131 from A's
namespace. C decapsulates. namespace. C decapsulates.
* From P-DAO 1: C encapsulates the packet with destination of F in * From P-DAO 1: C encapsulates the packet with destination of F 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.
3.4.2.2. External routes 3.5.2.2. External routes
In this formulation: In this formulation:
* P-DAO 1 signals C==>D==>E-to-E * P-DAO 1 signals C==>D==>E-to-E
* P-DAO 2 signals A==>B==>C-to-C,E * P-DAO 2 signals A==>B==>C-to-C,E
* P-DAO 3 signals F and G via the A-->E-to-F,G Track * P-DAO 3 signals F and G via the A-->E-to-F,G Track
Non-Storing Mode P-DAO 1 is sent to C and Non-Storing Mode P-DAO 2 Non-Storing Mode P-DAO 1 is sent to C and Non-Storing Mode P-DAO 2
skipping to change at page 21, line 39 skipping to change at page 24, line 39
* From the SRH: Packets forwarded by B have source A, destination C * From the SRH: Packets forwarded by B have source A, destination C
, a consumed SRH, and a RPI indicating a TrackId of 129 from A's , a consumed SRH, and a RPI indicating a TrackId of 129 from A's
namespace. C decapsulates. namespace. C decapsulates.
* 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.
3.4.2.3. Segment Routing 3.5.2.3. Segment Routing
In this formulation: In this formulation:
* P-DAO 1 signals C==>D==>E-to-E * P-DAO 1 signals C==>D==>E-to-E
* P-DAO 2 signals A==>B-to-C * P-DAO 2 signals A==>B-to-C
* P-DAO 3 signals F and G via the A-->C-->E-to-F,G Track * P-DAO 3 signals F and G via the A-->C-->E-to-F,G Track
Non-Storing Mode P-DAO 1 is sent to C and Non-Storing Mode P-DAO 2 Non-Storing Mode P-DAO 1 is sent to C and Non-Storing Mode P-DAO 2
skipping to change at page 24, line 19 skipping to change at page 27, line 19
connected route. connected route.
* 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.
3.5. Complex Tracks 3.6. Complex Tracks
To increase the reliability of the P2P transmission, this To increase the reliability of the P2P transmission, this
specification enables to build a collection of Legs between the same specification enables to build a collection of Legs between the same
Ingress and Egress Nodes and combine them with the same TrackID, as Ingress and Egress Nodes and combine them with the same TrackID, as
shown in Figure 2. Legs may cross at loose hops edges or remain shown in Figure 5. Legs may cross at loose hops edges or remain
parallel. parallel.
The Segments that join the loose hops of a Leg are installed with the The Segments that join the loose hops of a Leg are installed with the
same TrackID as the Leg. But each individual Leg and Segment has its same TrackID as the Leg. But each individual Leg and Segment has its
own P-RouteID which allows to manage it separately. When Legs cross own P-RouteID which allows to manage it separately. When Legs cross
within respsective Segment, the next loose hop (the current within respsective Segment, the next loose hop (the current
destination of the packet) indicates which Leg is being followed and destination of the packet) indicates which Leg is being followed and
a Segment that can reach that next loose hop is selected. a Segment that can reach that next loose hop is selected.
CPF CPF CPF CPF CPF CPF CPF CPF
skipping to change at page 25, line 44 skipping to change at page 28, line 44
<------ Segment 3 F,G,H ------> <---- Segment 4 J,E ----> <------ Segment 3 F,G,H ------> <---- Segment 4 J,E ---->
<- Leg 2 H, E -> <- Leg 2 H, E ->
<--- Segment 1 A,B ---> <- S5-> <---- Segment 4 J,E ----> <--- Segment 1 A,B ---> <- S5-> <---- Segment 4 J,E ---->
<- Leg 3 B, H, E -> <- Leg 3 B, H, E ->
) )
( (
( ) ( )
Figure 2: Segments and Tracks Figure 5: Segments and Tracks
Note that while this specification enables to build both Segments Note that while this specification enables to build both Segments
inside a Leg (aka East-West), such as Segment 2 above which is within inside a Leg (aka East-West), such as Segment 2 above which is within
Leg 1, and Inter-Leg Segments (aka North-South), such as Segment 2 Leg 1, and Inter-Leg Segments (aka North-South), such as Segment 2
above which joins Leg 1 and Leg 2, it does not signal to the Ingress above which joins Leg 1 and Leg 2, it does not signal to the Ingress
which Inter-Leg Segments are available, so the use of North-South which Inter-Leg Segments are available, so the use of North-South
Segments and associated PAREO functions is curently limited. The Segments and associated PAREO functions is curently limited. The
only possibility available at this time is to define overlapping Legs only possibility available at this time is to define overlapping Legs
as illustrated in Figure 2, with Leg 3 that is congruent with Leg 1 as illustrated in Figure 5, with Leg 3 that is congruent with Leg 1
till node B and congruent with Leg 2 from node H on, abstracting till node B and congruent with Leg 2 from node H on, abstracting
Segment 5 as an East-West Segment. Segment 5 as an East-West Segment.
DetNet Forwarding Nodes only understand the simple 1-to-1 forwarding DetNet Forwarding Nodes only understand the simple 1-to-1 forwarding
sublayer transport operation along a segment whereas the more sublayer transport operation along a segment whereas the more
sophisticated Relay nodes can also provide service sublayer functions sophisticated Relay nodes can also provide service sublayer functions
such as Replication and Elimination. One possible mapping between such as Replication and Elimination. One possible mapping between
DetNet and this specification is to signal the Relay Nodes as the DetNet and this specification is to signal the Relay Nodes as the
hops of a Leg and the forwarding Nodes as the hops in a Segment that hops of a Leg and the forwarding Nodes as the hops in a Segment that
join the Relay nodes as illustrated in Figure 2. join the Relay nodes as illustrated in Figure 5.
3.6. Scope and Expectations 3.7. Scope and Expectations
This specification expects that the RPL Main DODAG is operated in RPL This specification expects that the RPL Main DODAG is operated in RPL
Non-Storing Mode to sustain the exchanges with the Root. Based on Non-Storing Mode to sustain the exchanges with the Root. Based on
its comprehensive knowledge of the parent-child relationship, the its comprehensive knowledge of the parent-child relationship, the
Root can form an abstracted view of the whole DODAG topology. This Root can form an abstracted view of the whole DODAG topology. This
document adds the capability for nodes to advertise additional document adds the capability for nodes to advertise additional
sibling information to complement the topological awareness of the sibling information to complement the topological awareness of the
Root to be passed on to the PCE, and enable the PCE to build more / Root to be passed on to the PCE, and enable the PCE to build more /
better paths that traverse those siblings. better paths that traverse those siblings.
skipping to change at page 26, line 47 skipping to change at page 29, line 47
The "6TiSCH Architecture" [6TiSCH-ARCHI] leverages a centralized The "6TiSCH Architecture" [6TiSCH-ARCHI] leverages a centralized
model that is similar to that of "Deterministic Networking model that is similar to that of "Deterministic Networking
Architecture" [RFC8655], whereby the device resources and Architecture" [RFC8655], whereby the device resources and
capabilities are exposed to an external controller which installs capabilities are exposed to an external controller which installs
routing states into the network based on its own objective functions routing states into the network based on its own objective functions
that reside in that external entity. With DetNet and 6TiSCH, the that reside in that external entity. With DetNet and 6TiSCH, the
component of the controller that is responsible of computing routes component of the controller that is responsible of computing routes
is a PCE. The PCE computes its routes based on its own objective is a PCE. The PCE computes its routes based on its own objective
functions such as described in [RFC4655], and typically controls the functions such as described in [RFC4655], and typically controls the
routes using the PCE Protocol (PCEP) by [RFC5551]. While this routes using the PCE Protocol (PCEP) by [RFC5440]. While this
specification expects a PCE and while PCEP might effectively be used specification expects a PCE and while PCEP might effectively be used
between the Root and the PCE, the control protocol between the PCE between the Root and the PCE, the control protocol between the PCE
and the Root is out of scope. and the Root is out of scope.
This specification expects a single PCE with a full view of the This specification expects a single PCE with a full view of the
network. Distributing the PCE function for a large network is out of network. Distributing the PCE function for a large network is out of
scope. This specification uses the RPL Root as a proxy to the PCE. scope. This specification uses the RPL Root as a proxy to the PCE.
The PCE may be collocated with the Root, or may reside in an external The PCE may be collocated with the Root, or may reside in an external
Controller. In that case, the protocol between the Root and the PCE Controller. In that case, the protocol between the Root and the PCE
is out of scope and abstracted by / mapped to RPL inside the DODAG; is out of scope and abstracted by / mapped to RPL inside the DODAG;
skipping to change at page 27, line 30 skipping to change at page 30, line 30
statistical nature, and provide visibility on link throughput, statistical nature, and provide visibility on link throughput,
latency, stability and availability over relatively long periods. latency, stability and availability over relatively long periods.
The "Reliable and Available Wireless (RAW) Architecture/Framework" The "Reliable and Available Wireless (RAW) Architecture/Framework"
[RAW-ARCHI] extends the definition of Track, as being composed of [RAW-ARCHI] extends the definition of Track, as being composed of
East-West directional segments and North-South bidirectional East-West directional segments and North-South bidirectional
segments, to enable additional path diversity, using Packet ARQ, segments, to enable additional path diversity, using Packet ARQ,
Replication, Elimination, and Overhearing (PAREO) functions over the Replication, Elimination, and Overhearing (PAREO) functions over the
available paths, to provide a dynamic balance between the reliability available paths, to provide a dynamic balance between the reliability
and availability requirements of the flows and the need to conserve and availability requirements of the flows and the need to conserve
energy and spectrum.. This specification prepares for RAW by setting energy and spectrum. This specification prepares for RAW by setting
up the Tracks, but only forms DODAGs, which are composed of up the Tracks, but only forms DODAGs, which are composed of
aggregated end-to-end loose source routed Legs, joined by strict aggregated end-to-end loose source routed Legs, joined by strict
routed Segments, all oriented East-West. routed Segments, all oriented East-West.
The RAW Architecture defines a dataplane extension of the PCE called The RAW Architecture defines a dataplane extension of the PCE called
the Path Selection Engine (PSE), that adapts the use of the path the Path Selection Engine (PSE), that adapts the use of the path
redundancy within a Track to defeat the diverse causes of packet redundancy within a Track to defeat the diverse causes of packet
loss. The PSE controls the forwarding operation of the packets loss. The PSE controls the forwarding operation of the packets
within a Track This specification can use but does not impose a PSE within a Track This specification can use but does not impose a PSE
and does not provide the policies that wouldselect which packets are and does not provide the policies that wouldselect which packets are
skipping to change at page 28, line 43 skipping to change at page 31, line 43
(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 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 3. The 'P' flag is encoded in bit position 2 (to be confirmed Figure 6. 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.
skipping to change at page 29, line 21 skipping to change at page 32, line 21
+ + + +
| DODAGID field set to the | | DODAGID field set to the |
+ IPv6 Address of the Track Ingress + + IPv6 Address of the Track Ingress +
| used to source encapsulated packets | | used to source encapsulated packets |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)... | Option(s)...
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 3: Projected DAO Base Object Figure 6: Projected DAO Base Object
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.2 as Track, more in Section 6.2
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.
skipping to change at page 31, line 38 skipping to change at page 34, line 38
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 4: Extended RPL Option Format Figure 7: 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.5.
skipping to change at page 33, line 4 skipping to change at page 36, line 4
decision, in which case it MAY be used in Elective form. decision, in which case it MAY be used in Elective form.
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 5: P-RPI-6LoRH Format Figure 8: 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.3 and RPLInstanceID field signals the TrackID, see Section 3.4 and
Section 6.2 . Section 6.2 .
Section 6.7 details how a a Track Ingress leverages the P-RPI-6LoRH Section 6.7 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
skipping to change at page 34, line 13 skipping to change at page 37, line 13
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 6: New P-DAO Request Format Figure 9: 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.3 and Section 6.2. To allocate a new Track, Track, see Section 3.4 and Section 6.2. 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.
R: The 'R' flag is set to request a Complex Track for redundancy. R: The 'R' flag is set to request a Complex Track for redundancy.
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
skipping to change at page 35, line 15 skipping to change at page 38, line 15
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 7: New PDR-ACK Control Message Format Figure 10: 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 8: Status is substructured as indicated in Figure 11:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|E|R| Value | |E|R| Value |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 8: PDR-ACK status Format Figure 11: 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 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
skipping to change at page 36, line 25 skipping to change at page 39, line 25
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 9, for simplicity. addresses, as shown in Figure 12, 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 37, line 29 skipping to change at page 40, line 29
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. 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 9: VIO format (uncompressed form) Figure 12: 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 25 IANA), see =Table 25
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 39, line 31 skipping to change at page 42, line 31
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, and the
Root will assume symmetry. 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 |D| Flags |Comp.| Opaque | | Type | Option Length |S| Flags |Comp.| Opaque |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Step of Rank | Reserved | | Step of Rank | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
. . . .
. Sibling DODAGID (if the D flag not set) . . Sibling DODAGID (if the D flag not set) .
. . . .
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
. . . .
. Sibling Address . . Sibling Address .
. . . .
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Sibling Information Option Format Figure 13: Sibling Information Option Format
Option Type: 0x10 for SIO (to be confirmed by IANA), see =Table 25 Option Type: 0x10 for SIO (to be confirmed by IANA), see =Table 25
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.
D: 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
uses RPL for a particular use / environment MAY redefine the use uses RPL for a particular use / environment MAY redefine the use
skipping to change at page 42, line 21 skipping to change at page 45, line 21
This draft leverages the RPL Instance model as follows: This draft leverages the RPL Instance model as follows:
* The Root MAY use P-DAO messages to add better routes in the main * The Root MAY use P-DAO messages to add better routes in the main
(Global) RPL Instance in conformance with the routing objectives (Global) RPL Instance in conformance with the routing objectives
in that Instance. in that Instance.
To achieve this, the Root MAY install a Segment along a path down To achieve this, the Root MAY install a Segment along a path down
the main Non-Storing Mode DODAG. This enables a loose source the main Non-Storing Mode DODAG. This enables a loose source
routing and reduces the size of the Routing Header, see routing and reduces the size of the Routing Header, see
Appendix A.1. The Root MAY also install a Track Leg across the Section 3.3.1. The Root MAY also install a Track Leg across the
Main DODAG to complement the routing topology. Main DODAG to complement the routing topology.
When adding a P-Route to the RPL Main DODAG, the Root MUST set the When adding a P-Route to the RPL Main DODAG, the Root MUST set the
RPLInstanceID field of the P-DAO Base Object (see section 6.4.1. RPLInstanceID field of the P-DAO Base Object (see section 6.4.1.
of [RPL]) to the RPLInstanceID of the Main DODAG, and MUST NOT use of [RPL]) to the RPLInstanceID of the Main DODAG, and MUST NOT use
the DODAGID field. A P-Route provides a longer match to the the DODAGID field. A P-Route provides a longer match to the
Target Address than the default route via the Root, so it is Target Address than the default route via the Root, so it is
preferred. preferred.
* The Root MAY also use P-DAO messages to install a Track as an * The Root MAY also use P-DAO messages to install a Track as an
skipping to change at page 42, line 46 skipping to change at page 45, line 46
serves as TrackID. The TrackID MUST be unique for the IPv6 ULA or serves as TrackID. The TrackID MUST be unique for the IPv6 ULA or
GUA of the Track Ingress that serves as DODAGID for the Track. GUA of the Track Ingress that serves as DODAGID for the Track.
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 3, and the P-RouteID that identifies the Track as shown in Figure 6, 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 9. in Figure 12.
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, the namespace can be
delegated to the main Root, which can assign the TrackIDs for the delegated to the main Root, which can assign the TrackIDs for the
Tracks it creates without collision. Tracks it creates without collision.
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
skipping to change at page 45, line 39 skipping to change at page 48, line 39
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 10.14. Section 10.14.
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.3.2. Installing a Track Segment with a Storing Mode P-Route 6.3.2. Installing a Track Segment with a Storing Mode P-Route
As illustrated in Figure 11, a Storing Mode P-DAO installs a route As illustrated in Figure 14, 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 46, line 22 skipping to change at page 49, 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 11: Projecting a route Figure 14: 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 47, line 34 skipping to change at page 50, 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.3.3. Installing a Track Leg with a Non-Storing Mode P-Route 6.3.3. Installing a Track Leg with a Non-Storing Mode P-Route
As illustrated in Figure 12, a Non-Storing Mode P-DAO installs a As illustrated in Figure 15, 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 48, line 23 skipping to change at page 51, 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 12: Projecting a Non-Storing Route Figure 15: 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.
If the next entry in the loose sequence is reachable over a Storing If the next entry in the loose sequence is reachable over a Storing
Mode P-Route, it MUST be the Target of a Segment and the Ingress of a Mode P-Route, it MUST be the Target of a Segment and the Ingress of a
next segment, both already setup; the segments are associated with next segment, both already setup; the segments are associated with
the same Track, which avoids the need of an additional encapsulation. the same Track, which avoids the need of an additional encapsulation.
For instance, in Section 3.4.1.3, Segments A==>B-to-C and For instance, in Section 3.5.1.3, Segments A==>B-to-C and
C==>D==>E-to-F must be installed with Storing Mode P-DAO messages 1 C==>D==>E-to-F must be installed with Storing Mode P-DAO messages 1
and 2 before the Track A-->C-->E-to-F that joins them can be and 2 before the Track A-->C-->E-to-F that joins them can be
installed with Non-Storing Mode P-DAO 3. installed with Non-Storing Mode P-DAO 3.
Conversely, if it is reachable over a Non-Storing Mode P-Route, the Conversely, if it is reachable over a Non-Storing Mode P-Route, the
next loose source-routed hop of the inner Track is a Target of a next loose source-routed hop of the inner Track is a Target of a
previously installed Track and the Ingress of a next Track, which previously installed Track and the Ingress of a next Track, which
requires a de- and a re-encapsulation when switching the outer Tracks requires a de- and a re-encapsulation when switching the outer Tracks
that join the loose hops. This is examplified in Section 3.4.2.3 that join the loose hops. This is examplified in Section 3.5.2.3
where Non-Storing Mode P-DAO 1 and 2 install strict Tracks that Non- where Non-Storing Mode P-DAO 1 and 2 install strict Tracks that Non-
Storing Mode P-DAO 3 joins as a super Track. In such a case, packets Storing Mode P-DAO 3 joins as a super Track. In such a case, packets
are subject to double IP-in-IP encapsulation. are subject to double IP-in-IP encapsulation.
6.4. Tearing Down a P-Route 6.4. Tearing Down a P-Route
A P-DAO with a lifetime of 0 is interpreted as a No-Path DAO and A P-DAO with a lifetime of 0 is interpreted as a No-Path DAO and
results in cleaning up existing state as opposed to refreshing an results in cleaning up existing state as opposed to refreshing an
existing one or installing a new one. To tear down a Track, the Root existing one or installing a new one. To tear down a Track, the Root
must tear down all the Track Segments and Legs that compose it one by must tear down all the Track Segments and Legs that compose it one by
skipping to change at page 49, line 40 skipping to change at page 52, line 40
The No-Path P-DAO is forwarded normally along the reverse list, even The No-Path P-DAO is forwarded normally along the reverse list, even
if the intermediate node does not find a Segment state to clean up. if the intermediate node does not find a Segment state to clean up.
This results in cleaning up the existing Segment state if any, as This results in cleaning up the existing Segment state if any, as
opposed to refreshing an existing one or installing a new one. opposed to refreshing an existing one or installing a new one.
6.5. Maintaining a Track 6.5. Maintaining a Track
Repathing a Track Segment or Leg may cause jitter and packet Repathing a Track Segment or Leg may cause jitter and packet
misordering. For critical flows that require timely and/or in-order misordering. For critical flows that require timely and/or in-order
delivery, it might be necessary to deploy the PAREO functions delivery, it might be necessary to deploy the PAREO functions
[RAW-ARCHI] over a highly redundant Track.. This specification [RAW-ARCHI] over a highly redundant Track. This specification allows
allows to use more than one Leg for a Track, and 1+N packet to use more than one Leg for a Track, and 1+N packet redundancy.
redundancy.
This section provides the steps to ensure that no packet is lost due This section provides the steps to ensure that no packet is lost due
to the operation itself. This is ensured by installing the new to the operation itself. This is ensured by installing the new
section from its last node to the first, so when an intermediate node section from its last node to the first, so when an intermediate node
installs a route along the new section, all the downstream nodes in installs a route along the new section, all the downstream nodes in
the section have already installed their own. The disabled section the section have already installed their own. The disabled section
is removed when the packets in-flight are forwarded along the new is removed when the packets in-flight are forwarded along the new
section as well. section as well.
6.5.1. Maintaining a Track Segment 6.5.1. Maintaining a Track Segment
skipping to change at page 52, line 33 skipping to change at page 55, line 33
- If the Track Ingress is the originator of the packet and the - If the Track Ingress is the originator of the packet and the
Track Egress is the destination of the packet, there is no need Track Egress is the destination of the packet, there is no need
for an encapsulation. for an encapsulation.
- So the Track Ingress must encapsulate the traffic that it did - So the Track Ingress must encapsulate the traffic that it did
not originate, and add an RPI. not originate, and add an RPI.
A packet that is being routed over the RPL Instance associated to A packet that is being routed over the RPL Instance associated to
a first Non-Storing Mode Track MAY be placed (encapsulated) in a a first Non-Storing Mode Track MAY be placed (encapsulated) in a
second Track to cover one loose hop of the first Track as second Track to cover one loose hop of the first Track as
discussed in more details Section 3.4.2.3. On the other hand, a discussed in more details Section 3.5.2.3. On the other hand, a
Storing Mode Track must be strict and a packet that it placed in a Storing Mode Track must be strict and a packet that it placed in a
Storing Mode Track MUST follow that Track till the Track Egress. Storing Mode Track MUST follow that Track till the Track Egress.
The forwarding of a packet along a track will fail if the Track The forwarding of a packet along a track will fail if the Track
continuity is broken,e.g.: continuity is broken,e.g.:
* In the case of a strict path along a Segment, if the next strict * In the case of a strict path along a Segment, if the next strict
hop is not reachable, the packet is dropped. hop is not reachable, the packet is dropped.
* In the case of a loose source-routed path, when the loose next hop * In the case of a loose source-routed path, when the loose next hop
skipping to change at page 53, line 47 skipping to change at page 56, 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.7. Compression of the RPL Artifacts 6.7. 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 13, representing the case where : is formatted as shown in Figure 16, 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 13: A Packet as Forwarded along the Main DODAG Figure 16: 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 13 from the second octet is verbatim the packet represented in Figure 16 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 14 is 3, meaning that the SRH-6LoRH as a Length field shown in Figure 17 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 14: The IP-in-IP 6LoRH Header Figure 17: 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 5, using the TrackID as RPI-6LoRH Header, as illustrated in Figure 8, 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 15: The SRH 6LoRH Header Figure 18: 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 16: compressed form is illustrated in Figure 19:
+-+ ... -+-+-+- ... -+-+-+- ... -+-+-+-+-+- ... +-+-+-+-+-+-+- ... +-+ ... -+-+-+- ... -+-+-+- ... -+-+-+-+-+- ... +-+-+-+-+-+-+- ...
| 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 16: A Packet as Forwarded along a Track Figure 19: 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 57, line 47 skipping to change at page 60, line 47
* The node merely selects one of the proposed paths and applies the * The node merely selects one of the proposed paths and applies the
associated pre-computed routing header in the encapsulation. This associated pre-computed routing header in the encapsulation. This
alleviates both the complexity of computing a path and the alleviates both the complexity of computing a path and the
compressed form of the routing header. compressed form of the routing header.
The "Reliable and Available Wireless (RAW) Architecture/Framework" The "Reliable and Available Wireless (RAW) Architecture/Framework"
[RAW-ARCHI] actually expects the PSE at the Track Ingress to react to [RAW-ARCHI] actually expects the PSE at the Track Ingress to react to
changes in the forwarding conditions along the Track, and reroute changes in the forwarding conditions along the Track, and reroute
packets to maintain the required degree of reliability. To achieve packets to maintain the required degree of reliability. To achieve
this, the PSE need the full richness of a DODAG to form any path that this, the PSE need the full richness of a DODAG to form any path that
could make meet the SLAs. could make meet the Service Level Objective (SLO).
This section specifies the additions that are needed to turn the This section specifies the additions that are needed to turn the
Track into a full DODAG and enable the main Root to provide the Track into a full DODAG and enable the main Root to provide the
necessary topological information to the Track Ingress. The necessary topological information to the Track Ingress. The
expectation is that the metrics that the PSE uses are of an order expectation is that the metrics that the PSE uses are of an order
other than that of the PCE, because of the difference of time scale other than that of the PCE, because of the difference of time scale
between routing and forwarding, mor e in [RAW-ARCHI]. It follows between routing and forwarding, mor e in [RAW-ARCHI]. It follows
that the PSE will learn the metrics it needs from an alternate that the PSE will learn the metrics it needs from an alternate
source, e.g., OAM frames. source, e.g., OAM frames.
skipping to change at page 61, line 37 skipping to change at page 64, line 37
+===============+=============+===============+ +===============+=============+===============+
| 8 (Suggested) | P-RPI-6LoRH | This document | | 8 (Suggested) | P-RPI-6LoRH | This document |
+---------------+-------------+---------------+ +---------------+-------------+---------------+
Table 22: New Critical 6LoWPAN Routing Table 22: New Critical 6LoWPAN Routing
Header Type Header Type
10.3. New Subregistry For The RPL Option Flags 10.3. New 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 4, under the "Routing Protocol for Flags field, as detailed in Figure 7, under the "Routing Protocol for
Low Power and Lossy Networks (RPL)" registry. The bits are indexed Low Power and Lossy Networks (RPL)" registry. The bits are indexed
from 0 (leftmost) to 7. Each bit is Tracked with the following from 0 (leftmost) to 7. Each bit is Tracked with the following
qualities: 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 65, line 23 skipping to change at page 68, line 23
* Capability description * Capability description
* Reference * Reference
Registration procedure is "Standards Action" [RFC8126]. The initial Registration procedure is "Standards Action" [RFC8126]. The initial
allocation is as indicated in Table 29: allocation is as indicated in Table 29:
+===============+========================+===========+ +===============+========================+===========+
| Bit number | Capability description | Reference | | Bit number | Capability description | Reference |
+===============+========================+===========+ +===============+========================+===========+
| 0 (Suggested) | "D" flag: Sibling in | This | | 0 (Suggested) | "S" flag: Sibling in | This |
| | same DODAG as Self | document | | | same DODAG as Self | document |
+---------------+------------------------+-----------+ +---------------+------------------------+-----------+
Table 29: Initial SIO Flags Table 29: Initial SIO Flags
10.12. New destination Advertisement Object Flag 10.12. New 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] .
skipping to change at page 67, line 21 skipping to change at page 70, line 21
Control Message Protocol (ICMPv6) for the Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89, Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006, RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>. <https://www.rfc-editor.org/info/rfc4443>.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655, Computation Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006, DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>. <https://www.rfc-editor.org/info/rfc4655>.
[RFC5551] Gellens, R., Ed., "Lemonade Notifications Architecture", [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
RFC 5551, DOI 10.17487/RFC5551, August 2009, Element (PCE) Communication Protocol (PCEP)", RFC 5440,
<https://www.rfc-editor.org/info/rfc5551>. DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011, DOI 10.17487/RFC6282, September 2011,
<https://www.rfc-editor.org/info/rfc6282>. <https://www.rfc-editor.org/info/rfc6282>.
[RPL] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., [RPL] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550, Low-Power and Lossy Networks", RFC 6550,
skipping to change at page 70, line 26 skipping to change at page 73, line 26
[I-D.irtf-panrg-path-properties] [I-D.irtf-panrg-path-properties]
Enghardt, T. and C. Krähenbühl, "A Vocabulary of Path Enghardt, T. and C. Krähenbühl, "A Vocabulary of Path
Properties", Work in Progress, Internet-Draft, draft-irtf- Properties", Work in Progress, Internet-Draft, draft-irtf-
panrg-path-properties-03, 9 July 2021, panrg-path-properties-03, 9 July 2021,
<https://datatracker.ietf.org/doc/html/draft-irtf-panrg- <https://datatracker.ietf.org/doc/html/draft-irtf-panrg-
path-properties-03>. path-properties-03>.
[PCE] IETF, "Path Computation Element", [PCE] IETF, "Path Computation Element",
<https://dataTracker.ietf.org/doc/charter-ietf-pce/>. <https://dataTracker.ietf.org/doc/charter-ietf-pce/>.
Appendix A. Applications
A.1. Loose Source Routing
A RPL implementation operating in a very constrained LLN typically
uses the Non-Storing Mode of Operation as represented in Figure 17.
In that mode, a RPL node indicates a parent-child relationship to the
Root, using a destination Advertisement Object (DAO) that is unicast
from the node directly to the Root, and the Root typically builds a
source routed path to a destination down the DODAG by recursively
concatenating this information.
------+---------
| Internet
|
+-----+
| | Border router
| | (RPL Root)
+-----+ ^ | |
| | DAO | ACK |
o o o o | | | Strict
o o o o o o o o o | | | Source
o o o o o o o o o o | | | Route
o o o o o o o o o | | |
o o o o o o o o | v v
o o o o
LLN
Figure 17: RPL Non-Storing Mode of operation
Based on the parent-children relationships expressed in the Non-
Storing DAO messages,the Root possesses topological information about
the whole network, though this information is limited to the
structure of the DODAG for which it is the destination. A packet
that is generated within the domain will always reach the Root, which
can then apply a source routing information to reach the destination
if the destination is also in the DODAG. Similarly, a packet coming
from the outside of the domain for a destination that is expected to
be in a RPL domain reaches the Root.
It results that the Root, or then some associated centralized
computation engine such as a PCE, can determine the amount of packets
that reach a destination in the RPL domain, and thus the amount of
energy and bandwidth that is wasted for transmission, between itself
and the destination, as well as the risk of fragmentation, any
potential delays because of a paths longer than necessary (shorter
paths exist that would not traverse the Root).
As a network gets deep, the size of the source routing header that
the Root must add to all the downward packets becomes an issue for
nodes that are many hops away. In some use cases, a RPL network
forms long lines and a limited amount of well-targeted routing state
would allow to make the source routing operation loose as opposed to
strict, and save packet size. Limiting the packet size is directly
beneficial to the energy budget, but, mostly, it reduces the chances
of frame loss and/or packet fragmentation, which is highly
detrimental to the LLN operation. Because the capability to store a
routing state in every node is limited, the decision of which route
is installed where can only be optimized with a global knowledge of
the system, a knowledge that the Root or an associated PCE may
possess by means that are outside of the scope of this specification.
This specification enables to store a Storing Mode state in
intermediate routers, which enables to limit the excursion of the
source route headers in deep networks. Once a P-DAO exchange has
taken place for a given Target, if the Root operates in non Storing
Mode, then it may elide the sequence of routers that is installed in
the network from its source route headers to destination that are
reachable via that Target, and the source route headers effectively
become loose.
A.2. East-West Routes
RPL is optimized for Point-to-Multipoint (P2MP) and Multipoint-to-
Point (MP2P), whereby routes are always installed North-South (aka
up/down) along the RPL DODAG respectively from and towards the DODAG
Root. Peer to Peer (P2P) East-West routes in a RPL network will
generally suffer from some elongated (stretched) path versus a direct
(optimized) path, since routing between two nodes always happens via
a common parent, as illustrated in Figure 18:
------+---------
| Internet
|
+-----+
| | Border router
| | (RPL Root)
+-----+
X
^ v o o
^ o o v o o o o o
^ o o o v o o o o o
^ o o v o o o o o
S o o o D o o o
o o o o
LLN
Figure 18: Routing Stretch between S and D via common parent X
along North-South Paths
* In Storing Mode, unless the destination is a child of the source,
the packets will follow the default route up the DODAG as well.
If the destination is in the same DODAG, they will eventually
reach a common parent that has a route to the destination; at
worse, the common parent may also be the Root. From that common
parent, the packet will follow a path down the DODAG that is
optimized for the Objective Function that was used to build the
DODAG.
* in Non-Storing Mode, all packets routed within the DODAG flow all
the way up to the Root of the DODAG. If the destination is in the
same DODAG, the Root must encapsulate the packet to place an RH
that has the strict source route information down the DODAG to the
destination. This will be the case even if the destination is
relatively close to the source and the Root is relatively far off.
It results that it is often beneficial to enable East-West P2P
routes, either if the RPL route presents a stretch from shortest
path, or if the new route is engineered with a different objective,
and that it is even more critical in Non-Storing Mode than it is in
Storing Mode, because the routing stretch is wider. For that reason,
earlier work at the IETF introduced the "Reactive Discovery of
Point-to-Point Routes in Low Power and Lossy Networks" [RFC6997],
which specifies a distributed method for establishing optimized P2P
routes. This draft proposes an alternate based on a centralized
route computation.
------+---------
| Internet
|
+-----+
| | Border router
| | (RPL Root)
+-----+
|
o o o o
o o o o o o o o o
o o o o o o o o o o
o o o o o o o o o
S>>A>>>B>>C>>>D o o o
o o o o
LLN
Figure 19: More direct East-West Route between S and D
This specification enables to store source-routed or Storing Mode
state in intermediate routers, which enables to limit the stretch of
a P2P route and maintain the characteristics within a given SLA. An
example of service using this mechanism oculd be a control loop that
would be installed in a network that uses classical RPL for
asynchronous data collection. In that case, the P2P path may be
installed in a different RPL Instance, with a different objective
function.
Authors' Addresses Authors' Addresses
Pascal Thubert (editor) Pascal Thubert (editor)
Cisco Systems, Inc Cisco Systems, Inc
Building D Building D
45 Allee des Ormes - BP1200 45 Allee des Ormes - BP1200
06254 Mougins - Sophia Antipolis 06254 Mougins - Sophia Antipolis
France France
Phone: +33 497 23 26 34 Phone: +33 497 23 26 34
 End of changes. 71 change blocks. 
298 lines changed or deleted 293 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/