idnits 2.17.1 draft-ietf-roll-dao-projection-04.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 (June 19, 2018) is 2137 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: 'RFC6551' is defined on line 735, but no explicit reference was found in the text == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-14 == Outdated reference: A later version (-13) exists of draft-ietf-detnet-architecture-05 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 4 Intended status: Standards Track R. Jadhav 5 Expires: December 21, 2018 Huawei Tech 6 J. Pylakutty 7 Cisco 8 June 19, 2018 10 Root initiated routing state in RPL 11 draft-ietf-roll-dao-projection-04 13 Abstract 15 This document proposes a protocol extension to RPL that enables to 16 install a limited amount of centrally-computed routes in a RPL graph, 17 enabling loose source routing down a non-storing mode DODAG, or 18 transversal routes inside the DODAG. As opposed to the classical 19 route injection in RPL that are injected by the end devices, this 20 draft enables the root of the DODAG to projects the routes that are 21 needed on the nodes where they should be installed. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 21, 2018. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.2. References . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.3. Subset of a 6LoWPAN Glossary . . . . . . . . . . . . . . 4 62 2.4. New Terms . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Extending RFC 6550 . . . . . . . . . . . . . . . . . . . . . 5 64 4. New RPL Control Message Options . . . . . . . . . . . . . . . 5 65 5. Projected DAO . . . . . . . . . . . . . . . . . . . . . . . . 7 66 5.1. Non-storing Mode Projected Route . . . . . . . . . . . . 8 67 5.2. Storing-Mode Projected Route . . . . . . . . . . . . . . 9 68 6. Applications . . . . . . . . . . . . . . . . . . . . . . . . 11 69 6.1. Loose Source Routing in Non-storing Mode . . . . . . . . 11 70 6.2. Transversal Routes in storing and non-storing modes . . . 13 71 7. RPL Instances . . . . . . . . . . . . . . . . . . . . . . . . 15 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 73 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 74 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 75 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 76 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 77 11.2. Informative References . . . . . . . . . . . . . . . . . 17 78 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 18 79 A.1. Using storing mode P-DAO in non-storing mode MOP . . . . 18 80 A.2. Projecting a storing-mode transversal route . . . . . . . 19 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 83 1. Introduction 85 The "Routing Protocol for Low Power and Lossy Networks" [RFC6550] 86 (LLN)(RPL) is a generic Distance Vector protocol that is well suited 87 for application in a variety of low energy Internet of Things (IoT) 88 networks. RPL forms Destination Oriented Directed Acyclic Graphs 89 (DODAGs) in which the root often acts as the Border Router to connect 90 the RPL domain to the Internet. The root is responsible to select 91 the RPL Instance that is used to forward a packet coming from the 92 Internet into the RPL domain and set the related RPL information in 93 the packets. 95 The 6TiSCH architecture [I-D.ietf-6tisch-architecture] leverages RPL 96 for its routing operation and considers the Deterministic Networking 97 Architecture [I-D.ietf-detnet-architecture] as one possible model 98 whereby the device resources and capabilities are exposed to an 99 external controller which installs routing states into the network 100 based on some objective functions that reside in that external 101 entity. 103 Based on heuristics of usage, path length, and knowledge of device 104 capacity and available resources such as battery levels and 105 reservable buffers, a Path Computation Element ([PCE]) with a global 106 visibility on the system could install additional P2P routes that are 107 more optimized for the current needs as expressed by the objective 108 function. 110 This draft enables a RPL root to install and maintain projected 111 routes (P-routes) within its DODAG, along a selected set of nodes 112 that may or may not include self, for a chosen duration. This 113 potentially enables routes that are more optimized than those 114 obtained with the distributed operation of RPL, either in terms of 115 the size of a source-route header or in terms of path length, which 116 impacts both the latency and the packet delivery ratio. P-routes may 117 be installed in either Storing and Non-Storing Modes Instances of the 118 classical RPL operation, resulting in potentially hybrid situations 119 where the mode of some P-routes is different from that of the other 120 routes in the RPL Instance. 122 Projected routes must be used with the parsimony to limit the amount 123 of state that is installed in each device to fit within its 124 resources, and to limit the amount of rerouted traffic to fit within 125 the capabilities of the transmission links. The algorithm used to 126 compute the paths and the protocol used to learn the topology of the 127 network and the resources that are available in devices and in the 128 network are out of scope for this document. Possibly with the 129 assistance of a Path Computation Element ([PCE]) that could have a 130 better visibility on the larger system, the root computes which 131 segment could be optimized and uses this draft to install the 132 corresponding projected routes. 134 2. Terminology 136 2.1. BCP 14 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 140 "OPTIONAL" in this document are to be interpreted as described in BCP 141 14 [RFC2119][RFC8174] when, and only when, they appear in all 142 capitals, as shown here. 144 2.2. References 146 In this document, readers will encounter terms and concepts that are 147 discussed in the following documents: 149 o "Routing Protocol for Low Power and Lossy Networks" [RFC6550], and 151 o "Terminology in Low power And Lossy Networks" [RFC7102]. 153 2.3. Subset of a 6LoWPAN Glossary 155 This document often uses the following acronyms: 157 6BBR: 6LoWPAN Backbone Router 159 6LBR: 6LoWPAN Border Router 161 6LN: 6LoWPAN Node 163 6LR: 6LoWPAN Router 165 6CIO: Capability Indication Option 167 EARO: (Extended) Address Registration Option -- (E)ARO 169 EDAR: (Extended) Duplicate Address Request -- (E)DAR 171 EDAC: (Extended) Duplicate Address Confirmation -- (E)DAC 173 DAD: Duplicate Address Detection 175 DODAG: Destination-Oriented Directed Acyclic Graph 177 LLN: Low-Power and Lossy Network 179 NA: Neighbor Advertisement 181 NCE: Neighbor Cache Entry 183 ND: Neighbor Discovery 185 NDP: Neighbor Discovery Protocol 187 NS: Neighbor Solicitation 189 RPL: IPv6 Routing Protocol for LLNs (pronounced ripple) [RFC6550] 191 RA: Router Advertisement 192 RS: Router Solicitation 194 2.4. New Terms 196 Projected Route: A route that is installed remotely by a RPL root. 198 3. Extending RFC 6550 200 Section 6.7 of RPL [RFC6550] specifies Control Message Options (CMO) 201 to be placed in RPL messages such as the Destination Advertisement 202 Object (DAO) message. The RPL Target Option and the Transit 203 Information Option (TIO) are such options; the former indicates a 204 node to be reached and the latter specifies a parent that can be used 205 to reach that node. Options may be factorized; one or more 206 contiguous TIOs apply to the one or more contiguous Target options 207 that immediately precede the TIOs in the RPL message. 209 This specification introduces 2 new Control Message Options referred 210 to as Route Projection Options (RPO). One RPO is the Information 211 option (VIO) and the other is the Source-Routed VIO (SRVIO). The VIO 212 installs a route on each hop along a projected route (in a fashion 213 analogous to RPL Storing Mode) whereas the SRVIO installs a source- 214 routing state at the ingress node, which uses it to insert a routing 215 header in a fashion similar to Non-Storing Mode. 217 Like the TIO, the RPOs MUST be preceded by one or more RPL Target 218 Options to which they apply, and they can be factorized: multiple 219 contiguous RPOs indicate alternate paths to the target(s). 221 4. New RPL Control Message Options 223 The format of RPOs is as follows: 225 0 1 2 3 226 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 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Type | Option Length | Path Sequence | Path Lifetime | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | | 231 + + 232 . . 233 . Via Address 1 . 234 . . 235 + + 236 | | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | | 239 . .... . 240 | | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | | 243 + + 244 . . 245 . Via Address n . 246 . . 247 + + 248 | | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 Figure 1: Via Information option format 253 Option Type: 0x0A for VIO, 0x0B for SRVIO (to be confirmed by IANA) 255 Option Length: In bytes; variable, depending on the number of Via 256 Addresses. 258 Path Sequence: 8-bit unsigned integer. When a RPL Target option is 259 issued by the root of the DODAG (i.e. in a DAO message), that 260 root sets the Path Sequence and increments the Path Sequence 261 each time it issues a RPL Target option with updated 262 information. The indicated sequence deprecates any state for a 263 given Target that was learned from a previous sequence and adds 264 to any state that was learned for that sequence. 266 Path Lifetime: 8-bit unsigned integer. The length of time in 267 Lifetime Units (obtained from the Configuration option) that 268 the prefix is valid for route determination. The period starts 269 when a new Path Sequence is seen. A value of all one bits 270 (0xFF) represents infinity. A value of all zero bits (0x00) 271 indicates a loss of reachability. A DAO message that contains 272 a Via Information option with a Path Lifetime of 0x00 for a 273 Target is referred as a No-Path (for that Target) in this 274 document. 276 Via Address: 16 bytes. IPv6 Address of the next hop towards the 277 destination(s) indicated in the target option that immediately 278 precede the RPO. Via Addresses are indicated in the order of 279 the data path from the ingress to the egress nodes. TBD: See 280 how the /64 prefix can be elided if it is the same as that of 281 (all of) the target(s). In that case, the Next-Hop Address 282 could be expressed as the 8-bytes suffix only. 284 An RPO MUST contain at least one Via Address, and a Via Address MUST 285 NOT be present more than once, otherwise the RPO MUST be ignored. 287 5. Projected DAO 289 This draft adds a capability to RPL whereby the root of a DODAG 290 projects a route by sending an extended DAO message called a 291 Projected-DAO (P-DAO) to an arbitrary router in the DODAG, indicating 292 one or more sequence(s) of routers inside the DODAG via which the 293 target(s) indicated in the Target Information Option(s) (TIO) can be 294 reached. 296 A P-DAO is sent from a global address of the root to a global address 297 of the recipient, and MUST be confirmed by a DAO-ACK, which is sent 298 back to a global address of the root. 300 A P-DAO message MUST contain at least one TIO and at least one RPO 301 following it. There can be at most one such sequence of TIOs and 302 then RPOs. 304 Like a classical DAO message, a P-DAO is processed only if it is 305 "new" per section 9.2.2. "Generation of DAO Messages" of the RPL 306 specification [RFC6550]; this is determined using the Path Sequence 307 information from the RPO as opposed to a TIO. Also, a Path Lifetime 308 of 0 in an RPO indicates that a route is to be removed. 310 There are two kinds of operation for the projected routes, the 311 Storing Mode and the Non-Storing Mode. 313 The Non-Storing Mode is discussed in section Section 5.1. It uses 314 an SRVIO that carries a list of Via Addresses to be used as a 315 source-routed path to the target. The recipient of the P-DAO is 316 the ingress router of the source-routed path. Upon a Non-Storing 317 Mode P-DAO, the ingress router installs a source-routed state to 318 the target and replies to the root directly with a DAO-ACK 319 message. 321 The Storing Mode is discussed in section Section 5.2. It uses a 322 VIO with one Via Address per consecutive hop, from the ingress to 323 the egress of the path, including the list of all intermediate 324 routers in the data path order. The Via Addresses indicate the 325 routers in which the routing state to the target have to be 326 installed via the next Via Address in the VIO. In normal 327 operations, the P-DAO is propagated along the chain of Via Routers 328 from the egress router of the path till the ingress one, which 329 confirms the installation to the root with a DAO-ACK message. 330 Note that the root may be the ingress and it may be the egress of 331 the path, that it can also be neither but it cannot be both. 333 5.1. Non-storing Mode Projected Route 335 As illustrated in Figure 2, a P-DAO that carries an SRVIO enables the 336 root to install a source-routed path towards a target in any 337 particular router; with this path information the router can add a 338 source routed header reflecting the P-route to any packet for which 339 the current destination either is the said target or can be reached 340 via the target. 342 ------+--------- 343 | Internet 344 | 345 +-----+ 346 | | Border Router 347 | | (RPL Root) 348 +-----+ | P ^ | 349 | | DAO | ACK | Loose 350 o o o o router V | | Source 351 o o o o o o o o o | P-DAO . Route 352 o o o o o o o o o o | Source . Path 353 o o o o o o o o o | Route . From 354 o o o o o o o o | Path . Root 355 o o o o o target V . To 356 o o o o | Desti- 357 o o o o | nation 358 destination V 360 LLN 362 Figure 2: Projecting a Non-Storing Route 364 A route indicated by an SRVIO may be loose, meaning that the node 365 that owns the next listed Via Address is not necessarily a neighbor. 366 Without proper loop avoidance mechanisms, the interaction of loose 367 source routing and other mechanisms may effectively cause loops. In 368 order to avoid those loops, if the router that installs a P-route 369 does not have a connected route (a direct adjacency) to the next 370 soure routed hop and fails to locate it as a neighbor or a neighbor 371 of a neighbor, then it MUST ensure that it has another projected 372 route to the next loose hop under the control of the same route 373 computation system, otherwise the P-DAO is rejected. 375 When forwarding a packet to a destination for which the router 376 determines that routing happens via the target, the router inserts 377 the source routing header in the packet to reach the target. In the 378 case of a loose source-routed path, there MUST be either a neighbor 379 that is adjacent to the loose next hop, on which case the packet s 380 forwarded to that neighbor, or a source-routed path to the loose next 381 hop; in the latter case, another encapsulation takes place and the 382 process possibly recurses; otherwise the packet is dropped. 384 In order to add a source-routing header, the router encapsulates the 385 packet with an IP-in-IP header and a non-storing mode source routing 386 header (SRH) [RFC6554]. 388 In the uncompressed form the source of the packet would be self, the 389 destination would be the first Via Address in the SRVIO, and the SRH 390 would contain the list of the remaining Via Addresses and then the 391 target. 393 In practice, the router will normally use the "IPv6 over Low-Power 394 Wireless Personal Area Network (6LoWPAN) Paging Dispatch" [RFC8025] 395 to compress the RPL artifacts as indicated in the "6LoWPAN Routing 396 Header" [RFC8138] specification. In that case, the router indicates 397 self as encapsulator in an IP-in-IP 6LoRH Header, and places the list 398 of Via Addresses in the order of the VIO and then the target in the 399 SRH 6LoRH Header. 401 5.2. Storing-Mode Projected Route 403 As illustrated in Figure 3, the Storing Mode projected iq used by the 404 root to install a routing state towards a target in the routers along 405 a segment between an ingress and an egress router; this enables the 406 routers to forward along that segment any packet for which the next 407 loose hop is the said target, for instance a loose source routed 408 packet for which the next loose hop is the target, or a packet for 409 which the router has a routing state to the final destination via the 410 target. 412 ------+--------- 413 | Internet 414 | 415 +-----+ 416 | | Border Router 417 | | (RPL Root) 418 +-----+ | ^ | 419 | | DAO | ACK | 420 o o o o | | | 421 o o o o o o o o o | ^ | Projected . 422 o o o o o o o o o o | | DAO | Route . 423 o o o o o o o o o | ^ | . 424 o o o o o o o o v | DAO v . 425 o o LLN o o o | 426 o o o o o Loose Source Route Path | 427 o o o o From Root To Destination v 429 Figure 3: Projecting a route 431 In order to install the relevant routing state along the segment 432 between an ingress and an egress routers, the root sends a unicast 433 P-DAO message to the egress router of the routing segment that must 434 be installed. The P-DAO message contains the ordered list of hops 435 along the segment as a direct sequence of Via Information options 436 that are preceded by one or more RPL Target options to which they 437 relate. Each Via Information option contains a Path Lifetime for 438 which the state is to be maintained. 440 The root sends the P-DAO directly to the egress node of the segment. 441 In that P-DAO, the destination IP address matches the Via Address in 442 the last VIO. This is how the egress recognizes its role. In a 443 similar fashion, the ingress node recognizes its role as it matches 444 Via Address in the first VIO. 446 The egress node of the segment is the only node in the path that does 447 not install a route in response to the P-DAO; it is expected to be 448 already able to route to the target(s) on its own. It may either be 449 the target, or may have some existing information to reach the 450 target(s), such as a connected route or an already installed 451 projected route. If one of the targets cannot be located, the node 452 MUST answer to the root with a negative DAO-ACK listing the target(s) 453 that could not be located (suggested status 10 to be confirmed by 454 IANA). 456 If the egress node can reach all the targets, then it forwards the 457 P-DAO with unchanged content to its loose predecessor in the segment 458 as indicated in the list of Via Information options, and recursively 459 the message is propagated unchanged along the sequence of routers 460 indicated in the P-DAO, but in the reverse order, from egress to 461 ingress. 463 The address of the predecessor to be used as destination of the 464 propagated DAO message is found in the Via Information option the 465 precedes the one that contain the address of the propagating node, 466 which is used as source of the packet. 468 Upon receiving a propagated DAO, an intermediate router as well as 469 the ingress router install a route towards the DAO target(s) via its 470 successor in the P-DAO; the router locates the VIO that contains its 471 address, and uses as next hop the address found in the Via Address 472 field in the following VIO. The router MAY install additional routes 473 towards the addresses that are located in VIOs that are after the 474 next one, if any, but in case of a conflict or a lack of resource, a 475 route to a target installed by the root has precedence. 477 The process recurses till the P-DAO is propagated to ingress router 478 of the segment, which answers with a DAO-ACK to the root. 480 Also, the path indicated in a P-DAO may be loose, in which case the 481 reachability to the next hop has to be asserted. Each router along 482 the path indicated in a P-DAO is expected to be able to reach its 483 successor, either with a connected route (direct neighbor), or by 484 routing, for instance following a route installed previously by a DAO 485 or a P-DAO message. If that route is not connected then a recursive 486 lookup may take place at packet forwarding time to find the next hop 487 to reach the target(s). If it does not and cannot reach the next 488 router in the P-DAO, the router MUST answer to the root with a 489 negative DAO-ACK indicating the successor that is unreachable 490 (suggested status 11 to be confirmed by IANA). 492 A Path Lifetime of 0 in a Via Information option is used to clean up 493 the state. The P-DAO is forwarded as described above, but the DAO is 494 interpreted as a No-Path DAO and results in cleaning up existing 495 state as opposed to refreshing an existing one or installing a new 496 one. 498 6. Applications 500 6.1. Loose Source Routing in Non-storing Mode 502 A RPL implementation operating in a very constrained LLN typically 503 uses the Non-Storing Mode of Operation as represented in Figure 4. 504 In that mode, a RPL node indicates a parent-child relationship to the 505 root, using a Destination Advertisement Object (DAO) that is unicast 506 from the node directly to the root, and the root typically builds a 507 source routed path to a destination down the DODAG by recursively 508 concatenating this information. 510 ------+--------- 511 | Internet 512 | 513 +-----+ 514 | | Border Router 515 | | (RPL Root) 516 +-----+ ^ | | 517 | | DAO | ACK | 518 o o o o | | | Strict 519 o o o o o o o o o | | | Source 520 o o o o o o o o o o | | | Route 521 o o o o o o o o o | | | 522 o o o o o o o o | v v 523 o o o o 524 LLN 526 Figure 4: RPL non-storing mode of operation 528 Based on the parent-children relationships expressed in the non- 529 storing DAO messages,the root possesses topological information about 530 the whole network, though this information is limited to the 531 structure of the DODAG for which it is the destination. A packet 532 that is generated within the domain will always reach the root, which 533 can then apply a source routing information to reach the destination 534 if the destination is also in the DODAG. Similarly, a packet coming 535 from the outside of the domain for a destination that is expected to 536 be in a RPL domain reaches the root. 538 It results that the root, or then some associated centralized 539 computation engine such as a PCE, can determine the amount of packets 540 that reach a destination in the RPL domain, and thus the amount of 541 energy and bandwidth that is wasted for transmission, between itself 542 and the destination, as well as the risk of fragmentation, any 543 potential delays because of a paths longer than necessary (shorter 544 paths exist that would not traverse the root). 546 As a network gets deep, the size of the source routing header that 547 the root must add to all the downward packets becomes an issue for 548 nodes that are many hops away. In some use cases, a RPL network 549 forms long lines and a limited amount of well-targeted routing state 550 would allow to make the source routing operation loose as opposed to 551 strict, and save packet size. Limiting the packet size is directly 552 beneficial to the energy budget, but, mostly, it reduces the chances 553 of frame loss and/or packet fragmentation, which is highly 554 detrimental to the LLN operation. Because the capability to store a 555 routing state in every node is limited, the decision of which route 556 is installed where can only be optimized with a global knowledge of 557 the system, a knowledge that the root or an associated PCE may 558 possess by means that are outside of the scope of this specification. 560 This specification enables to store source-routed or storing mode 561 state in intermediate routers, which enables to limit the excursion 562 of the source route headers in deep networks. Once a P-DAO exchange 563 has taken place for a given target, if the root operates in non 564 storing mode, then it may elide the sequence of routers that is 565 installed in the network from its source route headers to destination 566 that are reachable via that target, and the source route headers 567 effectively become loose. 569 6.2. Transversal Routes in storing and non-storing modes 571 RPL is optimized for Point-to-Multipoint (P2MP), root to leaves and 572 Multipoint-to-Point (MP2P) leaves to root operations, whereby routes 573 are always installed along the RPL DODAG. Transversal Peer to Peer 574 (P2P) routes in a RPL network will generally suffer from some stretch 575 since routing between 2 peers always happens via a common parent, as 576 illustrated in Figure 5: 578 o in non-storing mode, all packets routed within the DODAG flow all 579 the way up to the root of the DODAG. If the destination is in the 580 same DODAG, the root must encapsulate the packet to place a 581 Routing Header that has the strict source route information down 582 the DODAG to the destination. This will be the case even if the 583 destination is relatively close to the source and the root is 584 relatively far off. 586 o In storing mode, unless the destination is a child of the source, 587 the packets will follow the default route up the DODAG as well. 588 If the destination is in the same DODAG, they will eventually 589 reach a common parent that has a route to the destination; at 590 worse, the common parent may also be the root. From that common 591 parent, the packet will follow a path down the DODAG that is 592 optimized for the Objective Function that was used to build the 593 DODAG. 595 ------+--------- 596 | Internet 597 | 598 +-----+ 599 | | Border Router 600 | | (RPL Root) 601 +-----+ 602 X 603 ^ v o o 604 ^ o o v o o o o o 605 ^ o o o v o o o o o 606 ^ o o v o o o o o 607 S o o o D o o o 608 o o o o 609 LLN 611 Figure 5: Routing Stretch between S and D via common parent X 613 It results that it is often beneficial to enable transversal P2P 614 routes, either if the RPL route presents a stretch from shortest 615 path, or if the new route is engineered with a different objective. 616 For that reason, earlier work at the IETF introduced the "Reactive 617 Discovery of Point-to-Point Routes in Low Power and Lossy Networks" 618 [RFC6997], which specifies a distributed method for establishing 619 optimized P2P routes. This draft proposes an alternate based on a 620 centralized route computation. 622 ------+--------- 623 | Internet 624 | 625 +-----+ 626 | | Border Router 627 | | (RPL Root) 628 +-----+ 629 | 630 o o o o 631 o o o o o o o o o 632 o o o o o o o o o o 633 o o o o o o o o o 634 S>>A>>>B>>C>>>D o o o 635 o o o o 636 LLN 638 Figure 6: Projected Transversal Route 640 This specification enables to store source-routed or storing mode 641 state in intermediate routers, which enables to limit the stretch of 642 a P2P route and maintain the characteristics within a given SLA. An 643 example of service using this mechanism oculd be a control loop that 644 would be installed in a network that uses classical RPL for 645 asynchronous data collection. In that case, the P2P path may be 646 installed in a different RPL Instance, with a different objective 647 function. 649 7. RPL Instances 651 It must be noted that RPL has a concept of instance but does not have 652 a concept of an administrative distance, which exists in certain 653 proprietary implementations to sort out conflicts between multiple 654 sources of routing information. This draft conforms the instance 655 model as follows: 657 o If the PCE needs to influence a particular instance to add better 658 routes in conformance with the routing objectives in that 659 instance, it may do so. When the PCE modifies an existing 660 instance then the added routes must not create a loop in that 661 instance. This is achieved by always preferring a route obtained 662 from the PCE over a route that is learned via RPL. 664 o If the PCE installs a more specific (say, Traffic Engineered) 665 route between a particular pair of nodes then it SHOULD use a 666 Local Instance from the ingress node of that path. A packet 667 associated with that instance will be routed along that path and 668 MUST NOT be placed over a Global Instance again. A packet that is 669 placed on a Global Instance may be injected in the Local Instance 670 based on node policy and the Local Instance paramenters. 672 In all cases, the path is indicated by a new Via Information option, 673 and the flow is similar to the flow used to obtain loose source 674 routing. 676 8. Security Considerations 678 This draft uses messages that are already present in RPL [RFC6550] 679 with optional secured versions. The same secured versions may be 680 used with this draft, and whatever security is deployed for a given 681 network also applies to the flows in this draft. 683 9. IANA Considerations 685 This document extends the IANA registry created by RFC 6550 for RPL 686 Control Codes as follows: 688 +------+-------------------+---------------+ 689 | Code | Description | Reference | 690 +------+-------------------+---------------+ 691 | 0x0A | Via | This document | 692 | | | | 693 | 0x0B | Source-Routed Via | This document | 694 +------+-------------------+---------------+ 696 RPL Control Codes 698 This document is updating the registry created by RFC 6550 for the 699 RPL 3-bit Mode of Operation (MOP) as follows: 701 +----------+------------------------------------------+-------------+ 702 | MOP | Description | Reference | 703 | value | | | 704 +----------+------------------------------------------+-------------+ 705 | 5 | Non-Storing mode of operation with | This | 706 | | Projected routes | document | 707 | | | | 708 | 6 | Storing mode of operation with Projected | This | 709 | | routes | document | 710 +----------+------------------------------------------+-------------+ 712 DIO Mode of operation 714 10. Acknowledgments 716 The authors wish to acknowledge JP Vasseur and Patrick Wetterwald for 717 their contributions to the ideas developed here. 719 11. References 721 11.1. Normative References 723 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 724 Requirement Levels", BCP 14, RFC 2119, 725 DOI 10.17487/RFC2119, March 1997, 726 . 728 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 729 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 730 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 731 Low-Power and Lossy Networks", RFC 6550, 732 DOI 10.17487/RFC6550, March 2012, 733 . 735 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 736 and D. Barthel, "Routing Metrics Used for Path Calculation 737 in Low-Power and Lossy Networks", RFC 6551, 738 DOI 10.17487/RFC6551, March 2012, 739 . 741 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 742 Routing Header for Source Routes with the Routing Protocol 743 for Low-Power and Lossy Networks (RPL)", RFC 6554, 744 DOI 10.17487/RFC6554, March 2012, 745 . 747 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 748 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 749 RFC 8025, DOI 10.17487/RFC8025, November 2016, 750 . 752 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 753 "IPv6 over Low-Power Wireless Personal Area Network 754 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 755 April 2017, . 757 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 758 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 759 May 2017, . 761 11.2. Informative References 763 [I-D.ietf-6tisch-architecture] 764 Thubert, P., "An Architecture for IPv6 over the TSCH mode 765 of IEEE 802.15.4", draft-ietf-6tisch-architecture-14 (work 766 in progress), April 2018. 768 [I-D.ietf-detnet-architecture] 769 Finn, N., Thubert, P., Varga, B., and J. Farkas, 770 "Deterministic Networking Architecture", draft-ietf- 771 detnet-architecture-05 (work in progress), May 2018. 773 [PCE] IETF, "Path Computation Element", 774 . 776 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and 777 J. Martocci, "Reactive Discovery of Point-to-Point Routes 778 in Low-Power and Lossy Networks", RFC 6997, 779 DOI 10.17487/RFC6997, August 2013, 780 . 782 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 783 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 784 2014, . 786 Appendix A. Examples 788 A.1. Using storing mode P-DAO in non-storing mode MOP 790 In non-storing mode, the DAG root maintains the knowledge of the 791 whole DODAG topology, so when both the source and the destination of 792 a packet are in the DODAG, the root can determine the common parent 793 that would have been used in storing mode, and thus the list of nodes 794 in the path between the common parent and the destination. For 795 instance in the diagram shown in Figure 7, if the source is node 41 796 and the destination is node 52, then the common parent is node 22. 798 ------+--------- 799 | Internet 800 | 801 +-----+ 802 | | Border Router 803 | | (RPL Root) 804 +-----+ 805 | \ \____ 806 / \ \ 807 o 11 o 12 o 13 808 / | / \ 809 o 22 o 23 o 24 o 25 810 / \ | \ \ 811 o 31 o 32 o o o 35 812 / / | \ | \ 813 o 41 o 42 o o o 45 o 46 814 | | | | \ | 815 o 51 o 52 o 53 o o 55 o 56 817 LLN 819 Figure 7: Example DODAG forming a logical tree topology 821 With this draft, the root can install a storing mode routing states 822 along a segment that is either from itself to the destination, or 823 from one or more common parents for a particular source/destination 824 pair towards that destination (in this particular example, this would 825 be the segment made of nodes 22, 32, 42). 827 In the example below, say that there is a lot of traffic to nodes 55 828 and 56 and the root decides to reduce the size of routing headers to 829 those destinations. The root can first send a DAO to node 45 830 indicating target 55 and a Via segment (35, 45), as well as another 831 DAO to node 46 indicating target 56 and a Via segment (35, 46). This 832 will save one entry in the routing header on both sides. The root 833 may then send a DAO to node 35 indicating targets 55 and 56 a Via 834 segment (13, 24, 35) to fully optimize that path. 836 Alternatively, the root may send a DAO to node 45 indicating target 837 55 and a Via segment (13, 24, 35, 45) and then a DAO to node 46 838 indicating target 56 and a Via segment (13, 24, 35, 46), indicating 839 the same DAO Sequence. 841 A.2. Projecting a storing-mode transversal route 843 In this example, say that a PCE determines that a path must be 844 installed between node S and node D via routers A, B and C, in order 845 to serve the needs of a particular application. 847 The root sends a P-DAO with a target option indicating the 848 destination D and a sequence Via Information option, one for S, which 849 is the ingress router of the segment, one for A and then for B, which 850 are an intermediate routers, and one for C, which is the egress 851 router. 853 ------+--------- 854 | Internet 855 | 856 +-----+ 857 | | Border Router 858 | | (RPL Root) 859 +-----+ 860 | Projected DAO message to C 861 o | o o 862 o o o | o o o o o 863 o o o | o o o o o o 864 o o V o o o o o o 865 S A B C D o o o 866 o o o o 867 LLN 869 Figure 8: Projected DAO from root 871 Upon reception of the P-DAO, C validates that it can reach D, e.g. 872 using IPv6 Neighbor Discovery, and if so, propagates the P-DAO 873 unchanged to B. 875 B checks that it can reach C and of so, installs a route towards D 876 via C. Then it propagates the P-DAO to A. 878 The process recurses till the P-DAO reaches S, the ingress of the 879 segment, which installs a route to D via A and sends a DAO-ACK to the 880 root. 882 ------+--------- 883 | Internet 884 | 885 +-----+ 886 | | Border Router 887 | | (RPL Root) 888 +-----+ 889 ^ Projected DAO-ACK from S 890 / o o o 891 / o o o o o o o 892 | o o o o o o o o o 893 | o o o o o o o o 894 S A B C D o o o 895 o o o o 896 LLN 898 Figure 9: Projected DAO-ACK to root 900 As a result, a transversal route is installed that does not need to 901 follow the DODAG structure. 903 ------+--------- 904 | Internet 905 | 906 +-----+ 907 | | Border Router 908 | | (RPL Root) 909 +-----+ 910 | 911 o o o o 912 o o o o o o o o o 913 o o o o o o o o o o 914 o o o o o o o o o 915 S>>A>>>B>>C>>>D o o o 916 o o o o 917 LLN 919 Figure 10: Projected Transversal Route 921 Authors' Addresses 922 Pascal Thubert (editor) 923 Cisco Systems 924 Village d'Entreprises Green Side 925 400, Avenue de Roumanille 926 Batiment T3 927 Biot - Sophia Antipolis 06410 928 FRANCE 930 Phone: +33 4 97 23 26 34 931 Email: pthubert@cisco.com 933 Rahul Arvind Jadhav 934 Huawei Tech 935 Kundalahalli Village, Whitefield, 936 Bangalore, Karnataka 560037 937 India 939 Phone: +91-080-49160700 940 Email: rahul.ietf@gmail.com 942 James Pylakutty 943 Cisco Systems 944 Cessna Business Park 945 Kadubeesanahalli 946 Marathalli ORR 947 Bangalore, Karnataka 560087 948 INDIA 950 Phone: +91 80 4426 4140 951 Email: mundenma@cisco.com