idnits 2.17.1 draft-ietf-roll-p2p-rpl-05.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 (November 14, 2011) is 4546 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'Rem' is mentioned on line 802, but not defined == Outdated reference: A later version (-04) exists of draft-brandt-roll-rpl-applicability-home-building-01 == Outdated reference: A later version (-06) exists of draft-ietf-6man-rpl-option-04 == Outdated reference: A later version (-07) exists of draft-ietf-6man-rpl-routing-header-04 == 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 (~~), 7 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: May 17, 2012 E. Baccelli 6 M. Philipp 7 INRIA 8 A. Brandt 9 Sigma Designs 10 J. Martocci 11 Johnson Controls 12 November 14, 2011 14 Reactive Discovery of Point-to-Point Routes in Low Power and Lossy 15 Networks 16 draft-ietf-roll-p2p-rpl-05 18 Abstract 20 This document specifies a route discovery mechanism, complementary to 21 the RPL base functionality. This mechanism allows an IPv6 router to 22 discover and establish, on demand, a route to another IPv6 router in 23 the LLN such that the discovered route meets specified metrics 24 constraints, without necessarily going along the DAG links 25 established by basic 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 May 17, 2012. 44 Copyright Notice 46 Copyright (c) 2011 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. The Route Discovery Option (RDO) . . . . . . . . . . . . . . . 7 67 6.1. Setting a DIO Carrying a Route Discovery Option . . . . . 10 68 7. The Discovery Reply Object (DRO) . . . . . . . . . . . . . . . 11 69 7.1. Secure DRO . . . . . . . . . . . . . . . . . . . . . . . . 13 70 7.2. Setting an RDO Carried in a Discovery Reply Object . . . . 13 71 8. P2P Route Discovery By Creating a Temporary DAG . . . . . . . 14 72 8.1. Joining a Temporary DAG . . . . . . . . . . . . . . . . . 14 73 8.2. Trickle Operation For DIOs Carrying a Route Discovery 74 Option . . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 8.3. Processing a DIO Carrying a Route Discovery Option . . . . 15 76 8.4. Additional Processing of a DIO Carrying a Route 77 Discovery Option At An Intermediate Router . . . . . . . . 16 78 8.5. Additional Processing of a DIO Carrying a Route 79 Discovery Option At The Target . . . . . . . . . . . . . . 16 80 8.6. Processing a DRO At An Intermediate Router . . . . . . . . 17 81 8.7. Processing a DRO At The Origin . . . . . . . . . . . . . . 18 82 9. The Discovery Reply Object Acknowledgement (DRO-ACK) . . . . . 19 83 10. Packet Forwarding Along a P2P Route . . . . . . . . . . . . . 20 84 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 85 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 86 12.1. Additions to RPL Control Codes . . . . . . . . . . . . . . 21 87 12.2. Additions to RPL Control Message Options . . . . . . . . . 21 88 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 89 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 90 14.1. Normative References . . . . . . . . . . . . . . . . . . . 22 91 14.2. Informative References . . . . . . . . . . . . . . . . . . 22 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 94 1. Introduction 96 Targeting Low power and Lossy Networks (LLNs), the RPL routing 97 protocol [I-D.ietf-roll-rpl] provides paths along a Directed Acyclic 98 Graph (DAG) rooted at a single router in the network: the sink. 99 Establishment and maintenance of the DAG is performed by each router 100 in the LLN using specific link-local multicast signalling (DIO 101 messages). 103 When two arbitrary routers (none of which being the sink) need to 104 communicate, basic RPL provides dog-legged paths along DAG links, 105 which may not be efficient enough for several Home and Building 106 Automation applications [RFC5826][RFC5867], for the following reasons 107 [I-D.brandt-roll-rpl-applicability-home-building]: 109 o The need to preprovision routes: each potential destination in the 110 network must declare itself as such, via specific additional 111 signalling (DAO messages). 113 o The need to route along DAG links: depending on the network 114 topology and metrics in use, the constraint to route along a DAG 115 may cause significantly suboptimal P2P routes and severe traffic 116 congestion near the DAG root. 118 This document thus describes a mechanism complementary to the basic 119 RPL functionality, enabling source-initiated, on-demand discovery of 120 a route between arbitrary routers in the LLN, such that the 121 discovered route meets specified metrics constraints, without 122 necessarily going along an existing DAG. Hereafter, such routes are 123 called point-to-point (P2P) routes. The specified mechanism allows 124 for the discovery of source routes as well as hop-by-hop routes. 125 Discovered routes may not be the best available but are guaranteed to 126 satisfy the desired constraints in terms of the routing metrics and 127 are thus considered "good enough" from the application's perspective. 129 A complementary functionality helping to decide whether or not to 130 initiate a route discovery, is a mechanism measuring the end-to-end 131 cost of an existing route. Section 4 provides further details on how 132 such functionality, specified in [I-D.ietf-roll-p2p-measurement], is 133 used to determine the value of metric constraints parameters in the 134 route discovery mechanism described in this document. 136 2. The Use Cases 138 The mechanism described in this document is intended to be employed 139 as complementary to RPL in specific scenarios that need P2P paths 140 between arbitrary routers. 142 One use case, common in a home environment, involves a remote control 143 (or a motion sensor) that suddenly needs to communicate with a lamp 144 module, whose network address is a-priori known. In this case, the 145 source of data (the remote control or the motion sensor) must be able 146 to discover a route to the destination (the lamp module) "on demand". 148 Another use case, common in a large commercial building environment, 149 involves a large LLN deployment where P2P communication along a 150 particular DAG among hundreds (or thousands) of routers creates 151 severe traffic congestion near that DAG's root, and thus routes 152 across this DAG are desirable. 154 The use cases also include scenarios where energy or latency 155 constraints are not satisfied by P2P routes provided by basic RPL 156 along a DAG because they involve traversing many more intermediate 157 routers than necessary to reach the destination. 159 3. Terminology 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 163 "OPTIONAL" in this document are to be interpreted as described in 164 [RFC2119]. 166 Additionally, this document uses terminology from 167 [I-D.ietf-roll-terminology] and [I-D.ietf-roll-rpl]. This document 168 introduces the following terms: 170 Origin : The RPL node initiating the route discovery. 172 Target : The RPL node at the other end point of the route(s) to be 173 discovered. 175 Intermediate Router: An RPL router that is neither the origin nor the 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 The route discovery mechanism, described in this document, may be 196 invoked by an origin when no route exists between itself and the 197 target or when the existing routes do not satisfy the desired 198 performance requirements. The mechanism is designed to discover and 199 establish one hop-by-hop route or discover one or more source routes 200 such that the discovered route(s) meet the specified constraints. In 201 some application contexts, the constraints that the discovered 202 route(s) must satisfy are intrinsically known or can be specified by 203 the application. For example, an origin that expects a target to be 204 less than 5 hops away may use "hop-count < 5" as the constraint. In 205 other application contexts, the origin may need to measure the cost 206 of an existing route to the target to determine the constraints. For 207 example, an origin that measures the total ETX of its along-DAG route 208 to the target to be 20 may use "ETX < x*20", where x is a fraction 209 that the origin decides, as the constraint. A mechanism measuring 210 the cost of an existing route between the origin and the target is 211 specified in [I-D.ietf-roll-p2p-measurement]. If there is no 212 existing route between the origin and target or the cost measurement 213 for the existing route fails, the origin will have to guess the 214 constraints used in the initial route discovery. Once, the initial 215 route discovery succeeds or fails, the origin will have a better 216 estimate for the constraints to be used in the subsequent route 217 discovery. 219 This document describes an on-demand discovery mechanism for P2P 220 routes that is complementary to the proactive routes offered by RPL 221 base functionality. The mechanism described in this document may 222 result in discovery of better P2P routes than the ones available 223 along a DAG designed to optimize routing cost to the DAG's root. The 224 improvement in route quality depends on a number of factors including 225 the network topology, the routing metrics in use and the prevalent 226 conditions in the network. A network designer may take in 227 consideration both the benefits (potentially better routes; no need 228 to maintain routes proactively) and costs (control messages generated 229 during the route discovery process) when using this mechanism. 231 5. Functional Overview 233 This section contains a high level description of P2P-RPL, the route 234 discovery mechanism specified in this document. 236 Similarly to basic RPL, P2P-RPL uses IPv6 link-local multicasted DIO 237 messages to establish a DAG (maintained temporarily). Each router 238 joining the DAG determines a rank for itself in the DAG and ignores 239 the subsequent DIO messages received from lower (higher in numerical 240 value) ranked neighbors. Thus, the DIO messages propagate outward 241 from the DAG root rather than return inward towards the DAG root. As 242 basic RPL, DIO message generation at a router is further controlled 243 by a Trickle timer that allows a router to avoid generating 244 unnecessary messages [RFC6206]. P2P-RPL also uses the routing 245 metrics, objective function [I-D.ietf-roll-routing-metrics] and 246 packet forwarding framework developed for basic RPL. 248 The P2P route discovery takes place by forming a temporary DAG rooted 249 at the origin. The DIOs used to create the temporary DA, carry the 250 following additional information via a Route Discovery Option (RDO 251 defined in Section 6): 253 o The target 255 o The relevant routing metrics 257 o The constraints that the discovered route must satisfy. These 258 constraints also limit how far the Discovery message may travel. 260 o The nature of the route(s) to be discovered: hop-by-hop or source 261 routes. This specification allows for the discovery of one hop- 262 by-hop route or up to four source routes in the forward direction. 264 o The desired number of routes (if source routes are being 265 discovered) 267 o Whether the route(s) need to be bidirectional. If bidirectional 268 route(s) are being discovered, the target may store the route in 269 backward direction for use as a source route. This specification 270 does not provide for the establishment of backward hop-by-hop 271 routes. 273 As the routers join the temporary DAG, they keep track of the best 274 (partial) route(s) they have seen and advertise these routes, along 275 with the corresponding routing metrics, in their DIOs. The routing 276 metrics are measured in forward direction unless bidirectional routes 277 are being discovered, in which case the measurement of routing 278 metrics need to take in account both forward and backward directions. 279 A router, including the target, discards a received DIO if the 280 aggregated routing metrics on the route advertised by the DIO do not 281 satisfy the listed constraints. These constraints can be used to 282 limit the propagation of DIO messages used for P2P route discovery. 283 A router may also discard a received DIO if it does not wish to be a 284 part of the discovered route due to limited resources or due to 285 policy reasons. 287 When the target receives a DIO, it checks whether the route 288 advertised therein satisfies the routing constraints. If yes, the 289 target may select the route for further processing as described next. 290 This document does not specify a particular method for the target to 291 select a route among the ones that satisfy the route constraints. 292 Example selection methods include selecting any route that meets the 293 constraints or selecting the best route(s) discovered over a certain 294 time period. 296 If one or more source routes are being discovered, the target sends 297 the discovered source routes to the origin via Discovery Reply Object 298 (DRO) messages, defined in Section 7, with one DRO message carrying 299 one discovered route. On receiving a DRO message, the origin stores 300 the route contained therein in its memory. 302 If a hop-by-hop route is being discovered, the target sends a DRO 303 message to the origin after selecting a suitable route among the ones 304 that satisfy the route constraints. The DRO message travels towards 305 the origin along the discovered route, establishing state for this 306 route in the routers on the path. 308 The target may store a discovered route in its memory if it is 309 bidirectional and use it as a backward source-route to send packets 310 to the origin. 312 The target may request the origin to acknowledge the receipt of a DRO 313 message by sending back a DRO Acknowledgement (DRO-ACK) message 314 defined in Section 9. The origin unicasts a DRO-ACK message to the 315 target. When the target does not receive the requested DRO-ACK 316 within a certain time interval of sending a DRO, it resends the DRO 317 message carrying the same route as before. 319 The use of trickle timers to delay the propagation of DIO messages 320 may cause some nodes to generate these messages even when the desired 321 routes have already been discovered. In order to preempt the 322 generation of such unnecessary messages, the target may set a "stop" 323 bit in the DRO message defined in Section 7, to let the nodes in the 324 LLN know about the completion of the route discovery process. 326 6. The Route Discovery Option (RDO) 328 This section specifies a new RPL option, Route Discovery Option (RDO) 329 which, when carried inside a DIO message, identifies that message as 330 performing a P2P route discovery by creating a temporary DAG as 331 specified in this document. 333 0 1 2 3 334 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 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Type = 10 | Option Length |D|H| N | Compr | L | Rem | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | | 339 | Target | 340 | | 341 | | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | | 344 | Address[1..n] | 345 | | 346 | | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 Figure 1: Format of the Route Discovery Option 351 In order to perform P2P route discovery as specified in this 352 document, a DIO MUST carry a Route Discovery Option (RDO) illustrated 353 in Figure 1. A Route Discovery Option consists of the following 354 fields: 356 o Option Type: 0x0A (to be confirmed by IANA). 358 o Option Length: 8-bit unsigned integer, representing the length in 359 octets of the option, not including the Option Type and Option 360 Length fields. 362 o Direction (D): This flag indicates the direction in which the 363 desired routes should be optimized. The flag is set to 1 if the 364 routes are to be optimized for use in both forward and backward 365 directions. If the discovered routes need be optimized in the 366 forward direction only, the flag is reset to 0. Note that the 367 discovered routes must have bidirectional reachability 368 irrespective of the value of D flag. This is because DRO messages 369 (defined in Section 7) travel from the target back the origin 370 along one of the discovered routes. The link-level metric objects 371 contained in the DIO SHOULD be measured in the direction indicated 372 by the D flag. 374 o Hop-by-hop (H): This flag is set to 1 if a hop-by-hop route is 375 desired. The flag is reset to zero if source routes are desired. 376 This specification allows for the establishment of one hop-by-hop 377 route and up to four source routes in the forward direction. This 378 specification does not allow for the establishment of hop-by-hop 379 routes in the backward direction. If a bidirectional route is 380 discovered, the target MAY use the route in backward direction as 381 a source route to reach the origin, irrespective of the value of H 382 flag. 384 o Number of Routes (N): When source routes are being discovered, the 385 value in this field plus one indicates the desired number of 386 routes. When a hop-by-hop route is being discovered this field 387 MUST be set to zero on transmission and ignored on reception. 389 o Compr: 4-bit unsigned integer indicating the number of prefix 390 octets that are elided from the Target field and the Address 391 vector. For example, Compr value will be 0 if full IPv6 addresses 392 are carried in the Target field and the Address vector. 394 o Life Time (L): A 2-bit field that indicates the suggested life 395 time of the temporary DAG, i.e., the suggested duration a router 396 joining the temporary DAG must maintain its membership in the DAG. 397 The mapping between the values in this field and the minimum life 398 time of the temporary DAG is as follows: 400 * 0x00: 1 second; 402 * 0x01: 4 seconds; 404 * 0x02: 16 seconds; 406 * 0x03: 64 seconds; 408 Note that a router MAY detach from the temporary DAG sooner if it 409 receives a DRO message concerning this DAG with "stop" bit set 410 (defined in Section 7). 412 o Rem: this field indicates the number of empty fields inside the 413 Address vector. 415 o Target: The IPv6 address of the target after eliding Compr number 416 of prefix octets. 418 o Address[1..n]: A vector of IPv6 addresses representing a (partial) 419 route in the forward direction: 421 * Each element in the vector has size (16 - Compr) octets. 423 * The total number of elements inside the Address vector is given 424 by n = (Option Length - 2 - (16 - Compr))/(16 - Compr). 426 * The Address vector is used to accumulate a route optimized in 427 the direction specified by the D field. 429 * The IPv6 addresses in the Address vector MUST be accessible in 430 both forward and backward directions. Accessibility in the 431 backward direction is required because the DRO message uses the 432 route accumulated in the Address vector to travel from the 433 target to the origin. 435 * The Address vector MUST carry the accumulated route in the 436 forward direction, i.e., the first element in the Address 437 vector must contain the IPv6 address of the router next to the 438 origin and so on. 440 * The origin and target addresses MUST NOT be included in the 441 Address vector. 443 * A router adding its address to the vector MUST ensure that its 444 address does not already exist in the vector. A router 445 specifying a complete route in the Address vector MUST ensure 446 that the vector does not contain any address more than once. 448 * The Address vector MUST NOT contain any multicast addresses. 450 6.1. Setting a DIO Carrying a Route Discovery Option 452 A DIO message MUST NOT carry more than one Route Discovery Option. A 453 router MUST discard a DIO if it contains more than one Route 454 Discovery Option. 456 The Base Object in a DIO message carrying a Route Discovery Option 457 MUST be set in the following manner: 459 o RPLInstanceID: RPLInstanceID MUST be a local value as described in 460 Section 5.1 of [I-D.ietf-roll-rpl]. The origin MUST NOT use the 461 same RPLInstanceID in two or more concurrent route discoveries. 462 The origin MAY use the same RPLInstanceID value to establish hop- 463 by-hop P2P routes to different target routers. 465 o Version Number: MUST be set to zero. The temporary DAG used for 466 P2P route discovery does not exist long enough to have new 467 versions. 469 o Grounded (G) Flag: MUST be cleared since this DAG is temporary in 470 nature and MUST NOT be used for routing purpose. 472 o Mode of Operation (MOP), DTSN: These fields MUST be set to value 0 473 since this DAG does not support downward routing. 475 o DODAGPreference (Prf): This field MUST be set to value 0 (least 476 preferred). 478 o DODAGID: This field MUST be set to the IPv6 address of the origin. 480 o The other fields in the Base Object can be set in the desired 481 fashion as per the rules described in [I-D.ietf-roll-rpl]. 483 The DIO message must carry a DODAG Configuration option. The DODAG 484 Configuration option MUST be set in the following manner: 486 o MaxRankIncrease: This field MUST be set to 0 to disable local 487 repair of the temporary DAG. 489 o Trickle parameters SHOULD be set as described in Section 8.2. 491 o The Default Lifetime and Lifetime Unit parameters in DODAG 492 Configuration option indicate the life time of the state the 493 routers maintain for a hop-by-hop route established using the 494 mechanism described in this draft. 496 o The other fields in the DODAG Configuration option, including the 497 OCP (identifying the Objective function defining the considered 498 metrics and constraints [I-D.ietf-roll-routing-metrics]) can be 499 set in the desired fashion as per the rules described in 500 [I-D.ietf-roll-rpl]. 502 A DIO, carrying a Route Discovery Option, MUST NOT carry any Route 503 Information or Prefix Information options described in 504 [I-D.ietf-roll-rpl], in which case the DIO should be discarded. 506 7. The Discovery Reply Object (DRO) 508 This section defines two new RPL Control Message types, the Discovery 509 Reply Object (DRO), with code 0x04 (to be confirmed by IANA), and the 510 Secure DRO, with code 0x84 (to be confirmed by IANA). A DRO serves 511 one of the following functions: 513 o Carry a discovered source route from the target to the origin; 515 o Establish a hop-by-hop route as it travels from the target to the 516 origin. 518 A DRO message MAY also serve the function of letting the routers in 519 the LLN know that a P2P route discovery is complete and no more DIO 520 messages need to be generated for the corresponding temporary DAG. A 521 DRO message MUST carry one Route Discovery Option and travel from the 522 target to the origin via link-local multicast along the route 523 specified in the Route Discovery Option. 525 0 1 2 3 526 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 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | RPLInstanceID | Version |Seq|S|A| Reserved | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | | 531 | DODAGID | 532 | | 533 | | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Option(s)... 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 538 Figure 2: Format of the base Discovery Reply Object (DRO) 540 The format of the base Discovery Reply Object (DRO) is shown in 541 Figure 2. A base DRO consists of the following fields: 543 o RPLInstanceID: The RPLInstanceID of the temporary DAG used for 544 route discovery. 546 o Version: The Version of the temporary DAG used for route 547 discovery. 549 o Sequence Number (Seq): This 2-bit field indicates the sequence 550 number for the DRO. This field is relevant when the A flag 551 (specified below) is set, i.e., the target requests an 552 acknowledgement from the origin for a received DRO. The origin 553 includes the RPLInstanceID, the DODAGID and the Sequence Number of 554 the received DRO inside the DRO-ACK message it sends back to the 555 target. 557 o Stop (S): This flag, when set by the target, indicates that the 558 P2P route discovery is over. The routers, receiving such a DRO, 559 SHOULD cancel any pending DIO transmissions for the temporary DAG 560 created for the route discovery and MAY detach from this DAG 561 immediately. Note that the stop flag serves to stop further DIO 562 transmissions for a P2P route discovery but it does not affect the 563 processing of DRO messages at either the origin or the 564 intermediate routers. In other words, a router (the origin or an 565 intermediate router) MUST continue to process the DRO messages 566 even if an earlier DRO message (with same RPLInstanceID, DODAGID 567 and Version Number fields) had the stop flag set. 569 o Ack Required (A): This flag, when set by the target, indicates 570 that the origin SHOULD unicast a DRO-ACK message (defined in 571 Section 9) to the target when it receives the DRO. 573 o Reserved: These bits are reserved for future use. These bits MUST 574 be set to zero on transmission and MUST be ignored on reception. 576 o DODAGID: The DODAGID of the temporary DAG used for route 577 discovery. The DODAGID also identifies the origin. The 578 RPLInstanceID, the Version and the DODAGID together uniquely 579 identify the temporary DAG used for route discovery and can be 580 copied from the DIO message advertizing the temporary DAG. 582 o Options: The DRO message MUST carry one Route Discovery Option 583 that MUST specify a complete route between the target and the 584 origin. The DRO message MAY carry a Metric Container Option that 585 contains the aggregated routing metrics values for the route 586 specified in Route Discovery Option. 588 7.1. Secure DRO 590 A Secure DRO message follows the format in Figure 7 of 591 [I-D.ietf-roll-rpl], where the base format is the base DRO shown in 592 Figure 2. 594 7.2. Setting an RDO Carried in a Discovery Reply Object 596 A Discovery Reply Object MUST carry a Route Discovery Option (RDO). 597 An RDO carried in a Discovery Reply Object MUST be set as defined in 598 Section 6 except for the following fields: 600 o Direction (D): this flag should be set to zero on transmission and 601 ignored on reception. 603 o Number of Routes (N): this field MUST be set to zero on 604 transmission and ignored on reception. 606 o Life Time (L): this field MUST be set to zero on transmission and 607 ignored on reception. 609 o Rem: this field indicates the number of fields in the Address 610 vector yet to be visited. 612 o Address[1..n]: the Address vector MUST contain a complete route 613 between the origin and the target such that the first element in 614 the vector contains the IPv6 address of the router next to the 615 origin and the last element contains the IPv6 address of the 616 router next to the target. 618 8. P2P Route Discovery By Creating a Temporary DAG 620 This section details the functioning of P2P route discovery by 621 creating a temporary DAG, using the RDO option in DIO messages on one 622 hand and DRO messages on the other hand. 624 8.1. Joining a Temporary DAG 626 When a router joins a temporary DAG advertized by a DIO carrying a 627 Route Discovery Option, it SHOULD maintain its membership in the DAG 628 for the suggested Life Time duration listed in the Route Discovery 629 Option. Maintaining membership in the DAG implies storing: 631 o The RPLInstanceID, the DODAGID and the DODAGVersionNumber for the 632 temporary DAG; 634 o The router's rank in the temporary DAG; 636 o The best values of the routing metrics, along with the associated 637 route(s) from the origin until this router (carried inside the 638 Route Discovery Option) in the DIOs received so far. 640 The only purpose of a temporary DAG's existence is to facilitate the 641 propagation of the Discovery messages. The temporary DAG MUST NOT be 642 used to route packets. A router SHOULD detach from the temporary DAG 643 once the duration of its membership in the DAG has exceeded the DAG's 644 suggested life time. A router MAY detach from a temporary DAG sooner 645 when it receives a DRO about the temporary DAG with stop flag set 646 (defined in Section 7). 648 8.2. Trickle Operation For DIOs Carrying a Route Discovery Option 650 An RPL router uses a Trickle timer [RFC6206] to control DIO 651 transmissions. The Trickle control of DIO transmissions provides 652 quick resolution of any "inconsistency" while avoiding redundant DIO 653 transmissions. The Trickle algorithm also imparts protection against 654 loss of DIOs due to inherent lack of reliability in wireless 655 communication. When controlling the transmissions of a DIO carrying 656 a Route Discovery Option, a Trickle timer SHOULD follow the following 657 rules: 659 o The receipt of a DIO, that allows the router to advertise a better 660 route (in terms of the routing metrics and the OCP in use) than 661 before, is considered "inconsistent" and hence resets the Trickle 662 timer. Note that the first receipt of a DIO advertising a 663 particular temporary DAG is always considered an inconsistent 664 event under this rule. 666 o The receipt of a DIO, that advertises a better route than the 667 router but does not lead to the router advertising a better route 668 itself, is considered "consistent". 670 o The receipt of a DIO, that advertises as good a route as the 671 router itself, is considered "consistent". 673 o The receipt of a DIO, that advertises a worse route than what the 674 router advertises, is considered neither "consistent" nor 675 "inconsistent", i.e., the receipt of such a DIO has no impact on 676 the Trickle operation. 678 o The recommended values of Imin and Imax are same as in base RPL 679 specification [I-D.ietf-roll-rpl], i.e., 8ms and 2.3 hours 680 respectively. 682 o The recommended value of redundancy constant "k" is 1. With this 683 value of "k", a DIO transmission will be suppressed if the router 684 receives even a single "consistent" DIO during a timer interval. 686 8.3. Processing a DIO Carrying a Route Discovery Option 688 The rules for DIO processing and transmission, described in Section 8 689 of RPL [I-D.ietf-roll-rpl], apply to DIOs carrying a Route Discovery 690 option as well except as modified in this document. 692 The following rules for processing a DIO carrying a Route Discovery 693 Option apply to both intermediate routers and the target. 695 A router SHOULD discard a received DIO with no further processing if 696 it does not have bidirectional reachability with the neighbor that 697 originated the received DIO. This is to ensure that a discovered 698 route can be used to send a DRO message from the target to the 699 origin. Note that bidirectional reachability does not mean that the 700 link must have the same values for a routing metric in both 701 directions. A router SHOULD update the values of the link-level 702 routing metrics included inside the DIO in the direction indicated by 703 the D flag in the Route Discovery Option. If the D flag is 0, i.e., 704 the discovered routes need not be bidirectional, the link-level 705 routing metrics SHOULD be measured in the forward direction, i.e., 706 towards the node receiving the DIO. If the D flag is 1, i.e., 707 bidirectional routes are desired, the link-level routing metrics 708 SHOULD be calculated so as to take in account the metric's value in 709 both forward and backward directions. 711 A router MUST discard the DIO with no further processing if it can 712 not evaluate the mandatory route constraints listed in the DIO or if 713 the routing metric values do not satisfy one or more of the mandatory 714 constraints. 716 8.4. Additional Processing of a DIO Carrying a Route Discovery Option 717 At An Intermediate Router 719 An intermediate router MUST discard a received DIO, containing a 720 Route Discovery Option, with no further processing if the router can 721 not elide "Compr" (as specified in the Route Discovery Option) prefix 722 octets from its IPv6 address that would potentially be added to the 723 Address vector as specified next. 725 On receiving a DIO containing a Route Discovery Option, an 726 intermediate router MUST determine whether this DIO advertises a 727 better route than the router itself and whether the receipt of the 728 DIO would allow the router to advertise a better route than before. 729 Accordingly, the router SHOULD consider this DIO as consistent/ 730 inconsistent from Trickle perspective as described in Section 8.2. 731 If the received DIO would allow the router to improve the route it 732 advertises, the router MUST add its IPv6 address to the route inside 733 the received DIO at location Address[n-Rem+1] and store this route in 734 memory for inclusion in its future DIOs. When an intermediate router 735 adds itself to a route, it MUST ensure that the IPv6 address added to 736 the route is accessible in both forward and backward directions. To 737 improve the diversity of the routes being discovered, an intermediate 738 router SHOULD remember multiple partial routes, the best it knows in 739 terms of the routing metrics, that it can advertise in the Route 740 Discovery Option inside its DIO. When the router generates its DIO, 741 it SHOULD randomly select the partial route to be included in the 742 Route Discovery Option from the set of best routes it has seen so 743 far. 745 8.5. Additional Processing of a DIO Carrying a Route Discovery Option 746 At The Target 748 The target discards a received DIO with no further processing if the 749 routing metrics inside the DIO do not satisfy the mandatory 750 constraints. Otherwise, the target MAY select the route contained in 751 the Route Discovery Option for further processing. This document 752 does not prescribe a particular method for the target to select such 753 routes. Example selection methods include selecting the desired 754 number of routes as they are identified or selecting the best routes 755 discovered over a certain time period. If multiple routes are 756 desired, the target SHOULD avoid selecting routes that have large 757 segments in common. If a discovered route is bidirectional (D=1), 758 the target MAY store the route in backward direction, obtained by 759 reversing the discovered forward route, for use as a source route to 760 reach the origin. After selecting a route, the target sends a 761 Discovery Reply Object (DRO) message back to the origin (identified 762 by the DODAGID field in the DIO). In this DRO, the target includes a 763 Route Discovery Option that contains the selected route inside the 764 Address vector. The Route Discovery Option included in the DRO 765 message MUST copy the H flag from the Route Discovery Option inside 766 the received DIO message. The other fields inside the Route 767 Discovery Option MUST be set as specified in Section 6. The 768 mechanism for the propagation of DRO messages is described in 769 Section 7. 771 The target MAY set the A flag inside the DRO message if it desires 772 the origin to send back a DRO-ACK message on receiving the DRO. In 773 this case, the target waits for DRO_ACK_WAIT_TIME duration for the 774 DRO-ACK message to arrive. Failure to receive the DRO-ACK message 775 within this time duration causes the target to retransmit the DRO 776 message. The target MAY retransmit the DRO message in this fashion 777 up to MAX_DRO_RETRANSMISSIONS times. 779 The target MAY include a Metric Container Option in the DRO message. 780 This Metric Container contains the end-to-end routing metric values 781 for the route specified in the Route Discovery Option. The target 782 MAY set the stop flag inside the DRO message (defined in Section 7) 783 if it has already selected the desired number of routes. A target 784 MUST NOT forward a DIO carrying a Route Discovery option any further. 786 8.6. Processing a DRO At An Intermediate Router 788 When a router receives a DRO message that does not list its IPv6 789 address in the DODAGID field, the router MUST process the received 790 message in the following manner: 792 o If the stop flag inside the received DRO is set and the router 793 currently belongs to the temporary DAG identified by the 794 (RPLInstanceID, DODAGID and Version fields of the) DRO, the router 795 SHOULD cancel any pending DIO transmissions for this temporary 796 DAG. Additionally, the router MAY detach from the temporary DAG 797 immediately. 799 o An intermediate router MUST ignore any Metric Container Option 800 contained in the DRO message. 802 o If Address[Rem] element inside the Route Discovery Option lists 803 the router's own IPv6 address, the router is a part of the route 804 carried in the Route Discovery Option. In this case, the router 805 MUST do the following: 807 * If the H flag inside the Route Discovery Option inside the DRO 808 message is set, the router SHOULD store the state for the 809 forward hop-by-hop route carried inside the Route Discovery 810 Option. This state consists of: 812 + The RPLInstanceID and the DODAGID fields of the DRO. 814 + The route's destination, the target (identified by Target 815 field in Route Discovery Option). 817 + The IPv6 address of the next hop, Address[Rem+1] (unless Rem 818 value equals the number of elements in the Address vector, 819 in which case the target itself is the next hop). 821 The router MUST drop the DRO message without further processing 822 if the H flag inside the Route Discovery Option is set but the 823 router chooses not to store the state for the hop-by-hop route. 825 * If the router already maintains a hop-by-hop state listing the 826 target as the destination and carrying same RPLInstanceID and 827 DODAGID fields as the received DRO and the next hop information 828 in the state does not match the next hop indicated in the 829 received DRO, the router MUST drop the DRO message with no 830 further processing. 832 * The router MUST decrement the Rem field inside the Route 833 Discovery Option and send the DRO further via link-local 834 multicast. 836 8.7. Processing a DRO At The Origin 838 When a router receives a DRO message that lists its IPv6 address in 839 the DODAGID field, the router recognizes itself as the origin for the 840 corresponding P2P route discovery and processes the Route Discovery 841 Option contained in the DRO in the following manner. 843 If the stop flag inside the received DRO is set and the origin still 844 belongs to the temporary DAG it initiated, it SHOULD cancel any 845 pending DIO transmissions for this temporary DAG. Additionally, the 846 origin MAY detach from the temporary DAG immediately. 848 If the Route Discovery Option inside the DRO identifies the 849 discovered route as a source route (H=0), the origin SHOULD store in 850 its memory the discovered route contained in the Address vector. 852 If the Route Discovery Option inside the DRO identifies the 853 discovered route as a hop-by-hop route (H=1), the origin SHOULD store 854 in its memory the state for the discovered route in the manner 855 described in Section 8.6. 857 If the received DRO message contains a Metric Container Option as 858 well, the origin MAY store the values of the routing metrics 859 associated with the discovered route in its memory. This information 860 may be useful in formulating the constraints for any future P2P route 861 discovery to the target. 863 If the A flag is set to one in the received DRO message, the origin 864 SHOULD generate a DRO-ACK message as described in Section 9 and 865 unicast the message to the target. The origin MAY source route the 866 DRO-ACK message to the target using the route contained in the 867 received DRO. If the received DRO established a hop-by-hop route to 868 the target, the origin MAY send the DRO-ACK message along this route. 869 Section 10 describes how a packet may be forwarded along a route 870 discovered using the mechanism described in this document. 872 9. The Discovery Reply Object Acknowledgement (DRO-ACK) 874 0 1 2 3 875 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 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | RPLInstanceID | Version |Seq| Reserved | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | | 880 | DODAGID | 881 | | 882 | | 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 Figure 3: Format of the base Discovery Reply Object Acknowledgement 886 (DRO-ACK) 888 A DRO message may fail to reach the origin due to a number of 889 reasons. Unlike the DIO messages that benefit from Trickle- 890 controlled retransmissions, the DRO messages are prone to loss due to 891 reasons associated with wireless communication. Since a DRO message 892 travels via link-local multicast, it can not use link-level 893 acknowledgements to improve the reliability of its transmission. 894 Also, an intermediate router may drop the DRO message (e.g., because 895 of its inability to store the state for the hop-by-hop route the DRO 896 is establishing). To protect against the potential failure of a DRO 897 message to reach the origin, the target MAY request the origin to 898 send back a DRO Acknowledgement (DRO-ACK) message on receiving a DRO 899 message. Failure to receive such an acknowledgement within the 900 DRO_ACK_WAIT_TIME interval of sending the DRO message forces the 901 target to resend the message. 903 This section defines two new RPL Control Message types: DRO 904 Acknowledgement (DRO-ACK; with code 0x05; to be confirmed by IANA) 905 and Secure DRO-ACK (with code 0x85; to be confirmed by IANA). A DRO- 906 ACK message MUST travel as a unicast message from the origin to the 907 target. The format of a base DRO-ACK message is shown in Figure 3. 908 Various fields in a DRO-ACK message MUST have the same values as the 909 corresponding fields in the DRO message. The field marked as 910 "Reserved" MUST be set to zero on transmission and MUST be ignored on 911 reception. A Secure DRO-ACK message follows the format in Figure 7 912 of [I-D.ietf-roll-rpl], where the base format is same as the base 913 DRO-ACK shown in Figure 3. 915 10. Packet Forwarding Along a P2P Route 917 This document specifies a mechanism to discover P2P routes, which can 918 be either source routes or hop-by-hop ones. A packet MAY use an RH4 919 header [I-D.ietf-6man-rpl-routing-header] to travel along a P2P 920 source route. Travel along a P2P hop-by-hop route requires 921 specifying the RPLInstanceID and the DODAGID to identify the route. 922 This is because P2P route discovery does not use globally unique 923 RPLInstanceID values and hence both the RPLInstanceID, which is a 924 local value assigned by the origin, and the DODAGID, which is an IPv6 925 address belonging to the origin, are required to uniquely identify a 926 P2P hop-by-hop route to a particular destination. A packet MAY 927 include an RPL option [I-D.ietf-6man-rpl-option] inside the IPv6 hop- 928 by-hop options header to travel along a P2P hop-by-hop route. In 929 this case, the origin MUST set the DODAGID of the P2P route as the 930 source IPv6 address of the packet. Further, the origin MUST specify 931 the RPLInstanceID, associated with the P2P route, inside the RPL 932 option and set the O flag inside the RPL option to 1. A router 933 receiving this packet will check the O flag inside the RPL option and 934 correctly infer the source IPv6 address of the packet as the DODAGID 935 of the hop-by-hop route to be used for forwarding the packet further. 937 11. Security Considerations 939 The security considerations for the operation of the reactive P2P 940 route discovery mechanism described in this document are similar to 941 the ones for the operation of RPL (as described in Section 19 of 942 [I-D.ietf-roll-rpl]). Section 10 of RPL specification 943 [I-D.ietf-roll-rpl] describes a variety of security mechanisms to 944 provide data confidentiality, authentication, replay protection and 945 delay protection services. Each RPL control message has a secure 946 version that allows the specification of the level of security and 947 the algorithms used to secure the message. The mechanism defined in 948 this document is based on the use of DIOs to form temporary DAGs and 949 discover P2P routes. These DIOs can be used in their secure versions 950 if desired. New RPL control messages defined in this document (DRO 951 and DRO-ACK) have secure versions as well. Thus, a particular 952 deployment of the reactive P2P route discovery mechanism described in 953 this document can analyze its security requirements and use the 954 appropriate set of RPL security mechanisms that meet those 955 requirements. 957 12. IANA Considerations 959 12.1. Additions to RPL Control Codes 961 IANA is requested to allocate new code points in the "RPL Control 962 Codes" registry for the "Discovery Reply Object" and "Discovery Reply 963 Object Acknowledgement" (and their secure versions) described in this 964 document. 966 +------+--------------------------------------------+---------------+ 967 | Code | Description | Reference | 968 +------+--------------------------------------------+---------------+ 969 | 0x04 | Discovery Reply Object | This document | 970 | 0x05 | Discovery Reply Object Acknowledgement | This document | 971 | 0x84 | Secure Discovery Reply Object | This document | 972 | 0x85 | Secure Discovery Reply Object | This document | 973 | | Acknowledgement | | 974 +------+--------------------------------------------+---------------+ 976 RPL Control Codes 978 12.2. Additions to RPL Control Message Options 980 IANA is requested to allocate a new value in the "RPL Control Message 981 Options" registry for the "Route Discovery Option" described in this 982 document. 984 +-------+-----------------+---------------+ 985 | Value | Meaning | Reference | 986 +-------+-----------------+---------------+ 987 | 10 | Route Discovery | This document | 988 +-------+-----------------+---------------+ 990 RPL Control Message Options 992 13. Acknowledgements 994 Authors gratefully acknowledge the contributions of the following 995 individuals (in alphabetical order) in the development of this 996 document: Dominique Barthel, Thomas Clausen, Richard Kelsey, Phil 997 Levis, Zach Shelby, Pascal Thubert and JP Vasseur. 999 14. References 1001 14.1. Normative References 1003 [I-D.ietf-roll-routing-metrics] 1004 Vasseur, J., Kim, M., Pister, K., Dejean, N., and D. 1005 Barthel, "Routing Metrics used for Path Calculation in Low 1006 Power and Lossy Networks", 1007 draft-ietf-roll-routing-metrics-19 (work in progress), 1008 March 2011. 1010 [I-D.ietf-roll-rpl] 1011 Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., 1012 Kelsey, R., Levis, P., Pister, K., Struik, R., and J. 1013 Vasseur, "RPL: IPv6 Routing Protocol for Low power and 1014 Lossy Networks", draft-ietf-roll-rpl-19 (work in 1015 progress), March 2011. 1017 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1018 Requirement Levels", BCP 14, RFC 2119, March 1997. 1020 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 1021 "The Trickle Algorithm", RFC 6206, March 2011. 1023 14.2. Informative References 1025 [I-D.brandt-roll-rpl-applicability-home-building] 1026 Brandt, A., Baccelli, E., and R. Cragie, "Applicability 1027 Statement: The use of RPL in Building and Home 1028 Environments", 1029 draft-brandt-roll-rpl-applicability-home-building-01 (work 1030 in progress), November 2010. 1032 [I-D.ietf-6man-rpl-option] 1033 Hui, J. and J. Vasseur, "RPL Option for Carrying RPL 1034 Information in Data-Plane Datagrams", 1035 draft-ietf-6man-rpl-option-04 (work in progress), 1036 October 2011. 1038 [I-D.ietf-6man-rpl-routing-header] 1039 Hui, J., Vasseur, J., Culler, D., and V. Manral, "An IPv6 1040 Routing Header for Source Routes with RPL", 1041 draft-ietf-6man-rpl-routing-header-04 (work in progress), 1042 October 2011. 1044 [I-D.ietf-roll-p2p-measurement] 1045 Goyal, M., Baccelli, E., Brandt, A., and J. Martocci, "A 1046 Mechanism to Measure the Quality of a Point-to-point Route 1047 in a Low Power and Lossy Network", 1048 draft-ietf-roll-p2p-measurement-02 (work in progress), 1049 October 2011. 1051 [I-D.ietf-roll-terminology] 1052 Vasseur, J., "Terminology in Low power And Lossy 1053 Networks", draft-ietf-roll-terminology-06 (work in 1054 progress), September 2011. 1056 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 1057 Routing Requirements in Low-Power and Lossy Networks", 1058 RFC 5826, April 2010. 1060 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 1061 "Building Automation Routing Requirements in Low-Power and 1062 Lossy Networks", RFC 5867, June 2010. 1064 Authors' Addresses 1066 Mukul Goyal (editor) 1067 University of Wisconsin Milwaukee 1068 3200 N Cramer St 1069 Milwaukee, WI 53201 1070 USA 1072 Phone: +1 414 2295001 1073 Email: mukul@uwm.edu 1075 Emmanuel Baccelli 1076 INRIA 1078 Phone: +33-169-335-511 1079 Email: Emmanuel.Baccelli@inria.fr 1080 URI: http://www.emmanuelbaccelli.org/ 1082 Matthias Philipp 1083 INRIA 1085 Phone: +33-169-335-511 1086 Email: Matthias.Philipp@inria.fr 1087 Anders Brandt 1088 Sigma Designs 1089 Emdrupvej 26A, 1. 1090 Copenhagen, Dk-2100 1091 Denmark 1093 Phone: +45-29609501 1094 Email: abr@sdesigns.dk 1096 Jerald Martocci 1097 Johnson Controls 1098 507 E Michigan St 1099 Milwaukee, WI 53202 1100 USA 1102 Phone: +1 414-524-4010 1103 Email: jerald.p.martocci@jci.com