idnits 2.17.1 draft-ietf-roll-dao-projection-02.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 (September 19, 2017) is 2410 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: A later version (-30) exists of draft-ietf-6tisch-architecture-12 == Outdated reference: A later version (-13) exists of draft-ietf-detnet-architecture-03 Summary: 0 errors (**), 0 flaws (~~), 3 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 J. Pylakutty 4 Intended status: Standards Track Cisco 5 Expires: March 23, 2018 September 19, 2017 7 Root initiated routing state in RPL 8 draft-ietf-roll-dao-projection-02 10 Abstract 12 This document proposes a protocol extension to RPL that enables to 13 install a limited amount of centrally-computed routes in a RPL graph, 14 enabling loose source routing down a non-storing mode DODAG, or 15 transversal routes inside the DODAG. As opposed to the classical 16 route injection in RPL that are injected by the end devices, this 17 draft enables the root of the DODAG to projects the routes that are 18 needed on the nodes where they should be installed. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on March 23, 2018. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. New RPL Control Message Options . . . . . . . . . . . . . . . 3 57 3.1. Via Information Option . . . . . . . . . . . . . . . . . 4 58 4. Projected DAO . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4.1. Non-storing Mode Projected DAO . . . . . . . . . . . . . 6 60 4.2. Storing-Mode Projected DAO . . . . . . . . . . . . . . . 8 61 5. Applications . . . . . . . . . . . . . . . . . . . . . . . . 10 62 5.1. Loose Source Routing in Non-storing Mode . . . . . . . . 10 63 5.2. Transversal Routes in storing and non-storing modes . . . 11 64 6. RPL Instances . . . . . . . . . . . . . . . . . . . . . . . . 13 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 67 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 69 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 70 10.2. Informative References . . . . . . . . . . . . . . . . . 15 71 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 16 72 A.1. Using storing mode P-DAO in non-storing mode MOP . . . . 16 73 A.2. Projecting a storing-mode transversal route . . . . . . . 17 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 76 1. Introduction 78 The "Routing Protocol for Low Power and Lossy Networks" [RFC6550] 79 (LLN)(RPL) is a generic Distance Vector protocol that is well suited 80 for application in a variety of low energy Internet of Things (IoT) 81 networks. RPL forms Destination Oriented Directed Acyclic Graphs 82 (DODAGs) in which the root often acts as the Border Router to connect 83 the RPL domain to the Internet. The root is responsible to select 84 the RPL Instance that is used to forward a packet coming from the 85 Internet into the RPL domain and set the related RPL information in 86 the packets. 88 The 6TiSCH architecture [I-D.ietf-6tisch-architecture] leverages RPL 89 for its routing operation and considers the Deterministic Networking 90 Architecture [I-D.ietf-detnet-architecture] as one possible model 91 whereby the device resources and capabilities are exposed to an 92 external controller which installs routing states into the network 93 based on some objective functions that reside in that external 94 entity. 96 Based on heuristics of usage, path length, and knowledge of device 97 capacity and available resources such as battery levels and 98 reservable buffers, a Path Computation Element ([PCE]) with a global 99 visibility on the system could install additional P2P routes that are 100 more optimized for the current needs as expressed by the objective 101 function. 103 This draft enables a RPL root, with optionally the assistance of a 104 PCE, to install and maintain additional storing and non-storing mode 105 routes within the RPL domain, along a selected set of nodes and for a 106 selected duration, thus providing routes more suitable than those 107 obtained with the distributed operation of RPL. Those routes may be 108 installed in either storing and non-storing modes RPL instances, 109 resulting in potentially hybrid situations where the mode of the 110 projected routes is different from that of the other routes in the 111 instance. 113 2. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 The Terminology used in this document is consistent with and 120 incorporates that described in "Terminology in Low power And Lossy 121 Networks"[RFC7102] and [RFC6550]. 123 3. New RPL Control Message Options 125 Section 6.7 of RPL [RFC6550] specifies Control Message Options (CMO) 126 to be placed in RPL messages such as the Destination Advertisement 127 Object (DAO) message. The RPL Target Option and the Transit 128 Information Option (TIO) are such options; the former indicates a 129 node to be reached and the latter specifies a parent that can be used 130 to reach that node. Options may be factorized; one or more 131 contiguous TIOs apply to the one or more contiguous Target options 132 that immediately precede the TIOs in the RPL message. 134 This specification introduces a new Control Message Option, the Via 135 Information option (VIO). Like the TIO, the VIO MUST be preceded by 136 one or more RPL Target options to which it applies. Unlike the TIO, 137 the VIO are not factorized: multiple contiguous Via options indicate 138 an ordered sequence of routers to reach the target(s), presented in 139 the order of the packet stream, source to destination, and in which a 140 routing state must be installed. 142 The Via Information option MUST contain at least one Via Address. 144 3.1. Via Information Option 146 The Via Information option MAY be present in DAO messages, and its 147 format is as follows: 149 0 1 2 3 150 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 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Type = 0x0A | Option Length | Path Sequence | Path Lifetime | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | | 155 + + 156 . . 157 . Via Address 1 . 158 . . 159 + + 160 | | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | | 163 . .... . 164 | | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | | 167 + + 168 . . 169 . Via Address n . 170 . . 171 + + 172 | | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 Figure 1: Via Information option format 177 Option Type: 0x0A (to be confirmed by IANA) 179 Option Length: In bytes; variable, depending on the number of Via 180 Addresses. 182 Path Sequence: 8-bit unsigned integer. When a RPL Target option is 183 issued by the root of the DODAG (i.e. in a DAO message), that 184 root sets the Path Sequence and increments the Path Sequence 185 each time it issues a RPL Target option with updated 186 information. The indicated sequence deprecates any state for a 187 given Target that was learned from a previous sequence and adds 188 to any state that was learned for that sequence. 190 Path Lifetime: 8-bit unsigned integer. The length of time in 191 Lifetime Units (obtained from the Configuration option) that 192 the prefix is valid for route determination. The period starts 193 when a new Path Sequence is seen. A value of all one bits 194 (0xFF) represents infinity. A value of all zero bits (0x00) 195 indicates a loss of reachability. A DAO message that contains 196 a Via Information option with a Path Lifetime of 0x00 for a 197 Target is referred as a No-Path (for that Target) in this 198 document. 200 Via Address: 16 bytes. IPv6 Address of the next hop towards the 201 destination(s) indicated in the target option that immediately 202 precede the VIO. TBD: See how the /64 prefix can be elided if 203 it is the same as that of (all of) the target(s). In that 204 case, the Next-Hop Address could be expressed as the 8-bytes 205 suffix only, otherwise it is expressed as 16 bytes, at least in 206 storing mode. 208 4. Projected DAO 210 This draft adds a capability to RPL whereby the root projects a route 211 through an extended DAO message called a Projected-DAO (P-DAO) to an 212 arbitrary router down the DODAG, indicating a next hop or a sequence 213 of routers via which a certain destination indicated in the Target 214 Information option may be reached. 216 A P-DAO message MUST contain at least a Target Information option and 217 at least one VIA Information option following it. 219 Like a classical DAO message, a P-DAO is processed only if it is 220 "new" per section 9.2.2. "Generation of DAO Messages" of the RPL 221 specification [RFC6550]; this is determined using the Path Sequence 222 information from the VIO as opposed to a TIO. Also, a Path Lifetime 223 of 0 in a VIO indicates that a route is to be removed. 225 There are two kinds of P-DAO, the storing mode and the non-storing 226 mode ones. 228 The non-storing mode P-DAO discussed in section Section 4.1 has a 229 single VIO with one or more Via Addresses in it, the list of Via 230 Addresses indicating the source-routed path to the target to be 231 installed in the router that receives the message, which replies 232 to the root directly with a DAO-ACK message. 234 The storing mode P-DAO discussed in section Section 4.2 has at 235 least two Via Information options with one Via Address each, for 236 the ingress and the egress of the path, and more if there are 237 intermediate routers. The Via Addresses indicate the routers in 238 which the routing state to the target have to be installed via the 239 next Via Address in the sequence of VIO. In normal operations, 240 the P-DAO is propagated along the chain of Via Routers from the 241 egress router of the path till the ingress one, which confirms the 242 installation to the root with a DAO-ACK message. Note that the 243 root may be the ingress and it may be the egress of the path, that 244 it can also be neither but it cannot be both. 246 The root is expected to use these mechanisms optimally and with 247 required parsimony to limit the state installed in the devices to fit 248 within their resources, but how the root figures the amount of 249 resources that is available in each device is out of scope for this 250 document. 252 In particular, the draft expects that the root has enough information 253 about the capability for each node to store a number of routes, which 254 can be discovered for instance using a Network Management System 255 (NMS) and/or the RPL routing extensions specified in "Routing for 256 Path Calculation in LLNs" [RFC6551]. 258 A route that is installed by a P-DAO is not necessarily installed 259 along the DODAG, though how the root and the optional PCE obtain the 260 additional topological information to compute other routes is out of 261 scope for this document 263 4.1. Non-storing Mode Projected DAO 265 As illustrated in Figure 2, the non-storing mode P-DAO enables the 266 root to install a source-routed path towards a target in any 267 particular router; with this path information the router can add a 268 source routed header reflecting the path to any packet for which the 269 current destination either is the said target or can be reached via 270 the target, for instance a loose source routed packet for which the 271 next loose hop is the target, or a packet for which the router has a 272 routing state to the final destination via the target. 274 ------+--------- 275 | Internet 276 | 277 +-----+ 278 | | Border Router 279 | | (RPL Root) 280 +-----+ | P ^ | 281 | | DAO | ACK | Loose 282 o o o o router V | | Source 283 o o o o o o o o o | P-DAO . Route 284 o o o o o o o o o o | Source . Path 285 o o o o o o o o o | Route . From 286 o o o o o o o o | Path . Root 287 o o o o o target V . To 288 o o o o | Desti- 289 o o o o | nation 290 destination V 292 LLN 294 Figure 2: Projecting a Non-Storing route 296 A router that receives a non-storing P-DAO installs a source routed 297 path towards each of the consecutive targets via a source route path 298 indicated in the following VIO. 300 When forwarding a packet to a destination for which the router 301 determines that routing happens via the target, the router inserts 302 the source routing header in the packet to reach the target. 304 In order to do so, the router encapsulates the packet with an IP in 305 IP header and a non-storing mode source routing header (SRH) 306 [RFC6554]. 308 In the uncompressed form the source of the packet would be self, the 309 destination would be the first Via Address in the VIO, and the SRH 310 would contain the list of the remaining Via Addresses and then the 311 target. 313 In practice, the router will normally use the "IPv6 over Low-Power 314 Wireless Personal Area Network (6LoWPAN) Paging Dispatch" [RFC8025] 315 to compress the RPL artifacts as indicated in the "6LoWPAN Routing 316 Header" [RFC8138] specification. In that case, the router indicates 317 self as encapsulator in an IP-in-IP 6LoRH Header, and places the list 318 of Via Addresses in the order of the VIO and then the target in the 319 SRH 6LoRH Header. 321 4.2. Storing-Mode Projected DAO 323 As illustrated in Figure 3, the storing mode P-DAO enables the root 324 to install a routing state towards a target in the routers along a 325 segment between an ingress and an egress router; this enables the 326 routers to forward along that segment any packet for which the next 327 loose hop is the said target, for instance a loose source routed 328 packet for which the next loose hop is the target, or a packet for 329 which the router has a routing state to the final destination via the 330 target. 332 ------+--------- 333 | Internet 334 | 335 +-----+ 336 | | Border Router 337 | | (RPL Root) 338 +-----+ | ^ | 339 | | DAO | ACK | 340 o o o o | | | 341 o o o o o o o o o | ^ | Projected . 342 o o o o o o o o o o | | DAO | Route . 343 o o o o o o o o o | ^ | . 344 o o o o o o o o v | DAO v . 345 o o LLN o o o | 346 o o o o o Loose Source Route Path | 347 o o o o From Root To Destination v 349 Figure 3: Projecting a route 351 Based on available topological, usage and capabilities node 352 information, the root or an associated PCE computes which segment 353 should be optimized and which relevant state should be installed in 354 which nodes. The algorithm is out of scope but it is envisaged that 355 the root could compute the ratio between the optimal path (existing 356 path not traversing the root, and the current path), the application 357 service level agreement (SLA) for specific flows that could benefit 358 from shorter paths, the energy wasted in the network, local 359 congestion on various links that would benefit from having flows 360 routed along alternate paths. 362 In order to install the relevant routing state along the segment 363 between an ingress and an egress routers, the root sends a unicast 364 P-DAO message to the egress router of the routing segment that must 365 be installed. The P-DAO message contains the ordered list of hops 366 along the segment as a direct sequence of Via Information options 367 that are preceded by one or more RPL Target options to which they 368 relate. Each Via Information option contains a Path Lifetime for 369 which the state is to be maintained. 371 The root sends the P-DAO directly to the egress node of the segment, 372 which In that P-DAO, the destination IP address matches the Via 373 Address in the last VIO. This is how the egress recognizes its role. 374 In a similar fashion, the ingress node recognizes its role as it 375 matches Via Address in the first VIO. 377 The egress node of the segment is the only node in the path that does 378 not install a route in response to the P-DAO; it is expected to be 379 already able to route to the target(s) on its own. It may either be 380 the target, or may have some existing information to reach the 381 target(s), such as a connected route or an already installed 382 projected route. If one of the targets cannot be located, the node 383 MUST answer to the root with a negative DAO-ACK listing the target(s) 384 that could not be located (suggested status 10 to be confirmed by 385 IANA). 387 If the egress node can reach all the targets, then it forwards the 388 P-DAO with unchanged content to its loose predecessor in the segment 389 as indicated in the list of Via Information options, and recursively 390 the message is propagated unchanged along the sequence of routers 391 indicated in the P-DAO, but in the reverse order, from egress to 392 ingress. 394 The address of the predecessor to be used as destination of the 395 propagated DAO message is found in the Via Information option the 396 precedes the one that contain the address of the propagating node, 397 which is used as source of the packet. 399 Upon receiving a propagated DAO, an intermediate router as well as 400 the ingress router install a route towards the DAO target(s) via its 401 successor in the P-DAO; the router locates the VIO that contains its 402 address, and uses as next hop the address found in the Via Address 403 field in the following VIO. The router MAY install additional routes 404 towards the addresses that are located in VIOs that are after the 405 next one, if any, but in case of a conflict or a lack of resource, a 406 route to a target installed by the root has precedence. 408 The process recurses till the P-DAO is propagated to ingress router 409 of the segment, which answers with a DAO-ACK to the root. 411 Also, the path indicated in a P-DAO may be loose, in which case the 412 reachability to the next hop has to be asserted. Each router along 413 the path indicated in a P-DAO is expected to be able to reach its 414 successor, either with a connected route (direct neighbor), or by 415 routing, for instance following a route installed previously by a DAO 416 or a P-DAO message. If that route is not connected then a recursive 417 lookup may take place at packet forwarding time to find the next hop 418 to reach the target(s). If it does not and cannot reach the next 419 router in the P-DAO, the router MUST answer to the root with a 420 negative DAO-ACK indicating the successor that is unreachable 421 (suggested status 11 to be confirmed by IANA). 423 A Path Lifetime of 0 in a Via Information option is used to clean up 424 the state. The P-DAO is forwarded as described above, but the DAO is 425 interpreted as a No-Path DAO and results in cleaning up existing 426 state as opposed to refreshing an existing one or installing a new 427 one. 429 5. Applications 431 5.1. Loose Source Routing in Non-storing Mode 433 A RPL implementation operating in a very constrained LLN typically 434 uses the Non-Storing Mode of Operation as represented in Figure 4. 435 In that mode, a RPL node indicates a parent-child relationship to the 436 root, using a Destination Advertisement Object (DAO) that is unicast 437 from the node directly to the root, and the root typically builds a 438 source routed path to a destination down the DODAG by recursively 439 concatenating this information. 441 ------+--------- 442 | Internet 443 | 444 +-----+ 445 | | Border Router 446 | | (RPL Root) 447 +-----+ ^ | | 448 | | DAO | ACK | 449 o o o o | | | Strict 450 o o o o o o o o o | | | Source 451 o o o o o o o o o o | | | Route 452 o o o o o o o o o | | | 453 o o o o o o o o | v v 454 o o o o 455 LLN 457 Figure 4: RPL non-storing mode of operation 459 Based on the parent-children relationships expressed in the non- 460 storing DAO messages,the root possesses topological information about 461 the whole network, though this information is limited to the 462 structure of the DODAG for which it is the destination. A packet 463 that is generated within the domain will always reach the root, which 464 can then apply a source routing information to reach the destination 465 if the destination is also in the DODAG. Similarly, a packet coming 466 from the outside of the domain for a destination that is expected to 467 be in a RPL domain reaches the root. 469 It results that the root, or then some associated centralized 470 computation engine such as a PCE, can determine the amount of packets 471 that reach a destination in the RPL domain, and thus the amount of 472 energy and bandwidth that is wasted for transmission, between itself 473 and the destination, as well as the risk of fragmentation, any 474 potential delays because of a paths longer than necessary (shorter 475 paths exist that would not traverse the root). 477 As a network gets deep, the size of the source routing header that 478 the root must add to all the downward packets becomes an issue for 479 nodes that are many hops away. In some use cases, a RPL network 480 forms long lines and a limited amount of well-targeted routing state 481 would allow to make the source routing operation loose as opposed to 482 strict, and save packet size. Limiting the packet size is directly 483 beneficial to the energy budget, but, mostly, it reduces the chances 484 of frame loss and/or packet fragmentation, which is highly 485 detrimental to the LLN operation. Because the capability to store a 486 routing state in every node is limited, the decision of which route 487 is installed where can only be optimized with a global knowledge of 488 the system, a knowledge that the root or an associated PCE may 489 possess by means that are outside of the scope of this specification. 491 This specification enables to store source-routed or storing mode 492 state in intermediate routers, which enables to limit the excursion 493 of the source route headers in deep networks. Once a P-DAO exchange 494 has taken place for a given target, if the root operates in non 495 storing mode, then it may elide the sequence of routers that is 496 installed in the network from its source route headers to destination 497 that are reachable via that target, and the source route headers 498 effectively become loose. 500 5.2. Transversal Routes in storing and non-storing modes 502 RPL is optimized for Point-to-Multipoint (P2MP), root to leaves and 503 Multipoint-to-Point (MP2P) leaves to root operations, whereby routes 504 are always installed along the RPL DODAG. Transversal Peer to Peer 505 (P2P) routes in a RPL network will generally suffer from some stretch 506 since routing between 2 peers always happens via a common parent, as 507 illustrated in Figure 5: 509 o in non-storing mode, all packets routed within the DODAG flow all 510 the way up to the root of the DODAG. If the destination is in the 511 same DODAG, the root must encapsulate the packet to place a 512 Routing Header that has the strict source route information down 513 the DODAG to the destination. This will be the case even if the 514 destination is relatively close to the source and the root is 515 relatively far off. 517 o In storing mode, unless the destination is a child of the source, 518 the packets will follow the default route up the DODAG as well. 519 If the destination is in the same DODAG, they will eventually 520 reach a common parent that has a route to the destination; at 521 worse, the common parent may also be the root. From that common 522 parent, the packet will follow a path down the DODAG that is 523 optimized for the Objective Function that was used to build the 524 DODAG. 526 ------+--------- 527 | Internet 528 | 529 +-----+ 530 | | Border Router 531 | | (RPL Root) 532 +-----+ 533 X 534 ^ v o o 535 ^ o o v o o o o o 536 ^ o o o v o o o o o 537 ^ o o v o o o o o 538 S o o o D o o o 539 o o o o 540 LLN 542 Figure 5: Routing Stretch between S and D via common parent X 544 It results that it is often beneficial to enable transversal P2P 545 routes, either if the RPL route presents a stretch from shortest 546 path, or if the new route is engineered with a different objective. 547 For that reason, earlier work at the IETF introduced the "Reactive 548 Discovery of Point-to-Point Routes in Low Power and Lossy Networks" 549 [RFC6997], which specifies a distributed method for establishing 550 optimized P2P routes. This draft proposes an alternate based on a 551 centralized route computation. 553 ------+--------- 554 | Internet 555 | 556 +-----+ 557 | | Border Router 558 | | (RPL Root) 559 +-----+ 560 | 561 o o o o 562 o o o o o o o o o 563 o o o o o o o o o o 564 o o o o o o o o o 565 S>>A>>>B>>C>>>D o o o 566 o o o o 567 LLN 569 Figure 6: Projected Transversal Route 571 This specification enables to store source-routed or storing mode 572 state in intermediate routers, which enables to limit the stretch of 573 a P2P route and maintain the characteristics within a given SLA. An 574 example of service using this mechanism oculd be a control loop that 575 would be installed in a network that uses classical RPL for 576 asynchronous data collection. In that case, the P2P path may be 577 installed in a different RPL Instance, with a different objective 578 function. 580 6. RPL Instances 582 It must be noted that RPL has a concept of instance but does not have 583 a concept of an administrative distance, which exists in certain 584 proprietary implementations to sort out conflicts between multiple 585 sources of routing information. This draft conforms the instance 586 model as follows: 588 o If the PCE needs to influence a particular instance to add better 589 routes in conformance with the routing objectives in that 590 instance, it may do so. When the PCE modifies an existing 591 instance then the added routes must not create a loop in that 592 instance. This is achieved by always preferring a route obtained 593 from the PCE over a route that is learned via RPL. 595 o If the PCE installs a more specific (say, Traffic Engineered) 596 route between a particular pair of nodes then it SHOULD use a 597 Local Instance from the ingress node of that path. A packet 598 associated with that instance will be routed along that path and 599 MUST NOT be placed over a Global Instance again. A packet that is 600 placed on a Global Instance may be injected in the Local Instance 601 based on node policy and the Local Instance paramenters. 603 In all cases, the path is indicated by a new Via Information option, 604 and the flow is similar to the flow used to obtain loose source 605 routing. 607 7. Security Considerations 609 This draft uses messages that are already present in RPL [RFC6550] 610 with optional secured versions. The same secured versions may be 611 used with this draft, and whatever security is deployed for a given 612 network also applies to the flows in this draft. 614 8. IANA Considerations 616 This document extends the IANA registry created by RFC 6550 for RPL 617 Control Codes as follows: 619 +------+-------------+---------------+ 620 | Code | Description | Reference | 621 +------+-------------+---------------+ 622 | 0x0A | Via | This document | 623 +------+-------------+---------------+ 625 RPL Control Codes 627 This document is updating the registry created by RFC 6550 for the 628 RPL 3-bit Mode of Operation (MOP) as follows: 630 +----------+------------------------------------------+-------------+ 631 | MOP | Description | Reference | 632 | value | | | 633 +----------+------------------------------------------+-------------+ 634 | 5 | Non-Storing mode of operation with | This | 635 | | Projected routes | document | 636 | | | | 637 | 6 | Storing mode of operation with Projected | This | 638 | | routes | document | 639 +----------+------------------------------------------+-------------+ 641 DIO Mode of operation 643 9. Acknowledgments 645 The authors wish to acknowledge JP Vasseur and Patrick Wetterwald for 646 their contributions to the ideas developed here. 648 10. References 650 10.1. Normative References 652 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 653 Requirement Levels", BCP 14, RFC 2119, 654 DOI 10.17487/RFC2119, March 1997, 655 . 657 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 658 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 659 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 660 Low-Power and Lossy Networks", RFC 6550, 661 DOI 10.17487/RFC6550, March 2012, 662 . 664 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 665 and D. Barthel, "Routing Metrics Used for Path Calculation 666 in Low-Power and Lossy Networks", RFC 6551, 667 DOI 10.17487/RFC6551, March 2012, 668 . 670 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 671 Routing Header for Source Routes with the Routing Protocol 672 for Low-Power and Lossy Networks (RPL)", RFC 6554, 673 DOI 10.17487/RFC6554, March 2012, 674 . 676 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 677 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 678 RFC 8025, DOI 10.17487/RFC8025, November 2016, 679 . 681 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 682 "IPv6 over Low-Power Wireless Personal Area Network 683 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 684 April 2017, . 686 10.2. Informative References 688 [I-D.ietf-6tisch-architecture] 689 Thubert, P., "An Architecture for IPv6 over the TSCH mode 690 of IEEE 802.15.4", draft-ietf-6tisch-architecture-12 (work 691 in progress), August 2017. 693 [I-D.ietf-detnet-architecture] 694 Finn, N., Thubert, P., Varga, B., and J. Farkas, 695 "Deterministic Networking Architecture", draft-ietf- 696 detnet-architecture-03 (work in progress), August 2017. 698 [PCE] IETF, "Path Computation Element", 699 . 701 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and 702 J. Martocci, "Reactive Discovery of Point-to-Point Routes 703 in Low-Power and Lossy Networks", RFC 6997, 704 DOI 10.17487/RFC6997, August 2013, 705 . 707 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 708 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 709 2014, . 711 Appendix A. Examples 713 A.1. Using storing mode P-DAO in non-storing mode MOP 715 In non-storing mode, the DAG root maintains the knowledge of the 716 whole DODAG topology, so when both the source and the destination of 717 a packet are in the DODAG, the root can determine the common parent 718 that would have been used in storing mode, and thus the list of nodes 719 in the path between the common parent and the destination. For 720 instance in the diagram shown in Figure 7, if the source is node 41 721 and the destination is node 52, then the common parent is node 22. 723 ------+--------- 724 | Internet 725 | 726 +-----+ 727 | | Border Router 728 | | (RPL Root) 729 +-----+ 730 | \ \____ 731 / \ \ 732 o 11 o 12 o 13 733 / | / \ 734 o 22 o 23 o 24 o 25 735 / \ | \ \ 736 o 31 o 32 o o o 35 737 / / | \ | \ 738 o 41 o 42 o o o 45 o 46 739 | | | | \ | 740 o 51 o 52 o 53 o o 55 o 56 742 LLN 744 Figure 7: Example DODAG forming a logical tree topology 746 With this draft, the root can install a storing mode routing states 747 along a segment that is either from itself to the destination, or 748 from one or more common parents for a particular source/destination 749 pair towards that destination (in this particular example, this would 750 be the segment made of nodes 22, 32, 42). 752 In the example below, say that there is a lot of traffic to nodes 55 753 and 56 and the root decides to reduce the size of routing headers to 754 those destinations. The root can first send a DAO to node 45 755 indicating target 55 and a Via segment (35, 45), as well as another 756 DAO to node 46 indicating target 56 and a Via segment (35, 46). This 757 will save one entry in the routing header on both sides. The root 758 may then send a DAO to node 35 indicating targets 55 and 56 a Via 759 segment (13, 24, 35) to fully optimize that path. 761 Alternatively, the root may send a DAO to node 45 indicating target 762 55 and a Via segment (13, 24, 35, 45) and then a DAO to node 46 763 indicating target 56 and a Via segment (13, 24, 35, 46), indicating 764 the same DAO Sequence. 766 A.2. Projecting a storing-mode transversal route 768 In this example, say that a PCE determines that a path must be 769 installed between node S and node D via routers A, B and C, in order 770 to serve the needs of a particular application. 772 The root sends a P-DAO with a target option indicating the 773 destination D and a sequence Via Information option, one for S, which 774 is the ingress router of the segment, one for A and then for B, which 775 are an intermediate routers, and one for C, which is the egress 776 router. 778 ------+--------- 779 | Internet 780 | 781 +-----+ 782 | | Border Router 783 | | (RPL Root) 784 +-----+ 785 | Projected DAO message to C 786 o | o o 787 o o o | o o o o o 788 o o o | o o o o o o 789 o o V o o o o o o 790 S A B C D o o o 791 o o o o 792 LLN 794 Figure 8: Projected DAO from root 796 Upon reception of the P-DAO, C validates that it can reach D, e.g. 797 using IPv6 Neighbor Discovery, and if so, propagates the P-DAO 798 unchanged to B. 800 B checks that it can reach C and of so, installs a route towards D 801 via C. Then it propagates the P-DAO to A. 803 The process recurses till the P-DAO reaches S, the ingress of the 804 segment, which installs a route to D via A and sends a DAO-ACK to the 805 root. 807 ------+--------- 808 | Internet 809 | 810 +-----+ 811 | | Border Router 812 | | (RPL Root) 813 +-----+ 814 ^ Projected DAO-ACK from S 815 / o o o 816 / o o o o o o o 817 | o o o o o o o o o 818 | o o o o o o o o 819 S A B C D o o o 820 o o o o 821 LLN 823 Figure 9: Projected DAO-ACK to root 825 As a result, a transversal route is installed that does not need to 826 follow the DODAG structure. 828 ------+--------- 829 | Internet 830 | 831 +-----+ 832 | | Border Router 833 | | (RPL Root) 834 +-----+ 835 | 836 o o o o 837 o o o o o o o o o 838 o o o o o o o o o o 839 o o o o o o o o o 840 S>>A>>>B>>C>>>D o o o 841 o o o o 842 LLN 844 Figure 10: Projected Transversal Route 846 Authors' Addresses 847 Pascal Thubert (editor) 848 Cisco Systems 849 Village d'Entreprises Green Side 850 400, Avenue de Roumanille 851 Batiment T3 852 Biot - Sophia Antipolis 06410 853 FRANCE 855 Phone: +33 4 97 23 26 34 856 Email: pthubert@cisco.com 858 James Pylakutty 859 Cisco Systems 860 Cessna Business Park 861 Kadubeesanahalli 862 Marathalli ORR 863 Bangalore, Karnataka 560087 864 INDIA 866 Phone: +91 80 4426 4140 867 Email: mundenma@cisco.com