draft-ietf-roll-dao-projection-01.txt   draft-ietf-roll-dao-projection-02.txt 
ROLL P. Thubert, Ed. ROLL P. Thubert, Ed.
Internet-Draft J. Pylakutty Internet-Draft J. Pylakutty
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: September 11, 2017 March 10, 2017 Expires: March 23, 2018 September 19, 2017
Root initiated routing state in RPL Root initiated routing state in RPL
draft-ietf-roll-dao-projection-01 draft-ietf-roll-dao-projection-02
Abstract Abstract
This document proposes a protocol extension to RPL that enables to This document proposes a protocol extension to RPL that enables to
install a limited amount of centrally-computed routes in a RPL graph, install a limited amount of centrally-computed routes in a RPL graph,
enabling loose source routing down a non-storing mode DODAG, or enabling loose source routing down a non-storing mode DODAG, or
transversal routes inside the DODAG. As opposed to the classical transversal routes inside the DODAG. As opposed to the classical
route injection in RPL that are injected by the end devices, this route injection in RPL that are injected by the end devices, this
draft enables the root of the DODAG to projects the routes that are draft enables the root of the DODAG to projects the routes that are
needed on the nodes where they should be installed. needed on the nodes where they should be installed.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 http://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 September 11, 2017. This Internet-Draft will expire on March 23, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
skipping to change at page 2, line 23 skipping to change at page 2, line 23
4. Projected DAO . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Projected DAO . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Non-storing Mode Projected DAO . . . . . . . . . . . . . 6 4.1. Non-storing Mode Projected DAO . . . . . . . . . . . . . 6
4.2. Storing-Mode Projected DAO . . . . . . . . . . . . . . . 8 4.2. Storing-Mode Projected DAO . . . . . . . . . . . . . . . 8
5. Applications . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Applications . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Loose Source Routing in Non-storing Mode . . . . . . . . 10 5.1. Loose Source Routing in Non-storing Mode . . . . . . . . 10
5.2. Transversal Routes in storing and non-storing modes . . . 11 5.2. Transversal Routes in storing and non-storing modes . . . 11
6. RPL Instances . . . . . . . . . . . . . . . . . . . . . . . . 13 6. RPL Instances . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 15 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 16
A.1. Using storing mode P-DAO in non-storing mode MOP . . . . 16 A.1. Using storing mode P-DAO in non-storing mode MOP . . . . 16
A.2. Projecting a storing-mode transversal route . . . . . . . 17 A.2. Projecting a storing-mode transversal route . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
The Routing Protocol for Low Power and Lossy Networks (LLN)(RPL) The "Routing Protocol for Low Power and Lossy Networks" [RFC6550]
[RFC6550] is a generic Distance Vector protocol that is well suited (LLN)(RPL) is a generic Distance Vector protocol that is well suited
for application in a variety of low energy Internet of Things (IoT) for 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 [I-D.ietf-6tisch-architecture] leverages RPL The 6TiSCH architecture [I-D.ietf-6tisch-architecture] leverages RPL
for its routing operation and considers the Deterministic Networking for its routing operation and considers the Deterministic Networking
skipping to change at page 3, line 29 skipping to change at page 3, line 29
projected routes is different from that of the other routes in the projected routes is different from that of the other routes in the
instance. instance.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The Terminology used in this document is consistent with and The Terminology used in this document is consistent with and
incorporates that described in `Terminology in Low power And Lossy incorporates that described in "Terminology in Low power And Lossy
Networks' [RFC7102] and [RFC6550]. Networks"[RFC7102] and [RFC6550].
3. New RPL Control Message Options 3. New RPL Control Message Options
Section 6.7 of [RFC6550] specifies Control Message Options (CMO) to Section 6.7 of RPL [RFC6550] specifies Control Message Options (CMO)
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 and the Transit Object (DAO) message. The RPL Target Option and the Transit
Information Option (TIO) are such options; the former indicates a Information Option (TIO) are such options; the former indicates a
node to be reached and the latter specifies a parent that can be used node to be reached and the latter specifies a parent that can be used
to reach that node. Options may be factorized; one or more to reach that node. Options may be factorized; one or more
contiguous TIOs apply to the one or more contiguous Target options contiguous TIOs apply to the one or more contiguous Target options
that immediately precede the TIOs in the RPL message. that immediately precede the TIOs in the RPL message.
This specification introduces a new Control Message Option, the Via This specification introduces a new Control Message Option, the Via
Information option (VIO). Like the TIO, the VIO MUST be preceded by Information option (VIO). Like the TIO, the VIO MUST be preceded by
one or more RPL Target options to which it applies. Unlike the TIO, one or more RPL Target options to which it applies. Unlike the TIO,
skipping to change at page 6, line 21 skipping to change at page 6, line 21
The root is expected to use these mechanisms optimally and with The root is expected to use these mechanisms optimally and with
required parsimony to limit the state installed in the devices to fit required parsimony to limit the state installed in the devices to fit
within their resources, but how the root figures the amount of within their resources, but how the root figures the amount of
resources that is available in each device is out of scope for this resources that is available in each device is out of scope for this
document. document.
In particular, the draft expects that the root has enough information In particular, the draft expects that the root has enough information
about the capability for each node to store a number of routes, which about the capability for each node to store a number of routes, which
can be discovered for instance using a Network Management System can be discovered for instance using a Network Management System
(NMS) and/or the RPL routing extensions specified in Routing for Path (NMS) and/or the RPL routing extensions specified in "Routing for
Calculation in LLNs [RFC6551]. Path Calculation in LLNs" [RFC6551].
A route that is installed by a P-DAO is not necessarily installed A route that is installed by a P-DAO is not necessarily installed
along the DODAG, though how the root and the optional PCE obtain the along the DODAG, though how the root and the optional PCE obtain the
additional topological information to compute other routes is out of additional topological information to compute other routes is out of
scope for this document scope for this document
4.1. Non-storing Mode Projected DAO 4.1. Non-storing Mode Projected DAO
As illustrated in Figure 2, the non-storing mode P-DAO enables the As illustrated in Figure 2, the non-storing mode P-DAO enables the
root to install a source-routed path towards a target in any root to install a source-routed path towards a target in any
skipping to change at page 7, line 25 skipping to change at page 7, line 25
o o o o o o o o o o | Source . Path o o o o o o o o o o | Source . Path
o o o o o o o o o | Route . From o o o o o o o o o | Route . From
o o o o o o o o | Path . Root o o o o o o o o | Path . Root
o o o o o target V . To o o o o o target V . To
o o o o | Desti- o o o o | Desti-
o o o o | nation o o o o | nation
destination V destination V
LLN LLN
Figure 2: Projecting a non-storing route Figure 2: Projecting a Non-Storing route
A router that receives a non-storing P-DAO installs a source routed A router that receives a non-storing P-DAO installs a source routed
path towards each of the consecutive targets via a source route path path towards each of the consecutive targets via a source route path
indicated in the following VIO. indicated in the following VIO.
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. the source routing header in the packet to reach the target.
In order to do so, the router encapsulates the packet with an IP in In order to do so, the router encapsulates the packet with an IP in
IP header and a non-storing mode source routing header (SRH) IP header and a non-storing mode source routing header (SRH)
[RFC6554]. [RFC6554].
In the uncompressed form the source of the packet would be self, the In the uncompressed form the source of the packet would be self, the
destination would be the first Via Address in the VIO, and the SRH destination would be the first Via Address in the VIO, and the SRH
would contain the list of the remaining Via Addresses and then the would contain the list of the remaining Via Addresses and then the
target. target.
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] to Wireless Personal Area Network (6LoWPAN) Paging Dispatch" [RFC8025]
compress the RPL artifacts as indicated in the 6LoWPAN Routing Header to compress the RPL artifacts as indicated in the "6LoWPAN Routing
[I-D.ietf-roll-routing-dispatch] specification. In that case, the Header" [RFC8138] specification. In that case, the router indicates
router indicates self as encapsulator in an IP-in-IP 6LoRH Header, self as encapsulator in an IP-in-IP 6LoRH Header, and places the list
and places the list of Via Addresses in the order of the VIO and then of Via Addresses in the order of the VIO and then the target in the
the target in the SRH 6LoRH Header. SRH 6LoRH Header.
4.2. Storing-Mode Projected DAO 4.2. Storing-Mode Projected DAO
As illustrated in Figure 3, the storing mode P-DAO enables the root As illustrated in Figure 3, the storing mode P-DAO enables the root
to install a routing state towards a target in the routers along a to install a routing state towards a target in the routers along a
segment between an ingress and an egress router; this enables the segment between an ingress and an egress router; this enables the
routers to forward along that segment any packet for which the next routers to forward along that segment any packet for which the next
loose hop is the said target, for instance a loose source routed loose hop is the said target, for instance a loose source routed
packet for which the next loose hop is the target, or a packet for packet for which the next loose hop is the target, or a packet for
which the router has a routing state to the final destination via the which the router has a routing state to the final destination via the
target. target.
------+--------- ------+---------
| Internet | Internet
| |
+-----+ +-----+
| | Border Router | | Border Router
| | (RPL Root) | | (RPL Root)
+-----+ | ^ | +-----+ | ^ |
| | DAO | ACK | | | DAO | ACK |
o o o o | | | Loose o o o o | | |
o o o o o o o o o | ^ | Source 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 o o o o LLN o o o |
o o o o o Loose Source Route Path |
LLN o o o o From Root To Destination v
Figure 3: Projecting a route Figure 3: Projecting a route
Based on available topological, usage and capabilities node Based on available topological, usage and capabilities node
information, the root or an associated PCE computes which segment information, the root or an associated PCE computes which segment
should be optimized and which relevant state should be installed in should be optimized and which relevant state should be installed in
which nodes. The algorithm is out of scope but it is envisaged that which nodes. The algorithm is out of scope but it is envisaged that
the root could compute the ratio between the optimal path (existing the root could compute the ratio between the optimal path (existing
path not traversing the root, and the current path), the application path not traversing the root, and the current path), the application
service level agreement (SLA) for specific flows that could benefit service level agreement (SLA) for specific flows that could benefit
skipping to change at page 10, line 22 skipping to change at page 10, line 22
the state. The P-DAO is forwarded as described above, but the DAO is the state. The P-DAO is forwarded as described above, but the DAO is
interpreted as a No-Path DAO and results in cleaning up existing interpreted as a No-Path DAO and results in cleaning up existing
state as opposed to refreshing an existing one or installing a new state as opposed to refreshing an existing one or installing a new
one. one.
5. Applications 5. Applications
5.1. Loose Source Routing in Non-storing Mode 5.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 whereby a RPL node indicates a uses the Non-Storing Mode of Operation as represented in Figure 4.
parent-child relationship to the root, using a Destination In that mode, a RPL node indicates a parent-child relationship to the
Advertisement Object (DAO) that is unicast from the node directly to root, using a Destination Advertisement Object (DAO) that is unicast
the root, and the root typically builds a source routed path to a from the node directly to the root, and the root typically builds a
destination down the DODAG by recursively concatenating this source routed path to a destination down the DODAG by recursively
information. concatenating this information.
------+--------- ------+---------
| Internet | Internet
| |
+-----+ +-----+
| | Border Router | | Border Router
| | (RPL Root) | | (RPL Root)
+-----+ ^ | | +-----+ ^ | |
| | DAO | ACK | | | DAO | ACK |
o o o o | | | Strict o o o o | | | Strict
skipping to change at page 12, line 39 skipping to change at page 12, line 39
^ o o v o o o o o ^ o o v o o o o o
S o o o D o o o S o o o D o o o
o o o o o o o o
LLN LLN
Figure 5: Routing Stretch between S and D via common parent X Figure 5: Routing Stretch between S and D via common parent X
It results that it is often beneficial to enable transversal P2P It results that it is often beneficial to enable transversal P2P
routes, either if the RPL route presents a stretch from shortest routes, either if the RPL route presents a stretch from shortest
path, or if the new route is engineered with a different objective. path, or if the new route is engineered with a different objective.
For that reason, earlier work at the IETF introduced the Reactive For that reason, earlier work at the IETF introduced the "Reactive
Discovery of Point-to-Point Routes in Low Power and Lossy Networks Discovery of Point-to-Point Routes in Low Power and Lossy Networks"
[RFC6997], which specifies a distributed method for establishing [RFC6997], which specifies a distributed method for establishing
optimized P2P routes. This draft proposes an alternate based on a optimized P2P routes. This draft proposes an alternate based on a
centralized route computation. centralized route computation.
------+--------- ------+---------
| Internet | Internet
| |
+-----+ +-----+
| | Border Router | | Border Router
| | (RPL Root) | | (RPL Root)
skipping to change at page 13, line 37 skipping to change at page 13, line 37
would be installed in a network that uses classical RPL for would be installed in a network that uses classical RPL for
asynchronous data collection. In that case, the P2P path may be asynchronous data collection. In that case, the P2P path may be
installed in a different RPL Instance, with a different objective installed in a different RPL Instance, with a different objective
function. function.
6. RPL Instances 6. RPL Instances
It must be noted that RPL has a concept of instance but does not have It must be noted that RPL has a concept of instance but does not have
a concept of an administrative distance, which exists in certain a concept of an administrative distance, which exists in certain
proprietary implementations to sort out conflicts between multiple proprietary implementations to sort out conflicts between multiple
sources. This draft conforms the instance model as follows: sources of routing information. This draft conforms the instance
model as follows:
o if the PCE needs to influence a particular instance to add better o 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. When the PCE modifies an existing instance, it may do so. When the PCE modifies an existing
instance then the added routes must not create a loop in that instance then the added routes must not create a loop in that
instance. This is achieved by always preferring a route obtained instance. This is achieved by always preferring a route obtained
from the PCE over a route that is learned via RPL. from the PCE over a route that is learned via RPL.
o If the PCE installs a more specific (Traffic Engineering) route o If the PCE installs a more specific (say, Traffic Engineered)
between a particular pair of nodes then it should use a Local route between a particular pair of nodes then it SHOULD use a
Instance from the ingress node of that path. Only packets Local Instance from the ingress node of that path. A packet
associated with that instance will be routed along that path. associated with that instance will be routed along that path and
MUST NOT be placed over a Global Instance again. A packet that is
placed on a Global Instance may be injected in the Local Instance
based on node policy and the Local Instance paramenters.
In all cases, the path is indicated by a new Via Information option, In all cases, the path is indicated by a new Via Information option,
and the flow is similar to the flow used to obtain loose source and the flow is similar to the flow used to obtain loose source
routing. routing.
7. Security Considerations 7. Security Considerations
This draft uses messages that are already present in [RFC6550] with This draft uses messages that are already present in RPL [RFC6550]
optional secured versions. The same secured versions may be used with optional secured versions. The same secured versions may be
with this draft, and whatever security is deployed for a given used 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.
8. IANA Considerations 8. IANA Considerations
This document updates the IANA registry for the Mode of Operation This document extends the IANA registry created by RFC 6550 for RPL
(MOP) Control Codes as follows:
4: Non-Storing with Projected routes [this] +------+-------------+---------------+
| Code | Description | Reference |
+------+-------------+---------------+
| 0x0A | Via | This document |
+------+-------------+---------------+
This document updates IANA registry for the RPL Control Message RPL Control Codes
Options
0x0A: Via descriptor [this] This document is updating the registry created by RFC 6550 for the
RPL 3-bit Mode of Operation (MOP) as follows:
+----------+------------------------------------------+-------------+
| MOP | Description | Reference |
| value | | |
+----------+------------------------------------------+-------------+
| 5 | Non-Storing mode of operation with | This |
| | Projected routes | document |
| | | |
| 6 | Storing mode of operation with Projected | This |
| | routes | document |
+----------+------------------------------------------+-------------+
DIO Mode of operation
9. Acknowledgments 9. Acknowledgments
The authors wish to acknowledge JP Vasseur and Patrick Wetterwald for The authors wish to acknowledge JP Vasseur and Patrick Wetterwald for
their contributions to the ideas developed here. their contributions to the ideas developed here.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-roll-routing-dispatch]
Thubert, P., Bormann, C., Toutain, L., and R. Cragie,
"6LoWPAN Routing Header", draft-ietf-roll-routing-
dispatch-05 (work in progress), October 2016.
[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,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., [RFC6550] 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,
<http://www.rfc-editor.org/info/rfc6550>. <https://www.rfc-editor.org/info/rfc6550>.
[RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N.,
and D. Barthel, "Routing Metrics Used for Path Calculation and D. Barthel, "Routing Metrics Used for Path Calculation
in Low-Power and Lossy Networks", RFC 6551, in Low-Power and Lossy Networks", RFC 6551,
DOI 10.17487/RFC6551, March 2012, DOI 10.17487/RFC6551, March 2012,
<http://www.rfc-editor.org/info/rfc6551>. <https://www.rfc-editor.org/info/rfc6551>.
[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,
<http://www.rfc-editor.org/info/rfc6554>. <https://www.rfc-editor.org/info/rfc6554>.
[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",
RFC 8025, DOI 10.17487/RFC8025, November 2016, RFC 8025, DOI 10.17487/RFC8025, November 2016,
<http://www.rfc-editor.org/info/rfc8025>. <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>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-6tisch-architecture] [I-D.ietf-6tisch-architecture]
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", draft-ietf-6tisch-architecture-11 (work of IEEE 802.15.4", draft-ietf-6tisch-architecture-12 (work
in progress), January 2017. in progress), August 2017.
[I-D.ietf-detnet-architecture] [I-D.ietf-detnet-architecture]
Finn, N. and P. Thubert, "Deterministic Networking Finn, N., Thubert, P., Varga, B., and J. Farkas,
Architecture", draft-ietf-detnet-architecture-00 (work in "Deterministic Networking Architecture", draft-ietf-
progress), September 2016. detnet-architecture-03 (work in progress), August 2017.
[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/>.
[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,
<http://www.rfc-editor.org/info/rfc6997>. <https://www.rfc-editor.org/info/rfc6997>.
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
2014, <http://www.rfc-editor.org/info/rfc7102>. 2014, <https://www.rfc-editor.org/info/rfc7102>.
Appendix A. Examples Appendix A. Examples
A.1. Using storing mode P-DAO in non-storing mode MOP A.1. Using storing mode P-DAO in non-storing mode MOP
In non-storing mode, the DAG root maintains the knowledge of the In non-storing mode, the DAG root maintains the knowledge of the
whole DODAG topology, so when both the source and the destination of whole DODAG topology, so when both the source and the destination of
a packet are in the DODAG, the root can determine the common parent a packet are in the DODAG, the root can determine the common parent
that would have been used in storing mode, and thus the list of nodes that would have been used in storing mode, and thus the list of nodes
in the path between the common parent and the destination. For in the path between the common parent and the destination. For
instance in the diagram shown in Figure 7, if the source is node 41 instance in the diagram shown in Figure 7, if the source is node 41
and the destination is node 52, then the common parent is node 22. and the destination is node 52, then the common parent is node 22.
 End of changes. 36 change blocks. 
81 lines changed or deleted 103 lines changed or added

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