idnits 2.17.00 (12 Aug 2021) /tmp/idnits29723/draft-ietf-roll-dao-projection-22.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1394 has weird spacing: '...-- Node z-- ...' == Line 1401 has weird spacing: '... Node z-- ...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Since the state about a Leg of a Track is located only on the Ingress Node, the Root cleans up the Leg by sending an NSM-VIO to the Ingress indicating the TrackID and the P-RouteID of the Leg being removed, a Segment Lifetime of 0 and a newer Segment Sequence. The SRH-6LoRH with the Via Addresses in the NSM-VIO are not needed; it SHOULD not be placed in the message and MUST be ignored by the receiver. Upon that NSM-VIO, the Ingress node removes all state for that Track if any, and replies positively anyway. -- The document date (25 November 2021) is 177 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 3135, but not defined ** Downref: Normative reference to an Informational RFC: RFC 4655 == Outdated reference: A later version (-04) exists of draft-ietf-raw-architecture-01 == Outdated reference: A later version (-05) exists of draft-ietf-raw-use-cases-03 == Outdated reference: A later version (-05) exists of draft-irtf-panrg-path-properties-04 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL P. Thubert, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track R.A. Jadhav 5 Expires: 29 May 2022 Huawei Tech 6 M. Gillmore 7 Itron 8 25 November 2021 10 Root initiated routing state in RPL 11 draft-ietf-roll-dao-projection-22 13 Abstract 15 This document extends RFC 6550, RFC 6553, and RFC 8138 to enable a 16 RPL Root to install and maintain Projected Routes within its DODAG, 17 along a selected set of nodes that may or may not include self, for a 18 chosen duration. This potentially enables routes that are more 19 optimized or resilient than those obtained with the classical 20 distributed operation of RPL, either in terms of the size of a 21 Routing Header or in terms of path length, which impacts both the 22 latency and the packet delivery ratio. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 29 May 2022. 41 Copyright Notice 43 Copyright (c) 2021 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Revised BSD License text as 52 described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Revised BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 60 2.2. References . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.4. Domain Terms . . . . . . . . . . . . . . . . . . . . . . 5 63 2.4.1. Projected Route . . . . . . . . . . . . . . . . . . . 6 64 2.4.2. Projected DAO . . . . . . . . . . . . . . . . . . . . 6 65 2.4.3. Path . . . . . . . . . . . . . . . . . . . . . . . . 6 66 2.4.4. Routing Stretch . . . . . . . . . . . . . . . . . . . 6 67 2.4.5. Track . . . . . . . . . . . . . . . . . . . . . . . . 7 68 3. Context and Goal . . . . . . . . . . . . . . . . . . . . . . 9 69 3.1. RPL Applicability . . . . . . . . . . . . . . . . . . . . 9 70 3.2. RPL Routing Modes . . . . . . . . . . . . . . . . . . . . 10 71 3.3. Requirements . . . . . . . . . . . . . . . . . . . . . . 11 72 3.3.1. Loose Source Routing . . . . . . . . . . . . . . . . 11 73 3.3.2. East-West Routes . . . . . . . . . . . . . . . . . . 13 74 3.4. On Tracks . . . . . . . . . . . . . . . . . . . . . . . . 14 75 3.4.1. Building Tracks With RPL . . . . . . . . . . . . . . 15 76 3.4.2. Tracks and RPL Instances . . . . . . . . . . . . . . 15 77 3.5. Serial Track Signaling . . . . . . . . . . . . . . . . . 16 78 3.5.1. Using Storing Mode Segments . . . . . . . . . . . . . 17 79 3.5.2. Using Non-Storing Mode joining Tracks . . . . . . . . 24 80 3.6. Complex Tracks . . . . . . . . . . . . . . . . . . . . . 31 81 3.7. Scope and Expectations . . . . . . . . . . . . . . . . . 33 82 3.7.1. External Dependencies . . . . . . . . . . . . . . . . 33 83 3.7.2. Positioning vs. Related IETF Standards . . . . . . . 33 84 4. Extending existing RFCs . . . . . . . . . . . . . . . . . . . 35 85 4.1. Extending RFC 6550 . . . . . . . . . . . . . . . . . . . 35 86 4.1.1. Projected DAO . . . . . . . . . . . . . . . . . . . . 36 87 4.1.2. Via Information Option . . . . . . . . . . . . . . . 37 88 4.1.3. Sibling Information Option . . . . . . . . . . . . . 37 89 4.1.4. P-DAO Request . . . . . . . . . . . . . . . . . . . . 38 90 4.1.5. Extending the RPI . . . . . . . . . . . . . . . . . . 38 91 4.1.6. Additional Flag in the RPL DODAG Configuration 92 Option . . . . . . . . . . . . . . . . . . . . . . . 38 93 4.2. Extending RFC 6553 . . . . . . . . . . . . . . . . . . . 39 94 4.3. Extending RFC 8138 . . . . . . . . . . . . . . . . . . . 40 95 5. New RPL Control Messages and Options . . . . . . . . . . . . 41 96 5.1. New P-DAO Request Control Message . . . . . . . . . . . . 42 97 5.2. New PDR-ACK Control Message . . . . . . . . . . . . . . . 43 98 5.3. Via Information Options . . . . . . . . . . . . . . . . . 44 99 5.4. Sibling Information Option . . . . . . . . . . . . . . . 47 100 6. Root Initiated Routing State . . . . . . . . . . . . . . . . 49 101 6.1. RPL Network Setup . . . . . . . . . . . . . . . . . . . . 49 102 6.2. Requesting a Track . . . . . . . . . . . . . . . . . . . 49 103 6.3. Identifying a Track . . . . . . . . . . . . . . . . . . . 50 104 6.4. Installing a Track . . . . . . . . . . . . . . . . . . . 51 105 6.4.1. Signaling a Projected Route . . . . . . . . . . . . . 52 106 6.4.2. Installing a Track Segment with a Storing Mode 107 P-Route . . . . . . . . . . . . . . . . . . . . . . . 53 108 6.4.3. Installing a Track Leg with a Non-Storing Mode 109 P-Route . . . . . . . . . . . . . . . . . . . . . . . 55 110 6.5. Tearing Down a P-Route . . . . . . . . . . . . . . . . . 57 111 6.6. Maintaining a Track . . . . . . . . . . . . . . . . . . . 57 112 6.6.1. Maintaining a Track Segment . . . . . . . . . . . . . 58 113 6.6.2. Maintaining a Track Leg . . . . . . . . . . . . . . . 58 114 6.7. Encapsulating and Forwarding Along a Track . . . . . . . 59 115 6.8. Compression of the RPL Artifacts . . . . . . . . . . . . 61 116 7. Lesser Constrained Variations . . . . . . . . . . . . . . . . 63 117 7.1. Storing Mode Main DODAG . . . . . . . . . . . . . . . . . 63 118 7.2. A Track as a Full DODAG . . . . . . . . . . . . . . . . . 65 119 8. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 66 120 9. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 68 121 10. Security Considerations . . . . . . . . . . . . . . . . . . . 69 122 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69 123 11.1. RPL DODAG Configuration Option Flag . . . . . . . . . . 69 124 11.2. Elective 6LoWPAN Routing Header Type . . . . . . . . . . 70 125 11.3. Critical 6LoWPAN Routing Header Type . . . . . . . . . . 70 126 11.4. Subregistry For The RPL Option Flags . . . . . . . . . . 70 127 11.5. RPL Control Codes . . . . . . . . . . . . . . . . . . . 71 128 11.6. RPL Control Message Options . . . . . . . . . . . . . . 71 129 11.7. SubRegistry for the Projected DAO Request Flags . . . . 72 130 11.8. SubRegistry for the PDR-ACK Flags . . . . . . . . . . . 72 131 11.9. Subregistry for the PDR-ACK Acceptance Status Values . . 73 132 11.10. Subregistry for the PDR-ACK Rejection Status Values . . 73 133 11.11. SubRegistry for the Via Information Options Flags . . . 73 134 11.12. SubRegistry for the Sibling Information Option Flags . . 74 135 11.13. destination Advertisement Object Flag . . . . . . . . . 74 136 11.14. New ICMPv6 Error Code . . . . . . . . . . . . . . . . . 75 137 11.15. RPL Rejection Status values . . . . . . . . . . . . . . 75 138 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 76 139 13. Normative References . . . . . . . . . . . . . . . . . . . . 76 140 14. Informative References . . . . . . . . . . . . . . . . . . . 77 141 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 80 143 1. Introduction 145 RPL, the "Routing Protocol for Low Power and Lossy Networks" [RPL] 146 (LLNs), is an anisotropic Distance Vector protocol that is well- 147 suited for application in a variety of low energy Internet of Things 148 (IoT) networks where stretched P2P paths are acceptable vs. the 149 signaling and state overhead involved in maintaining shortest paths 150 across. 152 RPL forms destination Oriented Directed Acyclic Graphs (DODAGs) in 153 which the Root often acts as the Border router to connect the RPL 154 domain to the IP backbone and routes along that graph up, towards the 155 Root, and down towards the nodes. 157 With this specification, an abstract routing function called a Path 158 Computation Element [PCE] (e.g., located in an central controller or 159 collocated with the Root) interacts with the RPL Root to compute Peer 160 to Peer (P2P) paths within a pre-existing RPL Main DODAG. The 161 topological information that is passed to the PCE is derived from the 162 DODAG that is already available at the Root in RPL Non-Storing Mode. 163 This specification introduces protocol extensions that enrich the 164 topological information that is available at the Root and passed to 165 the PCE. 167 Based on usage, path length, and knowledge of available resources 168 such as battery levels and reservable buffers in the nodes, the PCE 169 with a global visibility on the system can optimize the computed 170 routes for the application needs, including the capability to provide 171 path redundancy. This specification also introduces protocol 172 extensions that enable the Root to translates the computed paths into 173 RPL and install them as Projected Routes (aka P-Routes) inside the 174 DODAG on behalf of a PCE. 176 2. Terminology 178 2.1. Requirements Language 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 182 "OPTIONAL" in this document are to be interpreted as described in BCP 183 14 [RFC2119][RFC8174] when, and only when, they appear in all 184 capitals, as shown here. 186 2.2. References 188 In this document, readers will encounter terms and concepts that are 189 discussed in the "Routing Protocol for Low Power and Lossy Networks" 190 [RPL], the "6TiSCH Architecture" [6TiSCH-ARCHI], the "Deterministic 191 Networking Architecture" [RFC8655], the "Reliable and Available 192 Wireless (RAW) Architecture/Framework" [RAW-ARCHI], and "Terminology 193 in Low power And Lossy Networks" [RFC7102]. 195 2.3. Glossary 197 This document often uses the following acronyms: 199 CMO: Control Message Option 200 DAO: destination Advertisement Object 201 DAG: Directed Acyclic Graph 202 DODAG: destination-Oriented Directed Acyclic Graph; A DAG with only 203 one vertex (i.e., node) that has no outgoing edge (i.e., link) 204 GUA: IPv6 Global Unicast Address 205 LLN: Low-Power and Lossy Network 206 MOP: RPL Mode of Operation 207 P-DAO: Projected DAO 208 P-Route: Projected Route 209 PDR: P-DAO Request 210 RAN: RPL-Aware Node (either a RPL router or a RPL-Aware Leaf) 211 RAL: RPL-Aware Leaf 212 RH: Routing Header 213 RPI: RPL Packet Information 214 RTO: RPL Target Option 215 RUL: RPL-Unaware Leaf 216 SIO: RPL Sibling Information Option 217 ULA: IPv6 Unique Local Address 218 NSM-VIO: A Source-Routed Via Information Option, used in Non-Storing 219 Mode P-DAO messages. 220 SLO: Service Level Objective 221 TIO: RPL Transit Information Option 222 SM-VIO: A strict Via Information Option, used in Storing Mode P-DAO 223 messages. 224 VIO: A Via Information Option; it can be a SM-VIO or an NSM-VIO. 226 2.4. Domain Terms 228 This specification uses the following terminology: 230 2.4.1. Projected Route 232 A RPL P-Route is a RPL route that is computed remotely by a PCE, and 233 installed and maintained by a RPL Root on behalf of the PCE. It is 234 installed as a state that signals that destinations (aka Targets) are 235 reachable along a sequence of nodes. 237 2.4.2. Projected DAO 239 A DAO message used to install a P-Route. 241 2.4.3. Path 243 Quoting section 1.1.3 of [INT-ARCHI]: 245 | At a given moment, all the IP datagrams from a particular source 246 | host to a particular destination host will typically traverse the 247 | same sequence of gateways. We use the term "path" for this 248 | sequence. Note that a path is uni-directional; it is not unusual 249 | to have different paths in the two directions between a given host 250 | pair. 252 Section 2 of [I-D.irtf-panrg-path-properties] points to a longer, 253 more modern definition of path, which begins as follows: 255 | A sequence of adjacent path elements over which a packet can be 256 | transmitted, starting and ending with a node. A path is 257 | unidirectional. Paths are time-dependent, i.e., the sequence of 258 | path elements over which packets are sent from one node to another 259 | may change. A path is defined between two nodes. 261 It follows that the general acceptance of a path is a linear sequence 262 of nodes, as opposed to a multi-dimensional graph. In the context of 263 this document, a path is observed by following one copy of a packet 264 that is injected in a Track and possibly replicated within. 266 2.4.4. Routing Stretch 268 RPL is anisotropic, meaning that it is directional, or more exactly 269 polar. RPL does not behave the same way "down" with multicast DIO 270 messages that form the DODAG and "up" with unicast DAO messages that 271 follow the DODAG. This is in contrast with traditional IGPs that 272 operate the same in all directions and are thus called isotropic. 274 The term Routing Stretch denotes the length of a path, as compared 275 with a shortest path, which can be a abstract concepts in RPL when 276 the metrics are statistical and dynamic, and the concept of short 277 varies with the Objective Function. 279 The RPL DODAG optimizes the P2MP (from Root) and MP2P (to Root) 280 paths, but the P2P (node to node) traffic has to follow the same 281 DODAG. Following the DODAG, the RPL datapath passes via a common 282 parent in Storing Mode and via the Root in Non-Storing Mode. This 283 typically involves more hops and more latency than the minimum 284 possible for a direct P2P path that an isotropic protocol would 285 compute. We refer to this elongated path as stretched. 287 2.4.5. Track 289 A networking graph that can be followed to transport packets with 290 equivalent treatment; as opposed to the definition of a path above, a 291 Track is not necessarily linear. It may contain multiple paths that 292 may fork and rejoin, and may enable the RAW Packet ARQ, Replication, 293 Elimination, and Overhearing (PAREO) operations. 295 A ==> B ==> C -=- F ==> G ==> H T1 I: Ingress 296 / \ / \ / E: Egress 297 I O E -=- T2 T1, T2, T3: 298 \ / \ / \ External 299 P ==> Q ==> R -=- T ==> U ==> V T3 Targets 301 I ==> A ==> B ==> C : a segment to targets F and O 303 I --> F --> E : a leg to targets T1, T2, T3 305 I, A, B, C, F, G, H, E : a path to T1, T2, T3 307 Figure 1: A Track and its Components 309 This specification builds Tracks that are DODAGs oriented towards a 310 Track Ingress, and the forward direction for packets (aka East-West) 311 is from the Track Ingress to one of the possibly multiple Track 312 Egress Nodes, which is also down the DODAG. 314 The Track may be strictly connected, meaning that the vertices are 315 adjacent, or loosely connected, meaning that the vertices are 316 connected using Segments that are associated to the same Track. 318 2.4.5.1. TrackID 320 A RPL Local InstanceID that identifies a Track using the namespace 321 owned by the Track Ingress. The TrackID is associated with the IPv6 322 Address of the Track Ingress that is used as DODAGID, and together 323 they form a unique identification of the Track (see the definition of 324 DODAGID in section 2 of [RPL]. 326 2.4.5.2. namespace 328 The term namespace is used to refer to the scope of the TrackID. The 329 TrackID is locally significant within its namespace. The namespace 330 is identified by the DODAGID for the Track. The tuple (DODAGID, 331 TrackID) is globally unique. 333 2.4.5.3. Serial Track 335 A Track that has only one path. 337 2.4.5.4. Stand-Alone 339 A single P-DAO that fully defines a Track, e.g., a Serial Track 340 installed with a single Storing Mode Via Information option (SM-VIO). 342 2.4.5.5. Stitching 344 This specification using the term stitching to indicate that a track 345 is piped to another one, meaning that traffic out of the first is 346 injected in the other. 348 2.4.5.6. subTrack 350 A Track within a Track. As the Non-Storing Mode Via Information 351 option (NSM-VIO) can only signal a loose sequence of nodes, it takes 352 a number of them to signal a complex Track. Each NSM-VIO for the 353 same TrackId but a different Segment ID signals a different subTracks 354 that the Track Ingress adds to the topology. 356 2.4.5.7. Leg 358 An end-to-end East-West serial path that can be a Track by itself or 359 a subTrack of a complex Track. With this specification, a Leg is is 360 installed by the Root of the main DODAG using Non-Storing Mode P-DAO 361 messages, and it is expressed as a loose sequence of nodes that are 362 joined by Track Segments. 364 2.4.5.8. Segment 366 A serial path formed by a strict sequence of nodes, along which a 367 P-Route is installed. With this specification, a Segment is 368 typically installed by the Root of the main DODAG using Storing Mode 369 P-DAO messages. A Segment used as the topological edge of a Track. 370 Since this specification builds only DODAGs, all Segments are 371 oriented from Ingress (East) to Egress (West), as opposed to the 372 general RAW model, which allows North/South Segments that can be 373 bidirectional. 375 2.4.5.8.1. Section of a Segment 377 A continuous subset of a segment that may be replaced while the 378 segment remains. for instance, in segment A=>B=>C=>D=>E=>F, say that 379 the link C to D might be misbehaving. The section B=>C=>D=>E in the 380 segment may be replaced by B=>C'=>D'=>E to route around the problem. 381 The segment becomes A=>B=>C'=>D'=>E=>F. 383 2.4.5.8.2. Segment Routing and SRH 385 The terms Segment Routing and SRH refer to using source-routing to 386 hop over segments. In a Non-Storing mode RPL domain, the SRH is 387 typically a RPL Source Route Header (the IPv6 RH of type 3) as 388 defined in [RFC6554]. 390 If the network is a 6LoWPAN Network, the expectation is that the SRH 391 is compressed and encoded as a 6LoWPAN Routing Header (6LoRH), as 392 specified in section 5 of [RFC8138]. 394 On the other hand, if the RPL Network is less constrained and 395 operated in Storing Mode, as discussed in Section 7.1, the Segment 396 Routing operation and the SRH could be as specified in [RFC8754]. 397 This specification applies equally to both forms of source routing 398 and SRH. 400 3. Context and Goal 402 3.1. RPL Applicability 404 RPL is optimized for situations where the power is scarce, the 405 bandwidth constrained and the transmissions unreliable. This matches 406 the use case of an IoT LLN where RPL is typically used today, but 407 also situations of high relative mobility between the nodes in the 408 network (aka swarming), e.g., within a variable set of vehicles with 409 a similar global motion, or a toon of drones. 411 To reach this goal, RPL is primarily designed to minimize the control 412 plane activity, that is the relative amount of routing protocol 413 exchanges vs. data traffic, and the amount of state that is 414 maintained in each node. RPL does not need converge, and provides 415 connectivity to most nodes most of the time. 417 RPL may form multiple topologies called instances. Instances can be 418 created to enforce various optimizations through objective functions, 419 or to reach out through different Root Nodes. The concept of 420 objective function allows to adapt the activity of the routing 421 protocol to the use case, e.g., type, speed, and quality of the LLN 422 links. 424 RPL instances operate as ships passing in the night, unbeknownst of 425 one another. The RPL Root is responsible to select the RPL Instance 426 that is used to forward a packet coming from the Backbone into the 427 RPL domain and set the related RPL information in the packets. 6TiSCH 428 leverages RPL for its distributed routing operations. 430 To reduce the routing exchanges, RPL leverages an anisotropic 431 Distance Vector approach, which does not need a global knowledge of 432 the topology, and only optimizes the routes to and from the RPL Root, 433 allowing P2P paths to be stretched. Although RPL installs its routes 434 proactively, it only maintains them lazily, in reaction to actual 435 traffic, or as a slow background activity. 437 This is simple and efficient in situations where the traffic is 438 mostly directed from or to a central node, such as the control 439 traffic between routers and a controller of a Software Defined 440 Networking (SDN) infrastructure or an Autonomic Control Plane (ACP). 442 But stretch in P2P routing is counter-productive to both reliability 443 and latency as it introduces additional delay and chances of loss. 444 As a result, [RPL] is not a good fit for the use cases listed in the 445 RAW use cases document [USE-CASES], which demand high availability 446 and reliability, and as a consequence require both short and diverse 447 paths. 449 3.2. RPL Routing Modes 451 RPL first forms a default route in each node towards the a Root, and 452 those routes together coalesce as a Directed Acyclic Graph upwards. 453 RPL then constructs routes to destinations signaled as Targets in the 454 reverse direction, down the same DODAG. So do so, a RPL Instance can 455 be operated either in RPL Storing or Non-Storing Mode of Operation 456 (MOP). The default route towards the Root is maintained aggressively 457 and may change while a packet progresses without causing loops, so 458 the packet will still reach the Root. 460 In Non-Storing Mode, each node advertises itself as a Target directly 461 to the Root, indicating the parents that may be used to reach self. 462 Recursively, the Root builds and maintains an image of the whole 463 DODAG in memory, and leverages that abstraction to compute source 464 route paths for the packets to their destinations down the DODAG. 465 When a node changes its point(s) of attachment to the DODAG, it takes 466 single unicast packet to the Root along the default route to update 467 it, and the connectivity is restored immediately; this mode is 468 preferable for use cases where internet connectivity is dominant, or 469 when, like here, the Root controls the network activity in the nodes. 471 In Storing Mode, the routing information percolates upwards, and each 472 node maintains the routes to the subDAG of its descendants down the 473 DODAG. The maintenance is lazy, either reactive upon traffic or as a 474 slow background process. Packets flow via the common parent and the 475 routing stretch is reduced vs. Non-Storing, for a better P2P 476 connectivity. On the other hand, a new route takes a longer time to 477 propagate to the Root, time for the Distance-Vector protocol to 478 operate hop-by-hop, and the Internet connectivity is restored more 479 slowly upon movement. 481 Either way, the RPL routes are injected by the Target nodes, in a 482 distributed fashion. To complement RPL and eliminate routing 483 stretch, this specification introduces an hybrid mode that combines 484 Storing and Non-Storing operations to build and project routes onto 485 the nodes where they should be installed. This specification uses 486 the term Projected Route (P-Route) to refer to those routes. 488 A P-Route may be installed in either Storing and Non-Storing Mode, 489 potentially resulting in hybrid situations where the Mode of the P- 490 Route is different from that of the RPL Main DODAG. P-Routes can be 491 used as stand-alone segments to reduce the size of the source routing 492 headers with loose source routing operations down the main RPL DODAG. 493 P-Routes can also be combined with other P-Routes to form a more 494 complex forwarding graph called a Track. 496 3.3. Requirements 498 3.3.1. Loose Source Routing 500 A RPL implementation operating in a very constrained LLN typically 501 uses the Non-Storing Mode of Operation as represented in Figure 2. 502 In that mode, a RPL node indicates a parent-child relationship to the 503 Root, using a destination Advertisement Object (DAO) that is unicast 504 from the node directly to the Root, and the Root typically builds a 505 source routed path to a destination down the DODAG by recursively 506 concatenating this information. 508 +-----+ 509 | | Border router 510 | | (RPL Root) 511 +-----+ ^ | | 512 | | DAO | ACK | 513 o o o o | | | Strict 514 o o o o o o o o o | | | Source 515 o o o o o o o o o o | | | Route 516 o o o o o o o o o | | | 517 o o o o o o o o | v v 518 o o o o 519 LLN 521 Figure 2: RPL Non-Storing Mode of operation 523 Based on the parent-children relationships expressed in the Non- 524 Storing DAO messages, the Root possesses topological information 525 about the whole network, though this information is limited to the 526 structure of the DODAG for which it is the destination. A packet 527 that is generated within the domain will always reach the Root, which 528 can then apply a source routing information to reach the destination 529 if the destination is also in the DODAG. Similarly, a packet coming 530 from the outside of the domain for a destination that is expected to 531 be in a RPL domain reaches the Root. It results that the wireless 532 bandwidth near the Root is the gating factor for all transmissions 533 towards or within the domain, and that the Root is a single point of 534 failure for all connectivity to nodes within its domain. 536 The RPL Root must add a source routing header to all downward 537 packets. As a network grows, the size of the source routing header 538 augments with the depth of the nodes. In some use cases, a RPL 539 network forms long lines along physical structures such as streets 540 for lighting. Limiting the packet size is directly beneficial to the 541 energy budget, but, mostly, it reduces the chances of frame loss and 542 packet fragmentation, which are highly detrimental to the LLN 543 operation. A limited amount of well-targeted routing state would 544 allow the source routing operation to be loose as opposed to strict, 545 and save packet size. Because the capability to store a routing 546 state in every node is limited, the decision of which route is 547 installed where can only be optimized with a global knowledge of the 548 system, a knowledge that the Root or an associated PCE may possess by 549 means that are outside of the scope of this specification. 551 Being on path for all packets in Non-Storing mode, the Root may 552 determine the number of P2P packets in its RPL domain per source and 553 destination, the latency incurred, and the amount of energy and 554 bandwidth that is consumed to reach the self and then down, including 555 a possible fragmentation when encapsulating larger packets. Enabling 556 a shorter path that would not traverse the Root for select P2P 557 source/destinations may improve the latency, lower the consumption of 558 constrained resources, free bandwidth at the bottleneck near the 559 Root, improve the delivery ratio and reduce the latency for those P2P 560 flows with a global benefit for all flows of reducing the load at the 561 Root. 563 This requirement is to store a routing state associated with the Main 564 DODAG in selected RPL routers, to limit the excursion of the source 565 route headers in deep networks. The Root may elide the sequence of 566 routers that is installed in the network from its source route 567 header, which becomes loose while it is strict in [RPL]. 569 3.3.2. East-West Routes 571 [RPL] optimizes Point-to-Multipoint (P2MP) routes from the Root, 572 Multipoint-to-Point (MP2P) routes to the DODAG Root, and Internet 573 access when the Root also serves as Border Router. All routes are 574 installed North-South (aka up/down) along the RPL DODAG. Peer to 575 Peer (P2P) East-West routes in a RPL network will generally suffer 576 from some elongated (stretched) path versus a direct (optimized) 577 path, since routing between two nodes always happens via a common 578 parent, as illustrated in Figure 3: 580 ------+--------- 581 | Internet 582 +-----+ 583 | | Border router 584 | | (RPL Root) 585 +-----+ 586 X 587 ^ v o o 588 ^ o o v o o o o o 589 ^ o o o v o o o o o 590 ^ o o v o o o o o 591 S o o o D o o o 592 o o o o 593 LLN 595 Figure 3: Routing Stretch between S and D via common parent X 596 along North-South Paths 598 As described in [RFC9008], the amount of stretch depends on the Mode 599 of Operation: 601 * in Non-Storing Mode, all packets routed within the DODAG flow all 602 the way up to the Root of the DODAG. If the destination is in the 603 same DODAG, the Root must encapsulate the packet to place an RH 604 that has the strict source route information down the DODAG to the 605 destination. This will be the case even if the destination is 606 relatively close to the source and the Root is relatively far off. 608 * In Storing Mode, unless the destination is a child of the source, 609 the packets will follow the default route up the DODAG as well. 610 If the destination is in the same DODAG, they will eventually 611 reach a common parent that has a route to the destination; at 612 worse, the common parent may also be the Root. From that common 613 parent, the packet will follow a path down the DODAG that is 614 optimized for the Objective Function that was used to build the 615 DODAG. 617 It results that it is often beneficial to enable East-West P2P 618 routes, either if the RPL route presents a stretch from shortest 619 path, or if the new route is engineered with a different objective, 620 and that it is even more critical in Non-Storing Mode than it is in 621 Storing Mode, because the routing stretch is wider. For that reason, 622 earlier work at the IETF introduced the "Reactive Discovery of 623 Point-to-Point Routes in Low Power and Lossy Networks" [RFC6997], 624 which specifies a distributed method for establishing optimized P2P 625 routes. This draft proposes an alternate based on a centralized 626 route computation. 628 +-----+ 629 | | Border router 630 | | (RPL Root) 631 +-----+ 632 | 633 o o o o 634 o o o o o o o o o 635 o o o o o o o o o o 636 o o o o o o o o o 637 S>>A>>>B>>C>>>D o o o 638 o o o o 639 LLN 641 Figure 4: More direct East-West Route between S and D 643 The requirement is to install additional routes in the RPL routers, 644 to reduce the stretch of some P2P routes and maintain the 645 characteristics within a given SLO, e.g., in terms of latency and/or 646 reliability. 648 3.4. On Tracks 649 3.4.1. Building Tracks With RPL 651 The concept of a Track was introduced in the "6TiSCH Architecture" 652 [6TiSCH-ARCHI], as a collection of potential paths that leverage 653 redundant forwarding solutions along the way. This can be a DODAG or 654 a more complex structure that is only partially acyclic (e.g., per 655 packet). 657 With this specification, a Track is shaped as a DODAG, and following 658 the directed edges leads to a Track Ingress. Storing Mode P-DAO 659 messages follow the direction of the edges to set up routes for 660 traffic that flows the other way, towards the Track Egress(es). If 661 there is a single Track Egress, then the Track is reversible to form 662 another DODAG by reversing the direction of each edge. A node at the 663 Ingress of more than one Segment in a Track may use one or more of 664 these Segments to forward a packet inside the Track. 666 A RPL Track is a collection of (one or more) parallel loose source 667 routed sequences of nodes ordered from Ingress to Egress, each 668 forming a Track Leg. The nodes that are directly connected, 669 reachable via existing Tracks as illustrated in Section 3.5.2.3 or 670 joined with strict Segments of other nodes as shown in 671 Section 3.5.1.3. The Legs are expressed in RPL Non-Storing Mode and 672 require an encapsulation to add a Source Route Header, whereas the 673 Segments are expressed in RPL Storing Mode. 675 A Serial Track comprises provides only one path between Ingress and 676 Egress. It comprises at most one Leg. A Stand-Alone Segment 677 implicitly defines a Serial Track from its Ingress to Egress. 679 A complex Track forms a graph that provides a collection of potential 680 paths to provide redundancy for the packets, either as a collection 681 of Legs that may be parallel or cross at certain points, or as a more 682 generic DODAG. 684 3.4.2. Tracks and RPL Instances 686 Section 5.1. of [RPL] describes the RPL Instance and its encoding. 687 There can be up to 128 global RPL Instances, for which there can be 688 one or more DODAGs, and there can be 64 local RPL Instances, with a 689 namespace that is indexed by a DODAGID, where the DODAGID is a Unique 690 Local Address (ULA) or a Global Unicast Address (GUA) of the Root of 691 the DODAG. Bit 0 (most significant) is set to 1 to signal a Local 692 RPLInstanceID, as shown in Figure 5. By extension, this 693 specification expresses the value of the RPLInstanceID as a single 694 integer between 128 and 191, representing both the Local 695 RPLInstanceID in 0..63 and Bit 0 set. 697 0 1 2 3 4 5 6 7 698 +-+-+-+-+-+-+-+-+ 699 |1|D| ID | Local RPLInstanceID in 0..63 700 +-+-+-+-+-+-+-+-+ 702 Figure 5: Local RPLInstanceID Encoding 704 A Track is normally associated with a Local RPL Instance which 705 RPLInstanceID is used as the TrackID, more in Section 6.3. A Track 706 Leg may also be used as a subTrack that extends the RPL main DODAG. 707 In that case, the TrackID is set to the global RPLInstanceID of the 708 main DODAG, which suffices to identify the routing topology. As 709 opposed to local RPL instances, the Track Ingress that encapsulates 710 the packets over a subtrack is not Root, and that the source address 711 of the encapsulated packet is not used to determine the Track. 713 3.5. Serial Track Signaling 715 This specification enables to set up a P-Route along either a Track 716 Leg or a Segment. A P-Route is installed and maintained by the Root 717 of the main DODAG using an extended RPL DAO message called a 718 Projected DAO (P-DAO), and a Track is composed of the combination of 719 one or more P-Routes. 721 A P-DAO message for a Track signals the TrackID in the RPLInstanceID 722 field. In the case of a local RPL Instance, the address of the Track 723 Ingress is used as source to encapsulate packets along the Track. 724 The Track is signaled in the DODAGID field of the Projected DAO Base 725 Object, see Figure 8. 727 This specification introduces the Via Information Option (VIO) to 728 signal a sequence of hops in a Leg or a Segment in the P-DAO 729 messages, either in Storing Mode (SM-VIO) or Non-Storing Mode (NSM- 730 VIO). One P-DAO messages contains a single VIO, associated to one or 731 more RPL Target Options that signal the destination IPv6 addresses 732 that can reached along the Track, more in Section 5.3. 734 Before diving deeper into Track Legs and Segments signaling and 735 operation, this section provides examples of what how route 736 projection works through variations of a simple example. This simple 737 example illustrates the case of host routes, though RPL Targets can 738 be prefixes. 740 Say we want to build a Serial Track from node A to E in Figure 6, so 741 A can route packets to E's neighbors F and G along A, B, C, D and E 742 as opposed to via the Root: 744 /===> F 745 A ===> B ===> C ===> D===> E < 746 \===> G 748 Figure 6: Reference Track 750 Conventionally we use ==> to represent a strict hop and --> for a 751 loose hop. We use "-to-", such as in C==>D==>E-to-F to represent 752 coma-separated Targets, e.g., F is a Target for Segment C==>D==>E. 753 In this example, A is Track Ingress, E is Track Egress. C is a 754 stitching point. F and G are "external" Targets for the Track, and 755 become reachable from A via the Track A(ingress) to E (Egress and 756 implicit Target in Non-Storing Mode) leading to F and G (explicit 757 Targets). 759 Figure 5 depicts the format of the RPLInstanceID encoding for a local 760 RPLInstanceID . 762 In a general manner the desired outcome is as follows: 764 * Targets are E, F, and G 766 * P-DAO 1 signals C==>D==>E 768 * P-DAO 2 signals A==>B==>C 770 * P-DAO 3 signals F and G via the A-->E Track 772 P-DAO 3 may be ommitted if P-DAO 1 and 2 signal F and G as Targets. 774 Loose sequences of hops must be expressed in Non-Storing Mode, so 775 P-DAO 3 contains a NSM-VIO. With this specification, the DODAGID to 776 be used by the Ingress as source address is signaled if needed in the 777 DAO base object, the via list starts at the first loose hop and 778 matches the source route header, and the Egress of a Non-Storing Mode 779 P-DAO is an implicit Target that is not listed in the RTO. 781 3.5.1. Using Storing Mode Segments 783 A==>B==>C and C==>D==>E are segments of a same Track. Note that the 784 Storing Mode signaling imposes strict continuity in a segment, since 785 the P-DAO is passed hop by hop, as a classical DAO is, along the 786 reverse datapath that it signals. One benefit of strict routing is 787 that loops are avoided along the Track. 789 3.5.1.1. Stitched Segments 791 In this formulation: 793 * P-DAO 1 signals C==>D==>E-to-F,G 795 * P-DAO 2 signals A==>B==>C-to-F,G 797 Storing Mode P-DAO 1 is sent to E and when it is succesfully 798 acknowledged, Storing Mode P-DAO 2 is sent to C, as follows: 800 +====================+==============+==============+ 801 | Field | P-DAO 1 to E | P-DAO 2 to C | 802 +====================+==============+==============+ 803 | Mode | Storing | Storing | 804 +--------------------+--------------+--------------+ 805 | Track Ingress | A | A | 806 +--------------------+--------------+--------------+ 807 | (DODAGID, TrackID) | (A, 129) | (A, 129) | 808 +--------------------+--------------+--------------+ 809 | SegmentID | 1 | 2 | 810 +--------------------+--------------+--------------+ 811 | VIO | C, D, E | A, B, C | 812 +--------------------+--------------+--------------+ 813 | Targets | F, G | F, G | 814 +--------------------+--------------+--------------+ 816 Table 1: P-DAO Messages 818 As a result the RIBs are set as follows: 820 +======+=============+=========+=============+==========+ 821 | Node | destination | Origin | Next Hop(s) | TrackID | 822 +======+=============+=========+=============+==========+ 823 | E | F, G | P-DAO 1 | Neighbor | (A, 129) | 824 +------+-------------+---------+-------------+----------+ 825 | D | E | P-DAO 1 | Neighbor | (A, 129) | 826 +------+-------------+---------+-------------+----------+ 827 | " | F, G | P-DAO 1 | E | (A, 129) | 828 +------+-------------+---------+-------------+----------+ 829 | C | D | P-DAO 1 | Neighbor | (A, 129) | 830 +------+-------------+---------+-------------+----------+ 831 | " | F, G | P-DAO 1 | D | (A, 129) | 832 +------+-------------+---------+-------------+----------+ 833 | B | C | P-DAO 2 | Neighbor | (A, 129) | 834 +------+-------------+---------+-------------+----------+ 835 | " | F, G | P-DAO 2 | C | (A, 129) | 836 +------+-------------+---------+-------------+----------+ 837 | A | B | P-DAO 2 | Neighbor | (A, 129) | 838 +------+-------------+---------+-------------+----------+ 839 | " | F, G | P-DAO 2 | B | (A, 129) | 840 +------+-------------+---------+-------------+----------+ 842 Table 2: RIB setting 844 Packets originated by A to F or G do not require an encapsulation as 845 the RPI can be placed in the native header chain. For packets that 846 it routes, A must encapsulate to add the RPI that signals the 847 trackID; the outer headers of the packets that are forwarded along 848 the Track have the following settings: 850 +========+===================+===================+================+ 851 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 852 +========+===================+===================+================+ 853 | Outer | A | F or G | (A, 129) | 854 +--------+-------------------+-------------------+----------------+ 855 | Inner | X != A | F or G | N/A | 856 +--------+-------------------+-------------------+----------------+ 858 Table 3: Packet Header Settings 860 As an example, say that A has a packet for F. Using the RIB above: 862 * From P-DAO 2: A forwards to B and B forwards to C. 864 * From P-DAO 1: C forwards to D and D forwards to E. 866 * From Neighbor Cache Entry: E delivers the packet to F. 868 3.5.1.2. External routes 870 In this example, we consider F and G as destinations that are 871 external to the Track as a DODAG, as discussed in section 4.1.1. of 872 [RFC9008]. We then apply the directives for encapsulating in that 873 case, more in Section 6.7. 875 In this formulation, we set up the Track Leg explicitly, which 876 creates less routing state in intermediate hops at the expense of 877 larger packets to accommodate source routing: 879 * P-DAO 1 signals C==>D==>E-to-E 881 * P-DAO 2 signals A==>B==>C-to-E 883 * P-DAO 3 signals F and G via the A-->E-to-F,G Track 885 Storing Mode P-DAO 1 and 2, and Non-Storing Mode P-DAO 3, are sent to 886 E, C and A, respectively, as follows: 888 +====================+==============+==============+==============+ 889 | | P-DAO 1 to E | P-DAO 2 to C | P-DAO 3 to A | 890 +====================+==============+==============+==============+ 891 | Mode | Storing | Storing | Non-Storing | 892 +--------------------+--------------+--------------+--------------+ 893 | Track Ingress | A | A | A | 894 +--------------------+--------------+--------------+--------------+ 895 | (DODAGID, TrackID) | (A, 129) | (A, 129) | (A, 129) | 896 +--------------------+--------------+--------------+--------------+ 897 | SegmentID | 1 | 2 | 3 | 898 +--------------------+--------------+--------------+--------------+ 899 | VIO | C, D, E | A, B, C | E | 900 +--------------------+--------------+--------------+--------------+ 901 | Targets | E | E | F, G | 902 +--------------------+--------------+--------------+--------------+ 904 Table 4: P-DAO Messages 906 Note in the above that E is not an implicit Target in Storing mode, 907 so it must be added in the RTO. 909 As a result the RIBs are set as follows: 911 +======+=============+=========+=============+==========+ 912 | Node | destination | Origin | Next Hop(s) | TrackID | 913 +======+=============+=========+=============+==========+ 914 | E | F, G | P-DAO 1 | Neighbor | (A, 129) | 915 +------+-------------+---------+-------------+----------+ 916 | D | E | P-DAO 1 | Neighbor | (A, 129) | 917 +------+-------------+---------+-------------+----------+ 918 | C | D | P-DAO 1 | Neighbor | (A, 129) | 919 +------+-------------+---------+-------------+----------+ 920 | " | E | P-DAO 1 | D | (A, 129) | 921 +------+-------------+---------+-------------+----------+ 922 | B | C | P-DAO 2 | Neighbor | (A, 129) | 923 +------+-------------+---------+-------------+----------+ 924 | " | E | P-DAO 2 | C | (A, 129) | 925 +------+-------------+---------+-------------+----------+ 926 | A | B | P-DAO 2 | Neighbor | (A, 129) | 927 +------+-------------+---------+-------------+----------+ 928 | " | E | P-DAO 2 | B | (A, 129) | 929 +------+-------------+---------+-------------+----------+ 930 | " | F, G | P-DAO 3 | E | (A, 129) | 931 +------+-------------+---------+-------------+----------+ 933 Table 5: RIB setting 935 Packets from A to E do not require an encapsulation. The outer 936 headers of the packets that are forwarded along the Track have the 937 following settings: 939 +========+===================+====================+================+ 940 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 941 +========+===================+====================+================+ 942 | Outer | A | E | (A, 129) | 943 +--------+-------------------+--------------------+----------------+ 944 | Inner | X | E (X != A), F or G | N/A | 945 +--------+-------------------+--------------------+----------------+ 947 Table 6: Packet Header Settings 949 As an example, say that A has a packet for F. Using the RIB above: 951 * From P-DAO 3: A encapsulates the packet the Track signaled by 952 P-DAO 3, with the outer header above. Now the packet destination 953 is E. 955 * From P-DAO 2: A forwards to B and B forwards to C. 957 * From P-DAO 1: C forwards to D and D forwards to E; E decapsulates 958 the packet. 960 * From Neighbor Cache Entry: E delivers packets to F or G. 962 3.5.1.3. Segment Routing 964 In this formulation leverages Track Legs to combine Segments and form 965 a Graph. The packets are source routed from a Segment to the next to 966 adapt the path. As such, this can be seen as a form of Segment 967 Routing [RFC8402]: 969 * P-DAO 1 signals C==>D==>E-to-E 971 * P-DAO 2 signals A==>B-to-B,C 973 * P-DAO 3 signals F and G via the A-->C-->E-to-F,G Track 975 Storing Mode P-DAO 1 and 2, and Non-Storing Mode P-DAO 3, are sent to 976 E, B and A, respectively, as follows: 978 +====================+==============+==============+==============+ 979 | | P-DAO 1 to E | P-DAO 2 to B | P-DAO 3 to A | 980 +====================+==============+==============+==============+ 981 | Mode | Storing | Storing | Non-Storing | 982 +--------------------+--------------+--------------+--------------+ 983 | Track Ingress | A | A | A | 984 +--------------------+--------------+--------------+--------------+ 985 | (DODAGID, TrackID) | (A, 129) | (A, 129) | (A, 129) | 986 +--------------------+--------------+--------------+--------------+ 987 | SegmentID | 1 | 2 | 3 | 988 +--------------------+--------------+--------------+--------------+ 989 | VIO | C, D, E | A, B | C, E | 990 +--------------------+--------------+--------------+--------------+ 991 | Targets | E | C | F, G | 992 +--------------------+--------------+--------------+--------------+ 994 Table 7: P-DAO Messages 996 Note in the above that the Segment can terminate at the loose hop as 997 used in the example of P-DAO 1 or at the previous hop as done with 998 P-DAO 2. Both methods are possible on any Segment joined by a loose 999 Track Leg. P-DAO 1 generates more signaling since E is the Segment 1000 Egress when D could be, but has the benefit that it validates that 1001 the connectivity between D and E still exists. 1003 As a result the RIBs are set as follows: 1005 +======+=============+=========+=============+==========+ 1006 | Node | destination | Origin | Next Hop(s) | TrackID | 1007 +======+=============+=========+=============+==========+ 1008 | E | F, G | P-DAO 1 | Neighbor | (A, 129) | 1009 +------+-------------+---------+-------------+----------+ 1010 | D | E | P-DAO 1 | Neighbor | (A, 129) | 1011 +------+-------------+---------+-------------+----------+ 1012 | C | D | P-DAO 1 | Neighbor | (A, 129) | 1013 +------+-------------+---------+-------------+----------+ 1014 | " | E | P-DAO 1 | D | (A, 129) | 1015 +------+-------------+---------+-------------+----------+ 1016 | B | C | P-DAO 2 | Neighbor | (A, 129) | 1017 +------+-------------+---------+-------------+----------+ 1018 | A | B | P-DAO 2 | Neighbor | (A, 129) | 1019 +------+-------------+---------+-------------+----------+ 1020 | " | C | P-DAO 2 | B | (A, 129) | 1021 +------+-------------+---------+-------------+----------+ 1022 | " | E, F, G | P-DAO 3 | C, E | (A, 129) | 1023 +------+-------------+---------+-------------+----------+ 1025 Table 8: RIB setting 1027 Packets originated at A to E do not require an encapsulation, but 1028 carry a SRH via C. The outer headers of the packets that are 1029 forwarded along the Track have the following settings: 1031 +========+===================+====================+================+ 1032 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1033 +========+===================+====================+================+ 1034 | Outer | A | C till C then E | (A, 129) | 1035 +--------+-------------------+--------------------+----------------+ 1036 | Inner | X | E (X != A), F or G | N/A | 1037 +--------+-------------------+--------------------+----------------+ 1039 Table 9: Packet Header Settings 1041 As an example, say that A has a packet for F. Using the RIB above: 1043 * From P-DAO 3: A encapsulates the packet the Track signaled by 1044 P-DAO 3, with the outer header above. Now the destination in the 1045 IPv6 Header is C, and a SRH signals the final destination is E. 1047 * From P-DAO 2: A forwards to B and B forwards to C. 1049 * From P-DAO 3: C processes the SRH and sets the destination in the 1050 IPv6 Header to E. 1052 * From P-DAO 1: C forwards to D and D forwards to E; E decapsulates 1053 the packet. 1055 * From the Neighbor Cache Entry: E delivers packets to F or G. 1057 3.5.2. Using Non-Storing Mode joining Tracks 1059 In this formulation: 1061 * P-DAO 1 signals C==>D==>E-to-F,G 1063 * P-DAO 2 signals A==>B==>C-to-C,F,G 1065 A==>B==>C and C==>D==>E are Tracks expressed as Non-Storing P-DAOs. 1067 3.5.2.1. Stitched Tracks 1069 Non-Storing Mode P-DAO 1 and 2 are sent to C and A respectively, as 1070 follows: 1072 +====================+==============+==============+ 1073 | | P-DAO 1 to C | P-DAO 2 to A | 1074 +====================+==============+==============+ 1075 | Mode | Non-Storing | Non-Storing | 1076 +--------------------+--------------+--------------+ 1077 | Track Ingress | C | A | 1078 +--------------------+--------------+--------------+ 1079 | (DODAGID, TrackID) | (C, 131) | (A, 131) | 1080 +--------------------+--------------+--------------+ 1081 | SegmentID | 1 | 1 | 1082 +--------------------+--------------+--------------+ 1083 | VIO | D, E | B, C | 1084 +--------------------+--------------+--------------+ 1085 | Targets | F, G | E, F, G | 1086 +--------------------+--------------+--------------+ 1088 Table 10: P-DAO Messages 1090 As a result the RIBs are set as follows: 1092 +======+=============+=========+=============+==========+ 1093 | Node | destination | Origin | Next Hop(s) | TrackID | 1094 +======+=============+=========+=============+==========+ 1095 | E | F, G | ND | Neighbor | Any | 1096 +------+-------------+---------+-------------+----------+ 1097 | D | E | ND | Neighbor | Any | 1098 +------+-------------+---------+-------------+----------+ 1099 | C | D | ND | Neighbor | Any | 1100 +------+-------------+---------+-------------+----------+ 1101 | " | E, F, G | P-DAO 1 | D, E | (C, 131) | 1102 +------+-------------+---------+-------------+----------+ 1103 | B | C | ND | Neighbor | Any | 1104 +------+-------------+---------+-------------+----------+ 1105 | A | B | ND | Neighbor | Any | 1106 +------+-------------+---------+-------------+----------+ 1107 | " | C, E, F, G | P-DAO 2 | B, C | (A, 131) | 1108 +------+-------------+---------+-------------+----------+ 1110 Table 11: RIB setting 1112 Packets originated at A to E, F and G do not require an 1113 encapsulation, though it is preferred that A encapsulates and C 1114 decapsulates. Either way, they carry a SRH via B and C, and C needs 1115 to encapsulate to E, F, or G to add an SRH via D and E. The 1116 encapsulating headers of packets that are forwarded along the Track 1117 between C and E have the following settings: 1119 +========+===================+===================+================+ 1120 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1121 +========+===================+===================+================+ 1122 | Outer | C | D till D then E | (C, 131) | 1123 +--------+-------------------+-------------------+----------------+ 1124 | Inner | X | E, F, or G | N/A | 1125 +--------+-------------------+-------------------+----------------+ 1127 Table 12: Packet Header Settings between C and E 1129 As an example, say that A has a packet for F. Using the RIB above: 1131 * From P-DAO 2: A encapsulates the packet with destination of F in 1132 the Track signaled by P-DAO 2. The outer header has source A, 1133 destination B, an SRH that indicates C as the next loose hop, and 1134 a RPI indicating a TrackId of 131 from A's namespace, which is 1135 distinct from TrackId of 131 from C's. 1137 * From the SRH: Packets forwarded by B have source A, destination C, 1138 a consumed SRH, and a RPI indicating a TrackId of 131 from A's 1139 namespace. C decapsulates. 1141 * From P-DAO 1: C encapsulates the packet with destination of F in 1142 the Track signaled by P-DAO 1. The outer header has source C, 1143 destination D, an SRH that indicates E as the next loose hop, and 1144 a RPI indicating a TrackId of 131 from C's namespace. E 1145 decapsulates. 1147 3.5.2.2. External routes 1149 In this formulation: 1151 * P-DAO 1 signals C==>D==>E-to-E 1153 * P-DAO 2 signals A==>B==>C-to-C,E 1155 * P-DAO 3 signals F and G via the A-->E-to-F,G Track 1157 Non-Storing Mode P-DAO 1 is sent to C and Non-Storing Mode P-DAO 2 1158 and 3 are sent A, as follows: 1160 +====================+==============+==============+==============+ 1161 | | P-DAO 1 to C | P-DAO 2 to A | P-DAO 3 to A | 1162 +====================+==============+==============+==============+ 1163 | Mode | Non-Storing | Non-Storing | Non-Storing | 1164 +--------------------+--------------+--------------+--------------+ 1165 | Track Ingress | C | A | A | 1166 +--------------------+--------------+--------------+--------------+ 1167 | (DODAGID, TrackID) | (C, 131) | (A, 129) | (A, 141) | 1168 +--------------------+--------------+--------------+--------------+ 1169 | SegmentID | 1 | 1 | 1 | 1170 +--------------------+--------------+--------------+--------------+ 1171 | VIO | D, E | B, C | E | 1172 +--------------------+--------------+--------------+--------------+ 1173 | Targets | E | E | F, G | 1174 +--------------------+--------------+--------------+--------------+ 1176 Table 13: P-DAO Messages 1178 As a result the RIBs are set as follows: 1180 +======+=============+=========+=============+==========+ 1181 | Node | destination | Origin | Next Hop(s) | TrackID | 1182 +======+=============+=========+=============+==========+ 1183 | E | F, G | ND | Neighbor | Any | 1184 +------+-------------+---------+-------------+----------+ 1185 | D | E | ND | Neighbor | Any | 1186 +------+-------------+---------+-------------+----------+ 1187 | C | D | ND | Neighbor | Any | 1188 +------+-------------+---------+-------------+----------+ 1189 | " | E | P-DAO 1 | D, E | (C, 131) | 1190 +------+-------------+---------+-------------+----------+ 1191 | B | C | ND | Neighbor | Any | 1192 +------+-------------+---------+-------------+----------+ 1193 | A | B | ND | Neighbor | Any | 1194 +------+-------------+---------+-------------+----------+ 1195 | " | C, E | P-DAO 2 | B, C | (A, 129) | 1196 +------+-------------+---------+-------------+----------+ 1197 | " | F, G | P-DAO 3 | E | (A, 141) | 1198 +------+-------------+---------+-------------+----------+ 1200 Table 14: RIB setting 1202 The encapsulating headers of packets that are forwarded along the 1203 Track between C and E have the following settings: 1205 +========+===================+===================+================+ 1206 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1207 +========+===================+===================+================+ 1208 | Outer | C | D till D then E | (C, 131) | 1209 +--------+-------------------+-------------------+----------------+ 1210 | Middle | A | E | (A, 141) | 1211 +--------+-------------------+-------------------+----------------+ 1212 | Inner | X | E, F or G | N/A | 1213 +--------+-------------------+-------------------+----------------+ 1215 Table 15: Packet Header Settings 1217 As an example, say that A has a packet for F. Using the RIB above: 1219 * From P-DAO 3: A encapsulates the packet with destination of F in 1220 the Track signaled by P-DAO 3. The outer header has source A, 1221 destination E, and a RPI indicating a TrackId of 141 from A's 1222 namespace. This recurses with: 1224 * From P-DAO 2: A encapsulates the packet with destination of E in 1225 the Track signaled by P-DAO 2. The outer header has source A, 1226 destination B, an SRH that indicates C as the next loose hop, and 1227 a RPI indicating a TrackId of 129 from A's namespace. 1229 * From the SRH: Packets forwarded by B have source A, destination C 1230 , a consumed SRH, and a RPI indicating a TrackId of 129 from A's 1231 namespace. C decapsulates. 1233 * From P-DAO 1: C encapsulates the packet with destination of E in 1234 the Track signaled by P-DAO 1. The outer header has source C, 1235 destination D, an SRH that indicates E as the next loose hop, and 1236 a RPI indicating a TrackId of 131 from C's namespace. E 1237 decapsulates. 1239 3.5.2.3. Segment Routing 1241 In this formulation: 1243 * P-DAO 1 signals C==>D==>E-to-E 1245 * P-DAO 2 signals A==>B-to-C 1247 * P-DAO 3 signals F and G via the A-->C-->E-to-F,G Track 1249 Non-Storing Mode P-DAO 1 is sent to C and Non-Storing Mode P-DAO 2 1250 and 3 are sent A, as follows: 1252 +====================+==============+==============+==============+ 1253 | | P-DAO 1 to C | P-DAO 2 to A | P-DAO 3 to A | 1254 +====================+==============+==============+==============+ 1255 | Mode | Non-Storing | Non-Storing | Non-Storing | 1256 +--------------------+--------------+--------------+--------------+ 1257 | Track Ingress | C | A | A | 1258 +--------------------+--------------+--------------+--------------+ 1259 | (DODAGID, TrackID) | (C, 131) | (A, 129) | (A, 141) | 1260 +--------------------+--------------+--------------+--------------+ 1261 | SegmentID | 1 | 1 | 1 | 1262 +--------------------+--------------+--------------+--------------+ 1263 | VIO | D, E | B | C, E | 1264 +--------------------+--------------+--------------+--------------+ 1265 | Targets | | C | F, G | 1266 +--------------------+--------------+--------------+--------------+ 1268 Table 16: P-DAO Messages 1270 As a result the RIBs are set as follows: 1272 +======+=============+=========+=============+==========+ 1273 | Node | destination | Origin | Next Hop(s) | TrackID | 1274 +======+=============+=========+=============+==========+ 1275 | E | F, G | ND | Neighbor | Any | 1276 +------+-------------+---------+-------------+----------+ 1277 | D | E | ND | Neighbor | Any | 1278 +------+-------------+---------+-------------+----------+ 1279 | C | D | ND | Neighbor | Any | 1280 +------+-------------+---------+-------------+----------+ 1281 | " | E | P-DAO 1 | D, E | (C, 131) | 1282 +------+-------------+---------+-------------+----------+ 1283 | B | C | ND | Neighbor | Any | 1284 +------+-------------+---------+-------------+----------+ 1285 | A | B | ND | Neighbor | Any | 1286 +------+-------------+---------+-------------+----------+ 1287 | " | C | P-DAO 2 | B, C | (A, 129) | 1288 +------+-------------+---------+-------------+----------+ 1289 | " | E, F, G | P-DAO 3 | C, E | (A, 141) | 1290 +------+-------------+---------+-------------+----------+ 1292 Table 17: RIB setting 1294 The encapsulating headers of packets that are forwarded along the 1295 Track between A and B have the following settings: 1297 +========+===================+===================+================+ 1298 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1299 +========+===================+===================+================+ 1300 | Outer | A | B till D then E | (A, 129) | 1301 +--------+-------------------+-------------------+----------------+ 1302 | Middle | A | C | (A, 141) | 1303 +--------+-------------------+-------------------+----------------+ 1304 | Inner | X | E, F or G | N/A | 1305 +--------+-------------------+-------------------+----------------+ 1307 Table 18: Packet Header Settings 1309 The encapsulating headers of packets that are forwarded along the 1310 Track between B and C have the following settings: 1312 +========+===================+===================+================+ 1313 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1314 +========+===================+===================+================+ 1315 | Outer | A | C | (A, 141) | 1316 +--------+-------------------+-------------------+----------------+ 1317 | Inner | X | E, F or G | N/A | 1318 +--------+-------------------+-------------------+----------------+ 1320 Table 19: Packet Header Settings 1322 The encapsulating headers of packets that are forwarded along the 1323 Track between C and E have the following settings: 1325 +========+===================+===================+================+ 1326 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1327 +========+===================+===================+================+ 1328 | Outer | C | D till D then E | (C, 131) | 1329 +--------+-------------------+-------------------+----------------+ 1330 | Middle | A | E | (A, 141) | 1331 +--------+-------------------+-------------------+----------------+ 1332 | Inner | X | E, F or G | N/A | 1333 +--------+-------------------+-------------------+----------------+ 1335 Table 20: Packet Header Settings 1337 As an example, say that A has a packet for F. Using the RIB above: 1339 * From P-DAO 3: A encapsulates the packet with destination of F in 1340 the Track signaled by P-DAO 3. The outer header has source A, 1341 destination C, an SRH that indicates E as the next loose hop, and 1342 a RPI indicating a TrackId of 141 from A's namespace. This 1343 recurses with: 1345 * From P-DAO 2: A encapsulates the packet with destination of C in 1346 the Track signaled by P-DAO 2. The outer header has source A, 1347 destination B, and a RPI indicating a TrackId of 129 from A's 1348 namespace. B decapsulates forwards to C based on a sibling 1349 connected route. 1351 * From the SRH: C consumes the SRH and makes the destination E. 1353 * From P-DAO 1: C encapsulates the packet with destination of E in 1354 the Track signaled by P-DAO 1. The outer header has source C, 1355 destination D, an SRH that indicates E as the next loose hop, and 1356 a RPI indicating a TrackId of 131 from C's namespace. E 1357 decapsulates. 1359 3.6. Complex Tracks 1361 To increase the reliability of the P2P transmission, this 1362 specification enables to build a collection of Legs between the same 1363 Ingress and Egress Nodes and combine them with the same TrackID, as 1364 shown in Figure 7. Legs may cross at the edges of loose hops or 1365 remain parallel. 1367 The Segments that join the loose hops of a Leg are installed with the 1368 same TrackID as the Leg. But each individual Leg and Segment has its 1369 own P-RouteID which allows it to be managed separately. When Legs 1370 cross within respective Segment, the next loose hop (the current 1371 destination of the packet) indicates which Leg is being followed and 1372 a Segment that can reach that next loose hop is selected. 1374 CPF CPF CPF CPF 1376 Southbound API 1378 _-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._- 1379 _-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._- 1381 +----------+ 1382 | RPL Root | 1383 +----------+ 1384 ( ) 1385 ( ) 1386 ( DODAG ) 1387 ( ) 1388 ( ) 1389 ) 1390 <- Leg 1 B, E -> 1391 <--- Segment 1 A,B ---> <------- Segment 2 C,D,E -------> 1393 FWD --z Relay --z FWD --z FWD Target 1 1394 z-- Node z-- Node z-- Node z-- Node --z / 1395 --z (A) (B) \ (C) (D) z-- / 1396 Track \ Track 1397 Ingress Segment 5 Egress - Tgt 2 1398 (I) \ (E) 1399 --z \ z-- \ 1400 z-- FWD --z FWD --z Relay --z FWD --z \ 1401 Node z-- Node z-- Node z-- Node Target 3 1402 (F) (G) (H) (J) 1404 <------ Segment 3 F,G,H ------> <---- Segment 4 J,E ----> 1405 <- Leg 2 H, E -> 1407 <--- Segment 1 A,B ---> <- S5-> <---- Segment 4 J,E ----> 1408 <- Leg 3 B, H, E -> 1409 ) 1410 ( 1411 ( ) 1413 Figure 7: Segments and Tracks 1415 Note that while this specification enables to build both Segments 1416 inside a Leg (aka East-West), such as Segment 2 above which is within 1417 Leg 1, and Inter-Leg Segments (aka North-South), such as Segment 2 1418 above which joins Leg 1 and Leg 2, it does not signal to the Ingress 1419 which Inter-Leg Segments are available, so the use of North-South 1420 Segments and associated PAREO functions is curently limited. The 1421 only possibility available at this time is to define overlapping Legs 1422 as illustrated in Figure 7, with Leg 3 that is congruent with Leg 1 1423 till node B and congruent with Leg 2 from node H on, abstracting 1424 Segment 5 as an East-West Segment. 1426 3.7. Scope and Expectations 1428 3.7.1. External Dependencies 1430 This specification expects that the RPL Main DODAG is operated in RPL 1431 Non-Storing Mode to sustain the exchanges with the Root. Based on 1432 its comprehensive knowledge of the parent-child relationship, the 1433 Root can form an abstracted view of the whole DODAG topology. This 1434 document adds the capability for nodes to advertise additional 1435 sibling information to complement the topological awareness of the 1436 Root to be passed on to the PCE, and enable the PCE to build more / 1437 better paths that traverse those siblings. 1439 P-Routes require resources such as routing table space in the routers 1440 and bandwidth on the links; the amount of state that is installed in 1441 each node must be computed to fit within the node's memory, and the 1442 amount of rerouted traffic must fit within the capabilities of the 1443 transmission links. The methods used to learn the node capabilities 1444 and the resources that are available in the devices and in the 1445 network are out of scope for this document. The method to capture 1446 and report the LLN link capacity and reliability statistics are also 1447 out of scope. They may be fetched from the nodes through network 1448 management functions or other forms of telemetry such as OAM. 1450 3.7.2. Positioning vs. Related IETF Standards 1452 3.7.2.1. Extending 6TiSCH 1454 The "6TiSCH Architecture" [6TiSCH-ARCHI] leverages a centralized 1455 model that is similar to that of "Deterministic Networking 1456 Architecture" [RFC8655], whereby the device resources and 1457 capabilities are exposed to an external controller which installs 1458 routing states into the network based on its own objective functions 1459 that reside in that external entity. 1461 3.7.2.2. Mapping to DetNet 1463 DetNet Forwarding Nodes only understand the simple 1-to-1 forwarding 1464 sublayer transport operation along a segment whereas the more 1465 sophisticated Relay nodes can also provide service sublayer functions 1466 such as Replication and Elimination. 1468 One possible mapping between DetNet and this specification is to 1469 signal the Relay Nodes as the hops of a Leg and the forwarding Nodes 1470 as the hops in a Segment that join the Relay nodes as illustrated in 1471 Figure 7. 1473 3.7.2.3. Leveraging PCE 1475 With DetNet and 6TiSCH, the component of the controller that is 1476 responsible of computing routes is a PCE. The PCE computes its 1477 routes based on its own objective functions such as described in 1478 [RFC4655], and typically controls the routes using the PCE Protocol 1479 (PCEP) by [RFC5440]. While this specification expects a PCE and 1480 while PCEP might effectively be used between the Root and the PCE, 1481 the control protocol between the PCE and the Root is out of scope. 1483 This specification also expects a single PCE with a full view of the 1484 network. Distributing the PCE function for a large network is out of 1485 scope. This specification uses the RPL Root as a proxy to the PCE. 1486 The PCE may be collocated with the Root, or may reside in an external 1487 Controller. In that case, the protocol between the Root and the PCE 1488 is out of scope and abstracted by / mapped to RPL inside the DODAG; 1489 one possibility is for the Root to transmit the RPL DAOs with the 1490 SIOs that detail the parent/child and sibling information. 1492 The algorithm to compute the paths and the protocol used by the PCE 1493 and the metrics and link statistics involved in the computation are 1494 also out of scope. The effectiveness of the route computation by the 1495 PCE depends on the quality of the metrics that are reported from the 1496 RPL network. Which metrics are used and how they are reported is out 1497 of scope, but the expectation is that they are mostly of long-term, 1498 statistical nature, and provide visibility on link throughput, 1499 latency, stability and availability over relatively long periods. 1501 3.7.2.4. Providing for RAW 1503 The "Reliable and Available Wireless (RAW) Architecture/Framework" 1504 [RAW-ARCHI] extends the definition of Track, as being composed of 1505 East-West directional segments and North-South bidirectional 1506 segments, to enable additional path diversity, using Packet ARQ, 1507 Replication, Elimination, and Overhearing (PAREO) functions over the 1508 available paths, to provide a dynamic balance between the reliability 1509 and availability requirements of the flows and the need to conserve 1510 energy and spectrum. This specification prepares for RAW by setting 1511 up the Tracks, but only forms DODAGs, which are composed of 1512 aggregated end-to-end loose source routed Legs, joined by strict 1513 routed Segments, all oriented East-West. 1515 The RAW Architecture defines a dataplane extension of the PCE called 1516 the Path Selection Engine (PSE), that adapts the use of the path 1517 redundancy within a Track to defeat the diverse causes of packet 1518 loss. The PSE controls the forwarding operation of the packets 1519 within a Track This specification can use but does not impose a PSE 1520 and does not provide the policies that wouldselect which packets are 1521 routed through which path within a Track, IOW, how the PSE may use 1522 the path redundancy within the Track. By default, the use of the 1523 available redundancy is limited to simple load balancing, and all the 1524 segments are East-West unidirectional only. 1526 A Track may be set up to reduce the load around the Root, or to 1527 enable urgent traffic to flow more directly. This specification does 1528 not provide the policies that would decide which flows are routed 1529 through which Track. In a Non-Storing Mode RPL Instance, the Main 1530 DODAG provides a default route via the Root, and the Tracks provide 1531 more specific routes to the Track Targets. 1533 4. Extending existing RFCs 1535 4.1. Extending RFC 6550 1537 This specification extends RPL [RPL] to enable the Root to install 1538 East-West routes inside a Main DODAG that is operated as Non-Storing 1539 Mode. A Projected DAO (P-DAO) message (see Section 4.1.1) contains a 1540 new Via Information Option that installs a strict or a loose sequence 1541 of hops to form respectively a Track Segment or a Track Leg. A new 1542 P-DAO Request (PDR) message (see Section 5.1) enables a Track Ingress 1543 to request the Track from the Root. The resulting Track is also a 1544 DODAG for which the Track Ingress is the Root, the owner the address 1545 that serves as DODAGID and authoritative for the associated namespace 1546 from which the TrackID is selected. In the context of this 1547 specification, the installed route appears as a more specific route 1548 to the Track Targets, and the Track Ingress routes the packets 1549 towards the Targets via the Track using the longest match as usual. 1551 To ensure that the PDR and P-DAO messages can flow at most times, it 1552 is RECOMMENDED that the nodes involved in a Track mantain multiple 1553 parents in the Main DODAG, advertise them all to the Root, and use 1554 them in turn to retry similar packets. It is also RECOMMENDED that 1555 the Root uses diverse source route paths to retry similar messages ot 1556 the nodes in the Track. 1558 4.1.1. Projected DAO 1560 Section 6 of [RPL] introduces the RPL Control Message Options (CMO), 1561 including the RPL Target Option (RTO) and Transit Information Option 1562 (TIO), which can be placed in RPL messages such as the destination 1563 Advertisement Object (DAO). A DAO message signals routing 1564 information to one or more Targets indicated in RTOs, providing one 1565 hop information at a time in the TIO. A Projected DAO (P-DAO) is a 1566 special DAO message generated by the Root to install a P-Route formed 1567 of multiple hops in its DODAG. This provides a RPL-based method to 1568 install the Tracks as expected by the 6TiSCH Architecture 1569 [6TiSCH-ARCHI] as a collection of multiple P-Routes. 1571 The P-DAO is signaled with a new "Projected DAO" (P) flag, see 1572 Figure 8. The 'P' flag is encoded in bit position 2 (to be confirmed 1573 by IANA) of the Flags field in the DAO Base Object. The Root MUST 1574 set it to 1 in a Projected DAO message. Otherwise it MUST be set to 1575 0. It is set to 0 in Legacy implementations as specified 1576 respectively in Sections 20.11 and 6.4 of [RPL] 1578 The P-DAO is control plane signaling and should not be stuck behind 1579 high traffic levels. The expectation is that the P-DAO message is 1580 sent as high QoS level, above that of data traffic, typically with 1581 the Network Control precedence. 1583 0 1 2 3 1584 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 1585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1586 | TrackID |K|D|P| Flags | Reserved | DAOSequence | 1587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1588 | | 1589 + + 1590 | DODAGID field set to the | 1591 + IPv6 Address of the Track Ingress + 1592 | used to source encapsulated packets | 1593 + + 1594 | | 1595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1596 | Option(s)... 1597 +-+-+-+-+-+-+-+-+ 1599 Figure 8: Projected DAO Base Object 1601 New fields: 1603 TrackID: The local or global RPLInstanceID of the DODAG that serves 1604 as Track, more in Section 6.3 1606 P: 1-bit flag (position to be confirmed by IANA). 1608 The 'P' flag is set to 1 by the Root to signal a Projected DAO, 1609 and it is set to 0 otherwise. 1611 In RPL Non-Storing Mode, the TIO and RTO are combined in a DAO 1612 message to inform the DODAG Root of all the edges in the DODAG, which 1613 are formed by the directed parent-child relationships. The DAO 1614 message signals to the Root that a given parent can be used to reach 1615 a given child. The P-DAO message generalizes the DAO to signal to 1616 the Track Ingress that a Track for which it is Root can be used to 1617 reach children and siblings of the Track Egress. In both cases, 1618 options may be factorized and multiple RTOs may be present to signal 1619 a collection of children that can be reached through the parent or 1620 the Track, respectively. 1622 4.1.2. Via Information Option 1624 New CMOs called the Via Information Options (VIO) are introduced for 1625 use in P-DAO messages as a multihop alternative to the TIO, more in 1626 Section 5.3. One VIO is the stateful Storing Mode VIO (SM-VIO); an 1627 SM-VIO installs a strict hop-by-hop P-Route called a Track Segment. 1628 The other is the Non-Storing Mode VIO (NSM-VIO); the NSM-VIO installs 1629 a loose source-routed P-Route called a Track Leg at the Track 1630 Ingress, which uses that state to encapsulate a packet IPv6_in_IPv6 1631 with a new Routing Header (RH) to the Track Egress, more in 1632 Section 6.7. 1634 A P-DAO contains one or more RTOs to indicate the Target 1635 (destinations) that can be reached via the P-Route, followed by 1636 exactly one VIO that signals the sequence of nodes to be followed, 1637 more in Section 6. There are two modes of operation for the 1638 P-Routes, the Storing Mode and the Non-Storing Mode, see 1639 Section 6.4.2 and Section 6.4.3 respectively for more. 1641 4.1.3. Sibling Information Option 1643 This specification adds another CMO called the Sibling Information 1644 Option (SIO) that is used by a RPL Aware Node (RAN) to advertise a 1645 selection of its candidate neighbors as siblings to the Root, more in 1646 Section 5.4. The SIO is placed in DAO messages that are sent 1647 directly to the Root of the main DODAG. 1649 4.1.4. P-DAO Request 1651 Two new RPL Control Messages are also introduced, to enable a RPL- 1652 Aware Node to request the establishment of a Track between self as 1653 the Track Ingress Node and a Track Egress. The node makes its 1654 request by sending a new P-DAO Request (PDR) Message to the Root. 1655 The Root confirms with a new PDR-ACK message back to the requester 1656 RAN, see Section 5.1 for more. 1658 4.1.5. Extending the RPI 1660 Sending a Packet within a RPL Local Instance requires the presence of 1661 the abstract RPL Packet Information (RPI) described in section 11.2. 1662 of [RPL] in the outer IPv6 Header chain (see [RFC9008]). The RPI 1663 carries a local RPLInstanceID which, in association with either the 1664 source or the destination address in the IPv6 Header, indicates the 1665 RPL Instance that the packet follows. 1667 This specification extends [RPL] to create a new flag that signals 1668 that a packet is forwarded along a P-Route. 1670 Projected-Route 'P': 1-bit flag. It is set to 1 in the RPI that is 1671 added in the encapsulation when a packet is sent over a Track. It 1672 is set to 0 when a packet is forwarded along the main Track, 1673 including when the packet follows a Segment that joins loose hops 1674 of the Main DODAG. The flag is not mutable en-route. 1676 The encoding of the 'P' flag in native format is shown in Section 4.2 1677 while the compressed format is indicated in Section 4.3. 1679 4.1.6. Additional Flag in the RPL DODAG Configuration Option 1681 The DODAG Configuration Option is defined in Section 6.7.6 of [RPL]. 1682 Its purpose is extended to distribute configuration information 1683 affecting the construction and maintenance of the DODAG, as well as 1684 operational parameters for RPL on the DODAG, through the DODAG. This 1685 Option was originally designed with 4 bit positions reserved for 1686 future use as Flags. 1688 0 1 2 3 1689 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 1690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1691 | Type = 0x04 |Opt Length = 14|D| | | |A| ... | 1692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1693 |4 bits | 1695 Figure 9: DODAG Configuration Option (Partial View) 1697 This specification defines a new flag "Projected Routes Support" (D). 1698 The 'D' flag is encoded in bit position 0 of the reserved Flags in 1699 the DODAG Configuration Option (this is the most significant bit)(to 1700 be confirmed by IANA but there's little choice). It is set to 0 in 1701 legacy implementations as specified respectively in Sections 20.14 1702 and 6.7.6 of [RPL]. 1704 The 'D' flag is set to 1 to indicate that this specification is 1705 enabled in the network and that the Root will install the requested 1706 Tracks when feasible upon a PDR message. 1708 Section 4.1.2. of [RFC9008] updates [RPL] to indicate that the 1709 definition of the Flags applies to Mode of Operation values from zero 1710 (0) to six (6) only. For a MOP value of 7, the implementation MUST 1711 consider that the Root accepts PDR messages and will install 1712 Projected Routes. 1714 The RPL DODAG Configuration option is typically placed in a DODAG 1715 Information Object (DIO) message. The DIO message propagates down 1716 the DODAG to form and then maintain its structure. The DODAG 1717 Configuration option is copied unmodified from parents to children. 1718 xref target='RFC6550'/> states that: 1720 | Nodes other than the DODAG root MUST NOT modify this information 1721 | when propagating the DODAG Configuration option. 1723 Therefore, a legacy parent propagates the 'D' flag as set by the 1724 root, and when the 'D' flag is set to 1, it is transparently flooded 1725 to all the nodes in the DODAG. 1727 4.2. Extending RFC 6553 1729 "The RPL Option for Carrying RPL Information in Data-Plane Datagrams" 1730 [RFC6553]describes the RPL Option for use among RPL routers to 1731 include the abstract RPL Packet Information (RPI) described in 1732 section 11.2. of [RPL] in data packets. 1734 The RPL Option is commonly referred to as the RPI though the RPI is 1735 really the abstract information that is transported in the RPL 1736 Option. [RFC9008] updated the Option Type from 0x63 to 0x23. 1738 This specification modifies the RPL Option to encode the 'P' flag as 1739 follows: 1741 0 1 2 3 1742 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 1743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1744 | Option Type | Opt Data Len | 1745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1746 |O|R|F|P|0|0|0|0| RPLInstanceID | SenderRank | 1747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1748 | (sub-TLVs) | 1749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1751 Figure 10: Extended RPL Option Format 1753 Option Type: 0x23 or 0x63, see [RFC9008] 1755 Opt Data Len: See [RFC6553] 1757 'O', 'R' and 'F' flags: See [RFC6553]. Those flags MUST be set to 0 1758 by the sender and ignored by the receiver if the 'P' flag is set. 1760 Projected-Route 'P': 1-bit flag as defined in Section 4.1.5. 1762 RPLInstanceID: See [RFC6553]. Indicates the TrackId if the 'P' flag 1763 is set, as discussed in Section 4.1.1. 1765 SenderRank: See [RFC6553]. This field MUST be set to 0 by the 1766 sender and ignored by the receiver if the 'P'flag is set. 1768 4.3. Extending RFC 8138 1770 The 6LoWPAN Routing Header [RFC8138] specification introduces a new 1771 IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) 1772 [RFC6282] dispatch type for use in 6LoWPAN route-over topologies, 1773 which initially covers the needs of RPL data packet compression. 1775 Section 4 of [RFC8138] presents the generic formats of the 6LoWPAN 1776 Routing Header (6LoRH) with two forms, one Elective that can be 1777 ignored and skipped when the router does not understand it, and one 1778 Critical which causes the packet to be dropped when the router cannot 1779 process it. The 'E' Flag in the 6LoRH indicates its form. In order 1780 to skip the Elective 6LoRHs, their format imposes a fixed expression 1781 of the size, whereas the size of a Critical 6LoRH may be signaled in 1782 variable forms to enable additional optimizations. 1784 When the [RFC8138] compression is used, the Root of the Main DODAG 1785 that sets up the Track also constructs the compressed routing header 1786 (SRH-6LoRH) on behalf of the Track Ingress, which saves the 1787 complexities of optimizing the SRH-6LoRH encoding in constrained 1788 code. The SRH-6LoRH is signaled in the NSM-VIO, in a fashion that it 1789 is ready to be placed as is in the packet encapsulation by the Track 1790 Ingress. 1792 Section 6.3 of [RFC8138] presents the formats of the 6LoWPAN Routing 1793 Header of type 5 (RPI-6LoRH) that compresses the RPI for normal RPL 1794 operation. The format of the RPI-6LoRH is not suited for P-Routes 1795 since the O,R,F flags are not used and the Rank is unknown and 1796 ignored. 1798 This specification introduces a new 6LoRH, the P-RPI-6LoRH that can 1799 be used in either Elective or Critical 6LoRH form, see Table 22 and 1800 Table 23 respectively. The new 6LoRH MUST be used as a Critical 1801 6LoRH, unless an SRH-6LoRH is present and controls the routing 1802 decision, in which case it MAY be used in Elective form. 1804 The P-RPI-6LoRH is designed to compress the RPI along RPL P-Routes. 1805 Its format is as follows: 1807 0 1 2 1808 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1810 |1|0|E| Length | 6LoRH Type | RPLInstanceID | 1811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1813 Figure 11: P-RPI-6LoRH Format 1815 Type: IANA is requested to define the same value of the type for 1816 both Elective and Critical forms. A type of 8 is suggested. 1818 Elective 'E': See [RFC8138]. The 'E' flag is set to 1 to indicate 1819 an Elective 6LoRH, meaning that it can be ignored when forwarding. 1821 RPLInstanceID : In the context of this specification, the 1822 RPLInstanceID field signals the TrackID, see Section 3.4 and 1823 Section 6.3 . 1825 Section 6.8 details how a a Track Ingress leverages the P-RPI-6LoRH 1826 Header as part of the encapsulation of a packet to place it into a 1827 Track. 1829 5. New RPL Control Messages and Options 1830 5.1. New P-DAO Request Control Message 1832 The P-DAO Request (PDR) message is sent by a Node in the Main DODAG 1833 to the Root. It is a request to establish or refresh a Track where 1834 this node is Track Ingress, and signals whether an acknowledgment 1835 called PDR-ACK is requested or not. A positive PDR-ACK indicates 1836 that the Track was built and that the Roots commits to maintain the 1837 Track for the negotiated lifetime. 1839 The Root may use an asynchronous PDR-ACK with an negative status to 1840 indicate that the Track was terminated before its time. A status of 1841 "Transient Failure" (see Section 11.10) is an indication that the PDR 1842 may be retried after a reasonable time that depends on the 1843 deployment. Other negative status values indicate a permanent error; 1844 the tentative must be abandoned until a corrective action is taken at 1845 the application layer or through network management. 1847 The source IPv6 address of the PDR signals the Track Ingress to-be of 1848 the requested Track, and the TrackID is indicated in the message 1849 itself. One and only one RPL Target Option MUST be present in the 1850 message. The RTO signals the Track Egress, more in Section 6.2. 1852 The RPL Control Code for the PDR is 0x09, to be confirmed by IANA. 1853 The format of PDR Base Object is as follows: 1855 0 1 2 3 1856 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 1857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1858 | TrackID |K|R| Flags | ReqLifetime | PDRSequence | 1859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1860 | Option(s)... 1861 +-+-+-+-+-+-+-+-+ 1863 Figure 12: New P-DAO Request Format 1865 TrackID: 8-bit field. In the context of this specification, the 1866 TrackID field signals the RPLInstanceID of the DODAG formed by the 1867 Track, see Section 3.4 and Section 6.3. To allocate a new Track, 1868 the Ingress Node must provide a value that is not in use at this 1869 time. 1871 K: The 'K' flag is set to indicate that the recipient is expected to 1872 send a PDR-ACK back. 1874 R: The 'R' flag is set to request a Complex Track for redundancy. 1876 Flags: Reserved. The Flags field MUST initialized to zero by the 1877 sender and MUST be ignored by the receiver 1879 ReqLifetime: 8-bit unsigned integer. The requested lifetime for the 1880 Track expressed in Lifetime Units (obtained from the DODAG 1881 Configuration option). 1883 A PDR with a fresher PDRSequence refreshes the lifetime, and a 1884 PDRLifetime of 0 indicates that the Track should be destroyed, 1885 e.g., when the application that requested the Track terminates. 1887 PDRSequence: 8-bit wrapping sequence number, obeying the operation 1888 in section 7.2 of [RPL]. The PDRSequence is used to correlate a 1889 PDR-ACK message with the PDR message that triggered it. It is 1890 incremented at each PDR message and echoed in the PDR-ACK by the 1891 Root. 1893 5.2. New PDR-ACK Control Message 1895 The new PDR-ACK is sent as a response to a PDR message with the 'K' 1896 flag set. The RPL Control Code for the PDR-ACK is 0x0A, to be 1897 confirmed by IANA. Its format is as follows: 1899 0 1 2 3 1900 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 1901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1902 | TrackID | Flags | Track Lifetime| PDRSequence | 1903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1904 | PDR-ACK Status| Reserved | 1905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1906 | Option(s)... 1907 +-+-+-+-+-+-+-+ 1909 Figure 13: New PDR-ACK Control Message Format 1911 TrackID: Set to the TrackID indicated in the TrackID field of the 1912 PDR messages that this replies to. 1914 Flags: Reserved. The Flags field MUST initialized to zero by the 1915 sender and MUST be ignored by the receiver 1917 Track Lifetime: Indicates that remaining Lifetime for the Track, 1918 expressed in Lifetime Units; the value of zero (0x00) indicates 1919 that the Track was destroyed or not created. 1921 PDRSequence: 8-bit wrapping sequence number. It is incremented at 1922 each PDR message and echoed in the PDR-ACK. 1924 PDR-ACK Status: 8-bit field indicating the completion. The PDR-ACK 1925 Status is substructured as indicated in Figure 14: 1927 0 1 2 3 4 5 6 7 1928 +-+-+-+-+-+-+-+-+ 1929 |E|R| Value | 1930 +-+-+-+-+-+-+-+-+ 1932 Figure 14: PDR-ACK status Format 1934 E: 1-bit flag. Set to indicate a rejection. When not set, the 1935 value of 0 indicates Success/Unqualified Acceptance and other 1936 values indicate "not an outright rejection". 1937 R: 1-bit flag. Reserved, MUST be set to 0 by the sender and 1938 ignored by the receiver. 1939 Status Value: 6-bit unsigned integer. Values depending on the 1940 setting of the 'E' flag, see Table 28 and Table 29. 1942 Reserved: The Reserved field MUST initialized to zero by the sender 1943 and MUST be ignored by the receiver 1945 5.3. Via Information Options 1947 A VIO signals the ordered list of IPv6 Via Addresses that constitutes 1948 the hops of either a Leg (using Non-Storing Mode) a Segment (using 1949 storing mode) of a Track. A Storing Mode P-DAO contains one Storing 1950 Mode VIO (SM-VIO) whereas a Non-Storing Mode P-DAO contains one Non- 1951 Storing Mode VIO (NSM-VIO) 1953 The duration of the validity of a VIO is indicated in a Segment 1954 Lifetime field. A P-DAO message that contains a VIO with a Segment 1955 Lifetime of zero is referred as a No-Path P-DAO. 1957 The VIO contains one or more SRH-6LoRH header(s), each formed of a 1958 SRH-6LoRH head and a collection of compressed Via Addresses, except 1959 in the case of a Non-Storing Mode No-Path P-DAO where the SRH-6LoRH 1960 header is not present. 1962 In the case of a SM-VIO, or if [RFC8138] is not used in the data 1963 packets, then the Root MUST use only one SRH-6LoRH per Via 1964 Information Option, and the compression is the same forall the 1965 addresses, as shown in Figure 15, for simplicity. 1967 In case of an NSM-VIO and if [RFC8138] is in use in the Main DODAG, 1968 the Root SHOULD optimize the size of the NSM-VIO if using different 1969 SRH-6LoRH Types make the VIO globally shorter; this means that more 1970 than one SRH-6LoRH may be present. 1972 The format of the Via Information Options is as follows: 1974 0 1 2 3 1975 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 1976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1977 | Type | Option Length | Flags | P-RouteID | 1978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1979 |Segm. Sequence | Seg. Lifetime | SRH-6LoRH head | 1980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1981 | | 1982 . Via Address 1 (compressed by RFC 8138) . 1983 | | 1984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1985 | | 1986 . .... . 1987 | | 1988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1989 | | 1990 . Via Address n (compressed by RFC 8138) . 1991 | | 1992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1993 | | 1994 . Additional SRH-6LoRH Header(s) . 1995 | | 1996 . .... . 1998 Figure 15: VIO format (uncompressed form) 2000 Option Type: 0x0E for SM-VIO, 0x0F for NSM-VIO (to be confirmed by 2001 IANA), see =Table 26 2003 Option Length: 8-bit unsigned integer, representing the length in 2004 octets of the option, not including the Option Type and Length 2005 fields, see section 6.7.1. of [RPL]; the Option Length is 2006 variable, depending on the number of Via Addresses and the 2007 compression applied. 2009 P-RouteID: 8-bit field that identifies a component of a Track or the 2010 Main DODAG as indicated by the TrackID field. The value of 0 is 2011 used to signal a Serial Track, i.e., made of a single segment/Leg. 2012 In an SM-VIO, the P-RouteID indicates an actual Segment. In an an 2013 NSM-VIO, it indicates a Leg, that is a serial subTrack that is 2014 added to the overall topology of the Track. 2016 Segment Sequence: 8-bit unsigned integer. The Segment Sequence 2017 obeys the operation in section 7.2 of [RPL] and the lollipop 2018 starts at 255. 2020 When the Root of the DODAG needs to refresh or update a Segment in 2021 a Track, it increments the Segment Sequence individually for that 2022 Segment. 2024 The Segment information indicated in the VIO deprecates any state 2025 for the Segment indicated by the P-RouteID within the indicated 2026 Track and sets up the new information. 2028 A VIO with a Segment Sequence that is not as fresh as the current 2029 one is ignored. 2031 A VIO for a given DODAGID with the same (TrackID, P-RouteID, 2032 Segment Sequence) indicates a retry; it MUST NOT change the 2033 Segment and MUST be propagated or answered as the first copy. 2035 Segment Lifetime: 8-bit unsigned integer. The length of time in 2036 Lifetime Units (obtained from the Configuration option) that the 2037 Segment is usable. 2039 The period starts when a new Segment Sequence is seen. The value 2040 of 255 (0xFF) represents infinity. The value of zero (0x00) 2041 indicates a loss of reachability. 2043 SRH-6LoRH head: The first 2 bytes of the (first) SRH-6LoRH as shown 2044 in Figure 6 of [RFC8138]. As an example, a 6LoRH Type of 4 means 2045 that the VIA Addresses are provided in full with no compression. 2047 Via Address: An IPv6 ULA or GUA of a node along the Segment. The 2048 VIO contains one or more IPv6 Via Addresses listed in the datapath 2049 order from Ingress to Egress. The list is expressed in a 2050 compressed form as signaled by the preceding SRH-6LoRH header. 2052 In a Storing Mode P-DAO that updates or removes a section of an 2053 already existing Segment, the list in the SM-VIO may represent 2054 only the section of the Segment that is being updated; at the 2055 extreme, the SM-VIO updates only one node, in which case it 2056 contains only one IPv6 address. In all other cases, the list in 2057 the VIO MUST be complete. 2059 In the case of an SM-VIO, the list indicates a sequential (strict) 2060 path through direct neighbors, the complete list starts at Ingress 2061 and ends at Egress, and the nodes listed in the VIO, including the 2062 Egress, MAY be considered as implicit Targets. 2064 In the case of an NSM-VIO, the complete list can be loose and 2065 excludes the Ingress node, starting at the first loose hop and 2066 ending at a Track Egress; the Track Egress MUST be considered as 2067 an implicit Target, so it MUST NOT be signaled in a RPL Target 2068 Option. 2070 5.4. Sibling Information Option 2072 The Sibling Information Option (SIO) provides indication on siblings 2073 that could be used by the Root to form P-Routes. One or more SIO(s) 2074 may be placed in the DAO messages that are sent to the Root in Non- 2075 Storing Mode. 2077 To advertise a neighbor node, the router MUST have an active Address 2078 Registration from that sibling using [RFC8505], for an address (ULA 2079 or GUA) that serves as identifier for the node. If this router also 2080 registers an address to that sibling, and the link has similar 2081 properties in both directions, only the router with the lowest 2082 Interface ID in its registered address needs report the SIO, and the 2083 Root will assume symmetry. 2085 The format of the SIO is as follows: 2087 0 1 2 3 2088 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 2089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2090 | Type | Option Length |S| Flags |Comp.| Opaque | 2091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2092 | Step in Rank | Reserved | 2093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2094 | | 2095 + + 2096 . . 2097 . Sibling DODAGID (if the D flag not set) . 2098 . . 2099 + + 2100 | | 2101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2102 | | 2103 + + 2104 . . 2105 . Sibling Address . 2106 . . 2107 + + 2108 | | 2109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2111 Figure 16: Sibling Information Option Format 2113 Option Type: 0x10 for SIO (to be confirmed by IANA), see =Table 26 2115 Option Length: 8-bit unsigned integer, representing the length in 2116 octets of the option, not including the Option Type and Length 2117 fields, see section 6.7.1. of [RPL]. 2119 Reserved for Flags: MUST be set to zero by the sender and MUST be 2120 ignored by the receiver. 2122 S: 1-bit flag that is set to indicate that sibling belongs to the 2123 same DODAG. When not set, the Sibling DODAGID is indicated. 2125 Flags: Reserved. The Flags field MUST initialized to zero by the 2126 sender and MUST be ignored by the receiver 2128 Opaque: MAY be used to carry information that the node and the Root 2129 understand, e.g., a particular representation of the Link 2130 properties such as a proprietary Link Quality Information for 2131 packets received from the sibling. An industrial Alliance that 2132 uses RPL for a particular use / environment MAY redefine the use 2133 of this field to fit its needs. 2135 Compression Type: 3-bit unsigned integer. This is the SRH-6LoRH 2136 Type as defined in figure 7 in section 5.1 of [RFC8138] that 2137 corresponds to the compression used for the Sibling Address and 2138 its DODAGID if resent. The Compression reference is the Root of 2139 the Main DODAG. 2141 Step in Rank: 16-bit unsigned integer. This is the Step in Rank 2142 [RPL] as computed by the Objective Function between this node and 2143 the sibling, that reflects the abstract Rank increment that would 2144 be computed by the OF if the sibling was the preferred parent. 2146 Reserved: The Reserved field MUST initialized to zero by the sender 2147 and MUST be ignored by the receiver 2149 Sibling DODAGID: 2 to 16 bytes, the DODAGID of the sibling in a 2150 [RFC8138] compressed form as indicated by the Compression Type 2151 field. This field is present if and only if the D flag is not 2152 set. 2154 Sibling Address: 2 to 16 bytes, an IPv6 Address of the sibling, with 2155 a scope that MUST be make it reachable from the Root, e.g., it 2156 cannot be a Link Local Address. The IPv6 address is encoded in 2157 the [RFC8138] compressed form indicated by the Compression Type 2158 field. 2160 An SIO MAY be immediately followed by a DAG Metric Container. In 2161 that case the DAG Metric Container provides additional metrics for 2162 the hop from the Sibling to this node. 2164 6. Root Initiated Routing State 2166 6.1. RPL Network Setup 2168 To avoid the need of Path MTU Discovery, 6LoWPAN links are normally 2169 defined with a MTU of 1280 (see section 4 of [6LoWPAN]). Injecting 2170 packets in a Track typically involves an IP-in-IP encapsulation and 2171 additional IPv6 Extension Headers. This may cause a fragmentation if 2172 the resulting packets exceeds the MTU that is defined for the RPL 2173 domain. 2175 Though fragmentation is possible in a 6LoWPAN LLN, e.g., using 2176 [6LoWPAN], [RFC8930], and/or [RFC8931], it is RECOMMENDED to allow an 2177 MTU that is larger than 1280 in the main DODAG and allows for the 2178 additional headers while exposing only 1280 to the 6LoWPAN Nodes. 2180 6.2. Requesting a Track 2182 This specification introduces the PDR message, used by an LLN node to 2183 request the formation of a new Track for which this node is Ingress. 2184 Note that the namespace for the TrackID is owned by the Ingress node, 2185 and in the absence of a PDR, there must be some procedure for the 2186 Root to assign TrackIDs in that namespace while avoiding collisions, 2187 more in Section 6.3. 2189 The PDR signals the desired TrackID and the duration for which the 2190 Track should be established. Upon a PDR, the Root MAY install the 2191 Track as requested, in which case it answers with a PDR-ACK 2192 indicating the granted Track Lifetime. All the Segments MUST be of a 2193 same mode, either Storing or Non-Storing. All the Segments MUST be 2194 created with the same TrackID and the same DODAGID signaled in the 2195 P-DAO. 2197 The Root designs the Track as it sees best, and updates / changes the 2198 Segments overtime to serve the Track as needed. There is no 2199 notification to the requesting node when those changes happen. The 2200 Segment Lifetime in the P-DAO messages does not need to be aligned to 2201 the Requested Lifetime in the PDR, or between P-DAO messages for 2202 different Segments. The Root may use shorter lifetimes for the 2203 Segments and renew them faster than the Track is, or longer lifetimes 2204 in which case it will need to tear down the Segments if the Track is 2205 not renewed. 2207 When the Track Lifetime that was returned in the PDR-ACK is close to 2208 elapse - vs. the trip time from the node to the Root, the requesting 2209 node SHOULD resend a PDR using the TrackID in the PDR-ACK to extend 2210 the lifetime of the Track, else the Track will time out and the Root 2211 will tear down the whole structure. 2213 If the Track fails and cannot be restored, the Root notifies the 2214 requesting node asynchronously with a PDR-ACK with a Track Lifetime 2215 of 0, indicating that the Track has failed, and a PDR-ACK Status 2216 indicating the reason of the fault. 2218 6.3. Identifying a Track 2220 RPL defines the concept of an Instance to signal an individual 2221 routing topology, and multiple topologies can coexist in the same 2222 network. The RPLInstanceID is tagged in the RPI of every packet to 2223 signal which topology the packet actually follows. 2225 This draft leverages the RPL Instance model as follows: 2227 * The Root MAY use P-DAO messages to add better routes in the main 2228 (Global) RPL Instance in conformance with the routing objectives 2229 in that Instance. 2231 To achieve this, the Root MAY install a Segment along a path down 2232 the main Non-Storing Mode DODAG. This enables a loose source 2233 routing and reduces the size of the Routing Header, see 2234 Section 3.3.1. The Root MAY also install a Track Leg across the 2235 Main DODAG to complement the routing topology. 2237 When adding a P-Route to the RPL Main DODAG, the Root MUST set the 2238 RPLInstanceID field of the P-DAO Base Object (see section 6.4.1. 2239 of [RPL]) to the RPLInstanceID of the Main DODAG, and MUST NOT use 2240 the DODAGID field. A P-Route provides a longer match to the 2241 Target Address than the default route via the Root, so it is 2242 preferred. 2244 * The Root MAY also use P-DAO messages to install a Track as an 2245 independent routing topology (say, Traffic Engineered) to achieve 2246 particular routing characteristics from an Ingress to an Egress 2247 Endpoints. To achieve this, the Root MUST set up a local RPL 2248 Instance (see section 5 of [RPL]), and the Local RPLInstanceID 2249 serves as TrackID. The TrackID MUST be unique for the IPv6 ULA or 2250 GUA of the Track Ingress that serves as DODAGID for the Track. 2252 This way, a Track is uniquely identified by the tuple (DODAGID, 2253 TrackID) where the TrackID is always represented with the D flag 2254 set to 0 (see also section 5.1. of [RPL]), indicating when used in 2255 an RPI that the source address of the IPv6 packet signals the 2256 DODAGID. 2258 The P-DAO Base Object MUST indicate the tuple (DODAGID, TrackID) 2259 that identifies the Track as shown in Figure 8, and the P-RouteID 2260 that identifies the P-Route MUST be signaled in the VIO as shown 2261 in Figure 15. 2263 The Track Ingress is the Root of the DODAG ID formed by the local 2264 RPL Instance. It owns the namespace of its TrackIDs, so it can 2265 pick any unused value to request a new Track with a PDR. In a 2266 particular deployment where PDR are not used, the namespace can be 2267 delegated to the main Root, which can assign the TrackIDs for the 2268 Tracks it creates without collision. 2270 With this specification, the Root is aware of all the active 2271 Tracks, so it can also pick any unused value to form Tracks 2272 without a PDR. To avoid a collision of the Root and the Track 2273 Ingress picking the same value at the same time, it is RECOMMENDED 2274 that the Track Ingress starts allocating the ID value of the Local 2275 RPLInstanceID (see section 5.1. of [RPL]) used as TrackIDs with 2276 the value 0 incrementing, while the Root starts with 63 2277 decrementing. 2279 6.4. Installing a Track 2281 A Serial Track can be installed by a single P-Route that signals the 2282 sequence of consecutive nodes, either in Storing Mode as a single- 2283 Segment Track, or in Non-Storing Mode as a single-Leg Track. A 2284 single-Leg Track can be installed as a loose Non-Storing Mode 2285 P-Route, in which case the next loose entry must recursively be 2286 reached over a Serial Track. 2288 A Complex Track can be installed as a collection of P-Routes with the 2289 same DODAGID and Track ID. The Ingress of a Non-Storing Mode P-Route 2290 is the owner and Root of the DODAGID. The Ingress of a Storing Mode 2291 P-Route must be either the owner of the DODAGID, or a hop of a Leg of 2292 the same Track. In the latter case, the Targets of the P-Route must 2293 include the next hop of the Leg if there is one, to ensure forwarding 2294 continuity. In the case of a Complex Track, each Segment is 2295 maintained independently and asynchronously by the Root, with its own 2296 lifetime that may be shorter, the same, or longer than that of the 2297 Track. 2299 A route along a Track for which the TrackID is not the RPLInstanceID 2300 of the Main DODAG MUST be installed with a higher precedence than the 2301 routes along the Main DODAG, meaning that: 2303 * Longest match MUST be the prime comparison for routing. 2305 * In case of equal length match, the route along the Track MUST be 2306 preferred vs. the one along the Main DODAG. 2308 * There SHOULD NOT be 2 different Tracks leading to the same Target 2309 from same Ingress node, unless there's a policy for selecting 2310 which packets use which Track; such policy is out of scope. 2312 * A packet that was routed along a Track MUST NOT be routed along 2313 the main DODAG again; if the destination is not reachable as a 2314 neighbor by the node where the packet exits the Track then the 2315 packet MUST be dropped. 2317 6.4.1. Signaling a Projected Route 2319 This draft adds a capability whereby the Root of a main RPL DODAG 2320 installs a Track as a collection of P-Routes, using a Projected-DAO 2321 (P-DAO) message for each individual Track Leg or Segment. The P-DAO 2322 signals a collection of Targets in the RPL Target Option(s) (RTO). 2323 Those Targets can be reached via a sequence of routers indicated in a 2324 VIO. 2326 Like a classical DAO message, a P-DAO causes a change of state only 2327 if it is "new" per section 9.2.2. "Generation of DAO Messages" of 2328 the RPL specification [RPL]; this is determined using the Segment 2329 Sequence information from the VIO as opposed to the Path Sequence 2330 from a TIO. Also, a Segment Lifetime of 0 in a VIO indicates that 2331 the P-Route associated to the Segment is to be removed. There are 2332 two Modes of operation for the P-Routes, the Storing and the Non- 2333 Storing Modes. 2335 A P-DAO message MUST be sent from the address of the Root that serves 2336 as DODAGID for the Main DODAG. It MUST contain either exactly one 2337 sequence of one or more RTOs followed one VIO, or any number of 2338 sequences of one or more RTOs followed by one or more TIOs. The 2339 former is the normal expression for this specification, where as the 2340 latter corresponds to the variation for lesser constrained 2341 environments described in Section 7.2. 2343 A P-DAO that creates or updates a Track Leg MUST be sent to a GUA or 2344 a ULA of the Ingress of the Leg; it must contain the full list of 2345 hops in the Leg unless the Leg is being removed. A P-DAO that 2346 creates a new Track Segment MUST be sent to a GUA or a ULA of the 2347 Segment Egress and MUST signal the full list of hops in Segment; a 2348 P-DAO that updates (including deletes) a section of a Segment MUST be 2349 sent to the first node after the modified Segment and signal the full 2350 list of hops in the section starting at the node that immediately 2351 precedes the modified section. 2353 In Non-Storing Mode, as discussed in Section 6.4.3, the Root sends 2354 the P-DAO to the Track Ingress where the source-routing state is 2355 applied, whereas in Storing Mode, the P-DAO is sent to the last node 2356 on the installed path and forwarded in the reverse direction, 2357 installing a Storing Mode state at each hop, as discussed in 2358 Section 6.4.2. In both cases the Track Ingress is the owner of the 2359 Track, and it generates the P-DAO-ACK when the installation is 2360 successful. 2362 If the 'K' Flag is present in the P-DAO, the P-DAO must be 2363 acknowledged using a DAO-ACK that is sent back to the address of the 2364 Root from which the P-DAO was received. In most cases, the first 2365 node of the Leg, Segment, or updated section of the Segment is the 2366 node that sends the acknowledgment. The exception to the rule is 2367 when an intermediate node in a Segment fails to forward a Storing 2368 Mode P-DAO to the previous node in the SM-VIO. 2370 In a No-Path Non-Storing Mode P-DAO, the SRH-6LoRH MUST NOT be 2371 present in the NSM-VIO; the state in the Ingress is erased 2372 regardless. In all other cases, a VIO MUST contain at least one Via 2373 Address, and a Via Address MUST NOT be present more than once, which 2374 would create a loop. 2376 A node that processes a VIO MAY verify whether one of these 2377 conditions happen, and when so, it MUST ignore the P-DAO and reject 2378 it with a RPL Rejection Status of "Error in VIO" in the DAO-ACK, see 2379 Section 11.15. 2381 Other errors than those discussed explicitely that prevent the 2382 installing the route are acknowledged with a RPL Rejection Status of 2383 "Unqualified Rejection" in the DAO-ACK. 2385 6.4.2. Installing a Track Segment with a Storing Mode P-Route 2387 As illustrated in Figure 17, a Storing Mode P-DAO installs a route 2388 along the Segment signaled by the SM-VIO towards the Targets 2389 indicated in the Target Options. The Segment is to be included in a 2390 DODAG indicated by the P-DAO Base Object, that may be the one formed 2391 by the RPL Main DODAG, or a Track associated with a local RPL 2392 Instance. 2394 ------+--------- 2395 | Internet 2396 | 2397 +-----+ 2398 | | Border router 2399 | | (RPL Root) 2400 +-----+ | ^ | 2401 | | DAO | ACK | 2402 o o o o | | | 2403 o o o o o o o o o | ^ | Projected . 2404 o o o o o o o o o o | | DAO | Route . 2405 o o o o o o o o o | ^ | . 2406 o o o o o o o o v | DAO v . 2407 o o LLN o o o | 2408 o o o o o Loose Source Route Path | 2409 o o o o v 2411 Figure 17: Projecting a route 2413 In order to install the relevant routing state along the Segment , 2414 the Root sends a unicast P-DAO message to the Track Egress router of 2415 the routing Segment that is being installed. The P-DAO message 2416 contains a SM-VIO with the strict sequence of Via Addresses. The SM- 2417 VIO follows one or more RTOs indicating the Targets to which the 2418 Track leads. The SM-VIO contains a Segment Lifetime for which the 2419 state is to be maintained. 2421 The Root sends the P-DAO directly to the Egress node of the Segment. 2422 In that P-DAO, the destination IP address matches the last Via 2423 Address in the SM-VIO. This is how the Egress recognizes its role. 2424 In a similar fashion, the Segment Ingress node recognizes its role as 2425 it matches first Via Address in the SM-VIO. 2427 The Egress node of the Segment is the only node in the path that does 2428 not install a route in response to the P-DAO; it is expected to be 2429 already able to route to the Target(s) based on its existing tables. 2430 If one of the Targets is not known, the node MUST answer to the Root 2431 with a DAO-ACK listing the unreachable Target(s) in an RTO and a 2432 rejection status of "Unreachable Target". 2434 If the Egress node can reach all the Targets, then it forwards the 2435 P-DAO with unchanged content to its predecessor in the Segment as 2436 indicated in the list of Via Information options, and recursively the 2437 message is propagated unchanged along the sequence of routers 2438 indicated in the P-DAO, but in the reverse order, from Egress to 2439 Ingress. 2441 The address of the predecessor to be used as destination of the 2442 propagated DAO message is found in the Via Address the precedes the 2443 one that contain the address of the propagating node, which is used 2444 as source of the message. 2446 Upon receiving a propagated DAO, all except the Egress router MUST 2447 install a route towards the DAO Target(s) via their successor in the 2448 SM-VIO. A router that cannot store the routes to all the Targets in 2449 a P-DAO MUST reject the P-DAO by sending a DAO-ACK to the Root with a 2450 Rejection Status of "Out of Resources" as opposed to forwarding the 2451 DAO to its predecessor in the list. The router MAY install 2452 additional routes towards the VIA Addresses that are the SM-VIO after 2453 self, if any, but in case of a conflict or a lack of resource, the 2454 route(s) to the Target(s) are the ones that must be installed in 2455 priority. 2457 If a router cannot reach its predecessor in the SM-VIO, the router 2458 MUST send the DAO-ACK to the Root with a Rejection Status of 2459 "Predecessor Unreachable". 2461 The process continues till the P-DAO is propagated to Ingress router 2462 of the Segment, which answers with a DAO-ACK to the Root. The Root 2463 always expects a DAO-ACK, either from the Track Ingress with a 2464 positive status or from any node along the segment with a negative 2465 status. If the DAO-ACK is not received, the Root may retry the DAO 2466 with the same TID, or tear down the route. 2468 6.4.3. Installing a Track Leg with a Non-Storing Mode P-Route 2470 As illustrated in Figure 18, a Non-Storing Mode P-DAO installs a 2471 source-routed path within the Track indicated by the P-DAO Base 2472 Object, towards the Targets indicated in the Target Options. The 2473 source-routed path requires a Source-Routing header which implies an 2474 IP-in-IP encapsulation to add the SRH to an existing packet. It is 2475 sent to the Track Ingress which creates a tunnel associated with the 2476 Track, and connected routes over the tunnel to the Targets in the 2477 RTO. The tunnel encapsulation MUST incorporate a routing header via 2478 the list addresses listed in the VIO in the same order. The content 2479 of the NSM-VIO starting at the first SRH-6LoRH header MUST be used 2480 verbatim by the Track Ingress when it encapsulates a packet to 2481 forward it over the Track. 2483 ------+--------- 2484 | Internet 2485 | 2486 +-----+ 2487 | | Border router 2488 | | (RPL Root) 2489 +-----+ | P ^ ACK 2490 | Track | DAO | 2491 o o o o Ingress X V | X 2492 o o o o o o o X o X Source 2493 o o o o o o o o X o o X Routed 2494 o o ° o o o o X o X Segment 2495 o o o o o o o o X Egress X 2496 o o o o o | 2497 Target 2498 o o LLN o o 2499 o o o o 2501 Figure 18: Projecting a Non-Storing Route 2503 The next entry in the source-routed path must be either a neighbor of 2504 the previous entry, or reachable as a Target via another P-Route, 2505 either Storing or Non-Storing, which implies that the nested P-Route 2506 has to be installed before the loose sequence is, and that P-Routes 2507 must be installed from the last to the first along the datapath. For 2508 instance, a Segment of a Track must be installed before the Leg(s) of 2509 the same Track that use it, and stitched Segments must be installed 2510 in order from the last that reaches to the Targets to the first. 2512 If the next entry in the loose sequence is reachable over a Storing 2513 Mode P-Route, it MUST be the Target of a Segment and the Ingress of a 2514 next segment, both already setup; the segments are associated with 2515 the same Track, which avoids the need of an additional encapsulation. 2516 For instance, in Section 3.5.1.3, Segments A==>B-to-C and 2517 C==>D==>E-to-F must be installed with Storing Mode P-DAO messages 1 2518 and 2 before the Track A-->C-->E-to-F that joins them can be 2519 installed with Non-Storing Mode P-DAO 3. 2521 Conversely, if it is reachable over a Non-Storing Mode P-Route, the 2522 next loose source-routed hop of the inner Track is a Target of a 2523 previously installed Track and the Ingress of a next Track, which 2524 requires a de- and a re-encapsulation when switching the outer Tracks 2525 that join the loose hops. This is examplified in Section 3.5.2.3 2526 where Non-Storing Mode P-DAO 1 and 2 install strict Tracks that Non- 2527 Storing Mode P-DAO 3 joins as a super Track. In such a case, packets 2528 are subject to double IP-in-IP encapsulation. 2530 6.5. Tearing Down a P-Route 2532 A P-DAO with a lifetime of 0 is interpreted as a No-Path DAO and 2533 results in cleaning up existing state as opposed to refreshing an 2534 existing one or installing a new one. To tear down a Track, the Root 2535 must tear down all the Track Segments and Legs that compose it one by 2536 one. 2538 Since the state about a Leg of a Track is located only on the Ingress 2539 Node, the Root cleans up the Leg by sending an NSM-VIO to the Ingress 2540 indicating the TrackID and the P-RouteID of the Leg being removed, a 2541 Segment Lifetime of 0 and a newer Segment Sequence. The SRH-6LoRH 2542 with the Via Addresses in the NSM-VIO are not needed; it SHOULD not 2543 be placed in the message and MUST be ignored by the receiver. Upon 2544 that NSM-VIO, the Ingress node removes all state for that Track if 2545 any, and replies positively anyway. 2547 The Root cleans up a section of a Segment by sending an SM-VIO to the 2548 last node of the Segment, with the TrackID and the P-RouteID of the 2549 Segment being updated, a Segment Lifetime of zero (0) and a newer 2550 Segment Sequence. The Via Addresses in the SM-VIO indicates the 2551 section of the Segment being modified, from the first to the last 2552 node that is impacted. This can be the whole Segment if it is 2553 totally removed, or a sequence of one or more nodes that have been 2554 bypassed by a Segment update. 2556 The No-Path P-DAO is forwarded normally along the reverse list, even 2557 if the intermediate node does not find a Segment state to clean up. 2558 This results in cleaning up the existing Segment state if any, as 2559 opposed to refreshing an existing one or installing a new one. 2561 6.6. Maintaining a Track 2563 Repathing a Track Segment or Leg may cause jitter and packet 2564 misordering. For critical flows that require timely and/or in-order 2565 delivery, it might be necessary to deploy the PAREO functions 2566 [RAW-ARCHI] over a highly redundant Track. This specification allows 2567 to use more than one Leg for a Track, and 1+N packet redundancy. 2569 This section provides the steps to ensure that no packet is lost due 2570 to the operation itself. This is ensured by installing the new 2571 section from its last node to the first, so when an intermediate node 2572 installs a route along the new section, all the downstream nodes in 2573 the section have already installed their own. The disabled section 2574 is removed when the packets in-flight are forwarded along the new 2575 section as well. 2577 6.6.1. Maintaining a Track Segment 2579 To modify a section of a Segment between a first node and a second, 2580 downstream node (which can be the Ingress and Egress), while 2581 conserving those nodes in the Segment, the Root sends an SM-VIO to 2582 the second node indicating the sequence of nodes in the new section 2583 of the Segment. The SM-VIO indicates the TrackID and the P-RouteID 2584 of the Segment being updated, and a newer Segment Sequence. The 2585 P-DAO is propagated from the second to the first node and on the way, 2586 it updates the state on the nodes that are common to the old and the 2587 new section of the Segment and creates a state in the new nodes. 2589 When the state is updated in an intermediate node, that node might 2590 still receive packets that were in flight from the Ingress to self 2591 over the old section of the Segment. Since the remainder of the 2592 Segment is already updated, the packets are forwarded along the new 2593 version of the Segment from that node on. 2595 After a reasonable time to enable the deprecated sections to empty, 2596 the Root tears down the remaining section(s) of the old segments are 2597 teared down as described in Section 6.5. 2599 6.6.2. Maintaining a Track Leg 2601 This specification allows the Root to add Legs to a Track by sending 2602 a Non-Storing Mode P-DAO to the Ingress associated to the same 2603 TrackID, and a new Segment ID. If the Leg is loose, then the 2604 Segments that join the hops must be created first. It makes sense to 2605 add a new Leg before removing one that is becoming excessively lossy, 2606 and switch to the new Leg before removing the old. Dropping a Track 2607 before the new one is installed would reroute the traffic via the 2608 root; this may augment the latency beyond acceptable thresholds, and 2609 load the network near the root. This may also cause loops in the 2610 case of stitched Tracks; the packets that cannot be injected in the 2611 second Track may be routed back at reinjected at the Ingress of the 2612 first. 2614 It is also possible to update a Track Leg by sending a Non-Storing 2615 Mode P-DAO to the Ingress with the same Segment ID, an incremented 2616 Segment Sequence, and the new complete list of hops in the NSM-VIO. 2617 Updating a live Leg means changing one or more of the intermediate 2618 loose hops, and involves laying out new Segments from and to the new 2619 loose hops before the NSM-VIO for the new Leg is issued. 2621 Packets that are in flight over the old version of the Track Leg 2622 still follow the old source route path over the old Segments. After 2623 a reasonable time to enable the deprecated Segments to empty, the 2624 Root tears down those Segments as described in Section 6.5. 2626 6.7. Encapsulating and Forwarding Along a Track 2628 When injecting a packet in a Track, the Ingress router must 2629 encapsulate the packet using IP-in-IP to add the Source Routing 2630 Header with the final destination set to the Track Egress. 2632 All properties of a Track operations are inherited form the main RPL 2633 Instance that is used to install the Track. For instance, the use of 2634 compression per [RFC8138] is determined by whether it is used in the 2635 RPL Main DODAG, e.g., by setting the "T" flag [TURN-ON_RFC8138] in 2636 the RPL configuration option. 2638 The Track Ingress that places a packet in a Track encapsulates it 2639 with an IP-in-IP header, a Routing Header, and an IPv6 Hop-by-Hop 2640 Option Header that contains the RPL Packet Information (RPI) as 2641 follows: 2643 * In the uncompressed form the source of the packet is the address 2644 that this router uses as DODAGID for the Track, the destination is 2645 the first Via Address in the NSM-VIO, and the RH is a Source 2646 Routing Header (SRH) [RFC6554] that contains the list of the 2647 remaining Via Addresses terminating by the Track Egress. 2649 * The preferred alternate in a network where 6LoWPAN Header 2650 Compression [RFC6282] is used is to leverage "IPv6 over Low-Power 2651 Wireless Personal Area Network (6LoWPAN) Paging Dispatch" 2652 [RFC8025] to compress the RPL artifacts as indicated in [RFC8138]. 2654 In that case, the source routed header is the exact copy of the 2655 (chain of) SRH-6LoRH found in the NSM-VIO, also terminating by the 2656 Track Egress. The RPI-6LoRH is appended next, followed by an IP- 2657 in-IP 6LoRH Header that indicates the Ingress router in the 2658 Encapsulator Address field, see as a similar case Figure 20 of 2659 [TURN-ON_RFC8138]. 2661 To signal the Track in the packet, this specification leverages the 2662 RPL Forwarding model follows: 2664 * In the data packets, the Track DODAGID and the TrackID MUST be 2665 respectively signaled as the IPv6 Source Address and the 2666 RPLInstanceID field of the RPI that MUST be placed in the outer 2667 chain of IPv6 Headers. 2669 The RPI carries a local RPLInstanceID called the TrackID, which, 2670 in association with the DODAGID, indicates the Track along which 2671 the packet is forwarded. 2673 The D flag in the RPLInstanceID MUST be set to 0 to indicate that 2674 the source address in the IPv6 header is set ot the DODAGID, more 2675 in Section 6.3. 2677 * This draft conforms to the principles of [RFC9008] with regards to 2678 packet forwarding and encapsulation along a Track, as follows: 2680 - With this draft, the Track is a RPL DODAG. From the 2681 perspective of that DODAG, the Track Ingress is the Root, the 2682 Track Egress is a RPL-Aware 6LR, and neighbors of the Track 2683 Egress that can be reached via the Track, but are external to 2684 it, are external destinations and treated as RPL-Unaware Leaves 2685 (RULs). The encapsulation rules in [RFC9008] apply. 2687 - If the Track Ingress is the originator of the packet and the 2688 Track Egress is the destination of the packet, there is no need 2689 for an encapsulation. 2691 - So the Track Ingress must encapsulate the traffic that it did 2692 not originate, and add an RPI. 2694 A packet that is being routed over the RPL Instance associated to 2695 a first Non-Storing Mode Track MAY be placed (encapsulated) in a 2696 second Track to cover one loose hop of the first Track as 2697 discussed in more details Section 3.5.2.3. On the other hand, a 2698 Storing Mode Track must be strict and a packet that it placed in a 2699 Storing Mode Track MUST follow that Track till the Track Egress. 2701 The forwarding of a packet along a track will fail if the Track 2702 continuity is broken,e.g.: 2704 * In the case of a strict path along a Segment, if the next strict 2705 hop is not reachable, the packet is dropped. 2707 * In the case of a loose source-routed path, when the loose next hop 2708 is not a neighbor, there must be a Segment of the same Track to 2709 that loose next hop. When that is the case the packet is 2710 forwarded to the next hop along that segment, or a common neighbor 2711 with the loose next hop, on which case the packet is forwarded to 2712 that neighbor, or another Track to the loose next hop for which 2713 this node or a neighbor is Ingress; in the last case, another 2714 encapsulation takes place and the process possibly recurses; 2715 otherwise the packet is dropped. 2717 * When a Track Egress extracts a packet from a Track (decapsulates 2718 the packet), the destination of the inner packet must be either 2719 this node or a direct neighbor, or a Target of another Segment of 2720 the same Track for which this node is Ingress, otherwise the 2721 packet MUST be dropped. 2723 In case of a failure forwarding a packet along a Segment, e.g., the 2724 next hop is unreachable, the node that discovers the fault MUST send 2725 an ICMPv6 Error message [RFC4443] to the Root, with a new Code "Error 2726 in P-Route" (See Section 11.14). The Root can then repair by 2727 updating the broken Segment and/or Tracks, and in the case of a 2728 broken Segment, remove the leftover sections of the segment using SM- 2729 VIOs with a lifetime of 0 indicating the section ot one or more nodes 2730 being removed (See Section 6.6). 2732 In case of a permanent forwarding error along a Source Route path, 2733 the node that fails to forward SHOULD send an ICMP error with a code 2734 "Error in Source Routing Header" back to the source of the packet, as 2735 described in section 11.2.2.3. of [RPL]. Upon this message, the 2736 encapsulating node SHOULD stop using the source route path for a 2737 reasonable period of time which duration depends on the deployment, 2738 and it SHOULD send an ICMP message with a Code "Error in P-Route" to 2739 the Root. Failure to follow these steps may result in packet loss 2740 and wasted resources along the source route path that is broken. 2742 Either way, the ICMP message MUST be throttled in case of consecutive 2743 occurrences. It MUST be sourced at the ULA or a GUA that is used in 2744 this Track for the source node, so the Root can establish where the 2745 error happened. 2747 The portion of the invoking packet that is sent back in the ICMP 2748 message SHOULD record at least up to the RH if one is present, and 2749 this hop of the RH SHOULD be consumed by this node so that the 2750 destination in the IPv6 header is the next hop that this node could 2751 not reach. if a 6LoWPAN Routing Header (6LoRH) [RFC8138] is used to 2752 carry the IPv6 routing information in the outer header then that 2753 whole 6LoRH information SHOULD be present in the ICMP message. 2755 6.8. Compression of the RPL Artifacts 2757 When using [RFC8138] in the Main DODAG operated in Non-Storing Mode 2758 in a 6LoWPAN LLN, a typical packet that circulates in the Main DODAG 2759 is formatted as shown in Figure 19, representing the case where : 2761 +-+ ... -+- ... -+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-... 2762 |11110001| SRH- | RPI- | IP-in-IP | NH=1 |11110CPP| UDP | UDP 2763 | Page 1 | 6LoRH | 6LoRH | 6LoRH |LOWPAN_IPHC| UDP | hdr |Payld 2764 +-+ ... -+- ... -+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-... 2765 <= RFC 6282 => 2766 <================ Inner packet ==================== = = 2768 Figure 19: A Packet as Forwarded along the Main DODAG 2770 Since there is no page switch between the encapsulated packet and the 2771 encapsulation, the first octet of the compressed packet that acts as 2772 page selector is actually removed at encapsulation, so the inner 2773 packet used in the descriptions below start with the SRH-6LoRH, and 2774 is verbatim the packet represented in Figure 19 from the second octet 2775 on. 2777 When encapsulating that inner packet to place it in the Track, the 2778 first header that the Ingress appends at the head of the inner packet 2779 is an IP-in-IP 6LoRH Header; in that header, the encapsulator 2780 address, which maps to the IPv6 source address in the uncompressed 2781 form, contains a GUA or ULA IPv6 address of the Ingress node that 2782 serves as DODAG ID for the Track, expressed in the compressed form 2783 and using the DODAGID of the Main DODAG as compression reference. If 2784 the address is compressed to 2 bytes, the resulting value for the 2785 Length field shown in Figure 20 is 3, meaning that the SRH-6LoRH as a 2786 whole is 5-octets long. 2788 0 1 2 2789 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 2791 |1|0|1| Length | 6LoRH Type 6 | Hop Limit | Track DODAGID | 2792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 2794 Figure 20: The IP-in-IP 6LoRH Header 2796 At the head of the resulting sequence of bytes, the track Ingress 2797 then adds the RPI that carries the TrackID as RPLinstanceID as a P- 2798 RPI-6LoRH Header, as illustrated in Figure 11, using the TrackID as 2799 RPLInstanceID. Combined with the IP-in-IP 6LoRH Header, this allows 2800 to identify the Track without ambiguity. 2802 The SRH-6LoRH is then added at the head of the resulting sequence of 2803 bytes as a verbatim copy of the content of the SR-VIO that signaled 2804 the selected Track Leg. 2806 0 1 2807 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 .. .. .. 2808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+ 2809 |1|0|0| Size |6LoRH Type 0..4| Hop1 | Hop2 | | HopN | 2810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+ 2811 Where N = Size + 1 2813 Figure 21: The SRH 6LoRH Header 2815 The format of the resulting encapsulated packet in [RFC8138] 2816 compressed form is illustrated in Figure 22: 2818 +-+ ... -+-+-+- ... -+-+-+- ... -+-+-+-+-+- ... +-+-+-+-+-+-+- ... 2819 | Page 1 | SRH-6LoRH | P-RPI-6LoRH | IP-in-IP 6LoRH | Inner Packet 2820 +-+ ... -+-+-+- ... -+-+-+- ... -+-+-+-+-+- ... +-+-+-+-+-+-+- ... 2822 Signals : Loose Hops : TrackID : Track DODAGID : 2824 Figure 22: A Packet as Forwarded along a Track 2826 7. Lesser Constrained Variations 2828 7.1. Storing Mode Main DODAG 2830 This specification expects that the Main DODAG is operated in Non- 2831 Storing Mode. The reasons for that limitation are mostly related to 2832 LLN operations, power and spectrum conservation: 2834 * In Non-Storing Mode The Root already possesses the DODAG topology, 2835 so the additional topological information is reduced to the 2836 siblings. 2838 * The downwards routes are updated with unicast messages to the 2839 Root, which ensures that the Root can reach back to the LLN nodes 2840 after a repair faster than in the case of Storing Mode. Also the 2841 Root can control the use of the path diversity in the DODAG to 2842 reach to the LLN nodes. For both reasons, Non-Storing Mode 2843 provides better capabilities for the Root to maintain the 2844 P-Routes. 2846 * When the Main DODAG is operated in Non-Storing Mode, P-Routes 2847 enable loose Source Routing, which is only an advantage in that 2848 mode. Storing Mode does not use Source Routing Headers, and does 2849 not derive the same benefits from this capability. 2851 On the other hand, since RPL is a Layer-3 routing protocol, its 2852 applicability extends beyond LLNs to a generic IP network. RPL 2853 requires fewer resources than alternative IGPs like OSPF, ISIS, 2854 EIGRP, BABEL or RIP at the expense of a route stretch vs. the 2855 shortest path routes to a destination that those protocols compute. 2856 P-Routes add the capability to install shortest and/or constrained 2857 routes to special destinations such as discussed in section A.9.4. of 2858 the ANIMA ACP [RFC8994]. 2860 In a powered and wired network, when enough memory to store the 2861 needed routes is available, the RPL Storing Mode proposes a better 2862 trade-off than the Non-Storing, as it reduces the route stretch and 2863 lowers the load on the Root. In that case, the control path between 2864 the Root and the LLN nodes is highly available compared to LLNs, and 2865 the nodes can be reached to maintain the P-Routes at most times. 2867 This section specifies the additions that are needed to support 2868 Projected Routes when the Main DODAG is operated in Storing Mode. As 2869 long as the RPI can be processed adequately by the dataplane, the 2870 changes to this specification are limited to the DAO message. The 2871 Track structure, routes and forwarding operations remain the same. 2872 Since there is no capability negotiation, the expectation is that all 2873 the nodes in the network support this specification in the same 2874 fashion, or are configured the same way through management. 2876 In Storing Mode, the Root misses the Child to Parent relationship 2877 that forms the Main DODAG, as well as the sibling information. To 2878 provide that knowledge the nodes in the network MUST send additional 2879 DAO messages that are unicast to the Root as Non-Storing DAO messages 2880 are. 2882 In the DAO message, the originating router advertises a set of 2883 neighbor nodes using Sibling Information Options (SIO)s, regardless 2884 of the relative position in the DODAG of the advertised node vs. this 2885 router. 2887 The DAO message MUST be formed as follows: 2889 * The originating router is identified by the source address of the 2890 DAO. That address MUST be the one that this router registers to 2891 neighbor routers so the Root can correlate the DAOs from those 2892 routers when they advertise this router as their neighbor. The 2893 DAO contains one or more sequences of one Transit Information 2894 Option and one or more Sibling Information Options. There is no 2895 RPL Target Option so the Root is not confused into adding a 2896 Storing Mode route to the Target. 2898 * The TIO is formed as in Storing Mode, and the Parent Address is 2899 not present. The Path Sequence and Path Lifetime fields are 2900 aligned with the values used in the Address Registration of the 2901 node(s) advertised in the SIO, as explained in Section 9.1. of 2902 [RFC9010]. Having similar values in all nodes allows to factorise 2903 the TIO for multiple SIOs as done with [RPL]. 2905 * The TIO is followed by one or more SIOs that provide an address 2906 (ULA or GUA) of the advertised neighbor node. 2908 But the RPL routing information headers may not be supported on all 2909 type of routed network infrastructures, especially not in high-speed 2910 routers. When the RPI is not supported in the dataplane, there 2911 cannot be local RPL Instances and RPL can only operate as a single 2912 topology (the Main DODAG). The RPL Instance is that of the Main 2913 DODAG and the Ingress node that encapsulates is not the Root. The 2914 routes along the Tracks are alternate routes to those available along 2915 the Main DODAG. They MAY conflict with routes to children and MUST 2916 take precedence in the routing table. The Targets MUST be adjacent 2917 to the Track Egress to avoid loops that may form if the packet is 2918 reinjected in the Main DODAG. 2920 7.2. A Track as a Full DODAG 2922 This specification builds parallel or crossing Track Legs as opposed 2923 to a more complex DODAG with interconnections at any place desirable. 2924 The reason for that limitation is related to constrained node 2925 operations, and capability to store large amount of topological 2926 information and compute complex paths: 2928 * With this specification, the node in the LLN has no topological 2929 awareness, and does not need to maintain dynamic information about 2930 the link quality and availability. 2932 * The Root has a complete topological information and statistical 2933 metrics that allow it or its PCE to perform a global optimization 2934 of all Tracks in its DODAG. Based on that information, the Root 2935 computes the Track Leg and predigest the source route paths. 2937 * The node merely selects one of the proposed paths and applies the 2938 associated pre-computed routing header in the encapsulation. This 2939 alleviates both the complexity of computing a path and the 2940 compressed form of the routing header. 2942 The "Reliable and Available Wireless (RAW) Architecture/Framework" 2943 [RAW-ARCHI] actually expects the PSE at the Track Ingress to react to 2944 changes in the forwarding conditions along the Track, and reroute 2945 packets to maintain the required degree of reliability. To achieve 2946 this, the PSE need the full richness of a DODAG to form any path that 2947 could make meet the Service Level Objective (SLO). 2949 This section specifies the additions that are needed to turn the 2950 Track into a full DODAG and enable the main Root to provide the 2951 necessary topological information to the Track Ingress. The 2952 expectation is that the metrics that the PSE uses are of an order 2953 other than that of the PCE, because of the difference of time scale 2954 between routing and forwarding, mor e in [RAW-ARCHI]. It follows 2955 that the PSE will learn the metrics it needs from an alternate 2956 source, e.g., OAM frames. 2958 To pass the topological information to the Ingress, the Root uses a 2959 P-DAO messages that contains sequences of Target and Transit 2960 Information options that collectively represent the Track, expressed 2961 in the same fashion as in classical Non-Storing Mode. The difference 2962 as that the Root is the source as opposed to the destination, and can 2963 report information on many Targets, possibly the full Track, with one 2964 P-DAO. 2966 Note that the Path Sequence and Lifetime in the TIO are selected by 2967 the Root, and that the Target/Transit information tupples in the 2968 P-DAO are not those received by the Root in the DAO messages about 2969 the said Targets. The Track may follow sibling routes and does not 2970 need to be congruent with the Main DODAG. 2972 8. Profiles 2974 This document provides a set of tools that may or may not be needed 2975 by an implementation depending on the type of application it serves. 2976 This sections described profiles that can be implemented separately 2977 and can be used to discriminate what an implementation can and cannot 2978 do. This section describes profiles that enable to implement only a 2979 portion of this specification to meet a particular use case. 2981 Profiles 0 to 2 operate in the Main RPL Instance and do not require 2982 the support of local RPL Instances or the indication of the RPL 2983 Instance in the data plane. Profile 3 and above leverage Local RPL 2984 Instances to build arbitrary Tracks Rooted at the Track Ingress and 2985 using its namespace for TrackID. 2987 Profiles 0 and 1 are REQUIRED by all implementations that may be used 2988 in LLNs; this enables to use Storing Mode to reduce the size of the 2989 Source Route Header in the most common LLN deployments. Profile 2 is 2990 RECOMMENDED in high speed / wired environment to enable traffic 2991 Engineering and network automation. All the other profile / 2992 environment combinations are OPTIONAL. 2994 Profile 0 Profile 0 is the Legacy support of [RPL] Non-Storing Mode, 2995 with default routing Northwards (up) and strict source routing 2996 Southwards (down the main DOAG). It provides the minimal common 2997 functionality that must be implemented as a prerequisite to all 2998 the Track-supporting profiles. The other Profiles extend Profile 2999 0 with selected capabilities that this specification introduces on 3000 top. 3002 Profile 1 (Storing Mode P-Route Segments along the Main DODAG) Profi 3003 le 1 does not create new paths; compared to Profile 0, it combines 3004 Storing and Non-Storing Modes to balance the size of the Routing 3005 Header in the packet and the amount of state in the intermediate 3006 routers in a Non-Storing Mode RPL DODAG. 3008 Profile 2 (Non-Storing Mode P-Route Segments along the Main DODAG) P 3009 rofile 2 extends Profile 0 with Strict Source-Routing Non-Storing 3010 Mode P-Routes along the Main DODAG, which is the same as Profile 1 3011 but using NSM VIOs as opposed to SM VIOs. Profile 2 provides the 3012 same capability to compress the SRH in packets down the Main DODAG 3013 as Profile 1, but it require an encapsulation, in order to insert 3014 an additional SRH between the loose source routing hops. In that 3015 case, the Tracks MUST be installed as subTracks of the Main DODAG, 3016 the main RPL Instance MUST be used as TrackID, and the Ingress 3017 node that encapsulates is not the Root as it does not own the 3018 DODAGID. 3020 Profile 3 In order to form the best path possible, those Profiles 3021 require the support of Sibling Information Option to inform the 3022 Root of additional possible hops. Profile 3 extends Profile 1 3023 with additional Storing Mode P-Routes that install segments that 3024 do not follow the Main DODAG. If the Segment Ingress (in the SM- 3025 VIO) is the same as the IPv6 Address of the Track Ingress (in the 3026 projected DAO base Object), the P-DAO creates an implicit Track 3027 between the Segment Ingress and the Segment Egress. 3029 Profile 4 Profile 4 extends Profile 2 with Strict Source-Routing 3030 Non-Storing Mode P-Routes to form East-West Tracks that are inside 3031 the Main DODAG but do not necessarily follow it. A Track is 3032 formed as one or more strict source source routed paths between 3033 the Root that is the Track Ingress, and the Track Egress that is 3034 the last node. 3036 Profile 5 Profile 5 Combines Profile 4 with Profile 1 and enables to 3037 loose source routing between the Ingress and the Egress of the 3038 Track. As in Profile 1, Storing Mode P-Routes connect the dots in 3039 the loose source route. 3041 Profile 6 Profile 6 Combines Profile 4 with Profile 2 and also 3042 enables to loose source routing between the Ingress and the Egress 3043 of the Track. 3045 Profile 7 Profile 7 implements profile 5 in a Main DODAG that is 3046 operated in Storing Mode as presented in Section 7.1. As in 3047 Profile 1 and 2, the TrackID is the RPLInstanceID of the Main 3048 DODAG. Longest match rules decide whether a packet is sent along 3049 the Main DODAG or rerouted in a track. 3051 Profile 8 Profile 8 is offered in preparation of the RAW work, and 3052 for use cases where an arbitrary node in the network can afford 3053 the same code complexity as the RPL Root in a traditional 3054 deployment. It offers a full DODAG visibility to the Track 3055 Ingress as specified in Section 7.2 in a Non-Storing Mode Main 3056 DODAG. 3058 Profile 9 Profile 9 combines profiles 7 and 8, operating the Track 3059 as a full DODAG within a Storing Mode Main DODAG, using only the 3060 Main DODAG RPLInstanceID as TrackID. 3062 9. Backwards Compatibility 3064 This specification can operate in a mixed network where some nodes 3065 support it and some do not. There are restructions, though. All 3066 nodes that need to process a P-DAO must support this specification. 3067 As discussed in Section 3.7.1, how the root knows whether the nodes 3068 capabilities and whether it support this specification is out of 3069 scope. 3071 This specification defines the 'D' flag in the RPL DODAG 3072 Configuration Option (see Section 4.1.6) to signal that the RPL nodes 3073 can request the creation of Tracks. The requester may not know 3074 whether the Track can effectively be constructed, and whether enough 3075 nodes along the preferred paths support this specification. 3076 Therefore it makes sense to only set the 'D' flags in DIO when the 3077 conditions of success are in place, in particular when all the nodes 3078 that could be on path of tracks are upgraded. 3080 10. Security Considerations 3082 It is worth noting that with [RPL], every node in the LLN is RPL- 3083 aware and can inject any RPL-based attack in the network. This draft 3084 uses messages that are already present in RPL [RPL] with optional 3085 secured versions. The same secured versions may be used with this 3086 draft, and whatever security is deployed for a given network also 3087 applies to the flows in this draft. 3089 The LLN nodes depend on the 6LBR and the RPL participants for their 3090 operation. A trust model must be put in place to ensure that the 3091 right devices are acting in these roles, so as to avoid threats such 3092 as black-holing, (see [RFC7416] section 7). This trust model could 3093 be at a minimum based on a Layer-2 Secure joining and the Link-Layer 3094 security. This is a generic 6LoWPAN requirement, see Req5.1 in 3095 Appendix B.5 of [RFC8505]. 3097 In a general manner, the Security Considerations in [RPL], and 3098 [RFC7416] apply to this specification as well. The Link-Layer 3099 security is needed in particular to prevent Denial-Of-Service attacks 3100 whereby a rogue router creates a high churn in the RPL network by 3101 constantly injected forged P-DAO messages and using up all the 3102 available storage in the attacked routers. 3104 With this specification, only the Root may generate P-DAO messages. 3105 PDR messages may only be sent to the Root. This specification 3106 expects that the communication with the Root is authenticated but 3107 does enforce which method is used. 3109 Additionally, the trust model could include a role validation (e.g., 3110 using a role-based authorization) to ensure that the node that claims 3111 to be a RPL Root is entitled to do so. That trust should propagate 3112 from Egress to Ingress in the case of a Storing Mode P-DAO. 3114 This specification suggests some validation of the VIO to prevent 3115 basic loops by avoiding that a node appears twice. But that is only 3116 a minimal protection. Arguably, an attacker tha can inject P-DAOs 3117 can reroute any traffic and deplete critical resources such as 3118 spectrum and battery in the LLN rapidly. 3120 11. IANA Considerations 3122 11.1. RPL DODAG Configuration Option Flag 3124 IANA is requested to assign a flag from the "DODAG Configuration 3125 Option Flags for MOP 0..6" [RFC9010] registry as follows: 3127 +---------------+------------------------------+-----------+ 3128 | Bit Number | Capability Description | Reference | 3129 +---------------+------------------------------+-----------+ 3130 | 0 (suggested) | Projected Routes Support (D) | THIS RFC | 3131 +---------------+------------------------------+-----------+ 3133 Table 21: New DODAG Configuration Option Flag 3135 IANA is requested to add [THIS RFC] as a reference for MOP 7 in the 3136 RPL Mode of Operation registry. 3138 11.2. Elective 6LoWPAN Routing Header Type 3140 This document updates the IANA registry titled "Elective 6LoWPAN 3141 Routing Header Type" that was created for [RFC8138] and assigns the 3142 following value: 3144 +===============+=============+===============+ 3145 | Value | Description | Reference | 3146 +===============+=============+===============+ 3147 | 8 (Suggested) | P-RPI-6LoRH | This document | 3148 +---------------+-------------+---------------+ 3150 Table 22: New Elective 6LoWPAN Routing 3151 Header Type 3153 11.3. Critical 6LoWPAN Routing Header Type 3155 This document updates the IANA registry titled "Critical 6LoWPAN 3156 Routing Header Type" that was created for [RFC8138] and assigns the 3157 following value: 3159 +===============+=============+===============+ 3160 | Value | Description | Reference | 3161 +===============+=============+===============+ 3162 | 8 (Suggested) | P-RPI-6LoRH | This document | 3163 +---------------+-------------+---------------+ 3165 Table 23: New Critical 6LoWPAN Routing 3166 Header Type 3168 11.4. Subregistry For The RPL Option Flags 3170 IANA is required to create a subregistry for the 8-bit RPL Option 3171 Flags field, as detailed in Figure 10, under the "Routing Protocol 3172 for Low Power and Lossy Networks (RPL)" registry. The bits are 3173 indexed from 0 (leftmost) to 7. Each bit is Tracked with the 3174 following qualities: 3176 * Bit number (counting from bit 0 as the most significant bit) 3178 * Indication When Set 3180 * Reference 3182 Registration procedure is "Standards Action" [RFC8126]. The initial 3183 allocation is as indicated in Table 27: 3185 +===============+======================+===============+ 3186 | Bit number | Indication When Set | Reference | 3187 +===============+======================+===============+ 3188 | 0 | Down 'O' | [RFC6553] | 3189 +---------------+----------------------+---------------+ 3190 | 1 | Rank-Error (R) | [RFC6553] | 3191 +---------------+----------------------+---------------+ 3192 | 2 | Forwarding-Error (F) | [RFC6553] | 3193 +---------------+----------------------+---------------+ 3194 | 3 (Suggested) | Projected-Route (P) | This document | 3195 +---------------+----------------------+---------------+ 3197 Table 24: Initial PDR Flags 3199 11.5. RPL Control Codes 3201 This document extends the IANA Subregistry created by RFC 6550 for 3202 RPL Control Codes as indicated in Table 25: 3204 +==================+=============================+===============+ 3205 | Code | Description | Reference | 3206 +==================+=============================+===============+ 3207 | 0x09 (Suggested) | Projected DAO Request (PDR) | This document | 3208 +------------------+-----------------------------+---------------+ 3209 | 0x0A (Suggested) | PDR-ACK | This document | 3210 +------------------+-----------------------------+---------------+ 3212 Table 25: New RPL Control Codes 3214 11.6. RPL Control Message Options 3216 This document extends the IANA Subregistry created by RFC 6550 for 3217 RPL Control Message Options as indicated in Table 26: 3219 +==================+=============================+===============+ 3220 | Value | Meaning | Reference | 3221 +==================+=============================+===============+ 3222 | 0x0E (Suggested) | Stateful VIO (SM-VIO) | This document | 3223 +------------------+-----------------------------+---------------+ 3224 | 0x0F (Suggested) | Source-Routed VIO (NSM-VIO) | This document | 3225 +------------------+-----------------------------+---------------+ 3226 | 0x10 (Suggested) | Sibling Information option | This document | 3227 +------------------+-----------------------------+---------------+ 3229 Table 26: RPL Control Message Options 3231 11.7. SubRegistry for the Projected DAO Request Flags 3233 IANA is required to create a registry for the 8-bit Projected DAO 3234 Request (PDR) Flags field. Each bit is Tracked with the following 3235 qualities: 3237 * Bit number (counting from bit 0 as the most significant bit) 3239 * Capability description 3241 * Reference 3243 Registration procedure is "Standards Action" [RFC8126]. The initial 3244 allocation is as indicated in Table 27: 3246 +============+========================+===============+ 3247 | Bit number | Capability description | Reference | 3248 +============+========================+===============+ 3249 | 0 | PDR-ACK request (K) | This document | 3250 +------------+------------------------+---------------+ 3251 | 1 | Requested path should | This document | 3252 | | be redundant (R) | | 3253 +------------+------------------------+---------------+ 3255 Table 27: Initial PDR Flags 3257 11.8. SubRegistry for the PDR-ACK Flags 3259 IANA is required to create an subregistry for the 8-bit PDR-ACK Flags 3260 field. Each bit is Tracked with the following qualities: 3262 * Bit number (counting from bit 0 as the most significant bit) 3264 * Capability description 3266 * Reference 3267 Registration procedure is "Standards Action" [RFC8126]. No bit is 3268 currently defined for the PDR-ACK Flags. 3270 11.9. Subregistry for the PDR-ACK Acceptance Status Values 3272 IANA is requested to create a Subregistry for the PDR-ACK Acceptance 3273 Status values. 3275 * Possible values are 6-bit unsigned integers (0..63). 3277 * Registration procedure is "Standards Action" [RFC8126]. 3279 * Initial allocation is as indicated in Table 28: 3281 +-------+------------------------+---------------+ 3282 | Value | Meaning | Reference | 3283 +-------+------------------------+---------------+ 3284 | 0 | Unqualified Acceptance | This document | 3285 +-------+------------------------+---------------+ 3287 Table 28: Acceptance values of the PDR-ACK Status 3289 11.10. Subregistry for the PDR-ACK Rejection Status Values 3291 IANA is requested to create a Subregistry for the PDR-ACK Rejection 3292 Status values. 3294 * Possible values are 6-bit unsigned integers (0..63). 3296 * Registration procedure is "Standards Action" [RFC8126]. 3298 * Initial allocation is as indicated in Table 29: 3300 +-------+-----------------------+---------------+ 3301 | Value | Meaning | Reference | 3302 +-------+-----------------------+---------------+ 3303 | 0 | Unqualified Rejection | This document | 3304 +-------+-----------------------+---------------+ 3305 | 1 | Transient Failure | This document | 3306 +-------+-----------------------+---------------+ 3308 Table 29: Rejection values of the PDR-ACK Status 3310 11.11. SubRegistry for the Via Information Options Flags 3312 IANA is requested to create a Subregistry for the 5-bit Via 3313 Information Options (Via Information Option) Flags field. Each bit 3314 is Tracked with the following qualities: 3316 * Bit number (counting from bit 0 as the most significant bit) 3318 * Capability description 3320 * Reference 3322 Registration procedure is "Standards Action" [RFC8126]. No bit is 3323 currently defined for the Via Information Options (Via Information 3324 Option) Flags. 3326 11.12. SubRegistry for the Sibling Information Option Flags 3328 IANA is required to create a registry for the 5-bit Sibling 3329 Information Option (SIO) Flags field. Each bit is Tracked with the 3330 following qualities: 3332 * Bit number (counting from bit 0 as the most significant bit) 3334 * Capability description 3336 * Reference 3338 Registration procedure is "Standards Action" [RFC8126]. The initial 3339 allocation is as indicated in Table 30: 3341 +===============+========================+===========+ 3342 | Bit number | Capability description | Reference | 3343 +===============+========================+===========+ 3344 | 0 (Suggested) | "S" flag: Sibling in | This | 3345 | | same DODAG as Self | document | 3346 +---------------+------------------------+-----------+ 3348 Table 30: Initial SIO Flags 3350 11.13. destination Advertisement Object Flag 3352 This document modifies the "destination Advertisement Object (DAO) 3353 Flags" registry initially created in Section 20.11 of [RPL] . 3355 Section 4.1.1 also defines one new entry in the Registry as follows: 3357 +---------------+------------------------+-----------+ 3358 | Bit Number | Capability Description | Reference | 3359 +---------------+------------------------+-----------+ 3360 | 2 (Suggested) | Projected DAO (P) | THIS RFC | 3361 +---------------+------------------------+-----------+ 3363 Table 31: New destination Advertisement Object 3364 (DAO) Flag 3366 11.14. New ICMPv6 Error Code 3368 In some cases RPL will return an ICMPv6 error message when a message 3369 cannot be forwarded along a P-Route. 3371 IANA has defined an ICMPv6 "Code" Fields Registry for ICMPv6 Message 3372 Types. ICMPv6 Message Type 1 describes "destination Unreachable" 3373 codes. This specification requires that a new code is allocated from 3374 the ICMPv6 Code Fields Registry for ICMPv6 Message Type 1, for "Error 3375 in P-Route", with a suggested code value of 8, to be confirmed by 3376 IANA. 3378 11.15. RPL Rejection Status values 3380 This specification updates the Subregistry for the "RPL Rejection 3381 Status" values under the RPL registry, as follows: 3383 +---------------+-------------------------+-----------+ 3384 | Value | Meaning | Reference | 3385 +---------------+-------------------------+-----------+ 3386 | 2 (Suggested) | Out of Resources | THIS RFC | 3387 +---------------+-------------------------+-----------+ 3388 | 3 (Suggested) | Error in VIO | THIS RFC | 3389 +---------------+-------------------------+-----------+ 3390 | 4 (Suggested) | Predecessor Unreachable | THIS RFC | 3391 +---------------+-------------------------+-----------+ 3392 | 5 (Suggested) | Unreachable Target | THIS RFC | 3393 +---------------+-------------------------+-----------+ 3394 | 6..63 | Unassigned | | 3395 +---------------+-------------------------+-----------+ 3397 Table 32: Rejection values of the RPL Status 3399 12. Acknowledgments 3401 The authors wish to acknowledge JP Vasseur, Remy Liubing, James 3402 Pylakutty, and Patrick Wetterwald for their contributions to the 3403 ideas developed here. Many thanks to Dominique Barthel and SVR Anand 3404 for their global contribution to 6TiSCH, RAW and this document, as 3405 well as text suggestions that were incorporated, and to Michael 3406 Richardson for his useful recommendations based on his global view of 3407 the system. Also special thanks Toerless Eckert for his deep review, 3408 with many excellent suggestions that improved the readability and 3409 well as the content of the specification. 3411 13. Normative References 3413 [INT-ARCHI] 3414 Braden, R., Ed., "Requirements for Internet Hosts - 3415 Communication Layers", STD 3, RFC 1122, 3416 DOI 10.17487/RFC1122, October 1989, 3417 . 3419 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3420 Requirement Levels", BCP 14, RFC 2119, 3421 DOI 10.17487/RFC2119, March 1997, 3422 . 3424 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 3425 Control Message Protocol (ICMPv6) for the Internet 3426 Protocol Version 6 (IPv6) Specification", STD 89, 3427 RFC 4443, DOI 10.17487/RFC4443, March 2006, 3428 . 3430 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 3431 Computation Element (PCE)-Based Architecture", RFC 4655, 3432 DOI 10.17487/RFC4655, August 2006, 3433 . 3435 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 3436 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 3437 DOI 10.17487/RFC5440, March 2009, 3438 . 3440 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 3441 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 3442 DOI 10.17487/RFC6282, September 2011, 3443 . 3445 [RPL] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 3446 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 3447 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 3448 Low-Power and Lossy Networks", RFC 6550, 3449 DOI 10.17487/RFC6550, March 2012, 3450 . 3452 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 3453 Power and Lossy Networks (RPL) Option for Carrying RPL 3454 Information in Data-Plane Datagrams", RFC 6553, 3455 DOI 10.17487/RFC6553, March 2012, 3456 . 3458 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 3459 Routing Header for Source Routes with the Routing Protocol 3460 for Low-Power and Lossy Networks (RPL)", RFC 6554, 3461 DOI 10.17487/RFC6554, March 2012, 3462 . 3464 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3465 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 3466 May 2017, . 3468 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 3469 Writing an IANA Considerations Section in RFCs", BCP 26, 3470 RFC 8126, DOI 10.17487/RFC8126, June 2017, 3471 . 3473 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 3474 "IPv6 over Low-Power Wireless Personal Area Network 3475 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 3476 April 2017, . 3478 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 3479 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 3480 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 3481 . 3483 14. Informative References 3485 [6LoWPAN] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 3486 "Transmission of IPv6 Packets over IEEE 802.15.4 3487 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 3488 . 3490 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 3491 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 3492 2014, . 3494 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and 3495 J. Martocci, "Reactive Discovery of Point-to-Point Routes 3496 in Low-Power and Lossy Networks", RFC 6997, 3497 DOI 10.17487/RFC6997, August 2013, 3498 . 3500 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 3501 and M. Richardson, Ed., "A Security Threat Analysis for 3502 the Routing Protocol for Low-Power and Lossy Networks 3503 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 3504 . 3506 [6TiSCH-ARCHI] 3507 Thubert, P., Ed., "An Architecture for IPv6 over the Time- 3508 Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)", 3509 RFC 9030, DOI 10.17487/RFC9030, May 2021, 3510 . 3512 [RAW-ARCHI] 3513 Thubert, P., Papadopoulos, G. Z., and L. Berger, "Reliable 3514 and Available Wireless Architecture/Framework", Work in 3515 Progress, Internet-Draft, draft-ietf-raw-architecture-01, 3516 28 July 2021, . 3519 [USE-CASES] 3520 Papadopoulos, G. Z., Thubert, P., Theoleyre, F., and C. J. 3521 Bernardos, "RAW use cases", Work in Progress, Internet- 3522 Draft, draft-ietf-raw-use-cases-03, 20 October 2021, 3523 . 3526 [TURN-ON_RFC8138] 3527 Thubert, P., Ed. and L. Zhao, "A Routing Protocol for Low- 3528 Power and Lossy Networks (RPL) Destination-Oriented 3529 Directed Acyclic Graph (DODAG) Configuration Option for 3530 the 6LoWPAN Routing Header", RFC 9035, 3531 DOI 10.17487/RFC9035, April 2021, 3532 . 3534 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 3535 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 3536 RFC 8025, DOI 10.17487/RFC8025, November 2016, 3537 . 3539 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 3540 Perkins, "Registration Extensions for IPv6 over Low-Power 3541 Wireless Personal Area Network (6LoWPAN) Neighbor 3542 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 3543 . 3545 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 3546 Decraene, B., Litkowski, S., and R. Shakir, "Segment 3547 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 3548 July 2018, . 3550 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 3551 "Deterministic Networking Architecture", RFC 8655, 3552 DOI 10.17487/RFC8655, October 2019, 3553 . 3555 [RFC8930] Watteyne, T., Ed., Thubert, P., Ed., and C. Bormann, "On 3556 Forwarding 6LoWPAN Fragments over a Multi-Hop IPv6 3557 Network", RFC 8930, DOI 10.17487/RFC8930, November 2020, 3558 . 3560 [RFC8931] Thubert, P., Ed., "IPv6 over Low-Power Wireless Personal 3561 Area Network (6LoWPAN) Selective Fragment Recovery", 3562 RFC 8931, DOI 10.17487/RFC8931, November 2020, 3563 . 3565 [RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An 3566 Autonomic Control Plane (ACP)", RFC 8994, 3567 DOI 10.17487/RFC8994, May 2021, 3568 . 3570 [RFC9008] Robles, M.I., Richardson, M., and P. Thubert, "Using RPI 3571 Option Type, Routing Header for Source Routes, and IPv6- 3572 in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008, 3573 DOI 10.17487/RFC9008, April 2021, 3574 . 3576 [RFC9010] Thubert, P., Ed. and M. Richardson, "Routing for RPL 3577 (Routing Protocol for Low-Power and Lossy Networks) 3578 Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021, 3579 . 3581 [I-D.irtf-panrg-path-properties] 3582 Enghardt, T. and C. Kraehenbuehl, "A Vocabulary of Path 3583 Properties", Work in Progress, Internet-Draft, draft-irtf- 3584 panrg-path-properties-04, 25 October 2021, 3585 . 3588 [PCE] IETF, "Path Computation Element", 3589 . 3591 Authors' Addresses 3593 Pascal Thubert (editor) 3594 Cisco Systems, Inc 3595 Building D 3596 45 Allee des Ormes - BP1200 3597 06254 Mougins - Sophia Antipolis 3598 France 3600 Phone: +33 497 23 26 34 3601 Email: pthubert@cisco.com 3603 Rahul Arvind Jadhav 3604 Huawei Tech 3605 Kundalahalli Village, Whitefield, 3606 Bangalore 560037 3607 Karnataka 3608 India 3610 Phone: +91-080-49160700 3611 Email: rahul.ietf@gmail.com 3613 Matthew Gillmore 3614 Itron, Inc 3615 Building D 3616 2111 N Molter Road 3617 Liberty Lake, 99019 3618 United States 3620 Phone: +1.800.635.5461 3621 Email: matthew.gillmore@itron.com