idnits 2.17.00 (12 Aug 2021) /tmp/idnits22687/draft-ietf-roll-dao-projection-14.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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (2 October 2020) is 596 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: draft-ietf-6tisch-architecture has been published as RFC 9030 == Outdated reference: A later version (-09) exists of draft-pthubert-raw-architecture-04 == Outdated reference: draft-ietf-roll-useofrplinfo has been published as RFC 9008 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). 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: 5 April 2021 M. Gillmore 7 Itron 8 2 October 2020 10 Root initiated routing state in RPL 11 draft-ietf-roll-dao-projection-14 13 Abstract 15 This document updates RFC 6550 to enable a RPL Root to install and 16 maintain Projected Routes within its DODAG, along a selected set of 17 nodes that may or may not include self, for a chosen duration. This 18 potentially enables routes that are more optimized or resilient than 19 those obtained with the classical distributed operation of RPL, 20 either in terms of the size of a Routing Header or in terms of path 21 length, which impacts both the latency and the packet delivery ratio. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 5 April 2021. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 59 2.2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.3. Other Terms . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.4. References . . . . . . . . . . . . . . . . . . . . . . . 6 62 3. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 6 63 4. New RPL Control Messages and Options . . . . . . . . . . . . 8 64 4.1. New P-DAO Request Control Message . . . . . . . . . . . . 8 65 4.2. New PDR-ACK Control Message . . . . . . . . . . . . . . . 9 66 4.3. Route Projection Options . . . . . . . . . . . . . . . . 10 67 4.4. Sibling Information Option . . . . . . . . . . . . . . . 12 68 5. Projected DAO . . . . . . . . . . . . . . . . . . . . . . . . 14 69 5.1. Requesting a Track . . . . . . . . . . . . . . . . . . . 15 70 5.2. Identifying a Track . . . . . . . . . . . . . . . . . . . 16 71 5.3. Forwarding Along a Track . . . . . . . . . . . . . . . . 17 72 5.4. Non-Storing Mode Projected Route . . . . . . . . . . . . 18 73 5.5. Storing Mode Projected Route . . . . . . . . . . . . . . 19 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 76 7.1. New RPL Control Codes . . . . . . . . . . . . . . . . . . 21 77 7.2. New RPL Control Message Options . . . . . . . . . . . . . 22 78 7.3. SubRegistry for the Projected DAO Request Flags . . . . . 22 79 7.4. SubRegistry for the PDR-ACK Flags . . . . . . . . . . . . 23 80 7.5. Subregistry for the PDR-ACK Acceptance Status Values . . 23 81 7.6. Subregistry for the PDR-ACK Rejection Status Values . . . 23 82 7.7. SubRegistry for the Route Projection Options Flags . . . 24 83 7.8. SubRegistry for the Sibling Information Option Flags . . 24 84 7.9. Error in Projected Route ICMPv6 Code . . . . . . . . . . 25 85 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 86 9. Normative References . . . . . . . . . . . . . . . . . . . . 25 87 10. Informative References . . . . . . . . . . . . . . . . . . . 26 88 Appendix A. Applications . . . . . . . . . . . . . . . . . . . . 27 89 A.1. Loose Source Routing . . . . . . . . . . . . . . . . . . 27 90 A.2. Transversal Routes . . . . . . . . . . . . . . . . . . . 29 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 93 1. Introduction 95 RPL, the "Routing Protocol for Low Power and Lossy Networks" [RPL] 96 (LLNs), is a generic Distance Vector protocol that is well suited for 97 application in a variety of low energy Internet of Things (IoT) 98 networks. RPL forms Destination Oriented Directed Acyclic Graphs 99 (DODAGs) in which the Root often acts as the Border Router to connect 100 the RPL domain to the Internet. The Root is responsible to select 101 the RPL Instance that is used to forward a packet coming from the 102 Internet into the RPL domain and set the related RPL information in 103 the packets. 6TiSCH uses RPL for its routing operations. 105 The "6TiSCH Architecture" [6TiSCH-ARCHI] also leverages the 106 "Deterministic Networking Architecture" [RFC8655] centralized model 107 whereby the device resources and capabilities are exposed to an 108 external controller which installs routing states into the network 109 based on some objective functions that reside in that external 110 entity. With DetNet and 6TiSCH, the component of the controller that 111 is responsible of computing routes is called a Path Computation 112 Element ([PCE]). 114 Based on heuristics of usage, path length, and knowledge of device 115 capacity and available resources such as battery levels and 116 reservable buffers, the PCE with a global visibility on the system 117 can compute direct Peer to Peer (P2P) routes that are optimized for 118 the needs expressed by an objective function. This document 119 specifies protocol extensions to RPL [RPL] that enable the Root of a 120 main DODAG to install centrally-computed routes inside the DODAG on 121 behalf of a PCE. 123 This specification expects that the main RPL Instance is operated in 124 RPL Non-Storing Mode of Operation (MOP) to sustain the exchanges with 125 the Root. In that Mode, the Root has enough information to build a 126 basic DODAG topology based on parents and children, but lacks the 127 knowledge of siblings. This document adds the capability for nodes 128 to advertise sibling information in order to improve the topological 129 awareness of the Root. 131 As opposed to the classical RPL operations where routes are injected 132 by the Target nodes, the protocol extensions enable the Root of a 133 DODAG to project the routes that are needed onto the nodes where they 134 should be installed. This specification uses the term Projected 135 Route to refer to those routes. Projected Routes can be used to 136 reduce the size of the source routing headers with loose source 137 routing operations down the main RPL DODAG. Projected Routes can 138 also be used to build transversal routes for route optimization and 139 Traffic Engineering purposes, between nodes of the DODAG. 141 A Projected Route may be installed in either Storing and Non-Storing 142 Mode, potentially resulting in hybrid situations where the Mode of 143 the Projected Route is different from that of the main RPL Instance. 144 A Projected Route may be a stand-alone end-to-end path or a Segment 145 in a more complex forwarding graph called a Track. 147 The concept of a Track was introduced in the 6TiSCH architecture, as 148 a potentially complex path with redundant forwarding solutions along 149 the way. A node at the ingress of more than one Segment in a Track 150 may use any combination of those Segments to forward a packet towards 151 the Track Egress. 153 The "Reliable and Available Wireless (RAW) Architecture/Framework" 154 [RAW-ARCHI] defines the Path Selection Engine (PSE) that adapts the 155 use of the path redundancy within a Track to defeat the diverse 156 causes of packet loss. 158 The PSE is a dataplane extension of the PCE; it controls the 159 forwarding operation of the packets within a Track, using Packet ARQ, 160 Replication, Elimination, and Overhearing (PAREO) functions over the 161 Track segments, to provide a dynamic balance between the reliability 162 and availability requirements of the flows and the need to conserve 163 energy and spectrum. 165 The time scale at which the PCE (re)computes the Track can be long, 166 using long-term statistical metrics to perform global optimizations 167 at the scale of the whole network. Conversely, the PSE makes 168 forwarding decisions at the time scale of one or a small collection 169 of packets, based on a knowledge that is limited in scope to the 170 Track itself, so it can be refreshed at a fast pace. 172 Projected Routes must be used with the parsimony to limit the amount 173 of state that is installed in each device to fit within the device 174 resources, and to maintain the amount of rerouted traffic within the 175 capabilities of the transmission links. The methods used to learn 176 the node capabilities and the resources that are available in the 177 devices and in the network are out of scope for this document. 179 This specification uses the RPL Root as a proxy to the PCE. The PCE 180 may be collocated with the Root, or may reside in an external 181 Controller. 183 In that case, the PCE exchanges control messages with the Root over a 184 Southbound API that is out of scope for this specification. The 185 algorithm to compute the paths and the protocol used by an external 186 PCE to obtain the topology of the network from the Root are also out 187 of scope. 189 2. Terminology 191 2.1. Requirements Language 193 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 194 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 195 "OPTIONAL" in this document are to be interpreted as described in BCP 196 14 [RFC2119][RFC8174] when, and only when, they appear in all 197 capitals, as shown here. 199 2.2. Glossary 201 This document often uses the following acronyms: 203 CMO: Control Message Option 204 DAO: Destination Advertisement Object 205 DAG: Directed Acyclic Graph 206 DODAG: Destination-Oriented Directed Acyclic Graph; A DAG with only 207 one vertex (i.e., node) that has no outgoing edge (i.e., link) 208 LLN: Low-Power and Lossy Network 209 NMPR: Non-Storing Mode Projected Route 210 MOP: RPL Mode of Operation 211 P-DAO: Projected DAO 212 PDR: P-DAO Request 213 RAN: RPL-Aware Node (either a RPL Router or a RPL-Aware Leaf) 214 RAL: RPL-Aware Leaf 215 RH: Routing Header 216 RPI: RPL Packet Information 217 RPO: A Route Projection Option; it can be a VIO or an SRVIO. 218 RTO: RPL Target Option 219 RUL: RPL-Unaware Leaf 220 SIO: RPL Sibling Information Option 221 SRVIO: A Source-Routed Via Information Option, used in Non-Storing 222 Mode P-DAO messages. 223 SMPR: Storing Mode Projected Route 224 TIO: RPL Transit Information Option 225 VIO: A Via Information Option, used in Storing Mode P-DAO messages. 227 2.3. Other Terms 229 Projected Route: A Projected Route is a path segment that is 230 computed remotely, and installed and maintained by a RPL Root. 231 Projected DAO: A DAO message used to install a Projected Route. 232 Track: A complex path with redundant Segments to a destination. 233 TrackID: A RPL Local InstanceID with the 'D' bit set. The TrackID 234 is associated with a IPv6 Address to the Track Egress Node. 236 2.4. References 238 In this document, readers will encounter terms and concepts that are 239 discussed in the "Routing Protocol for Low Power and Lossy Networks" 240 [RPL] and "Terminology in Low power And Lossy Networks" [RFC7102]. 242 3. Updating RFC 6550 244 Section 6 of [RPL] introduces the RPL Control Message Options (CMO), 245 including the RPL Target Option (RTO) and Transit Information Option 246 (TIO), which can be placed in RPL messages such as the Destination 247 Advertisement Object (DAO). This specification extends the DAO 248 message with the Projected DAO (P-DAO); a P-DAO message signals one 249 or more Projected Route(s) using the new CMOs presented therein. 251 A Projected Route can be an additional route of higher precedence 252 within the main DODAG. In that case, it is installed with a P-DAO 253 using the parameters of the main DODAG, typically a global 254 RPLInstanceID and the DODAGID field elided as shown in Section 6.4.1. 255 of [RPL]. 257 A Projected Route can also be a Segment within a Track. A stand- 258 alone Segment can be used as a Serial Track. Segments can also be 259 combined to form a Complex Track. The Root uses a local RPL Instance 260 rooted at the Track Egress to signal the Track. The local 261 RPLInstanceID of the Track is called the TrackID, more in 262 Section 5.2. A P-DAO message for a Track signals the IPv6 Address of 263 the Track Egress in the DODAGID field of the DAO Base Object, and the 264 TrackID in the RPLInstanceID field, as shown in Figure 1. 266 0 1 2 3 267 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 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | TrackID |K|D| Flags | Reserved | DAOSequence | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | | 272 + + 273 | | 274 + IPv6 Address of the Track Egress + 275 | | 276 + + 277 | | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Option(s)... 280 +-+-+-+-+-+-+-+-+ 282 Figure 1: Projected DAO Format for a Track 284 In RPL Non-Storing Mode, the TIO and RTO are combined in a DAO 285 message to inform the DODAG Root of all the edges in the DODAG, which 286 are formed by the directed parent-child relationships. Options may 287 be factorized; multiple RTOs may be present to signal a collection of 288 children that can be reached via the parent(s) indicated in the 289 TIO(s) that follows the RTOs. This specification generalizes the 290 case of a parent that can be used to reach a child with that of a 291 whole Track through which both children and siblings of the Track 292 Egress are reachable. 294 New CMOs called the Route Projection Options (RPO) are introduced for 295 use in P-DAO messages as a multihop alternative to the TIO. One RPO 296 is the Via Information Option (VIO); the VIO installs a state at each 297 hop along a Storing Mode Projected Route (SMPR). The other is the 298 Source-Routed VIO (SRVIO); the SRVIO installs a source-routing state 299 at the Segment ingress, which uses that state to encapsulate a packet 300 with a Routing Header (RH) along a Non-Storing Mode Projected Route 301 (NMPR). 303 Like in a DAO message, the RTOs can be factorized in a P-DAO, but the 304 RPOs cannot. A P-DAO contains one or more RTOs that indicate the 305 destinations that can be reached via the Track, and exactly one RPO 306 that signals the sequence of nodes between the Track Ingress and the 307 Track Egress, both included. In Non-Storing Mode, the Root sends the 308 P-DAO to the Track Ingress where the source-routing state is stored. 309 In Storing Mode, the P-DAO is sent to the Track Egress and forwarded 310 along the Segment in the reverse direction, installing a Storing Mode 311 state at each hop. In both cases the Track Ingress generates the P- 312 DAO-ACK when the installation is successful. 314 This specification adds another CMO called the Sibling Information 315 Option (SIO) that is used by a RPL Aware Node (RAN) to advertise a 316 selection of its candidate neighbors as siblings to the Root, more in 317 Section 4.4. The sibling selection process is out of scope. 319 Two new RPL Control Messages are also introduced, to enable a RAN to 320 request the establishment of a Track between self as the Track 321 Ingress Node and a Track Egress. The RAN makes its request by 322 sending a new P-DAO Request (PDR) Message to the Root. The Root 323 confirms with a new PDR-ACK message back to the requester RAN, see 324 Section 4.1 for more. A positive PDR-ACK indicates that the Track 325 was built and that the Roots commits to maintain the Track for the 326 negotiated lifetime. In the case of a complex Track, each Segment is 327 maintained independently and asynchronously by the Root, with its own 328 lifetime that may be shorter, the same, or longer than that of the 329 Track. The Root may use an asynchronous PDR-ACK with an negative 330 status to indicate that the Track was terminated before its time. 332 4. New RPL Control Messages and Options 334 4.1. New P-DAO Request Control Message 336 The P-DAO Request (PDR) message is sent by a Node in the main DODAG 337 to the Root. It is a request to establish or refresh a Track. 338 Exactly one RTO MUST be present in a PDR. The RTO signals the Track 339 Egress, more in Section 5.1. 341 The RPL Control Code for the PDR is 0x09, to be confirmed by IANA. 342 The format of PDR Base Object is as follows: 344 0 1 2 3 345 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 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | TrackID |K|R| Flags | ReqLifetime | PDRSequence | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Option(s)... 350 +-+-+-+-+-+-+-+-+ 352 Figure 2: New P-DAO Request Format 354 TrackID: 8-bit field indicating the RPLInstanceID associated with 355 the Track. It is set to zero upon the first request for a new 356 Track and then to the TrackID once the Track was created, to 357 either renew it of destroy it. 359 K: The 'K' flag is set to indicate that the recipient is expected to 360 send a PDR-ACK back. 362 R: The 'R' flag is set to request a Complex Track for redundancy. 364 Flags: Reserved. The Flags field MUST initialized to zero by the 365 sender and MUST be ignored by the receiver 367 ReqLifetime: 8-bit unsigned integer. The requested lifetime for the 368 Track expressed in Lifetime Units (obtained from the DODAG 369 Configuration option). 371 A PDR with a fresher PDRSequence refreshes the lifetime, and a 372 PDRLifetime of 0 indicates that the track should be destroyed. 374 PDRSequence: 8-bit wrapping sequence number, obeying the operation 375 in section 7.2 of [RPL]. The PDRSequence is used to correlate a 376 PDR-ACK message with the PDR message that triggered it. It is 377 incremented at each PDR message and echoed in the PDR-ACK by the 378 Root. 380 4.2. New PDR-ACK Control Message 382 The new PDR-ACK is sent as a response to a PDR message with the 'K' 383 flag set. The RPL Control Code for the PDR-ACK is 0x0A, to be 384 confirmed by IANA. Its format is as follows: 386 0 1 2 3 387 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 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | TrackID | Flags | Track Lifetime| PDRSequence | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | PDR-ACK Status| Reserved | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Option(s)... 394 +-+-+-+-+-+-+-+ 396 Figure 3: New PDR-ACK Control Message Format 398 TrackID: The RPLInstanceID of the Track that was created. The value 399 of 0x00 is used to when no Track was created. 401 Flags: Reserved. The Flags field MUST initialized to zero by the 402 sender and MUST be ignored by the receiver 404 Track Lifetime: Indicates that remaining Lifetime for the Track, 405 expressed in Lifetime Units; the value of zero (0x00) indicates 406 that the Track was destroyed or not created. 408 PDRSequence: 8-bit wrapping sequence number. It is incremented at 409 each PDR message and echoed in the PDR-ACK. 411 PDR-ACK Status: 8-bit field indicating the completion. The PDR-ACK 412 Status is substructured as indicated in Figure 4: 414 0 1 2 3 4 5 6 7 415 +-+-+-+-+-+-+-+-+ 416 |E|R| Value | 417 +-+-+-+-+-+-+-+-+ 419 Figure 4: PDR-ACK status Format 421 E: 1-bit flag. Set to indicate a rejection. When not set, the 422 value of 0 indicates Success/Unqualified acceptance and other 423 values indicate "not an outright rejection". 424 R: 1-bit flag. Reserved, MUST be set to 0 by the sender and 425 ignored by the receiver. 426 Status Value: 6-bit unsigned integer. Values depending on the 427 setting of the 'E' flag, see Table 4 and Table 5. 429 Reserved: The Reserved field MUST initialized to zero by the sender 430 and MUST be ignored by the receiver 432 4.3. Route Projection Options 434 An RPO signals the ordered list of IPv6 Via Addresses that 435 constitutes the hops of either a Serial Track or a Segment of a more 436 Complex Track. An RPO MUST contain at least one Via Address, and a 437 Via Address MUST NOT be present more than once, otherwise the RPO 438 MUST be ignored. The format of the RPOs is as follows: 440 0 1 2 3 441 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 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Type | Option Length | Flags | SegmentID | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 |Segm. Sequence | Seg. Lifetime | SRH-6LoRH header | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | | 448 + + 449 . . 450 . Via Address 1 . 451 . . 452 + + 453 | | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | | 456 . .... . 457 | | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | | 460 + + 461 . . 462 . Via Address n . 463 . . 464 + + 465 | | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 Figure 5: Route Projection Option format (uncompressed form) 470 Option Type: 0x0B for VIO, 0x0C for SRVIO (to be confirmed by IANA) 472 Option Length: In bytes; variable, depending on the number of Via 473 Addresses and the compression. 475 SegmentID: 8-bit field that identifies a Segment within a Track or 476 the main DODAG as indicated by the TrackID field. The value of 0 477 is used to signal a Serial Track, i.e., made of a single segment. 479 Segment Sequence: 8-bit unsigned integer. The Segment Sequence 480 obeys the operation in section 7.2 of [RPL] and the lollipop 481 starts at 255. 483 When the Root of the DODAG needs to refresh or update a Segment in 484 a Track, it increments the Segment Sequence individually for that 485 Segment. 487 The Segment information indicated in the RPO deprecates any state 488 for the Segment indicated by the SegmentID within the indicated 489 Track and sets up the new information. 491 An RPO with a Segment Sequence that is not as fresh as the current 492 one is ignored. 494 An RPO for a given Track Egress with the same (TrackID, SegmentID, 495 Segment Sequence) indicates a retry; it MUST NOT change the 496 Segment and MUST be propagated or answered as the first copy. 498 Segment Lifetime: 8-bit unsigned integer. The length of time in 499 Lifetime Units (obtained from the Configuration option) that the 500 Segment is usable. 502 The period starts when a new Segment Sequence is seen. The value 503 of 255 (0xFF) represents infinity. The value of zero (0x00) 504 indicates a loss of reachability. 506 A P-DAO message that contains a Via Information option with a 507 Segment Lifetime of zero for a Track Egress is referred as a No- 508 Path (for that Track Egress) in this document. 510 SRH-6LoRH header: The first 2 bytes of the (first) SRH-6LoRH as 511 shown in Figure 6 of [RFC8138]. A 6LoRH Type of 4 means that the 512 VIA Addresses are provided in full with no compression. 514 Via Address: An IPv6 addresse along the Segment. 516 In a VIO, the list is a strict path between direct neighbors, 517 whereas for an SRVIO, the list may be loose, provided that each 518 listed node has a path to the next listed node, e.g., via another 519 Track. 521 In the case of a SMPR, or if [RFC8138] is not used in the data 522 packets, then the Root MUST use only one SRH-6LoRH per RPO, and 523 the compression is the same for all the addresses, as shown in 524 Figure 5. 526 In case of a NMPR, and if [RFC8138] is in use in the main DODAG, 527 then the Root SHOULD optimize the size of the SRVIO; more than one 528 SRH-6LoRH may be present, e.g., if the compression level changes 529 inside the Segment and different SRH-6LoRH Types are required. 531 4.4. Sibling Information Option 533 The Sibling Information Option (SIO) provides indication on siblings 534 that could be used by the Root to form Projected Routes. One or more 535 SIO(s) may be placed in the DAO messages that are sent to the Root in 536 Non-Storing Mode. 538 The format of the SIO is as follows: 540 0 1 2 3 541 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 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Type | Option Length |Comp.|B|D|Flags| Opaque | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | Step of Rank | Reserved | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | | 548 + + 549 . . 550 . Sibling DODAGID (if 'D' flag not set) . 551 . . 552 + + 553 | | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | | 556 + + 557 . . 558 . Sibling Address . 559 . . 560 + + 561 | | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 Figure 6: Sibling Information Option Format 566 Option Type: 0x0D (to be confirmed by IANA) 568 Option Length: In bytes, the size of the option. 570 Compression Type: 3-bit unsigned integer. This is the SRH-6LoRH 571 Type as defined in figure 7 in section 5.1 of [RFC8138] that 572 corresponds to the compression used for the Sibling Address and 573 its DODAGID if resent. The Compression refernce is the Root of 574 the main DODAG. 576 Reserved for Flags: MUST be set to zero by the sender and MUST be 577 ignored by the receiver. 579 B: 1-bit flag that is set to indicate that the connectivity to the 580 sibling is bidirectional and roughly symmetrical. In that case, 581 only one of the siblings may report the SIO for the hop. If 'B' 582 is not set then the SIO only indicates connectivity from the 583 sibling to this node, and does not provide information on the hop 584 from this node to the sibling. 586 D: 1-bit flag that is set to indicate that sibling belongs to the 587 same DODAG. When not set, the Sibling DODAGID is indicated. 589 Flags: Reserved. The Flags field MUST initialized to zero by the 590 sender and MUST be ignored by the receiver 592 Opaque: MAY be used to carry information that the node and the Root 593 understand, e.g., a particular representation of the Link 594 properties such as a proprietary Link Quality Information for 595 packets received from the sibling. An industrial Alliance that 596 uses RPL for a particular use / environment MAY redefine the use 597 of this field to fit its needs. 599 Step of Rank: 16-bit unsigned integer. This is the Step of Rank 600 [RPL] as computed by the Objective Function between this node and 601 the sibling. 603 Reserved: The Reserved field MUST initialized to zero by the sender 604 and MUST be ignored by the receiver 606 Sibling DODAGID: 2 to 16 bytes, the DODAGID of the sibling in a 607 [RFC8138] compressed form as indicated by the Compression Type 608 field. This field is present when the 'D' flag is not set. 610 Sibling Address: 2 to 16 bytes, the IPv6 Address of the sibling in a 611 [RFC8138] compressed form as indicated by the Compression Type 612 field. 614 An SIO MAY be immediately followed by a DAG Metric Container. In 615 that case the DAG Metric Container provides additional metrics for 616 the hop from the Sibling to this node. 618 5. Projected DAO 620 This draft adds a capability to RPL whereby the Root of a DODAG 621 projects a Track by sending one or more Projected-DAO (P-DAO) 622 messages to selected routers in the DODAG. The P-DAO signals a 623 collection of Targets in the RPL Target Option(s) (RTO). Those 624 Targets can be reached via a sequence of routers indicated in a Route 625 Projection Option (RPO). A P-DAO message MUST contain exactly one 626 RPO, which is either a VIO or an SRVIO, and MUST follow one or more 627 RTOs. There can be at most one such sequence of RTO(s) and an RPO. 629 A P-DAO MUST be sent from the address of the Root that serves as 630 DODAGID for the main DODAG. It MUST be sent to a GUA or a ULA of 631 either the ingress or the egress of the Segment, more below. If the 632 'K' Flag is present in the P-DAO, and unless the P-DAO does not reach 633 it, the ingress of the Segment is the node that acknowledges the 634 message, using a DAO-ACK that MUST be sent back to the address that 635 serves as DODAGID for the main DODAG. 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 Segment 640 Sequence information from the RPO as opposed to the Path Sequence 641 from a TIO. Also, a Segment Lifetime of 0 in an RPO indicates that 642 the projected route associated to the Segment 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 5.4. A Non-Storing 648 Mode P-DAO carries an SRVIO with the loose list of Via Addresses 649 that forms a source-routed Segment to the Track Egress. The 650 recipient of the P-DAO is the ingress router of the source-routed 651 Segment. The ingress router MUST install a source-routed state to 652 the Track Egress and reply to the Root directly using a DAO-ACK 653 message if requested to. 655 * The Storing Mode is discussed in Section 5.5. A Storing Mode 656 P-DAO carries a VIO with the strict list of Via Addresses from the 657 ingress to the egress of the Segment in the data path order. The 658 routers listed in the Via Addresses, except the egress, MUST 659 install a routing state to the Target(s) via the next Via Address 660 in the VIO. In normal operations, the P-DAO is propagated along 661 the chain of Via Routers from the egress router of the path till 662 the ingress one, which confirms the installation to the Root with 663 a DAO-ACK message. Note that the Root may be the ingress and it 664 may be the egress of the Segment, that it can also be neither but 665 it cannot be both. 667 In case of a forwarding error along a Projected Route, an ICMP error 668 is sent to the Root with a new Code "Error in Projected Route" (See 669 Section 7.9). The Root can then modify or remove the Projected 670 Route. The "Error in Projected Route" message has the same format as 671 the "Destination Unreachable Message", as specified in RFC 4443 672 [RFC4443]. 674 The portion of the invoking packet that is sent back in the ICMP 675 message SHOULD record at least up to the RH if one is present, and 676 this hop of the RH SHOULD be consumed by this node so that the 677 destination in the IPv6 header is the next hop that this node could 678 not reach. if a 6LoWPAN Routing Header (6LoRH) [RFC8138] is used to 679 carry the IPv6 routing information in the outer header then that 680 whole 6LoRH information SHOULD be present in the ICMP message. 682 The sender and exact operation depend on the Mode and is described in 683 Section 5.4 and Section 5.5 respectively. 685 5.1. Requesting a Track 687 A Node is free to ask the Root for a new Track at any time. This is 688 done with a PDR message, that indicates in the Requested Lifetime 689 field the duration for which the Track should be established. Upon a 690 PDR, the Root MAY install the necessary Segments, in which case it 691 answers with a PDR-ACK indicating the granted Track Lifetime. All 692 the Segments MUST be of a same mode, either Storing or Non-Storing. 693 All the Segments MUST be created with the same TrackID and the same 694 Track Egress signaled in the P-DAO. 696 The Root is free to design the Track as it wishes, and to change the 697 Segments overtime to serve the Track as needed, without notifying the 698 resquesting Node. The Segment Lifetime in the P-DAO messages does 699 not need to be aligned to the Requested Lifetime in the PDR, or 700 between P-DAO messages for different Segments. The Root may use 701 shorter lifetimes for the Segments and renew them faster than the 702 Track is, or longer lifetimes in which case it will need to tear down 703 the Segments if the Track is not renewed. 705 When the Track Lifetime that was returned in the PDR-ACK is close to 706 elapse, the resquesting Node needs to resend a PDR using the TrackID 707 in the PDR-ACK to extend the lifetime of the Track, else the Track 708 will time out and the Root will tear down the whole structure. 710 If the Track fails and cannot be restored, the Root notifies the 711 resquesting Node asynchronously with a PDR-ACK with a Track Lifetime 712 of 0, indicating that the Track has failed, and a PDR-ACK Status 713 indicating the reason of the fault. 715 5.2. Identifying a Track 717 RPL defines the concept of an Instance to signal an individual 718 routing topology but does not have a concept of an administrative 719 distance, which exists in certain proprietary implementations to sort 720 out conflicts between multiple sources of routing information within 721 one routing topology. 723 This draft leverages the RPL Instance model as follows: 725 * The Root MAY use P-DAO messages to add better routes in the main 726 (Global) Instance in conformance with the routing objectives in 727 that Instance. To achieve this, the Root MAY install an SMPR 728 along a path down the main Non-Storing Mode DODAG. This enables a 729 loose source routing and reduces the size of the Routing Header, 730 see Appendix A.1. 732 When adding an SMPR to the main RPL Instance, the Root MUST set 733 the RPLInstanceID field of the P-DAO message (see section 6.4.1. 734 of [RPL]) to the RPLInstanceID of the main DODAG, and MUST NOT use 735 the DODAGID field. A Projected Route provides a longer match to 736 the Target Address than the default route via the Root, so it is 737 preferred. 739 Once the Projected Route is installed, the intermediate nodes 740 listed in the VIO after first one (i.e. The ingress) can be 741 elided from the RH in packets sent along the Segment signaled in 742 the P-DAO. The resulting loose source routing header indicates 743 (one of) the Target(s) as the next entry after the ingress. 745 * The Root MAY also use P-DAO messages to install a specific (say, 746 Traffic Engineered) path as a Serial or as a Complex Track, to a 747 particular endpoint that is the Track Egress. In that case, the 748 Root MUST install a Local RPL Instance (see section 5 of [RPL]). 750 In a that case, the TrackID MUST be unique for the Global Unique 751 IPv6 Address (GUA) or Unique-Local Address (ULA) of the Track 752 Egress that serves as DODAGID for the Track. This way, a Track is 753 uniquely identified by the tuple (Track Egress Address, TrackID) 754 where the TrackID is always represented with the 'D' flag set. 756 The Track Egress Address and the TrackID MUST be signaled in the 757 P-DAO message as shown in Figure 1. 759 5.3. Forwarding Along a Track 761 Sending a Packet within a RPL Local Instance requires the presence of 762 an RPL Packet Information (RPI) (see [USEofRPLinfo]) in the outer 763 IPv6 Header chain. The RPI carries a local RPLInstanceID which, in 764 association with the IPv6 final destination, indicates the RPL 765 Instance that the packet follows. 767 This draft leverages the RPL Forwarding model follows: 769 * The RPI carries a local RPLInstanceID called the TrackID, which, 770 in association with the IPv6 final destination, indicates the 771 Track along which the packet is forwarded. The 'D' flag in the 772 RPLInstanceID MUST be set to indicate that the final destination 773 address in the IPv6 header owns the local RPLInstanceID, more in 774 Section 5.3. 776 In the data packets, the Track Egress Address and the TrackID MUST 777 be respectively signaled as the IPv6 Address of the final 778 destination and the RPLInstanceID field of the RPI that MUST be 779 placed in the outer chain of IPv6 Headers. 781 In case of a NMPR, the outer chain of IPv6 Headers contains an 782 IPv6 RH as well. If it is not fully consumed, then the final 783 destination is the last entry in the RH; else it is the 784 Destination Address in the IPv6 Header. When using the [RFC8138] 785 compression, it is the last hop of the last SRH-6LoRH of the outer 786 header in either case. 788 * If the Track Ingress is the originator of the packet and the Track 789 Egress is the destination of the packet, there is no need for an 790 encapsulation. Else, i.e., if the Track Ingress is forwarding a 791 packet into the Track, or if the the final destination is reached 792 over the Track via the Track Egress but is located beyond it, then 793 an IP-in-IP encapsulation is needed. 795 A packet that is being routed over the RPL Instance associated to 796 a first Non-Storing Mode Track MAY be placed (encapsulated) in a 797 second Track to cover one loose hop of the first Track. On the 798 other hand, a Storing Mode Track must be strict and a packet that 799 it placed in a Storing Mode Track MUST follow that Track till the 800 Track Egress. 802 When a Track Egress extracts a packet from a Track (decapsulates 803 the packet), the Destination of the inner packet MUST be either 804 this node or a direct neighbor, or a Target of another Segment of 805 the same Track for which this node is ingress, otherwise the 806 packet MUST be dropped. 808 All properties of a Track operations are inherited form the main RPL 809 Instance that is used to install the Track. For instance, the use of 810 compression per [RFC8138] is determined by whether it is used in the 811 main instance, e.g., by setting the "T" flag [TURN-ON_RFC8138] in the 812 RPL configuration option. 814 5.4. Non-Storing Mode Projected Route 816 As illustrated in Figure 7, a P-DAO that carries an SRVIO enables the 817 Root to install a source-routed path towards a Track Egress in any 818 particular router. 820 ------+--------- 821 | Internet 822 | 823 +-----+ 824 | | Border Router 825 | | (RPL Root) 826 +-----+ | P ^ ACK 827 | Track | DAO | 828 o o o o Ingress X V | X 829 o o o o o o o X o X Source 830 o o o o o o o o X o o X Routed 831 o o ° o o o o X o X Segment 832 o o o o o o o o X Track X 833 o o o o o Egress 835 o o o o 836 o o o o 837 destination 839 LLN 841 Figure 7: Projecting a Non-Storing Route 843 A route indicated by an SRVIO may be loose, meaning that the node 844 that owns the next listed Via Address is not necessarily a neighbor. 845 Without proper loop avoidance mechanisms, the interaction of loose 846 source routing and other mechanisms may effectively cause loops. 848 When forwarding a packet to a destination for which the router 849 determines that routing happens via the Track Egress, the router 850 inserts the source routing header in the packet with the destination 851 set to the Track Egress. 853 In order to signal the Segment, the router encapsulates the packet 854 with an IP-in-IP header and a Routing Header as follows: 856 * In the uncompressed form the source of the packet is this router, 857 the destination is the first Via Address in the SRVIO, and the RH 858 is a Source Routing Header (SRH) [RFC6554] that contains the list 859 of the remaining Via Addresses terminating by the Track Egress. 861 * The preferred alternate in a network where 6LoWPAN Header 862 Compression [RFC6282] is used is to leverage "IPv6 over Low-Power 863 Wireless Personal Area Network (6LoWPAN) Paging Dispatch" 864 [RFC8025] to compress the RPL artifacts as indicated in [RFC8138]. 866 In that case, the source routed header is the exact copy of the 867 (chain of) SRH-6LoRH found in the SRVIO, also terminating by the 868 Track Egress. The RPI-6LoRH is appended next, followed by an IP- 869 in-IP 6LoRH Header that indicates the Ingress Router in the 870 Encapsulator Address field, see as a similar case Figure 20 of 871 [TURN-ON_RFC8138]. 873 In the case of a loose source-routed path, there MUST be either a 874 neighbor that is adjacent to the loose next hop, on which case the 875 packet is forwarded to that neighbor, or another Track to the loose 876 next hop for which this node is Ingress; in the latter case, another 877 encapsulation takes place and the process possibly recurses; 878 otherwise the packet is dropped. 880 In case of a forwarding error along a Source Route path, the node 881 that fails to forward SHOULD send an ICMP error with a code "Error in 882 Source Routing Header" back to the source of the packet, as described 883 in section 11.2.2.3. of [RPL]. Upon this message, the encapsulating 884 node SHOULD stop using the source route path for a period of time and 885 it SHOULD send an ICMP message with a Code "Error in Projected Route" 886 to the Root. Failure to follow these steps may result in packet loss 887 and wasted resources along the source route path that is broken. 889 5.5. Storing Mode Projected Route 891 As illustrated in Figure 8, a P-DAO that carries a VIO enables the 892 Root to install a stateful route towards a collection of Targets 893 along a Segment between a Track Ingress and a Track Egress. 895 ------+--------- 896 | Internet 897 | 898 +-----+ 899 | | Border Router 900 | | (RPL Root) 901 +-----+ | ^ | 902 | | DAO | ACK | 903 o o o o | | | 904 o o o o o o o o o | ^ | Projected . 905 o o o o o o o o o o | | DAO | Route . 906 o o o o o o o o o | ^ | . 907 o o o o o o o o v | DAO v . 908 o o LLN o o o | 909 o o o o o Loose Source Route Path | 910 o o o o From Root To Destination v 912 Figure 8: Projecting a route 914 In order to install the relevant routing state along the Segment , 915 the Root sends a unicast P-DAO message to the Track Egress router of 916 the routing Segment that is being installed. The P-DAO message 917 contains a VIO with the direct sequence of Via Addresses. The VIO 918 follows one or more RTOs indicating the Targets to which the Track 919 leads. The VIO contains a Segment Lifetime for which the state is to 920 be maintained. 922 The Root sends the P-DAO directly to the egress node of the Segment. 923 In that P-DAO, the destination IP address matches the last Via 924 Address in the VIO. This is how the egress recognizes its role. In 925 a similar fashion, the ingress node recognizes its role as it matches 926 first Via Address in the VIO. 928 The Egress node of the Segment is the only node in the path that does 929 not install a route in response to the P-DAO; it is expected to be 930 already able to route to the Target(s) on its own. If one of the 931 Targets is not known, the node MUST answer to the Root with a 932 negative DAO-ACK listing the Target(s) that could not be located 933 (suggested status 10 to be confirmed by IANA). 935 If the egress node can reach all the Targets, then it forwards the 936 P-DAO with unchanged content to its loose predecessor in the Segment 937 as indicated in the list of Via Information options, and recursively 938 the message is propagated unchanged along the sequence of routers 939 indicated in the P-DAO, but in the reverse order, from egress to 940 ingress. 942 The address of the predecessor to be used as destination of the 943 propagated DAO message is found in the Via Address the precedes the 944 one that contain the address of the propagating node, which is used 945 as source of the message. 947 Upon receiving a propagated DAO, all except the Egress Router MUST 948 install a route towards the DAO Target(s) via their successor in the 949 VIO. The router MAY install additional routes towards the VIA 950 Addresses that are the VIO after the next one, if any, but in case of 951 a conflict or a lack of resource, the route(s) to the Target(s) have 952 precedence. 954 If a router cannot reach its predecessor in the VIO, the router MUST 955 answer to the Root with a negative DAO-ACK indicating the successor 956 that is unreachable (suggested status 11 to be confirmed by IANA). 958 The process continues till the P-DAO is propagated to ingress router 959 of the Segment, which answers with a DAO-ACK to the Root. 961 A Segment Lifetime of 0 in a Via Information option is used to clean 962 up the state. The P-DAO is forwarded as described above, but the DAO 963 is interpreted as a No-Path DAO and results in cleaning up existing 964 state as opposed to refreshing an existing one or installing a new 965 one. 967 In case of a forwarding error along an SMPR, the node that fails to 968 forward SHOULD send an ICMP error with a code "Error in Projected 969 Route" to the Root. Failure to do so may result in packet loss and 970 wasted resources along the Projected Route that is broken. 972 6. Security Considerations 974 This draft uses messages that are already present in RPL [RPL] with 975 optional secured versions. The same secured versions may be used 976 with this draft, and whatever security is deployed for a given 977 network also applies to the flows in this draft. 979 TODO: should probably consider how P-DAO messages could be abused by 980 a) rogue nodes b) via replay of messages c) if use of P-DAO messages 981 could in fact deal with any threats? 983 7. IANA Considerations 985 7.1. New RPL Control Codes 987 This document extends the IANA Subregistry created by RFC 6550 for 988 RPL Control Codes as indicated in Table 1: 990 +======+=============================+===============+ 991 | Code | Description | Reference | 992 +======+=============================+===============+ 993 | 0x09 | Projected DAO Request (PDR) | This document | 994 +------+-----------------------------+---------------+ 995 | 0x0A | PDR-ACK | This document | 996 +------+-----------------------------+---------------+ 998 Table 1: New RPL Control Codes 1000 7.2. New RPL Control Message Options 1002 This document extends the IANA Subregistry created by RFC 6550 for 1003 RPL Control Message Options as indicated in Table 2: 1005 +=======+======================================+===============+ 1006 | Value | Meaning | Reference | 1007 +=======+======================================+===============+ 1008 | 0x0B | Via Information option | This document | 1009 +-------+--------------------------------------+---------------+ 1010 | 0x0C | Source-Routed Via Information option | This document | 1011 +-------+--------------------------------------+---------------+ 1012 | 0x0D | Sibling Information option | This document | 1013 +-------+--------------------------------------+---------------+ 1015 Table 2: RPL Control Message Options 1017 7.3. SubRegistry for the Projected DAO Request Flags 1019 IANA is required to create a registry for the 8-bit Projected DAO 1020 Request (PDR) Flags field. Each bit is tracked with the following 1021 qualities: 1023 * Bit number (counting from bit 0 as the most significant bit) 1025 * Capability description 1027 * Reference 1029 Registration procedure is "Standards Action" [RFC8126]. The initial 1030 allocation is as indicated in Table 3: 1032 +============+========================+===============+ 1033 | Bit number | Capability description | Reference | 1034 +============+========================+===============+ 1035 | 0 | PDR-ACK request (K) | This document | 1036 +------------+------------------------+---------------+ 1037 | 1 | Requested path should | This document | 1038 | | be redundant (R) | | 1039 +------------+------------------------+---------------+ 1041 Table 3: Initial PDR Flags 1043 7.4. SubRegistry for the PDR-ACK Flags 1045 IANA is required to create an subregistry for the 8-bit PDR-ACK Flags 1046 field. Each bit is tracked with the following qualities: 1048 * Bit number (counting from bit 0 as the most significant bit) 1050 * Capability description 1052 * Reference 1054 Registration procedure is "Standards Action" [RFC8126]. No bit is 1055 currently defined for the PDR-ACK Flags. 1057 7.5. Subregistry for the PDR-ACK Acceptance Status Values 1059 IANA is requested to create a Subregistry for the PDR-ACK Acceptance 1060 Status values. 1062 * Possible values are 6-bit unsigned integers (0..63). 1064 * Registration procedure is "Standards Action" [RFC8126]. 1066 * Initial allocation is as indicated in Table 4: 1068 +-------+------------------------+---------------+ 1069 | Value | Meaning | Reference | 1070 +-------+------------------------+---------------+ 1071 | 0 | Unqualified acceptance | This document | 1072 +-------+------------------------+---------------+ 1074 Table 4: Acceptance values of the PDR-ACK Status 1076 7.6. Subregistry for the PDR-ACK Rejection Status Values 1078 IANA is requested to create a Subregistry for the PDR-ACK Rejection 1079 Status values. 1081 * Possible values are 6-bit unsigned integers (0..63). 1083 * Registration procedure is "Standards Action" [RFC8126]. 1085 * Initial allocation is as indicated in Table 5: 1087 +-------+-----------------------+---------------+ 1088 | Value | Meaning | Reference | 1089 +-------+-----------------------+---------------+ 1090 | 0 | Unqualified rejection | This document | 1091 +-------+-----------------------+---------------+ 1093 Table 5: Rejection values of the PDR-ACK Status 1095 7.7. SubRegistry for the Route Projection Options Flags 1097 IANA is requested to create a Subregistry for the 5-bit Route 1098 Projection Options (RPO) Flags field. Each bit is tracked with the 1099 following qualities: 1101 * Bit number (counting from bit 0 as the most significant bit) 1103 * Capability description 1105 * Reference 1107 Registration procedure is "Standards Action" [RFC8126]. No bit is 1108 currently defined for the Route Projection Options (RPO) Flags. 1110 7.8. SubRegistry for the Sibling Information Option Flags 1112 IANA is required to create a registry for the 5-bit Sibling 1113 Information Option (SIO) Flags field. Each bit is tracked with the 1114 following qualities: 1116 * Bit number (counting from bit 0 as the most significant bit) 1118 * Capability description 1120 * Reference 1122 Registration procedure is "Standards Action" [RFC8126]. The initial 1123 allocation is as indicated in Table 6: 1125 +============+===================================+===============+ 1126 | Bit number | Capability description | Reference | 1127 +============+===================================+===============+ 1128 | 0 | Connectivity is bidirectional (B) | This document | 1129 +------------+-----------------------------------+---------------+ 1131 Table 6: Initial SIO Flags 1133 7.9. Error in Projected Route ICMPv6 Code 1135 In some cases RPL will return an ICMPv6 error message when a message 1136 cannot be forwarded along a Projected Route. This ICMPv6 error 1137 message is "Error in Projected Route". 1139 IANA has defined an ICMPv6 "Code" Fields Registry for ICMPv6 Message 1140 Types. ICMPv6 Message Type 1 describes "Destination Unreachable" 1141 codes. This specification requires that a new code is allocated from 1142 the ICMPv6 Code Fields Registry for ICMPv6 Message Type 1, for "Error 1143 in Projected Route", with a suggested code value of 8, to be 1144 confirmed by IANA. 1146 8. Acknowledgments 1148 The authors wish to acknowledge JP Vasseur, Remy Liubing, James 1149 Pylakutty and Patrick Wetterwald for their contributions to the ideas 1150 developed here. 1152 9. Normative References 1154 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1155 Requirement Levels", BCP 14, RFC 2119, 1156 DOI 10.17487/RFC2119, March 1997, 1157 . 1159 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1160 Control Message Protocol (ICMPv6) for the Internet 1161 Protocol Version 6 (IPv6) Specification", STD 89, 1162 RFC 4443, DOI 10.17487/RFC4443, March 2006, 1163 . 1165 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 1166 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1167 DOI 10.17487/RFC6282, September 2011, 1168 . 1170 [RPL] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1171 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1172 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1173 Low-Power and Lossy Networks", RFC 6550, 1174 DOI 10.17487/RFC6550, March 2012, 1175 . 1177 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 1178 Routing Header for Source Routes with the Routing Protocol 1179 for Low-Power and Lossy Networks (RPL)", RFC 6554, 1180 DOI 10.17487/RFC6554, March 2012, 1181 . 1183 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1184 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1185 May 2017, . 1187 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1188 Writing an IANA Considerations Section in RFCs", BCP 26, 1189 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1190 . 1192 10. Informative References 1194 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 1195 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 1196 2014, . 1198 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and 1199 J. Martocci, "Reactive Discovery of Point-to-Point Routes 1200 in Low-Power and Lossy Networks", RFC 6997, 1201 DOI 10.17487/RFC6997, August 2013, 1202 . 1204 [6TiSCH-ARCHI] 1205 Thubert, P., "An Architecture for IPv6 over the TSCH mode 1206 of IEEE 802.15.4", Work in Progress, Internet-Draft, 1207 draft-ietf-6tisch-architecture-29, 27 August 2020, 1208 . 1211 [RAW-ARCHI] 1212 Thubert, P., Papadopoulos, G., and R. Buddenberg, 1213 "Reliable and Available Wireless Architecture/Framework", 1214 Work in Progress, Internet-Draft, draft-pthubert-raw- 1215 architecture-04, 6 July 2020, 1216 . 1219 [TURN-ON_RFC8138] 1220 Thubert, P. and L. Zhao, "A RPL DODAG Configuration Option 1221 for the 6LoWPAN Routing Header", Work in Progress, 1222 Internet-Draft, draft-ietf-roll-turnon-rfc8138-17, 30 1223 September 2020, . 1226 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 1227 "Deterministic Networking Architecture", RFC 8655, 1228 DOI 10.17487/RFC8655, October 2019, 1229 . 1231 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 1232 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 1233 RFC 8025, DOI 10.17487/RFC8025, November 2016, 1234 . 1236 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 1237 "IPv6 over Low-Power Wireless Personal Area Network 1238 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 1239 April 2017, . 1241 [USEofRPLinfo] 1242 Robles, I., Richardson, M., and P. Thubert, "Using RPI 1243 Option Type, Routing Header for Source Routes and IPv6-in- 1244 IPv6 encapsulation in the RPL Data Plane", Work in 1245 Progress, Internet-Draft, draft-ietf-roll-useofrplinfo-41, 1246 21 September 2020, . 1249 [PCE] IETF, "Path Computation Element", 1250 . 1252 Appendix A. Applications 1254 A.1. Loose Source Routing 1256 A RPL implementation operating in a very constrained LLN typically 1257 uses the Non-Storing Mode of Operation as represented in Figure 9. 1258 In that mode, a RPL node indicates a parent-child relationship to the 1259 Root, using a Destination Advertisement Object (DAO) that is unicast 1260 from the node directly to the Root, and the Root typically builds a 1261 source routed path to a destination down the DODAG by recursively 1262 concatenating this information. 1264 ------+--------- 1265 | Internet 1266 | 1267 +-----+ 1268 | | Border Router 1269 | | (RPL Root) 1270 +-----+ ^ | | 1271 | | DAO | ACK | 1272 o o o o | | | Strict 1273 o o o o o o o o o | | | Source 1274 o o o o o o o o o o | | | Route 1275 o o o o o o o o o | | | 1276 o o o o o o o o | v v 1277 o o o o 1278 LLN 1280 Figure 9: RPL Non-Storing Mode of operation 1282 Based on the parent-children relationships expressed in the non- 1283 storing DAO messages,the Root possesses topological information about 1284 the whole network, though this information is limited to the 1285 structure of the DODAG for which it is the destination. A packet 1286 that is generated within the domain will always reach the Root, which 1287 can then apply a source routing information to reach the destination 1288 if the destination is also in the DODAG. Similarly, a packet coming 1289 from the outside of the domain for a destination that is expected to 1290 be in a RPL domain reaches the Root. 1292 It results that the Root, or then some associated centralized 1293 computation engine such as a PCE, can determine the amount of packets 1294 that reach a destination in the RPL domain, and thus the amount of 1295 energy and bandwidth that is wasted for transmission, between itself 1296 and the destination, as well as the risk of fragmentation, any 1297 potential delays because of a paths longer than necessary (shorter 1298 paths exist that would not traverse the Root). 1300 As a network gets deep, the size of the source routing header that 1301 the Root must add to all the downward packets becomes an issue for 1302 nodes that are many hops away. In some use cases, a RPL network 1303 forms long lines and a limited amount of well-Targeted routing state 1304 would allow to make the source routing operation loose as opposed to 1305 strict, and save packet size. Limiting the packet size is directly 1306 beneficial to the energy budget, but, mostly, it reduces the chances 1307 of frame loss and/or packet fragmentation, which is highly 1308 detrimental to the LLN operation. Because the capability to store a 1309 routing state in every node is limited, the decision of which route 1310 is installed where can only be optimized with a global knowledge of 1311 the system, a knowledge that the Root or an associated PCE may 1312 possess by means that are outside of the scope of this specification. 1314 This specification enables to store a Storing Mode state in 1315 intermediate routers, which enables to limit the excursion of the 1316 source route headers in deep networks. Once a P-DAO exchange has 1317 taken place for a given Target, if the Root operates in non Storing 1318 Mode, then it may elide the sequence of routers that is installed in 1319 the network from its source route headers to destination that are 1320 reachable via that Target, and the source route headers effectively 1321 become loose. 1323 A.2. Transversal Routes 1325 RPL is optimized for Point-to-Multipoint (P2MP) and Multipoint-to- 1326 Point (MP2P), whereby routes are always installed along the RPL DODAG 1327 respectively from and towards the DODAG Root. Transversal Peer to 1328 Peer (P2P) routes in a RPL network will generally suffer from some 1329 elongated (stretched) path versus the best possible path, since 1330 routing between 2 nodes always happens via a common parent, as 1331 illustrated in Figure 10: 1333 * In Storing Mode, unless the destination is a child of the source, 1334 the packets will follow the default route up the DODAG as well. 1335 If the destination is in the same DODAG, they will eventually 1336 reach a common parent that has a route to the destination; at 1337 worse, the common parent may also be the Root. From that common 1338 parent, the packet will follow a path down the DODAG that is 1339 optimized for the Objective Function that was used to build the 1340 DODAG. 1342 * in Non-Storing Mode, all packets routed within the DODAG flow all 1343 the way up to the Root of the DODAG. If the destination is in the 1344 same DODAG, the Root must encapsulate the packet to place an RH 1345 that has the strict source route information down the DODAG to the 1346 destination. This will be the case even if the destination is 1347 relatively close to the source and the Root is relatively far off. 1349 ------+--------- 1350 | Internet 1351 | 1352 +-----+ 1353 | | Border Router 1354 | | (RPL Root) 1355 +-----+ 1356 X 1357 ^ v o o 1358 ^ o o v o o o o o 1359 ^ o o o v o o o o o 1360 ^ o o v o o o o o 1361 S o o o D o o o 1362 o o o o 1363 LLN 1365 Figure 10: Routing Stretch between S and D via common parent X 1367 It results that it is often beneficial to enable transversal P2P 1368 routes, either if the RPL route presents a stretch from shortest 1369 path, or if the new route is engineered with a different objective, 1370 and that it is even more critical in Non-Storing Mode than it is in 1371 Storing Mode, because the routing stretch is wider. For that reason, 1372 earlier work at the IETF introduced the "Reactive Discovery of 1373 Point-to-Point Routes in Low Power and Lossy Networks" [RFC6997], 1374 which specifies a distributed method for establishing optimized P2P 1375 routes. This draft proposes an alternate based on a centralized 1376 route computation. 1378 ------+--------- 1379 | Internet 1380 | 1381 +-----+ 1382 | | Border Router 1383 | | (RPL Root) 1384 +-----+ 1385 | 1386 o o o o 1387 o o o o o o o o o 1388 o o o o o o o o o o 1389 o o o o o o o o o 1390 S>>A>>>B>>C>>>D o o o 1391 o o o o 1392 LLN 1394 Figure 11: Projected Transversal Route 1396 This specification enables to store source-routed or Storing Mode 1397 state in intermediate routers, which enables to limit the stretch of 1398 a P2P route and maintain the characteristics within a given SLA. An 1399 example of service using this mechanism oculd be a control loop that 1400 would be installed in a network that uses classical RPL for 1401 asynchronous data collection. In that case, the P2P path may be 1402 installed in a different RPL Instance, with a different objective 1403 function. 1405 Authors' Addresses 1407 Pascal Thubert (editor) 1408 Cisco Systems, Inc 1409 Building D 1410 45 Allee des Ormes - BP1200 1411 06254 Mougins - Sophia Antipolis 1412 France 1414 Phone: +33 497 23 26 34 1415 Email: pthubert@cisco.com 1417 Rahul Arvind Jadhav 1418 Huawei Tech 1419 Kundalahalli Village, Whitefield, 1420 Bangalore 560037 1421 Karnataka 1422 India 1424 Phone: +91-080-49160700 1425 Email: rahul.ietf@gmail.com 1427 Matthew Gillmore 1428 Itron, Inc 1429 Building D 1430 2111 N Molter Road 1431 Liberty Lake, 99019 1432 United States 1434 Phone: +1.800.635.5461 1435 Email: matthew.gillmore@itron.com