idnits 2.17.1 draft-ietf-roll-mopex-cap-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 (August 9, 2019) is 1721 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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 Tech 4 Intended status: Standards Track P. Thubert 5 Expires: February 10, 2020 Cisco 6 August 9, 2019 8 Mode of Operation extension and Capabilities 9 draft-ietf-roll-mopex-cap-00 11 Abstract 13 RPL allows different mode of operations which allows nodes to have a 14 consensus on the basic primitives that must be supported to join the 15 network. The MOP field in RFC6550 is of 3 bits and is fast 16 depleting. This document extends the MOP field specification and 17 adds a notion of capabilities using which the nodes can further 18 advertise their support for, possibly optional, capabilities. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on February 10, 2020. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language and Terminology . . . . . . . . . . 3 56 2. Requirements for this document . . . . . . . . . . . . . . . 3 57 3. Extended MOP Control Message Option . . . . . . . . . . . . . 4 58 3.1. Final MOP . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.2. Handling MOPex . . . . . . . . . . . . . . . . . . . . . 5 60 4. Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4.1. Capability Control Message Option . . . . . . . . . . . . 5 62 4.2. Capabilities Handshake . . . . . . . . . . . . . . . . . 5 63 5. Implementations Consideration . . . . . . . . . . . . . . . . 6 64 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 66 7.1. Mode of operation: MOPex . . . . . . . . . . . . . . . . 6 67 7.2. New options: MOPex and Capabilities . . . . . . . . . . . 7 68 7.3. New Registry for Extended-MOP-value . . . . . . . . . . . 7 69 7.4. New Registry for Capabilities Flags . . . . . . . . . . . 7 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 73 9.2. Informative References . . . . . . . . . . . . . . . . . 8 74 Appendix A. Capability Handshake Example . . . . . . . . . . . . 8 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 77 1. Introduction 79 RPL [RFC6550] specifies a proactive distance-vector based routing 80 scheme. The protocol creates a DAG-like structure which operates 81 with a given "Mode of Operation" (MOP) determining the minimal and 82 mandatory set of primitives to be supported by all the participating 83 nodes. 85 MOP as per [RFC6550] is a 3-bit value carried in DIO messages and is 86 specific to the RPL Instance. The receipient of the DIO message can 87 join the specified network as a router only when it can support the 88 primitives as required by the mode of operation value. For example, 89 in case of MOP=3 (Storing MOP with multicast support) the nodes can 90 join the network as routers only when they can handle the DAO 91 advertisements from the peers and manage routing tables. The 3-bit 92 value is already exhausted and requires replenishment. This document 93 introduces a mechanism to extend mode of operation values. 95 This document further adds a notion of capabilities using which the 96 nodes in the network could inform its peers about its additional 97 capabilities/features. This document highlights the differences of 98 capabilities from that of Mode of operation and explains the 99 necessity of it. 101 1.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. Identifies the mode of operation of the RPL 108 Instance as administratively provisioned at and distributed by the 109 DODAG root. 111 MOPex: Extended MOP: This document extends the MOP values over a 112 bigger range. This extension of MOP is called MOPex. 114 Capabilities: Additional features or capabilities which might 115 possibly be optional that are supported by the node. 117 DAO: DODAG Advertisement Object. An RPL message used to advertise 118 the target information in order to establish routing adjacencies. 120 DIO: DODAG Information Object. An RPL message initiated by the root 121 and is used to advertise the network configuration information. 123 Current parent: Parent 6LR node before switching to the new path. 125 NPDAO: No-Path DAO. A DAO message which has target with lifetime 0. 127 MOPex: MOP extension as defined in this document. 129 This document uses terminology described in [RFC6550]. For the sake 130 of readability all the known relevant terms are repeated in this 131 section. 133 2. Requirements for this document 135 Following are the requirements considered for this documents: 137 REQ1: MOP extension. Current MOP of 3-bit is fast depleting. An 138 MOP extension needs to extend the possibility of adding new 139 MOPs in the future. 141 REQ2: Backwards compatibility. The new options and new fields in 142 the DIO message should be backward compatible i.e. if there 143 are nodes which support old MOPs they could still operate in 144 their own instances. 146 REQ3: Optional capabilities handshake. Capabilities are features, 147 possibly optional, which could be handshaked between the nodes 148 and the root within an RPL Instance. 150 REQ4: Capabilities handshake could be optionally added with existing 151 MOPs. Capabilities been optional in nature could be put to 152 use with existing MOPs. Capabilities and MOP-extension is 153 mutually independent i.e. a DIO can have a capabilities 154 option, MOP-extension option or both in the same message. 156 3. Extended MOP Control Message Option 158 This document reserves existing MOP value 7 to be used as an 159 extender. DIO messages with MOP value of 7 may refer to the Extended 160 MOP (MOPex) option in the DIO message. 162 0 1 2 3 163 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 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Type = TODO | Extended-MOP-value | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 Figure 1: Extended MOP Option 170 3.1. Final MOP 172 An implementation supporting this document MUST calculate the final 173 MOP value as the sum of base MOP (as supported in Section 6.3.1. of 174 [RFC6550]) plus the MOPex value. Thus if the MOPex value is 0, it 175 means the final MOP is 7 since the base MOP in this case will be set 176 to 7. 178 +----------+-------+-----------+ 179 | Base MOP | MOPex | Final MOP | 180 +----------+-------+-----------+ 181 | 0 | NA | 0 | 182 | 1 | NA | 1 | 183 | : | : | : | 184 | 6 | NA | 6 | 185 | 7 | 0 | 7 | 186 | 7 | 1 | 8 | 187 | 7 | 2 | 9 | 188 | : | : | : | 189 +----------+-------+-----------+ 191 Table 1: Final MOP calculation 193 3.2. Handling MOPex 195 If the MOPex option is absent in the DIO whose MOP is 7, then the 196 MOPex value can be assumed to be zero (thus the final MOP in this 197 case will be 7). The MOPex value should be referred only if the base 198 MOP value is 7 and if the MOPex option is present. In case the base 199 MOP is 7 and if the MOPex option is present, then the implementation 200 MUST calculate the final MOP after considering the value in MOPex. 202 Note that [RFC6550] allows the node who does not support the received 203 MOP to still join the network as a leaf node. This semantic 204 continues to be true even in case of MOPex. 206 4. Capabilities 208 Currently RPL specification does not have a mechanism whereby a node 209 can signal the set of features that are available on its end. Such a 210 mechanism could help the root to advertise its capabilities and in 211 response also determine some advanced information about the 212 capabilities of the joining nodes. The Mode of Operation field in 213 RPL mandates the operational requirement and does not allow loose 214 coupling of additional capabilities. This document defines 215 Capabilities as additional features which could be supported by the 216 nodes and handshaked as part of RPL signaling. Capabilities are 217 embedded as RPL control message option as defined Section 6.7 of 218 [RFC6550] in the base messages of DIO, DAO and DAO-ACK signaling. 220 Note that capabilities and MOPex are mutually exclusive and it is 221 possible for an implementation to support either or both of the 222 options. 224 4.1. Capability Control Message Option 226 0 1 2 3 227 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 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Type = TODO | Capabilities Flags | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 Figure 2: Capabilities Option 234 There are no capability flags defined by this document. 236 4.2. Capabilities Handshake 238 The root node could advertise the set of capabilities it supports in 239 the DIO message. A node could take advantage of the knowledge that 240 the root supports a particular capability. Similarly a node could 241 advertise its capabilities in the DAO message using the capability 242 control message option defined in this document. Capabilities 243 advertised by non-root nodes are strictly a subset of the 244 capabilities advertised by the root. 246 In storing MOP, the DAO message from the 6LR could contain multiple 247 target options. The targets of the capabilities option are indicated 248 by one or more Target options that precede the Capabilties Option. 249 This handling is similar to the Transit Information Option as 250 supported in Section 6.7.8. of [RFC6550]. 252 5. Implementations Consideration 254 The MOP-extension could cause 3-byte increase in memory in the RPL- 255 Instance. The MOP field in the RPL-Instance needs to be upgraded to 256 a 32 bit integer. 258 [RFC6550], it was possible to discard an unsupported DIO-MOP just by 259 inspecting the base message. With this document, the MOPex is a 260 different control message option and thus the discarding of the DIO 261 message could happen after inspecting the message options. 263 A node in storing MOP could independently construct a DAO message 264 with target options containing its child/sub-childs. Thus with 265 capabilities it needs to reconstruct the capabilities field as well. 266 This may result in increase in the memory requirement on per routing- 267 entry basis. 269 6. Acknowledgements 271 Thanks to Georgios Papadopoulos for the review and feedback. 273 7. IANA Considerations 275 7.1. Mode of operation: MOPex 277 IANA is requested to assign a new Mode of Operation, named "MOPex" 278 for MOP extension under the RPL registry. The value of 7 is to be 279 assigned from the "Mode of Operation" space [RFC6550] 281 +-------+-------------+---------------+ 282 | Value | Description | Reference | 283 +-------+-------------+---------------+ 284 | 7 | MOPex | This document | 285 +-------+-------------+---------------+ 287 Mode of Operation 289 7.2. New options: MOPex and Capabilities 291 Two new entries are required for new supporting new options "MOPex", 292 "Capabilities" from the "RPL Control Message Options" space 293 [RFC6550]. 295 +-------+--------------+---------------+ 296 | Value | Meaning | Reference | 297 +-------+--------------+---------------+ 298 | TBD1 | MOPex | This document | 299 | TBD2 | Capabilities | This document | 300 +-------+--------------+---------------+ 302 New options 304 7.3. New Registry for Extended-MOP-value 306 IANA is requested to create a registry for the extended-MOP-value 307 (MOPex). This registry should be located in TODO. New MOPex values 308 may be allocated only by an IETF review. Currently no values are 309 defined by this document. Each value is tracked with the following 310 qualities: 312 o MOPex value 314 o Description 316 o Defining RFC 318 7.4. New Registry for Capabilities Flags 320 IANA is requested to create a registry for the Capabilities flags as 321 described in Section 4 of this document. This registry should be 322 located in TODO. New Capabilities flags may be allocated only by an 323 IETF review. Currently no flags are defined by this document. Each 324 value is tracked with the following qualities: 326 o Flag 328 o Description 330 o Defining RFC 332 8. Security Considerations 334 The options defined in this document are carried in the base message 335 objects as defined in [RFC6550]. The RPL control message options are 336 protected by the same security mechanisms that protect the base 337 messages. 339 Capabilities flag can reveal that the node has been upgraded or is 340 running a old feature set. This document assumes that the base 341 messages that carry these options are protected by RPL security 342 mechanisms and thus are not visible to a malicious node. 344 9. References 346 9.1. Normative References 348 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 349 Requirement Levels", BCP 14, RFC 2119, 350 DOI 10.17487/RFC2119, March 1997, 351 . 353 9.2. Informative References 355 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 356 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 357 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 358 Low-Power and Lossy Networks", RFC 6550, 359 DOI 10.17487/RFC6550, March 2012, 360 . 362 Appendix A. Capability Handshake Example 364 Root 6LR 6LN 365 | | | 366 | DIO(CS1) | | 367 |------------>| DIO(CS1) | 368 | |----------->| 369 | | | 370 | | DAO(CS2) | 371 | |<-----------| 372 | DAO(CS2) | | 373 |<------------| | 374 | | | 375 CS: Capabilities Set 376 CS1: Capabilities set advertised by root 377 CS2: Capabilities set advertised by node. CS2 is a subset of CS1. 379 Figure 3: Capabilities Option 381 Authors' Addresses 383 Rahul Arvind Jadhav (editor) 384 Huawei Tech 385 Kundalahalli Village, Whitefield, 386 Bangalore, Karnataka 560037 387 India 389 Phone: +91-080-49160700 390 Email: rahul.ietf@gmail.com 392 Pascal Thubert 393 Cisco Systems, Inc 394 Building D 395 45 Allee des Ormes - BP1200 396 MOUGINS - Sophia Antipolis 06254 397 France 399 Phone: +33 497 23 26 34 400 Email: pthubert@cisco.com