idnits 2.17.1 draft-ietf-6lo-deadline-time-04.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 (March 8, 2019) is 1876 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 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-04 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-04 == Outdated reference: A later version (-44) exists of draft-ietf-roll-useofrplinfo-24 Summary: 2 errors (**), 0 flaws (~~), 5 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: September 9, 2019 SRM University-AP 6 S.V.R.Anand 7 Malati Hegde 8 Indian Institute of Science 9 C. Perkins 10 Futurewei 11 March 8, 2019 13 Packet Delivery Deadline time in 6LoWPAN Routing Header 14 draft-ietf-6lo-deadline-time-04 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 M2M applications that 22 operate within time-synchronized networks that agree on the meaning 23 of the time representations used for the deadline time values. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 9, 2019. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. 6LoRHE Generic Format . . . . . . . . . . . . . . . . . . . . 3 62 4. Deadline-6LoRHE . . . . . . . . . . . . . . . . . . . . . . . 4 63 5. Deadline-6LoRHE Format . . . . . . . . . . . . . . . . . . . 6 64 6. Deadline-6LoRHE in Three Network Scenarios . . . . . . . . . 7 65 6.1. Scenario 1: Endpoints in the same DODAG (N1) . . . . . . 8 66 6.2. Scenario 2: Endpoints in Networks with Dissimilar L2 67 Technologies. . . . . . . . . . . . . . . . . . . . . . . 9 68 6.3. Scenario 3: Packet transmission across different DODAGs 69 (N1 to N2). . . . . . . . . . . . . . . . . . . . . . . . 10 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 71 8. Synchronization Aspects . . . . . . . . . . . . . . . . . . . 12 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 73 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 76 11.2. Informative References . . . . . . . . . . . . . . . . . 15 77 Appendix A. Changes from revision 03 to revision 04 . . . . . . 16 78 Appendix B. Changes from revision 03 to revision 04 . . . . . . 16 79 Appendix C. Changes from revision 01 to revision 02 . . . . . . 17 80 Appendix D. Changes between earlier versions . . . . . . . . . . 17 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 83 1. Introduction 85 Low Power and Lossy Networks (LLNs) are likely to be deployed for 86 real time industrial applications requiring end-to-end delay 87 guarantees [I-D.ietf-detnet-use-cases]. A Deterministic Network 88 ("detnet") typically requires some data packets to reach their 89 receivers within strict time bounds. Intermediate nodes use the 90 deadline information to make appropriate packet forwarding and 91 scheduling decisions to meet the time bounds. 93 This document specifies a new type for the Elective 6LoWPAN Routing 94 Header (6LoRHE), so that the deadline time (i.e., the time of latest 95 acceptable delivery) of data packets can be included within the 96 6LoWPAN routing header. [RFC8138] specifies the 6LoWPAN Routing 97 Header (6LoRH), compression schemes for RPL routing (source routing) 98 operation [RFC6554], header compression of RPL Packet Information 99 [RFC6553], and IP-in-IP encapsulation. This document also specifies 100 handling of the deadline time when packets traverse between time- 101 synchronized networks operating in different timezones or distinct 102 reference clocks. Time synchronization techniques are outside the 103 scope of this document. There are a number of standards available 104 for this purpose, including IEEE 1588 [ieee-1588], IEEE 802.1AS 105 [dot1AS-2011], IEEE 802.15.4-2015 TSCH [dot15-tsch], and more. 107 The Deadline-6LoRHE can be used in any time synchronized 6Lo network. 108 A 6TiSCH network is used to describe the implementation of the 109 Deadline-6LoRHE, but this does not preclude its use in scenarios 110 other than 6TiSCH. For instance, there is a growing interest in 111 using 6lo over a BLE mesh network [I-D.ietf-6lo-blemesh] in 112 industrial IoT [dotBLEMesh]. BLE mesh time synchronization is being 113 explored by the Bluetooth community. There are also cases under 114 consideration in Wi-SUN [Wi-SUN_PHY], [dotWi-SUN]. 116 2. Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 120 "OPTIONAL" in this document are to be interpreted as described in 121 [RFC2119] [RFC8174]. 123 This document uses the terminology defined in [RFC6550] and 124 [I-D.ietf-6tisch-terminology]. 126 3. 6LoRHE Generic Format 128 Note: this section is not normative and is included for convenience. 129 The generic header format of the 6LoRHE is specified in 130 [I-D.ietf-roll-routing-dispatch]. Figure 1 illustrates the 6LoRHE 131 generic format. 133 0 1 134 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 136 |1|0|1| Length | Type | | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 138 <-- length --> 140 Figure 1: 6LoRHE format 142 o Length: Length of the 6LoRHE expressed in bytes, excluding the 143 first 2 bytes. This enables a node to skip a 6LoRHE if the Type 144 is not recognized/supported. 146 o Type (variable length): Type of the 6LoRHE (see Section 7) 148 4. Deadline-6LoRHE 150 The Deadline-6LoRHE (see Figure 3) is an elective 6LoRH (i.e., a 151 6LoRHE [RFC8138]) that provides the Deadline Time (DT) for an IPv6 152 datagram in a compressed form. Along with the deadline, the header 153 can include the packet Origination Time Delta (OTD), the time at 154 which the packet is enqueued for transmission (expressed as a value 155 to be subtracted from DT); this enables a close estimate of the total 156 delay incurred by a packet. The OTD field is initialized by the 157 sender based on the current time at the outgoing network interface 158 through which the packet is forwarded. Since the OTD is a delta the 159 length of the OTD field (i.e., OTL) will require fewer bits than the 160 length of the DT field (i.e., DTL). 162 The deadline field contains the value of the deadline time for the 163 packet. The packet SHOULD be delivered to the Receiver before this 164 time. 166 packet_deadline_time = packet_origination_time + max_delay 168 All nodes within the network SHOULD process the Deadline-6LoRHE in 169 order to support delay-sensitive deterministic applications. The 170 packet deadline time (DT) and origination time (OTD) are represented 171 in time units determined by a scaling parameter in the routing 172 header. One of the time units is the Network ASN (Absolute Slot 173 Number) which can be used in case of a time slotted synchronized 174 network (for instance a 6TiSCH network, where global time is 175 maintained in the units of slot lengths of a certain resolution). 177 The delay experienced by packets in the network is a useful metric 178 for network diagnostics and performance monitoring. Whenever a 179 packet crosses into a network using a different reference clock, the 180 Destination Time field is updated to represent the same Destination 181 Time, but expressed using the reference clock of the interface into 182 the new network. Then the origination time is the same as the 183 current time when the packet is transmitted into the new network, 184 minus the delay already experienced by the packet, say 'dly'. In 185 this way, within the newly entered network, the packet will appear to 186 have originated 'dly' time units earlier with respect to the 187 reference clock of the new network. 189 origination time in new network = current_time_in_new_network - 190 delay_already_experienced_in_previous_network(s) 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 the difference between 197 TZ3 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 DTL (4 bits): Length of DT field as an unsigned 4-bit integer, 263 encoding the length of the field in hex digits, minus one. 264 o OTL (3 bits) : Length of OTD field as an unsigned 3-bit integer, 265 encoding the length of the field in hex digits. If OTL == 0, the 266 OTD field is not present. The value of OTL MUST NOT exceed the 267 value of DTL plus one. 269 * For example, DTL = 0b0000 means the deadline time in the 6LoRHE 270 is 1 hex digit (4 bits) long. OTL = 0b111 means the 271 origination time is 7 hex digits (28 bits) long. 272 o TU (2 bits) : Indicates the time units for DT and OTD fields. The 273 encoding for the DT and OTD fields MUST always use the same time 274 units and precision. 276 * 00 : Time represented in seconds and fractional seconds 277 * 01 : Reserved 278 * 10 : Network ASN 279 * 11 : Reserved 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 Example: Consider a 6TiSCH network with time-slot length of 10ms. 306 Let the time units be ASNs (TU == (binary)0b10). Let the current 307 ASN when the packet is originated be 54400, and the maximum 308 allowable delay (max_delay) for the packet delivery be 1 second 309 from the packet origination, then: 311 deadline_time = packet_origination_time + max_delay 313 = 0xD480 + 0x64 (Network ASNs) 315 = 0xD4E4 (Network ASNs) 317 Then, the Deadline-6LoRHE encoding with nonzero OTL is: 319 DTL = 3, OTL = 2, TU = 0b10, BinaryPt = 8, DT = 0xD4E4, OTD 320 = 0x64 322 6. Deadline-6LoRHE in Three Network Scenarios 324 In this section, Deadline-6LoRHE operation is described for 3 network 325 scenarios. Figure 4 depicts a constrained time-synchronized LLN that 326 has two subnets N1 and N2, connected through LBRs 327 [I-D.ietf-6lo-backbone-router] with different reference clock times 328 T1 and T2. 330 +-------------------+ 331 | Time Synchronized | 332 | Network | 333 +---------+---------+ 334 | 335 | 336 | 337 +--------------+--------------+ 338 | | 339 +-----+ +-----+ 340 | | Backbone | | Backbone 341 o | | router | | router 342 +-----+ +-----+ 343 o o o 344 o o o o o o o o o 345 o LLN o o LLN o o 346 o o o o o o o o o 347 6LoWPAN Network (subnet N1) 6LoWPAN Network (subnet N2) 349 Figure 4: Intra-network Timezone Scenario 351 6.1. Scenario 1: Endpoints in the same DODAG (N1) 353 In scenario 1, shown in Figure 5, the Sender 'S' has an IP datagram 354 to be routed to a Receiver 'R' within the same DODAG. For the route 355 segment from Sender to 6LBR, the Sender includes a Deadline-6LoRHE by 356 encoding the deadline time contained in the packet. Subsequently, 357 each 6LR will perform hop-by-hop routing to forward the packet 358 towards the 6LBR. Once 6LBR receives the IP datagram, it sends the 359 packet downstream towards 'R'. 361 In case of a network running RPL non-storing mode, the 6LBR generates 362 a IPv6-in-IPv6 encapsulated packet when sending the packet downwards 363 to the Receiver [I-D.ietf-roll-useofrplinfo]. The 6LBR copies the 364 Deadline-6LoRHE from the Sender originated IP header to the outer IP 365 header. The Deadline-6LoRHE contained in the inner IP header is 366 removed. 368 +-------+ 369 ^ | 6LBR | | 370 | | | | 371 | +-------+ | 372 Upward | / /| \ | Downward 373 routing | (F) / | \ | routing 374 | / \ (C) | (D) | 375 | / \ | | / |\ | 376 | (A) (B) : (E) : R | 377 | /|\ | \ / \ | 378 | S : : : : : : v 380 Figure 5: End points within same DODAG (subnet N1) 382 At the tunnel endpoint of the encapsulation, the Deadline-6LoRHE is 383 copied back from the outer header to inner header, and the inner IP 384 packet is delivered to 'R'. 386 6.2. Scenario 2: Endpoints in Networks with Dissimilar L2 Technologies. 388 In scenario 2, shown in Figure 6, the Sender 'S' (belonging to DODAG 389 1) has IP datagram to be routed to a Receiver 'R' over a time- 390 synchronized IPv6 network. For the route segment from 'S' to 6LBR, 391 'S' includes a Deadline-6LoRHE. Subsequently, each 6LR will perform 392 hop-by-hop routing to forward the packet towards the 6LBR. Once the 393 Deadline Time information reaches the border router, the packet will 394 be encoded according to the mechanism prescribed in the other time- 395 synchronized network depicted as "Time Synchronized Network" in the 396 figure 6. The specific data encapsulation mechanisms followed in the 397 new network are beyond the scope of this document. 399 +----------------+ 400 | Time | 401 | Synchronized |------R 402 | Network | 403 +----------------+ 404 | 405 | 406 ----------+----------- 407 ^ | 408 | +---+---+ 409 | | 6LBR | 410 Upward | | | 411 routing | +------++ 412 | (F)/ /| \ 413 | / \ / | \ 414 | / \ (C) | (D) 415 | (A) (B) | | / |\ 416 | /|\ |\ : (E) : : 417 | S : : : : / \ 418 : : 420 Figure 6: Packet transmission in Dissimilar L2 Technologies or 421 Internet 423 For instance, the IP datagram could be routed to another time 424 synchronized deterministic network using the mechanism specified in 425 the In-band OAM [I-D.ietf-ippm-ioam-data], and then the deadline time 426 would be updated according to the measurement of the current time in 427 the new network. 429 6.3. Scenario 3: Packet transmission across different DODAGs (N1 to 430 N2). 432 Consider the scenario depicted in Figure 7, in which the Sender 'S' 433 (belonging to DODAG 1) has an IP datagram to be sent to Receiver 'R' 434 belonging to another DODAG (DODAG 2). The operation of this scenario 435 can be decomposed into combination of case 1 and case 2 scenarios. 436 For the route segment from 'S' to 6LBR1, 'S' includes the Deadline- 437 6LoRHE. Subsequently, each 6LR will perform hop-by-hop operation to 438 forward the packet towards the 6LBR1. Once the IP datagram reaches 439 6LBR1 of DODAG1, it applies the same rule as described in Case 2 440 while routing the packet to 6LBR2 over a (likely) time synchronized 441 wired backhaul. The wired side of 6LBR2 can be mapped to receiver of 442 Case 2. Once the packet reaches 6LBR2, it updates the Deadline- 443 6LoRHE by adding or subtracting the difference of time of DODAG2 and 444 sends the packet downstream towards 'R'. 446 Time Synchronized Network 447 -+---------------------------+- 448 | | 449 DODAG1 +---+---+ +---+---+ DODAG2 450 | 6LBR1 | | 6LBR2 | 451 | | | | 452 +-------+ +-------+ 453 (F)/ /| \ (F)/ /| \ 454 / \ / | \ / \ / | \ 455 / \ (C) | (D) / \ (C) | (D) 456 (A) (B) | | / |\ (A) (B) | | |\ 457 /|\ |\ : (E) : : /|\ |\ : (E) : : 458 S : : : : / \ : : : : : / \ 459 : : : R 460 Network N1, time zone T1 Network N2, time zone T2 462 Figure 7: Packet transmission in different DODAGs(N1 to N2) 464 Consider an example of a 6TiSCH network in which S in DODAG1 465 generates the packet at ASN 20000 to R in DODAG2. Let the maximum 466 allowable delay be 1 second. The time-slot length in DODAG1 and 467 DODAG2 is assumed to be 10ms. Once the deadline time is encoded in 468 Deadline-6LoRHE, the packet is forwarded to 6LBR of DODAG1. Suppose 469 the packet reaches 6LBR of DODAG1 at ASN 20030. 471 current_time = ASN at LBR * slot_length_value 473 remaining_time = deadline_time - current_time 474 = ((packet_origination_time + max_delay) - current time) 475 = (20000 + 100) - 20030 476 = 30 (in Network ASNs) 477 = 30 * 10^3 milliseconds. 479 Once the Deadline Time information reaches the border router, the 480 packet will be encoded according to the mechanism prescribed in the 481 other time-synchronized network. 483 7. IANA Considerations 485 This document defines a new Elective 6LoWPAN Routing Header Type, and 486 IANA is requested to assign a value (TBD) from the 6LoWPAN Dispatch 487 Page1 number space for this purpose. 489 Elective 6LoRH Type Value 490 +----------------------+--------+ 491 | Deadline-6LoRHE | TBD | 492 +----------------------+--------+ 494 Figure 8: Deadline-6LoRHE type 496 8. Synchronization Aspects 498 The document supports time representation of the deadline and 499 origination times carried in the packets traversing through networks 500 of different time zones having different time synchronization 501 mechanisms. For instance, in a 6TiSCH network where the time is 502 maintained as ASN time slots, the time synchronization is achieved 503 through beaconing among the nodes as described in [RFC7554]. There 504 could be 6lo networks that employ NTP where the nodes are 505 synchronized with an external reference clock from an NTP server. 506 The specification of the time synchronization method that need to be 507 followed by a network is beyond the scope of the document. 509 The number of hex digits chosen to represent DT, and the portion of 510 that field allocated to represent integer number of seconds, 511 determines the meaning of t_0, i.e., the meaning of DT == 0 in the 512 chosen representation. If DTL == 0, then there are only 4 bits that 513 can be used to count the time units, so that DT == 0 can never be 514 more than 16 time units in the past. This then requires that the 515 time synchronization between sender and receiver has to be tighter 516 than 16 time units. If the binary point were moved so that all the 517 bits were used for fractional time units (e.g., fractional seconds or 518 fractional ASNs), the time synchronization requirement would be 519 correspondingly tighter. 521 A 4-bit field for DT allows up to 16 hex digits, which is 64 bits. 522 That is enough to represent the NTP [RFC5905] 64-bit timestamp 523 format, which is more than enough for the purposes of establishing 524 deadline times. Unless the binary point is moved, this is enough to 525 represent time since year 1900. 527 For example, suppose that DTL = 0b0000 and the DT bits are split 528 evenly; then we can count up to 3 integer seconds. In that case t_0 529 would be the most recent second of the current minute that has 530 t mod 4 == 0. In other words, t_0 could be 0, 4, 8, 12, 16, ..., 52, 531 or 56 seconds since the start of the most recent minute. The 532 networks have to be synchronized well enough to ensure detection of 533 overrun, and therefore to know which of those values is the correct 534 value for t_0. This is the hardest case. 536 If DT = 3 and the DT bits are again split evenly, then we can count 537 up to 4,096 seconds. t_0 would be the start of the most recent hour. 539 For TU = 0b00, the time units are seconds. With DTL == 15, and 540 Binary Pt == 0, the epoch is (by default) January 1, 1900 at 00:00 541 UTC. The resolution is then (2 ^ (- 32)) seconds, which is the 542 maximum possible. This time format wraps around every 2^32 seconds, 543 which is roughly 136 years. For other choices of DTL and the Binary 544 Pt, the value of t_0 (i.e., the meaning of DT == 0) needs to be 545 established by means out of scope of this document. 547 For TU = 0b10, the time units are ASNs. The start time is relative, 548 and updated by a mechanism out of scope for this document. With 10 549 ms slots, DTL = 15, and Binary Pt == 0, it would take over a year for 550 the ASN to wrap around. Typically, the number of hex digits 551 allocated for TU = 0b10 would be less than 15. 553 9. Security Considerations 555 The security considerations of [RFC4944], [RFC6282] and [RFC6553] 556 apply. Using a compressed format as opposed to the full in-line 557 format is logically equivalent and does not create an opening for a 558 new threat when compared to [RFC6550], [RFC6553] and [RFC6554]. 560 10. Acknowledgements 562 The authors thank Pascal Thubert for suggesting the idea and 563 encouraging the work. Thanks to Shwetha Bhandari's suggestions which 564 were instrumental in extending the timing information to 565 heterogeneous networks. The authors acknowledge the 6TiSCH WG 566 members for their inputs on the mailing list. Special thanks to 567 Jerry Daniel, Seema Kumar, Avinash Mohan, Shalu Rajendran and Anita 568 Varghese for their support and valuable feedback. 570 11. References 572 11.1. Normative References 574 [I-D.ietf-6tisch-terminology] 575 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 576 "Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e", 577 draft-ietf-6tisch-terminology-10 (work in progress), March 578 2018. 580 [I-D.ietf-roll-routing-dispatch] 581 Thubert, P., Bormann, C., Toutain, L., and R. Cragie, 582 "6LoWPAN Routing Header", draft-ietf-roll-routing- 583 dispatch-05 (work in progress), October 2016. 585 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 586 Requirement Levels", BCP 14, RFC 2119, 587 DOI 10.17487/RFC2119, March 1997, 588 . 590 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 591 "Transmission of IPv6 Packets over IEEE 802.15.4 592 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 593 . 595 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 596 "Network Time Protocol Version 4: Protocol and Algorithms 597 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 598 . 600 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 601 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 602 DOI 10.17487/RFC6282, September 2011, 603 . 605 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 606 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 607 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 608 Low-Power and Lossy Networks", RFC 6550, 609 DOI 10.17487/RFC6550, March 2012, 610 . 612 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 613 Power and Lossy Networks (RPL) Option for Carrying RPL 614 Information in Data-Plane Datagrams", RFC 6553, 615 DOI 10.17487/RFC6553, March 2012, 616 . 618 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 619 Routing Header for Source Routes with the Routing Protocol 620 for Low-Power and Lossy Networks (RPL)", RFC 6554, 621 DOI 10.17487/RFC6554, March 2012, 622 . 624 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 625 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 626 Internet of Things (IoT): Problem Statement", RFC 7554, 627 DOI 10.17487/RFC7554, May 2015, 628 . 630 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 631 "IPv6 over Low-Power Wireless Personal Area Network 632 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 633 April 2017, . 635 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 636 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 637 May 2017, . 639 11.2. Informative References 641 [dot15-tsch] 642 "IEEE 802 Wireless", "IEEE Standard for Low-Rate Wireless 643 Networks, Part 15.4, IEEE Std 802.15.4-2015", April 2016. 645 [dot1AS-2011] 646 "IEEE Standards", "IEEE Standard for Local and 647 Metropolitan Area Networks - Timing and Synchronization 648 for Time-Sensitive Applications in Bridged Local Area 649 Networks", March 2011. 651 [dotBLEMesh] 652 Leonardi, L., Pattim, G., and L. Lo Bello, "Multi-Hop 653 Real-Time Communications Over Bluetooth Low Energy 654 Industrial Wireless Mesh Networks", IEEE Access Vol 6, 655 26505-26519, May 2018. 657 [dotWi-SUN] 658 Harada, H., Mizutani, K., Fujiwara, J., Mochizuki, K., 659 Obata, K., and R. Okumura, "IEEE 802.15.4g Based Wi-SUN 660 Communication Systems", IEICE Transactions on 661 Communications volume E100.B, Jan 2017. 663 [I-D.ietf-6lo-backbone-router] 664 Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 665 Backbone Router", draft-ietf-6lo-backbone-router-11 (work 666 in progress), February 2019. 668 [I-D.ietf-6lo-blemesh] 669 Gomez, C., Darroudi, S., Savolainen, T., and M. Spoerk, 670 "IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP", 671 draft-ietf-6lo-blemesh-04 (work in progress), January 672 2019. 674 [I-D.ietf-detnet-use-cases] 675 Grossman, E., "Deterministic Networking Use Cases", draft- 676 ietf-detnet-use-cases-20 (work in progress), December 677 2018. 679 [I-D.ietf-ippm-ioam-data] 680 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 681 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 682 P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, 683 "Data Fields for In-situ OAM", draft-ietf-ippm-ioam- 684 data-04 (work in progress), October 2018. 686 [I-D.ietf-roll-useofrplinfo] 687 Robles, I., Richardson, M., and P. Thubert, "Using RPL 688 Option Type, Routing Header for Source Routes and IPv6-in- 689 IPv6 encapsulation in the RPL Data Plane", draft-ietf- 690 roll-useofrplinfo-24 (work in progress), January 2019. 692 [ieee-1588] 693 "IEEE Standards", "IEEE Std 1588-2008 Standard for a 694 Precision Clock Synchronization Protocol for Networked 695 Measurement and Control Systems", July 2008. 697 [Wi-SUN_PHY] 698 Wi-SUN Alliance, "Wi-SUN PHY Specification V1.0", March 699 2016. 701 Appendix A. Changes from revision 03 to revision 04 703 This section lists the changes between draft-ietf-6lo-deadline-time 704 revisions ...-03.txt and ...-04.txt. 706 o Replaced OT (Origination Time) field by OTD (Origination Time 707 Delta), allowing a more compressed representation that needs less 708 processing during transitions between networks. 710 o Changed representation for DTL, OTL, DT, OTD. Eliminated EXP in 711 favor of BinaryPt. 713 o Revised the figures and examples to use new parameters 715 o Added new section on Synchronization Aspects to supply pertinent 716 information about how nodes agree on the meaning of t=0. 718 o Responded to numerous reviewer comments to improve editorial 719 consistency and improve terminology. 721 Appendix B. Changes from revision 03 to revision 04 723 This section lists the changes between draft-ietf-6lo-deadline-time 724 revisions ...-02.txt and ...-03.txt. 726 o Added non-normative 6LoRHE description, citing RFC 8138. 728 o Specified that the Origination Time (OT) is the time that packet 729 is enqueued for transmission. 731 o Mentioned more sources of packet delay. 733 o Clarified reasons that packet MAY be forwarded if 'D' bit is 0. 735 o Clarified that DT, OT, DTL and OTL are unsigned integers. 737 o Updated bibliographic citations, including BLEmesh and Wi-SUN. 739 Appendix C. Changes from revision 01 to revision 02 741 This section lists the changes between draft-ietf-6lo-deadline-time 742 revisions ...-01.txt and ...-02.txt. 744 o Replaced 6LoRHE description by reference to RFC 8138. 746 o Added figure to illustrate change to Origination Time when a 747 packet crosses timezone boundaries. 749 o Clarified that use of 6tisch networks is descriptive, not 750 normative. 752 o Clarified that In-Band OAM is used as an example and is not 753 normative. 755 o Updated bibliographic citations. 757 o Alphabetized contributor names. 759 Appendix D. Changes between earlier versions 761 This section lists the changes between draft-ietf-6lo-deadline-time 762 revisions ...-00.txt and ...-01.txt. 764 o Changed "SHOULD drop" to "MUST drop" a packet if the deadline is 765 passed (see Section 5). 767 o Added explanatory text about how packet delays might arise. (see 768 Section 4). 770 o Mentioned availability of time-synchronization protocols (see 771 Section 1). 773 o Updated bibliographic citations. 775 o Alphabetized contributor names. 777 o Added this section. 779 Authors' Addresses 781 Lijo Thomas 782 C-DAC 783 Centre for Development of Advanced Computing (C-DAC), Vellayambalam 784 Trivandrum 695033 785 India 787 Email: lijo@cdac.in 789 Satish Anamalamudi 790 SRM University-AP 791 Amaravati Campus 792 Amaravati, Andhra Pradesh 522 502 793 India 795 Email: satishnaidu80@gmail.com 797 S.V.R Anand 798 Indian Institute of Science 799 Bangalore 560012 800 India 802 Email: anand@ece.iisc.ernet.in 804 Malati Hegde 805 Indian Institute of Science 806 Bangalore 560012 807 India 809 Email: malati@ece.iisc.ernet.in 811 Charles E. Perkins 812 Futurewei 813 2330 Central Expressway 814 Santa Clara 95050 815 Unites States 817 Email: charliep@computer.org