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