idnits 2.17.1 draft-ietf-roll-dao-projection-11.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 : ---------------------------------------------------------------------------- -- 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 (September 11, 2020) is 1295 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-29 == Outdated reference: A later version (-09) exists of draft-pthubert-raw-architecture-04 Summary: 0 errors (**), 0 flaws (~~), 3 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: March 15, 2021 M. Gillmore 7 Itron 8 September 11, 2020 10 Root initiated routing state in RPL 11 draft-ietf-roll-dao-projection-11 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 March 15, 2021. 44 Copyright Notice 46 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 63 2.2. References . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.4. Other Terms . . . . . . . . . . . . . . . . . . . . . . . 6 66 3. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 6 67 4. Identifying a Path . . . . . . . . . . . . . . . . . . . . . 7 68 5. New RPL Control Messages and Options . . . . . . . . . . . . 8 69 5.1. New P-DAO Request Control Message . . . . . . . . . . . . 8 70 5.2. New PDR-ACK Control Message . . . . . . . . . . . . . . . 9 71 5.3. Route Projection Options . . . . . . . . . . . . . . . . 10 72 5.4. Sibling Information Option . . . . . . . . . . . . . . . 12 73 6. Projected DAO . . . . . . . . . . . . . . . . . . . . . . . . 14 74 6.1. Non-Storing Mode Projected Route . . . . . . . . . . . . 15 75 6.2. Storing-Mode Projected Route . . . . . . . . . . . . . . 17 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 78 8.1. New RPL Control Codes . . . . . . . . . . . . . . . . . . 19 79 8.2. New RPL Control Message Options . . . . . . . . . . . . . 19 80 8.3. New SubRegistry for the Projected DAO Request (PDR) 81 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 20 82 8.4. New SubRegistry for the PDR-ACK Flags . . . . . . . . . . 20 83 8.5. New Subregistry for the PDR-ACK Acceptance Status 84 values . . . . . . . . . . . . . . . . . . . . . . . . . 21 85 8.6. New Subregistry for the PDR-ACK Rejection Status 86 values . . . . . . . . . . . . . . . . . . . . . . . . . 21 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 22 91 8.9. Error in Projected Route ICMPv6 Code . . . . . . . . . . 22 92 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 93 10. Normative References . . . . . . . . . . . . . . . . . . . . 23 94 11. Informative References . . . . . . . . . . . . . . . . . . . 23 95 Appendix A. Applications . . . . . . . . . . . . . . . . . . . . 24 96 A.1. Loose Source Routing in Non-storing Mode . . . . . . . . 25 97 A.2. Transversal Routes in storing and non-storing modes . . . 26 98 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 28 99 B.1. Using storing mode P-DAO in non-storing mode MOP . . . . 28 100 B.2. Projecting a storing-mode transversal route . . . . . . . 29 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 103 1. Introduction 105 RPL, the "Routing Protocol for Low Power and Lossy Networks" [RPL] 106 (LLNs), is a generic Distance Vector protocol that is well suited for 107 application in a variety of low energy Internet of Things (IoT) 108 networks. RPL forms Destination Oriented Directed Acyclic Graphs 109 (DODAGs) in which the Root often acts as the Border Router to connect 110 the RPL domain to the Internet. The Root is responsible to select 111 the RPL Instance that is used to forward a packet coming from the 112 Internet into the RPL domain and set the related RPL information in 113 the packets. The "6TiSCH Architecture" [6TiSCH-ARCHI] uses RPL for 114 its routing operations. 116 The 6TiSCH Architecture also leverages the "Deterministic Networking 117 Architecture" [RFC8655] centralized model whereby the device 118 resources and capabilities are exposed to an external controller 119 which installs routing states into the network based on some 120 objective functions that reside in that external entity. With DetNet 121 and 6TiSCH, the component of the controller that is responsible of 122 computing routes 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 protocol extensions to RPL that enable 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 extensions enable 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 end-to-end path to a Target or a segment in a more complex 143 forwarding graph called a Track. 145 The concept of a Track was introduced in the 6TiSCH architecture, as 146 a complex path with redundant forwarding solutions along the way. A 147 node that is present on more than one segment in a Track may be able 148 to use either of the Track segments to forward a packet towards the 149 Target. 151 The "Reliable and Available Wireless (RAW) Architecture/Framework" 152 [RAW-ARCHI] extends the the forward plane to leverage that redundancy 153 with the Packet ARQ, Replication, Elimination, and Overhearing 154 (PAREO) functions. 156 The RAW Architecture also discusses the dynamic selection of the best 157 path for a packet within a Track at forwarding time. To that effect, 158 it defines the Path Selection Engine (PSE), which is the counter-part 159 of the PCE to perform rapid local adjustments of the forwarding 160 tables within the path diversity that the PCE has selected for the 161 Track. 163 RAW differentiates the time scale at which the PCE computes the Track 164 (slow, globally optimized, based on statistical metrics) and the time 165 scale at which the PSE makes the forwarding decision for a packet or 166 a small collection of packets (fast, but with a scope limited to the 167 Track). This provides a dynamic balance between the reliability and 168 availability requirements of the flows and the need to conserve 169 energy and spectrum. 171 Projected Routes must be used with the parsimony to limit the amount 172 of state that is installed in each device to fit within the device 173 resources, and to maintain the amount of rerouted traffic within the 174 capabilities of the transmission links. The methods used to learn 175 the node capabilities and the resources that are available in the 176 devices and in the network are out of scope for this document. 178 This specification expects that a base RPL Instance is operated in 179 RPL Non-Storing Mode to sustain the exchanges with the Root. In that 180 Mode, the Root has enough information to build a basic DODAG topology 181 based on parents and children, but lacks the knowledge of siblings. 182 This document adds the capability for nodes to advertise sibling 183 information in order to improve the topological awareness of the 184 Root. 186 This specification uses the RPL Root as a proxy to the PCE. The PCE 187 may be collocated with the Root, or may reside in an external 188 Controller. In that case, the PCE exchanges control messages with 189 the Root over a Southbound API, that is out of scope for this 190 specification. The algorithm to compute the paths and the protocol 191 used by an external PCE to obtain the topology of the network from 192 the Root are also out of scope. 194 2. Terminology 196 2.1. Requirements Language 198 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 199 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 200 "OPTIONAL" in this document are to be interpreted as described in BCP 201 14 [RFC2119][RFC8174] when, and only when, they appear in all 202 capitals, as shown here. 204 2.2. References 206 In this document, readers will encounter terms and concepts that are 207 discussed in the "Routing Protocol for Low Power and Lossy Networks" 208 [RPL] and "Terminology in Low power And Lossy Networks" [RFC7102]. 210 2.3. Glossary 212 This document often uses the following acronyms: 214 6BBR: 6LoWPAN Backbone Router 215 6LBR: 6LoWPAN Border Router 216 6LN: 6LoWPAN Node 217 6LR: 6LoWPAN Router 218 CMO: Control Message Option 219 DAO: Destination Advertisement Object 220 DODAG: Destination-Oriented Directed Acyclic Graph 221 LLN: Low-Power and Lossy Network 222 MOP: RPL Mode of Operation 223 NA: Neighbor Advertisement 224 NCE: Neighbor Cache Entry 225 ND: Neighbor Discovery 226 NDP: Neighbor Discovery Protocol 227 NS: Neighbor Solicitation 228 P-DAO: A Projected DAO is a DAO message sent by the RPL Root to 229 install a Projected Route. 230 PDR P-DAO Request 231 RA: Router Advertisement 232 RAN: RPL-Aware Node 233 RS: Router Solicitation 234 RPL: IPv6 Routing Protocol for LLNs [RPL] 235 RPO: A Route Projection Option; it can be a VIO or an SRVIO. 236 RTO: RPL Target Option 237 SIO: RPL Sibling Information Option 238 SRVIO: A Source-Routed Via Information Option, used in Non-Storing 239 Mode P-DAO messages. 240 TIO: RPL Transit Information Option 241 VIO: A Via Information Option, used in Storing Mode P-DAO messages. 243 2.4. Other Terms 245 Projected Route: A Projected Route is a serial path or path segment 246 that is computed, installed and maintained remotely by a RPL Root. 247 Track: The term Track is used in this document to refer to a complex 248 path, e.g., a DODAG, that incorporates redundant Projected Routes 249 towards a destination using diversity to increase the reliability. 251 3. Updating RFC 6550 253 This specification introduces two new RPL Control Messages to enable 254 a RPL Aware Node (RAN) to request the establisment of a Track from 255 self to a Target. The RAN makes its request by sending a new P-DAO 256 Request (PDR) Message to the Root. The Root confirms with a new PDR- 257 ACK message back to the requester RAN, see Section 5.1 for more. 259 Section 6.7 of [RPL] specifies the RPL Control Message Options (CMO) 260 to be placed in RPL messages such as the Destination Advertisement 261 Object (DAO) message. The RPL Target Option (RTO) and the Transit 262 Information Option (TIO) are such options. 264 In Non-Storing Mode, the TIO option is used in the DAO message to 265 inform the root of the parent-child relationships within the DODAG, 266 and the Root has a full knowledge of the DODAG structure. The TIO 267 applies to the RTOs that preceed it immediately in the message. 268 Options may be factorized; multiple TIOs may be present to indicate 269 multiple routes to the one or more contiguous addresses indicated in 270 the RTOs that immediately precede the TIOs in the RPL message. 272 This specification introduces two new CMOs referred to as Route 273 Projection Options (RPO) to install Projected Routes. One RPO is the 274 Via Information Option (VIO) and the other is the Source-Routed VIO 275 (SRVIO). The VIO installs a route on each hop along a Projected 276 Route (in a fashion analogous to RPL Storing Mode) whereas the SRVIO 277 installs a source-routing state at the ingress node, which uses that 278 state to encapsulate a packet with an IPv6 Routing Header in a 279 fashion similar to RPL Non-Storing Mode. 281 Like the TIO, the RPOs MUST be preceded by exactly one RTO to which 282 they apply, and SRVIOs MAY be factorized, though VIOs MUST NOT be. 283 Factorized contiguous SRVIOs indicate alternate paths to the Target, 284 more in Section 5.3. 286 This specification also introduces a new CMO to enable a RAN to 287 advertise a selection of its candidate neighbors as siblings to the 288 Root, using a new Sibling Information Option (SIO) as specified in 289 Section 5.4. 291 4. Identifying a Path 293 It must be noted that RPL has a concept of Instance to represent 294 different routing topologies but does not have a concept of an 295 administrative distance, which exists in certain proprietary 296 implementations to sort out conflicts between multiple sources of 297 routing information within one routing topology. 299 This draft conforms the Instance model as follows: 301 * If the PCE needs to influence a particular Instance to add better 302 routes in conformance with the routing objectives in that 303 Instance, it may do so as long as it does not create a loop. A 304 Projected Route is always preferred over a route that is learned 305 via RPL. 307 * A PCE that installs a more specific (say, Traffic Engineered) and 308 possibly complex path (i.e., a Track) towards a particular Target 309 MUST use a Local RPL Instance (see section 5 of [RPL]) associated 310 to that Target to identify the path. 312 We refer to that Local RPLInstanceID as TrackID. A TrackID MUST 313 be unique for a particular Target address. A Track is uniquely 314 identified within the RPL domain by the tuple (Target address, 315 TrackID). 317 When packet is placed on a Track, a RPL Packet Information (RPI) 318 is added with the TrackID as RPLInstanceID. The RPLInstanceID has 319 the 'D' flag set, indicating that the destination address in the 320 IPv6 header is the Target that is used to identify the Track. 322 * A packet that is routed over the RPL Instance associated to a 323 Track MUST NOT be placed over a different RPL Instance again. 324 Conversely, a packet that is placed on a Global Instance MAY be 325 injected in a Local Instance based on a network policy and the 326 Local Instance configuration. 328 A Projected Route is a serial path that may represent the end-to-end 329 route or only a segment in a complex Track, in which case multiple 330 Projected Routes are installed with the same tuple (Target address, 331 TrackID) and a different segment ID each. 333 All properties of a Track operations are inherited form the main 334 instance that is used to install the Track. For instance, the use of 335 compression per [RFC8138] is determined by whether it is used in the 336 main instance, e.g., by setting the "T" flag [TURN-ON_RFC8138] in the 337 RPL configuration option. 339 5. New RPL Control Messages and Options 341 5.1. New P-DAO Request Control Message 343 The P-DAO Request (PDR) message is sent to the Root to request a new 344 that the PCE establishes a new a projected route as a full path of a 345 collection of segments in a Track. Exactly one Target Options MUST 346 be present. 348 The format of PDR Base Object is as follows: 350 0 1 2 3 351 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 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | TrackID |K|R| Flags | PDRLifetime | PDRSequence | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Option(s)... 356 +-+-+-+-+-+-+-+-+ 358 Figure 1: New P-DAO Request Format 360 TrackID: 8-bit field indicating the RPLInstanceID associated with 361 the Track. It is set to zero upon the first request for a new 362 Track and then to the TrackID once the Track was created, to 363 either renew it of destroy it. 365 K: The 'K' flag is set to indicate that the recipient is expected to 366 send a PDR-ACK back. 368 R: The 'R' flag is set to indicate that the Requested path should be 369 redundant. 371 PDRLifetime: 8-bit unsigned integer. 373 The requested lifetime for the Track expressed in Lifetime Units 374 (obtained from the DODAG Configuration option). 376 A PDR with a fresher PDRSequence refreshes the lifetime, and a 377 PDRLifetime of 0 indicates that the track should be destroyed. 379 PDRSequence: 8-bit wrapping sequence number, obeying the operation 380 in section 7.2 of [RPL]. 382 The PDRSequence is used to correlate a PDR-ACK message with the 383 PDR message that triggeted it. It is incremented at each PDR 384 message and echoed in the PDR-ACK by the Root. 386 5.2. New PDR-ACK Control Message 388 The new PDR-ACK is sent as a response to a PDR message with the 'K' 389 flag set. Its format is as follows: 391 0 1 2 3 392 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 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | TrackID | Flags | Track Lifetime| PDRSequence | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | PDR-ACK Status| Reserved | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Option(s)... 399 +-+-+-+-+-+-+-+ 401 Figure 2: New PDR-ACK Control Message Format 403 TrackID: The RPLInstanceID of the Track that was created. Set to 0 404 when no Track is created. 406 Track Lifetime: Indicates that remaining Lifetime for the Track, 0 407 if the Track was destroyed or not created. 409 PDRSequence: 8-bit wrapping sequence number. It is incremented at 410 each PDR message and echoed in the PDR-ACK. 412 PDR-ACK Status: 8-bit field indicating the completion. 414 The PDR-ACK Status is further substructured as indicated in 415 Figure 3. 417 0 1 2 3 4 5 6 7 418 +-+-+-+-+-+-+-+-+ 419 |E|R| Value | 420 +-+-+-+-+-+-+-+-+ 422 Figure 3: PDR-ACK status Format 424 E: 1-bit flag. Set to indicate a rejection. When not set, a value 425 of 0 indicates Success/Unqualified acceptance and other values 426 indicate "not an outright rejection". 428 R: 1-bit flag. Reserved, MUST be set to 0 by the sender and ignored 429 by the receiver. 431 Status Value: 6-bit unsigned integer. Values depending on the 432 setting of the 'E' flag as indicated respectively in Table 4 and 433 Table 5. 435 5.3. Route Projection Options 437 The RPOs indicate a series of IPv6 addresses that can be compressed 438 using the method defined in the "6LoWPAN Routing Header" [RFC8138] 439 specification using the address of the Root found in the DODAGID 440 field of DIO messages as Compression Reference. 442 An RPO indicates a Projected Route that can be a serial Track in full 443 or a segment of a more complex Track. In Non-Storing Mode, multiple 444 RPO may be placed after a same Target Option to reflect different 445 segments originated at this node. The Track is identified by a 446 TrackID that is a Local RPLInstanceID to the Target of the Track. 448 The format of RPOs is as follows: 450 0 1 2 3 451 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 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Type | Option Length |C| Flags | Reserved | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | TrackID | SegmentID |Segm. Sequence | Seg. Lifetime | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | | 458 + + 459 . . 460 . Via Address 1 . 461 . . 462 + + 463 | | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | | 466 . .... . 467 | | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | | 470 + + 471 . . 472 . Via Address n . 473 . . 474 + + 475 | | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 Figure 4: Via Information option format (uncompressed form) 480 Option Type: 0x0A for VIO, 0x0B for SRVIO (to be confirmed by IANA) 481 Option Length: In bytes; variable, depending on the number of Via 482 Addresses. 484 C: 1-bit flag. Set to indicate that the following Via Addresses are 485 expressed as one or more SRH-6LoRH as defined in section 5.1 of 486 [RFC8138]. Figure 4 illustrates the case where the "C" flag is 487 not set, meaning that the Via Addresses are expressed in full 128 488 bits. 490 TrackID: 8-bit field indicating the topology Instance associated 491 with the Track. The tuple (Target Address, TrackID) forms a 492 unique ID of the Track in the RPL domain. 494 Track Sequence: 8-bit unsigned integer. The Track Sequence obeys 495 the operation in section 7.2 of [RPL] and the lollipop starts at 496 255. The Track Sequence is set by the Root and incremented each 497 time the Root refreshes that Track globally. A Track Sequence 498 that is fresher than the current on deprecates any state for the 499 Track. A Track Sequence that is current adds to any state that 500 was learned for that Track Sequence. A RTO with a Track Sequence 501 that is not as fresh as the current one is ignored. 503 Track Lifetime: 8-bit unsigned integer. The length of time in 504 Lifetime Units (obtained from the Configuration option) that the 505 Track is usable. The period starts when a new Track Sequence is 506 seen. A value of 255 (0xFF) represents infinity. A value of zero 507 (0x00) indicates a loss of reachability. A DAO message that 508 contains a Via Information option with a Path Lifetime of zero for 509 a Target is referred as a No-Path (for that Target) in this 510 document. 512 SegmentID: 8-bit field that identifies a segment within a Track. A 513 Value of 0 is used to signal a serial Track. 515 Segment Sequence: 8-bit unsigned integer. The Segment Sequence 516 obeys the operation in section 7.2 of [RPL] and the lollipop 517 starts at 255. When the Root of the DODAG needs to update a 518 single segment in a Track, but does not need to modify the rest of 519 the Track, it increments the Segment Sequence but not the Track 520 Sequence. The segment information indicated in the RTO deprecates 521 any state for the segment indicated by the SegmentID within the 522 indicated Track and sets up the new information. A RTO with a 523 Segment Sequence that is not as fresh as the current one is 524 ignored. a RTO for a given target with the same (TrackID, Track 525 Sequence, SegmentID, Segment Sequence) indicates a retry; it MUST 526 NOT change the segment and MUST be propagated or answered as the 527 first copy. 529 Via Address: The collection of Via Addresses along one segment, 530 indicated in the order of the path from the ingress to the egress 531 nodes. If the "C" flag is set, the fields Via Address 1 .. Via 532 Address n in Figure 4 are replaced by one or more of the headers 533 illustrated in Fig. 6 of [RFC8138]. More than one SRH-6LoRH is 534 needed if the compression of the addresses change inside the 535 segment and different SRH-6LoRH Types are used. 537 An RPO MUST contain at least one Via Address, and a Via Address MUST 538 NOT be present more than once, otherwise the RPO MUST be ignored. 540 5.4. Sibling Information Option 542 The Sibling Information Option (SIO) provides indication on siblings 543 that could be used by the Root to form Projected Routes. The format 544 of SIOs is as follows: 546 0 1 2 3 547 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 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | Type | Option Length |Comp.|B|D|Flags| Opaque | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Step of Rank | Sibling Rank | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | | 554 + + 555 . . 556 . Sibling DODAGID (if 'D' flag not set) . 557 . . 558 + + 559 | | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | | 562 + + 563 . . 564 . Sibling Address . 565 . . 566 + + 567 | | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 Figure 5: Sibling Information Option Format 572 Option Type: 0x0C (to be confirmed by IANA) 574 Option Length: In bytes; variable, depending on the number of Via 575 Addresses. 577 Compression Type: 3-bit unsigned integer. This is the SRH-6LoRH 578 Type as defined in figure 7 in section 5.1 of [RFC8138] that 579 corresponds to the compression used for the Sibling Address. 581 Reserved for Flags: MUST be set to zero by the sender and MUST be 582 ignored by the receiver. 584 B: 1-bit flag that is set to indicate that the connectivity to the 585 sibling is bidirectional and roughly symmetrical. In that case, 586 only one of the siblings may report the SIO for the hop. If 'B' 587 is not set then the SIO only indicates connectivity from the 588 sibling to this node, and does not provide information on the hop 589 from this node to the sibling. 591 D: 1-bit flag that is set to indicate that sibling belongs to the 592 same DODAG. When not set, the Sibling DODAGID is indicated. 594 Opaque: MAY be used to carry information that the node and the Root 595 understand, e.g., a particular representation of the Link 596 properties such as a proprietary Link Quality Information for 597 packets received from the sibling. An industraial Alliance that 598 uses RPL for a particular use / environment MAY redefine the use 599 of this field to fit its needs. 601 Step of Rank: 16-bit unsigned integer. This is the Step of Rank 602 [RPL] as computed by the Objective Function between this node and 603 the sibling. 605 Sibling Rank: 16-bit unsigned integer. When non-zero, this is the 606 Rank [RPL] as exposed by the sibling in DIO messages. 608 Sibling DODAGID: 2 to 16 bytes, the DODAGID of the sibling in a 609 [RFC8138] compressed form as indicated by the Compression Type 610 field. This field is present when the 'D' flag is not set. 612 Sibling Address: 2 to 16 bytes, the IPv6 Address of the sibling in a 613 [RFC8138] compressed form as indicated by the Compression Type 614 field. 616 An SIO MAY be immediately followed by a DAG Metric Container. In 617 that case the DAG Metric Container provides additional metrics for 618 the hop from the Sibling to this node. 620 6. Projected DAO 622 This draft adds a capability to RPL whereby the Root of a DODAG 623 projects a route by sending one or more extended DAO message called 624 Projected-DAO (P-DAO) messages to an arbitrary router in the DODAG, 625 indicating one or more sequence(s) of routers inside the DODAG via 626 which the Target(s) indicated in the RPL Target Option(s) (RTO) can 627 be reached. 629 A P-DAO is sent from a global address of the Root to a global address 630 of the recipient, and MUST be confirmed by a DAO-ACK, which is sent 631 back to a global address of the Root. 633 A P-DAO message MUST contain exactly one RTO and either one VIO or 634 one or more SRVIOs following it. There can be at most one such 635 sequence of RTOs and then RPOs. 637 Like a classical DAO message, a P-DAO causes a change of state only 638 if it is "new" per section 9.2.2. "Generation of DAO Messages" of 639 the RPL specification [RPL]; this is determined using the Track 640 Sequence and the Segment Sequence information from the RPO as opposed 641 to the Path Sequence from a TIO. Also, a Path Lifetime of 0 in an 642 RPO indicates that a route is to be removed. 644 There are two kinds of operation for the Projected Routes, the 645 Storing Mode and the Non-Storing Mode. 647 * The Non-Storing Mode is discussed in Section 6.1. It uses an 648 SRVIO that carries a list of Via Addresses to be used as a source- 649 routed path to the Target. The recipient of the P-DAO is the 650 ingress router of the source-routed path. Upon a Non-Storing Mode 651 P-DAO, the ingress router installs a source-routed state to the 652 Target and replies to the Root directly with a DAO-ACK message. 654 * The Storing Mode is discussed in Section 6.2. It uses a VIO with 655 one Via Address per consecutive hop, from the ingress to the 656 egress of the path, including the list of all intermediate routers 657 in the data path order. The Via Addresses indicate the routers in 658 which the routing state to the Target have to be installed via the 659 next Via Address in the VIO. In normal operations, the P-DAO is 660 propagated along the chain of Via Routers from the egress router 661 of the path till the ingress one, which confirms the installation 662 to the Root with a DAO-ACK message. Note that the Root may be the 663 ingress and it may be the egress of the path, that it can also be 664 neither but it cannot be both. 666 In case of a forwarding error along a Projected Route, an ICMP error 667 is sent to the Root with a new Code "Error in Projected Route" (See 668 Section 8.9). The Root can then modify or remove the Projected 669 Route. The "Error in Projected Route" message has the same format as 670 the "Destination Unreachable Message", as specified in RFC 4443 671 [RFC4443]. The portion of the invoking packet that is sent back in 672 the ICMP message SHOULD record at least up to the routing header if 673 one is present, and the routing header SHOULD be consumed by this 674 node so that the destination in the IPv6 header is the next hop that 675 this node could not reach. if a 6LoWPAN Routing Header (6LoRH) 676 [RFC8138] is used to carry the IPv6 routing information in the outter 677 header then that whole 6LoRH information SHOULD be present in the 678 ICMP message. The sender and exact operation depend on the Mode and 679 is described in Section 6.1 and Section 6.2 respectively. 681 6.1. Non-Storing Mode Projected Route 683 As illustrated in Figure 6, a P-DAO that carries an SRVIO enables the 684 Root to install a source-routed path towards a Target in any 685 particular router; with this path information the router can add a 686 source routed header reflecting the Projected Route to any packet for 687 which the current destination either is the said Target or can be 688 reached via the Target. 690 ------+--------- 691 | Internet 692 | 693 +-----+ 694 | | Border Router 695 | | (RPL Root) 696 +-----+ | P ^ | 697 | | DAO | ACK | Loose 698 o o o o router V | | Source 699 o o o o o o o o o | P-DAO . Route 700 o o o o o o o o o o | Source . Path 701 o o o o o o o o o | Route . From 702 o o o o o o o o | Path . Root 703 o o o o o Target V . To 704 o o o o | Desti- 705 o o o o | nation 706 destination V 708 LLN 710 Figure 6: Projecting a Non-Storing Route 712 A route indicated by an SRVIO may be loose, meaning that the node 713 that owns the next listed Via Address is not necessarily a neighbor. 714 Without proper loop avoidance mechanisms, the interaction of loose 715 source routing and other mechanisms may effectively cause loops. In 716 order to avoid those loops, if the router that installs a Projected 717 Route does not have a connected route (a direct adjacency) to the 718 next soure routed hop and fails to locate it as a neighbor or a 719 neighbor of a neighbor, then it MUST ensure that it has another 720 Projected Route to the next loose hop under the control of the same 721 route computation system, otherwise the P-DAO is rejected. 723 When forwarding a packet to a destination for which the router 724 determines that routing happens via the Target, the router inserts 725 the source routing header in the packet to reach the Target. In 726 order to add a source-routing header, the router encapsulates the 727 packet with an IP-in-IP header and a non-storing mode source routing 728 header (SRH) [RFC6554]. In the uncompressed form the source of the 729 packet would be self, the destination would be the first Via Address 730 in the SRVIO, and the SRH would contain the list of the remaining Via 731 Addresses and then the Target. 733 In the case of a loose source-routed path, there MUST be either a 734 neighbor that is adjacent to the loose next hop, on which case the 735 packet is forwarded to that neighbor, or a source-routed path to the 736 loose next hop; in the latter case, another encapsulation takes place 737 and the process possibly recurses; otherwise the packet is dropped. 739 In practice, the router will normally use the "IPv6 over Low-Power 740 Wireless Personal Area Network (6LoWPAN) Paging Dispatch" [RFC8025] 741 to compress the RPL artifacts as indicated in [RFC8138]. In that 742 case, the router indicates self as encapsulator in an IP-in-IP 6LoRH 743 Header, and places the list of Via Addresses in the order of the VIO 744 and then the Target in the SRH 6LoRH Header. 746 In case of a forwarding error along a Source Route path, the node 747 that fails to forward SHOULD send an ICMP error with a code "Error in 748 Source Routing Header" back to the source of the packet, as described 749 in section 11.2.2.3. of [RPL]. Upon this message, the encapsulating 750 node SHOULD stop using the source route path for a period of time and 751 it SHOULD send an ICMP message with a Code "Error in Projected Route" 752 to the Root. Failure to follow these steps may result in packet loss 753 and wasted resources along the source route path that is broken. 755 6.2. Storing-Mode Projected Route 757 As illustrated in Figure 7, the Storing Mode route projection is used 758 by the Root to install a routing state towards a Target in the 759 routers along a segment between an ingress and an egress router; this 760 enables the routers to forward along that segment any packet for 761 which the next loose hop is the said Target, for Instance a loose 762 source routed packet for which the next loose hop is the Target, or a 763 packet for which the router has a routing state to the final 764 destination via the Target. 766 ------+--------- 767 | Internet 768 | 769 +-----+ 770 | | Border Router 771 | | (RPL Root) 772 +-----+ | ^ | 773 | | DAO | ACK | 774 o o o o | | | 775 o o o o o o o o o | ^ | Projected . 776 o o o o o o o o o o | | DAO | Route . 777 o o o o o o o o o | ^ | . 778 o o o o o o o o v | DAO v . 779 o o LLN o o o | 780 o o o o o Loose Source Route Path | 781 o o o o From Root To Destination v 783 Figure 7: Projecting a route 785 In order to install the relevant routing state along the segment 786 between an ingress and an egress routers, the Root sends a unicast 787 P-DAO message to the egress router of the routing segment that must 788 be installed. The P-DAO message contains the ordered list of hops 789 along the segment as a direct sequence of Via Information options 790 that are preceded by one or more RPL Target options to which they 791 relate. Each Via Information option contains a Path Lifetime for 792 which the state is to be maintained. 794 The Root sends the P-DAO directly to the egress node of the segment. 795 In that P-DAO, the destination IP address matches the Via Address in 796 the last VIO. This is how the egress recognizes its role. In a 797 similar fashion, the ingress node recognizes its role as it matches 798 Via Address in the first VIO. 800 The egress node of the segment is the only node in the path that does 801 not install a route in response to the P-DAO; it is expected to be 802 already able to route to the Target(s) on its own. It may either be 803 the Target, or may have some existing information to reach the 804 Target(s), such as a connected route or an already installed 805 Projected Route. If one of the Targets cannot be located, the node 806 MUST answer to the Root with a negative DAO-ACK listing the Target(s) 807 that could not be located (suggested status 10 to be confirmed by 808 IANA). 810 If the egress node can reach all the Targets, then it forwards the 811 P-DAO with unchanged content to its loose predecessor in the segment 812 as indicated in the list of Via Information options, and recursively 813 the message is propagated unchanged along the sequence of routers 814 indicated in the P-DAO, but in the reverse order, from egress to 815 ingress. 817 The address of the predecessor to be used as destination of the 818 propagated DAO message is found in the Via Information option the 819 precedes the one that contain the address of the propagating node, 820 which is used as source of the packet. 822 Upon receiving a propagated DAO, an intermediate router as well as 823 the ingress router install a route towards the DAO Target(s) via its 824 successor in the P-DAO; the router locates the VIO that contains its 825 address, and uses as next hop the address found in the Via Address 826 field in the following VIO. The router MAY install additional routes 827 towards the addresses that are located in VIOs that are after the 828 next one, if any, but in case of a conflict or a lack of resource, a 829 route to a Target installed by the Root has precedence. 831 The process recurses till the P-DAO is propagated to ingress router 832 of the segment, which answers with a DAO-ACK to the Root. 834 Also, the path indicated in a P-DAO may be loose, in which case the 835 reachability to the next hop has to be asserted. Each router along 836 the path indicated in a P-DAO is expected to be able to reach its 837 successor, either with a connected route (direct neighbor), or by 838 routing, for Instance following a route installed previously by a DAO 839 or a P-DAO message. If that route is not connected then a recursive 840 lookup may take place at packet forwarding time to find the next hop 841 to reach the Target(s). If it does not and cannot reach the next 842 router in the P-DAO, the router MUST answer to the Root with a 843 negative DAO-ACK indicating the successor that is unreachable 844 (suggested status 11 to be confirmed by IANA). 846 A Path Lifetime of 0 in a Via Information option is used to clean up 847 the state. The P-DAO is forwarded as described above, but the DAO is 848 interpreted as a No-Path DAO and results in cleaning up existing 849 state as opposed to refreshing an existing one or installing a new 850 one. 852 In case of a forwarding error along a Storing Mode Projected Route, 853 the node that fails to forward SHOULD send an ICMP error with a code 854 "Error in Projected Route" to the Root. Failure to do so may result 855 in packet loss and wasted resources along the Projected Route that is 856 broken. 858 7. Security Considerations 860 This draft uses messages that are already present in RPL [RPL] with 861 optional secured versions. The same secured versions may be used 862 with this draft, and whatever security is deployed for a given 863 network also applies to the flows in this draft. 865 TODO: should probably consider how P-DAO messages could be abused by 866 a) rogue nodes b) via replay of messages c) if use of P-DAO messages 867 could in fact deal with any threats? 869 8. IANA Considerations 871 8.1. New RPL Control Codes 873 This document extends the IANA Subregistry created by RFC 6550 for 874 RPL Control Codes as indicated in Table 1: 876 +======+=============================+===============+ 877 | Code | Description | Reference | 878 +======+=============================+===============+ 879 | 0x09 | Projected DAO Request (PDR) | This document | 880 +------+-----------------------------+---------------+ 881 | 0x0A | PDR-ACK | This document | 882 +------+-----------------------------+---------------+ 884 Table 1: New RPL Control Codes 886 8.2. New RPL Control Message Options 888 This document extends the IANA Subregistry created by RFC 6550 for 889 RPL Control Message Options as indicated in Table 2: 891 +=======+======================================+===============+ 892 | Value | Meaning | Reference | 893 +=======+======================================+===============+ 894 | 0x0B | Via Information option | This document | 895 +-------+--------------------------------------+---------------+ 896 | 0x0C | Source-Routed Via Information option | This document | 897 +-------+--------------------------------------+---------------+ 898 | 0x0D | Sibling Information option | This document | 899 +-------+--------------------------------------+---------------+ 901 Table 2: RPL Control Message Options 903 8.3. New SubRegistry for the Projected DAO Request (PDR) Flags 905 IANA is required to create a registry for the 8-bit Projected DAO 906 Request (PDR) Flags field. Each bit is tracked with the following 907 qualities: 909 * Bit number (counting from bit 0 as the most significant bit) 911 * Capability description 913 * Reference 915 Registration procedure is "Standards Action" [RFC8126]. The initial 916 allocation is as indicated in Table 3: 918 +============+========================+===============+ 919 | Bit number | Capability description | Reference | 920 +============+========================+===============+ 921 | 0 | PDR-ACK request (K) | This document | 922 +------------+------------------------+---------------+ 923 | 1 | Requested path should | This document | 924 | | be redundant (R) | | 925 +------------+------------------------+---------------+ 927 Table 3: Initial PDR Flags 929 8.4. New SubRegistry for the PDR-ACK Flags 931 IANA is required to create an subregistry for the 8-bit PDR-ACK Flags 932 field. Each bit is tracked with the following qualities: 934 * Bit number (counting from bit 0 as the most significant bit) 936 * Capability description 938 * Reference 939 Registration procedure is "Standards Action" [RFC8126]. No bit is 940 currently defined for the PDR-ACK Flags. 942 8.5. New Subregistry for the PDR-ACK Acceptance Status values 944 IANA is requested to create a new subregistry for the PDR-ACK 945 Acceptance Status values. 947 * Possible values are 6-bit unsigned integers (0..63). 949 * Registration procedure is "Standards Action" [RFC8126]. 951 * Initial allocation is as indicated in Table 4: 953 +-------+------------------------+---------------+ 954 | Value | Meaning | Reference | 955 +-------+------------------------+---------------+ 956 | 0 | Unqualified acceptance | This document | 957 +-------+------------------------+---------------+ 959 Table 4: Acceptance values of the PDR-ACK Status 961 8.6. New Subregistry for the PDR-ACK Rejection Status values 963 IANA is requested to create a new subregistry for the PDR-ACK 964 Rejection Status values. 966 * Possible values are 6-bit unsigned integers (0..63). 968 * Registration procedure is "Standards Action" [RFC8126]. 970 * Initial allocation is as indicated in Table 5: 972 +-------+-----------------------+---------------+ 973 | Value | Meaning | Reference | 974 +-------+-----------------------+---------------+ 975 | 0 | Unqualified rejection | This document | 976 +-------+-----------------------+---------------+ 978 Table 5: Rejection values of the PDR-ACK Status 980 8.7. New SubRegistry for the Route Projection Options (RPO) Flags 982 IANA is requested to create a new subregistry for the 5-bit Route 983 Projection Options (RPO) Flags field. Each bit is tracked with the 984 following qualities: 986 * Bit number (counting from bit 0 as the most significant bit) 987 * Capability description 989 * Reference 991 Registration procedure is "Standards Action" [RFC8126]. No bit is 992 currently defined for the Route Projection Options (RPO) Flags. 994 8.8. New SubRegistry for the Sibling Information Option (SIO) Flags 996 IANA is required to create a registry for the 5-bit Sibling 997 Information Option (SIO) Flags field. Each bit is tracked with the 998 following qualities: 1000 * Bit number (counting from bit 0 as the most significant bit) 1002 * Capability description 1004 * Reference 1006 Registration procedure is "Standards Action" [RFC8126]. The initial 1007 allocation is as indicated in Table 6: 1009 +============+===================================+===============+ 1010 | Bit number | Capability description | Reference | 1011 +============+===================================+===============+ 1012 | 0 | Connectivity is bidirectional (B) | This document | 1013 +------------+-----------------------------------+---------------+ 1015 Table 6: Initial SIO Flags 1017 8.9. Error in Projected Route ICMPv6 Code 1019 In some cases RPL will return an ICMPv6 error message when a message 1020 cannot be forwarded along a Projected Route. This ICMPv6 error 1021 message is "Error in Projected Route". 1023 IANA has defined an ICMPv6 "Code" Fields Registry for ICMPv6 Message 1024 Types. ICMPv6 Message Type 1 describes "Destination Unreachable" 1025 codes. This specification requires that a new code is allocated from 1026 the ICMPv6 Code Fields Registry for ICMPv6 Message Type 1, for "Error 1027 in Projected Route", with a suggested code value of 8, to be 1028 confirmed by IANA. 1030 9. Acknowledgments 1032 The authors wish to acknowledge JP Vasseur, Remy Liubing, James 1033 Pylakutty and Patrick Wetterwald for their contributions to the ideas 1034 developed here. 1036 10. Normative References 1038 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1039 Requirement Levels", BCP 14, RFC 2119, 1040 DOI 10.17487/RFC2119, March 1997, 1041 . 1043 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1044 Control Message Protocol (ICMPv6) for the Internet 1045 Protocol Version 6 (IPv6) Specification", STD 89, 1046 RFC 4443, DOI 10.17487/RFC4443, March 2006, 1047 . 1049 [RPL] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1050 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1051 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1052 Low-Power and Lossy Networks", RFC 6550, 1053 DOI 10.17487/RFC6550, March 2012, 1054 . 1056 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 1057 Routing Header for Source Routes with the Routing Protocol 1058 for Low-Power and Lossy Networks (RPL)", RFC 6554, 1059 DOI 10.17487/RFC6554, March 2012, 1060 . 1062 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1063 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1064 May 2017, . 1066 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1067 Writing an IANA Considerations Section in RFCs", BCP 26, 1068 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1069 . 1071 11. Informative References 1073 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 1074 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 1075 2014, . 1077 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and 1078 J. Martocci, "Reactive Discovery of Point-to-Point Routes 1079 in Low-Power and Lossy Networks", RFC 6997, 1080 DOI 10.17487/RFC6997, August 2013, 1081 . 1083 [6TiSCH-ARCHI] 1084 Thubert, P., "An Architecture for IPv6 over the TSCH mode 1085 of IEEE 802.15.4", Work in Progress, Internet-Draft, 1086 draft-ietf-6tisch-architecture-29, August 27, 2020, 1087 . 1090 [RAW-ARCHI] 1091 Thubert, P., Papadopoulos, G., and R. Buddenberg, 1092 "Reliable and Available Wireless Architecture/Framework", 1093 Work in Progress, Internet-Draft, draft-pthubert-raw- 1094 architecture-04, July 6, 2020, 1095 . 1098 [TURN-ON_RFC8138] 1099 Thubert, P. and L. Zhao, "Configuration option for RFC 1100 8138", Work in Progress, Internet-Draft, draft-thubert- 1101 roll-turnon-rfc8138-03, July 8, 2019, 1102 . 1105 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 1106 "Deterministic Networking Architecture", RFC 8655, 1107 DOI 10.17487/RFC8655, October 2019, 1108 . 1110 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 1111 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 1112 RFC 8025, DOI 10.17487/RFC8025, November 2016, 1113 . 1115 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 1116 "IPv6 over Low-Power Wireless Personal Area Network 1117 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 1118 April 2017, . 1120 [PCE] IETF, "Path Computation Element", 1121 . 1123 Appendix A. Applications 1124 A.1. Loose Source Routing in Non-storing Mode 1126 A RPL implementation operating in a very constrained LLN typically 1127 uses the Non-Storing Mode of Operation as represented in Figure 8. 1128 In that mode, a RPL node indicates a parent-child relationship to the 1129 Root, using a Destination Advertisement Object (DAO) that is unicast 1130 from the node directly to the Root, and the Root typically builds a 1131 source routed path to a destination down the DODAG by recursively 1132 concatenating this information. 1134 ------+--------- 1135 | Internet 1136 | 1137 +-----+ 1138 | | Border Router 1139 | | (RPL Root) 1140 +-----+ ^ | | 1141 | | DAO | ACK | 1142 o o o o | | | Strict 1143 o o o o o o o o o | | | Source 1144 o o o o o o o o o o | | | Route 1145 o o o o o o o o o | | | 1146 o o o o o o o o | v v 1147 o o o o 1148 LLN 1150 Figure 8: RPL non-storing mode of operation 1152 Based on the parent-children relationships expressed in the non- 1153 storing DAO messages,the Root possesses topological information about 1154 the whole network, though this information is limited to the 1155 structure of the DODAG for which it is the destination. A packet 1156 that is generated within the domain will always reach the Root, which 1157 can then apply a source routing information to reach the destination 1158 if the destination is also in the DODAG. Similarly, a packet coming 1159 from the outside of the domain for a destination that is expected to 1160 be in a RPL domain reaches the Root. 1162 It results that the Root, or then some associated centralized 1163 computation engine such as a PCE, can determine the amount of packets 1164 that reach a destination in the RPL domain, and thus the amount of 1165 energy and bandwidth that is wasted for transmission, between itself 1166 and the destination, as well as the risk of fragmentation, any 1167 potential delays because of a paths longer than necessary (shorter 1168 paths exist that would not traverse the Root). 1170 As a network gets deep, the size of the source routing header that 1171 the Root must add to all the downward packets becomes an issue for 1172 nodes that are many hops away. In some use cases, a RPL network 1173 forms long lines and a limited amount of well-Targeted routing state 1174 would allow to make the source routing operation loose as opposed to 1175 strict, and save packet size. Limiting the packet size is directly 1176 beneficial to the energy budget, but, mostly, it reduces the chances 1177 of frame loss and/or packet fragmentation, which is highly 1178 detrimental to the LLN operation. Because the capability to store a 1179 routing state in every node is limited, the decision of which route 1180 is installed where can only be optimized with a global knowledge of 1181 the system, a knowledge that the Root or an associated PCE may 1182 possess by means that are outside of the scope of this specification. 1184 This specification enables to store source-routed or storing mode 1185 state in intermediate routers, which enables to limit the excursion 1186 of the source route headers in deep networks. Once a P-DAO exchange 1187 has taken place for a given Target, if the Root operates in non 1188 storing mode, then it may elide the sequence of routers that is 1189 installed in the network from its source route headers to destination 1190 that are reachable via that Target, and the source route headers 1191 effectively become loose. 1193 A.2. Transversal Routes in storing and non-storing modes 1195 RPL is optimized for Point-to-Multipoint (P2MP) and Multipoint-to- 1196 Point (MP2P), whereby routes are always installed along the RPL DODAG 1197 respectively from and towards the DODAG Root. Transversal Peer to 1198 Peer (P2P) routes in a RPL network will generally suffer from some 1199 elongated (stretched) path versus the best possible path, since 1200 routing between 2 nodes always happens via a common parent, as 1201 illustrated in Figure 9: 1203 * in non-storing mode, all packets routed within the DODAG flow all 1204 the way up to the Root of the DODAG. If the destination is in the 1205 same DODAG, the Root must encapsulate the packet to place a 1206 Routing Header that has the strict source route information down 1207 the DODAG to the destination. This will be the case even if the 1208 destination is relatively close to the source and the Root is 1209 relatively far off. 1211 * In storing mode, unless the destination is a child of the source, 1212 the packets will follow the default route up the DODAG as well. 1213 If the destination is in the same DODAG, they will eventually 1214 reach a common parent that has a route to the destination; at 1215 worse, the common parent may also be the Root. From that common 1216 parent, the packet will follow a path down the DODAG that is 1217 optimized for the Objective Function that was used to build the 1218 DODAG. 1220 ------+--------- 1221 | Internet 1222 | 1223 +-----+ 1224 | | Border Router 1225 | | (RPL Root) 1226 +-----+ 1227 X 1228 ^ v o o 1229 ^ o o v o o o o o 1230 ^ o o o v o o o o o 1231 ^ o o v o o o o o 1232 S o o o D o o o 1233 o o o o 1234 LLN 1236 Figure 9: Routing Stretch between S and D via common parent X 1238 It results that it is often beneficial to enable transversal P2P 1239 routes, either if the RPL route presents a stretch from shortest 1240 path, or if the new route is engineered with a different objective. 1241 For that reason, earlier work at the IETF introduced the "Reactive 1242 Discovery of Point-to-Point Routes in Low Power and Lossy Networks" 1243 [RFC6997], which specifies a distributed method for establishing 1244 optimized P2P routes. This draft proposes an alternate based on a 1245 centralized route computation. 1247 ------+--------- 1248 | Internet 1249 | 1250 +-----+ 1251 | | Border Router 1252 | | (RPL Root) 1253 +-----+ 1254 | 1255 o o o o 1256 o o o o o o o o o 1257 o o o o o o o o o o 1258 o o o o o o o o o 1259 S>>A>>>B>>C>>>D o o o 1260 o o o o 1261 LLN 1263 Figure 10: Projected Transversal Route 1265 This specification enables to store source-routed or storing mode 1266 state in intermediate routers, which enables to limit the stretch of 1267 a P2P route and maintain the characteristics within a given SLA. An 1268 example of service using this mechanism oculd be a control loop that 1269 would be installed in a network that uses classical RPL for 1270 asynchronous data collection. In that case, the P2P path may be 1271 installed in a different RPL Instance, with a different objective 1272 function. 1274 Appendix B. Examples 1276 B.1. Using storing mode P-DAO in non-storing mode MOP 1278 In non-storing mode, the DAG Root maintains the knowledge of the 1279 whole DODAG topology, so when both the source and the destination of 1280 a packet are in the DODAG, the Root can determine the common parent 1281 that would have been used in storing mode, and thus the list of nodes 1282 in the path between the common parent and the destination. For 1283 Instance in the diagram shown in Figure 11, if the source is node 41 1284 and the destination is node 52, then the common parent is node 22. 1286 ------+--------- 1287 | Internet 1288 | 1289 +-----+ 1290 | | Border Router 1291 | | (RPL Root) 1292 +-----+ 1293 | \ \____ 1294 / \ \ 1295 o 11 o 12 o 13 1296 / | / \ 1297 o 22 o 23 o 24 o 25 1298 / \ | \ \ 1299 o 31 o 32 o o o 35 1300 / / | \ | \ 1301 o 41 o 42 o o o 45 o 46 1302 | | | | \ | 1303 o 51 o 52 o 53 o o 55 o 56 1305 LLN 1307 Figure 11: Example DODAG forming a logical tree topology 1309 With this draft, the Root can install a storing mode routing states 1310 along a segment that is either from itself to the destination, or 1311 from one or more common parents for a particular source/destination 1312 pair towards that destination (in this particular example, this would 1313 be the segment made of nodes 22, 32, 42). 1315 In the example below, say that there is a lot of traffic to nodes 55 1316 and 56 and the Root decides to reduce the size of routing headers to 1317 those destinations. The Root can first send a DAO to node 45 1318 indicating Target 55 and a Via segment (35, 45), as well as another 1319 DAO to node 46 indicating Target 56 and a Via segment (35, 46). This 1320 will save one entry in the routing header on both sides. The Root 1321 may then send a DAO to node 35 indicating Targets 55 and 56 a Via 1322 segment (13, 24, 35) to fully optimize that path. 1324 Alternatively, the Root may send a DAO to node 45 indicating Target 1325 55 and a Via segment (13, 24, 35, 45) and then a DAO to node 46 1326 indicating Target 56 and a Via segment (13, 24, 35, 46), indicating 1327 the same DAO Sequence. 1329 B.2. Projecting a storing-mode transversal route 1331 In this example, say that a PCE determines that a path must be 1332 installed between node S and node D via routers A, B and C, in order 1333 to serve the needs of a particular application. 1335 The Root sends a P-DAO with a Target option indicating the 1336 destination D and a sequence Via Information option, one for S, which 1337 is the ingress router of the segment, one for A and then for B, which 1338 are an intermediate routers, and one for C, which is the egress 1339 router. 1341 ------+--------- 1342 | Internet 1343 | 1344 +-----+ 1345 | | Border Router 1346 | | (RPL Root) 1347 +-----+ 1348 | P-DAO message to C 1349 o | o o 1350 o o o | o o o o o 1351 o o o | o o o o o o 1352 o o V o o o o o o 1353 S A B C D o o o 1354 o o o o 1355 LLN 1357 Figure 12: P-DAO from Root 1359 Upon reception of the P-DAO, C validates that it can reach D, e.g. 1360 using IPv6 Neighbor Discovery, and if so, propagates the P-DAO 1361 unchanged to B. 1363 B checks that it can reach C and of so, installs a route towards D 1364 via C. Then it propagates the P-DAO to A. 1366 The process recurses till the P-DAO reaches S, the ingress of the 1367 segment, which installs a route to D via A and sends a DAO-ACK to the 1368 Root. 1370 ------+--------- 1371 | Internet 1372 | 1373 +-----+ 1374 | | Border Router 1375 | | (RPL Root) 1376 +-----+ 1377 ^ P-DAO-ACK from S 1378 / o o o 1379 / o o o o o o o 1380 | o o o o o o o o o 1381 | o o o o o o o o 1382 S A B C D o o o 1383 o o o o 1384 LLN 1386 Figure 13: P-DAO-ACK to Root 1388 As a result, a transversal route is installed that does not need to 1389 follow the DODAG structure. 1391 ------+--------- 1392 | Internet 1393 | 1394 +-----+ 1395 | | Border Router 1396 | | (RPL Root) 1397 +-----+ 1398 | 1399 o o o o 1400 o o o o o o o o o 1401 o o o o o o o o o o 1402 o o o o o o o o o 1403 S>>A>>>B>>C>>>D o o o 1404 o o o o 1405 LLN 1407 Figure 14: Projected Transversal Route 1409 Authors' Addresses 1411 Pascal Thubert (editor) 1412 Cisco Systems, Inc 1413 Building D 1414 45 Allee des Ormes - BP1200 1415 06254 Mougins - Sophia Antipolis 1416 France 1417 Phone: +33 497 23 26 34 1418 Email: pthubert@cisco.com 1420 Rahul Arvind Jadhav 1421 Huawei Tech 1422 Kundalahalli Village, Whitefield, 1423 Bangalore 560037 1424 Karnataka 1425 India 1427 Phone: +91-080-49160700 1428 Email: rahul.ietf@gmail.com 1430 Matthew Gillmore 1431 Itron, Inc 1432 Building D 1433 2111 N Molter Road 1434 Liberty Lake, 99019 1435 United States 1437 Phone: +1.800.635.5461 1438 Email: matthew.gillmore@itron.com