idnits 2.17.1 draft-koutsiamanis-roll-nsa-extension-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 (July 3, 2018) is 2124 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) == Missing Reference: 'IEEE802154-2015' is mentioned on line 449, but not defined == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-14 == Outdated reference: A later version (-13) exists of draft-ietf-detnet-architecture-06 == Outdated reference: A later version (-02) exists of draft-papadopoulos-6tisch-pre-reqs-01 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 R. Koutsiamanis, Ed. 3 Internet-Draft G. Papadopoulos 4 Intended status: Standards Track N. Montavont 5 Expires: January 4, 2019 IMT Atlantique 6 P. Thubert 7 Cisco 8 July 3, 2018 10 RPL DAG Metric Container Node State and Attribute object type extension 11 draft-koutsiamanis-roll-nsa-extension-02 13 Abstract 15 Implementing 6TiSCH Packet Replication and Elimination from / to the 16 RPL root requires the ability to forward copies of packets over 17 different paths via different RPL parents. Selecting the appropriate 18 parents to achieve ultra-low latency and jitter requires information 19 about a node's parents. This document details what information needs 20 to be transmitted and how it is encoded within a packet to enable 21 this functionality. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 4, 2019. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Tracks . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3.1. Tracks Overview . . . . . . . . . . . . . . . . . . . . . 3 61 3.2. Complex Tracks . . . . . . . . . . . . . . . . . . . . . 4 62 4. Packet Replication and Elimination principles . . . . . . . . 4 63 5. Alternative Parent Selection Issue . . . . . . . . . . . . . 5 64 6. Node State and Attribute (NSA) object type extension . . . . 6 65 6.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 6.1.1. DAG Metric Container fields . . . . . . . . . . . . . 9 67 6.1.2. Node State and Attribute fields . . . . . . . . . . . 9 68 6.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 9 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 9.1. Informative references . . . . . . . . . . . . . . . . . 10 73 9.2. Other Informative References . . . . . . . . . . . . . . 11 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 76 1. Introduction 78 Industrial network applications have stringent requirements on 79 reliability and predictability, and typically leverage 1+1 80 redundancy, aka Packet Replication and Elimination (PRE) 81 [I-D.papadopoulos-6tisch-pre-reqs] to achieve their goal. In order 82 for wireless networks to be able to be used in such applications, the 83 principles of Deterministic Networking [I-D.ietf-detnet-architecture] 84 lead to designs that aim at maximizing packet delivery rate and 85 minimizing latency and jitter. Additionally, given that the network 86 nodes often do not have an unlimited power supply, energy consumption 87 needs to be minimized as well. 89 To meet this goal, IEEE Std. 802.15.4 [IEEE802154-2015] provides 90 Time-Slotted Channel Hopping (TSCH), a mode of operation which uses a 91 fixed communication schedule to allow deterministic medium access as 92 well as channel hopping to work around radio interference. However, 93 since TSCH uses retransmissions in the event of a failed 94 transmission, end-to-end delay and jitter performance can 95 deteriorate. 97 The 6TiSCH working group, focusing on IPv6 over IEEE Std. 98 802.15.4-TSCH, has worked on the issues previously highlighted and 99 produced the "6TiSCH Architecture" [I-D.ietf-6tisch-architecture] to 100 address that case. Building on this architecture, "Exploiting Packet 101 Replication and Elimination in Complex Tracks in 6TiSCH LLNs" 102 [I-D.papadopoulos-6tisch-pre-reqs] leverages PRE to improve the 103 Packet Delivery Ratio (PDR), provide a hard bound to the end-to-end 104 latency, and limit jitter. 106 PRE achieves a controlled redundancy by laying multiple forwarding 107 paths through the network and using them in parallel for different 108 copies of a same packet. PRE can follow the Destination-Oriented 109 Directed Acyclic Graph (DODAG) formed by RPL from a node to the root. 110 Building a multi-path DODAG can be achieved based on the RPL 111 capability of having multiple parents for each node in a network, a 112 subset of which is used to forward packets. In order for this subset 113 to be defined, a RPL parent subset selection mechanism, which falls 114 within the remit of the RPL Objective Function (OF), needs to have 115 specific path information. The specification of the transmission of 116 this information is the focus of this document. 118 More concretely, this specification focuses on the extensions to the 119 DAG Metric Container [RFC6551] required for providing the PRE 120 mechanism a part of the information it needs to operate. This 121 information is the RPL [RFC6550] parent address set of a node and it 122 must be sent to potential children nodes of the node. The RPL DIO 123 Control Message is the canonical way of broadcasting this kind of 124 information and therefore its DAG Metric Container [RFC6551] field is 125 used to append a Node State and Attribute (NSA) object. The node's 126 parent address set is stored as an optional TLV within the NSA 127 object. This specification defines the type value and structure for 128 this TLV. 130 2. Terminology 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 3. Tracks 138 3.1. Tracks Overview 140 The concept of Track is introduced in the "6TiSCH Architecture" 141 [I-D.ietf-6tisch-architecture], defined as a sequence of elements, 142 each consisting of the 3-tuple of a transmitter, a receiver, and a 143 given timeslot expressed as a slotOffset/channelOffset tuple. A 144 simple Track is intended to provide the full resources required to 145 allow the transmission of a single packet from a source 6TiSCH node 146 to a destination 6TiSCH node across a 6TiSCH multihop path. 148 3.2. Complex Tracks 150 Similarly to, but as a generalization of a simple Track, a Complex 151 Track is defined in the "6TiSCH Architecture" 152 [I-D.ietf-6tisch-architecture] as a DODAG starting at a source 6TiSCH 153 node and leading to a sink 6TiSCH node in order to support multi-path 154 forwarding. Multiple independent paths may be produced by using 155 techniques for Packet Replication and Elimination (PRE) 156 [I-D.papadopoulos-6tisch-pre-reqs] based on DetNet 157 [I-D.ietf-detnet-architecture] principles. As an example, a complex 158 Track allows for branching off and rejoining over non-congruent 159 paths. 161 In the following Section, we will detail Deterministic Networks PRE 162 techniques. 164 4. Packet Replication and Elimination principles 166 The idea behind Packet Replication and Elimination (PRE) is to 167 transmit the same data packet through parallel and adjacent paths in 168 a network with the aim of improving reliability and predictability 169 through redundancy. 171 The process of replication consists of identifying multiple potential 172 paths, selecting a subset to use, and sending copies of a single 173 packet through each path. When receiving packets the process of 174 elimination is required so that multiple copies of the same packet 175 are not replicated again, to avoid an exponential growth in 176 unnecessary traffic. Combined together, these processes enable 177 controlled redundancy which in turn can be used to achieve the 178 previously stated goals of reliability (i.e., ultra-high packet 179 delivery rate) and predictability (i.e., ultra-low end-to-end delay 180 and jitter) in wireless networks. For example, in Figure 1, the 181 source 6TiSCH node S is sending the data packet to its RPL Default 182 Parent (DP) (node A) and Alternative Parent (AP) (node B) in two 183 different timeslots. 185 ( R ) root 186 ^^ ^^ 187 // \\ 188 // \\ 189 ( C ) ( D ) 190 ^^ ^ ^ ^^ 191 || \ / || 192 || \/ || 193 || /\ || 194 || / \ || 195 ( A ) ( B ) 196 ^^ ^ 197 || / 198 || / 199 || / 200 || / || Preferred Parent 201 ( S ) source | Potential Parent 203 Figure 1: Packet Replication: S transmits the same data packet twice: 204 to its DP (A) and to its AP (B). 206 In "Exploiting Packet Replication and Elimination in Complex Tracks 207 in 6TiSCH LLNs" [I-D.papadopoulos-6tisch-pre-reqs], the concept of 208 PRE is further expanded along with its requirements. 210 5. Alternative Parent Selection Issue 212 In the RPL protocol, each node maintains a list of potential parents. 213 For PRE, the DP node is defined as the RPL DODAG preferred parent 214 node. Furthermore, to construct an alternative path toward the root, 215 in addition to the DP node, each 6TiSCH node in the network registers 216 an AP node as well. There are multiple alternative methods of 217 selecting the AP node, functionality which is included in operation 218 of the RPL Objective Function (OF). In "Exploiting Packet 219 Replication and Elimination in Complex Tracks in 6TiSCH LLNs" 220 [I-D.papadopoulos-6tisch-pre-reqs], a scheme which allows the two 221 paths to remain correlated is detailed. More specifically, in this 222 scheme a 6TiSCH node will select an alternative parent node close to 223 its default parent node to allow the operation of overhearing between 224 parents. To do so, the node will check if its Default Grand Parent 225 (DGP), the DP of its DP, is in the set of parents of a potential AP. 226 If multiple potential APs match this condition, the AP with the 227 lowest rank will be registered. 229 ( R ) root 230 ^^ ^^ ^^ 231 // || \\ 232 // || \\ 233 // || \\ 234 // || \\ 235 ( C ) ( D ) ( E ) 236 ^^ ^ ^ ^^ ^ 237 || \ / || / 238 || \/ || / 239 || /\ || / 240 || / \ || / 241 ( A ) ( B ) 242 ^^ ^ 243 || / 244 || / 245 || / 246 || / || Preferred Parent 247 ( S ) source | Potential Parent 249 Figure 2: Example Parent Selection mechanism 251 For instance, in Figure 2, source 6TiSCH node S must know its 252 grandparent sets both through node A and through node B. In this 253 scenario, node A has the parent set {C, D} with C as DP and node B 254 has the parent set {C, D, E} with D as DP. Therefore, node S can 255 decide to use node B as its AP node, since the the DGP of S (via node 256 A) is node C, and node C is in the parent set of node B ({C, D, E}). 258 In order to select their AP node, 6TiSCH nodes need to be aware of 259 their grandparent node sets. Within RPL [RFC6550], the nodes use the 260 DODAG Information Object (DIO) Control Message to broadcast 261 information about themselves to potential children. However, RPL 262 [RFC6550], does not define how to propagate parent set related 263 information, which is what this document addresses. 265 6. Node State and Attribute (NSA) object type extension 267 For supporting PRE, nodes need to report their parent set to their 268 potential children. DIO messages can carry multiple options, out of 269 which the DAG Metric Container option [RFC6551] is the most suitable 270 structurally and semantically for the purpose of carrying the parent 271 set. The DAG Metric Container option itself can carry different 272 nested objects, out of which the Node State and Attribute (NSA) 273 [RFC6551] is appropriate for transferring generic node state data. 274 Within the Node State and Attribute it is possible to store optional 275 TLVs representing various node characteristics. As per the Node 276 State and Attribute (NSA) [RFC6551] description, no TLV have been 277 defined for use. This document defines one TLV for the purpose of 278 transmitting a node's parent set. 280 0 1 2 3 281 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 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | RPLInstanceID |Version Number | Rank | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 |G|0| MOP | Prf | DTSN | Flags | Reserved | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | | 288 + + 289 | | 290 + DODAGID + 291 | | 292 + + 293 | | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | DAGMC Type (2)| DAGMC Length | | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 297 | | 298 // DAG Metric Container data // 299 | | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 Figure 3: Example DIO Message with a DAG Metric Container option 304 The structure of the DIO Control Message when a DAG Metric Container 305 option is included is shown in Figure 3. The DAG Metric Container 306 option type (DAGMC Type in Figure 3) has the value 0x02 as per the 307 IANA registry for the RPL Control Message Options, and is defined in 308 [RFC6550]. The DAG Metric Container option length (DAGMC Length in 309 Figure 3) expresses the the DAG Metric Container length in bytes. 310 DAG Metric Container data holds the actual data and is shown further 311 expanded in Figure 4. 313 0 1 2 3 314 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 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 |Routing-MC-Type|Res Flags|P|C|O|R| A | Prec | Length (bytes)| |=>MC 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Res | Flags |A|O| PS type | PS Length | | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |=>NSA 320 | PS IPv6 address(es) ... | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 Figure 4: DAG Metric Container (MC) data with Node State and 324 Attribute (NSA) object body and a TLV 326 The structure of the DAG Metric Container data in the form of a Node 327 State and Attribute (NSA) object with a TLV in the NSA Optional TLVs 328 field is shown in Figure 4. The first 32 bits comprise the DAG 329 Metric Container header and all the following bits are part of the 330 Node State and Attribute object body, as defined in [RFC6551]. This 331 document defines a new TLV, which CAN be carried in the Node State 332 and Attribute (NSA) object Optional TLVs field. The TLV is named 333 Parent Set and is abbreviated as PS in Figure 4. 335 PS type: The type of the Parent Set TLV. The value is TBD1. 337 PS Length: The total length of the TLV value field (PS IPv6 338 address(es)) in bytes. 340 PS IPv6 address(es): A sequence of zero or more IPv6 addresses 341 belonging to a node's parent set. Each address requires 16 342 bytes. The order of the parents in the parent set is in 343 decreasing preference based on the Objective Function [RFC6550] 344 used by the node. 346 6.1. Usage 348 The PS SHOULD be used in the process of parent selection, and 349 especially in alternative parent selection, since it can help the 350 alternative path from significantly deviating from the preferred 351 path. The Parent Set is information local to the node that 352 broadcasts it. It does not make sense for this information to be 353 aggregated due to the scalability issue created by the space required 354 for many IPv6 addresses. Therefore, the PS MUST NOT be aggregated. 356 6.1.1. DAG Metric Container fields 358 Given the intended usage, when using the PS, the NSA object it is 359 contained in MUST be used as a constraint in the DAG Metric 360 Container. More specifically, using the PS places the following 361 requirements on the DAG Metric Container header fields: 363 o 'P' flag: MUST be cleared, since PS is used only with constraints. 365 o 'C' flag: MUST be set, since PS is used only with constraints. 367 o 'O' flag: Used as per [RFC6550], to indicated optionality. 369 o 'R' flag: MUST be cleared, since PS is used only with constraints. 371 o 'A' Field: MUST be set to 0 and ignored, since PS is used only 372 with constraints. 374 o 'Prec' Field: Used as per [RFC6550]. 376 6.1.2. Node State and Attribute fields 378 For reasons of clarity, the usage of the PS places no additional 379 restrictions on the NSA flags ('A' and 'O'), which can be used as 380 normally defined in [RFC6550]. 382 6.2. Compression 384 The PS IPv6 address(es) field in the Parent Set TLV add overhead due 385 to their size. Therefore, compression is highly desirable in order 386 for this extension to be usable. To meet this goal, a good 387 compression method candidate is [RFC8138] 6LoWPAN Routing Header 388 (6LoRH). Furthermore, the PS IPv6 address(es) belong by definition 389 to nodes in the same RPL DODAG and are stored in the form of a list 390 of addresses. This makes this field a good candidate for the use of 391 the same compression as in Source Routing Header 6LoRH (SRH-6LoRH), 392 achieving efficiency and implementation reuse. Therefore, the PS 393 IPv6 address(es) field SHOULD be compressed using the compression 394 method for Source Routing Header 6LoRH (SRH-6LoRH) [RFC8138]. 396 7. Security Considerations 398 TODO. 400 8. IANA Considerations 402 TBA. 404 9. References 406 9.1. Informative references 408 [I-D.ietf-6tisch-architecture] 409 Thubert, P., "An Architecture for IPv6 over the TSCH mode 410 of IEEE 802.15.4", draft-ietf-6tisch-architecture-14 (work 411 in progress), April 2018. 413 [I-D.ietf-detnet-architecture] 414 Finn, N., Thubert, P., Varga, B., and J. Farkas, 415 "Deterministic Networking Architecture", draft-ietf- 416 detnet-architecture-06 (work in progress), June 2018. 418 [I-D.papadopoulos-6tisch-pre-reqs] 419 Papadopoulos, G., Montavont, N., and P. Thubert, 420 "Exploiting Packet Replication and Elimination in Complex 421 Tracks in 6TiSCH LLNs", draft-papadopoulos-6tisch-pre- 422 reqs-01 (work in progress), December 2017. 424 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 425 Requirement Levels", BCP 14, RFC 2119, 426 DOI 10.17487/RFC2119, March 1997, 427 . 429 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 430 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 431 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 432 Low-Power and Lossy Networks", RFC 6550, 433 DOI 10.17487/RFC6550, March 2012, 434 . 436 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 437 and D. Barthel, "Routing Metrics Used for Path Calculation 438 in Low-Power and Lossy Networks", RFC 6551, 439 DOI 10.17487/RFC6551, March 2012, 440 . 442 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 443 "IPv6 over Low-Power Wireless Personal Area Network 444 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 445 April 2017, . 447 9.2. Other Informative References 449 [IEEE802154-2015] 450 IEEE standard for Information Technology, "IEEE Std 451 802.15.4-2015 Standard for Low-Rate Wireless Personal Area 452 Networks (WPANs)", December 2015. 454 Authors' Addresses 456 Remous-Aris Koutsiamanis (editor) 457 IMT Atlantique 458 Office B00 - 126A 459 2 Rue de la Chataigneraie 460 Cesson-Sevigne - Rennes 35510 461 FRANCE 463 Phone: +33 299 12 70 49 464 Email: aris@ariskou.com 466 Georgios Papadopoulos 467 IMT Atlantique 468 Office B00 - 114A 469 2 Rue de la Chataigneraie 470 Cesson-Sevigne - Rennes 35510 471 FRANCE 473 Phone: +33 299 12 70 04 474 Email: georgios.papadopoulos@imt-atlantique.fr 476 Nicolas Montavont 477 IMT Atlantique 478 Office B00 - 106A 479 2 Rue de la Chataigneraie 480 Cesson-Sevigne - Rennes 35510 481 FRANCE 483 Phone: +33 299 12 70 23 484 Email: nicolas.montavont@imt-atlantique.fr 485 Pascal Thubert 486 Cisco Systems, Inc 487 Building D 488 45 Allee des Ormes - BP1200 489 MOUGINS - Sophia Antipolis 06254 490 FRANCE 492 Phone: +33 497 23 26 34 493 Email: pthubert@cisco.com