idnits 2.17.00 (12 Aug 2021) /tmp/idnits63447/draft-ietf-roll-aodv-rpl-12.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 document date (30 January 2022) is 111 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 (~~), 0 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL C.E. Perkins 3 Internet-Draft Lupin Lodge 4 Intended status: Standards Track S.V.R.Anand 5 Expires: 3 August 2022 Indian Institute of Science 6 S. Anamalamudi 7 SRM University-AP 8 B. Liu 9 Huawei Technologies 10 30 January 2022 12 Supporting Asymmetric Links in Low Power Networks: AODV-RPL 13 draft-ietf-roll-aodv-rpl-12 15 Abstract 17 Route discovery for symmetric and asymmetric Peer-to-Peer (P2P) 18 traffic flows is a desirable feature in Low power and Lossy Networks 19 (LLNs). For that purpose, this document specifies a reactive P2P 20 route discovery mechanism for both hop-by-hop routing and source 21 routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL 22 protocol (AODV-RPL). Paired Instances are used to construct 23 directional paths, for cases where there are asymmetric links between 24 source and target nodes. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 3 August 2022. 43 Copyright Notice 45 Copyright (c) 2022 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Revised BSD License text as 54 described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Revised BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Overview of AODV-RPL . . . . . . . . . . . . . . . . . . . . 6 62 4. AODV-RPL DIO Options . . . . . . . . . . . . . . . . . . . . 6 63 4.1. AODV-RPL RREQ Option . . . . . . . . . . . . . . . . . . 7 64 4.2. AODV-RPL RREP Option . . . . . . . . . . . . . . . . . . 8 65 4.3. AODV-RPL Target Option . . . . . . . . . . . . . . . . . 10 66 5. Symmetric and Asymmetric Routes . . . . . . . . . . . . . . . 11 67 6. AODV-RPL Operation . . . . . . . . . . . . . . . . . . . . . 13 68 6.1. Route Request Generation . . . . . . . . . . . . . . . . 13 69 6.2. Receiving and Forwarding RREQ messages . . . . . . . . . 14 70 6.2.1. Step 1: RREQ reception and evaluation . . . . . . . . 14 71 6.2.2. Step 2: TargNode and Intermediate Router 72 determination . . . . . . . . . . . . . . . . . . . . 15 73 6.2.3. Step 3: Intermediate Router RREQ processing . . . . . 16 74 6.2.4. Step 4: Symmetric Route Processing at an Intermediate 75 Router . . . . . . . . . . . . . . . . . . . . . . . 16 76 6.2.5. Step 5: RREQ propagation at an Intermediate Router . 16 77 6.2.6. Step 6: RREQ reception at TargNode . . . . . . . . . 17 78 6.3. Generating Route Reply (RREP) at TargNode . . . . . . . . 17 79 6.3.1. RREP-DIO for Symmetric route . . . . . . . . . . . . 17 80 6.3.2. RREP-DIO for Asymmetric Route . . . . . . . . . . . . 18 81 6.3.3. RPLInstanceID Pairing . . . . . . . . . . . . . . . . 18 82 6.4. Receiving and Forwarding Route Reply . . . . . . . . . . 19 83 6.4.1. Step 1: Receiving and Evaluation . . . . . . . . . . 19 84 6.4.2. Step 2: OrigNode or Intermediate Router . . . . . . . 19 85 6.4.3. Step 3: Build Route to TargNode . . . . . . . . . . . 19 86 6.4.4. Step 4: RREP Propagation . . . . . . . . . . . . . . 20 87 7. Gratuitous RREP . . . . . . . . . . . . . . . . . . . . . . . 20 88 8. Operation of Trickle Timer . . . . . . . . . . . . . . . . . 21 89 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 90 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 91 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 92 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 93 12.1. Normative References . . . . . . . . . . . . . . . . . . 23 94 12.2. Informative References . . . . . . . . . . . . . . . . . 23 96 Appendix A. Example: Using ETX/RSSI Values to determine value of S 97 bit . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 98 Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . 26 99 B.1. Changes from version 11 to version 12 . . . . . . . . . . 26 100 B.2. Changes from version 10 to version 11 . . . . . . . . . . 27 101 B.3. Changes from version 09 to version 10 . . . . . . . . . . 28 102 B.4. Changes from version 08 to version 09 . . . . . . . . . . 29 103 B.5. Changes from version 07 to version 08 . . . . . . . . . . 29 104 B.6. Changes from version 06 to version 07 . . . . . . . . . . 30 105 B.7. Changes from version 05 to version 06 . . . . . . . . . . 30 106 B.8. Changes from version 04 to version 05 . . . . . . . . . . 30 107 B.9. Changes from version 03 to version 04 . . . . . . . . . . 30 108 B.10. Changes from version 02 to version 03 . . . . . . . . . . 31 109 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 31 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 112 1. Introduction 114 Routing Protocol for Low-Power and Lossy Networks (RPL) [RFC6550] is 115 an IPv6 distance vector routing protocol designed to support multiple 116 traffic flows through a root-based Destination-Oriented Directed 117 Acyclic Graph (DODAG). Typically, a router does not have routing 118 information for most other routers. Consequently, for traffic 119 between routers within the DODAG (i.e., Peer-to-Peer (P2P) traffic) 120 data packets either have to traverse the root in non-storing mode, or 121 traverse a common ancestor in storing mode. Such P2P traffic is 122 thereby likely to traverse longer routes and may suffer severe 123 congestion near the root (for more information see [RFC6997], 124 [RFC6998]). The network environment that is considered in this 125 document is assumed to be the same as described in Section 1 of 126 [RFC6550]. 128 The route discovery process in AODV-RPL is modeled on the analogous 129 procedure specified in AODV [RFC3561]. The on-demand nature of AODV 130 route discovery is natural for the needs of peer-to-peer routing in 131 RPL-based LLNs. AODV terminology has been adapted for use with AODV- 132 RPL messages, namely RREQ for Route Request, and RREP for Route 133 Reply. AODV-RPL currently omits some features compared to AODV -- in 134 particular, flagging Route Errors, "blacklisting" unidirectional 135 links ([RFC3561]), multihoming, and handling unnumbered interfaces. 137 AODV-RPL reuses and extends the core RPL functionality to support 138 routes with bidirectional asymmetric links. It retains RPL's DODAG 139 formation, RPL Instance and the associated Objective Function 140 (defined in [RFC6551]), trickle timers, and support for storing and 141 non-storing modes. AODV-RPL adds basic messages RREQ and RREP as 142 part of RPL DODAG Information Object (DIO) control message, which go 143 in separate (paired) RPL instances. AODV-RPL does not utilize the 144 Destination Advertisement Object (DAO) control message of RPL. AODV- 145 RPL uses the "P2P Route Discovery Mode of Operation" (MOP == 4) with 146 three new Options for the DIO message, dedicated to discover P2P 147 routes. These P2P routes may differ from routes discoverable by 148 native RPL. Since AODV-RPL uses newly defined Options, there is no 149 conflict with P2P-RPL [RFC6997], a previous document using the same 150 MOP. AODV-RPL can be operated whether or not native RPL is running 151 otherwise. 153 2. Terminology 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 157 "OPTIONAL" in this document are to be interpreted as described in BCP 158 14 [RFC2119] [RFC8174] when, and only when, they appear in all 159 capitals, as shown here. 161 AODV-RPL reuses names for messages and data structures, including 162 Rank, DODAG and DODAGID, as defined in RPL [RFC6550]. 164 AODV 165 Ad Hoc On-demand Distance Vector Routing[RFC3561]. 167 Asymmetric Route 168 The route from the OrigNode to the TargNode can traverse different 169 nodes than the route from the TargNode to the OrigNode. An 170 asymmetric route may result from the asymmetry of links, such that 171 only one direction of the series of links satisfies the Objective 172 Function during route discovery. 174 Bi-directional Asymmetric Link 175 A link that can be used in both directions but with different link 176 characteristics. 178 DIO 179 DODAG Information Object 181 DODAG RREQ-Instance (or simply RREQ-Instance) 182 RPL Instance built using the DIO with RREQ option; used for 183 control message transmission from OrigNode to TargNode, thus 184 enabling data transmission from TargNode to OrigNode. 186 DODAG RREP-Instance (or simply RREP-Instance) 187 RPL Instance built using the DIO with RREP option; used for 188 control message transmission from TargNode to OrigNode thus 189 enabling data transmission from OrigNode to TargNode. 191 Downward Direction 192 The direction from the OrigNode to the TargNode. 194 Downward Route 195 A route in the downward direction. 197 hop-by-hop routing 198 Routing when each router stores routing information about the next 199 hop. 201 on-demand routing 202 Routing in which a route is established only when needed. 204 OrigNode 205 The IPv6 router (Originating Node) initiating the AODV-RPL route 206 discovery to obtain a route to TargNode. 208 Paired DODAGs 209 Two DODAGs for a single route discovery process between OrigNode 210 and TargNode. 212 P2P 213 Peer-to-Peer -- in other words, not constrained a priori to 214 traverse a common ancestor. 216 reactive routing 217 Same as "on-demand" routing. 219 RREQ-DIO message 220 A DIO message containing the RREQ option. The RPLInstanceID in 221 RREQ-DIO is assigned locally by the OrigNode. The RREQ-DIO 222 message has a secure variant as noted in [RFC6550]. 224 RREP-DIO message 225 A DIO message containing the RREP option. OrigNode pairs the 226 RPLInstanceID in RREP-DIO to the one in the associated RREQ-DIO 227 message as described in Section 6.3.2. The RREP-DIO message has a 228 secure variant as noted in [RFC6550]. 230 Source routing 231 A mechanism by which the source supplies the complete route 232 towards the target node along with each data packet [RFC6550]. 234 Symmetric route 235 The upstream and downstream routes traverse the same routers and 236 over the same links. 238 TargNode 239 The IPv6 router (Target Node) for which OrigNode requires a route 240 and initiates Route Discovery within the LLN network. 242 Upward Direction 243 The direction from the TargNode to the OrigNode. 245 Upward Route 246 A route in the upward direction. 248 ART option 249 AODV-RPL Target option: a target option defined in this document. 251 3. Overview of AODV-RPL 253 With AODV-RPL, routes from OrigNode to TargNode within the LLN 254 network are established "on-demand". In other words, the route 255 discovery mechanism in AODV-RPL is invoked reactively when OrigNode 256 has data for delivery to the TargNode but existing routes do not 257 satisfy the application's requirements. AODV-RPL works without 258 requiring the use of RPL or any other routing protocol. 260 The routes discovered by AODV-RPL are not constrained to traverse a 261 common ancestor. AODV-RPL can enable asymmetric communication paths 262 in networks with bidirectional asymmetric links. For this purpose, 263 AODV-RPL enables discovery of two routes: namely, one from OrigNode 264 to TargNode, and another from TargNode to OrigNode. AODV-RPL also 265 enables discovery of symmetric routes along Paired DODAGs, when 266 symmetric routes are possible (see Section 5). 268 In AODV-RPL, routes are discovered by first forming a temporary DAG 269 rooted at the OrigNode. Paired DODAGs (Instances) are constructed 270 during route formation between the OrigNode and TargNode. The RREQ- 271 Instance is formed by route control messages from OrigNode to 272 TargNode whereas the RREP-Instance is formed by route control 273 messages from TargNode to OrigNode. Intermediate routers join the 274 DODAGs based on the Rank [RFC6550] as calculated from the DIO 275 message. Henceforth in this document, "RREQ-DIO message" means the 276 DIO message from OrigNode to TargNode, containing the RREQ option as 277 specified in Section 4.1. Similarly, "RREP-DIO message" means the 278 DIO message from TargNode to OrigNode, containing the RREP option as 279 specified in Section 4.2. The route discovered in the RREQ-Instance 280 is used for transmitting data from TargNode to OrigNode, and the 281 route discovered in RREP-Instance is used for transmitting data from 282 OrigNode to TargNode. 284 4. AODV-RPL DIO Options 285 4.1. AODV-RPL RREQ Option 287 OrigNode selects one of its IPv6 addresses and sets it in the DODAGID 288 field of the RREQ-DIO message. Exactly one RREQ option MUST be 289 present in a RREQ-DIO message, otherwise the message MUST be dropped. 291 0 1 2 3 292 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 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Option Type | Option Length |S|H|X| Compr | L | MaxRank | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Orig SeqNo | | 297 +-+-+-+-+-+-+-+-+ | 298 | | 299 | | 300 | Address Vector (Optional, Variable Length) | 301 | | 302 | | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 Figure 1: Format for AODV-RPL RREQ Option 307 OrigNode supplies the following information in the RREQ option: 309 Option Type 310 TBD2 312 Option Length 313 The length of the option in octets, excluding the Type and Length 314 fields. Variable due to the presence of the address vector and 315 the number of octets elided according to the Compr value. 317 S 318 Symmetric bit indicating a symmetric route from the OrigNode to 319 the router transmitting this RREQ-DIO. See Section 5. 321 H 322 Set to one for a hop-by-hop route. Set to zero for a source 323 route. This flag controls both the downstream route and upstream 324 route. 326 X 327 Reserved; MUST be initialized to zero and ignored upon reception. 329 Compr 330 4-bit unsigned integer. When Compr is nonzero, exactly that 331 number of prefix octets MUST be elided from each address before 332 storing it in the Address Vector. The octets elided are shared 333 with the IPv6 address in the DODAGID. This field is only used in 334 source routing mode (H=0). In hop-by-hop mode (H=1), this field 335 MUST be set to zero and ignored upon reception. 337 L 338 2-bit unsigned integer determining the length of time that a node 339 is able to belong to the RREQ-Instance (a temporary DAG including 340 the OrigNode and the TargNode). Once the time is reached, a node 341 MUST leave the RREQ-Instance and stop sending or receiving any 342 more DIOs for the RREQ-Instance. This naturally depends on the 343 node's ability to keep track of the time. L is independent from 344 the route lifetime, which is defined in the DODAG configuration 345 option. 347 * 0x00: No time limit imposed. 348 * 0x01: 16 seconds 349 * 0x02: 64 seconds 350 * 0x03: 256 seconds 352 MaxRank 353 This field indicates the upper limit on the integer portion of the 354 Rank (calculated using the DAGRank() macro defined in [RFC6550]). 355 A value of 0 in this field indicates the limit is infinity. 357 Orig SeqNo 358 Sequence Number of OrigNode. See Section 6.1. 360 Address Vector 361 A vector of IPv6 addresses representing the route that the RREQ- 362 DIO has passed. It is only present when the H bit is set to 0. 363 The prefix of each address is elided according to the Compr field. 365 TargNode can join the RREQ instance at a Rank whose integer portion 366 is less than or equal to the MaxRank. Other nodes MUST NOT join a 367 RREQ instance if its own Rank would be equal to or higher than 368 MaxRank. A router MUST discard a received RREQ if the integer part 369 of the advertised Rank equals or exceeds the MaxRank limit. 371 4.2. AODV-RPL RREP Option 373 TargNode sets one of its IPv6 addresses in the DODAGID field of the 374 RREP-DIO message. Exactly one RREP option MUST be present in a RREP- 375 DIO message, otherwise the message MUST be dropped. TargNode 376 supplies the following information in the RREP option: 378 0 1 2 3 379 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 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Option Type | Option Length |G|H|X| Compr | L | MaxRank | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Shift |X X| | 384 +-+-+-+-+-+-+-+-+ | 385 | | 386 | | 387 | Address Vector (Optional, Variable Length) | 388 . . 389 . . 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 Figure 2: Format for AODV-RPL RREP option 394 Option Type 395 TBD3 397 Option Length 398 The length of the option in octets, excluding the Type and Length 399 fields. Variable due to the presence of the address vector and 400 the number of octets elided according to the Compr value. 402 G 403 Gratuitous route (see Section 7). 405 H 406 The H bit in the RREP option MUST be set to be the same as the H 407 bit in RREQ option. It requests either source routing (H=0) or 408 hop-by-hop (H=1) for the downstream route. 410 X 411 Reserved; MUST be initialized to zero and ignored upon reception. 413 Compr 414 4-bit unsigned integer. Same definition as in RREQ option. 416 L 417 2-bit unsigned integer defined as in RREQ option. The lifetime of 418 the RREP-Instance MUST be shorter than the lifetime of the RREQ- 419 Instance to which it is paired. 421 MaxRank 422 Similarly to MaxRank in the RREQ message, this field indicates the 423 upper limit on the integer portion of the Rank. A value of 0 in 424 this field indicates the limit is infinity. 426 Shift 427 6-bit unsigned integer. This field is used to recover the 428 original RPLInstanceID (see Section 6.3.3); 0 indicates that the 429 original RPLInstanceID is used. 431 X X 432 Reserved; MUST be initialized to zero and ignored upon reception. 434 Address Vector 435 Only present when the H bit is set to 0. For an asymmetric route, 436 the Address Vector represents the IPv6 addresses of the path 437 through the network the RREP-DIO has passed. For a symmetric 438 route, it is the Address Vector when the RREQ-DIO arrives at the 439 TargNode, unchanged during the transmission to the OrigNode. 441 4.3. AODV-RPL Target Option 443 The AODV-RPL Target (ART) Option is based on the Target Option in 444 core RPL [RFC6550]. The Flags field is replaced by the Destination 445 Sequence Number of the TargNode and the Prefix Length field is 446 reduced to 7 bits so that the value is limited to be no greater than 447 127. 449 A RREQ-DIO message MUST carry at least one ART Option. A RREP-DIO 450 message MUST carry exactly one ART Option. Otherwise, the message 451 MUST be dropped. 453 OrigNode can include multiple TargNode addresses via multiple AODV- 454 RPL Target Options in the RREQ-DIO, for routes that share the same 455 requirement on metrics. This reduces the cost to building only one 456 DODAG. 458 0 1 2 3 459 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 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Option Type | Option Length | Dest SeqNo |X|Prefix Length| 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | | 464 + | 465 | Target Prefix / Address (Variable Length) | 466 . . 467 . . 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 Figure 3: ART Option format for AODV-RPL 472 Option Type 473 TBD4 475 Option Length 476 Length of the option in octets excluding the Type and Length 477 fields. 479 Dest SeqNo 481 In RREQ-DIO, if nonzero, it is the Sequence Number for the last 482 route that OrigNode stored to the TargNode for which a route is 483 desired. In RREP-DIO, it is the destination sequence number 484 associated to the route. Zero is used if there is no known 485 information about the sequence number of TargNode, and not used 486 otherwise. 488 X 489 A one-bit reserved field. This field MUST be initialized to zero 490 by the sender and MUST be ignored by the receiver. 492 Prefix Length 493 7-bit unsigned integer. Number of valid leading bits in the IPv6 494 Prefix. If Prefix Length is 0, then the value in the Target 495 Prefix / Address field represents an IPv6 address, not a prefix. 497 Target Prefix / Address 498 (variable-length field) An IPv6 destination address or prefix. 499 The Prefix Length field contains the number of valid leading bits 500 in the prefix. The Target Prefix / Address field contains the 501 least number of octets that can represent all of the bits of the 502 Prefix, in other words Ceil(Prefix Length/8) octets. The initial 503 bits in the Target Prefix / Address field preceding the prefix 504 length (if any) MUST be set to zero on transmission and MUST be 505 ignored on receipt. If Prefix Length is zero, the Address field 506 is 128 bits for IPv6 addresses. 508 5. Symmetric and Asymmetric Routes 510 Links are considered symmetric until indication to the contrary is 511 received. In Figure 4 and Figure 5, BR is the Border Router, O is 512 the OrigNode, each R is an intermediate router, and T is the 513 TargNode. If the RREQ-DIO arrives over an interface that is known to 514 be symmetric, and the S bit is set to 1, then it remains as 1, as 515 illustrated in Figure 4. If an intermediate router sends out RREQ- 516 DIO with the S bit set to 1, then each link en route from the 517 OrigNode O to this router has met the requirements of route 518 discovery, and the route can be used symmetrically. 520 BR 521 /----+----\ 522 / | \ 523 / | \ 524 R R R 525 _/ \ | / \ 526 / \ | / \ 527 / \ | / \ 528 R -------- R --- R ----- R -------- R 529 / \ <--S=1--> / \ <--S=1--> / \ 530 <--S=1--> \ / \ / <--S=1--> 531 / \ / \ / \ 532 O ---------- R ------ R------ R ----- R ----------- T 533 / \ / \ / \ / \ 534 / \ / \ / \ / \ 535 / \ / \ / \ / \ 536 R ----- R ----------- R ----- R ----- R ----- R ---- R----- R 538 >---- RREQ-Instance (Control: O-->T; Data: T-->O) -------> 539 <---- RREP-Instance (Control: T-->O; Data: O-->T) -------< 541 Figure 4: AODV-RPL with Symmetric Instances 543 Upon receiving a RREQ-DIO with the S bit set to 1, a node determines 544 whether this link can be used symmetrically, i.e., both directions 545 meet the requirements of data transmission. If the RREQ-DIO arrives 546 over an interface that is not known to be symmetric, or is known to 547 be asymmetric, the S bit is set to 0. If the S bit arrives already 548 set to be '0', it is set to be '0' when the RREQ-DIO is propagated 549 (Figure 5). For an asymmetric route, there is at least one hop which 550 doesn't satisfy the Objective Function. Based on the S bit received 551 in RREQ-DIO, TargNode T determines whether or not the route is 552 symmetric before transmitting the RREP-DIO message upstream towards 553 the OrigNode O. 555 It is beyond the scope of this document to specify the criteria used 556 when determining whether or not each link is symmetric. As an 557 example, intermediate routers can use local information (e.g., bit 558 rate, bandwidth, number of cells used in 6tisch [RFC9030]), a priori 559 knowledge (e.g., link quality according to previous communication) or 560 use averaging techniques as appropriate to the application. Other 561 link metric information can be acquired before AODV-RPL operation, by 562 executing evaluation procedures; for instance test traffic can be 563 generated between nodes of the deployed network. During AODV-RPL 564 operation, OAM techniques for evaluating link state (see [RFC7548], 565 [RFC7276], [co-ioam]) MAY be used (at regular intervals appropriate 566 for the LLN). The evaluation procedures are out of scope for AODV- 567 RPL. 569 Appendix A describes an example method using the upstream Expected 570 Number of Transmissions (ETX) and downstream Received Signal Strength 571 Indicator (RSSI) to estimate whether the link is symmetric in terms 572 of link quality using an averaging technique. 574 BR 575 /----+----\ 576 / | \ 577 / | \ 578 R R R 579 / \ | / \ 580 / \ | / \ 581 / \ | / \ 582 R --------- R --- R ---- R --------- R 583 / \ --S=1--> / \ --S=0--> / \ 584 --S=1--> \ / \ / --S=0--> 585 / \ / \ / \ 586 O ---------- R ------ R------ R ----- R ----------- T 587 / \ / \ / \ / \ 588 / <--S=0-- / \ / \ / <--S=0-- 589 / \ / \ / \ / \ 590 R ----- R ----------- R ----- R ----- R ----- R ---- R----- R 591 <--S=0-- <--S=0-- <--S=0-- <--S=0-- <--S=0-- 593 >---- RREQ-Instance (Control: O-->T; Data: T-->O) -------> 594 <---- RREP-Instance (Control: T-->O; Data: O-->T) -------< 596 Figure 5: AODV-RPL with Asymmetric Paired Instances 598 As illustrated in Figure 5, an intermediate router determines the S 599 bit value that the RREQ-DIO should carry using link asymmetry 600 detection methods as discussed earlier in this section. In many 601 cases the intermediate router has already made the link asymmetry 602 decision by the time RREQ-DIO arrives. 604 6. AODV-RPL Operation 606 6.1. Route Request Generation 608 The route discovery process is initiated when an application at the 609 OrigNode has data to be transmitted to the TargNode, but does not 610 have a route that satisfies the Objective Function for the target of 611 the application's data. In this case, the OrigNode builds a local 612 RPLInstance and a DODAG rooted at itself. Then it transmits a DIO 613 message containing exactly one RREQ option (see Section 4.1) to 614 multicast group all-RPL-nodes. The DIO MUST contain at least one ART 615 Option (see Section 4.3), which indicates the TargNode. The S bit in 616 RREQ-DIO sent out by the OrigNode is set to 1. 618 Each node maintains a sequence number; the operation is specified in 619 section 7.2 of [RFC6550]. When the OrigNode initiates a route 620 discovery process, it MUST increase its own sequence number to avoid 621 conflicts with previously established routes. The sequence number is 622 carried in the Orig SeqNo field of the RREQ option. 624 The address in the ART Option can be a unicast IPv6 address or a 625 prefix. The OrigNode can initiate the route discovery process for 626 multiple targets simultaneously by including multiple ART Options. 627 Within a RREQ-DIO the Objective Function for the routes to different 628 TargNodes MUST be the same. 630 OrigNode can maintain different RPLInstances to discover routes with 631 different requirements to the same targets. Using the RPLInstanceID 632 pairing mechanism (see Section 6.3.3), route replies (RREP-DIOs) for 633 different RPLInstances can be generated. 635 The transmission of RREQ-DIO obeys the Trickle timer [RFC6206]. If 636 the length of time specified by the L field has elapsed, the OrigNode 637 MUST leave the DODAG and stop sending RREQ-DIOs in the related 638 RPLInstance. 640 6.2. Receiving and Forwarding RREQ messages 642 6.2.1. Step 1: RREQ reception and evaluation 644 When a router X receives a RREQ message over a link from a neighbor 645 Y, X determines whether or not the RREQ is valid. If so, then X 646 determines whether the RREQ advertises a usable route to OrigNode, by 647 checking whether the link to Y can be used to tramsmit packets to 648 OrigNode. 650 When H=0 in the incoming RREQ, the router MUST drop the RREQ-DIO if 651 one of its addresses is present in the Address Vector. When H=1 in 652 the incoming RREQ, the router MUST drop the RREQ message if Orig 653 SeqNo field of the RREQ is older than the SeqNo value that X has 654 stored for a route to OrigNode. Otherwise, the router determines 655 whether to propagate the RREQ-DIO. It does this by determining 656 whether or not a route to OrigNode using the upstream direction of 657 the incoming link satisfies the Objective Function (OF). In order to 658 evaluate the OF, the router first determines the maximum useful rank 659 (MaxUseRank). If the router has previously joined the RREQ-Instance 660 associated with the RREQ-DIO, then MaxUseRank is set to be the Rank 661 value that was stored when the router processed the best previous 662 RREQ for the DODAG with the given RREQ-Instance. Otherwise, 663 MaxUseRank is set to be MaxRank. If OF cannot be satisfied (i.e., 664 the Rank evaluates to a value greater than MaxUseRank) the RREQ-DIO 665 MUST be dropped, and the following steps are not processed. 667 Otherwise, the router MUST join the RREQ-Instance and prepare to 668 propagate the RREQ-DIO, as follows. The upstream neighbor router 669 that transmitted the received RREQ-DIO is selected as the preferred 670 parent. 672 6.2.2. Step 2: TargNode and Intermediate Router determination 674 After determining that a received RREQ provides a usable route to 675 OrigNode, a router determines whether it is a TargNode, or a possible 676 intermediate router between OrigNode and a TargNode, or both. The 677 router is a TargNode if it finds one of its own addresses in a Target 678 Option in the RREQ. After possibly propagating the RREQ according to 679 the procedures in Steps 3, 4, and 5, the TargNode generates a RREP as 680 specified in Section 6.3. 682 If the OrigNode tries to reach multiple TargNodes in a single RREQ- 683 Instance, one of the TargNodes can be an intermediate router to other 684 TargNodes. In this case, before transmitting the RREQ-DIO to 685 multicast group all-RPL-nodes, a TargNode MUST delete the Target 686 Option encapsulating its own address, so that downstream routers with 687 higher Rank values do not try to create a route to this TargNode. 689 An intermediate router could receive several RREQ-DIOs from routers 690 with lower Rank values in the same RREQ-Instance with different lists 691 of Target Options. For the purposes of determining the intersection 692 with previous incoming RREQ-DIOs, the intermediate router maintains a 693 record of the targets that have been requested for a given RREQ- 694 Instance. An incoming RREQ-DIO message having multiple ART Options 695 coming from a router with higher Rank than the Rank of the stored 696 targets is ignored. When transmitting the RREQ-DIO, the intersection 697 of all received lists MUST be included if it is nonempty after 698 TargNode has deleted the Target Option encapsulating its own address. 699 If the intersection is empty, it means that all the targets have been 700 reached, and the router MUST NOT transmit any RREQ-DIO. Otherwise it 701 proceeds to Section 6.2.3. 703 For example, suppose two RREQ-DIOs are received with the same 704 RPLInstance and OrigNode. Suppose further that the first RREQ has 705 (T1, T2) as the targets, and the second one has (T2, T4) as targets. 706 Then only T2 needs to be included in the generated RREQ-DIO. 708 6.2.3. Step 3: Intermediate Router RREQ processing 710 The intermediate router establishes itself as a viable node for a 711 route to OrigNode as follows. If the H bit is set to 1, for hop-by- 712 hop routing, then the router MUST build or update its upward route 713 entry towards OrigNode, which includes at least the following items: 714 Source Address, RPLInstanceID, Destination Address, Next Hop, 715 Lifetime, and Sequence Number. The Destination Address and the 716 RPLInstanceID respectively can be learned from the DODAGID and the 717 RPLInstanceID of the RREQ-DIO. The Source Address is the address 718 used by the router to send data to the Next Hop, i.e., the preferred 719 parent. The lifetime is set according to DODAG configuration (not 720 the L field) and can be extended when the route is actually used. 721 The sequence number represents the freshness of the route entry; it 722 is copied from the Orig SeqNo field of the RREQ option. A route 723 entry with the same source and destination address, same 724 RPLInstanceID, but stale sequence number, MUST be deleted. 726 6.2.4. Step 4: Symmetric Route Processing at an Intermediate Router 728 If the S bit of the incoming RREQ-DIO is 0, then the route cannot be 729 symmetric, and the S bit of the RREQ-DIO to be transmitted is set to 730 0. Otherwise, the router MUST determine whether the downward (i.e., 731 towards the TargNode) direction of the incoming link satisfies the 732 OF. If so, the S bit of the RREQ-DIO to be transmitted is set to 1. 733 Otherwise the S bit of the RREQ-DIO to be transmitted is set to 0. 735 When a router joins the RREQ-Instance, it also associates within its 736 data structure for the RREQ-Instance the information about whether or 737 not the RREQ-DIO to be transmitted has the S-bit set to 1. This 738 information associated to RREQ-Instance is known as the S-bit of the 739 RREQ-Instance. It will be used later during the RREP-DIO message 740 processing Section 6.3.2. 742 Suppose a router has joined the RREQ-Instance, and H=0, and the S-bit 743 of the RREQ-Instance is set to 1. In this case, the router MAY 744 optionally associate to the RREQ-Instance, the Address Vector of the 745 symmetric route back to OrigNode. This is useful if the router later 746 receives an RREP-DIO that is paired with the RREQ. 748 6.2.5. Step 5: RREQ propagation at an Intermediate Router 750 If the router is an intermediate router, then it transmits the RREQ- 751 DIO to the multicast group all-RPL-nodes; if the H bit is set to 0, 752 the intermediate router MUST append the address of its interface 753 receiving the RREQ-DIO into the address vector. 755 6.2.6. Step 6: RREQ reception at TargNode 757 If the router is a TargNode and it was not already associated with 758 the RREQ-Instance, it prepares and transmits a RREP-DIO 759 (Section 6.3). If, on the other hand, TargNode was already 760 associated with the RREQ-Instance, it takes no further action and 761 does not send an RREP-DIO. 763 6.3. Generating Route Reply (RREP) at TargNode 765 When a TargNode receives a RREQ message over a link from a neighbor 766 Y, TargNode first follows the procedures in Section 6.2. If the link 767 to Y can be used to tramsmit packets to OrigNode, TargNode generates 768 a RREP according to the steps below. Otherwise TargNode drops the 769 RREQ and does not generate a RREP. 771 If the L field is not 0, the TargNode MAY delay transmitting the 772 RREP-DIO for duration RREP_WAIT_TIME to await a route with a lower 773 Rank. The value of RREP_WAIT_TIME is set by default to 1/4 of the 774 duration determined by the L field. For L == 0, RREP_WAIT_TIME is 775 set by default to 0. Depending upon the application, RREP_WAIT_TIME 776 may be set to other values. Smaller values enable quicker formation 777 for the P2P route. Larger values enable formation of P2P routes with 778 better Rank values. 780 The address of the OrigNode MUST be encapsulated in the ART Option 781 and included in this RREP-DIO message along with the SeqNo of 782 TargNode. 784 6.3.1. RREP-DIO for Symmetric route 786 If the RREQ-Instance corresponding to the RREQ-DIO that arrived at 787 TargNode has the S bit set to 1, there is a symmetric route both of 788 whose directions satisfy the Objective Function. Other RREQ-DIOs 789 might later provide better upward routes. The method of selection 790 between a qualified symmetric route and an asymmetric route that 791 might have better performance is implementation-specific and out of 792 scope. 794 For a symmetric route, the RREP-DIO message is unicast to the next 795 hop according to the Address Vector (H=0) or the route entry (H=1); 796 the DODAG in RREP-Instance does not need to be built. The 797 RPLInstanceID in the RREP-Instance is paired as defined in 798 Section 6.3.3. In case the H bit is set to 0, the address vector 799 from the RREQ-DIO MUST be included in the RREP-DIO. 801 6.3.2. RREP-DIO for Asymmetric Route 803 When a RREQ-DIO arrives at a TargNode with the S bit set to 0, the 804 TargNode MUST build a DODAG in the RREP-Instance corresponding to the 805 RREQ-DIO rooted at itself, in order to provide OrigNode with a 806 downstream route to the TargNode. The RREP-DIO message is 807 transmitted to multicast group all-RPL-nodes. 809 6.3.3. RPLInstanceID Pairing 811 Since the RPLInstanceID is assigned locally (i.e., there is no 812 coordination between routers in the assignment of RPLInstanceID), the 813 tuple (OrigNode, TargNode, RPLInstanceID) is needed to uniquely 814 identify a discovered route. It is possible that multiple route 815 discoveries with dissimilar Objective Functions are initiated 816 simultaneously. Thus between the same pair of OrigNode and TargNode, 817 there can be multiple AODV-RPL route discovery instances. So that 818 OrigNode and Targnode can avoid any mismatch, they MUST pair the 819 RREQ-Instance and the RREP-Instance in the same route discovery by 820 using the RPLInstanceID. 822 When preparing the RREP-DIO, a TargNode could find the RPLInstanceID 823 candidate for the RREP-Instance is already occupied by another RPL 824 Instance from an earlier route discovery operation which is still 825 active. This unlikely case might happen if two distinct OrigNodes 826 need routes to the same TargNode, and they happen to use the same 827 RPLInstanceID for RREQ-Instance. In such cases, the original 828 RPLInstanceID of an already active RREP-Instance MUST NOT be used 829 again for assigning RPLInstanceID for the later RREP-Instance. 830 Reusing the same RPLInstanceID for two distinct DODAGs originated 831 with the same DODAGID (TargNode address) would prevent intermediate 832 routers to distinguish between these DODAGs (and their associated 833 Objective Functions). Instead, the RPLInstanceID MUST be replaced by 834 another value so that the two RREP-instances can be distinguished. 835 In RREP-DIO option, the Shift field of the RREP-DIO message(Figure 2) 836 indicates the shift to be applied to original RPLInstanceID to obtain 837 the replacement RPLInstanceID. When the new RPLInstanceID after 838 shifting exceeds 255, it rolls over starting at 0. For example, if 839 the original RPLInstanceID is 252, and shifted by 6, the new 840 RPLInstanceID will be 2. Related operations can be found in 841 Section 6.4. RPLInstanceID collisions do not occur across RREQ-DIOs; 842 the DODAGID equals the OrigNode address and is sufficient to 843 disambiguate between DODAGs. 845 6.4. Receiving and Forwarding Route Reply 847 Upon receiving a RREP-DIO, a router which already belongs to the 848 RREP-Instance SHOULD drop the DIO. Otherwise the router performs the 849 steps in the following subsections. 851 6.4.1. Step 1: Receiving and Evaluation 853 If the Objective Function is not satisfied, the router MUST NOT join 854 the DODAG; the router MUST discard the RREP-DIO, and does not execute 855 the remaining steps in this section. An Intermediate Router MUST 856 discard a RREP if one of its addresses is present in the Address 857 Vector, and does not execute the remaining steps in this section. 859 If the S bit of the associated RREQ-Instance is set to 1, the router 860 MUST proceed to Section 6.2.2. 862 If the S-bit of the RREQ-Instance is set to 0, the router MUST 863 determine whether the downward direction of the link (towards the 864 TargNode) over which the RREP-DIO is received satisfies the Objective 865 Function, and the router's Rank would not exceed the MaxRank limit. 866 If so, the router joins the DODAG of the RREP-Instance. The router 867 that transmitted the received RREP-DIO is selected as the preferred 868 parent. Afterwards, other RREP-DIO messages can be received. 870 6.4.2. Step 2: OrigNode or Intermediate Router 872 The router updates its stored value of the TargNode's sequence number 873 according to the value provided in the ART option. The router next 874 checks if one of its addresses is included in the ART Option. If so, 875 this router is the OrigNode of the route discovery. Otherwise, it is 876 an intermediate router. 878 6.4.3. Step 3: Build Route to TargNode 880 If the H bit is set to 1, then the router (OrigNode or intermediate) 881 MUST build a downward route entry towards TargNode which includes at 882 least the following items: OrigNode Address, RPLInstanceID, TargNode 883 Address as destination, Next Hop, Lifetime and Sequence Number. For 884 a symmetric route, the Next Hop in the route entry is the router from 885 which the RREP-DIO is received. For an asymmetric route, the Next 886 Hop is the preferred parent in the DODAG of RREP-Instance. The 887 RPLInstanceID in the route entry MUST be the original RPLInstanceID 888 (after subtracting the Shift field value). The source address is 889 learned from the ART Option, and the destination address is learned 890 from the DODAGID. The lifetime is set according to DODAG 891 configuration (i.e., not the L field) and can be extended when the 892 route is actually used. The sequence number represents the freshness 893 of the route entry, and is copied from the Dest SeqNo field of the 894 ART option of the RREP-DIO. A route entry with same source and 895 destination address, same RPLInstanceID, but stale sequence number 896 (i.e., incoming sequence number is less than the currently stored 897 sequence number of the route entry), MUST be deleted. 899 6.4.4. Step 4: RREP Propagation 901 If the receiver is the OrigNode, it can start transmitting the 902 application data to TargNode along the path as provided in RREP- 903 Instance, and processing for the RREP-DIO is complete. Otherwise, 904 the RREP will be propagated towards OrigNode. If H=0, the 905 intermediate router MUST include the address of the interface 906 receiving the RREP-DIO into the address vector. If H=1, according to 907 the last step the intermediate router has set up a route entry for 908 TargNode. If the intermediate router has a route to OrigNode, it 909 uses that route to unicast the RREP-DIO to OrigNode. Otherwise, in 910 case of a symmetric route, the RREP-DIO message is unicast to the 911 Next Hop according to the address vector in the RREP-DIO (H=0) or the 912 local route entry (H=1). Otherwise In case of an asymmetric route, 913 the intermediate router transmits the RREP-DIO to multicast group 914 all-RPL-nodes. The RPLInstanceID in the transmitted RREP-DIO is the 915 same as the value in the received RREP-DIO. 917 7. Gratuitous RREP 919 In some cases, an Intermediate router that receives a RREQ-DIO 920 message MAY transmit a "Gratuitous" RREP-DIO message back to OrigNode 921 instead of continuing to multicast the RREQ-DIO towards TargNode. 922 The intermediate router effectively builds the RREP-Instance on 923 behalf of the actual TargNode. The G bit of the RREP option is 924 provided to distinguish the Gratuitous RREP-DIO (G=1) sent by the 925 Intermediate router from the RREP-DIO sent by TargNode (G=0). 927 The gratuitous RREP-DIO MAY be sent out when an intermediate router 928 receives a RREQ-DIO for a TargNode, and the router has a pair of 929 downward and upward routes to the TargNode which also satisfy the 930 Objective Function and for which the destination sequence number is 931 at least as large. 933 In case of source routing, the intermediate router MUST unicast the 934 received RREQ-DIO to TargNode including the address vector between 935 the OrigNode and the router. Thus the TargNode can have a complete 936 upward route address vector from itself to the OrigNode. Then the 937 router MUST include the address vector from the TargNode to the 938 router itself in the gratuitous RREP-DIO to be transmitted. 940 In case of hop-by-hop routing, the intermediate router MUST unicast 941 the received RREQ-DIO to the Next Hop on the route. The Next Hop 942 router along the route MUST build new route entries with the related 943 RPLInstanceID and DODAGID in the downward direction. The above 944 process will happen recursively until the RREQ-DIO arrives at the 945 TargNode. Then the TargNode MUST unicast recursively the RREP-DIO 946 hop-by-hop to the intermediate router, and the routers along the 947 route SHOULD build new route entries in the upward direction. Upon 948 receiving the unicast RREP-DIO, the intermediate router sends the 949 gratuitous RREP-DIO to the OrigNode as defined in Section 6.3. 951 8. Operation of Trickle Timer 953 The trickle timer operation to control RREQ-Instance/RREP-Instance 954 multicast uses [RFC6206] to control RREQ-DIO and RREP-DIO 955 transmissions. The Trickle control of these DIO transmissions follow 956 the procedures described in the Section 8.3 of [RFC6550] entitled 957 "DIO Transmission". 959 9. IANA Considerations 961 Note to RFC editor: 963 The sentence "The parenthesized numbers are only suggestions." is to 964 be removed prior publication. 966 A Subregistry in this section refers to a named sub-registry of the 967 "Routing Protocol for Low Power and Lossy Networks (RPL)" registry. 969 AODV-RPL uses the "P2P Route Discovery Mode of Operation" (MOP == 4) 970 with new Options as specified in this document. Please cite AODV-RPL 971 and this document as one of the protocols using MOP 4. 973 IANA is asked to assign three new AODV-RPL options "RREQ", "RREP" and 974 "ART", as described in Figure 6 from the "RPL Control Message 975 Options" Subregistry. The parenthesized numbers are only 976 suggestions. 978 +-------------+------------------------+---------------+ 979 | Value | Meaning | Reference | 980 +-------------+------------------------+---------------+ 981 | TBD2 (0x0B) | RREQ Option | This document | 982 +-------------+------------------------+---------------+ 983 | TBD3 (0x0C) | RREP Option | This document | 984 +-------------+------------------------+---------------+ 985 | TBD4 (0x0D) | ART Option | This document | 986 +-------------+------------------------+---------------+ 987 Figure 6: AODV-RPL Options 989 10. Security Considerations 991 The security considerations for the operation of AODV-RPL are similar 992 to those for the operation of RPL (as described in Section 19 of the 993 RPL specification [RFC6550]). Sections 6.1 and 10 of [RFC6550] 994 describe RPL's optional security framework, which AODV-RPL relies on 995 to provide data confidentiality, authentication, replay protection, 996 and delay protection services. Additional analysis for the security 997 threats to RPL can be found in [RFC7416]. 999 A router can join a temporary DAG created for a secure AODV-RPL route 1000 discovery only if it can support the security configuration in use 1001 (see Section 6.1 of [RFC6550]), which also specifies the key in use. 1002 It does not matter whether the key is preinstalled or dynamically 1003 acquired. The router must have the key in use before it can join the 1004 DAG being created for secure route discovery. 1006 If a rogue router knows the key for the security configuration in 1007 use, it can join the secure AODV-RPL route discovery and cause 1008 various types of damage. Such a rogue router could advertise false 1009 information in its DIOs in order to include itself in the discovered 1010 route(s). It could generate bogus RREQ-DIO, and RREP-DIO messages 1011 carrying bad routes or maliciously modify genuine RREP-DIO messages 1012 it receives. A rogue router acting as the OrigNode could launch 1013 denial-of-service attacks against the LLN deployment by initiating 1014 fake AODV-RPL route discoveries. When rogue routers might be 1015 present, RPL's preinstalled mode of operation, where the key to use 1016 for route discovery is preinstalled, SHOULD be used. 1018 When a RREQ-DIO message uses the source routing option by setting the 1019 H bit to 0, a rogue router may populate the Address Vector field with 1020 a set of addresses that may result in the RREP-DIO traveling in a 1021 routing loop. 1023 If a rogue router is able to forge a gratuitous RREP, it could mount 1024 denial-of-service attacks. 1026 11. Acknowledgements 1028 The authors thank Pascal Thubert, Rahul Jadhav, and Lijo Thomas for 1029 their support and valuable inputs. The authors specially thank 1030 Lavanya H.M for implementing AODV-RPl in Contiki and conducting 1031 extensive simulation studies. 1033 The authors would like to acknowledge the review, feedback and 1034 comments from the following people, in alphabetical order: Roman 1035 Danyliw, Lars Eggert, Benjamin Kaduk, Tero Kivinen, Erik Kline, 1036 Murray Kucherawy, Warren Kumari, Francesca Palombini, Alvaro Retana, 1037 Ines Robles, John Scudder, Meral Shirazipour, Peter Van der Stok, 1038 Eric Vyncke, and Robert Wilton. 1040 12. References 1042 12.1. Normative References 1044 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1045 Requirement Levels", BCP 14, RFC 2119, 1046 DOI 10.17487/RFC2119, March 1997, 1047 . 1049 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 1050 "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, 1051 March 2011, . 1053 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1054 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1055 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1056 Low-Power and Lossy Networks", RFC 6550, 1057 DOI 10.17487/RFC6550, March 2012, 1058 . 1060 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 1061 and D. Barthel, "Routing Metrics Used for Path Calculation 1062 in Low-Power and Lossy Networks", RFC 6551, 1063 DOI 10.17487/RFC6551, March 2012, 1064 . 1066 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1067 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1068 May 2017, . 1070 12.2. Informative References 1072 [co-ioam] Ballamajalu, Rashmi., S.V.R., Anand., and Malati Hegde, 1073 "Co-iOAM: In-situ Telemetry Metadata Transport for 1074 Resource Constrained Networks within IETF Standards 1075 Framework", 2018 10th International Conference on 1076 Communication Systems & Networks (COMSNETS) pp.573-576, 1077 January 2018. 1079 [contiki] Contiki contributors, "The Contiki Open Source OS for the 1080 Internet of Things (Contiki Version 2.7)", November 2013, 1081 . 1083 [Contiki-ng] 1084 Contiki-NG contributors, "Contiki-NG: The OS for Next 1085 Generation IoT Devices (Contiki-NG Version 4.6)", December 1086 2020, . 1088 [cooja] Contiki/Cooja contributors, "Cooja Simulator for Wireless 1089 Sensor Networks (Contiki/Cooja Version 2.7)", November 1090 2013, . 1093 [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- 1094 Demand Distance Vector (AODV) Routing", RFC 3561, 1095 DOI 10.17487/RFC3561, July 2003, 1096 . 1098 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and 1099 J. Martocci, "Reactive Discovery of Point-to-Point Routes 1100 in Low-Power and Lossy Networks", RFC 6997, 1101 DOI 10.17487/RFC6997, August 2013, 1102 . 1104 [RFC6998] Goyal, M., Ed., Baccelli, E., Brandt, A., and J. Martocci, 1105 "A Mechanism to Measure the Routing Metrics along a Point- 1106 to-Point Route in a Low-Power and Lossy Network", 1107 RFC 6998, DOI 10.17487/RFC6998, August 2013, 1108 . 1110 [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. 1111 Weingarten, "An Overview of Operations, Administration, 1112 and Maintenance (OAM) Tools", RFC 7276, 1113 DOI 10.17487/RFC7276, June 2014, 1114 . 1116 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 1117 and M. Richardson, Ed., "A Security Threat Analysis for 1118 the Routing Protocol for Low-Power and Lossy Networks 1119 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 1120 . 1122 [RFC7548] Ersue, M., Ed., Romascanu, D., Schoenwaelder, J., and A. 1123 Sehgal, "Management of Networks with Constrained Devices: 1124 Use Cases", RFC 7548, DOI 10.17487/RFC7548, May 2015, 1125 . 1127 [RFC9030] Thubert, P., Ed., "An Architecture for IPv6 over the Time- 1128 Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)", 1129 RFC 9030, DOI 10.17487/RFC9030, May 2021, 1130 . 1132 Appendix A. Example: Using ETX/RSSI Values to determine value of S bit 1134 The combination of Received Signal Strength Indication(downstream) 1135 (RSSI) and Expected Number of Transmissions(upstream) (ETX) has been 1136 tested to determine whether a link is symmetric or asymmetric at 1137 intermediate routers. We present two methods to obtain an ETX value 1138 from RSSI measurement. 1140 Method 1: In the first method, we constructed a table measuring RSSI 1141 vs ETX using the Cooja simulation [cooja] setup in the Contiki OS 1142 environment[contiki]. We used Contiki-2.7 running 6LoWPAN/RPL 1143 protocol stack for the simulations. For approximating the number 1144 of packet drops based on the RSSI values, we implemented simple 1145 logic that drops transmitted packets with certain pre-defined 1146 ratios before handing over the packets to the receiver. The 1147 packet drop ratio is implemented as a table lookup of RSSI ranges 1148 mapping to different packet drop ratios with lower RSSI ranges 1149 resulting in higher values. While this table has been defined for 1150 the purpose of capturing the overall link behavior, it is highly 1151 recommended to conduct physical radio measurement experiments, in 1152 general. By keeping the receiving node at different distances, we 1153 let the packets experience different packet drops as per the 1154 described method. The ETX value computation is done by another 1155 module which is part of RPL Objective Function implementation. 1156 Since ETX value is reflective of the extent of packet drops, it 1157 allowed us to prepare a useful ETX vs RSSI table. ETX versus RSSI 1158 values obtained in this way may be used as explained below: 1160 Source---------->NodeA---------->NodeB------->Destination 1162 Figure 7: Communication link from Source to Destination 1164 +=========================+========================================+ 1165 | RSSI at NodeA for NodeB | Expected ETX at NodeA for NodeB->NodeA | 1166 +=========================+========================================+ 1167 | > -60 | 150 | 1168 +-------------------------+----------------------------------------+ 1169 | -70 to -60 | 192 | 1170 +-------------------------+----------------------------------------+ 1171 | -80 to -70 | 226 | 1172 +-------------------------+----------------------------------------+ 1173 | -90 to -80 | 662 | 1174 +-------------------------+----------------------------------------+ 1175 | -100 to -90 | 3840 | 1176 +-------------------------+----------------------------------------+ 1178 Table 1: Selection of S bit based on Expected ETX value 1180 Method 2: One could also make use of the function 1181 guess_etx_from_rssi() defined in the 6LoWPAN/RPL protocol stack of 1182 Contiki-ng OS [Contiki-ng] to obtain RSSI-ETX mapping. This 1183 function outputs ETX value ranging between 128 and 3840 for -60 <= 1184 rssi <= -89. The function description is beyond the scope of this 1185 document. 1187 We tested the operations in this specification by making the 1188 following experiment, using the above parameters. In our experiment, 1189 a communication link is considered as symmetric if the ETX value of 1190 NodeA->NodeB and NodeB->NodeA (see Figure 7) are within, say, a 1:3 1191 ratio. This ratio should be understood as determining the link's 1192 symmetric/asymmetric nature. NodeA can typically know the ETX value 1193 in the direction of NodeA -> NodeB but it has no direct way of 1194 knowing the value of ETX from NodeB->NodeA. Using physical testbed 1195 experiments and realistic wireless channel propagation models, one 1196 can determine a relationship between RSSI and ETX representable as an 1197 expression or a mapping table. Such a relationship in turn can be 1198 used to estimate ETX value at nodeA for link NodeB--->NodeA from the 1199 received RSSI from NodeB. Whenever nodeA determines that the link 1200 towards the nodeB is bi-directional asymmetric then the S bit is set 1201 to 0. Afterwards, the link from NodeA to Destination remains 1202 designated as asymmetric and the S bit remains set to 0. 1204 Appendix B. Changelog 1206 Note to the RFC Editor: please remove this section before 1207 publication. 1209 B.1. Changes from version 11 to version 12 1210 * Defined RREP_WAIT_TIME for asymmetric as well as symmetric 1211 handling of RREP-DIO. 1213 * Clarifed link-local multicast transmission to use link-local 1214 multicast group all-RPL nodes. 1216 * Identified some security threats more explicitly. 1218 * Specified that the pairing between RREQ-DIO and RREP-DIO happens 1219 at OrigNode and TargNode. Intermediate routers do not necessarily 1220 maintain the pairing. 1222 * When RREQ-DIO is received with H=0 and S=1, specified that 1223 intermediate routers MAY store symmetric Address Vector 1224 information for possible use when a matchine RREP-DIO is received. 1226 * Specified that AODV-RPL uses the "P2P Route Discovery Mode of 1227 Operation" (MOP == 4), instead of requesting the allocation of a 1228 new MOP. Clarified that there is no conflict with [RFC6997]. 1230 * Fixed several important typos and improved language in numerous 1231 places. 1233 * Reorganized the steps in the specification for handling RREQ and 1234 RREP at an intermediate router, to more closely follow the order 1235 of processing actions to be taken by the router. 1237 B.2. Changes from version 10 to version 11 1239 * Numerous editorial improvements. 1241 * Replace Floor((7+(Prefix Length))/8) by Ceil(Prefix Length/8) for 1242 simplicity and ease of understanding. 1244 * Use "L field" instead of "L bit" since L is a two-bit field. 1246 * Improved the procedures in section 6.2.1. 1248 * Define the S bit of the data structure a router uses to represent 1249 whether or not the RREQ instance is for a symmetric or an 1250 asymmetric route. This replaces text in the document that was a 1251 holdover from earlier versions in which the RREP had an S bit for 1252 that purpose. 1254 * Quote terminology from AODV that has been identified as possibly 1255 originating in language reflecting various kinds of bias against 1256 certain cultures. 1258 * Clarified the relationship of AODV-RPL to RPL. 1260 * Eliminated the "Point-to-Point" terminology to avoid suggesting 1261 only a single link. 1263 * Modified certain passages to better reflect the possibility that a 1264 router might have multiple IP addresses. 1266 * "Rsv" replaced by "X X" for reserved field. 1268 * Added mandates for reserved fields, and replaces some ambiguous 1269 language phraseology by mandates. 1271 * Replaced "retransmit" terminology by more correct "propagate" 1272 terminology. 1274 * Added text about determining link symmetry near Figure 5. 1276 * Mandated checking the Address Vector to avoid routing loops. 1278 * Improved specification for use of the Shift value in 1279 Section 6.3.3. 1281 * Corrected the wrong use of RREQ-Instance to be RREP-Instance. 1283 * Referred to Subregistry values instead of Registry values in 1284 Section 9. 1286 * Sharpened language in Section 10, eliminated misleading use of 1287 capitalization in the words "Security Configuration". 1289 * Added acknowledgements and contributors. 1291 B.3. Changes from version 09 to version 10 1293 * Changed the title for brevity and to remove acronyms. 1295 * Added "Note to the RFC Editor" in Section 9. 1297 * Expanded DAO and P2MP in Section 1. 1299 * Reclassified [RFC6998] and [RFC7416] as Informational. 1301 * SHOULD changed to MUST in Section 4.1 and Section 4.2. 1303 * Several editorial improvements and clarifications. 1305 B.4. Changes from version 08 to version 09 1307 * Removed section "Link State Determination" and put some of the 1308 relevant material into Section 5. 1310 * Cited security section of [RFC6550] as part of the RREP-DIO 1311 message description in Section 2. 1313 * SHOULD has been changed to MUST in Section 4.2. 1315 * Expanded the terms ETX and RSSI in Section 5. 1317 * Section 6.4 has been expanded to provide a more precise 1318 explanation of the handling of route reply. 1320 * Added [RFC7416] in the Security Considerations (Section 10) for 1321 RPL security threats. Cited [RFC6550] for authenticated mode of 1322 operation. 1324 * Appendix A has been mostly re-written to describe methods to 1325 determine whether or not the S bit should be set to 1. 1327 * For consistency, adjusted several mandates from SHOULD to MUST and 1328 from SHOULD NOT to MUST NOT. 1330 * Numerous editorial improvements and clarifications. 1332 B.5. Changes from version 07 to version 08 1334 * Instead of describing the need for routes to "fulfill the 1335 requirements", specify that routes need to "satisfy the Objective 1336 Function". 1338 * Removed all normative dependencies on [RFC6997] 1340 * Rewrote Section 10 to avoid duplication of language in cited 1341 specifications. 1343 * Added a new section "Link State Determination" with text and 1344 citations to more fully describe how implementations determine 1345 whether links are symmetric. 1347 * Modified text comparing AODV-RPL to other protocols to emphasize 1348 the need for AODV-RPL instead of the problems with the other 1349 protocols. 1351 * Clarified that AODV-RPL uses some of the base RPL specification 1352 but does not require an instance of RPL to run. 1354 * Improved capitalization, quotation, and spelling variations. 1356 * Specified behavior upon reception of a RREQ-DIO or RREP-DIO 1357 message for an already existing DODAGID (e.g, Section 6.4). 1359 * Fixed numerous language issues in IANA Considerations Section 9. 1361 * For consistency, adjusted several mandates from SHOULD to MUST and 1362 from SHOULD NOT to MUST NOT. 1364 * Numerous editorial improvements and clarifications. 1366 B.6. Changes from version 06 to version 07 1368 * Added definitions for all fields of the ART option (see 1369 Section 4.3). Modified definition of Prefix Length to prohibit 1370 Prefix Length values greater than 127. 1372 * Modified the language from [RFC6550] Target Option definition so 1373 that the trailing zero bits of the Prefix Length are no longer 1374 described as "reserved". 1376 * Reclassified [RFC3561] and [RFC6998] as Informative. 1378 * Added citation for [RFC8174] to Terminology section. 1380 B.7. Changes from version 05 to version 06 1382 * Added Security Considerations based on the security mechanisms 1383 defined in [RFC6550]. 1385 * Clarified the nature of improvements due to P2P route discovery 1386 versus bidirectional asymmetric route discovery. 1388 * Editorial improvements and corrections. 1390 B.8. Changes from version 04 to version 05 1392 * Add description for sequence number operations. 1394 * Extend the residence duration L in section 4.1. 1396 * Change AODV-RPL Target option to ART option. 1398 B.9. Changes from version 03 to version 04 1400 * Updated RREP option format. Remove the T bit in RREP option. 1402 * Using the same RPLInstanceID for RREQ and RREP, no need to update 1403 [RFC6550]. 1405 * Explanation of Shift field in RREP. 1407 * Multiple target options handling during transmission. 1409 B.10. Changes from version 02 to version 03 1411 * Include the support for source routing. 1413 * Import some features from [RFC6997], e.g., choice between hop-by- 1414 hop and source routing, the L field which determines the duration 1415 of residence in the DAG, MaxRank, etc. 1417 * Define new target option for AODV-RPL, including the Destination 1418 Sequence Number in it. Move the TargNode address in RREQ option 1419 and the OrigNode address in RREP option into ADOV-RPL Target 1420 Option. 1422 * Support route discovery for multiple targets in one RREQ-DIO. 1424 * New RPLInstanceID pairing mechanism. 1426 Appendix C. Contributors 1428 Abdur Rashid Sangi 1430 Huaiyin Institute of Technology 1432 No.89 North Beijing Road, Qinghe District 1434 Huaian 223001 1436 P.R. China 1438 Email: sangi_bahrian@yahoo.com 1440 Malati Hegde 1442 Indian Institute of Science 1444 Bangalore 560012 1446 India 1448 Email: malati@iisc.ac.in 1449 Mingui Zhang 1451 Huawei Technologies 1453 No. 156 Beiqing Rd. Haidian District 1455 Beijing 100095 1457 P.R. China 1459 Email: zhangmingui@huawei.com 1461 Authors' Addresses 1463 Charles E. Perkins 1464 Lupin Lodge 1465 Los Gatos, 95033 1466 United States 1468 Email: charliep@lupinlodge.com 1470 S.V.R Anand 1471 Indian Institute of Science 1472 Bangalore 560012 1473 India 1475 Email: anandsvr@iisc.ac.in 1477 Satish Anamalamudi 1478 SRM University-AP 1479 Amaravati Campus 1480 Amaravati, Andhra Pradesh 522 502 1481 India 1483 Email: satishnaidu80@gmail.com 1485 Bing Liu 1486 Huawei Technologies 1487 No. 156 Beiqing Rd. Haidian District 1488 Beijing 1489 100095 1490 China 1492 Email: remy.liubing@huawei.com