idnits 2.17.1 draft-ietf-roll-dao-projection-20.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1087 has weird spacing: '...-- Node z-- ...' == Line 1094 has weird spacing: '... Node z-- ...' -- The document date (21 September 2021) is 945 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) ** Downref: Normative reference to an Informational RFC: RFC 4655 ** Downref: Normative reference to an Informational RFC: RFC 5551 == Outdated reference: A later version (-17) exists of draft-ietf-raw-architecture-01 == Outdated reference: A later version (-11) exists of draft-ietf-raw-use-cases-02 == Outdated reference: A later version (-08) exists of draft-irtf-panrg-path-properties-03 Summary: 2 errors (**), 0 flaws (~~), 7 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: 25 March 2022 Huawei Tech 6 M. Gillmore 7 Itron 8 21 September 2021 10 Root initiated routing state in RPL 11 draft-ietf-roll-dao-projection-20 13 Abstract 15 This document extends RFC 6550, RFC 6553,and RFC 8138 to enable a RPL 16 Root to install and maintain Projected Routes within its DODAG, along 17 a selected set of nodes that may or may not include self, for a 18 chosen duration. This potentially enables routes that are more 19 optimized or resilient than those obtained with the classical 20 distributed operation of RPL, either in terms of the size of a 21 Routing Header or in terms of path length, which impacts both the 22 latency and the packet delivery ratio. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 25 March 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 Simplified BSD License text 52 as described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 60 2.2. References . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.4. Domain Terms . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Context and Goal . . . . . . . . . . . . . . . . . . . . . . 6 64 3.1. RPL Applicability . . . . . . . . . . . . . . . . . . . . 7 65 3.2. RPL Routing Modes . . . . . . . . . . . . . . . . . . . . 8 66 3.3. On Tracks . . . . . . . . . . . . . . . . . . . . . . . . 9 67 3.4. Serial Track Signaling . . . . . . . . . . . . . . . . . 10 68 3.4.1. Using Storing Mode Segments . . . . . . . . . . . . . 11 69 3.4.2. Using Non-Storing Mode joining Tracks . . . . . . . . 17 70 3.5. Complex Tracks . . . . . . . . . . . . . . . . . . . . . 24 71 3.6. Scope and Expectations . . . . . . . . . . . . . . . . . 26 72 4. Extending existing RFCs . . . . . . . . . . . . . . . . . . . 28 73 4.1. Extending RFC 6550 . . . . . . . . . . . . . . . . . . . 28 74 4.1.1. Projected DAO . . . . . . . . . . . . . . . . . . . . 28 75 4.1.2. Via Information Option . . . . . . . . . . . . . . . 30 76 4.1.3. Sibling Information Option . . . . . . . . . . . . . 30 77 4.1.4. P-DAO Request . . . . . . . . . . . . . . . . . . . . 30 78 4.1.5. Extending the RPI . . . . . . . . . . . . . . . . . . 30 79 4.2. Extending RFC 6553 . . . . . . . . . . . . . . . . . . . 31 80 4.3. Extending RFC 8138 . . . . . . . . . . . . . . . . . . . 32 81 5. New RPL Control Messages and Options . . . . . . . . . . . . 33 82 5.1. New P-DAO Request Control Message . . . . . . . . . . . . 33 83 5.2. New PDR-ACK Control Message . . . . . . . . . . . . . . . 34 84 5.3. Via Information Options . . . . . . . . . . . . . . . . . 36 85 5.4. Sibling Information Option . . . . . . . . . . . . . . . 39 86 6. Root Initiated Routing State . . . . . . . . . . . . . . . . 41 87 6.1. Requesting a Track . . . . . . . . . . . . . . . . . . . 41 88 6.2. Identifying a Track . . . . . . . . . . . . . . . . . . . 42 89 6.3. Installing a Track . . . . . . . . . . . . . . . . . . . 43 90 6.3.1. Signaling a Projected Route . . . . . . . . . . . . . 44 91 6.3.2. Installing a Track Segment with a Storing Mode 92 P-Route . . . . . . . . . . . . . . . . . . . . . . . 45 93 6.3.3. Installing a Track Leg with a Non-Storing Mode 94 P-Route . . . . . . . . . . . . . . . . . . . . . . . 47 95 6.4. Tearing Down a P-Route . . . . . . . . . . . . . . . . . 49 96 6.5. Maintaining a Track . . . . . . . . . . . . . . . . . . . 49 97 6.5.1. Maintaining a Track Segment . . . . . . . . . . . . . 50 98 6.5.2. Maintaining a Track Leg . . . . . . . . . . . . . . . 50 99 6.6. Encapsulating and Forwarding Along a Track . . . . . . . 51 100 6.7. Compression of the RPL Artifacts . . . . . . . . . . . . 53 101 7. Lesser Constrained Variations . . . . . . . . . . . . . . . . 55 102 7.1. Storing Mode Main DODAG . . . . . . . . . . . . . . . . . 55 103 7.2. A Track as a Full DODAG . . . . . . . . . . . . . . . . . 57 104 8. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 58 105 9. Security Considerations . . . . . . . . . . . . . . . . . . . 60 106 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60 107 10.1. New Elective 6LoWPAN Routing Header Type . . . . . . . . 61 108 10.2. New Critical 6LoWPAN Routing Header Type . . . . . . . . 61 109 10.3. New Subregistry For The RPL Option Flags . . . . . . . . 61 110 10.4. New RPL Control Codes . . . . . . . . . . . . . . . . . 62 111 10.5. New RPL Control Message Options . . . . . . . . . . . . 62 112 10.6. SubRegistry for the Projected DAO Request Flags . . . . 63 113 10.7. SubRegistry for the PDR-ACK Flags . . . . . . . . . . . 63 114 10.8. Subregistry for the PDR-ACK Acceptance Status Values . . 63 115 10.9. Subregistry for the PDR-ACK Rejection Status Values . . 64 116 10.10. SubRegistry for the Via Information Options Flags . . . 64 117 10.11. SubRegistry for the Sibling Information Option Flags . . 65 118 10.12. New destination Advertisement Object Flag . . . . . . . 65 119 10.13. New ICMPv6 Error Code . . . . . . . . . . . . . . . . . 65 120 10.14. New RPL Rejection Status values . . . . . . . . . . . . 66 121 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 66 122 12. Normative References . . . . . . . . . . . . . . . . . . . . 66 123 13. Informative References . . . . . . . . . . . . . . . . . . . 68 124 Appendix A. Applications . . . . . . . . . . . . . . . . . . . . 70 125 A.1. Loose Source Routing . . . . . . . . . . . . . . . . . . 70 126 A.2. East-West Routes . . . . . . . . . . . . . . . . . . . . 72 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73 129 1. Introduction 131 RPL, the "Routing Protocol for Low Power and Lossy Networks" [RPL] 132 (LLNs), is an anisotropic Distance Vector protocol that is well- 133 suited for application in a variety of low energy Internet of Things 134 (IoT) networks where stretched P2P paths are acceptable vs. the 135 signaling and state overhead involved in maintaining shortest paths 136 across. 138 RPL forms destination Oriented Directed Acyclic Graphs (DODAGs) in 139 which the Root often acts as the Border router to connect the RPL 140 domain to the IP backbone and routes along that graph up, towards the 141 Root, and down towards the nodes. 143 With this specification, a Path Computation Element [PCE] in an 144 external controller interacts with the RPL Root to compute centrally 145 shorter Peer to Peer (P2P) paths within a pre-existing RPL Main 146 DODAG. The topological information that is passed to the PCE is 147 derived from the DODAG that is already available at the Root in RPL 148 Non-Storing Mode. This specification introduces protocol extensions 149 that enrich the topological information that is available at the Root 150 and passed to the PCE. 152 Based on usage, path length, and knowledge of available resources 153 such as battery levels and reservable buffers in the nodes, the PCE 154 with a global visibility on the system can optimize the computed 155 routes for the application needs, including the capability to provide 156 path redundancy. This specification also introduces protocol 157 extensions that enable the Root to translates the computed paths into 158 RPL and install them as Projected Routes (aka P-Routes) inside the 159 DODAG on behalf of a PCE. 161 2. Terminology 163 2.1. Requirements Language 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 167 "OPTIONAL" in this document are to be interpreted as described in BCP 168 14 [RFC2119][RFC8174] when, and only when, they appear in all 169 capitals, as shown here. 171 2.2. References 173 In this document, readers will encounter terms and concepts that are 174 discussed in the "Routing Protocol for Low Power and Lossy Networks" 175 [RPL], the "6TiSCH Architecture" [6TiSCH-ARCHI], the "Deterministic 176 Networking Architecture" [RFC8655], the "Reliable and Available 177 Wireless (RAW) Architecture/Framework" [RAW-ARCHI], and "Terminology 178 in Low power And Lossy Networks" [RFC7102]. 180 2.3. Glossary 182 This document often uses the following acronyms: 184 CMO: Control Message Option 185 DAO: destination Advertisement Object 186 DAG: Directed Acyclic Graph 187 DODAG: destination-Oriented Directed Acyclic Graph; A DAG with only 188 one vertex (i.e., node) that has no outgoing edge (i.e., link) 189 GUA: IPv6 Global Unicast Address 190 LLN: Low-Power and Lossy Network 191 MOP: RPL Mode of Operation 192 P-DAO: Projected DAO 193 P-Route: Projected Route 194 PDR: P-DAO Request 195 RAN: RPL-Aware Node (either a RPL router or a RPL-Aware Leaf) 196 RAL: RPL-Aware Leaf 197 RH: Routing Header 198 RPI: RPL Packet Information 199 RTO: RPL Target Option 200 RUL: RPL-Unaware Leaf 201 SIO: RPL Sibling Information Option 202 ULA: IPv6 Unique Local Address 203 NSM-VIO: A Source-Routed Via Information Option, used in Non-Storing 204 Mode P-DAO messages. 205 TIO: RPL Transit Information Option 206 SM-VIO: A strict Via Information Option, used in Storing Mode P-DAO 207 messages. 208 VIO: A Via Information Option; it can be a SM-VIO or an NSM-VIO. 210 2.4. Domain Terms 212 Projected Route: A RPL P-Route is a RPL route that is computed 213 remotely by a PCE, and installed and maintained by a RPL Root on 214 behalf of the PCE. It is installed as a state that signals that 215 destinations (aka Targets) are reachable along a sequence of 216 nodes. 217 Projected DAO: A DAO message used to install a P-Route. 218 Path: Quoting section 1.1.3 of [INT-ARCHI]: "At a given moment, all 219 the IP datagrams from a particular source host to a particular 220 destination host will typically traverse the same sequence of 221 gateways. We use the term "path" for this sequence. Note that a 222 path is uni-directional; it is not unusual to have different paths 223 in the two directions between a given host pair.". 224 Section 2 of [I-D.irtf-panrg-path-properties] points to a longer, 225 more modern definition of path, which begins as follows: " A 226 sequence of adjacent path elements over which a packet can be 227 transmitted, starting and ending with a node. A path is 228 unidirectional. Paths are time-dependent, i.e., the sequence of 229 path elements over which packets are sent from one node to another 230 may change. A path is defined between two nodes. " 231 It follows that the general acceptance of a path is a linear 232 sequence of nodes, as opposed to a multi-dimensional graph. In 233 the context of this document, a path is observed by following one 234 copy of a packet that is injected in a Track and possibly 235 replicated within. 236 Track: A networking graph that can be followed to transport packets 237 with equivalent treatment; as opposed to the definition of a path 238 above, a Track Track is not necessarily linear. It may contain 239 multiple paths that may fork and rejoin, and may enable the RAW 240 Packet ARQ, Replication, Elimination, and Overhearing (PAREO) 241 operations. 242 This specification builds Tracks that are DODAGs oriented towards 243 a Track Ingress, and the forward direction for packets is East- 244 West from the Track Ingress to one of the possibly multiple Track 245 Egress Nodes, which is also down the DODAG. 246 The Track may be strictly connected, meaning that the vertices are 247 adjacent, or loosely connected, meaning that the vertices are 248 connected using Segments that are associated to the same Track. 249 TrackID: A RPL Local InstanceID that identifies a Track using the 250 namespace owned ny the Track Ingress. The TrackID is associated 251 with the IPv6 Address of the Track Ingress that is used as 252 DODAGID, and together they form a unique identification of the 253 Track (see the definition of DODAGID in section 2 of [RPL]. 254 Serial Track: A Track that has only one path. 255 Stand-Alone: A single P-DAO that fully defines a Track, e.g., a 256 Serial Track installed with a single Storing Mode Via Information 257 option (SM-VIO). 258 subTrack: A Track within a Track. As the Non-Storing Mode Via 259 Information option (NSM-VIO) can only signal a loose sequence of 260 nodes, it takes a number of them to signal a complex Track. Each 261 NSM-VIO for the same TrackId but a different Segment ID signals a 262 different subTracks that the Track Ingress adds to the topology. 263 Track Leg: An end-to-end East-West serial path that can be a Track 264 by itself or a subTrack of a complex Track. With this 265 specification, a Leg is is installed by the Root of the main DODAG 266 using Non-Storing Mode P-DAO messages, and it is expressed as a 267 loose sequence of nodes that are joined by Track Segments. 268 Track Segment: A serial path formed by a strict sequence of nodes, 269 along which a P-Route is installed. With this specification, a 270 Segment is typically installed by the Root of the main DODAG using 271 Storing Mode P-DAO messages. A Segment used as the topological 272 edge of a Track. Since this specification builds only DODAGs, all 273 Segments are oriented from Ingress (East) to Egress (West), as 274 opposed to the general RAW model, which allows North/South 275 Segments that can be bidirectional. 277 3. Context and Goal 278 3.1. RPL Applicability 280 RPL is optimized for situations where the power is scarce, the 281 bandwidth constrained and the transmissions unreliable. This matches 282 the use case of an IoT LLN where RPL is typically used today, but 283 also situations of high relative mobility between the nodes in the 284 network (aka swarming), e.g., within a variable set of vehicles with 285 a similar global motion, or a toon of drones. 287 To reach this goal, RPL is primarily designed to minimize the control 288 plane activity, that is the relative amount of routing protocol 289 exchanges vs. data traffic, and the amount of state that is 290 maintained in each node. RPL does not need converge, and provides 291 connectivity to most nodes most of the time. 293 RPL may form multiple topologies called instances. Instances can be 294 created to enforce various optimizations through objective functions, 295 or to reach out through different Root Nodes. The concept of 296 objective function allows to adapt the activity of the routing 297 protocol to the use case, e.g., type, speed, and quality of the LLN 298 links. 300 RPL instances operate as ships in the night, unbeknownst of one 301 another. The RPL Root is responsible to select the RPL Instance that 302 is used to forward a packet coming from the Backbone into the RPL 303 domain and set the related RPL information in the packets. 6TiSCH 304 leverages RPL for its distributed routing operations. 306 To reduce the routing exchanges, RPL leverages an anisotropic 307 Distance Vector approach, which does not need a global knowledge of 308 the topology, and only optimizes the routes to and from the RPL Root, 309 allowing P2P paths to be stretched. Although RPL installs its routes 310 proactively, it only maintains them lazily, in reaction to actual 311 traffic, or as a slow background activity. 313 This is simple and efficient in situations where the traffic is 314 mostly directed from or to a central node, such as the control 315 traffic between routers and a controller of a Software Defined 316 Networking (SDN) infrastructure or an Autonomic Control Plane (ACP). 318 But stretch in P2P routing is counter-productive to both reliability 319 and latency as it introduces additional delay and chances of loss. 320 As a result, [RPL] is not a good fit for the use cases listed in the 321 RAW use cases document [USE-CASES], which demand high availability 322 and reliability, and as a consequence require both short and diverse 323 paths. 325 3.2. RPL Routing Modes 327 RPL first forms a default route in each node towards the a Root, and 328 those routes together coalesce as a Directed Acyclic Graph upwards. 329 RPL then constructs routes to so-called Targets in the reverse 330 direction, down the same DODAG. So do so, a RPL Instance can be 331 operated either in RPL Storing or Non-Storing Mode of Operation (MOP) 332 The default route towards the Root is maintained aggressively and may 333 change while a packet progresses without causing loops, so the packet 334 will still reach the Root. 336 In Non-Storing Mode, each node advertises itself as a Target directly 337 to the Root, indicating the parents that may be used to reach self. 338 Recursively, the Root builds and maintains an image of the whole 339 DODAG in memory, and leverages that abstraction to compute source 340 route paths for the packets to their destinations down the DODAG. 341 When a node changes its point(s) of attachment to the DODAG, it takes 342 single unicast packet to the Root along the default route to update 343 it, and the connectivity is restored immediately; this mode is 344 preferable for use cases where internet connectivity is dominant, or 345 when, like here, the Root controls the network activity in the nodes. 347 In Storing Mode, the routing information percolates upwards, and each 348 node maintains the routes to the subDAG of its descendants down the 349 DODAG. The maintenance is lazy, either reactive upon traffic or as a 350 slow background process. Packets flow via the common parent and the 351 routing stretch is reduced vs. Non-Storing, for a better P2P 352 connectivity, while the internet connectivity is restored more 353 slowly, time for the DV operation to operate hop-by-hop. 355 Either way, the RPL routes are injected by the Target nodes, in a 356 distributed fashion. To complement RPL and eliminate routing 357 stretch, this specification introduces an hybrid mode that combines 358 Storing and Non-Storing operations to build and project routes onto 359 the nodes where they should be installed. This specification uses 360 the term P-Route to refer to those routes. 362 A P-Route may be installed in either Storing and Non-Storing Mode, 363 potentially resulting in hybrid situations where the Mode of the P- 364 Route is different from that of the RPL Main DODAG. P-Routes can be 365 used as stand-alone segments to reduce the size of the source routing 366 headers with loose source routing operations down the main RPL DODAG. 367 P-Routes can also be combined with other P-Routes to form a more 368 complex forwarding graph called a Track. 370 3.3. On Tracks 372 A Track is typically a collection of parallel loose source routed 373 sequences of nodes from Ingress to Egress, forming so-called Track 374 Legs, that are joined with strict Segments of other nodes. The Legs 375 are expressed in RPL Non-Storing Modes and require an encapsulation 376 to add a Source Route Header, whereas the Segments are expressed in 377 Storing Mode. 379 A Serial Track comprises provides only one path between Ingress and 380 Egress. It comprises at most one Leg. A Stand-Alone Segment defines 381 implicitly a Serial Track from its Ingress to Egress. 383 A complex Track forms a graph that provides a collection of potential 384 paths to provide redundancy for the packets, either as a collection 385 of Legs that may be parallel or cross at certain points, or as a more 386 generic DODAG. 388 The concept of a Track was introduced in the "6TiSCH Architecture" 389 [6TiSCH-ARCHI], as a collection of potential paths that leverage 390 redundant forwarding solutions along the way. With this 391 specification, a Track forms DODAG that is directed towards a Track 392 Ingress. If there is a single Track Egress, then the Track is 393 reversible to form another DODAG by reversing the direction of each 394 edge. A node at the Ingress of more than one Segment in a Track may 395 use one or more of these Segments to forward a packet inside the 396 Track. 398 Section 5.1. of [RPL] describes the RPL Instance and its encoding. 399 There can be up to 128 global RPL Instances, for which there can be 400 one or more DODAGs, and there can be 64 local RPL Instances, with a 401 namespace that is indexed by a DODAGID, where the DODAGID is a Unique 402 Local Address (ULA) or a Global Unicast Address (GUA) of the Root of 403 the DODAG. 405 A Track is normally associated with a Local RPL Instance which 406 RPLInstanceID is used as the TrackID, more in Section 6.2. A Track 407 Leg may also be used as a subTrack that extends the RPL main DODAG. 408 In that case, the TrackID is set to the global RPLInstanceID of the 409 main DODAG, which suffices to identify the routing topology. As 410 opposed to local RPL instances, the Track Ingress that encapsulates 411 the packets over a subtrack is not Root, and that the source address 412 of the encapsulated packet is not used to determine the Track. 414 A P-DAO message for a Track signals the TrackID in the RPLInstanceID 415 field. In the case of a local RPL Instance, the address of the Track 416 Ingress to be used as source to encapsulated packets along the Track 417 is signaled in the DODAGID field of the Projected DAO Base Object; 418 that field is elided in the case of the RPL Main DODAG, see Figure 3. 420 3.4. Serial Track Signaling 422 This specification introduces the concept of a P-Route along either a 423 Track Leg or a Segment. A P-Route is installed and maintained using 424 an extended RPL DAO message called a Projected DAO (P-DAO), and a 425 Track is composed of the combination of one or more P-Routes. This 426 specification introduces the Via Information Option (VIO) to signal a 427 sequence of hops in a Leg or a Segment in the P-DAO messages, either 428 in Storing Mode (SM-VIO) or NON-Storing Mode (NSM-VIO). One P-DAO 429 messages contains a single VIO, associated to one or more RPL Target 430 Options that signal the destination IPv6 addresses that can reached 431 along the Track. 433 Before diving deeper into Track Legs and Segments signaling and 434 operation, this section provides examples of what how route 435 projection works through variations of a simple example. In this 436 simple example we show host routes though RPL Targets can be 437 prefixes. Say we want to build a Serial Track from node A to E in 438 Figure 1, so A can route packets to E's neighbors F and G along A, B, 439 C, D and E as opposed to via the Root: 441 /===> F 442 A ===> B ===> C ===> D===> E < 443 \===> G 445 Figure 1: Reference Track 447 Conventionally we use ==> to represent a strict hop and --> for a 448 loose hop. We use -to- like in C==>D==>E-to-F to represent coma- 449 separated Targets, e.g., F is a Target for Segment C==>D==>E. In 450 this example, A is Track Ingress, E is Track Egress. C is a 451 stitching point. F and G are "external" Targets for the Track, and 452 become reachable from A via the Track A(ingress) to E (Egress and 453 implicit Target in Non-Storing Mode) leading to F and G (explicit 454 Targets). 456 In a general manner the desired outcome is as follows: 458 * Targets are E, F, and G 460 * P-DAO 1 signals C==>D==>E 461 * P-DAO 2 signals A==>B==>C 463 * P-DAO 3 signals F and G via the A-->E Track 465 P-DAO 3 may be ommitted if P-DAO 1 and 2 signal F and G as Targets. 467 Loose sequences of hops must be expressed in Non-Storing Mode, so 468 P-DAO 3 contains a NSM-VIO. With this specification, the DODAGID to 469 be used by the Ingress as source address is signaled if needed in the 470 DAO base object, the via list starts at the first loose hop and 471 matches the source route header, and the Egress of a Non-Storing Mode 472 P-DAO is an implicit Target that is not listed in the RTO. 474 3.4.1. Using Storing Mode Segments 476 A==>B==>C and C==>D==>E are segments of a same Track. Note that the 477 Storing Mode signaling imposes strict continuity in a segment, since 478 the P-DAO is passed hop by hop, as a classical DAO is, along the 479 reverse datapath that it signals. One benefit of strict routing is 480 that loops are avoided along the Track. 482 3.4.1.1. Stitched Segments 484 In this formulation: 486 * P-DAO 1 signals C==>D==>E-to-F,G 488 * P-DAO 2 signals A==>B==>C-to-F,G 490 Storing Mode P-DAO 1 is sent to E and when it is succesfully 491 acknowledged, Storing Mode P-DAO 2 is sent to C, as follows: 493 +====================+==============+==============+ 494 | Field | P-DAO 1 to E | P-DAO 2 to C | 495 +====================+==============+==============+ 496 | Mode | Storing | Storing | 497 +--------------------+--------------+--------------+ 498 | Track Ingress | A | A | 499 +--------------------+--------------+--------------+ 500 | (DODAGID, TrackID) | (A, 129) | (A, 129) | 501 +--------------------+--------------+--------------+ 502 | SegmentID | 1 | 2 | 503 +--------------------+--------------+--------------+ 504 | VIO | C, D, E | A, B, C | 505 +--------------------+--------------+--------------+ 506 | Targets | F, G | F, G | 507 +--------------------+--------------+--------------+ 509 Table 1: P-DAO Messages 511 As a result the RIBs are set as follows: 513 +======+=============+=========+=============+==========+ 514 | Node | destination | Origin | Next Hop(s) | TrackID | 515 +======+=============+=========+=============+==========+ 516 | E | F, G | P-DAO 1 | Neighbor | (A, 129) | 517 +------+-------------+---------+-------------+----------+ 518 | D | E | P-DAO 1 | Neighbor | (A, 129) | 519 +------+-------------+---------+-------------+----------+ 520 | " | F, G | P-DAO 1 | E | (A, 129) | 521 +------+-------------+---------+-------------+----------+ 522 | C | D | P-DAO 1 | Neighbor | (A, 129) | 523 +------+-------------+---------+-------------+----------+ 524 | " | F, G | P-DAO 1 | D | (A, 129) | 525 +------+-------------+---------+-------------+----------+ 526 | B | C | P-DAO 2 | Neighbor | (A, 129) | 527 +------+-------------+---------+-------------+----------+ 528 | " | F, G | P-DAO 2 | C | (A, 129) | 529 +------+-------------+---------+-------------+----------+ 530 | A | B | P-DAO 2 | Neighbor | (A, 129) | 531 +------+-------------+---------+-------------+----------+ 532 | " | F, G | P-DAO 2 | B | (A, 129) | 533 +------+-------------+---------+-------------+----------+ 535 Table 2: RIB setting 537 Packets originated by A to F or G do not require an encapsulation as 538 the RPI can be placed in the native header chain. For packets that 539 it routes, A must encapsulate to add the RPI that signals the 540 trackID; the outer headers of the packets that are forwarded along 541 the Track have the following settings: 543 +========+===================+===================+================+ 544 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 545 +========+===================+===================+================+ 546 | Outer | A | F or G | (A, 129) | 547 +--------+-------------------+-------------------+----------------+ 548 | Inner | X != A | F or G | N/A | 549 +--------+-------------------+-------------------+----------------+ 551 Table 3: Packet Header Settings 553 As an example, say that A has a packet for F. Using the RIB above: 555 * From P-DAO 2: A forwards to B and B forwards to C. 557 * From P-DAO 1: C forwards to D and D forwards to E. 559 * From Neighbor Cache Entry: C delivers the packet to F. 561 3.4.1.2. External routes 563 In this example, we consider F and G as destinations that are 564 external to the Track as a DODAG, as discussed in section 4.1.1. of 565 [RFC9008]. We then apply the directives for encapsulating in that 566 case, more in Section 6.6. 568 In this formulation, we set up the Track Leg explicitly, which 569 creates less routing state in intermediate hops at the expense of 570 larger packets to accommodate source routing: 572 * P-DAO 1 signals C==>D==>E-to-E 574 * P-DAO 2 signals A==>B==>C-to-E 576 * P-DAO 3 signals F and G via the A-->E-to-F,G Track 578 Storing Mode P-DAO 1 and 2, and Non-Storing Mode P-DAO 3, are sent to 579 E, C and A, respectively, as follows: 581 +====================+==============+==============+==============+ 582 | | P-DAO 1 to E | P-DAO 2 to C | P-DAO 3 to A | 583 +====================+==============+==============+==============+ 584 | Mode | Storing | Storing | Non-Storing | 585 +--------------------+--------------+--------------+--------------+ 586 | Track Ingress | A | A | A | 587 +--------------------+--------------+--------------+--------------+ 588 | (DODAGID, TrackID) | (A, 129) | (A, 129) | (A, 129) | 589 +--------------------+--------------+--------------+--------------+ 590 | SegmentID | 1 | 2 | 3 | 591 +--------------------+--------------+--------------+--------------+ 592 | VIO | C, D, E | A, B, C | E | 593 +--------------------+--------------+--------------+--------------+ 594 | Targets | E | E | F, G | 595 +--------------------+--------------+--------------+--------------+ 597 Table 4: P-DAO Messages 599 Note in the above that E is not an implicit Target in Storing mode, 600 so it must be added in the RTO. 602 As a result the RIBs are set as follows: 604 +======+=============+=========+=============+==========+ 605 | Node | destination | Origin | Next Hop(s) | TrackID | 606 +======+=============+=========+=============+==========+ 607 | E | F, G | P-DAO 1 | Neighbor | (A, 129) | 608 +------+-------------+---------+-------------+----------+ 609 | D | E | P-DAO 1 | Neighbor | (A, 129) | 610 +------+-------------+---------+-------------+----------+ 611 | C | D | P-DAO 1 | Neighbor | (A, 129) | 612 +------+-------------+---------+-------------+----------+ 613 | " | E | P-DAO 1 | D | (A, 129) | 614 +------+-------------+---------+-------------+----------+ 615 | B | C | P-DAO 2 | Neighbor | (A, 129) | 616 +------+-------------+---------+-------------+----------+ 617 | " | E | P-DAO 2 | C | (A, 129) | 618 +------+-------------+---------+-------------+----------+ 619 | A | B | P-DAO 2 | Neighbor | (A, 129) | 620 +------+-------------+---------+-------------+----------+ 621 | " | E | P-DAO 2 | B | (A, 129) | 622 +------+-------------+---------+-------------+----------+ 623 | " | F, G | P-DAO 3 | E | (A, 129) | 624 +------+-------------+---------+-------------+----------+ 626 Table 5: RIB setting 628 Packets from A to E do not require an encapsulation. The outer 629 headers of the packets that are forwarded along the Track have the 630 following settings: 632 +========+===================+====================+================+ 633 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 634 +========+===================+====================+================+ 635 | Outer | A | E | (A, 129) | 636 +--------+-------------------+--------------------+----------------+ 637 | Inner | X | E (X != A), F or G | N/A | 638 +--------+-------------------+--------------------+----------------+ 640 Table 6: Packet Header Settings 642 As an example, say that A has a packet for F. Using the RIB above: 644 * From P-DAO 3: A encapsulates the packet the Track signaled by 645 P-DAO 3, with the outer header above. Now the packet destination 646 is E. 648 * From P-DAO 2: A forwards to B and B forwards to C. 650 * From P-DAO 1: C forwards to D and D forwards to E; E decapsulates 651 the packet. 653 * From Neighbor Cache Entry: C delivers packets to F or G. 655 3.4.1.3. Segment Routing 657 In this formulation leverages Track Legs to combine Segments and form 658 a Graph. The packets are source routed from a Segment to the next to 659 adapt the path. As such, this can be seen as a form of Segment 660 Routing [RFC8402]: 662 * P-DAO 1 signals C==>D==>E-to-E 664 * P-DAO 2 signals A==>B-to-B,C 666 * P-DAO 3 signals F and G via the A-->C-->E-to-F,G Track 668 Storing Mode P-DAO 1 and 2, and Non-Storing Mode P-DAO 3, are sent to 669 E, B and A, respectively, as follows: 671 +====================+==============+==============+==============+ 672 | | P-DAO 1 to E | P-DAO 2 to B | P-DAO 3 to A | 673 +====================+==============+==============+==============+ 674 | Mode | Storing | Storing | Non-Storing | 675 +--------------------+--------------+--------------+--------------+ 676 | Track Ingress | A | A | A | 677 +--------------------+--------------+--------------+--------------+ 678 | (DODAGID, TrackID) | (A, 129) | (A, 129) | (A, 129) | 679 +--------------------+--------------+--------------+--------------+ 680 | SegmentID | 1 | 2 | 3 | 681 +--------------------+--------------+--------------+--------------+ 682 | VIO | C, D, E | A, B | C, E | 683 +--------------------+--------------+--------------+--------------+ 684 | Targets | E | C | F, G | 685 +--------------------+--------------+--------------+--------------+ 687 Table 7: P-DAO Messages 689 Note in the above that the Segment can terminate at the loose hop as 690 used in the example of P-DAO 1 or at the previous hop as done with 691 P-DAO 2. Both methods are possible on any Segment joined by a loose 692 Track Leg. P-DAO 1 generates more signaling since E is the Segment 693 Egress when D could be, but has the benefit that it validates that 694 the connectivity between D and E still exists. 696 As a result the RIBs are set as follows: 698 +======+=============+=========+=============+==========+ 699 | Node | destination | Origin | Next Hop(s) | TrackID | 700 +======+=============+=========+=============+==========+ 701 | E | F, G | P-DAO 1 | Neighbor | (A, 129) | 702 +------+-------------+---------+-------------+----------+ 703 | D | E | P-DAO 1 | Neighbor | (A, 129) | 704 +------+-------------+---------+-------------+----------+ 705 | C | D | P-DAO 1 | Neighbor | (A, 129) | 706 +------+-------------+---------+-------------+----------+ 707 | " | E | P-DAO 1 | D | (A, 129) | 708 +------+-------------+---------+-------------+----------+ 709 | B | C | P-DAO 2 | Neighbor | (A, 129) | 710 +------+-------------+---------+-------------+----------+ 711 | A | B | P-DAO 2 | Neighbor | (A, 129) | 712 +------+-------------+---------+-------------+----------+ 713 | " | C | P-DAO 2 | B | (A, 129) | 714 +------+-------------+---------+-------------+----------+ 715 | " | E, F, G | P-DAO 3 | C, E | (A, 129) | 716 +------+-------------+---------+-------------+----------+ 718 Table 8: RIB setting 720 Packets originated at A to E do not require an encapsulation, but 721 carry a SRH via C. The outer headers of the packets that are 722 forwarded along the Track have the following settings: 724 +========+===================+====================+================+ 725 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 726 +========+===================+====================+================+ 727 | Outer | A | C till C then E | (A, 129) | 728 +--------+-------------------+--------------------+----------------+ 729 | Inner | X | E (X != A), F or G | N/A | 730 +--------+-------------------+--------------------+----------------+ 732 Table 9: Packet Header Settings 734 As an example, say that A has a packet for F. Using the RIB above: 736 * From P-DAO 3: A encapsulates the packet the Track signaled by 737 P-DAO 3, with the outer header above. Now the destination in the 738 IPv6 Header is C, and a SRH signals the final destination is E. 740 * From P-DAO 2: A forwards to B and B forwards to C. 742 * From P-DAO 3: C processes the SRH and sets the destination in the 743 IPv6 Header to E. 745 * From P-DAO 1: C forwards to D and D forwards to E; E decapsulates 746 the packet. 748 * From the Neighbor Cache Entry: C delivers packets to F or G. 750 3.4.2. Using Non-Storing Mode joining Tracks 752 In this formulation: 754 * P-DAO 1 signals C==>D==>E-to-F,G 756 * P-DAO 2 signals A==>B==>C-to-C,F,G 758 A==>B==>C and C==>D==>E are Tracks expressed as Non-Storing P-DAOs. 760 3.4.2.1. Stitched Tracks 762 Non-Storing Mode P-DAO 1 and 2 are sent to C and A respectively, as 763 follows: 765 +====================+==============+==============+ 766 | | P-DAO 1 to C | P-DAO 2 to A | 767 +====================+==============+==============+ 768 | Mode | Non-Storing | Non-Storing | 769 +--------------------+--------------+--------------+ 770 | Track Ingress | C | A | 771 +--------------------+--------------+--------------+ 772 | (DODAGID, TrackID) | (C, 131) | (A, 131) | 773 +--------------------+--------------+--------------+ 774 | SegmentID | 1 | 1 | 775 +--------------------+--------------+--------------+ 776 | VIO | D, E | B, C | 777 +--------------------+--------------+--------------+ 778 | Targets | F, G | E, F, G | 779 +--------------------+--------------+--------------+ 781 Table 10: P-DAO Messages 783 As a result the RIBs are set as follows: 785 +======+=============+=========+=============+==========+ 786 | Node | destination | Origin | Next Hop(s) | TrackID | 787 +======+=============+=========+=============+==========+ 788 | E | F, G | ND | Neighbor | Any | 789 +------+-------------+---------+-------------+----------+ 790 | D | E | ND | Neighbor | Any | 791 +------+-------------+---------+-------------+----------+ 792 | C | D | ND | Neighbor | Any | 793 +------+-------------+---------+-------------+----------+ 794 | " | E, F, G | P-DAO 1 | D, E | (C, 131) | 795 +------+-------------+---------+-------------+----------+ 796 | B | C | ND | Neighbor | Any | 797 +------+-------------+---------+-------------+----------+ 798 | A | B | ND | Neighbor | Any | 799 +------+-------------+---------+-------------+----------+ 800 | " | C, E, F, G | P-DAO 2 | B, C | (A, 131) | 801 +------+-------------+---------+-------------+----------+ 803 Table 11: RIB setting 805 Packets originated at A to E, F and G do not require an 806 encapsulation, though it is preferred that A encapsulates and C 807 decapsulates. Either way, they carry a SRH via B and C, and C needs 808 to encapsulate to E, F, or G to add an SRH via D and E. The 809 encapsulating headers of packets that are forwarded along the Track 810 between C and E have the following settings: 812 +========+===================+===================+================+ 813 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 814 +========+===================+===================+================+ 815 | Outer | C | D till D then E | (C, 131) | 816 +--------+-------------------+-------------------+----------------+ 817 | Inner | X | E, F, or G | N/A | 818 +--------+-------------------+-------------------+----------------+ 820 Table 12: Packet Header Settings between C and E 822 As an example, say that A has a packet for F. Using the RIB above: 824 * From P-DAO 2: A encapsulates the packet with destination of F in 825 the Track signaled by P-DAO 2. The outer header has source A, 826 destination B, an SRH that indicates C as the next loose hop, and 827 a RPI indicating a TrackId of 131 from A's namespace, which is 828 distinct from TrackId of 131 from C's. 830 * From the SRH: Packets forwarded by B have source A, destination C, 831 a consumed SRH, and a RPI indicating a TrackId of 131 from A's 832 namespace. C decapsulates. 834 * From P-DAO 1: C encapsulates the packet with destination of F in 835 the Track signaled by P-DAO 1. The outer header has source C, 836 destination D, an SRH that indicates E as the next loose hop, and 837 a RPI indicating a TrackId of 131 from C's namespace. E 838 decapsulates. 840 3.4.2.2. External routes 842 In this formulation: 844 * P-DAO 1 signals C==>D==>E-to-E 846 * P-DAO 2 signals A==>B==>C-to-C,E 848 * P-DAO 3 signals F and G via the A-->E-to-F,G Track 850 Non-Storing Mode P-DAO 1 is sent to C and Non-Storing Mode P-DAO 2 851 and 3 are sent A, as follows: 853 +====================+==============+==============+==============+ 854 | | P-DAO 1 to C | P-DAO 2 to A | P-DAO 3 to A | 855 +====================+==============+==============+==============+ 856 | Mode | Non-Storing | Non-Storing | Non-Storing | 857 +--------------------+--------------+--------------+--------------+ 858 | Track Ingress | C | A | A | 859 +--------------------+--------------+--------------+--------------+ 860 | (DODAGID, TrackID) | (C, 131) | (A, 129) | (A, 141) | 861 +--------------------+--------------+--------------+--------------+ 862 | SegmentID | 1 | 1 | 1 | 863 +--------------------+--------------+--------------+--------------+ 864 | VIO | D, E | B, C | E | 865 +--------------------+--------------+--------------+--------------+ 866 | Targets | E | E | F, G | 867 +--------------------+--------------+--------------+--------------+ 869 Table 13: P-DAO Messages 871 As a result the RIBs are set as follows: 873 +======+=============+=========+=============+==========+ 874 | Node | destination | Origin | Next Hop(s) | TrackID | 875 +======+=============+=========+=============+==========+ 876 | E | F, G | ND | Neighbor | Any | 877 +------+-------------+---------+-------------+----------+ 878 | D | E | ND | Neighbor | Any | 879 +------+-------------+---------+-------------+----------+ 880 | C | D | ND | Neighbor | Any | 881 +------+-------------+---------+-------------+----------+ 882 | " | E | P-DAO 1 | D, E | (C, 131) | 883 +------+-------------+---------+-------------+----------+ 884 | B | C | ND | Neighbor | Any | 885 +------+-------------+---------+-------------+----------+ 886 | A | B | ND | Neighbor | Any | 887 +------+-------------+---------+-------------+----------+ 888 | " | C, E | P-DAO 2 | B, C | (A, 129) | 889 +------+-------------+---------+-------------+----------+ 890 | " | F, G | P-DAO 3 | E | (A, 141) | 891 +------+-------------+---------+-------------+----------+ 893 Table 14: RIB setting 895 The encapsulating headers of packets that are forwarded along the 896 Track between C and E have the following settings: 898 +========+===================+===================+================+ 899 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 900 +========+===================+===================+================+ 901 | Outer | C | D till D then E | (C, 131) | 902 +--------+-------------------+-------------------+----------------+ 903 | Middle | A | E | (A, 141) | 904 +--------+-------------------+-------------------+----------------+ 905 | Inner | X | E, F or G | N/A | 906 +--------+-------------------+-------------------+----------------+ 908 Table 15: Packet Header Settings 910 As an example, say that A has a packet for F. Using the RIB above: 912 * From P-DAO 3: A encapsulates the packet with destination of F in 913 the Track signaled by P-DAO 3. The outer header has source A, 914 destination E, and a RPI indicating a TrackId of 141 from A's 915 namespace. This recurses with: 917 * From P-DAO 2: A encapsulates the packet with destination of E in 918 the Track signaled by P-DAO 2. The outer header has source A, 919 destination B, an SRH that indicates C as the next loose hop, and 920 a RPI indicating a TrackId of 129 from A's namespace. 922 * From the SRH: Packets forwarded by B have source A, destination C 923 , a consumed SRH, and a RPI indicating a TrackId of 129 from A's 924 namespace. C decapsulates. 926 * From P-DAO 1: C encapsulates the packet with destination of E in 927 the Track signaled by P-DAO 1. The outer header has source C, 928 destination D, an SRH that indicates E as the next loose hop, and 929 a RPI indicating a TrackId of 131 from C's namespace. E 930 decapsulates. 932 3.4.2.3. Segment Routing 934 In this formulation: 936 * P-DAO 1 signals C==>D==>E-to-E 938 * P-DAO 2 signals A==>B-to-C 940 * P-DAO 3 signals F and G via the A-->C-->E-to-F,G Track 942 Non-Storing Mode P-DAO 1 is sent to C and Non-Storing Mode P-DAO 2 943 and 3 are sent A, as follows: 945 +====================+==============+==============+==============+ 946 | | P-DAO 1 to C | P-DAO 2 to A | P-DAO 3 to A | 947 +====================+==============+==============+==============+ 948 | Mode | Non-Storing | Non-Storing | Non-Storing | 949 +--------------------+--------------+--------------+--------------+ 950 | Track Ingress | C | A | A | 951 +--------------------+--------------+--------------+--------------+ 952 | (DODAGID, TrackID) | (C, 131) | (A, 129) | (A, 141) | 953 +--------------------+--------------+--------------+--------------+ 954 | SegmentID | 1 | 1 | 1 | 955 +--------------------+--------------+--------------+--------------+ 956 | VIO | D, E | B | C, E | 957 +--------------------+--------------+--------------+--------------+ 958 | Targets | | C | F, G | 959 +--------------------+--------------+--------------+--------------+ 961 Table 16: P-DAO Messages 963 As a result the RIBs are set as follows: 965 +======+=============+=========+=============+==========+ 966 | Node | destination | Origin | Next Hop(s) | TrackID | 967 +======+=============+=========+=============+==========+ 968 | E | F, G | ND | Neighbor | Any | 969 +------+-------------+---------+-------------+----------+ 970 | D | E | ND | Neighbor | Any | 971 +------+-------------+---------+-------------+----------+ 972 | C | D | ND | Neighbor | Any | 973 +------+-------------+---------+-------------+----------+ 974 | " | E | P-DAO 1 | D, E | (C, 131) | 975 +------+-------------+---------+-------------+----------+ 976 | B | C | ND | Neighbor | Any | 977 +------+-------------+---------+-------------+----------+ 978 | A | B | ND | Neighbor | Any | 979 +------+-------------+---------+-------------+----------+ 980 | " | C | P-DAO 2 | B, C | (A, 129) | 981 +------+-------------+---------+-------------+----------+ 982 | " | E, F, G | P-DAO 3 | C, E | (A, 141) | 983 +------+-------------+---------+-------------+----------+ 985 Table 17: RIB setting 987 The encapsulating headers of packets that are forwarded along the 988 Track between A and B have the following settings: 990 +========+===================+===================+================+ 991 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 992 +========+===================+===================+================+ 993 | Outer | A | B till D then E | (A, 129) | 994 +--------+-------------------+-------------------+----------------+ 995 | Middle | A | C | (A, 141) | 996 +--------+-------------------+-------------------+----------------+ 997 | Inner | X | E, F or G | N/A | 998 +--------+-------------------+-------------------+----------------+ 1000 Table 18: Packet Header Settings 1002 The encapsulating headers of packets that are forwarded along the 1003 Track between B and C have the following settings: 1005 +========+===================+===================+================+ 1006 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1007 +========+===================+===================+================+ 1008 | Outer | A | C | (A, 141) | 1009 +--------+-------------------+-------------------+----------------+ 1010 | Inner | X | E, F or G | N/A | 1011 +--------+-------------------+-------------------+----------------+ 1013 Table 19: Packet Header Settings 1015 The encapsulating headers of packets that are forwarded along the 1016 Track between C and E have the following settings: 1018 +========+===================+===================+================+ 1019 | Header | IPv6 Source Addr. | IPv6 Dest. Addr. | TrackID in RPI | 1020 +========+===================+===================+================+ 1021 | Outer | C | D till D then E | (C, 131) | 1022 +--------+-------------------+-------------------+----------------+ 1023 | Middle | A | E | (A, 141) | 1024 +--------+-------------------+-------------------+----------------+ 1025 | Inner | X | E, F or G | N/A | 1026 +--------+-------------------+-------------------+----------------+ 1028 Table 20: Packet Header Settings 1030 As an example, say that A has a packet for F. Using the RIB above: 1032 * From P-DAO 3: A encapsulates the packet with destination of F in 1033 the Track signaled by P-DAO 3. The outer header has source A, 1034 destination C, an SRH that indicates E as the next loose hop, and 1035 a RPI indicating a TrackId of 141 from A's namespace. This 1036 recurses with: 1038 * From P-DAO 2: A encapsulates the packet with destination of C in 1039 the Track signaled by P-DAO 2. The outer header has source A, 1040 destination B, and a RPI indicating a TrackId of 129 from A's 1041 namespace. B decapsulates forwards to C based on a sibling 1042 connected route. 1044 * From the SRH: C consumes the SRH and makes the destination E. 1046 * From P-DAO 1: C encapsulates the packet with destination of E in 1047 the Track signaled by P-DAO 1. The outer header has source C, 1048 destination D, an SRH that indicates E as the next loose hop, and 1049 a RPI indicating a TrackId of 131 from C's namespace. E 1050 decapsulates. 1052 3.5. Complex Tracks 1054 To increase the reliability of the P2P transmission, this 1055 specification enables to build a collection of Legs between the same 1056 Ingress and Egress Nodes and combine them with the same TrackID, as 1057 shown in Figure 2. Legs may cross at loose hops edges or remain 1058 parallel. 1060 The Segments that join the loose hops of a Leg are installed with the 1061 same TrackID as the Leg. But each individual Leg and Segment has its 1062 own P-RouteID which allows to manage it separately. When Legs cross 1063 within respsective Segment, the next loose hop (the current 1064 destination of the packet) indicates which Leg is being followed and 1065 a Segment that can reach that next loose hop is selected. 1067 CPF CPF CPF CPF 1069 Southbound API 1071 _-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._- 1072 _-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._- 1074 +----------+ 1075 | RPL Root | 1076 +----------+ 1077 ( ) 1078 ( ) 1079 ( DODAG ) 1080 ( ) 1081 ( ) 1082 ) 1083 <- Leg 1 B, E -> 1084 <--- Segment 1 A,B ---> <------- Segment 2 C,D,E -------> 1086 FWD --z Relay --z FWD --z FWD Target 1 1087 z-- Node z-- Node z-- Node z-- Node --z / 1088 --z (A) (B) \ (C) (D) z-- / 1089 Track \ Track 1090 Ingress Segment 5 Egress - Tgt 2 1091 (I) \ (E) 1092 --z \ z-- \ 1093 z-- FWD --z FWD --z Relay --z FWD --z \ 1094 Node z-- Node z-- Node z-- Node Target 3 1095 (F) (G) (H) (J) 1097 <------ Segment 3 F,G,H ------> <---- Segment 4 J,E ----> 1098 <- Leg 2 H, E -> 1100 <--- Segment 1 A,B ---> <- S5-> <---- Segment 4 J,E ----> 1101 <- Leg 3 B, H, E -> 1102 ) 1103 ( 1104 ( ) 1106 Figure 2: Segments and Tracks 1108 Note that while this specification enables to build both Segments 1109 inside a Leg (aka East-West), such as Segment 2 above which is within 1110 Leg 1, and Inter-Leg Segments (aka North-South), such as Segment 2 1111 above which joins Leg 1 and Leg 2, it does not signal to the Ingress 1112 which Inter-Leg Segments are available, so the use of North-South 1113 Segments and associated PAREO functions is curently limited. The 1114 only possibility available at this time is to define overlapping Legs 1115 as illustrated in Figure 2, with Leg 3 that is congruent with Leg 1 1116 till node B and congruent with Leg 2 from node H on, abstracting 1117 Segment 5 as an East-West Segment. 1119 DetNet Forwarding Nodes only understand the simple 1-to-1 forwarding 1120 sublayer transport operation along a segment whereas the more 1121 sophisticated Relay nodes can also provide service sublayer functions 1122 such as Replication and Elimination. One possible mapping between 1123 DetNet and this specification is to signal the Relay Nodes as the 1124 hops of a Leg and the forwarding Nodes as the hops in a Segment that 1125 join the Relay nodes as illustrated in Figure 2. 1127 3.6. Scope and Expectations 1129 This specification expects that the RPL Main DODAG is operated in RPL 1130 Non-Storing Mode to sustain the exchanges with the Root. Based on 1131 its comprehensive knowledge of the parent-child relationship, the 1132 Root can form an abstracted view of the whole DODAG topology. This 1133 document adds the capability for nodes to advertise additional 1134 sibling information to complement the topological awareness of the 1135 Root to be passed on to the PCE, and enable the PCE to build more / 1136 better paths that traverse those siblings. 1138 P-Routes require resources such as routing table space in the routers 1139 and bandwidth on the links; the amount of state that is installed in 1140 each node must be computed to fit within the node's memory, and the 1141 amount of rerouted traffic must fit within the capabilities of the 1142 transmission links. The methods used to learn the node capabilities 1143 and the resources that are available in the devices and in the 1144 network are out of scope for this document. The method to capture 1145 and report the LLN link capacity and reliability statistics are also 1146 out of scope. They may be fetched from the nodes through network 1147 management functions or other forms of telemetry such as OAM. 1149 The "6TiSCH Architecture" [6TiSCH-ARCHI] leverages a centralized 1150 model that is similar to that of "Deterministic Networking 1151 Architecture" [RFC8655], whereby the device resources and 1152 capabilities are exposed to an external controller which installs 1153 routing states into the network based on its own objective functions 1154 that reside in that external entity. With DetNet and 6TiSCH, the 1155 component of the controller that is responsible of computing routes 1156 is a PCE. The PCE computes its routes based on its own objective 1157 functions such as described in [RFC4655], and typically controls the 1158 routes using the PCE Protocol (PCEP) by [RFC5551]. While this 1159 specification expects a PCE and while PCEP might effectively be used 1160 between the Root and the PCE, the control protocol between the PCE 1161 and the Root is out of scope. 1163 This specification expects a single PCE with a full view of the 1164 network. Distributing the PCE function for a large network is out of 1165 scope. This specification uses the RPL Root as a proxy to the PCE. 1166 The PCE may be collocated with the Root, or may reside in an external 1167 Controller. In that case, the protocol between the Root and the PCE 1168 is out of scope and abstracted by / mapped to RPL inside the DODAG; 1169 one possibility is for the Root to transmit the RPL DAOs with the 1170 SIOs that detail the parent/child and sibling information. 1172 The algorithm to compute the paths and the protocol used by the PCE 1173 and the metrics and link statistics involved in the computation are 1174 also out of scope. The effectiveness of the route computation by the 1175 PCE depends on the quality of the metrics that are reported from the 1176 RPL network. Which metrics are used and how they are reported is out 1177 of scope, but the expectation is that they are mostly of long-term, 1178 statistical nature, and provide visibility on link throughput, 1179 latency, stability and availability over relatively long periods. 1181 The "Reliable and Available Wireless (RAW) Architecture/Framework" 1182 [RAW-ARCHI] extends the definition of Track, as being composed of 1183 East-West directional segments and North-South bidirectional 1184 segments, to enable additional path diversity, using Packet ARQ, 1185 Replication, Elimination, and Overhearing (PAREO) functions over the 1186 available paths, to provide a dynamic balance between the reliability 1187 and availability requirements of the flows and the need to conserve 1188 energy and spectrum.. This specification prepares for RAW by setting 1189 up the Tracks, but only forms DODAGs, which are composed of 1190 aggregated end-to-end loose source routed Legs, joined by strict 1191 routed Segments, all oriented East-West. 1193 The RAW Architecture defines a dataplane extension of the PCE called 1194 the Path Selection Engine (PSE), that adapts the use of the path 1195 redundancy within a Track to defeat the diverse causes of packet 1196 loss. The PSE controls the forwarding operation of the packets 1197 within a Track This specification can use but does not impose a PSE 1198 and does not provide the policies that wouldselect which packets are 1199 routed through which path within a Track, IOW, how the PSE may use 1200 the path redundancy within the Track. By default, the use of the 1201 available redundancy is limited to simple load balancing, and all the 1202 segments are East-West unidirectional only. 1204 A Track may be set up to reduce the load around the Root, or to 1205 enable urgent traffic to flow more directly. This specification does 1206 not provide the policies that would decide which flows are routed 1207 through which Track. In a Non-Storing Mode RPL Instance, the Main 1208 DODAG provides a default route via the Root, and the Tracks provide 1209 more specific routes to the Track Targets. 1211 4. Extending existing RFCs 1213 4.1. Extending RFC 6550 1215 This specification extends RPL [RPL] to enable the Root to install 1216 East-West routes inside a Main DODAG that is operated as non-Storing 1217 Mode. A Projected DAO (P-DAO) message (see Section 4.1.1) contains a 1218 new Via Information Option that installs a strict or a loose sequence 1219 of hops to form respectively a Track Segment or a Track Leg. A new 1220 P-DAO Request (PDR) message (see Section 5.1) enables a Track Ingress 1221 to request the Track from the Root for which it is the Root and it 1222 owns the address that serves as TrackID, as well as the associated 1223 namespace from which it selects the TrackID. In the context of this 1224 specification, the installed route appears as a more specific route 1225 to the Track Targets, and the Track Ingress routes the packets 1226 towards the Targets via the Track using the longest match as usual. 1228 To ensure that the PDR and P-DAO messages can flow at most times, it 1229 is RECOMMENDED that the nodes involved in a Track mantain multiple 1230 parents in the Main DODAG, advertise them all to the Root, and use 1231 them in turn to retry similar packets. It is also RECOMMENDED that 1232 the Root uses diverse source route paths to retry similar messages ot 1233 the nodes in the Track. 1235 4.1.1. Projected DAO 1237 Section 6 of [RPL] introduces the RPL Control Message Options (CMO), 1238 including the RPL Target Option (RTO) and Transit Information Option 1239 (TIO), which can be placed in RPL messages such as the destination 1240 Advertisement Object (DAO). A DAO message signals routing 1241 information to one or more Targets indicated in RTOs, providing one 1242 hop information at a time in the TIO. A Projected DAO (P-DAO) is a 1243 special DAO message generated by the Root to install a P-Route formed 1244 of multiple hops in its DODAG. This provides a RPL-based method to 1245 install the Tracks as expected by the 6TiSCH Architecture 1246 [6TiSCH-ARCHI] as a collection of multiple P-Routes. 1248 The P-DAO is signaled with a new "Projected DAO" (P) flag, see 1249 Figure 3. The 'P' flag is encoded in bit position 2 (to be confirmed 1250 by IANA) of the Flags field in the DAO Base Object. The Root MUST 1251 set it to 1 in a Projected DAO message. Otherwise it MUST be set to 1252 0. It is set to 0 in Legacy implementations as specified 1253 respectively in Sections 20.11 and 6.4 of [RPL] 1255 The P-DAO is control plane signaling and should not be stuck behind 1256 high traffic levels. The expectation is that the P-DAO message is 1257 sent as high QoS level, above that of data traffic, typically with 1258 the Network Control precedence. 1260 0 1 2 3 1261 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 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 | TrackID |K|D|P| Flags | Reserved | DAOSequence | 1264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1265 | | 1266 + + 1267 | DODAGID field set to the | 1268 + IPv6 Address of the Track Ingress + 1269 | used to source encapsulated packets | 1270 + + 1271 | | 1272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1273 | Option(s)... 1274 +-+-+-+-+-+-+-+-+ 1276 Figure 3: Projected DAO Base Object 1278 New fields: 1280 TrackID: The local or global RPLInstanceID of the DODAG that serves 1281 as Track, more in Section 6.2 1283 P: 1-bit flag (position to be confirmed by IANA). 1285 The 'P' flag is set to 1 by the Root to signal a Projected DAO, 1286 and it is set to 0 otherwise. 1288 In RPL Non-Storing Mode, the TIO and RTO are combined in a DAO 1289 message to inform the DODAG Root of all the edges in the DODAG, which 1290 are formed by the directed parent-child relationships. Options may 1291 be factorized; multiple RTOs may be present to signal a collection of 1292 children that can be reached via the parent(s) indicated in the 1293 TIO(s) that follows the RTOs. This specification generalizes the 1294 case of a parent that can be used to reach a child with that of a 1295 whole Track through which children and siblings of the Track Egress 1296 are reachable. 1298 4.1.2. Via Information Option 1300 New CMOs called the Via Information Options (VIO) are introduced for 1301 use in P-DAO messages as a multihop alternative to the TIO, more in 1302 Section 5.3. One VIO is the stateful Storing Mode VIO (SM-VIO); an 1303 SM-VIO installs a strict hop-by-hop P-Route called a Track Segment. 1304 The other is the Non-Storing Mode VIO (NSM-VIO); the NSM-VIO installs 1305 a loose source-routed P-Route called a Track Leg at the Track 1306 Ingress, which uses that state to encapsulate a packet IPv6_in_IPv6 1307 with a new Routing Header (RH) to the Track Egress, more in 1308 Section 6.6. 1310 A P-DAO contains one or more RTOs to indicate the Target 1311 (destinations) that can be reached via the P-Route, followed by 1312 exactly one VIO that signals the sequence of nodes to be followed, 1313 more in Section 6. There are two modes of operation for the 1314 P-Routes, the Storing Mode and the Non-Storing Mode, see 1315 Section 6.3.2 and Section 6.3.3 respectively for more. 1317 4.1.3. Sibling Information Option 1319 This specification adds another CMO called the Sibling Information 1320 Option (SIO) that is used by a RPL Aware Node (RAN) to advertise a 1321 selection of its candidate neighbors as siblings to the Root, more in 1322 Section 5.4. The SIO is placed in DAO messages that are sent 1323 directly to the Root of the main DODAG. 1325 4.1.4. P-DAO Request 1327 Two new RPL Control Messages are also introduced, to enable a RPL- 1328 Aware Node to request the establishment of a Track between self as 1329 the Track Ingress Node and a Track Egress. The node makes its 1330 request by sending a new P-DAO Request (PDR) Message to the Root. 1331 The Root confirms with a new PDR-ACK message back to the requester 1332 RAN, see Section 5.1 for more. 1334 4.1.5. Extending the RPI 1336 Sending a Packet within a RPL Local Instance requires the presence of 1337 the abstract RPL Packet Information (RPI) described in section 11.2. 1338 of [RPL] in the outer IPv6 Header chain (see [RFC9008]). The RPI 1339 carries a local RPLInstanceID which, in association with either the 1340 source or the destination address in the IPv6 Header, indicates the 1341 RPL Instance that the packet follows. 1343 This specification extends [RPL] to create a new flag that signals 1344 that a packet is forwarded along a P-Route. 1346 Projected-Route 'P': 1-bit flag. It is set to 1 in the RPI that is 1347 added in the encapsulation when a packet is sent over a Track. It 1348 is set to 0 when a packet is forwarded along the main Track, 1349 including when the packet follows a Segment that joins loose hops 1350 of the Main DODAG. The flag is not mutable en-route. 1352 The encoding of the 'P' flag in native format is shown in Section 4.2 1353 while the compressed format is indicated in Section 4.3. 1355 4.2. Extending RFC 6553 1357 "The RPL Option for Carrying RPL Information in Data-Plane Datagrams" 1358 [RFC6553]describes the RPL Option for use among RPL routers to 1359 include the abstract RPL Packet Information (RPI) described in 1360 section 11.2. of [RPL] in data packets. 1362 The RPL Option is commonly referred to as the RPI though the RPI is 1363 really the abstract information that is transported in the RPL 1364 Option. [RFC9008] updated the Option Type from 0x63 to 0x23. 1366 This specification modifies the RPL Option to encode the 'P' flag as 1367 follows: 1369 0 1 2 3 1370 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 1371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1372 | Option Type | Opt Data Len | 1373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1374 |O|R|F|P|0|0|0|0| RPLInstanceID | SenderRank | 1375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1376 | (sub-TLVs) | 1377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1379 Figure 4: Extended RPL Option Format 1381 Option Type: 0x23 or 0x63, see [RFC9008] 1383 Opt Data Len: See [RFC6553] 1385 'O', 'R' and 'F' flags: See [RFC6553]. Those flags MUST be set to 0 1386 by the sender and ignored by the receiver if the 'P' flag is set. 1388 Projected-Route 'P': 1-bit flag as defined in Section 4.1.5. 1390 RPLInstanceID: See [RFC6553]. Indicates the TrackId if the 'P' flag 1391 is set, as discussed in Section 4.1.1. 1393 SenderRank: See [RFC6553]. This field MUST be set to 0 by the 1394 sender and ignored by the receiver if the 'P'flag is set. 1396 4.3. Extending RFC 8138 1398 The 6LoWPAN Routing Header [RFC8138] specification introduces a new 1399 IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) 1400 [RFC6282] dispatch type for use in 6LoWPAN route-over topologies, 1401 which initially covers the needs of RPL data packet compression. 1403 Section 4 of [RFC8138] presents the generic formats of the 6LoWPAN 1404 Routing Header (6LoRH) with two forms, one Elective that can be 1405 ignored and skipped when the router does not understand it, and one 1406 Critical which causes the packet to be dropped when the router cannot 1407 process it. The 'E' Flag in the 6LoRH indicates its form. In order 1408 to skip the Elective 6LoRHs, their format imposes a fixed expression 1409 of the size, whereas the size of a Critical 6LoRH may be signaled in 1410 variable forms to enable additional optimizations. 1412 When the [RFC8138] compression is used, the Root of the Main DODAG 1413 that sets up the Track also constructs the compressed routing header 1414 (SRH-6LoRH) on behalf of the Track Ingress, which saves the 1415 complexities of optimizing the SRH-6LoRH encoding in constrained 1416 code. The SRH-6LoRH is signaled in the NSM-VIO, in a fashion that it 1417 is ready to be placed as is in the packet encapsulation by the Track 1418 Ingress. 1420 Section 6.3 of [RFC8138] presents the formats of the 6LoWPAN Routing 1421 Header of type 5 (RPI-6LoRH) that compresses the RPI for normal RPL 1422 operation. The format of the RPI-6LoRH is not suited for P-Routes 1423 since the O,R,F flags are not used and the Rank is unknown and 1424 ignored. 1426 This specification introduces a new 6LoRH, the P-RPI-6LoRH that can 1427 be used in either Elective or Critical 6LoRH form, see Table 21 and 1428 Table 22 respectively. The new 6LoRH MUST be used as a Critical 1429 6LoRH, unless an SRH-6LoRH is present and controls the routing 1430 decision, in which case it MAY be used in Elective form. 1432 The P-RPI-6LoRH is designed to compress the RPI along RPL P-Routes. 1433 Its format is as follows: 1435 0 1 2 1436 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1438 |1|0|E| Length | 6LoRH Type | RPLInstanceID | 1439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1440 Figure 5: P-RPI-6LoRH Format 1442 Type: IANA is requested to define the same value of the type for 1443 both Elective and Critical forms. A type of 8 is suggested. 1445 Elective 'E': See [RFC8138]. The 'E' flag is set to 1 to indicate 1446 an Elective 6LoRH, meaning that it can be ignored when forwarding. 1448 RPLInstanceID : In the context of this specification, the 1449 RPLInstanceID field signals the TrackID, see Section 3.3 and 1450 Section 6.2 . 1452 Section 6.7 details how a a Track Ingress leverages the P-RPI-6LoRH 1453 Header as part of the encapsulation of a packet to place it into a 1454 Track. 1456 5. New RPL Control Messages and Options 1458 5.1. New P-DAO Request Control Message 1460 The P-DAO Request (PDR) message is sent by a Node in the Main DODAG 1461 to the Root. It is a request to establish or refresh a Track where 1462 this node is Track Ingress, and signals whether an acknowledgment 1463 called PDR-ACK is requested or not. A positive PDR-ACK indicates 1464 that the Track was built and that the Roots commits to maintain the 1465 Track for the negotiated lifetime. 1467 The Root may use an asynchronous PDR-ACK with an negative status to 1468 indicate that the Track was terminated before its time. A status of 1469 "Transient Failure" (see Section 10.9) is an indication that the PDR 1470 may be retried after a reasonable time that depends on the 1471 deployment. Other negative status values indicate a permanent error; 1472 the tentative must be abandoned until a corrective action is taken at 1473 the application layer or through network management. 1475 The source IPv6 address of the PDR signals the Track Ingress to-be of 1476 the requested Track, and the TrackID is indicated in the message 1477 itself. One and only one RPL Target Option MUST be present in the 1478 message. The RTO signals the Track Egress, more in Section 6.1. 1480 The RPL Control Code for the PDR is 0x09, to be confirmed by IANA. 1481 The format of PDR Base Object is as follows: 1483 0 1 2 3 1484 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 1485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1486 | TrackID |K|R| Flags | ReqLifetime | PDRSequence | 1487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1488 | Option(s)... 1489 +-+-+-+-+-+-+-+-+ 1491 Figure 6: New P-DAO Request Format 1493 TrackID: 8-bit field. In the context of this specification, the 1494 TrackID field signals the RPLInstanceID of the DODAG formed by the 1495 Track, see Section 3.3 and Section 6.2. To allocate a new Track, 1496 the Ingress Node must provide a value that is not in use at this 1497 time. 1499 K: The 'K' flag is set to indicate that the recipient is expected to 1500 send a PDR-ACK back. 1502 R: The 'R' flag is set to request a Complex Track for redundancy. 1504 Flags: Reserved. The Flags field MUST initialized to zero by the 1505 sender and MUST be ignored by the receiver 1507 ReqLifetime: 8-bit unsigned integer. The requested lifetime for the 1508 Track expressed in Lifetime Units (obtained from the DODAG 1509 Configuration option). 1511 A PDR with a fresher PDRSequence refreshes the lifetime, and a 1512 PDRLifetime of 0 indicates that the Track should be destroyed, 1513 e.g., when the application that requested the Track terminates. 1515 PDRSequence: 8-bit wrapping sequence number, obeying the operation 1516 in section 7.2 of [RPL]. The PDRSequence is used to correlate a 1517 PDR-ACK message with the PDR message that triggered it. It is 1518 incremented at each PDR message and echoed in the PDR-ACK by the 1519 Root. 1521 5.2. New PDR-ACK Control Message 1523 The new PDR-ACK is sent as a response to a PDR message with the 'K' 1524 flag set. The RPL Control Code for the PDR-ACK is 0x0A, to be 1525 confirmed by IANA. Its format is as follows: 1527 0 1 2 3 1528 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 1529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1530 | TrackID | Flags | Track Lifetime| PDRSequence | 1531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1532 | PDR-ACK Status| Reserved | 1533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1534 | Option(s)... 1535 +-+-+-+-+-+-+-+ 1537 Figure 7: New PDR-ACK Control Message Format 1539 TrackID: Set to the TrackID indicated in the TrackID field of the 1540 PDR messages that this replies to. 1542 Flags: Reserved. The Flags field MUST initialized to zero by the 1543 sender and MUST be ignored by the receiver 1545 Track Lifetime: Indicates that remaining Lifetime for the Track, 1546 expressed in Lifetime Units; the value of zero (0x00) indicates 1547 that the Track was destroyed or not created. 1549 PDRSequence: 8-bit wrapping sequence number. It is incremented at 1550 each PDR message and echoed in the PDR-ACK. 1552 PDR-ACK Status: 8-bit field indicating the completion. The PDR-ACK 1553 Status is substructured as indicated in Figure 8: 1555 0 1 2 3 4 5 6 7 1556 +-+-+-+-+-+-+-+-+ 1557 |E|R| Value | 1558 +-+-+-+-+-+-+-+-+ 1560 Figure 8: PDR-ACK status Format 1562 E: 1-bit flag. Set to indicate a rejection. When not set, the 1563 value of 0 indicates Success/Unqualified Acceptance and other 1564 values indicate "not an outright rejection". 1565 R: 1-bit flag. Reserved, MUST be set to 0 by the sender and 1566 ignored by the receiver. 1567 Status Value: 6-bit unsigned integer. Values depending on the 1568 setting of the 'E' flag, see Table 27 and Table 28. 1570 Reserved: The Reserved field MUST initialized to zero by the sender 1571 and MUST be ignored by the receiver 1573 5.3. Via Information Options 1575 A VIO signals the ordered list of IPv6 Via Addresses that constitutes 1576 the hops of either a Leg (using Non-Storing Mode) a Segment (using 1577 storing mode) of a Track. A Storing Mode P-DAO contains one Storing 1578 Mode VIO (SM-VIO) whereas a Non-Storing Mode P-DAO contains one Non- 1579 Storing Mode VIO (NSM-VIO) 1581 The duration of the validity of a VIO is indicated in a Segment 1582 Lifetime field. A P-DAO message that contains a VIO with a Segment 1583 Lifetime of zero is referred as a No-Path P-DAO. 1585 The VIO contains one or more SRH-6LoRH header(s), each formed of a 1586 SRH-6LoRH head and a collection of compressed Via Addresses, except 1587 in the case of a Non-Storing Mode No-Path P-DAO where the SRH-6LoRH 1588 header is not present. 1590 In the case of a SM-VIO, or if [RFC8138] is not used in the data 1591 packets, then the Root MUST use only one SRH-6LoRH per Via 1592 Information Option, and the compression is the same forall the 1593 addresses, as shown in Figure 9, for simplicity. 1595 In case of an NSM-VIO and if [RFC8138] is in use in the Main DODAG, 1596 the Root SHOULD optimize the size of the NSM-VIO if using different 1597 SRH-6LoRH Types make the VIO globally shorter; this means that more 1598 than one SRH-6LoRH may be present. 1600 The format of the Via Information Options is as follows: 1602 0 1 2 3 1603 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 1604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1605 | Type | Option Length | Flags | P-RouteID | 1606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1607 |Segm. Sequence | Seg. Lifetime | SRH-6LoRH head | 1608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1609 | | 1610 . Via Address 1 (compressed by RFC 8138) . 1611 | | 1612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1613 | | 1614 . .... . 1615 | | 1616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1617 | | 1618 . Via Address n (compressed by RFC 8138) . 1619 | | 1620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1621 | | 1622 . Additional SRH-6LoRH Header(s) . 1623 | | 1624 . .... . 1626 Figure 9: VIO format (uncompressed form) 1628 Option Type: 0x0E for SM-VIO, 0x0F for NSM-VIO (to be confirmed by 1629 IANA), see =Table 25 1631 Option Length: 8-bit unsigned integer, representing the length in 1632 octets of the option, not including the Option Type and Length 1633 fields, see section 6.7.1. of [RPL]; the Option Length is 1634 variable, depending on the number of Via Addresses and the 1635 compression applied. 1637 P-RouteID: 8-bit field that identifies a component of a Track or the 1638 Main DODAG as indicated by the TrackID field. The value of 0 is 1639 used to signal a Serial Track, i.e., made of a single segment/Leg. 1640 In an SM-VIO, the P-RouteID indicates an actual Segment. In an an 1641 NSM-VIO, it indicates a Leg, that is a serial subTrack that is 1642 added to the overall topology of the Track. 1644 Segment Sequence: 8-bit unsigned integer. The Segment Sequence 1645 obeys the operation in section 7.2 of [RPL] and the lollipop 1646 starts at 255. 1648 When the Root of the DODAG needs to refresh or update a Segment in 1649 a Track, it increments the Segment Sequence individually for that 1650 Segment. 1652 The Segment information indicated in the VIO deprecates any state 1653 for the Segment indicated by the P-RouteID within the indicated 1654 Track and sets up the new information. 1656 A VIO with a Segment Sequence that is not as fresh as the current 1657 one is ignored. 1659 A VIO for a given DODAGID with the same (TrackID, P-RouteID, 1660 Segment Sequence) indicates a retry; it MUST NOT change the 1661 Segment and MUST be propagated or answered as the first copy. 1663 Segment Lifetime: 8-bit unsigned integer. The length of time in 1664 Lifetime Units (obtained from the Configuration option) that the 1665 Segment is usable. 1667 The period starts when a new Segment Sequence is seen. The value 1668 of 255 (0xFF) represents infinity. The value of zero (0x00) 1669 indicates a loss of reachability. 1671 SRH-6LoRH head: The first 2 bytes of the (first) SRH-6LoRH as shown 1672 in Figure 6 of [RFC8138]. As an example, a 6LoRH Type of 4 means 1673 that the VIA Addresses are provided in full with no compression. 1675 Via Address: An IPv6 ULA or GUA of a node along the Segment. The 1676 VIO contains one or more IPv6 Via Addresses listed in the datapath 1677 order from Ingress to Egress. The list is expressed in a 1678 compressed form as signaled by the preceding SRH-6LoRH header. 1680 In a Storing Mode P-DAO that updates or removes a section of an 1681 already existing Segment, the list in the SM-VIO may represent 1682 only the section of the Segment that is being updated; at the 1683 extreme, the SM-VIO updates only one node, in which case it 1684 contains only one IPv6 address. In all other cases, the list in 1685 the VIO MUST be complete. 1687 In the case of an SM-VIO, the list indicates a sequential (strict) 1688 path through direct neighbors, the complete list starts at Ingress 1689 and ends at Egress, and the nodes listed in the VIO, including the 1690 Egress, MAY be considered as implicit Targets. 1692 In the case of an NSM-VIO, the complete list can be loose and 1693 excludes the Ingress node, starting at the first loose hop and 1694 ending at a Track Egress; the Track Egress MUST be considered as 1695 an implicit Target, so it MUST NOT be signaled in a RPL Target 1696 Option. 1698 5.4. Sibling Information Option 1700 The Sibling Information Option (SIO) provides indication on siblings 1701 that could be used by the Root to form P-Routes. One or more SIO(s) 1702 may be placed in the DAO messages that are sent to the Root in Non- 1703 Storing Mode. 1705 To advertise a neighbor node, the router MUST have an active Address 1706 Registration from that sibling using [RFC8505], for an address (ULA 1707 or GUA) that serves as identifier for the node. If this router also 1708 registers an address to that sibling, and the link has similar 1709 properties in both directions, only the router with the lowest 1710 Interface ID in its registered address needs report the SIO, and the 1711 Root will assume symmetry. 1713 The format of the SIO is as follows: 1715 0 1 2 3 1716 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 1717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1718 | Type | Option Length |D| Flags |Comp.| Opaque | 1719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1720 | Step of Rank | Reserved | 1721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1722 | | 1723 + + 1724 . . 1725 . Sibling DODAGID (if the D flag not set) . 1726 . . 1727 + + 1728 | | 1729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1730 | | 1731 + + 1732 . . 1733 . Sibling Address . 1734 . . 1735 + + 1736 | | 1737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1739 Figure 10: Sibling Information Option Format 1741 Option Type: 0x10 for SIO (to be confirmed by IANA), see =Table 25 1743 Option Length: 8-bit unsigned integer, representing the length in 1744 octets of the option, not including the Option Type and Length 1745 fields, see section 6.7.1. of [RPL]. 1747 Reserved for Flags: MUST be set to zero by the sender and MUST be 1748 ignored by the receiver. 1750 D: 1-bit flag that is set to indicate that sibling belongs to the 1751 same DODAG. When not set, the Sibling DODAGID is indicated. 1753 Flags: Reserved. The Flags field MUST initialized to zero by the 1754 sender and MUST be ignored by the receiver 1756 Opaque: MAY be used to carry information that the node and the Root 1757 understand, e.g., a particular representation of the Link 1758 properties such as a proprietary Link Quality Information for 1759 packets received from the sibling. An industrial Alliance that 1760 uses RPL for a particular use / environment MAY redefine the use 1761 of this field to fit its needs. 1763 Compression Type: 3-bit unsigned integer. This is the SRH-6LoRH 1764 Type as defined in figure 7 in section 5.1 of [RFC8138] that 1765 corresponds to the compression used for the Sibling Address and 1766 its DODAGID if resent. The Compression reference is the Root of 1767 the Main DODAG. 1769 Step of Rank: 16-bit unsigned integer. This is the Step of Rank 1770 [RPL] as computed by the Objective Function between this node and 1771 the sibling. 1773 Reserved: The Reserved field MUST initialized to zero by the sender 1774 and MUST be ignored by the receiver 1776 Sibling DODAGID: 2 to 16 bytes, the DODAGID of the sibling in a 1777 [RFC8138] compressed form as indicated by the Compression Type 1778 field. This field is present if and only if the D flag is not 1779 set. 1781 Sibling Address: 2 to 16 bytes, an IPv6 Address of the sibling, with 1782 a scope that MUST be make it reachable from the Root, e.g., it 1783 cannot be a Link Local Address. The IPv6 address is encoded in 1784 the [RFC8138] compressed form indicated by the Compression Type 1785 field. 1787 An SIO MAY be immediately followed by a DAG Metric Container. In 1788 that case the DAG Metric Container provides additional metrics for 1789 the hop from the Sibling to this node. 1791 6. Root Initiated Routing State 1793 6.1. Requesting a Track 1795 This specification introduces the PDR message, used by an LLN node to 1796 request the formation of a new Track for which this node is Ingress. 1797 Note that the namespace for the TrackID is owned by the Ingress node, 1798 and in the absence of a PDR, there must be some procedure for the 1799 Root to assign TrackIDs in that namespace while avoiding collisions, 1800 more in Section 6.2. 1802 The PDR signals the desired TrackID and the duration for which the 1803 Track should be established. Upon a PDR, the Root MAY install the 1804 Track as requested, in which case it answers with a PDR-ACK 1805 indicating the granted Track Lifetime. All the Segments MUST be of a 1806 same mode, either Storing or Non-Storing. All the Segments MUST be 1807 created with the same TrackID and the same DODAGID signaled in the 1808 P-DAO. 1810 The Root designs the Track as it sees best, and updates / changes the 1811 Segments overtime to serve the Track as needed. There is no 1812 notification to the requesting node when those changes happen. The 1813 Segment Lifetime in the P-DAO messages does not need to be aligned to 1814 the Requested Lifetime in the PDR, or between P-DAO messages for 1815 different Segments. The Root may use shorter lifetimes for the 1816 Segments and renew them faster than the Track is, or longer lifetimes 1817 in which case it will need to tear down the Segments if the Track is 1818 not renewed. 1820 When the Track Lifetime that was returned in the PDR-ACK is close to 1821 elapse - vs. the trip time from the node to the Root, the requesting 1822 node SHOULD resend a PDR using the TrackID in the PDR-ACK to extend 1823 the lifetime of the Track, else the Track will time out and the Root 1824 will tear down the whole structure. 1826 If the Track fails and cannot be restored, the Root notifies the 1827 requesting node asynchronously with a PDR-ACK with a Track Lifetime 1828 of 0, indicating that the Track has failed, and a PDR-ACK Status 1829 indicating the reason of the fault. 1831 6.2. Identifying a Track 1833 RPL defines the concept of an Instance to signal an individual 1834 routing topology, and multiple topologies can coexist in the same 1835 network. The RPLInstanceID is tagged in the RPI of every packet to 1836 signal which topology the packet actually follows. 1838 This draft leverages the RPL Instance model as follows: 1840 * The Root MAY use P-DAO messages to add better routes in the main 1841 (Global) RPL Instance in conformance with the routing objectives 1842 in that Instance. 1844 To achieve this, the Root MAY install a Segment along a path down 1845 the main Non-Storing Mode DODAG. This enables a loose source 1846 routing and reduces the size of the Routing Header, see 1847 Appendix A.1. The Root MAY also install a Track Leg across the 1848 Main DODAG to complement the routing topology. 1850 When adding a P-Route to the RPL Main DODAG, the Root MUST set the 1851 RPLInstanceID field of the P-DAO Base Object (see section 6.4.1. 1852 of [RPL]) to the RPLInstanceID of the Main DODAG, and MUST NOT use 1853 the DODAGID field. A P-Route provides a longer match to the 1854 Target Address than the default route via the Root, so it is 1855 preferred. 1857 * The Root MAY also use P-DAO messages to install a Track as an 1858 independent routing topology (say, Traffic Engineered) to achieve 1859 particular routing characteristics from an Ingress to an Egress 1860 Endpoints. To achieve this, the Root MUST set up a local RPL 1861 Instance (see section 5 of [RPL]), and the Local RPLInstanceID 1862 serves as TrackID. The TrackID MUST be unique for the IPv6 ULA or 1863 GUA of the Track Ingress that serves as DODAGID for the Track. 1865 This way, a Track is uniquely identified by the tuple (DODAGID, 1866 TrackID) where the TrackID is always represented with the D flag 1867 set to 0 (see also section 5.1. of [RPL]), indicating when used in 1868 an RPI that the source address of the IPv6 packet signals the 1869 DODAGID. 1871 The P-DAO Base Object MUST indicate the tuple (DODAGID, TrackID) 1872 that identifies the Track as shown in Figure 3, and the P-RouteID 1873 that identifies the P-Route MUST be signaled in the VIO as shown 1874 in Figure 9. 1876 The Track Ingress is the root of the DODAG ID formed by the local 1877 RPL Instance. It owns the namespace of its TrackIDs, so it can 1878 pick any unused value to request a new Track with a PDR. In a 1879 particular deployment where PDR are not used, the namespace can be 1880 delegated to the main Root, which can assign the TrackIDs for the 1881 Tracks it creates without collision. 1883 With this specification, the Root is aware of all the active 1884 Tracks, so it can also pick any unused value to form Tracks 1885 without a PDR. To avoid a collision of the Root and the Track 1886 Ingress picking the same value at the same time, it is RECOMMENDED 1887 that the Track Ingress starts allocating the ID value of the Local 1888 RPLInstanceID (see section 5.1. of [RPL]) used as TrackIDs with 1889 the value 0 incrementing, while the Root starts with 63 1890 decrementing. 1892 6.3. Installing a Track 1894 A Serial Track can be installed by a single P-Route that signals the 1895 sequence of consecutive nodes, either in Storing Mode as a single- 1896 Segment Track, or in Non-Storing Mode as a single-Leg Track. A 1897 single-Leg Track can be installed as a loose Non-Storing Mode 1898 P-Route, in which case the next loose entry must recursively be 1899 reached over a Serial Track. 1901 A Complex Track can be installed as a collection of P-Routes with the 1902 same DODAGID and Track ID. The Ingress of a Non-Storing Mode P-Route 1903 is the owner and Root of the DODAGID. The Ingress of a Storing Mode 1904 P-Route must be either the owner of the DODAGID, or a hop of a Leg of 1905 the same Track. In the latter case, the Targets of the P-Route must 1906 include the next hop of the Leg if there is one, to ensure forwarding 1907 continuity. In the case of a Complex Track, each Segment is 1908 maintained independently and asynchronously by the Root, with its own 1909 lifetime that may be shorter, the same, or longer than that of the 1910 Track. 1912 A route along a Track for which the TrackID is not the RPLInstanceID 1913 of the Main DODAG MUST be installed with a higher precedence than the 1914 routes along the Main DODAG, meaning that: 1916 * Longest match MUST be the prime comparison for routing. 1918 * In case of equal length match, the route along the Track MUST be 1919 preferred vs. the one along the Main DODAG. 1921 * There SHOULD NOT be 2 different Tracks leading to the same Target 1922 from same Ingress node, unless there's a policy for selecting 1923 which packets use which Track; such policy is out of scope. 1925 * A packet that was routed along a Track MUST NOT be routed along 1926 the main DODAG again; if the destination is not reachable as a 1927 neighbor by the node where the packet exits the Track then the 1928 packet MUST be dropped. 1930 6.3.1. Signaling a Projected Route 1932 This draft adds a capability whereby the Root of a main RPL DODAG 1933 installs a Track as a collection of P-Routes, using a Projected-DAO 1934 (P-DAO) message for each individual Track Leg or Segment. The P-DAO 1935 signals a collection of Targets in the RPL Target Option(s) (RTO). 1936 Those Targets can be reached via a sequence of routers indicated in a 1937 VIO. 1939 Like a classical DAO message, a P-DAO causes a change of state only 1940 if it is "new" per section 9.2.2. "Generation of DAO Messages" of 1941 the RPL specification [RPL]; this is determined using the Segment 1942 Sequence information from the VIO as opposed to the Path Sequence 1943 from a TIO. Also, a Segment Lifetime of 0 in a VIO indicates that 1944 the P-Route associated to the Segment is to be removed. There are 1945 two Modes of operation for the P-Routes, the Storing and the Non- 1946 Storing Modes. 1948 A P-DAO message MUST be sent from the address of the Root that serves 1949 as DODAGID for the Main DODAG. It MUST contain either exactly one 1950 sequence of one or more RTOs followed one VIO, or any number of 1951 sequences of one or more RTOs followed by one or more TIOs. The 1952 former is the normal expression for this specification, where as the 1953 latter corresponds to the variation for lesser constrained 1954 environments described in Section 7.2. 1956 A P-DAO that creates or updates a Track Leg MUST be sent to a GUA or 1957 a ULA of the Ingress of the Leg; it must contain the full list of 1958 hops in the Leg unless the Leg is being removed. A P-DAO that 1959 creates a new Track Segment MUST be sent to a GUA or a ULA of the 1960 Segment Egress and MUST signal the full list of hops in Segment; a 1961 P-DAO that updates (including deletes) a section of a Segment MUST be 1962 sent to the first node after the modified Segment and signal the full 1963 list of hops in the section starting at the node that immediately 1964 precedes the modified section. 1966 In Non-Storing Mode, as discussed in Section 6.3.3, the Root sends 1967 the P-DAO to the Track Ingress where the source-routing state is 1968 applied, whereas in Storing Mode, the P-DAO is sent to the last node 1969 on the installed path and forwarded in the reverse direction, 1970 installing a Storing Mode state at each hop, as discussed in 1971 Section 6.3.2. In both cases the Track Ingress is the owner of the 1972 Track, and it generates the P-DAO-ACK when the installation is 1973 successful. 1975 If the 'K' Flag is present in the P-DAO, the P-DAO must be 1976 acknowledged using a DAO-ACK that is sent back to the address of the 1977 Root from which the P-DAO was received. In most cases, the first 1978 node of the Leg, Segment, or updated section of the Segment is the 1979 node that sends the acknowledgment. The exception to the rule is 1980 when an intermediate node in a Segment fails to forward a Storing 1981 Mode P-DAO to the previous node in the SM-VIO. 1983 In a No-Path Non-Storing Mode P-DAO, the SRH-6LoRH MUST NOT be 1984 present in the NSM-VIO; the state in the Ingress is erased 1985 regardless. In all other cases, a VIO MUST contain at least one Via 1986 Address, and a Via Address MUST NOT be present more than once, which 1987 would create a loop. 1989 A node that processes a VIO MAY verify whether one of these 1990 conditions happen, and when so, it MUST ignore the P-DAO and reject 1991 it with a RPL Rejection Status of "Error in VIO" in the DAO-ACK, see 1992 Section 10.14. 1994 Other errors than those discussed explicitely that prevent the 1995 installing the route are acknowledged with a RPL Rejection Status of 1996 "Unqualified Rejection" in the DAO-ACK. 1998 6.3.2. Installing a Track Segment with a Storing Mode P-Route 2000 As illustrated in Figure 11, a Storing Mode P-DAO installs a route 2001 along the Segment signaled by the SM-VIO towards the Targets 2002 indicated in the Target Options. The Segment is to be included in a 2003 DODAG indicated by the P-DAO Base Object, that may be the one formed 2004 by the RPL Main DODAG, or a Track associated with a local RPL 2005 Instance. 2007 ------+--------- 2008 | Internet 2009 | 2010 +-----+ 2011 | | Border router 2012 | | (RPL Root) 2013 +-----+ | ^ | 2014 | | DAO | ACK | 2015 o o o o | | | 2016 o o o o o o o o o | ^ | Projected . 2017 o o o o o o o o o o | | DAO | Route . 2018 o o o o o o o o o | ^ | . 2019 o o o o o o o o v | DAO v . 2020 o o LLN o o o | 2021 o o o o o Loose Source Route Path | 2022 o o o o v 2024 Figure 11: Projecting a route 2026 In order to install the relevant routing state along the Segment , 2027 the Root sends a unicast P-DAO message to the Track Egress router of 2028 the routing Segment that is being installed. The P-DAO message 2029 contains a SM-VIO with the strict sequence of Via Addresses. The SM- 2030 VIO follows one or more RTOs indicating the Targets to which the 2031 Track leads. The SM-VIO contains a Segment Lifetime for which the 2032 state is to be maintained. 2034 The Root sends the P-DAO directly to the Egress node of the Segment. 2035 In that P-DAO, the destination IP address matches the last Via 2036 Address in the SM-VIO. This is how the Egress recognizes its role. 2037 In a similar fashion, the Segment Ingress node recognizes its role as 2038 it matches first Via Address in the SM-VIO. 2040 The Egress node of the Segment is the only node in the path that does 2041 not install a route in response to the P-DAO; it is expected to be 2042 already able to route to the Target(s) based on its existing tables. 2043 If one of the Targets is not known, the node MUST answer to the Root 2044 with a DAO-ACK listing the unreachable Target(s) in an RTO and a 2045 rejection status of "Unreachable Target". 2047 If the Egress node can reach all the Targets, then it forwards the 2048 P-DAO with unchanged content to its predecessor in the Segment as 2049 indicated in the list of Via Information options, and recursively the 2050 message is propagated unchanged along the sequence of routers 2051 indicated in the P-DAO, but in the reverse order, from Egress to 2052 Ingress. 2054 The address of the predecessor to be used as destination of the 2055 propagated DAO message is found in the Via Address the precedes the 2056 one that contain the address of the propagating node, which is used 2057 as source of the message. 2059 Upon receiving a propagated DAO, all except the Egress router MUST 2060 install a route towards the DAO Target(s) via their successor in the 2061 SM-VIO. A router that cannot store the routes to all the Targets in 2062 a P-DAO MUST reject the P-DAO by sending a DAO-ACK to the Root with a 2063 Rejection Status of "Out of Resources" as opposed to forwarding the 2064 DAO to its predecessor in the list. The router MAY install 2065 additional routes towards the VIA Addresses that are the SM-VIO after 2066 self, if any, but in case of a conflict or a lack of resource, the 2067 route(s) to the Target(s) are the ones that must be installed in 2068 priority. 2070 If a router cannot reach its predecessor in the SM-VIO, the router 2071 MUST send the DAO-ACK to the Root with a Rejection Status of 2072 "Predecessor Unreachable". 2074 The process continues till the P-DAO is propagated to Ingress router 2075 of the Segment, which answers with a DAO-ACK to the Root. The Root 2076 always expects a DAO-ACK, either from the Track Ingress with a 2077 positive status or from any node along the segment with a negative 2078 status. If the DAO-ACK is not received, the Root may retry the DAO 2079 with the same TID, or tear down the route. 2081 6.3.3. Installing a Track Leg with a Non-Storing Mode P-Route 2083 As illustrated in Figure 12, a Non-Storing Mode P-DAO installs a 2084 source-routed path within the Track indicated by the P-DAO Base 2085 Object, towards the Targets indicated in the Target Options. The 2086 source-routed path requires a Source-Routing header which implies an 2087 IP-in-IP encapsulation to add the SRH to an existing packet. It is 2088 sent to the Track Ingress which creates a tunnel associated with the 2089 Track, and connected routes over the tunnel to the Targets in the 2090 RTO. The tunnel encapsulation MUST incorporate a routing header via 2091 the list addresses listed in the VIO in the same order. The content 2092 of the NSM-VIO starting at the first SRH-6LoRH header MUST be used 2093 verbatim by the Track Ingress when it encapsulates a packet to 2094 forward it over the Track. 2096 ------+--------- 2097 | Internet 2098 | 2099 +-----+ 2100 | | Border router 2101 | | (RPL Root) 2102 +-----+ | P ^ ACK 2103 | Track | DAO | 2104 o o o o Ingress X V | X 2105 o o o o o o o X o X Source 2106 o o o o o o o o X o o X Routed 2107 o o ° o o o o X o X Segment 2108 o o o o o o o o X Egress X 2109 o o o o o | 2110 Target 2111 o o LLN o o 2112 o o o o 2114 Figure 12: Projecting a Non-Storing Route 2116 The next entry in the source-routed path must be either a neighbor of 2117 the previous entry, or reachable as a Target via another P-Route, 2118 either Storing or Non-Storing, which implies that the nested P-Route 2119 has to be installed before the loose sequence is, and that P-Routes 2120 must be installed from the last to the first along the datapath. For 2121 instance, a Segment of a Track must be installed before the Leg(s) of 2122 the same Track that use it, and stitched Segments must be installed 2123 in order from the last that reaches to the Targets to the first. 2125 If the next entry in the loose sequence is reachable over a Storing 2126 Mode P-Route, it MUST be the Target of a Segment and the Ingress of a 2127 next segment, both already setup; the segments are associated with 2128 the same Track, which avoids the need of an additional encapsulation. 2129 For instance, in Section 3.4.1.3, Segments A==>B-to-C and 2130 C==>D==>E-to-F must be installed with Storing Mode P-DAO messages 1 2131 and 2 before the Track A-->C-->E-to-F that joins them can be 2132 installed with Non-Storing Mode P-DAO 3. 2134 Conversely, if it is reachable over a Non-Storing Mode P-Route, the 2135 next loose source-routed hop of the inner Track is a Target of a 2136 previously installed Track and the Ingress of a next Track, which 2137 requires a de- and a re-encapsulation when switching the outer Tracks 2138 that join the loose hops. This is examplified in Section 3.4.2.3 2139 where Non-Storing Mode P-DAO 1 and 2 install strict Tracks that Non- 2140 Storing Mode P-DAO 3 joins as a super Track. In such a case, packets 2141 are subject to double IP-in-IP encapsulation. 2143 6.4. Tearing Down a P-Route 2145 A P-DAO with a lifetime of 0 is interpreted as a No-Path DAO and 2146 results in cleaning up existing state as opposed to refreshing an 2147 existing one or installing a new one. To tear down a Track, the Root 2148 must tear down all the Track Segments and Legs that compose it one by 2149 one. 2151 Since the state about a Leg of a Track is located only the Ingress 2152 Node, the Root cleans up the Leg by sending an NSM-VIO to the Ingress 2153 indicating the TrackID and the P-RouteID of the Leg being removed, a 2154 Segment Lifetime of 0 and a newer Segment Sequence. The SRH-6LoRH 2155 with the Via Addresses in the NSM-VIO are not needed and MUST be 2156 omitted. Upon that NSM-VIO, the Ingress node removes all state for 2157 that Track if any, and replies positively anyway. 2159 The Root cleans up a section of a Segment by sending an SM-VIO to the 2160 last node of the Segment, with the TrackID and the P-RouteID of the 2161 Segment being updated, a Segment Lifetime of zero (0) and a newer 2162 Segment Sequence. The Via Addresses in the SM-VIO indicates the 2163 section of the Segment being modified, from the first to the last 2164 node that is impacted. This can be the whole Segment if it is 2165 totally removed, or a sequence of one or more nodes that have been 2166 bypassed by a Segment update. 2168 The No-Path P-DAO is forwarded normally along the reverse list, even 2169 if the intermediate node does not find a Segment state to clean up. 2170 This results in cleaning up the existing Segment state if any, as 2171 opposed to refreshing an existing one or installing a new one. 2173 6.5. Maintaining a Track 2175 Repathing a Track Segment or Leg may cause jitter and packet 2176 misordering. For critical flows that require timely and/or in-order 2177 delivery, it might be necessary to deploy the PAREO functions 2178 [RAW-ARCHI] over a highly redundant Track.. This specification 2179 allows to use more than one Leg for a Track, and 1+N packet 2180 redundancy. 2182 This section provides the steps to ensure that no packet is lost due 2183 to the operation itself. This is ensured by installing the new 2184 section from its last node to the first, so when an intermediate node 2185 installs a route along the new section, all the downstream nodes in 2186 the section have already installed their own. The disabled section 2187 is removed when the packets in-flight are forwarded along the new 2188 section as well. 2190 6.5.1. Maintaining a Track Segment 2192 To modify a section of a Segment between a first node and a second, 2193 downstream node (which can be the Ingress and Egress), while 2194 conserving those nodes in the Segment, the Root sends an SM-VIO to 2195 the second node indicating the sequence of nodes in the new section 2196 of the Segment. The SM-VIO indicates the TrackID and the P-RouteID 2197 of the Segment being updated, and a newer Segment Sequence. The 2198 P-DAO is propagated from the second to the first node and on the way, 2199 it updates the state on the nodes that are common to the old and the 2200 new section of the Segment and creates a state in the new nodes. 2202 When the state is updated in an intermediate node, that node might 2203 still receive packets that were in flight from the Ingress to self 2204 over the old section of the Segment. Since the remainder of the 2205 Segment is already updated, the packets are forwarded along the new 2206 version of the Segment from that node on. 2208 After a reasonable time to enable the deprecated sections to empty, 2209 the root tears down the remaining section(s) of the old segments are 2210 teared down as described in Section 6.4. 2212 6.5.2. Maintaining a Track Leg 2214 This specification allows to add Legs to a Track by sending a Non- 2215 Storing Mode P-DAO to the Ingress associated to the same TrackID, and 2216 a new Segment ID. If the Leg is loose, then the Segments that join 2217 the hops must be created first. It makes sense to add a new Leg 2218 before removing one that is misbehaving, and switch to the new Leg 2219 before removing the old. 2221 It is also possible to update a Track Leg by sending a Non-Storing 2222 Mode P-DAO to the Ingress with the same Segment ID, an incremented 2223 Segment Sequence, and the new complete listy of hops in the NSM-VIO. 2224 Updating a live Leg means changing one or more of the intermediate 2225 loose hops, and involves laying out new Segments from and to the new 2226 loose hops before the NSM-VIO for the new Leg is issued. 2228 Packets that are in flight over the old version of the Track Leg 2229 still follow the old source route path over the old Segments. After 2230 a reasonable time to enable the deprecated Segments to empty, the 2231 root tears down those Segments as described in Section 6.4. 2233 6.6. Encapsulating and Forwarding Along a Track 2235 When forwarding a packet to a destination for which a router 2236 determines that routing happens via a Track for which it is Ingress, 2237 the router must encapsulated the packet using IP-in-IP to add the 2238 Source Routing Header with the final destination set to the Track 2239 Egress. Though fragmentation is possible in a 6LoWPAN LLN, e.g., 2240 using [6LoWPAN], [RFC8930], and/or [RFC8931], it is RECOMMENDED to 2241 allow an MTU that is larger than 1280 in the main DODAG and allows 2242 for the additional headers while exposing only 1280 to the 6LoWPAN 2243 Nodes as indicated by section 4 of [6LoWPAN]. 2245 All properties of a Track operations are inherited form the main RPL 2246 Instance that is used to install the Track. For instance, the use of 2247 compression per [RFC8138] is determined by whether it is used in the 2248 RPL Main DODAG, e.g., by setting the "T" flag [TURN-ON_RFC8138] in 2249 the RPL configuration option. 2251 The Track Ingress that places a packet in a Track encapsulates it 2252 with an IP-in-IP header, a Routing Header, and an IPv6 Hop-by-Hop 2253 Option Header that contains the RPL Packet Information (RPI) as 2254 follows: 2256 * In the uncompressed form the source of the packet is the address 2257 that this router uses as DODAGID for the Track, the destination is 2258 the first Via Address in the NSM-VIO, and the RH is a Source 2259 Routing Header (SRH) [RFC6554] that contains the list of the 2260 remaining Via Addresses terminating by the Track Egress. 2262 * The preferred alternate in a network where 6LoWPAN Header 2263 Compression [RFC6282] is used is to leverage "IPv6 over Low-Power 2264 Wireless Personal Area Network (6LoWPAN) Paging Dispatch" 2265 [RFC8025] to compress the RPL artifacts as indicated in [RFC8138]. 2267 In that case, the source routed header is the exact copy of the 2268 (chain of) SRH-6LoRH found in the NSM-VIO, also terminating by the 2269 Track Egress. The RPI-6LoRH is appended next, followed by an IP- 2270 in-IP 6LoRH Header that indicates the Ingress router in the 2271 Encapsulator Address field, see as a similar case Figure 20 of 2272 [TURN-ON_RFC8138]. 2274 To signal the Track in the packet, this specification leverages the 2275 RPL Forwarding model follows: 2277 * In the data packets, the Track DODAGID and the TrackID MUST be 2278 respectively signaled as the IPv6 Source Address and the 2279 RPLInstanceID field of the RPI that MUST be placed in the outer 2280 chain of IPv6 Headers. 2282 The RPI carries a local RPLInstanceID called the TrackID, which, 2283 in association with the DODAGID, indicates the Track along which 2284 the packet is forwarded. 2286 The D flag in the RPLInstanceID MUST be set to 0 to indicate that 2287 the source address in the IPv6 header is set ot the DODAGID, more 2288 in Section 6.2. 2290 * This draft conforms to the principles of [RFC9008] with regards to 2291 packet forwarding and encapsulation along a Track, as follows: 2293 - With this draft, the Track is a RPL DODAG. From the 2294 perspective of that DODAG, the Track Ingress is the Root, the 2295 Track Egress is a RPL-Aware 6LR, and neighbors of the Track 2296 Egress that can be reached via the Track, but are external to 2297 it, are external destinations and treated as RPL-Unaware Leaves 2298 (RULs). The encapsulation rules in [RFC9008] apply. 2300 - If the Track Ingress is the originator of the packet and the 2301 Track Egress is the destination of the packet, there is no need 2302 for an encapsulation. 2304 - So the Track Ingress must encapsulate the traffic that it did 2305 not originate, and add an RPI. 2307 A packet that is being routed over the RPL Instance associated to 2308 a first Non-Storing Mode Track MAY be placed (encapsulated) in a 2309 second Track to cover one loose hop of the first Track as 2310 discussed in more details Section 3.4.2.3. On the other hand, a 2311 Storing Mode Track must be strict and a packet that it placed in a 2312 Storing Mode Track MUST follow that Track till the Track Egress. 2314 The forwarding of a packet along a track will fail if the Track 2315 continuity is broken,e.g.: 2317 * In the case of a strict path along a Segment, if the next strict 2318 hop is not reachable, the packet is dropped. 2320 * In the case of a loose source-routed path, when the loose next hop 2321 is not a neighbor, there must be a Segment of the same Track to 2322 that loose next hop. When that is the case the packet is 2323 forwarded to the next hop along that segment, or a common neighbor 2324 with the loose next hop, on which case the packet is forwarded to 2325 that neighbor, or another Track to the loose next hop for which 2326 this node or a neighbor is Ingress; in the last case, another 2327 encapsulation takes place and the process possibly recurses; 2328 otherwise the packet is dropped. 2330 * When a Track Egress extracts a packet from a Track (decapsulates 2331 the packet), the destination of the inner packet must be either 2332 this node or a direct neighbor, or a Target of another Segment of 2333 the same Track for which this node is Ingress, otherwise the 2334 packet MUST be dropped. 2336 In case of a failure forwarding a packet along a Segment, e.g., the 2337 next hop is unreachable, the node that discovers the fault MUST send 2338 an ICMPv6 Error message [RFC4443] to the Root, with a new Code "Error 2339 in P-Route" (See Section 10.13). The Root can then repair by 2340 updating the broken Segment and/or Tracks, and in the case of a 2341 broken Segment, remove the leftover sections of the segment using SM- 2342 VIOs with a lifetime of 0 indicating the section ot one or more nodes 2343 being removed (See Section 6.5). 2345 In case of a permanent forwarding error along a Source Route path, 2346 the node that fails to forward SHOULD send an ICMP error with a code 2347 "Error in Source Routing Header" back to the source of the packet, as 2348 described in section 11.2.2.3. of [RPL]. Upon this message, the 2349 encapsulating node SHOULD stop using the source route path for a 2350 reasonable period of time which duration depends on the deployment, 2351 and it SHOULD send an ICMP message with a Code "Error in P-Route" to 2352 the Root. Failure to follow these steps may result in packet loss 2353 and wasted resources along the source route path that is broken. 2355 Either way, the ICMP message MUST be throttled in case of consecutive 2356 occurrences. It MUST be sourced at the ULA or a GUA that is used in 2357 this Track for the source node, so the Root can establish where the 2358 error happened. 2360 The portion of the invoking packet that is sent back in the ICMP 2361 message SHOULD record at least up to the RH if one is present, and 2362 this hop of the RH SHOULD be consumed by this node so that the 2363 destination in the IPv6 header is the next hop that this node could 2364 not reach. if a 6LoWPAN Routing Header (6LoRH) [RFC8138] is used to 2365 carry the IPv6 routing information in the outer header then that 2366 whole 6LoRH information SHOULD be present in the ICMP message. 2368 6.7. Compression of the RPL Artifacts 2370 When using [RFC8138] in the Main DODAG operated in Non-Storing Mode 2371 in a 6LoWPAN LLN, a typical packet that circulates in the Main DODAG 2372 is formatted as shown in Figure 13, representing the case where : 2374 +-+ ... -+- ... -+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-... 2375 |11110001| SRH- | RPI- | IP-in-IP | NH=1 |11110CPP| UDP | UDP 2376 | Page 1 | 6LoRH | 6LoRH | 6LoRH |LOWPAN_IPHC| UDP | hdr |Payld 2377 +-+ ... -+- ... -+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-... 2378 <= RFC 6282 => 2379 <================ Inner packet ==================== = = 2381 Figure 13: A Packet as Forwarded along the Main DODAG 2383 Since there is no page switch between the encapsulated packet and the 2384 encapsulation, the first octet of the compressed packet that acts as 2385 page selector is actually removed at encapsulation, so the inner 2386 packet used in the descriptions below start with the SRH-6LoRH, and 2387 is verbatim the packet represented in Figure 13 from the second octet 2388 on. 2390 When encapsulating that inner packet to place it in the Track, the 2391 first header that the Ingress appends at the head of the inner packet 2392 is an IP-in-IP 6LoRH Header; in that header, the encapsulator 2393 address, which maps to the IPv6 source address in the uncompressed 2394 form, contains a GUA or ULA IPv6 address of the Ingress node that 2395 serves as DODAG ID for the Track, expressed in the compressed form 2396 and using the DODAGID of the Main DODAG as compression reference. If 2397 the address is compressed to 2 bytes, the resulting value for the 2398 Length field shown in Figure 14 is 3, meaning that the SRH-6LoRH as a 2399 whole is 5-octets long. 2401 0 1 2 2402 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 2404 |1|0|1| Length | 6LoRH Type 6 | Hop Limit | Track DODAGID | 2405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 2407 Figure 14: The IP-in-IP 6LoRH Header 2409 At the head of the resulting sequence of bytes, the track Ingress 2410 then adds the RPI that carries the TrackID as RPLinstanceID as a P- 2411 RPI-6LoRH Header, as illustrated in Figure 5, using the TrackID as 2412 RPLInstanceID. Combined with the IP-in-IP 6LoRH Header, this allows 2413 to identify the Track without ambiguity. 2415 The SRH-6LoRH is then added at the head of the resulting sequence of 2416 bytes as a verbatim copy of the content of the SR-VIO that signaled 2417 the selected Track Leg. 2419 0 1 2420 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 .. .. .. 2421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+ 2422 |1|0|0| Size |6LoRH Type 0..4| Hop1 | Hop2 | | HopN | 2423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+ 2424 Where N = Size + 1 2426 Figure 15: The SRH 6LoRH Header 2428 The format of the resulting encapsulated packet in [RFC8138] 2429 compressed form is illustrated in Figure 16: 2431 +-+ ... -+-+-+- ... -+-+-+- ... -+-+-+-+-+- ... +-+-+-+-+-+-+- ... 2432 | Page 1 | SRH-6LoRH | P-RPI-6LoRH | IP-in-IP 6LoRH | Inner Packet 2433 +-+ ... -+-+-+- ... -+-+-+- ... -+-+-+-+-+- ... +-+-+-+-+-+-+- ... 2435 Signals : Loose Hops : TrackID : Track DODAGID : 2437 Figure 16: A Packet as Forwarded along a Track 2439 7. Lesser Constrained Variations 2441 7.1. Storing Mode Main DODAG 2443 This specification expects that the Main DODAG is operated in Non- 2444 Storing Mode. The reasons for that limitation are mostly related to 2445 LLN operations, power and spectrum conservation: 2447 * In Non-Storing Mode The Root already possesses the DODAG topology, 2448 so the additional topological information is reduced to the 2449 siblings. 2451 * The downwards routes are updated with unicast messages to the 2452 Root, which ensures that the Root can reach back to the LLN nodes 2453 after a repair faster than in the case of Storing Mode. Also the 2454 Root can control the use of the path diversity in the DODAG to 2455 reach to the LLN nodes. For both reasons, Non-Storing Mode 2456 provides better capabilities for the Root to maintain the 2457 P-Routes. 2459 * When the Main DODAG is operated in Non-Storing Mode, P-Routes 2460 enable loose Source Routing, which is only an advantage in that 2461 mode. Storing Mode does not use Source Routing Headers, and does 2462 not derive the same benefits from this capability. 2464 On the other hand, since RPL is a Layer-3 routing protocol, its 2465 applicability extends beyond LLNs to a generic IP network. RPL 2466 requires fewer resources than alternative IGPs like OSPF, ISIS, 2467 EIGRP, BABEL or RIP at the expense of a route stretch vs. the 2468 shortest path routes to a destination that those protocols compute. 2469 P-Routes add the capability to install shortest and/or constrained 2470 routes to special destinations such as discussed in section A.9.4. of 2471 the ANIMA ACP [RFC8994]. 2473 In a powered and wired network, when enough memory to store the 2474 needed routes is available, the RPL Storing Mode proposes a better 2475 trade-off than the Non-Storing, as it reduces the route stretch and 2476 lowers the load on the Root. In that case, the control path between 2477 the Root and the LLN nodes is highly available compared to LLNs, and 2478 the nodes can be reached to maintain the P-Routes at most times. 2480 This section specifies the additions that are needed to support 2481 Projected Routes when the Main DODAG is operated in Storing Mode. As 2482 long as the RPI can be processed adequately by the dataplane, the 2483 changes to this specification are limited to the DAO message. The 2484 Track structure, routes and forwarding operations remain the same. 2486 In Storing Mode, the Root misses the Child to Parent relationship 2487 that forms the Main DODAG, as well as the sibling information. To 2488 provide that knowledge the nodes in the network MUST send additional 2489 DAO messages that are unicast to the Root as Non-Storing DAO messages 2490 are. 2492 In the DAO message, the originating router advertises a set of 2493 neighbor nodes using Sibling Information Options (SIO)s, regardless 2494 of the relative position in the DODAG of the advertised node vs. this 2495 router. 2497 The DAO message MUST be formed as follows: 2499 * The originating router is identified by the source address of the 2500 DAO. That address MUST be the one that this router registers to 2501 neighbor routers so the Root can correlate the DAOs from those 2502 routers when they advertise this router as their neighbor. The 2503 DAO contains one or more sequences of one Transit Information 2504 Option and one or more Sibling Information Options. There is no 2505 RPL Target Option so the Root is not confused into adding a 2506 Storing Mode route to the Target. 2508 * The TIO is formed as in Storing Mode, and the Parent Address is 2509 not present. The Path Sequence and Path Lifetime fields are 2510 aligned with the values used in the Address Registration of the 2511 node(s) advertised in the SIO, as explained in Section 9.1. of 2512 [RFC9010]. Having similar values in all nodes allows to factorise 2513 the TIO for multiple SIOs as done with [RPL]. 2515 * The TIO is followed by one or more SIOs that provide an address 2516 (ULA or GUA) of the advertised neighbor node. 2518 But the RPL routing information headers may not be supported on all 2519 type of routed network infrastructures, especially not in high-speed 2520 routers. When the RPI is not be supported in the dataplane, there 2521 cannot be local RPL Instances and RPL can only operate as a single 2522 topology (the Main DODAG). The RPL Instance is that of the Main 2523 DODAG and the Ingress node that encapsulates is not the Root. The 2524 routes along the Tracks are alternate routes to those available along 2525 the Main DODAG. They MAY conflict with routes to children and MUST 2526 take precedence in the routing table. The Targets MUST be adjacent 2527 to the Track Egress to avoid loops that may form if the packet is 2528 reinjected in the Main DODAG. 2530 7.2. A Track as a Full DODAG 2532 This specification builds parallel or crossing Track Legs as opposed 2533 to a more complex DODAG with interconnections at any place desirable. 2534 The reason for that limitation is related to constrained node 2535 operations, and capability to store large amount of topological 2536 information and compute complex paths: 2538 * With this specification, the node in the LLN has no topological 2539 awareness, and does not need to maintain dynamic information about 2540 the link quality and availability. 2542 * The Root has a complete topological information and statistical 2543 metrics that allow it or its PCE to perform a global optimization 2544 of all Tracks in its DODAG. Based on that information, the Root 2545 computes the Track Leg and predigest the source route paths. 2547 * The node merely selects one of the proposed paths and applies the 2548 associated pre-computed routing header in the encapsulation. This 2549 alleviates both the complexity of computing a path and the 2550 compressed form of the routing header. 2552 The "Reliable and Available Wireless (RAW) Architecture/Framework" 2553 [RAW-ARCHI] actually expects the PSE at the Track Ingress to react to 2554 changes in the forwarding conditions along the Track, and reroute 2555 packets to maintain the required degree of reliability. To achieve 2556 this, the PSE need the full richness of a DODAG to form any path that 2557 could make meet the SLAs. 2559 This section specifies the additions that are needed to turn the 2560 Track into a full DODAG and enable the main Root to provide the 2561 necessary topological information to the Track Ingress. The 2562 expectation is that the metrics that the PSE uses are of an order 2563 other than that of the PCE, because of the difference of time scale 2564 between routing and forwarding, mor e in [RAW-ARCHI]. It follows 2565 that the PSE will learn the metrics it needs from an alternate 2566 source, e.g., OAM frames. 2568 To pass the topological information to the Ingress, the Root uses a 2569 P-DAO messages that contains sequences of Target and Transit 2570 Information options that collectively represent the Track, expressed 2571 in the same fashion as in classical Non-Storing Mode. The difference 2572 as that the Root is the source as opposed to the destination, and can 2573 report information on many Targets, possibly the full Track, with one 2574 P-DAO. 2576 Note that the Path Sequence and Lifetime in the TIO are selected by 2577 the Root, and that the Target/Transit information tupples in the 2578 P-DAO are not those received by the Root in the DAO messages about 2579 the said Targets. The Track may follow sibling routes and does not 2580 need to be congruent with the Main DODAG. 2582 8. Profiles 2584 This document provides a set of tools that may or may not be needed 2585 by an implementation depending on the type of application it serves. 2586 This sections described profiles that can be implemented separately 2587 and can be used to discriminate what an implementation can and cannot 2588 do. This section describes profiles that enable to implement only a 2589 portion of this specification to meet a particular use case. 2591 Profiles 0 to 2 operate in the Main RPL Instance and do not require 2592 the support of local RPL Instances or the indication of the RPL 2593 Instance in the data plane. Profile 3 and above leverage Local RPL 2594 Instances to build arbitrary Tracks rooted at the Track Ingress and 2595 using its namespace for TrackID. 2597 Profiles 0 and 1 are REQUIRED by all implementations that may be used 2598 in LLNs; this enables to use Storing Mode to reduce the size of the 2599 Source Route Header in the most common LLN deployments. Profile 2 is 2600 RECOMMENDED in high speed / wired environment to enable traffic 2601 Engineering and network automation. All the other profile / 2602 environment combinations are OPTIONAL. 2604 Profile 0 Profile 0 is the Legacy support of [RPL] Non-Storing Mode, 2605 with default routing Northwards (up) and strict source routing 2606 Southwards (down the main DOAG). It provides the minimal common 2607 functionality that must be implemented as a prerequisite to all 2608 the Track-supporting profiles. The other Profiles extend Profile 2609 0 with selected capabilities that this specification introduces on 2610 top. 2612 Profile 1 (Storing Mode P-Route Segments along the Main DODAG) Profi 2613 le 1 does not create new paths; compared to Profile 0, it combines 2614 Storing and Non-Storing Modes to balance the size of the Routing 2615 Header in the packet and the amount of state in the intermediate 2616 routers in a Non-Storing Mode RPL DODAG. 2618 Profile 2 (Non-Storing Mode P-Route Segments along the Main DODAG) P 2619 rofile 2 extends Profile 0 with Strict Source-Routing Non-Storing 2620 Mode P-Routes along the Main DODAG, which is the same as Profile 1 2621 but using NSM VIOs as opposed to SM VIOs. Profile 2 provides the 2622 same capability to compress the SRH in packets down the Main DODAG 2623 as Profile 1, but it require an encapsulation, in order to insert 2624 an additional SRH between the loose source routing hops. In that 2625 case, the Tracks MUST be installed as subTracks of the Main DODAG, 2626 the main RPL Instance MUST be used as TrackID, and the Ingress 2627 node that encapsulates is not the Root as it does not own the 2628 DODAGID. 2630 Profile 3 In order to form the best path possible, those Profiles 2631 require the support of Sibling Information Option to inform the 2632 Root of additional possible hops. Profile 3 extends Profile 1 2633 with additional Storing Mode P-Routes that install segments that 2634 do not follow the Main DODAG. If the Segment Ingress (in the SM- 2635 VIO) is the same as the IPv6 Address of the Track Ingress (in the 2636 projected DAO base Object), the P-DAO creates an implicit Track 2637 between the Segment Ingress and the Segment Egress. 2639 Profile 4 Profile 4 extends Profile 2 with Strict Source-Routing 2640 Non-Storing Mode P-Routes to form East-West Tracks that are inside 2641 the Main DODAG but do not necessarily follow it. A Track is 2642 formed as one or more strict source source routed paths between 2643 the Root that is the Track Ingress, and the Track Egress that is 2644 the last node. 2646 Profile 5 Profile 5 Combines Profile 4 with Profile 1 and enables to 2647 loose source routing between the Ingress and the Egress of the 2648 Track. As in Profile 1, Storing Mode P-Routes connect the dots in 2649 the loose source route. 2651 Profile 6 Profile 6 Combines Profile 4 with Profile 2 and also 2652 enables to loose source routing between the Ingress and the Egress 2653 of the Track. 2655 Profile 7 Profile 7 implements profile 5 in a Main DODAG that is 2656 operated in Storing Mode as presented in Section 7.1. As in 2657 Profile 1 and 2, the TrackID is the RPLInstanceID of the Main 2658 DODAG. Longest match rules decide whether a packet is sent along 2659 the Main DODAG or rerouted in a track. 2661 Profile 8 Profile 8 is offered in preparation of the RAW work, and 2662 for use cases where an arbitrary node in the network can afford 2663 the same code complexity as the RPL Root in a traditional 2664 deployment. It offers a full DODAG visibility to the Track 2665 Ingress as specified in Section 7.2 in a Non-Storing Mode Main 2666 DODAG. 2668 Profile 9 Profile 9 combines profiles 7 and 8, operating the Track 2669 as a full DODAG within a Storing Mode Main DODAG, using only the 2670 Main DODAG RPLInstanceID as TrackID. 2672 9. Security Considerations 2674 It is worth noting that with [RPL], every node in the LLN is RPL- 2675 aware and can inject any RPL-based attack in the network. This draft 2676 uses messages that are already present in RPL [RPL] with optional 2677 secured versions. The same secured versions may be used with this 2678 draft, and whatever security is deployed for a given network also 2679 applies to the flows in this draft. 2681 The LLN nodes depend on the 6LBR and the RPL participants for their 2682 operation. A trust model must be put in place to ensure that the 2683 right devices are acting in these roles, so as to avoid threats such 2684 as black-holing, (see [RFC7416] section 7). This trust model could 2685 be at a minimum based on a Layer-2 Secure joining and the Link-Layer 2686 security. This is a generic 6LoWPAN requirement, see Req5.1 in 2687 Appendix B.5 of [RFC8505]. 2689 In a general manner, the Security Considerations in [RPL], and 2690 [RFC7416] apply to this specification as well. The Link-Layer 2691 security is needed in particular to prevent Denial-Of-Service attacks 2692 whereby a rogue router creates a high churn in the RPL network by 2693 constantly injected forged P-DAO messages and using up all the 2694 available storage in the attacked routers. 2696 Additionally, the trust model could include a role validation (e.g., 2697 using a role-based authorization) to ensure that the node that claims 2698 to be a RPL Root is entitled to do so. That trust should propagate 2699 from Egress to Ingress in the case of a Storing Mode P-DAO. 2701 This specification suggests some validation of the VIO to prevent 2702 basic loops by avoiding that a node appears twice. But that is only 2703 a minimal protection. Arguably, an attacker tha can inject P-DAOs 2704 can reroute any traffic and deplete critical resources such as 2705 spectrum and battery in the LLN rapidly. 2707 10. IANA Considerations 2708 10.1. New Elective 6LoWPAN Routing Header Type 2710 This document updates the IANA registry titled "Elective 6LoWPAN 2711 Routing Header Type" that was created for [RFC8138] and assigns the 2712 following value: 2714 +===============+=============+===============+ 2715 | Value | Description | Reference | 2716 +===============+=============+===============+ 2717 | 8 (Suggested) | P-RPI-6LoRH | This document | 2718 +---------------+-------------+---------------+ 2720 Table 21: New Elective 6LoWPAN Routing 2721 Header Type 2723 10.2. New Critical 6LoWPAN Routing Header Type 2725 This document updates the IANA registry titled "Critical 6LoWPAN 2726 Routing Header Type" that was created for [RFC8138] and assigns the 2727 following value: 2729 +===============+=============+===============+ 2730 | Value | Description | Reference | 2731 +===============+=============+===============+ 2732 | 8 (Suggested) | P-RPI-6LoRH | This document | 2733 +---------------+-------------+---------------+ 2735 Table 22: New Critical 6LoWPAN Routing 2736 Header Type 2738 10.3. New Subregistry For The RPL Option Flags 2740 IANA is required to create a subregistry for the 8-bit RPL Option 2741 Flags field, as detailed in Figure 4, under the "Routing Protocol for 2742 Low Power and Lossy Networks (RPL)" registry. The bits are indexed 2743 from 0 (leftmost) to 7. Each bit is Tracked with the following 2744 qualities: 2746 * Bit number (counting from bit 0 as the most significant bit) 2748 * Indication When Set 2750 * Reference 2752 Registration procedure is "Standards Action" [RFC8126]. The initial 2753 allocation is as indicated in Table 26: 2755 +===============+======================+===============+ 2756 | Bit number | Indication When Set | Reference | 2757 +===============+======================+===============+ 2758 | 0 | Down 'O' | [RFC6553] | 2759 +---------------+----------------------+---------------+ 2760 | 1 | Rank-Error (R) | [RFC6553] | 2761 +---------------+----------------------+---------------+ 2762 | 2 | Forwarding-Error (F) | [RFC6553] | 2763 +---------------+----------------------+---------------+ 2764 | 3 (Suggested) | Projected-Route (P) | This document | 2765 +---------------+----------------------+---------------+ 2767 Table 23: Initial PDR Flags 2769 10.4. New RPL Control Codes 2771 This document extends the IANA Subregistry created by RFC 6550 for 2772 RPL Control Codes as indicated in Table 24: 2774 +==================+=============================+===============+ 2775 | Code | Description | Reference | 2776 +==================+=============================+===============+ 2777 | 0x09 (Suggested) | Projected DAO Request (PDR) | This document | 2778 +------------------+-----------------------------+---------------+ 2779 | 0x0A (Suggested) | PDR-ACK | This document | 2780 +------------------+-----------------------------+---------------+ 2782 Table 24: New RPL Control Codes 2784 10.5. New RPL Control Message Options 2786 This document extends the IANA Subregistry created by RFC 6550 for 2787 RPL Control Message Options as indicated in Table 25: 2789 +==================+=============================+===============+ 2790 | Value | Meaning | Reference | 2791 +==================+=============================+===============+ 2792 | 0x0E (Suggested) | Stateful VIO (SM-VIO) | This document | 2793 +------------------+-----------------------------+---------------+ 2794 | 0x0F (Suggested) | Source-Routed VIO (NSM-VIO) | This document | 2795 +------------------+-----------------------------+---------------+ 2796 | 0x10 (Suggested) | Sibling Information option | This document | 2797 +------------------+-----------------------------+---------------+ 2799 Table 25: RPL Control Message Options 2801 10.6. SubRegistry for the Projected DAO Request Flags 2803 IANA is required to create a registry for the 8-bit Projected DAO 2804 Request (PDR) Flags field. Each bit is Tracked with the following 2805 qualities: 2807 * Bit number (counting from bit 0 as the most significant bit) 2809 * Capability description 2811 * Reference 2813 Registration procedure is "Standards Action" [RFC8126]. The initial 2814 allocation is as indicated in Table 26: 2816 +============+========================+===============+ 2817 | Bit number | Capability description | Reference | 2818 +============+========================+===============+ 2819 | 0 | PDR-ACK request (K) | This document | 2820 +------------+------------------------+---------------+ 2821 | 1 | Requested path should | This document | 2822 | | be redundant (R) | | 2823 +------------+------------------------+---------------+ 2825 Table 26: Initial PDR Flags 2827 10.7. SubRegistry for the PDR-ACK Flags 2829 IANA is required to create an subregistry for the 8-bit PDR-ACK Flags 2830 field. Each bit is Tracked with the following qualities: 2832 * Bit number (counting from bit 0 as the most significant bit) 2834 * Capability description 2836 * Reference 2838 Registration procedure is "Standards Action" [RFC8126]. No bit is 2839 currently defined for the PDR-ACK Flags. 2841 10.8. Subregistry for the PDR-ACK Acceptance Status Values 2843 IANA is requested to create a Subregistry for the PDR-ACK Acceptance 2844 Status values. 2846 * Possible values are 6-bit unsigned integers (0..63). 2848 * Registration procedure is "Standards Action" [RFC8126]. 2850 * Initial allocation is as indicated in Table 27: 2852 +-------+------------------------+---------------+ 2853 | Value | Meaning | Reference | 2854 +-------+------------------------+---------------+ 2855 | 0 | Unqualified Acceptance | This document | 2856 +-------+------------------------+---------------+ 2858 Table 27: Acceptance values of the PDR-ACK Status 2860 10.9. Subregistry for the PDR-ACK Rejection Status Values 2862 IANA is requested to create a Subregistry for the PDR-ACK Rejection 2863 Status values. 2865 * Possible values are 6-bit unsigned integers (0..63). 2867 * Registration procedure is "Standards Action" [RFC8126]. 2869 * Initial allocation is as indicated in Table 28: 2871 +-------+-----------------------+---------------+ 2872 | Value | Meaning | Reference | 2873 +-------+-----------------------+---------------+ 2874 | 0 | Unqualified Rejection | This document | 2875 +-------+-----------------------+---------------+ 2876 | 1 | Transient Failure | This document | 2877 +-------+-----------------------+---------------+ 2879 Table 28: Rejection values of the PDR-ACK Status 2881 10.10. SubRegistry for the Via Information Options Flags 2883 IANA is requested to create a Subregistry for the 5-bit Via 2884 Information Options (Via Information Option) Flags field. Each bit 2885 is Tracked with the following qualities: 2887 * Bit number (counting from bit 0 as the most significant bit) 2889 * Capability description 2891 * Reference 2893 Registration procedure is "Standards Action" [RFC8126]. No bit is 2894 currently defined for the Via Information Options (Via Information 2895 Option) Flags. 2897 10.11. SubRegistry for the Sibling Information Option Flags 2899 IANA is required to create a registry for the 5-bit Sibling 2900 Information Option (SIO) Flags field. Each bit is Tracked with the 2901 following qualities: 2903 * Bit number (counting from bit 0 as the most significant bit) 2905 * Capability description 2907 * Reference 2909 Registration procedure is "Standards Action" [RFC8126]. The initial 2910 allocation is as indicated in Table 29: 2912 +===============+========================+===========+ 2913 | Bit number | Capability description | Reference | 2914 +===============+========================+===========+ 2915 | 0 (Suggested) | "D" flag: Sibling in | This | 2916 | | same DODAG as Self | document | 2917 +---------------+------------------------+-----------+ 2919 Table 29: Initial SIO Flags 2921 10.12. New destination Advertisement Object Flag 2923 This document modifies the "destination Advertisement Object (DAO) 2924 Flags" registry initially created in Section 20.11 of [RPL] . 2926 Section 4.1.1 also defines one new entry in the Registry as follows: 2928 +---------------+------------------------+-----------+ 2929 | Bit Number | Capability Description | Reference | 2930 +---------------+------------------------+-----------+ 2931 | 2 (Suggested) | Projected DAO (P) | THIS RFC | 2932 +---------------+------------------------+-----------+ 2934 Table 30: New destination Advertisement Object 2935 (DAO) Flag 2937 10.13. New ICMPv6 Error Code 2939 In some cases RPL will return an ICMPv6 error message when a message 2940 cannot be forwarded along a P-Route. 2942 IANA has defined an ICMPv6 "Code" Fields Registry for ICMPv6 Message 2943 Types. ICMPv6 Message Type 1 describes "destination Unreachable" 2944 codes. This specification requires that a new code is allocated from 2945 the ICMPv6 Code Fields Registry for ICMPv6 Message Type 1, for "Error 2946 in P-Route", with a suggested code value of 8, to be confirmed by 2947 IANA. 2949 10.14. New RPL Rejection Status values 2951 This specification updates the Subregistry for the "RPL Rejection 2952 Status" values under the RPL registry, as follows: 2954 +---------------+-------------------------+-----------+ 2955 | Value | Meaning | Reference | 2956 +---------------+-------------------------+-----------+ 2957 | 2 (Suggested) | Out of Resources | THIS RFC | 2958 +---------------+-------------------------+-----------+ 2959 | 3 (Suggested) | Error in VIO | THIS RFC | 2960 +---------------+-------------------------+-----------+ 2961 | 4 (Suggested) | Predecessor Unreachable | THIS RFC | 2962 +---------------+-------------------------+-----------+ 2963 | 5 (Suggested) | Unreachable Target | THIS RFC | 2964 +---------------+-------------------------+-----------+ 2965 | 6..63 | Unassigned | | 2966 +---------------+-------------------------+-----------+ 2968 Table 31: Rejection values of the RPL Status 2970 11. Acknowledgments 2972 The authors wish to acknowledge JP Vasseur, Remy Liubing, James 2973 Pylakutty, and Patrick Wetterwald for their contributions to the 2974 ideas developed here. Many thanks to Dominique Barthel and SVR Anand 2975 for their global contribution to 6TiSCH, RAW and this document, as 2976 well as text suggestions that were incorporated, and to Michael 2977 Richardson for his useful recommendations based on his global view of 2978 the system. Also special thanks Toerless Eckert for his deep review, 2979 with many excellent suggestions that improved the readability and 2980 well as the content of the specification. 2982 12. Normative References 2984 [INT-ARCHI] 2985 Braden, R., Ed., "Requirements for Internet Hosts - 2986 Communication Layers", STD 3, RFC 1122, 2987 DOI 10.17487/RFC1122, October 1989, 2988 . 2990 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2991 Requirement Levels", BCP 14, RFC 2119, 2992 DOI 10.17487/RFC2119, March 1997, 2993 . 2995 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2996 Control Message Protocol (ICMPv6) for the Internet 2997 Protocol Version 6 (IPv6) Specification", STD 89, 2998 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2999 . 3001 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 3002 Computation Element (PCE)-Based Architecture", RFC 4655, 3003 DOI 10.17487/RFC4655, August 2006, 3004 . 3006 [RFC5551] Gellens, R., Ed., "Lemonade Notifications Architecture", 3007 RFC 5551, DOI 10.17487/RFC5551, August 2009, 3008 . 3010 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 3011 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 3012 DOI 10.17487/RFC6282, September 2011, 3013 . 3015 [RPL] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 3016 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 3017 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 3018 Low-Power and Lossy Networks", RFC 6550, 3019 DOI 10.17487/RFC6550, March 2012, 3020 . 3022 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 3023 Power and Lossy Networks (RPL) Option for Carrying RPL 3024 Information in Data-Plane Datagrams", RFC 6553, 3025 DOI 10.17487/RFC6553, March 2012, 3026 . 3028 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 3029 Routing Header for Source Routes with the Routing Protocol 3030 for Low-Power and Lossy Networks (RPL)", RFC 6554, 3031 DOI 10.17487/RFC6554, March 2012, 3032 . 3034 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3035 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 3036 May 2017, . 3038 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 3039 Writing an IANA Considerations Section in RFCs", BCP 26, 3040 RFC 8126, DOI 10.17487/RFC8126, June 2017, 3041 . 3043 13. Informative References 3045 [6LoWPAN] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 3046 "Transmission of IPv6 Packets over IEEE 802.15.4 3047 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 3048 . 3050 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 3051 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 3052 2014, . 3054 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and 3055 J. Martocci, "Reactive Discovery of Point-to-Point Routes 3056 in Low-Power and Lossy Networks", RFC 6997, 3057 DOI 10.17487/RFC6997, August 2013, 3058 . 3060 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 3061 and M. Richardson, Ed., "A Security Threat Analysis for 3062 the Routing Protocol for Low-Power and Lossy Networks 3063 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 3064 . 3066 [6TiSCH-ARCHI] 3067 Thubert, P., Ed., "An Architecture for IPv6 over the Time- 3068 Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)", 3069 RFC 9030, DOI 10.17487/RFC9030, May 2021, 3070 . 3072 [RAW-ARCHI] 3073 Thubert, P., Papadopoulos, G. Z., and L. Berger, "Reliable 3074 and Available Wireless Architecture/Framework", Work in 3075 Progress, Internet-Draft, draft-ietf-raw-architecture-01, 3076 28 July 2021, . 3079 [USE-CASES] 3080 Papadopoulos, G. Z., Thubert, P., Theoleyre, F., and C. J. 3081 Bernardos, "RAW use cases", Work in Progress, Internet- 3082 Draft, draft-ietf-raw-use-cases-02, 12 July 2021, 3083 . 3086 [TURN-ON_RFC8138] 3087 Thubert, P., Ed. and L. Zhao, "A Routing Protocol for Low- 3088 Power and Lossy Networks (RPL) Destination-Oriented 3089 Directed Acyclic Graph (DODAG) Configuration Option for 3090 the 6LoWPAN Routing Header", RFC 9035, 3091 DOI 10.17487/RFC9035, April 2021, 3092 . 3094 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 3095 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 3096 RFC 8025, DOI 10.17487/RFC8025, November 2016, 3097 . 3099 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 3100 "IPv6 over Low-Power Wireless Personal Area Network 3101 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 3102 April 2017, . 3104 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 3105 Perkins, "Registration Extensions for IPv6 over Low-Power 3106 Wireless Personal Area Network (6LoWPAN) Neighbor 3107 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 3108 . 3110 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 3111 Decraene, B., Litkowski, S., and R. Shakir, "Segment 3112 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 3113 July 2018, . 3115 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 3116 "Deterministic Networking Architecture", RFC 8655, 3117 DOI 10.17487/RFC8655, October 2019, 3118 . 3120 [RFC8930] Watteyne, T., Ed., Thubert, P., Ed., and C. Bormann, "On 3121 Forwarding 6LoWPAN Fragments over a Multi-Hop IPv6 3122 Network", RFC 8930, DOI 10.17487/RFC8930, November 2020, 3123 . 3125 [RFC8931] Thubert, P., Ed., "IPv6 over Low-Power Wireless Personal 3126 Area Network (6LoWPAN) Selective Fragment Recovery", 3127 RFC 8931, DOI 10.17487/RFC8931, November 2020, 3128 . 3130 [RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An 3131 Autonomic Control Plane (ACP)", RFC 8994, 3132 DOI 10.17487/RFC8994, May 2021, 3133 . 3135 [RFC9008] Robles, M.I., Richardson, M., and P. Thubert, "Using RPI 3136 Option Type, Routing Header for Source Routes, and IPv6- 3137 in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008, 3138 DOI 10.17487/RFC9008, April 2021, 3139 . 3141 [RFC9010] Thubert, P., Ed. and M. Richardson, "Routing for RPL 3142 (Routing Protocol for Low-Power and Lossy Networks) 3143 Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021, 3144 . 3146 [I-D.irtf-panrg-path-properties] 3147 Enghardt, T. and C. Krähenbühl, "A Vocabulary of Path 3148 Properties", Work in Progress, Internet-Draft, draft-irtf- 3149 panrg-path-properties-03, 9 July 2021, 3150 . 3153 [PCE] IETF, "Path Computation Element", 3154 . 3156 Appendix A. Applications 3158 A.1. Loose Source Routing 3160 A RPL implementation operating in a very constrained LLN typically 3161 uses the Non-Storing Mode of Operation as represented in Figure 17. 3162 In that mode, a RPL node indicates a parent-child relationship to the 3163 Root, using a destination Advertisement Object (DAO) that is unicast 3164 from the node directly to the Root, and the Root typically builds a 3165 source routed path to a destination down the DODAG by recursively 3166 concatenating this information. 3168 ------+--------- 3169 | Internet 3170 | 3171 +-----+ 3172 | | Border router 3173 | | (RPL Root) 3174 +-----+ ^ | | 3175 | | DAO | ACK | 3176 o o o o | | | Strict 3177 o o o o o o o o o | | | Source 3178 o o o o o o o o o o | | | Route 3179 o o o o o o o o o | | | 3180 o o o o o o o o | v v 3181 o o o o 3182 LLN 3184 Figure 17: RPL Non-Storing Mode of operation 3186 Based on the parent-children relationships expressed in the Non- 3187 Storing DAO messages,the Root possesses topological information about 3188 the whole network, though this information is limited to the 3189 structure of the DODAG for which it is the destination. A packet 3190 that is generated within the domain will always reach the Root, which 3191 can then apply a source routing information to reach the destination 3192 if the destination is also in the DODAG. Similarly, a packet coming 3193 from the outside of the domain for a destination that is expected to 3194 be in a RPL domain reaches the Root. 3196 It results that the Root, or then some associated centralized 3197 computation engine such as a PCE, can determine the amount of packets 3198 that reach a destination in the RPL domain, and thus the amount of 3199 energy and bandwidth that is wasted for transmission, between itself 3200 and the destination, as well as the risk of fragmentation, any 3201 potential delays because of a paths longer than necessary (shorter 3202 paths exist that would not traverse the Root). 3204 As a network gets deep, the size of the source routing header that 3205 the Root must add to all the downward packets becomes an issue for 3206 nodes that are many hops away. In some use cases, a RPL network 3207 forms long lines and a limited amount of well-targeted routing state 3208 would allow to make the source routing operation loose as opposed to 3209 strict, and save packet size. Limiting the packet size is directly 3210 beneficial to the energy budget, but, mostly, it reduces the chances 3211 of frame loss and/or packet fragmentation, which is highly 3212 detrimental to the LLN operation. Because the capability to store a 3213 routing state in every node is limited, the decision of which route 3214 is installed where can only be optimized with a global knowledge of 3215 the system, a knowledge that the Root or an associated PCE may 3216 possess by means that are outside of the scope of this specification. 3218 This specification enables to store a Storing Mode state in 3219 intermediate routers, which enables to limit the excursion of the 3220 source route headers in deep networks. Once a P-DAO exchange has 3221 taken place for a given Target, if the Root operates in non Storing 3222 Mode, then it may elide the sequence of routers that is installed in 3223 the network from its source route headers to destination that are 3224 reachable via that Target, and the source route headers effectively 3225 become loose. 3227 A.2. East-West Routes 3229 RPL is optimized for Point-to-Multipoint (P2MP) and Multipoint-to- 3230 Point (MP2P), whereby routes are always installed North-South (aka 3231 up/down) along the RPL DODAG respectively from and towards the DODAG 3232 Root. Peer to Peer (P2P) East-West routes in a RPL network will 3233 generally suffer from some elongated (stretched) path versus a direct 3234 (optimized) path, since routing between two nodes always happens via 3235 a common parent, as illustrated in Figure 18: 3237 ------+--------- 3238 | Internet 3239 | 3240 +-----+ 3241 | | Border router 3242 | | (RPL Root) 3243 +-----+ 3244 X 3245 ^ v o o 3246 ^ o o v o o o o o 3247 ^ o o o v o o o o o 3248 ^ o o v o o o o o 3249 S o o o D o o o 3250 o o o o 3251 LLN 3253 Figure 18: Routing Stretch between S and D via common parent X 3254 along North-South Paths 3256 * In Storing Mode, unless the destination is a child of the source, 3257 the packets will follow the default route up the DODAG as well. 3258 If the destination is in the same DODAG, they will eventually 3259 reach a common parent that has a route to the destination; at 3260 worse, the common parent may also be the Root. From that common 3261 parent, the packet will follow a path down the DODAG that is 3262 optimized for the Objective Function that was used to build the 3263 DODAG. 3265 * in Non-Storing Mode, all packets routed within the DODAG flow all 3266 the way up to the Root of the DODAG. If the destination is in the 3267 same DODAG, the Root must encapsulate the packet to place an RH 3268 that has the strict source route information down the DODAG to the 3269 destination. This will be the case even if the destination is 3270 relatively close to the source and the Root is relatively far off. 3272 It results that it is often beneficial to enable East-West P2P 3273 routes, either if the RPL route presents a stretch from shortest 3274 path, or if the new route is engineered with a different objective, 3275 and that it is even more critical in Non-Storing Mode than it is in 3276 Storing Mode, because the routing stretch is wider. For that reason, 3277 earlier work at the IETF introduced the "Reactive Discovery of 3278 Point-to-Point Routes in Low Power and Lossy Networks" [RFC6997], 3279 which specifies a distributed method for establishing optimized P2P 3280 routes. This draft proposes an alternate based on a centralized 3281 route computation. 3283 ------+--------- 3284 | Internet 3285 | 3286 +-----+ 3287 | | Border router 3288 | | (RPL Root) 3289 +-----+ 3290 | 3291 o o o o 3292 o o o o o o o o o 3293 o o o o o o o o o o 3294 o o o o o o o o o 3295 S>>A>>>B>>C>>>D o o o 3296 o o o o 3297 LLN 3299 Figure 19: More direct East-West Route between S and D 3301 This specification enables to store source-routed or Storing Mode 3302 state in intermediate routers, which enables to limit the stretch of 3303 a P2P route and maintain the characteristics within a given SLA. An 3304 example of service using this mechanism oculd be a control loop that 3305 would be installed in a network that uses classical RPL for 3306 asynchronous data collection. In that case, the P2P path may be 3307 installed in a different RPL Instance, with a different objective 3308 function. 3310 Authors' Addresses 3312 Pascal Thubert (editor) 3313 Cisco Systems, Inc 3314 Building D 3315 45 Allee des Ormes - BP1200 3316 06254 Mougins - Sophia Antipolis 3317 France 3319 Phone: +33 497 23 26 34 3320 Email: pthubert@cisco.com 3321 Rahul Arvind Jadhav 3322 Huawei Tech 3323 Kundalahalli Village, Whitefield, 3324 Bangalore 560037 3325 Karnataka 3326 India 3328 Phone: +91-080-49160700 3329 Email: rahul.ietf@gmail.com 3331 Matthew Gillmore 3332 Itron, Inc 3333 Building D 3334 2111 N Molter Road 3335 Liberty Lake, 99019 3336 United States 3338 Phone: +1.800.635.5461 3339 Email: matthew.gillmore@itron.com