idnits 2.17.1 draft-ietf-roll-aodv-rpl-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (25 June 2022) is 670 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL C.E. Perkins 3 Internet-Draft Lupin Lodge 4 Intended status: Standards Track S.V.R.Anand 5 Expires: 27 December 2022 Indian Institute of Science 6 S. Anamalamudi 7 SRM University-AP 8 B. Liu 9 Huawei Technologies 10 25 June 2022 12 Supporting Asymmetric Links in Low Power Networks: AODV-RPL 13 draft-ietf-roll-aodv-rpl-14 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 routes 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 27 December 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 . . . . . . . . . . . . . . . . . . . . 7 62 4. AODV-RPL DIO Options . . . . . . . . . . . . . . . . . . . . 8 63 4.1. AODV-RPL RREQ Option . . . . . . . . . . . . . . . . . . 8 64 4.2. AODV-RPL RREP Option . . . . . . . . . . . . . . . . . . 10 65 4.3. AODV-RPL Target Option . . . . . . . . . . . . . . . . . 11 66 5. Symmetric and Asymmetric Routes . . . . . . . . . . . . . . . 13 67 6. AODV-RPL Operation . . . . . . . . . . . . . . . . . . . . . 15 68 6.1. Route Request Generation . . . . . . . . . . . . . . . . 15 69 6.2. Receiving and Forwarding RREQ messages . . . . . . . . . 16 70 6.2.1. Step 1: RREQ reception and evaluation . . . . . . . . 16 71 6.2.2. Step 2: TargNode and Intermediate Router 72 determination . . . . . . . . . . . . . . . . . . . . 17 73 6.2.3. Step 3: Intermediate Router RREQ processing . . . . . 18 74 6.2.4. Step 4: Symmetric Route Processing at an Intermediate 75 Router . . . . . . . . . . . . . . . . . . . . . . . 18 76 6.2.5. Step 5: RREQ propagation at an Intermediate Router . 19 77 6.2.6. Step 6: RREQ reception at TargNode . . . . . . . . . 19 78 6.3. Generating Route Reply (RREP) at TargNode . . . . . . . . 19 79 6.3.1. RREP-DIO for Symmetric route . . . . . . . . . . . . 19 80 6.3.2. RREP-DIO for Asymmetric Route . . . . . . . . . . . . 20 81 6.3.3. RPLInstanceID Pairing . . . . . . . . . . . . . . . . 20 82 6.4. Receiving and Forwarding Route Reply . . . . . . . . . . 21 83 6.4.1. Step 1: Receiving and Evaluation . . . . . . . . . . 21 84 6.4.2. Step 2: OrigNode or Intermediate Router . . . . . . . 21 85 6.4.3. Step 3: Build Route to TargNode . . . . . . . . . . . 21 86 6.4.4. Step 4: RREP Propagation . . . . . . . . . . . . . . 22 87 7. Gratuitous RREP . . . . . . . . . . . . . . . . . . . . . . . 22 88 8. Operation of Trickle Timer . . . . . . . . . . . . . . . . . 23 89 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 90 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 91 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 92 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 93 12.1. Normative References . . . . . . . . . . . . . . . . . . 25 94 12.2. Informative References . . . . . . . . . . . . . . . . . 26 96 Appendix A. Example: Using ETX/RSSI Values to determine value of S 97 bit . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 98 Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . 29 99 B.1. Changes from version 13 to version 14 . . . . . . . . . . 30 100 B.2. Changes from version 12 to version 13 . . . . . . . . . . 30 101 B.3. Changes from version 11 to version 12 . . . . . . . . . . 31 102 B.4. Changes from version 10 to version 11 . . . . . . . . . . 32 103 B.5. Changes from version 09 to version 10 . . . . . . . . . . 33 104 B.6. Changes from version 08 to version 09 . . . . . . . . . . 33 105 B.7. Changes from version 07 to version 08 . . . . . . . . . . 33 106 B.8. Changes from version 06 to version 07 . . . . . . . . . . 34 107 B.9. Changes from version 05 to version 06 . . . . . . . . . . 34 108 B.10. Changes from version 04 to version 05 . . . . . . . . . . 35 109 B.11. Changes from version 03 to version 04 . . . . . . . . . . 35 110 B.12. Changes from version 02 to version 03 . . . . . . . . . . 35 111 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 35 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 114 1. Introduction 116 Routing Protocol for Low-Power and Lossy Networks (RPL) [RFC6550] is 117 an IPv6 distance vector routing protocol designed to support multiple 118 traffic flows through a root-based Destination-Oriented Directed 119 Acyclic Graph (DODAG). Typically, a router does not have routing 120 information for most other routers. Consequently, for traffic 121 between routers within the DODAG (i.e., Peer-to-Peer (P2P) traffic) 122 data packets either have to traverse the root in non-storing mode, or 123 traverse a common ancestor in storing mode. Such P2P traffic is 124 thereby likely to traverse longer routes and may suffer severe 125 congestion near the root (for more information see [RFC6687], 126 [RFC6997], [RFC6998], [RFC9010]). The network environment that is 127 considered in this document is assumed to be the same as described in 128 Section 1 of [RFC6550]. 130 The route discovery process in AODV-RPL is modeled on the analogous 131 peer-to-peer procedure specified in AODV [RFC3561]. The on-demand 132 nature of AODV route discovery is natural for the needs of routing in 133 RPL-based LLNs when routes are needed but aren't yet established. 134 Peer-to-peer routing is desirable to discover shorter routes, and 135 especially when it is desired to avoid directing additional traffic 136 through a root or gateway node of the network. 138 AODV terminology has been adapted for use with AODV-RPL messages, 139 namely RREQ for Route Request, and RREP for Route Reply. AODV-RPL 140 currently omits some features compared to AODV -- in particular, 141 flagging Route Errors, "blacklisting" unidirectional links 142 ([RFC3561]), multihoming, and handling unnumbered interfaces. 144 AODV-RPL reuses and extends the core RPL functionality to support 145 routes with bidirectional asymmetric links. It retains RPL's DODAG 146 formation, RPL Instance and the associated Objective Function 147 (defined in [RFC6551]), trickle timers, and support for storing and 148 non-storing modes. AODV-RPL adds basic messages RREQ and RREP as 149 part of RPL DODAG Information Object (DIO) control message, which go 150 in separate (paired) RPL instances. AODV-RPL does not utilize the 151 Destination Advertisement Object (DAO) control message of RPL. AODV- 152 RPL uses the "P2P Route Discovery Mode of Operation" (MOP == 4) with 153 three new Options for the DIO message, dedicated to discover P2P 154 routes. These P2P routes may differ from routes discoverable by 155 native RPL. Since AODV-RPL uses newly defined Options and a newly 156 allocated multicast group (see Section 9), there is no conflict with 157 P2P-RPL [RFC6997], a previous document using the same MOP. AODV-RPL 158 can be operated whether or not P2P-RPL or native RPL is running 159 otherwise. For many networks AODV-RPL could be a replacement for 160 RPL, since it can find better routes at very moderate cost. 161 Consequently, it seems unlikely that RPL would be needed in a network 162 that is running AODV-RPL, even though it would be possible to run 163 both protocols at the same time. 165 2. Terminology 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 169 "OPTIONAL" in this document are to be interpreted as described in BCP 170 14 [RFC2119] [RFC8174] when, and only when, they appear in all 171 capitals, as shown here. 173 AODV-RPL reuses names for messages and data structures, including 174 Rank, DODAG and DODAGID, as defined in RPL [RFC6550]. 176 AODV 177 Ad Hoc On-demand Distance Vector Routing [RFC3561]. 179 ART option 180 AODV-RPL Target option: a target option defined in this document. 182 Asymmetric Route 183 The route from the OrigNode to the TargNode can traverse different 184 nodes than the route from the TargNode to the OrigNode. An 185 asymmetric route may result from the asymmetry of links, such that 186 only one direction of the series of links satisfies the Objective 187 Function during route discovery. 189 Bi-directional Asymmetric Link 190 A link that can be used in both directions but with different link 191 characteristics. 193 DIO 194 DODAG Information Object (defined in [RFC6550]) 196 DODAG RREQ-Instance (or simply RREQ-Instance) 197 RPL Instance built using the DIO with RREQ option; used for 198 transmission of control messages from OrigNode to TargNode, thus 199 enabling data transmission from TargNode to OrigNode. 201 DODAG RREP-Instance (or simply RREP-Instance) 202 RPL Instance built using the DIO with RREP option; used for 203 transmission of control messages from TargNode to OrigNode thus 204 enabling data transmission from OrigNode to TargNode. 206 Downward Direction 207 The direction from the OrigNode to the TargNode. 209 Downward Route 210 A route in the downward direction. 212 hop-by-hop route 213 A route for which each router along the routing path stores 214 routing information about the next hop. A hop-by-hop route is 215 created using RPL's "storing mode". 217 on-demand routing 218 Routing in which a route is established only when needed. 220 OrigNode 221 The IPv6 router (Originating Node) initiating the AODV-RPL route 222 discovery to obtain a route to TargNode. 224 Paired DODAGs 225 Two DODAGs for a single route discovery process between OrigNode 226 and TargNode. 228 P2P 229 Peer-to-Peer -- in other words, not constrained a priori to 230 traverse a common ancestor. 232 reactive routing 233 Same as "on-demand" routing. 235 REJOIN_REENABLE 236 The duration during which a node is prohibited from joining a 237 DODAG with a particular RREQ-InstanceID, after it has left a DODAG 238 with the same RREQ-InstanceID. The default value of 239 REJOIN_REENQBLE is 15 minutes. 241 RREQ-DIO message 242 A DIO message containing the RREQ option. The RPLInstanceID in 243 RREQ-DIO is assigned locally by the OrigNode. The RREQ-DIO 244 message has a secure variant as noted in [RFC6550]. 246 RREQ-InstanceID 247 The RPLInstanceID for the RREQ-Instance. The RREQ-InstanceID is 248 formed as the ordered pair (Orig_RPLInstanceID, OrigNode-IPaddr), 249 where Orig_RPLInstanceID is the local RPLInstanceID allocated by 250 OrigNode, and OrigNode-IPaddr is an IP address of OrigNode. The 251 RREQ-InstanceID uniquely identifies the RREQ-Instance. 253 RREP-DIO message 254 A DIO message containing the RREP option. OrigNode pairs the 255 RPLInstanceID in RREP-DIO to the one in the associated RREQ-DIO 256 message (i.e., the RREQ-InstanceID) as described in Section 6.3.2. 257 The RREP-DIO message has a secure variant as noted in [RFC6550]. 259 RREP-InstanceID 260 The RPLInstanceID for the RREP-Instance. The RREP-InstanceID is 261 formed as the ordered pair (Targ_RPLInstanceID, TargNode-IPaddr), 262 where Targ_RPLInstanceID is the local RPLInstanceID allocated by 263 TargNode, and TargNode-IPaddr is an IP address of TargNode. The 264 RREP-InstanceID uniquely identifies the RREP-Instance. The 265 RPLInstanceID in the RREP message along with the Delta value 266 indicates the associated RREQ-InstanceID. 268 Source routing 269 A mechanism by which the source supplies a vector of addresses 270 towards the destination node along with each data packet 271 [RFC6550]. 273 Symmetric route 274 The upstream and downstream routes traverse the same routers and 275 over the same links. 277 TargNode 278 The IPv6 router (Target Node) for which OrigNode requires a route 279 and initiates Route Discovery within the LLN network. 281 Upward Direction 282 The direction from the TargNode to the OrigNode. 284 Upward Route 285 A route in the upward direction. 287 3. Overview of AODV-RPL 289 With AODV-RPL, routes from OrigNode to TargNode within the LLN 290 network are established "on-demand". In other words, the route 291 discovery mechanism in AODV-RPL is invoked reactively when OrigNode 292 has data for delivery to the TargNode but existing routes do not 293 satisfy the application's requirements. AODV-RPL works without 294 requiring the use of RPL or any other routing protocol. 296 The routes discovered by AODV-RPL are not constrained to traverse a 297 common ancestor. AODV-RPL can enable asymmetric communication paths 298 in networks with bidirectional asymmetric links. For this purpose, 299 AODV-RPL enables discovery of two routes: namely, one from OrigNode 300 to TargNode, and another from TargNode to OrigNode. AODV-RPL also 301 enables discovery of symmetric routes along Paired DODAGs, when 302 symmetric routes are possible (see Section 5). 304 In AODV-RPL, routes are discovered by first forming a temporary DAG 305 rooted at the OrigNode. Paired DODAGs (Instances) are constructed 306 during route formation between the OrigNode and TargNode. The RREQ- 307 Instance is formed by route control messages from OrigNode to 308 TargNode whereas the RREP-Instance is formed by route control 309 messages from TargNode to OrigNode. The route discovered in the 310 RREQ-Instance is used for transmitting data from TargNode to 311 OrigNode, and the route discovered in RREP-Instance is used for 312 transmitting data from OrigNode to TargNode. 314 Intermediate routers join the DODAGs based on the Rank [RFC6550] as 315 calculated from the DIO message. Henceforth in this document, "RREQ- 316 DIO message" means the DIO message from OrigNode toward TargNode, 317 containing the RREQ option as specified in Section 4.1. The RREQ- 318 InstanceID is formed as the ordered pair (Orig_RPLInstanceID, 319 OrigNode-IPaddr), where Orig_RPLInstanceID is the local RPLInstanceID 320 allocated by OrigNode, and OrigNode-IPaddr is the IP address of 321 OrigNode. A node receiving the RREQ-DIO can use the RREQ-InstanceID 322 to identify the proper OF whenever that node receives a data packet 323 with Source Address == OrigNode-IPaddr and IPv6 RPL Option having the 324 RPLInstanceID == Orig_RPLInstanceID along with 'D' == 0. 326 Similarly, "RREP-DIO message" means the DIO message from TargNode 327 toward OrigNode, containing the RREP option as specified in 328 Section 4.2. The RREP-InstanceID is formed as the ordered pair 329 (Targ_RPLInstanceID, TargNode-IPaddr), where Targ_RPLInstanceID is 330 the local RPLInstanceID allocated by TargNode, and TargNode-IPaddr is 331 the IP address of TargNode. A node receiving the RREP-DIO can use 332 the RREP-InstanceID to identify the proper OF whenever that node 333 receives a data packet with Source Address == TargNode-IPaddr and 334 IPv6 RPL Option having the RPLInstanceID == Targ_RPLInstanceID along 335 with 'D' == 0. 337 4. AODV-RPL DIO Options 339 4.1. AODV-RPL RREQ Option 341 OrigNode selects one of its IPv6 addresses and sets it in the DODAGID 342 field of the RREQ-DIO message. The address scope of the selected 343 address must encompass the domain where the route is built (e.g, not 344 link-local). Exactly one RREQ option MUST be present in a RREQ-DIO 345 message, otherwise the message MUST be dropped. 347 0 1 2 3 348 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 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Option Type | Option Length |S|H|X| Compr | L | RankLimit | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Orig SeqNo | | 353 +-+-+-+-+-+-+-+-+ | 354 | | 355 | | 356 | Address Vector (Optional, Variable Length) | 357 | | 358 | | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 Figure 1: Format for AODV-RPL RREQ Option 363 OrigNode supplies the following information in the RREQ option: 365 Option Type 366 TBD2 368 Option Length 369 The length of the option in octets, excluding the Type and Length 370 fields. Variable due to the presence of the address vector and 371 the number of octets elided according to the Compr value. 373 S 374 Symmetric bit indicating a symmetric route from the OrigNode to 375 the router transmitting this RREQ-DIO. See Section 5. 377 H 378 Set to one for a hop-by-hop route. Set to zero for a source 379 route. This flag controls both the downstream route and upstream 380 route. 382 X 383 Reserved; MUST be initialized to zero and ignored upon reception. 385 Compr 386 4-bit unsigned integer. When Compr is nonzero, exactly that 387 number of prefix octets MUST be elided from each address before 388 storing it in the Address Vector. The octets elided are shared 389 with the IPv6 address in the DODAGID. This field is only used in 390 source routing mode (H=0). In hop-by-hop mode (H=1), this field 391 MUST be set to zero and ignored upon reception. 393 L 394 2-bit unsigned integer determining the time duration that a node 395 is able to belong to the RREQ-Instance (a temporary DAG including 396 the OrigNode and the TargNode). Once the time is reached, a node 397 MUST leave the RREQ-Instance and stop sending or receiving any 398 more DIOs for the RREQ-Instance. This naturally depends on the 399 node's ability to keep track of time. Once a node leaves an RREQ- 400 Instance, it MUST NOT rejoin the same RREQ-Instance for at least 401 the time interval specified by the configuration variable 402 REJOIN_REENABLE. L is independent from the route lifetime, which 403 is defined in the DODAG configuration option. 405 * 0x00: No time limit imposed. 406 * 0x01: 16 seconds 407 * 0x02: 64 seconds 408 * 0x03: 256 seconds 410 RankLimit 411 This field indicates the upper limit on the integer portion of the 412 Rank (calculated using the DAGRank() macro defined in [RFC6550]). 413 A value of 0 in this field indicates the limit is infinity. 415 Orig SeqNo 416 Sequence Number of OrigNode. See Section 6.1. 418 Address Vector 419 A vector of IPv6 addresses representing the route that the RREQ- 420 DIO has passed. It is only present when the H bit is set to 0. 421 The prefix of each address is elided according to the Compr field. 423 TargNode can join the RREQ instance at a Rank whose integer portion 424 is less than or equal to the RankLimit. Any other node MUST NOT join 425 a RREQ instance if its own Rank would be equal to or higher than 426 RankLimit. A router MUST discard a received RREQ if the integer part 427 of the advertised Rank equals or exceeds the RankLimit. 429 4.2. AODV-RPL RREP Option 431 TargNode sets one of its IPv6 addresses in the DODAGID field of the 432 RREP-DIO message. The address scope of the selected address must 433 encompass the domain where the route is built (e.g, not link-local). 434 Exactly one RREP option MUST be present in a RREP-DIO message, 435 otherwise the message MUST be dropped. TargNode supplies the 436 following information in the RREP option: 438 0 1 2 3 439 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 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Option Type | Option Length |G|H|X| Compr | L | RankLimit | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Delta |X X| | 444 +-+-+-+-+-+-+-+-+ | 445 | | 446 | | 447 | Address Vector (Optional, Variable Length) | 448 . . 449 . . 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 Figure 2: Format for AODV-RPL RREP option 454 Option Type 455 TBD3 457 Option Length 458 The length of the option in octets, excluding the Type and Length 459 fields. Variable due to the presence of the address vector and 460 the number of octets elided according to the Compr value. 462 G 463 Gratuitous RREP (see Section 7). 465 H 466 The H bit in the RREP option MUST be set to be the same as the H 467 bit in RREQ option. It requests either source routing (H=0) or 468 hop-by-hop (H=1) for the downstream route. 470 X 471 Reserved; MUST be initialized to zero and ignored upon reception. 473 Compr 474 4-bit unsigned integer. Same definition as in RREQ option. 476 L 477 2-bit unsigned integer defined as in RREQ option. The lifetime of 478 the RREP-Instance MUST be no greater than the lifetime of the 479 RREQ-Instance to which it is paired. 481 RankLimit 482 Similarly to RankLimit in the RREQ message, this field indicates 483 the upper limit on the integer portion of the Rank. A value of 0 484 in this field indicates the limit is infinity. 486 Delta 487 6-bit unsigned integer. This field is used to recover the RREQ- 488 InstanceID (see Section 6.3.3); 0 indicates that the RREQ- 489 InstanceID has the same value as the RPLInstanceID of the RREP 490 message. 492 X X 493 Reserved; MUST be initialized to zero and ignored upon reception. 495 Address Vector 496 Only present when the H bit is set to 0. For an asymmetric route, 497 the Address Vector represents the IPv6 addresses of the path 498 through the network the RREP-DIO has passed. For a symmetric 499 route, it is the Address Vector when the RREQ-DIO arrives at the 500 TargNode, unchanged during the transmission to the OrigNode. 502 4.3. AODV-RPL Target Option 504 The AODV-RPL Target (ART) Option is based on the Target Option in 505 core RPL [RFC6550]. The Flags field is replaced by the Destination 506 Sequence Number of the TargNode and the Prefix Length field is 507 reduced to 7 bits so that the value is limited to be no greater than 508 127. 510 A RREQ-DIO message MUST carry at least one ART Option. A RREP-DIO 511 message MUST carry exactly one ART Option. Otherwise, the message 512 MUST be dropped. 514 OrigNode can include multiple TargNode addresses via multiple AODV- 515 RPL Target Options in the RREQ-DIO, for routes that share the same 516 requirement on metrics. This reduces the cost to building only one 517 DODAG. 519 0 1 2 3 520 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 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | Option Type | Option Length | Dest SeqNo |X|Prefix Length| 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | | 525 + | 526 | Target Prefix / Address (Variable Length) | 527 . . 528 . . 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 Figure 3: ART Option format for AODV-RPL 533 Option Type 534 TBD4 536 Option Length 537 Length of the option in octets excluding the Type and Length 538 fields. 540 Dest SeqNo 542 In RREQ-DIO, if nonzero, it is the Sequence Number for the last 543 route that OrigNode stored to the TargNode for which a route is 544 desired. In RREP-DIO, it is the destination sequence number 545 associated to the route. Zero is used if there is no known 546 information about the sequence number of TargNode, and not used 547 otherwise. 549 X 550 A one-bit reserved field. This field MUST be initialized to zero 551 by the sender and MUST be ignored by the receiver. 553 Prefix Length 554 7-bit unsigned integer. Number of valid leading bits in the IPv6 555 Prefix. If Prefix Length is 0, then the value in the Target 556 Prefix / Address field represents an IPv6 address, not a prefix. 558 Target Prefix / Address 559 (variable-length field) An IPv6 destination address or prefix. 560 The Prefix Length field contains the number of valid leading bits 561 in the prefix. The Target Prefix / Address field contains the 562 least number of octets that can represent all of the bits of the 563 Prefix, in other words Ceil(Prefix Length/8) octets. The initial 564 bits in the Target Prefix / Address field preceding the prefix 565 length (if any) MUST be set to zero on transmission and MUST be 566 ignored on receipt. If Prefix Length is zero, the Address field 567 is 128 bits for IPv6 addresses. 569 5. Symmetric and Asymmetric Routes 571 Links are considered symmetric until indication to the contrary is 572 received. In Figure 4 and Figure 5, BR is the Border Router, O is 573 the OrigNode, each R is an intermediate router, and T is the 574 TargNode. In this example, the use of BR is only for illustrative 575 purposes; AODV does not depend on the use of border routers for its 576 operation. If the RREQ-DIO arrives over an interface that is known 577 to be symmetric, and the S bit is set to 1, then it remains as 1, as 578 illustrated in Figure 4. If an intermediate router sends out RREQ- 579 DIO with the S bit set to 1, then each link en route from the 580 OrigNode O to this router has met the requirements of route 581 discovery, and the route can be used symmetrically. 583 BR 584 /----+----\ 585 / | \ 586 / | \ 587 R R R 588 _/ \ | / \ 589 / \ | / \ 590 / \ | / \ 591 R -------- R --- R ----- R -------- R 592 / \ <--S=1--> / \ <--S=1--> / \ 593 <--S=1--> \ / \ / <--S=1--> 594 / \ / \ / \ 595 O ---------- R ------ R------ R ----- R ----------- T 596 / \ / \ / \ / \ 597 / \ / \ / \ / \ 598 / \ / \ / \ / \ 599 R ----- R ----------- R ----- R ----- R ----- R ---- R----- R 601 >---- RREQ-Instance (Control: O-->T; Data: T-->O) -------> 602 <---- RREP-Instance (Control: T-->O; Data: O-->T) -------< 604 Figure 4: AODV-RPL with Symmetric Instances 606 Upon receiving a RREQ-DIO with the S bit set to 1, a node determines 607 whether this link can be used symmetrically, i.e., both directions 608 meet the requirements of data transmission. If the RREQ-DIO arrives 609 over an interface that is not known to be symmetric, or is known to 610 be asymmetric, the S bit is set to 0. If the S bit arrives already 611 set to be '0', it is set to be '0' when the RREQ-DIO is propagated 612 (Figure 5). For an asymmetric route, there is at least one hop which 613 doesn't satisfy the Objective Function. Based on the S bit received 614 in RREQ-DIO, TargNode T determines whether or not the route is 615 symmetric before transmitting the RREP-DIO message upstream towards 616 the OrigNode O. 618 It is beyond the scope of this document to specify the criteria used 619 when determining whether or not each link is symmetric. As an 620 example, intermediate routers can use local information (e.g., bit 621 rate, bandwidth, number of cells used in 6tisch [RFC9030]), a priori 622 knowledge (e.g., link quality according to previous communication) or 623 use averaging techniques as appropriate to the application. Other 624 link metric information can be acquired before AODV-RPL operation, by 625 executing evaluation procedures; for instance test traffic can be 626 generated between nodes of the deployed network. During AODV-RPL 627 operation, OAM techniques for evaluating link state (see [RFC7548], 628 [RFC7276], [co-ioam]) MAY be used (at regular intervals appropriate 629 for the LLN). The evaluation procedures are out of scope for AODV- 630 RPL. 632 Appendix A describes an example method using the upstream Expected 633 Number of Transmissions (ETX) and downstream Received Signal Strength 634 Indicator (RSSI) to estimate whether the link is symmetric in terms 635 of link quality using an averaging technique. 637 BR 638 /----+----\ 639 / | \ 640 / | \ 641 R R R 642 / \ | / \ 643 / \ | / \ 644 / \ | / \ 645 R --------- R --- R ---- R --------- R 646 / \ --S=1--> / \ --S=0--> / \ 647 --S=1--> \ / \ / --S=0--> 648 / \ / \ / \ 649 O ---------- R ------ R------ R ----- R ----------- T 650 / \ / \ / \ / \ 651 / <--S=0-- / \ / \ / <--S=0-- 652 / \ / \ / \ / \ 653 R ----- R ----------- R ----- R ----- R ----- R ---- R----- R 654 <--S=0-- <--S=0-- <--S=0-- <--S=0-- <--S=0-- 656 >---- RREQ-Instance (Control: O-->T; Data: T-->O) -------> 657 <---- RREP-Instance (Control: T-->O; Data: O-->T) -------< 659 Figure 5: AODV-RPL with Asymmetric Paired Instances 661 As illustrated in Figure 5, an intermediate router determines the S 662 bit value that the RREQ-DIO should carry using link asymmetry 663 detection methods as discussed earlier in this section. In many 664 cases the intermediate router has already made the link asymmetry 665 decision by the time RREQ-DIO arrives. 667 6. AODV-RPL Operation 669 6.1. Route Request Generation 671 The route discovery process is initiated when an application at the 672 OrigNode has data to be transmitted to the TargNode, but does not 673 have a route that satisfies the Objective Function for the target of 674 the application's data. In this case, the OrigNode builds a local 675 RPLInstance and a DODAG rooted at itself. Then it transmits a DIO 676 message containing exactly one RREQ option (see Section 4.1) to 677 multicast group all-AODV-RPL-nodes. The RREQ-DIO MUST contain at 678 least one ART Option (see Section 4.3), which indicates the TargNode. 679 The S bit in RREQ-DIO sent out by the OrigNode is set to 1. 681 Each node maintains a sequence number; the operation is specified in 682 section 7.2 of [RFC6550]. When the OrigNode initiates a route 683 discovery process, it MUST increase its own sequence number to avoid 684 conflicts with previously established routes. The sequence number is 685 carried in the Orig SeqNo field of the RREQ option. 687 The Target Prefix / Address in the ART Option can be a unicast IPv6 688 address or a prefix. The OrigNode can initiate the route discovery 689 process for multiple targets simultaneously by including multiple ART 690 Options. Within a RREQ-DIO the Objective Function for the routes to 691 different TargNodes MUST be the same. 693 OrigNode can maintain different RPLInstances to discover routes with 694 different requirements to the same targets. Using the RPLInstanceID 695 pairing mechanism (see Section 6.3.3), route replies (RREP-DIOs) for 696 different RPLInstances can be generated. 698 The transmission of RREQ-DIO obeys the Trickle timer [RFC6206]. If 699 the duration specified by the L field has elapsed, the OrigNode MUST 700 leave the DODAG and stop sending RREQ-DIOs in the related 701 RPLInstance. OrigNode needs to set L field such that the DODAG will 702 not prematurely timeout during data transfer with the TargNode. For 703 setting this value, it has to consider factors such as Trickle timer, 704 TargNode hop distance, network size, link behavior, expected data 705 usage time, and so on. 707 6.2. Receiving and Forwarding RREQ messages 709 6.2.1. Step 1: RREQ reception and evaluation 711 When a router X receives a RREQ message over a link from a neighbor 712 Y, X first determines whether or not the RREQ is valid. If so, X 713 then determines whether or not it has sufficient resources available 714 to maintain the state needed to process an eventual RREP if the RREP 715 were to be received. If not, then X MUST drop the packet and 716 discontinue processing of the RREQ. Otherwise, X next determines 717 whether the RREQ advertises a usable route to OrigNode, by checking 718 whether the link to Y can be used to tramsmit packets to OrigNode. 720 When H=0 in the incoming RREQ, the router MUST drop the RREQ-DIO if 721 one of its addresses is present in the Address Vector. When H=1 in 722 the incoming RREQ, the router MUST drop the RREQ message if Orig 723 SeqNo field of the RREQ is older than the SeqNo value that X has 724 stored for a route to OrigNode. Otherwise, the router determines 725 whether to propagate the RREQ-DIO. It does this by determining 726 whether or not a route to OrigNode using the upstream direction of 727 the incoming link satisfies the Objective Function (OF). In order to 728 evaluate the OF, the router first determines the maximum useful rank 729 (MaxUsefulRank). If the router has previously joined the RREQ- 730 Instance associated with the RREQ-DIO, then MaxUsefulRank is set to 731 be the Rank value that was stored when the router processed the best 732 previous RREQ for the DODAG with the given RREQ-Instance. Otherwise, 733 MaxUsefulRank is set to be RankLimit. If OF cannot be satisfied 734 (i.e., the Rank evaluates to a value greater than MaxUsefulRank) the 735 RREQ-DIO MUST be dropped, and the following steps are not processed. 736 Otherwise, the router MUST join the RREQ-Instance and prepare to 737 propagate the RREQ-DIO, as follows. The upstream neighbor router 738 that transmitted the received RREQ-DIO is selected as the preferred 739 parent. 741 6.2.2. Step 2: TargNode and Intermediate Router determination 743 After determining that a received RREQ provides a usable route to 744 OrigNode, a router determines whether it is a TargNode, or a possible 745 intermediate router between OrigNode and a TargNode, or both. The 746 router is a TargNode if it finds one of its own addresses in a Target 747 Option in the RREQ. After possibly propagating the RREQ according to 748 the procedures in Steps 3, 4, and 5, the TargNode generates a RREP as 749 specified in Section 6.3. 751 If the OrigNode tries to reach multiple TargNodes in a single RREQ- 752 Instance, one of the TargNodes can be an intermediate router to other 753 TargNodes. In this case, before transmitting the RREQ-DIO to 754 multicast group all-AODV-RPL-nodes, a TargNode MUST delete the Target 755 Option encapsulating its own address, so that downstream routers with 756 higher Rank values do not try to create a route to this TargNode. 758 An intermediate router could receive several RREQ-DIOs from routers 759 with lower Rank values in the same RREQ-Instance with different lists 760 of Target Options. For the purposes of determining the intersection 761 with previous incoming RREQ-DIOs, the intermediate router maintains a 762 record of the targets that have been requested for a given RREQ- 763 Instance. An incoming RREQ-DIO message having multiple ART Options 764 coming from a router with higher Rank than the Rank of the stored 765 targets is ignored. When transmitting the RREQ-DIO, the intersection 766 of all received lists MUST be included if it is nonempty after 767 TargNode has deleted the Target Option encapsulating its own address. 768 If the intersection is empty, it means that all the targets have been 769 reached, and the router MUST NOT transmit any RREQ-DIO. Otherwise it 770 proceeds to Section 6.2.3. 772 For example, suppose two RREQ-DIOs are received with the same 773 RPLInstance and OrigNode. Suppose further that the first RREQ has 774 (T1, T2) as the targets, and the second one has (T2, T4) as targets. 775 Then only T2 needs to be included in the generated RREQ-DIO. 777 6.2.3. Step 3: Intermediate Router RREQ processing 779 The intermediate router establishes itself as a viable node for a 780 route to OrigNode as follows. If the H bit is set to 1, for a hop- 781 by-hop route, then the router MUST build or update its upward route 782 entry towards OrigNode, which includes at least the following items: 783 Source Address, RPLInstanceID, Destination Address, Next Hop, 784 Lifetime, and Sequence Number. The Destination Address and the 785 RPLInstanceID respectively can be learned from the DODAGID and the 786 RPLInstanceID of the RREQ-DIO. The Source Address is the address 787 used by the router to send data to the Next Hop, i.e., the preferred 788 parent. The lifetime is set according to DODAG configuration (not 789 the L field) and can be extended when the route is actually used. 790 The sequence number represents the freshness of the route entry; it 791 is copied from the Orig SeqNo field of the RREQ option. A route 792 entry with the same source and destination address, same 793 RPLInstanceID, but stale sequence number, MUST be deleted. 795 6.2.4. Step 4: Symmetric Route Processing at an Intermediate Router 797 If the S bit of the incoming RREQ-DIO is 0, then the route cannot be 798 symmetric, and the S bit of the RREQ-DIO to be transmitted is set to 799 0. Otherwise, the router MUST determine whether the downward (i.e., 800 towards the TargNode) direction of the incoming link satisfies the 801 OF. If so, the S bit of the RREQ-DIO to be transmitted is set to 1. 802 Otherwise the S bit of the RREQ-DIO to be transmitted is set to 0. 804 When a router joins the RREQ-Instance, it also associates within its 805 data structure for the RREQ-Instance the information about whether or 806 not the RREQ-DIO to be transmitted has the S-bit set to 1. This 807 information associated to RREQ-Instance is known as the S-bit of the 808 RREQ-Instance. It will be used later during the RREP-DIO message 809 processing Section 6.3.2. 811 Suppose a router has joined the RREQ-Instance, and H=0, and the S-bit 812 of the RREQ-Instance is set to 1. In this case, the router MAY 813 optionally associate to the RREQ-Instance, the Address Vector of the 814 symmetric route back to OrigNode. This is useful if the router later 815 receives an RREP-DIO that is paired with the RREQ-Instance. If the 816 router does NOT associate the Address Vector, then it has to rely on 817 multicast for the RREP. This can impose a substantial performance 818 penalty. 820 6.2.5. Step 5: RREQ propagation at an Intermediate Router 822 If the router is an intermediate router, then it transmits the RREQ- 823 DIO to the multicast group all-AODV-RPL-nodes; if the H bit is set to 824 0, the intermediate router MUST append the address of its interface 825 receiving the RREQ-DIO into the address vector. If, in addition, the 826 address of the router's transmitting the RREQ-DIO is not the same as 827 the address of the interface receiving the RREQ-DIO, the router MUST 828 also append the transmitting interface address into the address 829 vector. 831 6.2.6. Step 6: RREQ reception at TargNode 833 If the router is a TargNode and was already associated with the RREQ- 834 Instance, it takes no further action and does not send an RREP-DIO. 835 If TargNode is not already associated with the RREQ-Instance, it 836 prepares and transmits a RREP-DIO, possibly after waiting for 837 RREP_WAIT_TIME, as detailed in (Section 6.3). 839 6.3. Generating Route Reply (RREP) at TargNode 841 When a TargNode receives a RREQ message over a link from a neighbor 842 Y, TargNode first follows the procedures in Section 6.2. If the link 843 to Y can be used to tramsmit packets to OrigNode, TargNode generates 844 a RREP according to the steps below. Otherwise TargNode drops the 845 RREQ and does not generate a RREP. 847 If the L field is not 0, the TargNode MAY delay transmitting the 848 RREP-DIO for duration RREP_WAIT_TIME to await a route with a lower 849 Rank. The value of RREP_WAIT_TIME is set by default to 1/4 of the 850 duration determined by the L field. For L == 0, RREP_WAIT_TIME is 851 set by default to 0. Depending upon the application, RREP_WAIT_TIME 852 may be set to other values. Smaller values enable quicker formation 853 for the P2P route. Larger values enable formation of P2P routes with 854 better Rank values. 856 The address of the OrigNode MUST be encapsulated in the ART Option 857 and included in this RREP-DIO message along with the SeqNo of 858 TargNode. 860 6.3.1. RREP-DIO for Symmetric route 862 If the RREQ-Instance corresponding to the RREQ-DIO that arrived at 863 TargNode has the S bit set to 1, there is a symmetric route both of 864 whose directions satisfy the Objective Function. Other RREQ-DIOs 865 might later provide better upward routes. The method of selection 866 between a qualified symmetric route and an asymmetric route that 867 might have better performance is implementation-specific and out of 868 scope. 870 For a symmetric route, the RREP-DIO message is unicast to the next 871 hop according to the Address Vector (H=0) or the route entry (H=1); 872 the DODAG in RREP-Instance does not need to be built. The 873 RPLInstanceID in the RREP-Instance is paired as defined in 874 Section 6.3.3. In case the H bit is set to 0, the address vector 875 from the RREQ-DIO MUST be included in the RREP-DIO. 877 6.3.2. RREP-DIO for Asymmetric Route 879 When a RREQ-DIO arrives at a TargNode with the S bit set to 0, the 880 TargNode MUST build a DODAG in the RREP-Instance corresponding to the 881 RREQ-DIO rooted at itself, in order to provide OrigNode with a 882 downstream route to the TargNode. The RREP-DIO message is 883 transmitted to multicast group all-AODV-RPL-nodes. 885 6.3.3. RPLInstanceID Pairing 887 Since the RPLInstanceID is assigned locally (i.e., there is no 888 coordination between routers in the assignment of RPLInstanceID), the 889 tuple (OrigNode, TargNode, RPLInstanceID) is needed to uniquely 890 identify a discovered route. It is possible that multiple route 891 discoveries with dissimilar Objective Functions are initiated 892 simultaneously. Thus between the same pair of OrigNode and TargNode, 893 there can be multiple AODV-RPL route discovery instances. So that 894 OrigNode and Targnode can avoid any mismatch, they MUST pair the 895 RREQ-Instance and the RREP-Instance in the same route discovery by 896 using the RPLInstanceID. 898 When preparing the RREP-DIO, a TargNode could find the RPLInstanceID 899 candidate for the RREP-Instance is already occupied by another RPL 900 Instance from an earlier route discovery operation which is still 901 active. This unlikely case might happen if two distinct OrigNodes 902 need routes to the same TargNode, and they happen to use the same 903 RPLInstanceID for RREQ-Instance. In such cases, the RPLInstanceID of 904 an already active RREP-Instance MUST NOT be used again for assigning 905 RPLInstanceID for the later RREP-Instance. If the same RPLInstanceID 906 were re-used for two distinct DODAGs originated with the same DODAGID 907 (TargNode address), intermediate routers could not distinguish 908 between these DODAGs (and their associated Objective Functions). 909 Instead, the RPLInstanceID MUST be replaced by another value so that 910 the two RREP-instances can be distinguished. In the RREP-DIO option, 911 the Delta field of the RREP-DIO message (Figure 2) indicates the 912 increment to be applied to the pre-existing RPLInstanceID to obtain 913 the value of the RPLInstanceID that is used in the RREP-DIO message. 914 When the new RPLInstanceID after incrementation exceeds 255, it rolls 915 over starting at 0. For example, if the RREQ-InstanceID is 252, and 916 incremented by 6, the new RPLInstanceID will be 2. Related 917 operations can be found in Section 6.4. RPLInstanceID collisions do 918 not occur across RREQ-DIOs; the DODAGID equals the OrigNode address 919 and is sufficient to disambiguate between DODAGs. 921 6.4. Receiving and Forwarding Route Reply 923 Upon receiving a RREP-DIO, a router which already belongs to the 924 RREP-Instance SHOULD drop the RREP-DIO. Otherwise the router 925 performs the steps in the following subsections. 927 6.4.1. Step 1: Receiving and Evaluation 929 If the Objective Function is not satisfied, the router MUST NOT join 930 the DODAG; the router MUST discard the RREP-DIO, and does not execute 931 the remaining steps in this section. An Intermediate Router MUST 932 discard a RREP if one of its addresses is present in the Address 933 Vector, and does not execute the remaining steps in this section. 935 If the S bit of the associated RREQ-Instance is set to 1, the router 936 MUST proceed to Section 6.4.2. 938 If the S-bit of the RREQ-Instance is set to 0, the router MUST 939 determine whether the downward direction of the link (towards the 940 TargNode) over which the RREP-DIO is received satisfies the Objective 941 Function, and the router's Rank would not exceed the RankLimit. If 942 so, the router joins the DODAG of the RREP-Instance. The router that 943 transmitted the received RREP-DIO is selected as the preferred 944 parent. Afterwards, other RREP-DIO messages can be received. 946 6.4.2. Step 2: OrigNode or Intermediate Router 948 The router updates its stored value of the TargNode's sequence number 949 according to the value provided in the ART option. The router next 950 checks if one of its addresses is included in the ART Option. If so, 951 this router is the OrigNode of the route discovery. Otherwise, it is 952 an intermediate router. 954 6.4.3. Step 3: Build Route to TargNode 956 If the H bit is set to 1, then the router (OrigNode or intermediate) 957 MUST build a downward route entry towards TargNode which includes at 958 least the following items: OrigNode Address, RPLInstanceID, TargNode 959 Address as destination, Next Hop, Lifetime and Sequence Number. For 960 a symmetric route, the Next Hop in the route entry is the router from 961 which the RREP-DIO is received. For an asymmetric route, the Next 962 Hop is the preferred parent in the DODAG of RREP-Instance. The 963 RPLInstanceID in the route entry MUST be the RREQ-InstanceID (i.e., 964 after subtracting the Delta field value from the value of the 965 RPLInstanceID). The source address is learned from the ART Option, 966 and the destination address is learned from the DODAGID. The 967 lifetime is set according to DODAG configuration (i.e., not the L 968 field) and can be extended when the route is actually used. The 969 sequence number represents the freshness of the route entry, and is 970 copied from the Dest SeqNo field of the ART option of the RREP-DIO. 971 A route entry with same source and destination address, same 972 RPLInstanceID, but stale sequence number (i.e., incoming sequence 973 number is less than the currently stored sequence number of the route 974 entry), MUST be deleted. 976 6.4.4. Step 4: RREP Propagation 978 If the receiver is the OrigNode, it can start transmitting the 979 application data to TargNode along the path as provided in RREP- 980 Instance, and processing for the RREP-DIO is complete. Otherwise, 981 the RREP will be propagated towards OrigNode. If H=0, the 982 intermediate router MUST include the address of the interface 983 receiving the RREP-DIO into the address vector. If H=1, according to 984 the last step the intermediate router has set up a route entry for 985 TargNode. If the intermediate router has a route to OrigNode, it 986 uses that route to unicast the RREP-DIO to OrigNode. Otherwise, in 987 case of a symmetric route, the RREP-DIO message is unicast to the 988 Next Hop according to the address vector in the RREP-DIO (H=0) or the 989 local route entry (H=1). Otherwise, in case of an asymmetric route, 990 the intermediate router transmits the RREP-DIO to multicast group 991 all-AODV-RPL-nodes. The RPLInstanceID in the transmitted RREP-DIO is 992 the same as the value in the received RREP-DIO. 994 7. Gratuitous RREP 996 In some cases, an Intermediate router that receives a RREQ-DIO 997 message MAY unicast a "Gratuitous" RREP-DIO message back to OrigNode 998 before continuing the transmission of the RREQ-DIO towards TargNode. 999 The Gratuitous RREP allows the OrigNode to start transmitting data to 1000 TargNode sooner. The G bit of the RREP option is provided to 1001 distinguish the Gratuitous RREP-DIO (G=1) sent by the Intermediate 1002 router from the RREP-DIO sent by TargNode (G=0). 1004 The gratuitous RREP-DIO MAY be sent out when the Intermediate router 1005 receives a RREQ-DIO for a TargNode, and the router has a pair of 1006 downward and upward routes to the TargNode which also satisfy the 1007 Objective Function and for which the destination sequence number is 1008 at least as large as the sequence number in the RREQ-DIO message. 1009 After unicasting the Gratuitous RREP to the OrigNode, the 1010 Intermediate router then unicasts the RREQ towards TargNode, so that 1011 TargNode will have the advertised route towards OrigNode along with 1012 the RREQ-InstanceID for the RREQ-Instance. 1014 In case of source routing, the intermediate router MUST include the 1015 address vector between the OrigNode and itself in the Gratuitous 1016 RREP. It also includes the address vector in the unicast RREQ-DIO 1017 towards TargNode. Upon reception of the unicast RREQ-DIO, the 1018 TargNode will have a route address vector from itself to the 1019 OrigNode. Then the router MUST include the address vector from the 1020 TargNode to the router itself in the gratuitous RREP-DIO to be 1021 transmitted. 1023 For establishing hop-by-hop routes, the intermediate router MUST 1024 unicast the received RREQ-DIO to the Next Hop on the route. The Next 1025 Hop router along the route MUST build new route entries with the 1026 related RPLInstanceID and DODAGID in the downward direction. This 1027 process repeats at each node until the RREQ-DIO arrives at the 1028 TargNode. Then the TargNode and each router along the path towards 1029 OrigNode MUST unicast the RREP-DIO hop-by-hop towards OrigNode as 1030 specified in Section 6.3. 1032 8. Operation of Trickle Timer 1034 RREQ-Instance/RREP-Instance multicast uses trickle timer operations 1035 [RFC6206] to control RREQ-DIO and RREP-DIO transmissions. The 1036 Trickle control of these DIO transmissions follows the procedures 1037 described in the Section 8.3 of [RFC6550] entitled "DIO 1038 Transmission". If the route is symmetric, the RREP DIO does not need 1039 the Trickle timer mechanism. 1041 9. IANA Considerations 1043 Note to RFC editor: 1045 The sentence "The parenthesized numbers are only suggestions." is to 1046 be removed prior publication. 1048 A Subregistry in this section refers to a named sub-registry of the 1049 "Routing Protocol for Low Power and Lossy Networks (RPL)" registry. 1051 AODV-RPL uses the "P2P Route Discovery Mode of Operation" (MOP == 4) 1052 with new Options as specified in this document. Please cite AODV-RPL 1053 and this document as one of the protocols using MOP 4. 1055 IANA is asked to assign three new AODV-RPL options "RREQ", "RREP" and 1056 "ART", as described in Figure 6 from the "RPL Control Message 1057 Options" Subregistry. The parenthesized numbers are only 1058 suggestions. 1060 +-------------+------------------------+---------------+ 1061 | Value | Meaning | Reference | 1062 +-------------+------------------------+---------------+ 1063 | TBD2 (0x0B) | RREQ Option | This document | 1064 +-------------+------------------------+---------------+ 1065 | TBD3 (0x0C) | RREP Option | This document | 1066 +-------------+------------------------+---------------+ 1067 | TBD4 (0x0D) | ART Option | This document | 1068 +-------------+------------------------+---------------+ 1070 Figure 6: AODV-RPL Options 1072 IANA is requested to allocate a new permanent multicast address with 1073 link-local scope called all-AODV-RPL-nodes for nodes implementing 1074 this specification. 1076 10. Security Considerations 1078 The security considerations for the operation of AODV-RPL are similar 1079 to those for the operation of RPL (as described in Section 19 of the 1080 RPL specification [RFC6550]). Sections 6.1 and 10 of [RFC6550] 1081 describe RPL's optional security framework, which AODV-RPL relies on 1082 to provide data confidentiality, authentication, replay protection, 1083 and delay protection services. Additional analysis for the security 1084 threats to RPL can be found in [RFC7416]. 1086 A router can join a temporary DAG created for a secure AODV-RPL route 1087 discovery only if it can support the security configuration in use 1088 (see Section 6.1 of [RFC6550]), which also specifies the key in use. 1089 It does not matter whether the key is preinstalled or dynamically 1090 acquired. The router must have the key in use before it can join the 1091 DAG being created for secure route discovery. 1093 If a rogue router knows the key for the security configuration in 1094 use, it can join the secure AODV-RPL route discovery and cause 1095 various types of damage. Such a rogue router could advertise false 1096 information in its DIOs in order to include itself in the discovered 1097 route(s). It could generate bogus RREQ-DIO, and RREP-DIO messages 1098 carrying bad routes or maliciously modify genuine RREP-DIO messages 1099 it receives. A rogue router acting as the OrigNode could launch 1100 denial-of-service attacks against the LLN deployment by initiating 1101 fake AODV-RPL route discoveries. When rogue routers might be 1102 present, RPL's preinstalled mode of operation, where the key to use 1103 for route discovery is preinstalled, SHOULD be used. 1105 When a RREQ-DIO message uses the source routing option by setting the 1106 H bit to 0, a rogue router may populate the Address Vector field with 1107 a set of addresses that may result in the RREP-DIO traveling in a 1108 routing loop. 1110 If a rogue router is able to forge a gratuitous RREP, it could mount 1111 denial-of-service attacks. 1113 11. Acknowledgements 1115 The authors thank Pascal Thubert, Rahul Jadhav, and Lijo Thomas for 1116 their support and valuable inputs. The authors specially thank 1117 Lavanya H.M for implementing AODV-RPl in Contiki and conducting 1118 extensive simulation studies. 1120 The authors would like to acknowledge the review, feedback and 1121 comments from the following people, in alphabetical order: Roman 1122 Danyliw, Lars Eggert, Benjamin Kaduk, Tero Kivinen, Erik Kline, 1123 Murray Kucherawy, Warren Kumari, Francesca Palombini, Alvaro Retana, 1124 Ines Robles, John Scudder, Meral Shirazipour, Peter Van der Stok, 1125 Eric Vyncke, and Robert Wilton. 1127 12. References 1129 12.1. Normative References 1131 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1132 Requirement Levels", BCP 14, RFC 2119, 1133 DOI 10.17487/RFC2119, March 1997, 1134 . 1136 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 1137 "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, 1138 March 2011, . 1140 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1141 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1142 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1143 Low-Power and Lossy Networks", RFC 6550, 1144 DOI 10.17487/RFC6550, March 2012, 1145 . 1147 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 1148 and D. Barthel, "Routing Metrics Used for Path Calculation 1149 in Low-Power and Lossy Networks", RFC 6551, 1150 DOI 10.17487/RFC6551, March 2012, 1151 . 1153 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1154 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1155 May 2017, . 1157 12.2. Informative References 1159 [co-ioam] Rashmi Ballamajalu, Anand, S.V.R., and Malati Hegde, "Co- 1160 iOAM: In-situ Telemetry Metadata Transport for Resource 1161 Constrained Networks within IETF Standards Framework", 1162 2018 10th International Conference on Communication 1163 Systems & Networks (COMSNETS) pp.573-576, January 2018. 1165 [contiki] Contiki contributors, "The Contiki Open Source OS for the 1166 Internet of Things (Contiki Version 2.7)", November 2013, 1167 . 1169 [Contiki-ng] 1170 Contiki-NG contributors, "Contiki-NG: The OS for Next 1171 Generation IoT Devices (Contiki-NG Version 4.6)", December 1172 2020, . 1174 [cooja] Contiki/Cooja contributors, "Cooja Simulator for Wireless 1175 Sensor Networks (Contiki/Cooja Version 2.7)", November 1176 2013, . 1179 [empirical-study] 1180 Prasant Misra, Nadeem Ahmed, and Sanjay Jha, "An empirical 1181 study of asymmetry in low-power wireless links", IEEE 1182 Communications Magazine (Volume: 50, Issue: 7), July 2012. 1184 [Link_Asymmetry] 1185 Lifeng Sang, Anish Arora, and Hongwei Zhang, "On Link 1186 Asymmetry and One-way Estimation in Wireless Sensor 1187 Networks", ACM Transactions on Sensor Networks, Volume 6 1188 Issue 2 pp.1-25, February 2010, 1189 . 1191 [low-power-wireless] 1192 Kannan Srinivasan, Prabal Dutta, Arsalan Tavakoli, and 1193 Philip Levis, "An empirical study of low-power wireless", 1194 ACM Transactions on Sensor Networks (Volume 6 Issue 2 1195 pp.1-49), February 2010, 1196 . 1198 [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- 1199 Demand Distance Vector (AODV) Routing", RFC 3561, 1200 DOI 10.17487/RFC3561, July 2003, 1201 . 1203 [RFC6687] Tripathi, J., Ed., de Oliveira, J., Ed., and JP. Vasseur, 1204 Ed., "Performance Evaluation of the Routing Protocol for 1205 Low-Power and Lossy Networks (RPL)", RFC 6687, 1206 DOI 10.17487/RFC6687, October 2012, 1207 . 1209 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and 1210 J. Martocci, "Reactive Discovery of Point-to-Point Routes 1211 in Low-Power and Lossy Networks", RFC 6997, 1212 DOI 10.17487/RFC6997, August 2013, 1213 . 1215 [RFC6998] Goyal, M., Ed., Baccelli, E., Brandt, A., and J. Martocci, 1216 "A Mechanism to Measure the Routing Metrics along a Point- 1217 to-Point Route in a Low-Power and Lossy Network", 1218 RFC 6998, DOI 10.17487/RFC6998, August 2013, 1219 . 1221 [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. 1222 Weingarten, "An Overview of Operations, Administration, 1223 and Maintenance (OAM) Tools", RFC 7276, 1224 DOI 10.17487/RFC7276, June 2014, 1225 . 1227 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 1228 and M. Richardson, Ed., "A Security Threat Analysis for 1229 the Routing Protocol for Low-Power and Lossy Networks 1230 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 1231 . 1233 [RFC7548] Ersue, M., Ed., Romascanu, D., Schoenwaelder, J., and A. 1234 Sehgal, "Management of Networks with Constrained Devices: 1235 Use Cases", RFC 7548, DOI 10.17487/RFC7548, May 2015, 1236 . 1238 [RFC9010] Thubert, P., Ed. and M. Richardson, "Routing for RPL 1239 (Routing Protocol for Low-Power and Lossy Networks) 1240 Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021, 1241 . 1243 [RFC9030] Thubert, P., Ed., "An Architecture for IPv6 over the Time- 1244 Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)", 1245 RFC 9030, DOI 10.17487/RFC9030, May 2021, 1246 . 1248 Appendix A. Example: Using ETX/RSSI Values to determine value of S bit 1250 The combination of Received Signal Strength Indication(downstream) 1251 (RSSI) and Expected Number of Transmissions(upstream) (ETX) has been 1252 tested to determine whether a link is symmetric or asymmetric at 1253 intermediate routers. We present two methods to obtain an ETX value 1254 from RSSI measurement. 1256 Method 1: In the first method, we constructed a table measuring RSSI 1257 vs ETX using the Cooja simulation [cooja] setup in the Contiki OS 1258 environment[contiki]. We used Contiki-2.7 running 6LoWPAN/RPL 1259 protocol stack for the simulations. For approximating the number 1260 of packet drops based on the RSSI values, we implemented simple 1261 logic that drops transmitted packets with certain pre-defined 1262 ratios before handing over the packets to the receiver. The 1263 packet drop ratio is implemented as a table lookup of RSSI ranges 1264 mapping to different packet drop ratios with lower RSSI ranges 1265 resulting in higher values. While this table has been defined for 1266 the purpose of capturing the overall link behavior, it is highly 1267 recommended to conduct physical radio measurement experiments, in 1268 general. By keeping the receiving node at different distances, we 1269 let the packets experience different packet drops as per the 1270 described method. The ETX value computation is done by another 1271 module which is part of RPL Objective Function implementation. 1272 Since ETX value is reflective of the extent of packet drops, it 1273 allowed us to prepare a useful ETX vs RSSI table. ETX versus RSSI 1274 values obtained in this way may be used as explained below: 1276 Source---------->NodeA---------->NodeB------->Destination 1278 Figure 7: Communication link from Source to Destination 1280 +=========================+========================================+ 1281 | RSSI at NodeA for NodeB | Expected ETX at NodeA for NodeB->NodeA | 1282 +=========================+========================================+ 1283 | > -60 | 150 | 1284 +-------------------------+----------------------------------------+ 1285 | -70 to -60 | 192 | 1286 +-------------------------+----------------------------------------+ 1287 | -80 to -70 | 226 | 1288 +-------------------------+----------------------------------------+ 1289 | -90 to -80 | 662 | 1290 +-------------------------+----------------------------------------+ 1291 | -100 to -90 | 3840 | 1292 +-------------------------+----------------------------------------+ 1294 Table 1: Selection of S bit based on Expected ETX value 1296 Method 2: One could also make use of the function 1297 guess_etx_from_rssi() defined in the 6LoWPAN/RPL protocol stack of 1298 Contiki-ng OS [Contiki-ng] to obtain RSSI-ETX mapping. This 1299 function outputs ETX value ranging between 128 and 3840 for -60 <= 1300 rssi <= -89. The function description is beyond the scope of this 1301 document. 1303 We tested the operations in this specification by making the 1304 following experiment, using the above parameters. In our experiment, 1305 a communication link is considered as symmetric if the ETX value of 1306 NodeA->NodeB and NodeB->NodeA (see Figure 7) are within, say, a 1:3 1307 ratio. This ratio should be understood as determining the link's 1308 symmetric/asymmetric nature. NodeA can typically know the ETX value 1309 in the direction of NodeA -> NodeB but it has no direct way of 1310 knowing the value of ETX from NodeB->NodeA. Using physical testbed 1311 experiments and realistic wireless channel propagation models, one 1312 can determine a relationship between RSSI and ETX representable as an 1313 expression or a mapping table. Such a relationship in turn can be 1314 used to estimate ETX value at nodeA for link NodeB--->NodeA from the 1315 received RSSI from NodeB. Whenever nodeA determines that the link 1316 towards the nodeB is bi-directional asymmetric then the S bit is set 1317 to 0. Afterwards, the link from NodeA to Destination remains 1318 designated as asymmetric and the S bit remains set to 0. 1320 Determination of asymmetry versus bidirectionality remains a topic of 1321 lively discussion in the IETF. 1323 Appendix B. Changelog 1325 Note to the RFC Editor: please remove this section before 1326 publication. 1328 B.1. Changes from version 13 to version 14 1330 * Provided more details about scenarios naturally supporting the 1331 choice of AODV-RPL as a routing protocol 1333 * Added new informative references [RFC6687], [RFC9010]) that 1334 describe the value provided by peer-to-peer routing. 1336 * Requested IANA to allocate a new multicast group to enable clean 1337 separation of AODV-RPL operation from previous routing protocols 1338 in the RPL family. 1340 * Cited [RFC6550] as the origination of the definition of DIO 1342 * Defined "hop-by-hop route" as a route created using RPL's storing 1343 mode. 1345 * Defined new configuration variable REJOIN_REENABLE. 1347 * Improved definition for RREQ-InstanceID. Created analogous 1348 definition for RREP-InstanceID=(RPLInstanceID, TargNode_IPaddr) 1350 * Improved definition of source routing 1352 * Clarified that the Border Router (BR) in Figure 4 does not imply 1353 that AODV does not a require a BR as a protocol entity. 1355 * Provided more guidelines about factors to be considered by 1356 OrigNode when selecting a value for the 'L' field. 1358 * Described the disadvantage of not keeping track of the Address 1359 Vector in the RREQ-Instance. 1361 * Specified that in non-storing mode an intermediate node has to 1362 record the IP addresses of both incoming and outgoing interfaces 1363 into the Address Vector, when those interfaces have different IP 1364 addresses. 1366 * Added three informative references to describe relevant details 1367 about evaluating link assymetry. 1369 * Clarified details about Gratuitous RREP. 1371 B.2. Changes from version 12 to version 13 1373 * Changed name of "Shift" field to be the "Delta" field. 1375 * Specified that if a node does not have resources, it MUST drop the 1376 RREQ. 1378 * Changed name of MaxUseRank to MaxUsefulRank. 1380 * Revised a sentence that was not clear about when a TargNode can 1381 delay transmission of the RREP in response to a RREQ. 1383 * Provided advice about running AODV-RPL at same time as P2P-RPL or 1384 native RPL. 1386 * Small reorganization and enlargement of the description of Trickle 1387 time operation in Section 8. 1389 * Added definition for "RREQ-InstanceID" to Terminology section. 1391 * Specified that once a node leaves an RREQ-Instance, it MUST NOT 1392 rejoin the same RREQ-Instance. 1394 B.3. Changes from version 11 to version 12 1396 * Defined RREP_WAIT_TIME for asymmetric as well as symmetric 1397 handling of RREP-DIO. 1399 * Clarifed link-local multicast transmission to use link-local 1400 multicast group all-RPL nodes. 1402 * Identified some security threats more explicitly. 1404 * Specified that the pairing between RREQ-DIO and RREP-DIO happens 1405 at OrigNode and TargNode. Intermediate routers do not necessarily 1406 maintain the pairing. 1408 * When RREQ-DIO is received with H=0 and S=1, specified that 1409 intermediate routers MAY store symmetric Address Vector 1410 information for possible use when a matchine RREP-DIO is received. 1412 * Specified that AODV-RPL uses the "P2P Route Discovery Mode of 1413 Operation" (MOP == 4), instead of requesting the allocation of a 1414 new MOP. Clarified that there is no conflict with [RFC6997]. 1416 * Fixed several important typos and improved language in numerous 1417 places. 1419 * Reorganized the steps in the specification for handling RREQ and 1420 RREP at an intermediate router, to more closely follow the order 1421 of processing actions to be taken by the router. 1423 B.4. Changes from version 10 to version 11 1425 * Numerous editorial improvements. 1427 * Replace Floor((7+(Prefix Length))/8) by Ceil(Prefix Length/8) for 1428 simplicity and ease of understanding. 1430 * Use "L field" instead of "L bit" since L is a two-bit field. 1432 * Improved the procedures in section 6.2.1. 1434 * Define the S bit of the data structure a router uses to represent 1435 whether or not the RREQ instance is for a symmetric or an 1436 asymmetric route. This replaces text in the document that was a 1437 holdover from earlier versions in which the RREP had an S bit for 1438 that purpose. 1440 * Quote terminology from AODV that has been identified as possibly 1441 originating in language reflecting various kinds of bias against 1442 certain cultures. 1444 * Clarified the relationship of AODV-RPL to RPL. 1446 * Eliminated the "Point-to-Point" terminology to avoid suggesting 1447 only a single link. 1449 * Modified certain passages to better reflect the possibility that a 1450 router might have multiple IP addresses. 1452 * "Rsv" replaced by "X X" for reserved field. 1454 * Added mandates for reserved fields, and replaces some ambiguous 1455 language phraseology by mandates. 1457 * Replaced "retransmit" terminology by more correct "propagate" 1458 terminology. 1460 * Added text about determining link symmetry near Figure 5. 1462 * Mandated checking the Address Vector to avoid routing loops. 1464 * Improved specification for use of the Delta value in 1465 Section 6.3.3. 1467 * Corrected the wrong use of RREQ-Instance to be RREP-Instance. 1469 * Referred to Subregistry values instead of Registry values in 1470 Section 9. 1472 * Sharpened language in Section 10, eliminated misleading use of 1473 capitalization in the words "Security Configuration". 1475 * Added acknowledgements and contributors. 1477 B.5. Changes from version 09 to version 10 1479 * Changed the title for brevity and to remove acronyms. 1481 * Added "Note to the RFC Editor" in Section 9. 1483 * Expanded DAO and P2MP in Section 1. 1485 * Reclassified [RFC6998] and [RFC7416] as Informational. 1487 * SHOULD changed to MUST in Section 4.1 and Section 4.2. 1489 * Several editorial improvements and clarifications. 1491 B.6. Changes from version 08 to version 09 1493 * Removed section "Link State Determination" and put some of the 1494 relevant material into Section 5. 1496 * Cited security section of [RFC6550] as part of the RREP-DIO 1497 message description in Section 2. 1499 * SHOULD has been changed to MUST in Section 4.2. 1501 * Expanded the terms ETX and RSSI in Section 5. 1503 * Section 6.4 has been expanded to provide a more precise 1504 explanation of the handling of route reply. 1506 * Added [RFC7416] in the Security Considerations (Section 10) for 1507 RPL security threats. Cited [RFC6550] for authenticated mode of 1508 operation. 1510 * Appendix A has been mostly re-written to describe methods to 1511 determine whether or not the S bit should be set to 1. 1513 * For consistency, adjusted several mandates from SHOULD to MUST and 1514 from SHOULD NOT to MUST NOT. 1516 * Numerous editorial improvements and clarifications. 1518 B.7. Changes from version 07 to version 08 1519 * Instead of describing the need for routes to "fulfill the 1520 requirements", specify that routes need to "satisfy the Objective 1521 Function". 1523 * Removed all normative dependencies on [RFC6997] 1525 * Rewrote Section 10 to avoid duplication of language in cited 1526 specifications. 1528 * Added a new section "Link State Determination" with text and 1529 citations to more fully describe how implementations determine 1530 whether links are symmetric. 1532 * Modified text comparing AODV-RPL to other protocols to emphasize 1533 the need for AODV-RPL instead of the problems with the other 1534 protocols. 1536 * Clarified that AODV-RPL uses some of the base RPL specification 1537 but does not require an instance of RPL to run. 1539 * Improved capitalization, quotation, and spelling variations. 1541 * Specified behavior upon reception of a RREQ-DIO or RREP-DIO 1542 message for an already existing DODAGID (e.g, Section 6.4). 1544 * Fixed numerous language issues in IANA Considerations Section 9. 1546 * For consistency, adjusted several mandates from SHOULD to MUST and 1547 from SHOULD NOT to MUST NOT. 1549 * Numerous editorial improvements and clarifications. 1551 B.8. Changes from version 06 to version 07 1553 * Added definitions for all fields of the ART option (see 1554 Section 4.3). Modified definition of Prefix Length to prohibit 1555 Prefix Length values greater than 127. 1557 * Modified the language from [RFC6550] Target Option definition so 1558 that the trailing zero bits of the Prefix Length are no longer 1559 described as "reserved". 1561 * Reclassified [RFC3561] and [RFC6998] as Informative. 1563 * Added citation for [RFC8174] to Terminology section. 1565 B.9. Changes from version 05 to version 06 1566 * Added Security Considerations based on the security mechanisms 1567 defined in [RFC6550]. 1569 * Clarified the nature of improvements due to P2P route discovery 1570 versus bidirectional asymmetric route discovery. 1572 * Editorial improvements and corrections. 1574 B.10. Changes from version 04 to version 05 1576 * Add description for sequence number operations. 1578 * Extend the residence duration L in section 4.1. 1580 * Change AODV-RPL Target option to ART option. 1582 B.11. Changes from version 03 to version 04 1584 * Updated RREP option format. Remove the T bit in RREP option. 1586 * Using the same RPLInstanceID for RREQ and RREP, no need to update 1587 [RFC6550]. 1589 * Explanation of Delta field in RREP. 1591 * Multiple target options handling during transmission. 1593 B.12. Changes from version 02 to version 03 1595 * Include the support for source routing. 1597 * Import some features from [RFC6997], e.g., choice between hop-by- 1598 hop and source routing, the L field which determines the duration 1599 of residence in the DAG, RankLimit, etc. 1601 * Define new target option for AODV-RPL, including the Destination 1602 Sequence Number in it. Move the TargNode address in RREQ option 1603 and the OrigNode address in RREP option into ADOV-RPL Target 1604 Option. 1606 * Support route discovery for multiple targets in one RREQ-DIO. 1608 * New RPLInstanceID pairing mechanism. 1610 Appendix C. Contributors 1612 Abdur Rashid Sangi 1613 Huaiyin Institute of Technology 1615 No.89 North Beijing Road, Qinghe District 1617 Huaian 223001 1619 P.R. China 1621 Email: sangi_bahrian@yahoo.com 1623 Malati Hegde 1625 Indian Institute of Science 1627 Bangalore 560012 1629 India 1631 Email: malati@iisc.ac.in 1633 Mingui Zhang 1635 Huawei Technologies 1637 No. 156 Beiqing Rd. Haidian District 1639 Beijing 100095 1641 P.R. China 1643 Email: zhangmingui@huawei.com 1645 Authors' Addresses 1647 Charles E. Perkins 1648 Lupin Lodge 1649 Los Gatos, 95033 1650 United States 1651 Email: charliep@lupinlodge.com 1653 S.V.R Anand 1654 Indian Institute of Science 1655 Bangalore 560012 1656 India 1657 Email: anandsvr@iisc.ac.in 1658 Satish Anamalamudi 1659 SRM University-AP 1660 Amaravati Campus 1661 Amaravati, Andhra Pradesh 522 502 1662 India 1663 Email: satishnaidu80@gmail.com 1665 Bing Liu 1666 Huawei Technologies 1667 No. 156 Beiqing Rd. Haidian District 1668 Beijing 1669 100095 1670 China 1671 Email: remy.liubing@huawei.com