idnits 2.17.1 draft-ietf-roll-dao-projection-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (27 November 2020) is 1236 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-29 == Outdated reference: A later version (-09) exists of draft-pthubert-raw-architecture-05 == Outdated reference: A later version (-44) exists of draft-ietf-roll-useofrplinfo-42 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL P. Thubert, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track R.A. Jadhav 5 Expires: 31 May 2021 Huawei Tech 6 M. Gillmore 7 Itron 8 27 November 2020 10 Root initiated routing state in RPL 11 draft-ietf-roll-dao-projection-15 13 Abstract 15 This document extends RFC 6550 and RFC 6553 to enable a RPL Root to 16 install and maintain Projected Routes within its DODAG, along a 17 selected set of nodes that may or may not include self, for a chosen 18 duration. This potentially enables routes that are more optimized or 19 resilient than those obtained with the classical distributed 20 operation of RPL, either in terms of the size of a Routing Header or 21 in terms of path length, which impacts both the latency and the 22 packet delivery ratio. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 31 May 2021. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Simplified BSD License text 52 as described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 60 2.2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.3. Other Terms . . . . . . . . . . . . . . . . . . . . . . . 6 62 2.4. References . . . . . . . . . . . . . . . . . . . . . . . 6 63 3. Extending RFC 6550 . . . . . . . . . . . . . . . . . . . . . 6 64 3.1. Projected DAO . . . . . . . . . . . . . . . . . . . . . . 6 65 3.2. Sibling Information Option . . . . . . . . . . . . . . . 8 66 3.3. P-DAO Request . . . . . . . . . . . . . . . . . . . . . . 8 67 3.4. Extending the RPI . . . . . . . . . . . . . . . . . . . . 8 68 4. Extending RFC 6553 . . . . . . . . . . . . . . . . . . . . . 8 69 5. Extending RFC 8138 . . . . . . . . . . . . . . . . . . . . . 9 70 6. New RPL Control Messages and Options . . . . . . . . . . . . 10 71 6.1. New P-DAO Request Control Message . . . . . . . . . . . . 10 72 6.2. New PDR-ACK Control Message . . . . . . . . . . . . . . . 11 73 6.3. Via Information Options . . . . . . . . . . . . . . . . . 12 74 6.4. Sibling Information Option . . . . . . . . . . . . . . . 15 75 7. Projected DAO . . . . . . . . . . . . . . . . . . . . . . . . 16 76 7.1. Requesting a Track . . . . . . . . . . . . . . . . . . . 18 77 7.2. Identifying a Track . . . . . . . . . . . . . . . . . . . 18 78 7.3. Installing a Track . . . . . . . . . . . . . . . . . . . 19 79 7.4. Forwarding Along a Track . . . . . . . . . . . . . . . . 20 80 7.5. Non-Storing Mode Projected Route . . . . . . . . . . . . 21 81 7.6. Storing Mode Projected Route . . . . . . . . . . . . . . 23 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 83 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 84 9.1. New Elective 6LoWPAN Routing Header Type . . . . . . . . 25 85 9.2. New Critical 6LoWPAN Routing Header Type . . . . . . . . 25 86 9.3. New Subregistry For The RPL Option Flags . . . . . . . . 26 87 9.4. New RPL Control Codes . . . . . . . . . . . . . . . . . . 26 88 9.5. New RPL Control Message Options . . . . . . . . . . . . . 27 89 9.6. SubRegistry for the Projected DAO Request Flags . . . . . 27 90 9.7. SubRegistry for the PDR-ACK Flags . . . . . . . . . . . . 28 91 9.8. Subregistry for the PDR-ACK Acceptance Status Values . . 28 92 9.9. Subregistry for the PDR-ACK Rejection Status Values . . . 28 93 9.10. SubRegistry for the Via Information Options Flags . . . . 29 94 9.11. SubRegistry for the Sibling Information Option Flags . . 29 95 9.12. Error in Projected Route ICMPv6 Code . . . . . . . . . . 30 96 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 97 11. Normative References . . . . . . . . . . . . . . . . . . . . 30 98 12. Informative References . . . . . . . . . . . . . . . . . . . 31 99 Appendix A. Applications . . . . . . . . . . . . . . . . . . . . 32 100 A.1. Loose Source Routing . . . . . . . . . . . . . . . . . . 32 101 A.2. Transversal Routes . . . . . . . . . . . . . . . . . . . 34 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 104 1. Introduction 106 RPL, the "Routing Protocol for Low Power and Lossy Networks" [RPL] 107 (LLNs), is a generic Distance Vector protocol that is well suited for 108 application in a variety of low energy Internet of Things (IoT) 109 networks. RPL forms Destination Oriented Directed Acyclic Graphs 110 (DODAGs) in which the Root often acts as the Border Router to connect 111 the RPL domain to the Internet. The Root is responsible to select 112 the RPL Instance that is used to forward a packet coming from the 113 Internet into the RPL domain and set the related RPL information in 114 the packets. 6TiSCH uses RPL for its routing operations. 116 The "6TiSCH Architecture" [6TiSCH-ARCHI] also leverages the 117 "Deterministic Networking Architecture" [RFC8655] centralized model 118 whereby the device resources and capabilities are exposed to an 119 external controller which installs routing states into the network 120 based on some objective functions that reside in that external 121 entity. With DetNet and 6TiSCH, the component of the controller that 122 is responsible of computing routes is called a Path Computation 123 Element ([PCE]). 125 Based on heuristics of usage, path length, and knowledge of device 126 capacity and available resources such as battery levels and 127 reservable buffers, the PCE with a global visibility on the system 128 can compute direct Peer to Peer (P2P) routes that are optimized for 129 the needs expressed by an objective function. This document 130 specifies protocol extensions to RPL [RPL] that enable the Root of a 131 main DODAG to install centrally-computed routes inside the DODAG on 132 behalf of a PCE. 134 This specification expects that the main RPL Instance is operated in 135 RPL Non-Storing Mode of Operation (MOP) to sustain the exchanges with 136 the Root. In that Mode, the Root has enough information to build a 137 basic DODAG topology based on parents and children, but lacks the 138 knowledge of siblings. This document adds the capability for nodes 139 to advertise sibling information in order to improve the topological 140 awareness of the Root. 142 As opposed to the classical RPL operations where routes are injected 143 by the Target nodes, the protocol extensions enable the Root of a 144 DODAG to project the routes that are needed onto the nodes where they 145 should be installed. This specification uses the term Projected 146 Route to refer to those routes. Projected Routes can be used to 147 reduce the size of the source routing headers with loose source 148 routing operations down the main RPL DODAG. Projected Routes can 149 also be used to build transversal routes for route optimization and 150 Traffic Engineering purposes, between nodes of the DODAG. 152 A Projected Route may be installed in either Storing and Non-Storing 153 Mode, potentially resulting in hybrid situations where the Mode of 154 the Projected Route is different from that of the main RPL Instance. 155 A Projected Route may be a stand-alone end-to-end path or a Segment 156 in a more complex forwarding graph called a Track. 158 The concept of a Track was introduced in the 6TiSCH architecture, as 159 a potentially complex path with redundant forwarding solutions along 160 the way. With this specification, a Track is a DODAG formed by a RPL 161 local Instance that is rooted at the Track Ingress. If there is a 162 single Track Egress, then the Track is reversible to form another 163 DODAG by reversing the direction of each edge. A node at the ingress 164 of more than one Segment in a Track may use one or more of these 165 Segments to forward a packet inside the Track. 167 The "Reliable and Available Wireless (RAW) Architecture/Framework" 168 [RAW-ARCHI] defines the Path Selection Engine (PSE) that adapts the 169 use of the path redundancy within a Track to defeat the diverse 170 causes of packet loss. 172 The PSE is a dataplane extension of the PCE; it controls the 173 forwarding operation of the packets within a Track, using Packet ARQ, 174 Replication, Elimination, and Overhearing (PAREO) functions over the 175 Track segments, to provide a dynamic balance between the reliability 176 and availability requirements of the flows and the need to conserve 177 energy and spectrum. 179 The time scale at which the PCE (re)computes the Track can be long, 180 using long-term statistical metrics to perform global optimizations 181 at the scale of the whole network. Conversely, the PSE makes 182 forwarding decisions at the time scale of one or a small collection 183 of packets, based on a knowledge that is limited in scope to the 184 Track itself, so it can be refreshed at a fast pace. 186 Projected Routes must be used with the parsimony to limit the amount 187 of state that is installed in each device to fit within the device 188 resources, and to maintain the amount of rerouted traffic within the 189 capabilities of the transmission links. The methods used to learn 190 the node capabilities and the resources that are available in the 191 devices and in the network are out of scope for this document. 193 This specification uses the RPL Root as a proxy to the PCE. The PCE 194 may be collocated with the Root, or may reside in an external 195 Controller. 197 In that case, the PCE exchanges control messages with the Root over a 198 Southbound API that is out of scope for this specification. The 199 algorithm to compute the paths and the protocol used by an external 200 PCE to obtain the topology of the network from the Root are also out 201 of scope. 203 2. Terminology 205 2.1. Requirements Language 207 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 208 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 209 "OPTIONAL" in this document are to be interpreted as described in BCP 210 14 [RFC2119][RFC8174] when, and only when, they appear in all 211 capitals, as shown here. 213 2.2. Glossary 215 This document often uses the following acronyms: 217 CMO: Control Message Option 218 DAO: Destination Advertisement Object 219 DAG: Directed Acyclic Graph 220 DODAG: Destination-Oriented Directed Acyclic Graph; A DAG with only 221 one vertex (i.e., node) that has no outgoing edge (i.e., link) 222 LLN: Low-Power and Lossy Network 223 NMPR: Non-Storing Mode Projected Route 224 MOP: RPL Mode of Operation 225 P-DAO: Projected DAO 226 PDR: P-DAO Request 227 RAN: RPL-Aware Node (either a RPL Router or a RPL-Aware Leaf) 228 RAL: RPL-Aware Leaf 229 RH: Routing Header 230 RPI: RPL Packet Information 231 RTO: RPL Target Option 232 RUL: RPL-Unaware Leaf 233 SIO: RPL Sibling Information Option 234 SR-VIO: A Source-Routed Via Information Option, used in Non-Storing 235 Mode P-DAO messages. 236 SMPR: Storing Mode Projected Route 237 TIO: RPL Transit Information Option 238 SF-VIO: A Via Information Option, used in Storing Mode P-DAO 239 messages. 240 VIO: A Via Information Option; it can be a SF-VIO or an SR-VIO. 242 2.3. Other Terms 244 Projected Route: A RPL Projected Route is a RPL route that is 245 computed remotely by a PCE, and installed and maintained by a RPL 246 Root on behalf of the PCE. 247 Projected DAO: A DAO message used to install a Projected Route. 248 Track: A DODAG that provides a complex path from or to a Root that 249 is the destination of the DODAG. The Root is the Track Ingress, 250 and the forward direction for packets is down the DODAG, from the 251 Track Ingress to one of the possibly multiple Track Egress Nodes. 252 TrackID: A RPL Local InstanceID with the 'D' bit set to 0. The 253 TrackID is associated with the IPv6 Address of the Track Ingress 254 that is used to signal the DODAG Root. 256 2.4. References 258 In this document, readers will encounter terms and concepts that are 259 discussed in the "Routing Protocol for Low Power and Lossy Networks" 260 [RPL] and "Terminology in Low power And Lossy Networks" [RFC7102]. 262 3. Extending RFC 6550 264 3.1. Projected DAO 266 Section 6 of [RPL] introduces the RPL Control Message Options (CMO), 267 including the RPL Target Option (RTO) and Transit Information Option 268 (TIO), which can be placed in RPL messages such as the Destination 269 Advertisement Object (DAO). This specification extends the DAO 270 message with the Projected DAO (P-DAO); a P-DAO message signals a 271 Projected Route to one or more Targets using the new CMOs presented 272 therein. This specification enables to combine one or more Projected 273 Routes into a DODAG called a Track, that is traversed to reach the 274 Targets. 276 The Track is assimilated with the DODAG formed for a Local RPL 277 Instance. The local RPLInstanceID of the Track is called the 278 TrackID, more in Section 7.2. A P-DAO message for a Track signals 279 the TrackID in the RPLInstanceID field. The Track Ingress is 280 signaled in the DODAGID field of the Projected DAO Base Object; that 281 field is elided in the case of the main RPL Instance. The Track 282 Ingress is the Root of the Track, as shown in Figure 1. . 284 0 1 2 3 285 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 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | TrackID |K|D| Flags | Reserved | DAOSequence | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | | 290 + + 291 | | 292 + IPv6 Address of the Track Ingress + 293 | | 294 + + 295 | | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Option(s)... 298 +-+-+-+-+-+-+-+-+ 300 Figure 1: Projected DAO Format for a Track 302 In RPL Non-Storing Mode, the TIO and RTO are combined in a DAO 303 message to inform the DODAG Root of all the edges in the DODAG, which 304 are formed by the directed parent-child relationships. Options may 305 be factorized; multiple RTOs may be present to signal a collection of 306 children that can be reached via the parent(s) indicated in the 307 TIO(s) that follows the RTOs. This specification generalizes the 308 case of a parent that can be used to reach a child with that of a 309 whole Track through which both children and siblings of the Track 310 Egress are reachable. 312 New CMOs called the Via Information Options (VIO) are introduced for 313 use in P-DAO messages as a multihop alternative to the TIO. One VIO 314 is the Stateful Via Information Option (SF-VIO); the SF-VIO installs 315 Storing Mode Projected Route (SMPR) along a strict segment. The 316 other is the Source-Routed SF-VIO (SR-VIO); the SR-VIO installs a 317 Non-Storing Mode Projected Route (NMPR) at the Track Ingress, which 318 uses that state to encapsulate a packet with a Routing Header (RH) to 319 the Track Egress. 321 Like in a DAO message, the RTOs can be factorized in a P-DAO, but the 322 Via Options cannot. A P-DAO contains one or more RTOs that indicate 323 the destinations that can be reached via the Track, and exactly one 324 Via Option that signals a sequence of nodes. In Non-Storing Mode, 325 the Root sends the P-DAO to the Track Ingress where the source- 326 routing state is stored. In Storing Mode, the P-DAO is sent to the 327 Track Egress and forwarded along the Segment in the reverse 328 direction, installing a Storing Mode state to the Track Egress at 329 each hop. In both cases the Track Ingress is the owner of the Track, 330 and it generates the P-DAO-ACK when the installation is successful. 332 3.2. Sibling Information Option 334 This specification adds another CMO called the Sibling Information 335 Option (SIO) that is used by a RPL Aware Node (RAN) to advertise a 336 selection of its candidate neighbors as siblings to the Root, more in 337 Section 6.4. The sibling selection process is out of scope. 339 3.3. P-DAO Request 341 Two new RPL Control Messages are also introduced, to enable a RAN to 342 request the establishment of a Track between self as the Track 343 Ingress Node and a Track Egress. The RAN makes its request by 344 sending a new P-DAO Request (PDR) Message to the Root. The Root 345 confirms with a new PDR-ACK message back to the requester RAN, see 346 Section 6.1 for more. A positive PDR-ACK indicates that the Track 347 was built and that the Roots commits to maintain the Track for the 348 negotiated lifetime. In the case of a complex Track, each Segment is 349 maintained independently and asynchronously by the Root, with its own 350 lifetime that may be shorter, the same, or longer than that of the 351 Track. The Root may use an asynchronous PDR-ACK with an negative 352 status to indicate that the Track was terminated before its time. 354 3.4. Extending the RPI 356 Sending a Packet within a RPL Local Instance requires the presence of 357 the abstract RPL Packet Information (RPI) described in section 11.2. 358 of [RPL] in the outer IPv6 Header chain (see [USEofRPLinfo]). The 359 RPI carries a local RPLInstanceID which, in association with either 360 the source or the destination address in the IPv6 Header, indicates 361 the RPL Instance that the packet follows. 363 This specification extends [RPL] to create a new flag that signals 364 that a packet is forwarded along a projected route. 366 Projected-Route 'P': 1-bit flag. It is set to 1 if this packet is 367 sent over a projected route and set to 0 otherwise. 369 4. Extending RFC 6553 371 "The RPL Option for Carrying RPL Information in Data-Plane Datagrams" 372 [RFC6553]describes the RPL Option for use among RPL routers to 373 include the abstract RPL Packet Information (RPI) described in 374 section 11.2. of [RPL] in data packets. 376 The RPL Option is commonly referred to as the RPI though the RPI is 377 really the abstract information that is transported in the RPL 378 Option. [USEofRPLinfo] updated the Option Type from 0x63 to 0x23. 380 This specification modifies the RPL Option to encode the 'P' flag as 381 follows: 383 0 1 2 3 384 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 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Option Type | Opt Data Len | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 |O|R|F|P|0|0|0|0| RPLInstanceID | SenderRank | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | (sub-TLVs) | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 Figure 2: Extended RPL Option Format 395 Option Type: 0x23 or 0x63, see [USEofRPLinfo] 397 Opt Data Len: See [RFC6553] 399 'O', 'R' and 'F' flags: See [RFC6553]. Those flags MUST be set to 0 400 by the sender and ignored by the receiver if the 'P' flag is set. 402 Projected-Route 'P': 1-bit flag as defined in Section 3.4. 404 RPLInstanceID: See [RFC6553]. Indicates the TrackId if the 'P' flag 405 is set. 407 SenderRank: See [RFC6553]. This field MUST be set to 0 by the 408 sender and ignored by the receiver if the 'P'flag is set. 410 5. Extending RFC 8138 412 Section 6.3 of [RFC8138] presents the formats of the 6LoWPAN Routing 413 Header of type 5 (RPI-6LoRH) that compresses the RPI for normal RPL 414 operation. The format of the RPI-6LoRH is not suited for Projected 415 routes since the O,R,F flags are not used and the Rank is unknown and 416 ignored. 418 This specification introduces a new 6LoRH, the P-RPI-6LoRH, with a 419 type of 7. The P-RPI-6LoRH header is usually a a Critical 6LoWPAN 420 Routing Header, but it can be elective as well if an SRH-6LoRH is 421 present and controls the routing decision. 423 The P-RPI-6LoRH is designed to compress the RPI along RPL Projected 424 Routes. It sformat is as follows: 426 0 1 2 427 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 |1|0|E| Length | 6LoRH Type 7 | RPLInstanceID | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 Figure 3: P-RPI-6LoRH Format 434 Elective 'E': See [RFC8138]. The 'E' flag is set to 1 to indicate 435 an Elective 6LoRH, meaning that it can be ignored when forwarding. 437 6. New RPL Control Messages and Options 439 6.1. New P-DAO Request Control Message 441 The P-DAO Request (PDR) message is sent by a Node in the main DODAG 442 to the Root. It is a request to establish or refresh a Track. 443 Exactly one RTO MUST be present in a PDR. The RTO signals the Track 444 Egress, more in Section 7.1. 446 The RPL Control Code for the PDR is 0x09, to be confirmed by IANA. 447 The format of PDR Base Object is as follows: 449 0 1 2 3 450 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 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | TrackID |K|R| Flags | ReqLifetime | PDRSequence | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Option(s)... 455 +-+-+-+-+-+-+-+-+ 457 Figure 4: New P-DAO Request Format 459 TrackID: 8-bit field indicating the RPLInstanceID associated with 460 the Track. It is set to zero upon the first request for a new 461 Track and then to the TrackID once the Track was created, to 462 either renew it of destroy it. 464 K: The 'K' flag is set to indicate that the recipient is expected to 465 send a PDR-ACK back. 467 R: The 'R' flag is set to request a Complex Track for redundancy. 469 Flags: Reserved. The Flags field MUST initialized to zero by the 470 sender and MUST be ignored by the receiver 472 ReqLifetime: 8-bit unsigned integer. The requested lifetime for the 473 Track expressed in Lifetime Units (obtained from the DODAG 474 Configuration option). 476 A PDR with a fresher PDRSequence refreshes the lifetime, and a 477 PDRLifetime of 0 indicates that the track should be destroyed. 479 PDRSequence: 8-bit wrapping sequence number, obeying the operation 480 in section 7.2 of [RPL]. The PDRSequence is used to correlate a 481 PDR-ACK message with the PDR message that triggered it. It is 482 incremented at each PDR message and echoed in the PDR-ACK by the 483 Root. 485 6.2. New PDR-ACK Control Message 487 The new PDR-ACK is sent as a response to a PDR message with the 'K' 488 flag set. The RPL Control Code for the PDR-ACK is 0x0A, to be 489 confirmed by IANA. Its format is as follows: 491 0 1 2 3 492 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 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | TrackID | Flags | Track Lifetime| PDRSequence | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | PDR-ACK Status| Reserved | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Option(s)... 499 +-+-+-+-+-+-+-+ 501 Figure 5: New PDR-ACK Control Message Format 503 TrackID: The RPLInstanceID of the Track that was created. The value 504 of 0x00 is used to when no Track was created. 506 Flags: Reserved. The Flags field MUST initialized to zero by the 507 sender and MUST be ignored by the receiver 509 Track Lifetime: Indicates that remaining Lifetime for the Track, 510 expressed in Lifetime Units; the value of zero (0x00) indicates 511 that the Track was destroyed or not created. 513 PDRSequence: 8-bit wrapping sequence number. It is incremented at 514 each PDR message and echoed in the PDR-ACK. 516 PDR-ACK Status: 8-bit field indicating the completion. The PDR-ACK 517 Status is substructured as indicated in Figure 6: 519 0 1 2 3 4 5 6 7 520 +-+-+-+-+-+-+-+-+ 521 |E|R| Value | 522 +-+-+-+-+-+-+-+-+ 524 Figure 6: PDR-ACK status Format 526 E: 1-bit flag. Set to indicate a rejection. When not set, the 527 value of 0 indicates Success/Unqualified acceptance and other 528 values indicate "not an outright rejection". 529 R: 1-bit flag. Reserved, MUST be set to 0 by the sender and 530 ignored by the receiver. 531 Status Value: 6-bit unsigned integer. Values depending on the 532 setting of the 'E' flag, see Table 7 and Table 8. 534 Reserved: The Reserved field MUST initialized to zero by the sender 535 and MUST be ignored by the receiver 537 6.3. Via Information Options 539 An Via Option signals the ordered list of IPv6 Via Addresses that 540 constitutes the hops of either a Serial Track or a Segment of a more 541 Complex Track. An Via Option MUST contain at least one Via Address, 542 and a Via Address MUST NOT be present more than once, otherwise the 543 Via Option MUST be ignored. The format of the Via Options is as 544 follows: 546 0 1 2 3 547 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 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | Type | Option Length | Flags | SegmentID | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 |Segm. Sequence | Seg. Lifetime | SRH-6LoRH header | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | | 554 + + 555 . . 556 . Via Address 1 . 557 . . 558 + + 559 | | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | | 562 . .... . 563 | | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | | 566 + + 567 . . 568 . Via Address n . 569 . . 570 + + 571 | | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 Figure 7: Via Information Option format (uncompressed form) 576 Option Type: 0x0B for SF-VIO, 0x0C for SR-VIO (to be confirmed by 577 IANA) 579 Option Length: In bytes; variable, depending on the number of Via 580 Addresses and the compression. 582 SegmentID: 8-bit field that identifies a Segment within a Track or 583 the main DODAG as indicated by the TrackID field. The value of 0 584 is used to signal a Serial Track, i.e., made of a single segment. 586 Segment Sequence: 8-bit unsigned integer. The Segment Sequence 587 obeys the operation in section 7.2 of [RPL] and the lollipop 588 starts at 255. 590 When the Root of the DODAG needs to refresh or update a Segment in 591 a Track, it increments the Segment Sequence individually for that 592 Segment. 594 The Segment information indicated in the Via Option deprecates any 595 state for the Segment indicated by the SegmentID within the 596 indicated Track and sets up the new information. 598 An Via Option with a Segment Sequence that is not as fresh as the 599 current one is ignored. 601 A VIO for a given DODAGID with the same (TrackID, SegmentID, 602 Segment Sequence) indicates a retry; it MUST NOT change the 603 Segment and MUST be propagated or answered as the first copy. 605 Segment Lifetime: 8-bit unsigned integer. The length of time in 606 Lifetime Units (obtained from the Configuration option) that the 607 Segment is usable. 609 The period starts when a new Segment Sequence is seen. The value 610 of 255 (0xFF) represents infinity. The value of zero (0x00) 611 indicates a loss of reachability. 613 A P-DAO message that contains a Via Information option with a 614 Segment Lifetime of zero is referred as a No-Path P-DAO in this 615 document. 617 SRH-6LoRH header: The first 2 bytes of the (first) SRH-6LoRH as 618 shown in Figure 6 of [RFC8138]. A 6LoRH Type of 4 means that the 619 VIA Addresses are provided in full with no compression. 621 Via Address: An IPv6 addresse along the Segment. 623 In a SF-VIO, the list is a strict path between direct neighbors, 624 from the segment ingress to egress, both included. In an SR-VIO, 625 the list starts at the first hop and ends at a Track Egress. The 626 list in an SR-VIO may be loose, provided that each listed node has 627 a path to the next listed node, e.g., via a segment or another 628 Track. 630 In the case of a SF-VIO, or if [RFC8138] is not used in the data 631 packets, then the Root MUST use only one SRH-6LoRH per Via Option, 632 and the compression is the same for all the addresses, as shown in 633 Figure 7. 635 In case of an SR-VIO, and if [RFC8138] is in use in the main 636 DODAG, then the Root SHOULD optimize the size of the SR-VIO; more 637 than one SRH-6LoRH may be present, e.g., if the compression level 638 changes inside the Segment and different SRH-6LoRH Types are 639 required. The content of the SR-VIO starting at the first SRH- 640 6LoRH header is thus verbatim the one that the Track Ingress 641 places in the packet encapsulation to reach the Track Ingress. 643 6.4. Sibling Information Option 645 The Sibling Information Option (SIO) provides indication on siblings 646 that could be used by the Root to form Projected Routes. One or more 647 SIO(s) may be placed in the DAO messages that are sent to the Root in 648 Non-Storing Mode. 650 The format of the SIO is as follows: 652 0 1 2 3 653 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 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | Type | Option Length |Comp.|B|D|Flags| Opaque | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | Step of Rank | Reserved | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | | 660 + + 661 . . 662 . Sibling DODAGID (if 'D' flag not set) . 663 . . 664 + + 665 | | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | | 668 + + 669 . . 670 . Sibling Address . 671 . . 672 + + 673 | | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 Figure 8: Sibling Information Option Format 678 Option Type: 0x0D (to be confirmed by IANA) 680 Option Length: In bytes, the size of the option. 682 Compression Type: 3-bit unsigned integer. This is the SRH-6LoRH 683 Type as defined in figure 7 in section 5.1 of [RFC8138] that 684 corresponds to the compression used for the Sibling Address and 685 its DODAGID if resent. The Compression refernce is the Root of 686 the main DODAG. 688 Reserved for Flags: MUST be set to zero by the sender and MUST be 689 ignored by the receiver. 691 B: 1-bit flag that is set to indicate that the connectivity to the 692 sibling is bidirectional and roughly symmetrical. In that case, 693 only one of the siblings may report the SIO for the hop. If 'B' 694 is not set then the SIO only indicates connectivity from the 695 sibling to this node, and does not provide information on the hop 696 from this node to the sibling. 698 D: 1-bit flag that is set to indicate that sibling belongs to the 699 same DODAG. When not set, the Sibling DODAGID is indicated. 701 Flags: Reserved. The Flags field MUST initialized to zero by the 702 sender and MUST be ignored by the receiver 704 Opaque: MAY be used to carry information that the node and the Root 705 understand, e.g., a particular representation of the Link 706 properties such as a proprietary Link Quality Information for 707 packets received from the sibling. An industrial Alliance that 708 uses RPL for a particular use / environment MAY redefine the use 709 of this field to fit its needs. 711 Step of Rank: 16-bit unsigned integer. This is the Step of Rank 712 [RPL] as computed by the Objective Function between this node and 713 the sibling. 715 Reserved: The Reserved field MUST initialized to zero by the sender 716 and MUST be ignored by the receiver 718 Sibling DODAGID: 2 to 16 bytes, the DODAGID of the sibling in a 719 [RFC8138] compressed form as indicated by the Compression Type 720 field. This field is present when the 'D' flag is not set. 722 Sibling Address: 2 to 16 bytes, the IPv6 Address of the sibling in a 723 [RFC8138] compressed form as indicated by the Compression Type 724 field. 726 An SIO MAY be immediately followed by a DAG Metric Container. In 727 that case the DAG Metric Container provides additional metrics for 728 the hop from the Sibling to this node. 730 7. Projected DAO 732 This draft adds a capability to RPL whereby the Root of a main DODAG 733 installs a Track as a collection of Projected Routes, using a 734 Projected-DAO (P-DAO) message to maintain each individual route. The 735 P-DAO signals a collection of Targets in the RPL Target Option(s) 736 (RTO). Those Targets can be reached via a sequence of routers 737 indicated in a Via Information Option (VIO). A P-DAO message MUST 738 contain exactly one VIO, which is either a SF-VIO or an SR-VIO, and 739 MUST follow one or more RTOs. There can be at most one such sequence 740 of RTO(s) and an Via Option. A track is indentified by a tupple 741 DODAGID, TrackID and each route within a Track is indexed by a 742 SegmentID. 744 A P-DAO MUST be sent from the address of the Root that serves as 745 DODAGID for the main DODAG. It MUST be sent to a GUA or a ULA of 746 either the ingress or the egress of the Segment, more below. If the 747 'K' Flag is present in the P-DAO, and unless the P-DAO does not reach 748 it, the ingress of the Segment is the node that acknowledges the 749 message, using a DAO-ACK that MUST be sent back to the address that 750 serves as DODAGID for the main DODAG. 752 Like a classical DAO message, a P-DAO causes a change of state only 753 if it is "new" per section 9.2.2. "Generation of DAO Messages" of 754 the RPL specification [RPL]; this is determined using the Segment 755 Sequence information from the Via Option as opposed to the Path 756 Sequence from a TIO. Also, a Segment Lifetime of 0 in an Via Option 757 indicates that the projected route associated to the Segment is to be 758 removed. 760 There are two kinds of operation for the Projected Routes, the 761 Storing Mode and the Non-Storing Mode. 763 * The Non-Storing Mode is discussed in Section 7.5. A Non-Storing 764 Mode P-DAO carries an SR-VIO with the loose list of Via Addresses 765 that forms a source-routed Segment to the Track Egress. The 766 recipient of the P-DAO is the Track Ingress; it MUST install a 767 source-routed state to the Track Egress and reply to the Root 768 directly using a DAO-ACK message if requested to. 770 * The Storing Mode is discussed in Section 7.6. A Storing Mode 771 P-DAO carries a SF-VIO with the strict list of Via Addresses from 772 the ingress to the egress of the Segment in the data path order. 773 The routers listed in the Via Addresses, except the egress, MUST 774 install a routing state to the Target(s) via the next Via Address 775 in the SF-VIO. In normal operations, the P-DAO is propagated 776 along the chain of Via Routers from the egress router of the path 777 till the ingress one, which confirms the installation to the Root 778 with a DAO-ACK message. 780 In case of a forwarding error along a Projected Route, an ICMP error 781 is sent to the Root with a new Code "Error in Projected Route" (See 782 Section 9.12). The Root can then modify or remove the Projected 783 Route. The "Error in Projected Route" message has the same format as 784 the "Destination Unreachable Message", as specified in RFC 4443 785 [RFC4443]. 787 The portion of the invoking packet that is sent back in the ICMP 788 message SHOULD record at least up to the RH if one is present, and 789 this hop of the RH SHOULD be consumed by this node so that the 790 destination in the IPv6 header is the next hop that this node could 791 not reach. if a 6LoWPAN Routing Header (6LoRH) [RFC8138] is used to 792 carry the IPv6 routing information in the outer header then that 793 whole 6LoRH information SHOULD be present in the ICMP message. 795 The sender and exact operation depend on the Mode and is described in 796 Section 7.5 and Section 7.6 respectively. 798 7.1. Requesting a Track 800 A Node is free to ask the Root for a new Track at any time. This is 801 done with a PDR message, that indicates in the Requested Lifetime 802 field the duration for which the Track should be established. Upon a 803 PDR, the Root MAY install the necessary Segments, in which case it 804 answers with a PDR-ACK indicating the granted Track Lifetime. All 805 the Segments MUST be of a same mode, either Storing or Non-Storing. 806 All the Segments MUST be created with the same TrackID and the same 807 DODAGID signaled in the P-DAO. 809 The Root is free to design the Track as it wishes, and to change the 810 Segments overtime to serve the Track as needed, without notifying the 811 resquesting Node. The Segment Lifetime in the P-DAO messages does 812 not need to be aligned to the Requested Lifetime in the PDR, or 813 between P-DAO messages for different Segments. The Root may use 814 shorter lifetimes for the Segments and renew them faster than the 815 Track is, or longer lifetimes in which case it will need to tear down 816 the Segments if the Track is not renewed. 818 When the Track Lifetime that was returned in the PDR-ACK is close to 819 elapse, the resquesting Node needs to resend a PDR using the TrackID 820 in the PDR-ACK to extend the lifetime of the Track, else the Track 821 will time out and the Root will tear down the whole structure. 823 If the Track fails and cannot be restored, the Root notifies the 824 resquesting Node asynchronously with a PDR-ACK with a Track Lifetime 825 of 0, indicating that the Track has failed, and a PDR-ACK Status 826 indicating the reason of the fault. 828 7.2. Identifying a Track 830 RPL defines the concept of an Instance to signal an individual 831 routing topology but does not have a concept of an administrative 832 distance, which exists in certain proprietary implementations to sort 833 out conflicts between multiple sources of routing information within 834 one routing topology. 836 This draft leverages the RPL Instance model as follows: 838 * The Root MAY use P-DAO messages to add better routes in the main 839 (Global) Instance in conformance with the routing objectives in 840 that Instance. To achieve this, the Root MAY install an SMPR 841 along a path down the main Non-Storing Mode DODAG. This enables a 842 loose source routing and reduces the size of the Routing Header, 843 see Appendix A.1. 845 When adding an SMPR to the main RPL Instance, the Root MUST set 846 the RPLInstanceID field of the P-DAO message (see section 6.4.1. 847 of [RPL]) to the RPLInstanceID of the main DODAG, and MUST NOT use 848 the DODAGID field. A Projected Route provides a longer match to 849 the Target Address than the default route via the Root, so it is 850 preferred. 852 Once the Projected Route is installed, the intermediate nodes 853 listed in the SF-VIO after first one (i.e. The ingress) can be 854 elided from the RH in packets sent along the Segment signaled in 855 the P-DAO. The resulting loose source routing header indicates 856 (one of) the Target(s) as the next entry after the ingress. 858 * The Root MAY also use P-DAO messages to install a specific (say, 859 Traffic Engineered) path as a Serial or as a Complex Track, to a 860 particular endpoint that is the Track Egress. In that case, the 861 Root MUST install a Local RPL Instance (see section 5 of [RPL]). 863 In a that case, the TrackID MUST be unique for the Global Unique 864 IPv6 Address (GUA) or Unique-Local Address (ULA) of the Track 865 Ingress that serves as DODAGID for the Track. This way, a Track 866 is uniquely identified by the tuple (DODAGID, TrackID) where the 867 TrackID is always represented with the 'D' flag set to 0. 869 The Track Egress Address and the TrackID MUST be signaled in the 870 P-DAO message as shown in Figure 1. 872 7.3. Installing a Track 874 A Storing Mode P-DAO contains an SF-VIO that signals the strict 875 sequence of consecutive nodes to form a segment between a segment 876 ingress and a segment egress (both included). It installs a route of 877 a higher precedence along the segment towards the Targets indicated 878 in the Target Options. The segment is included in a DODAG indicated 879 by the P-DAO Base Object, that may be the one formed by the main RPL 880 Instance, or a Track associated with a local RPL Instance. A Track 881 Egress is signaled as a Target in the P-DAO, and as the last entry is 882 an SF-VIO of a last segment towards that Egress. 884 A Non-Storing Mode P-DAO signals a strict or loose sequence of nodes 885 between the Track Ingress (excluded) and a Track Egress (included). 886 It installs a source-routed path of a higher precedence within the 887 Track indicated by the P-DAO Base Object, towards the Targets 888 indicated in the Target Options. The source-routed path requires a 889 Source-Routing header which implies an encapsulation to add the SRH 890 to an existing packet. 892 The next entry in the sequence must be either a neighbor of the 893 previous entry, or reachable as a Target via another Projected Route, 894 either Storing or Non-Storing. If it is reachable over a Storing 895 Mode Projected Route, the next entry in the loose sequence is the 896 Target of a previous segment and the ingress of a next segment; the 897 segments are associated with the same Track, which avoids the need of 898 an encapsulation. Conversely, if it is reachable over a Non-Storing 899 Mode Projected Route, the next loose source routed hop of the inner 900 Track is a Target of a previous Track and the ingress of a next 901 Track, which requires a de- and a re-encapsulation. 903 A Serial Track is installed by a single Projected Routes that signals 904 the sequence of consecutive nodes, either in Storing or Non-Storing 905 Mode. If can be a loose Non-Storing Mode Projected Route, in which 906 case the next loose entry must recursively be reached over a Serial 907 Track. 909 A Complex Track can be installed as a collection of Projected Routes 910 with the same DODAGID and Track ID. The Ingress of a Non-Storing 911 Mode Projected Route must be the owner of the DODAGID. The Ingress 912 of a Storing Mode Projected Route must be either the owner of the 913 DODAGID, or the egress of a preceding Storing Mode Projected Route in 914 the same Track. In the latter case, the Targets of the Projected 915 Route must be Targets of the preceding Projected Route to ensure that 916 they are visible from the track Ingress. 918 7.4. Forwarding Along a Track 920 This draft leverages the RPL Forwarding model follows: 922 * In the data packets, the Track DODAGID and the TrackID MUST be 923 respectively signaled as the IPv6 Source Address and the 924 RPLInstanceID field of the RPI that MUST be placed in the outer 925 chain of IPv6 Headers. 927 The RPI carries a local RPLInstanceID called the TrackID, which, 928 in association with the DODAGID, indicates the Track along which 929 the packet is forwarded. 931 The 'D' flag in the RPLInstanceID MUST be set to 0 to indicate 932 that the source address in the IPv6 header is set ot the DODAGID, 933 more in Section 7.4. 935 * This draft conforms the principles of [USEofRPLinfo] with regards 936 to packet forwarding and encapsulation along a Track. 938 - In that case, the Track is the DODAG, the Track Ingress is the 939 Root, and the Track Egress is a RAL, and neighbors of the Track 940 Egress that can be reached via the Track are RULs. The 941 encapsulation rules in [USEofRPLinfo] apply. 943 - If the Track Ingress is the originator of the packet and the 944 Track Egress is the destination of the packet, there is no need 945 for an encapsulation. 947 - So the Track Ingress must encapsulate the traffic that it did 948 not originate, and add an RPI in any fashion. 950 A packet that is being routed over the RPL Instance associated to 951 a first Non-Storing Mode Track MAY be placed (encapsulated) in a 952 second Track to cover one loose hop of the first Track. On the 953 other hand, a Storing Mode Track must be strict and a packet that 954 it placed in a Storing Mode Track MUST follow that Track till the 955 Track Egress. 957 When a Track Egress extracts a packet from a Track (decapsulates 958 the packet), the Destination of the inner packet MUST be either 959 this node or a direct neighbor, or a Target of another Segment of 960 the same Track for which this node is ingress, otherwise the 961 packet MUST be dropped. 963 All properties of a Track operations are inherited form the main RPL 964 Instance that is used to install the Track. For instance, the use of 965 compression per [RFC8138] is determined by whether it is used in the 966 main instance, e.g., by setting the "T" flag [TURN-ON_RFC8138] in the 967 RPL configuration option. 969 7.5. Non-Storing Mode Projected Route 971 As illustrated in Figure 9, a P-DAO that carries an SR-VIO enables 972 the Root to install a source-routed path towards a Track Egress in 973 any particular router. 975 ------+--------- 976 | Internet 977 | 978 +-----+ 979 | | Border Router 980 | | (RPL Root) 981 +-----+ | P ^ ACK 982 | Track | DAO | 983 o o o o Ingress X V | X 984 o o o o o o o X o X Source 985 o o o o o o o o X o o X Routed 986 o o ° o o o o X o X Segment 987 o o o o o o o o X Track X 988 o o o o o Egress 990 o o o o 991 o o o o 992 destination 994 LLN 996 Figure 9: Projecting a Non-Storing Route 998 A route indicated by an SR-VIO may be loose, meaning that the node 999 that owns the next listed Via Address is not necessarily a neighbor. 1000 Without proper loop avoidance mechanisms, the interaction of loose 1001 source routing and other mechanisms may effectively cause loops. 1003 When forwarding a packet to a destination for which the router 1004 determines that routing happens via the Track Egress, the router 1005 inserts the source routing header in the packet with the destination 1006 set to the Track Egress. 1008 In order to signal the Segment, the router encapsulates the packet 1009 with an IP-in-IP header and a Routing Header as follows: 1011 * In the uncompressed form the source of the packet is this router, 1012 the destination is the first Via Address in the SR-VIO, and the RH 1013 is a Source Routing Header (SRH) [RFC6554] that contains the list 1014 of the remaining Via Addresses terminating by the Track Egress. 1016 * The preferred alternate in a network where 6LoWPAN Header 1017 Compression [RFC6282] is used is to leverage "IPv6 over Low-Power 1018 Wireless Personal Area Network (6LoWPAN) Paging Dispatch" 1019 [RFC8025] to compress the RPL artifacts as indicated in [RFC8138]. 1021 In that case, the source routed header is the exact copy of the 1022 (chain of) SRH-6LoRH found in the SR-VIO, also terminating by the 1023 Track Egress. The RPI-6LoRH is appended next, followed by an IP- 1024 in-IP 6LoRH Header that indicates the Ingress Router in the 1025 Encapsulator Address field, see as a similar case Figure 20 of 1026 [TURN-ON_RFC8138]. 1028 In the case of a loose source-routed path, there MUST be either a 1029 neighbor that is adjacent to the loose next hop, on which case the 1030 packet is forwarded to that neighbor, or another Track to the loose 1031 next hop for which this node is Ingress; in the latter case, another 1032 encapsulation takes place and the process possibly recurses; 1033 otherwise the packet is dropped. 1035 In case of a forwarding error along a Source Route path, the node 1036 that fails to forward SHOULD send an ICMP error with a code "Error in 1037 Source Routing Header" back to the source of the packet, as described 1038 in section 11.2.2.3. of [RPL]. Upon this message, the encapsulating 1039 node SHOULD stop using the source route path for a period of time and 1040 it SHOULD send an ICMP message with a Code "Error in Projected Route" 1041 to the Root. Failure to follow these steps may result in packet loss 1042 and wasted resources along the source route path that is broken. 1044 7.6. Storing Mode Projected Route 1046 As illustrated in Figure 10, a P-DAO that carries a SF-VIO enables 1047 the Root to install a stateful route towards a collection of Targets 1048 along a Segment between a Track Ingress and a Track Egress. 1050 ------+--------- 1051 | Internet 1052 | 1053 +-----+ 1054 | | Border Router 1055 | | (RPL Root) 1056 +-----+ | ^ | 1057 | | DAO | ACK | 1058 o o o o | | | 1059 o o o o o o o o o | ^ | Projected . 1060 o o o o o o o o o o | | DAO | Route . 1061 o o o o o o o o o | ^ | . 1062 o o o o o o o o v | DAO v . 1063 o o LLN o o o | 1064 o o o o o Loose Source Route Path | 1065 o o o o From Root To Destination v 1067 Figure 10: Projecting a route 1069 In order to install the relevant routing state along the Segment , 1070 the Root sends a unicast P-DAO message to the Track Egress router of 1071 the routing Segment that is being installed. The P-DAO message 1072 contains a SF-VIO with the direct sequence of Via Addresses. The SF- 1073 VIO follows one or more RTOs indicating the Targets to which the 1074 Track leads. The SF-VIO contains a Segment Lifetime for which the 1075 state is to be maintained. 1077 The Root sends the P-DAO directly to the egress node of the Segment. 1078 In that P-DAO, the destination IP address matches the last Via 1079 Address in the SF-VIO. This is how the egress recognizes its role. 1080 In a similar fashion, the ingress node recognizes its role as it 1081 matches first Via Address in the SF-VIO. 1083 The Egress node of the Segment is the only node in the path that does 1084 not install a route in response to the P-DAO; it is expected to be 1085 already able to route to the Target(s) on its own. If one of the 1086 Targets is not known, the node MUST answer to the Root with a 1087 negative DAO-ACK listing the Target(s) that could not be located 1088 (suggested status 10 to be confirmed by IANA). 1090 If the egress node can reach all the Targets, then it forwards the 1091 P-DAO with unchanged content to its loose predecessor in the Segment 1092 as indicated in the list of Via Information options, and recursively 1093 the message is propagated unchanged along the sequence of routers 1094 indicated in the P-DAO, but in the reverse order, from egress to 1095 ingress. 1097 The address of the predecessor to be used as destination of the 1098 propagated DAO message is found in the Via Address the precedes the 1099 one that contain the address of the propagating node, which is used 1100 as source of the message. 1102 Upon receiving a propagated DAO, all except the Egress Router MUST 1103 install a route towards the DAO Target(s) via their successor in the 1104 SF-VIO. The router MAY install additional routes towards the VIA 1105 Addresses that are the SF-VIO after the next one, if any, but in case 1106 of a conflict or a lack of resource, the route(s) to the Target(s) 1107 have precedence. 1109 If a router cannot reach its predecessor in the SF-VIO, the router 1110 MUST answer to the Root with a negative DAO-ACK indicating the 1111 successor that is unreachable (suggested status 11 to be confirmed by 1112 IANA). 1114 The process continues till the P-DAO is propagated to ingress router 1115 of the Segment, which answers with a DAO-ACK to the Root. 1117 A Segment Lifetime of 0 in a Via Information option is used to clean 1118 up the state. The P-DAO is forwarded as described above, but the DAO 1119 is interpreted as a No-Path DAO and results in cleaning up existing 1120 state as opposed to refreshing an existing one or installing a new 1121 one. 1123 In case of a forwarding error along an SMPR, the node that fails to 1124 forward SHOULD send an ICMP error with a code "Error in Projected 1125 Route" to the Root. Failure to do so may result in packet loss and 1126 wasted resources along the Projected Route that is broken. 1128 8. Security Considerations 1130 This draft uses messages that are already present in RPL [RPL] with 1131 optional secured versions. The same secured versions may be used 1132 with this draft, and whatever security is deployed for a given 1133 network also applies to the flows in this draft. 1135 TODO: should probably consider how P-DAO messages could be abused by 1136 a) rogue nodes b) via replay of messages c) if use of P-DAO messages 1137 could in fact deal with any threats? 1139 9. IANA Considerations 1141 9.1. New Elective 6LoWPAN Routing Header Type 1143 This document updates the IANA registry titled "Elective 6LoWPAN 1144 Routing Header Type" that was created for [RFC8138] and assigns the 1145 following value: 1147 +=======+=============+===============+ 1148 | Value | Description | Reference | 1149 +=======+=============+===============+ 1150 | 7 | P-RPI-6LoRH | This document | 1151 +-------+-------------+---------------+ 1153 Table 1: New Elective 6LoWPAN 1154 Routing Header Type 1156 9.2. New Critical 6LoWPAN Routing Header Type 1158 This document updates the IANA registry titled "Critical 6LoWPAN 1159 Routing Header Type" that was created for [RFC8138] and assigns the 1160 following value: 1162 +=======+=============+===============+ 1163 | Value | Description | Reference | 1164 +=======+=============+===============+ 1165 | 7 | P-RPI-6LoRH | This document | 1166 +-------+-------------+---------------+ 1168 Table 2: New Critical 6LoWPAN 1169 Routing Header Type 1171 9.3. New Subregistry For The RPL Option Flags 1173 IANA is required to create a subregistry for the 8-bit RPL Option 1174 Flags field, as detailed in Figure 2, under the "Routing Protocol for 1175 Low Power and Lossy Networks (RPL)" registry. The bits are indexed 1176 from 0 (leftmost) to 7. Each bit is tracked with the following 1177 qualities: 1179 * Bit number (counting from bit 0 as the most significant bit) 1181 * Indication When Set 1183 * Reference 1185 Registration procedure is "Standards Action" [RFC8126]. The initial 1186 allocation is as indicated in Table 6: 1188 +============+======================+===============+ 1189 | Bit number | Indication When Set | Reference | 1190 +============+======================+===============+ 1191 | 0 | Down 'O' | [RFC6553] | 1192 +------------+----------------------+---------------+ 1193 | 1 | Rank-Error (R) | [RFC6553] | 1194 +------------+----------------------+---------------+ 1195 | 2 | Forwarding-Error (F) | [RFC6553] | 1196 +------------+----------------------+---------------+ 1197 | 3 | Projected-Route (P) | This document | 1198 +------------+----------------------+---------------+ 1200 Table 3: Initial PDR Flags 1202 9.4. New RPL Control Codes 1204 This document extends the IANA Subregistry created by RFC 6550 for 1205 RPL Control Codes as indicated in Table 4: 1207 +======+=============================+===============+ 1208 | Code | Description | Reference | 1209 +======+=============================+===============+ 1210 | 0x09 | Projected DAO Request (PDR) | This document | 1211 +------+-----------------------------+---------------+ 1212 | 0x0A | PDR-ACK | This document | 1213 +------+-----------------------------+---------------+ 1215 Table 4: New RPL Control Codes 1217 9.5. New RPL Control Message Options 1219 This document extends the IANA Subregistry created by RFC 6550 for 1220 RPL Control Message Options as indicated in Table 5: 1222 +=======+==========================================+===============+ 1223 | Value | Meaning | Reference | 1224 +=======+==========================================+===============+ 1225 | 0x0B | Stateful Via Information option (SF-VIO) | This document | 1226 +-------+------------------------------------------+---------------+ 1227 | 0x0C | Source-Routed Via Information option | This document | 1228 | | (SR-VIO) | | 1229 +-------+------------------------------------------+---------------+ 1230 | 0x0D | Sibling Information option | This document | 1231 +-------+------------------------------------------+---------------+ 1233 Table 5: RPL Control Message Options 1235 9.6. SubRegistry for the Projected DAO Request Flags 1237 IANA is required to create a registry for the 8-bit Projected DAO 1238 Request (PDR) Flags field. Each bit is tracked with the following 1239 qualities: 1241 * Bit number (counting from bit 0 as the most significant bit) 1243 * Capability description 1245 * Reference 1247 Registration procedure is "Standards Action" [RFC8126]. The initial 1248 allocation is as indicated in Table 6: 1250 +============+========================+===============+ 1251 | Bit number | Capability description | Reference | 1252 +============+========================+===============+ 1253 | 0 | PDR-ACK request (K) | This document | 1254 +------------+------------------------+---------------+ 1255 | 1 | Requested path should | This document | 1256 | | be redundant (R) | | 1257 +------------+------------------------+---------------+ 1259 Table 6: Initial PDR Flags 1261 9.7. SubRegistry for the PDR-ACK Flags 1263 IANA is required to create an subregistry for the 8-bit PDR-ACK Flags 1264 field. Each bit is tracked with the following qualities: 1266 * Bit number (counting from bit 0 as the most significant bit) 1268 * Capability description 1270 * Reference 1272 Registration procedure is "Standards Action" [RFC8126]. No bit is 1273 currently defined for the PDR-ACK Flags. 1275 9.8. Subregistry for the PDR-ACK Acceptance Status Values 1277 IANA is requested to create a Subregistry for the PDR-ACK Acceptance 1278 Status values. 1280 * Possible values are 6-bit unsigned integers (0..63). 1282 * Registration procedure is "Standards Action" [RFC8126]. 1284 * Initial allocation is as indicated in Table 7: 1286 +-------+------------------------+---------------+ 1287 | Value | Meaning | Reference | 1288 +-------+------------------------+---------------+ 1289 | 0 | Unqualified acceptance | This document | 1290 +-------+------------------------+---------------+ 1292 Table 7: Acceptance values of the PDR-ACK Status 1294 9.9. Subregistry for the PDR-ACK Rejection Status Values 1296 IANA is requested to create a Subregistry for the PDR-ACK Rejection 1297 Status values. 1299 * Possible values are 6-bit unsigned integers (0..63). 1301 * Registration procedure is "Standards Action" [RFC8126]. 1303 * Initial allocation is as indicated in Table 8: 1305 +-------+-----------------------+---------------+ 1306 | Value | Meaning | Reference | 1307 +-------+-----------------------+---------------+ 1308 | 0 | Unqualified rejection | This document | 1309 +-------+-----------------------+---------------+ 1311 Table 8: Rejection values of the PDR-ACK Status 1313 9.10. SubRegistry for the Via Information Options Flags 1315 IANA is requested to create a Subregistry for the 5-bit Via 1316 Information Options (Via Option) Flags field. Each bit is tracked 1317 with the following qualities: 1319 * Bit number (counting from bit 0 as the most significant bit) 1321 * Capability description 1323 * Reference 1325 Registration procedure is "Standards Action" [RFC8126]. No bit is 1326 currently defined for the Via Information Options (Via Option) Flags. 1328 9.11. SubRegistry for the Sibling Information Option Flags 1330 IANA is required to create a registry for the 5-bit Sibling 1331 Information Option (SIO) Flags field. Each bit is tracked with the 1332 following qualities: 1334 * Bit number (counting from bit 0 as the most significant bit) 1336 * Capability description 1338 * Reference 1340 Registration procedure is "Standards Action" [RFC8126]. The initial 1341 allocation is as indicated in Table 9: 1343 +============+===================================+===============+ 1344 | Bit number | Capability description | Reference | 1345 +============+===================================+===============+ 1346 | 0 | Connectivity is bidirectional (B) | This document | 1347 +------------+-----------------------------------+---------------+ 1349 Table 9: Initial SIO Flags 1351 9.12. Error in Projected Route ICMPv6 Code 1353 In some cases RPL will return an ICMPv6 error message when a message 1354 cannot be forwarded along a Projected Route. This ICMPv6 error 1355 message is "Error in Projected Route". 1357 IANA has defined an ICMPv6 "Code" Fields Registry for ICMPv6 Message 1358 Types. ICMPv6 Message Type 1 describes "Destination Unreachable" 1359 codes. This specification requires that a new code is allocated from 1360 the ICMPv6 Code Fields Registry for ICMPv6 Message Type 1, for "Error 1361 in Projected Route", with a suggested code value of 8, to be 1362 confirmed by IANA. 1364 10. Acknowledgments 1366 The authors wish to acknowledge JP Vasseur, Remy Liubing, James 1367 Pylakutty and Patrick Wetterwald for their contributions to the ideas 1368 developed here. 1370 11. Normative References 1372 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1373 Requirement Levels", BCP 14, RFC 2119, 1374 DOI 10.17487/RFC2119, March 1997, 1375 . 1377 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1378 Control Message Protocol (ICMPv6) for the Internet 1379 Protocol Version 6 (IPv6) Specification", STD 89, 1380 RFC 4443, DOI 10.17487/RFC4443, March 2006, 1381 . 1383 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 1384 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1385 DOI 10.17487/RFC6282, September 2011, 1386 . 1388 [RPL] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1389 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1390 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1391 Low-Power and Lossy Networks", RFC 6550, 1392 DOI 10.17487/RFC6550, March 2012, 1393 . 1395 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 1396 Power and Lossy Networks (RPL) Option for Carrying RPL 1397 Information in Data-Plane Datagrams", RFC 6553, 1398 DOI 10.17487/RFC6553, March 2012, 1399 . 1401 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 1402 Routing Header for Source Routes with the Routing Protocol 1403 for Low-Power and Lossy Networks (RPL)", RFC 6554, 1404 DOI 10.17487/RFC6554, March 2012, 1405 . 1407 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1408 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1409 May 2017, . 1411 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1412 Writing an IANA Considerations Section in RFCs", BCP 26, 1413 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1414 . 1416 12. Informative References 1418 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 1419 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 1420 2014, . 1422 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and 1423 J. Martocci, "Reactive Discovery of Point-to-Point Routes 1424 in Low-Power and Lossy Networks", RFC 6997, 1425 DOI 10.17487/RFC6997, August 2013, 1426 . 1428 [6TiSCH-ARCHI] 1429 Thubert, P., "An Architecture for IPv6 over the TSCH mode 1430 of IEEE 802.15.4", Work in Progress, Internet-Draft, 1431 draft-ietf-6tisch-architecture-29, 27 August 2020, 1432 . 1435 [RAW-ARCHI] 1436 Thubert, P., Papadopoulos, G., and R. Buddenberg, 1437 "Reliable and Available Wireless Architecture/Framework", 1438 Work in Progress, Internet-Draft, draft-pthubert-raw- 1439 architecture-05, 15 November 2020, 1440 . 1443 [TURN-ON_RFC8138] 1444 Thubert, P. and L. Zhao, "A RPL DODAG Configuration Option 1445 for the 6LoWPAN Routing Header", Work in Progress, 1446 Internet-Draft, draft-ietf-roll-turnon-rfc8138-17, 30 1447 September 2020, . 1450 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 1451 "Deterministic Networking Architecture", RFC 8655, 1452 DOI 10.17487/RFC8655, October 2019, 1453 . 1455 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 1456 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 1457 RFC 8025, DOI 10.17487/RFC8025, November 2016, 1458 . 1460 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 1461 "IPv6 over Low-Power Wireless Personal Area Network 1462 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 1463 April 2017, . 1465 [USEofRPLinfo] 1466 Robles, I., Richardson, M., and P. Thubert, "Using RPI 1467 Option Type, Routing Header for Source Routes and IPv6-in- 1468 IPv6 encapsulation in the RPL Data Plane", Work in 1469 Progress, Internet-Draft, draft-ietf-roll-useofrplinfo-42, 1470 12 November 2020, . 1473 [PCE] IETF, "Path Computation Element", 1474 . 1476 Appendix A. Applications 1478 A.1. Loose Source Routing 1480 A RPL implementation operating in a very constrained LLN typically 1481 uses the Non-Storing Mode of Operation as represented in Figure 11. 1482 In that mode, a RPL node indicates a parent-child relationship to the 1483 Root, using a Destination Advertisement Object (DAO) that is unicast 1484 from the node directly to the Root, and the Root typically builds a 1485 source routed path to a destination down the DODAG by recursively 1486 concatenating this information. 1488 ------+--------- 1489 | Internet 1490 | 1491 +-----+ 1492 | | Border Router 1493 | | (RPL Root) 1494 +-----+ ^ | | 1495 | | DAO | ACK | 1496 o o o o | | | Strict 1497 o o o o o o o o o | | | Source 1498 o o o o o o o o o o | | | Route 1499 o o o o o o o o o | | | 1500 o o o o o o o o | v v 1501 o o o o 1502 LLN 1504 Figure 11: RPL Non-Storing Mode of operation 1506 Based on the parent-children relationships expressed in the non- 1507 storing DAO messages,the Root possesses topological information about 1508 the whole network, though this information is limited to the 1509 structure of the DODAG for which it is the destination. A packet 1510 that is generated within the domain will always reach the Root, which 1511 can then apply a source routing information to reach the destination 1512 if the destination is also in the DODAG. Similarly, a packet coming 1513 from the outside of the domain for a destination that is expected to 1514 be in a RPL domain reaches the Root. 1516 It results that the Root, or then some associated centralized 1517 computation engine such as a PCE, can determine the amount of packets 1518 that reach a destination in the RPL domain, and thus the amount of 1519 energy and bandwidth that is wasted for transmission, between itself 1520 and the destination, as well as the risk of fragmentation, any 1521 potential delays because of a paths longer than necessary (shorter 1522 paths exist that would not traverse the Root). 1524 As a network gets deep, the size of the source routing header that 1525 the Root must add to all the downward packets becomes an issue for 1526 nodes that are many hops away. In some use cases, a RPL network 1527 forms long lines and a limited amount of well-Targeted routing state 1528 would allow to make the source routing operation loose as opposed to 1529 strict, and save packet size. Limiting the packet size is directly 1530 beneficial to the energy budget, but, mostly, it reduces the chances 1531 of frame loss and/or packet fragmentation, which is highly 1532 detrimental to the LLN operation. Because the capability to store a 1533 routing state in every node is limited, the decision of which route 1534 is installed where can only be optimized with a global knowledge of 1535 the system, a knowledge that the Root or an associated PCE may 1536 possess by means that are outside of the scope of this specification. 1538 This specification enables to store a Storing Mode state in 1539 intermediate routers, which enables to limit the excursion of the 1540 source route headers in deep networks. Once a P-DAO exchange has 1541 taken place for a given Target, if the Root operates in non Storing 1542 Mode, then it may elide the sequence of routers that is installed in 1543 the network from its source route headers to destination that are 1544 reachable via that Target, and the source route headers effectively 1545 become loose. 1547 A.2. Transversal Routes 1549 RPL is optimized for Point-to-Multipoint (P2MP) and Multipoint-to- 1550 Point (MP2P), whereby routes are always installed along the RPL DODAG 1551 respectively from and towards the DODAG Root. Transversal Peer to 1552 Peer (P2P) routes in a RPL network will generally suffer from some 1553 elongated (stretched) path versus the best possible path, since 1554 routing between 2 nodes always happens via a common parent, as 1555 illustrated in Figure 12: 1557 * In Storing Mode, unless the destination is a child of the source, 1558 the packets will follow the default route up the DODAG as well. 1559 If the destination is in the same DODAG, they will eventually 1560 reach a common parent that has a route to the destination; at 1561 worse, the common parent may also be the Root. From that common 1562 parent, the packet will follow a path down the DODAG that is 1563 optimized for the Objective Function that was used to build the 1564 DODAG. 1566 * in Non-Storing Mode, all packets routed within the DODAG flow all 1567 the way up to the Root of the DODAG. If the destination is in the 1568 same DODAG, the Root must encapsulate the packet to place an RH 1569 that has the strict source route information down the DODAG to the 1570 destination. This will be the case even if the destination is 1571 relatively close to the source and the Root is relatively far off. 1573 ------+--------- 1574 | Internet 1575 | 1576 +-----+ 1577 | | Border Router 1578 | | (RPL Root) 1579 +-----+ 1580 X 1581 ^ v o o 1582 ^ o o v o o o o o 1583 ^ o o o v o o o o o 1584 ^ o o v o o o o o 1585 S o o o D o o o 1586 o o o o 1587 LLN 1589 Figure 12: Routing Stretch between S and D via common parent X 1591 It results that it is often beneficial to enable transversal P2P 1592 routes, either if the RPL route presents a stretch from shortest 1593 path, or if the new route is engineered with a different objective, 1594 and that it is even more critical in Non-Storing Mode than it is in 1595 Storing Mode, because the routing stretch is wider. For that reason, 1596 earlier work at the IETF introduced the "Reactive Discovery of 1597 Point-to-Point Routes in Low Power and Lossy Networks" [RFC6997], 1598 which specifies a distributed method for establishing optimized P2P 1599 routes. This draft proposes an alternate based on a centralized 1600 route computation. 1602 ------+--------- 1603 | Internet 1604 | 1605 +-----+ 1606 | | Border Router 1607 | | (RPL Root) 1608 +-----+ 1609 | 1610 o o o o 1611 o o o o o o o o o 1612 o o o o o o o o o o 1613 o o o o o o o o o 1614 S>>A>>>B>>C>>>D o o o 1615 o o o o 1616 LLN 1618 Figure 13: Projected Transversal Route 1620 This specification enables to store source-routed or Storing Mode 1621 state in intermediate routers, which enables to limit the stretch of 1622 a P2P route and maintain the characteristics within a given SLA. An 1623 example of service using this mechanism oculd be a control loop that 1624 would be installed in a network that uses classical RPL for 1625 asynchronous data collection. In that case, the P2P path may be 1626 installed in a different RPL Instance, with a different objective 1627 function. 1629 Authors' Addresses 1631 Pascal Thubert (editor) 1632 Cisco Systems, Inc 1633 Building D 1634 45 Allee des Ormes - BP1200 1635 06254 Mougins - Sophia Antipolis 1636 France 1638 Phone: +33 497 23 26 34 1639 Email: pthubert@cisco.com 1641 Rahul Arvind Jadhav 1642 Huawei Tech 1643 Kundalahalli Village, Whitefield, 1644 Bangalore 560037 1645 Karnataka 1646 India 1648 Phone: +91-080-49160700 1649 Email: rahul.ietf@gmail.com 1651 Matthew Gillmore 1652 Itron, Inc 1653 Building D 1654 2111 N Molter Road 1655 Liberty Lake, 99019 1656 United States 1658 Phone: +1.800.635.5461 1659 Email: matthew.gillmore@itron.com