idnits 2.17.1 draft-ietf-6lo-deadline-time-05.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 8, 2019) is 1754 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) ** Downref: Normative reference to an Informational draft: draft-ietf-6tisch-terminology (ref. 'I-D.ietf-6tisch-terminology') ** Downref: Normative reference to an Informational RFC: RFC 7384 ** Downref: Normative reference to an Informational RFC: RFC 7554 == Outdated reference: A later version (-20) exists of draft-ietf-6lo-backbone-router-11 == Outdated reference: A later version (-10) exists of draft-ietf-6lo-blemesh-05 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-24 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-06 == Outdated reference: A later version (-44) exists of draft-ietf-roll-useofrplinfo-31 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6lo Lijo Thomas 3 Internet-Draft C-DAC 4 Intended status: Standards Track S. Anamalamudi 5 Expires: January 9, 2020 SRM University-AP 6 S.V.R.Anand 7 Malati Hegde 8 Indian Institute of Science 9 C. Perkins 10 Futurewei 11 July 8, 2019 13 Packet Delivery Deadline time in 6LoWPAN Routing Header 14 draft-ietf-6lo-deadline-time-05 16 Abstract 18 This document specifies a new type for the 6LoWPAN routing header 19 containing the deadline time for data packets, designed for use over 20 constrained networks. The deadline time enables forwarding and 21 scheduling decisions for time critical IoT machine to machine (M2M) 22 applications that operate within time-synchronized networks that 23 agree on the meaning of the time representations used for the 24 deadline time values. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 9, 2020. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. 6LoRHE Generic Format . . . . . . . . . . . . . . . . . . . . 3 63 4. Deadline-6LoRHE . . . . . . . . . . . . . . . . . . . . . . . 4 64 5. Deadline-6LoRHE Format . . . . . . . . . . . . . . . . . . . 6 65 6. Deadline-6LoRHE in Three Network Scenarios . . . . . . . . . 8 66 6.1. Scenario 1: Endpoints in the same DODAG (N1) . . . . . . 9 67 6.2. Scenario 2: Endpoints in Networks with Dissimilar L2 68 Technologies. . . . . . . . . . . . . . . . . . . . . . . 10 69 6.3. Scenario 3: Packet transmission across different DODAGs 70 (N1 to N2). . . . . . . . . . . . . . . . . . . . . . . . 11 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 72 8. Synchronization Aspects . . . . . . . . . . . . . . . . . . . 13 73 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 74 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 75 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 77 11.2. Informative References . . . . . . . . . . . . . . . . . 17 78 Appendix A. Changes from revision 04 to revision 05 . . . . . . 18 79 Appendix B. Changes from revision 03 to revision 04 . . . . . . 18 80 Appendix C. Changes from revision 02 to revision 03 . . . . . . 19 81 Appendix D. Changes from revision 01 to revision 02 . . . . . . 19 82 Appendix E. Changes between earlier versions . . . . . . . . . . 20 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 85 1. Introduction 87 Low Power and Lossy Networks (LLNs) are likely to be deployed for 88 real time industrial applications requiring end-to-end delay 89 guarantees [I-D.ietf-detnet-use-cases]. A Deterministic Network 90 ("detnet") typically requires some data packets to reach their 91 receivers within strict time bounds. Intermediate nodes use the 92 deadline information to make appropriate packet forwarding and 93 scheduling decisions to meet the time bounds. 95 This document specifies a new type for the Elective 6LoWPAN Routing 96 Header (6LoRHE), so that the deadline time (i.e., the time of latest 97 acceptable delivery) of data packets can be included within the 98 6LoWPAN routing header. [RFC8138] specifies the 6LoWPAN Routing 99 Header (6LoRH), compression schemes for RPL routing (source routing) 100 operation [RFC6554], header compression of RPL Packet Information 101 [RFC6553], and IP-in-IP encapsulation. This document also specifies 102 handling of the deadline time when packets traverse between time- 103 synchronized networks operating in different timezones or distinct 104 reference clocks. Time synchronization techniques are outside the 105 scope of this document. There are a number of standards available 106 for this purpose, including IEEE 1588 [ieee-1588], IEEE 802.1AS 107 [dot1AS-2011], IEEE 802.15.4-2015 TSCH [dot15-tsch], and more. 109 The Deadline-6LoRHE can be used in any time synchronized 6Lo network. 110 A 6TiSCH network is used to describe the implementation of the 111 Deadline-6LoRHE, but this does not preclude its use in scenarios 112 other than 6TiSCH. For instance, there is a growing interest in 113 using 6lo over a BLE mesh network [I-D.ietf-6lo-blemesh] in 114 industrial IoT [dotBLEMesh]. BLE mesh time synchronization is being 115 explored by the Bluetooth community. There are also cases under 116 consideration in Wi-SUN [Wi-SUN_PHY], [dotWi-SUN]. 118 2. Terminology 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 122 "OPTIONAL" in this document are to be interpreted as described in 123 [RFC2119] [RFC8174]. 125 This document uses the terminology defined in [RFC6550] and 126 [I-D.ietf-6tisch-terminology]. 128 3. 6LoRHE Generic Format 130 Note: this section is not normative and is included for convenience. 131 The generic header format of the 6LoRHE is specified in 132 [I-D.ietf-roll-routing-dispatch]. Figure 1 illustrates the 6LoRHE 133 generic format. 135 0 1 136 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 138 |1|0|1| Length | Type | Options | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 140 <--- length ---> 142 Figure 1: 6LoRHE format 144 o Length: Length of the 6LoRHE expressed in bytes, excluding the 145 first 2 bytes. This enables a node to skip a 6LoRHE if the Type 146 is not recognized/supported. 148 o Type (variable length): Type of the 6LoRHE (see Section 7) 150 4. Deadline-6LoRHE 152 The Deadline-6LoRHE (see Figure 3) is an elective 6LoRH (i.e., a 153 6LoRHE [RFC8138]) that provides the Deadline Time (DT) for an IPv6 154 datagram in a compressed form. Along with the deadline, the header 155 can include the packet Origination Time Delta (OTD), the time at 156 which the packet is enqueued for transmission (expressed as a value 157 to be subtracted from DT); this enables a close estimate of the total 158 delay incurred by a packet. The OTD field is initialized by the 159 sender based on the current time at the outgoing network interface 160 through which the packet is forwarded. Since the OTD is a delta, the 161 length of the OTD field (i.e., OTL) will require fewer bits than the 162 length of the DT field (i.e., DTL). 164 The deadline field contains the value of the deadline time for the 165 packet -- in other words, the time by which the application expects 166 the packet to be delivered to the Receiver. 168 packet_deadline_time = packet_origination_time + max_delay 170 In order to support delay-sensitive deterministic applications, all 171 nodes within the network should process the Deadline-6LoRHE. The 172 packet deadline time (DT) and origination time (OTD) are represented 173 in time units determined by a scaling parameter in the routing 174 header. The Network ASN (Absolute Slot Number) can be used as a time 175 unit in a time slotted synchronized network (for instance a 6TiSCH 176 network, where global time is maintained in the units of slot lengths 177 of a certain resolution). 179 The delay experienced by packets in the network is a useful metric 180 for network diagnostics and performance monitoring. Whenever a 181 packet crosses into a network using a different reference clock, the 182 Destination Time field is updated to represent the same Destination 183 Time, but expressed using the reference clock of the interface into 184 the new network. Then the origination time is the same as the 185 current time when the packet is transmitted into the new network, 186 minus the delay already experienced by the packet, say 'current_dly'. 187 In this way, within the newly entered network, the packet will appear 188 to have originated 'current_dly' time units earlier with respect to 189 the reference clock of the new network. 191 new_network_origin_time = time_now_in_new_network - current_dly 192 The following example illustrates these calculations when a packet 193 travels between three networks, each in a different time zone. 'x' 194 can be 1, 2 or 3. Suppose that the deadline time as measured in 195 timezone 1 is 1050 and the origination time is 50. Suppose that the 196 difference between TZ2 and TZ1 is 900, and the difference between TZ3 197 and TZ3 is 3600. In the figure, OT is the origination time as 198 measured in the current timezone, and is equal to DT - OTD, that is, 199 DT - 1000. Figure 2 uses the following abbreviations: 201 TxA : Time of arrival of packet in the network 'x' 203 TxD : Departure time of packet from the network 'x' 205 dlyx : Delay experienced by the packet in the previous network(s) 207 TZx : The time zone of network 'x' 209 TZ1 TZ2 TZ3 210 T1A=50| | | 211 |---- dly1=50 | | 212 | \ | | 213 | \ | | 214 | \ T1D=100 |T2A=1000 | 215 | -------->|----- dly2=450 | 216 | | \ | 217 | | \ | 218 | | \ T2D=1400 | T3A=5000 219 | | ------------------->|----------> 220 | | | 221 v v v 223 dly0 = 0 dly1 = T1D-OT1 dly2 = T2D-OT2 224 = 100-50 = 1400 - 950 225 = 50 = 450 227 OT1 = T1A-dly0 OT2 = T2A-dly1 OT3 = T3A-dly2 228 = 50 = 1000-50 = 5000 - 450 229 = 950 = 4550 231 Figure 2: Destination Time Update example 233 There are multiple ways that a packet can be delayed, including 234 queuing delay, MAC layer contention delay, serialization delay, and 235 propagation delays. Sometimes there are processing delays as well. 236 For the purpose of determining whether or not the deadline has 237 already passed, these various delays are not distinguished. 239 5. Deadline-6LoRHE Format 241 0 1 2 3 242 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 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 |1|0|1| Length | 6LoRH Type |D| TU| DTL | OTL | BinaryPt | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | DT (variable length) | OTD(variable length)(optional)| 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 Figure 3: Deadline-6LoRHE format 251 o Length (5 bits): Length represents the total length of the 252 Deadline-6LoRHE type measured in octets. 253 o 6LoRH Type: TBD (see Section 7) 254 o D flag (1 bit): The 'D' flag, set by the Sender, qualifies the 255 action to be taken when a 6LR detects that the deadline time has 256 elapsed. If 'D' bit is 1, then the 6LR MUST drop the packet if 257 the deadline time is elapsed. If 'D' bit is 0, the packet MAY be 258 forwarded on an exception basis, if the forwarding node is NOT in 259 a situation of constrained resource, and if there are reasons to 260 suspect that downstream nodes might find it useful (delay 261 measurements, interpolations, etc.). 262 o TU (2 bits) : Indicates the time units for DT and OTD fields. The 263 encodings for the DT and OTD fields use the same time units and 264 precision. 266 * 00 : Time represented in seconds and fractional seconds 267 * 01 : Reserved 268 * 10 : Network ASN 269 * 11 : Reserved 270 o DTL (4 bits): Length of DT field as an unsigned 4-bit integer, 271 encoding the length of the field in hex digits, minus one. 272 o OTL (3 bits) : Length of OTD field as an unsigned 3-bit integer, 273 encoding the length of the field in hex digits. If OTL == 0, the 274 OTD field is not present. The value of OTL MUST NOT exceed the 275 value of DTL plus one. 277 * For example, DTL = 0b0000 means the deadline time in the 6LoRHE 278 is 1 hex digit (4 bits) long. OTL = 0b111 means the 279 origination time is 7 hex digits (28 bits) long. 280 o Binary Pt (6 bits) : If zero, the number of bits of the integer 281 part the DT is equal to the number of bits of the fractional part 282 of the DT. if nonzero, the Binary Pt is a signed integer 283 determining the position of the binary point within the value for 284 the DT. 286 * If BinaryPt value is positive, then the number of bits for the 287 integer part of the DT is increased by the value of BinaryPt, 288 and the number of bits for the fractional part of the DT is 289 correspondingly reduced. This increases the range of DT. 290 * If BinaryPt value is negative, then the number of bits for the 291 integer part of the DT is decreased by the value of BinaryPt, 292 and the number of bits for the fractional part of the DT is 293 correspondingly increased. This increases the precision of the 294 fractional seconds part of DT. 295 o DT Value (8..64-bit) : An unsigned integer of DTL+1 hex digits 296 giving the Deadline Time value 297 o OTD Value (8..64-bit) : An unsigned integer of OTL hex digits 298 giving the Origination Time as a negative offset from the DT value 300 Whenever a sender initiates the IP datagram, it includes the 301 Deadline-6LoRHE along with other 6LoRH information. For information 302 about the time synchronization requirements between sender and 303 receiver see Section 8. 305 For the chosen time unit, a compressed time representation is 306 available as follows. First, the application on the originating node 307 has to determine how many time bits are needed to represent the 308 difference between the time at which the packet is launched and the 309 deadline time, including the representation of fractional time units. 310 That number of bits (say, N_bits) determines DTL (the length of the 311 Deadline Time (DT)) as follows: 313 DTL = (N_bits mod 4) 315 The number of bits determined by DTL allows counting any number of 316 fractional time units in the range of interest determined by DT and 317 the origination time OT. Denote this number of fractional time units 318 to be Epoch_Range(DTL) (i.e., Epoch_Range is a function of DTL). 320 Epoch_Range(DTL) = (2^(4*(DTL+1)) 322 Each point of time between OT and DT is represented by a time unit 323 and a fractional time unit; in this section, this combined 324 representation is called a rational time unit (RTU). 1 RTU measures 325 the smallest fractional time that can be represented between two 326 points of time in the epoch (i.e., within the range of interest). 328 DT - OT cannot exceed 2^(4*(DTL+1)) == 16^(DTL+1). A low value of 329 DTL leads to a small Epoch_Range; if DTL = 0, there will only be 16 330 RTUs within the Epoch_Range (DTL) = 16^1 (for any time unit TU). The 331 values that can be represented in the current epoch are in the range 332 [0, (Epoch_Range(DTL) - 1)]. To minimize the required DTL, 333 wraparound is allowed but works naturally with the arithmetic modulo 334 Epoch_Range. 336 By default, DTL determines t_0 in the chosen RTUs as follows: 338 t_0 = [current_time - (current_time mod Epoch_Range (DTL))]. 340 Naturally, t_0 occurs at time 0 (or time 0.0000...) in the current 341 epoch. The last possible origination time representable in the 342 current epoch (counted in RTUs) is t_last = (t0 + (2^(4*(DTL+1))-1)). 343 In the RTUs chosen, the current epoch resides at the underlying time 344 interval [t_0, t_last]. If DT - OT is greater than t_last - OT, then 345 wraparound within the Epoch_Range occurs naturally. In all cases, OT 346 is represented by the value (OT mod Epoch_Range) and DT is 347 represented by the value (DT mod Epoch_Range). All arithmetic is to 348 be performed modulo (Epoch_Range(DTL)), yielding only positive values 349 for DT - OT. 351 Example: Consider a 6TiSCH network with time-slot length of 10ms. 352 Let the time units be ASNs (TU == (binary)0b10). Let the current 353 ASN when the packet is originated be 54400, and the maximum 354 allowable delay (max_delay) for the packet delivery be 1 second 355 from the packet origination, then: 357 deadline_time = packet_origination_time + max_delay 359 = 0xD480 + 0x64 (Network ASNs) 361 = 0xD4E4 (Network ASNs) 363 Then, the Deadline-6LoRHE encoding with nonzero OTL is: 365 DTL = 3, OTL = 2, TU = 0b10, BinaryPt = 8, DT = 0xD4E4, OTD 366 = 0x64 368 6. Deadline-6LoRHE in Three Network Scenarios 370 In this section, Deadline-6LoRHE operation is described for 3 network 371 scenarios. Figure 4 depicts a constrained time-synchronized LLN that 372 has two subnets N1 and N2, connected through LBRs 373 [I-D.ietf-6lo-backbone-router] with different reference clock times 374 T1 and T2. 376 +-------------------+ 377 | Time Synchronized | 378 | Network | 379 +---------+---------+ 380 | 381 | 382 | 383 +--------------+--------------+ 384 | | 385 +-----+ +-----+ 386 | | Backbone | | Backbone 387 o | | router | | router 388 +-----+ +-----+ 389 o o o 390 o o o o o o o o o 391 o LLN o o LLN o o 392 o o o o o o o o o 393 6LoWPAN Network (subnet N1) 6LoWPAN Network (subnet N2) 395 Figure 4: Intra-network Timezone Scenario 397 6.1. Scenario 1: Endpoints in the same DODAG (N1) 399 In scenario 1, shown in Figure 5, the Sender 'S' has an IP datagram 400 to be routed to a Receiver 'R' within the same DODAG. For the route 401 segment from Sender to 6LBR, the Sender includes a Deadline-6LoRHE by 402 encoding the deadline time contained in the packet. Subsequently, 403 each 6LR will perform hop-by-hop routing to forward the packet 404 towards the 6LBR. Once 6LBR receives the IP datagram, it sends the 405 packet downstream towards 'R'. 407 In case of a network running RPL non-storing mode, the 6LBR generates 408 a IPv6-in-IPv6 encapsulated packet when sending the packet downwards 409 to the Receiver [I-D.ietf-roll-useofrplinfo]. The 6LBR copies the 410 Deadline-6LoRHE from the Sender originated IP header to the outer IP 411 header. The Deadline-6LoRHE contained in the inner IP header is 412 removed. 414 +-------+ 415 ^ | 6LBR | | 416 | | | | 417 | +-------+ | 418 Upward | / /| \ | Downward 419 routing | (F) / | \ | routing 420 | / \ (C) | (D) | 421 | / \ | | / |\ | 422 | (A) (B) : (E) : R | 423 | /|\ | \ / \ | 424 | S : : : : : : v 426 Figure 5: End points within same DODAG (subnet N1) 428 At the tunnel endpoint of the encapsulation, the Deadline-6LoRHE is 429 copied back from the outer header to inner header, and the inner IP 430 packet is delivered to 'R'. 432 6.2. Scenario 2: Endpoints in Networks with Dissimilar L2 Technologies. 434 In scenario 2, shown in Figure 6, the Sender 'S' (belonging to DODAG 435 1) has IP datagram to be routed to a Receiver 'R' over a time- 436 synchronized IPv6 network. For the route segment from 'S' to 6LBR, 437 'S' includes a Deadline-6LoRHE. Subsequently, each 6LR will perform 438 hop-by-hop routing to forward the packet towards the 6LBR. Once the 439 Deadline Time information reaches the border router, the packet will 440 be encoded according to the mechanism prescribed in the other time- 441 synchronized network depicted as "Time Synchronized Network" in the 442 figure 6. The specific data encapsulation mechanisms followed in the 443 new network are beyond the scope of this document. 445 +----------------+ 446 | Time | 447 | Synchronized |------R 448 | Network | 449 +----------------+ 450 | 451 | 452 ----------+----------- 453 ^ | 454 | +---+---+ 455 | | 6LBR | 456 Upward | | | 457 routing | +------++ 458 | (F)/ /| \ 459 | / \ / | \ 460 | / \ (C) | (D) 461 | (A) (B) | | / |\ 462 | /|\ |\ : (E) : : 463 | S : : : : / \ 464 : : 466 Figure 6: Packet transmission in Dissimilar L2 Technologies or 467 Internet 469 For instance, the IP datagram could be routed to another time 470 synchronized deterministic network using the mechanism specified in 471 the In-band OAM [I-D.ietf-ippm-ioam-data], and then the deadline time 472 would be updated according to the measurement of the current time in 473 the new network. 475 6.3. Scenario 3: Packet transmission across different DODAGs (N1 to 476 N2). 478 Consider the scenario depicted in Figure 7, in which the Sender 'S' 479 (belonging to DODAG 1) has an IP datagram to be sent to Receiver 'R' 480 belonging to another DODAG (DODAG 2). The operation of this scenario 481 can be decomposed into combination of case 1 and case 2 scenarios. 482 For the route segment from 'S' to 6LBR1, 'S' includes the Deadline- 483 6LoRHE. Subsequently, each 6LR will perform hop-by-hop operation to 484 forward the packet towards the 6LBR1. Once the IP datagram reaches 485 6LBR1 of DODAG1, it applies the same rule as described in Case 2 486 while routing the packet to 6LBR2 over a (likely) time synchronized 487 wired backhaul. The wired side of 6LBR2 can be mapped to receiver of 488 Case 2. Once the packet reaches 6LBR2, it updates the Deadline- 489 6LoRHE by adding or subtracting the difference of time of DODAG2 and 490 sends the packet downstream towards 'R'. 492 Time Synchronized Network 493 -+---------------------------+- 494 | | 495 DODAG1 +---+---+ +---+---+ DODAG2 496 | 6LBR1 | | 6LBR2 | 497 | | | | 498 +-------+ +-------+ 499 (F)/ /| \ (F)/ /| \ 500 / \ / | \ / \ / | \ 501 / \ (C) | (D) / \ (C) | (D) 502 (A) (B) | | / |\ (A) (B) | | |\ 503 /|\ |\ : (E) : : /|\ |\ : (E) : : 504 S : : : : / \ : : : : : / \ 505 : : : R 506 Network N1, time zone T1 Network N2, time zone T2 508 Figure 7: Packet transmission in different DODAGs(N1 to N2) 510 Consider an example of a 6TiSCH network in which S in DODAG1 511 generates the packet at ASN 20000 to R in DODAG2. Let the maximum 512 allowable delay be 1 second. The time-slot length in DODAG1 and 513 DODAG2 is assumed to be 10ms. Once the deadline time is encoded in 514 Deadline-6LoRHE, the packet is forwarded to 6LBR of DODAG1. Suppose 515 the packet reaches 6LBR of DODAG1 at ASN 20030. 517 current_time = ASN at LBR * slot_length_value 519 remaining_time = deadline_time - current_time 520 = ((packet_origination_time + max_delay) - current time) 521 = (20000 + 100) - 20030 522 = 30 (in Network ASNs) 523 = 30 * 10^3 milliseconds. 525 Once the Deadline Time information reaches the border router, the 526 packet will be encoded according to the mechanism prescribed in the 527 other time-synchronized network. 529 7. IANA Considerations 531 This document defines a new Elective 6LoWPAN Routing Header Type, and 532 IANA is requested to assign a value (TBD) from the 6LoWPAN Dispatch 533 Page1 number space for this purpose. 535 Elective 6LoRH Type Value 536 +----------------------+--------+ 537 | Deadline-6LoRHE | TBD | 538 +----------------------+--------+ 540 Figure 8: Deadline-6LoRHE type 542 8. Synchronization Aspects 544 The document supports time representation of the deadline and 545 origination times carried in the packets traversing through networks 546 of different time zones having different time synchronization 547 mechanisms. For instance, in a 6TiSCH network where the time is 548 maintained as ASN time slots, the time synchronization is achieved 549 through beaconing among the nodes as described in [RFC7554]. There 550 could be 6lo networks that employ NTP where the nodes are 551 synchronized with an external reference clock from an NTP server. 552 The specification of the time synchronization method that need to be 553 followed by a network is beyond the scope of the document. 555 The number of hex digits chosen to represent DT, and the portion of 556 that field allocated to represent integer number of seconds, 557 determines the meaning of t_0, i.e., the meaning of DT == 0 in the 558 chosen representation. If DTL == 0, then there are only 4 bits that 559 can be used to count the time units, so that DT == 0 can never be 560 more than 16 time units (or fractional time units) in the past. This 561 then requires that the time synchronization between sender and 562 receiver has to be tighter than 16 units. If the binary point were 563 moved so that all the bits were used for fractional time units (e.g., 564 fractional seconds or fractional ASNs), the time synchronization 565 requirement would be correspondingly tighter. 567 A 4-bit field for DT allows up to 16 hex digits, which is 64 bits. 568 That is enough to represent the NTP [RFC5905] 64-bit timestamp 569 format, which is more than enough for the purposes of establishing 570 deadline times. Unless the binary point is moved, this is enough to 571 represent time since year 1900. 573 For example, suppose that DTL = 0b0000 and the DT bits are split 574 evenly; then we can count up to 3.75 seconds by quarter-seconds. 576 If DTL = 3 and the DT bits are again split evenly, then we can count 577 up to 256 seconds (in steps of 1/256 of a second). 579 In all cases, t_0 is defined as specified in Section 5 581 t_0 = [current_time - (current_time mod (2^(4*(DTL+1))))] 583 regardless of the choice of TU. 585 For TU = 0b00, the time units are seconds. With DTL == 15, and 586 Binary Pt == 0, the epoch is (by default) January 1, 1900 at 00:00 587 UTC. The resolution is then (2 ^ (- 32)) seconds, which is the 588 maximum possible. This time format wraps around every 2^32 seconds, 589 which is roughly 136 years. 591 For TU = 0b10, the time units are ASNs. The start time is relative, 592 and updated by a mechanism out of scope for this document. With 10 593 ms slots, DTL = 15, and Binary Pt == 0, it would take over a year for 594 the ASN to wrap around. Typically, the number of hex digits 595 allocated for TU = 0b10 would be less than 15. 597 9. Security Considerations 599 The security considerations of [RFC4944], [RFC6282] and [RFC6553] 600 apply. Using a compressed format as opposed to the full in-line 601 format is logically equivalent and does not create an opening for a 602 new threat when compared to [RFC6550], [RFC6553] and [RFC6554]. 604 The protocol elements specified in this document are designed to work 605 in controlled operational environments (e.g., industrial process 606 control and automation). In order to avoid misuse of the deadline 607 information that could potentially result in a Denial of Service 608 (DoS) attack, proper functioning of this deadline time mechanism 609 requires the provisioning and management of network resources for 610 supporting traffic flows with deadlines, performance monitoring, and 611 admission control policy enforcement. The network provisioning can 612 be done either centrally or in a distributed fashion. For example, 613 tracks in a 6tisch network could be established by a centralized PCE, 614 as described in the 6tisch architecture 615 [I-D.ietf-6tisch-architecture]. 617 The Security Considerations of Detnet architecture 618 [I-D.ietf-detnet-architecture] mostly apply to this document as well, 619 as follows. To secure the request and control of resources allocated 620 for tracks, authentication and authorization can be used for each 621 device, and network controller devices. In the case of distributed 622 control protocols, security is expected to be provided by the 623 security properties of the protocols in use. 625 When deadline bearing flows are identified on a per-flow basis, which 626 may provide attackers with additional information about the data 627 flows, when compared to networks that do not include per-flow 628 identification. The security implications of disclosing that 629 additional information deserve consideration when implementing this 630 deadline specification. 632 Because of the requirement of precise time synchronization, the 633 accuracy, availability, and integrity of time synchronization is of 634 critical importance. Extensive discussion of this topic can be found 635 in [RFC7384]. 637 10. Acknowledgements 639 The authors thank Pascal Thubert for suggesting the idea and 640 encouraging the work. Thanks to Shwetha Bhandari's suggestions which 641 were instrumental in extending the timing information to 642 heterogeneous networks. The authors acknowledge the 6TiSCH WG 643 members for their inputs on the mailing list. Special thanks to 644 Jerry Daniel, Dan Frost (Routing Directorate) Charlie Kaufman 645 (Security Directorate) Seema Kumar, Tal Mizrahi Avinash Mohan, Shalu 646 Rajendran, Anita Varghese, and Dale Worley (Gen-ART review) for their 647 support and valuable feedback. 649 11. References 651 11.1. Normative References 653 [I-D.ietf-6tisch-terminology] 654 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 655 "Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e", 656 draft-ietf-6tisch-terminology-10 (work in progress), March 657 2018. 659 [I-D.ietf-detnet-architecture] 660 Finn, N., Thubert, P., Varga, B., and J. Farkas, 661 "Deterministic Networking Architecture", draft-ietf- 662 detnet-architecture-13 (work in progress), May 2019. 664 [I-D.ietf-roll-routing-dispatch] 665 Thubert, P., Bormann, C., Toutain, L., and R. Cragie, 666 "6LoWPAN Routing Header", draft-ietf-roll-routing- 667 dispatch-05 (work in progress), October 2016. 669 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 670 Requirement Levels", BCP 14, RFC 2119, 671 DOI 10.17487/RFC2119, March 1997, 672 . 674 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 675 "Transmission of IPv6 Packets over IEEE 802.15.4 676 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 677 . 679 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 680 "Network Time Protocol Version 4: Protocol and Algorithms 681 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 682 . 684 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 685 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 686 DOI 10.17487/RFC6282, September 2011, 687 . 689 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 690 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 691 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 692 Low-Power and Lossy Networks", RFC 6550, 693 DOI 10.17487/RFC6550, March 2012, 694 . 696 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 697 Power and Lossy Networks (RPL) Option for Carrying RPL 698 Information in Data-Plane Datagrams", RFC 6553, 699 DOI 10.17487/RFC6553, March 2012, 700 . 702 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 703 Routing Header for Source Routes with the Routing Protocol 704 for Low-Power and Lossy Networks (RPL)", RFC 6554, 705 DOI 10.17487/RFC6554, March 2012, 706 . 708 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 709 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 710 October 2014, . 712 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 713 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 714 Internet of Things (IoT): Problem Statement", RFC 7554, 715 DOI 10.17487/RFC7554, May 2015, 716 . 718 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 719 "IPv6 over Low-Power Wireless Personal Area Network 720 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 721 April 2017, . 723 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 724 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 725 May 2017, . 727 11.2. Informative References 729 [dot15-tsch] 730 "IEEE 802 Wireless", "IEEE Standard for Low-Rate Wireless 731 Networks, Part 15.4, IEEE Std 802.15.4-2015", April 2016. 733 [dot1AS-2011] 734 "IEEE Standards", "IEEE Standard for Local and 735 Metropolitan Area Networks - Timing and Synchronization 736 for Time-Sensitive Applications in Bridged Local Area 737 Networks", March 2011. 739 [dotBLEMesh] 740 Leonardi, L., Pattim, G., and L. Lo Bello, "Multi-Hop 741 Real-Time Communications Over Bluetooth Low Energy 742 Industrial Wireless Mesh Networks", IEEE Access Vol 6, 743 26505-26519, May 2018. 745 [dotWi-SUN] 746 Harada, H., Mizutani, K., Fujiwara, J., Mochizuki, K., 747 Obata, K., and R. Okumura, "IEEE 802.15.4g Based Wi-SUN 748 Communication Systems", IEICE Transactions on 749 Communications volume E100.B, Jan 2017. 751 [I-D.ietf-6lo-backbone-router] 752 Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 753 Backbone Router", draft-ietf-6lo-backbone-router-11 (work 754 in progress), February 2019. 756 [I-D.ietf-6lo-blemesh] 757 Gomez, C., Darroudi, S., Savolainen, T., and M. Spoerk, 758 "IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP", 759 draft-ietf-6lo-blemesh-05 (work in progress), March 2019. 761 [I-D.ietf-6tisch-architecture] 762 Thubert, P., "An Architecture for IPv6 over the TSCH mode 763 of IEEE 802.15.4", draft-ietf-6tisch-architecture-24 (work 764 in progress), July 2019. 766 [I-D.ietf-detnet-use-cases] 767 Grossman, E., "Deterministic Networking Use Cases", draft- 768 ietf-detnet-use-cases-20 (work in progress), December 769 2018. 771 [I-D.ietf-ippm-ioam-data] 772 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 773 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 774 P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, 775 "Data Fields for In-situ OAM", draft-ietf-ippm-ioam- 776 data-06 (work in progress), July 2019. 778 [I-D.ietf-roll-useofrplinfo] 779 Robles, I., Richardson, M., and P. Thubert, "Using RPL 780 Option Type, Routing Header for Source Routes and IPv6-in- 781 IPv6 encapsulation in the RPL Data Plane", draft-ietf- 782 roll-useofrplinfo-31 (work in progress), July 2019. 784 [ieee-1588] 785 "IEEE Standards", "IEEE Std 1588-2008 Standard for a 786 Precision Clock Synchronization Protocol for Networked 787 Measurement and Control Systems", July 2008. 789 [Wi-SUN_PHY] 790 Wi-SUN Alliance, "Wi-SUN PHY Specification V1.0", March 791 2016. 793 Appendix A. Changes from revision 04 to revision 05 795 This section lists the changes between draft-ietf-6lo-deadline-time 796 revisions ...-04.txt and ...-05.txt. 798 o Included additional relevant material in Security Considerations 799 regarding expected deployment scenarios and the effect of 800 disclosing additional information during the travel of a packet. 802 o Reworked the specification for using time ranges shorter than the 803 maximum allowed by the choice of TU, so that fewer bits are needed 804 to represent DT and OT. 806 o Revised the figures and examples to use new parameters 808 o Reordered the field definitions for the Deadline-6LoRHE. 810 o Responded to numerous reviewer comments to improve terminology and 811 editorial consistency. 813 Appendix B. Changes from revision 03 to revision 04 815 This section lists the changes between draft-ietf-6lo-deadline-time 816 revisions ...-03.txt and ...-04.txt. 818 o Replaced OT (Origination Time) field by OTD (Origination Time 819 Delta), allowing a more compressed representation that needs less 820 processing during transitions between networks. 822 o Changed representation for DTL, OTL, DT, OTD. Eliminated EXP in 823 favor of BinaryPt. 825 o Revised the figures and examples to use new parameters 827 o Added new section on Synchronization Aspects to supply pertinent 828 information about how nodes agree on the meaning of t=0. 830 o Responded to numerous reviewer comments to improve editorial 831 consistency and improve terminology. 833 Appendix C. Changes from revision 02 to revision 03 835 This section lists the changes between draft-ietf-6lo-deadline-time 836 revisions ...-02.txt and ...-03.txt. 838 o Added non-normative 6LoRHE description, citing RFC 8138. 840 o Specified that the Origination Time (OT) is the time that packet 841 is enqueued for transmission. 843 o Mentioned more sources of packet delay. 845 o Clarified reasons that packet MAY be forwarded if 'D' bit is 0. 847 o Clarified that DT, OT, DTL and OTL are unsigned integers. 849 o Updated bibliographic citations, including BLEmesh and Wi-SUN. 851 Appendix D. Changes from revision 01 to revision 02 853 This section lists the changes between draft-ietf-6lo-deadline-time 854 revisions ...-01.txt and ...-02.txt. 856 o Replaced 6LoRHE description by reference to RFC 8138. 858 o Added figure to illustrate change to Origination Time when a 859 packet crosses timezone boundaries. 861 o Clarified that use of 6tisch networks is descriptive, not 862 normative. 864 o Clarified that In-Band OAM is used as an example and is not 865 normative. 867 o Updated bibliographic citations. 869 o Alphabetized contributor names. 871 Appendix E. Changes between earlier versions 873 This section lists the changes between draft-ietf-6lo-deadline-time 874 revisions ...-00.txt and ...-01.txt. 876 o Changed "SHOULD drop" to "MUST drop" a packet if the deadline is 877 passed (see Section 5). 879 o Added explanatory text about how packet delays might arise. (see 880 Section 4). 882 o Mentioned availability of time-synchronization protocols (see 883 Section 1). 885 o Updated bibliographic citations. 887 o Alphabetized contributor names. 889 o Added this section. 891 Authors' Addresses 893 Lijo Thomas 894 C-DAC 895 Centre for Development of Advanced Computing (C-DAC), Vellayambalam 896 Trivandrum 695033 897 India 899 Email: lijo@cdac.in 901 Satish Anamalamudi 902 SRM University-AP 903 Amaravati Campus 904 Amaravati, Andhra Pradesh 522 502 905 India 907 Email: satishnaidu80@gmail.com 908 S.V.R Anand 909 Indian Institute of Science 910 Bangalore 560012 911 India 913 Email: anand@ece.iisc.ernet.in 915 Malati Hegde 916 Indian Institute of Science 917 Bangalore 560012 918 India 920 Email: malati@ece.iisc.ernet.in 922 Charles E. Perkins 923 Futurewei 924 2330 Central Expressway 925 Santa Clara 95050 926 Unites States 928 Email: charliep@computer.org