idnits 2.17.1 draft-ietf-roll-aodv-rpl-03.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 (March 5, 2018) is 2243 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) ** Downref: Normative reference to an Experimental RFC: RFC 3561 ** Downref: Normative reference to an Informational RFC: RFC 5548 ** Downref: Normative reference to an Informational RFC: RFC 5673 ** Downref: Normative reference to an Informational RFC: RFC 5826 ** Downref: Normative reference to an Informational RFC: RFC 5867 ** Downref: Normative reference to an Experimental RFC: RFC 6997 ** Downref: Normative reference to an Experimental RFC: RFC 6998 Summary: 7 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL S. Anamalamudi 3 Internet-Draft Huaiyin Institute of Technology 4 Intended status: Standards Track M. Zhang 5 Expires: September 6, 2018 Huawei Technologies 6 AR. Sangi 7 Huaiyin Institute of Technology 8 C. Perkins 9 Futurewei 10 S.V.R.Anand 11 Indian Institute of Science 12 B. Liu 13 Huawei Technologies 14 March 5, 2018 16 Asymmetric AODV-P2P-RPL in Low-Power and Lossy Networks (LLNs) 17 draft-ietf-roll-aodv-rpl-03 19 Abstract 21 Route discovery for symmetric and asymmetric Point-to-Point (P2P) 22 traffic flows is a desirable feature in Low power and Lossy Networks 23 (LLNs). For that purpose, this document specifies a reactive P2P 24 route discovery mechanism for both hop-by-hop routing and source 25 routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL 26 protocol. Paired Instances are used to construct directional paths, 27 in case some of the links between source and target node are 28 asymmetric. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 6, 2018. 47 Copyright Notice 49 Copyright (c) 2018 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Overview of AODV-RPL . . . . . . . . . . . . . . . . . . . . 6 67 4. AODV-RPL DIO Options . . . . . . . . . . . . . . . . . . . . 6 68 4.1. AODV-RPL DIO RREQ Option . . . . . . . . . . . . . . . . 6 69 4.2. AODV-RPL DIO RREP Option . . . . . . . . . . . . . . . . 8 70 4.3. AODV-RPL DIO Target Option . . . . . . . . . . . . . . . 10 71 5. Symmetric and Asymmetric Routes . . . . . . . . . . . . . . . 11 72 6. AODV-RPL Operation . . . . . . . . . . . . . . . . . . . . . 13 73 6.1. Generating Route Request at OrigNode . . . . . . . . . . 13 74 6.2. Receiving and Forwarding Route Request . . . . . . . . . 14 75 6.3. Generating Route Reply at TargNode . . . . . . . . . . . 15 76 6.3.1. RREP-DIO for Symmetric route . . . . . . . . . . . . 15 77 6.3.2. RREP-DIO for Asymmetric Route . . . . . . . . . . . . 16 78 6.3.3. RPLInstanceID Pairing . . . . . . . . . . . . . . . . 16 79 6.4. Receiving and Forwarding Route Reply . . . . . . . . . . 17 80 7. Gratuitous RREP . . . . . . . . . . . . . . . . . . . . . . . 18 81 8. Operation of Trickle Timer . . . . . . . . . . . . . . . . . 19 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 83 9.1. New Mode of Operation: AODV-RPL . . . . . . . . . . . . . 19 84 9.2. AODV-RPL Options: RREQ, RREP, and Target . . . . . . . . 19 85 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 86 11. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 20 87 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 88 12.1. Normative References . . . . . . . . . . . . . . . . . . 20 89 12.2. Informative References . . . . . . . . . . . . . . . . . 21 90 Appendix A. ETX/RSSI Values to select S bit . . . . . . . . . . 21 91 Appendix B. Changes to version 02 . . . . . . . . . . . . . . . 22 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 94 1. Introduction 96 RPL[RFC6550] is a IPv6 distance vector routing protocol for Low-power 97 and Lossy Networks (LLNs), and is designed to support multiple 98 traffic flows through a root-based Destination-Oriented Directed 99 Acyclic Graph (DODAG). Typically, a router does not have routing 100 information for most other routers. Consequently, for traffic 101 between routers within the DODAG (i.e., Point-to-Point (P2P) traffic) 102 data packets either have to traverse the root in non-storing mode, or 103 traverse a common ancestor in storing mode. Such P2P traffic is 104 thereby likely to traverse sub-optimal routes and may suffer severe 105 congestion near the DAG root [RFC6997], [RFC6998]. 107 To discover optimal paths for P2P traffic flows in RPL, P2P-RPL 108 [RFC6997] specifies a temporary DODAG where the source acts as a 109 temporary root. The source initiates DIOs encapsulating the P2P 110 Route Discovery option (P2P-RDO) with an address vector for both hop- 111 by-hop mode (H=1) and source routing mode (H=0). Subsequently, each 112 intermediate router adds its IP address and multicasts the P2P mode 113 DIOs, until the message reaches the target node (TargNode). TargNode 114 sends the "Discovery Reply" object. P2P-RPL is efficient for source 115 routing, but much less efficient for hop-by-hop routing due to the 116 extra address vector overhead. However, for symmetric links, when 117 the P2P mode DIO message is being multicast from the source hop-by- 118 hop, receiving nodes can infer a next hop towards the source. When 119 TargNode subsequently replies to the source along the established 120 forward route, receiving nodes determine the next hop towards 121 TargNode. In other words, it is efficient to use only routing tables 122 for P2P-RDO message instead of "Address vector" for hop-by-hop routes 123 (H=1) over symmetric links. 125 RPL and P2P-RPL both specify the use of a single DODAG in networks of 126 symmetric links, where the two directions of a link MUST both satisfy 127 the constraints of the objective function. This eliminates the 128 possibility to use asymmetric links which are qualified in one 129 direction. But, application-specific routing requirements as defined 130 in IETF ROLL Working Group [RFC5548], [RFC5673], [RFC5826] and 131 [RFC5867] may be satisfied by routing paths using bidirectional 132 asymmetric links. For this purpose, [I-D.thubert-roll-asymlink] 133 describes bidirectional asymmetric links for RPL [RFC6550] with 134 Paired DODAGs, for which the DAG root (DODAGID) is common for two 135 Instances. This can satisfy application-specific routing 136 requirements for bidirectional asymmetric links in core RPL 137 [RFC6550]. Using P2P-RPL twice with Paired DODAGs, on the other 138 hand, requires two roots: one for the source and another for the 139 target node due to temporary DODAG formation. For networks composed 140 of bidirectional asymmetric links (see Section 5), AODV-RPL specifies 141 P2P route discovery, utilizing RPL with a new MoP. AODV-RPL makes 142 use of two multicast messages to discover possibly asymmetric routes, 143 which can achieve higher route diversity. AODV-RPL eliminates the 144 need for address vector control overhead in hop-by-hop mode. This 145 significantly reduces the control packet size, which is important for 146 Constrained LLN networks. Both discovered routes (upward and 147 downward) meet the application specific metrics and constraints that 148 are defined in the Objective Function for each Instance [RFC6552]. 150 The route discovery process in AODV-RPL is modeled on the analogous 151 procedure specified in AODV [RFC3561]. The on-demand nature of AODV 152 route discovery is natural for the needs of peer-to-peer routing in 153 RPL-based LLNs. AODV terminology has been adapted for use with AODV- 154 RPL messages, namely RREQ for Route Request, and RREP for Route 155 Reply. AODV-RPL currently omits some features compared to AODV -- in 156 particular, flagging Route Errors, blacklisting unidirectional links, 157 multihoming, and handling unnumbered interfaces. 159 2. Terminology 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 163 "OPTIONAL" in this document are to be interpreted as described in 164 [RFC2119]. Additionally, this document uses the following terms: 166 AODV 167 Ad Hoc On-demand Distance Vector Routing[RFC3561]. 169 AODV-RPL Instance 170 Either the RREQ-Instance or RREP-Instance 172 Asymmetric Route 173 The route from the OrigNode to the TargNode can traverse different 174 nodes than the route from the TargNode to the OrigNode. An 175 asymmetric route may result from the asymmetry of links, such that 176 only one direction of the series of links fulfills the constraints 177 in route discovery. If the OrigNode doesn't require an upward 178 route towards itself, the route is also considered as asymmetric. 180 Bi-directional Asymmetric Link 181 A link that can be used in both directions but with different link 182 characteristics. 184 DODAG RREQ-Instance (or simply RREQ-Instance) 185 RPL Instance built using the DIO with RREQ option; used for 186 control message transmission from OrigNode to TargNode, thus 187 enabling data transmission from TargNode to OrigNode. 189 DODAG RREP-Instance (or simply RREP-Instance) 190 RPL Instance built using the DIO with RREP option; used for 191 control message transmission from TargNode to OrigNode thus 192 enabling data transmission from OrigNode to TargNode. 194 Downward Direction 195 The direction from the OrigNode to the TargNode. 197 Downward Route 198 A route in the downward direction. 200 hop-by-hop routing 201 Routing when each node stores routing information about the next 202 hop. 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 of an application. 211 P2P 212 Point-to-Point -- in other words, not constrained to traverse a 213 common ancestor. 215 RREQ-DIO message 216 An AODV-RPL MoP DIO message containing the RREQ option. The 217 RPLInstanceID in RREQ-DIO is assigned locally by the OrigNode. 219 RREP-DIO message 220 An AODV-RPL MoP DIO message containing the RREP option. The 221 RPLInstanceID in RREP-DIO is typically paired to the one in the 222 associated RREQ-DIO message. 224 Source routing 225 The mechanism by which the source supplies the complete route 226 towards the target node along with each data packet [RFC6550]. 228 Symmetric route 229 The upstream and downstream routes traverse the same routers. 230 Both directions fulfill the constraints in route discovery. 232 TargNode 233 The IPv6 router (Target Node) for which OrigNode requires a route 234 and initiates Route Discovery within the LLN network. 236 Upward Direction 237 The direction from the TargNode to the OrigNode. 239 Upward Route 240 A route in the upward direction. 242 3. Overview of AODV-RPL 244 With AODV-RPL, routes from OrigNode to TargNode within the LLN 245 network established are "on-demand". In other words, the route 246 discovery mechanism in AODV-RPL is invoked reactively when OrigNode 247 has data for delivery to the TargNode but existing routes do not 248 satisfy the application's requirements. The routes discovered by 249 AODV-RPL are point-to-point; in other words the routes are not 250 constrained to traverse a common ancestor. Unlike core RPL [RFC6550] 251 and P2P-RPL [RFC6997], AODV-RPL can enable asymmetric communication 252 paths in networks with bidirectional asymmetric links. For this 253 purpose, AODV-RPL enables discovery of two routes: namely, one from 254 OrigNode to TargNode, and another from TargNode to OrigNode. When 255 possible, AODV-RPL also enables symmetric route discovery along 256 Paired DODAGs (see Section 5). 258 In AODV-RPL, route discovery is initiated by forming a temporary DAG 259 rooted at the OrigNode. Paired DODAGs (Instances) are constructed 260 according to a new AODV-RPL Mode of Operation (MoP) during route 261 formation between the OrigNode and TargNode. The RREQ-Instance is 262 formed by route control messages from OrigNode to TargNode whereas 263 the RREP-Instance is formed by route control messages from TargNode 264 to OrigNode (as shown in Figure 4). Intermediate routers join the 265 Paired DODAGs based on the rank as calculated from the DIO message. 266 Henceforth in this document, the RREQ-DIO message means the AODV-RPL 267 mode DIO message from OrigNode to TargNode, containing the RREQ 268 option. Similarly, the RREP-DIO message means the AODV-RPL mode DIO 269 message from TargNode to OrigNode, containing the RREP option. 270 Subsequently, the route discovered in the RREQ-Instance is used for 271 data transmission from TargNode to OrigNode, and the route discovered 272 in RREP-Instance is used for Data transmission from OrigNode to 273 TargNode. 275 4. AODV-RPL DIO Options 277 4.1. AODV-RPL DIO RREQ Option 279 A RREQ-DIO message MUST carry exactly one RREQ option. 281 0 1 2 3 282 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 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Type | Option Length |S|H|X| Compr | L | MaxRank | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Orig SeqNo | | 287 +-+-+-+-+-+-+-+-+ | 288 | | 289 | | 290 | Address Vector (Optional, Variable Length) | 291 | | 292 | | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 Figure 1: DIO RREQ option format for AODV-RPL MoP 297 OrigNode supplies the following information in the RREQ option of the 298 RREQ-Instance message: 300 Type 302 The type of the RREQ option(see Section 9.2). 304 Option Length 306 Length of the option in octets excluding the Type and Length 307 fields. Variable due to the presence of the address vector and 308 the number of octets elided according to the Compr value. 310 S 312 Symmetric bit indicating a symmetric route from the OrigNode to 313 the router issuing this RREQ-DIO. The bit SHOULD be set to 1 in 314 the RREQ-DIO when the OrigNode initiates the route discovery. 316 X 318 Reserved. 320 H 322 The OrigNode sets this flag to one if it desires a hop-by-hop 323 route. It sets this flag to zero if it desires a source route. 324 This flag is valid to both downstream route and upstream route. 326 Compr 327 4-bit unsigned integer. Number of prefix octets that are elided 328 from the Address Vector. The octets elided are shared with the 329 IPv6 address in the DODAGID. 331 L 332 2-bit unsigned integer. This field indicates the duration that a 333 node joining the temporary DAG in RREQ-Instance, including the 334 OrigNode and the TargNode. Once the time is reached, a node MUST 335 leave the DAG and stop sending or receiving any more DIOs for the 336 temporary DODAG. The detailed definition can be found in 337 [RFC6997]. 339 * 0x00: No duration time imposed. 340 * 0x01: 2 seconds 341 * 0x02: 16 seconds 342 * 0x03: 64 seconds 344 It should be indicated here that L is not the route lifetime, 345 which is defined in the DODAG configuration option. The route 346 entries in hop-by-hop routing and states of source routing can 347 still be maintained even after the DAG expires. 349 MaxRank 351 This field indicates the upper limit on the integer portion of the 352 rank. A node MUST NOT join a temporary DODAG if its own rank 353 would equal to or higher than the limit. A value of 0 in this 354 field indicates the limit is infinity. For more details please 355 refer to [RFC6997]. 357 OrigNode Sequence Number 359 Sequence Number of OrigNode, defined similarly as in AODV 360 [RFC3561]. 362 Address Vector (Optional) 364 A vector of IPv6 addresses representing the route that the RREQ- 365 DIO has passed. It is only present when the 'H' bit is set to 0. 366 The prefix of each address is elided according to the Compr field. 368 4.2. AODV-RPL DIO RREP Option 370 A RREP-DIO message MUST carry exactly one RREP option. 372 The TargNode supplies the following information in the RREP option: 374 0 1 2 3 375 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 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Type | Option Length |H|X| Compr | L | MaxRank | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 |T|G| SHIFT | Reserved | | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 381 | | 382 | | 383 | Address Vector (Optional, Variable Length) | 384 . . 385 . . 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 Figure 2: DIO RREP option format for AODV-RPL MoP 390 Type 391 The type of the RREP option (see Section 9.2) 393 Option Length 394 Length of the option in octets excluding the Type and Length 395 fields. Variable due to the presence of the address vector and 396 the number of octets elided according to the Compr value. 398 H 399 This bit indicates the downstream route is source routing (H=0) or 400 hop-by-hop (H=1). It SHOULD be set to be the same as the 'H' bit 401 in RREQ option. 403 X 405 Reserved. 407 Compr 408 4-bit unsigned integer. Same definition as in RREQ option. 410 L 411 2-bit unsigned integer with the same definition as in Section 4.1. 413 MaxRank 414 Same definition as in RREQ option. 416 T 417 'T' is set to 1 to indicate that the RREP-DIO MUST include exactly 418 one AODV-RPL Target Option. Otherwise, the Target Option is not 419 necessary in the RREP-DIO. 421 G 422 Gratuitous route (see Section 7). 424 SHIFT 425 6-bit unsigned integer. This field indicates the how many the 426 original InstanceID (see Section 6.3.3) is shifted (added an 427 integer from 0 to 63). 0 indicates that the original InstanceID 428 is used. 430 Reserved 431 Reserved for future usage; MUST be initialized to zero and MUST be 432 ignored upon reception. 434 Address Vector (Optional) 435 It is only present when the 'H' bit is set to 0. For an 436 asymmetric route, it is a vector of IPv6 addresses representing 437 the route that the RREP-DIO has passed. For symmetric route, it 438 is the accumulated vector when the RREQ-DIO arrives at the 439 TargNode. 441 4.3. AODV-RPL DIO Target Option 443 The AODV-RPL Target Option is defined based on the Target Option in 444 core RPL [RFC6550]: the Destination Sequence Number of the TargNode 445 is added. 447 A RREQ-DIO message MUST carry at least one AODV-RPL Target Options. 448 A RREP-DIO message MUST carry exactly one AODV-RPL Target Option 449 encapsulating the address of the OrigNode if the 'T' bit is set to 1. 451 If an OrigNode want to discover routes to multiple TargNodes, and 452 these routes share the same constraints, then the OrigNode can 453 include all the addresses of the TargNodes into multiple AODV-RPL 454 Target Options in the RREQ-DIO, so that the cost can be reduced to 455 building only one DODAG. Different addresses of the TargNodes can 456 merge if they share the same prefix. 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 | Type | Option Length | Dest SeqNo | Prefix Length | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | | 464 + | 465 | Target Prefix (Variable Length) | 466 . . 467 . . 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 Figure 3: Target option format for AODV-RPL MoP 472 Type 473 The type of the AODV-RPL Target Option (see Section 9.2) 475 Destination Sequence Number 477 In RREQ-DIO, if nonzero, it is the last known Sequence Number for 478 TargNode for which a route is desired. In RREP-DIO, it is the 479 destination sequence number associated to the route. 481 5. Symmetric and Asymmetric Routes 483 In Figure 4 and Figure 5, BR is the BorderRouter, O is the OrigNode, 484 R is an intermediate router, and T is the TargNode. If the RREQ-DIO 485 arrives over an interface that is known to be symmetric, and the 'S' 486 bit is set to 1, then it remains as 1, as illustrated in Figure 4. 487 An intermediate router sends out RREQ-DIO with the 'S' bit set to 1, 488 meaning that all the one-hop links on the route from the OrigNode to 489 this router meet the requirements of route discovery; thus the route 490 can be used symmetrically. 492 BR 493 / | \ 494 / | \ 495 / | \ 496 R R R 497 / \ | / \ 498 / \ | / \ 499 / \ | / \ 500 R -------- R --- R ----- R -------- R 501 / \ <--S=1--> / \ <--S=1--> / \ 502 <--S=1--> \ / \ / <--S=1--> 503 / \ / \ / \ 504 O ---------- R ------ R------ R ----- R ----------- T 505 / \ / \ / \ / \ 506 / \ / \ / \ / \ 507 / \ / \ / \ / \ 508 R ----- R ----------- R ----- R ----- R ----- R ---- R----- R 510 >---- RREQ-Instance (Control: S-->D; Data: D-->S) -------> 511 <---- RREP-Instance (Control: D-->S; Data: S-->D) -------< 513 Figure 4: AODV-RPL with Symmetric Paired Instances 515 Upon receiving a RREQ-DIO with the 'S' bit set to 1, a node MUST 516 decide if this one-hop link can be used symmetrically, i.e., both the 517 two directions meet the requirements of data transmission. If the 518 RREQ-DIO arrives over an interface that is not known to be symmetric, 519 or is known to be asymmetric, the 'S' bit is set to 0. Moreover, if 520 the 'S' bit arrives already set to be '0', it is set to be '0' on 521 retransmission (Figure 5). Therefore, for asymmetric route, there is 522 at least one hop which doesn't fulfill the constraints in the two 523 directions. Based on the 'S' bit received in RREQ-DIO, the TargNode 524 decides whether or not the route is symmetric before transmitting the 525 RREP-DIO message upstream towards the OrigNode. 527 The criterion and the corresponding metric used to determine if a 528 one-hop link is symmetric or not is implementation specific and 529 beyond the scope of the document. Also, the difference in the metric 530 values for upward and downward directions of a link that can be 531 establish its symmetric and asymmetric nature is implementation 532 specific. For instance, the intermediate routers MAY choose to use 533 local information (e.g., bit rate, bandwidth, number of cells used in 534 6tisch), a priori knowledge (e.g. link quality according to previous 535 communication) or estimate the metric using averaging techniques or 536 any other means that is appropriate to the application context. 538 Appendix A describes an example method using the ETX and RSSI to 539 estimate whether the link is symmetric in terms of link quality is 540 given in using an averaging technique. 542 BR 543 / | \ 544 / | \ 545 / | \ 546 R R R 547 / \ | / \ 548 / \ | / \ 549 / \ | / \ 550 R --------- R --- R ---- R --------- R 551 / \ --S=1--> / \ --S=0--> / \ 552 --S=1--> \ / \ / --S=0--> 553 / \ / \ / \ 554 O ---------- R ------ R------ R ----- R ----------- T 555 / \ / \ / \ / \ 556 / <--S=0-- / \ / \ / <--S=0-- 557 / \ / \ / \ / \ 558 R ----- R ----------- R ----- R ----- R ----- R ---- R----- R 559 <--S=0-- <--S=0-- <--S=0-- <--S=0-- <--S=0-- 561 >---- RREQ-Instance (Control: S-->D; Data: D-->S) -------> 562 <---- RREP-Instance (Control: D-->S; Data: S-->D) -------< 564 Figure 5: AODV-RPL with Asymmetric Paired Instances 566 6. AODV-RPL Operation 568 6.1. Generating Route Request at OrigNode 570 The route discovery process is initiated on-demand when an 571 application at the OrigNode has data to be transmitted to the 572 TargNode, but no route for the target exists or the current routes 573 don't fulfill the requirements of the data transmission. In this 574 case, the OrigNode MUST build a local RPLInstance and a DODAG rooted 575 at itself. Then it begins to send out DIO message in AODV-RPL MoP 576 via link-local multicast. The DIO MUST contain exactly one RREQ 577 option as defined in Section 4.1, and at least one AODV-RPL Target 578 Option as defined in Figure 3. This DIO message is noted as RREQ- 579 DIO. The 'S' bit in RREQ-DIO sent out by the OrigNode is set as 1. 581 The maintenance of Originator and Destination Sequence Number in the 582 RREQ option is as defined in AODV [RFC3561]. 584 The address in the AODV-RPL Target Option can be a unicast IPv6 585 address, a prefix or a multicast address. The OrigNode can initiate 586 the route discovery process for multiple targets simultaneously by 587 including multiple AODV-RPL Target Options, and within a RREQ-DIO the 588 requirements for the routes to different TargNodes MUST be the same. 590 The OrigNode can maintain different RPLInstances to discover routes 591 with different requirements to the same targets. Due to the 592 InstanceID pairing mechanism Section 6.3.3, route replies (RREP-DIOs) 593 from different paired RPLInstances can be distinguished. 595 The transmission of RREQ-DIO follows the Trickle timer. When the L 596 duration has transpired, the OrigNode MUST leave the DODAG and stop 597 sending any RREQ-DIOs in the related RPLInstance. 599 6.2. Receiving and Forwarding Route Request 601 Upon receiving a RREQ-DIO, a router out of the RREQ-instance goes 602 through the following steps: 604 Step 1: 606 If the 'S' bit in the received RREQ-DIO is set to 1, the router 607 MUST look into the two directions of the link by which the RREQ- 608 DIO is received. In case that the downward (i.e. towards the 609 TargNode) direction of the link can't fulfill the requirements, 610 then the link can't be used symmetrically, thus the 'S' bit of the 611 RREQ-DIO to be send out MUST be set as 0. If the 'S' bit in the 612 received RREQ-DIO is set to 0, the router MUST look only into the 613 upward direction (i.e. towards the OrigNode) of the link. If the 614 upward direction of the link can fulfill the requirements 615 indicated in the constraint option, and the router's rank would be 616 inferior to the MaxRank limit, the router chooses to join in the 617 DODAG of the RREQ-Instance. The router issuing the received RREQ- 618 DIO is selected as the preferred parent. Afterwards, other RREQ- 619 DIO message can be received. How to maintain the parent set, 620 select the preferred parent, and update the router's rank follows 621 the core RPL and the OFs defined in ROLL WG. 623 In case that the constraint or the MaxRank limit is not fulfilled, 624 the router MUST NOT join in the DODAG. Otherwise, go to the 625 following steps 2, 3, 4 and 5. 627 A router MUST discard a received RREQ-DIO if the advertised rank 628 equals or exceeds the MaxRank limit. 630 Step 2: 632 Then the router checks if one of its addresses is included in one 633 of the AODV-RPL Target Options or belongs to the indicated 634 multicast group. If so, this router is one of the TargNodes. 635 Otherwise, it is an intermediate router. 637 Step 3: 639 If the 'H' bit is set to 1, then the router (TargNode or 640 intermediate) MUST build route entry towards its preferred parent. 641 The route entry SHOULD be stored along with the associated 642 RPLInstanceID and DODAGID. If the 'H' bit is set to 0, an 643 intermediate router MUST include the address of the interface 644 receiving the RREQ-DIO into the address vector. 646 Step 4: 648 If there are multiple AODV-RPL Target Options in the received 649 RREQ-DIO, a TargNode SHOULD continue sending RREQ-DIO to reach 650 other targets. When preparing its own RREQ-DIO, the TargNode MUST 651 delete the AODV-RPL Target Option related to its own address, so 652 that the routers which higher ranks would know the route to this 653 target has already been found. When an intermediate router 654 receives several RREQ-DIOs which include different lists of AODV- 655 RPL Target Options, the intersection of these lists will be 656 included in its own RREQ-DIO. If the intersection is empty, the 657 router SHOULD NOT send out any RREQ-DIO. Any RREQ-DIO message 658 with different AODV-RPL Target Options coming from a router with 659 higher rank is ignored. 661 Step 5: 663 For an intermediate router, it sends out its own RREQ-DIO via 664 link-local multicast. For a TargNode, it can begin to prepare the 665 RREP-DIO. 667 6.3. Generating Route Reply at TargNode 669 6.3.1. RREP-DIO for Symmetric route 671 When a RREQ-DIO arrives at a TargNode with the 'S' bit set to 1, it 672 means there exists a symmetric route in which the two directions can 673 fulfill the requirements. Other RREQ-DIOs can bring the upward 674 direction of asymmetric routes (i.e. S=0). How to choose between a 675 qualified symmetric route and an asymmetric route hopefully having 676 better performance is implementation-specific and out of scope. If 677 the implementation choose to use the symmetric route, the TargNode 678 MAY send out the RREP-DIO after a duration RREP_WAIT_TIME to wait for 679 the convergence of RD to an optimal symmetric route. 681 For symmetric route, the RREP-DIO message is sent via unicast to the 682 OrigNode; therefore the DODAG in RREP-Instance doesn't need to be 683 actually built. The RPLInstanceID in the RREP-Instance is paired as 684 defined in Section 6.3.3. The 'S' bit in the base DIO remains as 1. 685 In the RREP option, The 'SHIFT' field and the 'T' bit are set as 686 defined in Section 6.3.3. The address vector received in the RREQ- 687 DIO MUST be included in this RREP option in case the 'H' bit is set 688 to 0 (both in RREQ-DIO and RREP-DIO). If the 'T' bit is set to 1, 689 the address of the OrigNode MUST be encapsulated in an AODV-RPL 690 Target Option and included in this RREP-DIO message, and the 691 Destination Sequence Number is set according to AODV [RFC3561]. 693 6.3.2. RREP-DIO for Asymmetric Route 695 When a RREQ-DIO arrives at a TargNode with the 'S' bit set to 0, the 696 TargNode MUST build a DODAG in the RREP-Instance rooted at itself in 697 order to discover the downstream route from the OrigNode to the 698 TargNode. The RREP-DIO message MUST be send out via link-local 699 multicast until the OrigNode is reached or the MaxRank limit is 700 exceeded. 702 The settings of the RREP-DIO are the same as in symmetric route. 704 6.3.3. RPLInstanceID Pairing 706 Since the RPLInstanceID is assigned locally (i.e., there is no 707 coordination between routers in the assignment of RPLInstanceID) the 708 tuple (RPLInstanceID, DODAGID, Address in the AODV-RPL Target Option) 709 is needed to uniquely identify a DODAG in an AODV-RPL instance. 710 Between the OrigNode and the TargNode, there can be multiple AODV-RPL 711 instances when applications upper layer have different requirements. 712 Therefore the RREQ-Instance and the RREP-Instance in the same route 713 discovery MUST be paired. The way to realize this is to pair their 714 RPLInstance IDs. 716 Typically, the two InstanceIDs are set as the local InstanceID in 717 core RPL: 719 0 1 2 3 4 5 6 7 720 +-+-+-+-+-+-+-+-+ 721 |1|D| ID | Local RPLInstanceID in 0..63 722 +-+-+-+-+-+-+-+-+ 724 Figure 6: Local Instance ID 726 The first bit is set to 1 indicating the RPLInstanceID is local. The 727 'D' bit here is used to distinguish the two AODV-RPL instances: D=0 728 for RREQ-Instance, D=1 for RREP-Instance. The ID of 6 bits SHOULD be 729 the same for RREQ-Instance and RREP-Instance. Here, the 'D' bit is 730 used slightly differently than in RPL. 732 When preparing the RREP-DIO, a TargNode could find the RPLInstanceID 733 to be used for the RREP-Instance is already occupied by another 734 instance from an earlier route discovery operation which is still 735 active. In other words, two OrigNodes need routes to the same 736 TargNode and they happen to use the same RPLInstanceID for RREQ- 737 Instance. In this case, the occupied RPLInstanceID MUST NOT be used 738 again. Then this RPLInstanceID SHOULD be shifted into another 739 integer and shifted back to the original one at the OrigNode. In 740 RREP option, the SHIFT field indicates the how many the original 741 RPLInstanceID is shifted. When the new InstanceID after shifting 742 exceeds 63, it will come back counting from 0. For example, the 743 original InstanceID is 60, and shifted by 6, the new InstanceID will 744 be 2. The 'T' MUST be set to 1 to make sure the two RREP-DIOs can be 745 distinguished by the address of the OrigNode in the AODV-RPL Target 746 Option. 748 6.4. Receiving and Forwarding Route Reply 750 Upon receiving a RREP-DIO, a router out of the RREP-Instance goes 751 through the following steps: 753 Step 1: 755 If the 'S' bit of the RREP-DIO is set to 0, the router MUST look 756 into the downward direction of the link (towards the TargNode) by 757 which the RREP-DIO is received. If the downward direction of the 758 link can fulfill the requirements indicated in the constraint 759 option, and the router's rank would be inferior to the MaxRank 760 limit, the router chooses to join in the DODAG of the RREP- 761 Instance. The router issuing the received RREP-DIO is selected as 762 the preferred parent. Afterwards, other RREQ-DIO messages can be 763 received. How to maintain the parent set, select the preferred 764 parent, and update the router's rank follows the core RPL and the 765 OFs defined in ROLL WG. 767 If the constraints are not fulfilled, the router MUST NOT join in 768 the DODAG, and will not go through steps 2, 3, and 4. 770 A router MUST discard a received RREQ-DIO if the advertised rank 771 equals or exceeds the MaxRank limit. 773 If the 'S' bit is set to 1, the router does nothing in this step. 775 Step 2: 777 Then the router checks if one of its addresses is included in the 778 AODV-RPL Target Option. If so, this router is the OrigNode of the 779 route discovery. Otherwise, it is an intermediate router. 781 Step 3: 783 If the 'H' bit is set to 1, then the router (OrigNode or 784 intermediate) MUST build route entry including the RPLInstanceID 785 of RREP-Instance and the DODAGID. For symmetric route, the route 786 entry is to the router from which the RREP-DIO is received. For 787 asymmetric route, the route entry is to the preferred parent in 788 the DODAG of RREQ-Instance. 790 If the 'H' bit is set to 0, for asymmetric route, an intermediate 791 router MUST include the address of the interface receiving the 792 RREP-DIO into the address vector, and for symmetric route, there 793 is nothing to do in this step. 795 Step 4: 797 For an intermediate router, in case of asymmetric route, the RREP- 798 DIO is sent out via link-local multicast; in case of symmetric 799 route, the RREP-DIO is unicasted to the OrigNode via the next hop 800 in source routing (H=0), or via the next hop in the route entry 801 built in the RREQ-Instance (H=1). For the OrigNode, it can start 802 transmitting the application data to TargNode along the path as 803 discovered through RREP-Instance. 805 7. Gratuitous RREP 807 In some cases, an Intermediate router that receives a RREQ-DIO 808 message MAY transmit a "Gratuitous" RREP-DIO message back to OrigNode 809 instead of continuing to multicast the RREQ-DIO towards TargNode. 810 The intermediate router effectively builds the RREP-Instance on 811 behalf of the actual TargNode. The 'G' bit of the RREP option is 812 provided to distinguish the Gratuitous RREP-DIO (G=1) sent by the 813 Intermediate node from the RREP-DIO sent by TargNode (G=0). 815 The gratuitous RREP-DIO can be sent out when an intermediate router R 816 receives a RREQ-DIO for a TargNode T, and R happens to have both 817 forward and reverse routes to T which also fulfill the requirements. 819 In case of source routing, the intermediate router R MUST unicast the 820 received RREQ-DIO to TargNode T including the address vector between 821 the OrigNode O and the router R. Thus T can have a complete address 822 vector between O and itself. Then T MUST unicast a RREP-DIO 823 including the address vector between T and R. 825 In case of hop-by-hop routing, R MUST unicast the received RREQ-DIO 826 to T. The routers along the route SHOULD build new route entries 827 with the related RPLInstanceID and DODAGID in the downward direction. 828 Then T MUST unicast the RREP-DIO to R, and the routers along the 829 route SHOULD build new route entries in the upward direction. Upon 830 received the unicast RREP-DIO, R sends the gratuitous RREP-DIO to the 831 OrigNode as the same way defined in Section 6.3. 833 8. Operation of Trickle Timer 835 The trickle timer operation to control RREQ-Instance/RREP-Instance 836 multicast is similar to that in P2P-RPL [RFC6997]. 838 9. IANA Considerations 840 9.1. New Mode of Operation: AODV-RPL 842 IANA is required to assign a new Mode of Operation, named "AODV-RPL" 843 for Point-to-Point(P2P) hop-by-hop routing under the RPL registry. 844 The value of TBD1 is assigned from the "Mode of Operation" space 845 [RFC6550]. 847 +-------------+---------------+---------------+ 848 | Value | Description | Reference | 849 +-------------+---------------+---------------+ 850 | TBD1 (5) | AODV-RPL | This document | 851 +-------------+---------------+---------------+ 853 Figure 7: Mode of Operation 855 9.2. AODV-RPL Options: RREQ, RREP, and Target 857 Three entries are required for new AODV-RPL options "RREQ", "RREP" 858 and "AODV-RPL Target" with values of TBD2 (0x0A), TBD3 (0x0B) and 859 TBD4 (0x0C) from the "RPL Control Message Options" space [RFC6550]. 861 +-------------+------------------------+---------------+ 862 | Value | Meaning | Reference | 863 +-------------+------------------------+---------------+ 864 | TBD2 (0x0A) | RREQ Option | This document | 865 +-------------+------------------------+---------------+ 866 | TBD3 (0x0B) | RREP Option | This document | 867 +-------------+------------------------+---------------+ 868 | TBD3 (0x0C) | AODV-RPL Target Option | This document | 869 +-------------+------------------------+---------------+ 871 Figure 8: AODV-RPL Options 873 10. Security Considerations 875 This document does not introduce additional security issues compared 876 to base RPL. For general RPL security considerations, see [RFC6550]. 878 11. Future Work 880 There has been some discussion about how to determine the initial 881 state of a link after an AODV-RPL-based network has begun operation. 882 The current draft operates as if the links are symmetric until 883 additional metric information is collected. The means for making 884 link metric information is considered out of scope for AODV-RPL. In 885 the future, RREQ and RREP messages could be equipped with new fields 886 for use in verifying link metrics. In particular, it is possible to 887 identify unidirectional links; an RREQ received across a 888 unidirectional link has to be dropped, since the destination node 889 cannot make use of the received DODAG to route packets back to the 890 source node that originated the route discovery operation. This is 891 roughly the same as considering a unidirectional link to present an 892 infinite cost metric that automatically disqualifies it for use in 893 the reverse direction. 895 12. References 897 12.1. Normative References 899 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 900 Requirement Levels", BCP 14, RFC 2119, 901 DOI 10.17487/RFC2119, March 1997, 902 . 904 [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- 905 Demand Distance Vector (AODV) Routing", RFC 3561, 906 DOI 10.17487/RFC3561, July 2003, 907 . 909 [RFC5548] Dohler, M., Ed., Watteyne, T., Ed., Winter, T., Ed., and 910 D. Barthel, Ed., "Routing Requirements for Urban Low-Power 911 and Lossy Networks", RFC 5548, DOI 10.17487/RFC5548, May 912 2009, . 914 [RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T. 915 Phinney, "Industrial Routing Requirements in Low-Power and 916 Lossy Networks", RFC 5673, DOI 10.17487/RFC5673, October 917 2009, . 919 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 920 Routing Requirements in Low-Power and Lossy Networks", 921 RFC 5826, DOI 10.17487/RFC5826, April 2010, 922 . 924 [RFC5867] Martocci, J., Ed., De Mil, P., Riou, N., and W. Vermeylen, 925 "Building Automation Routing Requirements in Low-Power and 926 Lossy Networks", RFC 5867, DOI 10.17487/RFC5867, June 927 2010, . 929 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 930 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 931 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 932 Low-Power and Lossy Networks", RFC 6550, 933 DOI 10.17487/RFC6550, March 2012, 934 . 936 [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing 937 Protocol for Low-Power and Lossy Networks (RPL)", 938 RFC 6552, DOI 10.17487/RFC6552, March 2012, 939 . 941 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and 942 J. Martocci, "Reactive Discovery of Point-to-Point Routes 943 in Low-Power and Lossy Networks", RFC 6997, 944 DOI 10.17487/RFC6997, August 2013, 945 . 947 [RFC6998] Goyal, M., Ed., Baccelli, E., Brandt, A., and J. Martocci, 948 "A Mechanism to Measure the Routing Metrics along a Point- 949 to-Point Route in a Low-Power and Lossy Network", 950 RFC 6998, DOI 10.17487/RFC6998, August 2013, 951 . 953 12.2. Informative References 955 [I-D.thubert-roll-asymlink] 956 Thubert, P., "RPL adaptation for asymmetrical links", 957 draft-thubert-roll-asymlink-02 (work in progress), 958 December 2011. 960 Appendix A. ETX/RSSI Values to select S bit 962 We have tested the combination of "RSSI(downstream)" and "ETX 963 (upstream)" to decide whether the link is symmetric or asymmetric at 964 the intermediate nodes. The example of how the ETX and RSSI values 965 are used in conjuction is explained below: 967 Source---------->NodeA---------->NodeB------->Destination 969 Figure 9: Communication link from Source to Destination 971 +-------------------------+----------------------------------------+ 972 | RSSI at NodeA for NodeB | Expected ETX at NodeA for NodeB->NodeA | 973 +-------------------------+----------------------------------------+ 974 | > -15 | 150 | 975 | -25 to -15 | 192 | 976 | -35 to -25 | 226 | 977 | -45 to -35 | 662 | 978 | -55 to -45 | 993 | 979 +-------------------------+----------------------------------------+ 981 Table 1: Selection of 'S' bit based on Expected ETX value 983 We tested the operations in this specification by making the 984 following experiment, using the above parameters. In our experiment, 985 a communication link is considered as symmetric if the ETX value of 986 NodeA->NodeB and NodeB->NodeA (See Figure.8) are, say, within 1:3 987 ratio. This ratio should be taken as a notional metric for deciding 988 link symmetric/asymmetric nature, and precise definition of the ratio 989 is beyond the scope of the draft. In general, NodeA can only know 990 the ETX value in the direction of NodeA -> NodeB but it has no direct 991 way of knowing the value of ETX from NodeB->NodeA. Using physical 992 testbed experiments and realistic wireless channel propagation 993 models, one can determine a relationship between RSSI and ETX 994 representable as an expression or a mapping table. Such a 995 relationship in turn can be used to estimate ETX value at nodeA for 996 link NodeB--->NodeA from the received RSSI from NodeB. Whenever 997 nodeA determines that the link towards the nodeB is bi-directional 998 asymmetric then the "S" bit is set to "S=0". Later on, the link from 999 NodeA to Destination is asymmetric with "S" bit remains to "0". 1001 Appendix B. Changes to version 02 1003 o Include the support for source routing. 1005 o Bring some features from [RFC6997], e.g., choice between hop-by- 1006 hop and source routing, duration of residence in the DAG, MaxRank, 1007 etc. 1009 o Define new target option for AODV-RPL, including the Destination 1010 Sequence Number in it. Move the TargNode address in RREQ option 1011 and the OrigNode address in RREP option into ADOV-RPL Target 1012 Option. 1014 o Support route discovery for multiple targets in one RREQ-DIO. 1016 o New InstanceID pairing mechanism. 1018 Authors' Addresses 1020 Satish Anamalamudi 1021 Huaiyin Institute of Technology 1022 No.89 North Beijing Road, Qinghe District 1023 Huaian 223001 1024 China 1026 Email: satishnaidu80@gmail.com 1028 Mingui Zhang 1029 Huawei Technologies 1030 No. 156 Beiqing Rd. Haidian District 1031 Beijing 100095 1032 China 1034 Email: zhangmingui@huawei.com 1036 Abdur Rashid Sangi 1037 Huaiyin Institute of Technology 1038 No.89 North Beijing Road, Qinghe District 1039 Huaian 223001 1040 P.R. China 1042 Email: sangi_bahrian@yahoo.com 1044 Charles E. Perkins 1045 Futurewei 1046 2330 Central Expressway 1047 Santa Clara 95050 1048 Unites States 1050 Email: charliep@computer.org 1052 S.V.R Anand 1053 Indian Institute of Science 1054 Bangalore 560012 1055 India 1057 Email: anand@ece.iisc.ernet.in 1058 Bing Liu 1059 Huawei Technologies 1060 No. 156 Beiqing Rd. Haidian District 1061 Beijing 100095 1062 China 1064 Email: remy.liubing@huawei.com