draft-ietf-roll-rpl-observations-02.txt   draft-ietf-roll-rpl-observations-03.txt 
ROLL R. Jadhav, Ed. ROLL R. Jadhav, Ed.
Internet-Draft R. Sahoo Internet-Draft R. Sahoo
Intended status: Standards Track Y. Wu Intended status: Standards Track Y. Wu
Expires: March 23, 2020 Huawei Expires: May 29, 2020 Huawei
September 20, 2019 November 26, 2019
RPL Observations RPL Observations
draft-ietf-roll-rpl-observations-02 draft-ietf-roll-rpl-observations-03
Abstract Abstract
This document describes RPL protocol design issues, various This document describes RPL protocol design issues, various
observations and possible consequences of the design and observations and possible consequences of the design and
implementation choices. implementation choices.
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
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 March 23, 2020. This Internet-Draft will expire on May 29, 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 Provisions Relating to IETF Documents
(https://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
skipping to change at page 2, line 19 skipping to change at page 2, line 19
2.1. Requirements Language and Terminology . . . . . . . . . . 3 2.1. Requirements Language and Terminology . . . . . . . . . . 3
3. DTSN increment in storing MOP . . . . . . . . . . . . . . . . 4 3. DTSN increment in storing MOP . . . . . . . . . . . . . . . . 4
3.1. Deliberations . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Deliberations . . . . . . . . . . . . . . . . . . . . . . 5
4. DAO retransmission and use of DAO-ACK in storing MOP . . . . 5 4. DAO retransmission and use of DAO-ACK in storing MOP . . . . 5
4.1. Significance of bidirectional Path establishment 4.1. Significance of bidirectional Path establishment
indication and relevance of DAO-ACK . . . . . . . . . . . 6 indication and relevance of DAO-ACK . . . . . . . . . . . 6
4.2. Problems with hop-by-hop DAO-ACK . . . . . . . . . . . . 6 4.2. Problems with hop-by-hop DAO-ACK . . . . . . . . . . . . 6
4.3. Problems with end-to-end DAO-ACK . . . . . . . . . . . . 6 4.3. Problems with end-to-end DAO-ACK . . . . . . . . . . . . 6
4.4. Deliberations . . . . . . . . . . . . . . . . . . . . . . 6 4.4. Deliberations . . . . . . . . . . . . . . . . . . . . . . 6
4.5. Implementation Notes . . . . . . . . . . . . . . . . . . 7 4.5. Implementation Notes . . . . . . . . . . . . . . . . . . 7
5. Handling resource unavailability . . . . . . . . . . . . . . 7 5. Interpreting Trickle Timer Reset . . . . . . . . . . . . . . 7
5.1. Deliberations . . . . . . . . . . . . . . . . . . . . . . 7 6. Handling resource unavailability . . . . . . . . . . . . . . 7
6. Handling aggregated targets . . . . . . . . . . . . . . . . . 7
6.1. Deliberations . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Deliberations . . . . . . . . . . . . . . . . . . . . . . 8
7. RPL Transit Information in DAO . . . . . . . . . . . . . . . 8 7. Handling aggregated targets . . . . . . . . . . . . . . . . . 8
7.1. Deliberations . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Deliberations . . . . . . . . . . . . . . . . . . . . . . 8
8. Upgrades or Extensions to RPL protocol . . . . . . . . . . . 9 8. RPL Transit Information in DAO . . . . . . . . . . . . . . . 9
9. Asymmetric Links and RPL . . . . . . . . . . . . . . . . . . 9 8.1. Deliberations . . . . . . . . . . . . . . . . . . . . . . 9
10. Adjacencies probing with RPL . . . . . . . . . . . . . . . . 9 9. Upgrades or Extensions to RPL protocol . . . . . . . . . . . 9
10.1. Deliberations . . . . . . . . . . . . . . . . . . . . . 10 10. Asymmetric Links and RPL . . . . . . . . . . . . . . . . . . 9
11. Control Options eliding mechanism in RPL . . . . . . . . . . 10 11. Adjacencies probing with RPL . . . . . . . . . . . . . . . . 10
12. Managing persistent variables across node reboots . . . . . . 10 11.1. Deliberations . . . . . . . . . . . . . . . . . . . . . 10
12.1. Persistent storage and RPL state information . . . . . . 10 12. Control Options eliding mechanism in RPL . . . . . . . . . . 11
12.2. Lollipop Counters . . . . . . . . . . . . . . . . . . . 11 13. Managing persistent variables across node reboots . . . . . . 11
12.3. RPL State variables . . . . . . . . . . . . . . . . . . 12 13.1. Persistent storage and RPL state information . . . . . . 11
12.3.1. DODAG Version . . . . . . . . . . . . . . . . . . . 12 13.2. Lollipop Counters . . . . . . . . . . . . . . . . . . . 12
12.3.2. DTSN field in DIO . . . . . . . . . . . . . . . . . 12 13.3. RPL State variables . . . . . . . . . . . . . . . . . . 13
12.3.3. PathSequence . . . . . . . . . . . . . . . . . . . . 13 13.3.1. DODAG Version . . . . . . . . . . . . . . . . . . . 13
12.4. State variables update frequency . . . . . . . . . . . . 13 13.3.2. DTSN field in DIO . . . . . . . . . . . . . . . . . 13
12.5. Deliberations . . . . . . . . . . . . . . . . . . . . . 13 13.3.3. PathSequence . . . . . . . . . . . . . . . . . . . . 13
12.6. Implementation Notes . . . . . . . . . . . . . . . . . . 14 13.4. State variables update frequency . . . . . . . . . . . . 14
13. Capabilities and its role in RPL . . . . . . . . . . . . . . 14 13.5. Deliberations . . . . . . . . . . . . . . . . . . . . . 14
13.1. Handshaking node capabilities . . . . . . . . . . . . . 14 13.6. Implementation Notes . . . . . . . . . . . . . . . . . . 14
13.2. How do Capabilities differ from MOP and Configuration 14. Capabilities and its role in RPL . . . . . . . . . . . . . . 15
14.1. Handshaking node capabilities . . . . . . . . . . . . . 15
14.2. How do Capabilities differ from MOP and Configuration
Option? . . . . . . . . . . . . . . . . . . . . . . . . 15 Option? . . . . . . . . . . . . . . . . . . . . . . . . 15
13.3. Deliberations . . . . . . . . . . . . . . . . . . . . . 15 14.3. Deliberations . . . . . . . . . . . . . . . . . . . . . 15
14. RPL under-specification . . . . . . . . . . . . . . . . . . . 15 15. RPL under-specification . . . . . . . . . . . . . . . . . . . 15
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
17. Security Considerations . . . . . . . . . . . . . . . . . . . 16 18. Security Considerations . . . . . . . . . . . . . . . . . . . 16
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
18.1. Normative References . . . . . . . . . . . . . . . . . . 16 19.1. Normative References . . . . . . . . . . . . . . . . . . 16
18.2. Informative References . . . . . . . . . . . . . . . . . 17 19.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Motivation 1. Motivation
The primary motivation for this draft is to enlist different issues The primary motivation for this draft is to enlist different issues
with RPL operation and invoke a discussion within the working group. with RPL operation and invoke a discussion within the working group.
This draft by itself is not intended for RFC tracks but as a WG This draft by itself is not intended for RFC tracks but as a WG
discussion track. This draft may in turn result in other work items discussion track. This draft may in turn result in other work items
taken up by the WG which may improvise on the issues mentioned taken up by the WG which may improvise on the issues mentioned
herewith. herewith.
2. Introduction 2. Introduction
RPL [RFC6550] specifies a proactive distance-vector routing scheme RPL [RFC6550] specifies a proactive distance-vector routing scheme
designed for LLNs (Low Power and Lossy Networks). RPL enables the designed for LLNs (Low Power and Lossy Networks). RPL enables the
network to be formed as a DODAG and supports storing mode and non- network to be formed as a DODAG and supports storing mode and non-
storing mode of operations. Non-storing mode allows reduced memory storing mode of operations. Non-storing mode allows reduced memory
resource usage on the nodes by allowing non-BR nodes to operate resource usage on the nodes by allowing non-BR nodes to operate
without managing a routing table and involves use of source routing without managing a routing table and involves use of source routing
by the 6LBR to direct the traffic along a specific path. In storing by the Root to direct the traffic along a specific path. In storing
mode of operation intermediate routers maintain routing tables. mode of operation intermediate routers maintain routing tables.
This work aims to highlight various issues with RPL which makes it This work aims to highlight various issues with RPL which makes it
difficult to handle certain scenarios. This work will highlight such difficult to handle certain scenarios. This work will highlight such
issues in context to RPL's mode of operations (storing versus non- issues in context to RPL's mode of operations (storing versus non-
storing). There are cases where RPL does not provide clear rules and storing). There are cases where RPL does not provide clear rules and
implementations have to make their choices hindering interoperability implementations have to make their choices hindering interoperability
and performance. and performance.
[I-D.clausen-lln-rpl-experiences] provides some interesting points. [I-D.clausen-lln-rpl-experiences] provides some interesting points.
skipping to change at page 7, line 22 skipping to change at page 7, line 30
The sequence of sending no-path DAO and DAO matters when updating the The sequence of sending no-path DAO and DAO matters when updating the
routing adjacencies on a parent switch. If an implementation chooses routing adjacencies on a parent switch. If an implementation chooses
to send no-path DAO before DAO then it results in significantly more to send no-path DAO before DAO then it results in significantly more
overhead for route invalidation. This is because no-path DAO would overhead for route invalidation. This is because no-path DAO would
traverse all the way up to the BR clearing the routes on the way. In traverse all the way up to the BR clearing the routes on the way. In
case there is a common ancestor post which the old and new path case there is a common ancestor post which the old and new path
remains same then it is better to send regular DAO first thus remains same then it is better to send regular DAO first thus
limiting the propagation of subsequent no-path DAO till this common limiting the propagation of subsequent no-path DAO till this common
ancestor. ancestor.
5. Handling resource unavailability 5. Interpreting Trickle Timer Reset
Trickle timer defines a mechanism to reset the timer. Trickle timer
reset is unlike regular periodic timers wherein the timer is simply
resetted to start again. Reset of trickle timer implies resetting
the trickle back to Imin and starting with a new interval as
mentioned in Section 4.2 of [RFC6206].
Implementations MUST not restart the trickle timer to the
instantaneous value of I which could have been advanced over a period
of time.
6. Handling resource unavailability
The nodes in the constrained networks have to maintain various The nodes in the constrained networks have to maintain various
records such as neighbor cache entries and routing entries on behalf records such as neighbor cache entries and routing entries on behalf
of other targets to facilitate packet forwarding. Because of the of other targets to facilitate packet forwarding. Because of the
constrained nature of the devices the memory available may be very constrained nature of the devices the memory available may be very
limited and thus the path selection algorithm may have to take into limited and thus the path selection algorithm may have to take into
consideration such resource constraints as well. consideration such resource constraints as well.
RPL currently does not have any mechanism to advertise such resource RPL currently does not have any mechanism to advertise such resource
indicator metrics. The primary tables associated with RPL are indicator metrics. The primary tables associated with RPL are
routing table and the neighbor cache. Even though neighbor cache is routing table and the neighbor cache. Even though neighbor cache is
not directly linked with RPL protocol, the maintenance of routing not directly linked with RPL protocol, the maintenance of routing
adjacencies results in updates to neigbor cache. adjacencies results in updates to neigbor cache.
5.1. Deliberations 6.1. Deliberations
Is it possible to know that an upstream parent/ancestor cannot Is it possible to know that an upstream parent/ancestor cannot
hold enough routing entries and thus this path should not be used? hold enough routing entries and thus this path should not be used?
Is it possible to know that an upstream parent cannot hold any Is it possible to know that an upstream parent cannot hold any
more neighbor cache entry and thus this upstream parent should not more neighbor cache entry and thus this upstream parent should not
be used? be used?
6. Handling aggregated targets 7. Handling aggregated targets
RPL allows and defines specific procedures so as to aid target RPL allows and defines specific procedures so as to aid target
aggregation in DAO. Having said that, the specification does not aggregation in DAO. Having said that, the specification does not
mandate use of aggregated targets nor does it make any comment on mandate use of aggregated targets nor does it make any comment on
whether a receiving node needs to handle it. Target aggregation is whether a receiving node needs to handle it. Target aggregation is
an useful tool and especially helps with link layer technologies that an useful tool and especially helps with link layer technologies that
does not suffer from low MTUs such as PLC. Even if the does not suffer from low MTUs such as PLC. Even if the
implementation does not support aggregating targets, it should implementation does not support aggregating targets, it should
atleast mandate reception of aggregated targets in DAO. atleast mandate reception of aggregated targets in DAO.
RPL has a mechanism currently to ACK the DAO but it does not have a RPL has a mechanism currently to ACK the DAO but it does not have a
mechanism to ACK the target container. Thus in case of aggregated mechanism to ACK the target container. Thus in case of aggregated
targets in the DAO, if the subset of the targets fail then it is targets in the DAO, if the subset of the targets fail then it is
impossible for the DAO-ACK to signal this to the DAO sender. impossible for the DAO-ACK to signal this to the DAO sender.
6.1. Deliberations 7.1. Deliberations
Even if the implementation does not support aggregating targets, Even if the implementation does not support aggregating targets,
should it atleast mandate reception and handling of aggregated should it atleast mandate reception and handling of aggregated
targets in DAO? targets in DAO?
There is a good scope for compressing aggregated targets which can There is a good scope for compressing aggregated targets which can
significantly reduce the RPL control overhead. significantly reduce the RPL control overhead.
How to selectively NACK subset of targets in case target How to selectively NACK subset of targets in case target
containers are aggregated? containers are aggregated?
The DEFAULT_DAO_DELAY of 1sec does not help much with aggregation. The DEFAULT_DAO_DELAY of 1sec does not help much with aggregation.
The upstream parent nodes should wait for more time then the child The upstream parent nodes should wait for more time then the child
nodes so as to effectively aggregate. Can we have nodes so as to effectively aggregate. Can we have
DEFAULT_DAO_DELAY a function of the level/rank the node is at? DEFAULT_DAO_DELAY a function of the level/rank the node is at?
7. RPL Transit Information in DAO 8. RPL Transit Information in DAO
RPL allows associating a target or set of targets with a Transit RPL allows associating a target or set of targets with a Transit
information container which contains attributes for a path to one or information container which contains attributes for a path to one or
more destinations identified by the set of targets. In case of NS- more destinations identified by the set of targets. In case of NS-
MOP, the transit Information will contain the all critical Parent MOP, the transit Information will contain the all critical Parent
Address which allows the common ancestor usually the root to identify Address which allows the common ancestor usually the root to identify
the source route header for the target node. The Transit Information the source route header for the target node. The Transit Information
also contains other information such as Path Sequence and Path also contains other information such as Path Sequence and Path
Lifetime which are critical for maintaining route adjacencies. Lifetime which are critical for maintaining route adjacencies.
RPL however does not mandate the use of Transit Information container RPL however does not mandate the use of Transit Information container
for targets. for targets.
7.1. Deliberations 8.1. Deliberations
Is it ok to let implementations decide on the inclusion of Transit Is it ok to let implementations decide on the inclusion of Transit
Information container? Information container?
Is it possible to achieve interop without mandating use of Transit Is it possible to achieve interop without mandating use of Transit
Information Container? Information Container?
If the Transit Information container is sent, should the handling If the Transit Information container is sent, should the handling
of PathSequence be mandated? of PathSequence be mandated?
8. Upgrades or Extensions to RPL protocol 9. Upgrades or Extensions to RPL protocol
RPL extensibility is highly desirable and is controlled by protocol RPL extensibility is highly desirable and is controlled by protocol
elements within the messaging framework. In the pursuit to keep the elements within the messaging framework. In the pursuit to keep the
signalling overhead less, RPL specification has been restricting in signalling overhead less, RPL specification has been restricting in
its approach to extend its field ranges, thus in some cases putting its approach to extend its field ranges, thus in some cases putting
extensibility at stakes. Consider for example, the mode of operation extensibility at stakes. Consider for example, the mode of operation
bits which is three bits in the RPL specification. These bits are bits which is three bits in the RPL specification. These bits are
already saturated and it may be difficult to add major upgrades already saturated and it may be difficult to add major upgrades
without extending these bits. without extending these bits.
9. Asymmetric Links and RPL 10. Asymmetric Links and RPL
Section 3.1 of [I-D.ietf-intarea-adhoc-wireless-com] explains Section 3.1 of [I-D.ietf-intarea-adhoc-wireless-com] explains
asymmetric link characteristics and what it takes for a protocol to asymmetric link characteristics and what it takes for a protocol to
support asymmetric links. RPL depends on bi-directional links for support asymmetric links. RPL depends on bi-directional links for
control even though near-perfect symmetry is not expected. The control even though near-perfect symmetry is not expected. The
implication of this is that the upstream and downstream path remains implication of this is that the upstream and downstream path remains
same within a given RPL instance for any pair of nodes. There are same within a given RPL instance for any pair of nodes. There are
following questions sprouting of this design: following questions sprouting of this design:
(1) Is it possible to detect asymmetric links? (1) Is it possible to detect asymmetric links?
skipping to change at page 9, line 45 skipping to change at page 10, line 19
instances which are coupled. This allows disjoint upstream and instances which are coupled. This allows disjoint upstream and
downstream paths between pair of nodes assuming that the link downstream paths between pair of nodes assuming that the link
asymmetricity is detected using some outside techniques. The link asymmetricity is detected using some outside techniques. The link
assumes that the link asymmetricity is already known to the nodes in assumes that the link asymmetricity is already known to the nodes in
the form of static configuration. In case of 6tisch networks, the the form of static configuration. In case of 6tisch networks, the
availability of transmission slots information can be used to availability of transmission slots information can be used to
identify link asymmetricity. The challenge with regards to detecting identify link asymmetricity. The challenge with regards to detecting
link asymmetricity arises from scenarios where, for example, the link asymmetricity arises from scenarios where, for example, the
nodes transmit with unequal power levels. nodes transmit with unequal power levels.
10. Adjacencies probing with RPL 11. Adjacencies probing with RPL
RPL avoids periodic hello messaging as compared to other distance- RPL avoids periodic hello messaging as compared to other distance-
vector protocols. It uses trickle timer based mechanism to update vector protocols. It uses trickle timer based mechanism to update
configuration parameters. This significantly reduces the RPL control configuration parameters. This significantly reduces the RPL control
overhead. One of the fallout of this design choice is that, in the overhead. One of the fallout of this design choice is that, in the
absence of regular traffic, the adjacencies could not be tested and absence of regular traffic, the adjacencies could not be tested and
repaired if broken. repaired if broken.
RPL provides a mechanism in the form of unicast DIS to query a RPL provides a mechanism in the form of unicast DIS to query a
particular node for its DIO. A node receiving a unicast DIS MUST particular node for its DIO. A node receiving a unicast DIS MUST
skipping to change at page 10, line 22 skipping to change at page 10, line 43
probing is implementation dependent, but the node is expected to probing is implementation dependent, but the node is expected to
invoke probing only when invoke probing only when
(1) There is no data traffic based on which the links could be (1) There is no data traffic based on which the links could be
tested. tested.
(2) There is no L2 feedback. In some case, L2 might provide (2) There is no L2 feedback. In some case, L2 might provide
periodic beacons at link layer and the absence of beacons could periodic beacons at link layer and the absence of beacons could
be used for link tests. be used for link tests.
10.1. Deliberations 11.1. Deliberations
(1) Should the probing scheme be standardized? In some cases using (1) Should the probing scheme be standardized? In some cases using
multicast based probing may prove advantageous. multicast based probing may prove advantageous.
(2) In some cases using multicast based probing may prove (2) In some cases using multicast based probing may prove
advantageous. Currently RPL does not have multicast based advantageous. Currently RPL does not have multicast based
probing. Multicast DIS/DIO may not be suitable for probing probing. Multicast DIS/DIO may not be suitable for probing
because it could possibly lead to change of states. because it could possibly lead to change of states.
11. Control Options eliding mechanism in RPL 12. Control Options eliding mechanism in RPL
RPL configuration changes are rare and thus various configuration RPL configuration changes are rare and thus various configuration
options may not change over a long period of time. RPL provides a options may not change over a long period of time. RPL provides a
way for the configuration options to be elided but there are no clear way for the configuration options to be elided but there are no clear
guidelines on how the eliding should be handled. In the absence of guidelines on how the eliding should be handled. In the absence of
such guidelines, it is possible that certain nodes may end up using such guidelines, it is possible that certain nodes may end up using
stale configuration in the event of transient link failures. stale configuration in the event of transient link failures.
12. Managing persistent variables across node reboots 13. Managing persistent variables across node reboots
12.1. Persistent storage and RPL state information 13.1. Persistent storage and RPL state information
Devices are required to be functional for several years without Devices are required to be functional for several years without
manual maintanence. Usually battery power consumption is considered manual maintanence. Usually battery power consumption is considered
key for operating the devices for several (tens of) years. But apart key for operating the devices for several (tens of) years. But apart
from battery, flash memory endurance may prove to be a lifetime from battery, flash memory endurance may prove to be a lifetime
bottleneck in constrained networks. Endurance is defined as maximum bottleneck in constrained networks. Endurance is defined as maximum
number of erase-write cycles that a NAND/NOR cell can undergo before number of erase-write cycles that a NAND/NOR cell can undergo before
losing its 'gauranteed' write operation. In some cases (cheaper losing its 'gauranteed' write operation. In some cases (cheaper
NAND-MLC/TLC), the endurance can be as less as 2K cycles. Thus for NAND-MLC/TLC), the endurance can be as less as 2K cycles. Thus for
e.g. if a given cell is written 5 times a day, that NAND-flash cell e.g. if a given cell is written 5 times a day, that NAND-flash cell
skipping to change at page 11, line 29 skipping to change at page 12, line 5
information then it becomes counter-productive. information then it becomes counter-productive.
In a star topology, the amount of persistent data write done by In a star topology, the amount of persistent data write done by
network protocols is very limited. But ad-hoc networks employing network protocols is very limited. But ad-hoc networks employing
routing protocols such as RPL assume certain state information to be routing protocols such as RPL assume certain state information to be
retained across node reboots. In case of IoT devices this storage is retained across node reboots. In case of IoT devices this storage is
mostly floating gate based NAND/NOR based flash memory. The impact mostly floating gate based NAND/NOR based flash memory. The impact
of loss of this state information differs depending upon the type of loss of this state information differs depending upon the type
(6LN/6LR/6LBR) of the node. (6LN/6LR/6LBR) of the node.
12.2. Lollipop Counters 13.2. Lollipop Counters
[RFC6550] Section 7.2. explains sequence counter operation defining [RFC6550] Section 7.2. explains sequence counter operation defining
lollipop [Perlman83] style counters. Lollipop counters specify lollipop [Perlman83] style counters. Lollipop counters specify
mechanism in which even if the counter value wraps, the algorithm mechanism in which even if the counter value wraps, the algorithm
would be able to tell whether the received value is the latest or would be able to tell whether the received value is the latest or
not. This mechanism also helps in "some cases" to recover from node not. This mechanism also helps in "some cases" to recover from node
reboot, but is not foolproof. reboot, but is not foolproof.
Consider an e.g. where Node A boots up and initialises the seqcnt to Consider an e.g. where Node A boots up and initialises the seqcnt to
240 as recommended in [RFC6550]. Node A communicates to Node B using 240 as recommended in [RFC6550]. Node A communicates to Node B using
skipping to change at page 12, line 28 skipping to change at page 13, line 5
Default values for lollipop counters considered from [RFC6550] Default values for lollipop counters considered from [RFC6550]
Section 7.2. Section 7.2.
Table 1: Example lollipop counter operation Table 1: Example lollipop counter operation
Based on this figure, there is dead zone (240 to 0) in which if A Based on this figure, there is dead zone (240 to 0) in which if A
operates after reboot then the seqcnt will always be considered operates after reboot then the seqcnt will always be considered
smaller. Thus node A needs to maintain the seqcnt in persistent smaller. Thus node A needs to maintain the seqcnt in persistent
storage and reuse this on reboot. storage and reuse this on reboot.
12.3. RPL State variables 13.3. RPL State variables
The impact of loss of RPL state information differs depending upon The impact of loss of RPL state information differs depending upon
the node type (6LN/6LR/6LBR). Following sections explain different the node type (6LN/6LR/6LBR). Following sections explain different
state variables and the impact in case this information is lost on state variables and the impact in case this information is lost on
reboot. reboot.
12.3.1. DODAG Version 13.3.1. DODAG Version
The tuple (RPLInstanceID, DODAGID, DODAGVersionNumber) uniquely The tuple (RPLInstanceID, DODAGID, DODAGVersionNumber) uniquely
identifies a DODAG Version. DODAGVersionNumber is incremented identifies a DODAG Version. DODAGVersionNumber is incremented
everytime a global repair is initiated for the instance (global or everytime a global repair is initiated for the instance (global or
local). A node receiving an older DODAGVersionNumber will ignore the local). A node receiving an older DODAGVersionNumber will ignore the
DIO message assuming it to be from old DODAG version. Thus a 6LBR DIO message assuming it to be from old DODAG version. Thus a 6LBR
node (and 6LR node in case of local DODAG) needs to maintain the node (and 6LR node in case of local DODAG) needs to maintain the
DODAGVersionNumber in the persistent storage, so as to be available DODAGVersionNumber in the persistent storage, so as to be available
on reboot. In case the 6LBR could not use the latest on reboot. In case the 6LBR could not use the latest
DODAGVersionNumber the implication are that it won't be able to DODAGVersionNumber the implication are that it won't be able to
recover/re-establish the routing table. recover/re-establish the routing table.
12.3.2. DTSN field in DIO 13.3.2. DTSN field in DIO
DTSN (Destination advertisement Trigger Sequence Number) is a DIO DTSN (Destination advertisement Trigger Sequence Number) is a DIO
message field used as part of procedure to maintain Downward routes. message field used as part of procedure to maintain Downward routes.
A 6LBR/6LR node may increment a DTSN in case it requires the A 6LBR/6LR node may increment a DTSN in case it requires the
downstream nodes to send DAO and thus update downward routes on the downstream nodes to send DAO and thus update downward routes on the
6LBR/6LR node. In case of RPL NS-MOP, only the 6LBR maintains the 6LBR/6LR node. In case of RPL NS-MOP, only the 6LBR maintains the
downward routes and thus controls this field update. In case of downward routes and thus controls this field update. In case of
S-MOP, 6LRs additionally keep downward routes and thus control this S-MOP, 6LRs additionally keep downward routes and thus control this
field update. field update.
In S-MOP, when a 6LR node switches parent it may have to issue a DIO In S-MOP, when a 6LR node switches parent it may have to issue a DIO
with incremented DTSN to trigger downstream child nodes to send DAO with incremented DTSN to trigger downstream child nodes to send DAO
so that the downward routes are established in all parent/ancestor so that the downward routes are established in all parent/ancestor
set. Thus in S-MOP, the frequency of DTSN update might be relatively set. Thus in S-MOP, the frequency of DTSN update might be relatively
high (given the node density and hysteresis set by objective function high (given the node density and hysteresis set by objective function
to switch parent). to switch parent).
12.3.3. PathSequence 13.3.3. PathSequence
PathSequence is part of RPL Transit Option, and associated with RPL PathSequence is part of RPL Transit Option, and associated with RPL
Target option. A node whichs owns a target address can associate a Target option. A node whichs owns a target address can associate a
PathSequence in the DAO message to denote freshness of the target PathSequence in the DAO message to denote freshness of the target
information. This is especially useful when a node uses multiple information. This is especially useful when a node uses multiple
paths or multiple parents to advertise its reachability. paths or multiple parents to advertise its reachability.
Loss of PathSequence information maintained on the target node can Loss of PathSequence information maintained on the target node can
result in routing adjacencies been lost on 6LRs/6LBR/6BBR. result in routing adjacencies been lost on 6LRs/6LBR/6BBR.
12.4. State variables update frequency 13.4. State variables update frequency
+--------------------+-------------------+------------------------+ +--------------------+-------------------+------------------------+
| State variable | Update frequency | Impacts node type | | State variable | Update frequency | Impacts node type |
+--------------------+-------------------+------------------------+ +--------------------+-------------------+------------------------+
| DODAGVersionNumber | Low | 6LBR, 6LR(local DODAG) | | DODAGVersionNumber | Low | 6LBR, 6LR(local DODAG) |
| DTSN | High(SM),Low(NSM) | 6LBR, 6LR | | DTSN | High(SM),Low(NSM) | 6LBR, 6LR |
| PathSequence | High(SM),Low(NSM) | 6LR, 6LN | | PathSequence | High(SM),Low(NSM) | 6LR, 6LN |
+--------------------+-------------------+------------------------+ +--------------------+-------------------+------------------------+
Low=<5 per day, High=>5 per day; SM=Storing MOP, NSM=Non-Storing MOP Low=<5 per day, High=>5 per day; SM=Storing MOP, NSM=Non-Storing MOP
Table 2: RPL State variables Table 2: RPL State variables
12.5. Deliberations 13.5. Deliberations
(1) Is it possible that RPL reduces the use of persistent storage (1) Is it possible that RPL reduces the use of persistent storage
for maintaining state information? for maintaining state information?
(2) In most cases, the node reboots will happen very rarely. Thus (2) In most cases, the node reboots will happen very rarely. Thus
doing a persistent storage book-keeping for handling node reboot doing a persistent storage book-keeping for handling node reboot
might not make sense. Is it possible to consider signaling might not make sense. Is it possible to consider signaling
(especially after the node reboots) so as to avoid maintaining (especially after the node reboots) so as to avoid maintaining
this persistent state? Is it possible to use one-time on-reboot this persistent state? Is it possible to use one-time on-reboot
signalling to recover some state information? signalling to recover some state information?
(3) It is necessary that RPL avoids using persistent storage as far (3) It is necessary that RPL avoids using persistent storage as far
as possible. Ideally, extensions to RPL should consider this as as possible. Ideally, extensions to RPL should consider this as
a design requirement especially for 6LR and 6LN nodes. DTSN and a design requirement especially for 6LR and 6LN nodes. DTSN and
PathSequence are the primary state variables which have major PathSequence are the primary state variables which have major
impact. impact.
12.6. Implementation Notes 13.6. Implementation Notes
An implementation should use a random DAOSequence number on reboot so An implementation should use a random DAOSequence number on reboot so
as to avoid a risk of reusing the same DAOSequence on reboot. as to avoid a risk of reusing the same DAOSequence on reboot.
Regardless the sequence counter size of 8bits does not provide much Regardless the sequence counter size of 8bits does not provide much
gurantees towards choosing a good random number. A parent node will gurantees towards choosing a good random number. A parent node will
not respond with a DAO-ACK in case it sees a DAO with the same not respond with a DAO-ACK in case it sees a DAO with the same
previous DAOSequence. previous DAOSequence.
Write-Before-Use: The state information should be written to the Write-Before-Use: The state information should be written to the
flash before using it in the messaging. If it is done the other way, flash before using it in the messaging. If it is done the other way,
then the chances are that the node power downs before writing to the then the chances are that the node power downs before writing to the
persistent storage. persistent storage.
13. Capabilities and its role in RPL 14. Capabilities and its role in RPL
RPL is a distributed protocol and it requires that the participating RPL is a distributed protocol and it requires that the participating
nodes agree on basic set of primitives to follow. RPL currently nodes agree on basic set of primitives to follow. RPL currently
handles this using MOP (Mode of Operation) bits in the DIO. MOP bits handles this using MOP (Mode of Operation) bits in the DIO. MOP bits
inform the nodes the basic mode of operation a node MUST support to inform the nodes the basic mode of operation a node MUST support to
join the Instance as a 6LR. The MOP is decided and advertised by the join the Instance as a 6LR. The MOP is decided and advertised by the
root of the RPL Instance. A node not supporting the given MOP may root of the RPL Instance. A node not supporting the given MOP may
still join the Instance as a leaf node or 6LN. still join the Instance as a leaf node or 6LN.
RPL further uses DIO Configuration Option to advertise the RPL further uses DIO Configuration Option to advertise the
configuration each node needs to use (for e.g., for trickle timer). configuration each node needs to use (for e.g., for trickle timer).
13.1. Handshaking node capabilities 14.1. Handshaking node capabilities
Currently there exist no mechanism to handshake capabilities of the Currently there exist no mechanism to handshake capabilities of the
root or 6LRs or 6LNs. If a feature is optional and is supported by root or 6LRs or 6LNs. If a feature is optional and is supported by
6LRs/6LNs then currently there exists no mechanism to signal it. 6LRs/6LNs then currently there exists no mechanism to signal it.
There are several RPL extension proposals which are possibly optional There are several RPL extension proposals which are possibly optional
features. Root needs to know if the 6LR/6LN supports these optional features. Root needs to know if the 6LR/6LN supports these optional
features to enable the extension in that path context. Similarly features to enable the extension in that path context. Similarly
6LRs and 6LNs need to know whether the root supports certain 6LRs and 6LNs need to know whether the root supports certain
extensions that it can make use of. extensions that it can make use of.
13.2. How do Capabilities differ from MOP and Configuration Option? 14.2. How do Capabilities differ from MOP and Configuration Option?
Unlike MOP and Configuration Option which are issued by the root of Unlike MOP and Configuration Option which are issued by the root of
the Instance, Capabilities can be issued by any node. A 6LN/6LR node the Instance, Capabilities can be issued by any node. A 6LN/6LR node
can advertise its capabilities such that those can be seen by can advertise its capabilities such that those can be seen by
intermediate 6LRs and the root of the Instance. intermediate 6LRs and the root of the Instance.
13.3. Deliberations 14.3. Deliberations
(1) Is it possible for leaf nodes to advertise their set of (1) Is it possible for leaf nodes to advertise their set of
capabilities, which can be used by root and/or intermediate 6LRs capabilities, which can be used by root and/or intermediate 6LRs
to make run time decisions? to make run time decisions?
(2) How should these capabilities be carried? Should it be carried (2) How should these capabilities be carried? Should it be carried
in DAO/DIO/DAO-ACK? in DAO/DIO/DAO-ACK?
(3) Should the definition of capabilities be same in both directions (3) Should the definition of capabilities be same in both directions
(upstream/downstream)? (upstream/downstream)?
14. RPL under-specification 15. RPL under-specification
(a) PathSequence: Is it mandatory to use PathSequence in DAO Transit (a) PathSequence: Is it mandatory to use PathSequence in DAO Transit
container? RPL mentions that a 6LR/6LBR hosting the routing container? RPL mentions that a 6LR/6LBR hosting the routing
entry on behalf of target node should refresh the lifetime on entry on behalf of target node should refresh the lifetime on
reception of a new Path Sequence. But RPL does not necessarily reception of a new Path Sequence. But RPL does not necessarily
mandate use of Path Sequence. Most of the open source mandate use of Path Sequence. Most of the open source
implementation [RIOT] [CONTIKI] currently do not issue Path implementation [RIOT] [CONTIKI] currently do not issue Path
Sequence in the DAO message. Sequence in the DAO message.
(b) Target Container aggregation in DAO: RPL allows multiple targets (b) Target Container aggregation in DAO: RPL allows multiple targets
to be aggregated in a single DAO message and has introduced a to be aggregated in a single DAO message and has introduced a
notion of DelayDAO using which a 6LR node could delay its DAO to notion of DelayDAO using which a 6LR node could delay its DAO to
enable such aggregation. But RPL does not have clear text on enable such aggregation. But RPL does not have clear text on
handling of aggregated DAOs and thus it hinders handling of aggregated DAOs and thus it hinders
interoperability. interoperability.
(c) DTSN Update: RPL does not clearly define in which cases DTSN (c) DTSN Update: RPL does not clearly define in which cases DTSN
should be updated in case of storing mode of operation. More should be updated in case of storing mode of operation. More
details for this are presented in Section 3. details for this are presented in Section 3.
15. Acknowledgements 16. Acknowledgements
Many thanks to Pascal Thubert for hallway chats and for helping Many thanks to Pascal Thubert for hallway chats and for helping
understand the existing design rationales. Thanks to Michael understand the existing design rationales. Thanks to Michael
Richardson for Unstrung RPL implementation rationale. Thanks to ML Richardson for Unstrung RPL implementation rationale. Thanks to ML
discussions, in particular (https://www.ietf.org/mail- discussions, in particular (https://www.ietf.org/mail-
archive/web/roll/current/msg09443.html). archive/web/roll/current/msg09443.html).
16. IANA Considerations 17. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
17. Security Considerations 18. Security Considerations
This is an information draft and does add any changes to the existing This is an information draft and does add any changes to the existing
specifications. specifications.
18. References 19. References
18.1. Normative References 19.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[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,
skipping to change at page 17, line 5 skipping to change at page 17, line 28
Low-Power Wireless Personal Area Networks (6LoWPANs)", Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012, RFC 6775, DOI 10.17487/RFC6775, November 2012,
<https://www.rfc-editor.org/info/rfc6775>. <https://www.rfc-editor.org/info/rfc6775>.
[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>.
18.2. Informative References 19.2. Informative References
[I-D.clausen-lln-rpl-experiences] [I-D.clausen-lln-rpl-experiences]
Clausen, T., Verdiere, A., Yi, J., Herberg, U., and Y. Clausen, T., Verdiere, A., Yi, J., Herberg, U., and Y.
Igarashi, "Observations on RPL: IPv6 Routing Protocol for Igarashi, "Observations on RPL: IPv6 Routing Protocol for
Low power and Lossy Networks", draft-clausen-lln-rpl- Low power and Lossy Networks", draft-clausen-lln-rpl-
experiences-11 (work in progress), March 2018. experiences-11 (work in progress), March 2018.
[I-D.ietf-intarea-adhoc-wireless-com] [I-D.ietf-intarea-adhoc-wireless-com]
Baccelli, E. and C. Perkins, "Multi-hop Ad Hoc Wireless Baccelli, E. and C. Perkins, "Multi-hop Ad Hoc Wireless
Communication", draft-ietf-intarea-adhoc-wireless-com-02 Communication", draft-ietf-intarea-adhoc-wireless-com-02
 End of changes. 41 change blocks. 
69 lines changed or deleted 84 lines changed or added

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