--- 1/draft-ietf-roll-efficient-npdao-14.txt 2019-07-08 06:14:17.338420861 -0700 +++ 2/draft-ietf-roll-efficient-npdao-15.txt 2019-07-08 06:14:17.390422171 -0700 @@ -1,22 +1,22 @@ ROLL R. Jadhav, Ed. Internet-Draft Huawei Intended status: Standards Track P. Thubert -Expires: January 4, 2020 Cisco +Expires: January 9, 2020 Cisco R. Sahoo Z. Cao Huawei - July 3, 2019 + July 8, 2019 Efficient Route Invalidation - draft-ietf-roll-efficient-npdao-14 + draft-ietf-roll-efficient-npdao-15 Abstract 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 proactive route invalidation message called as "Destination Cleanup Object" (DCO) is specified which fulfills requirements of an optimized route invalidation messaging. @@ -28,21 +28,21 @@ 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 January 4, 2020. + This Internet-Draft will expire on January 9, 2020. Copyright Notice Copyright (c) 2019 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 @@ -55,56 +55,57 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language and Terminology . . . . . . . . . . 3 1.2. Current NPDAO messaging . . . . . . . . . . . . . . . . . 4 1.3. Why Is NPDAO Important? . . . . . . . . . . . . . . . . . 5 2. Problems with current NPDAO messaging . . . . . . . . . . . . 6 2.1. Lost NPDAO due to link break to the previous parent . . . 6 2.2. Invalidate Routes of Dependent Nodes . . . . . . . . . . 6 2.3. Possible route downtime caused by asynchronous operation - of NPDAO and DAO . . . . . . . . . . . . . . 6 + of NPDAO and DAO . . . . . . . . . . . . . . . . . . . . 6 3. Requirements for the NPDAO Optimization . . . . . . . . . . . 6 3.1. Req#1: Remove messaging dependency on link to the previous parent . . . . . . . . . . . . . . . . . . . . . 6 3.2. Req#2: Dependent nodes route invalidation on parent switching . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Req#3: Route invalidation should not impact data traffic 7 4. Changes to RPL signaling . . . . . . . . . . . . . . . . . . 7 4.1. Change in RPL route invalidation semantics . . . . . . . 7 4.2. Transit Information Option changes . . . . . . . . . . . 8 4.3. Destination Cleanup Object (DCO) . . . . . . . . . . . . 9 4.3.1. Secure DCO . . . . . . . . . . . . . . . . . . . . . 10 4.3.2. DCO Options . . . . . . . . . . . . . . . . . . . . . 10 4.3.3. Path Sequence number in the DCO . . . . . . . . . . . 10 4.3.4. Destination Cleanup Option Acknowledgment (DCO-ACK) . 11 4.3.5. Secure DCO-ACK . . . . . . . . . . . . . . . . . . . 12 4.4. DCO Base Rules . . . . . . . . . . . . . . . . . . . . . 12 4.5. Unsolicited DCO . . . . . . . . . . . . . . . . . . . . . 12 4.6. Other considerations . . . . . . . . . . . . . . . . . . 13 4.6.1. Dependent Nodes invalidation . . . . . . . . . . . . 13 4.6.2. NPDAO and DCO in the same network . . . . . . . . . . 13 - 4.6.3. DCO with multiple preferred parents . . . . . . . . . 14 - 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 + 4.6.3. Considerations for DCO retry . . . . . . . . . . . . 14 + 4.6.4. DCO with multiple preferred parents . . . . . . . . . 15 + 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6.1. New Registry for the Destination Cleanup Object (DCO) - Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 15 + Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.2. New Registry for the Destination Cleanup Object - Acknowledgment (DCO-ACK) Status field . . . . . . . . . . 16 + Acknowledgment (DCO-ACK) Status field . . . . . . . . . . 17 6.3. New Registry for the Destination Cleanup Object (DCO) Acknowledgment Flags . . . . . . . . . . . . . . . . . . 17 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 - 8. Normative References . . . . . . . . . . . . . . . . . . . . 18 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 + 8. Normative References . . . . . . . . . . . . . . . . . . . . 19 Appendix A. Example Messaging . . . . . . . . . . . . . . . . . 19 - A.1. Example DCO Messaging . . . . . . . . . . . . . . . . . . 19 - A.2. Example DCO Messaging with multiple preferred parents . . 20 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 + A.1. Example DCO Messaging . . . . . . . . . . . . . . . . . . 20 + A.2. Example DCO Messaging with multiple preferred parents . . 21 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction RPL [RFC6550] (Routing Protocol for Low power and lossy networks) specifies a proactive distance-vector based routing scheme. RPL has optional messaging in the form of DAO (Destination Advertisement Object) messages, which the 6LBR (6Lo Border Router) and 6LR (6Lo Router) can use to learn a route towards the downstream nodes. In storing mode, DAO messages would result in routing entries being created on all intermediate 6LRs from the node's parent all the way @@ -407,27 +408,27 @@ Figure 3: DCO base object RPLInstanceID: 8-bit field indicating the topology instance associated with the DODAG, as learned from the DIO. K: The 'K' flag indicates that the recipient of DCO message is expected to send a DCO-ACK back. If the DCO-ACK is not received even after setting the 'K' flag, an implementation may retry the DCO at a later time. The number of retries are implementation and deployment dependent and are expected to be kept similar with those used in DAO - retries in [RFC6550]. A node receiving a DCO message without the 'K' - flag set MAY respond with a DCO-ACK, especially to report an error - condition. An example error condition could be that the node sending - the DCO-ACK does not find the routing entry for the indicated target. - When the sender does not set the 'K' flag it is an indication that - the sender does not expect a response, and the sender SHOULD NOT - retry the DCO. + retries in [RFC6550]. Section 4.6.3 specifies the considerations for + DCO retry. A node receiving a DCO message without the 'K' flag set + MAY respond with a DCO-ACK, especially to report an error condition. + An example error condition could be that the node sending the DCO-ACK + does not find the routing entry for the indicated target. When the + sender does not set the 'K' flag it is an indication that the sender + does not expect a response, and the sender SHOULD NOT retry the DCO. D: The 'D' flag indicates that the DODAGID field is present. This flag MUST be set when a local RPLInstanceID is used. Flags: The 6 bits remaining unused in the Flags field are reserved for future use. These bits MUST be initialized to zero by the sender and MUST be ignored by the receiver. Reserved: 8-bit unused field. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver. @@ -628,21 +629,54 @@ 1. Use NPDAO to invalidate the previous route and send regular DAO on the new path. 2. Send regular DAO on the new path with the 'I' flag set in the Transit Information Option such that the common ancestor node initiates the DCO message downstream to invalidate the previous route. This document recommends using option 2 for reasons specified in Section 3 in this document. -4.6.3. DCO with multiple preferred parents + This document assumes that all the 6LRs in the network support this + specification. If there are 6LRs en-route DCO message path which do + not support this document, then the route invalidation for + corresponding targets may not work or may work partially i.e., only + part of the path supporting DCO may be invalidated. Alternatively, a + node could generate an NPDAO if it does not receive a DCO with itself + as target within specified time limit. The specified time limit is + deployment specific and depends upon the maximum depth of the network + and per hop average latency. Note that sending NPDAO and DCO for the + same operation would not result in unwanted side-effects because the + acceptability of NPDAO or DCO depends upon the Path Sequence + freshness. + +4.6.3. Considerations for DCO retry + + A DCO message could be retried by a sender if it sets the 'K' flag + and does not receive a DCO-ACK. The DCO retry time could be + dependent on the maximum depth of the network and average per hop + latency. This could range from 2 seconds to 120 seconds depending on + the deployment. In case the latency limits are not known, an + implementation MUST NOT retry more than once in 3 seconds and MUST + NOT retry more than 3 times. + + The number of retries could also be set depending on how critical the + route invalidation could be for the deployment and the link layer + retry configuration. For networks supporting only MP2P and P2MP + flows, such as in AMI and telemetry applications, the 6LRs may not be + very keen to invalidate routes, unless they are highly memory- + constrained. For home and building automation networks which may + have substantial P2P traffic, the 6LRs might be keen to invalidate + efficiently because it may additionally impact the forwarding + efficiency. + +4.6.4. DCO with multiple preferred parents [RFC6550] allows a node to select multiple preferred parents for route establishment. Section 9.2.1 of [RFC6550] specifies, "All DAOs generated at the same time for the same Target MUST be sent with the same Path Sequence in the Transit Information". Subsequently when route invalidation has to be initiated, RPL mentions use of NPDAO which can be initiated with an updated Path Sequence to all the parent nodes through which the route is to be invalidated. With DCO, the Target node itself does not initiate the route