idnits 2.17.1 draft-ietf-roll-dao-projection-05.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 21, 2018) is 1951 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) == Unused Reference: 'RFC6553' is defined on line 633, but no explicit reference was found in the text == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-19 == Outdated reference: A later version (-13) exists of draft-ietf-detnet-architecture-10 Summary: 0 errors (**), 0 flaws (~~), 4 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. Jadhav 5 Expires: June 24, 2019 Huawei Tech 6 M. Gillmore 7 Itron 8 J. Pylakutty 9 Cisco 10 December 21, 2018 12 Root initiated routing state in RPL 13 draft-ietf-roll-dao-projection-05 15 Abstract 17 This document proposes a protocol extension to RPL that enables 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. As opposed to the classical 21 route injection in RPL that are injected by the end devices, this 22 draft enables the root of the DODAG to projects the routes that are 23 needed 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 June 24, 2019. 42 Copyright Notice 44 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.2. Subset of a 6LoWPAN Glossary . . . . . . . . . . . . . . 4 63 2.3. New Terms . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.4. References . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Extending RFC 6550 . . . . . . . . . . . . . . . . . . . . . 5 66 3.1. RPL Instances . . . . . . . . . . . . . . . . . . . . . . 5 67 3.2. New RPL Control Message Options . . . . . . . . . . . . . 6 68 3.3. Projected DAO . . . . . . . . . . . . . . . . . . . . . . 7 69 3.3.1. Non-Storing Mode P-Route . . . . . . . . . . . . . . 8 70 3.3.2. Storing-Mode P-Route . . . . . . . . . . . . . . . . 10 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 73 5.1. New RPL Control Codes . . . . . . . . . . . . . . . . . . 12 74 5.2. Error in Projected Route ICMPv6 Code . . . . . . . . . . 13 75 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 78 7.2. Informative References . . . . . . . . . . . . . . . . . 15 79 Appendix A. Applications . . . . . . . . . . . . . . . . . . . . 15 80 A.1. Loose Source Routing in Non-storing Mode . . . . . . . . 15 81 A.2. Transversal Routes in storing and non-storing modes . . . 17 82 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 19 83 B.1. Using storing mode P-DAO in non-storing mode MOP . . . . 19 84 B.2. Projecting a storing-mode transversal route . . . . . . . 20 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 87 1. Introduction 89 The "Routing Protocol for Low Power and Lossy Networks" [RFC6550] 90 (LLN)(RPL) is a generic Distance Vector protocol that is well suited 91 low energy Internet of Things (IoT) networks. RPL forms Destination 92 Oriented Directed Acyclic Graphs (DODAGs) in which the root often 93 acts as the Border Router to connect the RPL domain to the Internet. 94 The root is responsible to select the RPL Instance that is used to 95 forward a packet coming from the Internet into the RPL domain and set 96 the related RPL information in the packets. 98 The 6TiSCH architecture [I-D.ietf-6tisch-architecture] leverages RPL 99 for its routing operation and considers the Deterministic Networking 100 Architecture [I-D.ietf-detnet-architecture] as one possible model 101 whereby the device resources and capabilities are exposed to an 102 external controller which installs routing states into the network 103 based on some objective functions that reside in that external 104 entity. 106 Based on heuristics of usage, path length, and knowledge of device 107 capacity and available resources such as battery levels and 108 reservable buffers, a Path Computation Element ([PCE]) with a global 109 visibility on the system could install additional P2P routes that are 110 more optimized for the current needs as expressed by the objective 111 function. 113 This draft enables a RPL root to install and maintain projected 114 routes (P-Routes) within its DODAG, along a selected set of nodes 115 that may or may not include self, for a chosen duration. This 116 potentially enables routes that are more optimized than those 117 obtained with the distributed operation of RPL, either in terms of 118 the size of a source-route header or in terms of path length, which 119 impacts both the latency and the packet delivery ratio. P-routes may 120 be installed in either Storing and Non-Storing Modes Instances of the 121 classical RPL operation, resulting in potentially hybrid situations 122 where the mode of some P-routes is different from that of the other 123 routes in the RPL Instance. 125 P-Routes must be used with the parsimony to limit the amount of state 126 that is installed in each device to fit within its resources, and to 127 limit the amount of rerouted traffic to fit within the capabilities 128 of the transmission links. The algorithm used to compute the paths 129 and the protocol used to learn the topology of the network and the 130 resources that are available in devices and in the network are out of 131 scope for this document. Possibly with the assistance of a Path 132 Computation Element ([PCE]) that could have a better visibility on 133 the larger system, the root computes which segment could be optimized 134 and uses this draft to install the corresponding P-Routes. 136 2. Terminology 138 2.1. BCP 14 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 142 "OPTIONAL" in this document are to be interpreted as described in BCP 143 14 [RFC2119][RFC8174] when, and only when, they appear in all 144 capitals, as shown here. 146 2.2. Subset of a 6LoWPAN Glossary 148 This document often uses the following acronyms: 150 6BBR: 6LoWPAN Backbone Router 152 6LBR: 6LoWPAN Border Router 154 6LN: 6LoWPAN Node 156 6LR: 6LoWPAN Router 158 6CIO: Capability Indication Option 160 EARO: (Extended) Address Registration Option -- (E)ARO 162 EDAR: (Extended) Duplicate Address Request -- (E)DAR 164 EDAC: (Extended) Duplicate Address Confirmation -- (E)DAC 166 DAD: Duplicate Address Detection 168 DODAG: Destination-Oriented Directed Acyclic Graph 170 LLN: Low-Power and Lossy Network 172 NA: Neighbor Advertisement 174 NCE: Neighbor Cache Entry 176 ND: Neighbor Discovery 178 NDP: Neighbor Discovery Protocol 180 NS: Neighbor Solicitation 182 RPL: IPv6 Routing Protocol for LLNs (pronounced ripple) [RFC6550] 184 RA: Router Advertisement 186 RS: Router Solicitation 188 2.3. New Terms 190 P-Route: A route that is installed remotely by a RPL root. 192 2.4. References 194 In this document, readers will encounter terms and concepts that are 195 discussed in the following documents: 197 o "Routing Protocol for Low Power and Lossy Networks" [RFC6550], and 199 o "Terminology in Low power And Lossy Networks" [RFC7102]. 201 3. Extending RFC 6550 203 Section 6.7 of RPL [RFC6550] specifies Control Message Options (CMO) 204 to be placed in RPL messages such as the Destination Advertisement 205 Object (DAO) message. The RPL Target Option and the Transit 206 Information Option (TIO) are such options. In Non-Storing Mode, the 207 TIO option is used in the DAO message to indicate the immediate 208 parent of a given path. The TIO applies to the Target options that 209 immedially preceed it. Options may be factorized; multiple TIOs may 210 be present to indicate multiple routes to the one or more contiguous 211 addressed indicated in the Target Options that immediately precede 212 the TIOs in the RPL message. 214 This specification introduces two new Control Message Options 215 referred to as Route Projection Options (RPO). One RPO is the 216 Information option (VIO) and the other is the Source-Routed VIO 217 (SRVIO). The VIO installs a route on each hop along a P-Route (in a 218 fashion analogous to RPL Storing Mode) whereas the SRVIO installs a 219 source-routing state at the ingress node, which uses it to insert a 220 routing header in a fashion similar to Non-Storing Mode. 222 Like the TIO, the RPOs MUST be preceded by one or more RPL Target 223 Options to which they apply, and they can be factorized: multiple 224 contiguous RPOs indicate alternate paths to the target(s). 226 3.1. RPL Instances 228 It must be noted that RPL has a concept of instance but does not have 229 a concept of an administrative distance, which exists in certain 230 proprietary implementations to sort out conflicts between multiple 231 sources of routing information. This draft conforms the instance 232 model as follows: 234 o If the PCE needs to influence a particular instance to add better 235 routes in conformance with the routing objectives in that 236 instance, it may do so. When the PCE modifies an existing 237 instance then the added routes must not create a loop in that 238 instance. This is achieved by always preferring a route obtained 239 from the PCE over a route that is learned via RPL. 241 o If the PCE installs a more specific (say, Traffic Engineered) 242 route between a particular pair of nodes then it SHOULD use a 243 Local Instance from the ingress node of that path. A packet 244 associated with that instance will be routed along that path and 245 MUST NOT be placed over a Global Instance again. A packet that is 246 placed on a Global Instance may be injected in the Local Instance 247 based on node policy and the Local Instance paramenters. 249 In all cases, the path is indicated by a new Via Information option, 250 and the flow is similar to the flow used to obtain loose source 251 routing. 253 3.2. New RPL Control Message Options 255 The format of RPOs is as follows: 257 0 1 2 3 258 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 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Type | Option Length | Path Sequence | Path Lifetime | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | | 263 + + 264 . . 265 . Via Address 1 . 266 . . 267 + + 268 | | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | | 271 . .... . 272 | | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | | 275 + + 276 . . 277 . Via Address n . 278 . . 279 + + 280 | | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 Figure 1: Via Information option format 285 Option Type: 0x0A for VIO, 0x0B for SRVIO (to be confirmed by IANA) 286 Option Length: In bytes; variable, depending on the number of Via 287 Addresses. 289 Path Sequence: 8-bit unsigned integer. When a RPL Target option is 290 issued by the root of the DODAG (i.e. in a DAO message), that 291 root sets the Path Sequence and increments the Path Sequence 292 each time it issues a RPL Target option with updated 293 information. The indicated sequence deprecates any state for a 294 given Target that was learned from a previous sequence and adds 295 to any state that was learned for that sequence. 297 Path Lifetime: 8-bit unsigned integer. The length of time in 298 Lifetime Units (obtained from the Configuration option) that 299 the prefix is valid for route determination. The period starts 300 when a new Path Sequence is seen. A value of 255 (0xFF) 301 represents infinity. A value of zero (0x00) indicates a loss 302 of reachability. A DAO message that contains a Via Information 303 option with a Path Lifetime of zero for a Target is referred as 304 a No-Path (for that Target) in this document. 306 Via Address: 16 bytes. IPv6 Address of the next hop towards the 307 destination(s) indicated in the target option that immediately 308 precede the RPO. Via Addresses are indicated in the order of 309 the data path from the ingress to the egress nodes. 311 An RPO MUST contain at least one Via Address, and a Via Address MUST 312 NOT be present more than once, otherwise the RPO MUST be ignored. 314 3.3. Projected DAO 316 This draft adds a capability to RPL whereby the root of a DODAG 317 projects a route by sending an extended DAO message called a 318 Projected-DAO (P-DAO) to an arbitrary router in the DODAG, indicating 319 one or more sequence(s) of routers inside the DODAG via which the 320 target(s) indicated in the Target Information Option(s) (TIO) can be 321 reached. 323 A P-DAO is sent from a global address of the root to a global address 324 of the recipient, and MUST be confirmed by a DAO-ACK, which is sent 325 back to a global address of the root. 327 A P-DAO message MUST contain at least one TIO and at least one RPO 328 following it. There can be at most one such sequence of TIOs and 329 then RPOs. 331 Like a classical DAO message, a P-DAO is processed only if it is 332 "new" per section 9.2.2. "Generation of DAO Messages" of the RPL 333 specification [RFC6550]; this is determined using the Path Sequence 334 information from the RPO as opposed to a TIO. Also, a Path Lifetime 335 of 0 in an RPO indicates that a route is to be removed. 337 There are two kinds of operation for the P-Routes, the Storing Mode 338 and the Non-Storing Mode. 340 o The Non-Storing Mode is discussed in Section 3.3.1. It uses an 341 SRVIO that carries a list of Via Addresses to be used as a source- 342 routed path to the target. The recipient of the P-DAO is the 343 ingress router of the source-routed path. Upon a Non-Storing Mode 344 P-DAO, the ingress router installs a source-routed state to the 345 target and replies to the root directly with a DAO-ACK message. 347 o The Storing Mode is discussed in Section 3.3.2. It uses a VIO 348 with one Via Address per consecutive hop, from the ingress to the 349 egress of the path, including the list of all intermediate routers 350 in the data path order. The Via Addresses indicate the routers in 351 which the routing state to the target have to be installed via the 352 next Via Address in the VIO. In normal operations, the P-DAO is 353 propagated along the chain of Via Routers from the egress router 354 of the path till the ingress one, which confirms the installation 355 to the root with a DAO-ACK message. Note that the root may be the 356 ingress and it may be the egress of the path, that it can also be 357 neither but it cannot be both. 359 In case of a forwarding error along a P-Route, an ICMP error is sent 360 to the root with a new Code "Error in Projected Route" (See 361 Section 5.2). The root can then modify or remove the P-Route. The 362 "Error in Projected Route" message has the same format as the 363 "Destination Unreachable Message", as specified in RFC 4443 364 [RFC4443]. The portion of the invoking packet that is sent back in 365 the ICMP message SHOULD record at least up to the routing header if 366 one is present, and the routing header SHOULD be consumed by this 367 node so that the destination in the IPv6 header is the next hop that 368 this node could not reach. if a 6LoWPAN Routing Header (6LoRH) 369 [RFC8138] is used to carry the IPv6 routing information in the outter 370 header then that whole 6LoRH information SHOULD be present in the 371 ICMP message. The sender and exact operation depend on the Mode and 372 is described in Section 3.3.1 and Section 3.3.2 respectively. 374 3.3.1. Non-Storing Mode P-Route 376 As illustrated in Figure 2, a P-DAO that carries an SRVIO enables the 377 root to install a source-routed path towards a target in any 378 particular router; with this path information the router can add a 379 source routed header reflecting the P-route to any packet for which 380 the current destination either is the said target or can be reached 381 via the target. 383 ------+--------- 384 | Internet 385 | 386 +-----+ 387 | | Border Router 388 | | (RPL Root) 389 +-----+ | P ^ | 390 | | DAO | ACK | Loose 391 o o o o router V | | Source 392 o o o o o o o o o | P-DAO . Route 393 o o o o o o o o o o | Source . Path 394 o o o o o o o o o | Route . From 395 o o o o o o o o | Path . Root 396 o o o o o target V . To 397 o o o o | Desti- 398 o o o o | nation 399 destination V 401 LLN 403 Figure 2: Projecting a Non-Storing Route 405 A route indicated by an SRVIO may be loose, meaning that the node 406 that owns the next listed Via Address is not necessarily a neighbor. 407 Without proper loop avoidance mechanisms, the interaction of loose 408 source routing and other mechanisms may effectively cause loops. In 409 order to avoid those loops, if the router that installs a P-route 410 does not have a connected route (a direct adjacency) to the next 411 soure routed hop and fails to locate it as a neighbor or a neighbor 412 of a neighbor, then it MUST ensure that it has another P-Route to the 413 next loose hop under the control of the same route computation 414 system, otherwise the P-DAO is rejected. 416 When forwarding a packet to a destination for which the router 417 determines that routing happens via the target, the router inserts 418 the source routing header in the packet to reach the target. In the 419 case of a loose source-routed path, there MUST be either a neighbor 420 that is adjacent to the loose next hop, on which case the packet s 421 forwarded to that neighbor, or a source-routed path to the loose next 422 hop; in the latter case, another encapsulation takes place and the 423 process possibly recurses; otherwise the packet is dropped. 425 In order to add a source-routing header, the router encapsulates the 426 packet with an IP-in-IP header and a non-storing mode source routing 427 header (SRH) [RFC6554]. In the uncompressed form the source of the 428 packet would be self, the destination would be the first Via Address 429 in the SRVIO, and the SRH would contain the list of the remaining Via 430 Addresses and then the target. 432 In practice, the router will normally use the "IPv6 over Low-Power 433 Wireless Personal Area Network (6LoWPAN) Paging Dispatch" [RFC8025] 434 to compress the RPL artifacts as indicated in the "6LoWPAN Routing 435 Header" [RFC8138] specification. In that case, the router indicates 436 self as encapsulator in an IP-in-IP 6LoRH Header, and places the list 437 of Via Addresses in the order of the VIO and then the target in the 438 SRH 6LoRH Header. 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.3.2. Storing-Mode P-Route 452 As illustrated in Figure 3, 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 3: 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. Security Considerations 553 This draft uses messages that are already present in RPL [RFC6550] 554 with optional secured versions. The same secured versions may be 555 used with this draft, and whatever security is deployed for a given 556 network also applies to the flows in this draft. 558 TODO: should probably consider how P-DAO messages could be abused by 559 a) rogue nodes b) via replay of messages c) if use of P-DAO messages 560 could in fact deal with any threats? 562 5. IANA Considerations 564 5.1. New RPL Control Codes 566 This document extends the IANA registry created by RFC 6550 for RPL 567 Control Codes as follows: 569 +------+-------------------+---------------+ 570 | Code | Description | Reference | 571 +------+-------------------+---------------+ 572 | 0x0A | Via | This document | 573 | | | | 574 | 0x0B | Source-Routed Via | This document | 575 +------+-------------------+---------------+ 577 RPL Control Codes 579 This document is updating the registry created by RFC 6550 for the 580 RPL 3-bit Mode of Operation (MOP) as follows: 582 +-----------+----------------------------------------+--------------+ 583 | MOP value | Description | Reference | 584 +-----------+----------------------------------------+--------------+ 585 | 5 | Non-Storing mode of operation with | This | 586 | | P-Routes | document | 587 | | | | 588 | 6 | Storing mode of operation with | This | 589 | | P-Routes | document | 590 +-----------+----------------------------------------+--------------+ 592 DIO Mode of operation 594 5.2. Error in Projected Route ICMPv6 Code 596 In some cases RPL will return an ICMPv6 error message when a message 597 cannot be forwarded along a P-Route. This ICMPv6 error message is 598 "Error in Projected Route". 600 IANA has defined an ICMPv6 "Code" Fields Registry for ICMPv6 Message 601 Types. ICMPv6 Message Type 1 describes "Destination Unreachable" 602 codes. This specification requires that a new code is allocated from 603 the ICMPv6 Code Fields Registry for ICMPv6 Message Type 1, for "Error 604 in Projected Route", with a suggested code value of 8, to be 605 confirmed by IANA. 607 6. Acknowledgments 609 The authors wish to acknowledge JP Vasseur and Patrick Wetterwald for 610 their contributions to the ideas developed here. 612 7. References 613 7.1. Normative References 615 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 616 Requirement Levels", BCP 14, RFC 2119, 617 DOI 10.17487/RFC2119, March 1997, 618 . 620 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 621 Control Message Protocol (ICMPv6) for the Internet 622 Protocol Version 6 (IPv6) Specification", STD 89, 623 RFC 4443, DOI 10.17487/RFC4443, March 2006, 624 . 626 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 627 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 628 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 629 Low-Power and Lossy Networks", RFC 6550, 630 DOI 10.17487/RFC6550, March 2012, 631 . 633 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 634 Power and Lossy Networks (RPL) Option for Carrying RPL 635 Information in Data-Plane Datagrams", RFC 6553, 636 DOI 10.17487/RFC6553, March 2012, 637 . 639 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 640 Routing Header for Source Routes with the Routing Protocol 641 for Low-Power and Lossy Networks (RPL)", RFC 6554, 642 DOI 10.17487/RFC6554, March 2012, 643 . 645 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 646 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 647 RFC 8025, DOI 10.17487/RFC8025, November 2016, 648 . 650 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 651 "IPv6 over Low-Power Wireless Personal Area Network 652 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 653 April 2017, . 655 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 656 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 657 May 2017, . 659 7.2. Informative References 661 [I-D.ietf-6tisch-architecture] 662 Thubert, P., "An Architecture for IPv6 over the TSCH mode 663 of IEEE 802.15.4", draft-ietf-6tisch-architecture-19 (work 664 in progress), December 2018. 666 [I-D.ietf-detnet-architecture] 667 Finn, N., Thubert, P., Varga, B., and J. Farkas, 668 "Deterministic Networking Architecture", draft-ietf- 669 detnet-architecture-10 (work in progress), December 2018. 671 [PCE] IETF, "Path Computation Element", 672 . 674 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and 675 J. Martocci, "Reactive Discovery of Point-to-Point Routes 676 in Low-Power and Lossy Networks", RFC 6997, 677 DOI 10.17487/RFC6997, August 2013, 678 . 680 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 681 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 682 2014, . 684 Appendix A. Applications 686 A.1. Loose Source Routing in Non-storing Mode 688 A RPL implementation operating in a very constrained LLN typically 689 uses the Non-Storing Mode of Operation as represented in Figure 4. 690 In that mode, a RPL node indicates a parent-child relationship to the 691 root, using a Destination Advertisement Object (DAO) that is unicast 692 from the node directly to the root, and the root typically builds a 693 source routed path to a destination down the DODAG by recursively 694 concatenating this information. 696 ------+--------- 697 | Internet 698 | 699 +-----+ 700 | | Border Router 701 | | (RPL Root) 702 +-----+ ^ | | 703 | | DAO | ACK | 704 o o o o | | | Strict 705 o o o o o o o o o | | | Source 706 o o o o o o o o o o | | | Route 707 o o o o o o o o o | | | 708 o o o o o o o o | v v 709 o o o o 710 LLN 712 Figure 4: RPL non-storing mode of operation 714 Based on the parent-children relationships expressed in the non- 715 storing DAO messages,the root possesses topological information about 716 the whole network, though this information is limited to the 717 structure of the DODAG for which it is the destination. A packet 718 that is generated within the domain will always reach the root, which 719 can then apply a source routing information to reach the destination 720 if the destination is also in the DODAG. Similarly, a packet coming 721 from the outside of the domain for a destination that is expected to 722 be in a RPL domain reaches the root. 724 It results that the root, or then some associated centralized 725 computation engine such as a PCE, can determine the amount of packets 726 that reach a destination in the RPL domain, and thus the amount of 727 energy and bandwidth that is wasted for transmission, between itself 728 and the destination, as well as the risk of fragmentation, any 729 potential delays because of a paths longer than necessary (shorter 730 paths exist that would not traverse the root). 732 As a network gets deep, the size of the source routing header that 733 the root must add to all the downward packets becomes an issue for 734 nodes that are many hops away. In some use cases, a RPL network 735 forms long lines and a limited amount of well-targeted routing state 736 would allow to make the source routing operation loose as opposed to 737 strict, and save packet size. Limiting the packet size is directly 738 beneficial to the energy budget, but, mostly, it reduces the chances 739 of frame loss and/or packet fragmentation, which is highly 740 detrimental to the LLN operation. Because the capability to store a 741 routing state in every node is limited, the decision of which route 742 is installed where can only be optimized with a global knowledge of 743 the system, a knowledge that the root or an associated PCE may 744 possess by means that are outside of the scope of this specification. 746 This specification enables to store source-routed or storing mode 747 state in intermediate routers, which enables to limit the excursion 748 of the source route headers in deep networks. Once a P-DAO exchange 749 has taken place for a given target, if the root operates in non 750 storing mode, then it may elide the sequence of routers that is 751 installed in the network from its source route headers to destination 752 that are reachable via that target, and the source route headers 753 effectively become loose. 755 A.2. Transversal Routes in storing and non-storing modes 757 RPL is optimized for Point-to-Multipoint (P2MP) and Multipoint-to- 758 Point (MP2P), whereby routes are always installed along the RPL DODAG 759 respectively from and towards the DODAG Root. Transversal Peer to 760 Peer (P2P) routes in a RPL network will generally suffer from some 761 elongated (stretched) path versus the best possible path, since 762 routing between 2 nodes always happens via a common parent, as 763 illustrated in Figure 5: 765 o in non-storing mode, all packets routed within the DODAG flow all 766 the way up to the root of the DODAG. If the destination is in the 767 same DODAG, the root must encapsulate the packet to place a 768 Routing Header that has the strict source route information down 769 the DODAG to the destination. This will be the case even if the 770 destination is relatively close to the source and the root is 771 relatively far off. 773 o In storing mode, unless the destination is a child of the source, 774 the packets will follow the default route up the DODAG as well. 775 If the destination is in the same DODAG, they will eventually 776 reach a common parent that has a route to the destination; at 777 worse, the common parent may also be the root. From that common 778 parent, the packet will follow a path down the DODAG that is 779 optimized for the Objective Function that was used to build the 780 DODAG. 782 ------+--------- 783 | Internet 784 | 785 +-----+ 786 | | Border Router 787 | | (RPL Root) 788 +-----+ 789 X 790 ^ v o o 791 ^ o o v o o o o o 792 ^ o o o v o o o o o 793 ^ o o v o o o o o 794 S o o o D o o o 795 o o o o 796 LLN 798 Figure 5: Routing Stretch between S and D via common parent X 800 It results that it is often beneficial to enable transversal P2P 801 routes, either if the RPL route presents a stretch from shortest 802 path, or if the new route is engineered with a different objective. 803 For that reason, earlier work at the IETF introduced the "Reactive 804 Discovery of Point-to-Point Routes in Low Power and Lossy Networks" 805 [RFC6997], which specifies a distributed method for establishing 806 optimized P2P routes. This draft proposes an alternate based on a 807 centralized route computation. 809 ------+--------- 810 | Internet 811 | 812 +-----+ 813 | | Border Router 814 | | (RPL Root) 815 +-----+ 816 | 817 o o o o 818 o o o o o o o o o 819 o o o o o o o o o o 820 o o o o o o o o o 821 S>>A>>>B>>C>>>D o o o 822 o o o o 823 LLN 825 Figure 6: Projected Transversal Route 827 This specification enables to store source-routed or storing mode 828 state in intermediate routers, which enables to limit the stretch of 829 a P2P route and maintain the characteristics within a given SLA. An 830 example of service using this mechanism oculd be a control loop that 831 would be installed in a network that uses classical RPL for 832 asynchronous data collection. In that case, the P2P path may be 833 installed in a different RPL Instance, with a different objective 834 function. 836 Appendix B. Examples 838 B.1. Using storing mode P-DAO in non-storing mode MOP 840 In non-storing mode, the DAG root maintains the knowledge of the 841 whole DODAG topology, so when both the source and the destination of 842 a packet are in the DODAG, the root can determine the common parent 843 that would have been used in storing mode, and thus the list of nodes 844 in the path between the common parent and the destination. For 845 instance in the diagram shown in Figure 7, if the source is node 41 846 and the destination is node 52, then the common parent is node 22. 848 ------+--------- 849 | Internet 850 | 851 +-----+ 852 | | Border Router 853 | | (RPL Root) 854 +-----+ 855 | \ \____ 856 / \ \ 857 o 11 o 12 o 13 858 / | / \ 859 o 22 o 23 o 24 o 25 860 / \ | \ \ 861 o 31 o 32 o o o 35 862 / / | \ | \ 863 o 41 o 42 o o o 45 o 46 864 | | | | \ | 865 o 51 o 52 o 53 o o 55 o 56 867 LLN 869 Figure 7: Example DODAG forming a logical tree topology 871 With this draft, the root can install a storing mode routing states 872 along a segment that is either from itself to the destination, or 873 from one or more common parents for a particular source/destination 874 pair towards that destination (in this particular example, this would 875 be the segment made of nodes 22, 32, 42). 877 In the example below, say that there is a lot of traffic to nodes 55 878 and 56 and the root decides to reduce the size of routing headers to 879 those destinations. The root can first send a DAO to node 45 880 indicating target 55 and a Via segment (35, 45), as well as another 881 DAO to node 46 indicating target 56 and a Via segment (35, 46). This 882 will save one entry in the routing header on both sides. The root 883 may then send a DAO to node 35 indicating targets 55 and 56 a Via 884 segment (13, 24, 35) to fully optimize that path. 886 Alternatively, the root may send a DAO to node 45 indicating target 887 55 and a Via segment (13, 24, 35, 45) and then a DAO to node 46 888 indicating target 56 and a Via segment (13, 24, 35, 46), indicating 889 the same DAO Sequence. 891 B.2. Projecting a storing-mode transversal route 893 In this example, say that a PCE determines that a path must be 894 installed between node S and node D via routers A, B and C, in order 895 to serve the needs of a particular application. 897 The root sends a P-DAO with a target option indicating the 898 destination D and a sequence Via Information option, one for S, which 899 is the ingress router of the segment, one for A and then for B, which 900 are an intermediate routers, and one for C, which is the egress 901 router. 903 ------+--------- 904 | Internet 905 | 906 +-----+ 907 | | Border Router 908 | | (RPL Root) 909 +-----+ 910 | P-DAO message to C 911 o | o o 912 o o o | o o o o o 913 o o o | o o o o o o 914 o o V o o o o o o 915 S A B C D o o o 916 o o o o 917 LLN 919 Figure 8: P-DAO from root 921 Upon reception of the P-DAO, C validates that it can reach D, e.g. 922 using IPv6 Neighbor Discovery, and if so, propagates the P-DAO 923 unchanged to B. 925 B checks that it can reach C and of so, installs a route towards D 926 via C. Then it propagates the P-DAO to A. 928 The process recurses till the P-DAO reaches S, the ingress of the 929 segment, which installs a route to D via A and sends a DAO-ACK to the 930 root. 932 ------+--------- 933 | Internet 934 | 935 +-----+ 936 | | Border Router 937 | | (RPL Root) 938 +-----+ 939 ^ P-DAO-ACK from S 940 / o o o 941 / o o o o o o o 942 | o o o o o o o o o 943 | o o o o o o o o 944 S A B C D o o o 945 o o o o 946 LLN 948 Figure 9: P-DAO-ACK to root 950 As a result, a transversal route is installed that does not need to 951 follow the DODAG structure. 953 ------+--------- 954 | Internet 955 | 956 +-----+ 957 | | Border Router 958 | | (RPL Root) 959 +-----+ 960 | 961 o o o o 962 o o o o o o o o o 963 o o o o o o o o o o 964 o o o o o o o o o 965 S>>A>>>B>>C>>>D o o o 966 o o o o 967 LLN 969 Figure 10: Projected Transversal Route 971 Authors' Addresses 973 Pascal Thubert (editor) 974 Cisco Systems 975 Village d'Entreprises Green Side 976 400, Avenue de Roumanille 977 Batiment T3 978 Biot - Sophia Antipolis 06410 979 FRANCE 981 Phone: +33 4 97 23 26 34 982 Email: pthubert@cisco.com 984 Rahul Arvind Jadhav 985 Huawei Tech 986 Kundalahalli Village, Whitefield, 987 Bangalore, Karnataka 560037 988 India 990 Phone: +91-080-49160700 991 Email: rahul.ietf@gmail.com 993 Matthew Gillmore 994 Itron, Inc 995 Building D 996 2111 N Molter Road 997 Liberty Lake 99019 998 United States 1000 Phone: +1.800.635.5461 1001 Email: matthew.gillmore@itron.com 1003 James Pylakutty 1004 Cisco Systems 1005 Cessna Business Park 1006 Kadubeesanahalli 1007 Marathalli ORR 1008 Bangalore, Karnataka 560087 1009 INDIA 1011 Phone: +91 80 4426 4140 1012 Email: mundenma@cisco.com