idnits 2.17.1 draft-ietf-roll-capabilities-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 : ---------------------------------------------------------------------------- ** There are 22 instances of too long lines in the document, the longest one being 25 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 Merric: 16 bit unsigned integer represetning the 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 (February 10, 2020) is 1537 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 188, 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 (-34) exists of draft-ietf-roll-dao-projection-09 Summary: 2 errors (**), 0 flaws (~~), 5 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: August 13, 2020 Cisco 6 M. Richardson 7 Sandelman Software Works 8 R. Sahoo, Ed. 9 February 10, 2020 11 RPL Capabilities 12 draft-ietf-roll-capabilities-00 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 August 13, 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. Capability Catagories . . . . . . . . . . . . . . . . . . 5 61 3.2. Capability Control Message Option . . . . . . . . . . . . 5 62 3.3. Capabilities Handshake . . . . . . . . . . . . . . . . . 6 63 3.4. ROLL Capabilities . . . . . . . . . . . . . . . . . . . . 6 64 3.4.1. Projected Route Capability . . . . . . . . . . . . . 6 65 3.4.1.1. Format of Projected Route Capability . . . . . . 7 66 3.4.2. 6LoRH Capability . . . . . . . . . . . . . . . . . . 8 67 3.4.2.1. Format of 6LoRH Capability . . . . . . . . . . . 9 68 3.4.3. Routing Resource Capability . . . . . . . . . . . . . 9 69 3.4.3.1. Format of Routing Resource Capability . . . . . . 10 70 3.4.4. Neighbor Cache Capability . . . . . . . . . . . . . . 11 71 3.4.4.1. Format of Neighbor Cache Capability . . . . . . . 12 72 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 74 5.1. New option: Capabilities . . . . . . . . . . . . . . . . 12 75 5.2. New Registry for Capabilities Flags . . . . . . . . . . . 12 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 79 7.2. Informative References . . . . . . . . . . . . . . . . . 13 80 Appendix A. Capability Handshake Example . . . . . . . . . . . . 14 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 83 1. Introduction 85 RPL [RFC6550] specifies a proactive distance-vector based routing 86 scheme. The protocol creates a DAG-like structure which operates 87 with a given "Mode of Operation" (MOP) determining the minimal and 88 mandatory set of primitives to be supported by all the participating 89 nodes. 91 This document adds a notion of capabilities using which the nodes in 92 the network could inform its peers about its additional capabilities/ 93 features. This document highlights the differences of capabilities 94 from that of Mode of operation and explains the necessity of it. 96 1.1. Requirements Language and Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC 2119 [RFC2119]. 102 MOP: Mode of Operation. Identifies the mode of operation of the RPL 103 Instance as administratively provisioned at and distributed by the 104 DODAG root. 106 MOPex: Extended MOP: As defined in [I-D.jadhav-roll-mopex]. 108 Capabilities: Additional features or capabilities which might 109 possibly be optional that are supported by the node. 111 DAO: DODAG Advertisement Object. An RPL message used to advertise 112 the target information in order to establish routing adjacencies. 114 DIO: DODAG Information Object. An RPL message initiated by the root 115 and is used to advertise the network configuration information. 117 Current parent: Parent 6LR node before switching to the new path. 119 NPDAO: No-Path DAO. A DAO message which has target with lifetime 0. 121 MOPex: MOP extension as defined in this document. 123 Upstream path/direction: Path or direction from the node to the Root 124 in a DAG. 126 Downstream path/direction: Path or direction to the node from the 127 Root in a DAG. 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 1.2. What are Capabilities? 135 Currently RPL specification does not have a mechanism whereby a node 136 can signal the set of features that are available on its end. Such a 137 mechanism could help the root to advertise its capabilities and in 138 response also determine some advanced information about the 139 capabilities of the joining nodes. This document defines 140 Capabilities which could be supported by the nodes and handshaked as 141 part of RPL signaling. Capabilities are embedded as RPL control 142 message option as defined Section 6.7 of [RFC6550] in the base 143 messages of DIO, DAO and DAO-ACK signaling. 145 2. Requirements for this document 147 Following are the requirements considered for this documents: 149 REQ1: Backwards compatibility. The new options and new fields in 150 the DIO message should be backward compatible i.e. if there 151 are nodes which support old MOPs they could still operate in 152 their own instances. 154 REQ2: Optional capabilities handshake. Capabilities are features, 155 possibly optional, which could be handshaked between the nodes 156 and the root within an RPL Instance. 158 REQ3: Capabilities handshake could be optionally added with existing 159 MOPs. Capabilities been optional in nature could be put to 160 use with existing MOPs. Capabilities and MOP-extension is 161 mutually independent i.e. a DIO can have a capabilities 162 option, MOP-extension option or both in the same message. 164 REQ4: Capabilities could be explicitly queried. 166 2.1. How are Capabilities different from MOP or DIO Configuration 167 Option? 169 The Mode of Operation (MOP) field in RPL mandates the operational 170 requirement for the nodes joining as routers. MOP and DIO 171 Configuration Option is strictly controlled by the Root node in RPL. 172 Intermediate 6LRs could not modify the values. Also, the MOP never 173 changes for the lifetime of the RPL Instance. Changes in DIO 174 Configuration Option are possible but are very rare. Capabilities, 175 on the other hand, might change more dynamically. 177 RPL DIO message also carries routing metrics and constraints as 178 specified in [RFC6551]. Metrics and constraints are used as part of 179 objective function which aids in node's rank calculation. A router 180 may use capabilities carried in DIO message as additional metrics/ 181 constraints. However, capabilities have a larger scope and may be 182 carried in other messages other than DIO and can flow in both the 183 directions (upstream and downstream). 185 3. Capabilities 187 Handling of Capabilities MUST be supported if the network uses MOPex 188 [I-D.jadhav-roll-mopex]. 190 Note that capabilities and MOPex are mutually exclusive and it is 191 possible for an implementation to support either or both of the 192 options. 194 3.1. Capability Catagories 196 Capabilities can be divided into two broad categories: 198 Global Capabilities: It will include the features and capability 199 supported across an RPL instance. These capabilities can be 200 advertised by the Root or 6LRs of the DODAG. If a Node in the LLN 201 doesn't support a paticular global capability it may have to join the 202 RPL instance as a leaf node, as indicated by that individual 203 capability option. Example of such capabilities are Compression 204 Methods Supported, Support for TE paths (P-DAO). 206 Local Capabilities: It will include the cpabilities very specific to 207 a Node in the LLN. Example of such capabilities are NBR Cache 208 information, Routing Table Information. 210 Note that some capabilities can be either global or local depending 211 upon the context they are used ex.P-DAO [TODO: This is not clear] 213 3.2. Capability Control Message Option 215 0 1 2 3 216 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 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Type = TODO | Option Length | Capabilities TLVs 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 Figure 1: Capabilities Option 223 Multiple capabilities could be sent in the same message. The length 224 field allows the message parser to skip the capability TLV parsing. 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 | CAPType |G|I|. . . . . .| CAPInfo(Opt) 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 Figure 2: Capabilities TLV 234 Every capability is identified by its type and it may have an 235 optional Capability Info. Note that a given capability may or may 236 not be diseminated with additional information depending on the scope 237 of the capability indicated by the G bit. The first Bit of the 238 CAPType indicates if the capability is mandatory or optional Value of 239 1 indicates its a mandatory capability and 0 indicates its an 240 optional capability 241 G = If set indicates a Global Capability else its a local. For a 242 capability if it's mandatory and global bit is set then node those 243 either doesn't understand the capability or doesn't have this 244 capability should not join the DODAG as a router. All the global 245 capablities MUST be diseminated across the network. 247 I = Cap Info present 249 0 1 2 3 250 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 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | CAPLen | Cap Info(format decided by individual cap spec) 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 Figure 3: Capabilities Info 257 Capability Information provides additional information for the given 258 capability. The format of this field should be defined as part the 259 individual capability specification and is beyond the scope of this 260 document. This document provides a container format for carrying the 261 capability and its context information. 263 3.3. Capabilities Handshake 265 The root node could advertise the set of capabilities it supports in 266 the DIO message. A node could take advantage of the knowledge that 267 the root supports a particular capability. Similarly a node could 268 advertise its capabilities in the DAO message using the capability 269 control message option defined in this document. Capabilities 270 advertised by non-root nodes are strictly a subset of the 271 capabilities advertised by the root. 273 In storing MOP, the DAO message from the 6LR could contain multiple 274 target options because of the DAO-Aggregation. The targets of the 275 capabilities option are indicated by one or more Target options that 276 precede the Capabilties Option. This handling is similar to the 277 Transit Information Option as supported in Section 6.7.8. of 278 [RFC6550]. 280 3.4. ROLL Capabilities 282 3.4.1. Projected Route Capability 284 [I-D.ietf-roll-dao-projection] proposes mechanisms to compute and 285 install traffic engineered paths in the RPL network. It enables an 286 RPL Root to install and maintain Projected Routes based on requested 287 path metric, within its DODAG, along with a selected set of nodes 288 that may or may not include self, for a chosen duration. Projected 289 Route Capability will be used to enable this TE path calculation. 290 PRC will be an optional global capability. Any node that does not 291 understand or support the projected route functions can still act as 292 an LR. 294 The DODAG root will use projected routes capability to advertise the 295 support of projected routes with the possible mode of operations and 296 set of path metrics it can use to calculate a projected route. DODAG 297 root will add the PRC to DIO message so that it can disseminate the 298 information in entire DODAG. Router nodes in the LLN receiving DIOs 299 with PRC MUST forward the same into their sub-DODAG without any 300 change even though they don't understand or support the projected 301 route feature.LR will use the path metric information advertised by 302 the DODAG root to learn these metrics from the network and neighbors. 303 The same information they will use to advertise in the sibling 304 information option. LR will also use these path metrics information 305 to request traffic-engineered routes optimizing a or set of specific 306 network metric(s). 308 LRs in the network will use this capability to inform the PCE if they 309 can be part of a storing or non-storing or both mode of projected 310 routes. Here the PRC will be part of the DAO message. 312 The capability will convey the below information. The PRC MUST have 313 either of the information or both depending upon the node type.If 314 originator is BR, then both the information MUST be there. 316 I: Supports projected route for both storing and non-storing 317 mode. 319 II: List of supported path metrics that supported that can be used 320 to compute projected routes 322 III: [To Decide] Can we add the PCE address information to this? 324 3.4.1.1. Format of Projected Route Capability 326 0 1 2 3 327 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 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Type=0x01 |G|I|. . . . . .| CAPLen | MOP | Resvd | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Routing Metric 1 | Routing Metric 1 | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Routing Metric n-1 | Routing Metric n | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 Figure 4: Projected Route Capability TLV 338 Type: 0x01. 340 Flags: DODAG root MUST set G bit to 1 plus LRs MUST set it to 0. I 341 bit will always be set to 1. 343 CAPLen: 8-bit unsigned integer, representing the length in octets of 344 the option, not including the Option Type and Length fields. 346 MOP: 3-bit field indicating the mode of operation of projected route 347 capability. 349 Resvd: 5-bit unused fields.They MUST be initialized to zero by the 350 sender and MUST be ignored by the receiver. 352 Routing Merric: 16 bit unsigned integer represetning the the routing 353 metric to be used for TE path calculation. There can be n number of 354 such routing metric fields. These fileds are alowed with the PRC 355 sent by the DODAG ROOT. LRs MUST not send routing metric information 356 with PRC. 358 0 1 359 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Type=0x01 | Resvd | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 Figure 5: Routing Metric Information 366 3.4.2. 6LoRH Capability 368 [RFC8138] introduces a new 6LoWPAN Routing Header (6LoRH) to carry 369 IPv6 routing information. The 6LoRH may contain source routing 370 information such as a compressed form of SRH, and other sorts of 371 routing information such as the RPI and IP-in-IP encapsulation 373 The transition to [RFC8138] in a network can only be done when all 374 nodes support the specification. In a mixed case with both 375 RFC8138-capable and non-capable nodes it would not be posssible to 376 take advantage of 6LoRH.[I-D.thubert-roll-turnon-rfc8138] defines a 377 mechanism to control the use of 6LoRH in a DODAG by using "T" flag 378 bit in RPL configuration option. To assist DODAG root to decide if 379 it has to set "T" flag bit in RPL Configuration Option to enable 380 6LoRH within its DODAG, all LRs in DODAG MUST inform their support of 381 [RFC8138] by adding 6LoRH capability TLV to their advertised 382 capability control message option. 384 DODAG root MUST use 6LoRH capability TLV to inform all the nodes in 385 the DODAG, that DODAG is [RFC8138] compliance. 6LoRH is an optional 386 local capability. 388 Any LR joining the DODAG MUST add 6LoRH capability TLV to the 389 capability control message option in its DAO message to inform BR 390 that it supports RFC8138.If received DAO message doesn't have 6LoRH 391 capability TLV, DODAG Root MUST conclude the target node doesn't 392 support RFC 8138.So if DODAG is still not using 6LoRH, it MUST 393 refrain from using the compression and if it is already using it, it 394 MUST deny the LR from joining the DODAG with proper error code. 395 [TODO- Need to add new Error code]. 397 6LoRH capability is an optional capability any node that doesn't 398 understand or support the 6LoRH can join the DODAG if the "T" flag in 399 the RPL Configuration option is not set otherwise it MUST join the 400 network as a leaf node. 402 3.4.2.1. Format of 6LoRH Capability 404 0 1 2 3 405 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 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Type=0x02 |G|I|. . . . . .| Reserved | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 Figure 6: 6LoRH Capability TLV 412 Type: 0x02. 414 Flags: LRs MUST set it to 0. I bit will always be set to 0. 416 Reserved: 16-bit unsigned integer, they MUST be initialized to zero 417 by the sender and MUST be ignored by the receiver.. 419 3.4.3. Routing Resource Capability 421 Storing mode of operation requires each intermediate router in the 422 LLN to maintain routing states' information in the routing table. 423 LLN routers typically operate with constraints on processing power, 424 memory, and energy (battery power). Memory limits the number of 425 routing states an LR and BR can maintain. When the routing table of 426 an LR or BR is full, it will either reject the new DAO messages 427 received or will use some replacement policy to remove a routing 428 entry and add the new one. Rejection of DAO messages will lead to an 429 increase in DAO message transmission that impacts the energy and 430 network convergence time. Routing state replacement leads to 431 downward path downtime. 433 One possible way to solve problems due to routing table size 434 constraint is to use this information to add neighbors to the DAO 435 parent set.Routing resource capability can be used by LR and BR to 436 advertise their current routing table usage details in the network. 437 LR or LNs in LLN can use this information in the selection of the DAO 438 parent set. PCE can use this information to select intermediate 439 routers for the projected routes. Routing Resource is an optional 440 local capability. 442 Routing reource capability TLV can occur multiple times in the 443 capability control message option to advertise below possible routing 444 table information. 446 I: Master Routing Table Storing 448 II: Storing mode P-DAO Table 450 III: Non-Storing mode P-DAO 452 Routing resource capabablity sent in DIO message has link local scope 453 and it MUST not be forwarded. 455 3.4.3.1. Format of Routing Resource Capability 457 0 1 2 3 458 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 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Type=0x03 |G|I|. . . . . .| CAPLen | RT | Resvd | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Total Capacity | Used Per | Threshold | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 Figure 7: Routing Resource Capability TLV 467 Type: 0x03. 469 Flags: G bit MUST be set to 0. I bit will always be set to 1. 471 CAPLen: 8-bit unsigned integer, representing the length in octets of 472 the option, not including the Option Type and Length fields. 474 RT: 3-bit field indicating the routing resource type. This document 475 defines 3 routing resource type. 477 I: Master Routing Table Storing(RT = 1) 479 II: Storing mode P-DAO Table(RT = 2) 480 III: Non-Storing mode P-DAO(RT = 3) 482 Resvd: 5-bit unused field. It MUST be initialized to zero by the 483 sender and MUST be ignored by the receiver. 485 Total Capacity: 16 bit unsigned integer representing the the routing 486 table size. 488 Percentage used: 8 bit unsigned integer representing the the 489 percentage of routing table space currently in use. 491 Threshold: 8 bit unsigned integer representing the maximum routing 492 table space that can be used. If the routing resource type is RT1 493 and used Percentage is greater than or equal to a threshold, its 494 siblings MUST stop using it as the preferred parent or remove it from 495 the parent list. If the routing resource type is RT2 or RT3 and used 496 Percentage is greater than or equal to a threshold, PCE MUST 497 recompute some projected routes by excluding this node. 499 3.4.4. Neighbor Cache Capability 501 A neighbor cache maintains neighboring one-hop connected nodes 502 information such as MAC address, link-local IP address and other 503 reachability state information needed for layer two 504 communication.Node density has direct implications on the neighbor 505 cache. In the constrained network scenario the size of the neighbor 506 cache will be limited. Thus there are chances that a node may not be 507 able to store all the neighboring nodes in its cache and use 508 replacement algorithms to evict some of the entries to accommodate 509 the new one. If the replaced neighbor has installed a DAO route on 510 it then it can lead to packet loss or additional address resolution 511 message exchange. To avoid unnecessary replacement of neighbor cache 512 entries neighbor cache management policy 513 [I-D.ietf-lwig-nbr-mgmt-policy] proposes a solution that will put a 514 restriction on the connectivity to immediate neighbor depending upon 515 the type of neighbor. But this won't solve the problem unless until 516 the availability of neighbor cache is not taken into consideration 517 while selecting the DAO parent set. 519 Neighbor Cache capability can be used by LR and BR to advertise their 520 neighbor cache size information. This capablity information has only 521 link scope and should not be advertised in the entire network. 522 [TODO-- As neighbor cache entries category is not yet standardized i 523 think we can't use it in capability. With categories format of the 524 TLV is going to chnage.] 526 3.4.4.1. Format of Neighbor Cache Capability 528 4. Acknowledgements 530 Thanks to Georgios Papadopoulos, Li Zhao for the review and feedback. 532 5. IANA Considerations 534 5.1. New option: Capabilities 536 New entry is required for supporting new Capabilities option in the 537 "RPL Control Message Options" space [RFC6550]. 539 +-------+--------------+---------------+ 540 | Value | Meaning | Reference | 541 +-------+--------------+---------------+ 542 | TBD1 | Capabilities | This document | 543 +-------+--------------+---------------+ 545 New options 547 5.2. New Registry for Capabilities Flags 549 IANA is requested to create a registry for the Capabilities flags as 550 described in Section 2.1 of this document. This registry should be 551 located in TODO. New Capabilities flags may be allocated only by an 552 IETF review. Currently no flags are defined by this document. Each 553 value is tracked with the following qualities: 555 o Flag 557 o Description 559 o Defining RFC 561 6. Security Considerations 563 The options defined in this document are carried in the base message 564 objects as defined in [RFC6550]. The RPL control message options are 565 protected by the same security mechanisms that protect the base 566 messages. 568 Capabilities flag can reveal that the node has been upgraded or is 569 running a old feature set. This document assumes that the base 570 messages that carry these options are protected by RPL security 571 mechanisms and thus are not visible to a malicious node. 573 7. References 575 7.1. Normative References 577 [I-D.ietf-lwig-nbr-mgmt-policy] 578 Jadhav, R., Sahoo, R., Duquennoy, S., and J. Eriksson, 579 "Neighbor Management Policy for 6LoWPAN", draft-ietf-lwig- 580 nbr-mgmt-policy-03 (work in progress), February 2019. 582 [I-D.ietf-roll-dao-projection] 583 Thubert, P., Jadhav, R., and M. Gillmore, "Root initiated 584 routing state in RPL", draft-ietf-roll-dao-projection-09 585 (work in progress), November 2019. 587 [I-D.thubert-roll-turnon-rfc8138] 588 Thubert, P. and L. Zhao, "Configuration option for RFC 589 8138", draft-thubert-roll-turnon-rfc8138-03 (work in 590 progress), July 2019. 592 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 593 Requirement Levels", BCP 14, RFC 2119, 594 DOI 10.17487/RFC2119, March 1997, 595 . 597 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 598 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 599 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 600 Low-Power and Lossy Networks", RFC 6550, 601 DOI 10.17487/RFC6550, March 2012, 602 . 604 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 605 "IPv6 over Low-Power Wireless Personal Area Network 606 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 607 April 2017, . 609 7.2. Informative References 611 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 612 and D. Barthel, "Routing Metrics Used for Path Calculation 613 in Low-Power and Lossy Networks", RFC 6551, 614 DOI 10.17487/RFC6551, March 2012, 615 . 617 Appendix A. Capability Handshake Example 619 Root 6LR 6LN 620 | | | 621 | DIO(CS1) | | 622 |------------>| DIO(CS1) | 623 | |----------->| 624 | | | 625 | | DAO(CS2) | 626 | |<-----------| 627 | DAO(CS2) | | 628 |<------------| | 629 | | | 630 CS: Capabilities Set 631 CS1: Capabilities set advertised by root 632 CS2: Capabilities set advertised by node. CS2 is a subset of CS1. 634 Figure 8: Capabilities Option 636 Authors' Addresses 638 Rahul Arvind Jadhav (editor) 639 Huawei Tech 640 Kundalahalli Village, Whitefield, 641 Bangalore, Karnataka 560037 642 India 644 Phone: +91-080-49160700 645 Email: rahul.ietf@gmail.com 647 Pascal Thubert 648 Cisco Systems, Inc 649 Building D 650 45 Allee des Ormes - BP1200 651 MOUGINS - Sophia Antipolis 06254 652 France 654 Phone: +33 497 23 26 34 655 Email: pthubert@cisco.com 657 Michael Richardson 658 Sandelman Software Works 660 Email: mcr+ietf@sandelman.ca 661 Rabi Narayan Sahoo (editor) 663 Email: rabinarayans0828@gmail.com