--- 1/draft-ietf-roll-efficient-npdao-06.txt 2018-09-27 02:13:08.445210157 -0700 +++ 2/draft-ietf-roll-efficient-npdao-07.txt 2018-09-27 02:13:08.477210924 -0700 @@ -1,22 +1,22 @@ ROLL R. Jadhav, Ed. Internet-Draft Huawei Intended status: Standards Track P. Thubert -Expires: March 30, 2019 Cisco +Expires: March 31, 2019 Cisco R. Sahoo Z. Cao Huawei - September 26, 2018 + September 27, 2018 Efficient Route Invalidation - draft-ietf-roll-efficient-npdao-06 + draft-ietf-roll-efficient-npdao-07 Abstract This document describes the problems associated with the use of NPDAO messaging in RPL and signaling changes to improve route invalidation efficiency. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -25,42 +25,42 @@ 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 March 30, 2019. + This Internet-Draft will expire on March 31, 2019. Copyright Notice Copyright (c) 2018 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 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language and Terminology . . . . . . . . . . 3 - 1.2. Current NPDAO messaging . . . . . . . . . . . . . . . . . 3 + 1.2. Current NPDAO messaging . . . . . . . . . . . . . . . . . 4 1.3. Why NPDAO is important? . . . . . . . . . . . . . . . . . 4 2. Problems with current NPDAO messaging . . . . . . . . 5 2.1. Lost NPDAO due to link break to the previous parent . . . 5 2.2. Invalidate routes to dependent nodes . . . . . . . . . . 5 2.3. Possible route downtime caused by async operation of NPDAO and DAO . . . . . . . . . . . . . . . . . . . . . . 5 3. Requirements for the NPDAO Optimization . . . . . . . . . . . 5 3.1. Req#1: Tolerant to link failures to the previous parents . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Req#2: Dependent nodes route invalidation on parent @@ -71,58 +71,63 @@ 4.2. Transit Information Option changes . . . . . . . . . . . 7 4.3. Destination Cleanup Object (DCO) . . . . . . . . . . . . 8 4.3.1. Secure DCO . . . . . . . . . . . . . . . . . . . . . 9 4.3.2. DCO Options . . . . . . . . . . . . . . . . . . . . . 9 4.3.3. Path Sequence number in the DCO . . . . . . . . . . . 9 4.3.4. Destination Cleanup Option Acknowledgement (DCO-ACK) 9 4.3.5. Secure DCO-ACK . . . . . . . . . . . . . . . . . . . 10 4.4. Other considerations . . . . . . . . . . . . . . . . . . 11 4.4.1. Dependent Nodes invalidation . . . . . . . . . . . . 11 4.4.2. NPDAO and DCO in the same network . . . . . . . . . . 11 + 4.4.3. DCO with multiple preferred parents . . . . . . . . . 11 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . 12 - Appendix A. Example DCO Messaging . . . . . . . . . . . . . . . 12 + Appendix A. Example DCO Messaging . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction RPL [RFC6550] specifies a proactive distance-vector based routing - scheme. RPL has an optional messaging in the form of DAO messages - using which the 6LBR can learn route towards the nodes. In storing - mode, DAO messages would result in routing entries been created on - all intermediate hops from the node's parent all the way towards the - 6LBR. + scheme. RPL has an optional messaging in the form of DAO + (Destination Advertisement Object) messages using which the 6LBR can + learn route towards the nodes. In storing mode, DAO messages would + result in routing entries been created on all intermediate hops from + the node's parent all the way towards the 6LBR. RPL allows use of No-Path DAO (NPDAO) messaging to invalidate a routing path corresponding to the given target, thus releasing resources utilized on that path. A NPDAO is a DAO message with route lifetime of zero, originates at the target node and always flows upstream towards the 6LBR. This document explains the problems associated with the current use of NPDAO messaging and also discusses the requirements for an optimized route invalidation messaging scheme. Further a new pro-active route invalidation message called as "Destination Cleanup Object (DCO)" is specified which fulfills requirements of an optimized route invalidation messaging. + The document only caters to the RPL's storing mode of operation + (MOP). The non-storing MOP does not require use of NPDAO for route + invalidation since routing entries are not maintained on 6LRs. + 1.1. Requirements Language and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. - The document only caters to the RPL's storing mode of operation - (MOP). The non-storing MOP does not require use of NPDAO for route - invalidation since routing entries are not maintained on 6LRs. + DAO: Destination Advertisement Object + + DIO: DODAG Information Object Common Ancestor node: 6LR node which is the first common node on the old and new path for the child node. NPDAO: No-Path DAO. A DAO message which has target with lifetime 0. DCO: Destination Cleanup Object, A new RPL control message type defined by this draft. Regular DAO: A DAO message with non-zero lifetime. @@ -222,24 +228,24 @@ to (C). An NPDAO sent from previous route may invalidate the existing route whereas there is no way to determine whether the new DAO has successfully updated the route entries on the new path. 3. Requirements for the NPDAO Optimization 3.1. Req#1: Tolerant to link failures to the previous parents When the switching node sends the NPDAO message to the previous parent, it is normal that the link to the previous parent is prone to - failure. Therefore, it is required that the NPDAO message must be - tolerant to the link failure. The link referred here represents the - link between the node and its previous parent (from whom the node is - now disassociating). + failure. Therefore, it is required that the route invalidation does + not depend on the previous link which is prone to failure. The + previous link referred here represents the link between the node and + its previous parent (from whom the node is now disassociating). 3.2. Req#2: Dependent nodes route invalidation on parent switching It should be possible to do route invalidation for dependent nodes rooted at the switching node. 3.3. Req#3: Route invalidation should not impact data traffic While sending the NPDAO and DAO messages, it is possible that the NPDAO successfully invalidates the previous path, while the newly @@ -285,21 +291,24 @@ are appended to add message/use-case specific attributes. As an example, a DAO message may be attributed by one or more "RPL Target" options which specifies the reachability information for the given targets. Similarly, a Transit Information option may be associated with a set of RPL Target options. The draft proposes a change in Transit Information option to contain "Invalidate previous route" (I) bit. This I-bit signals the common ancestor node to generate a DCO on behalf of the target node. The I-bit is carried in the transit information option which augments the - reachability information for a given set of RPL Target(s). + reachability information for a given set of RPL Target(s). Transit + information option should be carried in the DAO message with I-bit + set in case route invalidation is sought for the correspondig + target(s). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x06 | Option Length |E|I| Flags | Path Control | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path Sequence | Path Lifetime | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + @@ -396,21 +405,24 @@ The DCO carries a Target option and an associated Transit Information option with a lifetime of 0x00000000 to indicate a loss of reachability to that Target. 4.3.3. Path Sequence number in the DCO A DCO message may contain a Path Sequence in the transit information option to identify the freshness of the DCO message. The Path Sequence in the DCO MUST use the same Path Sequence number present in the regular DAO message when the DCO is generated in response to DAO - message. + message. The DAO and DCO path sequence are picked from the same + sequence number set. Thus if a DCO is received by a 6LR and + subsequently a DAO is received with old seqeunce number, then the DAO + should be ignored. 4.3.4. Destination Cleanup Option Acknowledgement (DCO-ACK) The DCO-ACK message may be sent as a unicast packet by a DCO recipient in response to a unicast DCO message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RPLInstanceID |D| Reserved | DCOSequence | Status | @@ -466,26 +478,33 @@ nodes invalidation. Dependent nodes will generate their respective DAOs to update their paths, and the previous route invalidation for those nodes should work in the similar manner described for switching node. The dependent node may set the I-bit in the transit information option as part of regular DAO so as to request invalidation of previous route from the common ancestor node. 4.4.2. NPDAO and DCO in the same network Even with the changed semantics, the current NPDAO mechanism in - [RFC6550] can still be used. There are certain scenarios where - current NPDAO signalling may still be used, for example, when the - route lifetime expiry of the target happens or when the node simply - decides to gracefully terminate the RPL session on graceful node - shutdown. Moreover a deployment can have a mix of nodes supporting - the proposed DCO and the existing NPDAO mechanism. + [RFC6550] can still be used, for example, when the route lifetime + expiry of the target happens or when the node simply decides to + gracefully terminate the RPL session on graceful node shutdown. + Moreover a deployment can have a mix of nodes supporting the proposed + DCO and the existing NPDAO mechanism. + +4.4.3. DCO with multiple preferred parents + + [RFC6550] allows a node to select multiple preferred parents for + route establishment. DCO can be used for route invalidation in such + cases as well. There are no changes required in the DCO messaging to + support multiple preferred parents and DCO should work seemlessly in + such scenarios. 5. Acknowledgements Many thanks to Cenk Gundogan, Simon Duquennoy, Georgios Papadopoulous, Peter Van Der Stok for their review and comments. 6. IANA Considerations IANA is requested to allocate new ICMPv6 RPL control codes in RPL [RFC6550] for DCO and DCO-ACK messages. @@ -495,29 +514,31 @@ +------+---------------------------------------------+--------------+ | 0x04 | Destination Cleanup Object | This | | | | document | | 0x05 | Destination Cleanup Object Acknowledgement | This | | | | document | | 0x84 | Secure Destination Cleanup Object | This | | | | document | | 0x85 | Secure Destination Cleanup Object | This | | | Acknowledgement | document | +------+---------------------------------------------+--------------+ + IANA is requested to allocate bit 18 in the Transit Information Option defined in RPL [RFC6550] section 6.7.8 for Invalidate route 'I' flag. 7. Security Considerations - This document handles security considerations inline to base RPL. - Secure versions of DCO and DCO-ACK are added similar to other RPL - messages. For general RPL security considerations, see [RFC6550]. + The document adds new messages (DCO, DCO-ACK) which are similar to + existing RPL messages such as DAO, DAO-ACK. Secure versions of DCO + and DCO-ACK are added similar to other RPL messages (such as DAO, + DAO-ACK). For general RPL security considerations, see [RFC6550]. 8. References 8.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, .