idnits 2.17.1 draft-ietf-roll-dao-projection-25.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 are 2 instances 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 1406 has weird spacing: '...-- Node z-- ...' == Line 1413 has weird spacing: '... Node z-- ...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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 (23 March 2022) is 755 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 3250, but not defined ** Downref: Normative reference to an Informational RFC: RFC 4655 == Outdated reference: A later version (-17) exists of draft-ietf-raw-architecture-04 == 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-05 Summary: 1 error (**), 0 flaws (~~), 10 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: 24 September 2022 Huawei Tech 6 M. Richardson 7 Sandelman 8 23 March 2022 10 Root initiated routing state in RPL 11 draft-ietf-roll-dao-projection-25 13 Abstract 15 THIS RFC extends RFC 6550, RFC 6553, and RFC 8138 to enable a RPL 16 Root to install and maintain Projected Routes within its DODAG, along 17 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 24 September 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 . . . . . . . . . . . . . . . . . . . . 10 70 3.2. RPL Routing Modes . . . . . . . . . . . . . . . . . . . . 11 71 3.3. Requirements . . . . . . . . . . . . . . . . . . . . . . 12 72 3.3.1. Loose Source Routing . . . . . . . . . . . . . . . . 12 73 3.3.2. East-West Routes . . . . . . . . . . . . . . . . . . 13 74 3.4. On Tracks . . . . . . . . . . . . . . . . . . . . . . . . 15 75 3.4.1. Building Tracks With RPL . . . . . . . . . . . . . . 15 76 3.4.2. Tracks and RPL Instances . . . . . . . . . . . . . . 16 77 3.5. Serial Track Signaling . . . . . . . . . . . . . . . . . 16 78 3.5.1. Using Storing Mode Segments . . . . . . . . . . . . . 18 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 . . . 77 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 RFC are to be interpreted as described in BCP 14 185 [RFC2119][RFC8174] when, and only when, they appear in all capitals, 186 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 RFC, 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 RFC 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. Leg 355 An end-to-end East-West serial path. A leg can be a serial Track by 356 itself or a subTrack of a complex Track with the same Ingress and 357 Egress Nodes. With this specification, a Leg is is installed by the 358 Root of the main DODAG using a Non-Storing Mode P-DAO message, and it 359 is expressed as a loose sequence of nodes that are joined by Track 360 Segments. 362 As the Non-Storing Mode Via Information option (NSM-VIO) can only 363 signal sequences of nodes, it takes one Non-Storing Mode P-DAO 364 message per Leg to signal the structure of a complex Track. 366 Each NSM-VIO for the same TrackId but a different Segment ID signals 367 a different leg that the Track Ingress adds to the topology. 369 2.4.5.7. subTrack 371 A Track within a Track, formed by a non-empty collection of Legs of 372 the Track. 374 2.4.5.8. Segment 376 A serial path formed by a strict sequence of nodes, along which a 377 P-Route is installed. With this specification, a Segment is 378 typically installed by the Root of the main DODAG using Storing Mode 379 P-DAO messages. A Segment is used as the topological edge of a Track 380 joining the loose steps along the Legs that form the structure of a 381 complex Track. The same segment may be leveraged by more than one 382 Leg where the Legs overlap. 384 Since this specification builds only DODAGs, all Segments are 385 oriented from Ingress (East) to Egress (West), as opposed to the 386 general Track model in the RAW Architecture [RAW-ARCHI], which allows 387 North/South Segments that can be bidirectional as well. 389 2.4.5.8.1. Section of a Segment 391 A continuous subset of a segment that may be replaced while the 392 segment remains. for instance, in segment A=>B=>C=>D=>E=>F, say that 393 the link C to D might be misbehaving. The section B=>C=>D=>E in the 394 segment may be replaced by B=>C'=>D'=>E to route around the problem. 395 The segment becomes A=>B=>C'=>D'=>E=>F. 397 2.4.5.8.2. Segment Routing and SRH 399 The terms Segment Routing and SRH refer to using source-routing to 400 hop over segments. In a Non-Storing mode RPL domain, the SRH is 401 typically a RPL Source Route Header (the IPv6 RH of type 3) as 402 defined in [RFC6554]. 404 If the network is a 6LoWPAN Network, the expectation is that the SRH 405 is compressed and encoded as a 6LoWPAN Routing Header (6LoRH), as 406 specified in section 5 of [RFC8138]. 408 On the other hand, if the RPL Network is less constrained and 409 operated in Storing Mode, as discussed in Section 7.1, the Segment 410 Routing operation and the SRH could be as specified in [RFC8754]. 411 This specification applies equally to both forms of source routing 412 and SRH. 414 3. Context and Goal 415 3.1. RPL Applicability 417 RPL is optimized for situations where the power is scarce, the 418 bandwidth constrained and the transmissions unreliable. This matches 419 the use case of an IoT LLN where RPL is typically used today, but 420 also situations of high relative mobility between the nodes in the 421 network (aka swarming), e.g., within a variable set of vehicles with 422 a similar global motion, or a toon of drones. 424 To reach this goal, RPL is primarily designed to minimize the control 425 plane activity, that is the relative amount of routing protocol 426 exchanges vs. data traffic, and the amount of state that is 427 maintained in each node. RPL does not need converge, and provides 428 connectivity to most nodes most of the time. 430 RPL may form multiple topologies called instances. Instances can be 431 created to enforce various optimizations through objective functions, 432 or to reach out through different Root Nodes. The concept of 433 objective function allows to adapt the activity of the routing 434 protocol to the use case, e.g., type, speed, and quality of the LLN 435 links. 437 RPL instances operate as ships passing in the night, unbeknownst of 438 one another. The RPL Root is responsible to select the RPL Instance 439 that is used to forward a packet coming from the Backbone into the 440 RPL domain and set the related RPL information in the packets. 6TiSCH 441 leverages RPL for its distributed routing operations. 443 To reduce the routing exchanges, RPL leverages an anisotropic 444 Distance Vector approach, which does not need a global knowledge of 445 the topology, and only optimizes the routes to and from the RPL Root, 446 allowing P2P paths to be stretched. Although RPL installs its routes 447 proactively, it only maintains them lazily, in reaction to actual 448 traffic, or as a slow background activity. 450 This is simple and efficient in situations where the traffic is 451 mostly directed from or to a central node, such as the control 452 traffic between routers and a controller of a Software Defined 453 Networking (SDN) infrastructure or an Autonomic Control Plane (ACP). 455 But stretch in P2P routing is counter-productive to both reliability 456 and latency as it introduces additional delay and chances of loss. 457 As a result, [RPL] is not a good fit for the use cases listed in the 458 RAW use cases document [USE-CASES], which demand high availability 459 and reliability, and as a consequence require both short and diverse 460 paths. 462 3.2. RPL Routing Modes 464 RPL first forms a default route in each node towards the a Root, and 465 those routes together coalesce as a Directed Acyclic Graph upwards. 466 RPL then constructs routes to destinations signaled as Targets in the 467 reverse direction, down the same DODAG. So do so, a RPL Instance can 468 be operated either in RPL Storing or Non-Storing Mode of Operation 469 (MOP). The default route towards the Root is maintained aggressively 470 and may change while a packet progresses without causing loops, so 471 the packet will still reach the Root. 473 In Non-Storing Mode, each node advertises itself as a Target directly 474 to the Root, indicating the parents that may be used to reach self. 475 Recursively, the Root builds and maintains an image of the whole 476 DODAG in memory, and leverages that abstraction to compute source 477 route paths for the packets to their destinations down the DODAG. 478 When a node changes its point(s) of attachment to the DODAG, it takes 479 single unicast packet to the Root along the default route to update 480 it, and the connectivity is restored immediately; this mode is 481 preferable for use cases where internet connectivity is dominant, or 482 when, like here, the Root controls the network activity in the nodes. 484 In Storing Mode, the routing information percolates upwards, and each 485 node maintains the routes to the subDAG of its descendants down the 486 DODAG. The maintenance is lazy, either reactive upon traffic or as a 487 slow background process. Packets flow via the common parent and the 488 routing stretch is reduced vs. Non-Storing, for a better P2P 489 connectivity. On the other hand, a new route takes a longer time to 490 propagate to the Root, time for the Distance-Vector protocol to 491 operate hop-by-hop, and the Internet connectivity is restored more 492 slowly upon movement. 494 Either way, the RPL routes are injected by the Target nodes, in a 495 distributed fashion. To complement RPL and eliminate routing 496 stretch, this specification introduces an hybrid mode that combines 497 Storing and Non-Storing operations to build and project routes onto 498 the nodes where they should be installed. This specification uses 499 the term Projected Route (P-Route) to refer to those routes. 501 A P-Route may be installed in either Storing and Non-Storing Mode, 502 potentially resulting in hybrid situations where the Mode of the P- 503 Route is different from that of the RPL Main DODAG. P-Routes can be 504 used as stand-alone segments to reduce the size of the source routing 505 headers with loose source routing operations down the main RPL DODAG. 506 P-Routes can also be combined with other P-Routes to form a more 507 complex forwarding graph called a Track. 509 3.3. Requirements 511 3.3.1. Loose Source Routing 513 A RPL implementation operating in a very constrained LLN typically 514 uses the Non-Storing Mode of Operation as represented in Figure 2. 515 In that mode, a RPL node indicates a parent-child relationship to the 516 Root, using a destination Advertisement Object (DAO) that is unicast 517 from the node directly to the Root, and the Root typically builds a 518 source routed path to a destination down the DODAG by recursively 519 concatenating this information. 521 +-----+ 522 | | Border router 523 | | (RPL Root) 524 +-----+ ^ | | 525 | | DAO | ACK | 526 o o o o | | | Strict 527 o o o o o o o o o | | | Source 528 o o o o o o o o o o | | | Route 529 o o o o o o o o o | | | 530 o o o o o o o o | v v 531 o o o o 532 LLN 534 Figure 2: RPL Non-Storing Mode of operation 536 Based on the parent-children relationships expressed in the Non- 537 Storing DAO messages, the Root possesses topological information 538 about the whole network, though this information is limited to the 539 structure of the DODAG for which it is the destination. A packet 540 that is generated within the domain will always reach the Root, which 541 can then apply a source routing information to reach the destination 542 if the destination is also in the DODAG. Similarly, a packet coming 543 from the outside of the domain for a destination that is expected to 544 be in a RPL domain reaches the Root. It results that the wireless 545 bandwidth near the Root is the gating factor for all transmissions 546 towards or within the domain, and that the Root is a single point of 547 failure for all connectivity to nodes within its domain. 549 The RPL Root must add a source routing header to all downward 550 packets. As a network grows, the size of the source routing header 551 augments with the depth of the nodes. In some use cases, a RPL 552 network forms long lines along physical structures such as streets 553 for lighting. Limiting the packet size is directly beneficial to the 554 energy budget, but, mostly, it reduces the chances of frame loss and 555 packet fragmentation, which are highly detrimental to the LLN 556 operation. A limited amount of well-targeted routing state would 557 allow the source routing operation to be loose as opposed to strict, 558 and save packet size. Because the capability to store a routing 559 state in every node is limited, the decision of which route is 560 installed where can only be optimized with a global knowledge of the 561 system, a knowledge that the Root or an associated PCE may possess by 562 means that are outside of the scope of this specification. 564 Being on path for all packets in Non-Storing mode, the Root may 565 determine the number of P2P packets in its RPL domain per source and 566 destination, the latency incurred, and the amount of energy and 567 bandwidth that is consumed to reach the self and then down, including 568 a possible fragmentation when encapsulating larger packets. Enabling 569 a shorter path that would not traverse the Root for select P2P 570 source/destinations may improve the latency, lower the consumption of 571 constrained resources, free bandwidth at the bottleneck near the 572 Root, improve the delivery ratio and reduce the latency for those P2P 573 flows with a global benefit for all flows of reducing the load at the 574 Root. 576 This requirement is to store a routing state associated with the Main 577 DODAG in selected RPL routers, to limit the excursion of the source 578 route headers in deep networks. The Root may elide the sequence of 579 routers that is installed in the network from its source route 580 header, which becomes loose while it is strict in [RPL]. 582 3.3.2. East-West Routes 584 [RPL] optimizes Point-to-Multipoint (P2MP) routes from the Root, 585 Multipoint-to-Point (MP2P) routes to the DODAG Root, and Internet 586 access when the Root also serves as Border Router. All routes are 587 installed North-South (aka up/down) along the RPL DODAG. Peer to 588 Peer (P2P) East-West routes in a RPL network will generally suffer 589 from some elongated (stretched) path versus a direct (optimized) 590 path, since routing between two nodes always happens via a common 591 parent, as illustrated in Figure 3: 593 ------+--------- 594 | Internet 595 +-----+ 596 | | Border router 597 | | (RPL Root) 598 +-----+ 599 X 600 ^ v o o 601 ^ o o v o o o o o 602 ^ o o o v o o o o o 603 ^ o o v o o o o o 604 S o o o D o o o 605 o o o o 606 LLN 608 Figure 3: Routing Stretch between S and D via common parent X 609 along North-South Paths 611 As described in [RFC9008], the amount of stretch depends on the Mode 612 of Operation: 614 * in Non-Storing Mode, all packets routed within the DODAG flow all 615 the way up to the Root of the DODAG. If the destination is in the 616 same DODAG, the Root must encapsulate the packet to place an RH 617 that has the strict source route information down the DODAG to the 618 destination. This will be the case even if the destination is 619 relatively close to the source and the Root is relatively far off. 621 * In Storing Mode, unless the destination is a child of the source, 622 the packets will follow the default route up the DODAG as well. 623 If the destination is in the same DODAG, they will eventually 624 reach a common parent that has a route to the destination; at 625 worse, the common parent may also be the Root. From that common 626 parent, the packet will follow a path down the DODAG that is 627 optimized for the Objective Function that was used to build the 628 DODAG. 630 It results that it is often beneficial to enable East-West P2P 631 routes, either if the RPL route presents a stretch from shortest 632 path, or if the new route is engineered with a different objective, 633 and that it is even more critical in Non-Storing Mode than it is in 634 Storing Mode, because the routing stretch is wider. For that reason, 635 earlier work at the IETF introduced the "Reactive Discovery of 636 Point-to-Point Routes in Low Power and Lossy Networks" [RFC6997], 637 which specifies a distributed method for establishing optimized P2P 638 routes. This draft proposes an alternate based on a centralized 639 route computation. 641 +-----+ 642 | | Border router 643 | | (RPL Root) 644 +-----+ 645 | 646 o o o o 647 o o o o o o o o o 648 o o o o o o o o o o 649 o o o o o o o o o 650 S>>A>>>B>>C>>>D o o o 651 o o o o 652 LLN 654 Figure 4: More direct East-West Route between S and D 656 The requirement is to install additional routes in the RPL routers, 657 to reduce the stretch of some P2P routes and maintain the 658 characteristics within a given SLO, e.g., in terms of latency and/or 659 reliability. 661 3.4. On Tracks 663 3.4.1. Building Tracks With RPL 665 The concept of a Track was introduced in the "6TiSCH Architecture" 666 [RFC9030], as a collection of potential paths that leverage redundant 667 forwarding solutions along the way. This can be a DODAG or a more 668 complex structure that is only partially acyclic (e.g., per packet). 670 With this specification, a Track is shaped as a DODAG, and following 671 the directed edges leads to a Track Ingress. Storing Mode P-DAO 672 messages follow the direction of the edges to set up routes for 673 traffic that flows the other way, towards the Track Egress(es). If 674 there is a single Track Egress, then the Track is reversible to form 675 another DODAG by reversing the direction of each edge. A node at the 676 Ingress of more than one Segment in a Track may use one or more of 677 these Segments to forward a packet inside the Track. 679 A RPL Track is a collection of (one or more) parallel loose source 680 routed sequences of nodes ordered from Ingress to Egress, each 681 forming a Track Leg. The nodes that are directly connected, 682 reachable via existing Tracks as illustrated in Section 3.5.2.3 or 683 joined with strict Segments of other nodes as shown in 684 Section 3.5.1.3. The Legs are expressed in RPL Non-Storing Mode and 685 require an encapsulation to add a Source Route Header, whereas the 686 Segments are expressed in RPL Storing Mode. 688 A Serial Track comprises provides only one path between Ingress and 689 Egress. It comprises at most one Leg. A Stand-Alone Segment 690 implicitly defines a Serial Track from its Ingress to Egress. 692 A complex Track forms a graph that provides a collection of potential 693 paths to provide redundancy for the packets, either as a collection 694 of Legs that may be parallel or cross at certain points, or as a more 695 generic DODAG. 697 3.4.2. Tracks and RPL Instances 699 Section 5.1. of [RPL] describes the RPL Instance and its encoding. 700 There can be up to 128 global RPL Instances, for which there can be 701 one or more DODAGs, and there can be 64 local RPL Instances, with a 702 namespace that is indexed by a DODAGID, where the DODAGID is a Unique 703 Local Address (ULA) or a Global Unicast Address (GUA) of the Root of 704 the DODAG. Bit 0 (most significant) is set to 1 to signal a Local 705 RPLInstanceID, as shown in Figure 5. By extension, this 706 specification expresses the value of the RPLInstanceID as a single 707 integer between 128 and 191, representing both the Local 708 RPLInstanceID in 0..63 and Bit 0 set. 710 0 1 2 3 4 5 6 7 711 +-+-+-+-+-+-+-+-+ 712 |1|D| ID | Local RPLInstanceID in 0..63 713 +-+-+-+-+-+-+-+-+ 715 Figure 5: Local RPLInstanceID Encoding 717 A Track is normally associated with a Local RPL Instance which 718 RPLInstanceID is used as the TrackID, more in Section 6.3. A Track 719 Leg may also be used as a subTrack that extends the RPL main DODAG. 720 In that case, the TrackID is set to the global RPLInstanceID of the 721 main DODAG, which suffices to identify the routing topology. As 722 opposed to local RPL instances, the Track Ingress that encapsulates 723 the packets over a subtrack is not Root, and that the source address 724 of the encapsulated packet is not used to determine the Track. 726 3.5. Serial Track Signaling 728 This specification enables to set up a P-Route along either a Track 729 Leg or a Segment. A P-Route is installed and maintained by the Root 730 of the main DODAG using an extended RPL DAO message called a 731 Projected DAO (P-DAO), and a Track is composed of the combination of 732 one or more P-Routes. 734 A P-DAO message for a Track signals the TrackID in the RPLInstanceID 735 field. In the case of a local RPL Instance, the address of the Track 736 Ingress is used as source to encapsulate packets along the Track. 737 The Track is signaled in the DODAGID field of the Projected DAO Base 738 Object, see Figure 8. 740 This specification introduces the Via Information Option (VIO) to 741 signal a sequence of hops in a Leg or a Segment in the P-DAO 742 messages, either in Storing Mode (SM-VIO) or Non-Storing Mode (NSM- 743 VIO). One P-DAO messages contains a single VIO, associated to one or 744 more RPL Target Options that signal the destination IPv6 addresses 745 that can reached along the Track, more in Section 5.3. 747 Before diving deeper into Track Legs and Segments signaling and 748 operation, this section provides examples of what how route 749 projection works through variations of a simple example. This simple 750 example illustrates the case of host routes, though RPL Targets can 751 be prefixes. 753 Say we want to build a Serial Track from node A to E in Figure 6, so 754 A can route packets to E's neighbors F and G along A, B, C, D and E 755 as opposed to via the Root: 757 /===> F 758 A ===> B ===> C ===> D===> E < 759 \===> G 761 Figure 6: Reference Track 763 Conventionally we use ==> to represent a strict hop and --> for a 764 loose hop. We use "-to-", such as in C==>D==>E-to-F to represent 765 coma-separated Targets, e.g., F is a Target for Segment C==>D==>E. 766 In this example, A is Track Ingress, E is Track Egress. C is a 767 stitching point. F and G are "external" Targets for the Track, and 768 become reachable from A via the Track A(ingress) to E (Egress and 769 implicit Target in Non-Storing Mode) leading to F and G (explicit 770 Targets). 772 Figure 5 depicts the format of the RPLInstanceID encoding for a local 773 RPLInstanceID . 775 In a general manner the desired outcome is as follows: 777 * Targets are E, F, and G 779 * P-DAO 1 signals C==>D==>E 780 * P-DAO 2 signals A==>B==>C 782 * P-DAO 3 signals F and G via the A-->E Track 784 P-DAO 3 may be ommitted if P-DAO 1 and 2 signal F and G as Targets. 786 Loose sequences of hops must be expressed in Non-Storing Mode, so 787 P-DAO 3 contains a NSM-VIO. With this specification, the DODAGID to 788 be used by the Ingress as source address is signaled if needed in the 789 DAO base object, the via list starts at the first loose hop and 790 matches the source route header, and the Egress of a Non-Storing Mode 791 P-DAO is an implicit Target that is not listed in the RTO. 793 3.5.1. Using Storing Mode Segments 795 A==>B==>C and C==>D==>E are segments of a same Track. Note that the 796 Storing Mode signaling imposes strict continuity in a segment, since 797 the P-DAO is passed hop by hop, as a classical DAO is, along the 798 reverse datapath that it signals. One benefit of strict routing is 799 that loops are avoided along the Track. 801 3.5.1.1. Stitched Segments 803 In this formulation: 805 * P-DAO 1 signals C==>D==>E-to-F,G 807 * P-DAO 2 signals A==>B==>C-to-F,G 809 Storing Mode P-DAO 1 is sent to E and when it is succesfully 810 acknowledged, Storing Mode P-DAO 2 is sent to C, as follows: 812 +====================+==============+==============+ 813 | Field | P-DAO 1 to E | P-DAO 2 to C | 814 +====================+==============+==============+ 815 | Mode | Storing | Storing | 816 +--------------------+--------------+--------------+ 817 | Track Ingress | A | A | 818 +--------------------+--------------+--------------+ 819 | (DODAGID, TrackID) | (A, 129) | (A, 129) | 820 +--------------------+--------------+--------------+ 821 | SegmentID | 1 | 2 | 822 +--------------------+--------------+--------------+ 823 | VIO | C, D, E | A, B, C | 824 +--------------------+--------------+--------------+ 825 | Targets | F, G | F, G | 826 +--------------------+--------------+--------------+ 828 Table 1: P-DAO Messages 830 As a result the RIBs are set as follows: 832 +======+=============+=========+=============+==========+ 833 | Node | destination | Origin | Next Hop(s) | TrackID | 834 +======+=============+=========+=============+==========+ 835 | E | F, G | P-DAO 1 | Neighbor | (A, 129) | 836 +------+-------------+---------+-------------+----------+ 837 | D | E | P-DAO 1 | Neighbor | (A, 129) | 838 +------+-------------+---------+-------------+----------+ 839 | " | F, G | P-DAO 1 | E | (A, 129) | 840 +------+-------------+---------+-------------+----------+ 841 | C | D | P-DAO 1 | Neighbor | (A, 129) | 842 +------+-------------+---------+-------------+----------+ 843 | " | F, G | P-DAO 1 | D | (A, 129) | 844 +------+-------------+---------+-------------+----------+ 845 | B | C | P-DAO 2 | Neighbor | (A, 129) | 846 +------+-------------+---------+-------------+----------+ 847 | " | F, G | P-DAO 2 | C | (A, 129) | 848 +------+-------------+---------+-------------+----------+ 849 | A | B | P-DAO 2 | Neighbor | (A, 129) | 850 +------+-------------+---------+-------------+----------+ 851 | " | F, G | P-DAO 2 | B | (A, 129) | 852 +------+-------------+---------+-------------+----------+ 854 Table 2: RIB setting 856 Packets originated by A to F or G do not require an encapsulation as 857 the RPI can be placed in the native header chain. For packets that 858 it routes, A must encapsulate to add the RPI that signals the 859 trackID; the outer headers of the packets that are forwarded along 860 the Track have the following settings: 862 +========+===================+===================+================+ 863 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 864 +========+===================+===================+================+ 865 | Outer | A | F or G | (A, 129) | 866 +--------+-------------------+-------------------+----------------+ 867 | Inner | X != A | F or G | N/A | 868 +--------+-------------------+-------------------+----------------+ 870 Table 3: Packet Header Settings 872 As an example, say that A has a packet for F. Using the RIB above: 874 * From P-DAO 2: A forwards to B and B forwards to C. 876 * From P-DAO 1: C forwards to D and D forwards to E. 878 * From Neighbor Cache Entry: E delivers the packet to F. 880 3.5.1.2. External routes 882 In this example, we consider F and G as destinations that are 883 external to the Track as a DODAG, as discussed in section 4.1.1. of 884 [RFC9008]. We then apply the directives for encapsulating in that 885 case, more in Section 6.7. 887 In this formulation, we set up the Track Leg explicitly, which 888 creates less routing state in intermediate hops at the expense of 889 larger packets to accommodate source routing: 891 * P-DAO 1 signals C==>D==>E-to-E 893 * P-DAO 2 signals A==>B==>C-to-E 895 * P-DAO 3 signals F and G via the A-->E-to-F,G Track 897 Storing Mode P-DAO 1 and 2, and Non-Storing Mode P-DAO 3, are sent to 898 E, C and A, respectively, as follows: 900 +====================+==============+==============+==============+ 901 | | P-DAO 1 to E | P-DAO 2 to C | P-DAO 3 to A | 902 +====================+==============+==============+==============+ 903 | Mode | Storing | Storing | Non-Storing | 904 +--------------------+--------------+--------------+--------------+ 905 | Track Ingress | A | A | A | 906 +--------------------+--------------+--------------+--------------+ 907 | (DODAGID, TrackID) | (A, 129) | (A, 129) | (A, 129) | 908 +--------------------+--------------+--------------+--------------+ 909 | SegmentID | 1 | 2 | 3 | 910 +--------------------+--------------+--------------+--------------+ 911 | VIO | C, D, E | A, B, C | E | 912 +--------------------+--------------+--------------+--------------+ 913 | Targets | E | E | F, G | 914 +--------------------+--------------+--------------+--------------+ 916 Table 4: P-DAO Messages 918 Note in the above that E is not an implicit Target in Storing mode, 919 so it must be added in the RTO. 921 As a result the RIBs are set as follows: 923 +======+=============+=========+=============+==========+ 924 | Node | destination | Origin | Next Hop(s) | TrackID | 925 +======+=============+=========+=============+==========+ 926 | E | F, G | P-DAO 1 | Neighbor | (A, 129) | 927 +------+-------------+---------+-------------+----------+ 928 | D | E | P-DAO 1 | Neighbor | (A, 129) | 929 +------+-------------+---------+-------------+----------+ 930 | C | D | P-DAO 1 | Neighbor | (A, 129) | 931 +------+-------------+---------+-------------+----------+ 932 | " | E | P-DAO 1 | D | (A, 129) | 933 +------+-------------+---------+-------------+----------+ 934 | B | C | P-DAO 2 | Neighbor | (A, 129) | 935 +------+-------------+---------+-------------+----------+ 936 | " | E | P-DAO 2 | C | (A, 129) | 937 +------+-------------+---------+-------------+----------+ 938 | A | B | P-DAO 2 | Neighbor | (A, 129) | 939 +------+-------------+---------+-------------+----------+ 940 | " | E | P-DAO 2 | B | (A, 129) | 941 +------+-------------+---------+-------------+----------+ 942 | " | F, G | P-DAO 3 | E | (A, 129) | 943 +------+-------------+---------+-------------+----------+ 945 Table 5: RIB setting 947 Packets from A to E do not require an encapsulation. The outer 948 headers of the packets that are forwarded along the Track have the 949 following settings: 951 +========+===================+====================+================+ 952 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 953 +========+===================+====================+================+ 954 | Outer | A | E | (A, 129) | 955 +--------+-------------------+--------------------+----------------+ 956 | Inner | X | E (X != A), F or G | N/A | 957 +--------+-------------------+--------------------+----------------+ 959 Table 6: Packet Header Settings 961 As an example, say that A has a packet for F. Using the RIB above: 963 * From P-DAO 3: A encapsulates the packet the Track signaled by 964 P-DAO 3, with the outer header above. Now the packet destination 965 is E. 967 * From P-DAO 2: A forwards to B and B forwards to C. 969 * From P-DAO 1: C forwards to D and D forwards to E; E decapsulates 970 the packet. 972 * From Neighbor Cache Entry: E delivers packets to F or G. 974 3.5.1.3. Segment Routing 976 In this formulation leverages Track Legs to combine Segments and form 977 a Graph. The packets are source routed from a Segment to the next to 978 adapt the path. As such, this can be seen as a form of Segment 979 Routing [RFC8402]: 981 * P-DAO 1 signals C==>D==>E-to-E 983 * P-DAO 2 signals A==>B-to-B,C 985 * P-DAO 3 signals F and G via the A-->C-->E-to-F,G Track 987 Storing Mode P-DAO 1 and 2, and Non-Storing Mode P-DAO 3, are sent to 988 E, B and A, respectively, as follows: 990 +====================+==============+==============+==============+ 991 | | P-DAO 1 to E | P-DAO 2 to B | P-DAO 3 to A | 992 +====================+==============+==============+==============+ 993 | Mode | Storing | Storing | Non-Storing | 994 +--------------------+--------------+--------------+--------------+ 995 | Track Ingress | A | A | A | 996 +--------------------+--------------+--------------+--------------+ 997 | (DODAGID, TrackID) | (A, 129) | (A, 129) | (A, 129) | 998 +--------------------+--------------+--------------+--------------+ 999 | SegmentID | 1 | 2 | 3 | 1000 +--------------------+--------------+--------------+--------------+ 1001 | VIO | C, D, E | A, B | C, E | 1002 +--------------------+--------------+--------------+--------------+ 1003 | Targets | E | C | F, G | 1004 +--------------------+--------------+--------------+--------------+ 1006 Table 7: P-DAO Messages 1008 Note in the above that the Segment can terminate at the loose hop as 1009 used in the example of P-DAO 1 or at the previous hop as done with 1010 P-DAO 2. Both methods are possible on any Segment joined by a loose 1011 Track Leg. P-DAO 1 generates more signaling since E is the Segment 1012 Egress when D could be, but has the benefit that it validates that 1013 the connectivity between D and E still exists. 1015 As a result the RIBs are set as follows: 1017 +======+=============+=========+=============+==========+ 1018 | Node | destination | Origin | Next Hop(s) | TrackID | 1019 +======+=============+=========+=============+==========+ 1020 | E | F, G | P-DAO 1 | Neighbor | (A, 129) | 1021 +------+-------------+---------+-------------+----------+ 1022 | D | E | P-DAO 1 | Neighbor | (A, 129) | 1023 +------+-------------+---------+-------------+----------+ 1024 | C | D | P-DAO 1 | Neighbor | (A, 129) | 1025 +------+-------------+---------+-------------+----------+ 1026 | " | E | P-DAO 1 | D | (A, 129) | 1027 +------+-------------+---------+-------------+----------+ 1028 | B | C | P-DAO 2 | Neighbor | (A, 129) | 1029 +------+-------------+---------+-------------+----------+ 1030 | A | B | P-DAO 2 | Neighbor | (A, 129) | 1031 +------+-------------+---------+-------------+----------+ 1032 | " | C | P-DAO 2 | B | (A, 129) | 1033 +------+-------------+---------+-------------+----------+ 1034 | " | E, F, G | P-DAO 3 | C, E | (A, 129) | 1035 +------+-------------+---------+-------------+----------+ 1037 Table 8: RIB setting 1039 Packets originated at A to E do not require an encapsulation, but 1040 carry a SRH via C. The outer headers of the packets that are 1041 forwarded along the Track have the following settings: 1043 +========+===================+====================+================+ 1044 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1045 +========+===================+====================+================+ 1046 | Outer | A | C till C then E | (A, 129) | 1047 +--------+-------------------+--------------------+----------------+ 1048 | Inner | X | E (X != A), F or G | N/A | 1049 +--------+-------------------+--------------------+----------------+ 1051 Table 9: Packet Header Settings 1053 As an example, say that A has a packet for F. Using the RIB above: 1055 * From P-DAO 3: A encapsulates the packet the Track signaled by 1056 P-DAO 3, with the outer header above. Now the destination in the 1057 IPv6 Header is C, and a SRH signals the final destination is E. 1059 * From P-DAO 2: A forwards to B and B forwards to C. 1061 * From P-DAO 3: C processes the SRH and sets the destination in the 1062 IPv6 Header to E. 1064 * From P-DAO 1: C forwards to D and D forwards to E; E decapsulates 1065 the packet. 1067 * From the Neighbor Cache Entry: E delivers packets to F or G. 1069 3.5.2. Using Non-Storing Mode joining Tracks 1071 In this formulation: 1073 * P-DAO 1 signals C==>D==>E-to-F,G 1075 * P-DAO 2 signals A==>B==>C-to-E,F,G 1077 A==>B==>C and C==>D==>E are Tracks expressed as Non-Storing P-DAOs. 1079 3.5.2.1. Stitched Tracks 1081 Non-Storing Mode P-DAO 1 and 2 are sent to C and A respectively, as 1082 follows: 1084 +====================+==============+==============+ 1085 | | P-DAO 1 to C | P-DAO 2 to A | 1086 +====================+==============+==============+ 1087 | Mode | Non-Storing | Non-Storing | 1088 +--------------------+--------------+--------------+ 1089 | Track Ingress | C | A | 1090 +--------------------+--------------+--------------+ 1091 | (DODAGID, TrackID) | (C, 131) | (A, 131) | 1092 +--------------------+--------------+--------------+ 1093 | SegmentID | 1 | 1 | 1094 +--------------------+--------------+--------------+ 1095 | VIO | D, E | B, C | 1096 +--------------------+--------------+--------------+ 1097 | Targets | F, G | E, F, G | 1098 +--------------------+--------------+--------------+ 1100 Table 10: P-DAO Messages 1102 As a result the RIBs are set as follows: 1104 +======+=============+=========+=============+==========+ 1105 | Node | destination | Origin | Next Hop(s) | TrackID | 1106 +======+=============+=========+=============+==========+ 1107 | E | F, G | ND | Neighbor | Any | 1108 +------+-------------+---------+-------------+----------+ 1109 | D | E | ND | Neighbor | Any | 1110 +------+-------------+---------+-------------+----------+ 1111 | C | D | ND | Neighbor | Any | 1112 +------+-------------+---------+-------------+----------+ 1113 | " | E, F, G | P-DAO 1 | D, E | (C, 131) | 1114 +------+-------------+---------+-------------+----------+ 1115 | B | C | ND | Neighbor | Any | 1116 +------+-------------+---------+-------------+----------+ 1117 | A | B | ND | Neighbor | Any | 1118 +------+-------------+---------+-------------+----------+ 1119 | " | C, E, F, G | P-DAO 2 | B, C | (A, 131) | 1120 +------+-------------+---------+-------------+----------+ 1122 Table 11: RIB setting 1124 Packets originated at A to E, F and G do not require an 1125 encapsulation, though it is preferred that A encapsulates and C 1126 decapsulates. Either way, they carry a SRH via B and C, and C needs 1127 to encapsulate to E, F, or G to add an SRH via D and E. The 1128 encapsulating headers of packets that are forwarded along the Track 1129 between C and E have the following settings: 1131 +========+===================+===================+================+ 1132 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1133 +========+===================+===================+================+ 1134 | Outer | C | D till D then E | (C, 131) | 1135 +--------+-------------------+-------------------+----------------+ 1136 | Inner | X | E, F, or G | N/A | 1137 +--------+-------------------+-------------------+----------------+ 1139 Table 12: Packet Header Settings between C and E 1141 As an example, say that A has a packet for F. Using the RIB above: 1143 * From P-DAO 2: A encapsulates the packet with destination of F in 1144 the Track signaled by P-DAO 2. The outer header has source A, 1145 destination B, an SRH that indicates C as the next loose hop, and 1146 a RPI indicating a TrackId of 131 from A's namespace, which is 1147 distinct from TrackId of 131 from C's. 1149 * From the SRH: Packets forwarded by B have source A, destination C, 1150 a consumed SRH, and a RPI indicating a TrackId of 131 from A's 1151 namespace. C decapsulates. 1153 * From P-DAO 1: C encapsulates the packet with destination of F in 1154 the Track signaled by P-DAO 1. The outer header has source C, 1155 destination D, an SRH that indicates E as the next loose hop, and 1156 a RPI indicating a TrackId of 131 from C's namespace. E 1157 decapsulates. 1159 3.5.2.2. External routes 1161 In this formulation: 1163 * P-DAO 1 signals C==>D==>E-to-E 1165 * P-DAO 2 signals A==>B==>C-to-C,E 1167 * P-DAO 3 signals F and G via the A-->E-to-F,G Track 1169 Non-Storing Mode P-DAO 1 is sent to C and Non-Storing Mode P-DAO 2 1170 and 3 are sent A, as follows: 1172 +====================+==============+==============+==============+ 1173 | | P-DAO 1 to C | P-DAO 2 to A | P-DAO 3 to A | 1174 +====================+==============+==============+==============+ 1175 | Mode | Non-Storing | Non-Storing | Non-Storing | 1176 +--------------------+--------------+--------------+--------------+ 1177 | Track Ingress | C | A | A | 1178 +--------------------+--------------+--------------+--------------+ 1179 | (DODAGID, TrackID) | (C, 131) | (A, 129) | (A, 141) | 1180 +--------------------+--------------+--------------+--------------+ 1181 | SegmentID | 1 | 1 | 1 | 1182 +--------------------+--------------+--------------+--------------+ 1183 | VIO | D, E | B, C | E | 1184 +--------------------+--------------+--------------+--------------+ 1185 | Targets | E | E | F, G | 1186 +--------------------+--------------+--------------+--------------+ 1188 Table 13: P-DAO Messages 1190 As a result the RIBs are set as follows: 1192 +======+=============+=========+=============+==========+ 1193 | Node | destination | Origin | Next Hop(s) | TrackID | 1194 +======+=============+=========+=============+==========+ 1195 | E | F, G | ND | Neighbor | Any | 1196 +------+-------------+---------+-------------+----------+ 1197 | D | E | ND | Neighbor | Any | 1198 +------+-------------+---------+-------------+----------+ 1199 | C | D | ND | Neighbor | Any | 1200 +------+-------------+---------+-------------+----------+ 1201 | " | E | P-DAO 1 | D, E | (C, 131) | 1202 +------+-------------+---------+-------------+----------+ 1203 | B | C | ND | Neighbor | Any | 1204 +------+-------------+---------+-------------+----------+ 1205 | A | B | ND | Neighbor | Any | 1206 +------+-------------+---------+-------------+----------+ 1207 | " | C, E | P-DAO 2 | B, C | (A, 129) | 1208 +------+-------------+---------+-------------+----------+ 1209 | " | F, G | P-DAO 3 | E | (A, 141) | 1210 +------+-------------+---------+-------------+----------+ 1212 Table 14: RIB setting 1214 The encapsulating headers of packets that are forwarded along the 1215 Track between C and E have the following settings: 1217 +========+===================+===================+================+ 1218 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1219 +========+===================+===================+================+ 1220 | Outer | C | D till D then E | (C, 131) | 1221 +--------+-------------------+-------------------+----------------+ 1222 | Middle | A | E | (A, 141) | 1223 +--------+-------------------+-------------------+----------------+ 1224 | Inner | X | E, F or G | N/A | 1225 +--------+-------------------+-------------------+----------------+ 1227 Table 15: Packet Header Settings 1229 As an example, say that A has a packet for F. Using the RIB above: 1231 * From P-DAO 3: A encapsulates the packet with destination of F in 1232 the Track signaled by P-DAO 3. The outer header has source A, 1233 destination E, and a RPI indicating a TrackId of 141 from A's 1234 namespace. This recurses with: 1236 * From P-DAO 2: A encapsulates the packet with destination of E in 1237 the Track signaled by P-DAO 2. The outer header has source A, 1238 destination B, an SRH that indicates C as the next loose hop, and 1239 a RPI indicating a TrackId of 129 from A's namespace. 1241 * From the SRH: Packets forwarded by B have source A, destination C 1242 , a consumed SRH, and a RPI indicating a TrackId of 129 from A's 1243 namespace. C decapsulates. 1245 * From P-DAO 1: C encapsulates the packet with destination of E in 1246 the Track signaled by P-DAO 1. The outer header has source C, 1247 destination D, an SRH that indicates E as the next loose hop, and 1248 a RPI indicating a TrackId of 131 from C's namespace. E 1249 decapsulates. 1251 3.5.2.3. Segment Routing 1253 In this formulation: 1255 * P-DAO 1 signals C==>D==>E-to-E 1257 * P-DAO 2 signals A==>B-to-C 1259 * P-DAO 3 signals F and G via the A-->C-->E-to-F,G Track 1261 Non-Storing Mode P-DAO 1 is sent to C and Non-Storing Mode P-DAO 2 1262 and 3 are sent A, as follows: 1264 +====================+==============+==============+==============+ 1265 | | P-DAO 1 to C | P-DAO 2 to A | P-DAO 3 to A | 1266 +====================+==============+==============+==============+ 1267 | Mode | Non-Storing | Non-Storing | Non-Storing | 1268 +--------------------+--------------+--------------+--------------+ 1269 | Track Ingress | C | A | A | 1270 +--------------------+--------------+--------------+--------------+ 1271 | (DODAGID, TrackID) | (C, 131) | (A, 129) | (A, 141) | 1272 +--------------------+--------------+--------------+--------------+ 1273 | SegmentID | 1 | 1 | 1 | 1274 +--------------------+--------------+--------------+--------------+ 1275 | VIO | D, E | B | C, E | 1276 +--------------------+--------------+--------------+--------------+ 1277 | Targets | | C | F, G | 1278 +--------------------+--------------+--------------+--------------+ 1280 Table 16: P-DAO Messages 1282 As a result the RIBs are set as follows: 1284 +======+=============+=========+=============+==========+ 1285 | Node | destination | Origin | Next Hop(s) | TrackID | 1286 +======+=============+=========+=============+==========+ 1287 | E | F, G | ND | Neighbor | Any | 1288 +------+-------------+---------+-------------+----------+ 1289 | D | E | ND | Neighbor | Any | 1290 +------+-------------+---------+-------------+----------+ 1291 | C | D | ND | Neighbor | Any | 1292 +------+-------------+---------+-------------+----------+ 1293 | " | E | P-DAO 1 | D, E | (C, 131) | 1294 +------+-------------+---------+-------------+----------+ 1295 | B | C | ND | Neighbor | Any | 1296 +------+-------------+---------+-------------+----------+ 1297 | A | B | ND | Neighbor | Any | 1298 +------+-------------+---------+-------------+----------+ 1299 | " | C | P-DAO 2 | B, C | (A, 129) | 1300 +------+-------------+---------+-------------+----------+ 1301 | " | E, F, G | P-DAO 3 | C, E | (A, 141) | 1302 +------+-------------+---------+-------------+----------+ 1304 Table 17: RIB setting 1306 The encapsulating headers of packets that are forwarded along the 1307 Track between A and B have the following settings: 1309 +========+===================+===================+================+ 1310 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1311 +========+===================+===================+================+ 1312 | Outer | A | B till D then E | (A, 129) | 1313 +--------+-------------------+-------------------+----------------+ 1314 | Middle | A | C | (A, 141) | 1315 +--------+-------------------+-------------------+----------------+ 1316 | Inner | X | E, F or G | N/A | 1317 +--------+-------------------+-------------------+----------------+ 1319 Table 18: Packet Header Settings 1321 The encapsulating headers of packets that are forwarded along the 1322 Track between B and C have the following settings: 1324 +========+===================+===================+================+ 1325 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1326 +========+===================+===================+================+ 1327 | Outer | A | C | (A, 141) | 1328 +--------+-------------------+-------------------+----------------+ 1329 | Inner | X | E, F or G | N/A | 1330 +--------+-------------------+-------------------+----------------+ 1332 Table 19: Packet Header Settings 1334 The encapsulating headers of packets that are forwarded along the 1335 Track between C and E have the following settings: 1337 +========+===================+===================+================+ 1338 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1339 +========+===================+===================+================+ 1340 | Outer | C | D till D then E | (C, 131) | 1341 +--------+-------------------+-------------------+----------------+ 1342 | Middle | A | E | (A, 141) | 1343 +--------+-------------------+-------------------+----------------+ 1344 | Inner | X | E, F or G | N/A | 1345 +--------+-------------------+-------------------+----------------+ 1347 Table 20: Packet Header Settings 1349 As an example, say that A has a packet for F. Using the RIB above: 1351 * From P-DAO 3: A encapsulates the packet with destination of F in 1352 the Track signaled by P-DAO 3. The outer header has source A, 1353 destination C, an SRH that indicates E as the next loose hop, and 1354 a RPI indicating a TrackId of 141 from A's namespace. This 1355 recurses with: 1357 * From P-DAO 2: A encapsulates the packet with destination of C in 1358 the Track signaled by P-DAO 2. The outer header has source A, 1359 destination B, and a RPI indicating a TrackId of 129 from A's 1360 namespace. B decapsulates forwards to C based on a sibling 1361 connected route. 1363 * From the SRH: C consumes the SRH and makes the destination E. 1365 * From P-DAO 1: C encapsulates the packet with destination of E in 1366 the Track signaled by P-DAO 1. The outer header has source C, 1367 destination D, an SRH that indicates E as the next loose hop, and 1368 a RPI indicating a TrackId of 131 from C's namespace. E 1369 decapsulates. 1371 3.6. Complex Tracks 1373 To increase the reliability of the P2P transmission, this 1374 specification enables to build a collection of Legs between the same 1375 Ingress and Egress Nodes and combine them with the same TrackID, as 1376 shown in Figure 7. Legs may cross at the edges of loose hops or 1377 remain parallel. 1379 The Segments that join the loose hops of a Leg are installed with the 1380 same TrackID as the Leg. But each individual Leg and Segment has its 1381 own P-RouteID which allows it to be managed separately. When Legs 1382 cross within respective Segment, the next loose hop (the current 1383 destination of the packet) indicates which Leg is being followed and 1384 a Segment that can reach that next loose hop is selected. 1386 CPF CPF CPF CPF 1388 Southbound API 1390 _-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._- 1391 _-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._- 1393 +----------+ 1394 | RPL Root | 1395 +----------+ 1396 ( ) 1397 ( ) 1398 ( DODAG ) 1399 ( ) 1400 ( ) 1401 ) 1402 <- Leg 1 B, E -> 1403 <--- Segment 1 A,B ---> <------- Segment 2 C,D,E -------> 1405 FWD --z Relay --z FWD --z FWD Target 1 1406 z-- Node z-- Node z-- Node z-- Node --z / 1407 --z (A) (B) \ (C) (D) z-- / 1408 Track \ Track 1409 Ingress Segment 5 Egress - Tgt 2 1410 (I) \ (E) 1411 --z \ z-- \ 1412 z-- FWD --z FWD --z Relay --z FWD --z \ 1413 Node z-- Node z-- Node z-- Node Target 3 1414 (F) (G) (H) (J) 1416 <------ Segment 3 F,G,H ------> <---- Segment 4 J,E ----> 1417 <- Leg 2 H, E -> 1419 <--- Segment 1 A,B ---> <- S5-> <---- Segment 4 J,E ----> 1420 <- Leg 3 B, H, E -> 1421 ) 1422 ( 1423 ( ) 1425 Figure 7: Segments and Tracks 1427 Note that while this specification enables to build both Segments 1428 inside a Leg (aka East-West), such as Segment 2 above which is within 1429 Leg 1, and Inter-Leg Segments (aka North-South), such as Segment 2 1430 above which joins Leg 1 and Leg 2, it does not signal to the Ingress 1431 which Inter-Leg Segments are available, so the use of North-South 1432 Segments and associated PAREO functions is curently limited. The 1433 only possibility available at this time is to define overlapping Legs 1434 as illustrated in Figure 7, with Leg 3 that is congruent with Leg 1 1435 till node B and congruent with Leg 2 from node H on, abstracting 1436 Segment 5 as an East-West Segment. 1438 3.7. Scope and Expectations 1440 3.7.1. External Dependencies 1442 This specification expects that the RPL Main DODAG is operated in RPL 1443 Non-Storing Mode to sustain the exchanges with the Root. Based on 1444 its comprehensive knowledge of the parent-child relationship, the 1445 Root can form an abstracted view of the whole DODAG topology. THIS 1446 RFC adds the capability for nodes to advertise additional sibling 1447 information to complement the topological awareness of the Root to be 1448 passed on to the PCE, and enable the PCE to build more / better paths 1449 that traverse those siblings. 1451 P-Routes require resources such as routing table space in the routers 1452 and bandwidth on the links; the amount of state that is installed in 1453 each node must be computed to fit within the node's memory, and the 1454 amount of rerouted traffic must fit within the capabilities of the 1455 transmission links. The methods used to learn the node capabilities 1456 and the resources that are available in the devices and in the 1457 network are out of scope for THIS RFC. The method to capture and 1458 report the LLN link capacity and reliability statistics are also out 1459 of scope. They may be fetched from the nodes through network 1460 management functions or other forms of telemetry such as OAM. 1462 3.7.2. Positioning vs. Related IETF Standards 1464 3.7.2.1. Extending 6TiSCH 1466 The "6TiSCH Architecture" [RFC9030] leverages a centralized model 1467 that is similar to that of "Deterministic Networking Architecture" 1468 [RFC8655], whereby the device resources and capabilities are exposed 1469 to an external controller which installs routing states into the 1470 network based on its own objective functions that reside in that 1471 external entity. 1473 3.7.2.2. Mapping to DetNet 1475 DetNet Forwarding Nodes only understand the simple 1-to-1 forwarding 1476 sublayer transport operation along a segment whereas the more 1477 sophisticated Relay nodes can also provide service sublayer functions 1478 such as Replication and Elimination. 1480 One possible mapping between DetNet and this specification is to 1481 signal the Relay Nodes as the hops of a Leg and the forwarding Nodes 1482 as the hops in a Segment that join the Relay nodes as illustrated in 1483 Figure 7. 1485 3.7.2.3. Leveraging PCE 1487 With DetNet and 6TiSCH, the component of the controller that is 1488 responsible of computing routes is a PCE. The PCE computes its 1489 routes based on its own objective functions such as described in 1490 [RFC4655], and typically controls the routes using the PCE Protocol 1491 (PCEP) by [RFC5440]. While this specification expects a PCE and 1492 while PCEP might effectively be used between the Root and the PCE, 1493 the control protocol between the PCE and the Root is out of scope. 1495 This specification also expects a single PCE with a full view of the 1496 network. Distributing the PCE function for a large network is out of 1497 scope. This specification uses the RPL Root as a proxy to the PCE. 1498 The PCE may be collocated with the Root, or may reside in an external 1499 Controller. In that case, the protocol between the Root and the PCE 1500 is out of scope and abstracted by / mapped to RPL inside the DODAG; 1501 one possibility is for the Root to transmit the RPL DAOs with the 1502 SIOs that detail the parent/child and sibling information. 1504 The algorithm to compute the paths and the protocol used by the PCE 1505 and the metrics and link statistics involved in the computation are 1506 also out of scope. The effectiveness of the route computation by the 1507 PCE depends on the quality of the metrics that are reported from the 1508 RPL network. Which metrics are used and how they are reported is out 1509 of scope, but the expectation is that they are mostly of long-term, 1510 statistical nature, and provide visibility on link throughput, 1511 latency, stability and availability over relatively long periods. 1513 3.7.2.4. Providing for RAW 1515 The RAW Architecture [RAW-ARCHI] extends the definition of Track, as 1516 being composed of East-West directional segments and North-South 1517 bidirectional segments, to enable additional path diversity, using 1518 Packet ARQ, Replication, Elimination, and Overhearing (PAREO) 1519 functions over the available paths, to provide a dynamic balance 1520 between the reliability and availability requirements of the flows 1521 and the need to conserve energy and spectrum. This specification 1522 prepares for RAW by setting up the Tracks, but only forms DODAGs, 1523 which are composed of aggregated end-to-end loose source routed Legs, 1524 joined by strict routed Segments, all oriented East-West. 1526 The RAW Architecture defines a dataplane extension of the PCE called 1527 the Path Selection Engine (PSE), that adapts the use of the path 1528 redundancy within a Track to defeat the diverse causes of packet 1529 loss. The PSE controls the forwarding operation of the packets 1530 within a Track This specification can use but does not impose a PSE 1531 and does not provide the policies that wouldselect which packets are 1532 routed through which path within a Track, IOW, how the PSE may use 1533 the path redundancy within the Track. By default, the use of the 1534 available redundancy is limited to simple load balancing, and all the 1535 segments are East-West unidirectional only. 1537 A Track may be set up to reduce the load around the Root, or to 1538 enable urgent traffic to flow more directly. This specification does 1539 not provide the policies that would decide which flows are routed 1540 through which Track. In a Non-Storing Mode RPL Instance, the Main 1541 DODAG provides a default route via the Root, and the Tracks provide 1542 more specific routes to the Track Targets. 1544 4. Extending existing RFCs 1546 This section explains which changes are extensions to existing 1547 specifications, and which changes are amendments to existing 1548 specification. It is expected that extensions to existing 1549 specifications do not cause existing code on legacy 6LRs to 1550 malfunction, as the extensions will simply be ignored. New code is 1551 required for an extension. Those 6LRs will be unable to participate 1552 in the new mechanisms, but may also cause projected DAOs to be 1553 impossible to install. Amendments to existing specifications are 1554 situations where there are semantic changes required to existing 1555 code, and which may require new unit tests to confirm that legacy 1556 operations will continue unaffected. 1558 4.1. Extending RFC 6550 1560 This specification Extends RPL [RPL] to enable the Root to install 1561 East-West routes inside a Main DODAG that is operated as Non-Storing 1562 Mode. The Root issues a Projected DAO (P-DAO) message (see 1563 Section 4.1.1) to the Track Ingress; the P-DAO message contains a new 1564 Via Information Option (VIO) that installs a strict or a loose 1565 sequence of hops to form respectively a Track Segment or a Track Leg. 1567 The new P-DAO Request (PDR) is a new message detailed in Section 5.1. 1568 As per [RPL] section 6, if a node receives this message and it does 1569 not understand this new Code, then discards the message. When the 1570 root initiates to a node that it has not communicated with before, 1571 and to which it does not know if this specification has been 1572 implemented (by means such as capabilities), then the root SHOULD 1573 request a PDR-ACK. 1575 A P-DAO Request (PDR) message enables a Track Ingress to request the 1576 Track from the Root. The resulting Track is also a DODAG for which 1577 the Track Ingress is the Root, the owner the address that serves as 1578 DODAGID and authoritative for the associated namespace from which the 1579 TrackID is selected. In the context of this specification, the 1580 installed route appears as a more specific route to the Track 1581 Targets, and the Track Ingress routes the packets towards the Targets 1582 via the Track using the longest match as usual. 1584 To ensure that the PDR and P-DAO messages can flow at most times, it 1585 is RECOMMENDED that the nodes involved in a Track maintain multiple 1586 parents in the Main DODAG, advertise them all to the Root, and use 1587 them in turn to retry similar packets. It is also RECOMMENDED that 1588 the Root uses diverse source route paths to retry similar messages to 1589 the nodes in the Track. 1591 4.1.1. Projected DAO 1593 Section 6 of [RPL] introduces the RPL Control Message Options (CMO), 1594 including the RPL Target Option (RTO) and Transit Information Option 1595 (TIO), which can be placed in RPL messages such as the destination 1596 Advertisement Object (DAO). A DAO message signals routing 1597 information to one or more Targets indicated in RTOs, providing one 1598 hop information at a time in the TIO. 1600 THIS RFC Amends the specification of the DAO to create the P-DAO 1601 message. This Amended DAO is signaled with a new "Projected DAO" (P) 1602 flag, see Figure 8. 1604 A Projected DAO (P-DAO) is a special DAO message generated by the 1605 Root to install a P-Route formed of multiple hops in its DODAG. This 1606 provides a RPL-based method to install the Tracks as expected by the 1607 6TiSCH Architecture [RFC9030] as a collection of multiple P-Routes. 1609 The Root MUST source the P-DAO message with its address that serves 1610 as DODAGID for the main DODAG. The receiver MUST NOT accept a P-DAO 1611 message that is not sent by the Root of its DODAG and MUST ignore 1612 such message silently. 1614 The 'P' flag is encoded in bit position 2 (to be confirmed by IANA) 1615 of the Flags field in the DAO Base Object. The Root MUST set it to 1 1616 in a Projected DAO message. Otherwise it MUST be set to 0. It is 1617 set to 0 in Legacy implementations as specified respectively in 1618 Sections 20.11 and 6.4 of [RPL]. 1620 The P-DAO is control plane signaling and should not be stuck behind 1621 high traffic levels. The expectation is that the P-DAO message is 1622 sent as high QoS level, above that of data traffic, typically with 1623 the Network Control precedence. 1625 0 1 2 3 1626 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 1627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1628 | TrackID |K|D|P| Flags | Reserved | DAOSequence | 1629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1630 | | 1631 + + 1632 | DODAGID field set to the | 1633 + IPv6 Address of the Track Ingress + 1634 | used to source encapsulated packets | 1635 + + 1636 | | 1637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1638 | Option(s)... 1639 +-+-+-+-+-+-+-+-+ 1641 Figure 8: Projected DAO Base Object 1643 New fields: 1645 TrackID: The local or global RPLInstanceID of the DODAG that serves 1646 as Track, more in Section 6.3 1648 P: 1-bit flag (position to be confirmed by IANA). 1650 The 'P' flag is set to 1 by the Root to signal a Projected DAO, 1651 and it is set to 0 otherwise. 1653 The D flag is set to one to signal that the DODAGID field is present. 1654 It may be set to zero if and only if the destination address of the 1655 P-DAO-ACK message is set to the IPv6 address that serves as DODAGID 1656 and it MUST be set to one otherwise, meaning that the DODAGID field 1657 MUST then be present. 1659 In RPL Non-Storing Mode, the TIO and RTO are combined in a DAO 1660 message to inform the DODAG Root of all the edges in the DODAG, which 1661 are formed by the directed parent-child relationships. The DAO 1662 message signals to the Root that a given parent can be used to reach 1663 a given child. The P-DAO message generalizes the DAO to signal to 1664 the Track Ingress that a Track for which it is Root can be used to 1665 reach children and siblings of the Track Egress. In both cases, 1666 options may be factorized and multiple RTOs may be present to signal 1667 a collection of children that can be reached through the parent or 1668 the Track, respectively. 1670 4.1.2. Projected DAO-ACK 1672 THIS RFC also Amends the DAO-ACK message. The new P flag signals the 1673 projected form. 1675 The format of the P-DAO-ACK message is thus as illustrated in 1676 Figure 9: 1678 0 1 2 3 1679 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 1680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1681 | TrackID |D|P| Reserved | DAOSequence | Status | 1682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1683 | | 1684 + + 1685 | DODAGID field set to the | 1686 + IPv6 Address of the Track Ingress + 1687 | used to source encapsulated packets | 1688 + + 1689 | | 1690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1691 | Option(s)... 1692 +-+-+-+-+-+-+-+-+ 1694 Figure 9: Projected DAO-ACK Base Object 1696 New fields: 1698 TrackID: The local or global RPLInstanceID of the DODAG that serves 1699 as Track, more in Section 6.3 1701 P: 1-bit flag (position to be confirmed by IANA). 1703 The 'P' flag is set to 1 by the Root to signal a Projected DAO, 1704 and it is set to 0 otherwise. 1706 The D flag is set to one to signal that the DODAGID field is present. 1707 It may be set to zero if and only if the source address of the P-DAO- 1708 ACK message is set to the IPv6 address that serves as DODAGID and it 1709 MUST be set to one otherwise, meaning that the DODAGID field MUST 1710 then be present. 1712 4.1.3. Via Information Option 1714 THIS RFC Extends the CMO to create new objects called the Via 1715 Information Options (VIO). The VIOs are the multihop alternative to 1716 the TIO, more in Section 5.3. One VIO is the stateful Storing Mode 1717 VIO (SM-VIO); an SM-VIO installs a strict hop-by-hop P-Route called a 1718 Track Segment. The other is the Non-Storing Mode VIO (NSM-VIO); the 1719 NSM-VIO installs a loose source-routed P-Route called a Track Leg at 1720 the Track Ingress, which uses that state to encapsulate a packet 1721 IPv6_in_IPv6 with a new Routing Header (RH) to the Track Egress, more 1722 in Section 6.7. 1724 A P-DAO contains one or more RTOs to indicate the Target 1725 (destinations) that can be reached via the P-Route, followed by 1726 exactly one VIO that signals the sequence of nodes to be followed, 1727 more in Section 6. There are two modes of operation for the 1728 P-Routes, the Storing Mode and the Non-Storing Mode, see 1729 Section 6.4.2 and Section 6.4.3 respectively for more. 1731 4.1.4. Sibling Information Option 1733 This specification Extends the CMO to create the Sibling Information 1734 Option (SIO). The SIO is used by a RPL Aware Node (RAN) to advertise 1735 a selection of its candidate neighbors as siblings to the Root, more 1736 in Section 5.4. The SIO is placed in DAO messages that are sent 1737 directly to the Root of the main DODAG. 1739 4.1.5. P-DAO Request 1741 The set of RPL Control Messages is Extended to include the P-DAO 1742 Request (PDR) and P-DAO Request Acknowledgement (PDR-ACK). These two 1743 new RPL Control Messages enable an RPL-Aware Node to request the 1744 establishment of a Track between itself as the Track Ingress Node and 1745 a Track Egress. The node makes its request by sending a new P-DAO 1746 Request (PDR) Message to the Root. The Root confirms with a new PDR- 1747 ACK message back to the requester RAN, see Section 5.1 for more. 1749 4.1.6. Amending the RPI 1751 Sending a Packet within a RPL Local Instance requires the presence of 1752 the abstract RPL Packet Information (RPI) described in section 11.2. 1753 of [RPL] in the outer IPv6 Header chain (see [RFC9008]). The RPI 1754 carries a local RPLInstanceID which, in association with either the 1755 source or the destination address in the IPv6 Header, indicates the 1756 RPL Instance that the packet follows. 1758 This specification Amends [RPL] to create a new flag that signals 1759 that a packet is forwarded along a P-Route. 1761 Projected-Route 'P': 1-bit flag. It is set to 1 in the RPI that is 1762 added in the encapsulation when a packet is sent over a Track. It 1763 is set to 0 when a packet is forwarded along the main Track, 1764 including when the packet follows a Segment that joins loose hops 1765 of the Main DODAG. The flag is not mutable en-route. 1767 The encoding of the 'P' flag in native format is shown in Section 4.2 1768 while the compressed format is indicated in Section 4.3. 1770 4.1.7. Additional Flag in the RPL DODAG Configuration Option 1772 The DODAG Configuration Option is defined in Section 6.7.6 of [RPL]. 1773 Its purpose is extended to distribute configuration information 1774 affecting the construction and maintenance of the DODAG, as well as 1775 operational parameters for RPL on the DODAG, through the DODAG. This 1776 Option was originally designed with 4 bit positions reserved for 1777 future use as Flags. 1779 0 1 2 3 1780 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 1781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1782 | Type = 0x04 |Opt Length = 14|D| | | |A| ... | 1783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1784 |4 bits | 1786 Figure 10: DODAG Configuration Option (Partial View) 1788 This specification Amends the specification to define a new flag 1789 "Projected Routes Support" (D). The 'D' flag is encoded in bit 1790 position 0 of the reserved Flags in the DODAG Configuration Option 1791 (this is the most significant bit)(to be confirmed by IANA but 1792 there's little choice). It is set to 0 in legacy implementations as 1793 specified respectively in Sections 20.14 and 6.7.6 of [RPL]. 1795 The 'D' flag is set to 1 to indicate that this specification is 1796 enabled in the network and that the Root will install the requested 1797 Tracks when feasible upon a PDR message. 1799 Section 4.1.2. of [RFC9008] updates [RPL] to indicate that the 1800 definition of the Flags applies to Mode of Operation values from zero 1801 (0) to six (6) only. For a MOP value of 7, the implementation MUST 1802 consider that the Root accepts PDR messages and will install 1803 Projected Routes. 1805 The RPL DODAG Configuration option is typically placed in a DODAG 1806 Information Object (DIO) message. The DIO message propagates down 1807 the DODAG to form and then maintain its structure. The DODAG 1808 Configuration option is copied unmodified from parents to children. 1810 [RPL] states that: 1812 | Nodes other than the DODAG root MUST NOT modify this information 1813 | when propagating the DODAG Configuration option. 1815 Therefore, a legacy parent propagates the 'D' flag as set by the 1816 root, and when the 'D' flag is set to 1, it is transparently flooded 1817 to all the nodes in the DODAG. 1819 4.2. Extending RFC 6553 1821 "The RPL Option for Carrying RPL Information in Data-Plane Datagrams" 1822 [RFC6553]describes the RPL Option for use among RPL routers to 1823 include the abstract RPL Packet Information (RPI) described in 1824 section 11.2. of [RPL] in data packets. 1826 The RPL Option is commonly referred to as the RPI though the RPI is 1827 really the abstract information that is transported in the RPL 1828 Option. [RFC9008] updated the Option Type from 0x63 to 0x23. 1830 This specification Amends the RPL Option to encode the 'P' flag as 1831 follows: 1833 0 1 2 3 1834 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 1835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1836 | Option Type | Opt Data Len | 1837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1838 |O|R|F|P|0|0|0|0| RPLInstanceID | SenderRank | 1839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1840 | (sub-TLVs) | 1841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1842 Figure 11: Amended RPL Option Format 1844 Option Type: 0x23 or 0x63, see [RFC9008] 1846 Opt Data Len: See [RFC6553] 1848 'O', 'R' and 'F' flags: See [RFC6553]. Those flags MUST be set to 0 1849 by the sender and ignored by the receiver if the 'P' flag is set. 1851 Projected-Route 'P': 1-bit flag as defined in Section 4.1.6. 1853 RPLInstanceID: See [RFC6553]. Indicates the TrackId if the 'P' flag 1854 is set, as discussed in Section 4.1.1. 1856 SenderRank: See [RFC6553]. This field MUST be set to 0 by the 1857 sender and ignored by the receiver if the 'P'flag is set. 1859 4.3. Extending RFC 8138 1861 The 6LoWPAN Routing Header [RFC8138] specification introduces a new 1862 IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) 1863 [RFC6282] dispatch type for use in 6LoWPAN route-over topologies, 1864 which initially covers the needs of RPL data packet compression. 1866 Section 4 of [RFC8138] presents the generic formats of the 6LoWPAN 1867 Routing Header (6LoRH) with two forms, one Elective that can be 1868 ignored and skipped when the router does not understand it, and one 1869 Critical which causes the packet to be dropped when the router cannot 1870 process it. The 'E' Flag in the 6LoRH indicates its form. In order 1871 to skip the Elective 6LoRHs, their format imposes a fixed expression 1872 of the size, whereas the size of a Critical 6LoRH may be signaled in 1873 variable forms to enable additional optimizations. 1875 When the [RFC8138] compression is used, the Root of the Main DODAG 1876 that sets up the Track also constructs the compressed routing header 1877 (SRH-6LoRH) on behalf of the Track Ingress, which saves the 1878 complexities of optimizing the SRH-6LoRH encoding in constrained 1879 code. The SRH-6LoRH is signaled in the NSM-VIO, in a fashion that it 1880 is ready to be placed as is in the packet encapsulation by the Track 1881 Ingress. 1883 Section 6.3 of [RFC8138] presents the formats of the 6LoWPAN Routing 1884 Header of type 5 (RPI-6LoRH) that compresses the RPI for normal RPL 1885 operation. The format of the RPI-6LoRH is not suited for P-Routes 1886 since the O,R,F flags are not used and the Rank is unknown and 1887 ignored. 1889 This specification extends [RFC8138] to introduce a new 6LoRH, the P- 1890 RPI-6LoRH that can be used in either Elective or Critical 6LoRH form, 1891 see Table 22 and Table 23 respectively. The new 6LoRH MUST be used 1892 as a Critical 6LoRH, unless an SRH-6LoRH is present and controls the 1893 routing decision, in which case it MAY be used in Elective form. 1895 The P-RPI-6LoRH is designed to compress the RPI along RPL P-Routes. 1896 Its format is as follows: 1898 0 1 2 1899 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1901 |1|0|E| Length | 6LoRH Type | RPLInstanceID | 1902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1904 Figure 12: P-RPI-6LoRH Format 1906 Type: IANA is requested to define the same value of the type for 1907 both Elective and Critical forms. A type of 8 is suggested. 1909 Elective 'E': See [RFC8138]. The 'E' flag is set to 1 to indicate 1910 an Elective 6LoRH, meaning that it can be ignored when forwarding. 1912 RPLInstanceID : In the context of this specification, the 1913 RPLInstanceID field signals the TrackID, see Section 3.4 and 1914 Section 6.3 . 1916 Section 6.8 details how a a Track Ingress leverages the P-RPI-6LoRH 1917 Header as part of the encapsulation of a packet to place it into a 1918 Track. 1920 5. New RPL Control Messages and Options 1922 5.1. New P-DAO Request Control Message 1924 The P-DAO Request (PDR) message is sent by a Node in the Main DODAG 1925 to the Root. It is a request to establish or refresh a Track where 1926 this node is Track Ingress, and signals whether an acknowledgment 1927 called PDR-ACK is requested or not. A positive PDR-ACK indicates 1928 that the Track was built and that the Roots commits to maintain the 1929 Track for the negotiated lifetime. 1931 The main Root MAY indicate to the Track Ingress that the Track was 1932 terminated before its time and to do so, it MUST uses an asynchronous 1933 PDR-ACK with an negative status. A status of "Transient Failure" 1934 (see Section 11.10) is an indication that the PDR may be retried 1935 after a reasonable time that depends on the deployment. Other 1936 negative status values indicate a permanent error; the tentative must 1937 be abandoned until a corrective action is taken at the application 1938 layer or through network management. 1940 The source IPv6 address of the PDR signals the Track Ingress to-be of 1941 the requested Track, and the TrackID is indicated in the message 1942 itself. At least one RPL Target Option MUST be present in the 1943 message. If more than one RPL Target Option is present, the Root 1944 will provide a Track that reaches the first listed Target and a 1945 subset of the other Targets; the details of the subset selection are 1946 out of scope. The RTO signals the Track Egress, more in Section 6.2. 1948 The RPL Control Code for the PDR is 0x09, to be confirmed by IANA. 1949 The format of PDR Base Object is as follows: 1951 0 1 2 3 1952 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 1953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1954 | TrackID |K|R| Flags | ReqLifetime | PDRSequence | 1955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1956 | Option(s)... 1957 +-+-+-+-+-+-+-+-+ 1959 Figure 13: New P-DAO Request Format 1961 TrackID: 8-bit field. In the context of this specification, the 1962 TrackID field signals the RPLInstanceID of the DODAG formed by the 1963 Track, see Section 3.4 and Section 6.3. To allocate a new Track, 1964 the Ingress Node must provide a value that is not in use at this 1965 time. 1967 K: The 'K' flag is set to indicate that the recipient is expected to 1968 send a PDR-ACK back. 1970 R: The 'R' flag is set to request a Complex Track for redundancy. 1972 Flags: Reserved. The Flags field MUST initialized to zero by the 1973 sender and MUST be ignored by the receiver 1975 ReqLifetime: 8-bit unsigned integer. The requested lifetime for the 1976 Track expressed in Lifetime Units (obtained from the DODAG 1977 Configuration option). 1979 A PDR with a fresher PDRSequence refreshes the lifetime, and a 1980 PDRLifetime of 0 indicates that the Track should be destroyed, 1981 e.g., when the application that requested the Track terminates. 1983 PDRSequence: 8-bit wrapping sequence number, obeying the operation 1984 in section 7.2 of [RPL]. The PDRSequence is used to correlate a 1985 PDR-ACK message with the PDR message that triggered it. It is 1986 incremented at each PDR message and echoed in the PDR-ACK by the 1987 Root. 1989 5.2. New PDR-ACK Control Message 1991 The new PDR-ACK is sent as a response to a PDR message with the 'K' 1992 flag set. The RPL Control Code for the PDR-ACK is 0x0A, to be 1993 confirmed by IANA. Its format is as follows: 1995 0 1 2 3 1996 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 1997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1998 | TrackID | Flags | Track Lifetime| PDRSequence | 1999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2000 | PDR-ACK Status| Reserved | 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2002 | Option(s)... 2003 +-+-+-+-+-+-+-+ 2005 Figure 14: New PDR-ACK Control Message Format 2007 TrackID: Set to the TrackID indicated in the TrackID field of the 2008 PDR messages that this replies to. 2010 Flags: Reserved. The Flags field MUST initialized to zero by the 2011 sender and MUST be ignored by the receiver 2013 Track Lifetime: Indicates that remaining Lifetime for the Track, 2014 expressed in Lifetime Units; the value of zero (0x00) indicates 2015 that the Track was destroyed or not created. 2017 PDRSequence: 8-bit wrapping sequence number. It is incremented at 2018 each PDR message and echoed in the PDR-ACK. 2020 PDR-ACK Status: 8-bit field indicating the completion. The PDR-ACK 2021 Status is substructured as indicated in Figure 15: 2023 0 1 2 3 4 5 6 7 2024 +-+-+-+-+-+-+-+-+ 2025 |E|R| Value | 2026 +-+-+-+-+-+-+-+-+ 2028 Figure 15: PDR-ACK status Format 2030 E: 1-bit flag. Set to indicate a rejection. When not set, the 2031 value of 0 indicates Success/Unqualified Acceptance and other 2032 values indicate "not an outright rejection". 2033 R: 1-bit flag. Reserved, MUST be set to 0 by the sender and 2034 ignored by the receiver. 2035 Status Value: 6-bit unsigned integer. Values depending on the 2036 setting of the 'E' flag, see Table 28 and Table 29. 2038 Reserved: The Reserved field MUST initialized to zero by the sender 2039 and MUST be ignored by the receiver 2041 5.3. Via Information Options 2043 A VIO signals the ordered list of IPv6 Via Addresses that constitutes 2044 the hops of either a Leg (using Non-Storing Mode) a Segment (using 2045 storing mode) of a Track. A Storing Mode P-DAO contains one Storing 2046 Mode VIO (SM-VIO) whereas a Non-Storing Mode P-DAO contains one Non- 2047 Storing Mode VIO (NSM-VIO) 2049 The duration of the validity of a VIO is indicated in a Segment 2050 Lifetime field. A P-DAO message that contains a VIO with a Segment 2051 Lifetime of zero is referred as a No-Path P-DAO. 2053 The VIO contains one or more SRH-6LoRH header(s), each formed of a 2054 SRH-6LoRH head and a collection of compressed Via Addresses, except 2055 in the case of a Non-Storing Mode No-Path P-DAO where the SRH-6LoRH 2056 header is not present. 2058 In the case of a SM-VIO, or if [RFC8138] is not used in the data 2059 packets, then the Root MUST use only one SRH-6LoRH per Via 2060 Information Option, and the compression is the same forall the 2061 addresses, as shown in Figure 16, for simplicity. 2063 In case of an NSM-VIO and if [RFC8138] is in use in the Main DODAG, 2064 the Root SHOULD optimize the size of the NSM-VIO if using different 2065 SRH-6LoRH Types make the VIO globally shorter; this means that more 2066 than one SRH-6LoRH may be present. 2068 The format of the Via Information Options is as follows: 2070 0 1 2 3 2071 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 2072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2073 | Type | Option Length | Flags | P-RouteID | 2074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2075 |Segm. Sequence | Seg. Lifetime | SRH-6LoRH head | 2076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2077 | | 2078 . Via Address 1 (compressed by RFC 8138) . 2079 | | 2080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2081 | | 2082 . .... . 2083 | | 2084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2085 | | 2086 . Via Address n (compressed by RFC 8138) . 2087 | | 2088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2089 | | 2090 . Additional SRH-6LoRH Header(s) . 2091 | | 2092 . .... . 2094 Figure 16: VIO format (uncompressed form) 2096 Option Type: 0x0E for SM-VIO, 0x0F for NSM-VIO (to be confirmed by 2097 IANA), see =Table 26 2099 Option Length: 8-bit unsigned integer, representing the length in 2100 octets of the option, not including the Option Type and Length 2101 fields, see section 6.7.1. of [RPL]; the Option Length is 2102 variable, depending on the number of Via Addresses and the 2103 compression applied. 2105 P-RouteID: 8-bit field that identifies a component of a Track or the 2106 Main DODAG as indicated by the TrackID field. The value of 0 is 2107 used to signal a Serial Track, i.e., made of a single segment/Leg. 2108 In an SM-VIO, the P-RouteID indicates an actual Segment. In an an 2109 NSM-VIO, it indicates a Leg, that is a serial subTrack that is 2110 added to the overall topology of the Track. 2112 Segment Sequence: 8-bit unsigned integer. The Segment Sequence 2113 obeys the operation in section 7.2 of [RPL] and the lollipop 2114 starts at 255. 2116 When the Root of the DODAG needs to refresh or update a Segment in 2117 a Track, it increments the Segment Sequence individually for that 2118 Segment. 2120 The Segment information indicated in the VIO deprecates any state 2121 for the Segment indicated by the P-RouteID within the indicated 2122 Track and sets up the new information. 2124 A VIO with a Segment Sequence that is not as fresh as the current 2125 one is ignored. 2127 A VIO for a given DODAGID with the same (TrackID, P-RouteID, 2128 Segment Sequence) indicates a retry; it MUST NOT change the 2129 Segment and MUST be propagated or answered as the first copy. 2131 Segment Lifetime: 8-bit unsigned integer. The length of time in 2132 Lifetime Units (obtained from the Configuration option) that the 2133 Segment is usable. 2135 The period starts when a new Segment Sequence is seen. The value 2136 of 255 (0xFF) represents infinity. The value of zero (0x00) 2137 indicates a loss of reachability. 2139 SRH-6LoRH head: The first 2 bytes of the (first) SRH-6LoRH as shown 2140 in Figure 6 of [RFC8138]. As an example, a 6LoRH Type of 4 means 2141 that the VIA Addresses are provided in full with no compression. 2143 Via Address: An IPv6 ULA or GUA of a node along the Segment. The 2144 VIO contains one or more IPv6 Via Addresses listed in the datapath 2145 order from Ingress to Egress. The list is expressed in a 2146 compressed form as signaled by the preceding SRH-6LoRH header. 2148 In a Storing Mode P-DAO that updates or removes a section of an 2149 already existing Segment, the list in the SM-VIO may represent 2150 only the section of the Segment that is being updated; at the 2151 extreme, the SM-VIO updates only one node, in which case it 2152 contains only one IPv6 address. In all other cases, the list in 2153 the VIO MUST be complete. 2155 In the case of an SM-VIO, the list indicates a sequential (strict) 2156 path through direct neighbors, the complete list starts at Ingress 2157 and ends at Egress, and the nodes listed in the VIO, including the 2158 Egress, MAY be considered as implicit Targets. 2160 In the case of an NSM-VIO, the complete list can be loose and 2161 excludes the Ingress node, starting at the first loose hop and 2162 ending at a Track Egress; the Track Egress MUST be considered as 2163 an implicit Target, so it MUST NOT be signaled in a RPL Target 2164 Option. 2166 5.4. Sibling Information Option 2168 The Sibling Information Option (SIO) provides indication on siblings 2169 that could be used by the Root to form P-Routes. One or more SIO(s) 2170 may be placed in the DAO messages that are sent to the Root in Non- 2171 Storing Mode. 2173 To advertise a neighbor node, the router MUST have an active Address 2174 Registration from that sibling using [RFC8505], for an address (ULA 2175 or GUA) that serves as identifier for the node. If this router also 2176 registers an address to that sibling, and the link has similar 2177 properties in both directions, only the router with the lowest 2178 Interface ID in its registered address needs report the SIO, with the 2179 B flag set, and the Root will assume symmetry. 2181 The SIO carries a flag (B) that is set when similar performances can 2182 be expected both directions, so the routing can consider that the 2183 information provided for one direction is valid for both. If the SIO 2184 is effectively received from both sides then the B flag MUST be 2185 ignored. The policy that describes the performance criteria, and how 2186 they are asserted is out of scope. In the absence of an external 2187 protocol to assert the link quality, the flag SHOULD NOT be set. 2189 The format of the SIO is as follows: 2191 0 1 2 3 2192 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 2193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2194 | Type | Option Length |S|B|Flags|Comp.| Opaque | 2195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2196 | Step in Rank | Reserved | 2197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2198 | | 2199 + + 2200 . . 2201 . Sibling DODAGID (if the D flag not set) . 2202 . . 2203 + + 2204 | | 2205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2206 | | 2207 + + 2208 . . 2209 . Sibling Address . 2210 . . 2211 + + 2212 | | 2213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2215 Figure 17: Sibling Information Option Format 2217 Option Type: 0x10 for SIO (to be confirmed by IANA), see =Table 26 2219 Option Length: 8-bit unsigned integer, representing the length in 2220 octets of the option, not including the Option Type and Length 2221 fields, see section 6.7.1. of [RPL]. 2223 Reserved for Flags: MUST be set to zero by the sender and MUST be 2224 ignored by the receiver. 2226 B: 1-bit flag that is set to indicate that the connectivity to the 2227 sibling is bidirectional and roughly symmetrical. In that case, 2228 only one of the siblings may report the SIO for the hop. If 'B' 2229 is not set then the SIO only indicates connectivity from the 2230 sibling to this node, and does not provide information on the hop 2231 from this node to the sibling. 2233 S: 1-bit flag that is set to indicate that sibling belongs to the 2234 same DODAG. When not set, the Sibling DODAGID is indicated. 2236 Flags: Reserved. The Flags field MUST initialized to zero by the 2237 sender and MUST be ignored by the receiver 2239 Opaque: MAY be used to carry information that the node and the Root 2240 understand, e.g., a particular representation of the Link 2241 properties such as a proprietary Link Quality Information for 2242 packets received from the sibling. An industrial Alliance that 2243 uses RPL for a particular use / environment MAY redefine the use 2244 of this field to fit its needs. 2246 Compression Type: 3-bit unsigned integer. This is the SRH-6LoRH 2247 Type as defined in figure 7 in section 5.1 of [RFC8138] that 2248 corresponds to the compression used for the Sibling Address and 2249 its DODAGID if resent. The Compression reference is the Root of 2250 the Main DODAG. 2252 Step in Rank: 16-bit unsigned integer. This is the Step in Rank 2253 [RPL] as computed by the Objective Function between this node and 2254 the sibling, that reflects the abstract Rank increment that would 2255 be computed by the OF if the sibling was the preferred parent. 2257 Reserved: The Reserved field MUST initialized to zero by the sender 2258 and MUST be ignored by the receiver 2260 Sibling DODAGID: 2 to 16 bytes, the DODAGID of the sibling in a 2261 [RFC8138] compressed form as indicated by the Compression Type 2262 field. This field is present if and only if the D flag is not 2263 set. 2265 Sibling Address: 2 to 16 bytes, an IPv6 Address of the sibling, with 2266 a scope that MUST be make it reachable from the Root, e.g., it 2267 cannot be a Link Local Address. The IPv6 address is encoded in 2268 the [RFC8138] compressed form indicated by the Compression Type 2269 field. 2271 An SIO MAY be immediately followed by a DAG Metric Container. In 2272 that case the DAG Metric Container provides additional metrics for 2273 the hop from the Sibling to this node. 2275 6. Root Initiated Routing State 2277 6.1. RPL Network Setup 2279 To avoid the need of Path MTU Discovery, 6LoWPAN links are normally 2280 defined with a MTU of 1280 (see section 4 of [6LoWPAN]). Injecting 2281 packets in a Track typically involves an IP-in-IP encapsulation and 2282 additional IPv6 Extension Headers. This may cause a fragmentation if 2283 the resulting packets exceeds the MTU that is defined for the RPL 2284 domain. 2286 Though fragmentation is possible in a 6LoWPAN LLN, e.g., using 2287 [6LoWPAN], [RFC8930], and/or [RFC8931], it is RECOMMENDED to allow an 2288 MTU that is larger than 1280 in the main DODAG and allows for the 2289 additional headers while exposing only 1280 to the 6LoWPAN Nodes. 2291 6.2. Requesting a Track 2293 This specification introduces the PDR message, used by an LLN node to 2294 request the formation of a new Track for which this node is Ingress. 2295 Note that the namespace for the TrackID is owned by the Ingress node, 2296 and in the absence of a PDR, there must be some procedure for the 2297 Root to assign TrackIDs in that namespace while avoiding collisions, 2298 more in Section 6.3. 2300 The PDR signals the desired TrackID and the duration for which the 2301 Track should be established. Upon a PDR, the Root MAY install the 2302 Track as requested, in which case it answers with a PDR-ACK 2303 indicating the granted Track Lifetime. All the Segments MUST be of a 2304 same mode, either Storing or Non-Storing. All the Segments MUST be 2305 created with the same TrackID and the same DODAGID signaled in the 2306 P-DAO. 2308 The Root designs the Track as it sees best, and updates / changes the 2309 Segments overtime to serve the Track as needed. Note that there is 2310 no protocol element to notify to the requesting Track Ingress when 2311 changes happen deeper down the Track, so they are transparent to the 2312 Track Ingress. If the main Root cannot maintain an expected service 2313 level, then it needs to tear down the Track completely. The Segment 2314 Lifetime in the P-DAO messages does not need to be aligned to the 2315 Requested Lifetime in the PDR, or between P-DAO messages for 2316 different Segments. The Root may use shorter lifetimes for the 2317 Segments and renew them faster than the Track is, or longer lifetimes 2318 in which case it will need to tear down the Segments if the Track is 2319 not renewed. 2321 When the Track Lifetime that was returned in the PDR-ACK is close to 2322 elapse - vs. the trip time from the node to the Root, the requesting 2323 node SHOULD resend a PDR using the TrackID in the PDR-ACK to extend 2324 the lifetime of the Track, else the Track will time out and the Root 2325 will tear down the whole structure. 2327 If the Track fails and cannot be restored, the Root notifies the 2328 requesting node asynchronously with a PDR-ACK with a Track Lifetime 2329 of 0, indicating that the Track has failed, and a PDR-ACK Status 2330 indicating the reason of the fault. 2332 6.3. Identifying a Track 2334 RPL defines the concept of an Instance to signal an individual 2335 routing topology, and multiple topologies can coexist in the same 2336 network. The RPLInstanceID is tagged in the RPI of every packet to 2337 signal which topology the packet actually follows. 2339 This draft leverages the RPL Instance model as follows: 2341 * The Root MAY use P-DAO messages to add better routes in the main 2342 (Global) RPL Instance in conformance with the routing objectives 2343 in that Instance. 2345 To achieve this, the Root MAY install a Segment along a path down 2346 the main Non-Storing Mode DODAG. This enables a loose source 2347 routing and reduces the size of the Routing Header, see 2348 Section 3.3.1. The Root MAY also install a Track Leg across the 2349 Main DODAG to complement the routing topology. 2351 When adding a P-Route to the RPL Main DODAG, the Root MUST set the 2352 RPLInstanceID field of the P-DAO Base Object (see section 6.4.1. 2353 of [RPL]) to the RPLInstanceID of the Main DODAG, and MUST NOT use 2354 the DODAGID field. A P-Route provides a longer match to the 2355 Target Address than the default route via the Root, so it is 2356 preferred. 2358 * The Root MAY also use P-DAO messages to install a Track as an 2359 independent routing topology (say, Traffic Engineered) to achieve 2360 particular routing characteristics from an Ingress to an Egress 2361 Endpoints. To achieve this, the Root MUST set up a local RPL 2362 Instance (see section 5 of [RPL]), and the Local RPLInstanceID 2363 serves as TrackID. The TrackID MUST be unique for the IPv6 ULA or 2364 GUA of the Track Ingress that serves as DODAGID for the Track. 2366 This way, a Track is uniquely identified by the tuple (DODAGID, 2367 TrackID) where the TrackID is always represented with the D flag 2368 set to 0 (see also section 5.1. of [RPL]), indicating when used in 2369 an RPI that the source address of the IPv6 packet signals the 2370 DODAGID. 2372 The P-DAO Base Object MUST indicate the tuple (DODAGID, TrackID) 2373 that identifies the Track as shown in Figure 8, and the P-RouteID 2374 that identifies the P-Route MUST be signaled in the VIO as shown 2375 in Figure 16. 2377 The Track Ingress is the Root of the DODAG ID formed by the local 2378 RPL Instance. It owns the namespace of its TrackIDs, so it can 2379 pick any unused value to request a new Track with a PDR. In a 2380 particular deployment where PDR are not used, a portion of the 2381 namespace can be administratively delegated to the main Root, 2382 meaning that the main Root is authoritative for assigning the 2383 TrackIDs for the Tracks it creates. 2385 With this specification, the Root is aware of all the active 2386 Tracks, so it can also pick any unused value to form Tracks 2387 without a PDR. To avoid a collision of the Root and the Track 2388 Ingress picking the same value at the same time, it is RECOMMENDED 2389 that the Track Ingress starts allocating the ID value of the Local 2390 RPLInstanceID (see section 5.1. of [RPL]) used as TrackIDs with 2391 the value 0 incrementing, while the Root starts with 63 2392 decrementing. 2394 6.4. Installing a Track 2396 A Serial Track can be installed by a single P-Route that signals the 2397 sequence of consecutive nodes, either in Storing Mode as a single- 2398 Segment Track, or in Non-Storing Mode as a single-Leg Track. A 2399 single-Leg Track can be installed as a loose Non-Storing Mode 2400 P-Route, in which case the next loose entry must recursively be 2401 reached over a Serial Track. 2403 A Complex Track can be installed as a collection of P-Routes with the 2404 same DODAGID and Track ID. The Ingress of a Non-Storing Mode P-Route 2405 is the owner and Root of the DODAGID. The Ingress of a Storing Mode 2406 P-Route must be either the owner of the DODAGID, or a hop of a Leg of 2407 the same Track. In the latter case, the Targets of the P-Route must 2408 include the next hop of the Leg if there is one, to ensure forwarding 2409 continuity. In the case of a Complex Track, each Segment is 2410 maintained independently and asynchronously by the Root, with its own 2411 lifetime that may be shorter, the same, or longer than that of the 2412 Track. 2414 A route along a Track for which the TrackID is not the RPLInstanceID 2415 of the Main DODAG MUST be installed with a higher precedence than the 2416 routes along the Main DODAG, meaning that: 2418 * Longest match MUST be the prime comparison for routing. 2420 * In case of equal length match, the route along the Track MUST be 2421 preferred vs. the one along the Main DODAG. 2423 * There SHOULD NOT be 2 different Tracks leading to the same Target 2424 from same Ingress node, unless there's a policy for selecting 2425 which packets use which Track; such policy is out of scope. 2427 * A packet that was routed along a Track MUST NOT be routed along 2428 the main DODAG again; if the destination is not reachable as a 2429 neighbor by the node where the packet exits the Track then the 2430 packet MUST be dropped. 2432 6.4.1. Signaling a Projected Route 2434 This draft adds a capability whereby the Root of a main RPL DODAG 2435 installs a Track as a collection of P-Routes, using a Projected-DAO 2436 (P-DAO) message for each individual Track Leg or Segment. The P-DAO 2437 signals a collection of Targets in the RPL Target Option(s) (RTO). 2438 Those Targets can be reached via a sequence of routers indicated in a 2439 VIO. 2441 Like a classical DAO message, a P-DAO causes a change of state only 2442 if it is "new" per section 9.2.2. "Generation of DAO Messages" of 2443 the RPL specification [RPL]; this is determined using the Segment 2444 Sequence information from the VIO as opposed to the Path Sequence 2445 from a TIO. Also, a Segment Lifetime of 0 in a VIO indicates that 2446 the P-Route associated to the Segment is to be removed. There are 2447 two Modes of operation for the P-Routes, the Storing and the Non- 2448 Storing Modes. 2450 A P-DAO message MUST be sent from the address of the Root that serves 2451 as DODAGID for the Main DODAG. It MUST contain either exactly one 2452 sequence of one or more RTOs followed one VIO, or any number of 2453 sequences of one or more RTOs followed by one or more TIOs. The 2454 former is the normal expression for this specification, where as the 2455 latter corresponds to the variation for lesser constrained 2456 environments described in Section 7.2. 2458 A P-DAO that creates or updates a Track Leg MUST be sent to a GUA or 2459 a ULA of the Ingress of the Leg; it must contain the full list of 2460 hops in the Leg unless the Leg is being removed. A P-DAO that 2461 creates a new Track Segment MUST be sent to a GUA or a ULA of the 2462 Segment Egress and MUST signal the full list of hops in Segment; a 2463 P-DAO that updates (including deletes) a section of a Segment MUST be 2464 sent to the first node after the modified Segment and signal the full 2465 list of hops in the section starting at the node that immediately 2466 precedes the modified section. 2468 In Non-Storing Mode, as discussed in Section 6.4.3, the Root sends 2469 the P-DAO to the Track Ingress where the source-routing state is 2470 applied, whereas in Storing Mode, the P-DAO is sent to the last node 2471 on the installed path and forwarded in the reverse direction, 2472 installing a Storing Mode state at each hop, as discussed in 2473 Section 6.4.2. In both cases the Track Ingress is the owner of the 2474 Track, and it generates the P-DAO-ACK when the installation is 2475 successful. 2477 If the 'K' Flag is present in the P-DAO, the P-DAO must be 2478 acknowledged using a DAO-ACK that is sent back to the address of the 2479 Root from which the P-DAO was received. In most cases, the first 2480 node of the Leg, Segment, or updated section of the Segment is the 2481 node that sends the acknowledgment. The exception to the rule is 2482 when an intermediate node in a Segment fails to forward a Storing 2483 Mode P-DAO to the previous node in the SM-VIO. 2485 In a No-Path Non-Storing Mode P-DAO, the SRH-6LoRH MUST NOT be 2486 present in the NSM-VIO; the state in the Ingress is erased 2487 regardless. In all other cases, a VIO MUST contain at least one Via 2488 Address, and a Via Address MUST NOT be present more than once, which 2489 would create a loop. 2491 A node that processes a VIO MAY verify whether one of these 2492 conditions happen, and when so, it MUST ignore the P-DAO and reject 2493 it with a RPL Rejection Status of "Error in VIO" in the DAO-ACK, see 2494 Section 11.16. 2496 Other errors than those discussed explicitely that prevent the 2497 installing the route are acknowledged with a RPL Rejection Status of 2498 "Unqualified Rejection" in the DAO-ACK. 2500 6.4.2. Installing a Track Segment with a Storing Mode P-Route 2502 As illustrated in Figure 18, a Storing Mode P-DAO installs a route 2503 along the Segment signaled by the SM-VIO towards the Targets 2504 indicated in the Target Options. The Segment is to be included in a 2505 DODAG indicated by the P-DAO Base Object, that may be the one formed 2506 by the RPL Main DODAG, or a Track associated with a local RPL 2507 Instance. 2509 ------+--------- 2510 | Internet 2511 | 2512 +-----+ 2513 | | Border router 2514 | | (RPL Root) 2515 +-----+ | ^ | 2516 | | DAO | ACK | 2517 o o o o | | | 2518 o o o o o o o o o | ^ | Projected . 2519 o o o o o o o o o o | | DAO | Route . 2520 o o o o o o o o o | ^ | . 2521 o o o o o o o o v | DAO v . 2522 o o LLN o o o | 2523 o o o o o Loose Source Route Path | 2524 o o o o v 2526 Figure 18: Projecting a route 2528 In order to install the relevant routing state along the Segment , 2529 the Root sends a unicast P-DAO message to the Track Egress router of 2530 the routing Segment that is being installed. The P-DAO message 2531 contains a SM-VIO with the strict sequence of Via Addresses. The SM- 2532 VIO follows one or more RTOs indicating the Targets to which the 2533 Track leads. The SM-VIO contains a Segment Lifetime for which the 2534 state is to be maintained. 2536 The Root sends the P-DAO directly to the Egress node of the Segment. 2537 In that P-DAO, the destination IP address matches the last Via 2538 Address in the SM-VIO. This is how the Egress recognizes its role. 2539 In a similar fashion, the Segment Ingress node recognizes its role as 2540 it matches first Via Address in the SM-VIO. 2542 The Egress node of the Segment is the only node in the path that does 2543 not install a route in response to the P-DAO; it is expected to be 2544 already able to route to the Target(s) based on its existing tables. 2545 If one of the Targets is not known, the node MUST answer to the Root 2546 with a DAO-ACK listing the unreachable Target(s) in an RTO and a 2547 rejection status of "Unreachable Target". 2549 If the Egress node can reach all the Targets, then it forwards the 2550 P-DAO with unchanged content to its predecessor in the Segment as 2551 indicated in the list of Via Information options, and recursively the 2552 message is propagated unchanged along the sequence of routers 2553 indicated in the P-DAO, but in the reverse order, from Egress to 2554 Ingress. 2556 The address of the predecessor to be used as destination of the 2557 propagated DAO message is found in the Via Address the precedes the 2558 one that contain the address of the propagating node, which is used 2559 as source of the message. 2561 Upon receiving a propagated DAO, all except the Egress router MUST 2562 install a route towards the DAO Target(s) via their successor in the 2563 SM-VIO. A router that cannot store the routes to all the Targets in 2564 a P-DAO MUST reject the P-DAO by sending a DAO-ACK to the Root with a 2565 Rejection Status of "Out of Resources" as opposed to forwarding the 2566 DAO to its predecessor in the list. The router MAY install 2567 additional routes towards the VIA Addresses that are the SM-VIO after 2568 self, if any, but in case of a conflict or a lack of resource, the 2569 route(s) to the Target(s) are the ones that must be installed in 2570 priority. 2572 If a router cannot reach its predecessor in the SM-VIO, the router 2573 MUST send the DAO-ACK to the Root with a Rejection Status of 2574 "Predecessor Unreachable". 2576 The process continues till the P-DAO is propagated to Ingress router 2577 of the Segment, which answers with a DAO-ACK to the Root. The Root 2578 always expects a DAO-ACK, either from the Track Ingress with a 2579 positive status or from any node along the segment with a negative 2580 status. If the DAO-ACK is not received, the Root may retry the DAO 2581 with the same TID, or tear down the route. 2583 6.4.3. Installing a Track Leg with a Non-Storing Mode P-Route 2585 As illustrated in Figure 19, a Non-Storing Mode P-DAO installs a 2586 source-routed path within the Track indicated by the P-DAO Base 2587 Object, towards the Targets indicated in the Target Options. The 2588 source-routed path requires a Source-Routing header which implies an 2589 IP-in-IP encapsulation to add the SRH to an existing packet. It is 2590 sent to the Track Ingress which creates a tunnel associated with the 2591 Track, and connected routes over the tunnel to the Targets in the 2592 RTO. The tunnel encapsulation MUST incorporate a routing header via 2593 the list addresses listed in the VIO in the same order. The content 2594 of the NSM-VIO starting at the first SRH-6LoRH header MUST be used 2595 verbatim by the Track Ingress when it encapsulates a packet to 2596 forward it over the Track. 2598 ------+--------- 2599 | Internet 2600 | 2601 +-----+ 2602 | | Border router 2603 | | (RPL Root) 2604 +-----+ | P ^ ACK 2605 | Track | DAO | 2606 o o o o Ingress X V | X 2607 o o o o o o o X o X Source 2608 o o o o o o o o X o o X Routed 2609 o o ° o o o o X o X Segment 2610 o o o o o o o o X Egress X 2611 o o o o o | 2612 Target 2613 o o LLN o o 2614 o o o o 2616 Figure 19: Projecting a Non-Storing Route 2618 The next entry in the source-routed path must be either a neighbor of 2619 the previous entry, or reachable as a Target via another P-Route, 2620 either Storing or Non-Storing, which implies that the nested P-Route 2621 has to be installed before the loose sequence is, and that P-Routes 2622 must be installed from the last to the first along the datapath. For 2623 instance, a Segment of a Track must be installed before the Leg(s) of 2624 the same Track that use it, and stitched Segments must be installed 2625 in order from the last that reaches to the Targets to the first. 2627 If the next entry in the loose sequence is reachable over a Storing 2628 Mode P-Route, it MUST be the Target of a Segment and the Ingress of a 2629 next segment, both already setup; the segments are associated with 2630 the same Track, which avoids the need of an additional encapsulation. 2631 For instance, in Section 3.5.1.3, Segments A==>B-to-C and 2632 C==>D==>E-to-F must be installed with Storing Mode P-DAO messages 1 2633 and 2 before the Track A-->C-->E-to-F that joins them can be 2634 installed with Non-Storing Mode P-DAO 3. 2636 Conversely, if it is reachable over a Non-Storing Mode P-Route, the 2637 next loose source-routed hop of the inner Track is a Target of a 2638 previously installed Track and the Ingress of a next Track, which 2639 requires a de- and a re-encapsulation when switching the outer Tracks 2640 that join the loose hops. This is examplified in Section 3.5.2.3 2641 where Non-Storing Mode P-DAO 1 and 2 install strict Tracks that Non- 2642 Storing Mode P-DAO 3 joins as a super Track. In such a case, packets 2643 are subject to double IP-in-IP encapsulation. 2645 6.5. Tearing Down a P-Route 2647 A P-DAO with a lifetime of 0 is interpreted as a No-Path DAO and 2648 results in cleaning up existing state as opposed to refreshing an 2649 existing one or installing a new one. To tear down a Track, the Root 2650 must tear down all the Track Segments and Legs that compose it one by 2651 one. 2653 Since the state about a Leg of a Track is located only on the Ingress 2654 Node, the Root cleans up the Leg by sending an NSM-VIO to the Ingress 2655 indicating the TrackID and the P-RouteID of the Leg being removed, a 2656 Segment Lifetime of 0 and a newer Segment Sequence. The SRH-6LoRH 2657 with the Via Addresses in the NSM-VIO are not needed; it SHOULD not 2658 be placed in the message and MUST be ignored by the receiver. Upon 2659 that NSM-VIO, the Ingress node removes all state for that Track if 2660 any, and replies positively anyway. 2662 The Root cleans up a section of a Segment by sending an SM-VIO to the 2663 last node of the Segment, with the TrackID and the P-RouteID of the 2664 Segment being updated, a Segment Lifetime of zero (0) and a newer 2665 Segment Sequence. The Via Addresses in the SM-VIO indicates the 2666 section of the Segment being modified, from the first to the last 2667 node that is impacted. This can be the whole Segment if it is 2668 totally removed, or a sequence of one or more nodes that have been 2669 bypassed by a Segment update. 2671 The No-Path P-DAO is forwarded normally along the reverse list, even 2672 if the intermediate node does not find a Segment state to clean up. 2673 This results in cleaning up the existing Segment state if any, as 2674 opposed to refreshing an existing one or installing a new one. 2676 6.6. Maintaining a Track 2678 Repathing a Track Segment or Leg may cause jitter and packet 2679 misordering. For critical flows that require timely and/or in-order 2680 delivery, it might be necessary to deploy the PAREO functions 2681 [RAW-ARCHI] over a highly redundant Track. This specification allows 2682 to use more than one Leg for a Track, and 1+N packet redundancy. 2684 This section provides the steps to ensure that no packet is lost due 2685 to the operation itself. This is ensured by installing the new 2686 section from its last node to the first, so when an intermediate node 2687 installs a route along the new section, all the downstream nodes in 2688 the section have already installed their own. The disabled section 2689 is removed when the packets in-flight are forwarded along the new 2690 section as well. 2692 6.6.1. Maintaining a Track Segment 2694 To modify a section of a Segment between a first node and a second, 2695 downstream node (which can be the Ingress and Egress), while 2696 conserving those nodes in the Segment, the Root sends an SM-VIO to 2697 the second node indicating the sequence of nodes in the new section 2698 of the Segment. The SM-VIO indicates the TrackID and the P-RouteID 2699 of the Segment being updated, and a newer Segment Sequence. The 2700 P-DAO is propagated from the second to the first node and on the way, 2701 it updates the state on the nodes that are common to the old and the 2702 new section of the Segment and creates a state in the new nodes. 2704 When the state is updated in an intermediate node, that node might 2705 still receive packets that were in flight from the Ingress to self 2706 over the old section of the Segment. Since the remainder of the 2707 Segment is already updated, the packets are forwarded along the new 2708 version of the Segment from that node on. 2710 After a reasonable time to enable the deprecated sections to empty, 2711 the Root tears down the remaining section(s) of the old segments are 2712 teared down as described in Section 6.5. 2714 6.6.2. Maintaining a Track Leg 2716 This specification allows the Root to add Legs to a Track by sending 2717 a Non-Storing Mode P-DAO to the Ingress associated to the same 2718 TrackID, and a new Segment ID. If the Leg is loose, then the 2719 Segments that join the hops must be created first. It makes sense to 2720 add a new Leg before removing one that is becoming excessively lossy, 2721 and switch to the new Leg before removing the old. Dropping a Track 2722 before the new one is installed would reroute the traffic via the 2723 root; this may augment the latency beyond acceptable thresholds, and 2724 load the network near the root. This may also cause loops in the 2725 case of stitched Tracks; the packets that cannot be injected in the 2726 second Track may be routed back at reinjected at the Ingress of the 2727 first. 2729 It is also possible to update a Track Leg by sending a Non-Storing 2730 Mode P-DAO to the Ingress with the same Segment ID, an incremented 2731 Segment Sequence, and the new complete list of hops in the NSM-VIO. 2732 Updating a live Leg means changing one or more of the intermediate 2733 loose hops, and involves laying out new Segments from and to the new 2734 loose hops before the NSM-VIO for the new Leg is issued. 2736 Packets that are in flight over the old version of the Track Leg 2737 still follow the old source route path over the old Segments. After 2738 a reasonable time to enable the deprecated Segments to empty, the 2739 Root tears down those Segments as described in Section 6.5. 2741 6.7. Encapsulating and Forwarding Along a Track 2743 When injecting a packet in a Track, the Ingress router must 2744 encapsulate the packet using IP-in-IP to add the Source Routing 2745 Header with the final destination set to the Track Egress. 2747 All properties of a Track operations are inherited form the main RPL 2748 Instance that is used to install the Track. For instance, the use of 2749 compression per [RFC8138] is determined by whether it is used in the 2750 RPL Main DODAG, e.g., by setting the "T" flag [RFC9035] in the RPL 2751 configuration option. 2753 The Track Ingress that places a packet in a Track encapsulates it 2754 with an IP-in-IP header, a Routing Header, and an IPv6 Hop-by-Hop 2755 Option Header that contains the RPL Packet Information (RPI) as 2756 follows: 2758 * In the uncompressed form the source of the packet is the address 2759 that this router uses as DODAGID for the Track, the destination is 2760 the first Via Address in the NSM-VIO, and the RH is a Source 2761 Routing Header (SRH) [RFC6554] that contains the list of the 2762 remaining Via Addresses terminating by the Track Egress. 2764 * The preferred alternate in a network where 6LoWPAN Header 2765 Compression [RFC6282] is used is to leverage "IPv6 over Low-Power 2766 Wireless Personal Area Network (6LoWPAN) Paging Dispatch" 2767 [RFC8025] to compress the RPL artifacts as indicated in [RFC8138]. 2769 In that case, the source routed header is the exact copy of the 2770 (chain of) SRH-6LoRH found in the NSM-VIO, also terminating by the 2771 Track Egress. The RPI-6LoRH is appended next, followed by an IP- 2772 in-IP 6LoRH Header that indicates the Ingress router in the 2773 Encapsulator Address field, see as a similar case Figure 20 of 2774 [RFC9035]. 2776 To signal the Track in the packet, this specification leverages the 2777 RPL Forwarding model follows: 2779 * In the data packets, the Track DODAGID and the TrackID MUST be 2780 respectively signaled as the IPv6 Source Address and the 2781 RPLInstanceID field of the RPI that MUST be placed in the outer 2782 chain of IPv6 Headers. 2784 The RPI carries a local RPLInstanceID called the TrackID, which, 2785 in association with the DODAGID, indicates the Track along which 2786 the packet is forwarded. 2788 The D flag in the RPLInstanceID MUST be set to 0 to indicate that 2789 the source address in the IPv6 header is set ot the DODAGID, more 2790 in Section 6.3. 2792 * This draft conforms to the principles of [RFC9008] with regards to 2793 packet forwarding and encapsulation along a Track, as follows: 2795 - With this draft, the Track is a RPL DODAG. From the 2796 perspective of that DODAG, the Track Ingress is the Root, the 2797 Track Egress is a RPL-Aware 6LR, and neighbors of the Track 2798 Egress that can be reached via the Track, but are external to 2799 it, are external destinations and treated as RPL-Unaware Leaves 2800 (RULs). The encapsulation rules in [RFC9008] apply. 2802 - If the Track Ingress is the originator of the packet and the 2803 Track Egress is the destination of the packet, there is no need 2804 for an encapsulation. 2806 - So the Track Ingress must encapsulate the traffic that it did 2807 not originate, and add an RPI. 2809 A packet that is being routed over the RPL Instance associated to 2810 a first Non-Storing Mode Track MAY be placed (encapsulated) in a 2811 second Track to cover one loose hop of the first Track as 2812 discussed in more details Section 3.5.2.3. On the other hand, a 2813 Storing Mode Track must be strict and a packet that it placed in a 2814 Storing Mode Track MUST follow that Track till the Track Egress. 2816 The forwarding of a packet along a track will fail if the Track 2817 continuity is broken,e.g.: 2819 * In the case of a strict path along a Segment, if the next strict 2820 hop is not reachable, the packet is dropped. 2822 * In the case of a loose source-routed path, when the loose next hop 2823 is not a neighbor, there must be a Segment of the same Track to 2824 that loose next hop. When that is the case the packet is 2825 forwarded to the next hop along that segment, or a common neighbor 2826 with the loose next hop, on which case the packet is forwarded to 2827 that neighbor, or another Track to the loose next hop for which 2828 this node or a neighbor is Ingress; in the last case, another 2829 encapsulation takes place and the process possibly recurses; 2830 otherwise the packet is dropped. 2832 * When a Track Egress extracts a packet from a Track (decapsulates 2833 the packet), the destination of the inner packet must be either 2834 this node or a direct neighbor, or a Target of another Segment of 2835 the same Track for which this node is Ingress, otherwise the 2836 packet MUST be dropped. 2838 In case of a failure forwarding a packet along a Segment, e.g., the 2839 next hop is unreachable, the node that discovers the fault MUST send 2840 an ICMPv6 Error message [RFC4443] to the Root, with a new Code "Error 2841 in P-Route" (See Section 11.15). The Root can then repair by 2842 updating the broken Segment and/or Tracks, and in the case of a 2843 broken Segment, remove the leftover sections of the segment using SM- 2844 VIOs with a lifetime of 0 indicating the section ot one or more nodes 2845 being removed (See Section 6.6). 2847 In case of a permanent forwarding error along a Source Route path, 2848 the node that fails to forward SHOULD send an ICMP error with a code 2849 "Error in Source Routing Header" back to the source of the packet, as 2850 described in section 11.2.2.3. of [RPL]. Upon this message, the 2851 encapsulating node SHOULD stop using the source route path for a 2852 reasonable period of time which duration depends on the deployment, 2853 and it SHOULD send an ICMP message with a Code "Error in P-Route" to 2854 the Root. Failure to follow these steps may result in packet loss 2855 and wasted resources along the source route path that is broken. 2857 Either way, the ICMP message MUST be throttled in case of consecutive 2858 occurrences. It MUST be sourced at the ULA or a GUA that is used in 2859 this Track for the source node, so the Root can establish where the 2860 error happened. 2862 The portion of the invoking packet that is sent back in the ICMP 2863 message SHOULD record at least up to the RH if one is present, and 2864 this hop of the RH SHOULD be consumed by this node so that the 2865 destination in the IPv6 header is the next hop that this node could 2866 not reach. if a 6LoWPAN Routing Header (6LoRH) [RFC8138] is used to 2867 carry the IPv6 routing information in the outer header then that 2868 whole 6LoRH information SHOULD be present in the ICMP message. 2870 6.8. Compression of the RPL Artifacts 2872 When using [RFC8138] in the Main DODAG operated in Non-Storing Mode 2873 in a 6LoWPAN LLN, a typical packet that circulates in the Main DODAG 2874 is formatted as shown in Figure 20, representing the case where : 2876 +-+ ... -+- ... -+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-... 2877 |11110001| SRH- | RPI- | IP-in-IP | NH=1 |11110CPP| UDP | UDP 2878 | Page 1 | 6LoRH | 6LoRH | 6LoRH |LOWPAN_IPHC| UDP | hdr |Payld 2879 +-+ ... -+- ... -+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-... 2880 <= RFC 6282 => 2881 <================ Inner packet ==================== = = 2883 Figure 20: A Packet as Forwarded along the Main DODAG 2885 Since there is no page switch between the encapsulated packet and the 2886 encapsulation, the first octet of the compressed packet that acts as 2887 page selector is actually removed at encapsulation, so the inner 2888 packet used in the descriptions below start with the SRH-6LoRH, and 2889 is verbatim the packet represented in Figure 20 from the second octet 2890 on. 2892 When encapsulating that inner packet to place it in the Track, the 2893 first header that the Ingress appends at the head of the inner packet 2894 is an IP-in-IP 6LoRH Header; in that header, the encapsulator 2895 address, which maps to the IPv6 source address in the uncompressed 2896 form, contains a GUA or ULA IPv6 address of the Ingress node that 2897 serves as DODAG ID for the Track, expressed in the compressed form 2898 and using the DODAGID of the Main DODAG as compression reference. If 2899 the address is compressed to 2 bytes, the resulting value for the 2900 Length field shown in Figure 21 is 3, meaning that the SRH-6LoRH as a 2901 whole is 5-octets long. 2903 0 1 2 2904 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 2906 |1|0|1| Length | 6LoRH Type 6 | Hop Limit | Track DODAGID | 2907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 2909 Figure 21: The IP-in-IP 6LoRH Header 2911 At the head of the resulting sequence of bytes, the track Ingress 2912 then adds the RPI that carries the TrackID as RPLinstanceID as a P- 2913 RPI-6LoRH Header, as illustrated in Figure 12, using the TrackID as 2914 RPLInstanceID. Combined with the IP-in-IP 6LoRH Header, this allows 2915 to identify the Track without ambiguity. 2917 The SRH-6LoRH is then added at the head of the resulting sequence of 2918 bytes as a verbatim copy of the content of the SR-VIO that signaled 2919 the selected Track Leg. 2921 0 1 2922 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 .. .. .. 2923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+ 2924 |1|0|0| Size |6LoRH Type 0..4| Hop1 | Hop2 | | HopN | 2925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+ 2926 Where N = Size + 1 2928 Figure 22: The SRH 6LoRH Header 2930 The format of the resulting encapsulated packet in [RFC8138] 2931 compressed form is illustrated in Figure 23: 2933 +-+ ... -+-+-+- ... -+-+-+- ... -+-+-+-+-+- ... +-+-+-+-+-+-+- ... 2934 | Page 1 | SRH-6LoRH | P-RPI-6LoRH | IP-in-IP 6LoRH | Inner Packet 2935 +-+ ... -+-+-+- ... -+-+-+- ... -+-+-+-+-+- ... +-+-+-+-+-+-+- ... 2937 Signals : Loose Hops : TrackID : Track DODAGID : 2939 Figure 23: A Packet as Forwarded along a Track 2941 7. Lesser Constrained Variations 2943 7.1. Storing Mode Main DODAG 2945 This specification expects that the Main DODAG is operated in Non- 2946 Storing Mode. The reasons for that limitation are mostly related to 2947 LLN operations, power and spectrum conservation: 2949 * In Non-Storing Mode The Root already possesses the DODAG topology, 2950 so the additional topological information is reduced to the 2951 siblings. 2953 * The downwards routes are updated with unicast messages to the 2954 Root, which ensures that the Root can reach back to the LLN nodes 2955 after a repair faster than in the case of Storing Mode. Also the 2956 Root can control the use of the path diversity in the DODAG to 2957 reach to the LLN nodes. For both reasons, Non-Storing Mode 2958 provides better capabilities for the Root to maintain the 2959 P-Routes. 2961 * When the Main DODAG is operated in Non-Storing Mode, P-Routes 2962 enable loose Source Routing, which is only an advantage in that 2963 mode. Storing Mode does not use Source Routing Headers, and does 2964 not derive the same benefits from this capability. 2966 On the other hand, since RPL is a Layer-3 routing protocol, its 2967 applicability extends beyond LLNs to a generic IP network. RPL 2968 requires fewer resources than alternative IGPs like OSPF, ISIS, 2969 EIGRP, BABEL or RIP at the expense of a route stretch vs. the 2970 shortest path routes to a destination that those protocols compute. 2971 P-Routes add the capability to install shortest and/or constrained 2972 routes to special destinations such as discussed in section A.9.4. of 2973 the ANIMA ACP [RFC8994]. 2975 In a powered and wired network, when enough memory to store the 2976 needed routes is available, the RPL Storing Mode proposes a better 2977 trade-off than the Non-Storing, as it reduces the route stretch and 2978 lowers the load on the Root. In that case, the control path between 2979 the Root and the LLN nodes is highly available compared to LLNs, and 2980 the nodes can be reached to maintain the P-Routes at most times. 2982 This section specifies the additions that are needed to support 2983 Projected Routes when the Main DODAG is operated in Storing Mode. As 2984 long as the RPI can be processed adequately by the dataplane, the 2985 changes to this specification are limited to the DAO message. The 2986 Track structure, routes and forwarding operations remain the same. 2987 Since there is no capability negotiation, the expectation is that all 2988 the nodes in the network support this specification in the same 2989 fashion, or are configured the same way through management. 2991 In Storing Mode, the Root misses the Child to Parent relationship 2992 that forms the Main DODAG, as well as the sibling information. To 2993 provide that knowledge the nodes in the network MUST send additional 2994 DAO messages that are unicast to the Root as Non-Storing DAO messages 2995 are. 2997 In the DAO message, the originating router advertises a set of 2998 neighbor nodes using Sibling Information Options (SIO)s, regardless 2999 of the relative position in the DODAG of the advertised node vs. this 3000 router. 3002 The DAO message MUST be formed as follows: 3004 * The originating router is identified by the source address of the 3005 DAO. That address MUST be the one that this router registers to 3006 neighbor routers so the Root can correlate the DAOs from those 3007 routers when they advertise this router as their neighbor. The 3008 DAO contains one or more sequences of one Transit Information 3009 Option and one or more Sibling Information Options. There is no 3010 RPL Target Option so the Root is not confused into adding a 3011 Storing Mode route to the Target. 3013 * The TIO is formed as in Storing Mode, and the Parent Address is 3014 not present. The Path Sequence and Path Lifetime fields are 3015 aligned with the values used in the Address Registration of the 3016 node(s) advertised in the SIO, as explained in Section 9.1. of 3017 [RFC9010]. Having similar values in all nodes allows to factorise 3018 the TIO for multiple SIOs as done with [RPL]. 3020 * The TIO is followed by one or more SIOs that provide an address 3021 (ULA or GUA) of the advertised neighbor node. 3023 But the RPL routing information headers may not be supported on all 3024 type of routed network infrastructures, especially not in high-speed 3025 routers. When the RPI is not supported in the dataplane, there 3026 cannot be local RPL Instances and RPL can only operate as a single 3027 topology (the Main DODAG). The RPL Instance is that of the Main 3028 DODAG and the Ingress node that encapsulates is not the Root. The 3029 routes along the Tracks are alternate routes to those available along 3030 the Main DODAG. They MAY conflict with routes to children and MUST 3031 take precedence in the routing table. The Targets MUST be adjacent 3032 to the Track Egress to avoid loops that may form if the packet is 3033 reinjected in the Main DODAG. 3035 7.2. A Track as a Full DODAG 3037 This specification builds parallel or crossing Track Legs as opposed 3038 to a more complex DODAG with interconnections at any place desirable. 3039 The reason for that limitation is related to constrained node 3040 operations, and capability to store large amount of topological 3041 information and compute complex paths: 3043 * With this specification, the node in the LLN has no topological 3044 awareness, and does not need to maintain dynamic information about 3045 the link quality and availability. 3047 * The Root has a complete topological information and statistical 3048 metrics that allow it or its PCE to perform a global optimization 3049 of all Tracks in its DODAG. Based on that information, the Root 3050 computes the Track Leg and predigest the source route paths. 3052 * The node merely selects one of the proposed paths and applies the 3053 associated pre-computed routing header in the encapsulation. This 3054 alleviates both the complexity of computing a path and the 3055 compressed form of the routing header. 3057 The RAW Architecture [RAW-ARCHI] actually expects the PSE at the 3058 Track Ingress to react to changes in the forwarding conditions along 3059 the Track, and reroute packets to maintain the required degree of 3060 reliability. To achieve this, the PSE need the full richness of a 3061 DODAG to form any path that could make meet the Service Level 3062 Objective (SLO). 3064 This section specifies the additions that are needed to turn the 3065 Track into a full DODAG and enable the main Root to provide the 3066 necessary topological information to the Track Ingress. The 3067 expectation is that the metrics that the PSE uses are of an order 3068 other than that of the PCE, because of the difference of time scale 3069 between routing and forwarding, mor e in [RAW-ARCHI]. It follows 3070 that the PSE will learn the metrics it needs from an alternate 3071 source, e.g., OAM frames. 3073 To pass the topological information to the Ingress, the Root uses a 3074 P-DAO messages that contains sequences of Target and Transit 3075 Information options that collectively represent the Track, expressed 3076 in the same fashion as in classical Non-Storing Mode. The difference 3077 as that the Root is the source as opposed to the destination, and can 3078 report information on many Targets, possibly the full Track, with one 3079 P-DAO. 3081 Note that the Path Sequence and Lifetime in the TIO are selected by 3082 the Root, and that the Target/Transit information tupples in the 3083 P-DAO are not those received by the Root in the DAO messages about 3084 the said Targets. The Track may follow sibling routes and does not 3085 need to be congruent with the Main DODAG. 3087 8. Profiles 3089 THIS RFC provides a set of tools that may or may not be needed by an 3090 implementation depending on the type of application it serves. This 3091 sections described profiles that can be implemented separately and 3092 can be used to discriminate what an implementation can and cannot do. 3093 This section describes profiles that enable to implement only a 3094 portion of this specification to meet a particular use case. 3096 Profiles 0 to 2 operate in the Main RPL Instance and do not require 3097 the support of local RPL Instances or the indication of the RPL 3098 Instance in the data plane. Profile 3 and above leverage Local RPL 3099 Instances to build arbitrary Tracks Rooted at the Track Ingress and 3100 using its namespace for TrackID. 3102 Profiles 0 and 1 are REQUIRED by all implementations that may be used 3103 in LLNs; Profiles 1 leverages Storing Mode to reduce the size of the 3104 Source Route Header in the most common LLN deployments. Profile 2 is 3105 RECOMMENDED in high speed / wired environment to enable traffic 3106 Engineering and network automation. All the other profile / 3107 environment combinations are OPTIONAL. 3109 Profile 0 Profile 0 is the Legacy support of [RPL] Non-Storing Mode, 3110 with default routing Northwards (up) and strict source routing 3111 Southwards (down the main DOAG). It provides the minimal common 3112 functionality that must be implemented as a prerequisite to all 3113 the Track-supporting profiles. The other Profiles extend Profile 3114 0 with selected capabilities that this specification introduces on 3115 top. 3117 Profile 1 (Storing Mode P-Route Segments along the Main DODAG) Profi 3118 le 1 does not create new paths; compared to Profile 0, it combines 3119 Storing and Non-Storing Modes to balance the size of the Routing 3120 Header in the packet and the amount of state in the intermediate 3121 routers in a Non-Storing Mode RPL DODAG. 3123 Profile 2 (Non-Storing Mode P-Route Segments along the Main DODAG) P 3124 rofile 2 extends Profile 0 with Strict Source-Routing Non-Storing 3125 Mode P-Routes along the Main DODAG, which is the same as Profile 1 3126 but using NSM VIOs as opposed to SM VIOs. Profile 2 provides the 3127 same capability to compress the SRH in packets down the Main DODAG 3128 as Profile 1, but it require an encapsulation, in order to insert 3129 an additional SRH between the loose source routing hops. In that 3130 case, the Tracks MUST be installed as subTracks of the Main DODAG, 3131 the main RPL Instance MUST be used as TrackID, and the Ingress 3132 node that encapsulates is not the Root as it does not own the 3133 DODAGID. 3135 Profile 3 In order to form the best path possible, those Profiles 3136 require the support of Sibling Information Option to inform the 3137 Root of additional possible hops. Profile 3 extends Profile 1 3138 with additional Storing Mode P-Routes that install segments that 3139 do not follow the Main DODAG. If the Segment Ingress (in the SM- 3140 VIO) is the same as the IPv6 Address of the Track Ingress (in the 3141 projected DAO base Object), the P-DAO creates an implicit Track 3142 between the Segment Ingress and the Segment Egress. 3144 Profile 4 Profile 4 extends Profile 2 with Strict Source-Routing 3145 Non-Storing Mode P-Routes to form East-West Tracks that are inside 3146 the Main DODAG but do not necessarily follow it. A Track is 3147 formed as one or more strict source source routed paths between 3148 the Root that is the Track Ingress, and the Track Egress that is 3149 the last node. 3151 Profile 5 Profile 5 Combines Profile 4 with Profile 1 and enables to 3152 loose source routing between the Ingress and the Egress of the 3153 Track. As in Profile 1, Storing Mode P-Routes connect the dots in 3154 the loose source route. 3156 Profile 6 Profile 6 Combines Profile 4 with Profile 2 and also 3157 enables to loose source routing between the Ingress and the Egress 3158 of the Track. 3160 Profile 7 Profile 7 implements profile 5 in a Main DODAG that is 3161 operated in Storing Mode as presented in Section 7.1. As in 3162 Profile 1 and 2, the TrackID is the RPLInstanceID of the Main 3163 DODAG. Longest match rules decide whether a packet is sent along 3164 the Main DODAG or rerouted in a track. 3166 Profile 8 Profile 8 is offered in preparation of the RAW work, and 3167 for use cases where an arbitrary node in the network can afford 3168 the same code complexity as the RPL Root in a traditional 3169 deployment. It offers a full DODAG visibility to the Track 3170 Ingress as specified in Section 7.2 in a Non-Storing Mode Main 3171 DODAG. 3173 Profile 9 Profile 9 combines profiles 7 and 8, operating the Track 3174 as a full DODAG within a Storing Mode Main DODAG, using only the 3175 Main DODAG RPLInstanceID as TrackID. 3177 9. Backwards Compatibility 3179 This specification can operate in a mixed network where some nodes 3180 support it and some do not. There are restructions, though. All 3181 nodes that need to process a P-DAO MUST support this specification. 3182 As discussed in Section 3.7.1, how the root knows whether the nodes 3183 capabilities and whether it support this specification is out of 3184 scope. 3186 This specification defines the 'D' flag in the RPL DODAG 3187 Configuration Option (see Section 4.1.7) to signal that the RPL nodes 3188 can request the creation of Tracks. The requester may not know 3189 whether the Track can effectively be constructed, and whether enough 3190 nodes along the preferred paths support this specification. 3191 Therefore it makes sense to only set the 'D' flags in DIO when the 3192 conditions of success are in place, in particular when all the nodes 3193 that could be on path of tracks are upgraded. 3195 10. Security Considerations 3197 It is worth noting that with [RPL], every node in the LLN is RPL- 3198 aware and can inject any RPL-based attack in the network. This draft 3199 uses messages that are already present in RPL [RPL] with optional 3200 secured versions. The same secured versions may be used with this 3201 draft, and whatever security is deployed for a given network also 3202 applies to the flows in this draft. 3204 The LLN nodes depend on the 6LBR and the RPL participants for their 3205 operation. A trust model is necessary to ensure that the right 3206 devices are acting in these roles, so as to avoid threats such as 3207 black-holing, (see [RFC7416] section 7). This trust model could be 3208 at a minimum based on a Layer-2 Secure joining and the Link-Layer 3209 security. This is a generic 6LoWPAN requirement, see Req5.1 in 3210 Appendix B.5 of [RFC8505]. 3212 In a general manner, the Security Considerations in [RPL], and 3213 [RFC7416] apply to this specification as well. The Link-Layer 3214 security is needed in particular to prevent Denial-Of-Service attacks 3215 whereby a rogue router creates a high churn in the RPL network by 3216 constantly injected forged P-DAO messages and using up all the 3217 available storage in the attacked routers. 3219 With this specification, only the Root may generate P-DAO messages. 3220 PDR messages may only be sent to the Root. This specification 3221 expects that the communication with the Root is authenticated but 3222 does enforce which method is used. 3224 Additionally, the trust model could include a role validation (e.g., 3225 using a role-based authorization) to ensure that the node that claims 3226 to be a RPL Root is entitled to do so. That trust should propagate 3227 from Egress to Ingress in the case of a Storing Mode P-DAO. 3229 This specification suggests some validation of the VIO to prevent 3230 basic loops by avoiding that a node appears twice. But that is only 3231 a minimal protection. Arguably, an attacker that can inject P-DAOs 3232 can reroute any traffic and deplete critical resources such as 3233 spectrum and battery in the LLN rapidly. 3235 11. IANA Considerations 3237 11.1. RPL DODAG Configuration Option Flag 3239 IANA is requested to assign a flag from the "DODAG Configuration 3240 Option Flags for MOP 0..6" [RFC9010] registry as follows: 3242 +---------------+------------------------------+-----------+ 3243 | Bit Number | Capability Description | Reference | 3244 +---------------+------------------------------+-----------+ 3245 | 0 (suggested) | Projected Routes Support (D) | THIS RFC | 3246 +---------------+------------------------------+-----------+ 3248 Table 21: New DODAG Configuration Option Flag 3250 IANA is requested to add [THIS RFC] as a reference for MOP 7 in the 3251 RPL Mode of Operation registry. 3253 11.2. Elective 6LoWPAN Routing Header Type 3255 THIS RFC updates the IANA registry titled "Elective 6LoWPAN Routing 3256 Header Type" that was created for [RFC8138] and assigns the following 3257 value: 3259 +===============+=============+===========+ 3260 | Value | Description | Reference | 3261 +===============+=============+===========+ 3262 | 8 (Suggested) | P-RPI-6LoRH | THIS RFC | 3263 +---------------+-------------+-----------+ 3265 Table 22: New Elective 6LoWPAN Routing 3266 Header Type 3268 11.3. Critical 6LoWPAN Routing Header Type 3270 THIS RFC updates the IANA registry titled "Critical 6LoWPAN Routing 3271 Header Type" that was created for [RFC8138] and assigns the following 3272 value: 3274 +===============+=============+===========+ 3275 | Value | Description | Reference | 3276 +===============+=============+===========+ 3277 | 8 (Suggested) | P-RPI-6LoRH | THIS RFC | 3278 +---------------+-------------+-----------+ 3280 Table 23: New Critical 6LoWPAN Routing 3281 Header Type 3283 11.4. Subregistry For The RPL Option Flags 3285 IANA is required to create a subregistry for the 8-bit RPL Option 3286 Flags field, as detailed in Figure 11, under the "Routing Protocol 3287 for Low Power and Lossy Networks (RPL)" registry. The bits are 3288 indexed from 0 (leftmost) to 7. Each bit is Tracked with the 3289 following qualities: 3291 * Bit number (counting from bit 0 as the most significant bit) 3293 * Indication When Set 3295 * Reference 3297 Registration procedure is "Standards Action" [RFC8126]. The initial 3298 allocation is as indicated in Table 27: 3300 +===============+======================+===========+ 3301 | Bit number | Indication When Set | Reference | 3302 +===============+======================+===========+ 3303 | 0 | Down 'O' | [RFC6553] | 3304 +---------------+----------------------+-----------+ 3305 | 1 | Rank-Error (R) | [RFC6553] | 3306 +---------------+----------------------+-----------+ 3307 | 2 | Forwarding-Error (F) | [RFC6553] | 3308 +---------------+----------------------+-----------+ 3309 | 3 (Suggested) | Projected-Route (P) | THIS RFC | 3310 +---------------+----------------------+-----------+ 3312 Table 24: Initial PDR Flags 3314 11.5. RPL Control Codes 3316 THIS RFC extends the IANA Subregistry created by RFC 6550 for RPL 3317 Control Codes as indicated in Table 25: 3319 +==================+=============================+===========+ 3320 | Code | Description | Reference | 3321 +==================+=============================+===========+ 3322 | 0x09 (Suggested) | Projected DAO Request (PDR) | THIS RFC | 3323 +------------------+-----------------------------+-----------+ 3324 | 0x0A (Suggested) | PDR-ACK | THIS RFC | 3325 +------------------+-----------------------------+-----------+ 3327 Table 25: New RPL Control Codes 3329 11.6. RPL Control Message Options 3331 THIS RFC extends the IANA Subregistry created by RFC 6550 for RPL 3332 Control Message Options as indicated in Table 26: 3334 +==================+=============================+===========+ 3335 | Value | Meaning | Reference | 3336 +==================+=============================+===========+ 3337 | 0x0E (Suggested) | Stateful VIO (SM-VIO) | THIS RFC | 3338 +------------------+-----------------------------+-----------+ 3339 | 0x0F (Suggested) | Source-Routed VIO (NSM-VIO) | THIS RFC | 3340 +------------------+-----------------------------+-----------+ 3341 | 0x10 (Suggested) | Sibling Information option | THIS RFC | 3342 +------------------+-----------------------------+-----------+ 3344 Table 26: RPL Control Message Options 3346 11.7. SubRegistry for the Projected DAO Request Flags 3348 IANA is required to create a registry for the 8-bit Projected DAO 3349 Request (PDR) Flags field. Each bit is Tracked with the following 3350 qualities: 3352 * Bit number (counting from bit 0 as the most significant bit) 3354 * Capability description 3356 * Reference 3358 Registration procedure is "Standards Action" [RFC8126]. The initial 3359 allocation is as indicated in Table 27: 3361 +============+========================================+===========+ 3362 | Bit number | Capability description | Reference | 3363 +============+========================================+===========+ 3364 | 0 | PDR-ACK request (K) | THIS RFC | 3365 +------------+----------------------------------------+-----------+ 3366 | 1 | Requested path should be redundant (R) | THIS RFC | 3367 +------------+----------------------------------------+-----------+ 3369 Table 27: Initial PDR Flags 3371 11.8. SubRegistry for the PDR-ACK Flags 3373 IANA is required to create an subregistry for the 8-bit PDR-ACK Flags 3374 field. Each bit is Tracked with the following qualities: 3376 * Bit number (counting from bit 0 as the most significant bit) 3378 * Capability description 3380 * Reference 3381 Registration procedure is "Standards Action" [RFC8126]. No bit is 3382 currently defined for the PDR-ACK Flags. 3384 11.9. Subregistry for the PDR-ACK Acceptance Status Values 3386 IANA is requested to create a Subregistry for the PDR-ACK Acceptance 3387 Status values. 3389 * Possible values are 6-bit unsigned integers (0..63). 3391 * Registration procedure is "Standards Action" [RFC8126]. 3393 * Initial allocation is as indicated in Table 28: 3395 +-------+------------------------+-----------+ 3396 | Value | Meaning | Reference | 3397 +-------+------------------------+-----------+ 3398 | 0 | Unqualified Acceptance | THIS RFC | 3399 +-------+------------------------+-----------+ 3401 Table 28: Acceptance values of the PDR-ACK 3402 Status 3404 11.10. Subregistry for the PDR-ACK Rejection Status Values 3406 IANA is requested to create a Subregistry for the PDR-ACK Rejection 3407 Status values. 3409 * Possible values are 6-bit unsigned integers (0..63). 3411 * Registration procedure is "Standards Action" [RFC8126]. 3413 * Initial allocation is as indicated in Table 29: 3415 +-------+-----------------------+-----------+ 3416 | Value | Meaning | Reference | 3417 +-------+-----------------------+-----------+ 3418 | 0 | Unqualified Rejection | THIS RFC | 3419 +-------+-----------------------+-----------+ 3420 | 1 | Transient Failure | THIS RFC | 3421 +-------+-----------------------+-----------+ 3423 Table 29: Rejection values of the PDR-ACK 3424 Status 3426 11.11. SubRegistry for the Via Information Options Flags 3428 IANA is requested to create a Subregistry for the 5-bit Via 3429 Information Options (Via Information Option) Flags field. Each bit 3430 is Tracked with the following qualities: 3432 * Bit number (counting from bit 0 as the most significant bit) 3434 * Capability description 3436 * Reference 3438 Registration procedure is "Standards Action" [RFC8126]. No bit is 3439 currently defined for the Via Information Options (Via Information 3440 Option) Flags. 3442 11.12. SubRegistry for the Sibling Information Option Flags 3444 IANA is required to create a registry for the 5-bit Sibling 3445 Information Option (SIO) Flags field. Each bit is Tracked with the 3446 following qualities: 3448 * Bit number (counting from bit 0 as the most significant bit) 3450 * Capability description 3452 * Reference 3454 Registration procedure is "Standards Action" [RFC8126]. The initial 3455 allocation is as indicated in Table 30: 3457 +===============+========================+===========+ 3458 | Bit number | Capability description | Reference | 3459 +===============+========================+===========+ 3460 | 0 (Suggested) | "S" flag: Sibling in | THIS RFC | 3461 | | same DODAG as Self | | 3462 +---------------+------------------------+-----------+ 3464 Table 30: Initial SIO Flags 3466 11.13. Destination Advertisement Object Flag 3468 THIS RFC modifies the "Destination Advertisement Object (DAO) Flags" 3469 registry initially created in Section 20.11 of [RPL] . 3471 Section 4.1.1 also defines one new entry in the Registry as follows: 3473 +---------------+------------------------+-----------+ 3474 | Bit Number | Capability Description | Reference | 3475 +---------------+------------------------+-----------+ 3476 | 2 (Suggested) | Projected DAO (P) | THIS RFC | 3477 +---------------+------------------------+-----------+ 3479 Table 31: New Destination Advertisement Object 3480 (DAO) Flag 3482 11.14. Destination Advertisement Object Acknowledgment Flag 3484 THIS RFC modifies the "Destination Advertisement Object (DAO) 3485 Acknowledgment Flags" registry initially created in Section 20.12 of 3486 [RPL] . 3488 Section 4.1.2 also defines one new entry in the Registry as follows: 3490 +---------------+------------------------+-----------+ 3491 | Bit Number | Capability Description | Reference | 3492 +---------------+------------------------+-----------+ 3493 | 1 (Suggested) | Projected DAO-ACK (P) | THIS RFC | 3494 +---------------+------------------------+-----------+ 3496 Table 32: New Destination Advertisement Object 3497 Acknowledgment Flag 3499 11.15. New ICMPv6 Error Code 3501 In some cases RPL will return an ICMPv6 error message when a message 3502 cannot be forwarded along a P-Route. 3504 IANA has defined an ICMPv6 "Code" Fields Registry for ICMPv6 Message 3505 Types. ICMPv6 Message Type 1 describes "destination Unreachable" 3506 codes. This specification requires that a new code is allocated from 3507 the ICMPv6 Code Fields Registry for ICMPv6 Message Type 1, for "Error 3508 in P-Route", with a suggested code value of 8, to be confirmed by 3509 IANA. 3511 11.16. RPL Rejection Status values 3513 This specification updates the Subregistry for the "RPL Rejection 3514 Status" values under the RPL registry, as follows: 3516 +---------------+-------------------------+-----------+ 3517 | Value | Meaning | Reference | 3518 +---------------+-------------------------+-----------+ 3519 | 2 (Suggested) | Out of Resources | THIS RFC | 3520 +---------------+-------------------------+-----------+ 3521 | 3 (Suggested) | Error in VIO | THIS RFC | 3522 +---------------+-------------------------+-----------+ 3523 | 4 (Suggested) | Predecessor Unreachable | THIS RFC | 3524 +---------------+-------------------------+-----------+ 3525 | 5 (Suggested) | Unreachable Target | THIS RFC | 3526 +---------------+-------------------------+-----------+ 3527 | 6..63 | Unassigned | | 3528 +---------------+-------------------------+-----------+ 3530 Table 33: Rejection values of the RPL Status 3532 12. Acknowledgments 3534 The authors wish to acknowledge JP Vasseur, Remy Liubing, James 3535 Pylakutty, and Patrick Wetterwald for their contributions to the 3536 ideas developed here. Many thanks to Dominique Barthel and SVR Anand 3537 for their global contribution to 6TiSCH, RAW and this RFC, as well as 3538 text suggestions that were incorporated. Also special thanks Li Zhao 3539 and Toerless Eckert for their in-depth reviews, with many excellent 3540 suggestions that improved the readability and well as the content of 3541 the specification. Many thanks to Remous-Aris Koutsiamanis for his 3542 review during WGLC. 3544 13. Normative References 3546 [INT-ARCHI] 3547 Braden, R., Ed., "Requirements for Internet Hosts - 3548 Communication Layers", STD 3, RFC 1122, 3549 DOI 10.17487/RFC1122, October 1989, 3550 . 3552 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3553 Requirement Levels", BCP 14, RFC 2119, 3554 DOI 10.17487/RFC2119, March 1997, 3555 . 3557 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 3558 Control Message Protocol (ICMPv6) for the Internet 3559 Protocol Version 6 (IPv6) Specification", STD 89, 3560 RFC 4443, DOI 10.17487/RFC4443, March 2006, 3561 . 3563 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 3564 Computation Element (PCE)-Based Architecture", RFC 4655, 3565 DOI 10.17487/RFC4655, August 2006, 3566 . 3568 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 3569 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 3570 DOI 10.17487/RFC6282, September 2011, 3571 . 3573 [RPL] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 3574 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 3575 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 3576 Low-Power and Lossy Networks", RFC 6550, 3577 DOI 10.17487/RFC6550, March 2012, 3578 . 3580 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 3581 Power and Lossy Networks (RPL) Option for Carrying RPL 3582 Information in Data-Plane Datagrams", RFC 6553, 3583 DOI 10.17487/RFC6553, March 2012, 3584 . 3586 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 3587 Routing Header for Source Routes with the Routing Protocol 3588 for Low-Power and Lossy Networks (RPL)", RFC 6554, 3589 DOI 10.17487/RFC6554, March 2012, 3590 . 3592 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 3593 Writing an IANA Considerations Section in RFCs", BCP 26, 3594 RFC 8126, DOI 10.17487/RFC8126, June 2017, 3595 . 3597 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 3598 "IPv6 over Low-Power Wireless Personal Area Network 3599 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 3600 April 2017, . 3602 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3603 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 3604 May 2017, . 3606 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 3607 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 3608 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 3609 . 3611 [RFC9008] Robles, M.I., Richardson, M., and P. Thubert, "Using RPI 3612 Option Type, Routing Header for Source Routes, and IPv6- 3613 in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008, 3614 DOI 10.17487/RFC9008, April 2021, 3615 . 3617 14. Informative References 3619 [6LoWPAN] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 3620 "Transmission of IPv6 Packets over IEEE 802.15.4 3621 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 3622 . 3624 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 3625 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 3626 DOI 10.17487/RFC5440, March 2009, 3627 . 3629 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and 3630 J. Martocci, "Reactive Discovery of Point-to-Point Routes 3631 in Low-Power and Lossy Networks", RFC 6997, 3632 DOI 10.17487/RFC6997, August 2013, 3633 . 3635 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 3636 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 3637 2014, . 3639 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 3640 and M. Richardson, Ed., "A Security Threat Analysis for 3641 the Routing Protocol for Low-Power and Lossy Networks 3642 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 3643 . 3645 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 3646 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 3647 RFC 8025, DOI 10.17487/RFC8025, November 2016, 3648 . 3650 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 3651 Decraene, B., Litkowski, S., and R. Shakir, "Segment 3652 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 3653 July 2018, . 3655 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 3656 Perkins, "Registration Extensions for IPv6 over Low-Power 3657 Wireless Personal Area Network (6LoWPAN) Neighbor 3658 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 3659 . 3661 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 3662 "Deterministic Networking Architecture", RFC 8655, 3663 DOI 10.17487/RFC8655, October 2019, 3664 . 3666 [RFC8930] Watteyne, T., Ed., Thubert, P., Ed., and C. Bormann, "On 3667 Forwarding 6LoWPAN Fragments over a Multi-Hop IPv6 3668 Network", RFC 8930, DOI 10.17487/RFC8930, November 2020, 3669 . 3671 [RFC8931] Thubert, P., Ed., "IPv6 over Low-Power Wireless Personal 3672 Area Network (6LoWPAN) Selective Fragment Recovery", 3673 RFC 8931, DOI 10.17487/RFC8931, November 2020, 3674 . 3676 [RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An 3677 Autonomic Control Plane (ACP)", RFC 8994, 3678 DOI 10.17487/RFC8994, May 2021, 3679 . 3681 [RFC9010] Thubert, P., Ed. and M. Richardson, "Routing for RPL 3682 (Routing Protocol for Low-Power and Lossy Networks) 3683 Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021, 3684 . 3686 [RFC9030] Thubert, P., Ed., "An Architecture for IPv6 over the Time- 3687 Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)", 3688 RFC 9030, DOI 10.17487/RFC9030, May 2021, 3689 . 3691 [RFC9035] Thubert, P., Ed. and L. Zhao, "A Routing Protocol for Low- 3692 Power and Lossy Networks (RPL) Destination-Oriented 3693 Directed Acyclic Graph (DODAG) Configuration Option for 3694 the 6LoWPAN Routing Header", RFC 9035, 3695 DOI 10.17487/RFC9035, April 2021, 3696 . 3698 [RAW-ARCHI] 3699 Thubert, P. and G. Z. Papadopoulos, "Reliable and 3700 Available Wireless Architecture", Work in Progress, 3701 Internet-Draft, draft-ietf-raw-architecture-04, 4 March 3702 2022, . 3705 [USE-CASES] 3706 Bernardos, C. J., Papadopoulos, G. Z., Thubert, P., and F. 3707 Theoleyre, "RAW use-cases", Work in Progress, Internet- 3708 Draft, draft-ietf-raw-use-cases-05, 23 February 2022, 3709 . 3712 [I-D.kuehlewind-update-tag] 3713 Kuehlewind, M. and S. Krishnan, "Definition of new tags 3714 for relations between RFCs", Work in Progress, Internet- 3715 Draft, draft-kuehlewind-update-tag-04, 12 July 2021, 3716 . 3719 [I-D.irtf-panrg-path-properties] 3720 Enghardt, T. and C. Krähenbühl, "A Vocabulary of Path 3721 Properties", Work in Progress, Internet-Draft, draft-irtf- 3722 panrg-path-properties-05, 7 March 2022, 3723 . 3726 [PCE] IETF, "Path Computation Element", 3727 . 3729 Authors' Addresses 3731 Pascal Thubert (editor) 3732 Cisco Systems, Inc 3733 Building D 3734 45 Allee des Ormes - BP1200 3735 06254 Mougins - Sophia Antipolis 3736 France 3737 Phone: +33 497 23 26 34 3738 Email: pthubert@cisco.com 3739 Rahul Arvind Jadhav 3740 Huawei Tech 3741 Kundalahalli Village, Whitefield, 3742 Bangalore 560037 3743 Karnataka 3744 India 3745 Phone: +91-080-49160700 3746 Email: rahul.ietf@gmail.com 3748 Michael C. Richardson 3749 Sandelman Software Works 3750 Email: mcr+ietf@sandelman.ca 3751 URI: http://www.sandelman.ca/