idnits 2.17.1 draft-jadhav-roll-storing-rootack-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 20, 2020) is 1466 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'Perlman83' is defined on line 292, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL R. Jadhav, Ed. 3 Internet-Draft Huawei 4 Intended status: Standards Track April 20, 2020 5 Expires: October 22, 2020 7 RPL Storing Root Ack 8 draft-jadhav-roll-storing-rootack-00 10 Abstract 12 This document explains problems with DAO-ACK handling in RPL Storing 13 MOP and provides updates to RFC6550 to solve those problems. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on October 22, 2020. 32 Copyright Notice 34 Copyright (c) 2020 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2.1. Requirements Language and Terminology . . . . . . . . . . 3 52 3. Problems with DAO-ACK in Storing MOP . . . . . . . . . . . . 3 53 3.1. End to End Path Establishment Indication . . . . . . . . 4 54 3.2. Target node unaware if it needs to retry the DAO . . . . 5 55 4. Requirements for DAO-ACK handling in Storing MOP . . . . . . 5 56 5. DAO-ACK from Root . . . . . . . . . . . . . . . . . . . . . . 5 57 5.1. Transit Information Option update in DAO message . . . . 6 58 5.2. Root sends DAO-ACK addressed to Target . . . . . . . . . 6 59 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 62 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 64 9.2. Informative References . . . . . . . . . . . . . . . . . 7 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Motivation 69 The primary motivation for this draft is to enlist different issues 70 with RPL operation and invoke a discussion within the working group. 71 This draft by itself is not intended for RFC tracks but as a WG 72 discussion track. This draft may in turn result in other work items 73 taken up by the WG which may improvise on the issues mentioned 74 herewith. 76 2. Introduction 78 RPL [RFC6550] specifies a proactive distance-vector routing scheme 79 designed for LLNs (Low Power and Lossy Networks). RPL enables the 80 network to be formed as a DODAG and supports storing mode and non- 81 storing mode of operations. Non-storing mode allows reduced memory 82 resource usage on the nodes by allowing non-BR nodes to operate 83 without managing a routing table and involves use of source routing 84 by the Root to direct the traffic along a specific path. In storing 85 mode of operation the routing happens on hop-by-hop basis and 86 intermediate routers need to maintain routing tables. 88 DAO messaging helps to install downstream routing paths in the DODAG. 89 DAOs are generated on hop-by-hop basis. DAO may contain multiple RPL 90 Control Options. The Target Option identifies the address prefix for 91 which the route has to be installed and the corresponding Transit 92 Information Option identifies the parameters (such as lifetime, 93 freshness-counter, etc) for the target. The DAO base object contains 94 the 'K' flag indicating that a DAO-ACK is sought by the sender. The 95 DAO, DAO-ACK progresses on hop-by-hop basis all the way till Root. 97 This draft highlights various issues with RPL DAO-ACK handling in 98 Storing MOP. The draft provides requirements to solve the issues and 99 provides an updates to RFC6550 based on these requirements. 101 2.1. Requirements Language and Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC 2119 [RFC2119]. 107 MOP = Mode of Operation 109 NS-MOP = RPL Non-Storing Mode of Operation 111 S-MOP = RPL Storing Mode of Operation 113 This document uses terminology described in [RFC6550]. 115 3. Problems with DAO-ACK in Storing MOP 117 Consider the following topology for the subsequent description: 119 (Root) 120 | 121 | 122 | 123 (A) 124 / \ 125 / \ 126 / \ 127 (B) -(C) 128 | / | 129 | / | 130 | / | 131 (D)- (E) 132 \ ; 133 \ ; 134 \ ; 135 (F) 136 / \ 137 / \ 138 / \ 139 (G) (H) 141 Figure 1: Sample topology 143 3.1. End to End Path Establishment Indication 145 Nodes need to know whether the end to end path till the Root has been 146 established before they can initiate application traffic. In case of 147 NS-MOP, the DAO is addressed to the Root from the Target node and the 148 Root sends DAO-ACK directly addressed back to the target node. Thus 149 in case of NS-MOP, the node can make use of this DAO-ACK as an 150 indication whether the necessary routes have been installed. 151 However, in case of Storing MOP, the DAO/DAO-ACK signalling happens 152 at every hop. 154 Non-Storing MOP 156 | D ======== B ======== A ======== (Root) 157 | ---------------DAO------------> 158 | <-----------DAO-ACK------------ 159 | 160 V 161 time 163 Figure 2: NS-MOP DAO/DAO-ACK handling 165 Storing MOP 167 | D ======== B ======== A ======== (Root) 168 | ---DAO---> 169 | <-DAO-ACK- 170 | ---DAO---> 171 | <-DAO-ACK- 172 | ---DAO---> 173 | <-DAO-ACK- 174 V 175 time 177 Figure 3: Storing MOP DAO/DAO-ACK handling 179 Consider Figure 1, when node D sends a DAO, the node B receives the 180 DAO and instantly sends back DAO-ACK. Node B then subsequently 181 generates the DAO with Target as Node D and sends it to node A. The 182 DAO with Target as Node D may take time (since the DAO is scheduled 183 with DAO_DELAY timer by every node) to finally reach the Root at 184 which point the end to end path is established. There is no way for 185 node D to know when the end to end path is established. This 186 information is needed for node D to initiate its application traffic. 187 Initiating application traffic prior to this might almost certainly 188 lead to application packet retries causing congestion in the network. 190 3.2. Target node unaware if it needs to retry the DAO 192 It is possible that the intermediate 6LR goes down while attempting 193 to generate DAO on behalf of the target node. In this case, the 194 target node has no way of knowing to retry the DAO, in which case the 195 route installation may not happen until the target node's DAO 196 lifetime expires. 198 Consider Figure 1, assume that node A was generating DAO with Target 199 node D and sending it to Root. Node A reboots before attempting to 200 send DAO to Root. Node A has already sent DAO-ACK downstream to node 201 B. In this case, the target node D is not aware that sending DAO has 202 failed somewhere upstream. Note that as per RFC6550 upstream DAO is 203 scheduled based on DAO_DELAY but DAO_ACK is sent instantaneously on 204 DAO reception from downstream node. 206 4. Requirements for DAO-ACK handling in Storing MOP 208 Following are the requirements: 210 Indicate end to end path establishment The Target node must know 211 when to initiate the application traffic based on end to end path 212 establishment. 214 Handle multiple targets in DAOs A DAO message may contain multiple 215 Target Options. The DAO-ACK mechanism must handle multiple 216 targets in DAO. 218 Handle DAOs with address prefix RPL DAO Target Option may contain an 219 address prefix i.e., not the full address. 221 Provide suitable way for target node to retry The Target node must 222 have a way to know and retry the DAO in case the DAO transmission 223 fails enroute. 225 Backward compatible with current DAO-ACK The current per hop DAO-ACK 226 must function as it is. Legacy nodes should be able to operate 227 without any changes. 229 5. DAO-ACK from Root 231 The draft defines a way for the RPL Root to send the DAO-ACK back 232 directly addressed to the Target node. The Target node can receive 233 the DAO-ACK directly thus getting an indication that the end to end 234 path till the Root has been successfully established. 236 5.1. Transit Information Option update in DAO message 238 The Target node indicates that it wishes to receive DAO-ACK directly 239 from Root by setting the newly defined 'K' flag in Transit 240 Information Option. 242 0 1 2 3 243 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 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Type = 0x06 | Option Length |E|I|K| Flags | Path Control | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Path Sequence | Path Lifetime | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 Figure 4: Updated Transit Information Option (New K flag added) 252 5.2. Root sends DAO-ACK addressed to Target 254 On receiving a DAO with Transit Information Option with 'K' flag set, 255 the Root MUST respond with a DAO-ACK immediately to the address 256 extracted from the corresponding Target Option. 258 The DAO-ACK MUST contain the Transit Information Option with 259 parameters copied from the DAO's Transit Information Option based on 260 which this DAO-ACK was generated. The PathSequence in the Transit 261 Information Option helps the Target node to identify for which DAO it 262 generated it has received the DAO-ACK. The DAOSequence in the base 263 DAO object is ignored by the Target node. 265 6. Acknowledgements 267 7. IANA Considerations 269 IANA is requested to allocate bit 2 from the Transit Information 270 Option Flags registry for the 'K' flag (Section 5.1). 272 8. Security Considerations 274 9. References 276 9.1. Normative References 278 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 279 Requirement Levels", BCP 14, RFC 2119, 280 DOI 10.17487/RFC2119, March 1997, 281 . 283 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 284 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 285 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 286 Low-Power and Lossy Networks", RFC 6550, 287 DOI 10.17487/RFC6550, March 2012, 288 . 290 9.2. Informative References 292 [Perlman83] 293 Perlman, R., "Fault-Tolerant Broadcast of Routing 294 Information", North-Holland Computer Networks, Vol.7, 295 December 1983. 297 Author's Address 299 Rahul Arvind Jadhav (editor) 300 Huawei 301 Whitefield, 302 Bangalore, Karnataka 560037 303 India 305 Email: rahul.ietf@gmail.com