idnits 2.17.1 draft-ietf-roll-dao-projection-24.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1398 has weird spacing: '...-- Node z-- ...' == Line 1405 has weird spacing: '... Node z-- ...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Since the state about a Leg of a Track is located only on the Ingress Node, the Root cleans up the Leg by sending an NSM-VIO to the Ingress indicating the TrackID and the P-RouteID of the Leg being removed, a Segment Lifetime of 0 and a newer Segment Sequence. The SRH-6LoRH with the Via Addresses in the NSM-VIO are not needed; it SHOULD not be placed in the message and MUST be ignored by the receiver. Upon that NSM-VIO, the Ingress node removes all state for that Track if any, and replies positively anyway. -- The document date (25 February 2022) is 784 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) == Missing Reference: 'THIS RFC' is mentioned on line 3242, but not defined ** Downref: Normative reference to an Informational RFC: RFC 4655 == Outdated reference: A later version (-17) exists of draft-ietf-raw-architecture-03 == Outdated reference: A later version (-11) exists of draft-ietf-raw-use-cases-05 == Outdated reference: A later version (-08) exists of draft-irtf-panrg-path-properties-04 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL P. Thubert, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track R.A. Jadhav 5 Expires: 29 August 2022 Huawei Tech 6 M. Richardson 7 Sandelman 8 25 February 2022 10 Root initiated routing state in RPL 11 draft-ietf-roll-dao-projection-24 13 Abstract 15 This document extends RFC 6550, RFC 6553, and RFC 8138 to enable a 16 RPL Root to install and maintain Projected Routes within its DODAG, 17 along a selected set of nodes that may or may not include self, for a 18 chosen duration. This potentially enables routes that are more 19 optimized or resilient than those obtained with the classical 20 distributed operation of RPL, either in terms of the size of a 21 Routing Header or in terms of path length, which impacts both the 22 latency and the 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 29 August 2022. 41 Copyright Notice 43 Copyright (c) 2022 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 Revised BSD License text as 52 described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Revised BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 60 2.2. References . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.4. Domain Terms . . . . . . . . . . . . . . . . . . . . . . 5 63 2.4.1. Projected Route . . . . . . . . . . . . . . . . . . . 6 64 2.4.2. Projected DAO . . . . . . . . . . . . . . . . . . . . 6 65 2.4.3. Path . . . . . . . . . . . . . . . . . . . . . . . . 6 66 2.4.4. Routing Stretch . . . . . . . . . . . . . . . . . . . 6 67 2.4.5. Track . . . . . . . . . . . . . . . . . . . . . . . . 7 68 3. Context and Goal . . . . . . . . . . . . . . . . . . . . . . 9 69 3.1. RPL Applicability . . . . . . . . . . . . . . . . . . . . 9 70 3.2. RPL Routing Modes . . . . . . . . . . . . . . . . . . . . 10 71 3.3. Requirements . . . . . . . . . . . . . . . . . . . . . . 11 72 3.3.1. Loose Source Routing . . . . . . . . . . . . . . . . 11 73 3.3.2. East-West Routes . . . . . . . . . . . . . . . . . . 13 74 3.4. On Tracks . . . . . . . . . . . . . . . . . . . . . . . . 14 75 3.4.1. Building Tracks With RPL . . . . . . . . . . . . . . 15 76 3.4.2. Tracks and RPL Instances . . . . . . . . . . . . . . 15 77 3.5. Serial Track Signaling . . . . . . . . . . . . . . . . . 16 78 3.5.1. Using Storing Mode Segments . . . . . . . . . . . . . 17 79 3.5.2. Using Non-Storing Mode joining Tracks . . . . . . . . 24 80 3.6. Complex Tracks . . . . . . . . . . . . . . . . . . . . . 31 81 3.7. Scope and Expectations . . . . . . . . . . . . . . . . . 33 82 3.7.1. External Dependencies . . . . . . . . . . . . . . . . 33 83 3.7.2. Positioning vs. Related IETF Standards . . . . . . . 33 84 4. Extending existing RFCs . . . . . . . . . . . . . . . . . . . 35 85 4.1. Extending RFC 6550 . . . . . . . . . . . . . . . . . . . 35 86 4.1.1. Projected DAO . . . . . . . . . . . . . . . . . . . . 36 87 4.1.2. Projected DAO-ACK . . . . . . . . . . . . . . . . . . 38 88 4.1.3. Via Information Option . . . . . . . . . . . . . . . 39 89 4.1.4. Sibling Information Option . . . . . . . . . . . . . 39 90 4.1.5. P-DAO Request . . . . . . . . . . . . . . . . . . . . 39 91 4.1.6. Amending the RPI . . . . . . . . . . . . . . . . . . 40 92 4.1.7. Additional Flag in the RPL DODAG Configuration 93 Option . . . . . . . . . . . . . . . . . . . . . . . 40 94 4.2. Extending RFC 6553 . . . . . . . . . . . . . . . . . . . 41 95 4.3. Extending RFC 8138 . . . . . . . . . . . . . . . . . . . 42 96 5. New RPL Control Messages and Options . . . . . . . . . . . . 43 97 5.1. New P-DAO Request Control Message . . . . . . . . . . . . 43 98 5.2. New PDR-ACK Control Message . . . . . . . . . . . . . . . 45 99 5.3. Via Information Options . . . . . . . . . . . . . . . . . 46 100 5.4. Sibling Information Option . . . . . . . . . . . . . . . 49 101 6. Root Initiated Routing State . . . . . . . . . . . . . . . . 51 102 6.1. RPL Network Setup . . . . . . . . . . . . . . . . . . . . 51 103 6.2. Requesting a Track . . . . . . . . . . . . . . . . . . . 52 104 6.3. Identifying a Track . . . . . . . . . . . . . . . . . . . 53 105 6.4. Installing a Track . . . . . . . . . . . . . . . . . . . 54 106 6.4.1. Signaling a Projected Route . . . . . . . . . . . . . 55 107 6.4.2. Installing a Track Segment with a Storing Mode 108 P-Route . . . . . . . . . . . . . . . . . . . . . . . 56 109 6.4.3. Installing a Track Leg with a Non-Storing Mode 110 P-Route . . . . . . . . . . . . . . . . . . . . . . . 58 111 6.5. Tearing Down a P-Route . . . . . . . . . . . . . . . . . 60 112 6.6. Maintaining a Track . . . . . . . . . . . . . . . . . . . 60 113 6.6.1. Maintaining a Track Segment . . . . . . . . . . . . . 61 114 6.6.2. Maintaining a Track Leg . . . . . . . . . . . . . . . 61 115 6.7. Encapsulating and Forwarding Along a Track . . . . . . . 62 116 6.8. Compression of the RPL Artifacts . . . . . . . . . . . . 64 117 7. Lesser Constrained Variations . . . . . . . . . . . . . . . . 66 118 7.1. Storing Mode Main DODAG . . . . . . . . . . . . . . . . . 66 119 7.2. A Track as a Full DODAG . . . . . . . . . . . . . . . . . 68 120 8. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 69 121 9. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 71 122 10. Security Considerations . . . . . . . . . . . . . . . . . . . 72 123 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72 124 11.1. RPL DODAG Configuration Option Flag . . . . . . . . . . 72 125 11.2. Elective 6LoWPAN Routing Header Type . . . . . . . . . . 73 126 11.3. Critical 6LoWPAN Routing Header Type . . . . . . . . . . 73 127 11.4. Subregistry For The RPL Option Flags . . . . . . . . . . 73 128 11.5. RPL Control Codes . . . . . . . . . . . . . . . . . . . 74 129 11.6. RPL Control Message Options . . . . . . . . . . . . . . 74 130 11.7. SubRegistry for the Projected DAO Request Flags . . . . 75 131 11.8. SubRegistry for the PDR-ACK Flags . . . . . . . . . . . 75 132 11.9. Subregistry for the PDR-ACK Acceptance Status Values . . 76 133 11.10. Subregistry for the PDR-ACK Rejection Status Values . . 76 134 11.11. SubRegistry for the Via Information Options Flags . . . 76 135 11.12. SubRegistry for the Sibling Information Option Flags . . 77 136 11.13. Destination Advertisement Object Flag . . . . . . . . . 77 137 11.14. Destination Advertisement Object Acknowledgment Flag . . 78 138 11.15. New ICMPv6 Error Code . . . . . . . . . . . . . . . . . 78 139 11.16. RPL Rejection Status values . . . . . . . . . . . . . . 78 140 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 79 141 13. Normative References . . . . . . . . . . . . . . . . . . . . 79 142 14. Informative References . . . . . . . . . . . . . . . . . . . 81 143 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 83 145 1. Introduction 147 RPL, the "Routing Protocol for Low Power and Lossy Networks" [RPL] 148 (LLNs), is an anisotropic Distance Vector protocol that is well- 149 suited for application in a variety of low energy Internet of Things 150 (IoT) networks where stretched P2P paths are acceptable vs. the 151 signaling and state overhead involved in maintaining shortest paths 152 across. 154 RPL forms destination Oriented Directed Acyclic Graphs (DODAGs) in 155 which the Root often acts as the Border router to connect the RPL 156 domain to the IP backbone and routes along that graph up, towards the 157 Root, and down towards the nodes. 159 With this specification, an abstract routing function called a Path 160 Computation Element [PCE] (e.g., located in an central controller or 161 collocated with the Root) interacts with the RPL Root to compute Peer 162 to Peer (P2P) paths within a pre-existing RPL Main DODAG. The 163 topological information that is passed to the PCE is derived from the 164 DODAG that is already available at the Root in RPL Non-Storing Mode. 165 This specification introduces protocol extensions that enrich the 166 topological information that is available at the Root and passed to 167 the PCE. 169 Based on usage, path length, and knowledge of available resources 170 such as battery levels and reservable buffers in the nodes, the PCE 171 with a global visibility on the system can optimize the computed 172 routes for the application needs, including the capability to provide 173 path redundancy. This specification also introduces protocol 174 extensions that enable the Root to translates the computed paths into 175 RPL and install them as Projected Routes (aka P-Routes) inside the 176 DODAG on behalf of a PCE. 178 2. Terminology 180 2.1. Requirements Language 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 184 "OPTIONAL" in this document are to be interpreted as described in BCP 185 14 [RFC2119][RFC8174] when, and only when, they appear in all 186 capitals, as shown here. 188 In addition, the terms "Extends" and "Amends" are used as per 189 [I-D.kuehlewind-update-tag] section 3. 191 2.2. References 193 In this document, readers will encounter terms and concepts that are 194 discussed in the "Routing Protocol for Low Power and Lossy Networks" 195 [RPL], the "6TiSCH Architecture" [RFC9030], the "Deterministic 196 Networking Architecture" [RFC8655], the "Reliable and Available 197 Wireless (RAW) Architecture" [RAW-ARCHI], and "Terminology in Low 198 power And Lossy Networks" [RFC7102]. 200 2.3. Glossary 202 This document often uses the following acronyms: 204 CMO: Control Message Option 205 DAO: destination Advertisement Object 206 DAG: Directed Acyclic Graph 207 DODAG: destination-Oriented Directed Acyclic Graph; A DAG with only 208 one vertex (i.e., node) that has no outgoing edge (i.e., link) 209 GUA: IPv6 Global Unicast Address 210 LLN: Low-Power and Lossy Network 211 MOP: RPL Mode of Operation 212 P-DAO: Projected DAO 213 P-Route: Projected Route 214 PDR: P-DAO Request 215 RAN: RPL-Aware Node (either a RPL router or a RPL-Aware Leaf) 216 RAL: RPL-Aware Leaf 217 RH: Routing Header 218 RPI: RPL Packet Information 219 RTO: RPL Target Option 220 RUL: RPL-Unaware Leaf 221 SIO: RPL Sibling Information Option 222 ULA: IPv6 Unique Local Address 223 NSM-VIO: A Source-Routed Via Information Option, used in Non-Storing 224 Mode P-DAO messages. 225 SLO: Service Level Objective 226 TIO: RPL Transit Information Option 227 SM-VIO: A strict Via Information Option, used in Storing Mode P-DAO 228 messages. 229 VIO: A Via Information Option; it can be a SM-VIO or an NSM-VIO. 231 2.4. Domain Terms 233 This specification uses the following terminology: 235 2.4.1. Projected Route 237 A RPL P-Route is a RPL route that is computed remotely by a PCE, and 238 installed and maintained by a RPL Root on behalf of the PCE. It is 239 installed as a state that signals that destinations (aka Targets) are 240 reachable along a sequence of nodes. 242 2.4.2. Projected DAO 244 A DAO message used to install a P-Route. 246 2.4.3. Path 248 Quoting section 1.1.3 of [INT-ARCHI]: 250 | At a given moment, all the IP datagrams from a particular source 251 | host to a particular destination host will typically traverse the 252 | same sequence of gateways. We use the term "path" for this 253 | sequence. Note that a path is uni-directional; it is not unusual 254 | to have different paths in the two directions between a given host 255 | pair. 257 Section 2 of [I-D.irtf-panrg-path-properties] points to a longer, 258 more modern definition of path, which begins as follows: 260 | A sequence of adjacent path elements over which a packet can be 261 | transmitted, starting and ending with a node. A path is 262 | unidirectional. Paths are time-dependent, i.e., the sequence of 263 | path elements over which packets are sent from one node to another 264 | may change. A path is defined between two nodes. 266 It follows that the general acceptance of a path is a linear sequence 267 of nodes, as opposed to a multi-dimensional graph. In the context of 268 this document, a path is observed by following one copy of a packet 269 that is injected in a Track and possibly replicated within. 271 2.4.4. Routing Stretch 273 RPL is anisotropic, meaning that it is directional, or more exactly 274 polar. RPL does not behave the same way "down" with multicast DIO 275 messages that form the DODAG and "up" with unicast DAO messages that 276 follow the DODAG. This is in contrast with traditional IGPs that 277 operate the same in all directions and are thus called isotropic. 279 The term Routing Stretch denotes the length of a path, as compared 280 with a shortest path, which can be a abstract concepts in RPL when 281 the metrics are statistical and dynamic, and the concept of short 282 varies with the Objective Function. 284 The RPL DODAG optimizes the P2MP (from Root) and MP2P (to Root) 285 paths, but the P2P (node to node) traffic has to follow the same 286 DODAG. Following the DODAG, the RPL datapath passes via a common 287 parent in Storing Mode and via the Root in Non-Storing Mode. This 288 typically involves more hops and more latency than the minimum 289 possible for a direct P2P path that an isotropic protocol would 290 compute. We refer to this elongated path as stretched. 292 2.4.5. Track 294 A networking graph that can be followed to transport packets with 295 equivalent treatment; as opposed to the definition of a path above, a 296 Track is not necessarily linear. It may contain multiple paths that 297 may fork and rejoin, and may enable the RAW Packet ARQ, Replication, 298 Elimination, and Overhearing (PAREO) operations. 300 A ==> B ==> C -=- F ==> G ==> H T1 I: Ingress 301 / \ / \ / E: Egress 302 I O E -=- T2 T1, T2, T3: 303 \ / \ / \ External 304 P ==> Q ==> R -=- T ==> U ==> V T3 Targets 306 I ==> A ==> B ==> C : a segment to targets F and O 308 I --> F --> E : a leg to targets T1, T2, T3 310 I, A, B, C, F, G, H, E : a path to T1, T2, T3 312 Figure 1: A Track and its Components 314 This specification builds Tracks that are DODAGs oriented towards a 315 Track Ingress, and the forward direction for packets (aka East-West) 316 is from the Track Ingress to one of the possibly multiple Track 317 Egress Nodes, which is also down the DODAG. 319 The Track may be strictly connected, meaning that the vertices are 320 adjacent, or loosely connected, meaning that the vertices are 321 connected using Segments that are associated to the same Track. 323 2.4.5.1. TrackID 325 A RPL Local InstanceID that identifies a Track using the namespace 326 owned by the Track Ingress. The TrackID is associated with the IPv6 327 Address of the Track Ingress that is used as DODAGID, and together 328 they form a unique identification of the Track (see the definition of 329 DODAGID in section 2 of [RPL]. 331 2.4.5.2. Namespace 333 The term namespace is used to refer to the scope of the TrackID. The 334 TrackID is locally significant within its namespace. The namespace 335 is identified by the DODAGID for the Track. The tuple (DODAGID, 336 TrackID) is globally unique. 338 2.4.5.3. Serial Track 340 A Track that has only one path. 342 2.4.5.4. Stand-Alone 344 A single P-DAO that fully defines a Track, e.g., a Serial Track 345 installed with a single Storing Mode Via Information option (SM-VIO). 347 2.4.5.5. Stitching 349 This specification using the term stitching to indicate that a track 350 is piped to another one, meaning that traffic out of the first is 351 injected in the other. 353 2.4.5.6. subTrack 355 A Track within a Track. As the Non-Storing Mode Via Information 356 option (NSM-VIO) can only signal a loose sequence of nodes, it takes 357 a number of them to signal a complex Track. Each NSM-VIO for the 358 same TrackId but a different Segment ID signals a different subTracks 359 that the Track Ingress adds to the topology. 361 2.4.5.7. Leg 363 An end-to-end East-West serial path that can be a Track by itself or 364 a subTrack of a complex Track. With this specification, a Leg is is 365 installed by the Root of the main DODAG using Non-Storing Mode P-DAO 366 messages, and it is expressed as a loose sequence of nodes that are 367 joined by Track Segments. 369 2.4.5.8. Segment 371 A serial path formed by a strict sequence of nodes, along which a 372 P-Route is installed. With this specification, a Segment is 373 typically installed by the Root of the main DODAG using Storing Mode 374 P-DAO messages. A Segment used as the topological edge of a Track. 375 Since this specification builds only DODAGs, all Segments are 376 oriented from Ingress (East) to Egress (West), as opposed to the 377 general RAW model, which allows North/South Segments that can be 378 bidirectional. 380 2.4.5.8.1. Section of a Segment 382 A continuous subset of a segment that may be replaced while the 383 segment remains. for instance, in segment A=>B=>C=>D=>E=>F, say that 384 the link C to D might be misbehaving. The section B=>C=>D=>E in the 385 segment may be replaced by B=>C'=>D'=>E to route around the problem. 386 The segment becomes A=>B=>C'=>D'=>E=>F. 388 2.4.5.8.2. Segment Routing and SRH 390 The terms Segment Routing and SRH refer to using source-routing to 391 hop over segments. In a Non-Storing mode RPL domain, the SRH is 392 typically a RPL Source Route Header (the IPv6 RH of type 3) as 393 defined in [RFC6554]. 395 If the network is a 6LoWPAN Network, the expectation is that the SRH 396 is compressed and encoded as a 6LoWPAN Routing Header (6LoRH), as 397 specified in section 5 of [RFC8138]. 399 On the other hand, if the RPL Network is less constrained and 400 operated in Storing Mode, as discussed in Section 7.1, the Segment 401 Routing operation and the SRH could be as specified in [RFC8754]. 402 This specification applies equally to both forms of source routing 403 and SRH. 405 3. Context and Goal 407 3.1. RPL Applicability 409 RPL is optimized for situations where the power is scarce, the 410 bandwidth constrained and the transmissions unreliable. This matches 411 the use case of an IoT LLN where RPL is typically used today, but 412 also situations of high relative mobility between the nodes in the 413 network (aka swarming), e.g., within a variable set of vehicles with 414 a similar global motion, or a toon of drones. 416 To reach this goal, RPL is primarily designed to minimize the control 417 plane activity, that is the relative amount of routing protocol 418 exchanges vs. data traffic, and the amount of state that is 419 maintained in each node. RPL does not need converge, and provides 420 connectivity to most nodes most of the time. 422 RPL may form multiple topologies called instances. Instances can be 423 created to enforce various optimizations through objective functions, 424 or to reach out through different Root Nodes. The concept of 425 objective function allows to adapt the activity of the routing 426 protocol to the use case, e.g., type, speed, and quality of the LLN 427 links. 429 RPL instances operate as ships passing in the night, unbeknownst of 430 one another. The RPL Root is responsible to select the RPL Instance 431 that is used to forward a packet coming from the Backbone into the 432 RPL domain and set the related RPL information in the packets. 6TiSCH 433 leverages RPL for its distributed routing operations. 435 To reduce the routing exchanges, RPL leverages an anisotropic 436 Distance Vector approach, which does not need a global knowledge of 437 the topology, and only optimizes the routes to and from the RPL Root, 438 allowing P2P paths to be stretched. Although RPL installs its routes 439 proactively, it only maintains them lazily, in reaction to actual 440 traffic, or as a slow background activity. 442 This is simple and efficient in situations where the traffic is 443 mostly directed from or to a central node, such as the control 444 traffic between routers and a controller of a Software Defined 445 Networking (SDN) infrastructure or an Autonomic Control Plane (ACP). 447 But stretch in P2P routing is counter-productive to both reliability 448 and latency as it introduces additional delay and chances of loss. 449 As a result, [RPL] is not a good fit for the use cases listed in the 450 RAW use cases document [USE-CASES], which demand high availability 451 and reliability, and as a consequence require both short and diverse 452 paths. 454 3.2. RPL Routing Modes 456 RPL first forms a default route in each node towards the a Root, and 457 those routes together coalesce as a Directed Acyclic Graph upwards. 458 RPL then constructs routes to destinations signaled as Targets in the 459 reverse direction, down the same DODAG. So do so, a RPL Instance can 460 be operated either in RPL Storing or Non-Storing Mode of Operation 461 (MOP). The default route towards the Root is maintained aggressively 462 and may change while a packet progresses without causing loops, so 463 the packet will still reach the Root. 465 In Non-Storing Mode, each node advertises itself as a Target directly 466 to the Root, indicating the parents that may be used to reach self. 467 Recursively, the Root builds and maintains an image of the whole 468 DODAG in memory, and leverages that abstraction to compute source 469 route paths for the packets to their destinations down the DODAG. 470 When a node changes its point(s) of attachment to the DODAG, it takes 471 single unicast packet to the Root along the default route to update 472 it, and the connectivity is restored immediately; this mode is 473 preferable for use cases where internet connectivity is dominant, or 474 when, like here, the Root controls the network activity in the nodes. 476 In Storing Mode, the routing information percolates upwards, and each 477 node maintains the routes to the subDAG of its descendants down the 478 DODAG. The maintenance is lazy, either reactive upon traffic or as a 479 slow background process. Packets flow via the common parent and the 480 routing stretch is reduced vs. Non-Storing, for a better P2P 481 connectivity. On the other hand, a new route takes a longer time to 482 propagate to the Root, time for the Distance-Vector protocol to 483 operate hop-by-hop, and the Internet connectivity is restored more 484 slowly upon movement. 486 Either way, the RPL routes are injected by the Target nodes, in a 487 distributed fashion. To complement RPL and eliminate routing 488 stretch, this specification introduces an hybrid mode that combines 489 Storing and Non-Storing operations to build and project routes onto 490 the nodes where they should be installed. This specification uses 491 the term Projected Route (P-Route) to refer to those routes. 493 A P-Route may be installed in either Storing and Non-Storing Mode, 494 potentially resulting in hybrid situations where the Mode of the P- 495 Route is different from that of the RPL Main DODAG. P-Routes can be 496 used as stand-alone segments to reduce the size of the source routing 497 headers with loose source routing operations down the main RPL DODAG. 498 P-Routes can also be combined with other P-Routes to form a more 499 complex forwarding graph called a Track. 501 3.3. Requirements 503 3.3.1. Loose Source Routing 505 A RPL implementation operating in a very constrained LLN typically 506 uses the Non-Storing Mode of Operation as represented in Figure 2. 507 In that mode, a RPL node indicates a parent-child relationship to the 508 Root, using a destination Advertisement Object (DAO) that is unicast 509 from the node directly to the Root, and the Root typically builds a 510 source routed path to a destination down the DODAG by recursively 511 concatenating this information. 513 +-----+ 514 | | Border router 515 | | (RPL Root) 516 +-----+ ^ | | 517 | | DAO | ACK | 518 o o o o | | | Strict 519 o o o o o o o o o | | | Source 520 o o o o o o o o o o | | | Route 521 o o o o o o o o o | | | 522 o o o o o o o o | v v 523 o o o o 524 LLN 526 Figure 2: RPL Non-Storing Mode of operation 528 Based on the parent-children relationships expressed in the Non- 529 Storing DAO messages, the Root possesses topological information 530 about the whole network, though this information is limited to the 531 structure of the DODAG for which it is the destination. A packet 532 that is generated within the domain will always reach the Root, which 533 can then apply a source routing information to reach the destination 534 if the destination is also in the DODAG. Similarly, a packet coming 535 from the outside of the domain for a destination that is expected to 536 be in a RPL domain reaches the Root. It results that the wireless 537 bandwidth near the Root is the gating factor for all transmissions 538 towards or within the domain, and that the Root is a single point of 539 failure for all connectivity to nodes within its domain. 541 The RPL Root must add a source routing header to all downward 542 packets. As a network grows, the size of the source routing header 543 augments with the depth of the nodes. In some use cases, a RPL 544 network forms long lines along physical structures such as streets 545 for lighting. Limiting the packet size is directly beneficial to the 546 energy budget, but, mostly, it reduces the chances of frame loss and 547 packet fragmentation, which are highly detrimental to the LLN 548 operation. A limited amount of well-targeted routing state would 549 allow the source routing operation to be loose as opposed to strict, 550 and save packet size. Because the capability to store a routing 551 state in every node is limited, the decision of which route is 552 installed where can only be optimized with a global knowledge of the 553 system, a knowledge that the Root or an associated PCE may possess by 554 means that are outside of the scope of this specification. 556 Being on path for all packets in Non-Storing mode, the Root may 557 determine the number of P2P packets in its RPL domain per source and 558 destination, the latency incurred, and the amount of energy and 559 bandwidth that is consumed to reach the self and then down, including 560 a possible fragmentation when encapsulating larger packets. Enabling 561 a shorter path that would not traverse the Root for select P2P 562 source/destinations may improve the latency, lower the consumption of 563 constrained resources, free bandwidth at the bottleneck near the 564 Root, improve the delivery ratio and reduce the latency for those P2P 565 flows with a global benefit for all flows of reducing the load at the 566 Root. 568 This requirement is to store a routing state associated with the Main 569 DODAG in selected RPL routers, to limit the excursion of the source 570 route headers in deep networks. The Root may elide the sequence of 571 routers that is installed in the network from its source route 572 header, which becomes loose while it is strict in [RPL]. 574 3.3.2. East-West Routes 576 [RPL] optimizes Point-to-Multipoint (P2MP) routes from the Root, 577 Multipoint-to-Point (MP2P) routes to the DODAG Root, and Internet 578 access when the Root also serves as Border Router. All routes are 579 installed North-South (aka up/down) along the RPL DODAG. Peer to 580 Peer (P2P) East-West routes in a RPL network will generally suffer 581 from some elongated (stretched) path versus a direct (optimized) 582 path, since routing between two nodes always happens via a common 583 parent, as illustrated in Figure 3: 585 ------+--------- 586 | Internet 587 +-----+ 588 | | Border router 589 | | (RPL Root) 590 +-----+ 591 X 592 ^ v o o 593 ^ o o v o o o o o 594 ^ o o o v o o o o o 595 ^ o o v o o o o o 596 S o o o D o o o 597 o o o o 598 LLN 600 Figure 3: Routing Stretch between S and D via common parent X 601 along North-South Paths 603 As described in [RFC9008], the amount of stretch depends on the Mode 604 of Operation: 606 * in Non-Storing Mode, all packets routed within the DODAG flow all 607 the way up to the Root of the DODAG. If the destination is in the 608 same DODAG, the Root must encapsulate the packet to place an RH 609 that has the strict source route information down the DODAG to the 610 destination. This will be the case even if the destination is 611 relatively close to the source and the Root is relatively far off. 613 * In Storing Mode, unless the destination is a child of the source, 614 the packets will follow the default route up the DODAG as well. 615 If the destination is in the same DODAG, they will eventually 616 reach a common parent that has a route to the destination; at 617 worse, the common parent may also be the Root. From that common 618 parent, the packet will follow a path down the DODAG that is 619 optimized for the Objective Function that was used to build the 620 DODAG. 622 It results that it is often beneficial to enable East-West P2P 623 routes, either if the RPL route presents a stretch from shortest 624 path, or if the new route is engineered with a different objective, 625 and that it is even more critical in Non-Storing Mode than it is in 626 Storing Mode, because the routing stretch is wider. For that reason, 627 earlier work at the IETF introduced the "Reactive Discovery of 628 Point-to-Point Routes in Low Power and Lossy Networks" [RFC6997], 629 which specifies a distributed method for establishing optimized P2P 630 routes. This draft proposes an alternate based on a centralized 631 route computation. 633 +-----+ 634 | | Border router 635 | | (RPL Root) 636 +-----+ 637 | 638 o o o o 639 o o o o o o o o o 640 o o o o o o o o o o 641 o o o o o o o o o 642 S>>A>>>B>>C>>>D o o o 643 o o o o 644 LLN 646 Figure 4: More direct East-West Route between S and D 648 The requirement is to install additional routes in the RPL routers, 649 to reduce the stretch of some P2P routes and maintain the 650 characteristics within a given SLO, e.g., in terms of latency and/or 651 reliability. 653 3.4. On Tracks 654 3.4.1. Building Tracks With RPL 656 The concept of a Track was introduced in the "6TiSCH Architecture" 657 [RFC9030], as a collection of potential paths that leverage redundant 658 forwarding solutions along the way. This can be a DODAG or a more 659 complex structure that is only partially acyclic (e.g., per packet). 661 With this specification, a Track is shaped as a DODAG, and following 662 the directed edges leads to a Track Ingress. Storing Mode P-DAO 663 messages follow the direction of the edges to set up routes for 664 traffic that flows the other way, towards the Track Egress(es). If 665 there is a single Track Egress, then the Track is reversible to form 666 another DODAG by reversing the direction of each edge. A node at the 667 Ingress of more than one Segment in a Track may use one or more of 668 these Segments to forward a packet inside the Track. 670 A RPL Track is a collection of (one or more) parallel loose source 671 routed sequences of nodes ordered from Ingress to Egress, each 672 forming a Track Leg. The nodes that are directly connected, 673 reachable via existing Tracks as illustrated in Section 3.5.2.3 or 674 joined with strict Segments of other nodes as shown in 675 Section 3.5.1.3. The Legs are expressed in RPL Non-Storing Mode and 676 require an encapsulation to add a Source Route Header, whereas the 677 Segments are expressed in RPL Storing Mode. 679 A Serial Track comprises provides only one path between Ingress and 680 Egress. It comprises at most one Leg. A Stand-Alone Segment 681 implicitly defines a Serial Track from its Ingress to Egress. 683 A complex Track forms a graph that provides a collection of potential 684 paths to provide redundancy for the packets, either as a collection 685 of Legs that may be parallel or cross at certain points, or as a more 686 generic DODAG. 688 3.4.2. Tracks and RPL Instances 690 Section 5.1. of [RPL] describes the RPL Instance and its encoding. 691 There can be up to 128 global RPL Instances, for which there can be 692 one or more DODAGs, and there can be 64 local RPL Instances, with a 693 namespace that is indexed by a DODAGID, where the DODAGID is a Unique 694 Local Address (ULA) or a Global Unicast Address (GUA) of the Root of 695 the DODAG. Bit 0 (most significant) is set to 1 to signal a Local 696 RPLInstanceID, as shown in Figure 5. By extension, this 697 specification expresses the value of the RPLInstanceID as a single 698 integer between 128 and 191, representing both the Local 699 RPLInstanceID in 0..63 and Bit 0 set. 701 0 1 2 3 4 5 6 7 702 +-+-+-+-+-+-+-+-+ 703 |1|D| ID | Local RPLInstanceID in 0..63 704 +-+-+-+-+-+-+-+-+ 706 Figure 5: Local RPLInstanceID Encoding 708 A Track is normally associated with a Local RPL Instance which 709 RPLInstanceID is used as the TrackID, more in Section 6.3. A Track 710 Leg may also be used as a subTrack that extends the RPL main DODAG. 711 In that case, the TrackID is set to the global RPLInstanceID of the 712 main DODAG, which suffices to identify the routing topology. As 713 opposed to local RPL instances, the Track Ingress that encapsulates 714 the packets over a subtrack is not Root, and that the source address 715 of the encapsulated packet is not used to determine the Track. 717 3.5. Serial Track Signaling 719 This specification enables to set up a P-Route along either a Track 720 Leg or a Segment. A P-Route is installed and maintained by the Root 721 of the main DODAG using an extended RPL DAO message called a 722 Projected DAO (P-DAO), and a Track is composed of the combination of 723 one or more P-Routes. 725 A P-DAO message for a Track signals the TrackID in the RPLInstanceID 726 field. In the case of a local RPL Instance, the address of the Track 727 Ingress is used as source to encapsulate packets along the Track. 728 The Track is signaled in the DODAGID field of the Projected DAO Base 729 Object, see Figure 8. 731 This specification introduces the Via Information Option (VIO) to 732 signal a sequence of hops in a Leg or a Segment in the P-DAO 733 messages, either in Storing Mode (SM-VIO) or Non-Storing Mode (NSM- 734 VIO). One P-DAO messages contains a single VIO, associated to one or 735 more RPL Target Options that signal the destination IPv6 addresses 736 that can reached along the Track, more in Section 5.3. 738 Before diving deeper into Track Legs and Segments signaling and 739 operation, this section provides examples of what how route 740 projection works through variations of a simple example. This simple 741 example illustrates the case of host routes, though RPL Targets can 742 be prefixes. 744 Say we want to build a Serial Track from node A to E in Figure 6, so 745 A can route packets to E's neighbors F and G along A, B, C, D and E 746 as opposed to via the Root: 748 /===> F 749 A ===> B ===> C ===> D===> E < 750 \===> G 752 Figure 6: Reference Track 754 Conventionally we use ==> to represent a strict hop and --> for a 755 loose hop. We use "-to-", such as in C==>D==>E-to-F to represent 756 coma-separated Targets, e.g., F is a Target for Segment C==>D==>E. 757 In this example, A is Track Ingress, E is Track Egress. C is a 758 stitching point. F and G are "external" Targets for the Track, and 759 become reachable from A via the Track A(ingress) to E (Egress and 760 implicit Target in Non-Storing Mode) leading to F and G (explicit 761 Targets). 763 Figure 5 depicts the format of the RPLInstanceID encoding for a local 764 RPLInstanceID . 766 In a general manner the desired outcome is as follows: 768 * Targets are E, F, and G 770 * P-DAO 1 signals C==>D==>E 772 * P-DAO 2 signals A==>B==>C 774 * P-DAO 3 signals F and G via the A-->E Track 776 P-DAO 3 may be ommitted if P-DAO 1 and 2 signal F and G as Targets. 778 Loose sequences of hops must be expressed in Non-Storing Mode, so 779 P-DAO 3 contains a NSM-VIO. With this specification, the DODAGID to 780 be used by the Ingress as source address is signaled if needed in the 781 DAO base object, the via list starts at the first loose hop and 782 matches the source route header, and the Egress of a Non-Storing Mode 783 P-DAO is an implicit Target that is not listed in the RTO. 785 3.5.1. Using Storing Mode Segments 787 A==>B==>C and C==>D==>E are segments of a same Track. Note that the 788 Storing Mode signaling imposes strict continuity in a segment, since 789 the P-DAO is passed hop by hop, as a classical DAO is, along the 790 reverse datapath that it signals. One benefit of strict routing is 791 that loops are avoided along the Track. 793 3.5.1.1. Stitched Segments 795 In this formulation: 797 * P-DAO 1 signals C==>D==>E-to-F,G 799 * P-DAO 2 signals A==>B==>C-to-F,G 801 Storing Mode P-DAO 1 is sent to E and when it is succesfully 802 acknowledged, Storing Mode P-DAO 2 is sent to C, as follows: 804 +====================+==============+==============+ 805 | Field | P-DAO 1 to E | P-DAO 2 to C | 806 +====================+==============+==============+ 807 | Mode | Storing | Storing | 808 +--------------------+--------------+--------------+ 809 | Track Ingress | A | A | 810 +--------------------+--------------+--------------+ 811 | (DODAGID, TrackID) | (A, 129) | (A, 129) | 812 +--------------------+--------------+--------------+ 813 | SegmentID | 1 | 2 | 814 +--------------------+--------------+--------------+ 815 | VIO | C, D, E | A, B, C | 816 +--------------------+--------------+--------------+ 817 | Targets | F, G | F, G | 818 +--------------------+--------------+--------------+ 820 Table 1: P-DAO Messages 822 As a result the RIBs are set as follows: 824 +======+=============+=========+=============+==========+ 825 | Node | destination | Origin | Next Hop(s) | TrackID | 826 +======+=============+=========+=============+==========+ 827 | E | F, G | P-DAO 1 | Neighbor | (A, 129) | 828 +------+-------------+---------+-------------+----------+ 829 | D | E | P-DAO 1 | Neighbor | (A, 129) | 830 +------+-------------+---------+-------------+----------+ 831 | " | F, G | P-DAO 1 | E | (A, 129) | 832 +------+-------------+---------+-------------+----------+ 833 | C | D | P-DAO 1 | Neighbor | (A, 129) | 834 +------+-------------+---------+-------------+----------+ 835 | " | F, G | P-DAO 1 | D | (A, 129) | 836 +------+-------------+---------+-------------+----------+ 837 | B | C | P-DAO 2 | Neighbor | (A, 129) | 838 +------+-------------+---------+-------------+----------+ 839 | " | F, G | P-DAO 2 | C | (A, 129) | 840 +------+-------------+---------+-------------+----------+ 841 | A | B | P-DAO 2 | Neighbor | (A, 129) | 842 +------+-------------+---------+-------------+----------+ 843 | " | F, G | P-DAO 2 | B | (A, 129) | 844 +------+-------------+---------+-------------+----------+ 846 Table 2: RIB setting 848 Packets originated by A to F or G do not require an encapsulation as 849 the RPI can be placed in the native header chain. For packets that 850 it routes, A must encapsulate to add the RPI that signals the 851 trackID; the outer headers of the packets that are forwarded along 852 the Track have the following settings: 854 +========+===================+===================+================+ 855 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 856 +========+===================+===================+================+ 857 | Outer | A | F or G | (A, 129) | 858 +--------+-------------------+-------------------+----------------+ 859 | Inner | X != A | F or G | N/A | 860 +--------+-------------------+-------------------+----------------+ 862 Table 3: Packet Header Settings 864 As an example, say that A has a packet for F. Using the RIB above: 866 * From P-DAO 2: A forwards to B and B forwards to C. 868 * From P-DAO 1: C forwards to D and D forwards to E. 870 * From Neighbor Cache Entry: E delivers the packet to F. 872 3.5.1.2. External routes 874 In this example, we consider F and G as destinations that are 875 external to the Track as a DODAG, as discussed in section 4.1.1. of 876 [RFC9008]. We then apply the directives for encapsulating in that 877 case, more in Section 6.7. 879 In this formulation, we set up the Track Leg explicitly, which 880 creates less routing state in intermediate hops at the expense of 881 larger packets to accommodate source routing: 883 * P-DAO 1 signals C==>D==>E-to-E 885 * P-DAO 2 signals A==>B==>C-to-E 887 * P-DAO 3 signals F and G via the A-->E-to-F,G Track 889 Storing Mode P-DAO 1 and 2, and Non-Storing Mode P-DAO 3, are sent to 890 E, C and A, respectively, as follows: 892 +====================+==============+==============+==============+ 893 | | P-DAO 1 to E | P-DAO 2 to C | P-DAO 3 to A | 894 +====================+==============+==============+==============+ 895 | Mode | Storing | Storing | Non-Storing | 896 +--------------------+--------------+--------------+--------------+ 897 | Track Ingress | A | A | A | 898 +--------------------+--------------+--------------+--------------+ 899 | (DODAGID, TrackID) | (A, 129) | (A, 129) | (A, 129) | 900 +--------------------+--------------+--------------+--------------+ 901 | SegmentID | 1 | 2 | 3 | 902 +--------------------+--------------+--------------+--------------+ 903 | VIO | C, D, E | A, B, C | E | 904 +--------------------+--------------+--------------+--------------+ 905 | Targets | E | E | F, G | 906 +--------------------+--------------+--------------+--------------+ 908 Table 4: P-DAO Messages 910 Note in the above that E is not an implicit Target in Storing mode, 911 so it must be added in the RTO. 913 As a result the RIBs are set as follows: 915 +======+=============+=========+=============+==========+ 916 | Node | destination | Origin | Next Hop(s) | TrackID | 917 +======+=============+=========+=============+==========+ 918 | E | F, G | P-DAO 1 | Neighbor | (A, 129) | 919 +------+-------------+---------+-------------+----------+ 920 | D | E | P-DAO 1 | Neighbor | (A, 129) | 921 +------+-------------+---------+-------------+----------+ 922 | C | D | P-DAO 1 | Neighbor | (A, 129) | 923 +------+-------------+---------+-------------+----------+ 924 | " | E | P-DAO 1 | D | (A, 129) | 925 +------+-------------+---------+-------------+----------+ 926 | B | C | P-DAO 2 | Neighbor | (A, 129) | 927 +------+-------------+---------+-------------+----------+ 928 | " | E | P-DAO 2 | C | (A, 129) | 929 +------+-------------+---------+-------------+----------+ 930 | A | B | P-DAO 2 | Neighbor | (A, 129) | 931 +------+-------------+---------+-------------+----------+ 932 | " | E | P-DAO 2 | B | (A, 129) | 933 +------+-------------+---------+-------------+----------+ 934 | " | F, G | P-DAO 3 | E | (A, 129) | 935 +------+-------------+---------+-------------+----------+ 937 Table 5: RIB setting 939 Packets from A to E do not require an encapsulation. The outer 940 headers of the packets that are forwarded along the Track have the 941 following settings: 943 +========+===================+====================+================+ 944 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 945 +========+===================+====================+================+ 946 | Outer | A | E | (A, 129) | 947 +--------+-------------------+--------------------+----------------+ 948 | Inner | X | E (X != A), F or G | N/A | 949 +--------+-------------------+--------------------+----------------+ 951 Table 6: Packet Header Settings 953 As an example, say that A has a packet for F. Using the RIB above: 955 * From P-DAO 3: A encapsulates the packet the Track signaled by 956 P-DAO 3, with the outer header above. Now the packet destination 957 is E. 959 * From P-DAO 2: A forwards to B and B forwards to C. 961 * From P-DAO 1: C forwards to D and D forwards to E; E decapsulates 962 the packet. 964 * From Neighbor Cache Entry: E delivers packets to F or G. 966 3.5.1.3. Segment Routing 968 In this formulation leverages Track Legs to combine Segments and form 969 a Graph. The packets are source routed from a Segment to the next to 970 adapt the path. As such, this can be seen as a form of Segment 971 Routing [RFC8402]: 973 * P-DAO 1 signals C==>D==>E-to-E 975 * P-DAO 2 signals A==>B-to-B,C 977 * P-DAO 3 signals F and G via the A-->C-->E-to-F,G Track 979 Storing Mode P-DAO 1 and 2, and Non-Storing Mode P-DAO 3, are sent to 980 E, B and A, respectively, as follows: 982 +====================+==============+==============+==============+ 983 | | P-DAO 1 to E | P-DAO 2 to B | P-DAO 3 to A | 984 +====================+==============+==============+==============+ 985 | Mode | Storing | Storing | Non-Storing | 986 +--------------------+--------------+--------------+--------------+ 987 | Track Ingress | A | A | A | 988 +--------------------+--------------+--------------+--------------+ 989 | (DODAGID, TrackID) | (A, 129) | (A, 129) | (A, 129) | 990 +--------------------+--------------+--------------+--------------+ 991 | SegmentID | 1 | 2 | 3 | 992 +--------------------+--------------+--------------+--------------+ 993 | VIO | C, D, E | A, B | C, E | 994 +--------------------+--------------+--------------+--------------+ 995 | Targets | E | C | F, G | 996 +--------------------+--------------+--------------+--------------+ 998 Table 7: P-DAO Messages 1000 Note in the above that the Segment can terminate at the loose hop as 1001 used in the example of P-DAO 1 or at the previous hop as done with 1002 P-DAO 2. Both methods are possible on any Segment joined by a loose 1003 Track Leg. P-DAO 1 generates more signaling since E is the Segment 1004 Egress when D could be, but has the benefit that it validates that 1005 the connectivity between D and E still exists. 1007 As a result the RIBs are set as follows: 1009 +======+=============+=========+=============+==========+ 1010 | Node | destination | Origin | Next Hop(s) | TrackID | 1011 +======+=============+=========+=============+==========+ 1012 | E | F, G | P-DAO 1 | Neighbor | (A, 129) | 1013 +------+-------------+---------+-------------+----------+ 1014 | D | E | P-DAO 1 | Neighbor | (A, 129) | 1015 +------+-------------+---------+-------------+----------+ 1016 | C | D | P-DAO 1 | Neighbor | (A, 129) | 1017 +------+-------------+---------+-------------+----------+ 1018 | " | E | P-DAO 1 | D | (A, 129) | 1019 +------+-------------+---------+-------------+----------+ 1020 | B | C | P-DAO 2 | Neighbor | (A, 129) | 1021 +------+-------------+---------+-------------+----------+ 1022 | A | B | P-DAO 2 | Neighbor | (A, 129) | 1023 +------+-------------+---------+-------------+----------+ 1024 | " | C | P-DAO 2 | B | (A, 129) | 1025 +------+-------------+---------+-------------+----------+ 1026 | " | E, F, G | P-DAO 3 | C, E | (A, 129) | 1027 +------+-------------+---------+-------------+----------+ 1029 Table 8: RIB setting 1031 Packets originated at A to E do not require an encapsulation, but 1032 carry a SRH via C. The outer headers of the packets that are 1033 forwarded along the Track have the following settings: 1035 +========+===================+====================+================+ 1036 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1037 +========+===================+====================+================+ 1038 | Outer | A | C till C then E | (A, 129) | 1039 +--------+-------------------+--------------------+----------------+ 1040 | Inner | X | E (X != A), F or G | N/A | 1041 +--------+-------------------+--------------------+----------------+ 1043 Table 9: Packet Header Settings 1045 As an example, say that A has a packet for F. Using the RIB above: 1047 * From P-DAO 3: A encapsulates the packet the Track signaled by 1048 P-DAO 3, with the outer header above. Now the destination in the 1049 IPv6 Header is C, and a SRH signals the final destination is E. 1051 * From P-DAO 2: A forwards to B and B forwards to C. 1053 * From P-DAO 3: C processes the SRH and sets the destination in the 1054 IPv6 Header to E. 1056 * From P-DAO 1: C forwards to D and D forwards to E; E decapsulates 1057 the packet. 1059 * From the Neighbor Cache Entry: E delivers packets to F or G. 1061 3.5.2. Using Non-Storing Mode joining Tracks 1063 In this formulation: 1065 * P-DAO 1 signals C==>D==>E-to-F,G 1067 * P-DAO 2 signals A==>B==>C-to-E,F,G 1069 A==>B==>C and C==>D==>E are Tracks expressed as Non-Storing P-DAOs. 1071 3.5.2.1. Stitched Tracks 1073 Non-Storing Mode P-DAO 1 and 2 are sent to C and A respectively, as 1074 follows: 1076 +====================+==============+==============+ 1077 | | P-DAO 1 to C | P-DAO 2 to A | 1078 +====================+==============+==============+ 1079 | Mode | Non-Storing | Non-Storing | 1080 +--------------------+--------------+--------------+ 1081 | Track Ingress | C | A | 1082 +--------------------+--------------+--------------+ 1083 | (DODAGID, TrackID) | (C, 131) | (A, 131) | 1084 +--------------------+--------------+--------------+ 1085 | SegmentID | 1 | 1 | 1086 +--------------------+--------------+--------------+ 1087 | VIO | D, E | B, C | 1088 +--------------------+--------------+--------------+ 1089 | Targets | F, G | E, F, G | 1090 +--------------------+--------------+--------------+ 1092 Table 10: P-DAO Messages 1094 As a result the RIBs are set as follows: 1096 +======+=============+=========+=============+==========+ 1097 | Node | destination | Origin | Next Hop(s) | TrackID | 1098 +======+=============+=========+=============+==========+ 1099 | E | F, G | ND | Neighbor | Any | 1100 +------+-------------+---------+-------------+----------+ 1101 | D | E | ND | Neighbor | Any | 1102 +------+-------------+---------+-------------+----------+ 1103 | C | D | ND | Neighbor | Any | 1104 +------+-------------+---------+-------------+----------+ 1105 | " | E, F, G | P-DAO 1 | D, E | (C, 131) | 1106 +------+-------------+---------+-------------+----------+ 1107 | B | C | ND | Neighbor | Any | 1108 +------+-------------+---------+-------------+----------+ 1109 | A | B | ND | Neighbor | Any | 1110 +------+-------------+---------+-------------+----------+ 1111 | " | C, E, F, G | P-DAO 2 | B, C | (A, 131) | 1112 +------+-------------+---------+-------------+----------+ 1114 Table 11: RIB setting 1116 Packets originated at A to E, F and G do not require an 1117 encapsulation, though it is preferred that A encapsulates and C 1118 decapsulates. Either way, they carry a SRH via B and C, and C needs 1119 to encapsulate to E, F, or G to add an SRH via D and E. The 1120 encapsulating headers of packets that are forwarded along the Track 1121 between C and E have the following settings: 1123 +========+===================+===================+================+ 1124 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1125 +========+===================+===================+================+ 1126 | Outer | C | D till D then E | (C, 131) | 1127 +--------+-------------------+-------------------+----------------+ 1128 | Inner | X | E, F, or G | N/A | 1129 +--------+-------------------+-------------------+----------------+ 1131 Table 12: Packet Header Settings between C and E 1133 As an example, say that A has a packet for F. Using the RIB above: 1135 * From P-DAO 2: A encapsulates the packet with destination of F in 1136 the Track signaled by P-DAO 2. The outer header has source A, 1137 destination B, an SRH that indicates C as the next loose hop, and 1138 a RPI indicating a TrackId of 131 from A's namespace, which is 1139 distinct from TrackId of 131 from C's. 1141 * From the SRH: Packets forwarded by B have source A, destination C, 1142 a consumed SRH, and a RPI indicating a TrackId of 131 from A's 1143 namespace. C decapsulates. 1145 * From P-DAO 1: C encapsulates the packet with destination of F in 1146 the Track signaled by P-DAO 1. The outer header has source C, 1147 destination D, an SRH that indicates E as the next loose hop, and 1148 a RPI indicating a TrackId of 131 from C's namespace. E 1149 decapsulates. 1151 3.5.2.2. External routes 1153 In this formulation: 1155 * P-DAO 1 signals C==>D==>E-to-E 1157 * P-DAO 2 signals A==>B==>C-to-C,E 1159 * P-DAO 3 signals F and G via the A-->E-to-F,G Track 1161 Non-Storing Mode P-DAO 1 is sent to C and Non-Storing Mode P-DAO 2 1162 and 3 are sent A, as follows: 1164 +====================+==============+==============+==============+ 1165 | | P-DAO 1 to C | P-DAO 2 to A | P-DAO 3 to A | 1166 +====================+==============+==============+==============+ 1167 | Mode | Non-Storing | Non-Storing | Non-Storing | 1168 +--------------------+--------------+--------------+--------------+ 1169 | Track Ingress | C | A | A | 1170 +--------------------+--------------+--------------+--------------+ 1171 | (DODAGID, TrackID) | (C, 131) | (A, 129) | (A, 141) | 1172 +--------------------+--------------+--------------+--------------+ 1173 | SegmentID | 1 | 1 | 1 | 1174 +--------------------+--------------+--------------+--------------+ 1175 | VIO | D, E | B, C | E | 1176 +--------------------+--------------+--------------+--------------+ 1177 | Targets | E | E | F, G | 1178 +--------------------+--------------+--------------+--------------+ 1180 Table 13: P-DAO Messages 1182 As a result the RIBs are set as follows: 1184 +======+=============+=========+=============+==========+ 1185 | Node | destination | Origin | Next Hop(s) | TrackID | 1186 +======+=============+=========+=============+==========+ 1187 | E | F, G | ND | Neighbor | Any | 1188 +------+-------------+---------+-------------+----------+ 1189 | D | E | ND | Neighbor | Any | 1190 +------+-------------+---------+-------------+----------+ 1191 | C | D | ND | Neighbor | Any | 1192 +------+-------------+---------+-------------+----------+ 1193 | " | E | P-DAO 1 | D, E | (C, 131) | 1194 +------+-------------+---------+-------------+----------+ 1195 | B | C | ND | Neighbor | Any | 1196 +------+-------------+---------+-------------+----------+ 1197 | A | B | ND | Neighbor | Any | 1198 +------+-------------+---------+-------------+----------+ 1199 | " | C, E | P-DAO 2 | B, C | (A, 129) | 1200 +------+-------------+---------+-------------+----------+ 1201 | " | F, G | P-DAO 3 | E | (A, 141) | 1202 +------+-------------+---------+-------------+----------+ 1204 Table 14: RIB setting 1206 The encapsulating headers of packets that are forwarded along the 1207 Track between C and E have the following settings: 1209 +========+===================+===================+================+ 1210 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1211 +========+===================+===================+================+ 1212 | Outer | C | D till D then E | (C, 131) | 1213 +--------+-------------------+-------------------+----------------+ 1214 | Middle | A | E | (A, 141) | 1215 +--------+-------------------+-------------------+----------------+ 1216 | Inner | X | E, F or G | N/A | 1217 +--------+-------------------+-------------------+----------------+ 1219 Table 15: Packet Header Settings 1221 As an example, say that A has a packet for F. Using the RIB above: 1223 * From P-DAO 3: A encapsulates the packet with destination of F in 1224 the Track signaled by P-DAO 3. The outer header has source A, 1225 destination E, and a RPI indicating a TrackId of 141 from A's 1226 namespace. This recurses with: 1228 * From P-DAO 2: A encapsulates the packet with destination of E in 1229 the Track signaled by P-DAO 2. The outer header has source A, 1230 destination B, an SRH that indicates C as the next loose hop, and 1231 a RPI indicating a TrackId of 129 from A's namespace. 1233 * From the SRH: Packets forwarded by B have source A, destination C 1234 , a consumed SRH, and a RPI indicating a TrackId of 129 from A's 1235 namespace. C decapsulates. 1237 * From P-DAO 1: C encapsulates the packet with destination of E in 1238 the Track signaled by P-DAO 1. The outer header has source C, 1239 destination D, an SRH that indicates E as the next loose hop, and 1240 a RPI indicating a TrackId of 131 from C's namespace. E 1241 decapsulates. 1243 3.5.2.3. Segment Routing 1245 In this formulation: 1247 * P-DAO 1 signals C==>D==>E-to-E 1249 * P-DAO 2 signals A==>B-to-C 1251 * P-DAO 3 signals F and G via the A-->C-->E-to-F,G Track 1253 Non-Storing Mode P-DAO 1 is sent to C and Non-Storing Mode P-DAO 2 1254 and 3 are sent A, as follows: 1256 +====================+==============+==============+==============+ 1257 | | P-DAO 1 to C | P-DAO 2 to A | P-DAO 3 to A | 1258 +====================+==============+==============+==============+ 1259 | Mode | Non-Storing | Non-Storing | Non-Storing | 1260 +--------------------+--------------+--------------+--------------+ 1261 | Track Ingress | C | A | A | 1262 +--------------------+--------------+--------------+--------------+ 1263 | (DODAGID, TrackID) | (C, 131) | (A, 129) | (A, 141) | 1264 +--------------------+--------------+--------------+--------------+ 1265 | SegmentID | 1 | 1 | 1 | 1266 +--------------------+--------------+--------------+--------------+ 1267 | VIO | D, E | B | C, E | 1268 +--------------------+--------------+--------------+--------------+ 1269 | Targets | | C | F, G | 1270 +--------------------+--------------+--------------+--------------+ 1272 Table 16: P-DAO Messages 1274 As a result the RIBs are set as follows: 1276 +======+=============+=========+=============+==========+ 1277 | Node | destination | Origin | Next Hop(s) | TrackID | 1278 +======+=============+=========+=============+==========+ 1279 | E | F, G | ND | Neighbor | Any | 1280 +------+-------------+---------+-------------+----------+ 1281 | D | E | ND | Neighbor | Any | 1282 +------+-------------+---------+-------------+----------+ 1283 | C | D | ND | Neighbor | Any | 1284 +------+-------------+---------+-------------+----------+ 1285 | " | E | P-DAO 1 | D, E | (C, 131) | 1286 +------+-------------+---------+-------------+----------+ 1287 | B | C | ND | Neighbor | Any | 1288 +------+-------------+---------+-------------+----------+ 1289 | A | B | ND | Neighbor | Any | 1290 +------+-------------+---------+-------------+----------+ 1291 | " | C | P-DAO 2 | B, C | (A, 129) | 1292 +------+-------------+---------+-------------+----------+ 1293 | " | E, F, G | P-DAO 3 | C, E | (A, 141) | 1294 +------+-------------+---------+-------------+----------+ 1296 Table 17: RIB setting 1298 The encapsulating headers of packets that are forwarded along the 1299 Track between A and B have the following settings: 1301 +========+===================+===================+================+ 1302 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1303 +========+===================+===================+================+ 1304 | Outer | A | B till D then E | (A, 129) | 1305 +--------+-------------------+-------------------+----------------+ 1306 | Middle | A | C | (A, 141) | 1307 +--------+-------------------+-------------------+----------------+ 1308 | Inner | X | E, F or G | N/A | 1309 +--------+-------------------+-------------------+----------------+ 1311 Table 18: Packet Header Settings 1313 The encapsulating headers of packets that are forwarded along the 1314 Track between B and C have the following settings: 1316 +========+===================+===================+================+ 1317 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1318 +========+===================+===================+================+ 1319 | Outer | A | C | (A, 141) | 1320 +--------+-------------------+-------------------+----------------+ 1321 | Inner | X | E, F or G | N/A | 1322 +--------+-------------------+-------------------+----------------+ 1324 Table 19: Packet Header Settings 1326 The encapsulating headers of packets that are forwarded along the 1327 Track between C and E have the following settings: 1329 +========+===================+===================+================+ 1330 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1331 +========+===================+===================+================+ 1332 | Outer | C | D till D then E | (C, 131) | 1333 +--------+-------------------+-------------------+----------------+ 1334 | Middle | A | E | (A, 141) | 1335 +--------+-------------------+-------------------+----------------+ 1336 | Inner | X | E, F or G | N/A | 1337 +--------+-------------------+-------------------+----------------+ 1339 Table 20: Packet Header Settings 1341 As an example, say that A has a packet for F. Using the RIB above: 1343 * From P-DAO 3: A encapsulates the packet with destination of F in 1344 the Track signaled by P-DAO 3. The outer header has source A, 1345 destination C, an SRH that indicates E as the next loose hop, and 1346 a RPI indicating a TrackId of 141 from A's namespace. This 1347 recurses with: 1349 * From P-DAO 2: A encapsulates the packet with destination of C in 1350 the Track signaled by P-DAO 2. The outer header has source A, 1351 destination B, and a RPI indicating a TrackId of 129 from A's 1352 namespace. B decapsulates forwards to C based on a sibling 1353 connected route. 1355 * From the SRH: C consumes the SRH and makes the destination E. 1357 * From P-DAO 1: C encapsulates the packet with destination of E in 1358 the Track signaled by P-DAO 1. The outer header has source C, 1359 destination D, an SRH that indicates E as the next loose hop, and 1360 a RPI indicating a TrackId of 131 from C's namespace. E 1361 decapsulates. 1363 3.6. Complex Tracks 1365 To increase the reliability of the P2P transmission, this 1366 specification enables to build a collection of Legs between the same 1367 Ingress and Egress Nodes and combine them with the same TrackID, as 1368 shown in Figure 7. Legs may cross at the edges of loose hops or 1369 remain parallel. 1371 The Segments that join the loose hops of a Leg are installed with the 1372 same TrackID as the Leg. But each individual Leg and Segment has its 1373 own P-RouteID which allows it to be managed separately. When Legs 1374 cross within respective Segment, the next loose hop (the current 1375 destination of the packet) indicates which Leg is being followed and 1376 a Segment that can reach that next loose hop is selected. 1378 CPF CPF CPF CPF 1380 Southbound API 1382 _-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._- 1383 _-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._- 1385 +----------+ 1386 | RPL Root | 1387 +----------+ 1388 ( ) 1389 ( ) 1390 ( DODAG ) 1391 ( ) 1392 ( ) 1393 ) 1394 <- Leg 1 B, E -> 1395 <--- Segment 1 A,B ---> <------- Segment 2 C,D,E -------> 1397 FWD --z Relay --z FWD --z FWD Target 1 1398 z-- Node z-- Node z-- Node z-- Node --z / 1399 --z (A) (B) \ (C) (D) z-- / 1400 Track \ Track 1401 Ingress Segment 5 Egress - Tgt 2 1402 (I) \ (E) 1403 --z \ z-- \ 1404 z-- FWD --z FWD --z Relay --z FWD --z \ 1405 Node z-- Node z-- Node z-- Node Target 3 1406 (F) (G) (H) (J) 1408 <------ Segment 3 F,G,H ------> <---- Segment 4 J,E ----> 1409 <- Leg 2 H, E -> 1411 <--- Segment 1 A,B ---> <- S5-> <---- Segment 4 J,E ----> 1412 <- Leg 3 B, H, E -> 1413 ) 1414 ( 1415 ( ) 1417 Figure 7: Segments and Tracks 1419 Note that while this specification enables to build both Segments 1420 inside a Leg (aka East-West), such as Segment 2 above which is within 1421 Leg 1, and Inter-Leg Segments (aka North-South), such as Segment 2 1422 above which joins Leg 1 and Leg 2, it does not signal to the Ingress 1423 which Inter-Leg Segments are available, so the use of North-South 1424 Segments and associated PAREO functions is curently limited. The 1425 only possibility available at this time is to define overlapping Legs 1426 as illustrated in Figure 7, with Leg 3 that is congruent with Leg 1 1427 till node B and congruent with Leg 2 from node H on, abstracting 1428 Segment 5 as an East-West Segment. 1430 3.7. Scope and Expectations 1432 3.7.1. External Dependencies 1434 This specification expects that the RPL Main DODAG is operated in RPL 1435 Non-Storing Mode to sustain the exchanges with the Root. Based on 1436 its comprehensive knowledge of the parent-child relationship, the 1437 Root can form an abstracted view of the whole DODAG topology. This 1438 document adds the capability for nodes to advertise additional 1439 sibling information to complement the topological awareness of the 1440 Root to be passed on to the PCE, and enable the PCE to build more / 1441 better paths that traverse those siblings. 1443 P-Routes require resources such as routing table space in the routers 1444 and bandwidth on the links; the amount of state that is installed in 1445 each node must be computed to fit within the node's memory, and the 1446 amount of rerouted traffic must fit within the capabilities of the 1447 transmission links. The methods used to learn the node capabilities 1448 and the resources that are available in the devices and in the 1449 network are out of scope for this document. The method to capture 1450 and report the LLN link capacity and reliability statistics are also 1451 out of scope. They may be fetched from the nodes through network 1452 management functions or other forms of telemetry such as OAM. 1454 3.7.2. Positioning vs. Related IETF Standards 1456 3.7.2.1. Extending 6TiSCH 1458 The "6TiSCH Architecture" [RFC9030] leverages a centralized model 1459 that is similar to that of "Deterministic Networking Architecture" 1460 [RFC8655], whereby the device resources and capabilities are exposed 1461 to an external controller which installs routing states into the 1462 network based on its own objective functions that reside in that 1463 external entity. 1465 3.7.2.2. Mapping to DetNet 1467 DetNet Forwarding Nodes only understand the simple 1-to-1 forwarding 1468 sublayer transport operation along a segment whereas the more 1469 sophisticated Relay nodes can also provide service sublayer functions 1470 such as Replication and Elimination. 1472 One possible mapping between DetNet and this specification is to 1473 signal the Relay Nodes as the hops of a Leg and the forwarding Nodes 1474 as the hops in a Segment that join the Relay nodes as illustrated in 1475 Figure 7. 1477 3.7.2.3. Leveraging PCE 1479 With DetNet and 6TiSCH, the component of the controller that is 1480 responsible of computing routes is a PCE. The PCE computes its 1481 routes based on its own objective functions such as described in 1482 [RFC4655], and typically controls the routes using the PCE Protocol 1483 (PCEP) by [RFC5440]. While this specification expects a PCE and 1484 while PCEP might effectively be used between the Root and the PCE, 1485 the control protocol between the PCE and the Root is out of scope. 1487 This specification also expects a single PCE with a full view of the 1488 network. Distributing the PCE function for a large network is out of 1489 scope. This specification uses the RPL Root as a proxy to the PCE. 1490 The PCE may be collocated with the Root, or may reside in an external 1491 Controller. In that case, the protocol between the Root and the PCE 1492 is out of scope and abstracted by / mapped to RPL inside the DODAG; 1493 one possibility is for the Root to transmit the RPL DAOs with the 1494 SIOs that detail the parent/child and sibling information. 1496 The algorithm to compute the paths and the protocol used by the PCE 1497 and the metrics and link statistics involved in the computation are 1498 also out of scope. The effectiveness of the route computation by the 1499 PCE depends on the quality of the metrics that are reported from the 1500 RPL network. Which metrics are used and how they are reported is out 1501 of scope, but the expectation is that they are mostly of long-term, 1502 statistical nature, and provide visibility on link throughput, 1503 latency, stability and availability over relatively long periods. 1505 3.7.2.4. Providing for RAW 1507 The RAW Architecture [RAW-ARCHI] extends the definition of Track, as 1508 being composed of East-West directional segments and North-South 1509 bidirectional segments, to enable additional path diversity, using 1510 Packet ARQ, Replication, Elimination, and Overhearing (PAREO) 1511 functions over the available paths, to provide a dynamic balance 1512 between the reliability and availability requirements of the flows 1513 and the need to conserve energy and spectrum. This specification 1514 prepares for RAW by setting up the Tracks, but only forms DODAGs, 1515 which are composed of aggregated end-to-end loose source routed Legs, 1516 joined by strict routed Segments, all oriented East-West. 1518 The RAW Architecture defines a dataplane extension of the PCE called 1519 the Path Selection Engine (PSE), that adapts the use of the path 1520 redundancy within a Track to defeat the diverse causes of packet 1521 loss. The PSE controls the forwarding operation of the packets 1522 within a Track This specification can use but does not impose a PSE 1523 and does not provide the policies that wouldselect which packets are 1524 routed through which path within a Track, IOW, how the PSE may use 1525 the path redundancy within the Track. By default, the use of the 1526 available redundancy is limited to simple load balancing, and all the 1527 segments are East-West unidirectional only. 1529 A Track may be set up to reduce the load around the Root, or to 1530 enable urgent traffic to flow more directly. This specification does 1531 not provide the policies that would decide which flows are routed 1532 through which Track. In a Non-Storing Mode RPL Instance, the Main 1533 DODAG provides a default route via the Root, and the Tracks provide 1534 more specific routes to the Track Targets. 1536 4. Extending existing RFCs 1538 This section explains which changes are extensions to existing 1539 specifications, and which changes are amendments to existing 1540 specification. It is expected that extensions to existing 1541 specifications do not cause existing code on legacy 6LRs to 1542 malfunction, as the extensions will simply be ignored. New code is 1543 required for an extension. Those 6LRs will be unable to participate 1544 in the new mechanisms, but may also cause projected DAOs to be 1545 impossible to install. Amendments to existing specifications are 1546 situations where there are semantic changes required to existing 1547 code, and which may require new unit tests to confirm that legacy 1548 operations will continue unaffected. 1550 4.1. Extending RFC 6550 1552 This specification Extends RPL [RPL] to enable the Root to install 1553 East-West routes inside a Main DODAG that is operated as Non-Storing 1554 Mode. The Root issues a Projected DAO (P-DAO) message (see 1555 Section 4.1.1) to the Track Ingress; the P-DAO message contains a new 1556 Via Information Option (VIO) that installs a strict or a loose 1557 sequence of hops to form respectively a Track Segment or a Track Leg. 1559 The new P-DAO Request (PDR) is a new message detailed in Section 5.1. 1560 As per [RPL] section 6, if a node receives this message and it does 1561 not understand this new Code, then discards the message. When the 1562 root initiates to a node that it has not communicated with before, 1563 and to which it does not know if this specification has been 1564 implemented (by means such as capabilities), then the root SHOULD 1565 request a PDR-ACK. 1567 A P-DAO Request (PDR) message enables a Track Ingress to request the 1568 Track from the Root. The resulting Track is also a DODAG for which 1569 the Track Ingress is the Root, the owner the address that serves as 1570 DODAGID and authoritative for the associated namespace from which the 1571 TrackID is selected. In the context of this specification, the 1572 installed route appears as a more specific route to the Track 1573 Targets, and the Track Ingress routes the packets towards the Targets 1574 via the Track using the longest match as usual. 1576 To ensure that the PDR and P-DAO messages can flow at most times, it 1577 is RECOMMENDED that the nodes involved in a Track maintain multiple 1578 parents in the Main DODAG, advertise them all to the Root, and use 1579 them in turn to retry similar packets. It is also RECOMMENDED that 1580 the Root uses diverse source route paths to retry similar messages to 1581 the nodes in the Track. 1583 4.1.1. Projected DAO 1585 Section 6 of [RPL] introduces the RPL Control Message Options (CMO), 1586 including the RPL Target Option (RTO) and Transit Information Option 1587 (TIO), which can be placed in RPL messages such as the destination 1588 Advertisement Object (DAO). A DAO message signals routing 1589 information to one or more Targets indicated in RTOs, providing one 1590 hop information at a time in the TIO. 1592 This document Amends the specification of the DAO to create the P-DAO 1593 message. This Amended DAO is signaled with a new "Projected DAO" (P) 1594 flag, see Figure 8. 1596 A Projected DAO (P-DAO) is a special DAO message generated by the 1597 Root to install a P-Route formed of multiple hops in its DODAG. This 1598 provides a RPL-based method to install the Tracks as expected by the 1599 6TiSCH Architecture [RFC9030] as a collection of multiple P-Routes. 1601 The Root MUST source the P-DAO message with its address that serves 1602 as DODAGID for the main DODAG. The receiver MUST NOT accept a P-DAO 1603 message that is not sent by the Root of its DODAG and MUST ignore 1604 such message silently. 1606 The 'P' flag is encoded in bit position 2 (to be confirmed by IANA) 1607 of the Flags field in the DAO Base Object. The Root MUST set it to 1 1608 in a Projected DAO message. Otherwise it MUST be set to 0. It is 1609 set to 0 in Legacy implementations as specified respectively in 1610 Sections 20.11 and 6.4 of [RPL]. 1612 The P-DAO is control plane signaling and should not be stuck behind 1613 high traffic levels. The expectation is that the P-DAO message is 1614 sent as high QoS level, above that of data traffic, typically with 1615 the Network Control precedence. 1617 0 1 2 3 1618 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 1619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1620 | TrackID |K|D|P| Flags | Reserved | DAOSequence | 1621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1622 | | 1623 + + 1624 | DODAGID field set to the | 1625 + IPv6 Address of the Track Ingress + 1626 | used to source encapsulated packets | 1627 + + 1628 | | 1629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1630 | Option(s)... 1631 +-+-+-+-+-+-+-+-+ 1633 Figure 8: Projected DAO Base Object 1635 New fields: 1637 TrackID: The local or global RPLInstanceID of the DODAG that serves 1638 as Track, more in Section 6.3 1640 P: 1-bit flag (position to be confirmed by IANA). 1642 The 'P' flag is set to 1 by the Root to signal a Projected DAO, 1643 and it is set to 0 otherwise. 1645 The D flag is set to one to signal that the DODAGID field is present. 1646 It may be set to zero if and only if the destination address of the 1647 P-DAO-ACK message is set to the IPv6 address that serves as DODAGID 1648 and it MUST be set to one otherwise, meaning that the DODAGID field 1649 MUST then be present. 1651 In RPL Non-Storing Mode, the TIO and RTO are combined in a DAO 1652 message to inform the DODAG Root of all the edges in the DODAG, which 1653 are formed by the directed parent-child relationships. The DAO 1654 message signals to the Root that a given parent can be used to reach 1655 a given child. The P-DAO message generalizes the DAO to signal to 1656 the Track Ingress that a Track for which it is Root can be used to 1657 reach children and siblings of the Track Egress. In both cases, 1658 options may be factorized and multiple RTOs may be present to signal 1659 a collection of children that can be reached through the parent or 1660 the Track, respectively. 1662 4.1.2. Projected DAO-ACK 1664 This document also Amends the DAO-ACK message. The new P flag 1665 signals the projected form. 1667 The format of the P-DAO-ACK message is thus as illustrated in 1668 Figure 9: 1670 0 1 2 3 1671 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 1672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1673 | TrackID |D|P| Reserved | DAOSequence | Status | 1674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1675 | | 1676 + + 1677 | DODAGID field set to the | 1678 + IPv6 Address of the Track Ingress + 1679 | used to source encapsulated packets | 1680 + + 1681 | | 1682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1683 | Option(s)... 1684 +-+-+-+-+-+-+-+-+ 1686 Figure 9: Projected DAO-ACK Base Object 1688 New fields: 1690 TrackID: The local or global RPLInstanceID of the DODAG that serves 1691 as Track, more in Section 6.3 1693 P: 1-bit flag (position to be confirmed by IANA). 1695 The 'P' flag is set to 1 by the Root to signal a Projected DAO, 1696 and it is set to 0 otherwise. 1698 The D flag is set to one to signal that the DODAGID field is present. 1699 It may be set to zero if and only if the source address of the P-DAO- 1700 ACK message is set to the IPv6 address that serves as DODAGID and it 1701 MUST be set to one otherwise, meaning that the DODAGID field MUST 1702 then be present. 1704 4.1.3. Via Information Option 1706 This document Extends the CMO to create new objects called the Via 1707 Information Options (VIO). The VIOs are the multihop alternative to 1708 the TIO, more in Section 5.3. One VIO is the stateful Storing Mode 1709 VIO (SM-VIO); an SM-VIO installs a strict hop-by-hop P-Route called a 1710 Track Segment. The other is the Non-Storing Mode VIO (NSM-VIO); the 1711 NSM-VIO installs a loose source-routed P-Route called a Track Leg at 1712 the Track Ingress, which uses that state to encapsulate a packet 1713 IPv6_in_IPv6 with a new Routing Header (RH) to the Track Egress, more 1714 in Section 6.7. 1716 A P-DAO contains one or more RTOs to indicate the Target 1717 (destinations) that can be reached via the P-Route, followed by 1718 exactly one VIO that signals the sequence of nodes to be followed, 1719 more in Section 6. There are two modes of operation for the 1720 P-Routes, the Storing Mode and the Non-Storing Mode, see 1721 Section 6.4.2 and Section 6.4.3 respectively for more. 1723 4.1.4. Sibling Information Option 1725 This specification Extends the CMO to create the Sibling Information 1726 Option (SIO). The SIO is used by a RPL Aware Node (RAN) to advertise 1727 a selection of its candidate neighbors as siblings to the Root, more 1728 in Section 5.4. The SIO is placed in DAO messages that are sent 1729 directly to the Root of the main DODAG. 1731 4.1.5. P-DAO Request 1733 The set of RPL Control Messages is Extended to include the P-DAO 1734 Request (PDR) and P-DAO Request Acknowledgement (PDR-ACK). These two 1735 new RPL Control Messages enable an RPL-Aware Node to request the 1736 establishment of a Track between itself as the Track Ingress Node and 1737 a Track Egress. The node makes its request by sending a new P-DAO 1738 Request (PDR) Message to the Root. The Root confirms with a new PDR- 1739 ACK message back to the requester RAN, see Section 5.1 for more. 1741 4.1.6. Amending the RPI 1743 Sending a Packet within a RPL Local Instance requires the presence of 1744 the abstract RPL Packet Information (RPI) described in section 11.2. 1745 of [RPL] in the outer IPv6 Header chain (see [RFC9008]). The RPI 1746 carries a local RPLInstanceID which, in association with either the 1747 source or the destination address in the IPv6 Header, indicates the 1748 RPL Instance that the packet follows. 1750 This specification Amends [RPL] to create a new flag that signals 1751 that a packet is forwarded along a P-Route. 1753 Projected-Route 'P': 1-bit flag. It is set to 1 in the RPI that is 1754 added in the encapsulation when a packet is sent over a Track. It 1755 is set to 0 when a packet is forwarded along the main Track, 1756 including when the packet follows a Segment that joins loose hops 1757 of the Main DODAG. The flag is not mutable en-route. 1759 The encoding of the 'P' flag in native format is shown in Section 4.2 1760 while the compressed format is indicated in Section 4.3. 1762 4.1.7. Additional Flag in the RPL DODAG Configuration Option 1764 The DODAG Configuration Option is defined in Section 6.7.6 of [RPL]. 1765 Its purpose is extended to distribute configuration information 1766 affecting the construction and maintenance of the DODAG, as well as 1767 operational parameters for RPL on the DODAG, through the DODAG. This 1768 Option was originally designed with 4 bit positions reserved for 1769 future use as Flags. 1771 0 1 2 3 1772 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 1773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1774 | Type = 0x04 |Opt Length = 14|D| | | |A| ... | 1775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1776 |4 bits | 1778 Figure 10: DODAG Configuration Option (Partial View) 1780 This specification Amends the specification to define a new flag 1781 "Projected Routes Support" (D). The 'D' flag is encoded in bit 1782 position 0 of the reserved Flags in the DODAG Configuration Option 1783 (this is the most significant bit)(to be confirmed by IANA but 1784 there's little choice). It is set to 0 in legacy implementations as 1785 specified respectively in Sections 20.14 and 6.7.6 of [RPL]. 1787 The 'D' flag is set to 1 to indicate that this specification is 1788 enabled in the network and that the Root will install the requested 1789 Tracks when feasible upon a PDR message. 1791 Section 4.1.2. of [RFC9008] updates [RPL] to indicate that the 1792 definition of the Flags applies to Mode of Operation values from zero 1793 (0) to six (6) only. For a MOP value of 7, the implementation MUST 1794 consider that the Root accepts PDR messages and will install 1795 Projected Routes. 1797 The RPL DODAG Configuration option is typically placed in a DODAG 1798 Information Object (DIO) message. The DIO message propagates down 1799 the DODAG to form and then maintain its structure. The DODAG 1800 Configuration option is copied unmodified from parents to children. 1802 [RPL] states that: 1804 | Nodes other than the DODAG root MUST NOT modify this information 1805 | when propagating the DODAG Configuration option. 1807 Therefore, a legacy parent propagates the 'D' flag as set by the 1808 root, and when the 'D' flag is set to 1, it is transparently flooded 1809 to all the nodes in the DODAG. 1811 4.2. Extending RFC 6553 1813 "The RPL Option for Carrying RPL Information in Data-Plane Datagrams" 1814 [RFC6553]describes the RPL Option for use among RPL routers to 1815 include the abstract RPL Packet Information (RPI) described in 1816 section 11.2. of [RPL] in data packets. 1818 The RPL Option is commonly referred to as the RPI though the RPI is 1819 really the abstract information that is transported in the RPL 1820 Option. [RFC9008] updated the Option Type from 0x63 to 0x23. 1822 This specification Amends the RPL Option to encode the 'P' flag as 1823 follows: 1825 0 1 2 3 1826 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 1827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1828 | Option Type | Opt Data Len | 1829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1830 |O|R|F|P|0|0|0|0| RPLInstanceID | SenderRank | 1831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1832 | (sub-TLVs) | 1833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1834 Figure 11: Amended RPL Option Format 1836 Option Type: 0x23 or 0x63, see [RFC9008] 1838 Opt Data Len: See [RFC6553] 1840 'O', 'R' and 'F' flags: See [RFC6553]. Those flags MUST be set to 0 1841 by the sender and ignored by the receiver if the 'P' flag is set. 1843 Projected-Route 'P': 1-bit flag as defined in Section 4.1.6. 1845 RPLInstanceID: See [RFC6553]. Indicates the TrackId if the 'P' flag 1846 is set, as discussed in Section 4.1.1. 1848 SenderRank: See [RFC6553]. This field MUST be set to 0 by the 1849 sender and ignored by the receiver if the 'P'flag is set. 1851 4.3. Extending RFC 8138 1853 The 6LoWPAN Routing Header [RFC8138] specification introduces a new 1854 IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) 1855 [RFC6282] dispatch type for use in 6LoWPAN route-over topologies, 1856 which initially covers the needs of RPL data packet compression. 1858 Section 4 of [RFC8138] presents the generic formats of the 6LoWPAN 1859 Routing Header (6LoRH) with two forms, one Elective that can be 1860 ignored and skipped when the router does not understand it, and one 1861 Critical which causes the packet to be dropped when the router cannot 1862 process it. The 'E' Flag in the 6LoRH indicates its form. In order 1863 to skip the Elective 6LoRHs, their format imposes a fixed expression 1864 of the size, whereas the size of a Critical 6LoRH may be signaled in 1865 variable forms to enable additional optimizations. 1867 When the [RFC8138] compression is used, the Root of the Main DODAG 1868 that sets up the Track also constructs the compressed routing header 1869 (SRH-6LoRH) on behalf of the Track Ingress, which saves the 1870 complexities of optimizing the SRH-6LoRH encoding in constrained 1871 code. The SRH-6LoRH is signaled in the NSM-VIO, in a fashion that it 1872 is ready to be placed as is in the packet encapsulation by the Track 1873 Ingress. 1875 Section 6.3 of [RFC8138] presents the formats of the 6LoWPAN Routing 1876 Header of type 5 (RPI-6LoRH) that compresses the RPI for normal RPL 1877 operation. The format of the RPI-6LoRH is not suited for P-Routes 1878 since the O,R,F flags are not used and the Rank is unknown and 1879 ignored. 1881 This specification extends [RFC8138] to introduce a new 6LoRH, the P- 1882 RPI-6LoRH that can be used in either Elective or Critical 6LoRH form, 1883 see Table 22 and Table 23 respectively. The new 6LoRH MUST be used 1884 as a Critical 6LoRH, unless an SRH-6LoRH is present and controls the 1885 routing decision, in which case it MAY be used in Elective form. 1887 The P-RPI-6LoRH is designed to compress the RPI along RPL P-Routes. 1888 Its format is as follows: 1890 0 1 2 1891 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1893 |1|0|E| Length | 6LoRH Type | RPLInstanceID | 1894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1896 Figure 12: P-RPI-6LoRH Format 1898 Type: IANA is requested to define the same value of the type for 1899 both Elective and Critical forms. A type of 8 is suggested. 1901 Elective 'E': See [RFC8138]. The 'E' flag is set to 1 to indicate 1902 an Elective 6LoRH, meaning that it can be ignored when forwarding. 1904 RPLInstanceID : In the context of this specification, the 1905 RPLInstanceID field signals the TrackID, see Section 3.4 and 1906 Section 6.3 . 1908 Section 6.8 details how a a Track Ingress leverages the P-RPI-6LoRH 1909 Header as part of the encapsulation of a packet to place it into a 1910 Track. 1912 5. New RPL Control Messages and Options 1914 5.1. New P-DAO Request Control Message 1916 The P-DAO Request (PDR) message is sent by a Node in the Main DODAG 1917 to the Root. It is a request to establish or refresh a Track where 1918 this node is Track Ingress, and signals whether an acknowledgment 1919 called PDR-ACK is requested or not. A positive PDR-ACK indicates 1920 that the Track was built and that the Roots commits to maintain the 1921 Track for the negotiated lifetime. 1923 The main Root MAY indicate to the Track Ingress that the Track was 1924 terminated before its time and to do so, it MUST uses an asynchronous 1925 PDR-ACK with an negative status. A status of "Transient Failure" 1926 (see Section 11.10) is an indication that the PDR may be retried 1927 after a reasonable time that depends on the deployment. Other 1928 negative status values indicate a permanent error; the tentative must 1929 be abandoned until a corrective action is taken at the application 1930 layer or through network management. 1932 The source IPv6 address of the PDR signals the Track Ingress to-be of 1933 the requested Track, and the TrackID is indicated in the message 1934 itself. At least one RPL Target Option MUST be present in the 1935 message. If more than one RPL Target Option is present, the Root 1936 will provide a Track that reaches the first listed Target and a 1937 subset of the other Targets; the details of the subset selection are 1938 out of scope. The RTO signals the Track Egress, more in Section 6.2. 1940 The RPL Control Code for the PDR is 0x09, to be confirmed by IANA. 1941 The format of PDR Base Object is as follows: 1943 0 1 2 3 1944 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 1945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1946 | TrackID |K|R| Flags | ReqLifetime | PDRSequence | 1947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1948 | Option(s)... 1949 +-+-+-+-+-+-+-+-+ 1951 Figure 13: New P-DAO Request Format 1953 TrackID: 8-bit field. In the context of this specification, the 1954 TrackID field signals the RPLInstanceID of the DODAG formed by the 1955 Track, see Section 3.4 and Section 6.3. To allocate a new Track, 1956 the Ingress Node must provide a value that is not in use at this 1957 time. 1959 K: The 'K' flag is set to indicate that the recipient is expected to 1960 send a PDR-ACK back. 1962 R: The 'R' flag is set to request a Complex Track for redundancy. 1964 Flags: Reserved. The Flags field MUST initialized to zero by the 1965 sender and MUST be ignored by the receiver 1967 ReqLifetime: 8-bit unsigned integer. The requested lifetime for the 1968 Track expressed in Lifetime Units (obtained from the DODAG 1969 Configuration option). 1971 A PDR with a fresher PDRSequence refreshes the lifetime, and a 1972 PDRLifetime of 0 indicates that the Track should be destroyed, 1973 e.g., when the application that requested the Track terminates. 1975 PDRSequence: 8-bit wrapping sequence number, obeying the operation 1976 in section 7.2 of [RPL]. The PDRSequence is used to correlate a 1977 PDR-ACK message with the PDR message that triggered it. It is 1978 incremented at each PDR message and echoed in the PDR-ACK by the 1979 Root. 1981 5.2. New PDR-ACK Control Message 1983 The new PDR-ACK is sent as a response to a PDR message with the 'K' 1984 flag set. The RPL Control Code for the PDR-ACK is 0x0A, to be 1985 confirmed by IANA. Its format is as follows: 1987 0 1 2 3 1988 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 1989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1990 | TrackID | Flags | Track Lifetime| PDRSequence | 1991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1992 | PDR-ACK Status| Reserved | 1993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1994 | Option(s)... 1995 +-+-+-+-+-+-+-+ 1997 Figure 14: New PDR-ACK Control Message Format 1999 TrackID: Set to the TrackID indicated in the TrackID field of the 2000 PDR messages that this replies to. 2002 Flags: Reserved. The Flags field MUST initialized to zero by the 2003 sender and MUST be ignored by the receiver 2005 Track Lifetime: Indicates that remaining Lifetime for the Track, 2006 expressed in Lifetime Units; the value of zero (0x00) indicates 2007 that the Track was destroyed or not created. 2009 PDRSequence: 8-bit wrapping sequence number. It is incremented at 2010 each PDR message and echoed in the PDR-ACK. 2012 PDR-ACK Status: 8-bit field indicating the completion. The PDR-ACK 2013 Status is substructured as indicated in Figure 15: 2015 0 1 2 3 4 5 6 7 2016 +-+-+-+-+-+-+-+-+ 2017 |E|R| Value | 2018 +-+-+-+-+-+-+-+-+ 2020 Figure 15: PDR-ACK status Format 2022 E: 1-bit flag. Set to indicate a rejection. When not set, the 2023 value of 0 indicates Success/Unqualified Acceptance and other 2024 values indicate "not an outright rejection". 2025 R: 1-bit flag. Reserved, MUST be set to 0 by the sender and 2026 ignored by the receiver. 2027 Status Value: 6-bit unsigned integer. Values depending on the 2028 setting of the 'E' flag, see Table 28 and Table 29. 2030 Reserved: The Reserved field MUST initialized to zero by the sender 2031 and MUST be ignored by the receiver 2033 5.3. Via Information Options 2035 A VIO signals the ordered list of IPv6 Via Addresses that constitutes 2036 the hops of either a Leg (using Non-Storing Mode) a Segment (using 2037 storing mode) of a Track. A Storing Mode P-DAO contains one Storing 2038 Mode VIO (SM-VIO) whereas a Non-Storing Mode P-DAO contains one Non- 2039 Storing Mode VIO (NSM-VIO) 2041 The duration of the validity of a VIO is indicated in a Segment 2042 Lifetime field. A P-DAO message that contains a VIO with a Segment 2043 Lifetime of zero is referred as a No-Path P-DAO. 2045 The VIO contains one or more SRH-6LoRH header(s), each formed of a 2046 SRH-6LoRH head and a collection of compressed Via Addresses, except 2047 in the case of a Non-Storing Mode No-Path P-DAO where the SRH-6LoRH 2048 header is not present. 2050 In the case of a SM-VIO, or if [RFC8138] is not used in the data 2051 packets, then the Root MUST use only one SRH-6LoRH per Via 2052 Information Option, and the compression is the same forall the 2053 addresses, as shown in Figure 16, for simplicity. 2055 In case of an NSM-VIO and if [RFC8138] is in use in the Main DODAG, 2056 the Root SHOULD optimize the size of the NSM-VIO if using different 2057 SRH-6LoRH Types make the VIO globally shorter; this means that more 2058 than one SRH-6LoRH may be present. 2060 The format of the Via Information Options is as follows: 2062 0 1 2 3 2063 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 2064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2065 | Type | Option Length | Flags | P-RouteID | 2066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2067 |Segm. Sequence | Seg. Lifetime | SRH-6LoRH head | 2068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2069 | | 2070 . Via Address 1 (compressed by RFC 8138) . 2071 | | 2072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2073 | | 2074 . .... . 2075 | | 2076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2077 | | 2078 . Via Address n (compressed by RFC 8138) . 2079 | | 2080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2081 | | 2082 . Additional SRH-6LoRH Header(s) . 2083 | | 2084 . .... . 2086 Figure 16: VIO format (uncompressed form) 2088 Option Type: 0x0E for SM-VIO, 0x0F for NSM-VIO (to be confirmed by 2089 IANA), see =Table 26 2091 Option Length: 8-bit unsigned integer, representing the length in 2092 octets of the option, not including the Option Type and Length 2093 fields, see section 6.7.1. of [RPL]; the Option Length is 2094 variable, depending on the number of Via Addresses and the 2095 compression applied. 2097 P-RouteID: 8-bit field that identifies a component of a Track or the 2098 Main DODAG as indicated by the TrackID field. The value of 0 is 2099 used to signal a Serial Track, i.e., made of a single segment/Leg. 2100 In an SM-VIO, the P-RouteID indicates an actual Segment. In an an 2101 NSM-VIO, it indicates a Leg, that is a serial subTrack that is 2102 added to the overall topology of the Track. 2104 Segment Sequence: 8-bit unsigned integer. The Segment Sequence 2105 obeys the operation in section 7.2 of [RPL] and the lollipop 2106 starts at 255. 2108 When the Root of the DODAG needs to refresh or update a Segment in 2109 a Track, it increments the Segment Sequence individually for that 2110 Segment. 2112 The Segment information indicated in the VIO deprecates any state 2113 for the Segment indicated by the P-RouteID within the indicated 2114 Track and sets up the new information. 2116 A VIO with a Segment Sequence that is not as fresh as the current 2117 one is ignored. 2119 A VIO for a given DODAGID with the same (TrackID, P-RouteID, 2120 Segment Sequence) indicates a retry; it MUST NOT change the 2121 Segment and MUST be propagated or answered as the first copy. 2123 Segment Lifetime: 8-bit unsigned integer. The length of time in 2124 Lifetime Units (obtained from the Configuration option) that the 2125 Segment is usable. 2127 The period starts when a new Segment Sequence is seen. The value 2128 of 255 (0xFF) represents infinity. The value of zero (0x00) 2129 indicates a loss of reachability. 2131 SRH-6LoRH head: The first 2 bytes of the (first) SRH-6LoRH as shown 2132 in Figure 6 of [RFC8138]. As an example, a 6LoRH Type of 4 means 2133 that the VIA Addresses are provided in full with no compression. 2135 Via Address: An IPv6 ULA or GUA of a node along the Segment. The 2136 VIO contains one or more IPv6 Via Addresses listed in the datapath 2137 order from Ingress to Egress. The list is expressed in a 2138 compressed form as signaled by the preceding SRH-6LoRH header. 2140 In a Storing Mode P-DAO that updates or removes a section of an 2141 already existing Segment, the list in the SM-VIO may represent 2142 only the section of the Segment that is being updated; at the 2143 extreme, the SM-VIO updates only one node, in which case it 2144 contains only one IPv6 address. In all other cases, the list in 2145 the VIO MUST be complete. 2147 In the case of an SM-VIO, the list indicates a sequential (strict) 2148 path through direct neighbors, the complete list starts at Ingress 2149 and ends at Egress, and the nodes listed in the VIO, including the 2150 Egress, MAY be considered as implicit Targets. 2152 In the case of an NSM-VIO, the complete list can be loose and 2153 excludes the Ingress node, starting at the first loose hop and 2154 ending at a Track Egress; the Track Egress MUST be considered as 2155 an implicit Target, so it MUST NOT be signaled in a RPL Target 2156 Option. 2158 5.4. Sibling Information Option 2160 The Sibling Information Option (SIO) provides indication on siblings 2161 that could be used by the Root to form P-Routes. One or more SIO(s) 2162 may be placed in the DAO messages that are sent to the Root in Non- 2163 Storing Mode. 2165 To advertise a neighbor node, the router MUST have an active Address 2166 Registration from that sibling using [RFC8505], for an address (ULA 2167 or GUA) that serves as identifier for the node. If this router also 2168 registers an address to that sibling, and the link has similar 2169 properties in both directions, only the router with the lowest 2170 Interface ID in its registered address needs report the SIO, with the 2171 B flag set, and the Root will assume symmetry. 2173 The SIO carries a flag (B) that is set when similar performances can 2174 be expected both directions, so the routing can consider that the 2175 information provided for one direction is valid for both. If the SIO 2176 is effectively received from both sides then the B flag MUST be 2177 ignored. The policy that describes the performance criteria, and how 2178 they are asserted is out of scope. In the absence of an external 2179 protocol to assert the link quality, the flag SHOULD NOT be set. 2181 The format of the SIO is as follows: 2183 0 1 2 3 2184 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 2185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2186 | Type | Option Length |S|B|Flags|Comp.| Opaque | 2187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2188 | Step in Rank | Reserved | 2189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2190 | | 2191 + + 2192 . . 2193 . Sibling DODAGID (if the D flag not set) . 2194 . . 2195 + + 2196 | | 2197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2198 | | 2199 + + 2200 . . 2201 . Sibling Address . 2202 . . 2203 + + 2204 | | 2205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2207 Figure 17: Sibling Information Option Format 2209 Option Type: 0x10 for SIO (to be confirmed by IANA), see =Table 26 2211 Option Length: 8-bit unsigned integer, representing the length in 2212 octets of the option, not including the Option Type and Length 2213 fields, see section 6.7.1. of [RPL]. 2215 Reserved for Flags: MUST be set to zero by the sender and MUST be 2216 ignored by the receiver. 2218 B: 1-bit flag that is set to indicate that the connectivity to the 2219 sibling is bidirectional and roughly symmetrical. In that case, 2220 only one of the siblings may report the SIO for the hop. If 'B' 2221 is not set then the SIO only indicates connectivity from the 2222 sibling to this node, and does not provide information on the hop 2223 from this node to the sibling. 2225 S: 1-bit flag that is set to indicate that sibling belongs to the 2226 same DODAG. When not set, the Sibling DODAGID is indicated. 2228 Flags: Reserved. The Flags field MUST initialized to zero by the 2229 sender and MUST be ignored by the receiver 2231 Opaque: MAY be used to carry information that the node and the Root 2232 understand, e.g., a particular representation of the Link 2233 properties such as a proprietary Link Quality Information for 2234 packets received from the sibling. An industrial Alliance that 2235 uses RPL for a particular use / environment MAY redefine the use 2236 of this field to fit its needs. 2238 Compression Type: 3-bit unsigned integer. This is the SRH-6LoRH 2239 Type as defined in figure 7 in section 5.1 of [RFC8138] that 2240 corresponds to the compression used for the Sibling Address and 2241 its DODAGID if resent. The Compression reference is the Root of 2242 the Main DODAG. 2244 Step in Rank: 16-bit unsigned integer. This is the Step in Rank 2245 [RPL] as computed by the Objective Function between this node and 2246 the sibling, that reflects the abstract Rank increment that would 2247 be computed by the OF if the sibling was the preferred parent. 2249 Reserved: The Reserved field MUST initialized to zero by the sender 2250 and MUST be ignored by the receiver 2252 Sibling DODAGID: 2 to 16 bytes, the DODAGID of the sibling in a 2253 [RFC8138] compressed form as indicated by the Compression Type 2254 field. This field is present if and only if the D flag is not 2255 set. 2257 Sibling Address: 2 to 16 bytes, an IPv6 Address of the sibling, with 2258 a scope that MUST be make it reachable from the Root, e.g., it 2259 cannot be a Link Local Address. The IPv6 address is encoded in 2260 the [RFC8138] compressed form indicated by the Compression Type 2261 field. 2263 An SIO MAY be immediately followed by a DAG Metric Container. In 2264 that case the DAG Metric Container provides additional metrics for 2265 the hop from the Sibling to this node. 2267 6. Root Initiated Routing State 2269 6.1. RPL Network Setup 2271 To avoid the need of Path MTU Discovery, 6LoWPAN links are normally 2272 defined with a MTU of 1280 (see section 4 of [6LoWPAN]). Injecting 2273 packets in a Track typically involves an IP-in-IP encapsulation and 2274 additional IPv6 Extension Headers. This may cause a fragmentation if 2275 the resulting packets exceeds the MTU that is defined for the RPL 2276 domain. 2278 Though fragmentation is possible in a 6LoWPAN LLN, e.g., using 2279 [6LoWPAN], [RFC8930], and/or [RFC8931], it is RECOMMENDED to allow an 2280 MTU that is larger than 1280 in the main DODAG and allows for the 2281 additional headers while exposing only 1280 to the 6LoWPAN Nodes. 2283 6.2. Requesting a Track 2285 This specification introduces the PDR message, used by an LLN node to 2286 request the formation of a new Track for which this node is Ingress. 2287 Note that the namespace for the TrackID is owned by the Ingress node, 2288 and in the absence of a PDR, there must be some procedure for the 2289 Root to assign TrackIDs in that namespace while avoiding collisions, 2290 more in Section 6.3. 2292 The PDR signals the desired TrackID and the duration for which the 2293 Track should be established. Upon a PDR, the Root MAY install the 2294 Track as requested, in which case it answers with a PDR-ACK 2295 indicating the granted Track Lifetime. All the Segments MUST be of a 2296 same mode, either Storing or Non-Storing. All the Segments MUST be 2297 created with the same TrackID and the same DODAGID signaled in the 2298 P-DAO. 2300 The Root designs the Track as it sees best, and updates / changes the 2301 Segments overtime to serve the Track as needed. Note that there is 2302 no protocol element to notify to the requesting Track Ingress when 2303 changes happen deeper down the Track, so they are transparent to the 2304 Track Ingress. If the main Root cannot maintain an expected service 2305 level, then it needs to tear down the Track completely. The Segment 2306 Lifetime in the P-DAO messages does not need to be aligned to the 2307 Requested Lifetime in the PDR, or between P-DAO messages for 2308 different Segments. The Root may use shorter lifetimes for the 2309 Segments and renew them faster than the Track is, or longer lifetimes 2310 in which case it will need to tear down the Segments if the Track is 2311 not renewed. 2313 When the Track Lifetime that was returned in the PDR-ACK is close to 2314 elapse - vs. the trip time from the node to the Root, the requesting 2315 node SHOULD resend a PDR using the TrackID in the PDR-ACK to extend 2316 the lifetime of the Track, else the Track will time out and the Root 2317 will tear down the whole structure. 2319 If the Track fails and cannot be restored, the Root notifies the 2320 requesting node asynchronously with a PDR-ACK with a Track Lifetime 2321 of 0, indicating that the Track has failed, and a PDR-ACK Status 2322 indicating the reason of the fault. 2324 6.3. Identifying a Track 2326 RPL defines the concept of an Instance to signal an individual 2327 routing topology, and multiple topologies can coexist in the same 2328 network. The RPLInstanceID is tagged in the RPI of every packet to 2329 signal which topology the packet actually follows. 2331 This draft leverages the RPL Instance model as follows: 2333 * The Root MAY use P-DAO messages to add better routes in the main 2334 (Global) RPL Instance in conformance with the routing objectives 2335 in that Instance. 2337 To achieve this, the Root MAY install a Segment along a path down 2338 the main Non-Storing Mode DODAG. This enables a loose source 2339 routing and reduces the size of the Routing Header, see 2340 Section 3.3.1. The Root MAY also install a Track Leg across the 2341 Main DODAG to complement the routing topology. 2343 When adding a P-Route to the RPL Main DODAG, the Root MUST set the 2344 RPLInstanceID field of the P-DAO Base Object (see section 6.4.1. 2345 of [RPL]) to the RPLInstanceID of the Main DODAG, and MUST NOT use 2346 the DODAGID field. A P-Route provides a longer match to the 2347 Target Address than the default route via the Root, so it is 2348 preferred. 2350 * The Root MAY also use P-DAO messages to install a Track as an 2351 independent routing topology (say, Traffic Engineered) to achieve 2352 particular routing characteristics from an Ingress to an Egress 2353 Endpoints. To achieve this, the Root MUST set up a local RPL 2354 Instance (see section 5 of [RPL]), and the Local RPLInstanceID 2355 serves as TrackID. The TrackID MUST be unique for the IPv6 ULA or 2356 GUA of the Track Ingress that serves as DODAGID for the Track. 2358 This way, a Track is uniquely identified by the tuple (DODAGID, 2359 TrackID) where the TrackID is always represented with the D flag 2360 set to 0 (see also section 5.1. of [RPL]), indicating when used in 2361 an RPI that the source address of the IPv6 packet signals the 2362 DODAGID. 2364 The P-DAO Base Object MUST indicate the tuple (DODAGID, TrackID) 2365 that identifies the Track as shown in Figure 8, and the P-RouteID 2366 that identifies the P-Route MUST be signaled in the VIO as shown 2367 in Figure 16. 2369 The Track Ingress is the Root of the DODAG ID formed by the local 2370 RPL Instance. It owns the namespace of its TrackIDs, so it can 2371 pick any unused value to request a new Track with a PDR. In a 2372 particular deployment where PDR are not used, a portion of the 2373 namespace can be administratively delegated to the main Root, 2374 meaning that the main Root is authoritative for assigning the 2375 TrackIDs for the Tracks it creates. 2377 With this specification, the Root is aware of all the active 2378 Tracks, so it can also pick any unused value to form Tracks 2379 without a PDR. To avoid a collision of the Root and the Track 2380 Ingress picking the same value at the same time, it is RECOMMENDED 2381 that the Track Ingress starts allocating the ID value of the Local 2382 RPLInstanceID (see section 5.1. of [RPL]) used as TrackIDs with 2383 the value 0 incrementing, while the Root starts with 63 2384 decrementing. 2386 6.4. Installing a Track 2388 A Serial Track can be installed by a single P-Route that signals the 2389 sequence of consecutive nodes, either in Storing Mode as a single- 2390 Segment Track, or in Non-Storing Mode as a single-Leg Track. A 2391 single-Leg Track can be installed as a loose Non-Storing Mode 2392 P-Route, in which case the next loose entry must recursively be 2393 reached over a Serial Track. 2395 A Complex Track can be installed as a collection of P-Routes with the 2396 same DODAGID and Track ID. The Ingress of a Non-Storing Mode P-Route 2397 is the owner and Root of the DODAGID. The Ingress of a Storing Mode 2398 P-Route must be either the owner of the DODAGID, or a hop of a Leg of 2399 the same Track. In the latter case, the Targets of the P-Route must 2400 include the next hop of the Leg if there is one, to ensure forwarding 2401 continuity. In the case of a Complex Track, each Segment is 2402 maintained independently and asynchronously by the Root, with its own 2403 lifetime that may be shorter, the same, or longer than that of the 2404 Track. 2406 A route along a Track for which the TrackID is not the RPLInstanceID 2407 of the Main DODAG MUST be installed with a higher precedence than the 2408 routes along the Main DODAG, meaning that: 2410 * Longest match MUST be the prime comparison for routing. 2412 * In case of equal length match, the route along the Track MUST be 2413 preferred vs. the one along the Main DODAG. 2415 * There SHOULD NOT be 2 different Tracks leading to the same Target 2416 from same Ingress node, unless there's a policy for selecting 2417 which packets use which Track; such policy is out of scope. 2419 * A packet that was routed along a Track MUST NOT be routed along 2420 the main DODAG again; if the destination is not reachable as a 2421 neighbor by the node where the packet exits the Track then the 2422 packet MUST be dropped. 2424 6.4.1. Signaling a Projected Route 2426 This draft adds a capability whereby the Root of a main RPL DODAG 2427 installs a Track as a collection of P-Routes, using a Projected-DAO 2428 (P-DAO) message for each individual Track Leg or Segment. The P-DAO 2429 signals a collection of Targets in the RPL Target Option(s) (RTO). 2430 Those Targets can be reached via a sequence of routers indicated in a 2431 VIO. 2433 Like a classical DAO message, a P-DAO causes a change of state only 2434 if it is "new" per section 9.2.2. "Generation of DAO Messages" of 2435 the RPL specification [RPL]; this is determined using the Segment 2436 Sequence information from the VIO as opposed to the Path Sequence 2437 from a TIO. Also, a Segment Lifetime of 0 in a VIO indicates that 2438 the P-Route associated to the Segment is to be removed. There are 2439 two Modes of operation for the P-Routes, the Storing and the Non- 2440 Storing Modes. 2442 A P-DAO message MUST be sent from the address of the Root that serves 2443 as DODAGID for the Main DODAG. It MUST contain either exactly one 2444 sequence of one or more RTOs followed one VIO, or any number of 2445 sequences of one or more RTOs followed by one or more TIOs. The 2446 former is the normal expression for this specification, where as the 2447 latter corresponds to the variation for lesser constrained 2448 environments described in Section 7.2. 2450 A P-DAO that creates or updates a Track Leg MUST be sent to a GUA or 2451 a ULA of the Ingress of the Leg; it must contain the full list of 2452 hops in the Leg unless the Leg is being removed. A P-DAO that 2453 creates a new Track Segment MUST be sent to a GUA or a ULA of the 2454 Segment Egress and MUST signal the full list of hops in Segment; a 2455 P-DAO that updates (including deletes) a section of a Segment MUST be 2456 sent to the first node after the modified Segment and signal the full 2457 list of hops in the section starting at the node that immediately 2458 precedes the modified section. 2460 In Non-Storing Mode, as discussed in Section 6.4.3, the Root sends 2461 the P-DAO to the Track Ingress where the source-routing state is 2462 applied, whereas in Storing Mode, the P-DAO is sent to the last node 2463 on the installed path and forwarded in the reverse direction, 2464 installing a Storing Mode state at each hop, as discussed in 2465 Section 6.4.2. In both cases the Track Ingress is the owner of the 2466 Track, and it generates the P-DAO-ACK when the installation is 2467 successful. 2469 If the 'K' Flag is present in the P-DAO, the P-DAO must be 2470 acknowledged using a DAO-ACK that is sent back to the address of the 2471 Root from which the P-DAO was received. In most cases, the first 2472 node of the Leg, Segment, or updated section of the Segment is the 2473 node that sends the acknowledgment. The exception to the rule is 2474 when an intermediate node in a Segment fails to forward a Storing 2475 Mode P-DAO to the previous node in the SM-VIO. 2477 In a No-Path Non-Storing Mode P-DAO, the SRH-6LoRH MUST NOT be 2478 present in the NSM-VIO; the state in the Ingress is erased 2479 regardless. In all other cases, a VIO MUST contain at least one Via 2480 Address, and a Via Address MUST NOT be present more than once, which 2481 would create a loop. 2483 A node that processes a VIO MAY verify whether one of these 2484 conditions happen, and when so, it MUST ignore the P-DAO and reject 2485 it with a RPL Rejection Status of "Error in VIO" in the DAO-ACK, see 2486 Section 11.16. 2488 Other errors than those discussed explicitely that prevent the 2489 installing the route are acknowledged with a RPL Rejection Status of 2490 "Unqualified Rejection" in the DAO-ACK. 2492 6.4.2. Installing a Track Segment with a Storing Mode P-Route 2494 As illustrated in Figure 18, a Storing Mode P-DAO installs a route 2495 along the Segment signaled by the SM-VIO towards the Targets 2496 indicated in the Target Options. The Segment is to be included in a 2497 DODAG indicated by the P-DAO Base Object, that may be the one formed 2498 by the RPL Main DODAG, or a Track associated with a local RPL 2499 Instance. 2501 ------+--------- 2502 | Internet 2503 | 2504 +-----+ 2505 | | Border router 2506 | | (RPL Root) 2507 +-----+ | ^ | 2508 | | DAO | ACK | 2509 o o o o | | | 2510 o o o o o o o o o | ^ | Projected . 2511 o o o o o o o o o o | | DAO | Route . 2512 o o o o o o o o o | ^ | . 2513 o o o o o o o o v | DAO v . 2514 o o LLN o o o | 2515 o o o o o Loose Source Route Path | 2516 o o o o v 2518 Figure 18: Projecting a route 2520 In order to install the relevant routing state along the Segment , 2521 the Root sends a unicast P-DAO message to the Track Egress router of 2522 the routing Segment that is being installed. The P-DAO message 2523 contains a SM-VIO with the strict sequence of Via Addresses. The SM- 2524 VIO follows one or more RTOs indicating the Targets to which the 2525 Track leads. The SM-VIO contains a Segment Lifetime for which the 2526 state is to be maintained. 2528 The Root sends the P-DAO directly to the Egress node of the Segment. 2529 In that P-DAO, the destination IP address matches the last Via 2530 Address in the SM-VIO. This is how the Egress recognizes its role. 2531 In a similar fashion, the Segment Ingress node recognizes its role as 2532 it matches first Via Address in the SM-VIO. 2534 The Egress node of the Segment is the only node in the path that does 2535 not install a route in response to the P-DAO; it is expected to be 2536 already able to route to the Target(s) based on its existing tables. 2537 If one of the Targets is not known, the node MUST answer to the Root 2538 with a DAO-ACK listing the unreachable Target(s) in an RTO and a 2539 rejection status of "Unreachable Target". 2541 If the Egress node can reach all the Targets, then it forwards the 2542 P-DAO with unchanged content to its predecessor in the Segment as 2543 indicated in the list of Via Information options, and recursively the 2544 message is propagated unchanged along the sequence of routers 2545 indicated in the P-DAO, but in the reverse order, from Egress to 2546 Ingress. 2548 The address of the predecessor to be used as destination of the 2549 propagated DAO message is found in the Via Address the precedes the 2550 one that contain the address of the propagating node, which is used 2551 as source of the message. 2553 Upon receiving a propagated DAO, all except the Egress router MUST 2554 install a route towards the DAO Target(s) via their successor in the 2555 SM-VIO. A router that cannot store the routes to all the Targets in 2556 a P-DAO MUST reject the P-DAO by sending a DAO-ACK to the Root with a 2557 Rejection Status of "Out of Resources" as opposed to forwarding the 2558 DAO to its predecessor in the list. The router MAY install 2559 additional routes towards the VIA Addresses that are the SM-VIO after 2560 self, if any, but in case of a conflict or a lack of resource, the 2561 route(s) to the Target(s) are the ones that must be installed in 2562 priority. 2564 If a router cannot reach its predecessor in the SM-VIO, the router 2565 MUST send the DAO-ACK to the Root with a Rejection Status of 2566 "Predecessor Unreachable". 2568 The process continues till the P-DAO is propagated to Ingress router 2569 of the Segment, which answers with a DAO-ACK to the Root. The Root 2570 always expects a DAO-ACK, either from the Track Ingress with a 2571 positive status or from any node along the segment with a negative 2572 status. If the DAO-ACK is not received, the Root may retry the DAO 2573 with the same TID, or tear down the route. 2575 6.4.3. Installing a Track Leg with a Non-Storing Mode P-Route 2577 As illustrated in Figure 19, a Non-Storing Mode P-DAO installs a 2578 source-routed path within the Track indicated by the P-DAO Base 2579 Object, towards the Targets indicated in the Target Options. The 2580 source-routed path requires a Source-Routing header which implies an 2581 IP-in-IP encapsulation to add the SRH to an existing packet. It is 2582 sent to the Track Ingress which creates a tunnel associated with the 2583 Track, and connected routes over the tunnel to the Targets in the 2584 RTO. The tunnel encapsulation MUST incorporate a routing header via 2585 the list addresses listed in the VIO in the same order. The content 2586 of the NSM-VIO starting at the first SRH-6LoRH header MUST be used 2587 verbatim by the Track Ingress when it encapsulates a packet to 2588 forward it over the Track. 2590 ------+--------- 2591 | Internet 2592 | 2593 +-----+ 2594 | | Border router 2595 | | (RPL Root) 2596 +-----+ | P ^ ACK 2597 | Track | DAO | 2598 o o o o Ingress X V | X 2599 o o o o o o o X o X Source 2600 o o o o o o o o X o o X Routed 2601 o o ° o o o o X o X Segment 2602 o o o o o o o o X Egress X 2603 o o o o o | 2604 Target 2605 o o LLN o o 2606 o o o o 2608 Figure 19: Projecting a Non-Storing Route 2610 The next entry in the source-routed path must be either a neighbor of 2611 the previous entry, or reachable as a Target via another P-Route, 2612 either Storing or Non-Storing, which implies that the nested P-Route 2613 has to be installed before the loose sequence is, and that P-Routes 2614 must be installed from the last to the first along the datapath. For 2615 instance, a Segment of a Track must be installed before the Leg(s) of 2616 the same Track that use it, and stitched Segments must be installed 2617 in order from the last that reaches to the Targets to the first. 2619 If the next entry in the loose sequence is reachable over a Storing 2620 Mode P-Route, it MUST be the Target of a Segment and the Ingress of a 2621 next segment, both already setup; the segments are associated with 2622 the same Track, which avoids the need of an additional encapsulation. 2623 For instance, in Section 3.5.1.3, Segments A==>B-to-C and 2624 C==>D==>E-to-F must be installed with Storing Mode P-DAO messages 1 2625 and 2 before the Track A-->C-->E-to-F that joins them can be 2626 installed with Non-Storing Mode P-DAO 3. 2628 Conversely, if it is reachable over a Non-Storing Mode P-Route, the 2629 next loose source-routed hop of the inner Track is a Target of a 2630 previously installed Track and the Ingress of a next Track, which 2631 requires a de- and a re-encapsulation when switching the outer Tracks 2632 that join the loose hops. This is examplified in Section 3.5.2.3 2633 where Non-Storing Mode P-DAO 1 and 2 install strict Tracks that Non- 2634 Storing Mode P-DAO 3 joins as a super Track. In such a case, packets 2635 are subject to double IP-in-IP encapsulation. 2637 6.5. Tearing Down a P-Route 2639 A P-DAO with a lifetime of 0 is interpreted as a No-Path DAO and 2640 results in cleaning up existing state as opposed to refreshing an 2641 existing one or installing a new one. To tear down a Track, the Root 2642 must tear down all the Track Segments and Legs that compose it one by 2643 one. 2645 Since the state about a Leg of a Track is located only on the Ingress 2646 Node, the Root cleans up the Leg by sending an NSM-VIO to the Ingress 2647 indicating the TrackID and the P-RouteID of the Leg being removed, a 2648 Segment Lifetime of 0 and a newer Segment Sequence. The SRH-6LoRH 2649 with the Via Addresses in the NSM-VIO are not needed; it SHOULD not 2650 be placed in the message and MUST be ignored by the receiver. Upon 2651 that NSM-VIO, the Ingress node removes all state for that Track if 2652 any, and replies positively anyway. 2654 The Root cleans up a section of a Segment by sending an SM-VIO to the 2655 last node of the Segment, with the TrackID and the P-RouteID of the 2656 Segment being updated, a Segment Lifetime of zero (0) and a newer 2657 Segment Sequence. The Via Addresses in the SM-VIO indicates the 2658 section of the Segment being modified, from the first to the last 2659 node that is impacted. This can be the whole Segment if it is 2660 totally removed, or a sequence of one or more nodes that have been 2661 bypassed by a Segment update. 2663 The No-Path P-DAO is forwarded normally along the reverse list, even 2664 if the intermediate node does not find a Segment state to clean up. 2665 This results in cleaning up the existing Segment state if any, as 2666 opposed to refreshing an existing one or installing a new one. 2668 6.6. Maintaining a Track 2670 Repathing a Track Segment or Leg may cause jitter and packet 2671 misordering. For critical flows that require timely and/or in-order 2672 delivery, it might be necessary to deploy the PAREO functions 2673 [RAW-ARCHI] over a highly redundant Track. This specification allows 2674 to use more than one Leg for a Track, and 1+N packet redundancy. 2676 This section provides the steps to ensure that no packet is lost due 2677 to the operation itself. This is ensured by installing the new 2678 section from its last node to the first, so when an intermediate node 2679 installs a route along the new section, all the downstream nodes in 2680 the section have already installed their own. The disabled section 2681 is removed when the packets in-flight are forwarded along the new 2682 section as well. 2684 6.6.1. Maintaining a Track Segment 2686 To modify a section of a Segment between a first node and a second, 2687 downstream node (which can be the Ingress and Egress), while 2688 conserving those nodes in the Segment, the Root sends an SM-VIO to 2689 the second node indicating the sequence of nodes in the new section 2690 of the Segment. The SM-VIO indicates the TrackID and the P-RouteID 2691 of the Segment being updated, and a newer Segment Sequence. The 2692 P-DAO is propagated from the second to the first node and on the way, 2693 it updates the state on the nodes that are common to the old and the 2694 new section of the Segment and creates a state in the new nodes. 2696 When the state is updated in an intermediate node, that node might 2697 still receive packets that were in flight from the Ingress to self 2698 over the old section of the Segment. Since the remainder of the 2699 Segment is already updated, the packets are forwarded along the new 2700 version of the Segment from that node on. 2702 After a reasonable time to enable the deprecated sections to empty, 2703 the Root tears down the remaining section(s) of the old segments are 2704 teared down as described in Section 6.5. 2706 6.6.2. Maintaining a Track Leg 2708 This specification allows the Root to add Legs to a Track by sending 2709 a Non-Storing Mode P-DAO to the Ingress associated to the same 2710 TrackID, and a new Segment ID. If the Leg is loose, then the 2711 Segments that join the hops must be created first. It makes sense to 2712 add a new Leg before removing one that is becoming excessively lossy, 2713 and switch to the new Leg before removing the old. Dropping a Track 2714 before the new one is installed would reroute the traffic via the 2715 root; this may augment the latency beyond acceptable thresholds, and 2716 load the network near the root. This may also cause loops in the 2717 case of stitched Tracks; the packets that cannot be injected in the 2718 second Track may be routed back at reinjected at the Ingress of the 2719 first. 2721 It is also possible to update a Track Leg by sending a Non-Storing 2722 Mode P-DAO to the Ingress with the same Segment ID, an incremented 2723 Segment Sequence, and the new complete list of hops in the NSM-VIO. 2724 Updating a live Leg means changing one or more of the intermediate 2725 loose hops, and involves laying out new Segments from and to the new 2726 loose hops before the NSM-VIO for the new Leg is issued. 2728 Packets that are in flight over the old version of the Track Leg 2729 still follow the old source route path over the old Segments. After 2730 a reasonable time to enable the deprecated Segments to empty, the 2731 Root tears down those Segments as described in Section 6.5. 2733 6.7. Encapsulating and Forwarding Along a Track 2735 When injecting a packet in a Track, the Ingress router must 2736 encapsulate the packet using IP-in-IP to add the Source Routing 2737 Header with the final destination set to the Track Egress. 2739 All properties of a Track operations are inherited form the main RPL 2740 Instance that is used to install the Track. For instance, the use of 2741 compression per [RFC8138] is determined by whether it is used in the 2742 RPL Main DODAG, e.g., by setting the "T" flag [RFC9035] in the RPL 2743 configuration option. 2745 The Track Ingress that places a packet in a Track encapsulates it 2746 with an IP-in-IP header, a Routing Header, and an IPv6 Hop-by-Hop 2747 Option Header that contains the RPL Packet Information (RPI) as 2748 follows: 2750 * In the uncompressed form the source of the packet is the address 2751 that this router uses as DODAGID for the Track, the destination is 2752 the first Via Address in the NSM-VIO, and the RH is a Source 2753 Routing Header (SRH) [RFC6554] that contains the list of the 2754 remaining Via Addresses terminating by the Track Egress. 2756 * The preferred alternate in a network where 6LoWPAN Header 2757 Compression [RFC6282] is used is to leverage "IPv6 over Low-Power 2758 Wireless Personal Area Network (6LoWPAN) Paging Dispatch" 2759 [RFC8025] to compress the RPL artifacts as indicated in [RFC8138]. 2761 In that case, the source routed header is the exact copy of the 2762 (chain of) SRH-6LoRH found in the NSM-VIO, also terminating by the 2763 Track Egress. The RPI-6LoRH is appended next, followed by an IP- 2764 in-IP 6LoRH Header that indicates the Ingress router in the 2765 Encapsulator Address field, see as a similar case Figure 20 of 2766 [RFC9035]. 2768 To signal the Track in the packet, this specification leverages the 2769 RPL Forwarding model follows: 2771 * In the data packets, the Track DODAGID and the TrackID MUST be 2772 respectively signaled as the IPv6 Source Address and the 2773 RPLInstanceID field of the RPI that MUST be placed in the outer 2774 chain of IPv6 Headers. 2776 The RPI carries a local RPLInstanceID called the TrackID, which, 2777 in association with the DODAGID, indicates the Track along which 2778 the packet is forwarded. 2780 The D flag in the RPLInstanceID MUST be set to 0 to indicate that 2781 the source address in the IPv6 header is set ot the DODAGID, more 2782 in Section 6.3. 2784 * This draft conforms to the principles of [RFC9008] with regards to 2785 packet forwarding and encapsulation along a Track, as follows: 2787 - With this draft, the Track is a RPL DODAG. From the 2788 perspective of that DODAG, the Track Ingress is the Root, the 2789 Track Egress is a RPL-Aware 6LR, and neighbors of the Track 2790 Egress that can be reached via the Track, but are external to 2791 it, are external destinations and treated as RPL-Unaware Leaves 2792 (RULs). The encapsulation rules in [RFC9008] apply. 2794 - If the Track Ingress is the originator of the packet and the 2795 Track Egress is the destination of the packet, there is no need 2796 for an encapsulation. 2798 - So the Track Ingress must encapsulate the traffic that it did 2799 not originate, and add an RPI. 2801 A packet that is being routed over the RPL Instance associated to 2802 a first Non-Storing Mode Track MAY be placed (encapsulated) in a 2803 second Track to cover one loose hop of the first Track as 2804 discussed in more details Section 3.5.2.3. On the other hand, a 2805 Storing Mode Track must be strict and a packet that it placed in a 2806 Storing Mode Track MUST follow that Track till the Track Egress. 2808 The forwarding of a packet along a track will fail if the Track 2809 continuity is broken,e.g.: 2811 * In the case of a strict path along a Segment, if the next strict 2812 hop is not reachable, the packet is dropped. 2814 * In the case of a loose source-routed path, when the loose next hop 2815 is not a neighbor, there must be a Segment of the same Track to 2816 that loose next hop. When that is the case the packet is 2817 forwarded to the next hop along that segment, or a common neighbor 2818 with the loose next hop, on which case the packet is forwarded to 2819 that neighbor, or another Track to the loose next hop for which 2820 this node or a neighbor is Ingress; in the last case, another 2821 encapsulation takes place and the process possibly recurses; 2822 otherwise the packet is dropped. 2824 * When a Track Egress extracts a packet from a Track (decapsulates 2825 the packet), the destination of the inner packet must be either 2826 this node or a direct neighbor, or a Target of another Segment of 2827 the same Track for which this node is Ingress, otherwise the 2828 packet MUST be dropped. 2830 In case of a failure forwarding a packet along a Segment, e.g., the 2831 next hop is unreachable, the node that discovers the fault MUST send 2832 an ICMPv6 Error message [RFC4443] to the Root, with a new Code "Error 2833 in P-Route" (See Section 11.15). The Root can then repair by 2834 updating the broken Segment and/or Tracks, and in the case of a 2835 broken Segment, remove the leftover sections of the segment using SM- 2836 VIOs with a lifetime of 0 indicating the section ot one or more nodes 2837 being removed (See Section 6.6). 2839 In case of a permanent forwarding error along a Source Route path, 2840 the node that fails to forward SHOULD send an ICMP error with a code 2841 "Error in Source Routing Header" back to the source of the packet, as 2842 described in section 11.2.2.3. of [RPL]. Upon this message, the 2843 encapsulating node SHOULD stop using the source route path for a 2844 reasonable period of time which duration depends on the deployment, 2845 and it SHOULD send an ICMP message with a Code "Error in P-Route" to 2846 the Root. Failure to follow these steps may result in packet loss 2847 and wasted resources along the source route path that is broken. 2849 Either way, the ICMP message MUST be throttled in case of consecutive 2850 occurrences. It MUST be sourced at the ULA or a GUA that is used in 2851 this Track for the source node, so the Root can establish where the 2852 error happened. 2854 The portion of the invoking packet that is sent back in the ICMP 2855 message SHOULD record at least up to the RH if one is present, and 2856 this hop of the RH SHOULD be consumed by this node so that the 2857 destination in the IPv6 header is the next hop that this node could 2858 not reach. if a 6LoWPAN Routing Header (6LoRH) [RFC8138] is used to 2859 carry the IPv6 routing information in the outer header then that 2860 whole 6LoRH information SHOULD be present in the ICMP message. 2862 6.8. Compression of the RPL Artifacts 2864 When using [RFC8138] in the Main DODAG operated in Non-Storing Mode 2865 in a 6LoWPAN LLN, a typical packet that circulates in the Main DODAG 2866 is formatted as shown in Figure 20, representing the case where : 2868 +-+ ... -+- ... -+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-... 2869 |11110001| SRH- | RPI- | IP-in-IP | NH=1 |11110CPP| UDP | UDP 2870 | Page 1 | 6LoRH | 6LoRH | 6LoRH |LOWPAN_IPHC| UDP | hdr |Payld 2871 +-+ ... -+- ... -+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-... 2872 <= RFC 6282 => 2873 <================ Inner packet ==================== = = 2875 Figure 20: A Packet as Forwarded along the Main DODAG 2877 Since there is no page switch between the encapsulated packet and the 2878 encapsulation, the first octet of the compressed packet that acts as 2879 page selector is actually removed at encapsulation, so the inner 2880 packet used in the descriptions below start with the SRH-6LoRH, and 2881 is verbatim the packet represented in Figure 20 from the second octet 2882 on. 2884 When encapsulating that inner packet to place it in the Track, the 2885 first header that the Ingress appends at the head of the inner packet 2886 is an IP-in-IP 6LoRH Header; in that header, the encapsulator 2887 address, which maps to the IPv6 source address in the uncompressed 2888 form, contains a GUA or ULA IPv6 address of the Ingress node that 2889 serves as DODAG ID for the Track, expressed in the compressed form 2890 and using the DODAGID of the Main DODAG as compression reference. If 2891 the address is compressed to 2 bytes, the resulting value for the 2892 Length field shown in Figure 21 is 3, meaning that the SRH-6LoRH as a 2893 whole is 5-octets long. 2895 0 1 2 2896 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 2898 |1|0|1| Length | 6LoRH Type 6 | Hop Limit | Track DODAGID | 2899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 2901 Figure 21: The IP-in-IP 6LoRH Header 2903 At the head of the resulting sequence of bytes, the track Ingress 2904 then adds the RPI that carries the TrackID as RPLinstanceID as a P- 2905 RPI-6LoRH Header, as illustrated in Figure 12, using the TrackID as 2906 RPLInstanceID. Combined with the IP-in-IP 6LoRH Header, this allows 2907 to identify the Track without ambiguity. 2909 The SRH-6LoRH is then added at the head of the resulting sequence of 2910 bytes as a verbatim copy of the content of the SR-VIO that signaled 2911 the selected Track Leg. 2913 0 1 2914 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 .. .. .. 2915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+ 2916 |1|0|0| Size |6LoRH Type 0..4| Hop1 | Hop2 | | HopN | 2917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+ 2918 Where N = Size + 1 2920 Figure 22: The SRH 6LoRH Header 2922 The format of the resulting encapsulated packet in [RFC8138] 2923 compressed form is illustrated in Figure 23: 2925 +-+ ... -+-+-+- ... -+-+-+- ... -+-+-+-+-+- ... +-+-+-+-+-+-+- ... 2926 | Page 1 | SRH-6LoRH | P-RPI-6LoRH | IP-in-IP 6LoRH | Inner Packet 2927 +-+ ... -+-+-+- ... -+-+-+- ... -+-+-+-+-+- ... +-+-+-+-+-+-+- ... 2929 Signals : Loose Hops : TrackID : Track DODAGID : 2931 Figure 23: A Packet as Forwarded along a Track 2933 7. Lesser Constrained Variations 2935 7.1. Storing Mode Main DODAG 2937 This specification expects that the Main DODAG is operated in Non- 2938 Storing Mode. The reasons for that limitation are mostly related to 2939 LLN operations, power and spectrum conservation: 2941 * In Non-Storing Mode The Root already possesses the DODAG topology, 2942 so the additional topological information is reduced to the 2943 siblings. 2945 * The downwards routes are updated with unicast messages to the 2946 Root, which ensures that the Root can reach back to the LLN nodes 2947 after a repair faster than in the case of Storing Mode. Also the 2948 Root can control the use of the path diversity in the DODAG to 2949 reach to the LLN nodes. For both reasons, Non-Storing Mode 2950 provides better capabilities for the Root to maintain the 2951 P-Routes. 2953 * When the Main DODAG is operated in Non-Storing Mode, P-Routes 2954 enable loose Source Routing, which is only an advantage in that 2955 mode. Storing Mode does not use Source Routing Headers, and does 2956 not derive the same benefits from this capability. 2958 On the other hand, since RPL is a Layer-3 routing protocol, its 2959 applicability extends beyond LLNs to a generic IP network. RPL 2960 requires fewer resources than alternative IGPs like OSPF, ISIS, 2961 EIGRP, BABEL or RIP at the expense of a route stretch vs. the 2962 shortest path routes to a destination that those protocols compute. 2963 P-Routes add the capability to install shortest and/or constrained 2964 routes to special destinations such as discussed in section A.9.4. of 2965 the ANIMA ACP [RFC8994]. 2967 In a powered and wired network, when enough memory to store the 2968 needed routes is available, the RPL Storing Mode proposes a better 2969 trade-off than the Non-Storing, as it reduces the route stretch and 2970 lowers the load on the Root. In that case, the control path between 2971 the Root and the LLN nodes is highly available compared to LLNs, and 2972 the nodes can be reached to maintain the P-Routes at most times. 2974 This section specifies the additions that are needed to support 2975 Projected Routes when the Main DODAG is operated in Storing Mode. As 2976 long as the RPI can be processed adequately by the dataplane, the 2977 changes to this specification are limited to the DAO message. The 2978 Track structure, routes and forwarding operations remain the same. 2979 Since there is no capability negotiation, the expectation is that all 2980 the nodes in the network support this specification in the same 2981 fashion, or are configured the same way through management. 2983 In Storing Mode, the Root misses the Child to Parent relationship 2984 that forms the Main DODAG, as well as the sibling information. To 2985 provide that knowledge the nodes in the network MUST send additional 2986 DAO messages that are unicast to the Root as Non-Storing DAO messages 2987 are. 2989 In the DAO message, the originating router advertises a set of 2990 neighbor nodes using Sibling Information Options (SIO)s, regardless 2991 of the relative position in the DODAG of the advertised node vs. this 2992 router. 2994 The DAO message MUST be formed as follows: 2996 * The originating router is identified by the source address of the 2997 DAO. That address MUST be the one that this router registers to 2998 neighbor routers so the Root can correlate the DAOs from those 2999 routers when they advertise this router as their neighbor. The 3000 DAO contains one or more sequences of one Transit Information 3001 Option and one or more Sibling Information Options. There is no 3002 RPL Target Option so the Root is not confused into adding a 3003 Storing Mode route to the Target. 3005 * The TIO is formed as in Storing Mode, and the Parent Address is 3006 not present. The Path Sequence and Path Lifetime fields are 3007 aligned with the values used in the Address Registration of the 3008 node(s) advertised in the SIO, as explained in Section 9.1. of 3009 [RFC9010]. Having similar values in all nodes allows to factorise 3010 the TIO for multiple SIOs as done with [RPL]. 3012 * The TIO is followed by one or more SIOs that provide an address 3013 (ULA or GUA) of the advertised neighbor node. 3015 But the RPL routing information headers may not be supported on all 3016 type of routed network infrastructures, especially not in high-speed 3017 routers. When the RPI is not supported in the dataplane, there 3018 cannot be local RPL Instances and RPL can only operate as a single 3019 topology (the Main DODAG). The RPL Instance is that of the Main 3020 DODAG and the Ingress node that encapsulates is not the Root. The 3021 routes along the Tracks are alternate routes to those available along 3022 the Main DODAG. They MAY conflict with routes to children and MUST 3023 take precedence in the routing table. The Targets MUST be adjacent 3024 to the Track Egress to avoid loops that may form if the packet is 3025 reinjected in the Main DODAG. 3027 7.2. A Track as a Full DODAG 3029 This specification builds parallel or crossing Track Legs as opposed 3030 to a more complex DODAG with interconnections at any place desirable. 3031 The reason for that limitation is related to constrained node 3032 operations, and capability to store large amount of topological 3033 information and compute complex paths: 3035 * With this specification, the node in the LLN has no topological 3036 awareness, and does not need to maintain dynamic information about 3037 the link quality and availability. 3039 * The Root has a complete topological information and statistical 3040 metrics that allow it or its PCE to perform a global optimization 3041 of all Tracks in its DODAG. Based on that information, the Root 3042 computes the Track Leg and predigest the source route paths. 3044 * The node merely selects one of the proposed paths and applies the 3045 associated pre-computed routing header in the encapsulation. This 3046 alleviates both the complexity of computing a path and the 3047 compressed form of the routing header. 3049 The RAW Architecture [RAW-ARCHI] actually expects the PSE at the 3050 Track Ingress to react to changes in the forwarding conditions along 3051 the Track, and reroute packets to maintain the required degree of 3052 reliability. To achieve this, the PSE need the full richness of a 3053 DODAG to form any path that could make meet the Service Level 3054 Objective (SLO). 3056 This section specifies the additions that are needed to turn the 3057 Track into a full DODAG and enable the main Root to provide the 3058 necessary topological information to the Track Ingress. The 3059 expectation is that the metrics that the PSE uses are of an order 3060 other than that of the PCE, because of the difference of time scale 3061 between routing and forwarding, mor e in [RAW-ARCHI]. It follows 3062 that the PSE will learn the metrics it needs from an alternate 3063 source, e.g., OAM frames. 3065 To pass the topological information to the Ingress, the Root uses a 3066 P-DAO messages that contains sequences of Target and Transit 3067 Information options that collectively represent the Track, expressed 3068 in the same fashion as in classical Non-Storing Mode. The difference 3069 as that the Root is the source as opposed to the destination, and can 3070 report information on many Targets, possibly the full Track, with one 3071 P-DAO. 3073 Note that the Path Sequence and Lifetime in the TIO are selected by 3074 the Root, and that the Target/Transit information tupples in the 3075 P-DAO are not those received by the Root in the DAO messages about 3076 the said Targets. The Track may follow sibling routes and does not 3077 need to be congruent with the Main DODAG. 3079 8. Profiles 3081 This document provides a set of tools that may or may not be needed 3082 by an implementation depending on the type of application it serves. 3083 This sections described profiles that can be implemented separately 3084 and can be used to discriminate what an implementation can and cannot 3085 do. This section describes profiles that enable to implement only a 3086 portion of this specification to meet a particular use case. 3088 Profiles 0 to 2 operate in the Main RPL Instance and do not require 3089 the support of local RPL Instances or the indication of the RPL 3090 Instance in the data plane. Profile 3 and above leverage Local RPL 3091 Instances to build arbitrary Tracks Rooted at the Track Ingress and 3092 using its namespace for TrackID. 3094 Profiles 0 and 1 are REQUIRED by all implementations that may be used 3095 in LLNs; Profiles 1 leverages Storing Mode to reduce the size of the 3096 Source Route Header in the most common LLN deployments. Profile 2 is 3097 RECOMMENDED in high speed / wired environment to enable traffic 3098 Engineering and network automation. All the other profile / 3099 environment combinations are OPTIONAL. 3101 Profile 0 Profile 0 is the Legacy support of [RPL] Non-Storing Mode, 3102 with default routing Northwards (up) and strict source routing 3103 Southwards (down the main DOAG). It provides the minimal common 3104 functionality that must be implemented as a prerequisite to all 3105 the Track-supporting profiles. The other Profiles extend Profile 3106 0 with selected capabilities that this specification introduces on 3107 top. 3109 Profile 1 (Storing Mode P-Route Segments along the Main DODAG) Profi 3110 le 1 does not create new paths; compared to Profile 0, it combines 3111 Storing and Non-Storing Modes to balance the size of the Routing 3112 Header in the packet and the amount of state in the intermediate 3113 routers in a Non-Storing Mode RPL DODAG. 3115 Profile 2 (Non-Storing Mode P-Route Segments along the Main DODAG) P 3116 rofile 2 extends Profile 0 with Strict Source-Routing Non-Storing 3117 Mode P-Routes along the Main DODAG, which is the same as Profile 1 3118 but using NSM VIOs as opposed to SM VIOs. Profile 2 provides the 3119 same capability to compress the SRH in packets down the Main DODAG 3120 as Profile 1, but it require an encapsulation, in order to insert 3121 an additional SRH between the loose source routing hops. In that 3122 case, the Tracks MUST be installed as subTracks of the Main DODAG, 3123 the main RPL Instance MUST be used as TrackID, and the Ingress 3124 node that encapsulates is not the Root as it does not own the 3125 DODAGID. 3127 Profile 3 In order to form the best path possible, those Profiles 3128 require the support of Sibling Information Option to inform the 3129 Root of additional possible hops. Profile 3 extends Profile 1 3130 with additional Storing Mode P-Routes that install segments that 3131 do not follow the Main DODAG. If the Segment Ingress (in the SM- 3132 VIO) is the same as the IPv6 Address of the Track Ingress (in the 3133 projected DAO base Object), the P-DAO creates an implicit Track 3134 between the Segment Ingress and the Segment Egress. 3136 Profile 4 Profile 4 extends Profile 2 with Strict Source-Routing 3137 Non-Storing Mode P-Routes to form East-West Tracks that are inside 3138 the Main DODAG but do not necessarily follow it. A Track is 3139 formed as one or more strict source source routed paths between 3140 the Root that is the Track Ingress, and the Track Egress that is 3141 the last node. 3143 Profile 5 Profile 5 Combines Profile 4 with Profile 1 and enables to 3144 loose source routing between the Ingress and the Egress of the 3145 Track. As in Profile 1, Storing Mode P-Routes connect the dots in 3146 the loose source route. 3148 Profile 6 Profile 6 Combines Profile 4 with Profile 2 and also 3149 enables to loose source routing between the Ingress and the Egress 3150 of the Track. 3152 Profile 7 Profile 7 implements profile 5 in a Main DODAG that is 3153 operated in Storing Mode as presented in Section 7.1. As in 3154 Profile 1 and 2, the TrackID is the RPLInstanceID of the Main 3155 DODAG. Longest match rules decide whether a packet is sent along 3156 the Main DODAG or rerouted in a track. 3158 Profile 8 Profile 8 is offered in preparation of the RAW work, and 3159 for use cases where an arbitrary node in the network can afford 3160 the same code complexity as the RPL Root in a traditional 3161 deployment. It offers a full DODAG visibility to the Track 3162 Ingress as specified in Section 7.2 in a Non-Storing Mode Main 3163 DODAG. 3165 Profile 9 Profile 9 combines profiles 7 and 8, operating the Track 3166 as a full DODAG within a Storing Mode Main DODAG, using only the 3167 Main DODAG RPLInstanceID as TrackID. 3169 9. Backwards Compatibility 3171 This specification can operate in a mixed network where some nodes 3172 support it and some do not. There are restructions, though. All 3173 nodes that need to process a P-DAO MUST support this specification. 3174 As discussed in Section 3.7.1, how the root knows whether the nodes 3175 capabilities and whether it support this specification is out of 3176 scope. 3178 This specification defines the 'D' flag in the RPL DODAG 3179 Configuration Option (see Section 4.1.7) to signal that the RPL nodes 3180 can request the creation of Tracks. The requester may not know 3181 whether the Track can effectively be constructed, and whether enough 3182 nodes along the preferred paths support this specification. 3183 Therefore it makes sense to only set the 'D' flags in DIO when the 3184 conditions of success are in place, in particular when all the nodes 3185 that could be on path of tracks are upgraded. 3187 10. Security Considerations 3189 It is worth noting that with [RPL], every node in the LLN is RPL- 3190 aware and can inject any RPL-based attack in the network. This draft 3191 uses messages that are already present in RPL [RPL] with optional 3192 secured versions. The same secured versions may be used with this 3193 draft, and whatever security is deployed for a given network also 3194 applies to the flows in this draft. 3196 The LLN nodes depend on the 6LBR and the RPL participants for their 3197 operation. A trust model is necessary to ensure that the right 3198 devices are acting in these roles, so as to avoid threats such as 3199 black-holing, (see [RFC7416] section 7). This trust model could be 3200 at a minimum based on a Layer-2 Secure joining and the Link-Layer 3201 security. This is a generic 6LoWPAN requirement, see Req5.1 in 3202 Appendix B.5 of [RFC8505]. 3204 In a general manner, the Security Considerations in [RPL], and 3205 [RFC7416] apply to this specification as well. The Link-Layer 3206 security is needed in particular to prevent Denial-Of-Service attacks 3207 whereby a rogue router creates a high churn in the RPL network by 3208 constantly injected forged P-DAO messages and using up all the 3209 available storage in the attacked routers. 3211 With this specification, only the Root may generate P-DAO messages. 3212 PDR messages may only be sent to the Root. This specification 3213 expects that the communication with the Root is authenticated but 3214 does enforce which method is used. 3216 Additionally, the trust model could include a role validation (e.g., 3217 using a role-based authorization) to ensure that the node that claims 3218 to be a RPL Root is entitled to do so. That trust should propagate 3219 from Egress to Ingress in the case of a Storing Mode P-DAO. 3221 This specification suggests some validation of the VIO to prevent 3222 basic loops by avoiding that a node appears twice. But that is only 3223 a minimal protection. Arguably, an attacker that can inject P-DAOs 3224 can reroute any traffic and deplete critical resources such as 3225 spectrum and battery in the LLN rapidly. 3227 11. IANA Considerations 3229 11.1. RPL DODAG Configuration Option Flag 3231 IANA is requested to assign a flag from the "DODAG Configuration 3232 Option Flags for MOP 0..6" [RFC9010] registry as follows: 3234 +---------------+------------------------------+-----------+ 3235 | Bit Number | Capability Description | Reference | 3236 +---------------+------------------------------+-----------+ 3237 | 0 (suggested) | Projected Routes Support (D) | THIS RFC | 3238 +---------------+------------------------------+-----------+ 3240 Table 21: New DODAG Configuration Option Flag 3242 IANA is requested to add [THIS RFC] as a reference for MOP 7 in the 3243 RPL Mode of Operation registry. 3245 11.2. Elective 6LoWPAN Routing Header Type 3247 This document updates the IANA registry titled "Elective 6LoWPAN 3248 Routing Header Type" that was created for [RFC8138] and assigns the 3249 following value: 3251 +===============+=============+===============+ 3252 | Value | Description | Reference | 3253 +===============+=============+===============+ 3254 | 8 (Suggested) | P-RPI-6LoRH | This document | 3255 +---------------+-------------+---------------+ 3257 Table 22: New Elective 6LoWPAN Routing 3258 Header Type 3260 11.3. Critical 6LoWPAN Routing Header Type 3262 This document updates the IANA registry titled "Critical 6LoWPAN 3263 Routing Header Type" that was created for [RFC8138] and assigns the 3264 following value: 3266 +===============+=============+===============+ 3267 | Value | Description | Reference | 3268 +===============+=============+===============+ 3269 | 8 (Suggested) | P-RPI-6LoRH | This document | 3270 +---------------+-------------+---------------+ 3272 Table 23: New Critical 6LoWPAN Routing 3273 Header Type 3275 11.4. Subregistry For The RPL Option Flags 3277 IANA is required to create a subregistry for the 8-bit RPL Option 3278 Flags field, as detailed in Figure 11, under the "Routing Protocol 3279 for Low Power and Lossy Networks (RPL)" registry. The bits are 3280 indexed from 0 (leftmost) to 7. Each bit is Tracked with the 3281 following qualities: 3283 * Bit number (counting from bit 0 as the most significant bit) 3285 * Indication When Set 3287 * Reference 3289 Registration procedure is "Standards Action" [RFC8126]. The initial 3290 allocation is as indicated in Table 27: 3292 +===============+======================+===============+ 3293 | Bit number | Indication When Set | Reference | 3294 +===============+======================+===============+ 3295 | 0 | Down 'O' | [RFC6553] | 3296 +---------------+----------------------+---------------+ 3297 | 1 | Rank-Error (R) | [RFC6553] | 3298 +---------------+----------------------+---------------+ 3299 | 2 | Forwarding-Error (F) | [RFC6553] | 3300 +---------------+----------------------+---------------+ 3301 | 3 (Suggested) | Projected-Route (P) | This document | 3302 +---------------+----------------------+---------------+ 3304 Table 24: Initial PDR Flags 3306 11.5. RPL Control Codes 3308 This document extends the IANA Subregistry created by RFC 6550 for 3309 RPL Control Codes as indicated in Table 25: 3311 +==================+=============================+===============+ 3312 | Code | Description | Reference | 3313 +==================+=============================+===============+ 3314 | 0x09 (Suggested) | Projected DAO Request (PDR) | This document | 3315 +------------------+-----------------------------+---------------+ 3316 | 0x0A (Suggested) | PDR-ACK | This document | 3317 +------------------+-----------------------------+---------------+ 3319 Table 25: New RPL Control Codes 3321 11.6. RPL Control Message Options 3323 This document extends the IANA Subregistry created by RFC 6550 for 3324 RPL Control Message Options as indicated in Table 26: 3326 +==================+=============================+===============+ 3327 | Value | Meaning | Reference | 3328 +==================+=============================+===============+ 3329 | 0x0E (Suggested) | Stateful VIO (SM-VIO) | This document | 3330 +------------------+-----------------------------+---------------+ 3331 | 0x0F (Suggested) | Source-Routed VIO (NSM-VIO) | This document | 3332 +------------------+-----------------------------+---------------+ 3333 | 0x10 (Suggested) | Sibling Information option | This document | 3334 +------------------+-----------------------------+---------------+ 3336 Table 26: RPL Control Message Options 3338 11.7. SubRegistry for the Projected DAO Request Flags 3340 IANA is required to create a registry for the 8-bit Projected DAO 3341 Request (PDR) Flags field. Each bit is Tracked with the following 3342 qualities: 3344 * Bit number (counting from bit 0 as the most significant bit) 3346 * Capability description 3348 * Reference 3350 Registration procedure is "Standards Action" [RFC8126]. The initial 3351 allocation is as indicated in Table 27: 3353 +============+========================+===============+ 3354 | Bit number | Capability description | Reference | 3355 +============+========================+===============+ 3356 | 0 | PDR-ACK request (K) | This document | 3357 +------------+------------------------+---------------+ 3358 | 1 | Requested path should | This document | 3359 | | be redundant (R) | | 3360 +------------+------------------------+---------------+ 3362 Table 27: Initial PDR Flags 3364 11.8. SubRegistry for the PDR-ACK Flags 3366 IANA is required to create an subregistry for the 8-bit PDR-ACK Flags 3367 field. Each bit is Tracked with the following qualities: 3369 * Bit number (counting from bit 0 as the most significant bit) 3371 * Capability description 3373 * Reference 3374 Registration procedure is "Standards Action" [RFC8126]. No bit is 3375 currently defined for the PDR-ACK Flags. 3377 11.9. Subregistry for the PDR-ACK Acceptance Status Values 3379 IANA is requested to create a Subregistry for the PDR-ACK Acceptance 3380 Status values. 3382 * Possible values are 6-bit unsigned integers (0..63). 3384 * Registration procedure is "Standards Action" [RFC8126]. 3386 * Initial allocation is as indicated in Table 28: 3388 +-------+------------------------+---------------+ 3389 | Value | Meaning | Reference | 3390 +-------+------------------------+---------------+ 3391 | 0 | Unqualified Acceptance | This document | 3392 +-------+------------------------+---------------+ 3394 Table 28: Acceptance values of the PDR-ACK Status 3396 11.10. Subregistry for the PDR-ACK Rejection Status Values 3398 IANA is requested to create a Subregistry for the PDR-ACK Rejection 3399 Status values. 3401 * Possible values are 6-bit unsigned integers (0..63). 3403 * Registration procedure is "Standards Action" [RFC8126]. 3405 * Initial allocation is as indicated in Table 29: 3407 +-------+-----------------------+---------------+ 3408 | Value | Meaning | Reference | 3409 +-------+-----------------------+---------------+ 3410 | 0 | Unqualified Rejection | This document | 3411 +-------+-----------------------+---------------+ 3412 | 1 | Transient Failure | This document | 3413 +-------+-----------------------+---------------+ 3415 Table 29: Rejection values of the PDR-ACK Status 3417 11.11. SubRegistry for the Via Information Options Flags 3419 IANA is requested to create a Subregistry for the 5-bit Via 3420 Information Options (Via Information Option) Flags field. Each bit 3421 is Tracked with the following qualities: 3423 * Bit number (counting from bit 0 as the most significant bit) 3425 * Capability description 3427 * Reference 3429 Registration procedure is "Standards Action" [RFC8126]. No bit is 3430 currently defined for the Via Information Options (Via Information 3431 Option) Flags. 3433 11.12. SubRegistry for the Sibling Information Option Flags 3435 IANA is required to create a registry for the 5-bit Sibling 3436 Information Option (SIO) Flags field. Each bit is Tracked with the 3437 following qualities: 3439 * Bit number (counting from bit 0 as the most significant bit) 3441 * Capability description 3443 * Reference 3445 Registration procedure is "Standards Action" [RFC8126]. The initial 3446 allocation is as indicated in Table 30: 3448 +===============+========================+===========+ 3449 | Bit number | Capability description | Reference | 3450 +===============+========================+===========+ 3451 | 0 (Suggested) | "S" flag: Sibling in | This | 3452 | | same DODAG as Self | document | 3453 +---------------+------------------------+-----------+ 3455 Table 30: Initial SIO Flags 3457 11.13. Destination Advertisement Object Flag 3459 This document modifies the "Destination Advertisement Object (DAO) 3460 Flags" registry initially created in Section 20.11 of [RPL] . 3462 Section 4.1.1 also defines one new entry in the Registry as follows: 3464 +---------------+------------------------+-----------+ 3465 | Bit Number | Capability Description | Reference | 3466 +---------------+------------------------+-----------+ 3467 | 2 (Suggested) | Projected DAO (P) | THIS RFC | 3468 +---------------+------------------------+-----------+ 3470 Table 31: New Destination Advertisement Object 3471 (DAO) Flag 3473 11.14. Destination Advertisement Object Acknowledgment Flag 3475 This document modifies the "Destination Advertisement Object (DAO) 3476 Acknowledgment Flags" registry initially created in Section 20.12 of 3477 [RPL] . 3479 Section 4.1.2 also defines one new entry in the Registry as follows: 3481 +---------------+------------------------+-----------+ 3482 | Bit Number | Capability Description | Reference | 3483 +---------------+------------------------+-----------+ 3484 | 1 (Suggested) | Projected DAO-ACK (P) | THIS RFC | 3485 +---------------+------------------------+-----------+ 3487 Table 32: New Destination Advertisement Object 3488 Acknowledgment Flag 3490 11.15. New ICMPv6 Error Code 3492 In some cases RPL will return an ICMPv6 error message when a message 3493 cannot be forwarded along a P-Route. 3495 IANA has defined an ICMPv6 "Code" Fields Registry for ICMPv6 Message 3496 Types. ICMPv6 Message Type 1 describes "destination Unreachable" 3497 codes. This specification requires that a new code is allocated from 3498 the ICMPv6 Code Fields Registry for ICMPv6 Message Type 1, for "Error 3499 in P-Route", with a suggested code value of 8, to be confirmed by 3500 IANA. 3502 11.16. RPL Rejection Status values 3504 This specification updates the Subregistry for the "RPL Rejection 3505 Status" values under the RPL registry, as follows: 3507 +---------------+-------------------------+-----------+ 3508 | Value | Meaning | Reference | 3509 +---------------+-------------------------+-----------+ 3510 | 2 (Suggested) | Out of Resources | THIS RFC | 3511 +---------------+-------------------------+-----------+ 3512 | 3 (Suggested) | Error in VIO | THIS RFC | 3513 +---------------+-------------------------+-----------+ 3514 | 4 (Suggested) | Predecessor Unreachable | THIS RFC | 3515 +---------------+-------------------------+-----------+ 3516 | 5 (Suggested) | Unreachable Target | THIS RFC | 3517 +---------------+-------------------------+-----------+ 3518 | 6..63 | Unassigned | | 3519 +---------------+-------------------------+-----------+ 3521 Table 33: Rejection values of the RPL Status 3523 12. Acknowledgments 3525 The authors wish to acknowledge JP Vasseur, Remy Liubing, James 3526 Pylakutty, and Patrick Wetterwald for their contributions to the 3527 ideas developed here. Many thanks to Dominique Barthel and SVR Anand 3528 for their global contribution to 6TiSCH, RAW and this document, as 3529 well as text suggestions that were incorporated. Also special thanks 3530 Toerless Eckert for his deep review, with many excellent suggestions 3531 that improved the readability and well as the content of the 3532 specification. Many thanks to Remous-Aris Koutsiamanis for his 3533 review during WGLC. 3535 13. Normative References 3537 [INT-ARCHI] 3538 Braden, R., Ed., "Requirements for Internet Hosts - 3539 Communication Layers", STD 3, RFC 1122, 3540 DOI 10.17487/RFC1122, October 1989, 3541 . 3543 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3544 Requirement Levels", BCP 14, RFC 2119, 3545 DOI 10.17487/RFC2119, March 1997, 3546 . 3548 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 3549 Control Message Protocol (ICMPv6) for the Internet 3550 Protocol Version 6 (IPv6) Specification", STD 89, 3551 RFC 4443, DOI 10.17487/RFC4443, March 2006, 3552 . 3554 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 3555 Computation Element (PCE)-Based Architecture", RFC 4655, 3556 DOI 10.17487/RFC4655, August 2006, 3557 . 3559 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 3560 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 3561 DOI 10.17487/RFC6282, September 2011, 3562 . 3564 [RPL] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 3565 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 3566 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 3567 Low-Power and Lossy Networks", RFC 6550, 3568 DOI 10.17487/RFC6550, March 2012, 3569 . 3571 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 3572 Power and Lossy Networks (RPL) Option for Carrying RPL 3573 Information in Data-Plane Datagrams", RFC 6553, 3574 DOI 10.17487/RFC6553, March 2012, 3575 . 3577 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 3578 Routing Header for Source Routes with the Routing Protocol 3579 for Low-Power and Lossy Networks (RPL)", RFC 6554, 3580 DOI 10.17487/RFC6554, March 2012, 3581 . 3583 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 3584 Writing an IANA Considerations Section in RFCs", BCP 26, 3585 RFC 8126, DOI 10.17487/RFC8126, June 2017, 3586 . 3588 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 3589 "IPv6 over Low-Power Wireless Personal Area Network 3590 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 3591 April 2017, . 3593 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3594 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 3595 May 2017, . 3597 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 3598 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 3599 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 3600 . 3602 [RFC9008] Robles, M.I., Richardson, M., and P. Thubert, "Using RPI 3603 Option Type, Routing Header for Source Routes, and IPv6- 3604 in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008, 3605 DOI 10.17487/RFC9008, April 2021, 3606 . 3608 14. Informative References 3610 [6LoWPAN] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 3611 "Transmission of IPv6 Packets over IEEE 802.15.4 3612 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 3613 . 3615 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 3616 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 3617 DOI 10.17487/RFC5440, March 2009, 3618 . 3620 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and 3621 J. Martocci, "Reactive Discovery of Point-to-Point Routes 3622 in Low-Power and Lossy Networks", RFC 6997, 3623 DOI 10.17487/RFC6997, August 2013, 3624 . 3626 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 3627 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 3628 2014, . 3630 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 3631 and M. Richardson, Ed., "A Security Threat Analysis for 3632 the Routing Protocol for Low-Power and Lossy Networks 3633 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 3634 . 3636 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 3637 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 3638 RFC 8025, DOI 10.17487/RFC8025, November 2016, 3639 . 3641 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 3642 Decraene, B., Litkowski, S., and R. Shakir, "Segment 3643 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 3644 July 2018, . 3646 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 3647 Perkins, "Registration Extensions for IPv6 over Low-Power 3648 Wireless Personal Area Network (6LoWPAN) Neighbor 3649 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 3650 . 3652 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 3653 "Deterministic Networking Architecture", RFC 8655, 3654 DOI 10.17487/RFC8655, October 2019, 3655 . 3657 [RFC8930] Watteyne, T., Ed., Thubert, P., Ed., and C. Bormann, "On 3658 Forwarding 6LoWPAN Fragments over a Multi-Hop IPv6 3659 Network", RFC 8930, DOI 10.17487/RFC8930, November 2020, 3660 . 3662 [RFC8931] Thubert, P., Ed., "IPv6 over Low-Power Wireless Personal 3663 Area Network (6LoWPAN) Selective Fragment Recovery", 3664 RFC 8931, DOI 10.17487/RFC8931, November 2020, 3665 . 3667 [RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An 3668 Autonomic Control Plane (ACP)", RFC 8994, 3669 DOI 10.17487/RFC8994, May 2021, 3670 . 3672 [RFC9010] Thubert, P., Ed. and M. Richardson, "Routing for RPL 3673 (Routing Protocol for Low-Power and Lossy Networks) 3674 Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021, 3675 . 3677 [RFC9030] Thubert, P., Ed., "An Architecture for IPv6 over the Time- 3678 Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)", 3679 RFC 9030, DOI 10.17487/RFC9030, May 2021, 3680 . 3682 [RFC9035] Thubert, P., Ed. and L. Zhao, "A Routing Protocol for Low- 3683 Power and Lossy Networks (RPL) Destination-Oriented 3684 Directed Acyclic Graph (DODAG) Configuration Option for 3685 the 6LoWPAN Routing Header", RFC 9035, 3686 DOI 10.17487/RFC9035, April 2021, 3687 . 3689 [RAW-ARCHI] 3690 Thubert, P. and G. Z. Papadopoulos, "Reliable and 3691 Available Wireless Architecture", Work in Progress, 3692 Internet-Draft, draft-ietf-raw-architecture-03, 14 January 3693 2022, . 3696 [USE-CASES] 3697 Bernardos, C. J., Papadopoulos, G. Z., Thubert, P., and F. 3698 Theoleyre, "RAW use-cases", Work in Progress, Internet- 3699 Draft, draft-ietf-raw-use-cases-05, 23 February 2022, 3700 . 3703 [I-D.kuehlewind-update-tag] 3704 Kuehlewind, M. and S. Krishnan, "Definition of new tags 3705 for relations between RFCs", Work in Progress, Internet- 3706 Draft, draft-kuehlewind-update-tag-04, 12 July 2021, 3707 . 3710 [I-D.irtf-panrg-path-properties] 3711 Enghardt, T. and C. Kraehenbuehl, "A Vocabulary of Path 3712 Properties", Work in Progress, Internet-Draft, draft-irtf- 3713 panrg-path-properties-04, 25 October 2021, 3714 . 3717 [PCE] IETF, "Path Computation Element", 3718 . 3720 Authors' Addresses 3722 Pascal Thubert (editor) 3723 Cisco Systems, Inc 3724 Building D 3725 45 Allee des Ormes - BP1200 3726 06254 Mougins - Sophia Antipolis 3727 France 3728 Phone: +33 497 23 26 34 3729 Email: pthubert@cisco.com 3730 Rahul Arvind Jadhav 3731 Huawei Tech 3732 Kundalahalli Village, Whitefield, 3733 Bangalore 560037 3734 Karnataka 3735 India 3736 Phone: +91-080-49160700 3737 Email: rahul.ietf@gmail.com 3739 Michael C. Richardson 3740 Sandelman Software Works 3741 Email: mcr+ietf@sandelman.ca 3742 URI: http://www.sandelman.ca/