idnits 2.17.1 draft-ietf-roll-p2p-rpl-08.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 2, 2012) is 4437 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'NH' is mentioned on line 1018, but not defined == Outdated reference: A later version (-10) exists of draft-ietf-roll-p2p-measurement-02 == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-06 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Goyal, Ed. 3 Internet-Draft University of Wisconsin 4 Intended status: Experimental Milwaukee 5 Expires: September 3, 2012 E. Baccelli 6 M. Philipp 7 INRIA 8 A. Brandt 9 Sigma Designs 10 J. Martocci 11 Johnson Controls 12 March 2, 2012 14 Reactive Discovery of Point-to-Point Routes in Low Power and Lossy 15 Networks 16 draft-ietf-roll-p2p-rpl-08 18 Abstract 20 This document specifies a point-to-point route discovery mechanism, 21 complementary to the RPL core functionality. This mechanism allows 22 an IPv6 router to discover "on demand" routes to one or more IPv6 23 routers in the LLN such that the discovered routes meets specified 24 metrics constraints. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF 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 http://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 September 3, 2012. 43 Copyright Notice 45 Copyright (c) 2012 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 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. The Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 64 5. Functional Overview . . . . . . . . . . . . . . . . . . . . . 5 65 6. P2P Route Discovery Mode Of Operation . . . . . . . . . . . . 8 66 6.1. Setting a P2P Mode DIO . . . . . . . . . . . . . . . . . . 8 67 7. New RPL Control Message Options . . . . . . . . . . . . . . . 11 68 7.1. P2P Route Discovery Option (P2P-RDO) . . . . . . . . . . . 11 69 7.2. Data Option . . . . . . . . . . . . . . . . . . . . . . . 14 70 8. The Discovery Reply Object (DRO) . . . . . . . . . . . . . . . 14 71 8.1. Secure DRO . . . . . . . . . . . . . . . . . . . . . . . . 16 72 8.2. Setting a P2P-RDO Carried in a Discovery Reply Object . . 16 73 9. P2P-RPL Route Discovery By Creating a Temporary DAG . . . . . 17 74 9.1. Joining a Temporary DAG . . . . . . . . . . . . . . . . . 17 75 9.2. Trickle Operation For P2P Mode DIOs . . . . . . . . . . . 18 76 9.3. Processing a P2P Mode DIO . . . . . . . . . . . . . . . . 19 77 9.4. Additional Processing of a P2P Mode DIO At An 78 Intermediate Router . . . . . . . . . . . . . . . . . . . 20 79 9.5. Additional Processing of a P2P Mode DIO At The Target . . 21 80 9.6. Processing a DRO At An Intermediate Router . . . . . . . . 22 81 9.7. Processing a DRO At The Origin . . . . . . . . . . . . . . 23 82 10. The Discovery Reply Object Acknowledgement (DRO-ACK) . . . . . 24 83 11. Packet Forwarding Along a Route Discovered Using P2P-RPL . . . 25 84 12. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 25 85 13. Interoperability with Core RPL . . . . . . . . . . . . . . . . 26 86 14. Security Considerations . . . . . . . . . . . . . . . . . . . 26 87 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 88 15.1. Additions to DIO Mode of Operation . . . . . . . . . . . . 27 89 15.2. Additions to RPL Control Message Options . . . . . . . . . 27 90 15.3. Additions to RPL Control Codes . . . . . . . . . . . . . . 27 91 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 92 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 93 17.1. Normative References . . . . . . . . . . . . . . . . . . . 28 94 17.2. Informative References . . . . . . . . . . . . . . . . . . 29 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 97 1. Introduction 99 Targeting Low power and Lossy Networks (LLNs), the RPL routing 100 protocol [I-D.ietf-roll-rpl] provides paths along a Directed Acyclic 101 Graph (DAG) rooted at a single router in the network. Establishment 102 and maintenance of a DAG is performed by routers in the LLN using 103 DODAG Information Object (DIO) messages. When two arbitrary routers 104 (neither of which is the DAG's root) need to communicate, the data 105 packets are restricted to travel only along the links in the DAG. 106 Such point-to-point (P2P) routing functionality may not be sufficient 107 for several Home and Building Automation applications [RFC5826] 108 [RFC5867] due to the following reasons: 110 o The need to pre-establish routes: each potential destination in 111 the network must declare itself as such ahead of the time a source 112 needs to reach it. 114 o The need to route only along the links in the DAG: A DAG is built 115 to optimize the routing cost to reach the root. Restricting P2P 116 routes to use only the in-DAG links may result in significantly 117 suboptimal routes and severe traffic congestion near the DAG root. 119 This document describes an extension to core RPL that enables an IPv6 120 router in the LLN to discover routes to one or more IPv6 routers in 121 the LLN "on demand", such that the discovered routes meet the 122 specified metrics constraints, without necessarily going along the 123 links in an existing DAG. This reactive P2P route discovery 124 mechanism is henceforth referred to as P2P-RPL. P2P-RPL does not 125 guarantee discovery of a route. Also, the discovered routes may not 126 be the best available. However, any discovered routes are guaranteed 127 to satisfy the desired constraints in terms of the routing metrics 128 and are thus considered "good enough" from the application's 129 perspective. 131 A mechanism to measure the end-to-end cost of an existing route has 132 been specified in [I-D.ietf-roll-p2p-measurement]. As discussed in 133 Section 4, measuring the end-to-end cost of an existing route may 134 help decide whether to initiate the discovery of a better route using 135 P2P-RPL and the metric constraints to be used for this purpose. 137 2. The Use Cases 139 One use case, common in home and commercial building environments, 140 involves a device (say a remote control or an airduct controller) 141 that suddenly needs to communicate with another device (say a lamp or 142 a humidity sensor) to which it does not already have a route. In 143 this case, the remote control (or the airduct controller) must be 144 able to discover a route to the lamp (or the humidity sensor) "on 145 demand". 147 Another use case, common in a commercial building environment, 148 involves a large LLN deployment where P2P communication along a 149 particular DAG among hundreds (or thousands) of routers creates 150 severe traffic congestion near that DAG's root, and thus routes 151 across this DAG are desirable. 153 Other use cases involve scenarios where energy or latency constraints 154 are not satisfied by the P2P routes along an existing DAG because 155 they involve traversing many more intermediate routers than necessary 156 to reach the destination. 158 3. Terminology 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 162 "OPTIONAL" in this document are to be interpreted as described in 163 [RFC2119]. 165 Additionally, this document uses terminology from 166 [I-D.ietf-roll-terminology] and [I-D.ietf-roll-rpl]. This document 167 introduces the following terms: 169 Origin : The IPv6 router initiating the P2P-RPL route discovery. 171 Target : The IPv6 router at the other end point of the P2P route(s) 172 to be discovered. A P2P-RPL route discovery can discover routes to 173 multiple targets at the same time. 175 Intermediate Router: An IPv6 router that is neither the origin nor a 176 target. 178 Forward Route: A route in the forward direction, i.e., from the 179 origin to the target. 181 Backward Route: A route in the backward direction, i.e., from the 182 target to the origin. 184 Bidirectional Route: A route that can be used in both forward and 185 backward directions. 187 Source Route: A complete and ordered list of routers that can be used 188 by a packet to travel from a source to a destination node. 190 Hop-by-hop Route: The route characterized by each router on the route 191 using its routing table to determine the next hop on the route. 193 4. Applicability 195 A route discovery using P2P-RPL may be performed by an origin when no 196 route exists between itself and the target(s) or when the existing 197 routes do not satisfy the application requirements. P2P-RPL is 198 designed to discover hop-by-hop or source routes to one or more 199 targets such that the discovered routes meet the specified 200 constraints. In some application contexts, the constraints that the 201 discovered routes must satisfy are intrinsically known or can be 202 specified by the application. For example, an origin that expects 203 its targets to be less than 5 hops away may use "hop-count < 5" as 204 the constraint. In other application contexts, the origin may need 205 to measure the cost of the existing route to a target to determine 206 the constraints. For example, an origin that measures the total ETX 207 along its current route to a target to be 20 may use "ETX < x*20", 208 where x is a fraction that the origin decides, as the constraint. A 209 mechanism to measure the cost of an existing route between two IPv6 210 routers is specified in [I-D.ietf-roll-p2p-measurement]. If there is 211 no existing route between the origin and the target(s) or the cost 212 measurement for the existing routes fails, the origin will have to 213 guess the constraints to be used in the initial route discovery. 214 Once, the initial route discovery succeeds or fails, the origin will 215 have a better estimate for the constraints to be used in the 216 subsequent route discovery. 218 P2P-RPL may result in discovery of better P2P routes than the ones 219 available along a DAG designed to optimize routing cost to the DAG's 220 root. The improvement in route quality depends on a number of 221 factors including the network topology, the routing metrics in use 222 and the prevalent conditions in the network. A network designer may 223 take into consideration both the benefits (potentially better routes; 224 no need to maintain routes proactively) and costs (control messages 225 generated during the route discovery process) when using P2P-RPL. 227 5. Functional Overview 229 This section contains a high level description of P2P-RPL. 231 A P2P-RPL route discovery takes place by forming a DAG rooted at the 232 origin. As is the case with core RPL, P2P-RPL uses IPv6 link-local 233 multicast DIO messages to establish a DAG. However, unlike core RPL, 234 this DAG is temporary in nature and routers in the DAG leave once the 235 DAG's life time is over. The sole purpose of DAG creation is to 236 discover routes to the target(s) and DIOs serve as the route 237 discovery messages. Each router joining the DAG determines a rank 238 for itself in the DAG and ignores the subsequent DIOs received from 239 lower (higher in numerical value) ranked neighbors. Thus, the route 240 discovery messages propagate away from the origin rather than return 241 back to it. As in core RPL, DIO generation at a router is controlled 242 by a Trickle timer [RFC6206] that allows a router to avoid generating 243 unnecessary messages while providing protection against unreliable 244 wireless communication. P2P-RPL also uses the routing metrics 245 [I-D.ietf-roll-routing-metrics], objective functions and packet 246 forwarding framework 247 [I-D.ietf-6man-rpl-routing-header][I-D.ietf-6man-rpl-option] 248 developed for core RPL. 250 An origin may use P2P-RPL to discover routes to one or more targets 251 identified by one or more unicast/multicast addresses. P2P-RPL 252 allows for the discovery of one hop-by-hop route or upto four source 253 routes per target. P2P-RPL allows an origin to piggyback time- 254 critical application data on the DIO messages for delivery to the 255 target(s). P2P-RPL does not guarantee discovery of a route to a 256 target. Also, the discovered routes may not be the best available. 257 However, any discovered routes are guaranteed to satisfy the desired 258 constraints in terms of the routing metrics and are thus considered 259 "good enough" from the application's perspective. 261 A P2P-RPL route discovery takes place by forming a temporary DAG 262 rooted at the origin. The DIOs, used to create the temporary DAG, 263 are identified by a new Mode of Operation (P2P Route Discovery mode 264 defined in Section 6). The DIOs, listing the P2P Route Discovery 265 mode as the Mode of Operation, are henceforth referred to as the P2P 266 mode DIOs. A P2P mode DIO always carries one P2P Route Discovery 267 Option (defined in Section 7.1) in which the origin specifies the 268 following information: 270 o The IPv6 address of a target. This could be a unicast address or 271 a multicast one. Any additional targets may be specified by 272 including one or more RPL Target Options [I-D.ietf-roll-rpl] 273 inside the DIO. 275 o The nature of the route(s) to be discovered: hop-by-hop or source 276 routes. This specification allows for the discovery of one hop- 277 by-hop route or up to four source routes per target. 279 o The desired number of routes (if source routes are being 280 discovered). 282 o Whether the target(s) should send Discovery Reply Object (DRO) 283 messages (defined in Section 8) back to the origin on receiving a 284 DIO message. A DRO message carries a discovered source route back 285 to the origin or establishes a hop-by-hop route between the origin 286 and the target. By not allowing the generation of DRO messages, 287 an origin can use P2P-RPL as purely a mechanism to deliver time- 288 critical application data to the target(s). 290 A P2P Route Discovery Option also accumulates a route from the origin 291 to a target as the routers join the temporary DAG. 293 A P2P mode DIO MAY also carry: 295 o One or more Metric Container Options to specify: 297 * The relevant routing metrics. 299 * The constraints that the discovered route must satisfy. These 300 constraints also limit how far the DIOs message may travel. 302 o One or more RPL Target options to specify additional unicast or 303 multicast targets. 305 o One or more Data Options (defined in Section 7.2) to carry time- 306 critical application-level data to be delivered to the target(s). 308 As the routers join the temporary DAG, they keep track of the best 309 (partial) route(s) they have seen and advertise these routes, along 310 with the corresponding routing metrics, in their P2P mode DIOs. A 311 router, including the target(s), discards a received P2P mode DIO if 312 the aggregated routing metrics on the route advertised by the DIO do 313 not satisfy the listed constraints. These constraints can be used to 314 limit the propagation of P2P mode DIO messages. A router may also 315 discard a received P2P mode DIO if it does not wish to be a part of 316 the discovered route due to limited resources or due to policy 317 reasons. 319 When a target receives a P2P mode DIO, it forwards the data in any 320 Data Options to the higher layer. The target may remember the 321 discovered route for use as a source route to reach the origin. If 322 the origin has requested DRO messages to be sent back, the target may 323 select the route contained in the received DIO for further processing 324 as described next. This document does not specify a particular 325 method for the target to use to select a route for further 326 processing. Example methods include selecting any route that meets 327 the constraints or selecting the best route(s) discovered over a 328 certain time period. 330 If one or more source routes are being discovered, the target sends 331 the selected source routes to the origin via DRO messages with one 332 DRO message carrying one discovered route. On receiving a DRO 333 message, the origin stores the discovered route in its memory. If a 334 hop-by-hop route is being discovered, the target sends a DRO message 335 containing the selected route to the origin. The DRO message travels 336 back to the origin along the selected route, establishing state for 337 this route in the routers on the path. The target may include one or 338 more Data Options in a DRO message to deliver any time-critical 339 application data to the origin. 341 The target may request the origin to acknowledge the receipt of a DRO 342 message by sending back a DRO Acknowledgement (DRO-ACK) message 343 (defined in Section 10). The origin unicasts a DRO-ACK message to 344 the target. When the target does not receive the requested DRO-ACK 345 within a certain time interval of sending a DRO, it resends the DRO 346 message (up to a certain number of times) carrying the same route as 347 before. 349 The use of trickle timers to delay the propagation of DIO messages 350 may cause some nodes to generate these messages even when the desired 351 routes have already been discovered. In order to preempt the 352 generation of such unnecessary messages, the target may set a "stop" 353 flag in the DRO message to let the nodes in the LLN know about the 354 completion of the route discovery process. The routers receiving 355 such a DRO should not generate any more DIOs for this temporary DAG. 356 Neither should they process any received DIOs for this temporary DAG 357 in future. However, such routers must still process the DROs 358 received for this temporary DAG. 360 6. P2P Route Discovery Mode Of Operation 362 This section specifies a new RPL Mode of Operation (MOP), P2P Route 363 Discovery mode (or P2P mode, for short), with value 4 (to be 364 confirmed by IANA). A DIO message, listing P2P mode as the MOP, is 365 identified as performing a P2P-RPL route discovery by creating a 366 temporary DAG. A P2P mode DIO MUST carry one and only one P2P Route 367 Discovery Option (specified in Section 7.1). 369 6.1. Setting a P2P Mode DIO 371 The Base Object in a P2P mode DIO message MUST be set in the 372 following manner: 374 o RPLInstanceID: RPLInstanceID MUST be a local value as described in 375 Section 5.1 of [I-D.ietf-roll-rpl]. The origin MUST NOT use the 376 same RPLInstanceID in two or more concurrent route discoveries. 378 o Version Number: MUST be set to zero. The temporary DAG used for 379 P2P-RPL route discovery does not exist long enough to have new 380 versions. 382 o Grounded (G) Flag: MUST be cleared since this DAG is temporary in 383 nature, is created solely for the purpose of P2P-RPL route 384 discovery and MUST NOT be used for packet routing. 386 o Mode of Operation (MOP): MUST be set to 4, corresponding to P2P 387 Route Discovery mode. 389 o DTSN: MUST be set to value zero on transmission and ignored on 390 reception. 392 o DODAGPreference (Prf): This field MUST be set to value 0 (least 393 preferred). 395 o DODAGID: This field MUST be set to an IPv6 address of the origin. 397 o The other fields in the DIO Base Object can be set in the desired 398 fashion as per the rules described in [I-D.ietf-roll-rpl]. 400 The DODAG Configuration Option, inside a P2P mode DIO MUST be set in 401 the following manner: 403 o MaxRankIncrease: This field MUST be set to 0 to disable local 404 repair of the temporary DAG. 406 o Trickle parameters (DIOIntervalDoublings, DIOIntervalMin, 407 DIORedundancyConstant) SHOULD be set as described in Section 9.2. 409 o The Default Lifetime and Lifetime Unit parameters in DODAG 410 Configuration option indicate the life time of the state the 411 routers maintain for a hop-by-hop route established using P2P-RPL 412 and may be set as desired. 414 o The other fields in the DODAG Configuration Option, including the 415 OCP identifying the Objective function, can be set in the desired 416 fashion as per the rules described in [I-D.ietf-roll-rpl]. 418 A default DODAG Configuration Option comes in effect if a P2P mode 419 DIO does not carry an explicit one. The default DODAG Configuration 420 Option has the following parameter values: 422 o Authentication Enabled: 0 424 o DIOIntervalMin: 6, which translates to 64ms as the value for Imin 425 parameter in Trickle operation. 427 o DIORedundancyConstant: 1 429 o MaxRankIncrease: 0 431 o Default Lifetime: 0xFF 433 o Lifetime Unit: 0xFFFF 435 o Objective Code Point: 0, i.e., OF0 [I-D.ietf-roll-of0] is the 436 default objective function. 438 o The remaining parameters have default values as specified in 439 [I-D.ietf-roll-rpl]. 441 The routing metrics and constraints [I-D.ietf-roll-routing-metrics] 442 used in P2P-RPL route discovery are included in one or more Metric 443 Container Options [I-D.ietf-roll-rpl] inside the P2P mode DIO. Note 444 that a DIO need not include a Metric Container if OF0 is the 445 objective function in effect. In that case, a P2P mode DIO may still 446 specify an upper limit on the maximum rank, that a router may have in 447 the temporary DAG, inside the P2P Route Discovery Option (described 448 in Section 7.1). 450 A P2P mode DIO: 452 o MUST carry one (and only one) P2P Route Discovery Option 453 (described in Section 7.1). The P2P Route Discovery Option allows 454 for the specification of one unicast or multicast address for the 455 target. 457 o MAY carry one or more RPL Target Options to specify additional 458 unicast/multicast addresses for the target. 460 o MAY carry one or more Metric Container Options to specify routing 461 metrics and constraints. 463 o MAY carry one or more Data Options (described in Section 7.2) 464 containing time-critical application data to be delivered to the 465 target(s). 467 o MAY carry one or more Route Information or Prefix Information 468 Options (described in [I-D.ietf-roll-rpl]). 470 A router MUST discard a received P2P mode DIO if it violates any of 471 the rules listed above. 473 7. New RPL Control Message Options 475 This document defines two new RPL control message options: the P2P 476 Route Discovery Option and the Data Option. 478 7.1. P2P Route Discovery Option (P2P-RDO) 480 - 481 0 1 2 3 482 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 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Type = 10 | Option Length |R|H| N | Compr | L |MaxRank/NH | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | | 487 | Target | 488 | | 489 | | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | | 492 | Address[1..n] | 493 | | 494 | | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 Figure 1: Format of P2P Route Discovery Option (P2P-RDO) 499 The format of a P2P Route Discovery Option (P2P-RDO) is illustrated 500 in Figure 1. A P2P mode DIO and a DRO (defined in Section 8) message 501 MUST carry one and at most one P2P-RDO. A P2P-RDO consists of the 502 following fields: 504 o Option Type: 0x0A (to be confirmed by IANA). 506 o Option Length: 8-bit unsigned integer, representing the length in 507 octets of the option, not including the Option Type and Option 508 Length fields. 510 o Reply (R): The origin sets this flag to 1 to allow the target(s) 511 to send DRO messages back to the origin. If this flag is 0, a 512 target MUST NOT generate any DRO message. 514 o Hop-by-hop (H): This flag is valid only if the R flag is set to 1. 515 The origin sets this flag to 1 if it desires hop-by-hop routes. 516 The origin sets this flag to 0 if it desires source routes. This 517 specification allows for the establishment of one hop-by-hop route 518 or up to four source routes per target. The hop-by-hop route is 519 established in the forward direction, i.e. from the origin to the 520 target. This specification does not allow for the establishment 521 of hop-by-hop routes in the backward direction. 523 o Number of Routes (N): This flag is valid only if the R flag is 1 524 and H flag is 0, i.e. the targets are allowed to generate DRO 525 messages carrying discovered source routes back to the origin. In 526 this case, the value in the N field plus one indicates the number 527 of source routes that each target should convey to the origin. 528 When hop-by-hop routes are being discovered, the N field MUST be 529 set to zero on transmission and ignored on reception. 531 o Compr: 4-bit unsigned integer indicating the number of prefix 532 octets that are elided from the Target field and the Address 533 vector. For example, Compr value will be 0 if full IPv6 addresses 534 are carried in the Target field and the Address vector. 536 o Life Time (L): A 2-bit field that indicates the suggested life 537 time of the temporary DAG, i.e., the suggested duration a router 538 joining the temporary DAG SHOULD maintain its membership in the 539 DAG. The mapping between the values in this field and the life 540 time of the temporary DAG is as follows: 542 * 0x00: 1 second; 544 * 0x01: 4 seconds; 546 * 0x02: 16 seconds; 548 * 0x03: 64 seconds; 550 The origin sets this field based on its expectation regarding the 551 time required for the DIOs to reach the target(s). 553 o MaxRank/NH: 555 * When a P2P-RDO is included in a P2P mode DIO, this field 556 indicates the upper limit on the integer portion of the rank 557 (calculated using the DAGRank() macro defined in 558 [I-D.ietf-roll-rpl]) that a router may have in the temporary 559 DAG being created. An intermediate router MUST NOT join a 560 temporary DAG being created by a P2P mode DIO if the integer 561 portion of its rank would be equal to or higher (in numerical 562 value) than the MaxRank limit. A target can join the temporary 563 DAG at a rank whose integer portion is equal to the MaxRank. A 564 router MUST discard a received P2P mode DIO if the integer part 565 of the advertized rank equals or exceeds the MaxRank limit. A 566 value 0 in this field indicates that the MaxRank is infinity. 568 * When a P2P-RDO is included in a DRO message, this field 569 indicates the index of the next hop address inside the Address 570 vector. 572 o Target: An IPv6 address of the target after eliding Compr number 573 of prefix octets. When the P2P-RDO is included in a P2P mode DIO, 574 this field may contain a unicast address or a multicast one. Any 575 additional target addresses can be specified by including one or 576 more RPL Target Options [I-D.ietf-roll-rpl] in the DIO. When the 577 P2P-RDO is included in a DRO, this field MUST contain a unicast 578 IPv6 address of the target generating the DRO. 580 o Address[1..n]: A vector of IPv6 addresses representing a (partial) 581 route in the forward direction: 583 * Each element in the Address vector has size (16 - Compr) octets 584 and MUST contain a valid IPv6 address with first Compr octets 585 elided. 587 * The total number of elements inside the Address vector is given 588 by n = (Option Length - 2 - (16 - Compr))/(16 - Compr). 590 * The IPv6 addresses in the Address vector MUST be accessible in 591 both forward and backward directions. Accessibility in the 592 backward direction allows a DRO message to use the route 593 accumulated in the Address vector to travel from the target to 594 the origin. 596 * The Address vector MUST carry the accumulated route in the 597 forward direction, i.e., the first element in the Address 598 vector must contain the IPv6 address of the router next to the 599 origin and so on. 601 * The origin and target addresses MUST NOT be included in the 602 Address vector. 604 * A router adding its address to the vector MUST ensure that its 605 address does not already exist in the vector. A router 606 specifying a complete route in the Address vector MUST ensure 607 that the vector does not contain any address more than once. 609 * The Address vector MUST NOT contain any multicast addresses. 611 7.2. Data Option 613 0 1 2 3 614 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 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Type = 11 | Option Length | Data | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... | 619 Figure 2: Format of Data Option 621 The format of a Data Option is illustrated in Figure 2. A P2P mode 622 DIO and a DRO (defined in Section 8) message MAY carry one or more 623 Data Options. A P2P-RDO consists of the following fields: 625 o Option Type: 0x0B (to be confirmed by IANA). 627 o Option Length: 8-bit unsigned integer, representing the length in 628 octets of the option, not including the Option Type and Option 629 Length fields. 631 o Data: If the Data Option is contained in a DIO, this field 632 contains application data to be delivered to the target(s). If 633 the Data Option is contained in a DRO, this field contains 634 application data to be delivered to the origin. 636 8. The Discovery Reply Object (DRO) 638 This section defines two new RPL Control Message types, the Discovery 639 Reply Object (DRO), with code 0x04 (to be confirmed by IANA), and the 640 Secure DRO, with code 0x84 (to be confirmed by IANA). A DRO serves 641 one of the following functions: 643 o Carry a discovered source route from a target to the origin; 645 o Establish a hop-by-hop route as it travels from a target to the 646 origin. 648 A DRO message MAY serve the function of letting the routers in the 649 LLN know that a P2P-RPL route discovery is complete and no more DIO 650 messages need to be generated for the corresponding temporary DAG. A 651 DRO message MAY also carry time-critical application data from the 652 target to the origin in one or more Data Options. A DRO message MUST 653 carry one P2P-RDO whose Target field MUST contain a unicast IPv6 654 address of the target that generated the DRO. A DRO message travels 655 from the target to the origin via link-local multicast along the 656 route specified inside the Address vector in the P2P-RDO. 658 0 1 2 3 659 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 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | RPLInstanceID | Version |S|A|Seq| Reserved | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | | 664 | DODAGID | 665 | | 666 | | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | Option(s)... 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 671 Figure 3: Format of the base Discovery Reply Object (DRO) 673 The format of the base Discovery Reply Object (DRO) is shown in 674 Figure 3. A base DRO consists of the following fields: 676 o RPLInstanceID: The RPLInstanceID of the temporary DAG used for 677 route discovery. 679 o Version: The Version of the temporary DAG used for route 680 discovery. Since a temporary DAG always has value zero for the 681 Version, this field MUST always be set to zero. 683 o Stop (S): This flag, when set by a target, indicates that the P2P- 684 RPL route discovery is over. All the routers receiving such a 685 DRO, including the ones not listed in the route carried inside 686 P2P-RDO, 688 * SHOULD NOT process any more DIOs received for this temporary 689 DAG; 691 * SHOULD NOT generate any more DIOs for this temporary DAG; 693 * SHOULD cancel any pending DIO transmission for this temporary 694 DAG. 696 Note that the stop flag serves to stop further DIO transmissions 697 for a P2P-RPL route discovery but it does not affect the 698 processing of DRO messages at either the origin or the 699 intermediate routers. In other words, a router (the origin or an 700 intermediate router) MUST continue to process the DRO messages 701 even if an earlier DRO message (with same RPLInstanceID and 702 DODAGID fields) had the stop flag set to 1. 704 o Ack Required (A): This flag, when set by the target, indicates 705 that the origin MUST unicast a DRO-ACK message (defined in 706 Section 10) to the target when it receives the DRO. 708 o Sequence Number (Seq): This 2-bit field indicates the sequence 709 number for the DRO. This field is relevant when the A flag is 710 set, i.e., the target requests an acknowledgement from the origin 711 for a received DRO. The origin includes the RPLInstanceID, the 712 DODAGID and the Sequence Number of the received DRO inside the 713 DRO-ACK message it sends back to the target. 715 o Reserved: These bits are reserved for future use. These bits MUST 716 be set to zero on transmission and MUST be ignored on reception. 718 o DODAGID: The DODAGID of the temporary DAG used for route 719 discovery. The DODAGID also identifies the origin. The 720 RPLInstanceID, the Version and the DODAGID together uniquely 721 identify the temporary DAG used for route discovery and can be 722 copied from the DIO message advertizing the temporary DAG. 724 o Options: The DRO message: 726 * MUST carry one P2P-RDO that MUST specify a complete route 727 between the target and the origin; 729 * MAY carry one or more Metric Container Options that contains 730 the aggregated routing metrics values for the route specified 731 in P2P-RDO; 733 * MAY carry one or more Data Options to carry any time-critical 734 application data to the origin. 736 8.1. Secure DRO 738 A Secure DRO message follows the format in Figure 7 of 739 [I-D.ietf-roll-rpl], where the base format is the base DRO shown in 740 Figure 3. 742 8.2. Setting a P2P-RDO Carried in a Discovery Reply Object 744 A Discovery Reply Object MUST carry one P2P-RDO, which MUST be set as 745 defined in Section 7.1. Specifically, the following fields MUST be 746 set as specified next: 748 o Reply (R): This flag MUST be set to zero on transmission and 749 ignored on reception. 751 o Hop-by-Hop (H): The H flag in the P2P-RDO included in a DRO 752 message MUST have the same value as the H flag in the P2P-RDO 753 inside the corresponding DIO message. 755 o Number of Routes (N): This field MUST be set to zero on 756 transmission and ignored on reception. 758 o Life Time (L): This field MUST be set to zero on transmission and 759 ignored on reception. 761 o MaxRank/NH: This field indicates the index of the next hop address 762 in the Address vector. When a target generates a DRO message, the 763 NH field is set to n = (Option Length - 2 - (16 - Compr))/(16 - 764 Compr). 766 o Target: This field MUST contain a unicast IPv6 address of the 767 target generating the DRO. 769 o Address[1..n]: The Address vector MUST contain a complete route 770 between the origin and the target such that the first element in 771 the vector contains the IPv6 address of the router next to the 772 origin and the last element contains the IPv6 address of the 773 router next to the target. 775 9. P2P-RPL Route Discovery By Creating a Temporary DAG 777 This section details the functioning of P2P-RPL route discovery by 778 creating a temporary DAG, using the P2P mode DIO, DRO and DRO-ACK 779 messages. 781 9.1. Joining a Temporary DAG 783 All the routers participating in a P2P-RPL route discovery, including 784 the origin and the target(s), MUST join the temporary DAG being 785 created for the purpose. When a router joins a temporary DAG 786 advertized by a P2P mode DIO, it SHOULD maintain its membership in 787 the temporary DAG for the suggested Life Time duration listed in the 788 P2P-RDO. The only purpose of a temporary DAG's existence is to 789 facilitate the P2P-RPL route discovery process. The temporary DAG 790 MUST NOT be used to route packets. A router SHOULD detach from the 791 temporary DAG once the duration of its membership in the DAG has 792 exceeded the DAG's suggested life time. A router SHOULD NOT send or 793 receive any more DIOs for the temporary DAG and SHOULD cancel any 794 pending DIO transmission when it receives a DRO about the temporary 795 DAG with the stop flag set to 1. 797 9.2. Trickle Operation For P2P Mode DIOs 799 An RPL router uses a Trickle timer [RFC6206] to control DIO 800 transmissions. The Trickle control of DIO transmissions provides 801 quick resolution of any "inconsistency" while avoiding redundant DIO 802 transmissions. The Trickle algorithm also imparts protection against 803 loss of DIOs due to inherent lack of reliability in wireless 804 communication. When controlling the transmissions of a P2P mode DIO, 805 a Trickle timer SHOULD follow the following rules: 807 o The receipt of a P2P mode DIO, that allows the router to advertise 808 a better route (in terms of the routing metrics and the OF in use) 809 than before, is considered "inconsistent" and hence resets the 810 Trickle timer. Note that the first receipt of a P2P mode DIO 811 advertising a particular temporary DAG is always considered an 812 "inconsistent" event. 814 o The receipt of a P2P mode DIO from a parent in the temporary DAG 815 is considered neither "consistent" nor "inconsistent" if it does 816 not allow the router to advertise a better route than before. 817 Thus, the receipt of such DIOs has no impact on the Trickle 818 operation. Note that this document does not impose any 819 requirements on how a router might choose its parents in the 820 temporary DAG. 822 o The receipt of a P2P mode DIO is considered "consistent" if the 823 source of the DIO is not a parent in the temporary DAG and either 824 of the following conditions is true: 826 * The DIO advertises a better route than the router but does not 827 allow the router to advertise a better route itself; or 829 * The DIO advertises a route as good as the route (to be) 830 advertised by the router. 832 Note that Trickle algorithm's DIO suppression rules are in effect 833 at all times. Hence, a P2P-RPL router may suppress a DIO 834 transmission even if it has not made any DIO transmission yet. 836 o The receipt of a P2P mode DIO, that advertises a worse route than 837 what the router advertises (or would advertise when it gets a 838 chance to generate its DIO), is considered neither "consistent" 839 nor "inconsistent", i.e., the receipt of such a DIO has no impact 840 on the Trickle operation. 842 o The Imin parameter SHOULD be set taking in account the 843 connectivity within the network. For highly connected networks, a 844 small Imin value (of the order of the typical transmission delay 845 for a DIO) may lead to congestion in the network as a large number 846 of routers reset their Trickle timers in response to the first 847 receipt of a DIO from the origin. These routers would generate 848 their DIOs within Imin interval and cause additional routers to 849 reset their trickle timers and generate more DIOs. Thus, for 850 highly connected networks, the Imin parameter SHOULD be set to a 851 value at least one order of magnitude larger than the typical 852 transmission delay for a DIO. For sparsely connected networks, 853 the Imin parameter can be set to a value that is a small multiple 854 of the typical transmission delay for a DIO. Note that the Imin 855 value has a direct impact on the time required for a P2P-RPL route 856 discovery to complete. In general, the time required for a P2P- 857 RPL route discovery would increase approximately linearly with the 858 value of the Imin parameter. 860 o The Imax parameter SHOULD be set to a large value (several orders 861 of magnitude higher than the Imin value) and is unlikely to be 862 critical for P2P-RPL operation. This is because the first receipt 863 of a P2P mode DIO for a particular temporary DAG is considered an 864 inconsistent event and would lead to resetting of Trickle timer 865 duration to the Imin value. Given the temporary nature of the 866 DAGs used in P2P-RPL, Trickle timer may not get a chance to 867 increase much. 869 o The recommended value of redundancy constant "k" is 1. With this 870 value of "k", a DIO transmission will be suppressed if the router 871 receives even a single "consistent" DIO during a timer interval. 872 This setting for the redundancy constant is designed to reduce the 873 number of messages generated during a route discovery process and 874 is suitable for environments with low or moderate packet loss 875 rates. In environments with high packet loss rates, a higher 876 value for the redundancy constant may be more suitable. 878 9.3. Processing a P2P Mode DIO 880 The rules for DIO processing and transmission, described in Section 8 881 of RPL [I-D.ietf-roll-rpl], apply to P2P mode DIOs as well except as 882 modified in this document. 884 The following rules for processing a received P2P mode DIO apply to 885 both intermediate routers and the target. 887 A router SHOULD discard a received P2P mode DIO with no further 888 processing if it does not have bidirectional reachability with the 889 neighbor that generated the received DIO. Note that bidirectional 890 reachability does not mean that the link must have the same values 891 for a routing metric in both directions. A router SHOULD calculate 892 the values of the link-level routing metrics included in the received 893 DIO taking in account the metric's value in both forward and backward 894 directions. Bidirectional reachability along a discovered route 895 allows the target to use this route to reach the origin. In 896 particular, the DRO messages travel from the target to the origin 897 along a discovered route. 899 A router MUST discard a received P2P mode DIO with no further 900 processing: 902 o If the DIO advertises INFINITE_RANK as defined in 903 [I-D.ietf-roll-rpl]. 905 o If the integer part of the rank advertised in the DIO equals or 906 exceeds the MaxRank limit listed in the P2P Route Discovery 907 Option. 909 o If the router cannot evaluate the mandatory route constraints 910 listed in the DIO or if the routing metric values do not satisfy 911 one or more of the mandatory constraints. 913 o If the router previously received a DRO message with same 914 RPLInstanceID and DODAGID as the received DIO and with the stop 915 flag set to 1. 917 The router MUST check the target addresses listed in the P2P-RDO and 918 any RPL Target Options included in the received DIO. If one of its 919 IPv6 addresses is listed as a target address or if it belongs to the 920 multicast group specified as one of the target addresses, the router 921 considers itself a target and processes the received DIO as specified 922 in Section 9.5. Otherwise, the router considers itself an 923 intermediate router and processes the received DIO as specified in 924 Section 9.4. 926 9.4. Additional Processing of a P2P Mode DIO At An Intermediate Router 928 An intermediate router MUST discard a received P2P mode DIO with no 929 further processing if the router cannot elide Compr (as specified in 930 the P2P-RDO) prefix octets from its IPv6 address. 932 On receiving a P2P mode DIO, an intermediate router MUST determine 933 whether this DIO advertises a better route than the router itself and 934 whether the receipt of the DIO would allow the router to advertise a 935 better route than before. Accordingly, the router SHOULD consider 936 this DIO as consistent/inconsistent from Trickle perspective as 937 described in Section 9.2. Note that the route comparison in a P2P- 938 RPL route discovery is performed using the parent selection rules of 939 the OF in use as specified in Section 14 of RPL [I-D.ietf-roll-rpl]. 940 If the received DIO would allow the router to advertise a better 941 route, the router MUST remember the route advertised (inside the P2P- 942 RDO) in the DIO (after adding its own IPv6 address to the route) as 943 well as any Data Options for inclusion in its future DIOs. When an 944 intermediate router adds itself to a route, it MUST ensure that the 945 IPv6 address added to the route is reachable in both forward and 946 backward directions. To improve the diversity of the routes being 947 discovered, an intermediate router SHOULD keep track of multiple 948 partial routes to be advertised in the P2P-RDO inside its DIO. When 949 the router generates its DIO, it SHOULD randomly select the partial 950 route to be included in the P2P-RDO. 952 9.5. Additional Processing of a P2P Mode DIO At The Target 954 The target MUST deliver the data contained in any Data Options in the 955 received DIO to the application layer. The target MAY store the 956 route contained in the P2P-RDO in the received DIO for use as a 957 source route to reach the origin. If the Reply flag inside the P2P- 958 RDO is 0, the target MUST discard the received DIO with no further 959 processing. Otherwise, the target MAY select the route contained in 960 the P2P-RDO to send a DRO message back to the origin. If the H flag 961 inside the P2P-RDO is 1, the target needs to select one route and 962 send a DRO message along this route back to the origin. If the H 963 flag is 0, the number of routes to be selected (and the number of DRO 964 messages to be sent back) is given by one plus the value of the N 965 field in the P2P-RDO. This document does not prescribe a particular 966 method for the target to select the routes. Example methods include 967 selecting each route that meets the specified routing constraints 968 until the desired number have been selected or selecting the best 969 routes discovered over a certain time period. If multiple routes are 970 to be selected, the target SHOULD avoid selecting routes that have 971 large segments in common. 973 If the target selects the route contained in the P2P-RDO in the 974 received DIO, it sends a DRO message back to the origin (identified 975 by the DODAGID field in the DIO). The DRO message MUST include a 976 P2P-RDO that contains the selected route inside the Address vector. 977 Various fields inside the P2P-RDO MUST be set as specified in 978 Section 8.2. The target MAY set the A flag inside the DRO message if 979 it desires the origin to send back a DRO-ACK message on receiving the 980 DRO. In this case, the target waits for DRO_ACK_WAIT_TIME duration 981 for the DRO-ACK message to arrive. Failure to receive the DRO-ACK 982 message within this time duration causes the target to retransmit the 983 DRO message. The target MAY retransmit the DRO message in this 984 fashion up to MAX_DRO_RETRANSMISSIONS times. The values of 985 DRO_ACK_WAIT_TIME and MAX_DRO_RETRANSMISSIONS are defined in 986 Section 12. 988 The target MAY set the stop flag inside the DRO message if 989 o this router is the only target specified in the corresponding DIO, 990 i.e., the corresponding DIO specified a unicast address of the 991 router as the Target inside the P2P-RDO with no additional targets 992 specified via RPL Target Options; and 994 o the target has already selected the desired number of routes. 996 The target MAY include a Metric Container Option in the DRO message. 997 This Metric Container contains the end-to-end routing metric values 998 for the route specified in the P2P-RDO. The target MAY include one 999 or more Data Options in the DRO message to carry time-critical 1000 application data for the origin. The target MUST transmit the DRO 1001 message via a link-local multicast. 1003 A target MUST NOT forward a P2P mode DIO any further. 1005 9.6. Processing a DRO At An Intermediate Router 1007 When a router receives a DRO message that does not list its IPv6 1008 address in the DODAGID field, the router MUST process the received 1009 message in the following manner: 1011 o If the stop flag inside the received DRO is set, the router SHOULD 1012 NOT send or receive any more DIOs for this temporary DAG and 1013 SHOULD cancel any pending DIO transmission. 1015 o An intermediate router MUST ignore any Metric Container and Data 1016 Options contained in the DRO message. 1018 o If Address[NH] element inside the Route Discovery Option lists the 1019 router's own IPv6 address, the router is a part of the route 1020 carried in the P2P-RDO. In this case, the router MUST do the 1021 following: 1023 * If the H flag inside the P2P-RDO is 0 (i.e., the P2P-RDO is 1024 carrying a source route), the router MAY make a note of the 1025 RPLInstanceID and the DODAGID values listed in the DRO. The 1026 router may need this information to forward a packet traveling 1027 along the discovered source route using a Source Routing Header 1028 (SRH) [I-D.ietf-6man-rpl-routing-header] (see Section 11 for 1029 details). 1031 * If the H flag inside the P2P-RDO is 1, the router MUST store 1032 the state for the forward hop-by-hop route carried inside the 1033 P2P-RDO. This state consists of: 1035 + The RPLInstanceID and the DODAGID fields of the DRO. 1037 + The route's destination, the target (identified by Target 1038 field inside P2P-RDO). 1040 + The IPv6 address of the next hop, Address[NH+1] (unless NH 1041 value equals the number of elements in the Address vector, 1042 in which case the target itself is the next hop). 1044 * If the router already maintains a hop-by-hop state listing the 1045 target as the destination and carrying same RPLInstanceID and 1046 DODAGID fields as the received DRO and the next hop information 1047 in the state does not match the next hop indicated in the 1048 received DRO, the router MUST drop the DRO message with no 1049 further processing. 1051 * The router MUST decrement the NH field inside the P2P-RDO and 1052 send the DRO further via link-local multicast. 1054 9.7. Processing a DRO At The Origin 1056 When a router receives a DRO message that lists its IPv6 address in 1057 the DODAGID field, the router recognizes itself as the origin for the 1058 corresponding P2P-RPL route discovery and processes the message in 1059 the following manner. 1061 The origin MUST deliver data in any Data Options in the received DRO 1062 to the application layer. 1064 If the stop flag inside the received DRO is set, the origin SHOULD 1065 NOT generate any more DIOs for this temporary DAG and SHOULD cancel 1066 any pending DIO transmission. 1068 If the P2P-RDO inside the DRO identifies the discovered route as a 1069 source route (H=0), the origin MUST store in its memory the 1070 discovered route contained in the Address vector. 1072 If the P2P-RDO inside the DRO identifies the discovered route as a 1073 hop-by-hop route (H=1), the origin MUST store in its memory the state 1074 for the discovered route in the manner described in Section 9.6. 1076 If the received DRO message contains one or more Metric Container 1077 Options, the origin MAY store the values of the routing metrics 1078 associated with the discovered route in its memory. This information 1079 may be useful in formulating the constraints for any future P2P-RPL 1080 route discovery to the target. 1082 If the A flag is set to one in the received DRO message, the origin 1083 MUST generate a DRO-ACK message as described in Section 10 and 1084 unicast the message to the target (identified by the Target field 1085 inside the P2P-RDO). The origin MAY use the route just discovered to 1086 send the DRO-ACK message to the target. Section 11 describes how a 1087 packet may be forwarded along a source/hop-by-hop route discovered 1088 using P2P-RPL. 1090 10. The Discovery Reply Object Acknowledgement (DRO-ACK) 1092 0 1 2 3 1093 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 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 | RPLInstanceID | Version |Seq| Reserved | 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 | | 1098 | DODAGID | 1099 | | 1100 | | 1101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 Figure 4: Format of the base Discovery Reply Object Acknowledgement 1104 (DRO-ACK) 1106 A DRO message may fail to reach the origin due to a number of 1107 reasons. Unlike the DIO messages that benefit from Trickle- 1108 controlled retransmissions, the DRO messages are prone to loss due to 1109 unreliable wireless communication. Since a DRO message travels via 1110 link-local multicast, it cannot use link-level acknowledgements to 1111 improve the reliability of its transmission. Also, an intermediate 1112 router may drop the DRO message (e.g., because of its inability to 1113 store the state for the hop-by-hop route the DRO is establishing). 1114 To protect against the potential failure of a DRO message to reach 1115 the origin, the target MAY request the origin to send back a DRO 1116 Acknowledgement (DRO-ACK) message on receiving a DRO message. 1117 Failure to receive such an acknowledgement within the 1118 DRO_ACK_WAIT_TIME interval of sending the DRO message forces the 1119 target to resend the message. 1121 This section defines two new RPL Control Message types: DRO 1122 Acknowledgement (DRO-ACK; with code 0x05; to be confirmed by IANA) 1123 and Secure DRO-ACK (with code 0x85; to be confirmed by IANA). A DRO- 1124 ACK message MUST travel as a unicast message from the origin to the 1125 target. The format of a base DRO-ACK message is shown in Figure 4. 1126 Various fields in a DRO-ACK message MUST have the same values as the 1127 corresponding fields in the DRO message. The field marked as 1128 "Reserved" MUST be set to zero on transmission and MUST be ignored on 1129 reception. A Secure DRO-ACK message follows the format in Figure 7 1130 of [I-D.ietf-roll-rpl], where the base format is same as the base 1131 DRO-ACK shown in Figure 4. 1133 11. Packet Forwarding Along a Route Discovered Using P2P-RPL 1135 An origin MAY use a Source Routing Header (SRH) 1136 [I-D.ietf-6man-rpl-routing-header] to send a packet along a source 1137 route discovered using P2P-RPL. For this purpose, the origin MUST 1138 set the DODAGID of the temporary DAG used for the source route 1139 discovery as the source IPv6 address of the packet. Further, the 1140 origin MUST specify inside the SRH the RPLInstanceID of the temporary 1141 DAG used for the source route discovery. An intermediate router 1142 verifies being on the source route (it must have noted the 1143 RPLInstanceID and DODAGID before forwarding the DRO message, carrying 1144 the source route, towards the origin) before forwarding the packet 1145 further. 1147 Travel along a hop-by-hop route, established using P2P-RPL, requires 1148 specifying the RPLInstanceID and the DODAGID (of the temporary DAG 1149 used for the route discovery) to identify the route. This is because 1150 P2P-RPL route discovery does not use globally unique RPLInstanceID 1151 values and hence both the RPLInstanceID, a local value assigned by 1152 the origin, and the DODAGID, an IPv6 address of the origin, are 1153 required to uniquely identify a P2P-RPL hop-by-hop route to a 1154 particular destination. 1156 An origin MAY include an RPL option [I-D.ietf-6man-rpl-option] inside 1157 the IPv6 hop-by-hop options header of a packet to send it along a 1158 hop-by-hop route established using P2P-RPL. For this purpose, the 1159 origin MUST set the DODAGID of the temporary DAG used for the route 1160 discovery as the source IPv6 address of the packet. Further, the 1161 origin MUST specify inside the RPL option the RPLInstanceID of the 1162 temporary DAG used for the route discovery and set the O flag inside 1163 the RPL option to 1. On receiving this packet, an intermediate 1164 router checks the O flag and correctly infer the source IPv6 address 1165 of the packet as the DODAGID of the hop-by-hop route. The router 1166 then uses the DODAGID, the RPLInstanceID and the destination address 1167 to identify the routing state to be used to forward the packet 1168 further. 1170 12. Constants 1172 This document defines the following constants: 1174 o DRO_ACK_WAIT_TIME: The time duration a target waits for the DRO- 1175 ACK before retransmitting a DRO message. DRO_ACK_WAIT_TIME has a 1176 value of 1 second. 1178 o MAX_DRO_RETRANSMISSIONS: The maximum number of times a DRO message 1179 may be retransmitted if the target does not receive a DRO-ACK in 1180 response. MAX_DRO_RETRANSMISSIONS has a value 2. 1182 13. Interoperability with Core RPL 1184 This section describes how RPL routers that implement P2P-RPL 1185 interact with RPL routers that do not. In general, P2P-RPL operation 1186 does not affect core RPL operation and vice versa. However, core RPL 1187 does allow a router to join a DAG as a leaf node even if it does not 1188 understand the Mode of Operation (MOP) used in the DAG. Thus, an RPL 1189 router that does not implement P2P-RPL may conceivably join a 1190 temporary DAG being created for a P2P-RPL route discovery as a leaf 1191 node and maintain its membership even though the DAG no longer 1192 exists. This may impose a drain on the router's memory. However, 1193 such RPL-only leaf nodes do not interfere with P2P-RPL route 1194 discovery since a leaf node may only generate a DIO advertising an 1195 INFINITE_RANK and all routers implementing P2P-RPL are required to 1196 discard such DIOs. Note that core RPL does not require a router to 1197 join a DAG whose MOP it does not understand. Moreover, RPL routers 1198 in a particular deployment may have strict restrictions on the DAGs 1199 they may join, thereby mitigating the problem. 1201 The P2P-RPL mechanism described in this document works best when all 1202 the RPL routers in the LLN implement P2P-RPL. In general, the 1203 ability to discover routes as well as the quality of discovered 1204 routes would deteriorate with the fraction of RPL routers that 1205 implement P2P-RPL. 1207 14. Security Considerations 1209 The security considerations for the operation of P2P-RPL are similar 1210 to the ones for the operation of RPL (as described in Section 19 of 1211 [I-D.ietf-roll-rpl]). Section 10 of RPL specification 1212 [I-D.ietf-roll-rpl] describes a variety of security mechanisms that 1213 provide data confidentiality, authentication, replay protection and 1214 delay protection services. Each RPL control message has a secure 1215 version that allows the specification of the level of security and 1216 the algorithms used to secure the message. The mechanism defined in 1217 this document is based on the use of DIOs to form a temporary DAG and 1218 discover P2P routes. These DIOs can be used in their secure versions 1219 if desired. New RPL control messages defined in this document (DRO 1220 and DRO-ACK) have secure versions as well. Thus, a particular P2P- 1221 RPL deployment can analyze its security requirements and use the 1222 appropriate set of RPL security mechanisms that meet those 1223 requirements. 1225 15. IANA Considerations 1227 15.1. Additions to DIO Mode of Operation 1229 IANA is requested to allocate a new value in the "DIO Mode of 1230 Operation" registry for the "P2P Route Discovery Mode" described in 1231 this document. 1233 +----------+-----------------------------------------+--------------+ 1234 | MOP | Description | Reference | 1235 | Value | | | 1236 +----------+-----------------------------------------+--------------+ 1237 | 4 | Reactive P2P route discovery mode of | This | 1238 | | operation | document | 1239 +----------+-----------------------------------------+--------------+ 1241 DIO Mode of Operation 1243 15.2. Additions to RPL Control Message Options 1245 IANA is requested to allocate new values in the "RPL Control Message 1246 Options" registry for the "P2P Route Discovery Option" and the "Data 1247 Option" described in this document. 1249 +-------+---------------------+---------------+ 1250 | Value | Meaning | Reference | 1251 +-------+---------------------+---------------+ 1252 | 10 | P2P Route Discovery | This document | 1253 | 11 | Data | This document | 1254 +-------+---------------------+---------------+ 1256 RPL Control Message Options 1258 15.3. Additions to RPL Control Codes 1260 IANA is requested to allocate new code points in the "RPL Control 1261 Codes" registry for the "Discovery Reply Object" and "Discovery Reply 1262 Object Acknowledgement" (and their secure versions) described in this 1263 document. 1265 +------+--------------------------------------------+---------------+ 1266 | Code | Description | Reference | 1267 +------+--------------------------------------------+---------------+ 1268 | 0x04 | Discovery Reply Object | This document | 1269 | 0x05 | Discovery Reply Object Acknowledgement | This document | 1270 | 0x84 | Secure Discovery Reply Object | This document | 1271 | 0x85 | Secure Discovery Reply Object | This document | 1272 | | Acknowledgement | | 1273 +------+--------------------------------------------+---------------+ 1275 RPL Control Codes 1277 16. Acknowledgements 1279 Authors gratefully acknowledge the contributions of the following 1280 individuals (in alphabetical order) in the development of this 1281 document: Dominique Barthel, Jakob Buron, Thomas Clausen, Richard 1282 Kelsey, Phil Levis, Zach Shelby, Pascal Thubert, Hristo Valev and JP 1283 Vasseur. 1285 17. References 1287 17.1. Normative References 1289 [I-D.ietf-roll-routing-metrics] 1290 Barthel, D., Vasseur, J., Pister, K., Kim, M., and N. 1291 Dejean, "Routing Metrics used for Path Calculation in Low 1292 Power and Lossy Networks", 1293 draft-ietf-roll-routing-metrics-19 (work in progress), 1294 March 2011. 1296 [I-D.ietf-roll-rpl] 1297 Brandt, A., Vasseur, J., Hui, J., Pister, K., Thubert, P., 1298 Levis, P., Struik, R., Kelsey, R., Clausen, T., and T. 1299 Winter, "RPL: IPv6 Routing Protocol for Low power and 1300 Lossy Networks", draft-ietf-roll-rpl-19 (work in 1301 progress), March 2011. 1303 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1304 Requirement Levels", BCP 14, RFC 2119, March 1997. 1306 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 1307 "The Trickle Algorithm", RFC 6206, March 2011. 1309 17.2. Informative References 1311 [I-D.ietf-6man-rpl-option] 1312 Hui, J. and J. Vasseur, "RPL Option for Carrying RPL 1313 Information in Data-Plane Datagrams", 1314 draft-ietf-6man-rpl-option-06 (work in progress), 1315 December 2011. 1317 [I-D.ietf-6man-rpl-routing-header] 1318 Culler, D., Hui, J., Vasseur, J., and V. Manral, "An IPv6 1319 Routing Header for Source Routes with RPL", 1320 draft-ietf-6man-rpl-routing-header-07 (work in progress), 1321 December 2011. 1323 [I-D.ietf-roll-of0] 1324 Thubert, P., "RPL Objective Function Zero", 1325 draft-ietf-roll-of0-20 (work in progress), September 2011. 1327 [I-D.ietf-roll-p2p-measurement] 1328 Goyal, M., Baccelli, E., Brandt, A., and J. Martocci, "A 1329 Mechanism to Measure the Quality of a Point-to-point Route 1330 in a Low Power and Lossy Network", 1331 draft-ietf-roll-p2p-measurement-02 (work in progress), 1332 October 2011. 1334 [I-D.ietf-roll-terminology] 1335 Vasseur, J., "Terminology in Low power And Lossy 1336 Networks", draft-ietf-roll-terminology-06 (work in 1337 progress), September 2011. 1339 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 1340 Routing Requirements in Low-Power and Lossy Networks", 1341 RFC 5826, April 2010. 1343 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 1344 "Building Automation Routing Requirements in Low-Power and 1345 Lossy Networks", RFC 5867, June 2010. 1347 Authors' Addresses 1349 Mukul Goyal (editor) 1350 University of Wisconsin Milwaukee 1351 3200 N Cramer St 1352 Milwaukee, WI 53201 1353 USA 1355 Phone: +1 414 2295001 1356 Email: mukul@uwm.edu 1358 Emmanuel Baccelli 1359 INRIA 1361 Phone: +33-169-335-511 1362 Email: Emmanuel.Baccelli@inria.fr 1363 URI: http://www.emmanuelbaccelli.org/ 1365 Matthias Philipp 1366 INRIA 1368 Phone: +33-169-335-511 1369 Email: Matthias.Philipp@inria.fr 1371 Anders Brandt 1372 Sigma Designs 1373 Emdrupvej 26A, 1. 1374 Copenhagen, Dk-2100 1375 Denmark 1377 Phone: +45-29609501 1378 Email: abr@sdesigns.dk 1380 Jerald Martocci 1381 Johnson Controls 1382 507 E Michigan St 1383 Milwaukee, WI 53202 1384 USA 1386 Phone: +1 414-524-4010 1387 Email: jerald.p.martocci@jci.com