idnits 2.17.1 draft-ietf-roll-dao-projection-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 (4 November 2019) is 1634 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: 7 May 2020 M. Gillmore 7 Itron 8 4 November 2019 10 Root initiated routing state in RPL 11 draft-ietf-roll-dao-projection-08 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 7 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 . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . 18 80 8.3. New SubRegistry for the Projected DAO Request (PDR) 81 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 19 82 8.4. New SubRegistry for the PDR-ACK Flags . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 20 89 8.8. New SubRegistry for the Sibling Information Option 90 (SIO) Flags . . . . . . . . . . . . . . . . . . . . . . . 21 91 8.9. Error in Projected Route ICMPv6 Code . . . . . . . . . . 21 92 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 93 10. Normative References . . . . . . . . . . . . . . . . . . . . 22 94 11. Informative References . . . . . . . . . . . . . . . . . . . 22 95 Appendix A. Applications . . . . . . . . . . . . . . . . . . . . 23 96 A.1. Loose Source Routing in Non-storing Mode . . . . . . . . 23 97 A.2. Transversal Routes in storing and non-storing 98 modes . . . . . . . . . . . . . . . . . . . . . . . . . . 25 99 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 27 100 B.1. Using storing mode P-DAO in non-storing mode MOP . . . . 27 101 B.2. Projecting a storing-mode transversal route . . . . . . . 28 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 104 1. Introduction 106 RPL, the "Routing Protocol for Low Power and Lossy Networks" 107 [RFC6550] (LLNs), is a generic Distance Vector protocol that is well 108 suited for application in a variety of low energy Internet of Things 109 (IoT) networks. RPL forms Destination Oriented Directed Acyclic 110 Graphs (DODAGs) in which the Root often acts as the Border Router to 111 connect the RPL domain to the Internet. The Root is responsible to 112 select the RPL Instance that is used to forward a packet coming from 113 the Internet into the RPL domain and set the related RPL information 114 in the packets. 116 The 6TiSCH architecture [6TiSCH-ARCHI] leverages RPL for its routing 117 operations and considers the Deterministic Networking Architecture 118 [RFC8655] as one possible model whereby the device resources and 119 capabilities are exposed to an external controller which installs 120 routing states into the network based on some objective functions 121 that reside in that external entity. With DetNet and 6TiSCH, the 122 component of the controller that is responsible of computing routes 123 is called a Path Computation Element ([PCE]). 125 Based on heuristics of usage, path length, and knowledge of device 126 capacity and available resources such as battery levels and 127 reservable buffers, a PCE with a global visibility on the system can 128 compute P2P routes that are more optimized for the current needs as 129 expressed by the objective function. 131 This draft proposes a protocol extension to RPL that enables the Root 132 to install a limited amount of centrally-computed routes in a RPL 133 graph, on behalf of a PCE that may be collocated or separated from 134 the Root. Those extensions enable loose source routing down in RPL 135 Non-Storing Mode and transversal routes inside the DODAG regardless 136 of the RPL Mode of Operation (MOP). 138 As opposed to the classical RPL operations where routes are injected 139 by the Target nodes, the protocol extension enables the Root of a 140 DODAG to project the routes that are needed onto the nodes where they 141 should be installed. This specification uses the term Projected 142 Route to refer to those routes. A Projected Route may be a stand- 143 alone path to a Target or a segment in a complex Track [6TiSCH-ARCHI] 144 that provides redundant forwarding solutions to a destination to 145 improve reliability and availability of the wireless transmissions 146 [RAW-PS]. 148 Projected Routes must be used with the parsimony to limit the amount 149 of state that is installed in each device to fit within its 150 resources, and to limit the amount of rerouted traffic to fit within 151 the capabilities of the transmission links. The method to learn the 152 node capabilities and the resources that are available in the devices 153 and in the network are out of scope for this document. 155 In RPL Non-Storing Mode, the Root has enough information to build a 156 basic DODAG topology. This document adds the capability for nodes to 157 advertise sibling information in order to improve the topological 158 awareness of the Root. This specification uses the RPL Root as a 159 proxy to the PCE. The algorithm to compute the paths and the 160 protocol used by an external PCE to obtain the topology of the 161 network from the Root are out of scope for this document. 163 2. Terminology 165 2.1. BCP 14 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 169 "OPTIONAL" in this document are to be interpreted as described in BCP 170 14 [RFC2119][RFC8174] when, and only when, they appear in all 171 capitals, as shown here. 173 2.2. Subset of a 6LoWPAN Glossary 175 This document often uses the following acronyms: 177 6BBR: 6LoWPAN Backbone Router 179 6LBR: 6LoWPAN Border Router 181 6LN: 6LoWPAN Node 183 6LR: 6LoWPAN Router 185 DAD: Duplicate Address Detection 187 DODAG: Destination-Oriented Directed Acyclic Graph 189 LLN: Low-Power and Lossy Network 191 NA: Neighbor Advertisement 192 NCE: Neighbor Cache Entry 194 ND: Neighbor Discovery 196 NDP: Neighbor Discovery Protocol 198 NS: Neighbor Solicitation 200 RPL: IPv6 Routing Protocol for LLNs [RFC6550] 202 CMO: Control Message Option 204 DAO: Destination Advertisement Object 206 VIO: A Via Information Option, used in Storing Mode P-DAO messages. 208 SRVIO: A Source-Routed Via Information Option, used in Non-Storing 209 Mode P-DAO messages. 211 RPO: A Route Projection Option; it can be a VIO or an SRVIO. 213 P-DAO: A Projected DAO is a DAO message sent by the RPL Root to 214 install a Projected Route. 216 RTO: RPL Target Option 218 RAN: RPL-Aware Node 220 RA: Router Advertisement 222 RS: Router Solicitation 224 2.3. Other Terms 226 Projected Route: A Projected Route is a serial path that is computed 227 and installed remotely by a RPL Root. 229 Track: The term Track is used in this document to refer to a complex 230 path, e.g., a DODAG, that incorporates redundant Projected Routes 231 towards a destination for increased reliability, high availability 232 and load balancing. 234 2.4. References 236 In this document, readers will encounter terms and concepts that are 237 discussed in the following documents: 239 * "Routing Protocol for Low Power and Lossy Networks" [RFC6550], and 241 * "Terminology in Low power And Lossy Networks" [RFC7102]. 243 3. Extending RFC 6550 245 This specification introduces two new RPL Control Messages to enable 246 a RPL Aware Node (RAN) to request the establisment of a path from 247 self to a Target. A RAN may request the installation of a path by 248 sending a new P-DAO Request PDR) Message to the Root. The Root 249 confirms with a new PDR-ACK message back to the requester RAN with a 250 completion status once it is done installing the path. See 251 Section 5.1 for more. 253 Section 6.7 of [RFC6550] specifies RPL Control Message Options (CMO) 254 to be placed in RPL messages such as the Destination Advertisement 255 Object (DAO) message. The RPL Target Option (RTO) and the Transit 256 Information Option (TIO) are such options. In Non-Storing Mode, the 257 TIO option is used in the DAO message to indicate a parent within a 258 DODAG. The TIO applies to the RTOs that immedially preceed it in the 259 message. Options may be factorized; multiple TIOs may be present to 260 indicate multiple routes to the one or more contiguous addresses 261 indicated in the RTOs that immediately precede the TIOs in the RPL 262 message. 264 This specification introduces two new CMOs referred to as Route 265 Projection Options (RPO) to install Projected Routes. One RPO is the 266 Via Information Option (VIO) and the other is the Source-Routed VIO 267 (SRVIO). The VIO installs a route on each hop along a Projected 268 Route (in a fashion analogous to RPL Storing Mode) whereas the SRVIO 269 installs a source-routing state at the ingress node, which uses that 270 state to encapsulate a packet with an IPv6 Routing Header in a 271 fashion similar to RPL Non-Storing Mode. Like the TIO, the RPOs MUST 272 be preceded by exactly one RTO to which they apply, and they can be 273 factorized: multiple contiguous RPOs indicate alternate paths to the 274 Target, more in Section 5.3. 276 This specification also introduces a new CMO to enable a RAN to 277 advertise (some of) its siblings to the Root, using a new Sibling 278 Information Option (SIO) as specified in Section 5.4. 280 4. Identifying a Path 282 It must be noted that RPL has a concept of Instance to represent 283 different routing topologies but does not have a concept of an 284 administrative distance, which exists in certain proprietary 285 implementations to sort out conflicts between multiple sources of 286 routing information within one routing topology. This draft conforms 287 the Instance model as follows: 289 * If the PCE needs to influence a particular Instance to add better 290 routes in conformance with the routing objectives in that 291 Instance, it may do so as long as it does not create a loop. A 292 Projected Route is always preferred over a route that is learned 293 via RPL. 295 * A PCE that installs a more specific (say, Traffic Engineered) and 296 possibly complex path (aka a Track) towards a particular Target 297 MUST use a Local RPL Instance (see section 5 of [RFC6550]) 298 associated to that Target to identify the path. We refer to that 299 Local RPLInstanceID as TrackID. A projected path is uniquely 300 identified within the RPL domain by the tuple (Target address, 301 TrackID). When packet is placed on a Track, a RPL Packet 302 Information (RPI) is added with the TrackID as RPLInstanceID. The 303 RPLInstanceID has the 'D' flag set, indicating that the 304 destination address in the IPv6 header is the Target that is used 305 to identify the Track. 307 * A packet that is routed over a projected path MUST NOT be placed 308 over a different RPL Instance again. A packet that is placed on a 309 Global Instance MAY be injected in a Local Instance based on a 310 network policy and the Local Instance configuration. 312 A Projected Route is a serial path that may the whole path or a 313 segment in a complex Track, in which case multiple Projected Routes 314 are installed with the stuple (Target address, TrackID), and a node 315 that is present on more than one segment in a Track may be able to 316 use either of the Projected Routes to forward towards the Target. 317 The selection of the best route in a Track at forwarding time is out 318 of scope for this document. [RAW-PS] elaborates on that particular 319 problem. 321 5. New RPL Control Messages and Options 323 5.1. New P-DAO Request Control Message 325 The PDR is sent to the Root to request a new Path. Exactly one 326 Target Options MUST be present. 328 The format of P-DAO Request (PDR) Base Object is as follows: 330 0 1 2 3 331 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 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | RPLInstanceID |K|R| Flags | PDRLifetime | PDRSequence | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Option(s)... 336 +-+-+-+-+-+-+-+-+ 338 Figure 1: New P-DAO Request Format 340 TrackID: 8-bit field indicating the topology Instance associated 341 with the Track. It is set to zero upon the first request for a 342 new Track and then to the TrackID once the Track was created, to 343 either renew it of destroy it. 345 K: The 'K' flag is set to indicate that the recipient is expected to 346 send a PDR-ACK back. 348 R: The 'R' flag is set to indicate that the Requested path should be 349 redundant. 351 PDRLifetime: 8-bit unsigned integer. The requested lifetime for the 352 Track expressed in Lifetime Units (obtained from the Configuration 353 option). A PDR with a fresher PDRSequence refreshes the lifetime, 354 and a PDRLifetime of 0 indicates that the track should be 355 destroyed. 357 PDRSequence: 8-bit wrapping sequence number. The PDRSequence obeys 358 the operation in section 7.2 of [RFC6550]. It is incremented at 359 each PDR message and echoed in the PDR-ACK by the Root. The 360 PDRSequence is used to correlate a PDR-ACK message with the PDR 361 message that triggeted it. 363 5.2. New PDR-ACK Control Message 365 The new PDR-ACK is sent as a response to a PDR message with the 'K' 366 flag set. Its format is as follows: 368 0 1 2 3 369 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 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | TrackID | PDR-ACK Status| Flags | Track Lifetime| 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | PDRSequence | Reserved | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Option(s)... 376 +-+-+-+-+-+-+-+ 378 Figure 2: New PDR-ACK Control Message Format 380 TrackID: The RPLInstanceID of the Track that was created. Set to 0 381 when no Track is created. 383 PDR-ACK Status: Indicates the completion. Substructured as 384 indicated in Figure 3. 386 Track Lifetime: Indicates that remaining Lifetime for the Track, 0 387 if the Track was destroyed or not created. 389 PDRSequence: 8-bit wrapping sequence number. It is incremented at 390 each PDR message and echoed in the PDR-ACK. 392 The PDR-ACK Status is further substructured as follows: 394 0 395 0 1 2 3 4 5 6 7 396 +-+-+-+-+-+-+-+-+ 397 |E|R| Value | 398 +-+-+-+-+-+-+-+-+ 400 Figure 3: PDR-ACK status Format 402 The PDR-ACK Status subfields are: 404 E: 1-bit flag. Set to indicate a rejection. When not set, a value 405 of 0 indicates Success/Unqualified acceptance and other values 406 indicate "not an outright rejection". 408 R: 1-bit flag. Reserved, MUST be set to 0 by the sender and ignored 409 by the receiver. 411 Status Value: 6-bit unsigned integer. Values depedning on the 412 setting of the 'E' flag as indicated respectively in Table 4 and 413 Table 5. 415 5.3. Route Projection Options 417 The RPOs indicate a series of IPv6 addresses that can be compressed 418 using the method defined in the "6LoWPAN Routing Header" [RFC8138] 419 specification using the address of the Root found in the DODAGID 420 field of DIO messages as Compression Reference. 422 An RPO indicates a Projected Route that can be a serial Track in full 423 or a segment of a more complex Track. The Track is identified by a 424 RPLInstanceID that is either Global or local to the Target of the 425 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 | Path Lifetime | Path Sequence | Reserved | 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. 470 Path Lifetime: 8-bit unsigned integer. The length of time in 471 Lifetime Units (obtained from the Configuration option) that the 472 prefix is valid for route determination. The period starts when a 473 new Path Sequence is seen. A value of 255 (0xFF) represents 474 infinity. A value of zero (0x00) indicates a loss of 475 reachability. A DAO message that contains a Via Information 476 option with a Path Lifetime of zero for a Target is referred as a 477 No-Path (for that Target) in this document. 479 Path Sequence: 8-bit unsigned integer. When a RPL Target option is 480 issued by the Root of the DODAG (i.e. in a DAO message), that Root 481 sets the Path Sequence and increments the Path Sequence each time 482 it issues a RPL Target option with updated information. The 483 indicated sequence deprecates any state for a given Target that 484 was learned from a previous sequence and adds to any state that 485 was learned for that sequence. 487 Via Address: 2 to 16 bytes, a compressed IPv6 Address. A Via 488 Address indicates the next hop within the path towards the 489 destination(s) that is indicated in the Target option that 490 immediately precede the RPO in the DAO message. Via Addresses are 491 indicated in the order of the path from the ingress to the egress 492 nodes. All Via addresses are expressed in the same size as 493 indicated by the Compression Type. 495 An RPO MUST contain at least one Via Address, and a Via Address MUST 496 NOT be present more than once, otherwise the RPO MUST be ignored. 498 5.4. Sibling Information Option 500 The Sibling Information Option (SIO) provides indication on siblings 501 that could be used by the Root to form Projected Routes. The format 502 of SIOs is as follows: 504 0 1 2 3 505 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 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | Type | Option Length |Comp.|B| Flags | Opaque | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | Step of Rank | Reserved | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | | 512 + + 513 . . 514 . Sibling Address . 515 . . 516 + + 517 | | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 Figure 5: Sibling Information Option Format 522 Option Type: 0x0C (to be confirmed by IANA) 524 Option Length: In bytes; variable, depending on the number of Via 525 Addresses. 527 Compression Type: 3-bit unsigned integer. This is the SRH-6LoRH 528 Type as defined in figure 7 in section 5.1 of [RFC8138] that 529 corresponds to the compression used for the Sibling Address. 531 B: 1-bit flag that is set to indicate that the connectivity to the 532 sibling is bidirectional and roughly symmetrical. In that case, 533 only one of the siblings may report the SIO for the hop. If 'B' 534 is not set then the SIO only indicates connectivity from the 535 sibling to this node, and does not provide information on the hop 536 from this node to the sibling. 538 Opaque: MAY be used to carry information that the node and the Root 539 understand, e.g., a particular representation of the Link 540 properties such as a proprietary Link Quality Information for 541 packets received from the sibling. An industraial Alliance that 542 uses RPL for a particular use / environment MAY redefine the use 543 of this field to fit its needs. 545 Step of Rank: 16-bit unsigned integer. This is the Step of Rank 546 [RFC6550] as computed by the Objective Function between this node 547 and the sibling. 549 Reserved: MUST be set to zero by the sender and MUST be ignored by 550 the receiver. 552 Sibling Address: 2 to 16 bytes, the IPv6 Address of the sibling in a 553 [RFC8138] compressed form as indicated by the Compression Type 554 field. 556 An SIO MAY be immediately followed by a DAG Metric Container. In 557 that case the DAG Metric Container provides additional metrics for 558 the hop from the Sibling to this node. 560 6. Projected DAO 562 This draft adds a capability to RPL whereby the Root of a DODAG 563 projects a route by sending an extended DAO message called a 564 Projected-DAO (P-DAO) to an arbitrary router in the DODAG, indicating 565 one or more sequence(s) of routers inside the DODAG via which the 566 Target(s) indicated in the RPL Target Option(s) (RTO) can be reached. 568 A P-DAO is sent from a global address of the Root to a global address 569 of the recipient, and MUST be confirmed by a DAO-ACK, which is sent 570 back to a global address of the Root. 572 A P-DAO message MUST contain at least one RTO and at least one RPO 573 following it. There can be at most one such sequence of RTOs and 574 then RPOs. 576 Like a classical DAO message, a P-DAO is processed only if it is 577 "new" per section 9.2.2. "Generation of DAO Messages" of the RPL 578 specification [RFC6550]; this is determined using the Path Sequence 579 information from the RPO as opposed to a TIO. Also, a Path Lifetime 580 of 0 in an RPO indicates that a route is to be removed. 582 There are two kinds of operation for the Projected Routes, the 583 Storing Mode and the Non-Storing Mode. 585 * The Non-Storing Mode is discussed in Section 6.1. It uses an 586 SRVIO that carries a list of Via Addresses to be used as a source- 587 routed path to the Target. The recipient of the P-DAO is the 588 ingress router of the source-routed path. Upon a Non-Storing Mode 589 P-DAO, the ingress router installs a source-routed state to the 590 Target and replies to the Root directly with a DAO-ACK message. 592 * The Storing Mode is discussed in Section 6.2. It uses a VIO with 593 one Via Address per consecutive hop, from the ingress to the 594 egress of the path, including the list of all intermediate routers 595 in the data path order. The Via Addresses indicate the routers in 596 which the routing state to the Target have to be installed via the 597 next Via Address in the VIO. In normal operations, the P-DAO is 598 propagated along the chain of Via Routers from the egress router 599 of the path till the ingress one, which confirms the installation 600 to the Root with a DAO-ACK message. Note that the Root may be the 601 ingress and it may be the egress of the path, that it can also be 602 neither but it cannot be both. 604 In case of a forwarding error along a Projected Route, an ICMP error 605 is sent to the Root with a new Code "Error in Projected Route" (See 606 Section 8.9). The Root can then modify or remove the Projected 607 Route. The "Error in Projected Route" message has the same format as 608 the "Destination Unreachable Message", as specified in RFC 4443 609 [RFC4443]. The portion of the invoking packet that is sent back in 610 the ICMP message SHOULD record at least up to the routing header if 611 one is present, and the routing header SHOULD be consumed by this 612 node so that the destination in the IPv6 header is the next hop that 613 this node could not reach. if a 6LoWPAN Routing Header (6LoRH) 614 [RFC8138] is used to carry the IPv6 routing information in the outter 615 header then that whole 6LoRH information SHOULD be present in the 616 ICMP message. The sender and exact operation depend on the Mode and 617 is described in Section 6.1 and Section 6.2 respectively. 619 6.1. Non-Storing Mode Projected Route 621 As illustrated in Figure 6, a P-DAO that carries an SRVIO enables the 622 Root to install a source-routed path towards a Target in any 623 particular router; with this path information the router can add a 624 source routed header reflecting the Projected Route to any packet for 625 which the current destination either is the said Target or can be 626 reached via the Target. 628 ------+--------- 629 | Internet 630 | 631 +-----+ 632 | | Border Router 633 | | (RPL Root) 634 +-----+ | P ^ | 635 | | DAO | ACK | Loose 636 o o o o router V | | Source 637 o o o o o o o o o | P-DAO . Route 638 o o o o o o o o o o | Source . Path 639 o o o o o o o o o | Route . From 640 o o o o o o o o | Path . Root 641 o o o o o Target V . To 642 o o o o | Desti- 643 o o o o | nation 644 destination V 646 LLN 648 Figure 6: Projecting a Non-Storing Route 650 A route indicated by an SRVIO may be loose, meaning that the node 651 that owns the next listed Via Address is not necessarily a neighbor. 652 Without proper loop avoidance mechanisms, the interaction of loose 653 source routing and other mechanisms may effectively cause loops. In 654 order to avoid those loops, if the router that installs a Projected 655 Route does not have a connected route (a direct adjacency) to the 656 next soure routed hop and fails to locate it as a neighbor or a 657 neighbor of a neighbor, then it MUST ensure that it has another 658 Projected Route to the next loose hop under the control of the same 659 route computation system, otherwise the P-DAO is rejected. 661 When forwarding a packet to a destination for which the router 662 determines that routing happens via the Target, the router inserts 663 the source routing header in the packet to reach the Target. In the 664 case of a loose source-routed path, there MUST be either a neighbor 665 that is adjacent to the loose next hop, on which case the packet s 666 forwarded to that neighbor, or a source-routed path to the loose next 667 hop; in the latter case, another encapsulation takes place and the 668 process possibly recurses; otherwise the packet is dropped. 670 In order to add a source-routing header, the router encapsulates the 671 packet with an IP-in-IP header and a non-storing mode source routing 672 header (SRH) [RFC6554]. In the uncompressed form the source of the 673 packet would be self, the destination would be the first Via Address 674 in the SRVIO, and the SRH would contain the list of the remaining Via 675 Addresses and then the Target. 677 In practice, the router will normally use the "IPv6 over Low-Power 678 Wireless Personal Area Network (6LoWPAN) Paging Dispatch" [RFC8025] 679 to compress the RPL artifacts as indicated in [RFC8138]. In that 680 case, the router indicates self as encapsulator in an IP-in-IP 6LoRH 681 Header, and places the list of Via Addresses in the order of the VIO 682 and then the Target in the SRH 6LoRH Header. 684 In case of a forwarding error along a Source Route path, the node 685 that fails to forward SHOULD send an ICMP error with a code "Error in 686 Source Routing Header" back to the source of the packet, as described 687 in section 11.2.2.3. of [RFC6550]. Upon this message, the 688 encapsulating node SHOULD stop using the source route path for a 689 period of time and it SHOULD send an ICMP message with a Code "Error 690 in Projected Route" to the Root. Failure to follow these steps may 691 result in packet loss and wasted resources along the source route 692 path that is broken. 694 6.2. Storing-Mode Projected Route 696 As illustrated in Figure 7, the Storing Mode route projection is used 697 by the Root to install a routing state towards a Target in the 698 routers along a segment between an ingress and an egress router; this 699 enables the routers to forward along that segment any packet for 700 which the next loose hop is the said Target, for Instance a loose 701 source routed packet for which the next loose hop is the Target, or a 702 packet for which the router has a routing state to the final 703 destination via the Target. 705 ------+--------- 706 | Internet 707 | 708 +-----+ 709 | | Border Router 710 | | (RPL Root) 711 +-----+ | ^ | 712 | | DAO | ACK | 713 o o o o | | | 714 o o o o o o o o o | ^ | Projected . 715 o o o o o o o o o o | | DAO | Route . 716 o o o o o o o o o | ^ | . 717 o o o o o o o o v | DAO v . 718 o o LLN o o o | 719 o o o o o Loose Source Route Path | 720 o o o o From Root To Destination v 722 Figure 7: Projecting a route 724 In order to install the relevant routing state along the segment 725 between an ingress and an egress routers, the Root sends a unicast 726 P-DAO message to the egress router of the routing segment that must 727 be installed. The P-DAO message contains the ordered list of hops 728 along the segment as a direct sequence of Via Information options 729 that are preceded by one or more RPL Target options to which they 730 relate. Each Via Information option contains a Path Lifetime for 731 which the state is to be maintained. 733 The Root sends the P-DAO directly to the egress node of the segment. 734 In that P-DAO, the destination IP address matches the Via Address in 735 the last VIO. This is how the egress recognizes its role. In a 736 similar fashion, the ingress node recognizes its role as it matches 737 Via Address in the first VIO. 739 The egress node of the segment is the only node in the path that does 740 not install a route in response to the P-DAO; it is expected to be 741 already able to route to the Target(s) on its own. It may either be 742 the Target, or may have some existing information to reach the 743 Target(s), such as a connected route or an already installed 744 Projected Route. If one of the Targets cannot be located, the node 745 MUST answer to the Root with a negative DAO-ACK listing the Target(s) 746 that could not be located (suggested status 10 to be confirmed by 747 IANA). 749 If the egress node can reach all the Targets, then it forwards the 750 P-DAO with unchanged content to its loose predecessor in the segment 751 as indicated in the list of Via Information options, and recursively 752 the message is propagated unchanged along the sequence of routers 753 indicated in the P-DAO, but in the reverse order, from egress to 754 ingress. 756 The address of the predecessor to be used as destination of the 757 propagated DAO message is found in the Via Information option the 758 precedes the one that contain the address of the propagating node, 759 which is used as source of the packet. 761 Upon receiving a propagated DAO, an intermediate router as well as 762 the ingress router install a route towards the DAO Target(s) via its 763 successor in the P-DAO; the router locates the VIO that contains its 764 address, and uses as next hop the address found in the Via Address 765 field in the following VIO. The router MAY install additional routes 766 towards the addresses that are located in VIOs that are after the 767 next one, if any, but in case of a conflict or a lack of resource, a 768 route to a Target installed by the Root has precedence. 770 The process recurses till the P-DAO is propagated to ingress router 771 of the segment, which answers with a DAO-ACK to the Root. 773 Also, the path indicated in a P-DAO may be loose, in which case the 774 reachability to the next hop has to be asserted. Each router along 775 the path indicated in a P-DAO is expected to be able to reach its 776 successor, either with a connected route (direct neighbor), or by 777 routing, for Instance following a route installed previously by a DAO 778 or a P-DAO message. If that route is not connected then a recursive 779 lookup may take place at packet forwarding time to find the next hop 780 to reach the Target(s). If it does not and cannot reach the next 781 router in the P-DAO, the router MUST answer to the Root with a 782 negative DAO-ACK indicating the successor that is unreachable 783 (suggested status 11 to be confirmed by IANA). 785 A Path Lifetime of 0 in a Via Information option is used to clean up 786 the state. The P-DAO is forwarded as described above, but the DAO is 787 interpreted as a No-Path DAO and results in cleaning up existing 788 state as opposed to refreshing an existing one or installing a new 789 one. 791 In case of a forwarding error along a Storing Mode Projected Route, 792 the node that fails to forward SHOULD send an ICMP error with a code 793 "Error in Projected Route" to the Root. Failure to do so may result 794 in packet loss and wasted resources along the Projected Route that is 795 broken. 797 7. Security Considerations 799 This draft uses messages that are already present in RPL [RFC6550] 800 with optional secured versions. The same secured versions may be 801 used with this draft, and whatever security is deployed for a given 802 network also applies to the flows in this draft. 804 TODO: should probably consider how P-DAO messages could be abused by 805 a) rogue nodes b) via replay of messages c) if use of P-DAO messages 806 could in fact deal with any threats? 808 8. IANA Considerations 810 8.1. New RPL Control Codes 812 This document extends the IANA Subregistry created by RFC 6550 for 813 RPL Control Codes as indicated in Table 1: 815 +------+-----------------------------+---------------+ 816 | Code | Description | Reference | 817 +======+=============================+===============+ 818 | 0x09 | Projected DAO Request (PDR) | This document | 819 +------+-----------------------------+---------------+ 820 | 0x0A | PDR-ACK | This document | 821 +------+-----------------------------+---------------+ 823 Table 1: New RPL Control Codes 825 8.2. New RPL Control Message Options 827 This document extends the IANA Subregistry created by RFC 6550 for 828 RPL Control Message Options as indicated in Table 2: 830 +-------+--------------------------------------+---------------+ 831 | Value | Meaning | Reference | 832 +=======+======================================+===============+ 833 | 0x0B | Via Information option | This document | 834 +-------+--------------------------------------+---------------+ 835 | 0x0C | Source-Routed Via Information option | This document | 836 +-------+--------------------------------------+---------------+ 837 | 0x0D | Sibling Information option | This document | 838 +-------+--------------------------------------+---------------+ 840 Table 2: RPL Control Message Options 842 8.3. New SubRegistry for the Projected DAO Request (PDR) Flags 844 IANA is required to create a registry for the 8-bit Projected DAO 845 Request (PDR) Flags field. Each bit is tracked with the following 846 qualities: 848 * Bit number (counting from bit 0 as the most significant bit) 850 * Capability description 852 * Reference 854 Registration procedure is "Standards Action" [RFC8126]. The initial 855 allocation is as indicated in Table 3: 857 +------------+------------------------+---------------+ 858 | Bit number | Capability description | Reference | 859 +============+========================+===============+ 860 | 0 | PDR-ACK request (K) | This document | 861 +------------+------------------------+---------------+ 862 | 1 | Requested path should | This document | 863 | | be redundant (R) | | 864 +------------+------------------------+---------------+ 866 Table 3: Initial PDR Flags 868 8.4. New SubRegistry for the PDR-ACK Flags 870 IANA is required to create an subregistry for the 8-bit PDR-ACK Flags 871 field. Each bit is tracked with the following qualities: 873 * Bit number (counting from bit 0 as the most significant bit) 875 * Capability description 877 * Reference 878 Registration procedure is "Standards Action" [RFC8126]. No bit is 879 currently defined for the PDR-ACK Flags. 881 8.5. New Subregistry for the PDR-ACK Acceptance Status values 883 IANA is requested to create a new subregistry for the PDR-ACK 884 Acceptance Status values. 886 * Possible values are 6-bit unsigned integers (0..63). 888 * Registration procedure is "Standards Action" [RFC8126]. 890 * Initial allocation is as indicated in Table 4: 892 +-------+------------------------+---------------+ 893 | Value | Meaning | Reference | 894 +=======+========================+===============+ 895 | 0 | Unqualified acceptance | This document | 896 +-------+------------------------+---------------+ 898 Table 4: Acceptance values of the PDR-ACK Status 900 8.6. New Subregistry for the PDR-ACK Rejection Status values 902 IANA is requested to create a new subregistry for the PDR-ACK 903 Rejection Status values. 905 * Possible values are 6-bit unsigned integers (0..63). 907 * Registration procedure is "Standards Action" [RFC8126]. 909 * Initial allocation is as indicated in Table 5: 911 +-------+-----------------------+---------------+ 912 | Value | Meaning | Reference | 913 +=======+=======================+===============+ 914 | 0 | Unqualified rejection | This document | 915 +-------+-----------------------+---------------+ 917 Table 5: Rejection values of the PDR-ACK Status 919 8.7. New SubRegistry for the Route Projection Options (RPO) Flags 921 IANA is requested to create a new subregistry for the 5-bit Route 922 Projection Options (RPO) Flags field. Each bit is tracked with the 923 following qualities: 925 * Bit number (counting from bit 0 as the most significant bit) 926 * Capability description 928 * Reference 930 Registration procedure is "Standards Action" [RFC8126]. No bit is 931 currently defined for the Route Projection Options (RPO) Flags. 933 8.8. New SubRegistry for the Sibling Information Option (SIO) Flags 935 IANA is required to create a registry for the 5-bit Sibling 936 Information Option (SIO) Flags field. Each bit is tracked with the 937 following qualities: 939 * Bit number (counting from bit 0 as the most significant bit) 941 * Capability description 943 * Reference 945 Registration procedure is "Standards Action" [RFC8126]. The initial 946 allocation is as indicated in Table 6: 948 +------------+-----------------------------------+---------------+ 949 | Bit number | Capability description | Reference | 950 +============+===================================+===============+ 951 | 0 | Connectivity is bidirectional (B) | This document | 952 +------------+-----------------------------------+---------------+ 954 Table 6: Initial SIO Flags 956 8.9. Error in Projected Route ICMPv6 Code 958 In some cases RPL will return an ICMPv6 error message when a message 959 cannot be forwarded along a Projected Route. This ICMPv6 error 960 message is "Error in Projected Route". 962 IANA has defined an ICMPv6 "Code" Fields Registry for ICMPv6 Message 963 Types. ICMPv6 Message Type 1 describes "Destination Unreachable" 964 codes. This specification requires that a new code is allocated from 965 the ICMPv6 Code Fields Registry for ICMPv6 Message Type 1, for "Error 966 in Projected Route", with a suggested code value of 8, to be 967 confirmed by IANA. 969 9. Acknowledgments 971 The authors wish to acknowledge JP Vasseur, James Pylakutty and 972 Patrick Wetterwald for their contributions to the ideas developed 973 here. 975 10. Normative References 977 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 978 Requirement Levels", BCP 14, RFC 2119, 979 DOI 10.17487/RFC2119, March 1997, 980 . 982 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 983 Control Message Protocol (ICMPv6) for the Internet 984 Protocol Version 6 (IPv6) Specification", STD 89, 985 RFC 4443, DOI 10.17487/RFC4443, March 2006, 986 . 988 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 989 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 990 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 991 Low-Power and Lossy Networks", RFC 6550, 992 DOI 10.17487/RFC6550, March 2012, 993 . 995 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 996 Routing Header for Source Routes with the Routing Protocol 997 for Low-Power and Lossy Networks (RPL)", RFC 6554, 998 DOI 10.17487/RFC6554, March 2012, 999 . 1001 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 1002 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 1003 RFC 8025, DOI 10.17487/RFC8025, November 2016, 1004 . 1006 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 1007 "IPv6 over Low-Power Wireless Personal Area Network 1008 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 1009 April 2017, . 1011 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1012 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1013 May 2017, . 1015 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1016 Writing an IANA Considerations Section in RFCs", BCP 26, 1017 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1018 . 1020 11. Informative References 1022 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 1023 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 1024 2014, . 1026 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and 1027 J. Martocci, "Reactive Discovery of Point-to-Point Routes 1028 in Low-Power and Lossy Networks", RFC 6997, 1029 DOI 10.17487/RFC6997, August 2013, 1030 . 1032 [6TiSCH-ARCHI] 1033 Thubert, P., "An Architecture for IPv6 over the TSCH mode 1034 of IEEE 802.15.4", Work in Progress, Internet-Draft, 1035 draft-ietf-6tisch-architecture-28, 29 October 2019, 1036 . 1039 [RAW-PS] Thubert, P. and G. Papadopoulos, "Reliable and Available 1040 Wireless Problem Statement", Work in Progress, Internet- 1041 Draft, draft-pthubert-raw-problem-statement-04, 23 October 1042 2019, . 1045 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 1046 "Deterministic Networking Architecture", RFC 8655, 1047 DOI 10.17487/RFC8655, October 2019, 1048 . 1050 [PCE] IETF, "Path Computation Element", November 2019, 1051 . 1053 Appendix A. Applications 1055 A.1. Loose Source Routing in Non-storing Mode 1057 A RPL implementation operating in a very constrained LLN typically 1058 uses the Non-Storing Mode of Operation as represented in Figure 8. 1059 In that mode, a RPL node indicates a parent-child relationship to the 1060 Root, using a Destination Advertisement Object (DAO) that is unicast 1061 from the node directly to the Root, and the Root typically builds a 1062 source routed path to a destination down the DODAG by recursively 1063 concatenating this information. 1065 ------+--------- 1066 | Internet 1067 | 1068 +-----+ 1069 | | Border Router 1070 | | (RPL Root) 1071 +-----+ ^ | | 1072 | | DAO | ACK | 1073 o o o o | | | Strict 1074 o o o o o o o o o | | | Source 1075 o o o o o o o o o o | | | Route 1076 o o o o o o o o o | | | 1077 o o o o o o o o | v v 1078 o o o o 1079 LLN 1081 Figure 8: RPL non-storing mode of operation 1083 Based on the parent-children relationships expressed in the non- 1084 storing DAO messages,the Root possesses topological information about 1085 the whole network, though this information is limited to the 1086 structure of the DODAG for which it is the destination. A packet 1087 that is generated within the domain will always reach the Root, which 1088 can then apply a source routing information to reach the destination 1089 if the destination is also in the DODAG. Similarly, a packet coming 1090 from the outside of the domain for a destination that is expected to 1091 be in a RPL domain reaches the Root. 1093 It results that the Root, or then some associated centralized 1094 computation engine such as a PCE, can determine the amount of packets 1095 that reach a destination in the RPL domain, and thus the amount of 1096 energy and bandwidth that is wasted for transmission, between itself 1097 and the destination, as well as the risk of fragmentation, any 1098 potential delays because of a paths longer than necessary (shorter 1099 paths exist that would not traverse the Root). 1101 As a network gets deep, the size of the source routing header that 1102 the Root must add to all the downward packets becomes an issue for 1103 nodes that are many hops away. In some use cases, a RPL network 1104 forms long lines and a limited amount of well-Targeted routing state 1105 would allow to make the source routing operation loose as opposed to 1106 strict, and save packet size. Limiting the packet size is directly 1107 beneficial to the energy budget, but, mostly, it reduces the chances 1108 of frame loss and/or packet fragmentation, which is highly 1109 detrimental to the LLN operation. Because the capability to store a 1110 routing state in every node is limited, the decision of which route 1111 is installed where can only be optimized with a global knowledge of 1112 the system, a knowledge that the Root or an associated PCE may 1113 possess by means that are outside of the scope of this specification. 1115 This specification enables to store source-routed or storing mode 1116 state in intermediate routers, which enables to limit the excursion 1117 of the source route headers in deep networks. Once a P-DAO exchange 1118 has taken place for a given Target, if the Root operates in non 1119 storing mode, then it may elide the sequence of routers that is 1120 installed in the network from its source route headers to destination 1121 that are reachable via that Target, and the source route headers 1122 effectively become loose. 1124 A.2. Transversal Routes in storing and non-storing modes 1126 RPL is optimized for Point-to-Multipoint (P2MP) and Multipoint-to- 1127 Point (MP2P), whereby routes are always installed along the RPL DODAG 1128 respectively from and towards the DODAG Root. Transversal Peer to 1129 Peer (P2P) routes in a RPL network will generally suffer from some 1130 elongated (stretched) path versus the best possible path, since 1131 routing between 2 nodes always happens via a common parent, as 1132 illustrated in Figure 9: 1134 * in non-storing mode, all packets routed within the DODAG flow all 1135 the way up to the Root of the DODAG. If the destination is in the 1136 same DODAG, the Root must encapsulate the packet to place a 1137 Routing Header that has the strict source route information down 1138 the DODAG to the destination. This will be the case even if the 1139 destination is relatively close to the source and the Root is 1140 relatively far off. 1142 * In storing mode, unless the destination is a child of the source, 1143 the packets will follow the default route up the DODAG as well. 1144 If the destination is in the same DODAG, they will eventually 1145 reach a common parent that has a route to the destination; at 1146 worse, the common parent may also be the Root. From that common 1147 parent, the packet will follow a path down the DODAG that is 1148 optimized for the Objective Function that was used to build the 1149 DODAG. 1151 ------+--------- 1152 | Internet 1153 | 1154 +-----+ 1155 | | Border Router 1156 | | (RPL Root) 1157 +-----+ 1158 X 1159 ^ v o o 1160 ^ o o v o o o o o 1161 ^ o o o v o o o o o 1162 ^ o o v o o o o o 1163 S o o o D o o o 1164 o o o o 1165 LLN 1167 Figure 9: Routing Stretch between S and D via common parent X 1169 It results that it is often beneficial to enable transversal P2P 1170 routes, either if the RPL route presents a stretch from shortest 1171 path, or if the new route is engineered with a different objective. 1172 For that reason, earlier work at the IETF introduced the "Reactive 1173 Discovery of Point-to-Point Routes in Low Power and Lossy Networks" 1174 [RFC6997], which specifies a distributed method for establishing 1175 optimized P2P routes. This draft proposes an alternate based on a 1176 centralized route computation. 1178 ------+--------- 1179 | Internet 1180 | 1181 +-----+ 1182 | | Border Router 1183 | | (RPL Root) 1184 +-----+ 1185 | 1186 o o o o 1187 o o o o o o o o o 1188 o o o o o o o o o o 1189 o o o o o o o o o 1190 S>>A>>>B>>C>>>D o o o 1191 o o o o 1192 LLN 1194 Figure 10: Projected Transversal Route 1196 This specification enables to store source-routed or storing mode 1197 state in intermediate routers, which enables to limit the stretch of 1198 a P2P route and maintain the characteristics within a given SLA. An 1199 example of service using this mechanism oculd be a control loop that 1200 would be installed in a network that uses classical RPL for 1201 asynchronous data collection. In that case, the P2P path may be 1202 installed in a different RPL Instance, with a different objective 1203 function. 1205 Appendix B. Examples 1207 B.1. Using storing mode P-DAO in non-storing mode MOP 1209 In non-storing mode, the DAG Root maintains the knowledge of the 1210 whole DODAG topology, so when both the source and the destination of 1211 a packet are in the DODAG, the Root can determine the common parent 1212 that would have been used in storing mode, and thus the list of nodes 1213 in the path between the common parent and the destination. For 1214 Instance in the diagram shown in Figure 11, if the source is node 41 1215 and the destination is node 52, then the common parent is node 22. 1217 ------+--------- 1218 | Internet 1219 | 1220 +-----+ 1221 | | Border Router 1222 | | (RPL Root) 1223 +-----+ 1224 | \ \____ 1225 / \ \ 1226 o 11 o 12 o 13 1227 / | / \ 1228 o 22 o 23 o 24 o 25 1229 / \ | \ \ 1230 o 31 o 32 o o o 35 1231 / / | \ | \ 1232 o 41 o 42 o o o 45 o 46 1233 | | | | \ | 1234 o 51 o 52 o 53 o o 55 o 56 1236 LLN 1238 Figure 11: Example DODAG forming a logical tree topology 1240 With this draft, the Root can install a storing mode routing states 1241 along a segment that is either from itself to the destination, or 1242 from one or more common parents for a particular source/destination 1243 pair towards that destination (in this particular example, this would 1244 be the segment made of nodes 22, 32, 42). 1246 In the example below, say that there is a lot of traffic to nodes 55 1247 and 56 and the Root decides to reduce the size of routing headers to 1248 those destinations. The Root can first send a DAO to node 45 1249 indicating Target 55 and a Via segment (35, 45), as well as another 1250 DAO to node 46 indicating Target 56 and a Via segment (35, 46). This 1251 will save one entry in the routing header on both sides. The Root 1252 may then send a DAO to node 35 indicating Targets 55 and 56 a Via 1253 segment (13, 24, 35) to fully optimize that path. 1255 Alternatively, the Root may send a DAO to node 45 indicating Target 1256 55 and a Via segment (13, 24, 35, 45) and then a DAO to node 46 1257 indicating Target 56 and a Via segment (13, 24, 35, 46), indicating 1258 the same DAO Sequence. 1260 B.2. Projecting a storing-mode transversal route 1262 In this example, say that a PCE determines that a path must be 1263 installed between node S and node D via routers A, B and C, in order 1264 to serve the needs of a particular application. 1266 The Root sends a P-DAO with a Target option indicating the 1267 destination D and a sequence Via Information option, one for S, which 1268 is the ingress router of the segment, one for A and then for B, which 1269 are an intermediate routers, and one for C, which is the egress 1270 router. 1272 ------+--------- 1273 | Internet 1274 | 1275 +-----+ 1276 | | Border Router 1277 | | (RPL Root) 1278 +-----+ 1279 | P-DAO message to C 1280 o | o o 1281 o o o | o o o o o 1282 o o o | o o o o o o 1283 o o V o o o o o o 1284 S A B C D o o o 1285 o o o o 1286 LLN 1288 Figure 12: P-DAO from Root 1290 Upon reception of the P-DAO, C validates that it can reach D, e.g. 1291 using IPv6 Neighbor Discovery, and if so, propagates the P-DAO 1292 unchanged to B. 1294 B checks that it can reach C and of so, installs a route towards D 1295 via C. Then it propagates the P-DAO to A. 1297 The process recurses till the P-DAO reaches S, the ingress of the 1298 segment, which installs a route to D via A and sends a DAO-ACK to the 1299 Root. 1301 ------+--------- 1302 | Internet 1303 | 1304 +-----+ 1305 | | Border Router 1306 | | (RPL Root) 1307 +-----+ 1308 ^ P-DAO-ACK from S 1309 / o o o 1310 / o o o o o o o 1311 | o o o o o o o o o 1312 | o o o o o o o o 1313 S A B C D o o o 1314 o o o o 1315 LLN 1317 Figure 13: P-DAO-ACK to Root 1319 As a result, a transversal route is installed that does not need to 1320 follow the DODAG structure. 1322 ------+--------- 1323 | Internet 1324 | 1325 +-----+ 1326 | | Border Router 1327 | | (RPL Root) 1328 +-----+ 1329 | 1330 o o o o 1331 o o o o o o o o o 1332 o o o o o o o o o o 1333 o o o o o o o o o 1334 S>>A>>>B>>C>>>D o o o 1335 o o o o 1336 LLN 1338 Figure 14: Projected Transversal Route 1340 Authors' Addresses 1341 Pascal Thubert (editor) 1342 Cisco Systems, Inc 1343 Building D, 45 Allee des Ormes - BP1200 1344 06254 Mougins - Sophia Antipolis 1345 France 1347 Phone: +33 497 23 26 34 1348 Email: pthubert@cisco.com 1350 Rahul Arvind Jadhav 1351 Huawei Tech 1352 Kundalahalli Village, Whitefield, 1353 Bangalore 560037 1354 Karnataka 1355 India 1357 Phone: +91-080-49160700 1358 Email: rahul.ietf@gmail.com 1360 Matthew Gillmore 1361 Itron, Inc 1362 Building D, 2111 N Molter Road 1363 Liberty Lake, 99019 1364 United States 1366 Phone: +1.800.635.5461 1367 Email: matthew.gillmore@itron.com