idnits 2.17.00 (12 Aug 2021) /tmp/idnits20289/draft-ietf-roll-dao-projection-06.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6550, but the abstract doesn't seem to directly say this. It does mention RFC6550 though, so this could be OK. -- The draft header indicates that this document updates RFC8138, but the abstract doesn't seem to directly say this. It does mention RFC8138 though, so this could be OK. -- The draft header indicates that this document updates RFC6553, but the abstract doesn't seem to directly say this. It does mention RFC6553 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 24, 2019) is 1093 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: draft-ietf-6tisch-architecture has been published as RFC 9030 == Outdated reference: draft-ietf-detnet-architecture has been published as RFC 8655 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL P. Thubert, Ed. 3 Internet-Draft Cisco Systems 4 Updates: 6550, 6553, 8138 (if approved) R. Jadhav 5 Intended status: Standards Track Huawei Tech 6 Expires: November 25, 2019 M. Gillmore 7 Itron 8 J. Pylakutty 9 Cisco 10 May 24, 2019 12 Root initiated routing state in RPL 13 draft-ietf-roll-dao-projection-06 15 Abstract 17 This document extends RFC 6550, RFC 6553 and RFC 8138 and enable to 18 install a limited amount of centrally-computed routes in a RPL graph, 19 enabling loose source routing down a non-storing mode DODAG, or 20 transversal routes inside the DODAG. In constrast with classical 21 routes in RPL that are injected by the end devices, this draft 22 enables the root of the DODAG to projects the routes that are needed 23 on the nodes where they should be installed. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on November 25, 2019. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.2. New Terms . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.3. References . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Extending RFC 6550 . . . . . . . . . . . . . . . . . . . . . 4 65 3.1. RPL Instances . . . . . . . . . . . . . . . . . . . . . . 5 66 3.2. New RPL Control Message Options . . . . . . . . . . . . . 5 67 3.3. RPI for Projected Routes . . . . . . . . . . . . . . . . 7 68 3.4. Projected DAO . . . . . . . . . . . . . . . . . . . . . . 7 69 3.4.1. Non-Storing Mode P-Route . . . . . . . . . . . . . . 9 70 3.4.2. Storing-Mode P-Route . . . . . . . . . . . . . . . . 10 71 4. Extending RFC 8138 . . . . . . . . . . . . . . . . . . . . . 13 72 4.1. Elective RPI 6LoRH . . . . . . . . . . . . . . . . . . . 13 73 5. Extending RFC 6553 . . . . . . . . . . . . . . . . . . . . . 13 74 5.1. Uncompressed RPL Option . . . . . . . . . . . . . . . . . 13 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 77 7.1. New Elective 6LoWPAN Routing Header Type . . . . . . . . 14 78 7.2. New RPL Control Codes . . . . . . . . . . . . . . . . . . 15 79 7.3. Error in Projected Route ICMPv6 Code . . . . . . . . . . 15 80 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 82 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 83 9.2. Informative References . . . . . . . . . . . . . . . . . 17 84 Appendix A. Applications . . . . . . . . . . . . . . . . . . . . 18 85 A.1. Loose Source Routing in Non-storing Mode . . . . . . . . 18 86 A.2. Transversal Routes in storing and non-storing modes . . . 19 87 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 21 88 B.1. Using storing mode P-DAO in non-storing mode MOP . . . . 21 89 B.2. Projecting a storing-mode transversal route . . . . . . . 22 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 92 1. Introduction 94 The "Routing Protocol for Low Power and Lossy Networks" [RFC6550] 95 (LLN)(RPL) is a generic Distance Vector protocol that is well suited 96 low energy Internet of Things (IoT) networks. RPL forms Destination 97 Oriented Directed Acyclic Graphs (DODAGs) in which the root often 98 acts as the Border Router to connect the RPL domain to the Internet. 99 The root is responsible to select the RPL Instance that is used to 100 forward a packet coming from the Internet into the RPL domain and set 101 the related RPL information in the packets. 103 The 6TiSCH architecture [I-D.ietf-6tisch-architecture] leverages RPL 104 for its routing operation and considers the Deterministic Networking 105 Architecture [I-D.ietf-detnet-architecture] as one possible model 106 whereby the device resources and capabilities are exposed to an 107 external controller which installs routing states into the network 108 based on some objective functions that reside in that external 109 entity. 111 Based on heuristics of usage, path length, and knowledge of device 112 capacity and available resources such as battery levels and 113 reservable buffers, a Path Computation Element ([PCE]) with a global 114 visibility on the system could install additional P2P routes that are 115 more optimized for the current needs as expressed by the objective 116 function. 118 This draft enables a RPL root to install and maintain projected 119 routes (P-Routes) within its DODAG, along a selected set of nodes 120 that may or may not include self, for a chosen duration. This 121 potentially enables routes that are more optimized than those 122 obtained with the distributed operation of RPL, either in terms of 123 the size of a source-route header or in terms of path length, which 124 impacts both the latency and the packet delivery ratio. P-routes may 125 be installed in either Storing and Non-Storing Modes Instances of the 126 classical RPL operation, resulting in potentially hybrid situations 127 where the mode of some P-routes is different from that of the other 128 routes in the RPL Instance. 130 P-Routes must be used with the parsimony to limit the amount of state 131 that is installed in each device to fit within its resources, and to 132 limit the amount of rerouted traffic to fit within the capabilities 133 of the transmission links. The algorithm used to compute the paths 134 and the protocol used to learn the topology of the network and the 135 resources that are available in devices and in the network are out of 136 scope for this document. Possibly with the assistance of a Path 137 Computation Element ([PCE]) that could have a better visibility on 138 the larger system, the root computes which segment could be optimized 139 and uses this draft to install the corresponding P-Routes. 141 2. Terminology 143 2.1. BCP 14 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 147 "OPTIONAL" in this document are to be interpreted as described in BCP 148 14 [RFC2119][RFC8174] when, and only when, they appear in all 149 capitals, as shown here. 151 2.2. New Terms 153 P-Route: A route that is installed remotely by a RPL root. 155 2.3. References 157 In this document, readers will encounter terms and concepts that are 158 discussed in the following documents: 160 o "Routing Protocol for Low Power and Lossy Networks" [RFC6550], and 162 o "Terminology in Low power And Lossy Networks" [RFC7102]. 164 3. Extending RFC 6550 166 Section 6.7 of RPL [RFC6550] specifies Control Message Options (CMO) 167 to be placed in RPL messages such as the Destination Advertisement 168 Object (DAO) message. The RPL Target Option and the Transit 169 Information Option (TIO) are such options. In Non-Storing Mode, the 170 TIO option is used in the DAO message to indicate the immediate 171 parent of a given path. The TIO applies to the Target options that 172 immedially preceed it. Options may be factorized; multiple TIOs may 173 be present to indicate multiple routes to the one or more contiguous 174 addressed indicated in the Target Options that immediately precede 175 the TIOs in the RPL message. 177 This specification introduces two new Control Message Options 178 referred to as Route Projection Options (RPO). One RPO is the 179 Information option (VIO) and the other is the Source-Routed VIO 180 (SRVIO). The VIO installs a route on each hop along a P-Route (in a 181 fashion analogous to RPL Storing Mode) whereas the SRVIO installs a 182 source-routing state at the ingress node, which uses it to insert a 183 routing header in a fashion similar to Non-Storing Mode. 185 Like the TIO, the RPOs MUST be preceded by one or more RPL Target 186 Options to which they apply, and they can be factorized: multiple 187 contiguous RPOs indicate alternate paths to the target(s). 189 3.1. RPL Instances 191 It must be noted that RPL has a concept of instance but does not have 192 a concept of an administrative distance, which exists in certain 193 proprietary implementations to sort out conflicts between multiple 194 sources of routing information. This draft conforms the instance 195 model as follows: 197 o If the PCE needs to influence a particular instance to add better 198 routes in conformance with the routing objectives in that 199 instance, it may do so. When the PCE modifies an existing 200 instance then the added routes must not create a loop in that 201 instance. This is achieved by always preferring a route obtained 202 from the PCE over a route that is learned via RPL. 204 o If the PCE installs a more specific (say, Traffic Engineered) 205 route between a particular pair of nodes then it SHOULD use a 206 Local Instance from the ingress node of that path. A packet 207 associated with that instance will be routed along that path and 208 MUST NOT be placed over a Global Instance again. A packet that is 209 placed on a Global Instance may be injected in the Local Instance 210 based on node policy and the Local Instance paramenters. 212 In all cases, the path is indicated by a new Via Information option, 213 and the flow is similar to the flow used to obtain loose source 214 routing. 216 3.2. New RPL Control Message Options 218 The format of RPOs is as follows: 220 0 1 2 3 221 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 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Type | Option Length | Path Sequence | Path Lifetime | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | | 226 + + 227 . . 228 . Via Address 1 . 229 . . 230 + + 231 | | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | | 234 . .... . 235 | | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | | 238 + + 239 . . 240 . Via Address n . 241 . . 242 + + 243 | | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 Figure 1: Via Information option format 248 Option Type: 0x0A for VIO, 0x0B for SRVIO (to be confirmed by IANA) 250 Option Length: In bytes; variable, depending on the number of Via 251 Addresses. 253 Path Sequence: 8-bit unsigned integer. When a RPL Target option is 254 issued by the root of the DODAG (i.e. in a DAO message), that 255 root sets the Path Sequence and increments the Path Sequence 256 each time it issues a RPL Target option with updated 257 information. The indicated sequence deprecates any state for a 258 given Target that was learned from a previous sequence and adds 259 to any state that was learned for that sequence. 261 Path Lifetime: 8-bit unsigned integer. The length of time in 262 Lifetime Units (obtained from the Configuration option) that 263 the prefix is valid for route determination. The period starts 264 when a new Path Sequence is seen. A value of 255 (0xFF) 265 represents infinity. A value of zero (0x00) indicates a loss 266 of reachability. A DAO message that contains a Via Information 267 option with a Path Lifetime of zero for a Target is referred as 268 a No-Path (for that Target) in this document. 270 Via Address: 16 bytes. IPv6 Address of the next hop towards the 271 destination(s) indicated in the target option that immediately 272 precede the RPO. Via Addresses are indicated in the order of 273 the data path from the ingress to the egress nodes. 275 An RPO MUST contain at least one Via Address, and a Via Address MUST 276 NOT be present more than once, otherwise the RPO MUST be ignored. 278 3.3. RPI for Projected Routes 280 RPL [RFC6550], Section 11.2, specifies the RPL Packet Information 281 (RPI) as a set of fields that are placed by RPL routers in IP packets 282 to identify the RPL Instance, detect anomalies and trigger corrective 283 actions. 285 In particular, the SenderRank, which is the scalar metric computed by 286 a specialized Objective Function such as described in [RFC6552], 287 indicates the Rank of the sender and is modified at each hop. The 288 SenderRank field is used to validate that the packet progresses in 289 the expected direction, either upwards or downwards, along the DODAG. 291 RPL defines the "RPL Option for Carrying RPL Information in Data- 292 Plane Datagrams" [RFC6553] to transport the RPI, which is carried in 293 an IPv6 Hop-by-Hop Options Header [RFC8200], typically consuming 294 eight bytes per packet. 296 This specification updates [RFC6550] as follows. When using 297 projected routes, the Rank is useless and SHOULD be set to 0 in the 298 non-compressed form, and can be elided in the compressed form (see 299 Section 4.1). In a same fashion, the O, R, and F flags that are 300 defined in Section 11.2 of [RFC6550] are not used for packets that 301 follow a projected route and they MUST be reset. A new flag is 302 added, the P flag that indicates that the packet is injected along a 303 projected route. 305 3.4. Projected DAO 307 This draft adds a capability to RPL whereby the root of a DODAG 308 projects a route by sending an extended DAO message called a 309 Projected-DAO (P-DAO) to an arbitrary router in the DODAG, indicating 310 one or more sequence(s) of routers inside the DODAG via which the 311 target(s) indicated in the Target Information Option(s) (TIO) can be 312 reached. 314 A P-DAO is sent from a global address of the root to a global address 315 of the recipient, and MUST be confirmed by a DAO-ACK, which is sent 316 back to a global address of the root. 318 A P-DAO message MUST contain at least one TIO and at least one RPO 319 following it. There can be at most one such sequence of TIOs and 320 then RPOs. 322 Like a classical DAO message, a P-DAO is processed only if it is 323 "new" per section 9.2.2. "Generation of DAO Messages" of the RPL 324 specification [RFC6550]; this is determined using the Path Sequence 325 information from the RPO as opposed to a TIO. Also, a Path Lifetime 326 of 0 in an RPO indicates that a route is to be removed. 328 There are two kinds of operation for the P-Routes, the Storing Mode 329 and the Non-Storing Mode. 331 o The Non-Storing Mode is discussed in Section 3.4.1. It uses an 332 SRVIO that carries a list of Via Addresses to be used as a source- 333 routed path to the target. The recipient of the P-DAO is the 334 ingress router of the source-routed path. Upon a Non-Storing Mode 335 P-DAO, the ingress router installs a source-routed state to the 336 target and replies to the root directly with a DAO-ACK message. 338 o The Storing Mode is discussed in Section 3.4.2. It uses a VIO 339 with one Via Address per consecutive hop, from the ingress to the 340 egress of the path, including the list of all intermediate routers 341 in the data path order. The Via Addresses indicate the routers in 342 which the routing state to the target have to be installed via the 343 next Via Address in the VIO. In normal operations, the P-DAO is 344 propagated along the chain of Via Routers from the egress router 345 of the path till the ingress one, which confirms the installation 346 to the root with a DAO-ACK message. Note that the root may be the 347 ingress and it may be the egress of the path, that it can also be 348 neither but it cannot be both. 350 In case of a forwarding error along a P-Route, an ICMP error is sent 351 to the root with a new Code "Error in Projected Route" (See 352 Section 7.3). The root can then modify or remove the P-Route. The 353 "Error in Projected Route" message has the same format as the 354 "Destination Unreachable Message", as specified in RFC 4443 355 [RFC4443]. The portion of the invoking packet that is sent back in 356 the ICMP message SHOULD record at least up to the routing header if 357 one is present, and the routing header SHOULD be consumed by this 358 node so that the destination in the IPv6 header is the next hop that 359 this node could not reach. if a 6LoWPAN Routing Header (6LoRH) 360 [RFC8138] is used to carry the IPv6 routing information in the outter 361 header then that whole 6LoRH information SHOULD be present in the 362 ICMP message. The sender and exact operation depend on the Mode and 363 is described in Section 3.4.1 and Section 3.4.2 respectively. 365 3.4.1. Non-Storing Mode P-Route 367 As illustrated in Figure 2, a P-DAO that carries an SRVIO enables the 368 root to install a source-routed path towards a target in any 369 particular router; with this path information the router can add a 370 source routed header reflecting the P-route to any packet for which 371 the current destination either is the said target or can be reached 372 via the target. 374 ------+--------- 375 | Internet 376 | 377 +-----+ 378 | | Border Router 379 | | (RPL Root) 380 +-----+ | P ^ | 381 | | DAO | ACK | Loose 382 o o o o router V | | Source 383 o o o o o o o o o | P-DAO . Route 384 o o o o o o o o o o | Source . Path 385 o o o o o o o o o | Route . From 386 o o o o o o o o | Path . Root 387 o o o o o target V . To 388 o o o o | Desti- 389 o o o o | nation 390 destination V 392 LLN 394 Figure 2: Projecting a Non-Storing Route 396 A route indicated by an SRVIO may be loose, meaning that the node 397 that owns the next listed Via Address is not necessarily a neighbor. 398 Without proper loop avoidance mechanisms, the interaction of loose 399 source routing and other mechanisms may effectively cause loops. In 400 order to avoid those loops, if the router that installs a P-route 401 does not have a connected route (a direct adjacency) to the next 402 soure routed hop and fails to locate it as a neighbor or a neighbor 403 of a neighbor, then it MUST ensure that it has another P-Route to the 404 next loose hop under the control of the same route computation 405 system, otherwise the P-DAO is rejected. 407 When forwarding a packet to a destination for which the router 408 determines that routing happens via the target, the router inserts 409 the source routing header in the packet to reach the target. In the 410 case of a loose source-routed path, there MUST be either a neighbor 411 that is adjacent to the loose next hop, on which case the packet s 412 forwarded to that neighbor, or a source-routed path to the loose next 413 hop; in the latter case, another encapsulation takes place and the 414 process possibly recurses; otherwise the packet is dropped. 416 In order to add a source-routing header, the router encapsulates the 417 packet with an IP-in-IP header and a non-storing mode source routing 418 header (SRH) [RFC6554]. In the uncompressed form the source of the 419 packet would be self, the destination would be the first Via Address 420 in the SRVIO, and the SRH would contain the list of the remaining Via 421 Addresses and then the target. 423 In practice, the router will normally use the "IPv6 over Low-Power 424 Wireless Personal Area Network (6LoWPAN) Paging Dispatch" [RFC8025] 425 to compress the RPL artifacts as indicated in the "6LoWPAN Routing 426 Header" [RFC8138] specification. In that case, the router indicates 427 self as encapsulator in an IP-in-IP 6LoRH Header, and places the list 428 of Via Addresses in the order of the VIO and then the target in the 429 SRH 6LoRH Header. 431 +-+ ... -+-+ ... +-+- ... -+-+- ... -+-+-+- ... -+-+ ... 432 |11110001|SRH-6LoRH| ERPI- | IP-in-IP Encap | NH=1 |11110CPP| 433 |Page 1 |Type1 S=2| 6LoRH | 6LoRH sulator |LOWPAN_IPHC| UDP | 434 +-+ ... -+-+ ... +-+- ... -+-+- ... -+-+-+- ... -+-+ ... 435 <-RFC8138-><-This-><----RFC 8138----><-----RFC 6282-------> 436 RFC 5 to 19 bytes No RPL artifact 438 Figure 3: Example Compressed Packet with SRH. 440 In case of a forwarding error along a Source Route path, the node 441 that fails to forward SHOULD send an ICMP error with a code "Error in 442 Source Routing Header" back to the source of the packet, as described 443 in section 11.2.2.3. of [RFC6550]. Upon this message, the 444 encapsulating node SHOULD stop using the source route path for a 445 period of time and it SHOULD send an ICMP message with a Code "Error 446 in Projected Route" to the root. Failure to follow these steps may 447 result in packet loss and wasted resources along the source route 448 path that is broken. 450 3.4.2. Storing-Mode P-Route 452 As illustrated in Figure 4, the Storing Mode projected iq used by the 453 root to install a routing state towards a target in the routers along 454 a segment between an ingress and an egress router; this enables the 455 routers to forward along that segment any packet for which the next 456 loose hop is the said target, for instance a loose source routed 457 packet for which the next loose hop is the target, or a packet for 458 which the router has a routing state to the final destination via the 459 target. 461 ------+--------- 462 | Internet 463 | 464 +-----+ 465 | | Border Router 466 | | (RPL Root) 467 +-----+ | ^ | 468 | | DAO | ACK | 469 o o o o | | | 470 o o o o o o o o o | ^ | Projected . 471 o o o o o o o o o o | | DAO | Route . 472 o o o o o o o o o | ^ | . 473 o o o o o o o o v | DAO v . 474 o o LLN o o o | 475 o o o o o Loose Source Route Path | 476 o o o o From Root To Destination v 478 Figure 4: Projecting a route 480 In order to install the relevant routing state along the segment 481 between an ingress and an egress routers, the root sends a unicast 482 P-DAO message to the egress router of the routing segment that must 483 be installed. The P-DAO message contains the ordered list of hops 484 along the segment as a direct sequence of Via Information options 485 that are preceded by one or more RPL Target options to which they 486 relate. Each Via Information option contains a Path Lifetime for 487 which the state is to be maintained. 489 The root sends the P-DAO directly to the egress node of the segment. 490 In that P-DAO, the destination IP address matches the Via Address in 491 the last VIO. This is how the egress recognizes its role. In a 492 similar fashion, the ingress node recognizes its role as it matches 493 Via Address in the first VIO. 495 The egress node of the segment is the only node in the path that does 496 not install a route in response to the P-DAO; it is expected to be 497 already able to route to the target(s) on its own. It may either be 498 the target, or may have some existing information to reach the 499 target(s), such as a connected route or an already installed P-Route. 500 If one of the targets cannot be located, the node MUST answer to the 501 root with a negative DAO-ACK listing the target(s) that could not be 502 located (suggested status 10 to be confirmed by IANA). 504 If the egress node can reach all the targets, then it forwards the 505 P-DAO with unchanged content to its loose predecessor in the segment 506 as indicated in the list of Via Information options, and recursively 507 the message is propagated unchanged along the sequence of routers 508 indicated in the P-DAO, but in the reverse order, from egress to 509 ingress. 511 The address of the predecessor to be used as destination of the 512 propagated DAO message is found in the Via Information option the 513 precedes the one that contain the address of the propagating node, 514 which is used as source of the packet. 516 Upon receiving a propagated DAO, an intermediate router as well as 517 the ingress router install a route towards the DAO target(s) via its 518 successor in the P-DAO; the router locates the VIO that contains its 519 address, and uses as next hop the address found in the Via Address 520 field in the following VIO. The router MAY install additional routes 521 towards the addresses that are located in VIOs that are after the 522 next one, if any, but in case of a conflict or a lack of resource, a 523 route to a target installed by the root has precedence. 525 The process recurses till the P-DAO is propagated to ingress router 526 of the segment, which answers with a DAO-ACK to the root. 528 Also, the path indicated in a P-DAO may be loose, in which case the 529 reachability to the next hop has to be asserted. Each router along 530 the path indicated in a P-DAO is expected to be able to reach its 531 successor, either with a connected route (direct neighbor), or by 532 routing, for instance following a route installed previously by a DAO 533 or a P-DAO message. If that route is not connected then a recursive 534 lookup may take place at packet forwarding time to find the next hop 535 to reach the target(s). If it does not and cannot reach the next 536 router in the P-DAO, the router MUST answer to the root with a 537 negative DAO-ACK indicating the successor that is unreachable 538 (suggested status 11 to be confirmed by IANA). 540 A Path Lifetime of 0 in a Via Information option is used to clean up 541 the state. The P-DAO is forwarded as described above, but the DAO is 542 interpreted as a No-Path DAO and results in cleaning up existing 543 state as opposed to refreshing an existing one or installing a new 544 one. 546 In case of a forwarding error along a Storing Mode P-Route, the node 547 that fails to forward SHOULD send an ICMP error with a code "Error in 548 Projected Route" to the root. Failure to do so may result in packet 549 loss and wasted resources along the P-Route that is broken. 551 4. Extending RFC 8138 553 4.1. Elective RPI 6LoRH 555 [RFC8138] defines a Critical 6LoRH to compress the RPL RPI found in 556 normal packets inside a RPL domain, the RPI-6LoRH. 558 this specification introduces the ERPI-6LoRH header that MUST be used 559 to compress the RPI in packets that follow a projected route. As 560 discussed in Section 3.3, the Rank and the O, R, anf F flags are 561 always set to 0 and can be elided. The new P flag is always set and 562 can also be elided. It results that in general only the RPL 563 InstanceID is necessary in the compressed form. 565 This specification adds an optimization whereby the local 566 RPLInstanceID 0 for the source of the packet (the encapsulator when 567 using IP in IP) can be elided. This is the case where the 568 RPLInstanceID is encoded as binary b10000000, decimal 128, in the 569 non-compressed form. 571 The ERPI-6LoRH header is Elective since it does not contain 572 information that is critical to the routing and it can be ignored 573 when not understood. The resulting format is illustrated in Figure 5 574 below: 576 0 1 2 577 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 |1|0|1| Length | 6LoRH Type 5 | RPLInstanceID | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 Figure 5: A ERPI-6LoRH carrying a RPLInstanceID 584 The ERPI-6LoRH header is identifies by a 6LoRH Type of 5 (to be 585 confirmed by IANA), which is the same value as the RPI-6LoRH but in 586 the Elective namespace.If the RPLInstanceID is a local RPLInstanceID 587 0 for the source of the packet then it MUST be elided and the length 588 MUST be set to 0. Else the length MUST be set to 1 to indicate that 589 the ERPI-6LoRH carries a RPLinstanceID. 591 5. Extending RFC 6553 593 5.1. Uncompressed RPL Option 595 [RFC6553] defines a format for the RPI that is suitable for 596 transporting in the IPv6 Hop-by-Hop Header [RFC8200]. This 597 specification introduces a new flag in the RPI that must be encoded 598 in any format includeing uncompressed. 600 The updated format for the RPL Option is presented in Figure 6. 602 0 1 2 3 603 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 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | Option Type | Opt Data Len | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 |O|R|F|P|0|0|0|0| RPLInstanceID | SenderRank | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | (sub-TLVs) | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 Figure 6: RPL Option 614 New fields: 616 P: 1-bit flag; indicates that the packet is routed along 617 a projected route. 619 6. Security Considerations 621 This draft uses messages that are already present in RPL [RFC6550] 622 with optional secured versions. The same secured versions may be 623 used with this draft, and whatever security is deployed for a given 624 network also applies to the flows in this draft. 626 TODO: should probably consider how P-DAO messages could be abused by 627 a) rogue nodes b) via replay of messages c) if use of P-DAO messages 628 could in fact deal with any threats? 630 7. IANA Considerations 632 7.1. New Elective 6LoWPAN Routing Header Type 634 This specification assigns a new value (to be confirmed by IANA) in 635 the Elective 6LoWPAN Routing Header Type Registry created for RFC 636 8138 as below: 638 +---------------+-------------+----------------+ 639 | Value | Meaning | Defining Spec | 640 +---------------+-------------+----------------+ 641 | 5 (suggested) | ERPI-6LoRH | This document | 642 +---------------+-------------+----------------+ 644 Table 1: New Elective 6LoWPAN Routing Header Type 646 7.2. New RPL Control Codes 648 This document extends the IANA registry created by RFC 6550 for RPL 649 Control Codes as follows: 651 +------+-------------------+---------------+ 652 | Code | Description | Reference | 653 +------+-------------------+---------------+ 654 | 0x0A | Via | This document | 655 | | | | 656 | 0x0B | Source-Routed Via | This document | 657 +------+-------------------+---------------+ 659 RPL Control Codes 661 This document is updating the registry created by RFC 6550 for the 662 RPL 3-bit Mode of Operation (MOP) as follows: 664 +-----------+----------------------------------------+--------------+ 665 | MOP value | Description | Reference | 666 +-----------+----------------------------------------+--------------+ 667 | 5 | Non-Storing mode of operation with | This | 668 | | P-Routes | document | 669 | | | | 670 | 6 | Storing mode of operation with | This | 671 | | P-Routes | document | 672 +-----------+----------------------------------------+--------------+ 674 DIO Mode of operation 676 7.3. Error in Projected Route ICMPv6 Code 678 In some cases RPL will return an ICMPv6 error message when a message 679 cannot be forwarded along a P-Route. This ICMPv6 error message is 680 "Error in Projected Route". 682 IANA has defined an ICMPv6 "Code" Fields Registry for ICMPv6 Message 683 Types. ICMPv6 Message Type 1 describes "Destination Unreachable" 684 codes. This specification requires that a new code is allocated from 685 the ICMPv6 Code Fields Registry for ICMPv6 Message Type 1, for "Error 686 in Projected Route", with a suggested code value of 8, to be 687 confirmed by IANA. 689 8. Acknowledgments 691 The authors wish to acknowledge JP Vasseur and Patrick Wetterwald for 692 their contributions to the ideas developed here. 694 9. References 696 9.1. Normative References 698 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 699 Requirement Levels", BCP 14, RFC 2119, 700 DOI 10.17487/RFC2119, March 1997, 701 . 703 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 704 Control Message Protocol (ICMPv6) for the Internet 705 Protocol Version 6 (IPv6) Specification", STD 89, 706 RFC 4443, DOI 10.17487/RFC4443, March 2006, 707 . 709 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 710 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 711 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 712 Low-Power and Lossy Networks", RFC 6550, 713 DOI 10.17487/RFC6550, March 2012, 714 . 716 [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing 717 Protocol for Low-Power and Lossy Networks (RPL)", 718 RFC 6552, DOI 10.17487/RFC6552, March 2012, 719 . 721 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 722 Power and Lossy Networks (RPL) Option for Carrying RPL 723 Information in Data-Plane Datagrams", RFC 6553, 724 DOI 10.17487/RFC6553, March 2012, 725 . 727 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 728 Routing Header for Source Routes with the Routing Protocol 729 for Low-Power and Lossy Networks (RPL)", RFC 6554, 730 DOI 10.17487/RFC6554, March 2012, 731 . 733 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 734 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 735 RFC 8025, DOI 10.17487/RFC8025, November 2016, 736 . 738 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 739 "IPv6 over Low-Power Wireless Personal Area Network 740 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 741 April 2017, . 743 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 744 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 745 May 2017, . 747 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 748 (IPv6) Specification", STD 86, RFC 8200, 749 DOI 10.17487/RFC8200, July 2017, 750 . 752 9.2. Informative References 754 [I-D.ietf-6tisch-architecture] 755 Thubert, P., "An Architecture for IPv6 over the TSCH mode 756 of IEEE 802.15.4", draft-ietf-6tisch-architecture-20 (work 757 in progress), March 2019. 759 [I-D.ietf-detnet-architecture] 760 Finn, N., Thubert, P., Varga, B., and J. Farkas, 761 "Deterministic Networking Architecture", draft-ietf- 762 detnet-architecture-13 (work in progress), May 2019. 764 [PCE] IETF, "Path Computation Element", 765 . 767 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and 768 J. Martocci, "Reactive Discovery of Point-to-Point Routes 769 in Low-Power and Lossy Networks", RFC 6997, 770 DOI 10.17487/RFC6997, August 2013, 771 . 773 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 774 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 775 2014, . 777 Appendix A. Applications 779 A.1. Loose Source Routing in Non-storing Mode 781 A RPL implementation operating in a very constrained LLN typically 782 uses the Non-Storing Mode of Operation as represented in Figure 7. 783 In that mode, a RPL node indicates a parent-child relationship to the 784 root, using a Destination Advertisement Object (DAO) that is unicast 785 from the node directly to the root, and the root typically builds a 786 source routed path to a destination down the DODAG by recursively 787 concatenating this information. 789 ------+--------- 790 | Internet 791 | 792 +-----+ 793 | | Border Router 794 | | (RPL Root) 795 +-----+ ^ | | 796 | | DAO | ACK | 797 o o o o | | | Strict 798 o o o o o o o o o | | | Source 799 o o o o o o o o o o | | | Route 800 o o o o o o o o o | | | 801 o o o o o o o o | v v 802 o o o o 803 LLN 805 Figure 7: RPL non-storing mode of operation 807 Based on the parent-children relationships expressed in the non- 808 storing DAO messages,the root possesses topological information about 809 the whole network, though this information is limited to the 810 structure of the DODAG for which it is the destination. A packet 811 that is generated within the domain will always reach the root, which 812 can then apply a source routing information to reach the destination 813 if the destination is also in the DODAG. Similarly, a packet coming 814 from the outside of the domain for a destination that is expected to 815 be in a RPL domain reaches the root. 817 It results that the root, or then some associated centralized 818 computation engine such as a PCE, can determine the amount of packets 819 that reach a destination in the RPL domain, and thus the amount of 820 energy and bandwidth that is wasted for transmission, between itself 821 and the destination, as well as the risk of fragmentation, any 822 potential delays because of a paths longer than necessary (shorter 823 paths exist that would not traverse the root). 825 As a network gets deep, the size of the source routing header that 826 the root must add to all the downward packets becomes an issue for 827 nodes that are many hops away. In some use cases, a RPL network 828 forms long lines and a limited amount of well-targeted routing state 829 would allow to make the source routing operation loose as opposed to 830 strict, and save packet size. Limiting the packet size is directly 831 beneficial to the energy budget, but, mostly, it reduces the chances 832 of frame loss and/or packet fragmentation, which is highly 833 detrimental to the LLN operation. Because the capability to store a 834 routing state in every node is limited, the decision of which route 835 is installed where can only be optimized with a global knowledge of 836 the system, a knowledge that the root or an associated PCE may 837 possess by means that are outside of the scope of this specification. 839 This specification enables to store source-routed or storing mode 840 state in intermediate routers, which enables to limit the excursion 841 of the source route headers in deep networks. Once a P-DAO exchange 842 has taken place for a given target, if the root operates in non 843 storing mode, then it may elide the sequence of routers that is 844 installed in the network from its source route headers to destination 845 that are reachable via that target, and the source route headers 846 effectively become loose. 848 A.2. Transversal Routes in storing and non-storing modes 850 RPL is optimized for Point-to-Multipoint (P2MP) and Multipoint-to- 851 Point (MP2P), whereby routes are always installed along the RPL DODAG 852 respectively from and towards the DODAG Root. Transversal Peer to 853 Peer (P2P) routes in a RPL network will generally suffer from some 854 elongated (stretched) path versus the best possible path, since 855 routing between 2 nodes always happens via a common parent, as 856 illustrated in Figure 8: 858 o in non-storing mode, all packets routed within the DODAG flow all 859 the way up to the root of the DODAG. If the destination is in the 860 same DODAG, the root must encapsulate the packet to place a 861 Routing Header that has the strict source route information down 862 the DODAG to the destination. This will be the case even if the 863 destination is relatively close to the source and the root is 864 relatively far off. 866 o In storing mode, unless the destination is a child of the source, 867 the packets will follow the default route up the DODAG as well. 868 If the destination is in the same DODAG, they will eventually 869 reach a common parent that has a route to the destination; at 870 worse, the common parent may also be the root. From that common 871 parent, the packet will follow a path down the DODAG that is 872 optimized for the Objective Function that was used to build the 873 DODAG. 875 ------+--------- 876 | Internet 877 | 878 +-----+ 879 | | Border Router 880 | | (RPL Root) 881 +-----+ 882 X 883 ^ v o o 884 ^ o o v o o o o o 885 ^ o o o v o o o o o 886 ^ o o v o o o o o 887 S o o o D o o o 888 o o o o 889 LLN 891 Figure 8: Routing Stretch between S and D via common parent X 893 It results that it is often beneficial to enable transversal P2P 894 routes, either if the RPL route presents a stretch from shortest 895 path, or if the new route is engineered with a different objective. 896 For that reason, earlier work at the IETF introduced the "Reactive 897 Discovery of Point-to-Point Routes in Low Power and Lossy Networks" 898 [RFC6997], which specifies a distributed method for establishing 899 optimized P2P routes. This draft proposes an alternate based on a 900 centralized route computation. 902 ------+--------- 903 | Internet 904 | 905 +-----+ 906 | | Border Router 907 | | (RPL Root) 908 +-----+ 909 | 910 o o o o 911 o o o o o o o o o 912 o o o o o o o o o o 913 o o o o o o o o o 914 S>>A>>>B>>C>>>D o o o 915 o o o o 916 LLN 918 Figure 9: Projected Transversal Route 920 This specification enables to store source-routed or storing mode 921 state in intermediate routers, which enables to limit the stretch of 922 a P2P route and maintain the characteristics within a given SLA. An 923 example of service using this mechanism oculd be a control loop that 924 would be installed in a network that uses classical RPL for 925 asynchronous data collection. In that case, the P2P path may be 926 installed in a different RPL Instance, with a different objective 927 function. 929 Appendix B. Examples 931 B.1. Using storing mode P-DAO in non-storing mode MOP 933 In non-storing mode, the DAG root maintains the knowledge of the 934 whole DODAG topology, so when both the source and the destination of 935 a packet are in the DODAG, the root can determine the common parent 936 that would have been used in storing mode, and thus the list of nodes 937 in the path between the common parent and the destination. For 938 instance in the diagram shown in Figure 10, if the source is node 41 939 and the destination is node 52, then the common parent is node 22. 941 ------+--------- 942 | Internet 943 | 944 +-----+ 945 | | Border Router 946 | | (RPL Root) 947 +-----+ 948 | \ \____ 949 / \ \ 950 o 11 o 12 o 13 951 / | / \ 952 o 22 o 23 o 24 o 25 953 / \ | \ \ 954 o 31 o 32 o o o 35 955 / / | \ | \ 956 o 41 o 42 o o o 45 o 46 957 | | | | \ | 958 o 51 o 52 o 53 o o 55 o 56 960 LLN 962 Figure 10: Example DODAG forming a logical tree topology 964 With this draft, the root can install a storing mode routing states 965 along a segment that is either from itself to the destination, or 966 from one or more common parents for a particular source/destination 967 pair towards that destination (in this particular example, this would 968 be the segment made of nodes 22, 32, 42). 970 In the example below, say that there is a lot of traffic to nodes 55 971 and 56 and the root decides to reduce the size of routing headers to 972 those destinations. The root can first send a DAO to node 45 973 indicating target 55 and a Via segment (35, 45), as well as another 974 DAO to node 46 indicating target 56 and a Via segment (35, 46). This 975 will save one entry in the routing header on both sides. The root 976 may then send a DAO to node 35 indicating targets 55 and 56 a Via 977 segment (13, 24, 35) to fully optimize that path. 979 Alternatively, the root may send a DAO to node 45 indicating target 980 55 and a Via segment (13, 24, 35, 45) and then a DAO to node 46 981 indicating target 56 and a Via segment (13, 24, 35, 46), indicating 982 the same DAO Sequence. 984 B.2. Projecting a storing-mode transversal route 986 In this example, say that a PCE determines that a path must be 987 installed between node S and node D via routers A, B and C, in order 988 to serve the needs of a particular application. 990 The root sends a P-DAO with a target option indicating the 991 destination D and a sequence Via Information option, one for S, which 992 is the ingress router of the segment, one for A and then for B, which 993 are an intermediate routers, and one for C, which is the egress 994 router. 996 ------+--------- 997 | Internet 998 | 999 +-----+ 1000 | | Border Router 1001 | | (RPL Root) 1002 +-----+ 1003 | P-DAO message to C 1004 o | o o 1005 o o o | o o o o o 1006 o o o | o o o o o o 1007 o o V o o o o o o 1008 S A B C D o o o 1009 o o o o 1010 LLN 1012 Figure 11: P-DAO from root 1014 Upon reception of the P-DAO, C validates that it can reach D, e.g. 1015 using IPv6 Neighbor Discovery, and if so, propagates the P-DAO 1016 unchanged to B. 1018 B checks that it can reach C and of so, installs a route towards D 1019 via C. Then it propagates the P-DAO to A. 1021 The process recurses till the P-DAO reaches S, the ingress of the 1022 segment, which installs a route to D via A and sends a DAO-ACK to the 1023 root. 1025 ------+--------- 1026 | Internet 1027 | 1028 +-----+ 1029 | | Border Router 1030 | | (RPL Root) 1031 +-----+ 1032 ^ P-DAO-ACK from S 1033 / o o o 1034 / o o o o o o o 1035 | o o o o o o o o o 1036 | o o o o o o o o 1037 S A B C D o o o 1038 o o o o 1039 LLN 1041 Figure 12: P-DAO-ACK to root 1043 As a result, a transversal route is installed that does not need to 1044 follow the DODAG structure. 1046 ------+--------- 1047 | Internet 1048 | 1049 +-----+ 1050 | | Border Router 1051 | | (RPL Root) 1052 +-----+ 1053 | 1054 o o o o 1055 o o o o o o o o o 1056 o o o o o o o o o o 1057 o o o o o o o o o 1058 S>>A>>>B>>C>>>D o o o 1059 o o o o 1060 LLN 1062 Figure 13: Projected Transversal Route 1064 Authors' Addresses 1066 Pascal Thubert (editor) 1067 Cisco Systems 1068 Village d'Entreprises Green Side 1069 400, Avenue de Roumanille 1070 Batiment T3 1071 Biot - Sophia Antipolis 06410 1072 FRANCE 1074 Phone: +33 4 97 23 26 34 1075 Email: pthubert@cisco.com 1077 Rahul Arvind Jadhav 1078 Huawei Tech 1079 Kundalahalli Village, Whitefield, 1080 Bangalore, Karnataka 560037 1081 India 1083 Phone: +91-080-49160700 1084 Email: rahul.ietf@gmail.com 1085 Matthew Gillmore 1086 Itron, Inc 1087 Building D 1088 2111 N Molter Road 1089 Liberty Lake 99019 1090 United States 1092 Phone: +1.800.635.5461 1093 Email: matthew.gillmore@itron.com 1095 James Pylakutty 1096 Cisco Systems 1097 Cessna Business Park 1098 Kadubeesanahalli 1099 Marathalli ORR 1100 Bangalore, Karnataka 560087 1101 INDIA 1103 Phone: +91 80 4426 4140 1104 Email: mundenma@cisco.com