< draft-ietf-roll-dao-projection-10.txt   draft-ietf-roll-dao-projection-11.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: 12 November 2020 M. Gillmore Expires: March 15, 2021 M. Gillmore
Itron Itron
11 May 2020 September 11, 2020
Root initiated routing state in RPL Root initiated routing state in RPL
draft-ietf-roll-dao-projection-10 draft-ietf-roll-dao-projection-11
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 12 November 2020. This Internet-Draft will expire on March 15, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2.2. References . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. References . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Other Terms . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Other Terms . . . . . . . . . . . . . . . . . . . . . . . 6
3. Updating 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 . . . . . . . . . . . . 8 5. New RPL Control Messages and Options . . . . . . . . . . . . 8
5.1. New P-DAO Request Control Message . . . . . . . . . . . . 8 5.1. New P-DAO Request Control Message . . . . . . . . . . . . 8
5.2. New PDR-ACK Control Message . . . . . . . . . . . . . . . 8 5.2. New PDR-ACK Control Message . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . . . . . . . 14 6. Projected DAO . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Non-Storing Mode Projected Route . . . . . . . . . . . . 15 6.1. Non-Storing Mode Projected Route . . . . . . . . . . . . 15
6.2. Storing-Mode Projected Route . . . . . . . . . . . . . . 17 6.2. Storing-Mode Projected Route . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8.1. New RPL Control Codes . . . . . . . . . . . . . . . . . . 19 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)
skipping to change at page 3, line 20 skipping to change at page 3, line 20
1. Introduction 1. Introduction
RPL, the "Routing Protocol for Low Power and Lossy Networks" [RPL] RPL, the "Routing Protocol for Low Power and Lossy Networks" [RPL]
(LLNs), is a generic Distance Vector protocol that is well suited for (LLNs), is a generic Distance Vector protocol that is well suited for
application in a variety of low energy Internet of Things (IoT) application in a variety of low energy Internet of Things (IoT)
networks. RPL forms Destination Oriented Directed Acyclic Graphs networks. RPL forms Destination Oriented Directed Acyclic Graphs
(DODAGs) in which the Root often acts as the Border Router to connect (DODAGs) in which the Root often acts as the Border Router to connect
the RPL domain to the Internet. The Root is responsible to select the RPL domain to the Internet. The Root is responsible to select
the RPL Instance that is used to forward a packet coming from the the RPL Instance that is used to forward a packet coming from the
Internet into the RPL domain and set the related RPL information in Internet into the RPL domain and set the related RPL information in
the packets. the packets. The "6TiSCH Architecture" [6TiSCH-ARCHI] uses RPL for
its routing operations.
The "6TiSCH architecture" [6TiSCH-ARCHI] leverages RPL for its The 6TiSCH Architecture also leverages the "Deterministic Networking
routing operations and considers the Deterministic Networking Architecture" [RFC8655] centralized model whereby the device
Architecture [RFC8655] as one possible model whereby the device
resources and capabilities are exposed to an external controller resources and capabilities are exposed to an external controller
which installs routing states into the network based on some which installs routing states into the network based on some
objective functions that reside in that external entity. With DetNet objective functions that reside in that external entity. With DetNet
and 6TiSCH, the component of the controller that is responsible of and 6TiSCH, the component of the controller that is responsible of
computing routes 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. This draft proposes a protocol expressed by the objective function.
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).
The 6TiSCH architecture also introduces the concept of a Track that This draft proposes protocol extensions to RPL that enable the Root
is a complex path with possibly redundant forwarding solutions along to install a limited amount of centrally-computed routes in a RPL
the way, exploiting Packet ARQ, Replication, Elimination, and graph, on behalf of a PCE that may be collocated or separated from
Overhearing (PAREO) functions. The "Reliable and Available Wireless the Root. Those extensions enable loose source routing down in RPL
(RAW) Architecture/Framework" [RAW-ARCHI] separates the time scale at Non-Storing Mode and transversal routes inside the DODAG regardless
which the PCE computes the Track (slow, globally optimized, with of the RPL Mode of Operation (MOP).
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 extensions enable 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 end-to-end path to a Target or a segment in a more complex alone end-to-end path to a Target or a segment in a more complex
forwarding graph called a Track.
The concept of a Track was introduced in the 6TiSCH architecture, as
a complex path with redundant forwarding solutions along the way. A
node that is present on more than one segment in a Track may be able
to use either of the Track segments to forward a packet towards the
Target.
The "Reliable and Available Wireless (RAW) Architecture/Framework"
[RAW-ARCHI] extends the the forward plane to leverage that redundancy
with the Packet ARQ, Replication, Elimination, and Overhearing
(PAREO) functions.
The RAW Architecture also discusses the dynamic selection of the best
path for a packet within a Track at forwarding time. To that effect,
it defines the Path Selection Engine (PSE), which is the counter-part
of the PCE to perform rapid local adjustments of the forwarding
tables within the path diversity that the PCE has selected for the
Track. Track.
RAW differentiates the time scale at which the PCE computes the Track
(slow, globally optimized, based on statistical metrics) and the time
scale at which the PSE makes the forwarding decision for a packet or
a small collection of packets (fast, but with a scope limited to the
Track). This provides a dynamic balance between the reliability and
availability requirements of the flows and the need to conserve
energy and spectrum.
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 the device
resources, and to limit the amount of rerouted traffic to fit within resources, and to maintain the amount of rerouted traffic within the
the capabilities of the transmission links. The method to learn the capabilities of the transmission links. The methods used to learn
node capabilities and the resources that are available in the devices the node capabilities and the resources that are available in the
and in the network are out of scope for this document. devices and in the network are out of scope for this document.
In RPL Non-Storing Mode, the Root has enough information to build a This specification expects that a base RPL Instance is operated in
basic DODAG topology. This document adds the capability for nodes to RPL Non-Storing Mode to sustain the exchanges with the Root. In that
advertise sibling information in order to improve the topological Mode, the Root has enough information to build a basic DODAG topology
awareness of the Root. This specification uses the RPL Root as a based on parents and children, but lacks the knowledge of siblings.
proxy to the PCE. The algorithm to compute the paths and the This document adds the capability for nodes to advertise sibling
protocol used by an external PCE to obtain the topology of the information in order to improve the topological awareness of the
network from the Root are out of scope for this document. Root.
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
Controller. In that case, the PCE exchanges control messages with
the Root over a Southbound API, that is out of scope for this
specification. The algorithm to compute the paths and the protocol
used by an external PCE to obtain the topology of the network from
the Root are also out of scope.
2. Terminology 2. Terminology
2.1. BCP 14 2.1. Requirements Language
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. References 2.2. References
In this document, readers will encounter terms and concepts that are In this document, readers will encounter terms and concepts that are
discussed in the following documents: discussed in the "Routing Protocol for Low Power and Lossy Networks"
[RPL] and "Terminology in Low power And Lossy Networks" [RFC7102].
* "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 2.3. 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 CMO: Control Message Option
DAD: Duplicate Address Detection
DAO: Destination Advertisement Object 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 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
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
skipping to change at page 6, line 9 skipping to change at page 6, line 5
RS: Router Solicitation RS: Router Solicitation
RPL: IPv6 Routing Protocol for LLNs [RPL] RPL: IPv6 Routing Protocol for LLNs [RPL]
RPO: A Route Projection Option; it can be a VIO or an SRVIO. RPO: A Route Projection Option; it can be a VIO or an SRVIO.
RTO: RPL Target Option RTO: RPL Target Option
SIO: RPL Sibling Information Option SIO: RPL Sibling Information Option
SRVIO: A Source-Routed Via Information Option, used in Non-Storing SRVIO: A Source-Routed Via Information Option, used in Non-Storing
Mode P-DAO messages. Mode P-DAO messages.
TIO: RPL Transit Information Option TIO: RPL Transit Information Option
VIO: A Via Information Option, used in Storing Mode P-DAO messages. VIO: A Via Information Option, used in Storing Mode P-DAO messages.
2.4. Other Terms
Projected Route: A Projected Route is a serial path or path segment
that is computed, installed and maintained 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.
3. Updating RFC 6550 3. Updating 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 Track from
self to a Target. A RAN may request the installation of a path by self to a Target. The RAN makes its request by sending a new P-DAO
sending a new P-DAO Request (PDR) Message to the Root. The Root Request (PDR) Message to the Root. The Root confirms with a new PDR-
confirms with a new PDR-ACK message back to the requester RAN with a ACK message back to the requester RAN, see Section 5.1 for more.
completion status once it is done installing the path. See
Section 5.1 for more.
Section 6.7 of [RPL] specifies the 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.
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 In Non-Storing Mode, the TIO option is used in the DAO message to
message. Options may be factorized; multiple TIOs may be present to inform the root of the parent-child relationships within the DODAG,
indicate multiple routes to the one or more contiguous addresses and the Root has a full knowledge of the DODAG structure. The TIO
indicated in the RTOs that immediately precede the TIOs in the RPL applies to the RTOs that preceed it immediately in the message.
message. Options may be factorized; multiple TIOs may be present to indicate
multiple routes to the one or more contiguous addresses indicated in
the RTOs that immediately precede the TIOs in the RPL message.
This specification introduces two new CMOs referred to as Route This specification introduces two new CMOs referred to as Route
Projection Options (RPO) to install Projected Routes. One RPO is the Projection Options (RPO) to install Projected Routes. One RPO is the
Via Information Option (VIO) and the other is the Source-Routed VIO Via Information Option (VIO) and the other is the Source-Routed VIO
(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.
be preceded by exactly one RTO to which they apply, and they can be
factorized: multiple contiguous RPOs indicate alternate paths to the Like the TIO, the RPOs MUST be preceded by exactly one RTO to which
Target, more in Section 5.3. they apply, and SRVIOs MAY be factorized, though VIOs MUST NOT be.
Factorized contiguous SRVIOs indicate alternate paths to the 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 a selection of its candidate neighbors as siblings to the advertise a selection of its candidate neighbors as siblings to the
Root, using a new Sibling Information Option (SIO) as specified in Root, using a new Sibling Information Option (SIO) as specified in
Section 5.4. 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
skipping to change at page 7, line 22 skipping to change at page 7, line 22
This draft conforms 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 (i.e., a Track) towards a particular Target
MUST use a Local RPL Instance (see section 5 of [RPL]) associated MUST use a Local RPL Instance (see section 5 of [RPL]) associated
to that Target to identify the path. We refer to that Local to that Target to identify the path.
RPLInstanceID as TrackID. A projected path is uniquely identified
within the RPL domain by the tuple (Target address, TrackID). We refer to that Local RPLInstanceID as TrackID. A TrackID MUST
be unique for a particular Target address. A Track is uniquely
identified within the RPL domain by the tuple (Target address,
TrackID).
When packet is placed on a Track, a RPL Packet Information (RPI) When packet is placed on a Track, a RPL Packet Information (RPI)
is added with the TrackID as RPLInstanceID. The RPLInstanceID has is added with the TrackID as RPLInstanceID. The RPLInstanceID has
the 'D' flag set, indicating that the destination address in the the 'D' flag set, indicating that the destination address in the
IPv6 header is the Target that is used to identify the Track. IPv6 header is the Target that is used to identify the Track.
* A packet that is routed over a projected path MUST NOT be placed * A packet that is routed over the RPL Instance associated to a
over a different RPL Instance again. A packet that is placed on a Track MUST NOT be placed over a different RPL Instance again.
Global Instance MAY be injected in a Local Instance based on a Conversely, a packet that is placed on a Global Instance MAY be
network policy and the Local Instance configuration. injected in a Local Instance based on a network policy and the
Local Instance configuration.
A Projected Route is a serial path that may represent the end-to-end A Projected Route is a serial path that may represent the end-to-end
route or only a segment in a complex Track, in which case multiple route or only a segment in a complex Track, in which case multiple
Projected Routes are installed with the same tuple (Target address, Projected Routes are installed with the same tuple (Target address,
TrackID) and a different segment ID. A node that is present on more TrackID) and a different segment ID each.
than one segment in a Track may be able to use either of the
Projected Routes to forward towards the Target. The selection of the
best route in a Track at forwarding time is out of scope for this
document, but [RAW-ARCHI] elaborates on that particular problem.
All properties of a Track operations are inherited form the main All properties of a Track operations are inherited form the main
instance that is used to install the Track. For instance, the use of 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 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 main instance, e.g., by setting the "T" flag [TURN-ON_RFC8138] in the
RPL configuration option. 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 P-DAO Request (PDR) message is sent to the Root to request a new
Target Options MUST be present. that the PCE establishes a new a projected route as a full path of a
collection of segments in a Track. Exactly one Target Options MUST
be present.
The format of P-DAO Request (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 | 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
skipping to change at page 8, line 35 skipping to change at page 8, line 37
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.
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.
Track expressed in Lifetime Units (obtained from the Configuration
option). A PDR with a fresher PDRSequence refreshes the lifetime,
and a PDRLifetime of 0 indicates that the track should be
destroyed.
PDRSequence: 8-bit wrapping sequence number. The PDRSequence obeys The requested lifetime for the Track expressed in Lifetime Units
the operation in section 7.2 of [RPL]. It is incremented at each (obtained from the DODAG Configuration option).
PDR message and echoed in the PDR-ACK by the Root. The
PDRSequence is used to correlate a PDR-ACK message with the PDR A PDR with a fresher PDRSequence refreshes the lifetime, and a
message that triggeted it. PDRLifetime of 0 indicates that the track should be destroyed.
PDRSequence: 8-bit wrapping sequence number, obeying the operation
in section 7.2 of [RPL].
The PDRSequence is used to correlate a PDR-ACK message with the
PDR message that triggeted it. It is incremented at each PDR
message and echoed in the PDR-ACK by the Root.
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 | Flags | Track Lifetime| PDRSequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PDRSequence | Reserved | | PDR-ACK Status| 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
indicated in Figure 3.
Track Lifetime: Indicates that remaining Lifetime for the Track, 0 Track Lifetime: Indicates that remaining Lifetime for the Track, 0
if the Track was destroyed or not created. if 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.
The PDR-ACK Status is further substructured as follows: PDR-ACK Status: 8-bit field indicating the completion.
The PDR-ACK Status is further substructured as indicated in
Figure 3.
0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|E|R| Value | |E|R| Value |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 3: PDR-ACK status Format Figure 3: PDR-ACK status Format
The PDR-ACK Status subfields are:
E: 1-bit flag. Set to indicate a rejection. When not set, a value E: 1-bit flag. Set to indicate a rejection. When not set, a value
of 0 indicates Success/Unqualified acceptance and other values of 0 indicates Success/Unqualified acceptance and other values
indicate "not an outright rejection". indicate "not an outright rejection".
R: 1-bit flag. Reserved, MUST be set to 0 by the sender and ignored R: 1-bit flag. Reserved, MUST be set to 0 by the sender and ignored
by the receiver. by the receiver.
Status Value: 6-bit unsigned integer. Values depedning on the Status Value: 6-bit unsigned integer. Values depending on the
setting of the 'E' flag as indicated respectively in Table 4 and setting of the 'E' flag as indicated respectively in Table 4 and
Table 5. Table 5.
5.3. Route Projection Options 5.3. Route Projection Options
The RPOs indicate a series of IPv6 addresses that can be compressed The RPOs indicate a series of IPv6 addresses that can be compressed
using the method defined in the "6LoWPAN Routing Header" [RFC8138] using the method defined in the "6LoWPAN Routing Header" [RFC8138]
specification using the address of the Root found in the DODAGID specification using the address of the Root found in the DODAGID
field of DIO messages as Compression Reference. field of DIO messages as Compression Reference.
An RPO indicates a Projected Route that can be a serial Track in full An RPO indicates a Projected Route that can be a serial Track in full
or a segment of a more complex Track. In the latter case, multiple or a segment of a more complex Track. In Non-Storing Mode, multiple
RPO may be placed after a same Target Option. The Track is RPO may be placed after a same Target Option to reflect different
identified by a TrackID that is a Local RPLInstanceID to the Target segments originated at this node. The Track is identified by a
of the Track. TrackID that is a Local RPLInstanceID to the Target of the Track.
The format of RPOs is as follows: The format of RPOs 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.| Flags | TrackID | | Type | Option Length |C| Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Track Sequence| Track Lifetime| SegmentID |Segm. Sequence | | TrackID | SegmentID |Segm. Sequence | Seg. Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
. . . .
. Via Address 1 . . Via Address 1 .
. . . .
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 10, line 48 skipping to change at page 10, line 48
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
. . . .
. Via Address n . . Via Address n .
. . . .
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Via Information option format Figure 4: Via Information option format (uncompressed form)
Option Type: 0x0A for VIO, 0x0B for SRVIO (to be confirmed by IANA) Option Type: 0x0A for VIO, 0x0B for SRVIO (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 C: 1-bit flag. Set to indicate that the following Via Addresses are
Type as defined in figure 7 in section 5.1 of [RFC8138] that expressed as one or more SRH-6LoRH as defined in section 5.1 of
corresponds to the compression used for all the Via Addresses. [RFC8138]. Figure 4 illustrates the case where the "C" flag is
not set, meaning that the Via Addresses are expressed in full 128
bits.
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 [RPL] and the lollipop starts at the operation in section 7.2 of [RPL] and the lollipop starts at
255. The Track Sequence is set by the Root and incremented each 255. The Track Sequence is set by the Root and incremented each
time the Root refreshes that Track globally. A Track Sequence time the Root refreshes that Track globally. A Track Sequence
that is fresher than the current on deprecates any state for the that is fresher than the current on deprecates any state for the
skipping to change at page 12, line 5 skipping to change at page 12, line 5
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
first copy. first copy.
Via Address: 2 to 16 bytes, a compressed IPv6 Address. A Via Via Address: The collection of Via Addresses along one segment,
Address indicates the next hop within the path towards the
destination(s) that is indicated in the Target option that
immediately precede the RPO in the DAO message. Via Addresses are
indicated in the order of the path from the ingress to the egress indicated in the order of the path from the ingress to the egress
nodes. All Via addresses are expressed in the same size as nodes. If the "C" flag is set, the fields Via Address 1 .. Via
indicated by the Compression Type. Address n in Figure 4 are replaced by one or more of the headers
illustrated in Fig. 6 of [RFC8138]. More than one SRH-6LoRH is
needed if the compression of the addresses change inside the
segment and different SRH-6LoRH Types are used.
An RPO MUST contain at least one Via Address, and a Via Address MUST An RPO MUST contain at least one Via Address, and a Via Address MUST
NOT be present more than once, otherwise the RPO MUST be ignored. NOT be present more than once, otherwise the RPO MUST be ignored.
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:
skipping to change at page 14, line 8 skipping to change at page 14, line 8
[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
This draft adds a capability to RPL whereby the Root of a DODAG This draft adds a capability to RPL whereby the Root of a DODAG
projects a route by sending an extended DAO message called one or projects a route by sending one or more extended DAO message called
more Projected-DAO (P-DAO) messages to an arbitrary router in the Projected-DAO (P-DAO) messages to an arbitrary router in the DODAG,
DODAG, indicating one or more sequence(s) of routers inside the DODAG indicating one or more sequence(s) of routers inside the DODAG via
via which the Target(s) indicated in the RPL Target Option(s) (RTO) which the Target(s) indicated in the RPL Target Option(s) (RTO) can
can be reached. be reached.
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 exactly one RTO and either one VIO or
following it. There can be at most one such sequence of RTOs and one or more SRVIOs following it. There can be at most one such
then RPOs. sequence of RTOs and 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 [RPL]; 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.
skipping to change at page 19, line 29 skipping to change at page 19, line 29
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
This document extends the IANA Subregistry created by RFC 6550 for This document extends the IANA Subregistry created by RFC 6550 for
RPL Control Codes as indicated in Table 1: RPL Control Codes as indicated in Table 1:
+------+-----------------------------+---------------+ +======+=============================+===============+
| Code | Description | Reference | | Code | Description | Reference |
+======+=============================+===============+ +======+=============================+===============+
| 0x09 | Projected DAO Request (PDR) | This document | | 0x09 | Projected DAO Request (PDR) | This document |
+------+-----------------------------+---------------+ +------+-----------------------------+---------------+
| 0x0A | PDR-ACK | This document | | 0x0A | PDR-ACK | This document |
+------+-----------------------------+---------------+ +------+-----------------------------+---------------+
Table 1: New RPL Control Codes Table 1: New RPL Control Codes
8.2. New RPL Control Message Options 8.2. New RPL Control Message Options
This document extends the IANA Subregistry created by RFC 6550 for This document extends the IANA Subregistry created by RFC 6550 for
RPL Control Message Options as indicated in Table 2: RPL Control Message Options as indicated in Table 2:
+-------+--------------------------------------+---------------+ +=======+======================================+===============+
| Value | Meaning | Reference | | Value | Meaning | Reference |
+=======+======================================+===============+ +=======+======================================+===============+
| 0x0B | Via Information option | This document | | 0x0B | Via Information option | This document |
+-------+--------------------------------------+---------------+ +-------+--------------------------------------+---------------+
| 0x0C | Source-Routed Via Information option | This document | | 0x0C | Source-Routed Via Information option | This document |
+-------+--------------------------------------+---------------+ +-------+--------------------------------------+---------------+
| 0x0D | Sibling Information option | This document | | 0x0D | Sibling Information option | This document |
+-------+--------------------------------------+---------------+ +-------+--------------------------------------+---------------+
Table 2: RPL Control Message Options Table 2: RPL Control Message Options
skipping to change at page 20, line 32 skipping to change at page 20, line 32
* Bit number (counting from bit 0 as the most significant bit) * Bit number (counting from bit 0 as the most significant bit)
* 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 3: allocation is as indicated in Table 3:
+------------+------------------------+---------------+ +============+========================+===============+
| Bit number | Capability description | Reference | | Bit number | Capability description | Reference |
+============+========================+===============+ +============+========================+===============+
| 0 | PDR-ACK request (K) | This document | | 0 | PDR-ACK request (K) | This document |
+------------+------------------------+---------------+ +------------+------------------------+---------------+
| 1 | Requested path should | This document | | 1 | Requested path should | This document |
| | be redundant (R) | | | | be redundant (R) | |
+------------+------------------------+---------------+ +------------+------------------------+---------------+
Table 3: Initial PDR Flags Table 3: Initial PDR Flags
skipping to change at page 21, line 20 skipping to change at page 21, line 20
Acceptance Status values. Acceptance Status values.
* Possible values are 6-bit unsigned integers (0..63). * Possible values are 6-bit unsigned integers (0..63).
* Registration procedure is "Standards Action" [RFC8126]. * Registration procedure is "Standards Action" [RFC8126].
* Initial allocation is as indicated in Table 4: * Initial allocation is as indicated in Table 4:
+-------+------------------------+---------------+ +-------+------------------------+---------------+
| Value | Meaning | Reference | | Value | Meaning | Reference |
+=======+========================+===============+ +-------+------------------------+---------------+
| 0 | Unqualified acceptance | This document | | 0 | Unqualified acceptance | This document |
+-------+------------------------+---------------+ +-------+------------------------+---------------+
Table 4: Acceptance values of the PDR-ACK Status Table 4: Acceptance values of the PDR-ACK Status
8.6. New Subregistry for the PDR-ACK Rejection Status values 8.6. New Subregistry for the PDR-ACK Rejection Status values
IANA is requested to create a new subregistry for the PDR-ACK IANA is requested to create a new subregistry for the PDR-ACK
Rejection Status values. Rejection Status values.
* Possible values are 6-bit unsigned integers (0..63). * Possible values are 6-bit unsigned integers (0..63).
* Registration procedure is "Standards Action" [RFC8126]. * Registration procedure is "Standards Action" [RFC8126].
* Initial allocation is as indicated in Table 5: * Initial allocation is as indicated in Table 5:
+-------+-----------------------+---------------+ +-------+-----------------------+---------------+
| Value | Meaning | Reference | | Value | Meaning | Reference |
+=======+=======================+===============+ +-------+-----------------------+---------------+
| 0 | Unqualified rejection | This document | | 0 | Unqualified rejection | This document |
+-------+-----------------------+---------------+ +-------+-----------------------+---------------+
Table 5: Rejection values of the PDR-ACK Status Table 5: Rejection values of the PDR-ACK Status
8.7. New SubRegistry for the Route Projection Options (RPO) Flags 8.7. New SubRegistry for the Route Projection Options (RPO) Flags
IANA is requested to create a new subregistry for the 5-bit Route IANA is requested to create a new subregistry for the 5-bit Route
Projection Options (RPO) Flags field. Each bit is tracked with the Projection Options (RPO) Flags field. Each bit is tracked with the
following qualities: following qualities:
skipping to change at page 22, line 26 skipping to change at page 22, line 26
* Bit number (counting from bit 0 as the most significant bit) * Bit number (counting from bit 0 as the most significant bit)
* 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 6: allocation is as indicated in Table 6:
+------------+-----------------------------------+---------------+ +============+===================================+===============+
| Bit number | Capability description | Reference | | Bit number | Capability description | Reference |
+============+===================================+===============+ +============+===================================+===============+
| 0 | Connectivity is bidirectional (B) | This document | | 0 | Connectivity is bidirectional (B) | This document |
+------------+-----------------------------------+---------------+ +------------+-----------------------------------+---------------+
Table 6: Initial SIO Flags Table 6: Initial SIO Flags
8.9. Error in Projected Route ICMPv6 Code 8.9. Error in Projected Route ICMPv6 Code
In some cases RPL will return an ICMPv6 error message when a message In some cases RPL will return an ICMPv6 error message when a message
skipping to change at page 24, line 8 skipping to change at page 24, line 8
[RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and
J. Martocci, "Reactive Discovery of Point-to-Point Routes J. Martocci, "Reactive Discovery of Point-to-Point Routes
in Low-Power and Lossy Networks", RFC 6997, in Low-Power and Lossy Networks", RFC 6997,
DOI 10.17487/RFC6997, August 2013, DOI 10.17487/RFC6997, August 2013,
<https://www.rfc-editor.org/info/rfc6997>. <https://www.rfc-editor.org/info/rfc6997>.
[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-29, August 27, 2020,
<https://tools.ietf.org/html/draft-ietf-6tisch- <https://tools.ietf.org/html/draft-ietf-6tisch-
architecture-28>. architecture-29>.
[RAW-ARCHI] [RAW-ARCHI]
Thubert, P. and G. Papadopoulos, "Reliable and Available Thubert, P., Papadopoulos, G., and R. Buddenberg,
Wireless Architecture/Framework", Work in Progress, "Reliable and Available Wireless Architecture/Framework",
Internet-Draft, draft-pthubert-raw-architecture-01, 2 Work in Progress, Internet-Draft, draft-pthubert-raw-
April 2020, <https://tools.ietf.org/html/draft-pthubert- architecture-04, July 6, 2020,
raw-architecture-01>. <https://tools.ietf.org/html/draft-pthubert-raw-
architecture-04>.
[TURN-ON_RFC8138] [TURN-ON_RFC8138]
Thubert, P. and L. Zhao, "Configuration option for RFC Thubert, P. and L. Zhao, "Configuration option for RFC
8138", Work in Progress, Internet-Draft, draft-thubert- 8138", Work in Progress, Internet-Draft, draft-thubert-
roll-turnon-rfc8138-03, 8 July 2019, roll-turnon-rfc8138-03, July 8, 2019,
<https://tools.ietf.org/html/draft-thubert-roll-turnon- <https://tools.ietf.org/html/draft-thubert-roll-turnon-
rfc8138-03>. 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 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Paging Dispatch", Wireless Personal Area Network (6LoWPAN) Paging Dispatch",
 End of changes. 58 change blocks. 
150 lines changed or deleted 178 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/