idnits 2.17.1 draft-ietf-roll-dao-projection-18.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6554, 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 (12 July 2021) is 1012 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 (-09) exists of draft-pthubert-raw-architecture-05 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: 6554 (if approved) R.A. Jadhav 5 Intended status: Standards Track Huawei Tech 6 Expires: 13 January 2022 M. Gillmore 7 Itron 8 12 July 2021 10 Root initiated routing state in RPL 11 draft-ietf-roll-dao-projection-18 13 Abstract 15 This document extends RFC 6550 and RFC 6553 to enable a RPL Root to 16 install and maintain Projected Routes within its DODAG, along a 17 selected set of nodes that may or may not include self, for a chosen 18 duration. This potentially enables routes that are more optimized or 19 resilient than those obtained with the classical distributed 20 operation of RPL, either in terms of the size of a Routing Header or 21 in terms of path length, which impacts both the latency and the 22 packet delivery ratio. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 13 January 2022. 41 Copyright Notice 43 Copyright (c) 2021 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Simplified BSD License text 52 as described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 60 2.2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.3. Other Terms . . . . . . . . . . . . . . . . . . . . . . . 6 62 2.4. References . . . . . . . . . . . . . . . . . . . . . . . 6 63 3. Extending RFC 6550 . . . . . . . . . . . . . . . . . . . . . 6 64 3.1. Projected DAO . . . . . . . . . . . . . . . . . . . . . . 7 65 3.2. Sibling Information Option . . . . . . . . . . . . . . . 8 66 3.3. P-DAO Request . . . . . . . . . . . . . . . . . . . . . . 9 67 3.4. Extending the RPI . . . . . . . . . . . . . . . . . . . . 9 68 4. Extending RFC 6553 . . . . . . . . . . . . . . . . . . . . . 9 69 5. Extending RFC 8138 . . . . . . . . . . . . . . . . . . . . . 10 70 6. New RPL Control Messages and Options . . . . . . . . . . . . 11 71 6.1. New P-DAO Request Control Message . . . . . . . . . . . . 11 72 6.2. New PDR-ACK Control Message . . . . . . . . . . . . . . . 12 73 6.3. Via Information Options . . . . . . . . . . . . . . . . . 13 74 6.4. Sibling Information Option . . . . . . . . . . . . . . . 16 75 7. Projected DAO . . . . . . . . . . . . . . . . . . . . . . . . 18 76 7.1. Requesting a Track . . . . . . . . . . . . . . . . . . . 19 77 7.2. Identifying a Track . . . . . . . . . . . . . . . . . . . 20 78 7.3. Installing a Track . . . . . . . . . . . . . . . . . . . 21 79 7.3.1. Storing-Mode P-Route . . . . . . . . . . . . . . . . 22 80 7.3.2. Non-Storing-Mode P-Route . . . . . . . . . . . . . . 24 81 7.4. Forwarding Along a Track . . . . . . . . . . . . . . . . 26 82 8. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 27 83 9. Example Track Signaling . . . . . . . . . . . . . . . . . . . 28 84 9.1. Using Storing-Mode Segments . . . . . . . . . . . . . . . 29 85 9.1.1. Stitched Segments . . . . . . . . . . . . . . . . . . 29 86 9.1.2. External routes . . . . . . . . . . . . . . . . . . . 31 87 9.1.3. Segment Routing . . . . . . . . . . . . . . . . . . . 32 88 9.2. Using Non-Storing-Mode joining Tracks . . . . . . . . . . 34 89 9.2.1. Stitched Tracks . . . . . . . . . . . . . . . . . . . 34 90 9.2.2. External routes . . . . . . . . . . . . . . . . . . . 36 91 9.2.3. Segment Routing . . . . . . . . . . . . . . . . . . . 38 92 10. Security Considerations . . . . . . . . . . . . . . . . . . . 41 93 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 94 11.1. New Elective 6LoWPAN Routing Header Type . . . . . . . . 41 95 11.2. New Critical 6LoWPAN Routing Header Type . . . . . . . . 42 96 11.3. New Subregistry For The RPL Option Flags . . . . . . . . 42 97 11.4. New RPL Control Codes . . . . . . . . . . . . . . . . . 43 98 11.5. New RPL Control Message Options . . . . . . . . . . . . 43 99 11.6. SubRegistry for the Projected DAO Request Flags . . . . 43 100 11.7. SubRegistry for the PDR-ACK Flags . . . . . . . . . . . 44 101 11.8. Subregistry for the PDR-ACK Acceptance Status Values . . 44 102 11.9. Subregistry for the PDR-ACK Rejection Status Values . . 44 103 11.10. SubRegistry for the Via Information Options Flags . . . 45 104 11.11. SubRegistry for the Sibling Information Option Flags . . 45 105 11.12. New Destination Advertisement Object Flag . . . . . . . 46 106 11.13. Error in Projected Route ICMPv6 Code . . . . . . . . . . 46 107 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46 108 13. Normative References . . . . . . . . . . . . . . . . . . . . 46 109 14. Informative References . . . . . . . . . . . . . . . . . . . 47 110 Appendix A. Applications . . . . . . . . . . . . . . . . . . . . 49 111 A.1. Loose Source Routing . . . . . . . . . . . . . . . . . . 49 112 A.2. Transversal Routes . . . . . . . . . . . . . . . . . . . 51 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 115 1. Introduction 117 RPL, the "Routing Protocol for Low Power and Lossy Networks" [RPL] 118 (LLNs), is a generic Distance Vector protocol that is well suited for 119 application in a variety of low energy Internet of Things (IoT) 120 networks. RPL forms Destination Oriented Directed Acyclic Graphs 121 (DODAGs) in which the Root often acts as the Border Router to connect 122 the RPL domain to the Internet. The Root is responsible to select 123 the RPL Instance that is used to forward a packet coming from the 124 Internet into the RPL domain and set the related RPL information in 125 the packets. 6TiSCH uses RPL for its routing operations. 127 The "6TiSCH Architecture" [6TiSCH-ARCHI] also leverages the 128 "Deterministic Networking Architecture" [RFC8655] centralized model 129 whereby the device resources and capabilities are exposed to an 130 external controller which installs routing states into the network 131 based on some objective functions that reside in that external 132 entity. With DetNet and 6TiSCH, the component of the controller that 133 is responsible of computing routes is called a Path Computation 134 Element ([PCE]). 136 Based on heuristics of usage, path length, and knowledge of device 137 capacity and available resources such as battery levels and 138 reservable buffers, the PCE with a global visibility on the system 139 can compute direct Peer to Peer (P2P) routes that are optimized for 140 the needs expressed by an objective function. This document 141 specifies protocol extensions to RPL [RPL] that enable the Root of a 142 main DODAG to install centrally-computed routes inside the DODAG on 143 behalf of a PCE. 145 This specification expects that the main RPL Instance is operated in 146 RPL Non-Storing Mode of Operation (MOP) to sustain the exchanges with 147 the Root. In that Mode, the Root has enough information to build a 148 basic DODAG topology based on parents and children, but lacks the 149 knowledge of siblings. This document adds the capability for nodes 150 to advertise sibling information in order to improve the topological 151 awareness of the Root. 153 As opposed to the classical RPL operations where routes are injected 154 by the Target nodes, the protocol extensions enable the Root of a 155 DODAG to project the routes that are needed onto the nodes where they 156 should be installed. This specification uses the term Projected 157 Route to refer to those routes. Projected Routes can be used to 158 reduce the size of the source routing headers with loose source 159 routing operations down the main RPL DODAG. Projected Routes can 160 also be used to build transversal routes for route optimization and 161 Traffic Engineering purposes, between nodes of the DODAG. 163 A Projected Route may be installed in either Storing and Non-Storing 164 Mode, potentially resulting in hybrid situations where the Mode of 165 the Projected Route is different from that of the main RPL Instance. 166 A Projected Route may be a stand-alone end-to-end path or a Segment 167 in a more complex forwarding graph called a Track. 169 The concept of a Track was introduced in the 6TiSCH architecture, as 170 a potentially complex path with redundant forwarding solutions along 171 the way. With this specification, a Track is a DODAG formed by a RPL 172 local Instance that is rooted at the Track Ingress. If there is a 173 single Track Egress, then the Track is reversible to form another 174 DODAG by reversing the direction of each edge. A node at the ingress 175 of more than one Segment in a Track may use one or more of these 176 Segments to forward a packet inside the Track. 178 The "Reliable and Available Wireless (RAW) Architecture/Framework" 179 [RAW-ARCHI] defines the Path Selection Engine (PSE) that adapts the 180 use of the path redundancy within a Track to defeat the diverse 181 causes of packet loss. 183 The PSE is a dataplane extension of the PCE; it controls the 184 forwarding operation of the packets within a Track, using Packet ARQ, 185 Replication, Elimination, and Overhearing (PAREO) functions over the 186 Track segments, to provide a dynamic balance between the reliability 187 and availability requirements of the flows and the need to conserve 188 energy and spectrum. 190 The time scale at which the PCE (re)computes the Track can be long, 191 using long-term statistical metrics to perform global optimizations 192 at the scale of the whole network. Conversely, the PSE makes 193 forwarding decisions at the time scale of one or a small collection 194 of packets, based on a knowledge that is limited in scope to the 195 Track itself, so it can be refreshed at a fast pace. 197 Projected Routes must be used with the parsimony to limit the amount 198 of state that is installed in each device to fit within the device 199 resources, and to maintain the amount of rerouted traffic within the 200 capabilities of the transmission links. The methods used to learn 201 the node capabilities and the resources that are available in the 202 devices and in the network are out of scope for this document. 204 This specification uses the RPL Root as a proxy to the PCE. The PCE 205 may be collocated with the Root, or may reside in an external 206 Controller. 208 In that case, the PCE exchanges control messages with the Root over a 209 Southbound API that is out of scope for this specification. The 210 algorithm to compute the paths and the protocol used by an external 211 PCE to obtain the topology of the network from the Root are also out 212 of scope. 214 2. Terminology 216 2.1. Requirements Language 218 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 219 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 220 "OPTIONAL" in this document are to be interpreted as described in BCP 221 14 [RFC2119][RFC8174] when, and only when, they appear in all 222 capitals, as shown here. 224 2.2. Glossary 226 This document often uses the following acronyms: 228 CMO: Control Message Option 229 DAO: Destination Advertisement Object 230 DAG: Directed Acyclic Graph 231 DODAG: Destination-Oriented Directed Acyclic Graph; A DAG with only 232 one vertex (i.e., node) that has no outgoing edge (i.e., link) 233 LLN: Low-Power and Lossy Network 234 MOP: RPL Mode of Operation 235 P-DAO: Projected DAO 236 P-Route: Projected Route 237 PDR: P-DAO Request 238 RAN: RPL-Aware Node (either a RPL Router or a RPL-Aware Leaf) 239 RAL: RPL-Aware Leaf 240 RH: Routing Header 241 RPI: RPL Packet Information 242 RTO: RPL Target Option 243 RUL: RPL-Unaware Leaf 244 SIO: RPL Sibling Information Option 245 SR-VIO: A Source-Routed Via Information Option, used in Non-Storing- 246 Mode P-DAO messages. 247 TIO: RPL Transit Information Option 248 SF-VIO: A Via Information Option, used in Storing-Mode P-DAO 249 messages. 250 VIO: A Via Information Option; it can be a SF-VIO or an SR-VIO. 252 2.3. Other Terms 254 Projected Route: A RPL Projected Route is a RPL route that is 255 computed remotely by a PCE, and installed and maintained by a RPL 256 Root on behalf of the PCE. 257 Segment: A strict sequence of node along which a route is installed. 258 With this specification, a Segment is installed by the Root of the 259 main DODAG using Storing-Mode P-DAO messages. 260 Projected DAO: A DAO message used to install a Projected Route. 261 Track: A DODAG that provides a complex path from or to a Root that 262 is the destination of the DODAG. The Root is the Track Ingress, 263 and the forward direction for packets is down the DODAG, from the 264 Track Ingress to one of the possibly multiple Track Egress Nodes. 265 The DODAG may be strictly connected, meaning that the vertices are 266 adjacent, or loosely connected, meaning that the vertices are 267 connected using Segments that are associated to the same Track. 268 With this specification, a Track is installed by the Root of the 269 main DODAG using Non-Storing-Mode P-DAO messages. 270 TrackID: A RPL Local InstanceID with the D bit set to 0. The 271 TrackID is associated with the IPv6 Address of the Track Ingress 272 that is used to signal the DODAG Root, and together they form a 273 unique identification of the Track (see the definition of DODAGID 274 in section 2 of [RPL]. 276 2.4. References 278 In this document, readers will encounter terms and concepts that are 279 discussed in the "Routing Protocol for Low Power and Lossy Networks" 280 [RPL] and "Terminology in Low power And Lossy Networks" [RFC7102]. 282 3. Extending RFC 6550 283 3.1. Projected DAO 285 Section 6 of [RPL] introduces the RPL Control Message Options (CMO), 286 including the RPL Target Option (RTO) and Transit Information Option 287 (TIO), which can be placed in RPL messages such as the Destination 288 Advertisement Object (DAO). This specification extends the DAO 289 message with the Projected DAO (P-DAO); a P-DAO message signals a 290 Projected Route to one or more Targets using the new CMOs presented 291 therein. This specification enables to combine one or more Projected 292 Routes into a DODAG called a Track, that is traversed to reach the 293 Targets. 295 The Track is assimilated with the DODAG formed for a Local RPL 296 Instance. The local RPLInstanceID of the Track is called the 297 TrackID, more in Section 7.2. A P-DAO message for a Track signals 298 the TrackID in the RPLInstanceID field. The Track Ingress is 299 signaled in the DODAGID field of the Projected DAO Base Object; that 300 field is elided in the case of the main RPL Instance. The Track 301 Ingress is the Root of the Track, as shown in Figure 1. 303 This specification defines the new "Projected DAO" (P) flag. The 'P' 304 flag is encoded in bit position 2 (to be confirmed by IANA) of the 305 Flags field in the DAO Base Object. The Root MUST set it to 1 in a 306 Projected DAO message. Otherwise it MUST be set to 0. It is set to 307 0 in legacy implementations as specified respectively in Sections 308 20.11 and 6.4 of [RPL]. . 310 0 1 2 3 311 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 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | TrackID |K|D|P| Flags | Reserved | DAOSequence | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | | 316 + + 317 | | 318 + IPv6 Address of the Track Ingress + 319 | | 320 + + 321 | | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Option(s)... 324 +-+-+-+-+-+-+-+-+ 326 Figure 1: Projected DAO Base Object 328 New fields: 330 TrackID: In the case of a P-DAO, the RPLInstanceID field is called 331 TrackID. This is a naming convenience but does not change the 332 semantics and format of the RPLInstanceID that is used as TrackID. 334 P: 1-bit flag (position to be confirmed by IANA). 336 The 'P' flag is set to 1 by the Root to signal a Projected DAO, 337 and it is set to 0 otherwise. 339 In RPL Non-Storing Mode, the TIO and RTO are combined in a DAO 340 message to inform the DODAG Root of all the edges in the DODAG, which 341 are formed by the directed parent-child relationships. Options may 342 be factorized; multiple RTOs may be present to signal a collection of 343 children that can be reached via the parent(s) indicated in the 344 TIO(s) that follows the RTOs. This specification generalizes the 345 case of a parent that can be used to reach a child with that of a 346 whole Track through which both children and siblings of the Track 347 Egress are reachable. 349 New CMOs called the Via Information Options (VIO) are introduced for 350 use in P-DAO messages as a multihop alternative to the TIO. One VIO 351 is the Stateful VIO (SF-VIO); the SF-VIO installs Storing-Mode 352 Projected Route along a strict segment. The other is the Source- 353 Routed VIO (SR-VIO); the SR-VIO installs a Non-Storing-Mode Projected 354 Route at the Track Ingress, which uses that state to encapsulate a 355 packet with a Routing Header (RH) to the Track Egress. 357 Like in a DAO message, the RTOs can be factorized in a P-DAO, but the 358 Via Information Options cannot. A P-DAO contains one or more RTOs 359 that indicate the destinations that can be reached via the Track, and 360 exactly one VIO that signals a sequence of nodes. In Non-Storing 361 Mode, the Root sends the P-DAO to the Track Ingress where the source- 362 routing state is stored. In Storing Mode, the P-DAO is sent to the 363 Track Egress and forwarded along the Segment in the reverse 364 direction, installing a Storing Mode state to the Track Egress at 365 each hop. In both cases the Track Ingress is the owner of the Track, 366 and it generates the P-DAO-ACK when the installation is successful. 368 3.2. Sibling Information Option 370 This specification adds another CMO called the Sibling Information 371 Option (SIO) that is used by a RPL Aware Node (RAN) to advertise a 372 selection of its candidate neighbors as siblings to the Root, more in 373 Section 6.4. The sibling selection process is out of scope. The 374 expectation is that a node reports a Sibling Address in a SIO based 375 on an active address registration [RFC8505] from that sibling for 376 that address with the 'R' flag not set in the EARO. The node may 377 assess the liveliness of the sibling at any time by performing a 378 registration for one of its own addresses, either a link local or a 379 global one, depending on whether the node expects the sibling to 380 perform a matching advertisement in its own SIO. 382 3.3. P-DAO Request 384 Two new RPL Control Messages are also introduced, to enable a RAN to 385 request the establishment of a Track between self as the Track 386 Ingress Node and a Track Egress. The RAN makes its request by 387 sending a new P-DAO Request (PDR) Message to the Root. The Root 388 confirms with a new PDR-ACK message back to the requester RAN, see 389 Section 6.1 for more. A positive PDR-ACK indicates that the Track 390 was built and that the Roots commits to maintain the Track for the 391 negotiated lifetime. In the case of a complex Track, each Segment is 392 maintained independently and asynchronously by the Root, with its own 393 lifetime that may be shorter, the same, or longer than that of the 394 Track. The Root may use an asynchronous PDR-ACK with an negative 395 status to indicate that the Track was terminated before its time. 397 3.4. Extending the RPI 399 Sending a Packet within a RPL Local Instance requires the presence of 400 the abstract RPL Packet Information (RPI) described in section 11.2. 401 of [RPL] in the outer IPv6 Header chain (see [USEofRPLinfo]). The 402 RPI carries a local RPLInstanceID which, in association with either 403 the source or the destination address in the IPv6 Header, indicates 404 the RPL Instance that the packet follows. 406 This specification extends [RPL] to create a new flag that signals 407 that a packet is forwarded along a projected route. 409 Projected-Route 'P': 1-bit flag. It is set to 1 if this packet is 410 sent over a projected route and set to 0 otherwise. 412 4. Extending RFC 6553 414 "The RPL Option for Carrying RPL Information in Data-Plane Datagrams" 415 [RFC6553]describes the RPL Option for use among RPL routers to 416 include the abstract RPL Packet Information (RPI) described in 417 section 11.2. of [RPL] in data packets. 419 The RPL Option is commonly referred to as the RPI though the RPI is 420 really the abstract information that is transported in the RPL 421 Option. [USEofRPLinfo] updated the Option Type from 0x63 to 0x23. 423 This specification modifies the RPL Option to encode the 'P' flag as 424 follows: 426 0 1 2 3 427 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 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Option Type | Opt Data Len | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 |O|R|F|P|0|0|0|0| RPLInstanceID | SenderRank | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | (sub-TLVs) | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 Figure 2: Extended RPL Option Format 438 Option Type: 0x23 or 0x63, see [USEofRPLinfo] 440 Opt Data Len: See [RFC6553] 442 'O', 'R' and 'F' flags: See [RFC6553]. Those flags MUST be set to 0 443 by the sender and ignored by the receiver if the 'P' flag is set. 445 Projected-Route 'P': 1-bit flag as defined in Section 3.4. 447 RPLInstanceID: See [RFC6553]. Indicates the TrackId if the 'P' flag 448 is set. 450 SenderRank: See [RFC6553]. This field MUST be set to 0 by the 451 sender and ignored by the receiver if the 'P'flag is set. 453 5. Extending RFC 8138 455 Section 6.3 of [RFC8138] presents the formats of the 6LoWPAN Routing 456 Header of type 5 (RPI-6LoRH) that compresses the RPI for normal RPL 457 operation. The format of the RPI-6LoRH is not suited for Projected 458 routes since the O,R,F flags are not used and the Rank is unknown and 459 ignored. 461 This specification introduces a new 6LoRH, the P-RPI-6LoRH, with a 462 type of 7. The P-RPI-6LoRH header is usually a a Critical 6LoWPAN 463 Routing Header, but it can be elective as well if an SRH-6LoRH is 464 present and controls the routing decision. 466 The P-RPI-6LoRH is designed to compress the RPI along RPL Projected 467 Routes. It sformat is as follows: 469 0 1 2 470 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 |1|0|E| Length | 6LoRH Type 7 | RPLInstanceID | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 Figure 3: P-RPI-6LoRH Format 477 Elective 'E': See [RFC8138]. The 'E' flag is set to 1 to indicate 478 an Elective 6LoRH, meaning that it can be ignored when forwarding. 480 6. New RPL Control Messages and Options 482 6.1. New P-DAO Request Control Message 484 The P-DAO Request (PDR) message is sent by a Node in the main DODAG 485 to the Root. It is a request to establish or refresh a Track where 486 this node is Track Ingress. The source IPv6 address of the PDR 487 signals the Track Ingress of the requested Track, and the TrackID is 488 indicated in the message itself. One and only one RPL Target Option 489 MUST be present in the message. The RTO signals the Track Egress, 490 more in Section 7.1. 492 The RPL Control Code for the PDR is 0x09, to be confirmed by IANA. 493 The format of PDR Base Object is as follows: 495 0 1 2 3 496 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 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | TrackID |K|R| Flags | ReqLifetime | PDRSequence | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | Option(s)... 501 +-+-+-+-+-+-+-+-+ 503 Figure 4: New P-DAO Request Format 505 TrackID: 8-bit field indicating the RPLInstanceID associated with 506 the Track. 508 K: The 'K' flag is set to indicate that the recipient is expected to 509 send a PDR-ACK back. 511 R: The 'R' flag is set to request a Complex Track for redundancy. 513 Flags: Reserved. The Flags field MUST initialized to zero by the 514 sender and MUST be ignored by the receiver 516 ReqLifetime: 8-bit unsigned integer. The requested lifetime for the 517 Track expressed in Lifetime Units (obtained from the DODAG 518 Configuration option). 520 A PDR with a fresher PDRSequence refreshes the lifetime, and a 521 PDRLifetime of 0 indicates that the track should be destroyed. 523 PDRSequence: 8-bit wrapping sequence number, obeying the operation 524 in section 7.2 of [RPL]. The PDRSequence is used to correlate a 525 PDR-ACK message with the PDR message that triggered it. It is 526 incremented at each PDR message and echoed in the PDR-ACK by the 527 Root. 529 6.2. New PDR-ACK Control Message 531 The new PDR-ACK is sent as a response to a PDR message with the 'K' 532 flag set. The RPL Control Code for the PDR-ACK is 0x0A, to be 533 confirmed by IANA. Its format is as follows: 535 0 1 2 3 536 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 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | TrackID | Flags | Track Lifetime| PDRSequence | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | PDR-ACK Status| Reserved | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | Option(s)... 543 +-+-+-+-+-+-+-+ 545 Figure 5: New PDR-ACK Control Message Format 547 TrackID: The RPLInstanceID of the Track that was created. The value 548 of 0x00 is used to when no Track was created. 550 Flags: Reserved. The Flags field MUST initialized to zero by the 551 sender and MUST be ignored by the receiver 553 Track Lifetime: Indicates that remaining Lifetime for the Track, 554 expressed in Lifetime Units; the value of zero (0x00) indicates 555 that the Track was destroyed or not created. 557 PDRSequence: 8-bit wrapping sequence number. It is incremented at 558 each PDR message and echoed in the PDR-ACK. 560 PDR-ACK Status: 8-bit field indicating the completion. The PDR-ACK 561 Status is substructured as indicated in Figure 6: 563 0 1 2 3 4 5 6 7 564 +-+-+-+-+-+-+-+-+ 565 |E|R| Value | 566 +-+-+-+-+-+-+-+-+ 568 Figure 6: PDR-ACK status Format 570 E: 1-bit flag. Set to indicate a rejection. When not set, the 571 value of 0 indicates Success/Unqualified acceptance and other 572 values indicate "not an outright rejection". 573 R: 1-bit flag. Reserved, MUST be set to 0 by the sender and 574 ignored by the receiver. 575 Status Value: 6-bit unsigned integer. Values depending on the 576 setting of the 'E' flag, see Table 27 and Table 28. 578 Reserved: The Reserved field MUST initialized to zero by the sender 579 and MUST be ignored by the receiver 581 6.3. Via Information Options 583 A VIO signals the ordered list of IPv6 Via Addresses that constitutes 584 the hops of either a Serial Track or a Segment of a more Complex 585 Track. A VIO MUST contain at least one Via Address, and a Via 586 Address MUST NOT be present more than once, otherwise the VIO MUST be 587 ignored. The format of the Via Information Options is as follows: 589 0 1 2 3 590 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 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Type | Option Length | Flags | SegmentID | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 |Segm. Sequence | Seg. Lifetime | SRH-6LoRH header | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | | 597 + + 598 . . 599 . Via Address 1 . 600 . . 601 + + 602 | | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | | 605 . .... . 606 | | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | | 609 + + 610 . . 611 . Via Address n . 612 . . 613 + + 614 | | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 Figure 7: VIO format (uncompressed form) 619 Option Type: 0x0B for SF-VIO, 0x0C for SR-VIO (to be confirmed by 620 IANA) 622 Option Length: In bytes; variable, depending on the number of Via 623 Addresses and the compression. 625 SegmentID: 8-bit field that identifies a Segment within a Track or 626 the main DODAG as indicated by the TrackID field. The value of 0 627 is used to signal a Serial Track, i.e., made of a single segment. 629 Segment Sequence: 8-bit unsigned integer. The Segment Sequence 630 obeys the operation in section 7.2 of [RPL] and the lollipop 631 starts at 255. 633 When the Root of the DODAG needs to refresh or update a Segment in 634 a Track, it increments the Segment Sequence individually for that 635 Segment. 637 The Segment information indicated in the VIO deprecates any state 638 for the Segment indicated by the SegmentID within the indicated 639 Track and sets up the new information. 641 A VIO with a Segment Sequence that is not as fresh as the current 642 one is ignored. 644 A VIO for a given DODAGID with the same (TrackID, SegmentID, 645 Segment Sequence) indicates a retry; it MUST NOT change the 646 Segment and MUST be propagated or answered as the first copy. 648 Segment Lifetime: 8-bit unsigned integer. The length of time in 649 Lifetime Units (obtained from the Configuration option) that the 650 Segment is usable. 652 The period starts when a new Segment Sequence is seen. The value 653 of 255 (0xFF) represents infinity. The value of zero (0x00) 654 indicates a loss of reachability. 656 A P-DAO message that contains a VIO with a Segment Lifetime of 657 zero is referred as a No-Path P-DAO in this document. 659 SRH-6LoRH header: The first 2 bytes of the (first) SRH-6LoRH as 660 shown in Figure 6 of [RFC8138]. A 6LoRH Type of 4 means that the 661 VIA Addresses are provided in full with no compression. 663 Via Address: An IPv6 address along the Segment. 665 In a SF-VIO, the list is a strict path between direct neighbors, 666 from the Segment Ingress to Egress, both included. The router 667 that processes an SF-VIO MAY create additional routing state 668 towards the nodes after self via the node immediately after self 669 in the SF-VIO, but in case of memory shortage the routes to the 670 Targets have precedence since they are the ones that the router 671 commits to store. 673 In an SR-VIO, the list includes the egress but not the ingress 674 node. It starts at the first hop and ends at a Track Egress. In 675 that case, the Track Egress MUST be considered as an implicit 676 Target, so it MUST NOT be listed it in a RPL Target Option. The 677 list in an SR-VIO may be loose, provided that each listed node has 678 a path to the next listed node, e.g., via a segment or another 679 Track. 681 In the case of a SF-VIO, or if [RFC8138] is not used in the data 682 packets, then the Root MUST use only one SRH-6LoRH per Via 683 Information Option, and the compression is the same for all the 684 addresses, as shown in Figure 7. 686 In case of an SR-VIO, and if [RFC8138] is in use in the main 687 DODAG, then the Root SHOULD optimize the size of the SR-VIO; more 688 than one SRH-6LoRH may be present, e.g., if the compression level 689 changes inside the Segment and different SRH-6LoRH Types are 690 required. The content of the SR-VIO starting at the first SRH- 691 6LoRH header is thus verbatim the one that the Track Ingress 692 places in the packet encapsulation to reach the Track Ingress. 694 6.4. Sibling Information Option 696 The Sibling Information Option (SIO) provides indication on siblings 697 that could be used by the Root to form Projected Routes. One or more 698 SIO(s) may be placed in the DAO messages that are sent to the Root in 699 Non-Storing Mode. 701 The format of the SIO is as follows: 703 0 1 2 3 704 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 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | Type | Option Length |Comp.|B|D|Flags| Opaque | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | Step of Rank | Reserved | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | | 711 + + 712 . . 713 . Sibling DODAGID (if the D flag not set) . 714 . . 715 + + 716 | | 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | | 719 + + 720 . . 721 . Sibling Address . 722 . . 723 + + 724 | | 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 Figure 8: Sibling Information Option Format 729 Option Type: 0x0D (to be confirmed by IANA) 731 Option Length: In bytes, the size of the option. 733 Compression Type: 3-bit unsigned integer. This is the SRH-6LoRH 734 Type as defined in figure 7 in section 5.1 of [RFC8138] that 735 corresponds to the compression used for the Sibling Address and 736 its DODAGID if resent. The Compression reference is the Root of 737 the main DODAG. 739 Reserved for Flags: MUST be set to zero by the sender and MUST be 740 ignored by the receiver. 742 B: 1-bit flag that is set to indicate that the connectivity to the 743 sibling is bidirectional and roughly symmetrical. In that case, 744 only one of the siblings may report the SIO for the hop. If 'B' 745 is not set then the SIO only indicates connectivity from the 746 sibling to this node, and does not provide information on the hop 747 from this node to the sibling. 749 D: 1-bit flag that is set to indicate that sibling belongs to the 750 same DODAG. When not set, the Sibling DODAGID is indicated. 752 Flags: Reserved. The Flags field MUST initialized to zero by the 753 sender and MUST be ignored by the receiver 755 Opaque: MAY be used to carry information that the node and the Root 756 understand, e.g., a particular representation of the Link 757 properties such as a proprietary Link Quality Information for 758 packets received from the sibling. An industrial Alliance that 759 uses RPL for a particular use / environment MAY redefine the use 760 of this field to fit its needs. 762 Step of Rank: 16-bit unsigned integer. This is the Step of Rank 763 [RPL] as computed by the Objective Function between this node and 764 the sibling. 766 Reserved: The Reserved field MUST initialized to zero by the sender 767 and MUST be ignored by the receiver 769 Sibling DODAGID: 2 to 16 bytes, the DODAGID of the sibling in a 770 [RFC8138] compressed form as indicated by the Compression Type 771 field. This field is present if and only if the D flag is not 772 set. 774 Sibling Address: 2 to 16 bytes, an IPv6 Address of the sibling, with 775 a scope that MUST be make it reachable from the Root, e.g., it 776 cannot be a Link Local Address. The IPv6 address is encoded in 777 the [RFC8138] compressed form indicated by the Compression Type 778 field. 780 An SIO MAY be immediately followed by a DAG Metric Container. In 781 that case the DAG Metric Container provides additional metrics for 782 the hop from the Sibling to this node. 784 7. Projected DAO 786 This draft adds a capability to RPL whereby the Root of a main DODAG 787 installs a Track as a collection of Projected Routes, using a 788 Projected-DAO (P-DAO) message to maintain each individual route. The 789 P-DAO signals a collection of Targets in the RPL Target Option(s) 790 (RTO). Those Targets can be reached via a sequence of routers 791 indicated in a VIO. A P-DAO message MUST contain exactly one VIO, 792 which is either a SF-VIO or an SR-VIO, and MUST follow one or more 793 RTOs. There can be at most one such sequence of RTO(s) and an Via 794 Information Option. A track is identified by a tuple DODAGID, 795 TrackID and each route within a Track is indexed by a SegmentID. 797 A P-DAO MUST be sent from the address of the Root that serves as 798 DODAGID for the main DODAG. It MUST be sent to a GUA or a ULA of 799 either the ingress or the egress of the Segment, more below. If the 800 'K' Flag is present in the P-DAO, and unless the P-DAO does not reach 801 it, the ingress of the Segment is the node that acknowledges the 802 message, using a DAO-ACK that MUST be sent back to the address that 803 serves as DODAGID for the main DODAG. 805 Like a classical DAO message, a P-DAO causes a change of state only 806 if it is "new" per section 9.2.2. "Generation of DAO Messages" of 807 the RPL specification [RPL]; this is determined using the Segment 808 Sequence information from the VIO as opposed to the Path Sequence 809 from a TIO. Also, a Segment Lifetime of 0 in a VIO indicates that 810 the projected route associated to the Segment is to be removed. 812 There are two kinds of operation for the Projected Routes, the 813 Storing Mode and the Non-Storing Mode. 815 * The Non-Storing Mode is discussed in Section 7.3.2. A Non-Storing 816 Mode P-DAO carries an SR-VIO with the loose list of Via Addresses 817 that forms a source-routed Segment to the Track Egress. The 818 recipient of the P-DAO is the Track Ingress; it MUST install a 819 source-routed state to the Track Egress and reply to the Root 820 directly using a DAO-ACK message if requested to. 822 * The Storing Mode is discussed in Section 7.3.1. A Storing Mode 823 P-DAO carries a SF-VIO with the strict list of Via Addresses from 824 the ingress to the egress of the Segment in the data path order. 825 The routers listed in the Via Addresses, except the egress, MUST 826 install a routing state to the Target(s) via the next Via Address 827 in the SF-VIO. In normal operations, the P-DAO is propagated 828 along the chain of Via Routers from the egress router of the path 829 till the ingress one, which confirms the installation to the Root 830 with a DAO-ACK message. 832 In case of a forwarding error along a Projected Route, an ICMP error 833 is sent to the Root with a new Code "Error in Projected Route" (See 834 Section 11.13). The Root can then modify or remove the Projected 835 Route. The "Error in Projected Route" message has the same format as 836 the "Destination Unreachable Message", as specified in RFC 4443 837 [RFC4443]. 839 The portion of the invoking packet that is sent back in the ICMP 840 message SHOULD record at least up to the RH if one is present, and 841 this hop of the RH SHOULD be consumed by this node so that the 842 destination in the IPv6 header is the next hop that this node could 843 not reach. if a 6LoWPAN Routing Header (6LoRH) [RFC8138] is used to 844 carry the IPv6 routing information in the outer header then that 845 whole 6LoRH information SHOULD be present in the ICMP message. 847 The sender and exact operation depend on the Mode and is described in 848 Section 7.3.2 and Section 7.3.1 respectively. 850 7.1. Requesting a Track 852 A Node is free to ask the Root for a new Track for which it will be 853 Ingress at any time. This is done with a PDR message, that indicates 854 the desired TrackID and the duration for which the Track should be 855 established. Upon a PDR, the Root MAY install the necessary 856 Segments, in which case it answers with a PDR-ACK indicating the 857 granted Track Lifetime. All the Segments MUST be of a same mode, 858 either Storing or Non-Storing. All the Segments MUST be created with 859 the same TrackID and the same DODAGID signaled in the P-DAO. 861 The Root is free to design the Track as it wishes, and to change the 862 Segments overtime to serve the Track as needed, without notifying the 863 resquesting Node. The Segment Lifetime in the P-DAO messages does 864 not need to be aligned to the Requested Lifetime in the PDR, or 865 between P-DAO messages for different Segments. The Root may use 866 shorter lifetimes for the Segments and renew them faster than the 867 Track is, or longer lifetimes in which case it will need to tear down 868 the Segments if the Track is not renewed. 870 When the Track Lifetime that was returned in the PDR-ACK is close to 871 elapse, the resquesting Node needs to resend a PDR using the TrackID 872 in the PDR-ACK to extend the lifetime of the Track, else the Track 873 will time out and the Root will tear down the whole structure. 875 If the Track fails and cannot be restored, the Root notifies the 876 resquesting Node asynchronously with a PDR-ACK with a Track Lifetime 877 of 0, indicating that the Track has failed, and a PDR-ACK Status 878 indicating the reason of the fault. 880 7.2. Identifying a Track 882 RPL defines the concept of an Instance to signal an individual 883 routing topology but does not have a concept of an administrative 884 distance, which exists in certain proprietary implementations to sort 885 out conflicts between multiple sources of routing information within 886 one routing topology. 888 This draft leverages the RPL Instance model as follows: 890 * The Root MAY use P-DAO messages to add better routes in the main 891 (Global) Instance in conformance with the routing objectives in 892 that Instance. To achieve this, the Root MAY install an Storing- 893 Mode P-Route along a path down the main Non-Storing Mode DODAG. 894 This enables a loose source routing and reduces the size of the 895 Routing Header, see Appendix A.1. 897 When adding an Storing-Mode P-Route to the main RPL Instance, the 898 Root MUST set the RPLInstanceID field of the P-DAO message (see 899 section 6.4.1. of [RPL]) to the RPLInstanceID of the main DODAG, 900 and MUST NOT use the DODAGID field. A Projected Route provides a 901 longer match to the Target Address than the default route via the 902 Root, so it is preferred. 904 Once the Projected Route is installed, the intermediate nodes 905 listed in the SF-VIO after first one (i.e. The ingress) can be 906 elided from the RH in packets sent along the Segment signaled in 907 the P-DAO. The resulting loose source routing header indicates 908 (one of) the Target(s) as the next entry after the ingress. 910 * The Root MAY also use P-DAO messages to install a specific (say, 911 Traffic Engineered) path as a Serial or as a Complex Track, to a 912 particular endpoint that is the Track Egress. In that case, the 913 Root MUST install a Local RPL Instance (see section 5 of [RPL]), 914 and the Local RPLInstanceID is called TrackID. 916 In that case, the TrackID MUST be unique for the Global Unique 917 IPv6 Address (GUA) or Unique-Local Address (ULA) of the Track 918 Ingress that serves as DODAGID for the Track. The Track Ingress 919 owns the namespace of its TrackIDs, so it can pick any unused 920 value to request a new Track with a PDR. The Root is aware of all 921 the active Tracks, so it can also pick any unused value to form 922 Tracks without a PDR. To avoid a collision of the Root and the 923 Track Ingress picking the same value at the same time, it is 924 RECOMMENDED that the Track Ingress starts allocating the ID value 925 of the Local RPLInstanceID (see section 5.1. of [RPL]) used as 926 TrackIDs with the value 0 incrementing, while the Root starts with 927 63 decrementing. 929 This way, a Track is uniquely identified by the tuple (DODAGID, 930 TrackID) where the TrackID is always represented with the D flag 931 set to 0. 933 The Track Egress Address and the TrackID MUST be signaled in the 934 P-DAO message as shown in Figure 1. 936 7.3. Installing a Track 938 A Storing-Mode P-DAO contains an SF-VIO that signals the strict 939 sequence of consecutive nodes to form a segment between a segment 940 ingress and a segment egress (both included). It installs a route of 941 a higher precedence along the segment towards the Targets indicated 942 in the Target Options. The segment is included in a DODAG indicated 943 by the P-DAO Base Object, that may be the one formed by the main RPL 944 Instance, or a Track associated with a local RPL Instance. A Track 945 Egress is signaled as a Target in the P-DAO, and as the last entry is 946 an SF-VIO of a last segment towards that Egress. 948 A Non-Storing-Mode P-DAO signals a strict or loose sequence of nodes 949 between the Track Ingress (excluded) and a Track Egress (included). 950 It installs a source-routed path of a higher precedence within the 951 Track indicated by the P-DAO Base Object, towards the Targets 952 indicated in the Target Options. The source-routed path requires a 953 Source-Routing header which implies an encapsulation to add the SRH 954 to an existing packet. 956 The next entry in the sequence must be either a neighbor of the 957 previous entry, or reachable as a Target via another Projected Route, 958 either Storing or Non-Storing. If it is reachable over a Storing 959 Mode Projected Route, the next entry in the loose sequence is the 960 Target of a previous segment and the ingress of a next segment; the 961 segments are associated with the same Track, which avoids the need of 962 an encapsulation. Conversely, if it is reachable over a Non-Storing 963 Mode Projected Route, the next loose source routed hop of the inner 964 Track is a Target of a previous Track and the ingress of a next 965 Track, which requires a de- and a re-encapsulation. 967 A Serial Track is installed by a single Projected Routes that signals 968 the sequence of consecutive nodes, either in Storing or Non-Storing 969 Mode. If can be a loose Non-Storing Mode Projected Route, in which 970 case the next loose entry must recursively be reached over a Serial 971 Track. 973 A Complex Track can be installed as a collection of Projected Routes 974 with the same DODAGID and Track ID. The Ingress of a Non-Storing 975 Mode Projected Route must be the owner of the DODAGID. The Ingress 976 of a Storing Mode Projected Route must be either the owner of the 977 DODAGID, or the egress of a preceding Storing Mode Projected Route in 978 the same Track. In the latter case, the Targets of the Projected 979 Route must be Targets of the preceding Projected Route to ensure that 980 they are visible from the track Ingress. 982 7.3.1. Storing-Mode P-Route 984 Profile 1 extends RPL operation in a Non-Storing Mode network with 985 Storing-Mode Projected Routes that install segments along the main 986 DODAG and enable to loose source routing between the Root and the 987 targets. 989 7.3.1.1. Installing a Storing-Mode P-Route 991 As illustrated in Figure 9, a P-DAO that carries a SF-VIO enables the 992 Root to install a stateful route towards a collection of Targets 993 along a Segment between a Track Ingress and a Track Egress using a 994 projected DAO Message. 996 ------+--------- 997 | Internet 998 | 999 +-----+ 1000 | | Border Router 1001 | | (RPL Root) 1002 +-----+ | ^ | 1003 | | DAO | ACK | 1004 o o o o | | | 1005 o o o o o o o o o | ^ | Projected . 1006 o o o o o o o o o o | | DAO | Route . 1007 o o o o o o o o o | ^ | . 1008 o o o o o o o o v | DAO v . 1009 o o LLN o o o | 1010 o o o o o Loose Source Route Path | 1011 o o o o From Root To Destination v 1013 Figure 9: Projecting a route 1015 In order to install the relevant routing state along the Segment , 1016 the Root sends a unicast P-DAO message to the Track Egress router of 1017 the routing Segment that is being installed. The P-DAO message 1018 contains a SF-VIO with the direct sequence of Via Addresses. The SF- 1019 VIO follows one or more RTOs indicating the Targets to which the 1020 Track leads. The SF-VIO contains a Segment Lifetime for which the 1021 state is to be maintained. 1023 The Root sends the P-DAO directly to the egress node of the Segment. 1024 In that P-DAO, the destination IP address matches the last Via 1025 Address in the SF-VIO. This is how the egress recognizes its role. 1026 In a similar fashion, the ingress node recognizes its role as it 1027 matches first Via Address in the SF-VIO. 1029 The Egress node of the Segment is the only node in the path that does 1030 not install a route in response to the P-DAO; it is expected to be 1031 already able to route to the Target(s) on its own. If one of the 1032 Targets is not known, the node MUST answer to the Root with a 1033 negative DAO-ACK listing the Target(s) that could not be located 1034 (suggested status 10 to be confirmed by IANA). 1036 If the egress node can reach all the Targets, then it forwards the 1037 P-DAO with unchanged content to its loose predecessor in the Segment 1038 as indicated in the list of Via Information options, and recursively 1039 the message is propagated unchanged along the sequence of routers 1040 indicated in the P-DAO, but in the reverse order, from egress to 1041 ingress. 1043 The address of the predecessor to be used as destination of the 1044 propagated DAO message is found in the Via Address the precedes the 1045 one that contain the address of the propagating node, which is used 1046 as source of the message. 1048 Upon receiving a propagated DAO, all except the Egress Router MUST 1049 install a route towards the DAO Target(s) via their successor in the 1050 SF-VIO. The router MAY install additional routes towards the VIA 1051 Addresses that are the SF-VIO after the next one, if any, but in case 1052 of a conflict or a lack of resource, the route(s) to the Target(s) 1053 have precedence. 1055 If a router cannot reach its predecessor in the SF-VIO, the router 1056 MUST answer to the Root with a negative DAO-ACK indicating the 1057 successor that is unreachable (suggested status 11 to be confirmed by 1058 IANA). 1060 The process continues till the P-DAO is propagated to ingress router 1061 of the Segment, which answers with a DAO-ACK to the Root. The Root 1062 always expects a DAO-ACK, either from the Track Ingress with a 1063 positive status or from any node along the segment with a negative 1064 status. If the DAO-ACK is not received, the Root may retry the DAO 1065 with the same TID, or tear down the route. 1067 7.3.1.2. Maintaining and Tearing Down a Storing-Mode P-Route 1069 A Segment Lifetime of 0 in a VIO is used to clean up the state. The 1070 P-DAO is forwarded as described above, but the DAO is interpreted as 1071 a No-Path DAO and results in cleaning up existing state as opposed to 1072 refreshing an existing one or installing a new one. 1074 Note that the continuity of the segment may be broken; this happens 1075 if the bidirectional connectivity between contiguous hops of the 1076 segment is lost. In that case the Root needs to send the projected 1077 DAO to one or more intermediate node(s) as opposed to the egress 1078 node, indicating a portion of segment that is being replaced or 1079 cleaned up. At the extreme, the P-DAO updates only one node, in 1080 which case it contains only one VIO. 1082 In case of a forwarding error along an Storing-Mode P-Route, the node 1083 that fails to forward SHOULD send an ICMP error with a code "Error in 1084 Projected Route" to the Root. Failure to do so may result in packet 1085 loss and wasted resources along the Projected Route that is broken. 1087 7.3.2. Non-Storing-Mode P-Route 1089 As illustrated in Figure 10, a P-DAO that carries an SR-VIO enables 1090 the Root to install a source-routed path from a Track Ingress towards 1091 a Target along the main DODAG. 1093 ------+--------- 1094 | Internet 1095 | 1096 +-----+ 1097 | | Border Router 1098 | | (RPL Root) 1099 +-----+ | P ^ ACK 1100 | Track | DAO | 1101 o o o o Ingress X V | X 1102 o o o o o o o X o X Source 1103 o o o o o o o o X o o X Routed 1104 o o ° o o o o X o X Segment 1105 o o o o o o o o X Track X 1106 o o o o o Egress 1108 o o o o 1109 o o o o 1110 destination 1112 LLN 1114 Figure 10: Projecting a Non-Storing Route 1116 When forwarding a packet to a destination for which the router 1117 determines that routing happens via a Track Target, the router 1118 inserts the Source Routing Header in the packet with the final 1119 destination at the Track Egress. 1121 In order to signal the Segment, the router encapsulates the packet 1122 with an IP-in-IP header and a Routing Header as follows: 1124 * In the uncompressed form the source of the packet is this router, 1125 the destination is the first Via Address in the SR-VIO, and the RH 1126 is a Source Routing Header (SRH) [RFC6554] that contains the list 1127 of the remaining Via Addresses terminating by the Track Egress. 1129 * The preferred alternate in a network where 6LoWPAN Header 1130 Compression [RFC6282] is used is to leverage "IPv6 over Low-Power 1131 Wireless Personal Area Network (6LoWPAN) Paging Dispatch" 1132 [RFC8025] to compress the RPL artifacts as indicated in [RFC8138]. 1134 In that case, the source routed header is the exact copy of the 1135 (chain of) SRH-6LoRH found in the SR-VIO, also terminating by the 1136 Track Egress. The RPI-6LoRH is appended next, followed by an IP- 1137 in-IP 6LoRH Header that indicates the Ingress Router in the 1138 Encapsulator Address field, see as a similar case Figure 20 of 1139 [TURN-ON_RFC8138]. 1141 In the case of a loose source-routed path, there MUST be either a 1142 neighbor that is adjacent to the loose next hop, on which case the 1143 packet is forwarded to that neighbor, or another Track to the loose 1144 next hop for which this node is Ingress; in the latter case, another 1145 encapsulation takes place and the process possibly recurses; 1146 otherwise the packet is dropped. 1148 In case of a forwarding error along a Source Route path, the node 1149 that fails to forward SHOULD send an ICMP error with a code "Error in 1150 Source Routing Header" back to the source of the packet, as described 1151 in section 11.2.2.3. of [RPL]. Upon this message, the encapsulating 1152 node SHOULD stop using the source route path for a period of time and 1153 it SHOULD send an ICMP message with a Code "Error in Projected Route" 1154 to the Root. Failure to follow these steps may result in packet loss 1155 and wasted resources along the source route path that is broken. 1157 7.4. Forwarding Along a Track 1159 This draft leverages the RPL Forwarding model follows: 1161 * In the data packets, the Track DODAGID and the TrackID MUST be 1162 respectively signaled as the IPv6 Source Address and the 1163 RPLInstanceID field of the RPI that MUST be placed in the outer 1164 chain of IPv6 Headers. 1166 The RPI carries a local RPLInstanceID called the TrackID, which, 1167 in association with the DODAGID, indicates the Track along which 1168 the packet is forwarded. 1170 The D flag in the RPLInstanceID MUST be set to 0 to indicate that 1171 the source address in the IPv6 header is set ot the DODAGID, more 1172 in Section 7.4. 1174 * This draft conforms the principles of [USEofRPLinfo] with regards 1175 to packet forwarding and encapsulation along a Track. 1177 - In that case, the Track is the DODAG, the Track Ingress is the 1178 Root, and the Track Egress is a RAL, and neighbors of the Track 1179 Egress that can be reached via the Track are RULs. The 1180 encapsulation rules in [USEofRPLinfo] apply. 1182 - If the Track Ingress is the originator of the packet and the 1183 Track Egress is the destination of the packet, there is no need 1184 for an encapsulation. 1186 - So the Track Ingress must encapsulate the traffic that it did 1187 not originate, and add an RPI in any fashion. 1189 A packet that is being routed over the RPL Instance associated to 1190 a first Non-Storing Mode Track MAY be placed (encapsulated) in a 1191 second Track to cover one loose hop of the first Track. On the 1192 other hand, a Storing Mode Track must be strict and a packet that 1193 it placed in a Storing Mode Track MUST follow that Track till the 1194 Track Egress. 1196 When a Track Egress extracts a packet from a Track (decapsulates 1197 the packet), the Destination of the inner packet MUST be either 1198 this node or a direct neighbor, or a Target of another Segment of 1199 the same Track for which this node is ingress, otherwise the 1200 packet MUST be dropped. 1202 All properties of a Track operations are inherited form the main RPL 1203 Instance that is used to install the Track. For instance, the use of 1204 compression per [RFC8138] is determined by whether it is used in the 1205 main instance, e.g., by setting the "T" flag [TURN-ON_RFC8138] in the 1206 RPL configuration option. 1208 8. Profiles 1210 This document provides a set of tools that may or may not be needed 1211 by an implementation depending on the type of application it serves. 1212 This sections described profiles that can be implemented separately 1213 and can be used to discriminate what an implementation can and cannot 1214 do. 1216 Profile 0 Profile 0 is the legacy support of [RPL] Non-Storing Mode. 1217 It provides the minimal common functionality that must be 1218 implemented as a prerequisite to all the Track-supporting 1219 profiles. The other Profiles extend Profile 0 with selected 1220 capabilities that this specification introduces on top. 1222 Profile 1 (Storing-Mode P-Route Segments along the main DODAG) Profi 1223 le 1 does not create new paths; it combines Storing and Non- 1224 Storing Modes to balance the size of the routing header in the 1225 packet and the amount of state in the intermediate routers in a 1226 Non-Storing Mode RPL DODAG. 1228 Profile 2 (Non-Storing-Mode P-Route Segments along the main DODAG) P 1229 rofile 2 extends Profile 0 with Strict Source-Routing Non-Storing- 1230 Mode Projected Routes along the main DODAG. Profile 2 provides 1231 the same capability to compress the SRH in packets down the main 1232 DODAG as Profile 1, but it require an encapsulation, in order to 1233 insert an additional SRH between the loose source routing hops. 1235 Profile 3 Profile 3 and above build Tracks that do not necessarily 1236 follow the main DODAG. In order to form the best path possible, 1237 those Profiles require the support of Sibling Information Option 1238 to inform the Root of additional possible hops. Profile 3 extends 1239 Profile 1 with additional Storing-Mode Projected Routes that 1240 install segments that do not follow the main DODAG. If the 1241 Segment Ingress (in the SF-VIO) is the same as the IPv6 Address of 1242 the Track Ingress (in the projected DAO base Object), the P-DAO 1243 creates an implicit Track between the Segment Ingress and the 1244 Segment Egress. 1246 Profile 4 Profile 4 extends Profile 2 with Strict Source-Routing 1247 Non-Storing-Mode Projected Routes to form Tracks inside the main 1248 DODAG. A Track is formed as one or more strict source source 1249 routed paths between the Root that is the Track Ingress, and the 1250 Track Egress that is the last node 1252 Profile 5 Profile 5 Combines Profile 4 with Profile 1 and enables to 1253 loose source routing between the Ingress and the Egress of the 1254 Track. As in Profile 1, Storing-Mode Projected Routes connect the 1255 dots in the loose source route. 1257 Profile 6 Profile 6 Combines Profile 4 with Profile 2 and also 1258 enables to loose source routing between the Ingress and the Egress 1259 of the Track. 1261 9. Example Track Signaling 1263 The remainder of the section provides an example of how a Track can 1264 be signaled 1266 ===> F 1267 A ===> B ===> C ===> D===> E < 1268 ===> G 1270 Figure 11: Reference Track 1272 A is Track ingress, E is track Egress. C is stitching point. F and 1273 G are E's neighbors, "external" to the Track, and reachable from A 1274 over the Track A->E. 1276 In a general manner we want: 1278 * P-DAO 1 signals C==>B==>E 1280 * P-DAO 2 signals A==>B==>C 1282 * P-DAO 3 signals F and G via the A==>E Track 1283 P-DAO 3 being loose, it can only be non-storing. Note that since the 1284 Root is always the ingress of a Track, and all SR-VIOs are now Track, 1285 the Root being signaled in the DAO base object can now be elided in 1286 the VIA list in SR-VIO. This enables the construction by the main 1287 root of the RFC 8138 optimized SRH-6LoRH in the SR-VIO, to be placed 1288 as is in the packet by the Root. 1290 9.1. Using Storing-Mode Segments 1292 A==>B==>C and C==>D==>E are segments of a same Track. Note that the 1293 storing mode signaling imposes strict continuity in a segment. One 1294 benefit of strict routing is that loops are avoided along the Track. 1296 9.1.1. Stitched Segments 1298 Storing-Mode P-DAO 1 and 2 are sent to E and C, as follows: 1300 +===============+==============+==============+ 1301 | Field | P-DAO 1 to E | P-DAO 2 to C | 1302 +===============+==============+==============+ 1303 | Mode | Storing | Storing | 1304 +---------------+--------------+--------------+ 1305 | Track Ingress | A | A | 1306 +---------------+--------------+--------------+ 1307 | TrackID | (A, 129) | (A, 129) | 1308 +---------------+--------------+--------------+ 1309 | VIO | C, D, E | A, B, C | 1310 +---------------+--------------+--------------+ 1311 | Targets | E, F, G | E, F, G | 1312 +---------------+--------------+--------------+ 1314 Table 1: P-DAO Messages 1316 As a result the RIBs are set as follows: 1318 +======+=============+=========+=============+==========+ 1319 | Node | Destination | Origin | Next Hop(s) | TrackID | 1320 +======+=============+=========+=============+==========+ 1321 | E | F, G | P-DAO 1 | Neighbor | (A, 129) | 1322 +------+-------------+---------+-------------+----------+ 1323 | D | E | P-DAO 1 | Neighbor | (A, 129) | 1324 +------+-------------+---------+-------------+----------+ 1325 | " | F, G | P-DAO 1 | E | (A, 129) | 1326 +------+-------------+---------+-------------+----------+ 1327 | C | D | P-DAO 1 | Neighbor | (A, 129) | 1328 +------+-------------+---------+-------------+----------+ 1329 | " | E, F, G | P-DAO 1 | D | (A, 129) | 1330 +------+-------------+---------+-------------+----------+ 1331 | B | C | P-DAO 2 | Neighbor | (A, 129) | 1332 +------+-------------+---------+-------------+----------+ 1333 | " | E, F, G | P-DAO 2 | C | (A, 129) | 1334 +------+-------------+---------+-------------+----------+ 1335 | A | B | P-DAO 2 | Neighbor | (A, 129) | 1336 +------+-------------+---------+-------------+----------+ 1337 | A | E, F, G | P-DAO 2 | B | (A, 129) | 1338 +------+-------------+---------+-------------+----------+ 1340 Table 2: RIB setting 1342 E recognizes that it is the Track Egress because it is both a Target 1343 and a Segment Endpoint. 1345 Packets originated by A to E, F, or G, do not require an 1346 encapsulation. In any fashion, the outer headers of the packets that 1347 are forwarded along the Track have the following settings: 1349 +========+===================+===================+================+ 1350 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1351 +========+===================+===================+================+ 1352 | Outer | A | E, F or G | (A, 129) | 1353 +--------+-------------------+-------------------+----------------+ 1354 | Inner | X != A | E, F or G | N/A | 1355 +--------+-------------------+-------------------+----------------+ 1357 Table 3: Packet header settings 1359 As an example, say that A has a packet for F. Using the RIB above: 1361 * From P-DAO 2: A forwards to B and B forwards to C. 1363 * From P-DAO 1: C forwards to D and D forwards to E. 1365 * From Neighbor Cache Entry: C delivers the packet to F. 1367 9.1.2. External routes 1369 Storing-Mode P-DAO 1 and 2, and Non-Storing-Mode P-DAO 3, are sent to 1370 E, C and A, respectively, as follows: 1372 +===============+==============+==============+==============+ 1373 | | P-DAO 1 to E | P-DAO 2 to C | P-DAO 3 to A | 1374 +===============+==============+==============+==============+ 1375 | Mode | Storing | Storing | Non-Storing | 1376 +---------------+--------------+--------------+--------------+ 1377 | Track Ingress | A | A | A | 1378 +---------------+--------------+--------------+--------------+ 1379 | TrackID | (A, 129) | (A, 129) | (A, 129) | 1380 +---------------+--------------+--------------+--------------+ 1381 | VIO | C, D, E | A, B, C | E | 1382 +---------------+--------------+--------------+--------------+ 1383 | Targets | E | E | F, G | 1384 +---------------+--------------+--------------+--------------+ 1386 Table 4: P-DAO Messages 1388 As a result the RIBs are set as follows: 1390 +======+=============+=========+=============+==========+ 1391 | Node | Destination | Origin | Next Hop(s) | TrackID | 1392 +======+=============+=========+=============+==========+ 1393 | E | F, G | P-DAO 1 | Neighbor | (A, 129) | 1394 +------+-------------+---------+-------------+----------+ 1395 | D | E | P-DAO 1 | Neighbor | (A, 129) | 1396 +------+-------------+---------+-------------+----------+ 1397 | C | D | P-DAO 1 | Neighbor | (A, 129) | 1398 +------+-------------+---------+-------------+----------+ 1399 | " | E | P-DAO 1 | D | (A, 129) | 1400 +------+-------------+---------+-------------+----------+ 1401 | B | C | P-DAO 2 | Neighbor | (A, 129) | 1402 +------+-------------+---------+-------------+----------+ 1403 | " | E | P-DAO 2 | C | (A, 129) | 1404 +------+-------------+---------+-------------+----------+ 1405 | A | B | P-DAO 2 | Neighbor | (A, 129) | 1406 +------+-------------+---------+-------------+----------+ 1407 | A | E | P-DAO 2 | B | (A, 129) | 1408 +------+-------------+---------+-------------+----------+ 1409 | A | F, G | P-DAO 3 | E | (A, 129) | 1410 +------+-------------+---------+-------------+----------+ 1412 Table 5: RIB setting 1414 Packets from A to E do not require an encapsulation. In any fashion, 1415 the outer headers of the packets that are forwarded along the Track 1416 have the following settings: 1418 +========+===================+====================+================+ 1419 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1420 +========+===================+====================+================+ 1421 | Outer | A | E | (A, 129) | 1422 +--------+-------------------+--------------------+----------------+ 1423 | Inner | X | E (X != A), F or G | N/A | 1424 +--------+-------------------+--------------------+----------------+ 1426 Table 6: Packet header settings 1428 As an example, say that A has a packet for F. Using the RIB above: 1430 * From P-DAO 3: A encapsulates the packet the Track signaled by 1431 P-DAO 3, with the outer header above. Now the packet destination 1432 is E. 1434 * From P-DAO 2: A forwards to B and B forwards to C. 1436 * From P-DAO 1: C forwards to D and D forwards to E; E decapsulates 1437 the packet. 1439 * From Neighbor Cache Entry: C delivers packets to F or G. 1441 9.1.3. Segment Routing 1443 Storing-Mode P-DAO 1 and 2, and Non-Storing-Mode P-DAO 3, are sent to 1444 E, B and A, respectively, as follows: 1446 +===============+==============+==============+==============+ 1447 | | P-DAO 1 to E | P-DAO 2 to B | P-DAO 3 to A | 1448 +===============+==============+==============+==============+ 1449 | Mode | Storing | Storing | Non-Storing | 1450 +---------------+--------------+--------------+--------------+ 1451 | Track Ingress | A | A | A | 1452 +---------------+--------------+--------------+--------------+ 1453 | TrackID | (A, 129) | (A, 129) | (A, 129) | 1454 +---------------+--------------+--------------+--------------+ 1455 | VIO | C, D, E | A, B | C, E | 1456 +---------------+--------------+--------------+--------------+ 1457 | Targets | E | B, C | F, G | 1458 +---------------+--------------+--------------+--------------+ 1460 Table 7: P-DAO Messages 1462 As a result the RIBs are set as follows: 1464 +======+=============+=========+=============+==========+ 1465 | Node | Destination | Origin | Next Hop(s) | TrackID | 1466 +======+=============+=========+=============+==========+ 1467 | E | F, G | P-DAO 1 | Neighbor | (A, 129) | 1468 +------+-------------+---------+-------------+----------+ 1469 | D | E | P-DAO 1 | Neighbor | (A, 129) | 1470 +------+-------------+---------+-------------+----------+ 1471 | C | D | P-DAO 1 | Neighbor | (A, 129) | 1472 +------+-------------+---------+-------------+----------+ 1473 | " | E | P-DAO 1 | D | (A, 129) | 1474 +------+-------------+---------+-------------+----------+ 1475 | B | C | P-DAO 2 | Neighbor | (A, 129) | 1476 +------+-------------+---------+-------------+----------+ 1477 | A | B | P-DAO 2 | Neighbor | (A, 129) | 1478 +------+-------------+---------+-------------+----------+ 1479 | " | C | P-DAO 2 | B | (A, 129) | 1480 +------+-------------+---------+-------------+----------+ 1481 | " | E, F, G | P-DAO 3 | C, E | (A, 129) | 1482 +------+-------------+---------+-------------+----------+ 1484 Table 8: RIB setting 1486 Packets from A to E do not require an encapsulation, but carry a SRH 1487 via C. In any fashion, the outer headers of the packets that are 1488 forwarded along the Track have the following settings: 1490 +========+===================+====================+================+ 1491 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1492 +========+===================+====================+================+ 1493 | Outer | A | C till C then E | (A, 129) | 1494 +--------+-------------------+--------------------+----------------+ 1495 | Inner | X | E (X != A), F or G | N/A | 1496 +--------+-------------------+--------------------+----------------+ 1498 Table 9: Packet header settings 1500 As an example, say that A has a packet for F. Using the RIB above: 1502 * From P-DAO 3: A encapsulates the packet the Track signaled by 1503 P-DAO 3, with the outer header above. Now the destination in the 1504 IPv6 Header is C, and a SRH signals the final destination is E. 1506 * From P-DAO 2: A forwards to B and B forwards to C. 1508 * From P-DAO 3: C processes the SRH and sets the destination in the 1509 IPv6 Header to E. 1511 * From P-DAO 1: C forwards to D and D forwards to E; E decapsulates 1512 the packet. 1514 * From the Neighbor Cache Entry: C delivers packets to F or G. 1516 9.2. Using Non-Storing-Mode joining Tracks 1518 A==>B==>C and C==>D==>E are Tracks expressed as non-storing P-DAOs. 1520 9.2.1. Stitched Tracks 1522 Non-Storing Mode P-DAO 1 and 2 are sent to C and A respectively, as 1523 follows: 1525 +===============+==============+==============+ 1526 | | P-DAO 1 to C | P-DAO 2 to A | 1527 +===============+==============+==============+ 1528 | Mode | Non-Storing | Non-Storing | 1529 +---------------+--------------+--------------+ 1530 | Track Ingress | C | A | 1531 +---------------+--------------+--------------+ 1532 | TrackID | (C, 131) | (A, 129) | 1533 +---------------+--------------+--------------+ 1534 | VIO | D, E | B, C | 1535 +---------------+--------------+--------------+ 1536 | Targets | F, G | E, F, G | 1537 +---------------+--------------+--------------+ 1539 Table 10: P-DAO Messages 1541 As a result the RIBs are set as follows: 1543 +======+=============+=========+=============+==========+ 1544 | Node | Destination | Origin | Next Hop(s) | TrackID | 1545 +======+=============+=========+=============+==========+ 1546 | E | F, G | ND | Neighbor | Any | 1547 +------+-------------+---------+-------------+----------+ 1548 | D | E | ND | Neighbor | Any | 1549 +------+-------------+---------+-------------+----------+ 1550 | C | D | ND | Neighbor | Any | 1551 +------+-------------+---------+-------------+----------+ 1552 | " | E, F, G | P-DAO 1 | D, E | (C, 131) | 1553 +------+-------------+---------+-------------+----------+ 1554 | B | C | ND | Neighbor | Any | 1555 +------+-------------+---------+-------------+----------+ 1556 | A | B | ND | Neighbor | Any | 1557 +------+-------------+---------+-------------+----------+ 1558 | " | C, E, F, G | P-DAO 2 | B, C | (A, 129) | 1559 +------+-------------+---------+-------------+----------+ 1561 Table 11: RIB setting 1563 Packets from A to E, F and G do not require an encapsulation, though 1564 it is preferred that A encapsulates and C decapsulates. Either way, 1565 they carry a SRH via B and C, and C needs to encapsulate to E, F, or 1566 G to add an SRH via D and E. The encapsulating headers of packets 1567 that are forwarded along the Track between C and E have the following 1568 settings: 1570 +========+===================+===================+================+ 1571 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1572 +========+===================+===================+================+ 1573 | Outer | C | D till D then E | (C, 131) | 1574 +--------+-------------------+-------------------+----------------+ 1575 | Inner | X | E, F, or G | N/A | 1576 +--------+-------------------+-------------------+----------------+ 1578 Table 12: Packet header settings 1580 As an example, say that A has a packet for F. Using the RIB above: 1582 * From P-DAO 2: A encapsulates the packet with destination of F in 1583 the Track signaled by P-DAO 2. The outer header has source A, 1584 destination B, an SRH that indicates C as the next loose hop, and 1585 a RPI indicating a TrackId of 129 from A's namespace. 1587 * From the SRH: Packets forwarded by B have source A, destination C 1588 , a consumed SRH, and a RPI indicating a TrackId of 129 from A's 1589 namespace. C decapsulates. 1591 * From P-DAO 1: C encapsulates the packet with destination of F in 1592 the Track signaled by P-DAO 1. The outer header has source C, 1593 destination D, an SRH that indicates E as the next loose hop, and 1594 a RPI indicating a TrackId of 131 from C's namespace. E 1595 decapsulates. 1597 9.2.2. External routes 1599 Non-Storing Mode P-DAO 1 is sent to C and Non-Storing Mode P-DAO 2 1600 and 3 are sent A, as follows: 1602 +===============+==============+==============+==============+ 1603 | | P-DAO 1 to C | P-DAO 2 to A | P-DAO 3 to A | 1604 +===============+==============+==============+==============+ 1605 | Mode | Non-Storing | Non-Storing | Non-Storing | 1606 +---------------+--------------+--------------+--------------+ 1607 | Track Ingress | C | A | A | 1608 +---------------+--------------+--------------+--------------+ 1609 | TrackID | (C, 131) | (A, 129) | (A, 141) | 1610 +---------------+--------------+--------------+--------------+ 1611 | VIO | D, E | B, C | E | 1612 +---------------+--------------+--------------+--------------+ 1613 | Targets | E | E | F, G | 1614 +---------------+--------------+--------------+--------------+ 1616 Table 13: P-DAO Messages 1618 As a result the RIBs are set as follows: 1620 +======+=============+=========+=============+==========+ 1621 | Node | Destination | Origin | Next Hop(s) | TrackID | 1622 +======+=============+=========+=============+==========+ 1623 | E | F, G | ND | Neighbor | Any | 1624 +------+-------------+---------+-------------+----------+ 1625 | D | E | ND | Neighbor | Any | 1626 +------+-------------+---------+-------------+----------+ 1627 | C | D | ND | Neighbor | Any | 1628 +------+-------------+---------+-------------+----------+ 1629 | " | E | P-DAO 1 | D, E | (C, 131) | 1630 +------+-------------+---------+-------------+----------+ 1631 | B | C | ND | Neighbor | Any | 1632 +------+-------------+---------+-------------+----------+ 1633 | A | B | ND | Neighbor | Any | 1634 +------+-------------+---------+-------------+----------+ 1635 | " | C, E | P-DAO 2 | B, C | (A, 129) | 1636 +------+-------------+---------+-------------+----------+ 1637 | " | F, G | P-DAO 3 | E | (A, 141) | 1638 +------+-------------+---------+-------------+----------+ 1640 Table 14: RIB setting 1642 The encapsulating headers of packets that are forwarded along the 1643 Track between C and E have the following settings: 1645 +========+===================+===================+================+ 1646 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1647 +========+===================+===================+================+ 1648 | Outer | C | D till D then E | (C, 131) | 1649 +--------+-------------------+-------------------+----------------+ 1650 | Middle | A | E | (A, 141) | 1651 +--------+-------------------+-------------------+----------------+ 1652 | Inner | X | E, F or G | N/A | 1653 +--------+-------------------+-------------------+----------------+ 1655 Table 15: Packet header settings 1657 As an example, say that A has a packet for F. Using the RIB above: 1659 * From P-DAO 3: A encapsulates the packet with destination of F in 1660 the Track signaled by P-DAO 3. The outer header has source A, 1661 destination E, and a RPI indicating a TrackId of 141 from A's 1662 namespace. This recurses with: 1664 * From P-DAO 2: A encapsulates the packet with destination of E in 1665 the Track signaled by P-DAO 2. The outer header has source A, 1666 destination B, an SRH that indicates C as the next loose hop, and 1667 a RPI indicating a TrackId of 129 from A's namespace. 1669 * From the SRH: Packets forwarded by B have source A, destination C 1670 , a consumed SRH, and a RPI indicating a TrackId of 129 from A's 1671 namespace. C decapsulates. 1673 * From P-DAO 1: C encapsulates the packet with destination of E in 1674 the Track signaled by P-DAO 1. The outer header has source C, 1675 destination D, an SRH that indicates E as the next loose hop, and 1676 a RPI indicating a TrackId of 131 from C's namespace. E 1677 decapsulates. 1679 9.2.3. Segment Routing 1681 Non-Storing Mode P-DAO 1 is sent to C and Non-Storing Mode P-DAO 2 1682 and 3 are sent A, as follows: 1684 +===============+==============+==============+==============+ 1685 | | P-DAO 1 to C | P-DAO 2 to A | P-DAO 3 to A | 1686 +===============+==============+==============+==============+ 1687 | Mode | Non-Storing | Non-Storing | Non-Storing | 1688 +---------------+--------------+--------------+--------------+ 1689 | Track Ingress | C | A | A | 1690 +---------------+--------------+--------------+--------------+ 1691 | TrackID | (C, 131) | (A, 129) | (A, 141) | 1692 +---------------+--------------+--------------+--------------+ 1693 | VIO | D, E | B | C, E | 1694 +---------------+--------------+--------------+--------------+ 1695 | Targets | | C | F, G | 1696 +---------------+--------------+--------------+--------------+ 1698 Table 16: P-DAO Messages 1700 As a result the RIBs are set as follows: 1702 +======+=============+=========+=============+==========+ 1703 | Node | Destination | Origin | Next Hop(s) | TrackID | 1704 +======+=============+=========+=============+==========+ 1705 | E | F, G | ND | Neighbor | Any | 1706 +------+-------------+---------+-------------+----------+ 1707 | D | E | ND | Neighbor | Any | 1708 +------+-------------+---------+-------------+----------+ 1709 | C | D | ND | Neighbor | Any | 1710 +------+-------------+---------+-------------+----------+ 1711 | " | E | P-DAO 1 | D, E | (C, 131) | 1712 +------+-------------+---------+-------------+----------+ 1713 | B | C | ND | Neighbor | Any | 1714 +------+-------------+---------+-------------+----------+ 1715 | A | B | ND | Neighbor | Any | 1716 +------+-------------+---------+-------------+----------+ 1717 | " | C | P-DAO 2 | B, C | (A, 129) | 1718 +------+-------------+---------+-------------+----------+ 1719 | " | E, F, G | P-DAO 3 | C, E | (A, 141) | 1720 +------+-------------+---------+-------------+----------+ 1722 Table 17: RIB setting 1724 The encapsulating headers of packets that are forwarded along the 1725 Track between A and B have the following settings: 1727 +========+===================+===================+================+ 1728 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1729 +========+===================+===================+================+ 1730 | Outer | A | B till D then E | (A, 129) | 1731 +--------+-------------------+-------------------+----------------+ 1732 | Middle | A | C | (A, 141) | 1733 +--------+-------------------+-------------------+----------------+ 1734 | Inner | X | E, F or G | N/A | 1735 +--------+-------------------+-------------------+----------------+ 1737 Table 18: Packet header settings 1739 The encapsulating headers of packets that are forwarded along the 1740 Track between B and C have the following settings: 1742 +========+===================+===================+================+ 1743 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1744 +========+===================+===================+================+ 1745 | Outer | A | C | (A, 141) | 1746 +--------+-------------------+-------------------+----------------+ 1747 | Inner | X | E, F or G | N/A | 1748 +--------+-------------------+-------------------+----------------+ 1750 Table 19: Packet header settings 1752 The encapsulating headers of packets that are forwarded along the 1753 Track between C and E have the following settings: 1755 +========+===================+===================+================+ 1756 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1757 +========+===================+===================+================+ 1758 | Outer | C | D till D then E | (C, 131) | 1759 +--------+-------------------+-------------------+----------------+ 1760 | Middle | A | E | (A, 141) | 1761 +--------+-------------------+-------------------+----------------+ 1762 | Inner | X | E, F or G | N/A | 1763 +--------+-------------------+-------------------+----------------+ 1765 Table 20: Packet header settings 1767 As an example, say that A has a packet for F. Using the RIB above: 1769 * From P-DAO 3: A encapsulates the packet with destination of F in 1770 the Track signaled by P-DAO 3. The outer header has source A, 1771 destination C, an SRH that indicates E as the next loose hop, and 1772 a RPI indicating a TrackId of 141 from A's namespace. This 1773 recurses with: 1775 * From P-DAO 2: A encapsulates the packet with destination of C in 1776 the Track signaled by P-DAO 2. The outer header has source A, 1777 destination B, and a RPI indicating a TrackId of 129 from A's 1778 namespace. B decapsulates forwards to C based on a sibling 1779 connected route. 1781 * From the SRH: C consumes the SRH and makes the destination E. 1783 * From P-DAO 1: C encapsulates the packet with destination of E in 1784 the Track signaled by P-DAO 1. The outer header has source C, 1785 destination D, an SRH that indicates E as the next loose hop, and 1786 a RPI indicating a TrackId of 131 from C's namespace. E 1787 decapsulates. 1789 10. Security Considerations 1791 It is worth noting that with [RPL], every node in the LLN is RPL- 1792 aware and can inject any RPL-based attack in the network. This draft 1793 uses messages that are already present in RPL [RPL] with optional 1794 secured versions. The same secured versions may be used with this 1795 draft, and whatever security is deployed for a given network also 1796 applies to the flows in this draft. 1798 The LLN nodes depend on the 6LBR and the RPL participants for their 1799 operation. A trust model must be put in place to ensure that the 1800 right devices are acting in these roles, so as to avoid threats such 1801 as black-holing, (see [RFC7416] section 7). This trust model could 1802 be at a minimum based on a Layer-2 Secure joining and the Link-Layer 1803 security. This is a generic 6LoWPAN requirement, see Req5.1 in 1804 Appendix B.5 of [RFC8505]. 1806 In a general manner, the Security Considerations in [RPL], and 1807 [RFC7416] apply to this specification as well. The Link-Layer 1808 security is needed in particular to prevent Denial-Of-Service attacks 1809 whereby a rogue router creates a high churn in the RPL network by 1810 constantly injected forged P-DAO messages and using up all the 1811 available storage in the attacked routers. 1813 Additionally, the trust model could include a role validation (e.g., 1814 using a role-based authorization) to ensure that the node that claims 1815 to be a RPL Root is entitled to do so. That trust should propagate 1816 from egress to ingress in the case of a Storing Mode P-DAO. 1818 11. IANA Considerations 1820 11.1. New Elective 6LoWPAN Routing Header Type 1822 This document updates the IANA registry titled "Elective 6LoWPAN 1823 Routing Header Type" that was created for [RFC8138] and assigns the 1824 following value: 1826 +=======+=============+===============+ 1827 | Value | Description | Reference | 1828 +=======+=============+===============+ 1829 | 7 | P-RPI-6LoRH | This document | 1830 +-------+-------------+---------------+ 1832 Table 21: New Elective 6LoWPAN 1833 Routing Header Type 1835 11.2. New Critical 6LoWPAN Routing Header Type 1837 This document updates the IANA registry titled "Critical 6LoWPAN 1838 Routing Header Type" that was created for [RFC8138] and assigns the 1839 following value: 1841 +=======+=============+===============+ 1842 | Value | Description | Reference | 1843 +=======+=============+===============+ 1844 | 7 | P-RPI-6LoRH | This document | 1845 +-------+-------------+---------------+ 1847 Table 22: New Critical 6LoWPAN 1848 Routing Header Type 1850 11.3. New Subregistry For The RPL Option Flags 1852 IANA is required to create a subregistry for the 8-bit RPL Option 1853 Flags field, as detailed in Figure 2, under the "Routing Protocol for 1854 Low Power and Lossy Networks (RPL)" registry. The bits are indexed 1855 from 0 (leftmost) to 7. Each bit is tracked with the following 1856 qualities: 1858 * Bit number (counting from bit 0 as the most significant bit) 1860 * Indication When Set 1862 * Reference 1864 Registration procedure is "Standards Action" [RFC8126]. The initial 1865 allocation is as indicated in Table 26: 1867 +============+======================+===============+ 1868 | Bit number | Indication When Set | Reference | 1869 +============+======================+===============+ 1870 | 0 | Down 'O' | [RFC6553] | 1871 +------------+----------------------+---------------+ 1872 | 1 | Rank-Error (R) | [RFC6553] | 1873 +------------+----------------------+---------------+ 1874 | 2 | Forwarding-Error (F) | [RFC6553] | 1875 +------------+----------------------+---------------+ 1876 | 3 | Projected-Route (P) | This document | 1877 +------------+----------------------+---------------+ 1879 Table 23: Initial PDR Flags 1881 11.4. New RPL Control Codes 1883 This document extends the IANA Subregistry created by RFC 6550 for 1884 RPL Control Codes as indicated in Table 24: 1886 +======+=============================+===============+ 1887 | Code | Description | Reference | 1888 +======+=============================+===============+ 1889 | 0x09 | Projected DAO Request (PDR) | This document | 1890 +------+-----------------------------+---------------+ 1891 | 0x0A | PDR-ACK | This document | 1892 +------+-----------------------------+---------------+ 1894 Table 24: New RPL Control Codes 1896 11.5. New RPL Control Message Options 1898 This document extends the IANA Subregistry created by RFC 6550 for 1899 RPL Control Message Options as indicated in Table 25: 1901 +=======+============================+===============+ 1902 | Value | Meaning | Reference | 1903 +=======+============================+===============+ 1904 | 0x0B | Stateful VIO (SF-VIO) | This document | 1905 +-------+----------------------------+---------------+ 1906 | 0x0C | Source-Routed VIO (SR-VIO) | This document | 1907 +-------+----------------------------+---------------+ 1908 | 0x0D | Sibling Information option | This document | 1909 +-------+----------------------------+---------------+ 1911 Table 25: RPL Control Message Options 1913 11.6. SubRegistry for the Projected DAO Request Flags 1915 IANA is required to create a registry for the 8-bit Projected DAO 1916 Request (PDR) Flags field. Each bit is tracked with the following 1917 qualities: 1919 * Bit number (counting from bit 0 as the most significant bit) 1921 * Capability description 1923 * Reference 1925 Registration procedure is "Standards Action" [RFC8126]. The initial 1926 allocation is as indicated in Table 26: 1928 +============+========================+===============+ 1929 | Bit number | Capability description | Reference | 1930 +============+========================+===============+ 1931 | 0 | PDR-ACK request (K) | This document | 1932 +------------+------------------------+---------------+ 1933 | 1 | Requested path should | This document | 1934 | | be redundant (R) | | 1935 +------------+------------------------+---------------+ 1937 Table 26: Initial PDR Flags 1939 11.7. SubRegistry for the PDR-ACK Flags 1941 IANA is required to create an subregistry for the 8-bit PDR-ACK Flags 1942 field. Each bit is tracked with the following qualities: 1944 * Bit number (counting from bit 0 as the most significant bit) 1946 * Capability description 1948 * Reference 1950 Registration procedure is "Standards Action" [RFC8126]. No bit is 1951 currently defined for the PDR-ACK Flags. 1953 11.8. Subregistry for the PDR-ACK Acceptance Status Values 1955 IANA is requested to create a Subregistry for the PDR-ACK Acceptance 1956 Status values. 1958 * Possible values are 6-bit unsigned integers (0..63). 1960 * Registration procedure is "Standards Action" [RFC8126]. 1962 * Initial allocation is as indicated in Table 27: 1964 +-------+------------------------+---------------+ 1965 | Value | Meaning | Reference | 1966 +-------+------------------------+---------------+ 1967 | 0 | Unqualified acceptance | This document | 1968 +-------+------------------------+---------------+ 1970 Table 27: Acceptance values of the PDR-ACK Status 1972 11.9. Subregistry for the PDR-ACK Rejection Status Values 1974 IANA is requested to create a Subregistry for the PDR-ACK Rejection 1975 Status values. 1977 * Possible values are 6-bit unsigned integers (0..63). 1979 * Registration procedure is "Standards Action" [RFC8126]. 1981 * Initial allocation is as indicated in Table 28: 1983 +-------+-----------------------+---------------+ 1984 | Value | Meaning | Reference | 1985 +-------+-----------------------+---------------+ 1986 | 0 | Unqualified rejection | This document | 1987 +-------+-----------------------+---------------+ 1989 Table 28: Rejection values of the PDR-ACK Status 1991 11.10. SubRegistry for the Via Information Options Flags 1993 IANA is requested to create a Subregistry for the 5-bit Via 1994 Information Options (Via Information Option) Flags field. Each bit 1995 is tracked with the following qualities: 1997 * Bit number (counting from bit 0 as the most significant bit) 1999 * Capability description 2001 * Reference 2003 Registration procedure is "Standards Action" [RFC8126]. No bit is 2004 currently defined for the Via Information Options (Via Information 2005 Option) Flags. 2007 11.11. SubRegistry for the Sibling Information Option Flags 2009 IANA is required to create a registry for the 5-bit Sibling 2010 Information Option (SIO) Flags field. Each bit is tracked with the 2011 following qualities: 2013 * Bit number (counting from bit 0 as the most significant bit) 2015 * Capability description 2017 * Reference 2019 Registration procedure is "Standards Action" [RFC8126]. The initial 2020 allocation is as indicated in Table 29: 2022 +============+===================================+===============+ 2023 | Bit number | Capability description | Reference | 2024 +============+===================================+===============+ 2025 | 0 | Connectivity is bidirectional (B) | This document | 2026 +------------+-----------------------------------+---------------+ 2028 Table 29: Initial SIO Flags 2030 11.12. New Destination Advertisement Object Flag 2032 This document modifies the "Destination Advertisement Object (DAO) 2033 Flags" registry initially created in Section 20.11 of [RPL] . 2035 Section 3.1 also defines one new entry in the Registry as follows: 2037 +---------------+------------------------+-----------+ 2038 | Bit Number | Capability Description | Reference | 2039 +---------------+------------------------+-----------+ 2040 | 2 (suggested) | Projected DAO (P) | THIS RFC | 2041 +---------------+------------------------+-----------+ 2043 Table 30: New Destination Advertisement Object 2044 (DAO) Flag 2046 11.13. Error in Projected Route ICMPv6 Code 2048 In some cases RPL will return an ICMPv6 error message when a message 2049 cannot be forwarded along a Projected Route. This ICMPv6 error 2050 message is "Error in Projected Route". 2052 IANA has defined an ICMPv6 "Code" Fields Registry for ICMPv6 Message 2053 Types. ICMPv6 Message Type 1 describes "Destination Unreachable" 2054 codes. This specification requires that a new code is allocated from 2055 the ICMPv6 Code Fields Registry for ICMPv6 Message Type 1, for "Error 2056 in Projected Route", with a suggested code value of 8, to be 2057 confirmed by IANA. 2059 12. Acknowledgments 2061 The authors wish to acknowledge JP Vasseur, Remy Liubing, James 2062 Pylakutty and Patrick Wetterwald for their contributions to the ideas 2063 developed here. 2065 13. Normative References 2067 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2068 Requirement Levels", BCP 14, RFC 2119, 2069 DOI 10.17487/RFC2119, March 1997, 2070 . 2072 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2073 Control Message Protocol (ICMPv6) for the Internet 2074 Protocol Version 6 (IPv6) Specification", STD 89, 2075 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2076 . 2078 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 2079 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 2080 DOI 10.17487/RFC6282, September 2011, 2081 . 2083 [RPL] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 2084 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 2085 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 2086 Low-Power and Lossy Networks", RFC 6550, 2087 DOI 10.17487/RFC6550, March 2012, 2088 . 2090 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 2091 Power and Lossy Networks (RPL) Option for Carrying RPL 2092 Information in Data-Plane Datagrams", RFC 6553, 2093 DOI 10.17487/RFC6553, March 2012, 2094 . 2096 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 2097 Routing Header for Source Routes with the Routing Protocol 2098 for Low-Power and Lossy Networks (RPL)", RFC 6554, 2099 DOI 10.17487/RFC6554, March 2012, 2100 . 2102 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2103 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2104 May 2017, . 2106 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2107 Writing an IANA Considerations Section in RFCs", BCP 26, 2108 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2109 . 2111 14. Informative References 2113 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 2114 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 2115 2014, . 2117 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and 2118 J. Martocci, "Reactive Discovery of Point-to-Point Routes 2119 in Low-Power and Lossy Networks", RFC 6997, 2120 DOI 10.17487/RFC6997, August 2013, 2121 . 2123 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 2124 and M. Richardson, Ed., "A Security Threat Analysis for 2125 the Routing Protocol for Low-Power and Lossy Networks 2126 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 2127 . 2129 [6TiSCH-ARCHI] 2130 Thubert, P., Ed., "An Architecture for IPv6 over the Time- 2131 Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)", 2132 RFC 9030, DOI 10.17487/RFC9030, May 2021, 2133 . 2135 [RAW-ARCHI] 2136 Thubert, P., Papadopoulos, G. Z., and R. Buddenberg, 2137 "Reliable and Available Wireless Architecture/Framework", 2138 Work in Progress, Internet-Draft, draft-pthubert-raw- 2139 architecture-05, 15 November 2020, 2140 . 2143 [TURN-ON_RFC8138] 2144 Thubert, P., Ed. and L. Zhao, "A Routing Protocol for Low- 2145 Power and Lossy Networks (RPL) Destination-Oriented 2146 Directed Acyclic Graph (DODAG) Configuration Option for 2147 the 6LoWPAN Routing Header", RFC 9035, 2148 DOI 10.17487/RFC9035, April 2021, 2149 . 2151 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 2152 "Deterministic Networking Architecture", RFC 8655, 2153 DOI 10.17487/RFC8655, October 2019, 2154 . 2156 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 2157 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 2158 RFC 8025, DOI 10.17487/RFC8025, November 2016, 2159 . 2161 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 2162 "IPv6 over Low-Power Wireless Personal Area Network 2163 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 2164 April 2017, . 2166 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 2167 Perkins, "Registration Extensions for IPv6 over Low-Power 2168 Wireless Personal Area Network (6LoWPAN) Neighbor 2169 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 2170 . 2172 [USEofRPLinfo] 2173 Robles, M.I., Richardson, M., and P. Thubert, "Using RPI 2174 Option Type, Routing Header for Source Routes, and IPv6- 2175 in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008, 2176 DOI 10.17487/RFC9008, April 2021, 2177 . 2179 [PCE] IETF, "Path Computation Element", 2180 . 2182 Appendix A. Applications 2184 A.1. Loose Source Routing 2186 A RPL implementation operating in a very constrained LLN typically 2187 uses the Non-Storing Mode of Operation as represented in Figure 12. 2188 In that mode, a RPL node indicates a parent-child relationship to the 2189 Root, using a Destination Advertisement Object (DAO) that is unicast 2190 from the node directly to the Root, and the Root typically builds a 2191 source routed path to a destination down the DODAG by recursively 2192 concatenating this information. 2194 ------+--------- 2195 | Internet 2196 | 2197 +-----+ 2198 | | Border Router 2199 | | (RPL Root) 2200 +-----+ ^ | | 2201 | | DAO | ACK | 2202 o o o o | | | Strict 2203 o o o o o o o o o | | | Source 2204 o o o o o o o o o o | | | Route 2205 o o o o o o o o o | | | 2206 o o o o o o o o | v v 2207 o o o o 2208 LLN 2210 Figure 12: RPL Non-Storing Mode of operation 2212 Based on the parent-children relationships expressed in the non- 2213 storing DAO messages,the Root possesses topological information about 2214 the whole network, though this information is limited to the 2215 structure of the DODAG for which it is the destination. A packet 2216 that is generated within the domain will always reach the Root, which 2217 can then apply a source routing information to reach the destination 2218 if the destination is also in the DODAG. Similarly, a packet coming 2219 from the outside of the domain for a destination that is expected to 2220 be in a RPL domain reaches the Root. 2222 It results that the Root, or then some associated centralized 2223 computation engine such as a PCE, can determine the amount of packets 2224 that reach a destination in the RPL domain, and thus the amount of 2225 energy and bandwidth that is wasted for transmission, between itself 2226 and the destination, as well as the risk of fragmentation, any 2227 potential delays because of a paths longer than necessary (shorter 2228 paths exist that would not traverse the Root). 2230 As a network gets deep, the size of the source routing header that 2231 the Root must add to all the downward packets becomes an issue for 2232 nodes that are many hops away. In some use cases, a RPL network 2233 forms long lines and a limited amount of well-Targeted routing state 2234 would allow to make the source routing operation loose as opposed to 2235 strict, and save packet size. Limiting the packet size is directly 2236 beneficial to the energy budget, but, mostly, it reduces the chances 2237 of frame loss and/or packet fragmentation, which is highly 2238 detrimental to the LLN operation. Because the capability to store a 2239 routing state in every node is limited, the decision of which route 2240 is installed where can only be optimized with a global knowledge of 2241 the system, a knowledge that the Root or an associated PCE may 2242 possess by means that are outside of the scope of this specification. 2244 This specification enables to store a Storing Mode state in 2245 intermediate routers, which enables to limit the excursion of the 2246 source route headers in deep networks. Once a P-DAO exchange has 2247 taken place for a given Target, if the Root operates in non Storing 2248 Mode, then it may elide the sequence of routers that is installed in 2249 the network from its source route headers to destination that are 2250 reachable via that Target, and the source route headers effectively 2251 become loose. 2253 A.2. Transversal Routes 2255 RPL is optimized for Point-to-Multipoint (P2MP) and Multipoint-to- 2256 Point (MP2P), whereby routes are always installed along the RPL DODAG 2257 respectively from and towards the DODAG Root. Transversal Peer to 2258 Peer (P2P) routes in a RPL network will generally suffer from some 2259 elongated (stretched) path versus the best possible path, since 2260 routing between 2 nodes always happens via a common parent, as 2261 illustrated in Figure 13: 2263 * In Storing Mode, unless the destination is a child of the source, 2264 the packets will follow the default route up the DODAG as well. 2265 If the destination is in the same DODAG, they will eventually 2266 reach a common parent that has a route to the destination; at 2267 worse, the common parent may also be the Root. From that common 2268 parent, the packet will follow a path down the DODAG that is 2269 optimized for the Objective Function that was used to build the 2270 DODAG. 2272 * in Non-Storing Mode, all packets routed within the DODAG flow all 2273 the way up to the Root of the DODAG. If the destination is in the 2274 same DODAG, the Root must encapsulate the packet to place an RH 2275 that has the strict source route information down the DODAG to the 2276 destination. This will be the case even if the destination is 2277 relatively close to the source and the Root is relatively far off. 2279 ------+--------- 2280 | Internet 2281 | 2282 +-----+ 2283 | | Border Router 2284 | | (RPL Root) 2285 +-----+ 2286 X 2287 ^ v o o 2288 ^ o o v o o o o o 2289 ^ o o o v o o o o o 2290 ^ o o v o o o o o 2291 S o o o D o o o 2292 o o o o 2293 LLN 2295 Figure 13: Routing Stretch between S and D via common parent X 2297 It results that it is often beneficial to enable transversal P2P 2298 routes, either if the RPL route presents a stretch from shortest 2299 path, or if the new route is engineered with a different objective, 2300 and that it is even more critical in Non-Storing Mode than it is in 2301 Storing Mode, because the routing stretch is wider. For that reason, 2302 earlier work at the IETF introduced the "Reactive Discovery of 2303 Point-to-Point Routes in Low Power and Lossy Networks" [RFC6997], 2304 which specifies a distributed method for establishing optimized P2P 2305 routes. This draft proposes an alternate based on a centralized 2306 route computation. 2308 ------+--------- 2309 | Internet 2310 | 2311 +-----+ 2312 | | Border Router 2313 | | (RPL Root) 2314 +-----+ 2315 | 2316 o o o o 2317 o o o o o o o o o 2318 o o o o o o o o o o 2319 o o o o o o o o o 2320 S>>A>>>B>>C>>>D o o o 2321 o o o o 2322 LLN 2324 Figure 14: Projected Transversal Route 2326 This specification enables to store source-routed or Storing Mode 2327 state in intermediate routers, which enables to limit the stretch of 2328 a P2P route and maintain the characteristics within a given SLA. An 2329 example of service using this mechanism oculd be a control loop that 2330 would be installed in a network that uses classical RPL for 2331 asynchronous data collection. In that case, the P2P path may be 2332 installed in a different RPL Instance, with a different objective 2333 function. 2335 Authors' Addresses 2337 Pascal Thubert (editor) 2338 Cisco Systems, Inc 2339 Building D 2340 45 Allee des Ormes - BP1200 2341 06254 Mougins - Sophia Antipolis 2342 France 2344 Phone: +33 497 23 26 34 2345 Email: pthubert@cisco.com 2346 Rahul Arvind Jadhav 2347 Huawei Tech 2348 Kundalahalli Village, Whitefield, 2349 Bangalore 560037 2350 Karnataka 2351 India 2353 Phone: +91-080-49160700 2354 Email: rahul.ietf@gmail.com 2356 Matthew Gillmore 2357 Itron, Inc 2358 Building D 2359 2111 N Molter Road 2360 Liberty Lake, 99019 2361 United States 2363 Phone: +1.800.635.5461 2364 Email: matthew.gillmore@itron.com