idnits 2.17.1 draft-koutsiamanis-roll-nsa-extension-03.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 (October 22, 2018) is 2006 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 341, but not defined == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-15 == Outdated reference: A later version (-13) exists of draft-ietf-detnet-architecture-08 Summary: 0 errors (**), 0 flaws (~~), 4 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: April 25, 2019 IMT Atlantique 6 P. Thubert 7 Cisco 8 October 22, 2018 10 RPL DAG Metric Container Node State and Attribute object type extension 11 draft-koutsiamanis-roll-nsa-extension-03 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 April 25, 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. Node State and Attribute (NSA) object type extension . . . . 4 60 3.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.1.1. DAG Metric Container fields . . . . . . . . . . . . . 6 62 3.1.2. Node State and Attribute fields . . . . . . . . . . . 6 63 3.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 6 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 6.1. Informative references . . . . . . . . . . . . . . . . . 7 68 6.2. Other Informative References . . . . . . . . . . . . . . 8 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Introduction 73 Industrial network applications have stringent requirements on 74 reliability and predictability, and typically leverage 1+1 75 redundancy, aka Packet Replication and Elimination (PRE) 76 [I-D.papadopoulos-6tisch-pre-reqs] to achieve their goal. In order 77 for wireless networks to be able to be used in such applications, the 78 principles of Deterministic Networking [I-D.ietf-detnet-architecture] 79 lead to designs that aim at maximizing packet delivery rate and 80 minimizing latency and jitter. Additionally, given that the network 81 nodes often do not have an unlimited power supply, energy consumption 82 needs to be minimized as well. 84 To meet this goal, IEEE Std. 802.15.4 [IEEE802154-2015] provides 85 Time-Slotted Channel Hopping (TSCH), a mode of operation which uses a 86 fixed communication schedule to allow deterministic medium access as 87 well as channel hopping to work around radio interference. However, 88 since TSCH uses retransmissions in the event of a failed 89 transmission, end-to-end delay and jitter performance can 90 deteriorate. 92 The 6TiSCH working group, focusing on IPv6 over IEEE Std. 93 802.15.4-TSCH, has worked on the issues previously highlighted and 94 produced the "6TiSCH Architecture" [I-D.ietf-6tisch-architecture] to 95 address that case. Building on this architecture, "Exploiting Packet 96 Replication and Elimination in Complex Tracks in 6TiSCH LLNs" 98 [I-D.papadopoulos-6tisch-pre-reqs] leverages PRE to improve the 99 Packet Delivery Ratio (PDR), provide a hard bound to the end-to-end 100 latency, and limit jitter. 102 PRE achieves a controlled redundancy by laying multiple forwarding 103 paths through the network and using them in parallel for different 104 copies of a same packet. PRE can follow the Destination-Oriented 105 Directed Acyclic Graph (DODAG) formed by RPL from a node to the root. 106 Building a multi-path DODAG can be achieved based on the RPL 107 capability of having multiple parents for each node in a network, a 108 subset of which is used to forward packets. In order for this subset 109 to be defined, a RPL parent subset selection mechanism, which falls 110 within the remit of the RPL Objective Function (OF), needs to have 111 specific path information. The specification of the transmission of 112 this information is the focus of this document. 114 More concretely, this specification focuses on the extensions to the 115 DAG Metric Container [RFC6551] required for providing the PRE 116 mechanism a part of the information it needs to operate. This 117 information is the RPL [RFC6550] parent address set of a node and it 118 must be sent to potential children nodes of the node. The RPL DIO 119 Control Message is the canonical way of broadcasting this kind of 120 information and therefore its DAG Metric Container [RFC6551] field is 121 used to append a Node State and Attribute (NSA) object. The node's 122 parent address set is stored as an optional TLV within the NSA 123 object. This specification defines the type value and structure for 124 this TLV. 126 2. Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [RFC2119]. 132 The draft uses the following Terminology: 134 Track A sequence of 6TiSCH schedule resources to support a single- 135 path multi-hop transmission of a packet. See "6TiSCH 136 Architecture" [I-D.ietf-6tisch-architecture] for more. 138 Complex Track A Track which supports a multi-path multi-hop 139 transmission of a packet. See "6TiSCH Architecture" 140 [I-D.ietf-6tisch-architecture] for more. 142 Packet Replication and Elimination (PRE) The sending of multiple 143 copies of a packet using multi-path forwarding over a multi-hop 144 network and the consolidation of multiple received packet copies 145 to control flooding. See "Exploiting Packet Replication and 146 Elimination in Complex Tracks in 6TiSCH LLNs" 147 [I-D.papadopoulos-6tisch-pre-reqs] for more. 149 Alternative Parent (AP) Selection The problem of how to select the 150 next hop target node for a packet copy to be forwarded to when 151 performing packet replication. See "Exploiting Packet Replication 152 and Elimination in Complex Tracks in 6TiSCH LLNs" 153 [I-D.papadopoulos-6tisch-pre-reqs] for more. 155 3. Node State and Attribute (NSA) object type extension 157 For supporting PRE, nodes need to report their parent set to their 158 potential children. DIO messages can carry multiple options, out of 159 which the DAG Metric Container option [RFC6551] is the most suitable 160 structurally and semantically for the purpose of carrying the parent 161 set. The DAG Metric Container option itself can carry different 162 nested objects, out of which the Node State and Attribute (NSA) 163 [RFC6551] is appropriate for transferring generic node state data. 164 Within the Node State and Attribute it is possible to store optional 165 TLVs representing various node characteristics. As per the Node 166 State and Attribute (NSA) [RFC6551] description, no TLV has been 167 defined for use. This document defines one TLV for the purpose of 168 transmitting a node's parent set. 170 0 1 2 3 171 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 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | RPLInstanceID |Version Number | Rank | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 |G|0| MOP | Prf | DTSN | Flags | Reserved | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | | 178 + + 179 | | 180 + DODAGID + 181 | | 182 + + 183 | | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | DAGMC Type (2)| DAGMC Length | | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 187 | | 188 // DAG Metric Container data // 189 | | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 Figure 1: Example DIO Message with a DAG Metric Container option 194 Figure 1 shows the structure of the DIO Control Message when a DAG 195 Metric Container option is included. The DAG Metric Container option 196 type (DAGMC Type in Figure 1) has the value 0x02 as per the IANA 197 registry for the RPL Control Message Options, and is defined in 198 [RFC6550]. The DAG Metric Container option length (DAGMC Length in 199 Figure 1) expresses the DAG Metric Container length in bytes. DAG 200 Metric Container data holds the actual data and is shown expanded in 201 Figure 2. 203 0 1 2 3 204 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 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 |Routing-MC-Type|Res Flags|P|C|O|R| A | Prec | Length (bytes)| |=>MC 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Res | Flags |A|O| PS type | PS Length | | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |=>NSA 210 | PS IPv6 address(es) ... | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 Figure 2: DAG Metric Container (MC) data with Node State and 214 Attribute (NSA) object body and a TLV 216 The structure of the DAG Metric Container data in the form of a Node 217 State and Attribute (NSA) object with a TLV in the NSA Optional TLVs 218 field is shown in Figure 2. The first 32 bits comprise the DAG 219 Metric Container header and all the following bits are part of the 220 Node State and Attribute object body, as defined in [RFC6551]. This 221 document defines a new TLV, which CAN be carried in the Node State 222 and Attribute (NSA) object Optional TLVs field. The TLV is named 223 Parent Set and is abbreviated as PS in Figure 2. 225 PS type: The type of the Parent Set TLV. The value is TBD1. 227 PS Length: The total length of the TLV value field (PS IPv6 228 address(es)) in bytes. 230 PS IPv6 address(es): A sequence of zero or more IPv6 addresses 231 belonging to a node's parent set. Each address requires 16 232 bytes. The order of the parents in the parent set is in 233 decreasing preference based on the Objective Function [RFC6550] 234 used by the node. 236 3.1. Usage 238 The PS SHOULD be used in the process of parent selection, and 239 especially in alternative parent selection, since it can help the 240 alternative path from significantly deviating from the preferred 241 path. The Parent Set is information local to the node that 242 broadcasts it. 244 3.1.1. DAG Metric Container fields 246 Given the intended usage, when using the PS, the NSA object it is 247 contained in MUST be used as a constraint in the DAG Metric 248 Container. More specifically, using the PS places the following 249 requirements on the DAG Metric Container header fields: 251 o 'P' flag: MUST be cleared, since PS is used only with constraints. 253 o 'C' flag: MUST be set, since PS is used only with constraints. 255 o 'O' flag: Used as per [RFC6550], to indicated optionality. 257 o 'R' flag: MUST be cleared, since PS is used only with constraints. 259 o 'A' Field: MUST be set to 0 and ignored, since PS is used only 260 with constraints. 262 o 'Prec' Field: Used as per [RFC6550]. 264 3.1.2. Node State and Attribute fields 266 For clarity reasons, the usage of the PS places no additional 267 restrictions on the NSA flags ('A' and 'O'), which can be used as 268 normally defined in [RFC6550]. 270 3.2. Compression 272 The PS IPv6 address(es) field in the Parent Set TLV add overhead due 273 to their size. Therefore, compression is highly desirable in order 274 for this extension to be usable. To meet this goal, a good 275 compression method candidate is [RFC8138] 6LoWPAN Routing Header 276 (6LoRH). Furthermore, the PS IPv6 address(es) belong by definition 277 to nodes in the same RPL DODAG and are stored in the form of a list 278 of addresses. This makes this field a good candidate for the use of 279 the same compression as in Source Routing Header 6LoRH (SRH-6LoRH), 280 achieving efficiency and implementation reuse. Therefore, the PS 281 IPv6 address(es) field SHOULD be compressed using the compression 282 method for Source Routing Header 6LoRH (SRH-6LoRH) [RFC8138]. 284 4. Security Considerations 286 The structure of the DIO control message is extended, within the pre- 287 defined DIO options. Therefore, the security mechanisms defined in 288 RPL [RFC6550] apply to this proposed extension. 290 5. IANA Considerations 292 This proposal requests the allocation of a new value TBD1 for the 293 "Parent Set" TLV in the Routing Metric/Constraint TLVs sub-registry 294 from IANA. 296 6. References 298 6.1. Informative references 300 [I-D.ietf-6tisch-architecture] 301 Thubert, P., "An Architecture for IPv6 over the TSCH mode 302 of IEEE 802.15.4", draft-ietf-6tisch-architecture-15 (work 303 in progress), October 2018. 305 [I-D.ietf-detnet-architecture] 306 Finn, N., Thubert, P., Varga, B., and J. Farkas, 307 "Deterministic Networking Architecture", draft-ietf- 308 detnet-architecture-08 (work in progress), September 2018. 310 [I-D.papadopoulos-6tisch-pre-reqs] 311 Papadopoulos, G., Montavont, N., and P. Thubert, 312 "Exploiting Packet Replication and Elimination in Complex 313 Tracks in 6TiSCH LLNs", draft-papadopoulos-6tisch-pre- 314 reqs-02 (work in progress), July 2018. 316 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 317 Requirement Levels", BCP 14, RFC 2119, 318 DOI 10.17487/RFC2119, March 1997, 319 . 321 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 322 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 323 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 324 Low-Power and Lossy Networks", RFC 6550, 325 DOI 10.17487/RFC6550, March 2012, 326 . 328 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 329 and D. Barthel, "Routing Metrics Used for Path Calculation 330 in Low-Power and Lossy Networks", RFC 6551, 331 DOI 10.17487/RFC6551, March 2012, 332 . 334 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 335 "IPv6 over Low-Power Wireless Personal Area Network 336 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 337 April 2017, . 339 6.2. Other Informative References 341 [IEEE802154-2015] 342 IEEE standard for Information Technology, "IEEE Std 343 802.15.4-2015 Standard for Low-Rate Wireless Personal Area 344 Networks (WPANs)", December 2015. 346 Authors' Addresses 348 Remous-Aris Koutsiamanis (editor) 349 IMT Atlantique 350 Office B00 - 126A 351 2 Rue de la Chataigneraie 352 Cesson-Sevigne - Rennes 35510 353 FRANCE 355 Phone: +33 299 12 70 49 356 Email: aris@ariskou.com 358 Georgios Papadopoulos 359 IMT Atlantique 360 Office B00 - 114A 361 2 Rue de la Chataigneraie 362 Cesson-Sevigne - Rennes 35510 363 FRANCE 365 Phone: +33 299 12 70 04 366 Email: georgios.papadopoulos@imt-atlantique.fr 368 Nicolas Montavont 369 IMT Atlantique 370 Office B00 - 106A 371 2 Rue de la Chataigneraie 372 Cesson-Sevigne - Rennes 35510 373 FRANCE 375 Phone: +33 299 12 70 23 376 Email: nicolas.montavont@imt-atlantique.fr 377 Pascal Thubert 378 Cisco Systems, Inc 379 Building D 380 45 Allee des Ormes - BP1200 381 MOUGINS - Sophia Antipolis 06254 382 FRANCE 384 Phone: +33 497 23 26 34 385 Email: pthubert@cisco.com