draft-ietf-roll-dao-projection-09.txt   draft-ietf-roll-dao-projection-10.txt 
ROLL P. Thubert, Ed. ROLL P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Updates: 6550 (if approved) R.A. Jadhav Updates: 6550 (if approved) R.A. Jadhav
Intended status: Standards Track Huawei Tech Intended status: Standards Track Huawei Tech
Expires: 20 May 2020 M. Gillmore Expires: 12 November 2020 M. Gillmore
Itron Itron
17 November 2019 11 May 2020
Root initiated routing state in RPL Root initiated routing state in RPL
draft-ietf-roll-dao-projection-09 draft-ietf-roll-dao-projection-10
Abstract Abstract
This document enables a RPL Root to install and maintain Projected This document enables a RPL Root to install and maintain Projected
Routes within its DODAG, along a selected set of nodes that may or Routes within its DODAG, along a selected set of nodes that may or
may not include self, for a chosen duration. This potentially may not include self, for a chosen duration. This potentially
enables routes that are more optimized or resilient than those enables routes that are more optimized or resilient than those
obtained with the classical distributed operation of RPL, either in obtained with the classical distributed operation of RPL, either in
terms of the size of a source-route header or in terms of path terms of the size of a source-route header or in terms of path
length, which impacts both the latency and the packet delivery ratio. length, which impacts both the latency and the packet delivery ratio.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 20 May 2020. This Internet-Draft will expire on 12 November 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Subset of a 6LoWPAN Glossary . . . . . . . . . . . . . . 4 2.2. References . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Other Terms . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Other Terms . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. References . . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Extending RFC 6550 . . . . . . . . . . . . . . . . . . . . . 6 3. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 6
4. Identifying a Path . . . . . . . . . . . . . . . . . . . . . 7 4. Identifying a Path . . . . . . . . . . . . . . . . . . . . . 7
5. New RPL Control Messages and Options . . . . . . . . . . . . 7 5. New RPL Control Messages and Options . . . . . . . . . . . . 8
5.1. New P-DAO Request Control Message . . . . . . . . . . . . 7 5.1. New P-DAO Request Control Message . . . . . . . . . . . . 8
5.2. New PDR-ACK Control Message . . . . . . . . . . . . . . . 8 5.2. New PDR-ACK Control Message . . . . . . . . . . . . . . . 8
5.3. Route Projection Options . . . . . . . . . . . . . . . . 10 5.3. Route Projection Options . . . . . . . . . . . . . . . . 10
5.4. Sibling Information Option . . . . . . . . . . . . . . . 12 5.4. Sibling Information Option . . . . . . . . . . . . . . . 12
6. Projected DAO . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Projected DAO . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Non-Storing Mode Projected Route . . . . . . . . . . . . 14 6.1. Non-Storing Mode Projected Route . . . . . . . . . . . . 15
6.2. Storing-Mode Projected Route . . . . . . . . . . . . . . 16 6.2. Storing-Mode Projected Route . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8.1. New RPL Control Codes . . . . . . . . . . . . . . . . . . 18 8.1. New RPL Control Codes . . . . . . . . . . . . . . . . . . 19
8.2. New RPL Control Message Options . . . . . . . . . . . . . 19 8.2. New RPL Control Message Options . . . . . . . . . . . . . 19
8.3. New SubRegistry for the Projected DAO Request (PDR) 8.3. New SubRegistry for the Projected DAO Request (PDR)
Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.4. New SubRegistry for the PDR-ACK Flags . . . . . . . . . . 20 8.4. New SubRegistry for the PDR-ACK Flags . . . . . . . . . . 20
8.5. New Subregistry for the PDR-ACK Acceptance Status 8.5. New Subregistry for the PDR-ACK Acceptance Status
values . . . . . . . . . . . . . . . . . . . . . . . . . 20 values . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.6. New Subregistry for the PDR-ACK Rejection Status 8.6. New Subregistry for the PDR-ACK Rejection Status
values . . . . . . . . . . . . . . . . . . . . . . . . . 20 values . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.7. New SubRegistry for the Route Projection Options (RPO) 8.7. New SubRegistry for the Route Projection Options (RPO)
Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.8. New SubRegistry for the Sibling Information Option (SIO) 8.8. New SubRegistry for the Sibling Information Option (SIO)
Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.9. Error in Projected Route ICMPv6 Code . . . . . . . . . . 22 8.9. Error in Projected Route ICMPv6 Code . . . . . . . . . . 22
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
10. Normative References . . . . . . . . . . . . . . . . . . . . 22 10. Normative References . . . . . . . . . . . . . . . . . . . . 23
11. Informative References . . . . . . . . . . . . . . . . . . . 23 11. Informative References . . . . . . . . . . . . . . . . . . . 23
Appendix A. Applications . . . . . . . . . . . . . . . . . . . . 24 Appendix A. Applications . . . . . . . . . . . . . . . . . . . . 24
A.1. Loose Source Routing in Non-storing Mode . . . . . . . . 24 A.1. Loose Source Routing in Non-storing Mode . . . . . . . . 25
A.2. Transversal Routes in storing and non-storing modes . . . 25 A.2. Transversal Routes in storing and non-storing modes . . . 26
Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 27 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 28
B.1. Using storing mode P-DAO in non-storing mode MOP . . . . 27 B.1. Using storing mode P-DAO in non-storing mode MOP . . . . 28
B.2. Projecting a storing-mode transversal route . . . . . . . 28 B.2. Projecting a storing-mode transversal route . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
RPL, the "Routing Protocol for Low Power and Lossy Networks" RPL, the "Routing Protocol for Low Power and Lossy Networks" [RPL]
[RFC6550] (LLNs), is a generic Distance Vector protocol that is well (LLNs), is a generic Distance Vector protocol that is well suited for
suited for application in a variety of low energy Internet of Things application in a variety of low energy Internet of Things (IoT)
(IoT) networks. RPL forms Destination Oriented Directed Acyclic networks. RPL forms Destination Oriented Directed Acyclic Graphs
Graphs (DODAGs) in which the Root often acts as the Border Router to (DODAGs) in which the Root often acts as the Border Router to connect
connect the RPL domain to the Internet. The Root is responsible to the RPL domain to the Internet. The Root is responsible to select
select the RPL Instance that is used to forward a packet coming from the RPL Instance that is used to forward a packet coming from the
the Internet into the RPL domain and set the related RPL information Internet into the RPL domain and set the related RPL information in
in the packets. the packets.
The 6TiSCH architecture [6TiSCH-ARCHI] leverages RPL for its routing The "6TiSCH architecture" [6TiSCH-ARCHI] leverages RPL for its
operations and considers the Deterministic Networking Architecture routing operations and considers the Deterministic Networking
[RFC8655] as one possible model whereby the device resources and Architecture [RFC8655] as one possible model whereby the device
capabilities are exposed to an external controller which installs resources and capabilities are exposed to an external controller
routing states into the network based on some objective functions which installs routing states into the network based on some
that reside in that external entity. With DetNet and 6TiSCH, the objective functions that reside in that external entity. With DetNet
component of the controller that is responsible of computing routes and 6TiSCH, the component of the controller that is responsible of
is called a Path Computation Element ([PCE]). computing routes is called a Path Computation Element ([PCE]).
Based on heuristics of usage, path length, and knowledge of device Based on heuristics of usage, path length, and knowledge of device
capacity and available resources such as battery levels and capacity and available resources such as battery levels and
reservable buffers, a PCE with a global visibility on the system can reservable buffers, a PCE with a global visibility on the system can
compute P2P routes that are more optimized for the current needs as compute P2P routes that are more optimized for the current needs as
expressed by the objective function. expressed by the objective function. This draft proposes a protocol
extension to RPL that enables the Root to install a limited amount of
centrally-computed routes in a RPL graph, on behalf of a PCE that may
be collocated or separated from the Root. Those extensions enable
loose source routing down in RPL Non-Storing Mode and transversal
routes inside the DODAG regardless of the RPL Mode of Operation
(MOP).
This draft proposes a protocol extension to RPL that enables the Root The 6TiSCH architecture also introduces the concept of a Track that
to install a limited amount of centrally-computed routes in a RPL is a complex path with possibly redundant forwarding solutions along
graph, on behalf of a PCE that may be collocated or separated from the way, exploiting Packet ARQ, Replication, Elimination, and
the Root. Those extensions enable loose source routing down in RPL Overhearing (PAREO) functions. The "Reliable and Available Wireless
Non-Storing Mode and transversal routes inside the DODAG regardless (RAW) Architecture/Framework" [RAW-ARCHI] separates the time scale at
of the RPL Mode of Operation (MOP). which the PCE computes the Track (slow, globally optimized, with
statistical metrics) and the time scale at which the forwarding
decision is made for a packet or a small collection of packets (fast,
at the scale of the Track), to leverage the PAREO functions
dynamically and provide the required reliability and availability
while conserving energy and spectrum.
As opposed to the classical RPL operations where routes are injected As opposed to the classical RPL operations where routes are injected
by the Target nodes, the protocol extension enables the Root of a by the Target nodes, the protocol extension enables the Root of a
DODAG to project the routes that are needed onto the nodes where they DODAG to project the routes that are needed onto the nodes where they
should be installed. This specification uses the term Projected should be installed. This specification uses the term Projected
Route to refer to those routes. A Projected Route may be a stand- Route to refer to those routes. A Projected Route may be a stand-
alone path to a Target or a segment in a complex Track [6TiSCH-ARCHI] alone end-to-end path to a Target or a segment in a more complex
that provides redundant forwarding solutions to a destination to Track.
improve reliability and availability of the wireless transmissions
[RAW-PS].
Projected Routes must be used with the parsimony to limit the amount Projected Routes must be used with the parsimony to limit the amount
of state that is installed in each device to fit within its of state that is installed in each device to fit within its
resources, and to limit the amount of rerouted traffic to fit within resources, and to limit the amount of rerouted traffic to fit within
the capabilities of the transmission links. The method to learn the the capabilities of the transmission links. The method to learn the
node capabilities and the resources that are available in the devices node capabilities and the resources that are available in the devices
and in the network are out of scope for this document. and in the network are out of scope for this document.
In RPL Non-Storing Mode, the Root has enough information to build a In RPL Non-Storing Mode, the Root has enough information to build a
basic DODAG topology. This document adds the capability for nodes to basic DODAG topology. This document adds the capability for nodes to
skipping to change at page 4, line 32 skipping to change at page 5, line 5
2. Terminology 2. Terminology
2.1. BCP 14 2.1. BCP 14
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all 14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2.2. Subset of a 6LoWPAN Glossary 2.2. References
In this document, readers will encounter terms and concepts that are
discussed in the following documents:
* "Routing Protocol for Low Power and Lossy Networks" [RPL], and
* "Terminology in Low power And Lossy Networks" [RFC7102].
2.3. Other Terms
Projected Route: A Projected Route is a serial path that is computed
and installed remotely by a RPL Root.
Track: The term Track is used in this document to refer to a complex
path, e.g., a DODAG, that incorporates redundant Projected Routes
towards a destination using diversity to increase the reliability.
2.4. Glossary
This document often uses the following acronyms: This document often uses the following acronyms:
6BBR: 6LoWPAN Backbone Router 6BBR: 6LoWPAN Backbone Router
6LBR: 6LoWPAN Border Router 6LBR: 6LoWPAN Border Router
6LN: 6LoWPAN Node 6LN: 6LoWPAN Node
6LR: 6LoWPAN Router 6LR: 6LoWPAN Router
CMO: Control Message Option
DAD: Duplicate Address Detection DAD: Duplicate Address Detection
DAO: Destination Advertisement Object
DODAG: Destination-Oriented Directed Acyclic Graph DODAG: Destination-Oriented Directed Acyclic Graph
LLN: Low-Power and Lossy Network LLN: Low-Power and Lossy Network
MOP: RPL Mode of Operation
NA: Neighbor Advertisement NA: Neighbor Advertisement
NCE: Neighbor Cache Entry NCE: Neighbor Cache Entry
ND: Neighbor Discovery ND: Neighbor Discovery
NDP: Neighbor Discovery Protocol NDP: Neighbor Discovery Protocol
NS: Neighbor Solicitation NS: Neighbor Solicitation
RPL: IPv6 Routing Protocol for LLNs [RFC6550]
CMO: Control Message Option
DAO: Destination Advertisement Object
VIO: A Via Information Option, used in Storing Mode P-DAO messages.
SRVIO: A Source-Routed Via Information Option, used in Non-Storing
Mode P-DAO messages.
RPO: A Route Projection Option; it can be a VIO or an SRVIO.
P-DAO: A Projected DAO is a DAO message sent by the RPL Root to P-DAO: A Projected DAO is a DAO message sent by the RPL Root to
install a Projected Route. install a Projected Route.
PDR P-DAO Request
RTO: RPL Target Option
RAN: RPL-Aware Node
RA: Router Advertisement RA: Router Advertisement
RAN: RPL-Aware Node
RS: Router Solicitation RS: Router Solicitation
RPL: IPv6 Routing Protocol for LLNs [RPL]
RPO: A Route Projection Option; it can be a VIO or an SRVIO.
RTO: RPL Target Option
SIO: RPL Sibling Information Option
SRVIO: A Source-Routed Via Information Option, used in Non-Storing
Mode P-DAO messages.
TIO: RPL Transit Information Option
VIO: A Via Information Option, used in Storing Mode P-DAO messages.
2.3. Other Terms 3. Updating RFC 6550
Projected Route: A Projected Route is a serial path that is computed
and installed remotely by a RPL Root.
Track: The term Track is used in this document to refer to a complex
path, e.g., a DODAG, that incorporates redundant Projected Routes
towards a destination for increased reliability, high availability
and load balancing.
2.4. References
In this document, readers will encounter terms and concepts that are
discussed in the following documents:
* "Routing Protocol for Low Power and Lossy Networks" [RFC6550], and
* "Terminology in Low power And Lossy Networks" [RFC7102].
3. Extending RFC 6550
This specification introduces two new RPL Control Messages to enable This specification introduces two new RPL Control Messages to enable
a RPL Aware Node (RAN) to request the establisment of a path from a RPL Aware Node (RAN) to request the establisment of a path from
self to a Target. A RAN may request the installation of a path by self to a Target. A RAN may request the installation of a path by
sending a new P-DAO Request PDR) Message to the Root. The Root sending a new P-DAO Request (PDR) Message to the Root. The Root
confirms with a new PDR-ACK message back to the requester RAN with a confirms with a new PDR-ACK message back to the requester RAN with a
completion status once it is done installing the path. See completion status once it is done installing the path. See
Section 5.1 for more. Section 5.1 for more.
Section 6.7 of [RFC6550] specifies RPL Control Message Options (CMO) Section 6.7 of [RPL] specifies the RPL Control Message Options (CMO)
to be placed in RPL messages such as the Destination Advertisement to be placed in RPL messages such as the Destination Advertisement
Object (DAO) message. The RPL Target Option (RTO) and the Transit Object (DAO) message. The RPL Target Option (RTO) and the Transit
Information Option (TIO) are such options. In Non-Storing Mode, the Information Option (TIO) are such options. In Non-Storing Mode, the
TIO option is used in the DAO message to indicate a parent within a TIO option is used in the DAO message to indicate a parent within a
DODAG. The TIO applies to the RTOs that immedially preceed it in the DODAG. The TIO applies to the RTOs that immedially preceed it in the
message. Options may be factorized; multiple TIOs may be present to message. Options may be factorized; multiple TIOs may be present to
indicate multiple routes to the one or more contiguous addresses indicate multiple routes to the one or more contiguous addresses
indicated in the RTOs that immediately precede the TIOs in the RPL indicated in the RTOs that immediately precede the TIOs in the RPL
message. message.
skipping to change at page 6, line 43 skipping to change at page 6, line 43
(SRVIO). The VIO installs a route on each hop along a Projected (SRVIO). The VIO installs a route on each hop along a Projected
Route (in a fashion analogous to RPL Storing Mode) whereas the SRVIO Route (in a fashion analogous to RPL Storing Mode) whereas the SRVIO
installs a source-routing state at the ingress node, which uses that installs a source-routing state at the ingress node, which uses that
state to encapsulate a packet with an IPv6 Routing Header in a state to encapsulate a packet with an IPv6 Routing Header in a
fashion similar to RPL Non-Storing Mode. Like the TIO, the RPOs MUST fashion similar to RPL Non-Storing Mode. Like the TIO, the RPOs MUST
be preceded by exactly one RTO to which they apply, and they can be be preceded by exactly one RTO to which they apply, and they can be
factorized: multiple contiguous RPOs indicate alternate paths to the factorized: multiple contiguous RPOs indicate alternate paths to the
Target, more in Section 5.3. Target, more in Section 5.3.
This specification also introduces a new CMO to enable a RAN to This specification also introduces a new CMO to enable a RAN to
advertise (some of) its siblings to the Root, using a new Sibling advertise a selection of its candidate neighbors as siblings to the
Information Option (SIO) as specified in Section 5.4. Root, using a new Sibling Information Option (SIO) as specified in
Section 5.4.
4. Identifying a Path 4. Identifying a Path
It must be noted that RPL has a concept of Instance to represent It must be noted that RPL has a concept of Instance to represent
different routing topologies but does not have a concept of an different routing topologies but does not have a concept of an
administrative distance, which exists in certain proprietary administrative distance, which exists in certain proprietary
implementations to sort out conflicts between multiple sources of implementations to sort out conflicts between multiple sources of
routing information within one routing topology. This draft conforms routing information within one routing topology.
the Instance model as follows:
This draft conforms the Instance model as follows:
* If the PCE needs to influence a particular Instance to add better * If the PCE needs to influence a particular Instance to add better
routes in conformance with the routing objectives in that routes in conformance with the routing objectives in that
Instance, it may do so as long as it does not create a loop. A Instance, it may do so as long as it does not create a loop. A
Projected Route is always preferred over a route that is learned Projected Route is always preferred over a route that is learned
via RPL. via RPL.
* A PCE that installs a more specific (say, Traffic Engineered) and * A PCE that installs a more specific (say, Traffic Engineered) and
possibly complex path (aka a Track) towards a particular Target possibly complex path (aka a Track) towards a particular Target
MUST use a Local RPL Instance (see section 5 of [RFC6550]) MUST use a Local RPL Instance (see section 5 of [RPL]) associated
associated to that Target to identify the path. We refer to that to that Target to identify the path. We refer to that Local
Local RPLInstanceID as TrackID. A projected path is uniquely RPLInstanceID as TrackID. A projected path is uniquely identified
identified within the RPL domain by the tuple (Target address, within the RPL domain by the tuple (Target address, TrackID).
TrackID). When packet is placed on a Track, a RPL Packet When packet is placed on a Track, a RPL Packet Information (RPI)
Information (RPI) is added with the TrackID as RPLInstanceID. The is added with the TrackID as RPLInstanceID. The RPLInstanceID has
RPLInstanceID has the 'D' flag set, indicating that the the 'D' flag set, indicating that the destination address in the
destination address in the IPv6 header is the Target that is used IPv6 header is the Target that is used to identify the Track.
to identify the Track.
* A packet that is routed over a projected path MUST NOT be placed * A packet that is routed over a projected path MUST NOT be placed
over a different RPL Instance again. A packet that is placed on a over a different RPL Instance again. A packet that is placed on a
Global Instance MAY be injected in a Local Instance based on a Global Instance MAY be injected in a Local Instance based on a
network policy and the Local Instance configuration. network policy and the Local Instance configuration.
A Projected Route is a serial path that may the whole path or a A Projected Route is a serial path that may represent the end-to-end
segment in a complex Track, in which case multiple Projected Routes route or only a segment in a complex Track, in which case multiple
are installed with the same tuple (Target address, TrackID) and a Projected Routes are installed with the same tuple (Target address,
different segment ID. A node that is present on more than one TrackID) and a different segment ID. A node that is present on more
segment in a Track may be able to use either of the Projected Routes than one segment in a Track may be able to use either of the
to forward towards the Target. The selection of the best route in a Projected Routes to forward towards the Target. The selection of the
Track at forwarding time is out of scope for this document. [RAW-PS] best route in a Track at forwarding time is out of scope for this
elaborates on that particular problem. document, but [RAW-ARCHI] elaborates on that particular problem.
All properties of a Track operations are inherited form the main
instance that is used to install the Track. For instance, the use of
compression per [RFC8138] is determined by whether it is used in the
main instance, e.g., by setting the "T" flag [TURN-ON_RFC8138] in the
RPL configuration option.
5. New RPL Control Messages and Options 5. New RPL Control Messages and Options
5.1. New P-DAO Request Control Message 5.1. New P-DAO Request Control Message
The PDR is sent to the Root to request a new Path. Exactly one The PDR is sent to the Root to request a new Path. Exactly one
Target Options MUST be present. Target Options MUST be present.
The format of P-DAO Request (PDR) Base Object is as follows: The format of P-DAO Request (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 | PDRLifetime | PDRSequence | | TrackID |K|R| Flags | PDRLifetime | PDRSequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)... | Option(s)...
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 1: New P-DAO Request Format Figure 1: New P-DAO Request Format
TrackID: 8-bit field indicating the RPLInstanceID associated with TrackID: 8-bit field indicating the RPLInstanceID associated with
the Track. It is set to zero upon the first request for a new the Track. It is set to zero upon the first request for a new
Track and then to the TrackID once the Track was created, to Track and then to the TrackID once the Track was created, to
either renew it of destroy it. either renew it of destroy it.
K: The 'K' flag is set to indicate that the recipient is expected to K: The 'K' flag is set to indicate that the recipient is expected to
send a PDR-ACK back. send a PDR-ACK back.
skipping to change at page 8, line 35 skipping to change at page 8, line 42
R: The 'R' flag is set to indicate that the Requested path should be R: The 'R' flag is set to indicate that the Requested path should be
redundant. redundant.
PDRLifetime: 8-bit unsigned integer. The requested lifetime for the PDRLifetime: 8-bit unsigned integer. The requested lifetime for the
Track expressed in Lifetime Units (obtained from the Configuration Track expressed in Lifetime Units (obtained from the Configuration
option). A PDR with a fresher PDRSequence refreshes the lifetime, option). A PDR with a fresher PDRSequence refreshes the lifetime,
and a PDRLifetime of 0 indicates that the track should be and a PDRLifetime of 0 indicates that the track should be
destroyed. destroyed.
PDRSequence: 8-bit wrapping sequence number. The PDRSequence obeys PDRSequence: 8-bit wrapping sequence number. The PDRSequence obeys
the operation in section 7.2 of [RFC6550]. It is incremented at the operation in section 7.2 of [RPL]. It is incremented at each
each PDR message and echoed in the PDR-ACK by the Root. The PDR message and echoed in the PDR-ACK by the Root. The
PDRSequence is used to correlate a PDR-ACK message with the PDR PDRSequence is used to correlate a PDR-ACK message with the PDR
message that triggeted it. message that triggeted it.
5.2. New PDR-ACK Control Message 5.2. New PDR-ACK Control Message
The new PDR-ACK is sent as a response to a PDR message with the 'K' The new PDR-ACK is sent as a response to a PDR message with the 'K'
flag set. Its format is as follows: flag set. Its format 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 | PDR-ACK Status| Flags | Track Lifetime| | TrackID | PDR-ACK Status| Flags | Track Lifetime|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PDRSequence | Reserved | | PDRSequence | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)... | Option(s)...
+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+
Figure 2: New PDR-ACK Control Message Format Figure 2: New PDR-ACK Control Message Format
TrackID: The RPLInstanceID of the Track that was created. Set to 0 TrackID: The RPLInstanceID of the Track that was created. Set to 0
when no Track is created. when no Track is created.
PDR-ACK Status: Indicates the completion. Substructured as PDR-ACK Status: Indicates the completion. Substructured as
indicated in Figure 3. indicated in Figure 3.
Track Lifetime: Indicates that remaining Lifetime for the Track, 0 Track Lifetime: Indicates that remaining Lifetime for the Track, 0
skipping to change at page 11, line 16 skipping to change at page 11, line 16
Compression Type: 3-bit unsigned integer. This is the SRH-6LoRH Compression Type: 3-bit unsigned integer. This is the SRH-6LoRH
Type as defined in figure 7 in section 5.1 of [RFC8138] that Type as defined in figure 7 in section 5.1 of [RFC8138] that
corresponds to the compression used for all the Via Addresses. corresponds to the compression used for all the Via Addresses.
TrackID: 8-bit field indicating the topology Instance associated TrackID: 8-bit field indicating the topology Instance associated
with the Track. The tuple (Target Address, TrackID) forms a with the Track. The tuple (Target Address, TrackID) forms a
unique ID of the Track in the RPL domain. unique ID of the Track in the RPL domain.
Track Sequence: 8-bit unsigned integer. The Track Sequence obeys Track Sequence: 8-bit unsigned integer. The Track Sequence obeys
the operation in section 7.2 of [RFC6550] and the lollipop starts the operation in section 7.2 of [RPL] and the lollipop starts at
at 255. The Track Sequence is set by the Root and incremented 255. The Track Sequence is set by the Root and incremented each
each time the Root refreshes that Track globally. A Track time the Root refreshes that Track globally. A Track Sequence
Sequence that is fresher than the current on deprecates any state that is fresher than the current on deprecates any state for the
for the Track. A Track Sequence that is current adds to any state Track. A Track Sequence that is current adds to any state that
that was learned for that Track Sequence. A RTO with a Track was learned for that Track Sequence. A RTO with a Track Sequence
Sequence that is not as fresh as the current one is ignored. that is not as fresh as the current one is ignored.
Track Lifetime: 8-bit unsigned integer. The length of time in Track Lifetime: 8-bit unsigned integer. The length of time in
Lifetime Units (obtained from the Configuration option) that the Lifetime Units (obtained from the Configuration option) that the
Track is usable. The period starts when a new Track Sequence is Track is usable. The period starts when a new Track Sequence is
seen. A value of 255 (0xFF) represents infinity. A value of zero seen. A value of 255 (0xFF) represents infinity. A value of zero
(0x00) indicates a loss of reachability. A DAO message that (0x00) indicates a loss of reachability. A DAO message that
contains a Via Information option with a Path Lifetime of zero for contains a Via Information option with a Path Lifetime of zero for
a Target is referred as a No-Path (for that Target) in this a Target is referred as a No-Path (for that Target) in this
document. document.
SegmentID: 8-bit field that identifies a segment within a Track. A SegmentID: 8-bit field that identifies a segment within a Track. A
Value of 0 is used to signal a serial Track. Value of 0 is used to signal a serial Track.
Segment Sequence: 8-bit unsigned integer. The Segment Sequence Segment Sequence: 8-bit unsigned integer. The Segment Sequence
obeys the operation in section 7.2 of [RFC6550] and the lollipop obeys the operation in section 7.2 of [RPL] and the lollipop
starts at 255. When the Root of the DODAG needs to update a starts at 255. When the Root of the DODAG needs to update a
single segment in a Track, but does not need to modify the rest of single segment in a Track, but does not need to modify the rest of
the Track, it increments the Segment Sequence but not the Track the Track, it increments the Segment Sequence but not the Track
Sequence. The segment information indicated in the RTO deprecates Sequence. The segment information indicated in the RTO deprecates
any state for the segment indicated by the SegmentID within the any state for the segment indicated by the SegmentID within the
indicated Track and sets up the new information. A RTO with a indicated Track and sets up the new information. A RTO with a
Segment Sequence that is not as fresh as the current one is Segment Sequence that is not as fresh as the current one is
ignored. a RTO for a given target with the same (TrackID, Track ignored. a RTO for a given target with the same (TrackID, Track
Sequence, SegmentID, Segment Sequence) indicates a retry; it MUST Sequence, SegmentID, Segment Sequence) indicates a retry; it MUST
NOT change the segment and MUST be propagated or answered as the NOT change the segment and MUST be propagated or answered as the
skipping to change at page 12, line 22 skipping to change at page 12, line 25
5.4. Sibling Information Option 5.4. Sibling Information Option
The Sibling Information Option (SIO) provides indication on siblings The Sibling Information Option (SIO) provides indication on siblings
that could be used by the Root to form Projected Routes. The format that could be used by the Root to form Projected Routes. The format
of SIOs is as follows: of SIOs 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 |Comp.|B| Flags | Opaque | | Type | Option Length |Comp.|B|D|Flags| Opaque |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Step of Rank | Reserved | | Step of Rank | Sibling Rank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
. .
. Sibling DODAGID (if 'D' flag not set) .
. .
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
. . . .
. Sibling Address . . Sibling Address .
. . . .
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 12, line 46 skipping to change at page 13, line 9
Option Type: 0x0C (to be confirmed by IANA) Option Type: 0x0C (to be confirmed by IANA)
Option Length: In bytes; variable, depending on the number of Via Option Length: In bytes; variable, depending on the number of Via
Addresses. Addresses.
Compression Type: 3-bit unsigned integer. This is the SRH-6LoRH Compression Type: 3-bit unsigned integer. This is the SRH-6LoRH
Type as defined in figure 7 in section 5.1 of [RFC8138] that Type as defined in figure 7 in section 5.1 of [RFC8138] that
corresponds to the compression used for the Sibling Address. corresponds to the compression used for the Sibling Address.
Reserved for Flags: MUST be set to zero by the sender and MUST be
ignored by the receiver.
B: 1-bit flag that is set to indicate that the connectivity to the B: 1-bit flag that is set to indicate that the connectivity to the
sibling is bidirectional and roughly symmetrical. In that case, sibling is bidirectional and roughly symmetrical. In that case,
only one of the siblings may report the SIO for the hop. If 'B' only one of the siblings may report the SIO for the hop. If 'B'
is not set then the SIO only indicates connectivity from the is not set then the SIO only indicates connectivity from the
sibling to this node, and does not provide information on the hop sibling to this node, and does not provide information on the hop
from this node to the sibling. from this node to the sibling.
D: 1-bit flag that is set to indicate that sibling belongs to the
same DODAG. When not set, the Sibling DODAGID is indicated.
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 industraial Alliance that packets received from the sibling. An industraial Alliance that
uses RPL for a particular use / environment MAY redefine the use uses RPL for a particular use / environment MAY redefine the use
of this field to fit its needs. of this field to fit its needs.
Step of Rank: 16-bit unsigned integer. This is the Step of Rank Step of Rank: 16-bit unsigned integer. This is the Step of Rank
[RFC6550] as computed by the Objective Function between this node [RPL] as computed by the Objective Function between this node and
and the sibling. the sibling.
Reserved: MUST be set to zero by the sender and MUST be ignored by Sibling Rank: 16-bit unsigned integer. When non-zero, this is the
the receiver. Rank [RPL] as exposed by the sibling in DIO messages.
Sibling DODAGID: 2 to 16 bytes, the DODAGID of the sibling in a
[RFC8138] compressed form as indicated by the Compression Type
field. This field is present when the 'D' flag is not set.
Sibling Address: 2 to 16 bytes, the IPv6 Address of the sibling in a Sibling Address: 2 to 16 bytes, the IPv6 Address of the sibling in a
[RFC8138] compressed form as indicated by the Compression Type [RFC8138] compressed form as indicated by the Compression Type
field. field.
An SIO MAY be immediately followed by a DAG Metric Container. In An SIO MAY be immediately followed by a DAG Metric Container. In
that case the DAG Metric Container provides additional metrics for that case the DAG Metric Container provides additional metrics for
the hop from the Sibling to this node. the hop from the Sibling to this node.
6. Projected DAO 6. Projected DAO
skipping to change at page 13, line 48 skipping to change at page 14, line 24
A P-DAO is sent from a global address of the Root to a global address A P-DAO is sent from a global address of the Root to a global address
of the recipient, and MUST be confirmed by a DAO-ACK, which is sent of the recipient, and MUST be confirmed by a DAO-ACK, which is sent
back to a global address of the Root. back to a global address of the Root.
A P-DAO message MUST contain at least one RTO and at least one RPO A P-DAO message MUST contain at least one RTO and at least one RPO
following it. There can be at most one such sequence of RTOs and following it. There can be at most one such sequence of RTOs and
then RPOs. then RPOs.
Like a classical DAO message, a P-DAO causes a change of state only Like a classical DAO message, a P-DAO causes a change of state only
if it is "new" per section 9.2.2. "Generation of DAO Messages" of if it is "new" per section 9.2.2. "Generation of DAO Messages" of
the RPL specification [RFC6550]; this is determined using the Track the RPL specification [RPL]; this is determined using the Track
Sequence and the Segment Sequence information from the RPO as opposed Sequence and the Segment Sequence information from the RPO as opposed
to the Path Sequence from a TIO. Also, a Path Lifetime of 0 in an to the Path Sequence from a TIO. Also, a Path Lifetime of 0 in an
RPO indicates that a route is to be removed. RPO indicates that a route is to be removed.
There are two kinds of operation for the Projected Routes, the There are two kinds of operation for the Projected Routes, the
Storing Mode and the Non-Storing Mode. Storing Mode and the Non-Storing Mode.
* The Non-Storing Mode is discussed in Section 6.1. It uses an * The Non-Storing Mode is discussed in Section 6.1. It uses an
SRVIO that carries a list of Via Addresses to be used as a source- SRVIO that carries a list of Via Addresses to be used as a source-
routed path to the Target. The recipient of the P-DAO is the routed path to the Target. The recipient of the P-DAO is the
skipping to change at page 15, line 40 skipping to change at page 16, line 18
source routing and other mechanisms may effectively cause loops. In source routing and other mechanisms may effectively cause loops. In
order to avoid those loops, if the router that installs a Projected order to avoid those loops, if the router that installs a Projected
Route does not have a connected route (a direct adjacency) to the Route does not have a connected route (a direct adjacency) to the
next soure routed hop and fails to locate it as a neighbor or a next soure routed hop and fails to locate it as a neighbor or a
neighbor of a neighbor, then it MUST ensure that it has another neighbor of a neighbor, then it MUST ensure that it has another
Projected Route to the next loose hop under the control of the same Projected Route to the next loose hop under the control of the same
route computation system, otherwise the P-DAO is rejected. route computation system, otherwise the P-DAO is rejected.
When forwarding a packet to a destination for which the router When forwarding a packet to a destination for which the router
determines that routing happens via the Target, the router inserts determines that routing happens via the Target, the router inserts
the source routing header in the packet to reach the Target. In the the source routing header in the packet to reach the Target. In
case of a loose source-routed path, there MUST be either a neighbor order to add a source-routing header, the router encapsulates the
that is adjacent to the loose next hop, on which case the packet s
forwarded to that neighbor, or a source-routed path to the loose next
hop; in the latter case, another encapsulation takes place and the
process possibly recurses; otherwise the packet is dropped.
In order to add a source-routing header, the router encapsulates the
packet with an IP-in-IP header and a non-storing mode source routing packet with an IP-in-IP header and a non-storing mode source routing
header (SRH) [RFC6554]. In the uncompressed form the source of the header (SRH) [RFC6554]. In the uncompressed form the source of the
packet would be self, the destination would be the first Via Address packet would be self, the destination would be the first Via Address
in the SRVIO, and the SRH would contain the list of the remaining Via in the SRVIO, and the SRH would contain the list of the remaining Via
Addresses and then the Target. Addresses and then the Target.
In the case of a loose source-routed path, there MUST be either a
neighbor that is adjacent to the loose next hop, on which case the
packet is forwarded to that neighbor, or a source-routed path to the
loose next hop; in the latter case, another encapsulation takes place
and the process possibly recurses; otherwise the packet is dropped.
In practice, the router will normally use the "IPv6 over Low-Power In practice, the router will normally use the "IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Paging Dispatch" [RFC8025] Wireless Personal Area Network (6LoWPAN) Paging Dispatch" [RFC8025]
to compress the RPL artifacts as indicated in [RFC8138]. In that to compress the RPL artifacts as indicated in [RFC8138]. In that
case, the router indicates self as encapsulator in an IP-in-IP 6LoRH case, the router indicates self as encapsulator in an IP-in-IP 6LoRH
Header, and places the list of Via Addresses in the order of the VIO Header, and places the list of Via Addresses in the order of the VIO
and then the Target in the SRH 6LoRH Header. and then the Target in the SRH 6LoRH Header.
In case of a forwarding error along a Source Route path, the node In case of a forwarding error along a Source Route path, the node
that fails to forward SHOULD send an ICMP error with a code "Error in that fails to forward SHOULD send an ICMP error with a code "Error in
Source Routing Header" back to the source of the packet, as described Source Routing Header" back to the source of the packet, as described
in section 11.2.2.3. of [RFC6550]. Upon this message, the in section 11.2.2.3. of [RPL]. Upon this message, the encapsulating
encapsulating node SHOULD stop using the source route path for a node SHOULD stop using the source route path for a period of time and
period of time and it SHOULD send an ICMP message with a Code "Error it SHOULD send an ICMP message with a Code "Error in Projected Route"
in Projected Route" to the Root. Failure to follow these steps may to the Root. Failure to follow these steps may result in packet loss
result in packet loss and wasted resources along the source route and wasted resources along the source route path that is broken.
path that is broken.
6.2. Storing-Mode Projected Route 6.2. Storing-Mode Projected Route
As illustrated in Figure 7, the Storing Mode route projection is used As illustrated in Figure 7, the Storing Mode route projection is used
by the Root to install a routing state towards a Target in the by the Root to install a routing state towards a Target in the
routers along a segment between an ingress and an egress router; this routers along a segment between an ingress and an egress router; this
enables the routers to forward along that segment any packet for enables the routers to forward along that segment any packet for
which the next loose hop is the said Target, for Instance a loose which the next loose hop is the said Target, for Instance a loose
source routed packet for which the next loose hop is the Target, or a source routed packet for which the next loose hop is the Target, or a
packet for which the router has a routing state to the final packet for which the router has a routing state to the final
destination via the Target. destination via the Target.
------+--------- ------+---------
| Internet | Internet
| |
+-----+ +-----+
| | Border Router | | Border Router
| | (RPL Root) | | (RPL Root)
+-----+ | ^ | +-----+ | ^ |
| | 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 From Root To Destination v o o o o From Root To Destination v
Figure 7: Projecting a route Figure 7: 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
between an ingress and an egress routers, the Root sends a unicast between an ingress and an egress routers, the Root sends a unicast
P-DAO message to the egress router of the routing segment that must P-DAO message to the egress router of the routing segment that must
be installed. The P-DAO message contains the ordered list of hops be installed. The P-DAO message contains the ordered list of hops
along the segment as a direct sequence of Via Information options along the segment as a direct sequence of Via Information options
that are preceded by one or more RPL Target options to which they that are preceded by one or more RPL Target options to which they
relate. Each Via Information option contains a Path Lifetime for relate. Each Via Information option contains a Path Lifetime for
skipping to change at page 18, line 31 skipping to change at page 19, line 13
one. one.
In case of a forwarding error along a Storing Mode Projected Route, In case of a forwarding error along a Storing Mode Projected Route,
the node that fails to forward SHOULD send an ICMP error with a code the node that fails to forward SHOULD send an ICMP error with a code
"Error in Projected Route" to the Root. Failure to do so may result "Error in Projected Route" to the Root. Failure to do so may result
in packet loss and wasted resources along the Projected Route that is in packet loss and wasted resources along the Projected Route that is
broken. broken.
7. Security Considerations 7. Security Considerations
This draft uses messages that are already present in RPL [RFC6550] This draft uses messages that are already present in RPL [RPL] with
with optional secured versions. The same secured versions may be optional secured versions. The same secured versions may be used
used with this draft, and whatever security is deployed for a given with this draft, and whatever security is deployed for a given
network also applies to the flows in this draft. network also applies to the flows in this draft.
TODO: should probably consider how P-DAO messages could be abused by TODO: should probably consider how P-DAO messages could be abused by
a) rogue nodes b) via replay of messages c) if use of P-DAO messages a) rogue nodes b) via replay of messages c) if use of P-DAO messages
could in fact deal with any threats? could in fact deal with any threats?
8. IANA Considerations 8. IANA Considerations
8.1. New RPL Control Codes 8.1. New RPL Control Codes
skipping to change at page 22, line 28 skipping to change at page 22, line 49
IANA has defined an ICMPv6 "Code" Fields Registry for ICMPv6 Message IANA has defined an ICMPv6 "Code" Fields Registry for ICMPv6 Message
Types. ICMPv6 Message Type 1 describes "Destination Unreachable" Types. ICMPv6 Message Type 1 describes "Destination Unreachable"
codes. This specification requires that a new code is allocated from codes. This specification requires that a new code is allocated from
the ICMPv6 Code Fields Registry for ICMPv6 Message Type 1, for "Error the ICMPv6 Code Fields Registry for ICMPv6 Message Type 1, for "Error
in Projected Route", with a suggested code value of 8, to be in Projected Route", with a suggested code value of 8, to be
confirmed by IANA. confirmed by IANA.
9. Acknowledgments 9. Acknowledgments
The authors wish to acknowledge JP Vasseur, James Pylakutty and The authors wish to acknowledge JP Vasseur, Remy Liubing, James
Patrick Wetterwald for their contributions to the ideas developed Pylakutty and Patrick Wetterwald for their contributions to the ideas
here. developed here.
10. Normative References 10. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
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>.
[RFC6550] 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,
DOI 10.17487/RFC6550, March 2012, DOI 10.17487/RFC6550, March 2012,
<https://www.rfc-editor.org/info/rfc6550>. <https://www.rfc-editor.org/info/rfc6550>.
[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
Routing Header for Source Routes with the Routing Protocol Routing Header for Source Routes with the Routing Protocol
for Low-Power and Lossy Networks (RPL)", RFC 6554, for Low-Power and Lossy Networks (RPL)", RFC 6554,
DOI 10.17487/RFC6554, March 2012, DOI 10.17487/RFC6554, March 2012,
<https://www.rfc-editor.org/info/rfc6554>. <https://www.rfc-editor.org/info/rfc6554>.
[RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Paging Dispatch",
RFC 8025, DOI 10.17487/RFC8025, November 2016,
<https://www.rfc-editor.org/info/rfc8025>.
[RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,
"IPv6 over Low-Power Wireless Personal Area Network
(6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,
April 2017, <https://www.rfc-editor.org/info/rfc8138>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
11. Informative References 11. Informative References
skipping to change at page 23, line 49 skipping to change at page 24, line 12
DOI 10.17487/RFC6997, August 2013, DOI 10.17487/RFC6997, August 2013,
<https://www.rfc-editor.org/info/rfc6997>. <https://www.rfc-editor.org/info/rfc6997>.
[6TiSCH-ARCHI] [6TiSCH-ARCHI]
Thubert, P., "An Architecture for IPv6 over the TSCH mode Thubert, P., "An Architecture for IPv6 over the TSCH mode
of IEEE 802.15.4", Work in Progress, Internet-Draft, of IEEE 802.15.4", Work in Progress, Internet-Draft,
draft-ietf-6tisch-architecture-28, 29 October 2019, draft-ietf-6tisch-architecture-28, 29 October 2019,
<https://tools.ietf.org/html/draft-ietf-6tisch- <https://tools.ietf.org/html/draft-ietf-6tisch-
architecture-28>. architecture-28>.
[RAW-PS] Thubert, P. and G. Papadopoulos, "Reliable and Available [RAW-ARCHI]
Wireless Problem Statement", Work in Progress, Internet- Thubert, P. and G. Papadopoulos, "Reliable and Available
Draft, draft-pthubert-raw-problem-statement-04, 23 October Wireless Architecture/Framework", Work in Progress,
2019, <https://tools.ietf.org/html/draft-pthubert-raw- Internet-Draft, draft-pthubert-raw-architecture-01, 2
problem-statement-04>. April 2020, <https://tools.ietf.org/html/draft-pthubert-
raw-architecture-01>.
[TURN-ON_RFC8138]
Thubert, P. and L. Zhao, "Configuration option for RFC
8138", Work in Progress, Internet-Draft, draft-thubert-
roll-turnon-rfc8138-03, 8 July 2019,
<https://tools.ietf.org/html/draft-thubert-roll-turnon-
rfc8138-03>.
[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", RFC 8655, "Deterministic Networking Architecture", RFC 8655,
DOI 10.17487/RFC8655, October 2019, DOI 10.17487/RFC8655, October 2019,
<https://www.rfc-editor.org/info/rfc8655>. <https://www.rfc-editor.org/info/rfc8655>.
[RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Paging Dispatch",
RFC 8025, DOI 10.17487/RFC8025, November 2016,
<https://www.rfc-editor.org/info/rfc8025>.
[RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,
"IPv6 over Low-Power Wireless Personal Area Network
(6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,
April 2017, <https://www.rfc-editor.org/info/rfc8138>.
[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 Appendix A. Applications
A.1. Loose Source Routing in Non-storing Mode A.1. Loose Source Routing in Non-storing Mode
A RPL implementation operating in a very constrained LLN typically A RPL implementation operating in a very constrained LLN typically
uses the Non-Storing Mode of Operation as represented in Figure 8. uses the Non-Storing Mode of Operation as represented in Figure 8.
In that mode, a RPL node indicates a parent-child relationship to the In that mode, a RPL node indicates a parent-child relationship to the
Root, using a Destination Advertisement Object (DAO) that is unicast Root, using a Destination Advertisement Object (DAO) that is unicast
from the node directly to the Root, and the Root typically builds a from the node directly to the Root, and the Root typically builds a
source routed path to a destination down the DODAG by recursively source routed path to a destination down the DODAG by recursively
concatenating this information. concatenating this information.
skipping to change at page 30, line 48 skipping to change at page 31, line 48
S>>A>>>B>>C>>>D o o o S>>A>>>B>>C>>>D o o o
o o o o o o o o
LLN LLN
Figure 14: Projected Transversal Route Figure 14: Projected Transversal Route
Authors' Addresses Authors' Addresses
Pascal Thubert (editor) Pascal Thubert (editor)
Cisco Systems, Inc Cisco Systems, Inc
Building D, 45 Allee des Ormes - BP1200 Building D
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
Email: pthubert@cisco.com Email: pthubert@cisco.com
Rahul Arvind Jadhav Rahul Arvind Jadhav
Huawei Tech Huawei Tech
Kundalahalli Village, Whitefield, Kundalahalli Village, Whitefield,
Bangalore 560037 Bangalore 560037
Karnataka Karnataka
India India
skipping to change at page 31, line 18 skipping to change at page 32, line 19
Kundalahalli Village, Whitefield, Kundalahalli Village, Whitefield,
Bangalore 560037 Bangalore 560037
Karnataka Karnataka
India India
Phone: +91-080-49160700 Phone: +91-080-49160700
Email: rahul.ietf@gmail.com Email: rahul.ietf@gmail.com
Matthew Gillmore Matthew Gillmore
Itron, Inc Itron, Inc
Building D, 2111 N Molter Road Building D
2111 N Molter Road
Liberty Lake, 99019 Liberty Lake, 99019
United States United States
Phone: +1.800.635.5461 Phone: +1.800.635.5461
Email: matthew.gillmore@itron.com Email: matthew.gillmore@itron.com
 End of changes. 68 change blocks. 
218 lines changed or deleted 239 lines changed or added

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