idnits 2.17.00 (12 Aug 2021) /tmp/idnits21557/draft-ietf-roll-capabilities-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 13 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Routing Metric: 16 bit unsigned integer represetning the routing metric to be used for TE path calculation. There can be n number of such routing metric fields. These fileds are alowed with the PRC sent by the DODAG ROOT. LRs MUST not send routing metric information with PRC. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Routing resource capabablity sent in DIO message has link local scope and it MUST not be forwarded. -- The document date (March 9, 2020) is 803 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) == Missing Reference: 'I-D.jadhav-roll-mopex' is mentioned on line 191, but not defined == Missing Reference: 'TODO' is mentioned on line 611, but not defined ** Downref: Normative reference to an Informational draft: draft-ietf-lwig-nbr-mgmt-policy (ref. 'I-D.ietf-lwig-nbr-mgmt-policy') == Outdated reference: A later version (-25) exists of draft-ietf-roll-dao-projection-09 Summary: 2 errors (**), 0 flaws (~~), 6 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 Tech 4 Intended status: Standards Track P. Thubert 5 Expires: September 10, 2020 Cisco 6 M. Richardson 7 Sandelman Software Works 8 R. Sahoo, Ed. 9 March 9, 2020 11 RPL Capabilities 12 draft-ietf-roll-capabilities-01 14 Abstract 16 This draft enables the discovery, advertisement and query of 17 capabilities for RPL nodes. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 10, 2020. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Requirements Language and Terminology . . . . . . . . . . 3 55 1.2. What are Capabilities? . . . . . . . . . . . . . . . . . 3 56 2. Requirements for this document . . . . . . . . . . . . . . . 4 57 2.1. How are Capabilities different from MOP or DIO 58 Configuration Option? . . . . . . . . . . . . . . . . . . 4 59 3. Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.1. Capability Catagories . . . . . . . . . . . . . . . . . . 5 61 3.2. Capability Control Message Option . . . . . . . . . . . . 5 62 3.3. Capabilities Handshake . . . . . . . . . . . . . . . . . 6 63 4. Guidelines for defining new capabilities . . . . . . . . . . 7 64 4.1. Handling Capability flags . . . . . . . . . . . . . . . . 7 65 4.1.1. Rules to handle capabilities flag . . . . . . . . . . 7 66 5. ROLL Capabilities . . . . . . . . . . . . . . . . . . . . . . 7 67 5.1. Projected Route Capability (PRC) . . . . . . . . . . . . 8 68 5.1.1. Format of Projected Route Capability . . . . . . . . 8 69 5.2. 6LoRH Capability . . . . . . . . . . . . . . . . . . . . 9 70 5.2.1. Format of 6LoRH Capability . . . . . . . . . . . . . 10 71 5.3. Routing Resource Capability . . . . . . . . . . . . . . . 11 72 5.3.1. Format of Routing Resource Capability . . . . . . . . 11 73 5.4. Neighbor Cache Capability . . . . . . . . . . . . . . . . 12 74 5.4.1. Format of Neighbor Cache Capability . . . . . . . . . 13 75 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 77 7.1. New option: Capabilities . . . . . . . . . . . . . . . . 13 78 7.2. New Registry for Capabilities Flags . . . . . . . . . . . 13 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 82 9.2. Informative References . . . . . . . . . . . . . . . . . 15 83 Appendix A. Capability Handshake Example . . . . . . . . . . . . 15 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 86 1. Introduction 88 RPL [RFC6550] specifies a proactive distance-vector based routing 89 scheme. The protocol creates a DAG-like structure which operates 90 with a given "Mode of Operation" (MOP) determining the minimal and 91 mandatory set of primitives to be supported by all the participating 92 nodes. 94 This document adds a notion of capabilities using which the nodes in 95 the network could inform its peers about its additional capabilities/ 96 features. This document highlights the differences of capabilities 97 from that of Mode of operation and explains the necessity of it. 99 1.1. Requirements Language and Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC 2119 [RFC2119]. 105 MOP: Mode of Operation. Identifies the mode of operation of the RPL 106 Instance as administratively provisioned at and distributed by the 107 DODAG root. 109 MOPex: Extended MOP: As defined in [I-D.jadhav-roll-mopex]. 111 Capabilities: Additional features or capabilities which might 112 possibly be optional that are supported by the node. 114 DAO: DODAG Advertisement Object. An RPL message used to advertise 115 the target information in order to establish routing adjacencies. 117 DIO: DODAG Information Object. An RPL message initiated by the root 118 and is used to advertise the network configuration information. 120 Current parent: Parent 6LR node before switching to the new path. 122 NPDAO: No-Path DAO. A DAO message which has target with lifetime 0. 124 MOPex: MOP extension as defined in this document. 126 Upstream path/direction: Path or direction from the node to the Root 127 in a DAG. 129 Downstream path/direction: Path or direction to the node from the 130 Root in a DAG. 132 This document uses terminology described in [RFC6550]. For the sake 133 of readability all the known relevant terms are repeated in this 134 section. 136 1.2. What are Capabilities? 138 Currently RPL specification does not have a mechanism whereby a node 139 can signal the set of features that are available on its end. Such a 140 mechanism could help the root to advertise its capabilities and in 141 response also determine some advanced information about the 142 capabilities of the joining nodes. This document defines 143 Capabilities which could be supported by the nodes and handshaked as 144 part of RPL signaling. Capabilities are embedded as RPL control 145 message option as defined Section 6.7 of [RFC6550] in the base 146 messages of DIO, DAO and DAO-ACK signaling. 148 2. Requirements for this document 150 Following are the requirements considered for this documents: 152 REQ1: Backwards compatibility. The new options and new fields in 153 the DIO message should be backward compatible i.e. if there 154 are nodes which support old MOPs they could still operate in 155 their own instances. 157 REQ2: Optional capabilities handshake. Capabilities are features, 158 possibly optional, which could be handshaked between the nodes 159 and the root within an RPL Instance. 161 REQ3: Capabilities handshake could be optionally added with existing 162 MOPs. Capabilities been optional in nature could be put to 163 use with existing MOPs. Capabilities and MOP-extension is 164 mutually independent i.e. a DIO can have a capabilities 165 option, MOP-extension option or both in the same message. 167 REQ4: Capabilities could be explicitly queried. 169 2.1. How are Capabilities different from MOP or DIO Configuration 170 Option? 172 The Mode of Operation (MOP) field in RPL mandates the operational 173 requirement for the nodes joining as routers. MOP and DIO 174 Configuration Option is strictly controlled by the Root node in RPL. 175 Intermediate 6LRs could not modify the values. Also, the MOP never 176 changes for the lifetime of the RPL Instance. Changes in DIO 177 Configuration Option are possible but are very rare. Capabilities, 178 on the other hand, might change more dynamically. 180 RPL DIO message also carries routing metrics and constraints as 181 specified in [RFC6551]. Metrics and constraints are used as part of 182 objective function which aids in node's rank calculation. A router 183 may use capabilities carried in DIO message as additional metrics/ 184 constraints. However, capabilities have a larger scope and may be 185 carried in other messages other than DIO and can flow in both the 186 directions (upstream and downstream). 188 3. Capabilities 190 Handling of Capabilities MUST be supported if the network uses MOPex 191 [I-D.jadhav-roll-mopex]. 193 Note that capabilities and MOPex are mutually exclusive and it is 194 possible for an implementation to support either or both of the 195 options. 197 3.1. Capability Catagories 199 Capabilities can be divided into two broad categories: 201 Global Capabilities: It will include the features and capability 202 supported across an RPL instance. These capabilities can be 203 advertised by the Root or 6LRs of the DODAG. If a Node in the LLN 204 doesn't support a paticular global capability it may have to join the 205 RPL instance as a leaf node, as indicated by that individual 206 capability option. Example of such capabilities are Compression 207 Methods Supported, Support for TE paths (P-DAO). 209 Local Capabilities: It will include the cpabilities very specific to 210 a Node in the LLN. Example of such capabilities are NBR Cache 211 information, Routing Table Information. 213 Note that some capabilities can be either global or local depending 214 upon the context they are used ex.P-DAO [TODO: This is not clear] 216 3.2. Capability Control Message Option 218 0 1 2 3 219 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 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Type = TODO | Option Length | Capabilities TLVs 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 Figure 1: Capabilities Option 226 Multiple capabilities could be sent in the same message. The length 227 field allows the message parser to skip the capability TLV parsing. 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | CAPType |J|I|G|.|.|.|.|.| CAPInfo(Opt) 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 Figure 2: Capabilities TLV 237 Every capability is identified by its type and it may have an 238 optional Capability Info. Note that a given capability may or may 239 not be diseminated with additional information depending on the scope 240 of the capability indicated by the I bit. 242 J = Join only as leaf if capability not understood 244 I = Capability Info present 246 G = If set indicates a Global Capability else its a local. For a 247 capability if it's mandatory and global bit is set then node those 248 either doesn't understand the capability or doesn't have this 249 capability should not join the DODAG as a router. All the global 250 capablities MUST be diseminated across the network. 6LRs in the 251 network MUST copy the global capabilities in their DIOs. 253 0 1 2 3 254 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 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | CAPLen | Cap Info(format decided by individual cap spec) 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 Figure 3: Capabilities Info 261 Capability Information provides additional information for the given 262 capability. The format of this field should be defined as part the 263 individual capability specification and is beyond the scope of this 264 document. This document provides a container format for carrying the 265 capability and its context information. 267 3.3. Capabilities Handshake 269 The root node could advertise the set of capabilities it supports in 270 the DIO message. A node could take advantage of the knowledge that 271 the root supports a particular capability. Similarly a node could 272 advertise its capabilities in the DAO message using the capability 273 control message option defined in this document. Capabilities 274 advertised by non-root nodes are strictly a subset of the 275 capabilities advertised by the root. 277 In storing MOP, the DAO message from the 6LR could contain multiple 278 target options because of the DAO-Aggregation. The targets of the 279 capabilities option are indicated by one or more Target options that 280 precede the Capabilties Option. This handling is similar to the 281 Transit Information Option as supported in Section 6.7.8. of 282 [RFC6550]. 284 4. Guidelines for defining new capabilities 286 This section provides guidelines/recommendations towards defining new 287 capabilities. Note that the capabilities might be carried as part of 288 the multicast messaging such as DIO and hence the set should be used 289 in restrictive manner as far as possible. 291 4.1. Handling Capability flags 293 The 'G' (global) flag indicating global capability should be set only 294 by the root. However, it is not mandatory for the root to set this 295 flag for all capabilities it indicates. It should set this flag only 296 for those capabilities which the 6LRs downstream must propagate 297 further downstream. 299 The 'I' (information) flag is set only when there is additional 300 information to be set in context to the capability. 302 The 'J' (join) flag can be set in context to a capability either by a 303 6LR or the root. The 'J' flag indicates that if the capability is 304 not supported by a node then it can join the instance only as a 6LN 305 (or do not join as 6LR). 307 The 'C' (copy) flag is set by the node indicating that the 308 capabilities MUST be copied downstream by the node. 310 4.1.1. Rules to handle capabilities flag 311 On receiving a capability it does not support, the node MUST check 312 the 'J' flag of the capability before joining the Instance. If the 313 'J' flag is set then it can only join as a 6LN. 314 If the node is operating as 6LR and subsequently it receives a 315 capability which it doesn't understand with 'J' flag set, then the 316 node has to switch itself to 6LN mode. During switching the node 317 needs to inform its downstream peers of its changed status by sending 318 a DIO with infinite rank as mentioned in [RFC6550]. 320 5. ROLL Capabilities 321 5.1. Projected Route Capability (PRC) 323 [I-D.ietf-roll-dao-projection] proposes mechanisms to compute and 324 install traffic engineered paths in the RPL network. It enables an 325 RPL Root to install and maintain Projected Routes based on requested 326 path metric, within its DODAG, along with a selected set of nodes 327 that may or may not include self, for a chosen duration. Projected 328 Route Capability will be used to enable this TE path calculation. 329 PRC will be an optional global capability. Any node that does not 330 understand or support the projected route functions can still act as 331 an LR. 333 The DODAG root will use projected routes capability to advertise the 334 support of projected routes with the possible mode of operations and 335 set of path metrics it can use to calculate a projected route. DODAG 336 root will add the PRC to DIO message so that it can disseminate the 337 information in entire DODAG. Router nodes in the LLN receiving DIOs 338 with PRC MUST forward the same into their sub-DODAG without any 339 change even though they don't understand or support the projected 340 route feature.LR will use the path metric information advertised by 341 the DODAG root to learn these metrics from the network and neighbors. 342 The same information they will use to advertise in the sibling 343 information option. LR will also use these path metrics information 344 to request traffic-engineered routes optimizing a or set of specific 345 network metric(s). 347 LRs in the network will use this capability to inform the PCE if they 348 can be part of a storing or non-storing or both mode of projected 349 routes. Here the PRC will be part of the DAO message. 351 The capability will convey the below information. The PRC MUST have 352 either of the information or both depending upon the node type.If 353 originator is BR, then both the information MUST be there. 355 I: Supports projected route for both storing and non-storing 356 mode. 358 II: List of supported path metrics that can be used to compute 359 projected routes. 361 III: [To Decide] Can we add the PCE address information to this? 363 5.1.1. Format of Projected Route Capability 364 0 1 2 3 365 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 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Type=0x01 |J|I|G|. . . . .| CAPLen | MOP | Resvd | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Routing Metric 1 | Routing Metric 1 | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Routing Metric n-1 | Routing Metric n | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 Figure 4: Projected Route Capability TLV 376 Type: 0x01. 378 Flags: DODAG root MUST set G bit to 1 plus LRs MUST set it to 0. I 379 bit will always be set to 1. 381 CAPLen: 8-bit unsigned integer, representing the length in octets of 382 the option, not including the Option Type and Length fields. 384 MOP: 3-bit field indicating the mode of operation of projected route 385 capability. 387 Resvd: 5-bit unused fields.They MUST be initialized to zero by the 388 sender and MUST be ignored by the receiver. 390 Routing Metric: 16 bit unsigned integer represetning the routing 391 metric to be used for TE path calculation. There can be n number of 392 such routing metric fields. These fileds are alowed with the PRC 393 sent by the DODAG ROOT. LRs MUST not send routing metric information 394 with PRC. 396 0 1 397 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Type=0x01 | Resvd | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 Figure 5: Routing Metric Information 404 5.2. 6LoRH Capability 406 [RFC8138] introduces a new 6LoWPAN Routing Header (6LoRH) to carry 407 IPv6 routing information. The 6LoRH may contain source routing 408 information such as a compressed form of SRH, and other sorts of 409 routing information such as the RPI and IP-in-IP encapsulation 410 The transition to [RFC8138] in a network can only be done when all 411 nodes support the specification. In a mixed case with both 412 RFC8138-capable and non-capable nodes it would not be posssible to 413 take advantage of 6LoRH.[I-D.thubert-roll-turnon-rfc8138] defines a 414 mechanism to control the use of 6LoRH in a DODAG by using "T" flag 415 bit in RPL configuration option. To assist DODAG root to decide if 416 it has to set "T" flag bit in RPL Configuration Option to enable 417 6LoRH within its DODAG, all LRs in DODAG MUST inform their support of 418 [RFC8138] by adding 6LoRH capability TLV to their advertised 419 capability control message option. 421 DODAG root MUST use 6LoRH capability TLV to inform all the nodes in 422 the DODAG, that DODAG is [RFC8138] compliance. 6LoRH is an optional 423 local capability. 425 Any LR joining the DODAG MUST add 6LoRH capability TLV to the 426 capability control message option in its DAO message to inform BR 427 that it supports RFC8138.If received DAO message doesn't have 6LoRH 428 capability TLV, DODAG Root MUST conclude the target node doesn't 429 support RFC 8138.So if DODAG is still not using 6LoRH, it MUST 430 refrain from using the compression and if it is already using it, it 431 MUST deny the LR from joining the DODAG with proper error code. 432 [TODO- Need to add new Error code]. 434 6LoRH capability is an optional capability any node that doesn't 435 understand or support the 6LoRH can join the DODAG if the "T" flag in 436 the RPL Configuration option is not set otherwise it MUST join the 437 network as a leaf node. 439 5.2.1. Format of 6LoRH Capability 441 0 1 2 3 442 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 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Type=0x02 |J|I|G|. . . . .| Reserved | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 Figure 6: 6LoRH Capability TLV 449 Type: 0x02. 451 Flags: LRs MUST set it to 0. I bit will always be set to 0. 453 Reserved: 16-bit unsigned integer, they MUST be initialized to zero 454 by the sender and MUST be ignored by the receiver.. 456 5.3. Routing Resource Capability 458 Storing mode of operation requires each intermediate router in the 459 LLN to maintain routing states' information in the routing table. 460 LLN routers typically operate with constraints on processing power, 461 memory, and energy (battery power). Memory limits the number of 462 routing states an LR and BR can maintain. When the routing table of 463 an LR or BR is full, it will either reject the new DAO messages 464 received or will use some replacement policy to remove a routing 465 entry and add the new one. Rejection of DAO messages will lead to an 466 increase in DAO message transmission that impacts the energy and 467 network convergence time. Routing state replacement leads to 468 downward path downtime. 470 One possible way to solve problems due to routing table size 471 constraint is to use this information to add neighbors to the DAO 472 parent set.Routing resource capability can be used by LR and BR to 473 advertise their current routing table usage details in the network. 474 LR or LNs in LLN can use this information in the selection of the DAO 475 parent set. PCE can use this information to select intermediate 476 routers for the projected routes. Routing Resource is an optional 477 local capability. 479 Routing reource capability TLV can occur multiple times in the 480 capability control message option to advertise below possible routing 481 table information. 483 I: Master Routing Table Storing 485 II: Storing mode P-DAO Table 487 III: Non-Storing mode P-DAO 489 Routing resource capabablity sent in DIO message has link local scope 490 and it MUST not be forwarded. 492 5.3.1. Format of Routing Resource Capability 494 0 1 2 3 495 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 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | Type=0x03 |J|I|G|. . . . .| CAPLen | RT | Resvd | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | Total Capacity | Used Per | Threshold | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 Figure 7: Routing Resource Capability TLV 504 Type: 0x03. 506 Flags: G bit MUST be set to 0. I bit will always be set to 1. 508 CAPLen: 8-bit unsigned integer, representing the length in octets of 509 the option, not including the Option Type and Length fields. 511 RT: 3-bit field indicating the routing resource type. This document 512 defines 3 routing resource type. 514 I: Master Routing Table Storing(RT = 1) 516 II: Storing mode P-DAO Table(RT = 2) 518 III: Non-Storing mode P-DAO(RT = 3) 520 Resvd: 5-bit unused field. It MUST be initialized to zero by the 521 sender and MUST be ignored by the receiver. 523 Total Capacity: 16 bit unsigned integer representing the the routing 524 table size. 526 Percentage used: 8 bit unsigned integer representing the the 527 percentage of routing table space currently in use. 529 Threshold: 8 bit unsigned integer representing the maximum routing 530 table space that can be used. If the routing resource type is RT1 531 and used Percentage is greater than or equal to a threshold, its 532 siblings MUST stop using it as the preferred parent or remove it from 533 the parent list. If the routing resource type is RT2 or RT3 and used 534 Percentage is greater than or equal to a threshold, PCE MUST 535 recompute some projected routes by excluding this node. 537 5.4. Neighbor Cache Capability 539 A neighbor cache maintains neighboring one-hop connected nodes 540 information such as MAC address, link-local IP address and other 541 reachability state information needed for layer two 542 communication.Node density has direct implications on the neighbor 543 cache. In the constrained network scenario the size of the neighbor 544 cache will be limited. Thus there are chances that a node may not be 545 able to store all the neighboring nodes in its cache and use 546 replacement algorithms to evict some of the entries to accommodate 547 the new one. If the replaced neighbor has installed a DAO route on 548 it then it can lead to packet loss or additional address resolution 549 message exchange. To avoid unnecessary replacement of neighbor cache 550 entries neighbor cache management policy 551 [I-D.ietf-lwig-nbr-mgmt-policy] proposes a solution that will put a 552 restriction on the connectivity to immediate neighbor depending upon 553 the type of neighbor. But this won't solve the problem unless until 554 the availability of neighbor cache is not taken into consideration 555 while selecting the DAO parent set. 557 Neighbor Cache capability can be used by LR and BR to advertise their 558 neighbor cache size information. This capablity information has only 559 link scope and should not be advertised in the entire network. 560 [TODO-- As neighbor cache entries category is not yet standardized i 561 think we can't use it in capability. With categories format of the 562 TLV is going to chnage.] 564 5.4.1. Format of Neighbor Cache Capability 566 6. Acknowledgements 568 Thanks to Georgios Papadopoulos, Li Zhao for the review and feedback. 570 7. IANA Considerations 572 7.1. New option: Capabilities 574 New entry is required for supporting new Capabilities option in the 575 "RPL Control Message Options" space [RFC6550]. 577 +-------+--------------+---------------+ 578 | Value | Meaning | Reference | 579 +-------+--------------+---------------+ 580 | TBD1 | Capabilities | This document | 581 +-------+--------------+---------------+ 583 New options 585 7.2. New Registry for Capabilities Flags 587 IANA is requested to create a registry for the Capabilities flags as 588 described in Section 2.1 of this document. This registry should be 589 located in TODO. New Capabilities flags may be allocated only by an 590 IETF review. Currently no flags are defined by this document. Each 591 value is tracked with the following qualities: 593 o Flag 595 o Description 597 o Defining RFC 599 8. Security Considerations 601 The options defined in this document are carried in the base message 602 objects as defined in [RFC6550]. The RPL control message options are 603 protected by the same security mechanisms that protect the base 604 messages. 606 Capabilities flag can reveal that the node has been upgraded or is 607 running a old feature set. This document assumes that the base 608 messages that carry these options are protected by RPL security 609 mechanisms and thus are not visible to a malicious node. 611 [TODO] implications of malicious attack involving setting the 612 capability flags. 614 9. References 616 9.1. Normative References 618 [I-D.ietf-lwig-nbr-mgmt-policy] 619 Jadhav, R., Sahoo, R., Duquennoy, S., and J. Eriksson, 620 "Neighbor Management Policy for 6LoWPAN", draft-ietf-lwig- 621 nbr-mgmt-policy-03 (work in progress), February 2019. 623 [I-D.ietf-roll-dao-projection] 624 Thubert, P., Jadhav, R., and M. Gillmore, "Root initiated 625 routing state in RPL", draft-ietf-roll-dao-projection-09 626 (work in progress), November 2019. 628 [I-D.thubert-roll-turnon-rfc8138] 629 Thubert, P. and L. Zhao, "Configuration option for RFC 630 8138", draft-thubert-roll-turnon-rfc8138-03 (work in 631 progress), July 2019. 633 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 634 Requirement Levels", BCP 14, RFC 2119, 635 DOI 10.17487/RFC2119, March 1997, 636 . 638 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 639 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 640 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 641 Low-Power and Lossy Networks", RFC 6550, 642 DOI 10.17487/RFC6550, March 2012, 643 . 645 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 646 "IPv6 over Low-Power Wireless Personal Area Network 647 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 648 April 2017, . 650 9.2. Informative References 652 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 653 and D. Barthel, "Routing Metrics Used for Path Calculation 654 in Low-Power and Lossy Networks", RFC 6551, 655 DOI 10.17487/RFC6551, March 2012, 656 . 658 Appendix A. Capability Handshake Example 660 Root 6LR 6LN 661 | | | 662 | DIO(CS1) | | 663 |------------>| DIO(CS1) | 664 | |----------->| 665 | | | 666 | | DAO(CS2) | 667 | |<-----------| 668 | DAO(CS2) | | 669 |<------------| | 670 | | | 671 CS: Capabilities Set 672 CS1: Capabilities set advertised by root 673 CS2: Capabilities set advertised by node. CS2 is a subset of CS1. 675 Figure 8: Capabilities Option 677 Authors' Addresses 679 Rahul Arvind Jadhav (editor) 680 Huawei Tech 681 Kundalahalli Village, Whitefield, 682 Bangalore, Karnataka 560037 683 India 685 Phone: +91-080-49160700 686 Email: rahul.ietf@gmail.com 687 Pascal Thubert 688 Cisco Systems, Inc 689 Building D 690 45 Allee des Ormes - BP1200 691 MOUGINS - Sophia Antipolis 06254 692 France 694 Phone: +33 497 23 26 34 695 Email: pthubert@cisco.com 697 Michael Richardson 698 Sandelman Software Works 700 Email: mcr+ietf@sandelman.ca 702 Rabi Narayan Sahoo (editor) 704 Email: rabinarayans0828@gmail.com