idnits 2.17.1 draft-ietf-roll-dao-projection-16.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 (15 January 2021) is 1169 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 == Outdated reference: A later version (-44) exists of draft-ietf-roll-useofrplinfo-43 Summary: 0 errors (**), 0 flaws (~~), 4 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: 19 July 2021 M. Gillmore 7 Itron 8 15 January 2021 10 Root initiated routing state in RPL 11 draft-ietf-roll-dao-projection-16 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 19 July 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 . . . . . . . . . . . . 10 72 6.2. New PDR-ACK Control Message . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . 18 77 7.2. Identifying a Track . . . . . . . . . . . . . . . . . . . 19 78 7.3. Installing a Track . . . . . . . . . . . . . . . . . . . 20 79 7.3.1. Storing-Mode P-Route . . . . . . . . . . . . . . . . 21 80 7.3.2. Non-Storing-Mode P-Route . . . . . . . . . . . . . . 23 81 7.4. Forwarding Along a Track . . . . . . . . . . . . . . . . 24 82 8. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 25 83 9. Example Track Signaling . . . . . . . . . . . . . . . . . . . 26 84 9.1. Using Storing-Mode Segments . . . . . . . . . . . . . . . 27 85 9.1.1. Stitched Segments . . . . . . . . . . . . . . . . . . 27 86 9.1.2. External routes . . . . . . . . . . . . . . . . . . . 29 87 9.1.3. Segment Routing . . . . . . . . . . . . . . . . . . . 30 88 9.2. Using Non-Storing-Mode joining Tracks . . . . . . . . . . 32 89 9.2.1. Stitched Tracks . . . . . . . . . . . . . . . . . . . 32 90 9.2.2. External routes . . . . . . . . . . . . . . . . . . . 34 91 9.2.3. Segment Routing . . . . . . . . . . . . . . . . . . . 36 92 10. Security Considerations . . . . . . . . . . . . . . . . . . . 39 93 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 94 11.1. New Elective 6LoWPAN Routing Header Type . . . . . . . . 39 95 11.2. New Critical 6LoWPAN Routing Header Type . . . . . . . . 39 96 11.3. New Subregistry For The RPL Option Flags . . . . . . . . 40 97 11.4. New RPL Control Codes . . . . . . . . . . . . . . . . . 40 98 11.5. New RPL Control Message Options . . . . . . . . . . . . 41 99 11.6. SubRegistry for the Projected DAO Request Flags . . . . 41 100 11.7. SubRegistry for the PDR-ACK Flags . . . . . . . . . . . 41 101 11.8. Subregistry for the PDR-ACK Acceptance Status Values . . 42 102 11.9. Subregistry for the PDR-ACK Rejection Status Values . . 42 103 11.10. SubRegistry for the Via Information Options Flags . . . 43 104 11.11. SubRegistry for the Sibling Information Option Flags . . 43 105 11.12. New Destination Advertisement Object Flag . . . . . . . 43 106 11.13. Error in Projected Route ICMPv6 Code . . . . . . . . . . 44 107 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 108 13. Normative References . . . . . . . . . . . . . . . . . . . . 44 109 14. Informative References . . . . . . . . . . . . . . . . . . . 45 110 Appendix A. Applications . . . . . . . . . . . . . . . . . . . . 46 111 A.1. Loose Source Routing . . . . . . . . . . . . . . . . . . 47 112 A.2. Transversal Routes . . . . . . . . . . . . . . . . . . . 48 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 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. 266 2.4. References 268 In this document, readers will encounter terms and concepts that are 269 discussed in the "Routing Protocol for Low Power and Lossy Networks" 270 [RPL] and "Terminology in Low power And Lossy Networks" [RFC7102]. 272 3. Extending RFC 6550 274 3.1. Projected DAO 276 Section 6 of [RPL] introduces the RPL Control Message Options (CMO), 277 including the RPL Target Option (RTO) and Transit Information Option 278 (TIO), which can be placed in RPL messages such as the Destination 279 Advertisement Object (DAO). This specification extends the DAO 280 message with the Projected DAO (P-DAO); a P-DAO message signals a 281 Projected Route to one or more Targets using the new CMOs presented 282 therein. This specification enables to combine one or more Projected 283 Routes into a DODAG called a Track, that is traversed to reach the 284 Targets. 286 The Track is assimilated with the DODAG formed for a Local RPL 287 Instance. The local RPLInstanceID of the Track is called the 288 TrackID, more in Section 7.2. A P-DAO message for a Track signals 289 the TrackID in the RPLInstanceID field. The Track Ingress is 290 signaled in the DODAGID field of the Projected DAO Base Object; that 291 field is elided in the case of the main RPL Instance. The Track 292 Ingress is the Root of the Track, as shown in Figure 1. 294 This specification defines the new "Projected DAO" (P) flag. The 'P' 295 flag is encoded in bit position 2 (to be confirmed by IANA) of the 296 Flags field in the DAO Base Object. The Root MUST set it to 1 in a 297 Projected DAO message. Otherwise it MUST be set to 0. It is set to 298 0 in legacy implementations as specified respectively in Sections 299 20.11 and 6.4 of [RPL]. . 301 0 1 2 3 302 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 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | TrackID |K|D|P| Flags | Reserved | DAOSequence | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | | 307 + + 308 | | 309 + IPv6 Address of the Track Ingress + 310 | | 311 + + 312 | | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Option(s)... 315 +-+-+-+-+-+-+-+-+ 317 Figure 1: Projected DAO Base Object 319 New fields: 321 TrackID: In the case of a P-DAO, the RPLInstanceID field is called 322 TrackID. This is a naming convenience but does not change the 323 semantics and format of the RPLInstanceID that is used as TrackID. 325 P: 1-bit flag (position to be confirmed by IANA). 327 The 'P' flag is set to 1 by the Root to signal a Projected DAO, 328 and it is set to 0 otherwise. 330 In RPL Non-Storing Mode, the TIO and RTO are combined in a DAO 331 message to inform the DODAG Root of all the edges in the DODAG, which 332 are formed by the directed parent-child relationships. Options may 333 be factorized; multiple RTOs may be present to signal a collection of 334 children that can be reached via the parent(s) indicated in the 335 TIO(s) that follows the RTOs. This specification generalizes the 336 case of a parent that can be used to reach a child with that of a 337 whole Track through which both children and siblings of the Track 338 Egress are reachable. 340 New CMOs called the Via Information Options (VIO) are introduced for 341 use in P-DAO messages as a multihop alternative to the TIO. One VIO 342 is the Stateful VIO(SF-VIO); the SF-VIO installs Storing-Mode 343 Projected Route along a strict segment. The other is the Source- 344 Routed VIO (SR-VIO); the SR-VIO installs a Non-Storing-Mode Projected 345 Route at the Track Ingress, which uses that state to encapsulate a 346 packet with a Routing Header (RH) to the Track Egress. 348 Like in a DAO message, the RTOs can be factorized in a P-DAO, but the 349 Via Information Options cannot. A P-DAO contains one or more RTOs 350 that indicate the destinations that can be reached via the Track, and 351 exactly one VIOthat signals a sequence of nodes. In Non-Storing 352 Mode, the Root sends the P-DAO to the Track Ingress where the source- 353 routing state is stored. In Storing Mode, the P-DAO is sent to the 354 Track Egress and forwarded along the Segment in the reverse 355 direction, installing a Storing Mode state to the Track Egress at 356 each hop. In both cases the Track Ingress is the owner of the Track, 357 and it generates the P-DAO-ACK when the installation is successful. 359 3.2. Sibling Information Option 361 This specification adds another CMO called the Sibling Information 362 Option (SIO) that is used by a RPL Aware Node (RAN) to advertise a 363 selection of its candidate neighbors as siblings to the Root, more in 364 Section 6.4. The sibling selection process is out of scope. 366 3.3. P-DAO Request 368 Two new RPL Control Messages are also introduced, to enable a RAN to 369 request the establishment of a Track between self as the Track 370 Ingress Node and a Track Egress. The RAN makes its request by 371 sending a new P-DAO Request (PDR) Message to the Root. The Root 372 confirms with a new PDR-ACK message back to the requester RAN, see 373 Section 6.1 for more. A positive PDR-ACK indicates that the Track 374 was built and that the Roots commits to maintain the Track for the 375 negotiated lifetime. In the case of a complex Track, each Segment is 376 maintained independently and asynchronously by the Root, with its own 377 lifetime that may be shorter, the same, or longer than that of the 378 Track. The Root may use an asynchronous PDR-ACK with an negative 379 status to indicate that the Track was terminated before its time. 381 3.4. Extending the RPI 383 Sending a Packet within a RPL Local Instance requires the presence of 384 the abstract RPL Packet Information (RPI) described in section 11.2. 385 of [RPL] in the outer IPv6 Header chain (see [USEofRPLinfo]). The 386 RPI carries a local RPLInstanceID which, in association with either 387 the source or the destination address in the IPv6 Header, indicates 388 the RPL Instance that the packet follows. 390 This specification extends [RPL] to create a new flag that signals 391 that a packet is forwarded along a projected route. 393 Projected-Route 'P': 1-bit flag. It is set to 1 if this packet is 394 sent over a projected route and set to 0 otherwise. 396 4. Extending RFC 6553 398 "The RPL Option for Carrying RPL Information in Data-Plane Datagrams" 399 [RFC6553]describes the RPL Option for use among RPL routers to 400 include the abstract RPL Packet Information (RPI) described in 401 section 11.2. of [RPL] in data packets. 403 The RPL Option is commonly referred to as the RPI though the RPI is 404 really the abstract information that is transported in the RPL 405 Option. [USEofRPLinfo] updated the Option Type from 0x63 to 0x23. 407 This specification modifies the RPL Option to encode the 'P' flag as 408 follows: 410 0 1 2 3 411 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 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Option Type | Opt Data Len | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 |O|R|F|P|0|0|0|0| RPLInstanceID | SenderRank | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | (sub-TLVs) | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 Figure 2: Extended RPL Option Format 422 Option Type: 0x23 or 0x63, see [USEofRPLinfo] 424 Opt Data Len: See [RFC6553] 426 'O', 'R' and 'F' flags: See [RFC6553]. Those flags MUST be set to 0 427 by the sender and ignored by the receiver if the 'P' flag is set. 429 Projected-Route 'P': 1-bit flag as defined in Section 3.4. 431 RPLInstanceID: See [RFC6553]. Indicates the TrackId if the 'P' flag 432 is set. 434 SenderRank: See [RFC6553]. This field MUST be set to 0 by the 435 sender and ignored by the receiver if the 'P'flag is set. 437 5. Extending RFC 8138 439 Section 6.3 of [RFC8138] presents the formats of the 6LoWPAN Routing 440 Header of type 5 (RPI-6LoRH) that compresses the RPI for normal RPL 441 operation. The format of the RPI-6LoRH is not suited for Projected 442 routes since the O,R,F flags are not used and the Rank is unknown and 443 ignored. 445 This specification introduces a new 6LoRH, the P-RPI-6LoRH, with a 446 type of 7. The P-RPI-6LoRH header is usually a a Critical 6LoWPAN 447 Routing Header, but it can be elective as well if an SRH-6LoRH is 448 present and controls the routing decision. 450 The P-RPI-6LoRH is designed to compress the RPI along RPL Projected 451 Routes. It sformat is as follows: 453 0 1 2 454 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 |1|0|E| Length | 6LoRH Type 7 | RPLInstanceID | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 Figure 3: P-RPI-6LoRH Format 461 Elective 'E': See [RFC8138]. The 'E' flag is set to 1 to indicate 462 an Elective 6LoRH, meaning that it can be ignored when forwarding. 464 6. New RPL Control Messages and Options 466 6.1. New P-DAO Request Control Message 468 The P-DAO Request (PDR) message is sent by a Node in the main DODAG 469 to the Root. It is a request to establish or refresh a Track. 470 Exactly one RTO MUST be present in a PDR. The RTO signals the Track 471 Egress, more in Section 7.1. 473 The RPL Control Code for the PDR is 0x09, to be confirmed by IANA. 474 The format of PDR Base Object is as follows: 476 0 1 2 3 477 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 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | TrackID |K|R| Flags | ReqLifetime | PDRSequence | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Option(s)... 482 +-+-+-+-+-+-+-+-+ 484 Figure 4: New P-DAO Request Format 486 TrackID: 8-bit field indicating the RPLInstanceID associated with 487 the Track. It is set to zero upon the first request for a new 488 Track and then to the TrackID once the Track was created, to 489 either renew it of destroy it. 491 K: The 'K' flag is set to indicate that the recipient is expected to 492 send a PDR-ACK back. 494 R: The 'R' flag is set to request a Complex Track for redundancy. 496 Flags: Reserved. The Flags field MUST initialized to zero by the 497 sender and MUST be ignored by the receiver 499 ReqLifetime: 8-bit unsigned integer. The requested lifetime for the 500 Track expressed in Lifetime Units (obtained from the DODAG 501 Configuration option). 503 A PDR with a fresher PDRSequence refreshes the lifetime, and a 504 PDRLifetime of 0 indicates that the track should be destroyed. 506 PDRSequence: 8-bit wrapping sequence number, obeying the operation 507 in section 7.2 of [RPL]. The PDRSequence is used to correlate a 508 PDR-ACK message with the PDR message that triggered it. It is 509 incremented at each PDR message and echoed in the PDR-ACK by the 510 Root. 512 6.2. New PDR-ACK Control Message 514 The new PDR-ACK is sent as a response to a PDR message with the 'K' 515 flag set. The RPL Control Code for the PDR-ACK is 0x0A, to be 516 confirmed by IANA. Its format is as follows: 518 0 1 2 3 519 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 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | TrackID | Flags | Track Lifetime| PDRSequence | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | PDR-ACK Status| Reserved | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Option(s)... 526 +-+-+-+-+-+-+-+ 528 Figure 5: New PDR-ACK Control Message Format 530 TrackID: The RPLInstanceID of the Track that was created. The value 531 of 0x00 is used to when no Track was created. 533 Flags: Reserved. The Flags field MUST initialized to zero by the 534 sender and MUST be ignored by the receiver 536 Track Lifetime: Indicates that remaining Lifetime for the Track, 537 expressed in Lifetime Units; the value of zero (0x00) indicates 538 that the Track was destroyed or not created. 540 PDRSequence: 8-bit wrapping sequence number. It is incremented at 541 each PDR message and echoed in the PDR-ACK. 543 PDR-ACK Status: 8-bit field indicating the completion. The PDR-ACK 544 Status is substructured as indicated in Figure 6: 546 0 1 2 3 4 5 6 7 547 +-+-+-+-+-+-+-+-+ 548 |E|R| Value | 549 +-+-+-+-+-+-+-+-+ 551 Figure 6: PDR-ACK status Format 553 E: 1-bit flag. Set to indicate a rejection. When not set, the 554 value of 0 indicates Success/Unqualified acceptance and other 555 values indicate "not an outright rejection". 556 R: 1-bit flag. Reserved, MUST be set to 0 by the sender and 557 ignored by the receiver. 558 Status Value: 6-bit unsigned integer. Values depending on the 559 setting of the 'E' flag, see Table 27 and Table 28. 561 Reserved: The Reserved field MUST initialized to zero by the sender 562 and MUST be ignored by the receiver 564 6.3. Via Information Options 566 An VIOsignals the ordered list of IPv6 Via Addresses that constitutes 567 the hops of either a Serial Track or a Segment of a more Complex 568 Track. An VIOMUST contain at least one Via Address, and a Via 569 Address MUST NOT be present more than once, otherwise the VIOMUST be 570 ignored. The format of the Via Information Options is as follows: 572 0 1 2 3 573 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 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Type | Option Length | Flags | SegmentID | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 |Segm. Sequence | Seg. Lifetime | SRH-6LoRH header | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | | 580 + + 581 . . 582 . Via Address 1 . 583 . . 584 + + 585 | | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | | 588 . .... . 589 | | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | | 592 + + 593 . . 594 . Via Address n . 595 . . 596 + + 597 | | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 Figure 7: VIOformat (uncompressed form) 602 Option Type: 0x0B for SF-VIO, 0x0C for SR-VIO (to be confirmed by 603 IANA) 605 Option Length: In bytes; variable, depending on the number of Via 606 Addresses and the compression. 608 SegmentID: 8-bit field that identifies a Segment within a Track or 609 the main DODAG as indicated by the TrackID field. The value of 0 610 is used to signal a Serial Track, i.e., made of a single segment. 612 Segment Sequence: 8-bit unsigned integer. The Segment Sequence 613 obeys the operation in section 7.2 of [RPL] and the lollipop 614 starts at 255. 616 When the Root of the DODAG needs to refresh or update a Segment in 617 a Track, it increments the Segment Sequence individually for that 618 Segment. 620 The Segment information indicated in the VIOdeprecates any state 621 for the Segment indicated by the SegmentID within the indicated 622 Track and sets up the new information. 624 An VIOwith a Segment Sequence that is not as fresh as the current 625 one is ignored. 627 A VIO for a given DODAGID with the same (TrackID, SegmentID, 628 Segment Sequence) indicates a retry; it MUST NOT change the 629 Segment and MUST be propagated or answered as the first copy. 631 Segment Lifetime: 8-bit unsigned integer. The length of time in 632 Lifetime Units (obtained from the Configuration option) that the 633 Segment is usable. 635 The period starts when a new Segment Sequence is seen. The value 636 of 255 (0xFF) represents infinity. The value of zero (0x00) 637 indicates a loss of reachability. 639 A P-DAO message that contains a VIOwith a Segment Lifetime of zero 640 is referred as a No-Path P-DAO in this document. 642 SRH-6LoRH header: The first 2 bytes of the (first) SRH-6LoRH as 643 shown in Figure 6 of [RFC8138]. A 6LoRH Type of 4 means that the 644 VIA Addresses are provided in full with no compression. 646 Via Address: An IPv6 addresse along the Segment. 648 In a SF-VIO, the list is a strict path between direct neighbors, 649 from the segment ingress to egress, both included. In an SR-VIO, 650 the list starts at the first hop and ends at a Track Egress. The 651 list in an SR-VIO may be loose, provided that each listed node has 652 a path to the next listed node, e.g., via a segment or another 653 Track. 655 In the case of a SF-VIO, or if [RFC8138] is not used in the data 656 packets, then the Root MUST use only one SRH-6LoRH per Via 657 Information Option, and the compression is the same for all the 658 addresses, as shown in Figure 7. 660 In case of an SR-VIO, and if [RFC8138] is in use in the main 661 DODAG, then the Root SHOULD optimize the size of the SR-VIO; more 662 than one SRH-6LoRH may be present, e.g., if the compression level 663 changes inside the Segment and different SRH-6LoRH Types are 664 required. The content of the SR-VIO starting at the first SRH- 665 6LoRH header is thus verbatim the one that the Track Ingress 666 places in the packet encapsulation to reach the Track Ingress. 668 6.4. Sibling Information Option 670 The Sibling Information Option (SIO) provides indication on siblings 671 that could be used by the Root to form Projected Routes. One or more 672 SIO(s) may be placed in the DAO messages that are sent to the Root in 673 Non-Storing Mode. 675 The format of the SIO is as follows: 677 0 1 2 3 678 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 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | Type | Option Length |Comp.|B|D|Flags| Opaque | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 | Step of Rank | Reserved | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | | 685 + + 686 . . 687 . Sibling DODAGID (if 'D' flag not set) . 688 . . 689 + + 690 | | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | | 693 + + 694 . . 695 . Sibling Address . 696 . . 697 + + 698 | | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 Figure 8: Sibling Information Option Format 703 Option Type: 0x0D (to be confirmed by IANA) 705 Option Length: In bytes, the size of the option. 707 Compression Type: 3-bit unsigned integer. This is the SRH-6LoRH 708 Type as defined in figure 7 in section 5.1 of [RFC8138] that 709 corresponds to the compression used for the Sibling Address and 710 its DODAGID if resent. The Compression refernce is the Root of 711 the main DODAG. 713 Reserved for Flags: MUST be set to zero by the sender and MUST be 714 ignored by the receiver. 716 B: 1-bit flag that is set to indicate that the connectivity to the 717 sibling is bidirectional and roughly symmetrical. In that case, 718 only one of the siblings may report the SIO for the hop. If 'B' 719 is not set then the SIO only indicates connectivity from the 720 sibling to this node, and does not provide information on the hop 721 from this node to the sibling. 723 D: 1-bit flag that is set to indicate that sibling belongs to the 724 same DODAG. When not set, the Sibling DODAGID is indicated. 726 Flags: Reserved. The Flags field MUST initialized to zero by the 727 sender and MUST be ignored by the receiver 729 Opaque: MAY be used to carry information that the node and the Root 730 understand, e.g., a particular representation of the Link 731 properties such as a proprietary Link Quality Information for 732 packets received from the sibling. An industrial Alliance that 733 uses RPL for a particular use / environment MAY redefine the use 734 of this field to fit its needs. 736 Step of Rank: 16-bit unsigned integer. This is the Step of Rank 737 [RPL] as computed by the Objective Function between this node and 738 the sibling. 740 Reserved: The Reserved field MUST initialized to zero by the sender 741 and MUST be ignored by the receiver 743 Sibling DODAGID: 2 to 16 bytes, the DODAGID of the sibling in a 744 [RFC8138] compressed form as indicated by the Compression Type 745 field. This field is present when the 'D' flag is not set. 747 Sibling Address: 2 to 16 bytes, the IPv6 Address of the sibling in a 748 [RFC8138] compressed form as indicated by the Compression Type 749 field. 751 An SIO MAY be immediately followed by a DAG Metric Container. In 752 that case the DAG Metric Container provides additional metrics for 753 the hop from the Sibling to this node. 755 7. Projected DAO 757 This draft adds a capability to RPL whereby the Root of a main DODAG 758 installs a Track as a collection of Projected Routes, using a 759 Projected-DAO (P-DAO) message to maintain each individual route. The 760 P-DAO signals a collection of Targets in the RPL Target Option(s) 761 (RTO). Those Targets can be reached via a sequence of routers 762 indicated in a VIO(VIO). A P-DAO message MUST contain exactly one 763 VIO, which is either a SF-VIO or an SR-VIO, and MUST follow one or 764 more RTOs. There can be at most one such sequence of RTO(s) and an 765 Via Information Option. A track is indentified by a tupple DODAGID, 766 TrackID and each route within a Track is indexed by a SegmentID. 768 A P-DAO MUST be sent from the address of the Root that serves as 769 DODAGID for the main DODAG. It MUST be sent to a GUA or a ULA of 770 either the ingress or the egress of the Segment, more below. If the 771 'K' Flag is present in the P-DAO, and unless the P-DAO does not reach 772 it, the ingress of the Segment is the node that acknowledges the 773 message, using a DAO-ACK that MUST be sent back to the address that 774 serves as DODAGID for the main DODAG. 776 Like a classical DAO message, a P-DAO causes a change of state only 777 if it is "new" per section 9.2.2. "Generation of DAO Messages" of 778 the RPL specification [RPL]; this is determined using the Segment 779 Sequence information from the VIOas opposed to the Path Sequence from 780 a TIO. Also, a Segment Lifetime of 0 in an VIOindicates that the 781 projected route associated to the Segment is to be removed. 783 There are two kinds of operation for the Projected Routes, the 784 Storing Mode and the Non-Storing Mode. 786 * The Non-Storing Mode is discussed in Section 7.3.2. A Non-Storing 787 Mode P-DAO carries an SR-VIO with the loose list of Via Addresses 788 that forms a source-routed Segment to the Track Egress. The 789 recipient of the P-DAO is the Track Ingress; it MUST install a 790 source-routed state to the Track Egress and reply to the Root 791 directly using a DAO-ACK message if requested to. 793 * The Storing Mode is discussed in Section 7.3.1. A Storing Mode 794 P-DAO carries a SF-VIO with the strict list of Via Addresses from 795 the ingress to the egress of the Segment in the data path order. 796 The routers listed in the Via Addresses, except the egress, MUST 797 install a routing state to the Target(s) via the next Via Address 798 in the SF-VIO. In normal operations, the P-DAO is propagated 799 along the chain of Via Routers from the egress router of the path 800 till the ingress one, which confirms the installation to the Root 801 with a DAO-ACK message. 803 In case of a forwarding error along a Projected Route, an ICMP error 804 is sent to the Root with a new Code "Error in Projected Route" (See 805 Section 11.13). The Root can then modify or remove the Projected 806 Route. The "Error in Projected Route" message has the same format as 807 the "Destination Unreachable Message", as specified in RFC 4443 808 [RFC4443]. 810 The portion of the invoking packet that is sent back in the ICMP 811 message SHOULD record at least up to the RH if one is present, and 812 this hop of the RH SHOULD be consumed by this node so that the 813 destination in the IPv6 header is the next hop that this node could 814 not reach. if a 6LoWPAN Routing Header (6LoRH) [RFC8138] is used to 815 carry the IPv6 routing information in the outer header then that 816 whole 6LoRH information SHOULD be present in the ICMP message. 818 The sender and exact operation depend on the Mode and is described in 819 Section 7.3.2 and Section 7.3.1 respectively. 821 7.1. Requesting a Track 823 A Node is free to ask the Root for a new Track at any time. This is 824 done with a PDR message, that indicates in the Requested Lifetime 825 field the duration for which the Track should be established. Upon a 826 PDR, the Root MAY install the necessary Segments, in which case it 827 answers with a PDR-ACK indicating the granted Track Lifetime. All 828 the Segments MUST be of a same mode, either Storing or Non-Storing. 829 All the Segments MUST be created with the same TrackID and the same 830 DODAGID signaled in the P-DAO. 832 The Root is free to design the Track as it wishes, and to change the 833 Segments overtime to serve the Track as needed, without notifying the 834 resquesting Node. The Segment Lifetime in the P-DAO messages does 835 not need to be aligned to the Requested Lifetime in the PDR, or 836 between P-DAO messages for different Segments. The Root may use 837 shorter lifetimes for the Segments and renew them faster than the 838 Track is, or longer lifetimes in which case it will need to tear down 839 the Segments if the Track is not renewed. 841 When the Track Lifetime that was returned in the PDR-ACK is close to 842 elapse, the resquesting Node needs to resend a PDR using the TrackID 843 in the PDR-ACK to extend the lifetime of the Track, else the Track 844 will time out and the Root will tear down the whole structure. 846 If the Track fails and cannot be restored, the Root notifies the 847 resquesting Node asynchronously with a PDR-ACK with a Track Lifetime 848 of 0, indicating that the Track has failed, and a PDR-ACK Status 849 indicating the reason of the fault. 851 7.2. Identifying a Track 853 RPL defines the concept of an Instance to signal an individual 854 routing topology but does not have a concept of an administrative 855 distance, which exists in certain proprietary implementations to sort 856 out conflicts between multiple sources of routing information within 857 one routing topology. 859 This draft leverages the RPL Instance model as follows: 861 * The Root MAY use P-DAO messages to add better routes in the main 862 (Global) Instance in conformance with the routing objectives in 863 that Instance. To achieve this, the Root MAY install an Storing- 864 Mode P-Route along a path down the main Non-Storing Mode DODAG. 865 This enables a loose source routing and reduces the size of the 866 Routing Header, see Appendix A.1. 868 When adding an Storing-Mode P-Route to the main RPL Instance, the 869 Root MUST set the RPLInstanceID field of the P-DAO message (see 870 section 6.4.1. of [RPL]) to the RPLInstanceID of the main DODAG, 871 and MUST NOT use the DODAGID field. A Projected Route provides a 872 longer match to the Target Address than the default route via the 873 Root, so it is preferred. 875 Once the Projected Route is installed, the intermediate nodes 876 listed in the SF-VIO after first one (i.e. The ingress) can be 877 elided from the RH in packets sent along the Segment signaled in 878 the P-DAO. The resulting loose source routing header indicates 879 (one of) the Target(s) as the next entry after the ingress. 881 * The Root MAY also use P-DAO messages to install a specific (say, 882 Traffic Engineered) path as a Serial or as a Complex Track, to a 883 particular endpoint that is the Track Egress. In that case, the 884 Root MUST install a Local RPL Instance (see section 5 of [RPL]). 886 In a that case, the TrackID MUST be unique for the Global Unique 887 IPv6 Address (GUA) or Unique-Local Address (ULA) of the Track 888 Ingress that serves as DODAGID for the Track. This way, a Track 889 is uniquely identified by the tuple (DODAGID, TrackID) where the 890 TrackID is always represented with the 'D' flag set to 0. 892 The Track Egress Address and the TrackID MUST be signaled in the 893 P-DAO message as shown in Figure 1. 895 7.3. Installing a Track 897 A Storing-Mode P-DAO contains an SF-VIO that signals the strict 898 sequence of consecutive nodes to form a segment between a segment 899 ingress and a segment egress (both included). It installs a route of 900 a higher precedence along the segment towards the Targets indicated 901 in the Target Options. The segment is included in a DODAG indicated 902 by the P-DAO Base Object, that may be the one formed by the main RPL 903 Instance, or a Track associated with a local RPL Instance. A Track 904 Egress is signaled as a Target in the P-DAO, and as the last entry is 905 an SF-VIO of a last segment towards that Egress. 907 A Non-Storing-Mode P-DAO signals a strict or loose sequence of nodes 908 between the Track Ingress (excluded) and a Track Egress (included). 909 It installs a source-routed path of a higher precedence within the 910 Track indicated by the P-DAO Base Object, towards the Targets 911 indicated in the Target Options. The source-routed path requires a 912 Source-Routing header which implies an encapsulation to add the SRH 913 to an existing packet. 915 The next entry in the sequence must be either a neighbor of the 916 previous entry, or reachable as a Target via another Projected Route, 917 either Storing or Non-Storing. If it is reachable over a Storing 918 Mode Projected Route, the next entry in the loose sequence is the 919 Target of a previous segment and the ingress of a next segment; the 920 segments are associated with the same Track, which avoids the need of 921 an encapsulation. Conversely, if it is reachable over a Non-Storing 922 Mode Projected Route, the next loose source routed hop of the inner 923 Track is a Target of a previous Track and the ingress of a next 924 Track, which requires a de- and a re-encapsulation. 926 A Serial Track is installed by a single Projected Routes that signals 927 the sequence of consecutive nodes, either in Storing or Non-Storing 928 Mode. If can be a loose Non-Storing Mode Projected Route, in which 929 case the next loose entry must recursively be reached over a Serial 930 Track. 932 A Complex Track can be installed as a collection of Projected Routes 933 with the same DODAGID and Track ID. The Ingress of a Non-Storing 934 Mode Projected Route must be the owner of the DODAGID. The Ingress 935 of a Storing Mode Projected Route must be either the owner of the 936 DODAGID, or the egress of a preceding Storing Mode Projected Route in 937 the same Track. In the latter case, the Targets of the Projected 938 Route must be Targets of the preceding Projected Route to ensure that 939 they are visible from the track Ingress. 941 7.3.1. Storing-Mode P-Route 943 Profile 1 extends RPL opertation in a Non-Storing Mode network with 944 Storing-Mode Projected Routes that install segments along the main 945 DODAG and enable to loose source routing between the Root and the 946 targets. 948 As illustrated in Figure 9, a P-DAO that carries a SF-VIO enables the 949 Root to install a stateful route towards a collection of Targets 950 along a Segment between a Track Ingress and a Track Egress. 952 ------+--------- 953 | Internet 954 | 955 +-----+ 956 | | Border Router 957 | | (RPL Root) 958 +-----+ | ^ | 959 | | DAO | ACK | 960 o o o o | | | 961 o o o o o o o o o | ^ | Projected . 962 o o o o o o o o o o | | DAO | Route . 963 o o o o o o o o o | ^ | . 964 o o o o o o o o v | DAO v . 965 o o LLN o o o | 966 o o o o o Loose Source Route Path | 967 o o o o From Root To Destination v 969 Figure 9: Projecting a route 971 In order to install the relevant routing state along the Segment , 972 the Root sends a unicast P-DAO message to the Track Egress router of 973 the routing Segment that is being installed. The P-DAO message 974 contains a SF-VIO with the direct sequence of Via Addresses. The SF- 975 VIO follows one or more RTOs indicating the Targets to which the 976 Track leads. The SF-VIO contains a Segment Lifetime for which the 977 state is to be maintained. 979 The Root sends the P-DAO directly to the egress node of the Segment. 980 In that P-DAO, the destination IP address matches the last Via 981 Address in the SF-VIO. This is how the egress recognizes its role. 982 In a similar fashion, the ingress node recognizes its role as it 983 matches first Via Address in the SF-VIO. 985 The Egress node of the Segment is the only node in the path that does 986 not install a route in response to the P-DAO; it is expected to be 987 already able to route to the Target(s) on its own. If one of the 988 Targets is not known, the node MUST answer to the Root with a 989 negative DAO-ACK listing the Target(s) that could not be located 990 (suggested status 10 to be confirmed by IANA). 992 If the egress node can reach all the Targets, then it forwards the 993 P-DAO with unchanged content to its loose predecessor in the Segment 994 as indicated in the list of Via Information options, and recursively 995 the message is propagated unchanged along the sequence of routers 996 indicated in the P-DAO, but in the reverse order, from egress to 997 ingress. 999 The address of the predecessor to be used as destination of the 1000 propagated DAO message is found in the Via Address the precedes the 1001 one that contain the address of the propagating node, which is used 1002 as source of the message. 1004 Upon receiving a propagated DAO, all except the Egress Router MUST 1005 install a route towards the DAO Target(s) via their successor in the 1006 SF-VIO. The router MAY install additional routes towards the VIA 1007 Addresses that are the SF-VIO after the next one, if any, but in case 1008 of a conflict or a lack of resource, the route(s) to the Target(s) 1009 have precedence. 1011 If a router cannot reach its predecessor in the SF-VIO, the router 1012 MUST answer to the Root with a negative DAO-ACK indicating the 1013 successor that is unreachable (suggested status 11 to be confirmed by 1014 IANA). 1016 The process continues till the P-DAO is propagated to ingress router 1017 of the Segment, which answers with a DAO-ACK to the Root. 1019 A Segment Lifetime of 0 in a VIOis used to clean up the state. The 1020 P-DAO is forwarded as described above, but the DAO is interpreted as 1021 a No-Path DAO and results in cleaning up existing state as opposed to 1022 refreshing an existing one or installing a new one. 1024 In case of a forwarding error along an Storing-Mode P-Route, the node 1025 that fails to forward SHOULD send an ICMP error with a code "Error in 1026 Projected Route" to the Root. Failure to do so may result in packet 1027 loss and wasted resources along the Projected Route that is broken. 1029 7.3.2. Non-Storing-Mode P-Route 1031 As illustrated in Figure 10, a P-DAO that carries an SR-VIO enables 1032 the Root to install a source-routed path from a Track Ingress towards 1033 a Target along the main DODAG. 1035 ------+--------- 1036 | Internet 1037 | 1038 +-----+ 1039 | | Border Router 1040 | | (RPL Root) 1041 +-----+ | P ^ ACK 1042 | Track | DAO | 1043 o o o o Ingress X V | X 1044 o o o o o o o X o X Source 1045 o o o o o o o o X o o X Routed 1046 o o ° o o o o X o X Segment 1047 o o o o o o o o X Track X 1048 o o o o o Egress 1050 o o o o 1051 o o o o 1052 destination 1054 LLN 1056 Figure 10: Projecting a Non-Storing Route 1058 When forwarding a packet to a destination for which the router 1059 determines that routing happens via a Track Target, the router 1060 inserts the Source Routing Header in the packet with the final 1061 destination at the Track Egress. 1063 In order to signal the Segment, the router encapsulates the packet 1064 with an IP-in-IP header and a Routing Header as follows: 1066 * In the uncompressed form the source of the packet is this router, 1067 the destination is the first Via Address in the SR-VIO, and the RH 1068 is a Source Routing Header (SRH) [RFC6554] that contains the list 1069 of the remaining Via Addresses terminating by the Track Egress. 1071 * The preferred alternate in a network where 6LoWPAN Header 1072 Compression [RFC6282] is used is to leverage "IPv6 over Low-Power 1073 Wireless Personal Area Network (6LoWPAN) Paging Dispatch" 1074 [RFC8025] to compress the RPL artifacts as indicated in [RFC8138]. 1076 In that case, the source routed header is the exact copy of the 1077 (chain of) SRH-6LoRH found in the SR-VIO, also terminating by the 1078 Track Egress. The RPI-6LoRH is appended next, followed by an IP- 1079 in-IP 6LoRH Header that indicates the Ingress Router in the 1080 Encapsulator Address field, see as a similar case Figure 20 of 1081 [TURN-ON_RFC8138]. 1083 In the case of a loose source-routed path, there MUST be either a 1084 neighbor that is adjacent to the loose next hop, on which case the 1085 packet is forwarded to that neighbor, or another Track to the loose 1086 next hop for which this node is Ingress; in the latter case, another 1087 encapsulation takes place and the process possibly recurses; 1088 otherwise the packet is dropped. 1090 In case of a forwarding error along a Source Route path, the node 1091 that fails to forward SHOULD send an ICMP error with a code "Error in 1092 Source Routing Header" back to the source of the packet, as described 1093 in section 11.2.2.3. of [RPL]. Upon this message, the encapsulating 1094 node SHOULD stop using the source route path for a period of time and 1095 it SHOULD send an ICMP message with a Code "Error in Projected Route" 1096 to the Root. Failure to follow these steps may result in packet loss 1097 and wasted resources along the source route path that is broken. 1099 7.4. Forwarding Along a Track 1101 This draft leverages the RPL Forwarding model follows: 1103 * In the data packets, the Track DODAGID and the TrackID MUST be 1104 respectively signaled as the IPv6 Source Address and the 1105 RPLInstanceID field of the RPI that MUST be placed in the outer 1106 chain of IPv6 Headers. 1108 The RPI carries a local RPLInstanceID called the TrackID, which, 1109 in association with the DODAGID, indicates the Track along which 1110 the packet is forwarded. 1112 The 'D' flag in the RPLInstanceID MUST be set to 0 to indicate 1113 that the source address in the IPv6 header is set ot the DODAGID, 1114 more in Section 7.4. 1116 * This draft conforms the principles of [USEofRPLinfo] with regards 1117 to packet forwarding and encapsulation along a Track. 1119 - In that case, the Track is the DODAG, the Track Ingress is the 1120 Root, and the Track Egress is a RAL, and neighbors of the Track 1121 Egress that can be reached via the Track are RULs. The 1122 encapsulation rules in [USEofRPLinfo] apply. 1124 - If the Track Ingress is the originator of the packet and the 1125 Track Egress is the destination of the packet, there is no need 1126 for an encapsulation. 1128 - So the Track Ingress must encapsulate the traffic that it did 1129 not originate, and add an RPI in any fashion. 1131 A packet that is being routed over the RPL Instance associated to 1132 a first Non-Storing Mode Track MAY be placed (encapsulated) in a 1133 second Track to cover one loose hop of the first Track. On the 1134 other hand, a Storing Mode Track must be strict and a packet that 1135 it placed in a Storing Mode Track MUST follow that Track till the 1136 Track Egress. 1138 When a Track Egress extracts a packet from a Track (decapsulates 1139 the packet), the Destination of the inner packet MUST be either 1140 this node or a direct neighbor, or a Target of another Segment of 1141 the same Track for which this node is ingress, otherwise the 1142 packet MUST be dropped. 1144 All properties of a Track operations are inherited form the main RPL 1145 Instance that is used to install the Track. For instance, the use of 1146 compression per [RFC8138] is determined by whether it is used in the 1147 main instance, e.g., by setting the "T" flag [TURN-ON_RFC8138] in the 1148 RPL configuration option. 1150 8. Profiles 1152 This document provides a set of tools that may or may not be needed 1153 by an implementation depending on the type of application it serves. 1154 This sections described profiles that can be implemented separately 1155 and can be used to discriminate what an implementation can and cannot 1156 do. 1158 Profile 0 Profile 0 is the legacy support of [RPL] Non-Storing Mode. 1159 It provides the minimal common functionality that must be 1160 implemented as a prerequisite to all the Track-supporting 1161 profiles. The other Profiles extend Profile 0 with selected 1162 capabilities that this specification introduces on top. 1164 Profile 1 (Storing-Mode P-Route Segments along the main DODAG) Profi 1165 le 1 does not create new paths; it combines Storing and Non- 1166 Storing Modes to balance the size of the routing header in the 1167 packet and the amount of state in the intermediate routers in a 1168 Non-Storing Mode RPL DODAG. 1170 Profile 2 (Non-Storing-Mode P-Route Segments along the main DODAG) P 1171 rofile 2 extends Profile 0 with Strict Source-Routing Non-Storing- 1172 Mode Projected Routes along the main DODAG. Profile 2 provides 1173 the same capability to compress the SRH in packets down the main 1174 DODAG as Profile 1, but it require an encapsulation, in order to 1175 insert an additional SRH between the loose source routing hops. 1177 Profile 3 Profile 3 and above build Tracks that do not necessarily 1178 follow the main DODAG. In order to form the best path possible, 1179 those Profiles require the support of Sibling Information Option 1180 to inform the Root of additional possible hops. Profile 3 extends 1181 Profile 1 with additional Storing-Mode Projected Routes that 1182 install segments that do not follow the main DODAG. Segments can 1183 be associated in a Track rooted at an Ingress node, but there is 1184 no explicit Egress node, and no source routing operation. 1186 Profile 4 Profile 4 extends Profile 2 with Strict Source-Routing 1187 Non-Storing-Mode Projected Routes to form Tracks inside the main 1188 DODAG. A Track is formed as one or more strict source source 1189 routed paths between the Root that is the Track Ingress, and the 1190 Track Egress that is the last node 1192 Profile 5 Profile 5 Combines Profile 4 with Profile 1 and enables to 1193 loose source routing between the Ingress and the Egress of the 1194 Track. As in Profile 1, Storing-Mode Projected Routes connect the 1195 dots in the loose source route. 1197 Profile 6 Profile 6 Combines Profile 4 with Profile 2 and also 1198 enables to loose source routing between the Ingress and the Egress 1199 of the Track. 1201 9. Example Track Signaling 1203 The remainder of the section provides an example of how a Track can 1204 be signaled 1206 ===> F 1207 A ===> B ===> C ===> D===> E < 1208 ===> G 1210 Figure 11: Reference Track 1212 A is Track ingress, E is track Egress. C is stitching point. F and 1213 G are E's neighbors, "external" to the Track, and reachable from A 1214 over the Track A->E. 1216 In a general manner we want: 1218 * P-DAO 1 signals C==>B==>E 1220 * P-DAO 2 signals A==>B==>C 1222 * P-DAO 3 signals F and G via the A==>E Track 1224 P-DAO 3 being loose, it can only be non-storing. Note that since the 1225 Root is always the ingress of a Track, and all SR-VIOs are now Track, 1226 the Root being signaled in the DAO base object can now be elided in 1227 the VIA list in SR-VIO. This enables the construction by the main 1228 root of the RFC 8138 optimized SRH-6LoRH in the SR-VIO, to be placed 1229 as is in the packet by the Root. 1231 9.1. Using Storing-Mode Segments 1233 A==>B==>C and C==>D==>E are segments of a same Track. Note that the 1234 storing mode signaling imposes strict continuity in a segment. One 1235 benefit of strict routing is that loops are avoided along the Track. 1237 9.1.1. Stitched Segments 1239 Storing-Mode P-DAO 1 and 2 are sent to E and C, as follows: 1241 +===============+==============+==============+ 1242 | Field | P-DAO 1 to E | P-DAO 2 to C | 1243 +===============+==============+==============+ 1244 | Mode | Storing | Storing | 1245 +---------------+--------------+--------------+ 1246 | Track Ingress | A | A | 1247 +---------------+--------------+--------------+ 1248 | TrackID | (A, 129) | (A, 129) | 1249 +---------------+--------------+--------------+ 1250 | VIO | C, D, E | A, B, C | 1251 +---------------+--------------+--------------+ 1252 | Targets | E, F, G | E, F, G | 1253 +---------------+--------------+--------------+ 1255 Table 1: P-DAO Messages 1257 As a result the RIBs are set as follows: 1259 +======+=============+=========+=============+==========+ 1260 | Node | Destination | Origin | Next Hop(s) | TrackID | 1261 +======+=============+=========+=============+==========+ 1262 | E | F, G | P-DAO 1 | Neighbor | (A, 129) | 1263 +------+-------------+---------+-------------+----------+ 1264 | D | E | P-DAO 1 | Neighbor | (A, 129) | 1265 +------+-------------+---------+-------------+----------+ 1266 | " | F, G | P-DAO 1 | E | (A, 129) | 1267 +------+-------------+---------+-------------+----------+ 1268 | C | D | P-DAO 1 | Neighbor | (A, 129) | 1269 +------+-------------+---------+-------------+----------+ 1270 | " | E, F, G | P-DAO 1 | D | (A, 129) | 1271 +------+-------------+---------+-------------+----------+ 1272 | B | C | P-DAO 2 | Neighbor | (A, 129) | 1273 +------+-------------+---------+-------------+----------+ 1274 | " | E, F, G | P-DAO 2 | C | (A, 129) | 1275 +------+-------------+---------+-------------+----------+ 1276 | A | B | P-DAO 2 | Neighbor | (A, 129) | 1277 +------+-------------+---------+-------------+----------+ 1278 | A | E, F, G | P-DAO 2 | B | (A, 129) | 1279 +------+-------------+---------+-------------+----------+ 1281 Table 2: RIB setting 1283 E recognizes that it is the Track Egress because it is both a Target 1284 and a Segment Endpoint. 1286 Packets originated by A to E, F, or G, do not require an 1287 encapsulation. In any fashion, the outer headers of the packets that 1288 are forwarded along the Track have the following settings: 1290 +========+===================+===================+================+ 1291 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1292 +========+===================+===================+================+ 1293 | Outer | A | E, F or G | (A, 129) | 1294 +--------+-------------------+-------------------+----------------+ 1295 | Inner | X != A | E, F or G | N/A | 1296 +--------+-------------------+-------------------+----------------+ 1298 Table 3: Packet header settings 1300 As an example, say that A has a packet for F. Using the RIB above: 1302 * From P-DAO 2: A forwards to B and B forwards to C. 1304 * From P-DAO 1: C forwards to D and D forwards to E. 1306 * From Neighbor Cache Entry: C delivers the packet to F. 1308 9.1.2. External routes 1310 Storing-Mode P-DAO 1 and 2, and Non-Storing-Mode P-DAO 3, are sent to 1311 E, C and A, respectively, as follows: 1313 +===============+==============+==============+==============+ 1314 | | P-DAO 1 to E | P-DAO 2 to C | P-DAO 3 to A | 1315 +===============+==============+==============+==============+ 1316 | Mode | Storing | Storing | Non-Storing | 1317 +---------------+--------------+--------------+--------------+ 1318 | Track Ingress | A | A | A | 1319 +---------------+--------------+--------------+--------------+ 1320 | TrackID | (A, 129) | (A, 129) | (A, 129) | 1321 +---------------+--------------+--------------+--------------+ 1322 | VIO | C, D, E | A, B, C | E | 1323 +---------------+--------------+--------------+--------------+ 1324 | Targets | E | E | F, G | 1325 +---------------+--------------+--------------+--------------+ 1327 Table 4: P-DAO Messages 1329 As a result the RIBs are set as follows: 1331 +======+=============+=========+=============+==========+ 1332 | Node | Destination | Origin | Next Hop(s) | TrackID | 1333 +======+=============+=========+=============+==========+ 1334 | E | F, G | P-DAO 1 | Neighbor | (A, 129) | 1335 +------+-------------+---------+-------------+----------+ 1336 | D | E | P-DAO 1 | Neighbor | (A, 129) | 1337 +------+-------------+---------+-------------+----------+ 1338 | C | D | P-DAO 1 | Neighbor | (A, 129) | 1339 +------+-------------+---------+-------------+----------+ 1340 | " | E | P-DAO 1 | D | (A, 129) | 1341 +------+-------------+---------+-------------+----------+ 1342 | B | C | P-DAO 2 | Neighbor | (A, 129) | 1343 +------+-------------+---------+-------------+----------+ 1344 | " | E | P-DAO 2 | C | (A, 129) | 1345 +------+-------------+---------+-------------+----------+ 1346 | A | B | P-DAO 2 | Neighbor | (A, 129) | 1347 +------+-------------+---------+-------------+----------+ 1348 | A | E | P-DAO 2 | B | (A, 129) | 1349 +------+-------------+---------+-------------+----------+ 1350 | A | F, G | P-DAO 3 | E | (A, 129) | 1351 +------+-------------+---------+-------------+----------+ 1353 Table 5: RIB setting 1355 Packets from A to E do not require an encapsulation. In any fashion, 1356 the outer headers of the packets that are forwarded along the Track 1357 have the following settings: 1359 +========+===================+====================+================+ 1360 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1361 +========+===================+====================+================+ 1362 | Outer | A | E | (A, 129) | 1363 +--------+-------------------+--------------------+----------------+ 1364 | Inner | X | E (X != A), F or G | N/A | 1365 +--------+-------------------+--------------------+----------------+ 1367 Table 6: Packet header settings 1369 As an example, say that A has a packet for F. Using the RIB above: 1371 * From P-DAO 3: A encapsulates the packet the Track signaled by 1372 P-DAO 3, with the outer header above. Now the packet destination 1373 is E. 1375 * From P-DAO 2: A forwards to B and B forwards to C. 1377 * From P-DAO 1: C forwards to D and D forwards to E; E decapsulates 1378 the packet. 1380 * From Neighbor Cache Entry: C delivers packets to F or G. 1382 9.1.3. Segment Routing 1384 Storing-Mode P-DAO 1 and 2, and Non-Storing-Mode P-DAO 3, are sent to 1385 E, B and A, respectively, as follows: 1387 +===============+==============+==============+==============+ 1388 | | P-DAO 1 to E | P-DAO 2 to B | P-DAO 3 to A | 1389 +===============+==============+==============+==============+ 1390 | Mode | Storing | Storing | Non-Storing | 1391 +---------------+--------------+--------------+--------------+ 1392 | Track Ingress | A | A | A | 1393 +---------------+--------------+--------------+--------------+ 1394 | TrackID | (A, 129) | (A, 129) | (A, 129) | 1395 +---------------+--------------+--------------+--------------+ 1396 | VIO | C, D, E | A, B | C, E | 1397 +---------------+--------------+--------------+--------------+ 1398 | Targets | E | B, C | F, G | 1399 +---------------+--------------+--------------+--------------+ 1401 Table 7: P-DAO Messages 1403 As a result the RIBs are set as follows: 1405 +======+=============+=========+=============+==========+ 1406 | Node | Destination | Origin | Next Hop(s) | TrackID | 1407 +======+=============+=========+=============+==========+ 1408 | E | F, G | P-DAO 1 | Neighbor | (A, 129) | 1409 +------+-------------+---------+-------------+----------+ 1410 | D | E | P-DAO 1 | Neighbor | (A, 129) | 1411 +------+-------------+---------+-------------+----------+ 1412 | C | D | P-DAO 1 | Neighbor | (A, 129) | 1413 +------+-------------+---------+-------------+----------+ 1414 | " | E | P-DAO 1 | D | (A, 129) | 1415 +------+-------------+---------+-------------+----------+ 1416 | B | C | P-DAO 2 | Neighbor | (A, 129) | 1417 +------+-------------+---------+-------------+----------+ 1418 | A | B | P-DAO 2 | Neighbor | (A, 129) | 1419 +------+-------------+---------+-------------+----------+ 1420 | " | C | P-DAO 2 | B | (A, 129) | 1421 +------+-------------+---------+-------------+----------+ 1422 | " | E, F, G | P-DAO 3 | C, E | (A, 129) | 1423 +------+-------------+---------+-------------+----------+ 1425 Table 8: RIB setting 1427 Packets from A to E do not require an encapsulation, but carry a SRH 1428 via C. In any fashion, the outer headers of the packets that are 1429 forwarded along the Track have the following settings: 1431 +========+===================+====================+================+ 1432 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1433 +========+===================+====================+================+ 1434 | Outer | A | C till C then E | (A, 129) | 1435 +--------+-------------------+--------------------+----------------+ 1436 | Inner | X | E (X != A), F or G | N/A | 1437 +--------+-------------------+--------------------+----------------+ 1439 Table 9: Packet header settings 1441 As an example, say that A has a packet for F. Using the RIB above: 1443 * From P-DAO 3: A encapsulates the packet the Track signaled by 1444 P-DAO 3, with the outer header above. Now the destination in the 1445 IPv6 Header is C, and a SRH signals the final destination is E. 1447 * From P-DAO 2: A forwards to B and B forwards to C. 1449 * From P-DAO 3: C processes the SRH and sets the destination in the 1450 IPv6 Header to E. 1452 * From P-DAO 1: C forwards to D and D forwards to E; E decapsulates 1453 the packet. 1455 * From the Neighbor Cache Entry: C delivers packets to F or G. 1457 9.2. Using Non-Storing-Mode joining Tracks 1459 A==>B==>C and C==>D==>E are Tracks expressed as non-storing P-DAOs. 1461 9.2.1. Stitched Tracks 1463 Non-Storing Mode P-DAO 1 and 2 are sent to C and A respectively, as 1464 follows: 1466 +===============+==============+==============+ 1467 | | P-DAO 1 to C | P-DAO 2 to A | 1468 +===============+==============+==============+ 1469 | Mode | Non-Storing | Non-Storing | 1470 +---------------+--------------+--------------+ 1471 | Track Ingress | C | A | 1472 +---------------+--------------+--------------+ 1473 | TrackID | (C, 131) | (A, 129) | 1474 +---------------+--------------+--------------+ 1475 | VIO | D, E | B, C | 1476 +---------------+--------------+--------------+ 1477 | Targets | F, G | E, F, G | 1478 +---------------+--------------+--------------+ 1480 Table 10: P-DAO Messages 1482 As a result the RIBs are set as follows: 1484 +======+=============+=========+=============+==========+ 1485 | Node | Destination | Origin | Next Hop(s) | TrackID | 1486 +======+=============+=========+=============+==========+ 1487 | E | F, G | ND | Neighbor | Any | 1488 +------+-------------+---------+-------------+----------+ 1489 | D | E | ND | Neighbor | Any | 1490 +------+-------------+---------+-------------+----------+ 1491 | C | D | ND | Neighbor | Any | 1492 +------+-------------+---------+-------------+----------+ 1493 | " | E, F, G | P-DAO 1 | D, E | (C, 131) | 1494 +------+-------------+---------+-------------+----------+ 1495 | B | C | ND | Neighbor | Any | 1496 +------+-------------+---------+-------------+----------+ 1497 | A | B | ND | Neighbor | Any | 1498 +------+-------------+---------+-------------+----------+ 1499 | " | C, E, F, G | P-DAO 2 | B, C | (A, 129) | 1500 +------+-------------+---------+-------------+----------+ 1502 Table 11: RIB setting 1504 Packets from A to E, F and G do not require an encapsulation, though 1505 it is preferred that A encapsulates and C decapsulates. Either way, 1506 they carry a SRH via B and C, and C needs to encapsulate to E, F, or 1507 G to add an SRH via D and E. The encapsulating headers of packets 1508 that are forwarded along the Track between C and E have the following 1509 settings: 1511 +========+===================+===================+================+ 1512 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1513 +========+===================+===================+================+ 1514 | Outer | C | D till D then E | (C, 131) | 1515 +--------+-------------------+-------------------+----------------+ 1516 | Inner | X | E, F, or G | N/A | 1517 +--------+-------------------+-------------------+----------------+ 1519 Table 12: Packet header settings 1521 As an example, say that A has a packet for F. Using the RIB above: 1523 * From P-DAO 2: A encapsulates the packet with destination of F in 1524 the Track signaled by P-DAO 2. The outer header has source A, 1525 destination B, an SRH that indicates C as the next loose hop, and 1526 a RPI indicating a TrackId of 129 from A's namespace. 1528 * From the SRH: Packets forwarded by B have source A, destination C 1529 , a consumed SRH, and a RPI indicating a TrackId of 129 from A's 1530 namespace. C decapsulates. 1532 * From P-DAO 1: C encapsulates the packet with destination of F in 1533 the Track signaled by P-DAO 1. The outer header has source C, 1534 destination D, an SRH that indicates E as the next loose hop, and 1535 a RPI indicating a TrackId of 131 from C's namespace. E 1536 decapsulates. 1538 9.2.2. External routes 1540 Non-Storing Mode P-DAO 1 is sent to C and Non-Storing Mode P-DAO 2 1541 and 3 are sent A, as follows: 1543 +===============+==============+==============+==============+ 1544 | | P-DAO 1 to C | P-DAO 2 to A | P-DAO 3 to A | 1545 +===============+==============+==============+==============+ 1546 | Mode | Non-Storing | Non-Storing | Non-Storing | 1547 +---------------+--------------+--------------+--------------+ 1548 | Track Ingress | C | A | A | 1549 +---------------+--------------+--------------+--------------+ 1550 | TrackID | (C, 131) | (A, 129) | (A, 141) | 1551 +---------------+--------------+--------------+--------------+ 1552 | VIO | D, E | B, C | E | 1553 +---------------+--------------+--------------+--------------+ 1554 | Targets | E | E | F, G | 1555 +---------------+--------------+--------------+--------------+ 1557 Table 13: P-DAO Messages 1559 As a result the RIBs are set as follows: 1561 +======+=============+=========+=============+==========+ 1562 | Node | Destination | Origin | Next Hop(s) | TrackID | 1563 +======+=============+=========+=============+==========+ 1564 | E | F, G | ND | Neighbor | Any | 1565 +------+-------------+---------+-------------+----------+ 1566 | D | E | ND | Neighbor | Any | 1567 +------+-------------+---------+-------------+----------+ 1568 | C | D | ND | Neighbor | Any | 1569 +------+-------------+---------+-------------+----------+ 1570 | " | E | P-DAO 1 | D, E | (C, 131) | 1571 +------+-------------+---------+-------------+----------+ 1572 | B | C | ND | Neighbor | Any | 1573 +------+-------------+---------+-------------+----------+ 1574 | A | B | ND | Neighbor | Any | 1575 +------+-------------+---------+-------------+----------+ 1576 | " | C, E | P-DAO 2 | B, C | (A, 129) | 1577 +------+-------------+---------+-------------+----------+ 1578 | " | F, G | P-DAO 3 | E | (A, 141) | 1579 +------+-------------+---------+-------------+----------+ 1581 Table 14: RIB setting 1583 The encapsulating headers of packets that are forwarded along the 1584 Track between C and E have the following settings: 1586 +========+===================+===================+================+ 1587 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1588 +========+===================+===================+================+ 1589 | Outer | C | D till D then E | (C, 131) | 1590 +--------+-------------------+-------------------+----------------+ 1591 | Middle | A | E | (A, 141) | 1592 +--------+-------------------+-------------------+----------------+ 1593 | Inner | X | E, F or G | N/A | 1594 +--------+-------------------+-------------------+----------------+ 1596 Table 15: Packet header settings 1598 As an example, say that A has a packet for F. Using the RIB above: 1600 * From P-DAO 3: A encapsulates the packet with destination of F in 1601 the Track signaled by P-DAO 3. The outer header has source A, 1602 destination E, and a RPI indicating a TrackId of 141 from A's 1603 namespace. This recurses with: 1605 * From P-DAO 2: A encapsulates the packet with destination of E in 1606 the Track signaled by P-DAO 2. The outer header has source A, 1607 destination B, an SRH that indicates C as the next loose hop, and 1608 a RPI indicating a TrackId of 129 from A's namespace. 1610 * From the SRH: Packets forwarded by B have source A, destination C 1611 , a consumed SRH, and a RPI indicating a TrackId of 129 from A's 1612 namespace. C decapsulates. 1614 * From P-DAO 1: C encapsulates the packet with destination of E in 1615 the Track signaled by P-DAO 1. The outer header has source C, 1616 destination D, an SRH that indicates E as the next loose hop, and 1617 a RPI indicating a TrackId of 131 from C's namespace. E 1618 decapsulates. 1620 9.2.3. Segment Routing 1622 Non-Storing Mode P-DAO 1 is sent to C and Non-Storing Mode P-DAO 2 1623 and 3 are sent A, as follows: 1625 +===============+==============+==============+==============+ 1626 | | P-DAO 1 to C | P-DAO 2 to A | P-DAO 3 to A | 1627 +===============+==============+==============+==============+ 1628 | Mode | Non-Storing | Non-Storing | Non-Storing | 1629 +---------------+--------------+--------------+--------------+ 1630 | Track Ingress | C | A | A | 1631 +---------------+--------------+--------------+--------------+ 1632 | TrackID | (C, 131) | (A, 129) | (A, 141) | 1633 +---------------+--------------+--------------+--------------+ 1634 | VIO | D, E | B | C, E | 1635 +---------------+--------------+--------------+--------------+ 1636 | Targets | | C | F, G | 1637 +---------------+--------------+--------------+--------------+ 1639 Table 16: P-DAO Messages 1641 As a result the RIBs are set as follows: 1643 +======+=============+=========+=============+==========+ 1644 | Node | Destination | Origin | Next Hop(s) | TrackID | 1645 +======+=============+=========+=============+==========+ 1646 | E | F, G | ND | Neighbor | Any | 1647 +------+-------------+---------+-------------+----------+ 1648 | D | E | ND | Neighbor | Any | 1649 +------+-------------+---------+-------------+----------+ 1650 | C | D | ND | Neighbor | Any | 1651 +------+-------------+---------+-------------+----------+ 1652 | " | E | P-DAO 1 | D, E | (C, 131) | 1653 +------+-------------+---------+-------------+----------+ 1654 | B | C | ND | Neighbor | Any | 1655 +------+-------------+---------+-------------+----------+ 1656 | A | B | ND | Neighbor | Any | 1657 +------+-------------+---------+-------------+----------+ 1658 | " | C | P-DAO 2 | B, C | (A, 129) | 1659 +------+-------------+---------+-------------+----------+ 1660 | " | E, F, G | P-DAO 3 | C, E | (A, 141) | 1661 +------+-------------+---------+-------------+----------+ 1663 Table 17: RIB setting 1665 The encapsulating headers of packets that are forwarded along the 1666 Track between A and B have the following settings: 1668 +========+===================+===================+================+ 1669 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1670 +========+===================+===================+================+ 1671 | Outer | A | B till D then E | (A, 129) | 1672 +--------+-------------------+-------------------+----------------+ 1673 | Middle | A | C | (A, 141) | 1674 +--------+-------------------+-------------------+----------------+ 1675 | Inner | X | E, F or G | N/A | 1676 +--------+-------------------+-------------------+----------------+ 1678 Table 18: Packet header settings 1680 The encapsulating headers of packets that are forwarded along the 1681 Track between B and C have the following settings: 1683 +========+===================+===================+================+ 1684 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1685 +========+===================+===================+================+ 1686 | Outer | A | C | (A, 141) | 1687 +--------+-------------------+-------------------+----------------+ 1688 | Inner | X | E, F or G | N/A | 1689 +--------+-------------------+-------------------+----------------+ 1691 Table 19: Packet header settings 1693 The encapsulating headers of packets that are forwarded along the 1694 Track between C and E have the following settings: 1696 +========+===================+===================+================+ 1697 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1698 +========+===================+===================+================+ 1699 | Outer | C | D till D then E | (C, 131) | 1700 +--------+-------------------+-------------------+----------------+ 1701 | Middle | A | E | (A, 141) | 1702 +--------+-------------------+-------------------+----------------+ 1703 | Inner | X | E, F or G | N/A | 1704 +--------+-------------------+-------------------+----------------+ 1706 Table 20: Packet header settings 1708 As an example, say that A has a packet for F. Using the RIB above: 1710 * From P-DAO 3: A encapsulates the packet with destination of F in 1711 the Track signaled by P-DAO 3. The outer header has source A, 1712 destination C, an SRH that indicates E as the next loose hop, and 1713 a RPI indicating a TrackId of 141 from A's namespace. This 1714 recurses with: 1716 * From P-DAO 2: A encapsulates the packet with destination of C in 1717 the Track signaled by P-DAO 2. The outer header has source A, 1718 destination B, and a RPI indicating a TrackId of 129 from A's 1719 namespace. B decapsulates forwards to C based on a sibling 1720 connected route. 1722 * From the SRH: C consumes the SRH and makes the destination E. 1724 * From P-DAO 1: C encapsulates the packet with destination of E in 1725 the Track signaled by P-DAO 1. The outer header has source C, 1726 destination D, an SRH that indicates E as the next loose hop, and 1727 a RPI indicating a TrackId of 131 from C's namespace. E 1728 decapsulates. 1730 10. Security Considerations 1732 This draft uses messages that are already present in RPL [RPL] with 1733 optional secured versions. The same secured versions may be used 1734 with this draft, and whatever security is deployed for a given 1735 network also applies to the flows in this draft. 1737 TODO: should probably consider how P-DAO messages could be abused by 1738 a) rogue nodes b) via replay of messages c) if use of P-DAO messages 1739 could in fact deal with any threats? 1741 11. IANA Considerations 1743 11.1. New Elective 6LoWPAN Routing Header Type 1745 This document updates the IANA registry titled "Elective 6LoWPAN 1746 Routing Header Type" that was created for [RFC8138] and assigns the 1747 following value: 1749 +=======+=============+===============+ 1750 | Value | Description | Reference | 1751 +=======+=============+===============+ 1752 | 7 | P-RPI-6LoRH | This document | 1753 +-------+-------------+---------------+ 1755 Table 21: New Elective 6LoWPAN 1756 Routing Header Type 1758 11.2. New Critical 6LoWPAN Routing Header Type 1760 This document updates the IANA registry titled "Critical 6LoWPAN 1761 Routing Header Type" that was created for [RFC8138] and assigns the 1762 following value: 1764 +=======+=============+===============+ 1765 | Value | Description | Reference | 1766 +=======+=============+===============+ 1767 | 7 | P-RPI-6LoRH | This document | 1768 +-------+-------------+---------------+ 1770 Table 22: New Critical 6LoWPAN 1771 Routing Header Type 1773 11.3. New Subregistry For The RPL Option Flags 1775 IANA is required to create a subregistry for the 8-bit RPL Option 1776 Flags field, as detailed in Figure 2, under the "Routing Protocol for 1777 Low Power and Lossy Networks (RPL)" registry. The bits are indexed 1778 from 0 (leftmost) to 7. Each bit is tracked with the following 1779 qualities: 1781 * Bit number (counting from bit 0 as the most significant bit) 1783 * Indication When Set 1785 * Reference 1787 Registration procedure is "Standards Action" [RFC8126]. The initial 1788 allocation is as indicated in Table 26: 1790 +============+======================+===============+ 1791 | Bit number | Indication When Set | Reference | 1792 +============+======================+===============+ 1793 | 0 | Down 'O' | [RFC6553] | 1794 +------------+----------------------+---------------+ 1795 | 1 | Rank-Error (R) | [RFC6553] | 1796 +------------+----------------------+---------------+ 1797 | 2 | Forwarding-Error (F) | [RFC6553] | 1798 +------------+----------------------+---------------+ 1799 | 3 | Projected-Route (P) | This document | 1800 +------------+----------------------+---------------+ 1802 Table 23: Initial PDR Flags 1804 11.4. New RPL Control Codes 1806 This document extends the IANA Subregistry created by RFC 6550 for 1807 RPL Control Codes as indicated in Table 24: 1809 +======+=============================+===============+ 1810 | Code | Description | Reference | 1811 +======+=============================+===============+ 1812 | 0x09 | Projected DAO Request (PDR) | This document | 1813 +------+-----------------------------+---------------+ 1814 | 0x0A | PDR-ACK | This document | 1815 +------+-----------------------------+---------------+ 1817 Table 24: New RPL Control Codes 1819 11.5. New RPL Control Message Options 1821 This document extends the IANA Subregistry created by RFC 6550 for 1822 RPL Control Message Options as indicated in Table 25: 1824 +=======+============================+===============+ 1825 | Value | Meaning | Reference | 1826 +=======+============================+===============+ 1827 | 0x0B | Stateful VIO(SF-VIO) | This document | 1828 +-------+----------------------------+---------------+ 1829 | 0x0C | Source-Routed VIO(SR-VIO) | This document | 1830 +-------+----------------------------+---------------+ 1831 | 0x0D | Sibling Information option | This document | 1832 +-------+----------------------------+---------------+ 1834 Table 25: RPL Control Message Options 1836 11.6. SubRegistry for the Projected DAO Request Flags 1838 IANA is required to create a registry for the 8-bit Projected DAO 1839 Request (PDR) Flags field. Each bit is tracked with the following 1840 qualities: 1842 * Bit number (counting from bit 0 as the most significant bit) 1844 * Capability description 1846 * Reference 1848 Registration procedure is "Standards Action" [RFC8126]. The initial 1849 allocation is as indicated in Table 26: 1851 +============+========================+===============+ 1852 | Bit number | Capability description | Reference | 1853 +============+========================+===============+ 1854 | 0 | PDR-ACK request (K) | This document | 1855 +------------+------------------------+---------------+ 1856 | 1 | Requested path should | This document | 1857 | | be redundant (R) | | 1858 +------------+------------------------+---------------+ 1860 Table 26: Initial PDR Flags 1862 11.7. SubRegistry for the PDR-ACK Flags 1864 IANA is required to create an subregistry for the 8-bit PDR-ACK Flags 1865 field. Each bit is tracked with the following qualities: 1867 * Bit number (counting from bit 0 as the most significant bit) 1869 * Capability description 1871 * Reference 1873 Registration procedure is "Standards Action" [RFC8126]. No bit is 1874 currently defined for the PDR-ACK Flags. 1876 11.8. Subregistry for the PDR-ACK Acceptance Status Values 1878 IANA is requested to create a Subregistry for the PDR-ACK Acceptance 1879 Status values. 1881 * Possible values are 6-bit unsigned integers (0..63). 1883 * Registration procedure is "Standards Action" [RFC8126]. 1885 * Initial allocation is as indicated in Table 27: 1887 +-------+------------------------+---------------+ 1888 | Value | Meaning | Reference | 1889 +-------+------------------------+---------------+ 1890 | 0 | Unqualified acceptance | This document | 1891 +-------+------------------------+---------------+ 1893 Table 27: Acceptance values of the PDR-ACK Status 1895 11.9. Subregistry for the PDR-ACK Rejection Status Values 1897 IANA is requested to create a Subregistry for the PDR-ACK Rejection 1898 Status values. 1900 * Possible values are 6-bit unsigned integers (0..63). 1902 * Registration procedure is "Standards Action" [RFC8126]. 1904 * Initial allocation is as indicated in Table 28: 1906 +-------+-----------------------+---------------+ 1907 | Value | Meaning | Reference | 1908 +-------+-----------------------+---------------+ 1909 | 0 | Unqualified rejection | This document | 1910 +-------+-----------------------+---------------+ 1912 Table 28: Rejection values of the PDR-ACK Status 1914 11.10. SubRegistry for the Via Information Options Flags 1916 IANA is requested to create a Subregistry for the 5-bit Via 1917 Information Options (Via Information Option) Flags field. Each bit 1918 is tracked with the following qualities: 1920 * Bit number (counting from bit 0 as the most significant bit) 1922 * Capability description 1924 * Reference 1926 Registration procedure is "Standards Action" [RFC8126]. No bit is 1927 currently defined for the Via Information Options (Via Information 1928 Option) Flags. 1930 11.11. SubRegistry for the Sibling Information Option Flags 1932 IANA is required to create a registry for the 5-bit Sibling 1933 Information Option (SIO) Flags field. Each bit is tracked with the 1934 following qualities: 1936 * Bit number (counting from bit 0 as the most significant bit) 1938 * Capability description 1940 * Reference 1942 Registration procedure is "Standards Action" [RFC8126]. The initial 1943 allocation is as indicated in Table 29: 1945 +============+===================================+===============+ 1946 | Bit number | Capability description | Reference | 1947 +============+===================================+===============+ 1948 | 0 | Connectivity is bidirectional (B) | This document | 1949 +------------+-----------------------------------+---------------+ 1951 Table 29: Initial SIO Flags 1953 11.12. New Destination Advertisement Object Flag 1955 This document modifies the "Destination Advertisement Object (DAO) 1956 Flags" registry initially created in Section 20.11 of [RPL] . 1958 Section 3.1 also defines one new entry in the Registry as follows: 1960 +---------------+------------------------+-----------+ 1961 | Bit Number | Capability Description | Reference | 1962 +---------------+------------------------+-----------+ 1963 | 2 (suggested) | Projected DAO (P) | THIS RFC | 1964 +---------------+------------------------+-----------+ 1966 Table 30: New Destination Advertisement Object 1967 (DAO) Flag 1969 11.13. Error in Projected Route ICMPv6 Code 1971 In some cases RPL will return an ICMPv6 error message when a message 1972 cannot be forwarded along a Projected Route. This ICMPv6 error 1973 message is "Error in Projected Route". 1975 IANA has defined an ICMPv6 "Code" Fields Registry for ICMPv6 Message 1976 Types. ICMPv6 Message Type 1 describes "Destination Unreachable" 1977 codes. This specification requires that a new code is allocated from 1978 the ICMPv6 Code Fields Registry for ICMPv6 Message Type 1, for "Error 1979 in Projected Route", with a suggested code value of 8, to be 1980 confirmed by IANA. 1982 12. Acknowledgments 1984 The authors wish to acknowledge JP Vasseur, Remy Liubing, James 1985 Pylakutty and Patrick Wetterwald for their contributions to the ideas 1986 developed here. 1988 13. Normative References 1990 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1991 Requirement Levels", BCP 14, RFC 2119, 1992 DOI 10.17487/RFC2119, March 1997, 1993 . 1995 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1996 Control Message Protocol (ICMPv6) for the Internet 1997 Protocol Version 6 (IPv6) Specification", STD 89, 1998 RFC 4443, DOI 10.17487/RFC4443, March 2006, 1999 . 2001 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 2002 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 2003 DOI 10.17487/RFC6282, September 2011, 2004 . 2006 [RPL] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 2007 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 2008 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 2009 Low-Power and Lossy Networks", RFC 6550, 2010 DOI 10.17487/RFC6550, March 2012, 2011 . 2013 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 2014 Power and Lossy Networks (RPL) Option for Carrying RPL 2015 Information in Data-Plane Datagrams", RFC 6553, 2016 DOI 10.17487/RFC6553, March 2012, 2017 . 2019 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 2020 Routing Header for Source Routes with the Routing Protocol 2021 for Low-Power and Lossy Networks (RPL)", RFC 6554, 2022 DOI 10.17487/RFC6554, March 2012, 2023 . 2025 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2026 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2027 May 2017, . 2029 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2030 Writing an IANA Considerations Section in RFCs", BCP 26, 2031 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2032 . 2034 14. Informative References 2036 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 2037 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 2038 2014, . 2040 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and 2041 J. Martocci, "Reactive Discovery of Point-to-Point Routes 2042 in Low-Power and Lossy Networks", RFC 6997, 2043 DOI 10.17487/RFC6997, August 2013, 2044 . 2046 [6TiSCH-ARCHI] 2047 Thubert, P., "An Architecture for IPv6 over the TSCH mode 2048 of IEEE 802.15.4", Work in Progress, Internet-Draft, 2049 draft-ietf-6tisch-architecture-30, 26 November 2020, 2050 . 2053 [RAW-ARCHI] 2054 Thubert, P., Papadopoulos, G., and R. Buddenberg, 2055 "Reliable and Available Wireless Architecture/Framework", 2056 Work in Progress, Internet-Draft, draft-pthubert-raw- 2057 architecture-05, 15 November 2020, 2058 . 2061 [TURN-ON_RFC8138] 2062 Thubert, P. and L. Zhao, "A RPL DODAG Configuration Option 2063 for the 6LoWPAN Routing Header", Work in Progress, 2064 Internet-Draft, draft-ietf-roll-turnon-rfc8138-18, 18 2065 December 2020, . 2068 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 2069 "Deterministic Networking Architecture", RFC 8655, 2070 DOI 10.17487/RFC8655, October 2019, 2071 . 2073 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 2074 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 2075 RFC 8025, DOI 10.17487/RFC8025, November 2016, 2076 . 2078 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 2079 "IPv6 over Low-Power Wireless Personal Area Network 2080 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 2081 April 2017, . 2083 [USEofRPLinfo] 2084 Robles, I., Richardson, M., and P. Thubert, "Using RPI 2085 Option Type, Routing Header for Source Routes and IPv6-in- 2086 IPv6 encapsulation in the RPL Data Plane", Work in 2087 Progress, Internet-Draft, draft-ietf-roll-useofrplinfo-43, 2088 10 January 2021, . 2091 [PCE] IETF, "Path Computation Element", 2092 . 2094 Appendix A. Applications 2095 A.1. Loose Source Routing 2097 A RPL implementation operating in a very constrained LLN typically 2098 uses the Non-Storing Mode of Operation as represented in Figure 12. 2099 In that mode, a RPL node indicates a parent-child relationship to the 2100 Root, using a Destination Advertisement Object (DAO) that is unicast 2101 from the node directly to the Root, and the Root typically builds a 2102 source routed path to a destination down the DODAG by recursively 2103 concatenating this information. 2105 ------+--------- 2106 | Internet 2107 | 2108 +-----+ 2109 | | Border Router 2110 | | (RPL Root) 2111 +-----+ ^ | | 2112 | | DAO | ACK | 2113 o o o o | | | Strict 2114 o o o o o o o o o | | | Source 2115 o o o o o o o o o o | | | Route 2116 o o o o o o o o o | | | 2117 o o o o o o o o | v v 2118 o o o o 2119 LLN 2121 Figure 12: RPL Non-Storing Mode of operation 2123 Based on the parent-children relationships expressed in the non- 2124 storing DAO messages,the Root possesses topological information about 2125 the whole network, though this information is limited to the 2126 structure of the DODAG for which it is the destination. A packet 2127 that is generated within the domain will always reach the Root, which 2128 can then apply a source routing information to reach the destination 2129 if the destination is also in the DODAG. Similarly, a packet coming 2130 from the outside of the domain for a destination that is expected to 2131 be in a RPL domain reaches the Root. 2133 It results that the Root, or then some associated centralized 2134 computation engine such as a PCE, can determine the amount of packets 2135 that reach a destination in the RPL domain, and thus the amount of 2136 energy and bandwidth that is wasted for transmission, between itself 2137 and the destination, as well as the risk of fragmentation, any 2138 potential delays because of a paths longer than necessary (shorter 2139 paths exist that would not traverse the Root). 2141 As a network gets deep, the size of the source routing header that 2142 the Root must add to all the downward packets becomes an issue for 2143 nodes that are many hops away. In some use cases, a RPL network 2144 forms long lines and a limited amount of well-Targeted routing state 2145 would allow to make the source routing operation loose as opposed to 2146 strict, and save packet size. Limiting the packet size is directly 2147 beneficial to the energy budget, but, mostly, it reduces the chances 2148 of frame loss and/or packet fragmentation, which is highly 2149 detrimental to the LLN operation. Because the capability to store a 2150 routing state in every node is limited, the decision of which route 2151 is installed where can only be optimized with a global knowledge of 2152 the system, a knowledge that the Root or an associated PCE may 2153 possess by means that are outside of the scope of this specification. 2155 This specification enables to store a Storing Mode state in 2156 intermediate routers, which enables to limit the excursion of the 2157 source route headers in deep networks. Once a P-DAO exchange has 2158 taken place for a given Target, if the Root operates in non Storing 2159 Mode, then it may elide the sequence of routers that is installed in 2160 the network from its source route headers to destination that are 2161 reachable via that Target, and the source route headers effectively 2162 become loose. 2164 A.2. Transversal Routes 2166 RPL is optimized for Point-to-Multipoint (P2MP) and Multipoint-to- 2167 Point (MP2P), whereby routes are always installed along the RPL DODAG 2168 respectively from and towards the DODAG Root. Transversal Peer to 2169 Peer (P2P) routes in a RPL network will generally suffer from some 2170 elongated (stretched) path versus the best possible path, since 2171 routing between 2 nodes always happens via a common parent, as 2172 illustrated in Figure 13: 2174 * In Storing Mode, unless the destination is a child of the source, 2175 the packets will follow the default route up the DODAG as well. 2176 If the destination is in the same DODAG, they will eventually 2177 reach a common parent that has a route to the destination; at 2178 worse, the common parent may also be the Root. From that common 2179 parent, the packet will follow a path down the DODAG that is 2180 optimized for the Objective Function that was used to build the 2181 DODAG. 2183 * in Non-Storing Mode, all packets routed within the DODAG flow all 2184 the way up to the Root of the DODAG. If the destination is in the 2185 same DODAG, the Root must encapsulate the packet to place an RH 2186 that has the strict source route information down the DODAG to the 2187 destination. This will be the case even if the destination is 2188 relatively close to the source and the Root is relatively far off. 2190 ------+--------- 2191 | Internet 2192 | 2193 +-----+ 2194 | | Border Router 2195 | | (RPL Root) 2196 +-----+ 2197 X 2198 ^ v o o 2199 ^ o o v o o o o o 2200 ^ o o o v o o o o o 2201 ^ o o v o o o o o 2202 S o o o D o o o 2203 o o o o 2204 LLN 2206 Figure 13: Routing Stretch between S and D via common parent X 2208 It results that it is often beneficial to enable transversal P2P 2209 routes, either if the RPL route presents a stretch from shortest 2210 path, or if the new route is engineered with a different objective, 2211 and that it is even more critical in Non-Storing Mode than it is in 2212 Storing Mode, because the routing stretch is wider. For that reason, 2213 earlier work at the IETF introduced the "Reactive Discovery of 2214 Point-to-Point Routes in Low Power and Lossy Networks" [RFC6997], 2215 which specifies a distributed method for establishing optimized P2P 2216 routes. This draft proposes an alternate based on a centralized 2217 route computation. 2219 ------+--------- 2220 | Internet 2221 | 2222 +-----+ 2223 | | Border Router 2224 | | (RPL Root) 2225 +-----+ 2226 | 2227 o o o o 2228 o o o o o o o o o 2229 o o o o o o o o o o 2230 o o o o o o o o o 2231 S>>A>>>B>>C>>>D o o o 2232 o o o o 2233 LLN 2235 Figure 14: Projected Transversal Route 2237 This specification enables to store source-routed or Storing Mode 2238 state in intermediate routers, which enables to limit the stretch of 2239 a P2P route and maintain the characteristics within a given SLA. An 2240 example of service using this mechanism oculd be a control loop that 2241 would be installed in a network that uses classical RPL for 2242 asynchronous data collection. In that case, the P2P path may be 2243 installed in a different RPL Instance, with a different objective 2244 function. 2246 Authors' Addresses 2248 Pascal Thubert (editor) 2249 Cisco Systems, Inc 2250 Building D 2251 45 Allee des Ormes - BP1200 2252 06254 Mougins - Sophia Antipolis 2253 France 2255 Phone: +33 497 23 26 34 2256 Email: pthubert@cisco.com 2258 Rahul Arvind Jadhav 2259 Huawei Tech 2260 Kundalahalli Village, Whitefield, 2261 Bangalore 560037 2262 Karnataka 2263 India 2265 Phone: +91-080-49160700 2266 Email: rahul.ietf@gmail.com 2268 Matthew Gillmore 2269 Itron, Inc 2270 Building D 2271 2111 N Molter Road 2272 Liberty Lake, 99019 2273 United States 2275 Phone: +1.800.635.5461 2276 Email: matthew.gillmore@itron.com