idnits 2.17.1 draft-ietf-roll-mopex-cap-01.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 (November 1, 2019) is 1639 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: May 4, 2020 Cisco 6 M. Richardson 7 Sandelman Software Works 8 November 1, 2019 10 Mode of Operation extension and Capabilities 11 draft-ietf-roll-mopex-cap-01 13 Abstract 15 RPL allows different mode of operations which allows nodes to have a 16 consensus on the basic primitives that must be supported to join the 17 network. The MOP field in RFC6550 is of 3 bits and is fast 18 depleting. This document extends the MOP field specification and 19 adds a notion of capabilities using which the nodes can further 20 advertise their support for, possibly optional, capabilities. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 4, 2020. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Requirements Language and Terminology . . . . . . . . . . 3 58 2. Requirements for this document . . . . . . . . . . . . . . . 3 59 3. Extended MOP Control Message Option . . . . . . . . . . . . . 4 60 3.1. Final MOP . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.2. Handling MOPex . . . . . . . . . . . . . . . . . . . . . 5 62 4. Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4.1. Capability Control Message Option . . . . . . . . . . . . 6 64 4.2. Capabilities Handshake . . . . . . . . . . . . . . . . . 7 65 5. Implementations Consideration . . . . . . . . . . . . . . . . 7 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 68 7.1. Mode of operation: MOPex . . . . . . . . . . . . . . . . 7 69 7.2. New options: MOPex and Capabilities . . . . . . . . . . . 8 70 7.3. New Registry for Extended-MOP-value . . . . . . . . . . . 8 71 7.4. New Registry for Capabilities Flags . . . . . . . . . . . 8 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 75 9.2. Informative References . . . . . . . . . . . . . . . . . 9 76 Appendix A. Capability Handshake Example . . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 79 1. Introduction 81 RPL [RFC6550] specifies a proactive distance-vector based routing 82 scheme. The protocol creates a DAG-like structure which operates 83 with a given "Mode of Operation" (MOP) determining the minimal and 84 mandatory set of primitives to be supported by all the participating 85 nodes. 87 MOP as per [RFC6550] is a 3-bit value carried in DIO messages and is 88 specific to the RPL Instance. The receipient of the DIO message can 89 join the specified network as a router only when it can support the 90 primitives as required by the mode of operation value. For example, 91 in case of MOP=3 (Storing MOP with multicast support) the nodes can 92 join the network as routers only when they can handle the DAO 93 advertisements from the peers and manage routing tables. The 3-bit 94 value is already exhausted and requires replenishment. This document 95 introduces a mechanism to extend mode of operation values. 97 This document further adds a notion of capabilities using which the 98 nodes in the network could inform its peers about its additional 99 capabilities/features. This document highlights the differences of 100 capabilities from that of Mode of operation and explains the 101 necessity of it. 103 1.1. Requirements Language and Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [RFC2119]. 109 MOP: Mode of Operation. Identifies the mode of operation of the RPL 110 Instance as administratively provisioned at and distributed by the 111 DODAG root. 113 MOPex: Extended MOP: This document extends the MOP values over a 114 bigger range. This extension of MOP is called MOPex. 116 Capabilities: Additional features or capabilities which might 117 possibly be optional that are supported by the node. 119 DAO: DODAG Advertisement Object. An RPL message used to advertise 120 the target information in order to establish routing adjacencies. 122 DIO: DODAG Information Object. An RPL message initiated by the root 123 and is used to advertise the network configuration information. 125 Current parent: Parent 6LR node before switching to the new path. 127 NPDAO: No-Path DAO. A DAO message which has target with lifetime 0. 129 MOPex: MOP extension as defined in this document. 131 This document uses terminology described in [RFC6550]. For the sake 132 of readability all the known relevant terms are repeated in this 133 section. 135 2. Requirements for this document 137 Following are the requirements considered for this documents: 139 REQ1: MOP extension. Current MOP of 3-bit is fast depleting. An 140 MOP extension needs to extend the possibility of adding new 141 MOPs in the future. 143 REQ2: Backwards compatibility. The new options and new fields in 144 the DIO message should be backward compatible i.e. if there 145 are nodes which support old MOPs they could still operate in 146 their own instances. 148 REQ3: Optional capabilities handshake. Capabilities are features, 149 possibly optional, which could be handshaked between the nodes 150 and the root within an RPL Instance. 152 REQ4: Capabilities handshake could be optionally added with existing 153 MOPs. Capabilities been optional in nature could be put to 154 use with existing MOPs. Capabilities and MOP-extension is 155 mutually independent i.e. a DIO can have a capabilities 156 option, MOP-extension option or both in the same message. 158 3. Extended MOP Control Message Option 160 This document reserves existing MOP value 7 to be used as an 161 extender. DIO messages with MOP value of 7 may refer to the Extended 162 MOP (MOPex) option in the DIO message. 164 0 1 2 3 165 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 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Type = TODO | Extended-MOP-value | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 Figure 1: Extended MOP Option 172 3.1. Final MOP 174 An implementation supporting this document MUST calculate the final 175 MOP value as the sum of base MOP (as supported in Section 6.3.1. of 176 [RFC6550]) plus the MOPex value. Thus if the MOPex value is 0, it 177 means the final MOP is 7 since the base MOP in this case will be set 178 to 7. 180 +----------+-------+-----------+ 181 | Base MOP | MOPex | Final MOP | 182 +----------+-------+-----------+ 183 | 0 | NA | 0 | 184 | 1 | NA | 1 | 185 | : | : | : | 186 | 6 | NA | 6 | 187 | 7 | 0 | 7 | 188 | 7 | 1 | 8 | 189 | 7 | 2 | 9 | 190 | : | : | : | 191 +----------+-------+-----------+ 193 Table 1: Final MOP calculation 195 3.2. Handling MOPex 197 If the MOPex option is absent in the DIO whose MOP is 7, then the 198 MOPex value can be assumed to be zero (thus the final MOP in this 199 case will be 7). The MOPex value should be referred only if the base 200 MOP value is 7 and if the MOPex option is present. In case the base 201 MOP is 7 and if the MOPex option is present, then the implementation 202 MUST calculate the final MOP after considering the value in MOPex. 204 Note that [RFC6550] allows the node who does not support the received 205 MOP to still join the network as a leaf node. This semantic 206 continues to be true even in case of MOPex. 208 4. Capabilities 210 Currently RPL specification does not have a mechanism whereby a node 211 can signal the set of features that are available on its end. Such a 212 mechanism could help the root to advertise its capabilities and in 213 response also determine some advanced information about the 214 capabilities of the joining nodes. The Mode of Operation field in 215 RPL mandates the operational requirement and does not allow loose 216 coupling of additional capabilities. This document defines 217 Capabilities as additional features which could be supported by the 218 nodes and handshaked as part of RPL signaling. Capabilities are 219 embedded as RPL control message option as defined Section 6.7 of 220 [RFC6550] in the base messages of DIO, DAO and DAO-ACK signaling. 222 Note that capabilities and MOPex are mutually exclusive and it is 223 possible for an implementation to support either or both of the 224 options. 226 4.1. Capability Control Message Option 228 0 1 2 3 229 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 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Type = TODO | Option Length | Capabilities TLVs 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 Figure 2: Capabilities Option 236 Multiple capabilities could be sent in the same message. The length 237 field allows the message parser to skip the capability TLV parsing. 239 0 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | CAPType |J|C|I|. . . . .| CAPInfo(Opt) 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 Figure 3: Capabilities TLV 247 Every capability is identified by its type and it may have an 248 optional Capability Info. Note that a given capability may or may 249 not be diseminated with additional information depending on the 'I' 250 flag. 252 J = Join only as leaf if capability not understood 254 C = Copy capability to children 256 I = Cap Info present 258 0 1 2 3 259 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 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | CAPLen | Cap Info(format decided by individual cap spec) 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 Figure 4: Capabilities Info 266 Capability Information provides additional information for the given 267 capability. The format of this field should be defined as part the 268 individual capability specification and is beyond the scope of this 269 document. This document provides a container format for carrying the 270 capability and its context information. 272 4.2. Capabilities Handshake 274 The root node could advertise the set of capabilities it supports in 275 the DIO message. A node could take advantage of the knowledge that 276 the root supports a particular capability. Similarly a node could 277 advertise its capabilities in the DAO message using the capability 278 control message option defined in this document. Capabilities 279 advertised by non-root nodes are strictly a subset of the 280 capabilities advertised by the root. 282 In storing MOP, the DAO message from the 6LR could contain multiple 283 target options. The targets of the capabilities option are indicated 284 by one or more Target options that precede the Capabilties Option. 285 This handling is similar to the Transit Information Option as 286 supported in Section 6.7.8. of [RFC6550]. 288 5. Implementations Consideration 290 The MOP-extension could cause 3-byte increase in memory in the RPL- 291 Instance. The MOP field in the RPL-Instance needs to be upgraded to 292 a 32 bit integer. 294 [RFC6550], it was possible to discard an unsupported DIO-MOP just by 295 inspecting the base message. With this document, the MOPex is a 296 different control message option and thus the discarding of the DIO 297 message could happen after inspecting the message options. 299 A node in storing MOP could independently construct a DAO message 300 with target options containing its child/sub-childs. Thus with 301 capabilities it needs to reconstruct the capabilities field as well. 302 This may result in increase in the memory requirement on per routing- 303 entry basis. 305 6. Acknowledgements 307 Thanks to Georgios Papadopoulos for the review and feedback. 309 7. IANA Considerations 311 7.1. Mode of operation: MOPex 313 IANA is requested to assign a new Mode of Operation, named "MOPex" 314 for MOP extension under the RPL registry. The value of 7 is to be 315 assigned from the "Mode of Operation" space [RFC6550] 316 +-------+-------------+---------------+ 317 | Value | Description | Reference | 318 +-------+-------------+---------------+ 319 | 7 | MOPex | This document | 320 +-------+-------------+---------------+ 322 Mode of Operation 324 7.2. New options: MOPex and Capabilities 326 Two new entries are required for new supporting new options "MOPex", 327 "Capabilities" from the "RPL Control Message Options" space 328 [RFC6550]. 330 +-------+--------------+---------------+ 331 | Value | Meaning | Reference | 332 +-------+--------------+---------------+ 333 | TBD1 | MOPex | This document | 334 | TBD2 | Capabilities | This document | 335 +-------+--------------+---------------+ 337 New options 339 7.3. New Registry for Extended-MOP-value 341 IANA is requested to create a registry for the extended-MOP-value 342 (MOPex). This registry should be located in TODO. New MOPex values 343 may be allocated only by an IETF review. Currently no values are 344 defined by this document. Each value is tracked with the following 345 qualities: 347 o MOPex value 349 o Description 351 o Defining RFC 353 7.4. New Registry for Capabilities Flags 355 IANA is requested to create a registry for the Capabilities flags as 356 described in Section 4 of this document. This registry should be 357 located in TODO. New Capabilities flags may be allocated only by an 358 IETF review. Currently no flags are defined by this document. Each 359 value is tracked with the following qualities: 361 o Flag 363 o Description 364 o Defining RFC 366 8. Security Considerations 368 The options defined in this document are carried in the base message 369 objects as defined in [RFC6550]. The RPL control message options are 370 protected by the same security mechanisms that protect the base 371 messages. 373 Capabilities flag can reveal that the node has been upgraded or is 374 running a old feature set. This document assumes that the base 375 messages that carry these options are protected by RPL security 376 mechanisms and thus are not visible to a malicious node. 378 9. References 380 9.1. Normative References 382 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 383 Requirement Levels", BCP 14, RFC 2119, 384 DOI 10.17487/RFC2119, March 1997, 385 . 387 9.2. Informative References 389 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 390 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 391 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 392 Low-Power and Lossy Networks", RFC 6550, 393 DOI 10.17487/RFC6550, March 2012, 394 . 396 Appendix A. Capability Handshake Example 397 Root 6LR 6LN 398 | | | 399 | DIO(CS1) | | 400 |------------>| DIO(CS1) | 401 | |----------->| 402 | | | 403 | | DAO(CS2) | 404 | |<-----------| 405 | DAO(CS2) | | 406 |<------------| | 407 | | | 408 CS: Capabilities Set 409 CS1: Capabilities set advertised by root 410 CS2: Capabilities set advertised by node. CS2 is a subset of CS1. 412 Figure 5: Capabilities Option 414 Authors' Addresses 416 Rahul Arvind Jadhav (editor) 417 Huawei Tech 418 Kundalahalli Village, Whitefield, 419 Bangalore, Karnataka 560037 420 India 422 Phone: +91-080-49160700 423 Email: rahul.ietf@gmail.com 425 Pascal Thubert 426 Cisco Systems, Inc 427 Building D 428 45 Allee des Ormes - BP1200 429 MOUGINS - Sophia Antipolis 06254 430 France 432 Phone: +33 497 23 26 34 433 Email: pthubert@cisco.com 435 Michael Richardson 436 Sandelman Software Works 438 Email: mcr+ietf@sandelman.ca