idnits 2.17.1 draft-koutsiamanis-roll-nsa-extension-00.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 2262 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 361, 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-00 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 . . . . 5 66 6.1. Compression . . . . . . . . . . . . . . . . . . . . . . . 7 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 9.1. Informative references . . . . . . . . . . . . . . . . . 8 71 9.2. Other Informative References . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 Industrial network applications have stringent requirements on 77 reliability and predictability, and typically leverage 1+1 78 redundancy, aka Packet Replication and Elimination (PRE) 79 [I-D.papadopoulos-6tisch-pre-reqs] to achieve their goal. In order 80 for wireless networks to be able to be used in such applications, the 81 principles of Deterministic Networking [I-D.ietf-detnet-architecture] 82 lead to designs that aim at maximizing packet delivery rate and 83 minimizing latency and jitter. Additionally, given that the network 84 nodes often do not have an unlimited power supply, energy consumption 85 needs to be minimized as well. 87 To meet this goal, IEEE Std. 802.15.4 [IEEE802154-2015] provides 88 Time-Slotted Channel Hopping (TSCH), a mode of operation which uses a 89 fixed communication schedule to allow deterministic medium access as 90 well as channel hopping to work around radio interference. However, 91 since TSCH uses retransmissions in the event of a failed 92 transmission, end-to-end delay and jitter performance can 93 deteriorate. 95 The 6TiSCH working group, focusing on IPv6 over IEEE Std. 96 802.15.4-TSCH, has worked on the issues previously highlighted and 97 produced the "6TiSCH Architecture" [I-D.ietf-6tisch-architecture] to 98 address that case. Building on this architecture, "Exploiting Packet 99 Replication and Elimination in Complex Tracks in 6TiSCH LLNs" 100 [I-D.papadopoulos-6tisch-pre-reqs] leverages PRE to improve the 101 Packet Delivery Ratio (PDR), provide a hard bound to the end-to-end 102 latency, and limit jitter. 104 PRE achieves a controlled redundancy by laying multiple forwarding 105 paths through the network and using them in parallel for different 106 copies of a same packet. PRE can follow the Destination-Oriented 107 Directed Acyclic Graph (DODAG) formed by RPL from a node to the root. 108 Building a multi-path DODAG can be achieved based on the RPL 109 capability of having multiple parents for each node in a network, a 110 subset of which is used to forward packets. In order for this subset 111 to be defined, a RPL parent subset selection mechanism, which falls 112 within the remit of the RPL Objective Function (OF), needs to have 113 specific path information. The specification of the transmission of 114 this information is the focus of this document. 116 More concretely, this specification focuses on the extensions to the 117 DAG Metric Container [RFC6551] required for providing the PRE 118 mechanism a part of the information it needs to operate. This 119 information is the RPL [RFC6550] parent node address set of a node 120 and it must be sent to potential children nodes of the node. The RPL 121 DIO Control Message is the canonical way of broadcasting this kind of 122 information and therefore its DAG Metric Container [RFC6551] field is 123 used to append a Node State and Attribute (NSA) object. The node's 124 parent node address set is stored as an optional TLV within the NSA 125 object. This specification defines the type value and structure for 126 this TLV. 128 2. Terminology 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119]. 134 3. Tracks 136 3.1. Tracks Overview 138 The concept of Track is introduced in the "6TiSCH Architecture" 139 [I-D.ietf-6tisch-architecture], defined as a sequence of elements, 140 each consisting of the 3-tuple of a transmitter, a receiver, and a 141 given timeslot expressed as a slotOffset/channelOffset tuple. A 142 simple Track is intended to provide the full resources required to 143 allow the transmission of a single packet from a source 6TiSCH node 144 to a destination 6TiSCH node across a 6TiSCH multihop path. 146 3.2. Complex Tracks 148 Similarly to, but as a generalization of a simple Track, a Complex 149 Track is defined in the "6TiSCH Architecture" 150 [I-D.ietf-6tisch-architecture] as a DODAG starting at a source 6TiSCH 151 node and leading to a sink 6TiSCH node in order to support multi-path 152 forwarding. Multiple independent paths may be produced by using 153 techniques for Packet Replication and Elimination (PRE) 154 [I-D.papadopoulos-6tisch-pre-reqs] based on DetNet 155 [I-D.ietf-detnet-architecture] principles. As an example, a complex 156 Track allows for branching off and rejoining over congruent paths. 158 In the following Section, we will detail Deterministic Networks PRE 159 techniques. 161 4. Packet Replication and Elimination principles 163 The idea behind Packet Replication and Elimination (PRE) is to 164 transmit the same data packet through parallel and adjacent paths in 165 a network with the aim of improving reliability and predictability 166 through redundancy. 168 The process of replication consists of identifying multiple potential 169 paths, selecting a subset to use, and sending copies of a single 170 packet through each path. When receiving packets the process of 171 elimination is required so that multiple copies of the same packet 172 are not replicated again, to avoid an exponential growth in 173 unnecessary traffic. Combined together, these processes enable 174 controlled redundancy which in turn can be used to achieve the 175 previously stated goals of reliability (i.e., ultra-high packet 176 delivery rate) and predictability (i.e., ultra-low end-to-end delay 177 and jitter) in wireless networks. For example, in Figure 1, the 178 source 6TiSCH node S is sending the data packet to its what is called 179 RPL Default Parent (DP) and Alternative Parent (AP), nodes A and B, 180 in two different timeslots. 182 ===> (A) ====> (C) === 183 // \\ // \\ 184 source (S) \\ (R) (root) 185 \\ // \\ // 186 ===> (B) ====> (D) === 188 Figure 1: Packet Replication: S transmits twice the same data packet, 189 to its DP (A) and to its AP (B). 191 In Exploiting Packet Replication and Elimination in Complex Tracks in 192 6TiSCH LLNs [I-D.papadopoulos-6tisch-pre-reqs], the concept of PRE is 193 further expanded along with its requirements. 195 5. Alternative Parent Selection Issue 197 In the RPL protocol, each node maintains a list of potential parents. 198 For PRE, the DP node is defined as the RPL DODAG preferred parent 199 node. Furthermore, to construct an alternative path toward the root, 200 in addition to the DP node, each 6TiSCH node in the network registers 201 an AP node as well. There are multiple alternative methods of 202 selecting the AP node, functionality which is included in operation 203 of the RPL Objective Function (OF). In Exploiting Packet Replication 204 and Elimination in Complex Tracks in 6TiSCH LLNs 205 [I-D.papadopoulos-6tisch-pre-reqs], a scheme which allows the two 206 paths to remain correlated is detailed. More specifically, in this 207 scheme a 6TiSCH node will select an alternative parent node close to 208 its default parent node to allow the operation of overhearing between 209 parents. To do so, the node will check if its Default Grand Parent 210 (DGP), the DP of its DP, is in the set of parents of a potential AP. 211 If multiple potential APs match this condition, the AP with the 212 lowest rank will be registered. 214 For instance, in Figure 1, source 6TiSCH node S must know its 215 grandparent sets both through node A and through node B. In this 216 scenario, node A and node B have the same parent sets, nodes C and D, 217 and therefore for node S, the grandparent set through A is the same 218 as the grandparent set through B. 220 In order to select their AP node, 6TiSCH nodes need to be aware of 221 their grandparent node sets. Within RPL [RFC6550], the nodes use the 222 DODAG Information Object (DIO) Control Message to broadcast 223 information about themselves to potential children. However, RPL 224 [RFC6550], does not define how to propagate parent set related 225 information, which is what this document addresses. 227 6. Node State and Attribute (NSA) object type extension 229 For supporting PRE, nodes need to report their parent node set to 230 their potential children. DIO messages can carry multiple options, 231 out of which the DAG Metric Container option [RFC6551] is the most 232 suitable structurally and semantically for the purpose of carrying 233 the parent node set. The DAG Metric Container option itself can 234 carry different nested objects, out of which the Node State and 235 Attribute (NSA) [RFC6551] is appropriate for transferring generic 236 node state data. Within the Node State and Attribute it is possible 237 to store optional TLVs representing various node characteristics. As 238 per the Node State and Attribute (NSA) [RFC6551] description, no TLV 239 have been defined for use. This document defines one TLV for the 240 purpose of transmitting a node's parent node set. 242 0 1 2 3 243 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 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | RPLInstanceID |Version Number | Rank | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 |G|0| MOP | Prf | DTSN | Flags | Reserved | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | | 250 + + 251 | | 252 + DODAGID + 253 | | 254 + + 255 | | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | DAGMC Type (2)| DAGMC Length | | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 259 | | 260 // DAG Metric Container data // 261 | | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 Figure 2: Example DIO Message with a DAG Metric Container option 266 The structure of the DIO Control Message when a DAG Metric Container 267 option is included is shown in Figure 2. The DAG Metric Container 268 option type (DAGMC Type in Figure 2) has the value 0x02 as per the 269 IANA registry for the RPL Control Message Options, and is defined in 270 [RFC6550]. The DAG Metric Container option length (DAGMC Length in 271 Figure 2) expresses the the DAG Metric Container length in bytes. 272 DAG Metric Container data holds the actual data and is shown further 273 expanded in Figure 3. 275 0 1 2 3 276 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 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 |Routing-MC-Type|Res Flags|P|C|O|R| A | Prec | Length (bytes)| 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Res | Flags |A|O| PNS type (1) | PNS Length | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | PNS IPv6 address(es) ... 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 Figure 3: DAG Metric Container data with Node State and Attribute 286 (NSA) object body and a TLV 288 The structure of the DAG Metric Container data in the form of a Node 289 State and Attribute (NSA) object with a TLV in the NSA Optional TLVs 290 field is shown in Figure 3. The DAG Metric Container fields up to 291 the first 48 bits (including the O flag) are defined in [RFC6551] as 292 part of the Node State and Attribute (NSA) object body. This 293 document defines a new TLV, which CAN be carried in the Node State 294 and Attribute (NSA) object Optional TLVs field. The TLV is named 295 Parent Node Set and is abbreviated as PNS in Figure 3. 297 PNS type: The type of the Parent Node Set TLV. The value is 1. 299 PNS Length: The total length of the TLV value field (PNS IPv6 300 address(es)) in bytes. 302 PNS IPv6 address(es): A sequence of zero or more IPv6 addresses 303 belonging to a node's parent set. Each address requires 16 304 bytes. The order of the parents in the parent set is in 305 decreasing preference based on the Objective Function [RFC6550] 306 used by the node. 308 6.1. Compression 310 The PNS IPv6 address(es) field in the Parent Node Set TLV MAY be 311 compressed using any compression method available to conserve space. 313 7. Security Considerations 315 TODO. 317 8. IANA Considerations 319 TBA. 321 9. References 323 9.1. Informative references 325 [I-D.ietf-6tisch-architecture] 326 Thubert, P., "An Architecture for IPv6 over the TSCH mode 327 of IEEE 802.15.4", draft-ietf-6tisch-architecture-13 (work 328 in progress), November 2017. 330 [I-D.ietf-detnet-architecture] 331 Finn, N., Thubert, P., Varga, B., and J. Farkas, 332 "Deterministic Networking Architecture", draft-ietf- 333 detnet-architecture-04 (work in progress), October 2017. 335 [I-D.papadopoulos-6tisch-pre-reqs] 336 Papadopoulos, G., Montavont, N., and P. Thubert, 337 "Exploiting Packet Replication and Elimination in Complex 338 Tracks in 6TiSCH LLNs", draft-papadopoulos-6tisch-pre- 339 reqs-01 (work in progress), December 2017. 341 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 342 Requirement Levels", BCP 14, RFC 2119, 343 DOI 10.17487/RFC2119, March 1997, 344 . 346 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 347 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 348 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 349 Low-Power and Lossy Networks", RFC 6550, 350 DOI 10.17487/RFC6550, March 2012, 351 . 353 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 354 and D. Barthel, "Routing Metrics Used for Path Calculation 355 in Low-Power and Lossy Networks", RFC 6551, 356 DOI 10.17487/RFC6551, March 2012, 357 . 359 9.2. Other Informative References 361 [IEEE802154-2015] 362 IEEE standard for Information Technology, "IEEE Std 363 802.15.4-2015 Standard for Low-Rate Wireless Personal Area 364 Networks (WPANs)", December 2015. 366 Authors' Addresses 368 Remous-Aris Koutsiamanis (editor) 369 IMT Atlantique 370 Office B00 - 126A 371 2 Rue de la Chataigneraie 372 Cesson-Sevigne - Rennes 35510 373 FRANCE 375 Phone: +33 299 12 70 49 376 Email: aris@ariskou.com 378 Georgios Papadopoulos 379 IMT Atlantique 380 Office B00 - 114A 381 2 Rue de la Chataigneraie 382 Cesson-Sevigne - Rennes 35510 383 FRANCE 385 Phone: +33 299 12 70 04 386 Email: georgios.papadopoulos@imt-atlantique.fr 388 Nicolas Montavont 389 IMT Atlantique 390 Office B00 - 106A 391 2 Rue de la Chataigneraie 392 Cesson-Sevigne - Rennes 35510 393 FRANCE 395 Phone: +33 299 12 70 23 396 Email: nicolas.montavont@imt-atlantique.fr 398 Pascal Thubert 399 Cisco Systems, Inc 400 Building D 401 45 Allee des Ormes - BP1200 402 MOUGINS - Sophia Antipolis 06254 403 FRANCE 405 Phone: +33 497 23 26 34 406 Email: pthubert@cisco.com