idnits 2.17.1 draft-ietf-roll-dao-projection-09.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 : ---------------------------------------------------------------------------- ** There are 19 instances of too long lines in the document, the longest one being 3 characters in excess of 72. -- The draft header indicates that this document updates RFC6550, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (17 November 2019) is 1593 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-28 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL P. Thubert, Ed. 3 Internet-Draft Cisco Systems 4 Updates: 6550 (if approved) R.A. Jadhav 5 Intended status: Standards Track Huawei Tech 6 Expires: 20 May 2020 M. Gillmore 7 Itron 8 17 November 2019 10 Root initiated routing state in RPL 11 draft-ietf-roll-dao-projection-09 13 Abstract 15 This document enables a RPL Root to install and maintain Projected 16 Routes within its DODAG, along a selected set of nodes that may or 17 may not include self, for a chosen duration. This potentially 18 enables routes that are more optimized or resilient than those 19 obtained with the classical distributed operation of RPL, either in 20 terms of the size of a source-route header or in terms of path 21 length, which impacts both the latency and the packet delivery ratio. 22 Projected Routes may be installed in either Storing and Non-Storing 23 Modes Instances of the classical RPL operation, resulting in 24 potentially hybrid situations where the mode of some Projected Routes 25 is different from that of the other routes in the RPL Instance. 27 Status of This Memo 29 This Internet-Draft is submitted 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 https://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 20 May 2020. 44 Copyright Notice 46 Copyright (c) 2019 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 (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.2. Subset of a 6LoWPAN Glossary . . . . . . . . . . . . . . 4 64 2.3. Other Terms . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.4. References . . . . . . . . . . . . . . . . . . . . . . . 5 66 3. Extending RFC 6550 . . . . . . . . . . . . . . . . . . . . . 6 67 4. Identifying a Path . . . . . . . . . . . . . . . . . . . . . 7 68 5. New RPL Control Messages and Options . . . . . . . . . . . . 7 69 5.1. New P-DAO Request Control Message . . . . . . . . . . . . 7 70 5.2. New PDR-ACK Control Message . . . . . . . . . . . . . . . 8 71 5.3. Route Projection Options . . . . . . . . . . . . . . . . 10 72 5.4. Sibling Information Option . . . . . . . . . . . . . . . 12 73 6. Projected DAO . . . . . . . . . . . . . . . . . . . . . . . . 13 74 6.1. Non-Storing Mode Projected Route . . . . . . . . . . . . 14 75 6.2. Storing-Mode Projected Route . . . . . . . . . . . . . . 16 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 78 8.1. New RPL Control Codes . . . . . . . . . . . . . . . . . . 18 79 8.2. New RPL Control Message Options . . . . . . . . . . . . . 19 80 8.3. New SubRegistry for the Projected DAO Request (PDR) 81 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 19 82 8.4. New SubRegistry for the PDR-ACK Flags . . . . . . . . . . 20 83 8.5. New Subregistry for the PDR-ACK Acceptance Status 84 values . . . . . . . . . . . . . . . . . . . . . . . . . 20 85 8.6. New Subregistry for the PDR-ACK Rejection Status 86 values . . . . . . . . . . . . . . . . . . . . . . . . . 20 87 8.7. New SubRegistry for the Route Projection Options (RPO) 88 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 21 89 8.8. New SubRegistry for the Sibling Information Option (SIO) 90 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 21 91 8.9. Error in Projected Route ICMPv6 Code . . . . . . . . . . 22 92 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 93 10. Normative References . . . . . . . . . . . . . . . . . . . . 22 94 11. Informative References . . . . . . . . . . . . . . . . . . . 23 95 Appendix A. Applications . . . . . . . . . . . . . . . . . . . . 24 96 A.1. Loose Source Routing in Non-storing Mode . . . . . . . . 24 97 A.2. Transversal Routes in storing and non-storing modes . . . 25 98 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 27 99 B.1. Using storing mode P-DAO in non-storing mode MOP . . . . 27 100 B.2. Projecting a storing-mode transversal route . . . . . . . 28 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 103 1. Introduction 105 RPL, the "Routing Protocol for Low Power and Lossy Networks" 106 [RFC6550] (LLNs), is a generic Distance Vector protocol that is well 107 suited for application in a variety of low energy Internet of Things 108 (IoT) networks. RPL forms Destination Oriented Directed Acyclic 109 Graphs (DODAGs) in which the Root often acts as the Border Router to 110 connect the RPL domain to the Internet. The Root is responsible to 111 select the RPL Instance that is used to forward a packet coming from 112 the Internet into the RPL domain and set the related RPL information 113 in the packets. 115 The 6TiSCH architecture [6TiSCH-ARCHI] leverages RPL for its routing 116 operations and considers the Deterministic Networking Architecture 117 [RFC8655] as one possible model whereby the device resources and 118 capabilities are exposed to an external controller which installs 119 routing states into the network based on some objective functions 120 that reside in that external entity. With DetNet and 6TiSCH, the 121 component of the controller that is responsible of computing routes 122 is called a Path Computation Element ([PCE]). 124 Based on heuristics of usage, path length, and knowledge of device 125 capacity and available resources such as battery levels and 126 reservable buffers, a PCE with a global visibility on the system can 127 compute P2P routes that are more optimized for the current needs as 128 expressed by the objective function. 130 This draft proposes a protocol extension to RPL that enables the Root 131 to install a limited amount of centrally-computed routes in a RPL 132 graph, on behalf of a PCE that may be collocated or separated from 133 the Root. Those extensions enable loose source routing down in RPL 134 Non-Storing Mode and transversal routes inside the DODAG regardless 135 of the RPL Mode of Operation (MOP). 137 As opposed to the classical RPL operations where routes are injected 138 by the Target nodes, the protocol extension enables the Root of a 139 DODAG to project the routes that are needed onto the nodes where they 140 should be installed. This specification uses the term Projected 141 Route to refer to those routes. A Projected Route may be a stand- 142 alone path to a Target or a segment in a complex Track [6TiSCH-ARCHI] 143 that provides redundant forwarding solutions to a destination to 144 improve reliability and availability of the wireless transmissions 145 [RAW-PS]. 147 Projected Routes must be used with the parsimony to limit the amount 148 of state that is installed in each device to fit within its 149 resources, and to limit the amount of rerouted traffic to fit within 150 the capabilities of the transmission links. The method to learn the 151 node capabilities and the resources that are available in the devices 152 and in the network are out of scope for this document. 154 In RPL Non-Storing Mode, the Root has enough information to build a 155 basic DODAG topology. This document adds the capability for nodes to 156 advertise sibling information in order to improve the topological 157 awareness of the Root. This specification uses the RPL Root as a 158 proxy to the PCE. The algorithm to compute the paths and the 159 protocol used by an external PCE to obtain the topology of the 160 network from the Root are out of scope for this document. 162 2. Terminology 164 2.1. BCP 14 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 168 "OPTIONAL" in this document are to be interpreted as described in BCP 169 14 [RFC2119][RFC8174] when, and only when, they appear in all 170 capitals, as shown here. 172 2.2. Subset of a 6LoWPAN Glossary 174 This document often uses the following acronyms: 176 6BBR: 6LoWPAN Backbone Router 178 6LBR: 6LoWPAN Border Router 180 6LN: 6LoWPAN Node 182 6LR: 6LoWPAN Router 184 DAD: Duplicate Address Detection 186 DODAG: Destination-Oriented Directed Acyclic Graph 188 LLN: Low-Power and Lossy Network 190 NA: Neighbor Advertisement 191 NCE: Neighbor Cache Entry 193 ND: Neighbor Discovery 195 NDP: Neighbor Discovery Protocol 197 NS: Neighbor Solicitation 199 RPL: IPv6 Routing Protocol for LLNs [RFC6550] 201 CMO: Control Message Option 203 DAO: Destination Advertisement Object 205 VIO: A Via Information Option, used in Storing Mode P-DAO messages. 207 SRVIO: A Source-Routed Via Information Option, used in Non-Storing 208 Mode P-DAO messages. 210 RPO: A Route Projection Option; it can be a VIO or an SRVIO. 212 P-DAO: A Projected DAO is a DAO message sent by the RPL Root to 213 install a Projected Route. 215 RTO: RPL Target Option 217 RAN: RPL-Aware Node 219 RA: Router Advertisement 221 RS: Router Solicitation 223 2.3. Other Terms 225 Projected Route: A Projected Route is a serial path that is computed 226 and installed remotely by a RPL Root. 228 Track: The term Track is used in this document to refer to a complex 229 path, e.g., a DODAG, that incorporates redundant Projected Routes 230 towards a destination for increased reliability, high availability 231 and load balancing. 233 2.4. References 235 In this document, readers will encounter terms and concepts that are 236 discussed in the following documents: 238 * "Routing Protocol for Low Power and Lossy Networks" [RFC6550], and 240 * "Terminology in Low power And Lossy Networks" [RFC7102]. 242 3. Extending RFC 6550 244 This specification introduces two new RPL Control Messages to enable 245 a RPL Aware Node (RAN) to request the establisment of a path from 246 self to a Target. A RAN may request the installation of a path by 247 sending a new P-DAO Request PDR) Message to the Root. The Root 248 confirms with a new PDR-ACK message back to the requester RAN with a 249 completion status once it is done installing the path. See 250 Section 5.1 for more. 252 Section 6.7 of [RFC6550] specifies RPL Control Message Options (CMO) 253 to be placed in RPL messages such as the Destination Advertisement 254 Object (DAO) message. The RPL Target Option (RTO) and the Transit 255 Information Option (TIO) are such options. In Non-Storing Mode, the 256 TIO option is used in the DAO message to indicate a parent within a 257 DODAG. The TIO applies to the RTOs that immedially preceed it in the 258 message. Options may be factorized; multiple TIOs may be present to 259 indicate multiple routes to the one or more contiguous addresses 260 indicated in the RTOs that immediately precede the TIOs in the RPL 261 message. 263 This specification introduces two new CMOs referred to as Route 264 Projection Options (RPO) to install Projected Routes. One RPO is the 265 Via Information Option (VIO) and the other is the Source-Routed VIO 266 (SRVIO). The VIO installs a route on each hop along a Projected 267 Route (in a fashion analogous to RPL Storing Mode) whereas the SRVIO 268 installs a source-routing state at the ingress node, which uses that 269 state to encapsulate a packet with an IPv6 Routing Header in a 270 fashion similar to RPL Non-Storing Mode. Like the TIO, the RPOs MUST 271 be preceded by exactly one RTO to which they apply, and they can be 272 factorized: multiple contiguous RPOs indicate alternate paths to the 273 Target, more in Section 5.3. 275 This specification also introduces a new CMO to enable a RAN to 276 advertise (some of) its siblings to the Root, using a new Sibling 277 Information Option (SIO) as specified in Section 5.4. 279 4. Identifying a Path 281 It must be noted that RPL has a concept of Instance to represent 282 different routing topologies but does not have a concept of an 283 administrative distance, which exists in certain proprietary 284 implementations to sort out conflicts between multiple sources of 285 routing information within one routing topology. This draft conforms 286 the Instance model as follows: 288 * If the PCE needs to influence a particular Instance to add better 289 routes in conformance with the routing objectives in that 290 Instance, it may do so as long as it does not create a loop. A 291 Projected Route is always preferred over a route that is learned 292 via RPL. 294 * A PCE that installs a more specific (say, Traffic Engineered) and 295 possibly complex path (aka a Track) towards a particular Target 296 MUST use a Local RPL Instance (see section 5 of [RFC6550]) 297 associated to that Target to identify the path. We refer to that 298 Local RPLInstanceID as TrackID. A projected path is uniquely 299 identified within the RPL domain by the tuple (Target address, 300 TrackID). When packet is placed on a Track, a RPL Packet 301 Information (RPI) is added with the TrackID as RPLInstanceID. The 302 RPLInstanceID has the 'D' flag set, indicating that the 303 destination address in the IPv6 header is the Target that is used 304 to identify the Track. 306 * A packet that is routed over a projected path MUST NOT be placed 307 over a different RPL Instance again. A packet that is placed on a 308 Global Instance MAY be injected in a Local Instance based on a 309 network policy and the Local Instance configuration. 311 A Projected Route is a serial path that may the whole path or a 312 segment in a complex Track, in which case multiple Projected Routes 313 are installed with the same tuple (Target address, TrackID) and a 314 different segment ID. A node that is present on more than one 315 segment in a Track may be able to use either of the Projected Routes 316 to forward towards the Target. The selection of the best route in a 317 Track at forwarding time is out of scope for this document. [RAW-PS] 318 elaborates on that particular problem. 320 5. New RPL Control Messages and Options 322 5.1. New P-DAO Request Control Message 324 The PDR is sent to the Root to request a new Path. Exactly one 325 Target Options MUST be present. 327 The format of P-DAO Request (PDR) Base Object is as follows: 329 0 1 2 3 330 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 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | TrackID |K|R| Flags | PDRLifetime | PDRSequence | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Option(s)... 335 +-+-+-+-+-+-+-+-+ 337 Figure 1: New P-DAO Request Format 339 TrackID: 8-bit field indicating the RPLInstanceID associated with 340 the Track. It is set to zero upon the first request for a new 341 Track and then to the TrackID once the Track was created, to 342 either renew it of destroy it. 344 K: The 'K' flag is set to indicate that the recipient is expected to 345 send a PDR-ACK back. 347 R: The 'R' flag is set to indicate that the Requested path should be 348 redundant. 350 PDRLifetime: 8-bit unsigned integer. The requested lifetime for the 351 Track expressed in Lifetime Units (obtained from the Configuration 352 option). A PDR with a fresher PDRSequence refreshes the lifetime, 353 and a PDRLifetime of 0 indicates that the track should be 354 destroyed. 356 PDRSequence: 8-bit wrapping sequence number. The PDRSequence obeys 357 the operation in section 7.2 of [RFC6550]. It is incremented at 358 each PDR message and echoed in the PDR-ACK by the Root. The 359 PDRSequence is used to correlate a PDR-ACK message with the PDR 360 message that triggeted it. 362 5.2. New PDR-ACK Control Message 364 The new PDR-ACK is sent as a response to a PDR message with the 'K' 365 flag set. Its format is as follows: 367 0 1 2 3 368 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 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | TrackID | PDR-ACK Status| Flags | Track Lifetime| 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | PDRSequence | Reserved | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Option(s)... 375 +-+-+-+-+-+-+-+ 377 Figure 2: New PDR-ACK Control Message Format 379 TrackID: The RPLInstanceID of the Track that was created. Set to 0 380 when no Track is created. 382 PDR-ACK Status: Indicates the completion. Substructured as 383 indicated in Figure 3. 385 Track Lifetime: Indicates that remaining Lifetime for the Track, 0 386 if the Track was destroyed or not created. 388 PDRSequence: 8-bit wrapping sequence number. It is incremented at 389 each PDR message and echoed in the PDR-ACK. 391 The PDR-ACK Status is further substructured as follows: 393 0 394 0 1 2 3 4 5 6 7 395 +-+-+-+-+-+-+-+-+ 396 |E|R| Value | 397 +-+-+-+-+-+-+-+-+ 399 Figure 3: PDR-ACK status Format 401 The PDR-ACK Status subfields are: 403 E: 1-bit flag. Set to indicate a rejection. When not set, a value 404 of 0 indicates Success/Unqualified acceptance and other values 405 indicate "not an outright rejection". 407 R: 1-bit flag. Reserved, MUST be set to 0 by the sender and ignored 408 by the receiver. 410 Status Value: 6-bit unsigned integer. Values depedning on the 411 setting of the 'E' flag as indicated respectively in Table 4 and 412 Table 5. 414 5.3. Route Projection Options 416 The RPOs indicate a series of IPv6 addresses that can be compressed 417 using the method defined in the "6LoWPAN Routing Header" [RFC8138] 418 specification using the address of the Root found in the DODAGID 419 field of DIO messages as Compression Reference. 421 An RPO indicates a Projected Route that can be a serial Track in full 422 or a segment of a more complex Track. In the latter case, multiple 423 RPO may be placed after a same Target Option. The Track is 424 identified by a TrackID that is a Local RPLInstanceID to the Target 425 of the Track. 427 The format of RPOs is as follows: 429 0 1 2 3 430 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 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | Type | Option Length |Comp.| Flags | TrackID | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Track Sequence| Track Lifetime| SegmentID |Segm. Sequence | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | | 437 + + 438 . . 439 . Via Address 1 . 440 . . 441 + + 442 | | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | | 445 . .... . 446 | | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | | 449 + + 450 . . 451 . Via Address n . 452 . . 453 + + 454 | | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 Figure 4: Via Information option format 459 Option Type: 0x0A for VIO, 0x0B for SRVIO (to be confirmed by IANA) 460 Option Length: In bytes; variable, depending on the number of Via 461 Addresses. 463 Compression Type: 3-bit unsigned integer. This is the SRH-6LoRH 464 Type as defined in figure 7 in section 5.1 of [RFC8138] that 465 corresponds to the compression used for all the Via Addresses. 467 TrackID: 8-bit field indicating the topology Instance associated 468 with the Track. The tuple (Target Address, TrackID) forms a 469 unique ID of the Track in the RPL domain. 471 Track Sequence: 8-bit unsigned integer. The Track Sequence obeys 472 the operation in section 7.2 of [RFC6550] and the lollipop starts 473 at 255. The Track Sequence is set by the Root and incremented 474 each time the Root refreshes that Track globally. A Track 475 Sequence that is fresher than the current on deprecates any state 476 for the Track. A Track Sequence that is current adds to any state 477 that was learned for that Track Sequence. A RTO with a Track 478 Sequence that is not as fresh as the current one is ignored. 480 Track Lifetime: 8-bit unsigned integer. The length of time in 481 Lifetime Units (obtained from the Configuration option) that the 482 Track is usable. The period starts when a new Track Sequence is 483 seen. A value of 255 (0xFF) represents infinity. A value of zero 484 (0x00) indicates a loss of reachability. A DAO message that 485 contains a Via Information option with a Path Lifetime of zero for 486 a Target is referred as a No-Path (for that Target) in this 487 document. 489 SegmentID: 8-bit field that identifies a segment within a Track. A 490 Value of 0 is used to signal a serial Track. 492 Segment Sequence: 8-bit unsigned integer. The Segment Sequence 493 obeys the operation in section 7.2 of [RFC6550] and the lollipop 494 starts at 255. When the Root of the DODAG needs to update a 495 single segment in a Track, but does not need to modify the rest of 496 the Track, it increments the Segment Sequence but not the Track 497 Sequence. The segment information indicated in the RTO deprecates 498 any state for the segment indicated by the SegmentID within the 499 indicated Track and sets up the new information. A RTO with a 500 Segment Sequence that is not as fresh as the current one is 501 ignored. a RTO for a given target with the same (TrackID, Track 502 Sequence, SegmentID, Segment Sequence) indicates a retry; it MUST 503 NOT change the segment and MUST be propagated or answered as the 504 first copy. 506 Via Address: 2 to 16 bytes, a compressed IPv6 Address. A Via 507 Address indicates the next hop within the path towards the 508 destination(s) that is indicated in the Target option that 509 immediately precede the RPO in the DAO message. Via Addresses are 510 indicated in the order of the path from the ingress to the egress 511 nodes. All Via addresses are expressed in the same size as 512 indicated by the Compression Type. 514 An RPO MUST contain at least one Via Address, and a Via Address MUST 515 NOT be present more than once, otherwise the RPO MUST be ignored. 517 5.4. Sibling Information Option 519 The Sibling Information Option (SIO) provides indication on siblings 520 that could be used by the Root to form Projected Routes. The format 521 of SIOs is as follows: 523 0 1 2 3 524 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 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | Type | Option Length |Comp.|B| Flags | Opaque | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | Step of Rank | Reserved | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | | 531 + + 532 . . 533 . Sibling Address . 534 . . 535 + + 536 | | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 Figure 5: Sibling Information Option Format 541 Option Type: 0x0C (to be confirmed by IANA) 543 Option Length: In bytes; variable, depending on the number of Via 544 Addresses. 546 Compression Type: 3-bit unsigned integer. This is the SRH-6LoRH 547 Type as defined in figure 7 in section 5.1 of [RFC8138] that 548 corresponds to the compression used for the Sibling Address. 550 B: 1-bit flag that is set to indicate that the connectivity to the 551 sibling is bidirectional and roughly symmetrical. In that case, 552 only one of the siblings may report the SIO for the hop. If 'B' 553 is not set then the SIO only indicates connectivity from the 554 sibling to this node, and does not provide information on the hop 555 from this node to the sibling. 557 Opaque: MAY be used to carry information that the node and the Root 558 understand, e.g., a particular representation of the Link 559 properties such as a proprietary Link Quality Information for 560 packets received from the sibling. An industraial Alliance that 561 uses RPL for a particular use / environment MAY redefine the use 562 of this field to fit its needs. 564 Step of Rank: 16-bit unsigned integer. This is the Step of Rank 565 [RFC6550] as computed by the Objective Function between this node 566 and the sibling. 568 Reserved: MUST be set to zero by the sender and MUST be ignored by 569 the receiver. 571 Sibling Address: 2 to 16 bytes, the IPv6 Address of the sibling in a 572 [RFC8138] compressed form as indicated by the Compression Type 573 field. 575 An SIO MAY be immediately followed by a DAG Metric Container. In 576 that case the DAG Metric Container provides additional metrics for 577 the hop from the Sibling to this node. 579 6. Projected DAO 581 This draft adds a capability to RPL whereby the Root of a DODAG 582 projects a route by sending an extended DAO message called one or 583 more Projected-DAO (P-DAO) messages to an arbitrary router in the 584 DODAG, indicating one or more sequence(s) of routers inside the DODAG 585 via which the Target(s) indicated in the RPL Target Option(s) (RTO) 586 can be reached. 588 A P-DAO is sent from a global address of the Root to a global address 589 of the recipient, and MUST be confirmed by a DAO-ACK, which is sent 590 back to a global address of the Root. 592 A P-DAO message MUST contain at least one RTO and at least one RPO 593 following it. There can be at most one such sequence of RTOs and 594 then RPOs. 596 Like a classical DAO message, a P-DAO causes a change of state only 597 if it is "new" per section 9.2.2. "Generation of DAO Messages" of 598 the RPL specification [RFC6550]; this is determined using the Track 599 Sequence and the Segment Sequence information from the RPO as opposed 600 to the Path Sequence from a TIO. Also, a Path Lifetime of 0 in an 601 RPO indicates that a route is to be removed. 603 There are two kinds of operation for the Projected Routes, the 604 Storing Mode and the Non-Storing Mode. 606 * The Non-Storing Mode is discussed in Section 6.1. It uses an 607 SRVIO that carries a list of Via Addresses to be used as a source- 608 routed path to the Target. The recipient of the P-DAO is the 609 ingress router of the source-routed path. Upon a Non-Storing Mode 610 P-DAO, the ingress router installs a source-routed state to the 611 Target and replies to the Root directly with a DAO-ACK message. 613 * The Storing Mode is discussed in Section 6.2. It uses a VIO with 614 one Via Address per consecutive hop, from the ingress to the 615 egress of the path, including the list of all intermediate routers 616 in the data path order. The Via Addresses indicate the routers in 617 which the routing state to the Target have to be installed via the 618 next Via Address in the VIO. In normal operations, the P-DAO is 619 propagated along the chain of Via Routers from the egress router 620 of the path till the ingress one, which confirms the installation 621 to the Root with a DAO-ACK message. Note that the Root may be the 622 ingress and it may be the egress of the path, that it can also be 623 neither but it cannot be both. 625 In case of a forwarding error along a Projected Route, an ICMP error 626 is sent to the Root with a new Code "Error in Projected Route" (See 627 Section 8.9). The Root can then modify or remove the Projected 628 Route. The "Error in Projected Route" message has the same format as 629 the "Destination Unreachable Message", as specified in RFC 4443 630 [RFC4443]. The portion of the invoking packet that is sent back in 631 the ICMP message SHOULD record at least up to the routing header if 632 one is present, and the routing header SHOULD be consumed by this 633 node so that the destination in the IPv6 header is the next hop that 634 this node could not reach. if a 6LoWPAN Routing Header (6LoRH) 635 [RFC8138] is used to carry the IPv6 routing information in the outter 636 header then that whole 6LoRH information SHOULD be present in the 637 ICMP message. The sender and exact operation depend on the Mode and 638 is described in Section 6.1 and Section 6.2 respectively. 640 6.1. Non-Storing Mode Projected Route 642 As illustrated in Figure 6, a P-DAO that carries an SRVIO enables the 643 Root to install a source-routed path towards a Target in any 644 particular router; with this path information the router can add a 645 source routed header reflecting the Projected Route to any packet for 646 which the current destination either is the said Target or can be 647 reached via the Target. 649 ------+--------- 650 | Internet 651 | 652 +-----+ 653 | | Border Router 654 | | (RPL Root) 655 +-----+ | P ^ | 656 | | DAO | ACK | Loose 657 o o o o router V | | Source 658 o o o o o o o o o | P-DAO . Route 659 o o o o o o o o o o | Source . Path 660 o o o o o o o o o | Route . From 661 o o o o o o o o | Path . Root 662 o o o o o Target V . To 663 o o o o | Desti- 664 o o o o | nation 665 destination V 667 LLN 669 Figure 6: Projecting a Non-Storing Route 671 A route indicated by an SRVIO may be loose, meaning that the node 672 that owns the next listed Via Address is not necessarily a neighbor. 673 Without proper loop avoidance mechanisms, the interaction of loose 674 source routing and other mechanisms may effectively cause loops. In 675 order to avoid those loops, if the router that installs a Projected 676 Route does not have a connected route (a direct adjacency) to the 677 next soure routed hop and fails to locate it as a neighbor or a 678 neighbor of a neighbor, then it MUST ensure that it has another 679 Projected Route to the next loose hop under the control of the same 680 route computation system, otherwise the P-DAO is rejected. 682 When forwarding a packet to a destination for which the router 683 determines that routing happens via the Target, the router inserts 684 the source routing header in the packet to reach the Target. In the 685 case of a loose source-routed path, there MUST be either a neighbor 686 that is adjacent to the loose next hop, on which case the packet s 687 forwarded to that neighbor, or a source-routed path to the loose next 688 hop; in the latter case, another encapsulation takes place and the 689 process possibly recurses; otherwise the packet is dropped. 691 In order to add a source-routing header, the router encapsulates the 692 packet with an IP-in-IP header and a non-storing mode source routing 693 header (SRH) [RFC6554]. In the uncompressed form the source of the 694 packet would be self, the destination would be the first Via Address 695 in the SRVIO, and the SRH would contain the list of the remaining Via 696 Addresses and then the Target. 698 In practice, the router will normally use the "IPv6 over Low-Power 699 Wireless Personal Area Network (6LoWPAN) Paging Dispatch" [RFC8025] 700 to compress the RPL artifacts as indicated in [RFC8138]. In that 701 case, the router indicates self as encapsulator in an IP-in-IP 6LoRH 702 Header, and places the list of Via Addresses in the order of the VIO 703 and then the Target in the SRH 6LoRH Header. 705 In case of a forwarding error along a Source Route path, the node 706 that fails to forward SHOULD send an ICMP error with a code "Error in 707 Source Routing Header" back to the source of the packet, as described 708 in section 11.2.2.3. of [RFC6550]. Upon this message, the 709 encapsulating node SHOULD stop using the source route path for a 710 period of time and it SHOULD send an ICMP message with a Code "Error 711 in Projected Route" to the Root. Failure to follow these steps may 712 result in packet loss and wasted resources along the source route 713 path that is broken. 715 6.2. Storing-Mode Projected Route 717 As illustrated in Figure 7, the Storing Mode route projection is used 718 by the Root to install a routing state towards a Target in the 719 routers along a segment between an ingress and an egress router; this 720 enables the routers to forward along that segment any packet for 721 which the next loose hop is the said Target, for Instance a loose 722 source routed packet for which the next loose hop is the Target, or a 723 packet for which the router has a routing state to the final 724 destination via the Target. 726 ------+--------- 727 | Internet 728 | 729 +-----+ 730 | | Border Router 731 | | (RPL Root) 732 +-----+ | ^ | 733 | | DAO | ACK | 734 o o o o | | | 735 o o o o o o o o o | ^ | Projected . 736 o o o o o o o o o o | | DAO | Route . 737 o o o o o o o o o | ^ | . 738 o o o o o o o o v | DAO v . 739 o o LLN o o o | 740 o o o o o Loose Source Route Path | 741 o o o o From Root To Destination v 743 Figure 7: Projecting a route 745 In order to install the relevant routing state along the segment 746 between an ingress and an egress routers, the Root sends a unicast 747 P-DAO message to the egress router of the routing segment that must 748 be installed. The P-DAO message contains the ordered list of hops 749 along the segment as a direct sequence of Via Information options 750 that are preceded by one or more RPL Target options to which they 751 relate. Each Via Information option contains a Path Lifetime for 752 which the state is to be maintained. 754 The Root sends the P-DAO directly to the egress node of the segment. 755 In that P-DAO, the destination IP address matches the Via Address in 756 the last VIO. This is how the egress recognizes its role. In a 757 similar fashion, the ingress node recognizes its role as it matches 758 Via Address in the first VIO. 760 The egress node of the segment is the only node in the path that does 761 not install a route in response to the P-DAO; it is expected to be 762 already able to route to the Target(s) on its own. It may either be 763 the Target, or may have some existing information to reach the 764 Target(s), such as a connected route or an already installed 765 Projected Route. If one of the Targets cannot be located, the node 766 MUST answer to the Root with a negative DAO-ACK listing the Target(s) 767 that could not be located (suggested status 10 to be confirmed by 768 IANA). 770 If the egress node can reach all the Targets, then it forwards the 771 P-DAO with unchanged content to its loose predecessor in the segment 772 as indicated in the list of Via Information options, and recursively 773 the message is propagated unchanged along the sequence of routers 774 indicated in the P-DAO, but in the reverse order, from egress to 775 ingress. 777 The address of the predecessor to be used as destination of the 778 propagated DAO message is found in the Via Information option the 779 precedes the one that contain the address of the propagating node, 780 which is used as source of the packet. 782 Upon receiving a propagated DAO, an intermediate router as well as 783 the ingress router install a route towards the DAO Target(s) via its 784 successor in the P-DAO; the router locates the VIO that contains its 785 address, and uses as next hop the address found in the Via Address 786 field in the following VIO. The router MAY install additional routes 787 towards the addresses that are located in VIOs that are after the 788 next one, if any, but in case of a conflict or a lack of resource, a 789 route to a Target installed by the Root has precedence. 791 The process recurses till the P-DAO is propagated to ingress router 792 of the segment, which answers with a DAO-ACK to the Root. 794 Also, the path indicated in a P-DAO may be loose, in which case the 795 reachability to the next hop has to be asserted. Each router along 796 the path indicated in a P-DAO is expected to be able to reach its 797 successor, either with a connected route (direct neighbor), or by 798 routing, for Instance following a route installed previously by a DAO 799 or a P-DAO message. If that route is not connected then a recursive 800 lookup may take place at packet forwarding time to find the next hop 801 to reach the Target(s). If it does not and cannot reach the next 802 router in the P-DAO, the router MUST answer to the Root with a 803 negative DAO-ACK indicating the successor that is unreachable 804 (suggested status 11 to be confirmed by IANA). 806 A Path Lifetime of 0 in a Via Information option is used to clean up 807 the state. The P-DAO is forwarded as described above, but the DAO is 808 interpreted as a No-Path DAO and results in cleaning up existing 809 state as opposed to refreshing an existing one or installing a new 810 one. 812 In case of a forwarding error along a Storing Mode Projected Route, 813 the node that fails to forward SHOULD send an ICMP error with a code 814 "Error in Projected Route" to the Root. Failure to do so may result 815 in packet loss and wasted resources along the Projected Route that is 816 broken. 818 7. Security Considerations 820 This draft uses messages that are already present in RPL [RFC6550] 821 with optional secured versions. The same secured versions may be 822 used with this draft, and whatever security is deployed for a given 823 network also applies to the flows in this draft. 825 TODO: should probably consider how P-DAO messages could be abused by 826 a) rogue nodes b) via replay of messages c) if use of P-DAO messages 827 could in fact deal with any threats? 829 8. IANA Considerations 831 8.1. New RPL Control Codes 833 This document extends the IANA Subregistry created by RFC 6550 for 834 RPL Control Codes as indicated in Table 1: 836 +------+-----------------------------+---------------+ 837 | Code | Description | Reference | 838 +======+=============================+===============+ 839 | 0x09 | Projected DAO Request (PDR) | This document | 840 +------+-----------------------------+---------------+ 841 | 0x0A | PDR-ACK | This document | 842 +------+-----------------------------+---------------+ 844 Table 1: New RPL Control Codes 846 8.2. New RPL Control Message Options 848 This document extends the IANA Subregistry created by RFC 6550 for 849 RPL Control Message Options as indicated in Table 2: 851 +-------+--------------------------------------+---------------+ 852 | Value | Meaning | Reference | 853 +=======+======================================+===============+ 854 | 0x0B | Via Information option | This document | 855 +-------+--------------------------------------+---------------+ 856 | 0x0C | Source-Routed Via Information option | This document | 857 +-------+--------------------------------------+---------------+ 858 | 0x0D | Sibling Information option | This document | 859 +-------+--------------------------------------+---------------+ 861 Table 2: RPL Control Message Options 863 8.3. New SubRegistry for the Projected DAO Request (PDR) Flags 865 IANA is required to create a registry for the 8-bit Projected DAO 866 Request (PDR) Flags field. Each bit is tracked with the following 867 qualities: 869 * Bit number (counting from bit 0 as the most significant bit) 871 * Capability description 873 * Reference 875 Registration procedure is "Standards Action" [RFC8126]. The initial 876 allocation is as indicated in Table 3: 878 +------------+------------------------+---------------+ 879 | Bit number | Capability description | Reference | 880 +============+========================+===============+ 881 | 0 | PDR-ACK request (K) | This document | 882 +------------+------------------------+---------------+ 883 | 1 | Requested path should | This document | 884 | | be redundant (R) | | 885 +------------+------------------------+---------------+ 887 Table 3: Initial PDR Flags 889 8.4. New SubRegistry for the PDR-ACK Flags 891 IANA is required to create an subregistry for the 8-bit PDR-ACK Flags 892 field. Each bit is tracked with the following qualities: 894 * Bit number (counting from bit 0 as the most significant bit) 896 * Capability description 898 * Reference 900 Registration procedure is "Standards Action" [RFC8126]. No bit is 901 currently defined for the PDR-ACK Flags. 903 8.5. New Subregistry for the PDR-ACK Acceptance Status values 905 IANA is requested to create a new subregistry for the PDR-ACK 906 Acceptance Status values. 908 * Possible values are 6-bit unsigned integers (0..63). 910 * Registration procedure is "Standards Action" [RFC8126]. 912 * Initial allocation is as indicated in Table 4: 914 +-------+------------------------+---------------+ 915 | Value | Meaning | Reference | 916 +=======+========================+===============+ 917 | 0 | Unqualified acceptance | This document | 918 +-------+------------------------+---------------+ 920 Table 4: Acceptance values of the PDR-ACK Status 922 8.6. New Subregistry for the PDR-ACK Rejection Status values 924 IANA is requested to create a new subregistry for the PDR-ACK 925 Rejection Status values. 927 * Possible values are 6-bit unsigned integers (0..63). 929 * Registration procedure is "Standards Action" [RFC8126]. 931 * Initial allocation is as indicated in Table 5: 933 +-------+-----------------------+---------------+ 934 | Value | Meaning | Reference | 935 +=======+=======================+===============+ 936 | 0 | Unqualified rejection | This document | 937 +-------+-----------------------+---------------+ 939 Table 5: Rejection values of the PDR-ACK Status 941 8.7. New SubRegistry for the Route Projection Options (RPO) Flags 943 IANA is requested to create a new subregistry for the 5-bit Route 944 Projection Options (RPO) Flags field. Each bit is tracked with the 945 following qualities: 947 * Bit number (counting from bit 0 as the most significant bit) 949 * Capability description 951 * Reference 953 Registration procedure is "Standards Action" [RFC8126]. No bit is 954 currently defined for the Route Projection Options (RPO) Flags. 956 8.8. New SubRegistry for the Sibling Information Option (SIO) Flags 958 IANA is required to create a registry for the 5-bit Sibling 959 Information Option (SIO) Flags field. Each bit is tracked with the 960 following qualities: 962 * Bit number (counting from bit 0 as the most significant bit) 964 * Capability description 966 * Reference 968 Registration procedure is "Standards Action" [RFC8126]. The initial 969 allocation is as indicated in Table 6: 971 +------------+-----------------------------------+---------------+ 972 | Bit number | Capability description | Reference | 973 +============+===================================+===============+ 974 | 0 | Connectivity is bidirectional (B) | This document | 975 +------------+-----------------------------------+---------------+ 977 Table 6: Initial SIO Flags 979 8.9. Error in Projected Route ICMPv6 Code 981 In some cases RPL will return an ICMPv6 error message when a message 982 cannot be forwarded along a Projected Route. This ICMPv6 error 983 message is "Error in Projected Route". 985 IANA has defined an ICMPv6 "Code" Fields Registry for ICMPv6 Message 986 Types. ICMPv6 Message Type 1 describes "Destination Unreachable" 987 codes. This specification requires that a new code is allocated from 988 the ICMPv6 Code Fields Registry for ICMPv6 Message Type 1, for "Error 989 in Projected Route", with a suggested code value of 8, to be 990 confirmed by IANA. 992 9. Acknowledgments 994 The authors wish to acknowledge JP Vasseur, James Pylakutty and 995 Patrick Wetterwald for their contributions to the ideas developed 996 here. 998 10. Normative References 1000 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1001 Requirement Levels", BCP 14, RFC 2119, 1002 DOI 10.17487/RFC2119, March 1997, 1003 . 1005 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1006 Control Message Protocol (ICMPv6) for the Internet 1007 Protocol Version 6 (IPv6) Specification", STD 89, 1008 RFC 4443, DOI 10.17487/RFC4443, March 2006, 1009 . 1011 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1012 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1013 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1014 Low-Power and Lossy Networks", RFC 6550, 1015 DOI 10.17487/RFC6550, March 2012, 1016 . 1018 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 1019 Routing Header for Source Routes with the Routing Protocol 1020 for Low-Power and Lossy Networks (RPL)", RFC 6554, 1021 DOI 10.17487/RFC6554, March 2012, 1022 . 1024 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 1025 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 1026 RFC 8025, DOI 10.17487/RFC8025, November 2016, 1027 . 1029 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 1030 "IPv6 over Low-Power Wireless Personal Area Network 1031 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 1032 April 2017, . 1034 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1035 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1036 May 2017, . 1038 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1039 Writing an IANA Considerations Section in RFCs", BCP 26, 1040 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1041 . 1043 11. Informative References 1045 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 1046 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 1047 2014, . 1049 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and 1050 J. Martocci, "Reactive Discovery of Point-to-Point Routes 1051 in Low-Power and Lossy Networks", RFC 6997, 1052 DOI 10.17487/RFC6997, August 2013, 1053 . 1055 [6TiSCH-ARCHI] 1056 Thubert, P., "An Architecture for IPv6 over the TSCH mode 1057 of IEEE 802.15.4", Work in Progress, Internet-Draft, 1058 draft-ietf-6tisch-architecture-28, 29 October 2019, 1059 . 1062 [RAW-PS] Thubert, P. and G. Papadopoulos, "Reliable and Available 1063 Wireless Problem Statement", Work in Progress, Internet- 1064 Draft, draft-pthubert-raw-problem-statement-04, 23 October 1065 2019, . 1068 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 1069 "Deterministic Networking Architecture", RFC 8655, 1070 DOI 10.17487/RFC8655, October 2019, 1071 . 1073 [PCE] IETF, "Path Computation Element", 1074 . 1076 Appendix A. Applications 1078 A.1. Loose Source Routing in Non-storing Mode 1080 A RPL implementation operating in a very constrained LLN typically 1081 uses the Non-Storing Mode of Operation as represented in Figure 8. 1082 In that mode, a RPL node indicates a parent-child relationship to the 1083 Root, using a Destination Advertisement Object (DAO) that is unicast 1084 from the node directly to the Root, and the Root typically builds a 1085 source routed path to a destination down the DODAG by recursively 1086 concatenating this information. 1088 ------+--------- 1089 | Internet 1090 | 1091 +-----+ 1092 | | Border Router 1093 | | (RPL Root) 1094 +-----+ ^ | | 1095 | | DAO | ACK | 1096 o o o o | | | Strict 1097 o o o o o o o o o | | | Source 1098 o o o o o o o o o o | | | Route 1099 o o o o o o o o o | | | 1100 o o o o o o o o | v v 1101 o o o o 1102 LLN 1104 Figure 8: RPL non-storing mode of operation 1106 Based on the parent-children relationships expressed in the non- 1107 storing DAO messages,the Root possesses topological information about 1108 the whole network, though this information is limited to the 1109 structure of the DODAG for which it is the destination. A packet 1110 that is generated within the domain will always reach the Root, which 1111 can then apply a source routing information to reach the destination 1112 if the destination is also in the DODAG. Similarly, a packet coming 1113 from the outside of the domain for a destination that is expected to 1114 be in a RPL domain reaches the Root. 1116 It results that the Root, or then some associated centralized 1117 computation engine such as a PCE, can determine the amount of packets 1118 that reach a destination in the RPL domain, and thus the amount of 1119 energy and bandwidth that is wasted for transmission, between itself 1120 and the destination, as well as the risk of fragmentation, any 1121 potential delays because of a paths longer than necessary (shorter 1122 paths exist that would not traverse the Root). 1124 As a network gets deep, the size of the source routing header that 1125 the Root must add to all the downward packets becomes an issue for 1126 nodes that are many hops away. In some use cases, a RPL network 1127 forms long lines and a limited amount of well-Targeted routing state 1128 would allow to make the source routing operation loose as opposed to 1129 strict, and save packet size. Limiting the packet size is directly 1130 beneficial to the energy budget, but, mostly, it reduces the chances 1131 of frame loss and/or packet fragmentation, which is highly 1132 detrimental to the LLN operation. Because the capability to store a 1133 routing state in every node is limited, the decision of which route 1134 is installed where can only be optimized with a global knowledge of 1135 the system, a knowledge that the Root or an associated PCE may 1136 possess by means that are outside of the scope of this specification. 1138 This specification enables to store source-routed or storing mode 1139 state in intermediate routers, which enables to limit the excursion 1140 of the source route headers in deep networks. Once a P-DAO exchange 1141 has taken place for a given Target, if the Root operates in non 1142 storing mode, then it may elide the sequence of routers that is 1143 installed in the network from its source route headers to destination 1144 that are reachable via that Target, and the source route headers 1145 effectively become loose. 1147 A.2. Transversal Routes in storing and non-storing modes 1149 RPL is optimized for Point-to-Multipoint (P2MP) and Multipoint-to- 1150 Point (MP2P), whereby routes are always installed along the RPL DODAG 1151 respectively from and towards the DODAG Root. Transversal Peer to 1152 Peer (P2P) routes in a RPL network will generally suffer from some 1153 elongated (stretched) path versus the best possible path, since 1154 routing between 2 nodes always happens via a common parent, as 1155 illustrated in Figure 9: 1157 * in non-storing mode, all packets routed within the DODAG flow all 1158 the way up to the Root of the DODAG. If the destination is in the 1159 same DODAG, the Root must encapsulate the packet to place a 1160 Routing Header that has the strict source route information down 1161 the DODAG to the destination. This will be the case even if the 1162 destination is relatively close to the source and the Root is 1163 relatively far off. 1165 * In storing mode, unless the destination is a child of the source, 1166 the packets will follow the default route up the DODAG as well. 1167 If the destination is in the same DODAG, they will eventually 1168 reach a common parent that has a route to the destination; at 1169 worse, the common parent may also be the Root. From that common 1170 parent, the packet will follow a path down the DODAG that is 1171 optimized for the Objective Function that was used to build the 1172 DODAG. 1174 ------+--------- 1175 | Internet 1176 | 1177 +-----+ 1178 | | Border Router 1179 | | (RPL Root) 1180 +-----+ 1181 X 1182 ^ v o o 1183 ^ o o v o o o o o 1184 ^ o o o v o o o o o 1185 ^ o o v o o o o o 1186 S o o o D o o o 1187 o o o o 1188 LLN 1190 Figure 9: Routing Stretch between S and D via common parent X 1192 It results that it is often beneficial to enable transversal P2P 1193 routes, either if the RPL route presents a stretch from shortest 1194 path, or if the new route is engineered with a different objective. 1195 For that reason, earlier work at the IETF introduced the "Reactive 1196 Discovery of Point-to-Point Routes in Low Power and Lossy Networks" 1197 [RFC6997], which specifies a distributed method for establishing 1198 optimized P2P routes. This draft proposes an alternate based on a 1199 centralized route computation. 1201 ------+--------- 1202 | Internet 1203 | 1204 +-----+ 1205 | | Border Router 1206 | | (RPL Root) 1207 +-----+ 1208 | 1209 o o o o 1210 o o o o o o o o o 1211 o o o o o o o o o o 1212 o o o o o o o o o 1213 S>>A>>>B>>C>>>D o o o 1214 o o o o 1215 LLN 1217 Figure 10: Projected Transversal Route 1219 This specification enables to store source-routed or storing mode 1220 state in intermediate routers, which enables to limit the stretch of 1221 a P2P route and maintain the characteristics within a given SLA. An 1222 example of service using this mechanism oculd be a control loop that 1223 would be installed in a network that uses classical RPL for 1224 asynchronous data collection. In that case, the P2P path may be 1225 installed in a different RPL Instance, with a different objective 1226 function. 1228 Appendix B. Examples 1230 B.1. Using storing mode P-DAO in non-storing mode MOP 1232 In non-storing mode, the DAG Root maintains the knowledge of the 1233 whole DODAG topology, so when both the source and the destination of 1234 a packet are in the DODAG, the Root can determine the common parent 1235 that would have been used in storing mode, and thus the list of nodes 1236 in the path between the common parent and the destination. For 1237 Instance in the diagram shown in Figure 11, if the source is node 41 1238 and the destination is node 52, then the common parent is node 22. 1240 ------+--------- 1241 | Internet 1242 | 1243 +-----+ 1244 | | Border Router 1245 | | (RPL Root) 1246 +-----+ 1247 | \ \____ 1248 / \ \ 1249 o 11 o 12 o 13 1250 / | / \ 1251 o 22 o 23 o 24 o 25 1252 / \ | \ \ 1253 o 31 o 32 o o o 35 1254 / / | \ | \ 1255 o 41 o 42 o o o 45 o 46 1256 | | | | \ | 1257 o 51 o 52 o 53 o o 55 o 56 1259 LLN 1261 Figure 11: Example DODAG forming a logical tree topology 1263 With this draft, the Root can install a storing mode routing states 1264 along a segment that is either from itself to the destination, or 1265 from one or more common parents for a particular source/destination 1266 pair towards that destination (in this particular example, this would 1267 be the segment made of nodes 22, 32, 42). 1269 In the example below, say that there is a lot of traffic to nodes 55 1270 and 56 and the Root decides to reduce the size of routing headers to 1271 those destinations. The Root can first send a DAO to node 45 1272 indicating Target 55 and a Via segment (35, 45), as well as another 1273 DAO to node 46 indicating Target 56 and a Via segment (35, 46). This 1274 will save one entry in the routing header on both sides. The Root 1275 may then send a DAO to node 35 indicating Targets 55 and 56 a Via 1276 segment (13, 24, 35) to fully optimize that path. 1278 Alternatively, the Root may send a DAO to node 45 indicating Target 1279 55 and a Via segment (13, 24, 35, 45) and then a DAO to node 46 1280 indicating Target 56 and a Via segment (13, 24, 35, 46), indicating 1281 the same DAO Sequence. 1283 B.2. Projecting a storing-mode transversal route 1285 In this example, say that a PCE determines that a path must be 1286 installed between node S and node D via routers A, B and C, in order 1287 to serve the needs of a particular application. 1289 The Root sends a P-DAO with a Target option indicating the 1290 destination D and a sequence Via Information option, one for S, which 1291 is the ingress router of the segment, one for A and then for B, which 1292 are an intermediate routers, and one for C, which is the egress 1293 router. 1295 ------+--------- 1296 | Internet 1297 | 1298 +-----+ 1299 | | Border Router 1300 | | (RPL Root) 1301 +-----+ 1302 | P-DAO message to C 1303 o | o o 1304 o o o | o o o o o 1305 o o o | o o o o o o 1306 o o V o o o o o o 1307 S A B C D o o o 1308 o o o o 1309 LLN 1311 Figure 12: P-DAO from Root 1313 Upon reception of the P-DAO, C validates that it can reach D, e.g. 1314 using IPv6 Neighbor Discovery, and if so, propagates the P-DAO 1315 unchanged to B. 1317 B checks that it can reach C and of so, installs a route towards D 1318 via C. Then it propagates the P-DAO to A. 1320 The process recurses till the P-DAO reaches S, the ingress of the 1321 segment, which installs a route to D via A and sends a DAO-ACK to the 1322 Root. 1324 ------+--------- 1325 | Internet 1326 | 1327 +-----+ 1328 | | Border Router 1329 | | (RPL Root) 1330 +-----+ 1331 ^ P-DAO-ACK from S 1332 / o o o 1333 / o o o o o o o 1334 | o o o o o o o o o 1335 | o o o o o o o o 1336 S A B C D o o o 1337 o o o o 1338 LLN 1340 Figure 13: P-DAO-ACK to Root 1342 As a result, a transversal route is installed that does not need to 1343 follow the DODAG structure. 1345 ------+--------- 1346 | Internet 1347 | 1348 +-----+ 1349 | | Border Router 1350 | | (RPL Root) 1351 +-----+ 1352 | 1353 o o o o 1354 o o o o o o o o o 1355 o o o o o o o o o o 1356 o o o o o o o o o 1357 S>>A>>>B>>C>>>D o o o 1358 o o o o 1359 LLN 1361 Figure 14: Projected Transversal Route 1363 Authors' Addresses 1365 Pascal Thubert (editor) 1366 Cisco Systems, Inc 1367 Building D, 45 Allee des Ormes - BP1200 1368 06254 Mougins - Sophia Antipolis 1369 France 1371 Phone: +33 497 23 26 34 1372 Email: pthubert@cisco.com 1374 Rahul Arvind Jadhav 1375 Huawei Tech 1376 Kundalahalli Village, Whitefield, 1377 Bangalore 560037 1378 Karnataka 1379 India 1381 Phone: +91-080-49160700 1382 Email: rahul.ietf@gmail.com 1384 Matthew Gillmore 1385 Itron, Inc 1386 Building D, 2111 N Molter Road 1387 Liberty Lake, 99019 1388 United States 1390 Phone: +1.800.635.5461 1391 Email: matthew.gillmore@itron.com