idnits 2.17.1 draft-ietf-roll-dao-projection-17.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 (3 June 2021) is 1057 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: 5 December 2021 M. Gillmore 7 Itron 8 3 June 2021 10 Root initiated routing state in RPL 11 draft-ietf-roll-dao-projection-17 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 5 December 2021. 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 . . . . . . . . . . . . . . . . . . . . . . 6 65 3.2. Sibling Information Option . . . . . . . . . . . . . . . 8 66 3.3. P-DAO Request . . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . 15 75 7. Projected DAO . . . . . . . . . . . . . . . . . . . . . . . . 17 76 7.1. Requesting a Track . . . . . . . . . . . . . . . . . . . 19 77 7.2. Identifying a Track . . . . . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . 25 82 8. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 26 83 9. Example Track Signaling . . . . . . . . . . . . . . . . . . . 27 84 9.1. Using Storing-Mode Segments . . . . . . . . . . . . . . . 28 85 9.1.1. Stitched Segments . . . . . . . . . . . . . . . . . . 28 86 9.1.2. External routes . . . . . . . . . . . . . . . . . . . 30 87 9.1.3. Segment Routing . . . . . . . . . . . . . . . . . . . 31 88 9.2. Using Non-Storing-Mode joining Tracks . . . . . . . . . . 33 89 9.2.1. Stitched Tracks . . . . . . . . . . . . . . . . . . . 33 90 9.2.2. External routes . . . . . . . . . . . . . . . . . . . 35 91 9.2.3. Segment Routing . . . . . . . . . . . . . . . . . . . 37 92 10. Security Considerations . . . . . . . . . . . . . . . . . . . 40 93 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 94 11.1. New Elective 6LoWPAN Routing Header Type . . . . . . . . 40 95 11.2. New Critical 6LoWPAN Routing Header Type . . . . . . . . 40 96 11.3. New Subregistry For The RPL Option Flags . . . . . . . . 41 97 11.4. New RPL Control Codes . . . . . . . . . . . . . . . . . 41 98 11.5. New RPL Control Message Options . . . . . . . . . . . . 42 99 11.6. SubRegistry for the Projected DAO Request Flags . . . . 42 100 11.7. SubRegistry for the PDR-ACK Flags . . . . . . . . . . . 42 101 11.8. Subregistry for the PDR-ACK Acceptance Status Values . . 43 102 11.9. Subregistry for the PDR-ACK Rejection Status Values . . 43 103 11.10. SubRegistry for the Via Information Options Flags . . . 44 104 11.11. SubRegistry for the Sibling Information Option Flags . . 44 105 11.12. New Destination Advertisement Object Flag . . . . . . . 44 106 11.13. Error in Projected Route ICMPv6 Code . . . . . . . . . . 45 107 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45 108 13. Normative References . . . . . . . . . . . . . . . . . . . . 45 109 14. Informative References . . . . . . . . . . . . . . . . . . . 46 110 Appendix A. Applications . . . . . . . . . . . . . . . . . . . . 48 111 A.1. Loose Source Routing . . . . . . . . . . . . . . . . . . 48 112 A.2. Transversal Routes . . . . . . . . . . . . . . . . . . . 49 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 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 Projected DAO: A DAO message used to install a Projected Route. 258 Track: A DODAG that provides a complex path from or to a Root that 259 is the destination of the DODAG. The Root is the Track Ingress, 260 and the forward direction for packets is down the DODAG, from the 261 Track Ingress to one of the possibly multiple Track Egress Nodes. 262 TrackID: A RPL Local InstanceID with the D bit set to 0. The 263 TrackID is associated with the IPv6 Address of the Track Ingress 264 that is used to signal the DODAG Root. The owner of the namespace 265 is the Track Ingress. 267 2.4. References 269 In this document, readers will encounter terms and concepts that are 270 discussed in the "Routing Protocol for Low Power and Lossy Networks" 271 [RPL] and "Terminology in Low power And Lossy Networks" [RFC7102]. 273 3. Extending RFC 6550 275 3.1. Projected DAO 277 Section 6 of [RPL] introduces the RPL Control Message Options (CMO), 278 including the RPL Target Option (RTO) and Transit Information Option 279 (TIO), which can be placed in RPL messages such as the Destination 280 Advertisement Object (DAO). This specification extends the DAO 281 message with the Projected DAO (P-DAO); a P-DAO message signals a 282 Projected Route to one or more Targets using the new CMOs presented 283 therein. This specification enables to combine one or more Projected 284 Routes into a DODAG called a Track, that is traversed to reach the 285 Targets. 287 The Track is assimilated with the DODAG formed for a Local RPL 288 Instance. The local RPLInstanceID of the Track is called the 289 TrackID, more in Section 7.2. A P-DAO message for a Track signals 290 the TrackID in the RPLInstanceID field. The Track Ingress is 291 signaled in the DODAGID field of the Projected DAO Base Object; that 292 field is elided in the case of the main RPL Instance. The Track 293 Ingress is the Root of the Track, as shown in Figure 1. 295 This specification defines the new "Projected DAO" (P) flag. The 'P' 296 flag is encoded in bit position 2 (to be confirmed by IANA) of the 297 Flags field in the DAO Base Object. The Root MUST set it to 1 in a 298 Projected DAO message. Otherwise it MUST be set to 0. It is set to 299 0 in legacy implementations as specified respectively in Sections 300 20.11 and 6.4 of [RPL]. . 302 0 1 2 3 303 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 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | TrackID |K|D|P| Flags | Reserved | DAOSequence | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | | 308 + + 309 | | 310 + IPv6 Address of the Track Ingress + 311 | | 312 + + 313 | | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Option(s)... 316 +-+-+-+-+-+-+-+-+ 318 Figure 1: Projected DAO Base Object 320 New fields: 322 TrackID: In the case of a P-DAO, the RPLInstanceID field is called 323 TrackID. This is a naming convenience but does not change the 324 semantics and format of the RPLInstanceID that is used as TrackID. 326 P: 1-bit flag (position to be confirmed by IANA). 328 The 'P' flag is set to 1 by the Root to signal a Projected DAO, 329 and it is set to 0 otherwise. 331 In RPL Non-Storing Mode, the TIO and RTO are combined in a DAO 332 message to inform the DODAG Root of all the edges in the DODAG, which 333 are formed by the directed parent-child relationships. Options may 334 be factorized; multiple RTOs may be present to signal a collection of 335 children that can be reached via the parent(s) indicated in the 336 TIO(s) that follows the RTOs. This specification generalizes the 337 case of a parent that can be used to reach a child with that of a 338 whole Track through which both children and siblings of the Track 339 Egress are reachable. 341 New CMOs called the Via Information Options (VIO) are introduced for 342 use in P-DAO messages as a multihop alternative to the TIO. One VIO 343 is the Stateful VIO(SF-VIO); the SF-VIO installs Storing-Mode 344 Projected Route along a strict segment. The other is the Source- 345 Routed VIO (SR-VIO); the SR-VIO installs a Non-Storing-Mode Projected 346 Route at the Track Ingress, which uses that state to encapsulate a 347 packet with a Routing Header (RH) to the Track Egress. 349 Like in a DAO message, the RTOs can be factorized in a P-DAO, but the 350 Via Information Options cannot. A P-DAO contains one or more RTOs 351 that indicate the destinations that can be reached via the Track, and 352 exactly one VIOthat signals a sequence of nodes. In Non-Storing 353 Mode, the Root sends the P-DAO to the Track Ingress where the source- 354 routing state is stored. In Storing Mode, the P-DAO is sent to the 355 Track Egress and forwarded along the Segment in the reverse 356 direction, installing a Storing Mode state to the Track Egress at 357 each hop. In both cases the Track Ingress is the owner of the Track, 358 and it generates the P-DAO-ACK when the installation is successful. 360 3.2. Sibling Information Option 362 This specification adds another CMO called the Sibling Information 363 Option (SIO) that is used by a RPL Aware Node (RAN) to advertise a 364 selection of its candidate neighbors as siblings to the Root, more in 365 Section 6.4. The sibling selection process is out of scope. The 366 expectation is that a node reports a Sibling Address in a SIO based 367 on an active address registration [RFC8505] from that sibling for 368 that address with the 'R' flag not set in the EARO. The node may 369 assess the liveliness of the sibling at any time by performing a 370 registration for one of its own addresses, either a link local or a 371 global one, depending on whether the node expects the sibling to 372 perform a matching advertisement in its own SIO. 374 3.3. P-DAO Request 376 Two new RPL Control Messages are also introduced, to enable a RAN to 377 request the establishment of a Track between self as the Track 378 Ingress Node and a Track Egress. The RAN makes its request by 379 sending a new P-DAO Request (PDR) Message to the Root. The Root 380 confirms with a new PDR-ACK message back to the requester RAN, see 381 Section 6.1 for more. A positive PDR-ACK indicates that the Track 382 was built and that the Roots commits to maintain the Track for the 383 negotiated lifetime. In the case of a complex Track, each Segment is 384 maintained independently and asynchronously by the Root, with its own 385 lifetime that may be shorter, the same, or longer than that of the 386 Track. The Root may use an asynchronous PDR-ACK with an negative 387 status to indicate that the Track was terminated before its time. 389 3.4. Extending the RPI 391 Sending a Packet within a RPL Local Instance requires the presence of 392 the abstract RPL Packet Information (RPI) described in section 11.2. 393 of [RPL] in the outer IPv6 Header chain (see [USEofRPLinfo]). The 394 RPI carries a local RPLInstanceID which, in association with either 395 the source or the destination address in the IPv6 Header, indicates 396 the RPL Instance that the packet follows. 398 This specification extends [RPL] to create a new flag that signals 399 that a packet is forwarded along a projected route. 401 Projected-Route 'P': 1-bit flag. It is set to 1 if this packet is 402 sent over a projected route and set to 0 otherwise. 404 4. Extending RFC 6553 406 "The RPL Option for Carrying RPL Information in Data-Plane Datagrams" 407 [RFC6553]describes the RPL Option for use among RPL routers to 408 include the abstract RPL Packet Information (RPI) described in 409 section 11.2. of [RPL] in data packets. 411 The RPL Option is commonly referred to as the RPI though the RPI is 412 really the abstract information that is transported in the RPL 413 Option. [USEofRPLinfo] updated the Option Type from 0x63 to 0x23. 415 This specification modifies the RPL Option to encode the 'P' flag as 416 follows: 418 0 1 2 3 419 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 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Option Type | Opt Data Len | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 |O|R|F|P|0|0|0|0| RPLInstanceID | SenderRank | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | (sub-TLVs) | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 Figure 2: Extended RPL Option Format 430 Option Type: 0x23 or 0x63, see [USEofRPLinfo] 431 Opt Data Len: See [RFC6553] 433 'O', 'R' and 'F' flags: See [RFC6553]. Those flags MUST be set to 0 434 by the sender and ignored by the receiver if the 'P' flag is set. 436 Projected-Route 'P': 1-bit flag as defined in Section 3.4. 438 RPLInstanceID: See [RFC6553]. Indicates the TrackId if the 'P' flag 439 is set. 441 SenderRank: See [RFC6553]. This field MUST be set to 0 by the 442 sender and ignored by the receiver if the 'P'flag is set. 444 5. Extending RFC 8138 446 Section 6.3 of [RFC8138] presents the formats of the 6LoWPAN Routing 447 Header of type 5 (RPI-6LoRH) that compresses the RPI for normal RPL 448 operation. The format of the RPI-6LoRH is not suited for Projected 449 routes since the O,R,F flags are not used and the Rank is unknown and 450 ignored. 452 This specification introduces a new 6LoRH, the P-RPI-6LoRH, with a 453 type of 7. The P-RPI-6LoRH header is usually a a Critical 6LoWPAN 454 Routing Header, but it can be elective as well if an SRH-6LoRH is 455 present and controls the routing decision. 457 The P-RPI-6LoRH is designed to compress the RPI along RPL Projected 458 Routes. It sformat is as follows: 460 0 1 2 461 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 |1|0|E| Length | 6LoRH Type 7 | RPLInstanceID | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 Figure 3: P-RPI-6LoRH Format 468 Elective 'E': See [RFC8138]. The 'E' flag is set to 1 to indicate 469 an Elective 6LoRH, meaning that it can be ignored when forwarding. 471 6. New RPL Control Messages and Options 472 6.1. New P-DAO Request Control Message 474 The P-DAO Request (PDR) message is sent by a Node in the main DODAG 475 to the Root. It is a request to establish or refresh a Track where 476 this node is Track Ingress. The source IPv6 address of the PDR 477 signals the Track Ingress of the requested Track, and the TrackID is 478 indicated in the message itself. One and only one RPL Target Option 479 MUST be present in the message. The RTO signals the Track Egress, 480 more in Section 7.1. 482 The RPL Control Code for the PDR is 0x09, to be confirmed by IANA. 483 The format of PDR Base Object is as follows: 485 0 1 2 3 486 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 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | TrackID |K|R| Flags | ReqLifetime | PDRSequence | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | Option(s)... 491 +-+-+-+-+-+-+-+-+ 493 Figure 4: New P-DAO Request Format 495 TrackID: 8-bit field indicating the RPLInstanceID associated with 496 the Track. 498 K: The 'K' flag is set to indicate that the recipient is expected to 499 send a PDR-ACK back. 501 R: The 'R' flag is set to request a Complex Track for redundancy. 503 Flags: Reserved. The Flags field MUST initialized to zero by the 504 sender and MUST be ignored by the receiver 506 ReqLifetime: 8-bit unsigned integer. The requested lifetime for the 507 Track expressed in Lifetime Units (obtained from the DODAG 508 Configuration option). 510 A PDR with a fresher PDRSequence refreshes the lifetime, and a 511 PDRLifetime of 0 indicates that the track should be destroyed. 513 PDRSequence: 8-bit wrapping sequence number, obeying the operation 514 in section 7.2 of [RPL]. The PDRSequence is used to correlate a 515 PDR-ACK message with the PDR message that triggered it. It is 516 incremented at each PDR message and echoed in the PDR-ACK by the 517 Root. 519 6.2. New PDR-ACK Control Message 521 The new PDR-ACK is sent as a response to a PDR message with the 'K' 522 flag set. The RPL Control Code for the PDR-ACK is 0x0A, to be 523 confirmed by IANA. Its format is as follows: 525 0 1 2 3 526 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 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | TrackID | Flags | Track Lifetime| PDRSequence | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | PDR-ACK Status| Reserved | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | Option(s)... 533 +-+-+-+-+-+-+-+ 535 Figure 5: New PDR-ACK Control Message Format 537 TrackID: The RPLInstanceID of the Track that was created. The value 538 of 0x00 is used to when no Track was created. 540 Flags: Reserved. The Flags field MUST initialized to zero by the 541 sender and MUST be ignored by the receiver 543 Track Lifetime: Indicates that remaining Lifetime for the Track, 544 expressed in Lifetime Units; the value of zero (0x00) indicates 545 that the Track was destroyed or not created. 547 PDRSequence: 8-bit wrapping sequence number. It is incremented at 548 each PDR message and echoed in the PDR-ACK. 550 PDR-ACK Status: 8-bit field indicating the completion. The PDR-ACK 551 Status is substructured as indicated in Figure 6: 553 0 1 2 3 4 5 6 7 554 +-+-+-+-+-+-+-+-+ 555 |E|R| Value | 556 +-+-+-+-+-+-+-+-+ 558 Figure 6: PDR-ACK status Format 560 E: 1-bit flag. Set to indicate a rejection. When not set, the 561 value of 0 indicates Success/Unqualified acceptance and other 562 values indicate "not an outright rejection". 563 R: 1-bit flag. Reserved, MUST be set to 0 by the sender and 564 ignored by the receiver. 565 Status Value: 6-bit unsigned integer. Values depending on the 566 setting of the 'E' flag, see Table 27 and Table 28. 568 Reserved: The Reserved field MUST initialized to zero by the sender 569 and MUST be ignored by the receiver 571 6.3. Via Information Options 573 An VIOsignals the ordered list of IPv6 Via Addresses that constitutes 574 the hops of either a Serial Track or a Segment of a more Complex 575 Track. An VIOMUST contain at least one Via Address, and a Via 576 Address MUST NOT be present more than once, otherwise the VIOMUST be 577 ignored. The format of the Via Information Options is as follows: 579 0 1 2 3 580 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 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | Type | Option Length | Flags | SegmentID | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 |Segm. Sequence | Seg. Lifetime | SRH-6LoRH header | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | | 587 + + 588 . . 589 . Via Address 1 . 590 . . 591 + + 592 | | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | | 595 . .... . 596 | | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | | 599 + + 600 . . 601 . Via Address n . 602 . . 603 + + 604 | | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 Figure 7: VIOformat (uncompressed form) 609 Option Type: 0x0B for SF-VIO, 0x0C for SR-VIO (to be confirmed by 610 IANA) 612 Option Length: In bytes; variable, depending on the number of Via 613 Addresses and the compression. 615 SegmentID: 8-bit field that identifies a Segment within a Track or 616 the main DODAG as indicated by the TrackID field. The value of 0 617 is used to signal a Serial Track, i.e., made of a single segment. 619 Segment Sequence: 8-bit unsigned integer. The Segment Sequence 620 obeys the operation in section 7.2 of [RPL] and the lollipop 621 starts at 255. 623 When the Root of the DODAG needs to refresh or update a Segment in 624 a Track, it increments the Segment Sequence individually for that 625 Segment. 627 The Segment information indicated in the VIOdeprecates any state 628 for the Segment indicated by the SegmentID within the indicated 629 Track and sets up the new information. 631 An VIOwith a Segment Sequence that is not as fresh as the current 632 one is ignored. 634 A VIO for a given DODAGID with the same (TrackID, SegmentID, 635 Segment Sequence) indicates a retry; it MUST NOT change the 636 Segment and MUST be propagated or answered as the first copy. 638 Segment Lifetime: 8-bit unsigned integer. The length of time in 639 Lifetime Units (obtained from the Configuration option) that the 640 Segment is usable. 642 The period starts when a new Segment Sequence is seen. The value 643 of 255 (0xFF) represents infinity. The value of zero (0x00) 644 indicates a loss of reachability. 646 A P-DAO message that contains a VIOwith a Segment Lifetime of zero 647 is referred as a No-Path P-DAO in this document. 649 SRH-6LoRH header: The first 2 bytes of the (first) SRH-6LoRH as 650 shown in Figure 6 of [RFC8138]. A 6LoRH Type of 4 means that the 651 VIA Addresses are provided in full with no compression. 653 Via Address: An IPv6 address along the Segment. 655 In a SF-VIO, the list is a strict path between direct neighbors, 656 from the Segment Ingress to Egress, both included. The router 657 that processes an SF-VIO MAY create additional routing state 658 towards the nodes after self via the node immediatelt after self 659 in the SF-VIO, but in case of memory shortage the routes to the 660 Targets have precedence since they are the ones that the router 661 commits to store. 663 In an SR-VIO, the list starts at the first hop and ends at a Track 664 Egress. In that case, the Track Egress MUST be considered as an 665 implicit Target, so it MUST NOT be listed it in a RPL Target 666 Option. The list in an SR-VIO may be loose, provided that each 667 listed node has a path to the next listed node, e.g., via a 668 segment or another Track. 670 In the case of a SF-VIO, or if [RFC8138] is not used in the data 671 packets, then the Root MUST use only one SRH-6LoRH per Via 672 Information Option, and the compression is the same for all the 673 addresses, as shown in Figure 7. 675 In case of an SR-VIO, and if [RFC8138] is in use in the main 676 DODAG, then the Root SHOULD optimize the size of the SR-VIO; more 677 than one SRH-6LoRH may be present, e.g., if the compression level 678 changes inside the Segment and different SRH-6LoRH Types are 679 required. The content of the SR-VIO starting at the first SRH- 680 6LoRH header is thus verbatim the one that the Track Ingress 681 places in the packet encapsulation to reach the Track Ingress. 683 6.4. Sibling Information Option 685 The Sibling Information Option (SIO) provides indication on siblings 686 that could be used by the Root to form Projected Routes. One or more 687 SIO(s) may be placed in the DAO messages that are sent to the Root in 688 Non-Storing Mode. 690 The format of the SIO is as follows: 692 0 1 2 3 693 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 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | Type | Option Length |Comp.|B|D|Flags| Opaque | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | Step of Rank | Reserved | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | | 700 + + 701 . . 702 . Sibling DODAGID (if the D flag not set) . 703 . . 704 + + 705 | | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | | 708 + + 709 . . 710 . Sibling Address . 711 . . 712 + + 713 | | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 Figure 8: Sibling Information Option Format 718 Option Type: 0x0D (to be confirmed by IANA) 720 Option Length: In bytes, the size of the option. 722 Compression Type: 3-bit unsigned integer. This is the SRH-6LoRH 723 Type as defined in figure 7 in section 5.1 of [RFC8138] that 724 corresponds to the compression used for the Sibling Address and 725 its DODAGID if resent. The Compression reference is the Root of 726 the main DODAG. 728 Reserved for Flags: MUST be set to zero by the sender and MUST be 729 ignored by the receiver. 731 B: 1-bit flag that is set to indicate that the connectivity to the 732 sibling is bidirectional and roughly symmetrical. In that case, 733 only one of the siblings may report the SIO for the hop. If 'B' 734 is not set then the SIO only indicates connectivity from the 735 sibling to this node, and does not provide information on the hop 736 from this node to the sibling. 738 D: 1-bit flag that is set to indicate that sibling belongs to the 739 same DODAG. When not set, the Sibling DODAGID is indicated. 741 Flags: Reserved. The Flags field MUST initialized to zero by the 742 sender and MUST be ignored by the receiver 744 Opaque: MAY be used to carry information that the node and the Root 745 understand, e.g., a particular representation of the Link 746 properties such as a proprietary Link Quality Information for 747 packets received from the sibling. An industrial Alliance that 748 uses RPL for a particular use / environment MAY redefine the use 749 of this field to fit its needs. 751 Step of Rank: 16-bit unsigned integer. This is the Step of Rank 752 [RPL] as computed by the Objective Function between this node and 753 the sibling. 755 Reserved: The Reserved field MUST initialized to zero by the sender 756 and MUST be ignored by the receiver 758 Sibling DODAGID: 2 to 16 bytes, the DODAGID of the sibling in a 759 [RFC8138] compressed form as indicated by the Compression Type 760 field. This field is present if and only if the D flag is not 761 set. 763 Sibling Address: 2 to 16 bytes, an IPv6 Address of the sibling, with 764 a scope that MUST be make it reachable from the Root, e.g., it 765 cannot be a Link Local Address. The IPv6 address is encoded in 766 the [RFC8138] compressed form indicated by the Compression Type 767 field. 769 An SIO MAY be immediately followed by a DAG Metric Container. In 770 that case the DAG Metric Container provides additional metrics for 771 the hop from the Sibling to this node. 773 7. Projected DAO 775 This draft adds a capability to RPL whereby the Root of a main DODAG 776 installs a Track as a collection of Projected Routes, using a 777 Projected-DAO (P-DAO) message to maintain each individual route. The 778 P-DAO signals a collection of Targets in the RPL Target Option(s) 779 (RTO). Those Targets can be reached via a sequence of routers 780 indicated in a VIO(VIO). A P-DAO message MUST contain exactly one 781 VIO, which is either a SF-VIO or an SR-VIO, and MUST follow one or 782 more RTOs. There can be at most one such sequence of RTO(s) and an 783 Via Information Option. A track is indentified by a tupple DODAGID, 784 TrackID and each route within a Track is indexed by a SegmentID. 786 A P-DAO MUST be sent from the address of the Root that serves as 787 DODAGID for the main DODAG. It MUST be sent to a GUA or a ULA of 788 either the ingress or the egress of the Segment, more below. If the 789 'K' Flag is present in the P-DAO, and unless the P-DAO does not reach 790 it, the ingress of the Segment is the node that acknowledges the 791 message, using a DAO-ACK that MUST be sent back to the address that 792 serves as DODAGID for the main DODAG. 794 Like a classical DAO message, a P-DAO causes a change of state only 795 if it is "new" per section 9.2.2. "Generation of DAO Messages" of 796 the RPL specification [RPL]; this is determined using the Segment 797 Sequence information from the VIOas opposed to the Path Sequence from 798 a TIO. Also, a Segment Lifetime of 0 in an VIOindicates that the 799 projected route associated to the Segment is to be removed. 801 There are two kinds of operation for the Projected Routes, the 802 Storing Mode and the Non-Storing Mode. 804 * The Non-Storing Mode is discussed in Section 7.3.2. A Non-Storing 805 Mode P-DAO carries an SR-VIO with the loose list of Via Addresses 806 that forms a source-routed Segment to the Track Egress. The 807 recipient of the P-DAO is the Track Ingress; it MUST install a 808 source-routed state to the Track Egress and reply to the Root 809 directly using a DAO-ACK message if requested to. 811 * The Storing Mode is discussed in Section 7.3.1. A Storing Mode 812 P-DAO carries a SF-VIO with the strict list of Via Addresses from 813 the ingress to the egress of the Segment in the data path order. 814 The routers listed in the Via Addresses, except the egress, MUST 815 install a routing state to the Target(s) via the next Via Address 816 in the SF-VIO. In normal operations, the P-DAO is propagated 817 along the chain of Via Routers from the egress router of the path 818 till the ingress one, which confirms the installation to the Root 819 with a DAO-ACK message. 821 In case of a forwarding error along a Projected Route, an ICMP error 822 is sent to the Root with a new Code "Error in Projected Route" (See 823 Section 11.13). The Root can then modify or remove the Projected 824 Route. The "Error in Projected Route" message has the same format as 825 the "Destination Unreachable Message", as specified in RFC 4443 826 [RFC4443]. 828 The portion of the invoking packet that is sent back in the ICMP 829 message SHOULD record at least up to the RH if one is present, and 830 this hop of the RH SHOULD be consumed by this node so that the 831 destination in the IPv6 header is the next hop that this node could 832 not reach. if a 6LoWPAN Routing Header (6LoRH) [RFC8138] is used to 833 carry the IPv6 routing information in the outer header then that 834 whole 6LoRH information SHOULD be present in the ICMP message. 836 The sender and exact operation depend on the Mode and is described in 837 Section 7.3.2 and Section 7.3.1 respectively. 839 7.1. Requesting a Track 841 A Node is free to ask the Root for a new Track for which it will be 842 Ingress at any time. This is done with a PDR message, that indicates 843 the desired TrackID and the duration for which the Track should be 844 established. Upon a PDR, the Root MAY install the necessary 845 Segments, in which case it answers with a PDR-ACK indicating the 846 granted Track Lifetime. All the Segments MUST be of a same mode, 847 either Storing or Non-Storing. All the Segments MUST be created with 848 the same TrackID and the same DODAGID signaled in the P-DAO. 850 The Root is free to design the Track as it wishes, and to change the 851 Segments overtime to serve the Track as needed, without notifying the 852 resquesting Node. The Segment Lifetime in the P-DAO messages does 853 not need to be aligned to the Requested Lifetime in the PDR, or 854 between P-DAO messages for different Segments. The Root may use 855 shorter lifetimes for the Segments and renew them faster than the 856 Track is, or longer lifetimes in which case it will need to tear down 857 the Segments if the Track is not renewed. 859 When the Track Lifetime that was returned in the PDR-ACK is close to 860 elapse, the resquesting Node needs to resend a PDR using the TrackID 861 in the PDR-ACK to extend the lifetime of the Track, else the Track 862 will time out and the Root will tear down the whole structure. 864 If the Track fails and cannot be restored, the Root notifies the 865 resquesting Node asynchronously with a PDR-ACK with a Track Lifetime 866 of 0, indicating that the Track has failed, and a PDR-ACK Status 867 indicating the reason of the fault. 869 7.2. Identifying a Track 871 RPL defines the concept of an Instance to signal an individual 872 routing topology but does not have a concept of an administrative 873 distance, which exists in certain proprietary implementations to sort 874 out conflicts between multiple sources of routing information within 875 one routing topology. 877 This draft leverages the RPL Instance model as follows: 879 * The Root MAY use P-DAO messages to add better routes in the main 880 (Global) Instance in conformance with the routing objectives in 881 that Instance. To achieve this, the Root MAY install an Storing- 882 Mode P-Route along a path down the main Non-Storing Mode DODAG. 883 This enables a loose source routing and reduces the size of the 884 Routing Header, see Appendix A.1. 886 When adding an Storing-Mode P-Route to the main RPL Instance, the 887 Root MUST set the RPLInstanceID field of the P-DAO message (see 888 section 6.4.1. of [RPL]) to the RPLInstanceID of the main DODAG, 889 and MUST NOT use the DODAGID field. A Projected Route provides a 890 longer match to the Target Address than the default route via the 891 Root, so it is preferred. 893 Once the Projected Route is installed, the intermediate nodes 894 listed in the SF-VIO after first one (i.e. The ingress) can be 895 elided from the RH in packets sent along the Segment signaled in 896 the P-DAO. The resulting loose source routing header indicates 897 (one of) the Target(s) as the next entry after the ingress. 899 * The Root MAY also use P-DAO messages to install a specific (say, 900 Traffic Engineered) path as a Serial or as a Complex Track, to a 901 particular endpoint that is the Track Egress. In that case, the 902 Root MUST install a Local RPL Instance (see section 5 of [RPL]), 903 and the Local RPLInstanceID is called TrackID. 905 In that case, the TrackID MUST be unique for the Global Unique 906 IPv6 Address (GUA) or Unique-Local Address (ULA) of the Track 907 Ingress that serves as DODAGID for the Track. The Track Ingress 908 owns the namespace of its TrackIDs, so it can pick any unused 909 value to request a new Track with a PDR. The Root is aware of all 910 the active Tracks, so it can also pick any unused value to form 911 Tracks without a PDR. To avoid a collision of the Root and the 912 Track Ingress picking the same value at the same time, it is 913 RECOMMENDED that the Track Ingress starts allocating the ID value 914 of the Local RPLInstanceID (see section 5.1. of [RPL]) used as 915 TrackIDs with the value 0 incrementing, while the Root starts with 916 63 decrementing. 918 This way, a Track is uniquely identified by the tuple (DODAGID, 919 TrackID) where the TrackID is always represented with the D flag 920 set to 0. 922 The Track Egress Address and the TrackID MUST be signaled in the 923 P-DAO message as shown in Figure 1. 925 7.3. Installing a Track 927 A Storing-Mode P-DAO contains an SF-VIO that signals the strict 928 sequence of consecutive nodes to form a segment between a segment 929 ingress and a segment egress (both included). It installs a route of 930 a higher precedence along the segment towards the Targets indicated 931 in the Target Options. The segment is included in a DODAG indicated 932 by the P-DAO Base Object, that may be the one formed by the main RPL 933 Instance, or a Track associated with a local RPL Instance. A Track 934 Egress is signaled as a Target in the P-DAO, and as the last entry is 935 an SF-VIO of a last segment towards that Egress. 937 A Non-Storing-Mode P-DAO signals a strict or loose sequence of nodes 938 between the Track Ingress (excluded) and a Track Egress (included). 939 It installs a source-routed path of a higher precedence within the 940 Track indicated by the P-DAO Base Object, towards the Targets 941 indicated in the Target Options. The source-routed path requires a 942 Source-Routing header which implies an encapsulation to add the SRH 943 to an existing packet. 945 The next entry in the sequence must be either a neighbor of the 946 previous entry, or reachable as a Target via another Projected Route, 947 either Storing or Non-Storing. If it is reachable over a Storing 948 Mode Projected Route, the next entry in the loose sequence is the 949 Target of a previous segment and the ingress of a next segment; the 950 segments are associated with the same Track, which avoids the need of 951 an encapsulation. Conversely, if it is reachable over a Non-Storing 952 Mode Projected Route, the next loose source routed hop of the inner 953 Track is a Target of a previous Track and the ingress of a next 954 Track, which requires a de- and a re-encapsulation. 956 A Serial Track is installed by a single Projected Routes that signals 957 the sequence of consecutive nodes, either in Storing or Non-Storing 958 Mode. If can be a loose Non-Storing Mode Projected Route, in which 959 case the next loose entry must recursively be reached over a Serial 960 Track. 962 A Complex Track can be installed as a collection of Projected Routes 963 with the same DODAGID and Track ID. The Ingress of a Non-Storing 964 Mode Projected Route must be the owner of the DODAGID. The Ingress 965 of a Storing Mode Projected Route must be either the owner of the 966 DODAGID, or the egress of a preceding Storing Mode Projected Route in 967 the same Track. In the latter case, the Targets of the Projected 968 Route must be Targets of the preceding Projected Route to ensure that 969 they are visible from the track Ingress. 971 7.3.1. Storing-Mode P-Route 973 Profile 1 extends RPL opertation in a Non-Storing Mode network with 974 Storing-Mode Projected Routes that install segments along the main 975 DODAG and enable to loose source routing between the Root and the 976 targets. 978 As illustrated in Figure 9, a P-DAO that carries a SF-VIO enables the 979 Root to install a stateful route towards a collection of Targets 980 along a Segment between a Track Ingress and a Track Egress. 982 ------+--------- 983 | Internet 984 | 985 +-----+ 986 | | Border Router 987 | | (RPL Root) 988 +-----+ | ^ | 989 | | DAO | ACK | 990 o o o o | | | 991 o o o o o o o o o | ^ | Projected . 992 o o o o o o o o o o | | DAO | Route . 993 o o o o o o o o o | ^ | . 994 o o o o o o o o v | DAO v . 995 o o LLN o o o | 996 o o o o o Loose Source Route Path | 997 o o o o From Root To Destination v 999 Figure 9: Projecting a route 1001 In order to install the relevant routing state along the Segment , 1002 the Root sends a unicast P-DAO message to the Track Egress router of 1003 the routing Segment that is being installed. The P-DAO message 1004 contains a SF-VIO with the direct sequence of Via Addresses. The SF- 1005 VIO follows one or more RTOs indicating the Targets to which the 1006 Track leads. The SF-VIO contains a Segment Lifetime for which the 1007 state is to be maintained. 1009 The Root sends the P-DAO directly to the egress node of the Segment. 1010 In that P-DAO, the destination IP address matches the last Via 1011 Address in the SF-VIO. This is how the egress recognizes its role. 1012 In a similar fashion, the ingress node recognizes its role as it 1013 matches first Via Address in the SF-VIO. 1015 The Egress node of the Segment is the only node in the path that does 1016 not install a route in response to the P-DAO; it is expected to be 1017 already able to route to the Target(s) on its own. If one of the 1018 Targets is not known, the node MUST answer to the Root with a 1019 negative DAO-ACK listing the Target(s) that could not be located 1020 (suggested status 10 to be confirmed by IANA). 1022 If the egress node can reach all the Targets, then it forwards the 1023 P-DAO with unchanged content to its loose predecessor in the Segment 1024 as indicated in the list of Via Information options, and recursively 1025 the message is propagated unchanged along the sequence of routers 1026 indicated in the P-DAO, but in the reverse order, from egress to 1027 ingress. 1029 The address of the predecessor to be used as destination of the 1030 propagated DAO message is found in the Via Address the precedes the 1031 one that contain the address of the propagating node, which is used 1032 as source of the message. 1034 Upon receiving a propagated DAO, all except the Egress Router MUST 1035 install a route towards the DAO Target(s) via their successor in the 1036 SF-VIO. The router MAY install additional routes towards the VIA 1037 Addresses that are the SF-VIO after the next one, if any, but in case 1038 of a conflict or a lack of resource, the route(s) to the Target(s) 1039 have precedence. 1041 If a router cannot reach its predecessor in the SF-VIO, the router 1042 MUST answer to the Root with a negative DAO-ACK indicating the 1043 successor that is unreachable (suggested status 11 to be confirmed by 1044 IANA). 1046 The process continues till the P-DAO is propagated to ingress router 1047 of the Segment, which answers with a DAO-ACK to the Root. 1049 A Segment Lifetime of 0 in a VIOis used to clean up the state. The 1050 P-DAO is forwarded as described above, but the DAO is interpreted as 1051 a No-Path DAO and results in cleaning up existing state as opposed to 1052 refreshing an existing one or installing a new one. 1054 In case of a forwarding error along an Storing-Mode P-Route, the node 1055 that fails to forward SHOULD send an ICMP error with a code "Error in 1056 Projected Route" to the Root. Failure to do so may result in packet 1057 loss and wasted resources along the Projected Route that is broken. 1059 7.3.2. Non-Storing-Mode P-Route 1061 As illustrated in Figure 10, a P-DAO that carries an SR-VIO enables 1062 the Root to install a source-routed path from a Track Ingress towards 1063 a Target along the main DODAG. 1065 ------+--------- 1066 | Internet 1067 | 1068 +-----+ 1069 | | Border Router 1070 | | (RPL Root) 1071 +-----+ | P ^ ACK 1072 | Track | DAO | 1073 o o o o Ingress X V | X 1074 o o o o o o o X o X Source 1075 o o o o o o o o X o o X Routed 1076 o o ° o o o o X o X Segment 1077 o o o o o o o o X Track X 1078 o o o o o Egress 1080 o o o o 1081 o o o o 1082 destination 1084 LLN 1086 Figure 10: Projecting a Non-Storing Route 1088 When forwarding a packet to a destination for which the router 1089 determines that routing happens via a Track Target, the router 1090 inserts the Source Routing Header in the packet with the final 1091 destination at the Track Egress. 1093 In order to signal the Segment, the router encapsulates the packet 1094 with an IP-in-IP header and a Routing Header as follows: 1096 * In the uncompressed form the source of the packet is this router, 1097 the destination is the first Via Address in the SR-VIO, and the RH 1098 is a Source Routing Header (SRH) [RFC6554] that contains the list 1099 of the remaining Via Addresses terminating by the Track Egress. 1101 * The preferred alternate in a network where 6LoWPAN Header 1102 Compression [RFC6282] is used is to leverage "IPv6 over Low-Power 1103 Wireless Personal Area Network (6LoWPAN) Paging Dispatch" 1104 [RFC8025] to compress the RPL artifacts as indicated in [RFC8138]. 1106 In that case, the source routed header is the exact copy of the 1107 (chain of) SRH-6LoRH found in the SR-VIO, also terminating by the 1108 Track Egress. The RPI-6LoRH is appended next, followed by an IP- 1109 in-IP 6LoRH Header that indicates the Ingress Router in the 1110 Encapsulator Address field, see as a similar case Figure 20 of 1111 [TURN-ON_RFC8138]. 1113 In the case of a loose source-routed path, there MUST be either a 1114 neighbor that is adjacent to the loose next hop, on which case the 1115 packet is forwarded to that neighbor, or another Track to the loose 1116 next hop for which this node is Ingress; in the latter case, another 1117 encapsulation takes place and the process possibly recurses; 1118 otherwise the packet is dropped. 1120 In case of a forwarding error along a Source Route path, the node 1121 that fails to forward SHOULD send an ICMP error with a code "Error in 1122 Source Routing Header" back to the source of the packet, as described 1123 in section 11.2.2.3. of [RPL]. Upon this message, the encapsulating 1124 node SHOULD stop using the source route path for a period of time and 1125 it SHOULD send an ICMP message with a Code "Error in Projected Route" 1126 to the Root. Failure to follow these steps may result in packet loss 1127 and wasted resources along the source route path that is broken. 1129 7.4. Forwarding Along a Track 1131 This draft leverages the RPL Forwarding model follows: 1133 * In the data packets, the Track DODAGID and the TrackID MUST be 1134 respectively signaled as the IPv6 Source Address and the 1135 RPLInstanceID field of the RPI that MUST be placed in the outer 1136 chain of IPv6 Headers. 1138 The RPI carries a local RPLInstanceID called the TrackID, which, 1139 in association with the DODAGID, indicates the Track along which 1140 the packet is forwarded. 1142 The D flag in the RPLInstanceID MUST be set to 0 to indicate that 1143 the source address in the IPv6 header is set ot the DODAGID, more 1144 in Section 7.4. 1146 * This draft conforms the principles of [USEofRPLinfo] with regards 1147 to packet forwarding and encapsulation along a Track. 1149 - In that case, the Track is the DODAG, the Track Ingress is the 1150 Root, and the Track Egress is a RAL, and neighbors of the Track 1151 Egress that can be reached via the Track are RULs. The 1152 encapsulation rules in [USEofRPLinfo] apply. 1154 - If the Track Ingress is the originator of the packet and the 1155 Track Egress is the destination of the packet, there is no need 1156 for an encapsulation. 1158 - So the Track Ingress must encapsulate the traffic that it did 1159 not originate, and add an RPI in any fashion. 1161 A packet that is being routed over the RPL Instance associated to 1162 a first Non-Storing Mode Track MAY be placed (encapsulated) in a 1163 second Track to cover one loose hop of the first Track. On the 1164 other hand, a Storing Mode Track must be strict and a packet that 1165 it placed in a Storing Mode Track MUST follow that Track till the 1166 Track Egress. 1168 When a Track Egress extracts a packet from a Track (decapsulates 1169 the packet), the Destination of the inner packet MUST be either 1170 this node or a direct neighbor, or a Target of another Segment of 1171 the same Track for which this node is ingress, otherwise the 1172 packet MUST be dropped. 1174 All properties of a Track operations are inherited form the main RPL 1175 Instance that is used to install the Track. For instance, the use of 1176 compression per [RFC8138] is determined by whether it is used in the 1177 main instance, e.g., by setting the "T" flag [TURN-ON_RFC8138] in the 1178 RPL configuration option. 1180 8. Profiles 1182 This document provides a set of tools that may or may not be needed 1183 by an implementation depending on the type of application it serves. 1184 This sections described profiles that can be implemented separately 1185 and can be used to discriminate what an implementation can and cannot 1186 do. 1188 Profile 0 Profile 0 is the legacy support of [RPL] Non-Storing Mode. 1189 It provides the minimal common functionality that must be 1190 implemented as a prerequisite to all the Track-supporting 1191 profiles. The other Profiles extend Profile 0 with selected 1192 capabilities that this specification introduces on top. 1194 Profile 1 (Storing-Mode P-Route Segments along the main DODAG) Profi 1195 le 1 does not create new paths; it combines Storing and Non- 1196 Storing Modes to balance the size of the routing header in the 1197 packet and the amount of state in the intermediate routers in a 1198 Non-Storing Mode RPL DODAG. 1200 Profile 2 (Non-Storing-Mode P-Route Segments along the main DODAG) P 1201 rofile 2 extends Profile 0 with Strict Source-Routing Non-Storing- 1202 Mode Projected Routes along the main DODAG. Profile 2 provides 1203 the same capability to compress the SRH in packets down the main 1204 DODAG as Profile 1, but it require an encapsulation, in order to 1205 insert an additional SRH between the loose source routing hops. 1207 Profile 3 Profile 3 and above build Tracks that do not necessarily 1208 follow the main DODAG. In order to form the best path possible, 1209 those Profiles require the support of Sibling Information Option 1210 to inform the Root of additional possible hops. Profile 3 extends 1211 Profile 1 with additional Storing-Mode Projected Routes that 1212 install segments that do not follow the main DODAG. If the 1213 Segment Ingress (in the SF-VIO) is the same as the IPv6 Address of 1214 the Track Ingress (in the projected DAO base Object), the P-DAO 1215 creates an implicit Track between the Segment Ingress and the 1216 Segment Egress. 1218 Profile 4 Profile 4 extends Profile 2 with Strict Source-Routing 1219 Non-Storing-Mode Projected Routes to form Tracks inside the main 1220 DODAG. A Track is formed as one or more strict source source 1221 routed paths between the Root that is the Track Ingress, and the 1222 Track Egress that is the last node 1224 Profile 5 Profile 5 Combines Profile 4 with Profile 1 and enables to 1225 loose source routing between the Ingress and the Egress of the 1226 Track. As in Profile 1, Storing-Mode Projected Routes connect the 1227 dots in the loose source route. 1229 Profile 6 Profile 6 Combines Profile 4 with Profile 2 and also 1230 enables to loose source routing between the Ingress and the Egress 1231 of the Track. 1233 9. Example Track Signaling 1235 The remainder of the section provides an example of how a Track can 1236 be signaled 1238 ===> F 1239 A ===> B ===> C ===> D===> E < 1240 ===> G 1242 Figure 11: Reference Track 1244 A is Track ingress, E is track Egress. C is stitching point. F and 1245 G are E's neighbors, "external" to the Track, and reachable from A 1246 over the Track A->E. 1248 In a general manner we want: 1250 * P-DAO 1 signals C==>B==>E 1252 * P-DAO 2 signals A==>B==>C 1254 * P-DAO 3 signals F and G via the A==>E Track 1256 P-DAO 3 being loose, it can only be non-storing. Note that since the 1257 Root is always the ingress of a Track, and all SR-VIOs are now Track, 1258 the Root being signaled in the DAO base object can now be elided in 1259 the VIA list in SR-VIO. This enables the construction by the main 1260 root of the RFC 8138 optimized SRH-6LoRH in the SR-VIO, to be placed 1261 as is in the packet by the Root. 1263 9.1. Using Storing-Mode Segments 1265 A==>B==>C and C==>D==>E are segments of a same Track. Note that the 1266 storing mode signaling imposes strict continuity in a segment. One 1267 benefit of strict routing is that loops are avoided along the Track. 1269 9.1.1. Stitched Segments 1271 Storing-Mode P-DAO 1 and 2 are sent to E and C, as follows: 1273 +===============+==============+==============+ 1274 | Field | P-DAO 1 to E | P-DAO 2 to C | 1275 +===============+==============+==============+ 1276 | Mode | Storing | Storing | 1277 +---------------+--------------+--------------+ 1278 | Track Ingress | A | A | 1279 +---------------+--------------+--------------+ 1280 | TrackID | (A, 129) | (A, 129) | 1281 +---------------+--------------+--------------+ 1282 | VIO | C, D, E | A, B, C | 1283 +---------------+--------------+--------------+ 1284 | Targets | E, F, G | E, F, G | 1285 +---------------+--------------+--------------+ 1287 Table 1: P-DAO Messages 1289 As a result the RIBs are set as follows: 1291 +======+=============+=========+=============+==========+ 1292 | Node | Destination | Origin | Next Hop(s) | TrackID | 1293 +======+=============+=========+=============+==========+ 1294 | E | F, G | P-DAO 1 | Neighbor | (A, 129) | 1295 +------+-------------+---------+-------------+----------+ 1296 | D | E | P-DAO 1 | Neighbor | (A, 129) | 1297 +------+-------------+---------+-------------+----------+ 1298 | " | F, G | P-DAO 1 | E | (A, 129) | 1299 +------+-------------+---------+-------------+----------+ 1300 | C | D | P-DAO 1 | Neighbor | (A, 129) | 1301 +------+-------------+---------+-------------+----------+ 1302 | " | E, F, G | P-DAO 1 | D | (A, 129) | 1303 +------+-------------+---------+-------------+----------+ 1304 | B | C | P-DAO 2 | Neighbor | (A, 129) | 1305 +------+-------------+---------+-------------+----------+ 1306 | " | E, F, G | P-DAO 2 | C | (A, 129) | 1307 +------+-------------+---------+-------------+----------+ 1308 | A | B | P-DAO 2 | Neighbor | (A, 129) | 1309 +------+-------------+---------+-------------+----------+ 1310 | A | E, F, G | P-DAO 2 | B | (A, 129) | 1311 +------+-------------+---------+-------------+----------+ 1313 Table 2: RIB setting 1315 E recognizes that it is the Track Egress because it is both a Target 1316 and a Segment Endpoint. 1318 Packets originated by A to E, F, or G, do not require an 1319 encapsulation. In any fashion, the outer headers of the packets that 1320 are forwarded along the Track have the following settings: 1322 +========+===================+===================+================+ 1323 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1324 +========+===================+===================+================+ 1325 | Outer | A | E, F or G | (A, 129) | 1326 +--------+-------------------+-------------------+----------------+ 1327 | Inner | X != A | E, F or G | N/A | 1328 +--------+-------------------+-------------------+----------------+ 1330 Table 3: Packet header settings 1332 As an example, say that A has a packet for F. Using the RIB above: 1334 * From P-DAO 2: A forwards to B and B forwards to C. 1336 * From P-DAO 1: C forwards to D and D forwards to E. 1338 * From Neighbor Cache Entry: C delivers the packet to F. 1340 9.1.2. External routes 1342 Storing-Mode P-DAO 1 and 2, and Non-Storing-Mode P-DAO 3, are sent to 1343 E, C and A, respectively, as follows: 1345 +===============+==============+==============+==============+ 1346 | | P-DAO 1 to E | P-DAO 2 to C | P-DAO 3 to A | 1347 +===============+==============+==============+==============+ 1348 | Mode | Storing | Storing | Non-Storing | 1349 +---------------+--------------+--------------+--------------+ 1350 | Track Ingress | A | A | A | 1351 +---------------+--------------+--------------+--------------+ 1352 | TrackID | (A, 129) | (A, 129) | (A, 129) | 1353 +---------------+--------------+--------------+--------------+ 1354 | VIO | C, D, E | A, B, C | E | 1355 +---------------+--------------+--------------+--------------+ 1356 | Targets | E | E | F, G | 1357 +---------------+--------------+--------------+--------------+ 1359 Table 4: P-DAO Messages 1361 As a result the RIBs are set as follows: 1363 +======+=============+=========+=============+==========+ 1364 | Node | Destination | Origin | Next Hop(s) | TrackID | 1365 +======+=============+=========+=============+==========+ 1366 | E | F, G | P-DAO 1 | Neighbor | (A, 129) | 1367 +------+-------------+---------+-------------+----------+ 1368 | D | E | P-DAO 1 | Neighbor | (A, 129) | 1369 +------+-------------+---------+-------------+----------+ 1370 | C | D | P-DAO 1 | Neighbor | (A, 129) | 1371 +------+-------------+---------+-------------+----------+ 1372 | " | E | P-DAO 1 | D | (A, 129) | 1373 +------+-------------+---------+-------------+----------+ 1374 | B | C | P-DAO 2 | Neighbor | (A, 129) | 1375 +------+-------------+---------+-------------+----------+ 1376 | " | E | P-DAO 2 | C | (A, 129) | 1377 +------+-------------+---------+-------------+----------+ 1378 | A | B | P-DAO 2 | Neighbor | (A, 129) | 1379 +------+-------------+---------+-------------+----------+ 1380 | A | E | P-DAO 2 | B | (A, 129) | 1381 +------+-------------+---------+-------------+----------+ 1382 | A | F, G | P-DAO 3 | E | (A, 129) | 1383 +------+-------------+---------+-------------+----------+ 1385 Table 5: RIB setting 1387 Packets from A to E do not require an encapsulation. In any fashion, 1388 the outer headers of the packets that are forwarded along the Track 1389 have the following settings: 1391 +========+===================+====================+================+ 1392 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1393 +========+===================+====================+================+ 1394 | Outer | A | E | (A, 129) | 1395 +--------+-------------------+--------------------+----------------+ 1396 | Inner | X | E (X != A), F or G | N/A | 1397 +--------+-------------------+--------------------+----------------+ 1399 Table 6: Packet header settings 1401 As an example, say that A has a packet for F. Using the RIB above: 1403 * From P-DAO 3: A encapsulates the packet the Track signaled by 1404 P-DAO 3, with the outer header above. Now the packet destination 1405 is E. 1407 * From P-DAO 2: A forwards to B and B forwards to C. 1409 * From P-DAO 1: C forwards to D and D forwards to E; E decapsulates 1410 the packet. 1412 * From Neighbor Cache Entry: C delivers packets to F or G. 1414 9.1.3. Segment Routing 1416 Storing-Mode P-DAO 1 and 2, and Non-Storing-Mode P-DAO 3, are sent to 1417 E, B and A, respectively, as follows: 1419 +===============+==============+==============+==============+ 1420 | | P-DAO 1 to E | P-DAO 2 to B | P-DAO 3 to A | 1421 +===============+==============+==============+==============+ 1422 | Mode | Storing | Storing | Non-Storing | 1423 +---------------+--------------+--------------+--------------+ 1424 | Track Ingress | A | A | A | 1425 +---------------+--------------+--------------+--------------+ 1426 | TrackID | (A, 129) | (A, 129) | (A, 129) | 1427 +---------------+--------------+--------------+--------------+ 1428 | VIO | C, D, E | A, B | C, E | 1429 +---------------+--------------+--------------+--------------+ 1430 | Targets | E | B, C | F, G | 1431 +---------------+--------------+--------------+--------------+ 1433 Table 7: P-DAO Messages 1435 As a result the RIBs are set as follows: 1437 +======+=============+=========+=============+==========+ 1438 | Node | Destination | Origin | Next Hop(s) | TrackID | 1439 +======+=============+=========+=============+==========+ 1440 | E | F, G | P-DAO 1 | Neighbor | (A, 129) | 1441 +------+-------------+---------+-------------+----------+ 1442 | D | E | P-DAO 1 | Neighbor | (A, 129) | 1443 +------+-------------+---------+-------------+----------+ 1444 | C | D | P-DAO 1 | Neighbor | (A, 129) | 1445 +------+-------------+---------+-------------+----------+ 1446 | " | E | P-DAO 1 | D | (A, 129) | 1447 +------+-------------+---------+-------------+----------+ 1448 | B | C | P-DAO 2 | Neighbor | (A, 129) | 1449 +------+-------------+---------+-------------+----------+ 1450 | A | B | P-DAO 2 | Neighbor | (A, 129) | 1451 +------+-------------+---------+-------------+----------+ 1452 | " | C | P-DAO 2 | B | (A, 129) | 1453 +------+-------------+---------+-------------+----------+ 1454 | " | E, F, G | P-DAO 3 | C, E | (A, 129) | 1455 +------+-------------+---------+-------------+----------+ 1457 Table 8: RIB setting 1459 Packets from A to E do not require an encapsulation, but carry a SRH 1460 via C. In any fashion, the outer headers of the packets that are 1461 forwarded along the Track have the following settings: 1463 +========+===================+====================+================+ 1464 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1465 +========+===================+====================+================+ 1466 | Outer | A | C till C then E | (A, 129) | 1467 +--------+-------------------+--------------------+----------------+ 1468 | Inner | X | E (X != A), F or G | N/A | 1469 +--------+-------------------+--------------------+----------------+ 1471 Table 9: Packet header settings 1473 As an example, say that A has a packet for F. Using the RIB above: 1475 * From P-DAO 3: A encapsulates the packet the Track signaled by 1476 P-DAO 3, with the outer header above. Now the destination in the 1477 IPv6 Header is C, and a SRH signals the final destination is E. 1479 * From P-DAO 2: A forwards to B and B forwards to C. 1481 * From P-DAO 3: C processes the SRH and sets the destination in the 1482 IPv6 Header to E. 1484 * From P-DAO 1: C forwards to D and D forwards to E; E decapsulates 1485 the packet. 1487 * From the Neighbor Cache Entry: C delivers packets to F or G. 1489 9.2. Using Non-Storing-Mode joining Tracks 1491 A==>B==>C and C==>D==>E are Tracks expressed as non-storing P-DAOs. 1493 9.2.1. Stitched Tracks 1495 Non-Storing Mode P-DAO 1 and 2 are sent to C and A respectively, as 1496 follows: 1498 +===============+==============+==============+ 1499 | | P-DAO 1 to C | P-DAO 2 to A | 1500 +===============+==============+==============+ 1501 | Mode | Non-Storing | Non-Storing | 1502 +---------------+--------------+--------------+ 1503 | Track Ingress | C | A | 1504 +---------------+--------------+--------------+ 1505 | TrackID | (C, 131) | (A, 129) | 1506 +---------------+--------------+--------------+ 1507 | VIO | D, E | B, C | 1508 +---------------+--------------+--------------+ 1509 | Targets | F, G | E, F, G | 1510 +---------------+--------------+--------------+ 1512 Table 10: P-DAO Messages 1514 As a result the RIBs are set as follows: 1516 +======+=============+=========+=============+==========+ 1517 | Node | Destination | Origin | Next Hop(s) | TrackID | 1518 +======+=============+=========+=============+==========+ 1519 | E | F, G | ND | Neighbor | Any | 1520 +------+-------------+---------+-------------+----------+ 1521 | D | E | ND | Neighbor | Any | 1522 +------+-------------+---------+-------------+----------+ 1523 | C | D | ND | Neighbor | Any | 1524 +------+-------------+---------+-------------+----------+ 1525 | " | E, F, G | P-DAO 1 | D, E | (C, 131) | 1526 +------+-------------+---------+-------------+----------+ 1527 | B | C | ND | Neighbor | Any | 1528 +------+-------------+---------+-------------+----------+ 1529 | A | B | ND | Neighbor | Any | 1530 +------+-------------+---------+-------------+----------+ 1531 | " | C, E, F, G | P-DAO 2 | B, C | (A, 129) | 1532 +------+-------------+---------+-------------+----------+ 1534 Table 11: RIB setting 1536 Packets from A to E, F and G do not require an encapsulation, though 1537 it is preferred that A encapsulates and C decapsulates. Either way, 1538 they carry a SRH via B and C, and C needs to encapsulate to E, F, or 1539 G to add an SRH via D and E. The encapsulating headers of packets 1540 that are forwarded along the Track between C and E have the following 1541 settings: 1543 +========+===================+===================+================+ 1544 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1545 +========+===================+===================+================+ 1546 | Outer | C | D till D then E | (C, 131) | 1547 +--------+-------------------+-------------------+----------------+ 1548 | Inner | X | E, F, or G | N/A | 1549 +--------+-------------------+-------------------+----------------+ 1551 Table 12: Packet header settings 1553 As an example, say that A has a packet for F. Using the RIB above: 1555 * From P-DAO 2: A encapsulates the packet with destination of F in 1556 the Track signaled by P-DAO 2. The outer header has source A, 1557 destination B, an SRH that indicates C as the next loose hop, and 1558 a RPI indicating a TrackId of 129 from A's namespace. 1560 * From the SRH: Packets forwarded by B have source A, destination C 1561 , a consumed SRH, and a RPI indicating a TrackId of 129 from A's 1562 namespace. C decapsulates. 1564 * From P-DAO 1: C encapsulates the packet with destination of F in 1565 the Track signaled by P-DAO 1. The outer header has source C, 1566 destination D, an SRH that indicates E as the next loose hop, and 1567 a RPI indicating a TrackId of 131 from C's namespace. E 1568 decapsulates. 1570 9.2.2. External routes 1572 Non-Storing Mode P-DAO 1 is sent to C and Non-Storing Mode P-DAO 2 1573 and 3 are sent A, as follows: 1575 +===============+==============+==============+==============+ 1576 | | P-DAO 1 to C | P-DAO 2 to A | P-DAO 3 to A | 1577 +===============+==============+==============+==============+ 1578 | Mode | Non-Storing | Non-Storing | Non-Storing | 1579 +---------------+--------------+--------------+--------------+ 1580 | Track Ingress | C | A | A | 1581 +---------------+--------------+--------------+--------------+ 1582 | TrackID | (C, 131) | (A, 129) | (A, 141) | 1583 +---------------+--------------+--------------+--------------+ 1584 | VIO | D, E | B, C | E | 1585 +---------------+--------------+--------------+--------------+ 1586 | Targets | E | E | F, G | 1587 +---------------+--------------+--------------+--------------+ 1589 Table 13: P-DAO Messages 1591 As a result the RIBs are set as follows: 1593 +======+=============+=========+=============+==========+ 1594 | Node | Destination | Origin | Next Hop(s) | TrackID | 1595 +======+=============+=========+=============+==========+ 1596 | E | F, G | ND | Neighbor | Any | 1597 +------+-------------+---------+-------------+----------+ 1598 | D | E | ND | Neighbor | Any | 1599 +------+-------------+---------+-------------+----------+ 1600 | C | D | ND | Neighbor | Any | 1601 +------+-------------+---------+-------------+----------+ 1602 | " | E | P-DAO 1 | D, E | (C, 131) | 1603 +------+-------------+---------+-------------+----------+ 1604 | B | C | ND | Neighbor | Any | 1605 +------+-------------+---------+-------------+----------+ 1606 | A | B | ND | Neighbor | Any | 1607 +------+-------------+---------+-------------+----------+ 1608 | " | C, E | P-DAO 2 | B, C | (A, 129) | 1609 +------+-------------+---------+-------------+----------+ 1610 | " | F, G | P-DAO 3 | E | (A, 141) | 1611 +------+-------------+---------+-------------+----------+ 1613 Table 14: RIB setting 1615 The encapsulating headers of packets that are forwarded along the 1616 Track between C and E have the following settings: 1618 +========+===================+===================+================+ 1619 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1620 +========+===================+===================+================+ 1621 | Outer | C | D till D then E | (C, 131) | 1622 +--------+-------------------+-------------------+----------------+ 1623 | Middle | A | E | (A, 141) | 1624 +--------+-------------------+-------------------+----------------+ 1625 | Inner | X | E, F or G | N/A | 1626 +--------+-------------------+-------------------+----------------+ 1628 Table 15: Packet header settings 1630 As an example, say that A has a packet for F. Using the RIB above: 1632 * From P-DAO 3: A encapsulates the packet with destination of F in 1633 the Track signaled by P-DAO 3. The outer header has source A, 1634 destination E, and a RPI indicating a TrackId of 141 from A's 1635 namespace. This recurses with: 1637 * From P-DAO 2: A encapsulates the packet with destination of E in 1638 the Track signaled by P-DAO 2. The outer header has source A, 1639 destination B, an SRH that indicates C as the next loose hop, and 1640 a RPI indicating a TrackId of 129 from A's namespace. 1642 * From the SRH: Packets forwarded by B have source A, destination C 1643 , a consumed SRH, and a RPI indicating a TrackId of 129 from A's 1644 namespace. C decapsulates. 1646 * From P-DAO 1: C encapsulates the packet with destination of E in 1647 the Track signaled by P-DAO 1. The outer header has source C, 1648 destination D, an SRH that indicates E as the next loose hop, and 1649 a RPI indicating a TrackId of 131 from C's namespace. E 1650 decapsulates. 1652 9.2.3. Segment Routing 1654 Non-Storing Mode P-DAO 1 is sent to C and Non-Storing Mode P-DAO 2 1655 and 3 are sent A, as follows: 1657 +===============+==============+==============+==============+ 1658 | | P-DAO 1 to C | P-DAO 2 to A | P-DAO 3 to A | 1659 +===============+==============+==============+==============+ 1660 | Mode | Non-Storing | Non-Storing | Non-Storing | 1661 +---------------+--------------+--------------+--------------+ 1662 | Track Ingress | C | A | A | 1663 +---------------+--------------+--------------+--------------+ 1664 | TrackID | (C, 131) | (A, 129) | (A, 141) | 1665 +---------------+--------------+--------------+--------------+ 1666 | VIO | D, E | B | C, E | 1667 +---------------+--------------+--------------+--------------+ 1668 | Targets | | C | F, G | 1669 +---------------+--------------+--------------+--------------+ 1671 Table 16: P-DAO Messages 1673 As a result the RIBs are set as follows: 1675 +======+=============+=========+=============+==========+ 1676 | Node | Destination | Origin | Next Hop(s) | TrackID | 1677 +======+=============+=========+=============+==========+ 1678 | E | F, G | ND | Neighbor | Any | 1679 +------+-------------+---------+-------------+----------+ 1680 | D | E | ND | Neighbor | Any | 1681 +------+-------------+---------+-------------+----------+ 1682 | C | D | ND | Neighbor | Any | 1683 +------+-------------+---------+-------------+----------+ 1684 | " | E | P-DAO 1 | D, E | (C, 131) | 1685 +------+-------------+---------+-------------+----------+ 1686 | B | C | ND | Neighbor | Any | 1687 +------+-------------+---------+-------------+----------+ 1688 | A | B | ND | Neighbor | Any | 1689 +------+-------------+---------+-------------+----------+ 1690 | " | C | P-DAO 2 | B, C | (A, 129) | 1691 +------+-------------+---------+-------------+----------+ 1692 | " | E, F, G | P-DAO 3 | C, E | (A, 141) | 1693 +------+-------------+---------+-------------+----------+ 1695 Table 17: RIB setting 1697 The encapsulating headers of packets that are forwarded along the 1698 Track between A and B have the following settings: 1700 +========+===================+===================+================+ 1701 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1702 +========+===================+===================+================+ 1703 | Outer | A | B till D then E | (A, 129) | 1704 +--------+-------------------+-------------------+----------------+ 1705 | Middle | A | C | (A, 141) | 1706 +--------+-------------------+-------------------+----------------+ 1707 | Inner | X | E, F or G | N/A | 1708 +--------+-------------------+-------------------+----------------+ 1710 Table 18: Packet header settings 1712 The encapsulating headers of packets that are forwarded along the 1713 Track between B and C have the following settings: 1715 +========+===================+===================+================+ 1716 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1717 +========+===================+===================+================+ 1718 | Outer | A | C | (A, 141) | 1719 +--------+-------------------+-------------------+----------------+ 1720 | Inner | X | E, F or G | N/A | 1721 +--------+-------------------+-------------------+----------------+ 1723 Table 19: Packet header settings 1725 The encapsulating headers of packets that are forwarded along the 1726 Track between C and E have the following settings: 1728 +========+===================+===================+================+ 1729 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1730 +========+===================+===================+================+ 1731 | Outer | C | D till D then E | (C, 131) | 1732 +--------+-------------------+-------------------+----------------+ 1733 | Middle | A | E | (A, 141) | 1734 +--------+-------------------+-------------------+----------------+ 1735 | Inner | X | E, F or G | N/A | 1736 +--------+-------------------+-------------------+----------------+ 1738 Table 20: Packet header settings 1740 As an example, say that A has a packet for F. Using the RIB above: 1742 * From P-DAO 3: A encapsulates the packet with destination of F in 1743 the Track signaled by P-DAO 3. The outer header has source A, 1744 destination C, an SRH that indicates E as the next loose hop, and 1745 a RPI indicating a TrackId of 141 from A's namespace. This 1746 recurses with: 1748 * From P-DAO 2: A encapsulates the packet with destination of C in 1749 the Track signaled by P-DAO 2. The outer header has source A, 1750 destination B, and a RPI indicating a TrackId of 129 from A's 1751 namespace. B decapsulates forwards to C based on a sibling 1752 connected route. 1754 * From the SRH: C consumes the SRH and makes the destination E. 1756 * From P-DAO 1: C encapsulates the packet with destination of E in 1757 the Track signaled by P-DAO 1. The outer header has source C, 1758 destination D, an SRH that indicates E as the next loose hop, and 1759 a RPI indicating a TrackId of 131 from C's namespace. E 1760 decapsulates. 1762 10. Security Considerations 1764 This draft uses messages that are already present in RPL [RPL] with 1765 optional secured versions. The same secured versions may be used 1766 with this draft, and whatever security is deployed for a given 1767 network also applies to the flows in this draft. 1769 TODO: should probably consider how P-DAO messages could be abused by 1770 a) rogue nodes b) via replay of messages c) if use of P-DAO messages 1771 could in fact deal with any threats? 1773 11. IANA Considerations 1775 11.1. New Elective 6LoWPAN Routing Header Type 1777 This document updates the IANA registry titled "Elective 6LoWPAN 1778 Routing Header Type" that was created for [RFC8138] and assigns the 1779 following value: 1781 +=======+=============+===============+ 1782 | Value | Description | Reference | 1783 +=======+=============+===============+ 1784 | 7 | P-RPI-6LoRH | This document | 1785 +-------+-------------+---------------+ 1787 Table 21: New Elective 6LoWPAN 1788 Routing Header Type 1790 11.2. New Critical 6LoWPAN Routing Header Type 1792 This document updates the IANA registry titled "Critical 6LoWPAN 1793 Routing Header Type" that was created for [RFC8138] and assigns the 1794 following value: 1796 +=======+=============+===============+ 1797 | Value | Description | Reference | 1798 +=======+=============+===============+ 1799 | 7 | P-RPI-6LoRH | This document | 1800 +-------+-------------+---------------+ 1802 Table 22: New Critical 6LoWPAN 1803 Routing Header Type 1805 11.3. New Subregistry For The RPL Option Flags 1807 IANA is required to create a subregistry for the 8-bit RPL Option 1808 Flags field, as detailed in Figure 2, under the "Routing Protocol for 1809 Low Power and Lossy Networks (RPL)" registry. The bits are indexed 1810 from 0 (leftmost) to 7. Each bit is tracked with the following 1811 qualities: 1813 * Bit number (counting from bit 0 as the most significant bit) 1815 * Indication When Set 1817 * Reference 1819 Registration procedure is "Standards Action" [RFC8126]. The initial 1820 allocation is as indicated in Table 26: 1822 +============+======================+===============+ 1823 | Bit number | Indication When Set | Reference | 1824 +============+======================+===============+ 1825 | 0 | Down 'O' | [RFC6553] | 1826 +------------+----------------------+---------------+ 1827 | 1 | Rank-Error (R) | [RFC6553] | 1828 +------------+----------------------+---------------+ 1829 | 2 | Forwarding-Error (F) | [RFC6553] | 1830 +------------+----------------------+---------------+ 1831 | 3 | Projected-Route (P) | This document | 1832 +------------+----------------------+---------------+ 1834 Table 23: Initial PDR Flags 1836 11.4. New RPL Control Codes 1838 This document extends the IANA Subregistry created by RFC 6550 for 1839 RPL Control Codes as indicated in Table 24: 1841 +======+=============================+===============+ 1842 | Code | Description | Reference | 1843 +======+=============================+===============+ 1844 | 0x09 | Projected DAO Request (PDR) | This document | 1845 +------+-----------------------------+---------------+ 1846 | 0x0A | PDR-ACK | This document | 1847 +------+-----------------------------+---------------+ 1849 Table 24: New RPL Control Codes 1851 11.5. New RPL Control Message Options 1853 This document extends the IANA Subregistry created by RFC 6550 for 1854 RPL Control Message Options as indicated in Table 25: 1856 +=======+============================+===============+ 1857 | Value | Meaning | Reference | 1858 +=======+============================+===============+ 1859 | 0x0B | Stateful VIO(SF-VIO) | This document | 1860 +-------+----------------------------+---------------+ 1861 | 0x0C | Source-Routed VIO(SR-VIO) | This document | 1862 +-------+----------------------------+---------------+ 1863 | 0x0D | Sibling Information option | This document | 1864 +-------+----------------------------+---------------+ 1866 Table 25: RPL Control Message Options 1868 11.6. SubRegistry for the Projected DAO Request Flags 1870 IANA is required to create a registry for the 8-bit Projected DAO 1871 Request (PDR) Flags field. Each bit is tracked with the following 1872 qualities: 1874 * Bit number (counting from bit 0 as the most significant bit) 1876 * Capability description 1878 * Reference 1880 Registration procedure is "Standards Action" [RFC8126]. The initial 1881 allocation is as indicated in Table 26: 1883 +============+========================+===============+ 1884 | Bit number | Capability description | Reference | 1885 +============+========================+===============+ 1886 | 0 | PDR-ACK request (K) | This document | 1887 +------------+------------------------+---------------+ 1888 | 1 | Requested path should | This document | 1889 | | be redundant (R) | | 1890 +------------+------------------------+---------------+ 1892 Table 26: Initial PDR Flags 1894 11.7. SubRegistry for the PDR-ACK Flags 1896 IANA is required to create an subregistry for the 8-bit PDR-ACK Flags 1897 field. Each bit is tracked with the following qualities: 1899 * Bit number (counting from bit 0 as the most significant bit) 1901 * Capability description 1903 * Reference 1905 Registration procedure is "Standards Action" [RFC8126]. No bit is 1906 currently defined for the PDR-ACK Flags. 1908 11.8. Subregistry for the PDR-ACK Acceptance Status Values 1910 IANA is requested to create a Subregistry for the PDR-ACK Acceptance 1911 Status values. 1913 * Possible values are 6-bit unsigned integers (0..63). 1915 * Registration procedure is "Standards Action" [RFC8126]. 1917 * Initial allocation is as indicated in Table 27: 1919 +-------+------------------------+---------------+ 1920 | Value | Meaning | Reference | 1921 +-------+------------------------+---------------+ 1922 | 0 | Unqualified acceptance | This document | 1923 +-------+------------------------+---------------+ 1925 Table 27: Acceptance values of the PDR-ACK Status 1927 11.9. Subregistry for the PDR-ACK Rejection Status Values 1929 IANA is requested to create a Subregistry for the PDR-ACK Rejection 1930 Status values. 1932 * Possible values are 6-bit unsigned integers (0..63). 1934 * Registration procedure is "Standards Action" [RFC8126]. 1936 * Initial allocation is as indicated in Table 28: 1938 +-------+-----------------------+---------------+ 1939 | Value | Meaning | Reference | 1940 +-------+-----------------------+---------------+ 1941 | 0 | Unqualified rejection | This document | 1942 +-------+-----------------------+---------------+ 1944 Table 28: Rejection values of the PDR-ACK Status 1946 11.10. SubRegistry for the Via Information Options Flags 1948 IANA is requested to create a Subregistry for the 5-bit Via 1949 Information Options (Via Information Option) Flags field. Each bit 1950 is tracked with the following qualities: 1952 * Bit number (counting from bit 0 as the most significant bit) 1954 * Capability description 1956 * Reference 1958 Registration procedure is "Standards Action" [RFC8126]. No bit is 1959 currently defined for the Via Information Options (Via Information 1960 Option) Flags. 1962 11.11. SubRegistry for the Sibling Information Option Flags 1964 IANA is required to create a registry for the 5-bit Sibling 1965 Information Option (SIO) Flags field. Each bit is tracked with the 1966 following qualities: 1968 * Bit number (counting from bit 0 as the most significant bit) 1970 * Capability description 1972 * Reference 1974 Registration procedure is "Standards Action" [RFC8126]. The initial 1975 allocation is as indicated in Table 29: 1977 +============+===================================+===============+ 1978 | Bit number | Capability description | Reference | 1979 +============+===================================+===============+ 1980 | 0 | Connectivity is bidirectional (B) | This document | 1981 +------------+-----------------------------------+---------------+ 1983 Table 29: Initial SIO Flags 1985 11.12. New Destination Advertisement Object Flag 1987 This document modifies the "Destination Advertisement Object (DAO) 1988 Flags" registry initially created in Section 20.11 of [RPL] . 1990 Section 3.1 also defines one new entry in the Registry as follows: 1992 +---------------+------------------------+-----------+ 1993 | Bit Number | Capability Description | Reference | 1994 +---------------+------------------------+-----------+ 1995 | 2 (suggested) | Projected DAO (P) | THIS RFC | 1996 +---------------+------------------------+-----------+ 1998 Table 30: New Destination Advertisement Object 1999 (DAO) Flag 2001 11.13. Error in Projected Route ICMPv6 Code 2003 In some cases RPL will return an ICMPv6 error message when a message 2004 cannot be forwarded along a Projected Route. This ICMPv6 error 2005 message is "Error in Projected Route". 2007 IANA has defined an ICMPv6 "Code" Fields Registry for ICMPv6 Message 2008 Types. ICMPv6 Message Type 1 describes "Destination Unreachable" 2009 codes. This specification requires that a new code is allocated from 2010 the ICMPv6 Code Fields Registry for ICMPv6 Message Type 1, for "Error 2011 in Projected Route", with a suggested code value of 8, to be 2012 confirmed by IANA. 2014 12. Acknowledgments 2016 The authors wish to acknowledge JP Vasseur, Remy Liubing, James 2017 Pylakutty and Patrick Wetterwald for their contributions to the ideas 2018 developed here. 2020 13. Normative References 2022 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2023 Requirement Levels", BCP 14, RFC 2119, 2024 DOI 10.17487/RFC2119, March 1997, 2025 . 2027 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2028 Control Message Protocol (ICMPv6) for the Internet 2029 Protocol Version 6 (IPv6) Specification", STD 89, 2030 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2031 . 2033 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 2034 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 2035 DOI 10.17487/RFC6282, September 2011, 2036 . 2038 [RPL] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 2039 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 2040 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 2041 Low-Power and Lossy Networks", RFC 6550, 2042 DOI 10.17487/RFC6550, March 2012, 2043 . 2045 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 2046 Power and Lossy Networks (RPL) Option for Carrying RPL 2047 Information in Data-Plane Datagrams", RFC 6553, 2048 DOI 10.17487/RFC6553, March 2012, 2049 . 2051 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 2052 Routing Header for Source Routes with the Routing Protocol 2053 for Low-Power and Lossy Networks (RPL)", RFC 6554, 2054 DOI 10.17487/RFC6554, March 2012, 2055 . 2057 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2058 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2059 May 2017, . 2061 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2062 Writing an IANA Considerations Section in RFCs", BCP 26, 2063 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2064 . 2066 14. Informative References 2068 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 2069 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 2070 2014, . 2072 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and 2073 J. Martocci, "Reactive Discovery of Point-to-Point Routes 2074 in Low-Power and Lossy Networks", RFC 6997, 2075 DOI 10.17487/RFC6997, August 2013, 2076 . 2078 [6TiSCH-ARCHI] 2079 Thubert, P., Ed., "An Architecture for IPv6 over the Time- 2080 Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)", 2081 RFC 9030, DOI 10.17487/RFC9030, May 2021, 2082 . 2084 [RAW-ARCHI] 2085 Thubert, P., Papadopoulos, G. Z., and R. Buddenberg, 2086 "Reliable and Available Wireless Architecture/Framework", 2087 Work in Progress, Internet-Draft, draft-pthubert-raw- 2088 architecture-05, 15 November 2020, 2089 . 2092 [TURN-ON_RFC8138] 2093 Thubert, P., Ed. and L. Zhao, "A Routing Protocol for Low- 2094 Power and Lossy Networks (RPL) Destination-Oriented 2095 Directed Acyclic Graph (DODAG) Configuration Option for 2096 the 6LoWPAN Routing Header", RFC 9035, 2097 DOI 10.17487/RFC9035, April 2021, 2098 . 2100 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 2101 "Deterministic Networking Architecture", RFC 8655, 2102 DOI 10.17487/RFC8655, October 2019, 2103 . 2105 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 2106 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 2107 RFC 8025, DOI 10.17487/RFC8025, November 2016, 2108 . 2110 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 2111 "IPv6 over Low-Power Wireless Personal Area Network 2112 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 2113 April 2017, . 2115 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 2116 Perkins, "Registration Extensions for IPv6 over Low-Power 2117 Wireless Personal Area Network (6LoWPAN) Neighbor 2118 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 2119 . 2121 [USEofRPLinfo] 2122 Robles, M.I., Richardson, M., and P. Thubert, "Using RPI 2123 Option Type, Routing Header for Source Routes, and IPv6- 2124 in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008, 2125 DOI 10.17487/RFC9008, April 2021, 2126 . 2128 [PCE] IETF, "Path Computation Element", 2129 . 2131 Appendix A. Applications 2133 A.1. Loose Source Routing 2135 A RPL implementation operating in a very constrained LLN typically 2136 uses the Non-Storing Mode of Operation as represented in Figure 12. 2137 In that mode, a RPL node indicates a parent-child relationship to the 2138 Root, using a Destination Advertisement Object (DAO) that is unicast 2139 from the node directly to the Root, and the Root typically builds a 2140 source routed path to a destination down the DODAG by recursively 2141 concatenating this information. 2143 ------+--------- 2144 | Internet 2145 | 2146 +-----+ 2147 | | Border Router 2148 | | (RPL Root) 2149 +-----+ ^ | | 2150 | | DAO | ACK | 2151 o o o o | | | Strict 2152 o o o o o o o o o | | | Source 2153 o o o o o o o o o o | | | Route 2154 o o o o o o o o o | | | 2155 o o o o o o o o | v v 2156 o o o o 2157 LLN 2159 Figure 12: RPL Non-Storing Mode of operation 2161 Based on the parent-children relationships expressed in the non- 2162 storing DAO messages,the Root possesses topological information about 2163 the whole network, though this information is limited to the 2164 structure of the DODAG for which it is the destination. A packet 2165 that is generated within the domain will always reach the Root, which 2166 can then apply a source routing information to reach the destination 2167 if the destination is also in the DODAG. Similarly, a packet coming 2168 from the outside of the domain for a destination that is expected to 2169 be in a RPL domain reaches the Root. 2171 It results that the Root, or then some associated centralized 2172 computation engine such as a PCE, can determine the amount of packets 2173 that reach a destination in the RPL domain, and thus the amount of 2174 energy and bandwidth that is wasted for transmission, between itself 2175 and the destination, as well as the risk of fragmentation, any 2176 potential delays because of a paths longer than necessary (shorter 2177 paths exist that would not traverse the Root). 2179 As a network gets deep, the size of the source routing header that 2180 the Root must add to all the downward packets becomes an issue for 2181 nodes that are many hops away. In some use cases, a RPL network 2182 forms long lines and a limited amount of well-Targeted routing state 2183 would allow to make the source routing operation loose as opposed to 2184 strict, and save packet size. Limiting the packet size is directly 2185 beneficial to the energy budget, but, mostly, it reduces the chances 2186 of frame loss and/or packet fragmentation, which is highly 2187 detrimental to the LLN operation. Because the capability to store a 2188 routing state in every node is limited, the decision of which route 2189 is installed where can only be optimized with a global knowledge of 2190 the system, a knowledge that the Root or an associated PCE may 2191 possess by means that are outside of the scope of this specification. 2193 This specification enables to store a Storing Mode state in 2194 intermediate routers, which enables to limit the excursion of the 2195 source route headers in deep networks. Once a P-DAO exchange has 2196 taken place for a given Target, if the Root operates in non Storing 2197 Mode, then it may elide the sequence of routers that is installed in 2198 the network from its source route headers to destination that are 2199 reachable via that Target, and the source route headers effectively 2200 become loose. 2202 A.2. Transversal Routes 2204 RPL is optimized for Point-to-Multipoint (P2MP) and Multipoint-to- 2205 Point (MP2P), whereby routes are always installed along the RPL DODAG 2206 respectively from and towards the DODAG Root. Transversal Peer to 2207 Peer (P2P) routes in a RPL network will generally suffer from some 2208 elongated (stretched) path versus the best possible path, since 2209 routing between 2 nodes always happens via a common parent, as 2210 illustrated in Figure 13: 2212 * In Storing Mode, unless the destination is a child of the source, 2213 the packets will follow the default route up the DODAG as well. 2214 If the destination is in the same DODAG, they will eventually 2215 reach a common parent that has a route to the destination; at 2216 worse, the common parent may also be the Root. From that common 2217 parent, the packet will follow a path down the DODAG that is 2218 optimized for the Objective Function that was used to build the 2219 DODAG. 2221 * in Non-Storing Mode, all packets routed within the DODAG flow all 2222 the way up to the Root of the DODAG. If the destination is in the 2223 same DODAG, the Root must encapsulate the packet to place an RH 2224 that has the strict source route information down the DODAG to the 2225 destination. This will be the case even if the destination is 2226 relatively close to the source and the Root is relatively far off. 2228 ------+--------- 2229 | Internet 2230 | 2231 +-----+ 2232 | | Border Router 2233 | | (RPL Root) 2234 +-----+ 2235 X 2236 ^ v o o 2237 ^ o o v o o o o o 2238 ^ o o o v o o o o o 2239 ^ o o v o o o o o 2240 S o o o D o o o 2241 o o o o 2242 LLN 2244 Figure 13: Routing Stretch between S and D via common parent X 2246 It results that it is often beneficial to enable transversal P2P 2247 routes, either if the RPL route presents a stretch from shortest 2248 path, or if the new route is engineered with a different objective, 2249 and that it is even more critical in Non-Storing Mode than it is in 2250 Storing Mode, because the routing stretch is wider. For that reason, 2251 earlier work at the IETF introduced the "Reactive Discovery of 2252 Point-to-Point Routes in Low Power and Lossy Networks" [RFC6997], 2253 which specifies a distributed method for establishing optimized P2P 2254 routes. This draft proposes an alternate based on a centralized 2255 route computation. 2257 ------+--------- 2258 | Internet 2259 | 2260 +-----+ 2261 | | Border Router 2262 | | (RPL Root) 2263 +-----+ 2264 | 2265 o o o o 2266 o o o o o o o o o 2267 o o o o o o o o o o 2268 o o o o o o o o o 2269 S>>A>>>B>>C>>>D o o o 2270 o o o o 2271 LLN 2273 Figure 14: Projected Transversal Route 2275 This specification enables to store source-routed or Storing Mode 2276 state in intermediate routers, which enables to limit the stretch of 2277 a P2P route and maintain the characteristics within a given SLA. An 2278 example of service using this mechanism oculd be a control loop that 2279 would be installed in a network that uses classical RPL for 2280 asynchronous data collection. In that case, the P2P path may be 2281 installed in a different RPL Instance, with a different objective 2282 function. 2284 Authors' Addresses 2286 Pascal Thubert (editor) 2287 Cisco Systems, Inc 2288 Building D 2289 45 Allee des Ormes - BP1200 2290 06254 Mougins - Sophia Antipolis 2291 France 2293 Phone: +33 497 23 26 34 2294 Email: pthubert@cisco.com 2296 Rahul Arvind Jadhav 2297 Huawei Tech 2298 Kundalahalli Village, Whitefield, 2299 Bangalore 560037 2300 Karnataka 2301 India 2303 Phone: +91-080-49160700 2304 Email: rahul.ietf@gmail.com 2306 Matthew Gillmore 2307 Itron, Inc 2308 Building D 2309 2111 N Molter Road 2310 Liberty Lake, 99019 2311 United States 2313 Phone: +1.800.635.5461 2314 Email: matthew.gillmore@itron.com