draft-ietf-roll-rpl-observations-06.txt   draft-ietf-roll-rpl-observations-07.txt 
ROLL R. Jadhav, Ed. ROLL R.A. Jadhav, Ed.
Internet-Draft Internet-Draft
Intended status: Standards Track R. Sahoo Intended status: Standards Track R.N. Sahoo
Expires: December 5, 2021 Juniper Expires: 2 June 2022 Juniper
Y. Wu Y. Wu
Huawei Huawei
June 3, 2021 29 November 2021
RPL Observations RPL Observations
draft-ietf-roll-rpl-observations-06 draft-ietf-roll-rpl-observations-07
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 35 skipping to change at page 1, line 35
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 December 5, 2021. This Internet-Draft will expire on 2 June 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Revised BSD License text as
include Simplified BSD License text as described in Section 4.e of described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Revised BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
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
indication and relevance of DAO-ACK . . . . . . . . . . . 6 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. Interpreting Trickle Timer . . . . . . . . . . . . . . . . . 7 5. Interpreting Trickle Timer . . . . . . . . . . . . . . . . . 7
6. Handling resource unavailability . . . . . . . . . . . . . . 8 6. Handling resource unavailability . . . . . . . . . . . . . . 8
6.1. Deliberations . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Deliberations . . . . . . . . . . . . . . . . . . . . . . 8
7. Handling aggregated targets . . . . . . . . . . . . . . . . . 9 7. Handling aggregated targets . . . . . . . . . . . . . . . . . 9
7.1. Deliberations . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Deliberations . . . . . . . . . . . . . . . . . . . . . . 9
8. RPL Transit Information in DAO . . . . . . . . . . . . . . . 9 8. RPL Transit Information in DAO . . . . . . . . . . . . . . . 9
8.1. Deliberations . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Deliberations . . . . . . . . . . . . . . . . . . . . . . 10
9. Upgrades or Extensions to RPL protocol . . . . . . . . . . . 10 9. Upgrades or Extensions to RPL protocol . . . . . . . . . . . 10
10. Path Control bits handling . . . . . . . . . . . . . . . . . 10 10. Path Control bits handling . . . . . . . . . . . . . . . . . 10
11. Asymmetric Links and RPL . . . . . . . . . . . . . . . . . . 11 11. Asymmetric Links and RPL . . . . . . . . . . . . . . . . . . 11
12. Adjacencies probing with RPL . . . . . . . . . . . . . . . . 11 12. Adjacencies probing with RPL . . . . . . . . . . . . . . . . 12
12.1. Deliberations . . . . . . . . . . . . . . . . . . . . . 12 12.1. Deliberations . . . . . . . . . . . . . . . . . . . . . 12
13. Control Options eliding mechanism in RPL . . . . . . . . . . 12 13. Control Options eliding mechanism in RPL . . . . . . . . . . 12
14. Managing persistent variables across node reboots . . . . . . 12 14. Managing persistent variables across node reboots . . . . . . 12
14.1. Persistent storage and RPL state information . . . . . . 12 14.1. Persistent storage and RPL state information . . . . . . 13
14.2. Lollipop Counters . . . . . . . . . . . . . . . . . . . 13 14.2. Lollipop Counters . . . . . . . . . . . . . . . . . . . 13
14.3. RPL State variables . . . . . . . . . . . . . . . . . . 14 14.3. RPL State variables . . . . . . . . . . . . . . . . . . 14
14.3.1. DODAG Version . . . . . . . . . . . . . . . . . . . 14 14.3.1. DODAG Version . . . . . . . . . . . . . . . . . . . 15
14.3.2. DTSN field in DIO . . . . . . . . . . . . . . . . . 14 14.3.2. DTSN field in DIO . . . . . . . . . . . . . . . . . 15
14.3.3. PathSequence . . . . . . . . . . . . . . . . . . . . 15 14.3.3. PathSequence . . . . . . . . . . . . . . . . . . . . 15
14.4. State variables update frequency . . . . . . . . . . . . 15 14.4. State variables update frequency . . . . . . . . . . . . 16
14.5. Deliberations . . . . . . . . . . . . . . . . . . . . . 15 14.5. Deliberations . . . . . . . . . . . . . . . . . . . . . 16
14.6. Implementation Notes . . . . . . . . . . . . . . . . . . 16 14.6. Implementation Notes . . . . . . . . . . . . . . . . . . 16
15. Capabilities and its role in RPL . . . . . . . . . . . . . . 16 15. Capabilities and its role in RPL . . . . . . . . . . . . . . 17
15.1. Handshaking node capabilities . . . . . . . . . . . . . 16 15.1. Handshaking node capabilities . . . . . . . . . . . . . 17
15.2. How do Capabilities differ from MOP and Configuration 15.2. How do Capabilities differ from MOP and Configuration
Option? . . . . . . . . . . . . . . . . . . . . . . . . 17 Option? . . . . . . . . . . . . . . . . . . . . . . . . 17
15.3. Deliberations . . . . . . . . . . . . . . . . . . . . . 17 15.3. Deliberations . . . . . . . . . . . . . . . . . . . . . 17
16. Backward Compatibility issues with RPL Options . . . . . . . 17 16. Backward Compatibility issues with RPL Options . . . . . . . 18
17. RPL under-specification . . . . . . . . . . . . . . . . . . . 17 17. RPL under-specification . . . . . . . . . . . . . . . . . . . 18
18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
20. Security Considerations . . . . . . . . . . . . . . . . . . . 18 20. Security Considerations . . . . . . . . . . . . . . . . . . . 19
21. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
21.1. Normative References . . . . . . . . . . . . . . . . . . 18 21.1. Normative References . . . . . . . . . . . . . . . . . . 19
21.2. Informative References . . . . . . . . . . . . . . . . . 19 21.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 19 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
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.
skipping to change at page 5, line 49 skipping to change at page 5, line 47
upstream. In other words, the parent node accepts the upstream. In other words, the parent node accepts the
responsibilty of sending the DAO upstream till the point it is responsibilty of sending the DAO upstream till the point it is
ACKed the moment it responds back with its own ACK to the child. ACKed the moment it responds back with its own ACK to the child.
1-> 3-> 1-> 3->
DAO DAO DAO DAO
(TgtNode)--------(6LR)-------(root) (TgtNode)--------(6LR)-------(root)
ACK ACK ACK ACK
<-2 <-4 <-2 <-4
Figure 2: Hop-by-hop DAO-ACK Figure 2: Hop-by-hop DAO-ACK
1-> 2-> 1-> 2->
DAO DAO DAO DAO
(TgtNode)--------(6LR)-------(root) (TgtNode)--------(6LR)-------(root)
ACK ACK ACK ACK
<-4 <-3 <-4 <-3
Figure 3: End-to-End DAO-ACK Figure 3: End-to-End DAO-ACK
4.1. Significance of bidirectional Path establishment indication and 4.1. Significance of bidirectional Path establishment indication and
relevance of DAO-ACK relevance of DAO-ACK
Lot of application traffic patterns requires that the bidirectional Lot of application traffic patterns requires that the bidirectional
path be established between the target node and the root. A typical path be established between the target node and the root. A typical
example is that COAP request with ACK bit set would require an example is that COAP request with ACK bit set would require an
acknowledgement from the end receiver and thus warrants bidirectional acknowledgement from the end receiver and thus warrants bidirectional
path establishment. It is imperative that the target node first path establishment. It is imperative that the target node first
ascertains whether such a bidirectional path is established before ascertains whether such a bidirectional path is established before
skipping to change at page 7, line 41 skipping to change at page 7, line 43
Trickle algorithm defines a mechanism to reset the timer. Trickle Trickle algorithm defines a mechanism to reset the timer. Trickle
timer reset is unlike regular periodic timers wherein the timer is timer reset is unlike regular periodic timers wherein the timer is
simply reset to start again. Reset of trickle timer implies simply reset to start again. Reset of trickle timer implies
resetting the trickle back to Imin and starting with a new interval resetting the trickle back to Imin and starting with a new interval
as mentioned in Section 4.2 of [RFC6206]. as mentioned in Section 4.2 of [RFC6206].
|----|--------|----------------|------------------------------| . . . . |----|--------|----------------|------------------------------| . . . .
Imin I2 I3 I4 I5 Imin I2 I3 I4 I5
Figure 4: Trickle Timer Operation Figure 4: Trickle Timer Operation
The above figure shows an example of trickle intervals. An interval The above figure shows an example of trickle intervals. An interval
is double that of the previous interval size. Section 4.2. of is double that of the previous interval size. Section 4.2. of
[RFC6206] states that, [RFC6206] states that,
"If Trickle hears a transmission that is "inconsistent" and I is "If Trickle hears a transmission that is "inconsistent" and I is
greater than Imin, it resets the Trickle timer. To reset the timer, greater than Imin, it resets the Trickle timer. To reset the timer,
Trickle sets I to Imin and starts a new interval as in step 2. If I Trickle sets I to Imin and starts a new interval as in step 2. If I
is equal to Imin when Trickle hears an "inconsistent" transmission, is equal to Imin when Trickle hears an "inconsistent" transmission,
Trickle does nothing. Trickle can also reset its timer in response Trickle does nothing. Trickle can also reset its timer in response
skipping to change at page 14, line 5 skipping to change at page 14, line 11
this seqcnt and node B uses this seqcnt to determine whether the this seqcnt and node B uses this seqcnt to determine whether the
information node A sent in the packet is latest. Now lets assume, information node A sent in the packet is latest. Now lets assume,
the counter value reaches 250 after some operations on Node A, and the counter value reaches 250 after some operations on Node A, and
node B keeps receiving updated seqcnt from node A. Now consider that node B keeps receiving updated seqcnt from node A. Now consider that
node A reboots, and since it reinitializes the seqcnt value to 240 node A reboots, and since it reinitializes the seqcnt value to 240
and sends the information to node B (who has seqcnt of 250 stored on and sends the information to node B (who has seqcnt of 250 stored on
behalf of node A). As per section 7.2. of [RFC6550], when node B behalf of node A). As per section 7.2. of [RFC6550], when node B
receives this packet it will consider the information to be old receives this packet it will consider the information to be old
(since 240 < 250). (since 240 < 250).
+-----+-----+----------+ +=====+=====+==========+
| A | B | Output | | A | B | Output |
+-----+-----+----------+ +=====+=====+==========+
| 240 | 240 | A<B, old | | 240 | 240 | A<B, old |
| 240 | 241 | A<B, old | +-----+-----+----------+
| 240 | :: | A<B, old | | 240 | 241 | A<B, old |
| 240 | 256 | A<B, old | +-----+-----+----------+
| 240 | 0 | A<B, new | | 240 | :: | A<B, old |
| 240 | 1 | A>B, new | +-----+-----+----------+
| 240 | :: | A>B, new | | 240 | 256 | A<B, old |
| 240 | 127 | A>B, new | +-----+-----+----------+
+-----+-----+----------+ | 240 | 0 | A<B, new |
+-----+-----+----------+
| 240 | 1 | A>B, new |
+-----+-----+----------+
| 240 | :: | A>B, new |
+-----+-----+----------+
| 240 | 127 | A>B, new |
+-----+-----+----------+
Default values for lollipop counters considered from [RFC6550] Table 1: Example
Section 7.2. lollipop counter
operation
Table 1: Example lollipop counter operation Default values for lollipop counters considered from [RFC6550]
Section 7.2.
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.
14.3. RPL State variables 14.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
skipping to change at page 15, line 30 skipping to change at page 16, line 7
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.
14.4. State variables update frequency 14.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 Table 2: RPL State variables
Table 2: RPL State variables Low=<5 per day, High=>5 per day; SM=Storing MOP, NSM=Non-Storing MOP
14.5. Deliberations 14.5. Deliberations
(1) Is it possible that RPL removes the use of persistent storage (1) Is it possible that RPL removes 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
skipping to change at page 19, line 16 skipping to change at page 19, line 45
Bormann, "Neighbor Discovery Optimization for IPv6 over Bormann, "Neighbor Discovery Optimization for IPv6 over
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>.
21.2. Informative References 21.2. Informative References
[I-D.clausen-lln-rpl-experiences] [I-D.clausen-lln-rpl-experiences]
Clausen, T., Verdiere, A. C. D., Yi, J., Herberg, U., and Clausen, T., Verdiere, A. C. D., Yi, J., Herberg, U., and
Y. Igarashi, "Observations on RPL: IPv6 Routing Protocol Y. Igarashi, "Observations on RPL: IPv6 Routing Protocol
for Low power and Lossy Networks", draft-clausen-lln-rpl- for Low power and Lossy Networks", Work in Progress,
experiences-11 (work in progress), March 2018. Internet-Draft, draft-clausen-lln-rpl-experiences-11, 27
March 2018, <https://www.ietf.org/archive/id/draft-
clausen-lln-rpl-experiences-11.txt>.
[I-D.ietf-intarea-adhoc-wireless-com] [I-D.ietf-intarea-adhoc-wireless-com]
Baccelli, E. and C. E. Perkins, "Multi-hop Ad Hoc Wireless Baccelli, E. and C. E. Perkins, "Multi-hop Ad Hoc Wireless
Communication", draft-ietf-intarea-adhoc-wireless-com-02 Communication", Work in Progress, Internet-Draft, draft-
(work in progress), July 2016. ietf-intarea-adhoc-wireless-com-02, 20 July 2016,
<https://www.ietf.org/archive/id/draft-ietf-intarea-adhoc-
wireless-com-02.txt>.
[I-D.ietf-roll-aodv-rpl] [I-D.ietf-roll-aodv-rpl]
Anamalamudi, S., Zhang, M., Perkins, C. E., Anand, S., and Anamalamudi, S., Perkins, C. E., Anand, S., and B. Liu,
B. Liu, "Supporting Asymmetric Links in Low Power "Supporting Asymmetric Links in Low Power Networks: AODV-
Networks: AODV-RPL", draft-ietf-roll-aodv-rpl-10 (work in RPL", Work in Progress, Internet-Draft, draft-ietf-roll-
progress), April 2021. aodv-rpl-11, 16 September 2021,
<https://www.ietf.org/archive/id/draft-ietf-roll-aodv-rpl-
11.txt>.
[Perlman83] [Perlman83]
Perlman, R., "Fault-Tolerant Broadcast of Routing Perlman, R., "Fault-Tolerant Broadcast of Routing
Information", North-Holland Computer Networks, Vol.7, Information", North-Holland Computer Networks, Vol.7,
December 1983. December 1983.
Appendix A. Additional Stuff Appendix A. Additional Stuff
Authors' Addresses Authors' Addresses
Rahul Arvind Jadhav (editor) Rahul Arvind Jadhav (editor)
Marathahalli Marathahalli
Bangalore, Karnataka 560037 Bangalore 560037
Karnataka
India India
Email: rahul.ietf@gmail.com Email: rahul.ietf@gmail.com
Rabi Narayan Sahoo Rabi Narayan Sahoo
Juniper Juniper
Whitefield Whitefield
Bangalore, Karnataka 560037 Bangalore 560037
Karnataka
India India
Email: rabinarayans0828@gmail.com Email: rabinarayans0828@gmail.com
Yuefeng Wu Yuefeng Wu
Huawei Huawei
No.101, Software Avenue, Yuhuatai District, No.101, Software Avenue, Yuhuatai District,
Nanjing, Jiangsu 210012 Nanjing
Jiangsu, 210012
China China
Phone: +86-15251896569 Phone: +86-15251896569
Email: wuyuefeng@huawei.com Email: wuyuefeng@huawei.com
 End of changes. 34 change blocks. 
65 lines changed or deleted 85 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/