--- 1/draft-ietf-roll-rpl-observations-03.txt 2020-05-21 02:13:04.297805460 -0700 +++ 2/draft-ietf-roll-rpl-observations-04.txt 2020-05-21 02:13:04.325805837 -0700 @@ -1,19 +1,19 @@ ROLL R. Jadhav, Ed. Internet-Draft R. Sahoo Intended status: Standards Track Y. Wu -Expires: May 29, 2020 Huawei - November 26, 2019 +Expires: November 22, 2020 Huawei + May 21, 2020 RPL Observations - draft-ietf-roll-rpl-observations-03 + draft-ietf-roll-rpl-observations-04 Abstract This document describes RPL protocol design issues, various observations and possible consequences of the design and implementation choices. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -22,25 +22,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on May 29, 2020. + This Internet-Draft will expire on November 22, 2020. Copyright Notice - Copyright (c) 2019 IETF Trust and the persons identified as the + Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -53,57 +53,58 @@ 2.1. Requirements Language and Terminology . . . . . . . . . . 3 3. DTSN increment in storing MOP . . . . . . . . . . . . . . . . 4 3.1. Deliberations . . . . . . . . . . . . . . . . . . . . . . 5 4. DAO retransmission and use of DAO-ACK in storing MOP . . . . 5 4.1. Significance of bidirectional Path establishment indication and relevance of DAO-ACK . . . . . . . . . . . 6 4.2. Problems with hop-by-hop DAO-ACK . . . . . . . . . . . . 6 4.3. Problems with end-to-end DAO-ACK . . . . . . . . . . . . 6 4.4. Deliberations . . . . . . . . . . . . . . . . . . . . . . 6 4.5. Implementation Notes . . . . . . . . . . . . . . . . . . 7 - 5. Interpreting Trickle Timer Reset . . . . . . . . . . . . . . 7 - 6. Handling resource unavailability . . . . . . . . . . . . . . 7 + 5. Interpreting Trickle Timer . . . . . . . . . . . . . . . . . 7 + 6. Handling resource unavailability . . . . . . . . . . . . . . 8 6.1. Deliberations . . . . . . . . . . . . . . . . . . . . . . 8 - 7. Handling aggregated targets . . . . . . . . . . . . . . . . . 8 - 7.1. Deliberations . . . . . . . . . . . . . . . . . . . . . . 8 + 7. Handling aggregated targets . . . . . . . . . . . . . . . . . 9 + 7.1. Deliberations . . . . . . . . . . . . . . . . . . . . . . 9 8. RPL Transit Information in DAO . . . . . . . . . . . . . . . 9 - 8.1. Deliberations . . . . . . . . . . . . . . . . . . . . . . 9 - 9. Upgrades or Extensions to RPL protocol . . . . . . . . . . . 9 - 10. Asymmetric Links and RPL . . . . . . . . . . . . . . . . . . 9 - 11. Adjacencies probing with RPL . . . . . . . . . . . . . . . . 10 - 11.1. Deliberations . . . . . . . . . . . . . . . . . . . . . 10 - 12. Control Options eliding mechanism in RPL . . . . . . . . . . 11 - 13. Managing persistent variables across node reboots . . . . . . 11 - 13.1. Persistent storage and RPL state information . . . . . . 11 - 13.2. Lollipop Counters . . . . . . . . . . . . . . . . . . . 12 - 13.3. RPL State variables . . . . . . . . . . . . . . . . . . 13 - 13.3.1. DODAG Version . . . . . . . . . . . . . . . . . . . 13 - 13.3.2. DTSN field in DIO . . . . . . . . . . . . . . . . . 13 - 13.3.3. PathSequence . . . . . . . . . . . . . . . . . . . . 13 - 13.4. State variables update frequency . . . . . . . . . . . . 14 - 13.5. Deliberations . . . . . . . . . . . . . . . . . . . . . 14 - 13.6. Implementation Notes . . . . . . . . . . . . . . . . . . 14 - 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 - 14.3. Deliberations . . . . . . . . . . . . . . . . . . . . . 15 - 15. RPL under-specification . . . . . . . . . . . . . . . . . . . 15 - 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 - 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 - 18. Security Considerations . . . . . . . . . . . . . . . . . . . 16 - 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 19.1. Normative References . . . . . . . . . . . . . . . . . . 16 - 19.2. Informative References . . . . . . . . . . . . . . . . . 17 - - Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 18 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 + 8.1. Deliberations . . . . . . . . . . . . . . . . . . . . . . 10 + 9. Upgrades or Extensions to RPL protocol . . . . . . . . . . . 10 + 10. Path Control bits handling . . . . . . . . . . . . . . . . . 10 + 11. Asymmetric Links and RPL . . . . . . . . . . . . . . . . . . 11 + 12. Adjacencies probing with RPL . . . . . . . . . . . . . . . . 11 + 12.1. Deliberations . . . . . . . . . . . . . . . . . . . . . 12 + 13. Control Options eliding mechanism in RPL . . . . . . . . . . 12 + 14. Managing persistent variables across node reboots . . . . . . 12 + 14.1. Persistent storage and RPL state information . . . . . . 12 + 14.2. Lollipop Counters . . . . . . . . . . . . . . . . . . . 13 + 14.3. RPL State variables . . . . . . . . . . . . . . . . . . 14 + 14.3.1. DODAG Version . . . . . . . . . . . . . . . . . . . 14 + 14.3.2. DTSN field in DIO . . . . . . . . . . . . . . . . . 14 + 14.3.3. PathSequence . . . . . . . . . . . . . . . . . . . . 15 + 14.4. State variables update frequency . . . . . . . . . . . . 15 + 14.5. Deliberations . . . . . . . . . . . . . . . . . . . . . 15 + 14.6. Implementation Notes . . . . . . . . . . . . . . . . . . 16 + 15. Capabilities and its role in RPL . . . . . . . . . . . . . . 16 + 15.1. Handshaking node capabilities . . . . . . . . . . . . . 16 + 15.2. How do Capabilities differ from MOP and Configuration + Option? . . . . . . . . . . . . . . . . . . . . . . . . 17 + 15.3. Deliberations . . . . . . . . . . . . . . . . . . . . . 17 + 16. Backward Compatibility issues with RPL Options . . . . . . . 17 + 17. RPL under-specification . . . . . . . . . . . . . . . . . . . 17 + 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 + 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 + 20. Security Considerations . . . . . . . . . . . . . . . . . . . 18 + 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 21.1. Normative References . . . . . . . . . . . . . . . . . . 18 + 21.2. Informative References . . . . . . . . . . . . . . . . . 19 + Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 20 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 1. Motivation The primary motivation for this draft is to enlist different issues 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 discussion track. This draft may in turn result in other work items taken up by the WG which may improvise on the issues mentioned herewith. @@ -278,51 +279,80 @@ (1) How should an implementation interpret the DAO-ACK semantics? (2) What is the best way for the target node to know that the end to end bidirectional path is successfully installed or updated? In NS-MOP, the DAO-ACK provides a clear way to do this. Can the same be achieved for storing-MOP? (3) What happens if the DAO-ACK with Status!=0 is responded by ancestor node? - (4) How to selectively NACK subset of targets in case target - containers are aggregated? + (4) How to selectively NACK subset of targets in case target options + are aggregated? 4.5. Implementation Notes Current RPL open source implementations have both types of DAO-ACK implementations. For e.g. RIOT supports hop-by-hop DAO-ACK. Contiki older versions supported hop-by-hop ACK but the recent version have changed to end-to-end ACK implementation. The sequence of sending no-path DAO and DAO matters when updating the routing adjacencies on a parent switch. If an implementation chooses to send no-path DAO before DAO then it results in significantly more 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 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 limiting the propagation of subsequent no-path DAO till this common ancestor. -5. Interpreting Trickle Timer Reset +5. Interpreting Trickle Timer - 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]. + Trickle algorithm defines a mechanism to reset the timer. Trickle + timer reset is unlike regular periodic timers wherein the timer is + simply reset 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. +|----|--------|----------------|--------------------------------| . . . . . . + Imin I2 I3 I4 I5 + + Figure 4: Trickle Timer Operation + + The above figure shows an example of trickle intervals. An interval + is double that of the previous interval size. Section 4.2. of + [RFC6206] states that, + + "If Trickle hears a transmission that is "inconsistent" and I is + 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 + is equal to Imin when Trickle hears an "inconsistent" transmission, + Trickle does nothing. Trickle can also reset its timer in response + to external "events"." + + Thus if the trickle timer has advanced to subsequent intervals i.e., + >= I2, then a reset of trickle timer implies going back to Imin. + However, if the trickle timer is currently in Imin and if it hears an + inconsistent transmission then it does nothing. + + In context to multicast DIS/DIO operation, this implies that if the + DIO trickle timer is already at Imin and if the node hears a + multicast DIS, then the timer does nothing. It MUST NOT reset the + timer again in this case. + + An implementation MUST never restart the timer within an interval. + For e.g., in the above figure, if the timer is in interval I2, the + implementation MUST never restart the timer to the beginning of the + current interval i.e., I2. If the timer is in interval T2 and if the + reset is to be done then the interval is set back to Imin. If the + timer is already in Imin, then the reset should do nothing. 6. Handling resource unavailability The nodes in the constrained networks have to maintain various records such as neighbor cache entries and routing entries on behalf of other targets to facilitate packet forwarding. Because of the constrained nature of the devices the memory available may be very limited and thus the path selection algorithm may have to take into consideration such resource constraints as well. @@ -346,78 +376,119 @@ RPL allows and defines specific procedures so as to aid target aggregation in DAO. Having said that, the specification does not mandate use of aggregated targets nor does it make any comment on whether a receiving node needs to handle it. Target aggregation is an useful tool and especially helps with link layer technologies that does not suffer from low MTUs such as PLC. Even if the implementation does not support aggregating targets, it should atleast mandate reception of aggregated targets in DAO. 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 option. Thus in case of aggregated 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. 7.1. Deliberations Even if the implementation does not support aggregating targets, should it atleast mandate reception and handling of aggregated targets in DAO? There is a good scope for compressing aggregated targets which can significantly reduce the RPL control overhead. - How to selectively NACK subset of targets in case target - containers are aggregated? + How to selectively NACK subset of targets in case target options + are aggregated? The DEFAULT_DAO_DELAY of 1sec does not help much with aggregation. The upstream parent nodes should wait for more time then the child nodes so as to effectively aggregate. Can we have DEFAULT_DAO_DELAY a function of the level/rank the node is at? 8. RPL Transit Information in DAO RPL allows associating a target or set of targets with a Transit - information container which contains attributes for a path to one or + Information Option which contains attributes for a path to one or more destinations identified by the set of targets. In case of NS- MOP, the transit Information will contain the all critical Parent Address which allows the common ancestor usually the root to identify the source route header for the target node. The Transit Information also contains other information such as Path Sequence and Path 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 Option for targets. 8.1. Deliberations Is it ok to let implementations decide on the inclusion of Transit - Information container? + Information Option? Is it possible to achieve interop without mandating use of Transit - Information Container? + Information Option? - If the Transit Information container is sent, should the handling - of PathSequence be mandated? + If the Transit Information Option is sent, should the handling of + PathSequence be mandated? 9. Upgrades or Extensions to RPL protocol RPL extensibility is highly desirable and is controlled by protocol elements within the messaging framework. In the pursuit to keep the signalling overhead less, RPL specification has been restricting in its approach to extend its field ranges, thus in some cases putting extensibility at stakes. Consider for example, the mode of operation bits which is three bits in the RPL specification. These bits are already saturated and it may be difficult to add major upgrades without extending these bits. -10. Asymmetric Links and RPL + Addition of new Control Options or new RPL Codes almost certainly + results in backward compatibility issues. RFC6550 clearly mentions + that a message with an unknown RPL Code MUST be silently discarded. + However, no explicit handling is suggested for unknown RPL control + option types. In some cases, implementations simply copy-forward an + unknown option as it is while in other cases the unknown option is + stripped off before forwarding the message. + + Deliberations: + + (1) What are the extensibility options RPL could implement? How + much overhead would it incur? + + (2) Most of the extensions are in the form of new control options. + Should RPL have a mechanism to only handle such extensions in a + backward compatible but in a generic manner? + +10. Path Control bits handling + + RPL uses Path Control bits in the DAO's Transit Information Option + for installing multiple downward routes to the nodes. These multiple + routes could be used for reliability, latency or traffic load- + balancing within a DAG. The path control bits are usable both in + storing and non-storing mode of operation. + + RFC6550 Section 9.9 bullet point 9 requires a mandatory setting of + Path Control bits in all the unicast DAOs sent by the Target node. + However, no existing implementation of RPL supports this. There is + no reason for a network which only requires a single path to the root + to mandatorily support path control bits. + + Deliberations: + + (1) Should the mandatory clause for supporting Path Control Bits in + RFC6550 Section 9.9 point 9 be removed? + + (2) Handling Path Control Bits may be complex. An implementation + guideline explaining the use-cases and resource (memory + requirements) assumptions would help implementors decide the + utility of this technique. + +11. Asymmetric Links and RPL Section 3.1 of [I-D.ietf-intarea-adhoc-wireless-com] explains asymmetric link characteristics and what it takes for a protocol to support asymmetric links. RPL depends on bi-directional links for control even though near-perfect symmetry is not expected. The implication of this is that the upstream and downstream path remains same within a given RPL instance for any pair of nodes. There are following questions sprouting of this design: (1) Is it possible to detect asymmetric links? @@ -429,21 +501,21 @@ instances which are coupled. This allows disjoint upstream and downstream paths between pair of nodes assuming that the link asymmetricity is detected using some outside techniques. The link assumes that the link asymmetricity is already known to the nodes in the form of static configuration. In case of 6tisch networks, the availability of transmission slots information can be used to identify link asymmetricity. The challenge with regards to detecting link asymmetricity arises from scenarios where, for example, the nodes transmit with unequal power levels. -11. Adjacencies probing with RPL +12. Adjacencies probing with RPL RPL avoids periodic hello messaging as compared to other distance- vector protocols. It uses trickle timer based mechanism to update configuration parameters. This significantly reduces the RPL control overhead. One of the fallout of this design choice is that, in the absence of regular traffic, the adjacencies could not be tested and repaired if broken. 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 @@ -453,42 +525,42 @@ probing is implementation dependent, but the node is expected to invoke probing only when (1) There is no data traffic based on which the links could be tested. (2) There is no L2 feedback. In some case, L2 might provide periodic beacons at link layer and the absence of beacons could be used for link tests. -11.1. Deliberations +12.1. Deliberations (1) Should the probing scheme be standardized? In some cases using multicast based probing may prove advantageous. (2) In some cases using multicast based probing may prove advantageous. Currently RPL does not have multicast based probing. Multicast DIS/DIO may not be suitable for probing because it could possibly lead to change of states. -12. Control Options eliding mechanism in RPL +13. Control Options eliding mechanism in RPL RPL configuration changes are rare and thus various configuration 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 guidelines on how the eliding should be handled. In the absence of such guidelines, it is possible that certain nodes may end up using stale configuration in the event of transient link failures. -13. Managing persistent variables across node reboots +14. Managing persistent variables across node reboots -13.1. Persistent storage and RPL state information +14.1. Persistent storage and RPL state information Devices are required to be functional for several years without manual maintanence. Usually battery power consumption is considered key for operating the devices for several (tens of) years. But apart from battery, flash memory endurance may prove to be a lifetime bottleneck in constrained networks. Endurance is defined as maximum number of erase-write cycles that a NAND/NOR cell can undergo before losing its 'gauranteed' write operation. In some cases (cheaper 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 @@ -508,21 +580,21 @@ information then it becomes counter-productive. In a star topology, the amount of persistent data write done by network protocols is very limited. But ad-hoc networks employing routing protocols such as RPL assume certain state information to be retained across node reboots. In case of IoT devices this storage is mostly floating gate based NAND/NOR based flash memory. The impact of loss of this state information differs depending upon the type (6LN/6LR/6LBR) of the node. -13.2. Lollipop Counters +14.2. Lollipop Counters [RFC6550] Section 7.2. explains sequence counter operation defining lollipop [Perlman83] style counters. Lollipop counters specify mechanism in which even if the counter value wraps, the algorithm 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 reboot, but is not foolproof. 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 @@ -552,205 +624,229 @@ Default values for lollipop counters considered from [RFC6550] Section 7.2. Table 1: Example lollipop counter operation 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 smaller. Thus node A needs to maintain the seqcnt in persistent storage and reuse this on reboot. -13.3. RPL State variables +14.3. RPL State variables The impact of loss of RPL state information differs depending upon the node type (6LN/6LR/6LBR). Following sections explain different state variables and the impact in case this information is lost on reboot. -13.3.1. DODAG Version +14.3.1. DODAG Version The tuple (RPLInstanceID, DODAGID, DODAGVersionNumber) uniquely identifies a DODAG Version. DODAGVersionNumber is incremented everytime a global repair is initiated for the instance (global or local). A node receiving an older DODAGVersionNumber will ignore the 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 DODAGVersionNumber in the persistent storage, so as to be available on reboot. In case the 6LBR could not use the latest DODAGVersionNumber the implication are that it won't be able to recover/re-establish the routing table. -13.3.2. DTSN field in DIO +14.3.2. DTSN field in DIO DTSN (Destination advertisement Trigger Sequence Number) is a DIO message field used as part of procedure to maintain Downward routes. 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 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 S-MOP, 6LRs additionally keep downward routes and thus control this field update. 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 so that the downward routes are established in all parent/ancestor set. Thus in S-MOP, the frequency of DTSN update might be relatively high (given the node density and hysteresis set by objective function to switch parent). -13.3.3. PathSequence +14.3.3. PathSequence PathSequence is part of RPL Transit Option, and associated with RPL Target option. A node whichs owns a target address can associate a PathSequence in the DAO message to denote freshness of the target information. This is especially useful when a node uses multiple paths or multiple parents to advertise its reachability. Loss of PathSequence information maintained on the target node can result in routing adjacencies been lost on 6LRs/6LBR/6BBR. -13.4. State variables update frequency +14.4. State variables update frequency +--------------------+-------------------+------------------------+ | State variable | Update frequency | Impacts node type | +--------------------+-------------------+------------------------+ | DODAGVersionNumber | Low | 6LBR, 6LR(local DODAG) | | DTSN | High(SM),Low(NSM) | 6LBR, 6LR | | 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 -13.5. Deliberations +14.5. Deliberations - (1) Is it possible that RPL reduces the use of persistent storage + (1) Is it possible that RPL removes the use of persistent storage for maintaining state information? (2) In most cases, the node reboots will happen very rarely. Thus doing a persistent storage book-keeping for handling node reboot might not make sense. Is it possible to consider signaling (especially after the node reboots) so as to avoid maintaining this persistent state? Is it possible to use one-time on-reboot signalling to recover some state information? (3) It is necessary that RPL avoids using persistent storage as far as possible. Ideally, extensions to RPL should consider this as a design requirement especially for 6LR and 6LN nodes. DTSN and PathSequence are the primary state variables which have major impact. -13.6. Implementation Notes +14.6. Implementation Notes An implementation should use a random DAOSequence number on reboot so as to avoid a risk of reusing the same DAOSequence on reboot. Regardless the sequence counter size of 8bits does not provide much 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 previous DAOSequence. 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, then the chances are that the node power downs before writing to the persistent storage. -14. Capabilities and its role in RPL +15. Capabilities and its role in RPL RPL is a distributed protocol and it requires that the participating nodes agree on basic set of primitives to follow. RPL currently 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 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 still join the Instance as a leaf node or 6LN. RPL further uses DIO Configuration Option to advertise the configuration each node needs to use (for e.g., for trickle timer). -14.1. Handshaking node capabilities +15.1. Handshaking node capabilities Currently there exist no mechanism to handshake capabilities of the 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. There are several RPL extension proposals which are possibly optional features. Root needs to know if the 6LR/6LN supports these optional features to enable the extension in that path context. Similarly 6LRs and 6LNs need to know whether the root supports certain extensions that it can make use of. -14.2. How do Capabilities differ from MOP and Configuration Option? +15.2. How do Capabilities differ from MOP and Configuration Option? 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 can advertise its capabilities such that those can be seen by intermediate 6LRs and the root of the Instance. -14.3. Deliberations +15.3. Deliberations (1) Is it possible for leaf nodes to advertise their set of capabilities, which can be used by root and/or intermediate 6LRs to make run time decisions? (2) How should these capabilities be carried? Should it be carried in DAO/DIO/DAO-ACK? (3) Should the definition of capabilities be same in both directions (upstream/downstream)? -15. RPL under-specification +16. Backward Compatibility issues with RPL Options + + Most of the new work in ROLL requires addition of new control + options. Everytime a new control option is added, it is required + that all the nodes upgrade to support this option. In many cases, + the new specification declares using a Flag day to switch to the new + functionality. + + New control options may not require mandatory handling on every node + but it requires at-least some processing. For e.g., assume that a + new control option is added to DIO message. The option does not + require any handling on the nodes not supporting it but it requires + at-least for these nodes to forward this new control option + downstream. Currently the new control option may be stripped off. + + It should be possible for the unknown control options to be copied + as-is to the downstream/upstream node(s). The specification defining + the new control option will decide whether a node should strip-off or + copy the unknown control option. + +17. RPL under-specification (a) PathSequence: Is it mandatory to use PathSequence in DAO Transit - container? RPL mentions that a 6LR/6LBR hosting the routing - entry on behalf of target node should refresh the lifetime on - reception of a new Path Sequence. But RPL does not necessarily - mandate use of Path Sequence. Most of the open source - implementation [RIOT] [CONTIKI] currently do not issue Path - Sequence in the DAO message. + Information Option? RPL mentions that a 6LR/6LBR hosting the + routing entry on behalf of target node should refresh the + lifetime on reception of a new Path Sequence. But RPL does not + necessarily mandate use of Path Sequence. Most of the open + source implementation [RIOT] [CONTIKI] currently do not issue + Path Sequence in the DAO message. - (b) Target Container aggregation in DAO: RPL allows multiple targets - to be aggregated in a single DAO message and has introduced a + (b) Target Option aggregation in DAO: RPL allows multiple targets 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 enable such aggregation. But RPL does not have clear text on handling of aggregated DAOs and thus it hinders interoperability. (c) DTSN Update: RPL does not clearly define in which cases DTSN should be updated in case of storing mode of operation. More details for this are presented in Section 3. -16. Acknowledgements +18. Acknowledgements Many thanks to Pascal Thubert for hallway chats and for helping understand the existing design rationales. Thanks to Michael Richardson for Unstrung RPL implementation rationale. Thanks to ML discussions, in particular (https://www.ietf.org/mail- archive/web/roll/current/msg09443.html). -17. IANA Considerations +19. IANA Considerations This memo includes no request to IANA. -18. Security Considerations +20. Security Considerations This is an information draft and does add any changes to the existing specifications. -19. References +21. References -19.1. Normative References +21.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . + [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, + "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, + March 2011, . + [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012, . [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., and D. Barthel, "Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks", RFC 6551, @@ -767,38 +863,38 @@ Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI 10.17487/RFC6775, November 2012, . [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and J. Martocci, "Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks", RFC 6997, DOI 10.17487/RFC6997, August 2013, . -19.2. Informative References +21.2. Informative References [I-D.clausen-lln-rpl-experiences] Clausen, T., Verdiere, A., Yi, J., Herberg, U., and Y. Igarashi, "Observations on RPL: IPv6 Routing Protocol for Low power and Lossy Networks", draft-clausen-lln-rpl- experiences-11 (work in progress), March 2018. [I-D.ietf-intarea-adhoc-wireless-com] Baccelli, E. and C. Perkins, "Multi-hop Ad Hoc Wireless Communication", draft-ietf-intarea-adhoc-wireless-com-02 (work in progress), July 2016. [I-D.ietf-roll-aodv-rpl] Anamalamudi, S., Zhang, M., Perkins, C., Anand, S., and B. - Liu, "Asymmetric AODV-P2P-RPL in Low-Power and Lossy - Networks (LLNs)", draft-ietf-roll-aodv-rpl-07 (work in - progress), April 2019. + Liu, "AODV based RPL Extensions for Supporting Asymmetric + P2P Links in Low-Power and Lossy Networks", draft-ietf- + roll-aodv-rpl-08 (work in progress), May 2020. [Perlman83] Perlman, R., "Fault-Tolerant Broadcast of Routing Information", North-Holland Computer Networks, Vol.7, December 1983. Appendix A. Additional Stuff Authors' Addresses