< draft-ietf-roll-dao-projection-08.txt   draft-ietf-roll-dao-projection-09.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: 7 May 2020 M. Gillmore Expires: 20 May 2020 M. Gillmore
Itron Itron
4 November 2019 17 November 2019
Root initiated routing state in RPL Root initiated routing state in RPL
draft-ietf-roll-dao-projection-08 draft-ietf-roll-dao-projection-09
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 7 May 2020. This Internet-Draft will expire on 20 May 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Subset of a 6LoWPAN Glossary . . . . . . . . . . . . . . 4 2.2. Subset of a 6LoWPAN Glossary . . . . . . . . . . . . . . 4
2.3. Other Terms . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Other Terms . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. References . . . . . . . . . . . . . . . . . . . . . . . 5 2.4. References . . . . . . . . . . . . . . . . . . . . . . . 5
3. Extending RFC 6550 . . . . . . . . . . . . . . . . . . . . . 6 3. Extending 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 . . . . . . . . . . . . 7
5.1. New P-DAO Request Control Message . . . . . . . . . . . . 7 5.1. New P-DAO Request Control Message . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . 11 5.4. Sibling Information Option . . . . . . . . . . . . . . . 12
6. Projected DAO . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Projected DAO . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Non-Storing Mode Projected Route . . . . . . . . . . . . 14 6.1. Non-Storing Mode Projected Route . . . . . . . . . . . . 14
6.2. Storing-Mode Projected Route . . . . . . . . . . . . . . 16 6.2. Storing-Mode Projected Route . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8.1. New RPL Control Codes . . . . . . . . . . . . . . . . . . 18 8.1. New RPL Control Codes . . . . . . . . . . . . . . . . . . 18
8.2. New RPL Control Message Options . . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.4. New SubRegistry for the PDR-ACK Flags . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.6. New Subregistry for the PDR-ACK Rejection Status 8.6. New Subregistry for the PDR-ACK Rejection Status
values . . . . . . . . . . . . . . . . . . . . . . . . . 20 values . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.7. New SubRegistry for the Route Projection Options (RPO) 8.7. New SubRegistry for the Route Projection Options (RPO)
Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.8. New SubRegistry for the Sibling Information Option 8.8. New SubRegistry for the Sibling Information Option (SIO)
(SIO) Flags . . . . . . . . . . . . . . . . . . . . . . . 21 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.9. Error in Projected Route ICMPv6 Code . . . . . . . . . . 21 8.9. Error in Projected Route ICMPv6 Code . . . . . . . . . . 22
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
10. Normative References . . . . . . . . . . . . . . . . . . . . 22 10. Normative References . . . . . . . . . . . . . . . . . . . . 22
11. Informative References . . . . . . . . . . . . . . . . . . . 22 11. Informative References . . . . . . . . . . . . . . . . . . . 23
Appendix A. Applications . . . . . . . . . . . . . . . . . . . . 23 Appendix A. Applications . . . . . . . . . . . . . . . . . . . . 24
A.1. Loose Source Routing in Non-storing Mode . . . . . . . . 23 A.1. Loose Source Routing in Non-storing Mode . . . . . . . . 24
A.2. Transversal Routes in storing and non-storing A.2. Transversal Routes in storing and non-storing modes . . . 25
modes . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 27 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 27
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 . . . . 27
B.2. Projecting a storing-mode transversal route . . . . . . . 28 B.2. Projecting a storing-mode transversal route . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
RPL, the "Routing Protocol for Low Power and Lossy Networks" RPL, the "Routing Protocol for Low Power and Lossy Networks"
[RFC6550] (LLNs), is a generic Distance Vector protocol that is well [RFC6550] (LLNs), is a generic Distance Vector protocol that is well
suited for application in a variety of low energy Internet of Things suited for application in a variety of low energy Internet of Things
(IoT) networks. RPL forms Destination Oriented Directed Acyclic (IoT) networks. RPL forms Destination Oriented Directed Acyclic
Graphs (DODAGs) in which the Root often acts as the Border Router to Graphs (DODAGs) in which the Root often acts as the Border Router to
connect the RPL domain to the Internet. The Root is responsible to connect the RPL domain to the Internet. The Root is responsible to
select the RPL Instance that is used to forward a packet coming from select the RPL Instance that is used to forward a packet coming from
skipping to change at page 7, line 39 skipping to change at page 7, line 39
destination address in the IPv6 header is the Target that is used destination address in the 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 the whole path or a
segment in a complex Track, in which case multiple Projected Routes segment in a complex Track, in which case multiple Projected Routes
are installed with the stuple (Target address, TrackID), and a node are installed with the same tuple (Target address, TrackID) and a
that is present on more than one segment in a Track may be able to different segment ID. A node that is present on more than one
use either of the Projected Routes to forward towards the Target. segment in a Track may be able to use either of the Projected Routes
The selection of the best route in a Track at forwarding time is out to forward towards the Target. The selection of the best route in a
of scope for this document. [RAW-PS] elaborates on that particular Track at forwarding time is out of scope for this document. [RAW-PS]
problem. elaborates on that particular problem.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID |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 topology Instance associated TrackID: 8-bit field indicating the RPLInstanceID associated with
with the Track. It is set to zero upon the first request for a the Track. It is set to zero upon the first request for a new
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. The requested lifetime for the
Track expressed in Lifetime Units (obtained from the Configuration Track expressed in Lifetime Units (obtained from the Configuration
skipping to change at page 10, line 13 skipping to change at page 10, line 13
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. The Track is identified by a or a segment of a more complex Track. In the latter case, multiple
RPLInstanceID that is either Global or local to the Target of the RPO may be placed after a same Target Option. The Track is
Track. identified by a 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 |Comp.| Flags | TrackID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Lifetime | Path Sequence | Reserved | | Track Sequence| Track Lifetime| SegmentID |Segm. Sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
. . . .
. Via Address 1 . . Via Address 1 .
. . . .
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 11, line 12 skipping to change at page 11, line 12
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 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. with the Track. The tuple (Target Address, TrackID) forms a
unique ID of the Track in the RPL domain.
Path Lifetime: 8-bit unsigned integer. The length of time in Track Sequence: 8-bit unsigned integer. The Track Sequence obeys
the operation in section 7.2 of [RFC6550] and the lollipop starts
at 255. The Track Sequence is set by the Root and incremented
each time the Root refreshes that Track globally. A Track
Sequence that is fresher than the current on deprecates any state
for the Track. A Track Sequence that is current adds to any state
that was learned for that Track Sequence. A RTO with a Track
Sequence that is not as fresh as the current one is ignored.
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
prefix is valid for route determination. The period starts when a Track is usable. The period starts when a new Track Sequence is
new Path Sequence is seen. A value of 255 (0xFF) represents seen. A value of 255 (0xFF) represents infinity. A value of zero
infinity. A value of zero (0x00) indicates a loss of (0x00) indicates a loss of reachability. A DAO message that
reachability. A DAO message that contains a Via Information contains a Via Information option with a Path Lifetime of zero for
option with a Path Lifetime of zero for a Target is referred as a a Target is referred as a No-Path (for that Target) in this
No-Path (for that Target) in this document. document.
Path Sequence: 8-bit unsigned integer. When a RPL Target option is SegmentID: 8-bit field that identifies a segment within a Track. A
issued by the Root of the DODAG (i.e. in a DAO message), that Root Value of 0 is used to signal a serial Track.
sets the Path Sequence and increments the Path Sequence each time
it issues a RPL Target option with updated information. The Segment Sequence: 8-bit unsigned integer. The Segment Sequence
indicated sequence deprecates any state for a given Target that obeys the operation in section 7.2 of [RFC6550] and the lollipop
was learned from a previous sequence and adds to any state that starts at 255. When the Root of the DODAG needs to update a
was learned for that sequence. 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
Sequence. The segment information indicated in the RTO deprecates
any state for the segment indicated by the SegmentID within the
indicated Track and sets up the new information. A RTO with a
Segment Sequence that is not as fresh as the current one is
ignored. a RTO for a given target with the same (TrackID, Track
Sequence, SegmentID, Segment Sequence) indicates a retry; it MUST
NOT change the segment and MUST be propagated or answered as the
first copy.
Via Address: 2 to 16 bytes, a compressed IPv6 Address. A Via Via Address: 2 to 16 bytes, a compressed IPv6 Address. A Via
Address indicates the next hop within the path towards the Address indicates the next hop within the path towards the
destination(s) that is indicated in the Target option that destination(s) that is indicated in the Target option that
immediately precede the RPO in the DAO message. Via Addresses are 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. All Via addresses are expressed in the same size as
indicated by the Compression Type. indicated by the Compression Type.
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
skipping to change at page 13, line 16 skipping to change at page 13, line 32
[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 a projects a route by sending an extended DAO message called one or
Projected-DAO (P-DAO) to an arbitrary router in the DODAG, indicating more Projected-DAO (P-DAO) messages to an arbitrary router in the
one or more sequence(s) of routers inside the DODAG via which the DODAG, indicating one or more sequence(s) of routers inside the DODAG
Target(s) indicated in the RPL Target Option(s) (RTO) can be reached. via which the Target(s) indicated in the RPL Target Option(s) (RTO)
can 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 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 is processed only if it is Like a classical DAO message, a P-DAO causes a change of state only
"new" per section 9.2.2. "Generation of DAO Messages" of the RPL if it is "new" per section 9.2.2. "Generation of DAO Messages" of
specification [RFC6550]; this is determined using the Path Sequence the RPL specification [RFC6550]; this is determined using the Track
information from the RPO as opposed to a TIO. Also, a Path Lifetime Sequence and the Segment Sequence information from the RPO as opposed
of 0 in an RPO indicates that a route is to be removed. to the Path Sequence from a TIO. Also, a Path Lifetime of 0 in an
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
ingress router of the source-routed path. Upon a Non-Storing Mode ingress router of the source-routed path. Upon a Non-Storing Mode
P-DAO, the ingress router installs a source-routed state to the P-DAO, the ingress router installs a source-routed state to the
Target and replies to the Root directly with a DAO-ACK message. Target and replies to the Root directly with a DAO-ACK message.
skipping to change at page 23, line 33 skipping to change at page 24, line 12
Wireless Problem Statement", Work in Progress, Internet- Wireless Problem Statement", Work in Progress, Internet-
Draft, draft-pthubert-raw-problem-statement-04, 23 October Draft, draft-pthubert-raw-problem-statement-04, 23 October
2019, <https://tools.ietf.org/html/draft-pthubert-raw- 2019, <https://tools.ietf.org/html/draft-pthubert-raw-
problem-statement-04>. problem-statement-04>.
[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>.
[PCE] IETF, "Path Computation Element", November 2019, [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
 End of changes. 22 change blocks. 
57 lines changed or deleted 78 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/