idnits 2.17.1 draft-ietf-roll-p2p-rpl-07.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 (January 29, 2012) is 4471 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'NH' is mentioned on line 911, 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: August 1, 2012 E. Baccelli 6 M. Philipp 7 INRIA 8 A. Brandt 9 Sigma Designs 10 J. Martocci 11 Johnson Controls 12 January 29, 2012 14 Reactive Discovery of Point-to-Point Routes in Low Power and Lossy 15 Networks 16 draft-ietf-roll-p2p-rpl-07 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 and establish, on demand, a route to 23 another IPv6 router in the LLN such that the discovered route meets 24 specified metrics constraints, without necessarily going along the 25 DAG links established by core RPL. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on August 1, 2012. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. The Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 65 5. Functional Overview . . . . . . . . . . . . . . . . . . . . . 5 66 6. P2P Route Discovery Mode Of Operation . . . . . . . . . . . . 7 67 6.1. Setting a P2P Mode DIO . . . . . . . . . . . . . . . . . . 8 68 7. P2P Route Discovery Option (P2P-RDO) . . . . . . . . . . . . . 10 69 8. The Discovery Reply Object (DRO) . . . . . . . . . . . . . . . 13 70 8.1. Secure DRO . . . . . . . . . . . . . . . . . . . . . . . . 14 71 8.2. Setting a P2P-RDO Carried in a Discovery Reply Object . . 15 72 9. P2P-RPL Route Discovery By Creating a Temporary DAG . . . . . 15 73 9.1. Joining a Temporary DAG . . . . . . . . . . . . . . . . . 15 74 9.2. Trickle Operation For P2P Mode DIOs . . . . . . . . . . . 16 75 9.3. Processing a P2P Mode DIO . . . . . . . . . . . . . . . . 17 76 9.4. Additional Processing of a P2P Mode DIO At An 77 Intermediate Router . . . . . . . . . . . . . . . . . . . 18 78 9.5. Additional Processing of a P2P Mode DIO At The Target . . 19 79 9.6. Processing a DRO At An Intermediate Router . . . . . . . . 19 80 9.7. Processing a DRO At The Origin . . . . . . . . . . . . . . 20 81 10. The Discovery Reply Object Acknowledgement (DRO-ACK) . . . . . 21 82 11. Packet Forwarding Along a P2P-RPL Route . . . . . . . . . . . 22 83 12. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 23 84 13. Interoperability With Core RPL . . . . . . . . . . . . . . . . 23 85 14. Security Considerations . . . . . . . . . . . . . . . . . . . 23 86 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 87 15.1. Additions to DIO Mode of Operation . . . . . . . . . . . . 24 88 15.2. Additions to RPL Control Message Options . . . . . . . . . 24 89 15.3. Additions to RPL Control Codes . . . . . . . . . . . . . . 25 90 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 91 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 92 17.1. Normative References . . . . . . . . . . . . . . . . . . . 25 93 17.2. Informative References . . . . . . . . . . . . . . . . . . 26 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 96 1. Introduction 98 Targeting Low power and Lossy Networks (LLNs), the RPL routing 99 protocol [I-D.ietf-roll-rpl] provides paths along a Directed Acyclic 100 Graph (DAG) rooted at a single router in the network. Establishment 101 and maintenance of the DAG is performed by each router in the LLN 102 using specific link-local multicast signaling (DIO messages). 104 When two arbitrary routers (neither of which is the DAG's root) need 105 to communicate, core RPL provides dog-legged paths along DAG links, 106 which may not be efficient enough for several Home and Building 107 Automation applications [RFC5826][RFC5867], for the following 108 reasons: 110 o The need to preprovision routes: each potential destination in the 111 network must declare itself as such, via specific additional 112 signaling (DAO messages). 114 o The need to route along DAG links: depending on the network 115 topology and metrics in use, the constraint to route along a DAG 116 may cause significantly suboptimal P2P routes and severe traffic 117 congestion near the DAG root. 119 This document thus describes a mechanism, complementary to the core 120 RPL functionality, that enables a router to discover on-demand a 121 route to another arbitrary router in the LLN, such that the 122 discovered route meets specified metrics constraints, without 123 necessarily going along an existing DAG. This reactive P2P route 124 discovery mechanism is henceforth referred to as P2P-RPL. P2P-RPL 125 allows for the discovery of source routes as well as hop-by-hop 126 routes. Discovered routes may not be the best available but are 127 guaranteed to satisfy the desired constraints in terms of the routing 128 metrics and are thus considered "good enough" from the application's 129 perspective. 131 A complementary functionality that helps decide whether or not to 132 initiate a P2P route discovery, is a mechanism to measure the end-to- 133 end cost of an existing route. Section 4 provides further details on 134 how such functionality, specified in [I-D.ietf-roll-p2p-measurement], 135 is used to determine the value of metric constraints for the route 136 discovery using P2P-RPL. 138 2. The Use Cases 140 P2P-RPL is intended to be employed as complementary to RPL in 141 specific scenarios that need P2P paths between arbitrary routers. 143 One use case, common in a home environment, involves a remote control 144 (or a motion sensor) that suddenly needs to communicate with a lamp 145 module, whose network address is a-priori known. In this case, the 146 source of data (the remote control or the motion sensor) must be able 147 to discover a route to the destination (the lamp module) "on demand". 149 Another use case, common in a large commercial building environment, 150 involves a large LLN deployment where P2P communication along a 151 particular DAG among hundreds (or thousands) of routers creates 152 severe traffic congestion near that DAG's root, and thus routes 153 across this DAG are desirable. 155 The use cases also include scenarios where energy or latency 156 constraints are not satisfied by the routes provided by core RPL 157 along a DAG because they involve traversing many more intermediate 158 routers than necessary to reach the destination. 160 3. Terminology 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 164 "OPTIONAL" in this document are to be interpreted as described in 165 [RFC2119]. 167 Additionally, this document uses terminology from 168 [I-D.ietf-roll-terminology] and [I-D.ietf-roll-rpl]. This document 169 introduces the following terms: 171 Origin : The RPL router initiating the P2P route discovery. 173 Target : The RPL router at the other end point of the P2P route(s) to 174 be discovered. 176 Intermediate Router: An RPL router that is neither the origin nor the 177 target. 179 Forward Route: A route in the forward direction, i.e., from the 180 origin to the target. 182 Backward Route: A route in the backward direction, i.e., from the 183 target to the origin. 185 Bidirectional Route: A route that can be used in both forward and 186 backward directions. 188 Source Route: A complete and ordered list of routers that can be used 189 by a packet to travel from a source to a destination node. 191 Hop-by-hop Route: The route characterized by each router on the route 192 using its routing table to determine the next hop on the route. 194 4. Applicability 196 A route discovery using P2P-RPL may be performed by an origin when no 197 route exists between itself and the target or when the existing 198 routes do not satisfy the application requirements. P2P-RPL is 199 designed to discover and establish one hop-by-hop route or discover 200 one or more source routes such that the discovered route(s) meet the 201 specified constraints. In some application contexts, the constraints 202 that the discovered route(s) must satisfy are intrinsically known or 203 can be specified by the application. For example, an origin that 204 expects a target to be less than 5 hops away may use "hop-count < 5" 205 as the constraint. In other application contexts, the origin may 206 need to measure the cost of an existing route to the target to 207 determine the constraints. For example, an origin that measures the 208 total ETX of its along-DAG route to the target to be 20 may use "ETX 209 < x*20", where x is a fraction that the origin decides, as the 210 constraint. A mechanism to measure the cost of an existing route 211 between the origin and the target is specified in 212 [I-D.ietf-roll-p2p-measurement]. If there is no existing route 213 between the origin and target or the cost measurement for the 214 existing route fails, the origin will have to guess the constraints 215 used in the initial route discovery. Once, the initial route 216 discovery succeeds or fails, the origin will have a better estimate 217 for the constraints to be used in the subsequent route discovery. 219 P2P-RPL may result in discovery of better P2P routes than the ones 220 available along a DAG designed to optimize routing cost to the DAG's 221 root. The improvement in route quality depends on a number of 222 factors including the network topology, the routing metrics in use 223 and the prevalent conditions in the network. A network designer may 224 take into consideration both the benefits (potentially better routes; 225 no need to maintain routes proactively) and costs (control messages 226 generated during the route discovery process) when using P2P-RPL. 228 5. Functional Overview 230 This section contains a high level description of P2P-RPL. 232 As is the case with core RPL, P2P-RPL uses IPv6 link-local multicast 233 DIO messages to establish a DAG (unlike core RPL, this DAG is 234 temporary). Each router joining the DAG determines a rank for itself 235 in the DAG and ignores the subsequent DIO messages received from 236 lower (higher in numerical value) ranked neighbors. Thus, the DIO 237 messages propagate outward from the DAG root rather than return 238 inward towards the DAG root. As in core RPL, DIO message generation 239 at a router is further controlled by a Trickle timer that allows a 240 router to avoid generating unnecessary messages [RFC6206]. P2P-RPL 241 also uses the routing metrics [I-D.ietf-roll-routing-metrics], 242 objective functions and packet forwarding framework specified for 243 core RPL. 245 In P2P-RPL, a route discovery takes place by forming a temporary DAG 246 rooted at the origin. The DIOs, used to create the temporary DAG, 247 are identified by a new Mode of Operation (P2P Route Discovery mode 248 defined in Section 6) and carry the following information (in a P2P 249 Route Discovery Option defined in Section 7): 251 o An IPv6 address of the target. 253 o The nature of the route(s) to be discovered: hop-by-hop or source 254 routes. This specification allows for the discovery of one hop- 255 by-hop route or up to four source routes in the forward direction. 257 o The desired number of routes (if source routes are being 258 discovered). 260 o Whether the route(s) need to be bidirectional. If bidirectional 261 route(s) are being discovered, the target may store the route in 262 backward direction for use as a source route. This specification 263 does not provide for the establishment of backward hop-by-hop 264 routes. 266 The DIOs, listing the P2P Route Discovery mode as the Mode of 267 Operation, are henceforth referred to as the P2P mode DIOs. The P2P 268 mode DIOs MAY also carry the following information (in one or more 269 Metric Container Options): 271 o The relevant routing metrics 273 o The constraints that the discovered route must satisfy. These 274 constraints also limit how far the DIOs message may travel. 276 As the routers join the temporary DAG, they keep track of the best 277 (partial) route(s) they have seen and advertise these routes, along 278 with the corresponding routing metrics, in their P2P mode DIOs. The 279 routing metrics are measured in forward direction unless 280 bidirectional routes are being discovered, in which case the 281 measurement of routing metrics need to take into account both forward 282 and backward directions. A router, including the target, discards a 283 received P2P mode DIO if the aggregated routing metrics on the route 284 advertised by the DIO do not satisfy the listed constraints. These 285 constraints can be used to limit the propagation of P2P mode DIO 286 messages. A router may also discard a received P2P mode DIO if it 287 does not wish to be a part of the discovered route due to limited 288 resources or due to policy reasons. 290 When the target receives a P2P mode DIO, it checks whether the route 291 advertised therein satisfies the routing constraints. If yes, the 292 target may select the route for further processing as described next. 293 This document does not specify a particular method for the target to 294 select a route among the ones that satisfy the route constraints. 295 Examples include selecting any route that meets the constraints or 296 selecting the best route(s) discovered over a certain time period. 298 If one or more source routes are being discovered, the target sends 299 the discovered source routes to the origin via Discovery Reply Object 300 (DRO) messages (defined in Section 8) with one DRO message carrying 301 one discovered route. On receiving a DRO message, the origin stores 302 the route contained therein in its memory. 304 If a hop-by-hop route is being discovered, the target sends a DRO 305 message to the origin after selecting a suitable route among the ones 306 that satisfy the route constraints. The DRO message travels towards 307 the origin along the discovered route, establishing state for this 308 route in the routers on the path. 310 The target may store a discovered route in its memory if it is 311 bidirectional and use it as a backward source-route to send packets 312 to the origin. 314 The target may request the origin to acknowledge the receipt of a DRO 315 message by sending back a DRO Acknowledgement (DRO-ACK) message 316 (defined in Section 10). The origin unicasts a DRO-ACK message to 317 the target. When the target does not receive the requested DRO-ACK 318 within a certain time interval of sending a DRO, it resends the DRO 319 message (up to a certain number of times) carrying the same route as 320 before. 322 The use of trickle timers to delay the propagation of DIO messages 323 may cause some nodes to generate these messages even when the desired 324 routes have already been discovered. In order to preempt the 325 generation of such unnecessary messages, the target may set a "stop" 326 bit in the DRO message to let the nodes in the LLN know about the 327 completion of the route discovery process. 329 6. P2P Route Discovery Mode Of Operation 331 This section specifies a new RPL Mode of Operation (MOP), P2P Route 332 Discovery mode (or P2P mode, for short), with value 4 (to be 333 confirmed by IANA). A DIO message, listing P2P mode as the MOP, is 334 identified as performing reactive P2P route discovery by creating a 335 temporary DAG. A P2P mode DIO MUST carry one P2P Route Discovery 336 Option (specified in Section 7). 338 6.1. Setting a P2P Mode DIO 340 The Base Object in a P2P mode DIO message MUST be set in the 341 following manner: 343 o RPLInstanceID: RPLInstanceID MUST be a local value as described in 344 Section 5.1 of [I-D.ietf-roll-rpl]. The origin MUST NOT use the 345 same RPLInstanceID in two or more concurrent route discoveries. 346 The origin MAY use the same RPLInstanceID value to establish hop- 347 by-hop P2P-RPL routes to different target routers as long as these 348 route discoveries are not concurrent. 350 o Version Number: MUST be set to zero. The temporary DAG used for 351 P2P-RPL route discovery does not exist long enough to have new 352 versions. 354 o Grounded (G) Flag: MUST be cleared since this DAG is temporary in 355 nature, is created solely for the purpose of P2P-RPL route 356 discovery and MUST NOT be used for packet routing. 358 o Mode of Operation (MOP): MUST be set to 4, corresponding to P2P 359 Route Discovery mode. 361 o DTSN: MUST be set to value zero on transmission and ignored on 362 reception. 364 o DODAGPreference (Prf): This field MUST be set to value 0 (least 365 preferred). 367 o DODAGID: This field MUST be set to an IPv6 address of the origin. 369 o The other fields in the DIO Base Object can be set in the desired 370 fashion as per the rules described in [I-D.ietf-roll-rpl]. 372 The DODAG Configuration Option, inside a P2P mode DIO MUST be set in 373 the following manner: 375 o MaxRankIncrease: This field MUST be set to 0 to disable local 376 repair of the temporary DAG. 378 o Trickle parameters (DIOIntervalDoublings, DIOIntervalMin, 379 DIORedundancyConstant) SHOULD be set as described in Section 9.2. 381 o The Default Lifetime and Lifetime Unit parameters in DODAG 382 Configuration option indicate the life time of the state the 383 routers maintain for a hop-by-hop route established using P2P-RPL 384 and may be set as desired. 386 o The other fields in the DODAG Configuration Option, including the 387 OCP identifying the Objective function, can be set in the desired 388 fashion as per the rules described in [I-D.ietf-roll-rpl]. 390 A default DODAG Configuration Option comes in effect if a P2P mode 391 DIO does not carry an explicit one. The default DODAG Configuration 392 Option has the following parameter values: 394 o Authentication Enabled: 0 396 o DIOIntervalMin: 6, which translates to 64ms as the value for Imin 397 parameter in Trickle operation. 399 o DIORedundancyConstant: 1 401 o MaxRankIncrease: 0 403 o Default Lifetime: 0xFF 405 o Lifetime Unit: 0xFFFF 407 o Objective Code Point: 0, i.e., OF0 [I-D.ietf-roll-of0] is the 408 default objective function. 410 o The remaining parameters have default values as specified in 411 [I-D.ietf-roll-rpl]. 413 The routing metrics and constraints [I-D.ietf-roll-routing-metrics] 414 used in P2P-RPL route discovery are included in one or more Metric 415 Container options [I-D.ietf-roll-rpl] inside the P2P mode DIO. Note 416 that a DIO need not include a Metric Container if OF0 is the 417 objective function in effect. In that case, a P2P mode DIO may still 418 specify an upper limit on the maximum rank, that a router may have in 419 the temporary DAG, inside the P2P Route Discovery Option (described 420 in Section 7). 422 A P2P mode DIO: 424 o MUST NOT carry any Route Information or Prefix Information Options 425 (described in [I-D.ietf-roll-rpl]). 427 o MUST carry one (and only one) P2P Route Discovery Option 428 (described in Section 7). 430 A router MUST discard a received P2P mode DIO if it violates any of 431 the rules listed above. 433 7. P2P Route Discovery Option (P2P-RDO) 435 This section specifies a new RPL option, P2P Route Discovery Option 436 (P2P-RDO), one instance of which MUST be carried inside a P2P mode 437 DIO message. 439 0 1 2 3 440 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 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Type = 10 | Option Length |D|H| N | Compr | L |MaxRank/NH | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | | 445 | Target | 446 | | 447 | | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | | 450 | Address[1..n] | 451 | | 452 | | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 Figure 1: Format of P2P Route Discovery Option (P2P-RDO) 457 The format of a P2P-RDO is illustrated in Figure 1. A P2P mode DIO 458 and a DRO (defined in Section 8 message MUST carry one P2P-RDO. A 459 P2P-RDO consists of the following fields: 461 o Option Type: 0x0A (to be confirmed by IANA). 463 o Option Length: 8-bit unsigned integer, representing the length in 464 octets of the option, not including the Option Type and Option 465 Length fields. 467 o Direction (D): This flag indicates the direction in which the 468 desired routes should be optimized. The flag is set to 1 if the 469 routes are to be optimized for use in both forward and backward 470 directions. If the discovered routes need to be optimized in the 471 forward direction only, the flag is reset to 0. Note that the 472 discovered routes should have bidirectional reachability 473 irrespective of the value of the D flag. This is because DRO 474 messages travel from the target back to the origin along one of 475 the discovered routes. The link-level metric objects contained in 476 the P2P mode DIO SHOULD be measured in the direction indicated by 477 the D flag. 479 o Hop-by-hop (H): This flag is set to 1 if a hop-by-hop route is 480 desired. The flag is reset to zero if source routes are desired. 481 This specification allows for the establishment of one hop-by-hop 482 route or up to four source routes in the forward direction. This 483 specification does not allow for the establishment of hop-by-hop 484 routes in the backward direction. If a bidirectional route is 485 discovered, the target MAY use the route in backward direction as 486 a source route to reach the origin, irrespective of the value of 487 the H flag. 489 o Number of Routes (N): When source routes are being discovered, the 490 value in this field plus one indicates the desired number of 491 routes. When a hop-by-hop route is being discovered this field 492 MUST be set to zero on transmission and ignored on reception. 494 o Compr: 4-bit unsigned integer indicating the number of prefix 495 octets that are elided from the Target field and the Address 496 vector. For example, Compr value will be 0 if full IPv6 addresses 497 are carried in the Target field and the Address vector. 499 o Life Time (L): A 2-bit field that indicates the suggested life 500 time of the temporary DAG, i.e., the suggested duration a router 501 joining the temporary DAG SHOULD maintain its membership in the 502 DAG. The mapping between the values in this field and the life 503 time of the temporary DAG is as follows: 505 * 0x00: 1 second; 507 * 0x01: 4 seconds; 509 * 0x02: 16 seconds; 511 * 0x03: 64 seconds; 513 The origin sets this field based on its expectation regarding the 514 time required for the DIOs to reach the target. Note that a 515 router MAY detach from the temporary DAG sooner if it receives a 516 DRO message concerning this DAG with "stop" bit set. 518 o MaxRank/NH: 520 * When a P2P Route Disovery Option is included in a P2P mode DIO, 521 this field indicates the upper limit on the integer portion of 522 the rank (calculated using the DAGRank() macro defined in 523 [I-D.ietf-roll-rpl]) that a router may have in the temporary 524 DAG being created. An intermediate router MUST NOT join a 525 temporary DAG being created by a P2P mode DIO if the integer 526 portion of its rank would be equal to or higher (in numerical 527 value) than the MaxRank limit. The target can join the 528 temporary DAG at a rank whose integer portion is equal to the 529 MaxRank. A router MUST discard a received P2P mode DIO if the 530 integer part of the advertized rank equals or exceeds the 531 MaxRank limit. A value 0 in this field indicates that the 532 MaxRank is infinity. 534 * When a P2P-RDO is included in a DRO message, this field 535 indicates the index of the next hop address inside the Address 536 vector. 538 o Target: The IPv6 address of the target after eliding Compr number 539 of prefix octets. 541 o Address[1..n]: A vector of IPv6 addresses representing a (partial) 542 route in the forward direction: 544 * Each element in the Address vector has size (16 - Compr) octets 545 and MUST contain a valid IPv6 address with first Compr octets 546 elided. 548 * The total number of elements inside the Address vector is given 549 by n = (Option Length - 2 - (16 - Compr))/(16 - Compr). 551 * The Address vector is used to accumulate a route optimized in 552 the direction specified by the D flag. 554 * The IPv6 addresses in the Address vector MUST be accessible in 555 both forward and backward directions. Accessibility in the 556 backward direction is required because the DRO message uses the 557 route accumulated in the Address vector to travel from the 558 target to the origin. 560 * The Address vector MUST carry the accumulated route in the 561 forward direction, i.e., the first element in the Address 562 vector must contain the IPv6 address of the router next to the 563 origin and so on. 565 * The origin and target addresses MUST NOT be included in the 566 Address vector. 568 * A router adding its address to the vector MUST ensure that its 569 address does not already exist in the vector. A router 570 specifying a complete route in the Address vector MUST ensure 571 that the vector does not contain any address more than once. 573 * The Address vector MUST NOT contain any multicast addresses. 575 8. The Discovery Reply Object (DRO) 577 This section defines two new RPL Control Message types, the Discovery 578 Reply Object (DRO), with code 0x04 (to be confirmed by IANA), and the 579 Secure DRO, with code 0x84 (to be confirmed by IANA). A DRO serves 580 one of the following functions: 582 o Carry a discovered source route from the target to the origin; 584 o Establish a hop-by-hop route as it travels from the target to the 585 origin. 587 A DRO message MAY also serve the function of letting the routers in 588 the LLN know that a P2P-RPL route discovery is complete and no more 589 DIO messages need to be generated for the corresponding temporary 590 DAG. A DRO message MUST carry one P2P-RDO and travel from the target 591 to the origin via link-local multicast along the route specified 592 inside the Address vector in the P2P-RDO. 594 0 1 2 3 595 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 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | RPLInstanceID | Version |Seq|S|A| Reserved | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | | 600 | DODAGID | 601 | | 602 | | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | Option(s)... 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 607 Figure 2: Format of the base Discovery Reply Object (DRO) 609 The format of the base Discovery Reply Object (DRO) is shown in 610 Figure 2. A base DRO consists of the following fields: 612 o RPLInstanceID: The RPLInstanceID of the temporary DAG used for 613 route discovery. 615 o Version: The Version of the temporary DAG used for route 616 discovery. Since a temporary DAG always has value zero for the 617 Version, this field MUST always be set to zero. 619 o Sequence Number (Seq): This 2-bit field indicates the sequence 620 number for the DRO. This field is relevant when the A flag 621 (specified below) is set, i.e., the target requests an 622 acknowledgement from the origin for a received DRO. The origin 623 includes the RPLInstanceID, the DODAGID and the Sequence Number of 624 the received DRO inside the DRO-ACK message it sends back to the 625 target. 627 o Stop (S): This flag, when set by the target, indicates that the 628 P2P-RPL route discovery is over. All the routers receiving such a 629 DRO, including the ones not listed in the route carried inside 630 P2P-RDO, SHOULD cancel any pending DIO transmissions for the 631 temporary DAG created for the route discovery and MAY detach from 632 this DAG immediately. Note that the stop flag serves to stop 633 further DIO transmissions for a P2P-RPL route discovery but it 634 does not affect the processing of DRO messages at either the 635 origin or the intermediate routers. In other words, a router (the 636 origin or an intermediate router) MUST continue to process the DRO 637 messages even if an earlier DRO message (with same RPLInstanceID, 638 DODAGID and Version Number fields) had the stop flag set. 640 o Ack Required (A): This flag, when set by the target, indicates 641 that the origin SHOULD unicast a DRO-ACK message (defined in 642 Section 10) to the target when it receives the DRO. 644 o Reserved: These bits are reserved for future use. These bits MUST 645 be set to zero on transmission and MUST be ignored on reception. 647 o DODAGID: The DODAGID of the temporary DAG used for route 648 discovery. The DODAGID also identifies the origin. The 649 RPLInstanceID, the Version and the DODAGID together uniquely 650 identify the temporary DAG used for route discovery and can be 651 copied from the DIO message advertizing the temporary DAG. 653 o Options: The DRO message MUST carry one P2P-RDO that MUST specify 654 a complete route between the target and the origin. The DRO 655 message MAY carry a Metric Container Option that contains the 656 aggregated routing metrics values for the route specified in P2P- 657 RDO. 659 8.1. Secure DRO 661 A Secure DRO message follows the format in Figure 7 of 662 [I-D.ietf-roll-rpl], where the base format is the base DRO shown in 663 Figure 2. 665 8.2. Setting a P2P-RDO Carried in a Discovery Reply Object 667 A Discovery Reply Object MUST carry one P2P-RDO, which MUST be set as 668 defined in Section 7 with the following exceptions: 670 o Direction (D): This flag MUST be set to zero on transmission and 671 ignored on reception. 673 o Number of Routes (N): This field MUST be set to zero on 674 transmission and ignored on reception. 676 o Life Time (L): This field MUST be set to zero on transmission and 677 ignored on reception. 679 o MaxRank/NH: This field indicates the index of the next hop address 680 in the Address vector. When a target generates a DRO message, the 681 NH field is set to n = (Option Length - 2 - (16 - Compr))/(16 - 682 Compr). 684 o Address[1..n]: The Address vector MUST contain a complete route 685 between the origin and the target such that the first element in 686 the vector contains the IPv6 address of the router next to the 687 origin and the last element contains the IPv6 address of the 688 router next to the target. 690 9. P2P-RPL Route Discovery By Creating a Temporary DAG 692 This section details the functioning of P2P-RPL route discovery by 693 creating a temporary DAG, using the P2P mode DIO, DRO and DRO-ACK 694 messages. 696 9.1. Joining a Temporary DAG 698 All the routers participating in a P2P-RPL route discovery, including 699 the origin and the target, MUST join the temporary DAG being created 700 for the purpose. When a router joins a temporary DAG advertized by a 701 P2P mode DIO, it SHOULD maintain its membership in the temporary DAG 702 for the suggested Life Time duration listed in the P2P-RDO. The only 703 purpose of a temporary DAG's existence is to facilitate the P2P-RPL 704 route discovery process. The temporary DAG MUST NOT be used to route 705 packets. A router SHOULD detach from the temporary DAG once the 706 duration of its membership in the DAG has exceeded the DAG's 707 suggested life time. A router MAY detach from a temporary DAG sooner 708 when it receives a DRO about the temporary DAG with the stop flag 709 set. 711 9.2. Trickle Operation For P2P Mode DIOs 713 An RPL router uses a Trickle timer [RFC6206] to control DIO 714 transmissions. The Trickle control of DIO transmissions provides 715 quick resolution of any "inconsistency" while avoiding redundant DIO 716 transmissions. The Trickle algorithm also imparts protection against 717 loss of DIOs due to inherent lack of reliability in wireless 718 communication. When controlling the transmissions of a P2P mode DIO, 719 a Trickle timer SHOULD follow the following rules: 721 o The receipt of a P2P mode DIO, that allows the router to advertise 722 a better route (in terms of the routing metrics and the OF in use) 723 than before, is considered "inconsistent" and hence resets the 724 Trickle timer. Note that the first receipt of a P2P mode DIO 725 advertising a particular temporary DAG is always considered an 726 "inconsistent" event. 728 o The receipt of a P2P mode DIO from a parent in the temporary DAG 729 is considered neither "consistent" nor "inconsistent" if it does 730 not allow the router to advertise a better route than before. 731 Thus, the receipt of such DIOs has no impact on the Trickle 732 operation. Note that this document does not impose any 733 requirements on how a router might choose its parents in the 734 temporary DAG. 736 o The receipt of a P2P mode DIO is considered "consistent" if the 737 source of the DIO is not a parent in the temporary DAG and either 738 of the following conditions is true: 740 * The DIO advertises a better route than the router but does not 741 allow the router to advertise a better route itself; or 743 * The DIO advertises a route as good as the route (to be) 744 advertised by the router. 746 Note that Trickle algorithm's DIO suppression rules are in effect 747 at all times. Hence, a P2P-RPL router may suppress a DIO 748 transmission even if it has not made any DIO transmission yet. 750 o The receipt of a P2P mode DIO, that advertises a worse route than 751 what the router advertises (or would advertise when it gets a 752 chance to generate its DIO), is considered neither "consistent" 753 nor "inconsistent", i.e., the receipt of such a DIO has no impact 754 on the Trickle operation. 756 o The Imin parameter SHOULD be set taking in account the 757 connectivity within the network. For highly connected networks, a 758 small Imin value (of the order of the typical transmission delay 759 for a DIO) may lead to congestion in the network as a large number 760 of routers reset their Trickle timers in response to the first 761 receipt of a DIO from the origin. These routers would generate 762 their DIOs within Imin interval and cause additional routers to 763 reset their trickle timers and generate more DIOs. Thus, for 764 highly connected networks, the Imin parameter SHOULD be set to a 765 value at least one order of magnitude larger than the typical 766 transmission delay for a DIO. For sparsely connected networks, 767 the Imin parameter can be set to a value that is a small multiple 768 of the typical transmission delay for a DIO. Note that the Imin 769 value has a direct impact on the time required for a P2P-RPL route 770 discovery to complete. In general, the time required for a P2P- 771 RPL route discovery would increase approximately linearly with the 772 value of the Imin parameter. 774 o The Imax parameter SHOULD be set to a large value (several orders 775 of magnitude higher than the Imin value) and is unlikely to be 776 critical for P2P-RPL operation. This is because the first receipt 777 of a P2P mode DIO for a particular temporary DAG is considered an 778 inconsistent event and would lead to resetting of Trickle timer 779 duration to the Imin value. Given the temporary nature of the 780 DAGs used in P2P-RPL, Trickle timer may not get a chance to 781 increase much. 783 o The recommended value of redundancy constant "k" is 1. With this 784 value of "k", a DIO transmission will be suppressed if the router 785 receives even a single "consistent" DIO during a timer interval. 786 This setting for the redundancy constant is designed to reduce the 787 number of messages generated during a route discovery process and 788 is suitable for environments with low or moderate packet loss 789 rates. In environments with high packet loss rates, a higher 790 value for the redundancy constant may be more suitable. 792 9.3. Processing a P2P Mode DIO 794 The rules for DIO processing and transmission, described in Section 8 795 of RPL [I-D.ietf-roll-rpl], apply to P2P mode DIOs as well except as 796 modified in this document. 798 The following rules for processing a P2P mode DIO apply to both 799 intermediate routers and the target. 801 A router SHOULD discard a received P2P mode DIO with no further 802 processing if it does not have bidirectional reachability with the 803 neighbor that originated the received DIO. This is to ensure that a 804 discovered route can be used to send a DRO message from the target to 805 the origin. Note that bidirectional reachability does not mean that 806 the link must have the same values for a routing metric in both 807 directions. A router SHOULD update the values of the link-level 808 routing metrics included inside the DIO in the direction indicated by 809 the D flag in the P2P-RDO. If the D flag is 0, i.e., the discovered 810 routes need not be bidirectional, the link-level routing metrics 811 SHOULD be measured in the forward direction, i.e., towards the node 812 receiving the DIO. If the D flag is 1, i.e., bidirectional routes 813 are desired, the link-level routing metrics SHOULD be calculated so 814 as to take into account the metric's value in both forward and 815 backward directions. 817 A router MUST discard the received P2P mode DIO with no further 818 processing: 820 o If the DIO advertises INFINITE_RANK as defined in 821 [I-D.ietf-roll-rpl]. 823 o If the integer part of the rank advertised in the DIO equals or 824 exceeds the MaxRank limit listed in the P2P Route Discovery 825 Option. 827 o If the router cannot evaluate the mandatory route constraints 828 listed in the DIO or if the routing metric values do not satisfy 829 one or more of the mandatory constraints. 831 9.4. Additional Processing of a P2P Mode DIO At An Intermediate Router 833 An intermediate router MUST discard a received P2P mode DIO with no 834 further processing if the router cannot elide Compr (as specified in 835 the P2P-RDO) prefix octets from its IPv6 address. 837 On receiving a P2P mode DIO, an intermediate router MUST determine 838 whether this DIO advertises a better route than the router itself and 839 whether the receipt of the DIO would allow the router to advertise a 840 better route than before. Accordingly, the router SHOULD consider 841 this DIO as consistent/inconsistent from Trickle perspective as 842 described in Section 9.2. Note that the route comparison in a P2P- 843 RPL route discovery is performed using the parent selection rules of 844 the OF in use as specified in Section 14 of RPL [I-D.ietf-roll-rpl]. 845 If the received DIO would allow the router to improve the route it 846 advertises, the router MUST store the route advertised in the DIO in 847 memory (after adding its own IPv6 address to the route) for inclusion 848 in its future DIOs. When an intermediate router adds itself to a 849 route, it MUST ensure that the IPv6 address added to the route is 850 accessible in both forward and backward directions. To improve the 851 diversity of the routes being discovered, an intermediate router 852 SHOULD keep track of multiple partial routes to be advertised in the 853 P2P-RDO inside its DIO. When the router generates its DIO, it SHOULD 854 randomly select the partial route to be included in the P2P-RDO. 856 9.5. Additional Processing of a P2P Mode DIO At The Target 858 The target discards a received P2P mode DIO with no further 859 processing if the routing metrics inside the DIO do not satisfy the 860 mandatory constraints. Otherwise, the target MAY select the route 861 contained in the P2P-RDO for further processing. This document does 862 not prescribe a particular method for the target to select such 863 routes. Examples include selecting the desired number of routes as 864 they are identified or selecting the best routes discovered over a 865 certain time period. If multiple routes are desired, the target 866 SHOULD avoid selecting routes that have large segments in common. If 867 a discovered route is bidirectional (D=1), the target MAY store the 868 route in backward direction, obtained by reversing the discovered 869 forward route, for use as a source route to reach the origin. After 870 selecting a route, the target sends a Discovery Reply Object (DRO) 871 message back to the origin (identified by the DODAGID field in the 872 DIO). In this DRO, the target includes a P2P-RDO that contains the 873 selected route inside the Address vector. The P2P-RDO included in 874 the DRO message MUST copy the H flag from the P2P-RDO inside the 875 received DIO message. The other fields inside the P2P-RDO MUST be 876 set as specified in Section 7. The mechanism for the propagation of 877 DRO messages is described in Section 8. 879 The target MAY set the A flag inside the DRO message if it desires 880 the origin to send back a DRO-ACK message on receiving the DRO. In 881 this case, the target waits for DRO_ACK_WAIT_TIME duration for the 882 DRO-ACK message to arrive. Failure to receive the DRO-ACK message 883 within this time duration causes the target to retransmit the DRO 884 message. The target MAY retransmit the DRO message in this fashion 885 up to MAX_DRO_RETRANSMISSIONS times. The values of DRO_ACK_WAIT_TIME 886 and MAX_DRO_RETRANSMISSIONS are defined in Section 12. 888 The target MAY include a Metric Container Option in the DRO message. 889 This Metric Container contains the end-to-end routing metric values 890 for the route specified in the P2P-RDO. The target MAY set the stop 891 flag inside the DRO message (and detach from the temporary DAG) if it 892 has already selected the desired number of routes. A target MUST NOT 893 forward a P2P mode DIO any further. 895 9.6. Processing a DRO At An Intermediate Router 897 When a router receives a DRO message that does not list its IPv6 898 address in the DODAGID field, the router MUST process the received 899 message in the following manner: 901 o If the stop flag inside the received DRO is set and the router 902 currently belongs to the temporary DAG identified by the 903 (RPLInstanceID, DODAGID and Version fields of the) DRO, the router 904 SHOULD cancel any pending DIO transmissions for this temporary 905 DAG. Additionally, the router MAY detach from the temporary DAG 906 immediately. 908 o An intermediate router MUST ignore any Metric Container Option 909 contained in the DRO message. 911 o If Address[NH] element inside the Route Discovery Option lists the 912 router's own IPv6 address, the router is a part of the route 913 carried in the P2P-RDO. In this case, the router MUST do the 914 following: 916 * If the H flag inside the P2P-RDO inside the DRO message is set, 917 the router SHOULD store the state for the forward hop-by-hop 918 route carried inside the P2P-RDO. This state consists of: 920 + The RPLInstanceID and the DODAGID fields of the DRO. 922 + The route's destination, the target (identified by Target 923 field in P2P-RDO). 925 + The IPv6 address of the next hop, Address[NH+1] (unless NH 926 value equals the number of elements in the Address vector, 927 in which case the target itself is the next hop). 929 The router MUST drop the DRO message with no further processing 930 if the H flag inside the P2P-RDO is set but the router chooses 931 not to store the state for the hop-by-hop route. 933 * If the router already maintains a hop-by-hop state listing the 934 target as the destination and carrying same RPLInstanceID and 935 DODAGID fields as the received DRO and the next hop information 936 in the state does not match the next hop indicated in the 937 received DRO, the router MUST drop the DRO message with no 938 further processing. 940 * The router MUST decrement the NH field inside the P2P-RDO and 941 send the DRO further via link-local multicast. 943 9.7. Processing a DRO At The Origin 945 When a router receives a DRO message that lists its IPv6 address in 946 the DODAGID field, the router recognizes itself as the origin for the 947 corresponding P2P-RPL route discovery and processes the P2P-RDO 948 contained in the DRO in the following manner. 950 If the stop flag inside the received DRO is set and the origin still 951 belongs to the temporary DAG it initiated, it SHOULD cancel any 952 pending DIO transmissions for this temporary DAG. Additionally, the 953 origin MAY detach from the temporary DAG immediately. 955 If the P2P-RDO inside the DRO identifies the discovered route as a 956 source route (H=0), the origin SHOULD store in its memory the 957 discovered route contained in the Address vector. 959 If the P2P-RDO inside the DRO identifies the discovered route as a 960 hop-by-hop route (H=1), the origin SHOULD store in its memory the 961 state for the discovered route in the manner described in 962 Section 9.6. 964 If the received DRO message contains a Metric Container Option as 965 well, the origin MAY store the values of the routing metrics 966 associated with the discovered route in its memory. This information 967 may be useful in formulating the constraints for any future P2P-RPL 968 route discovery to the target. 970 If the A flag is set to one in the received DRO message, the origin 971 SHOULD generate a DRO-ACK message as described in Section 10 and 972 unicast the message to the target. The origin MAY source route the 973 DRO-ACK message to the target using the route contained in the 974 received DRO. If the received DRO established a hop-by-hop route to 975 the target, the origin MAY send the DRO-ACK message along this route. 976 Section 11 describes how a packet may be forwarded along a route 977 discovered using P2P-RPL. 979 10. The Discovery Reply Object Acknowledgement (DRO-ACK) 981 0 1 2 3 982 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 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | RPLInstanceID | Version |Seq| Reserved | 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 | | 987 | DODAGID | 988 | | 989 | | 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 Figure 3: Format of the base Discovery Reply Object Acknowledgement 993 (DRO-ACK) 995 A DRO message may fail to reach the origin due to a number of 996 reasons. Unlike the DIO messages that benefit from Trickle- 997 controlled retransmissions, the DRO messages are prone to loss due to 998 reasons associated with wireless communication. Since a DRO message 999 travels via link-local multicast, it cannot use link-level 1000 acknowledgements to improve the reliability of its transmission. 1001 Also, an intermediate router may drop the DRO message (e.g., because 1002 of its inability to store the state for the hop-by-hop route the DRO 1003 is establishing). To protect against the potential failure of a DRO 1004 message to reach the origin, the target MAY request the origin to 1005 send back a DRO Acknowledgement (DRO-ACK) message on receiving a DRO 1006 message. Failure to receive such an acknowledgement within the 1007 DRO_ACK_WAIT_TIME interval of sending the DRO message forces the 1008 target to resend the message. 1010 This section defines two new RPL Control Message types: DRO 1011 Acknowledgement (DRO-ACK; with code 0x05; to be confirmed by IANA) 1012 and Secure DRO-ACK (with code 0x85; to be confirmed by IANA). A DRO- 1013 ACK message MUST travel as a unicast message from the origin to the 1014 target. The format of a base DRO-ACK message is shown in Figure 3. 1015 Various fields in a DRO-ACK message MUST have the same values as the 1016 corresponding fields in the DRO message. The field marked as 1017 "Reserved" MUST be set to zero on transmission and MUST be ignored on 1018 reception. A Secure DRO-ACK message follows the format in Figure 7 1019 of [I-D.ietf-roll-rpl], where the base format is same as the base 1020 DRO-ACK shown in Figure 3. 1022 11. Packet Forwarding Along a P2P-RPL Route 1024 This document specifies a mechanism to discover P2P routes, which can 1025 be either source routes or hop-by-hop ones. A packet MAY use an SRH 1026 header [I-D.ietf-6man-rpl-routing-header] to travel along a source 1027 route discovered using P2P-RPL. Travel along a hop-by-hop route, 1028 established using P2P-RPL, requires specifying the RPLInstanceID and 1029 the DODAGID to identify the route. This is because P2P-RPL route 1030 discovery does not use globally unique RPLInstanceID values and hence 1031 both the RPLInstanceID, which is a local value assigned by the 1032 origin, and the DODAGID, which is an IPv6 address belonging to the 1033 origin, are required to uniquely identify a P2P-RPL hop-by-hop route 1034 to a particular destination. A packet MAY include an RPL option 1035 [I-D.ietf-6man-rpl-option] inside the IPv6 hop-by-hop options header 1036 to travel along a hop-by-hop route established using P2P-RPL. In 1037 this case, the origin MUST set the DODAGID of the P2P-RPL route as 1038 the source IPv6 address of the packet. Further, the origin MUST 1039 specify the RPLInstanceID, associated with the P2P-RPL route, inside 1040 the RPL option and set the O flag inside the RPL option to 1. A 1041 router receiving this packet will check the O flag inside the RPL 1042 option and correctly infer the source IPv6 address of the packet as 1043 the DODAGID of the hop-by-hop route to be used for forwarding the 1044 packet further. 1046 12. Constants 1048 This document defines the following constants: 1050 o DRO_ACK_WAIT_TIME: The time duration a target waits for the DRO- 1051 ACK before retransmitting a DRO message. DRO_ACK_WAIT_TIME has a 1052 value of 1 second. 1054 o MAX_DRO_RETRANSMISSIONS: The maximum number of times a DRO message 1055 may be retransmitted if the target does not receive a DRO-ACK in 1056 response. MAX_DRO_RETRANSMISSIONS has a value 2. 1058 13. Interoperability With Core RPL 1060 This section describes how RPL routers that implement P2P-RPL 1061 interact with RPL routers that do not. In general, P2P-RPL operation 1062 does not affect core RPL operation and vice versa. However, core RPL 1063 does allow a router to join a DAG as a leaf node even if it does not 1064 understand the Mode of Operation (MOP) used in the DAG. Thus, an RPL 1065 router that does not implement P2P-RPL may conceivably join a 1066 temporary DAG being created for a P2P-RPL route discovery as a leaf 1067 node and maintain its membership even though the DAG no longer 1068 exists. This may impose a drain on the router's memory. However, 1069 such RPL-only leaf nodes do not interfere with P2P-RPL route 1070 discovery since a leaf node may only generate a DIO advertising an 1071 INFINITE_RANK and all routers implementing P2P-RPL are required to 1072 discard such DIOs. 1074 Note that core RPL does not require a router to join a DAG whose MOP 1075 it does not understand. Moreover, RPL routers would, in practice, 1076 have strict restrictions on the DAGs that may join. Thus, the 1077 problem described in the preceding paragraph may not occur in 1078 practice. 1080 The P2P-RPL mechanism described in this document works best when all 1081 the RPL routers in the LLN implement P2P-RPL. In general, the 1082 ability to discover routes as well as the quality of discovered 1083 routes would deteriorate with the fraction of RPL routers that 1084 implement P2P-RPL. 1086 14. Security Considerations 1088 The security considerations for the operation of the reactive P2P 1089 route discovery mechanism described in this document are similar to 1090 the ones for the operation of RPL (as described in Section 19 of 1091 [I-D.ietf-roll-rpl]). Section 10 of RPL specification 1093 [I-D.ietf-roll-rpl] describes a variety of security mechanisms to 1094 provide data confidentiality, authentication, replay protection and 1095 delay protection services. Each RPL control message has a secure 1096 version that allows the specification of the level of security and 1097 the algorithms used to secure the message. The mechanism defined in 1098 this document is based on the use of DIOs to form temporary DAGs and 1099 discover P2P routes. These DIOs can be used in their secure versions 1100 if desired. New RPL control messages defined in this document (DRO 1101 and DRO-ACK) have secure versions as well. Thus, a particular 1102 deployment of the reactive P2P route discovery mechanism described in 1103 this document can analyze its security requirements and use the 1104 appropriate set of RPL security mechanisms that meet those 1105 requirements. 1107 15. IANA Considerations 1109 15.1. Additions to DIO Mode of Operation 1111 IANA is requested to allocate a new value in the "DIO Mode of 1112 Operation" registry for the "P2P Route Discovery Mode" described in 1113 this document. 1115 +----------+-----------------------------------------+--------------+ 1116 | MOP | Description | Reference | 1117 | Value | | | 1118 +----------+-----------------------------------------+--------------+ 1119 | 4 | Reactive P2P route discovery mode of | This | 1120 | | operation | document | 1121 +----------+-----------------------------------------+--------------+ 1123 DIO Mode of Operation 1125 15.2. Additions to RPL Control Message Options 1127 IANA is requested to allocate a new value in the "RPL Control Message 1128 Options" registry for the "Route Discovery Option" described in this 1129 document. 1131 +-------+---------------------+---------------+ 1132 | Value | Meaning | Reference | 1133 +-------+---------------------+---------------+ 1134 | 10 | P2P Route Discovery | This document | 1135 +-------+---------------------+---------------+ 1137 RPL Control Message Options 1139 15.3. Additions to RPL Control Codes 1141 IANA is requested to allocate new code points in the "RPL Control 1142 Codes" registry for the "Discovery Reply Object" and "Discovery Reply 1143 Object Acknowledgement" (and their secure versions) described in this 1144 document. 1146 +------+--------------------------------------------+---------------+ 1147 | Code | Description | Reference | 1148 +------+--------------------------------------------+---------------+ 1149 | 0x04 | Discovery Reply Object | This document | 1150 | 0x05 | Discovery Reply Object Acknowledgement | This document | 1151 | 0x84 | Secure Discovery Reply Object | This document | 1152 | 0x85 | Secure Discovery Reply Object | This document | 1153 | | Acknowledgement | | 1154 +------+--------------------------------------------+---------------+ 1156 RPL Control Codes 1158 16. Acknowledgements 1160 Authors gratefully acknowledge the contributions of the following 1161 individuals (in alphabetical order) in the development of this 1162 document: Dominique Barthel, Jakob Buron, Thomas Clausen, Richard 1163 Kelsey, Phil Levis, Zach Shelby, Pascal Thubert, Hristo Valev and JP 1164 Vasseur. 1166 17. References 1168 17.1. Normative References 1170 [I-D.ietf-roll-routing-metrics] 1171 Vasseur, J., Kim, M., Pister, K., Dejean, N., and D. 1172 Barthel, "Routing Metrics used for Path Calculation in Low 1173 Power and Lossy Networks", 1174 draft-ietf-roll-routing-metrics-19 (work in progress), 1175 March 2011. 1177 [I-D.ietf-roll-rpl] 1178 Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., 1179 Kelsey, R., Levis, P., Pister, K., Struik, R., and J. 1180 Vasseur, "RPL: IPv6 Routing Protocol for Low power and 1181 Lossy Networks", draft-ietf-roll-rpl-19 (work in 1182 progress), March 2011. 1184 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1185 Requirement Levels", BCP 14, RFC 2119, March 1997. 1187 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 1188 "The Trickle Algorithm", RFC 6206, March 2011. 1190 17.2. Informative References 1192 [I-D.ietf-6man-rpl-option] 1193 Hui, J. and J. Vasseur, "RPL Option for Carrying RPL 1194 Information in Data-Plane Datagrams", 1195 draft-ietf-6man-rpl-option-06 (work in progress), 1196 December 2011. 1198 [I-D.ietf-6man-rpl-routing-header] 1199 Hui, J., Vasseur, J., Culler, D., and V. Manral, "An IPv6 1200 Routing Header for Source Routes with RPL", 1201 draft-ietf-6man-rpl-routing-header-07 (work in progress), 1202 December 2011. 1204 [I-D.ietf-roll-of0] 1205 Thubert, P., "RPL Objective Function Zero", 1206 draft-ietf-roll-of0-20 (work in progress), September 2011. 1208 [I-D.ietf-roll-p2p-measurement] 1209 Goyal, M., Baccelli, E., Brandt, A., and J. Martocci, "A 1210 Mechanism to Measure the Quality of a Point-to-point Route 1211 in a Low Power and Lossy Network", 1212 draft-ietf-roll-p2p-measurement-02 (work in progress), 1213 October 2011. 1215 [I-D.ietf-roll-terminology] 1216 Vasseur, J., "Terminology in Low power And Lossy 1217 Networks", draft-ietf-roll-terminology-06 (work in 1218 progress), September 2011. 1220 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 1221 Routing Requirements in Low-Power and Lossy Networks", 1222 RFC 5826, April 2010. 1224 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 1225 "Building Automation Routing Requirements in Low-Power and 1226 Lossy Networks", RFC 5867, June 2010. 1228 Authors' Addresses 1230 Mukul Goyal (editor) 1231 University of Wisconsin Milwaukee 1232 3200 N Cramer St 1233 Milwaukee, WI 53201 1234 USA 1236 Phone: +1 414 2295001 1237 Email: mukul@uwm.edu 1239 Emmanuel Baccelli 1240 INRIA 1242 Phone: +33-169-335-511 1243 Email: Emmanuel.Baccelli@inria.fr 1244 URI: http://www.emmanuelbaccelli.org/ 1246 Matthias Philipp 1247 INRIA 1249 Phone: +33-169-335-511 1250 Email: Matthias.Philipp@inria.fr 1252 Anders Brandt 1253 Sigma Designs 1254 Emdrupvej 26A, 1. 1255 Copenhagen, Dk-2100 1256 Denmark 1258 Phone: +45-29609501 1259 Email: abr@sdesigns.dk 1261 Jerald Martocci 1262 Johnson Controls 1263 507 E Michigan St 1264 Milwaukee, WI 53202 1265 USA 1267 Phone: +1 414-524-4010 1268 Email: jerald.p.martocci@jci.com