idnits 2.17.00 (12 Aug 2021) /tmp/idnits7157/draft-ietf-6lo-deadline-time-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 15, 2018) is 1314 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') == Outdated reference: draft-ietf-roll-routing-dispatch has been published as RFC 8138 == Outdated reference: draft-ietf-6lo-backbone-router has been published as RFC 8929 == Outdated reference: draft-ietf-6lo-blemesh has been published as RFC 9159 == Outdated reference: draft-ietf-detnet-use-cases has been published as RFC 8578 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-03 == Outdated reference: draft-ietf-roll-useofrplinfo has been published as RFC 9008 Summary: 1 error (**), 0 flaws (~~), 7 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: April 18, 2019 SRM University-AP 6 S.V.R.Anand 7 Malati Hegde 8 Indian Institute of Science 9 C. Perkins 10 Futurewei 11 October 15, 2018 13 Packet Delivery Deadline time in 6LoWPAN Routing Header 14 draft-ietf-6lo-deadline-time-03 16 Abstract 18 This document specifies a new type for the 6LoWPAN routing header 19 containing the delivery deadline time for data packets. The deadline 20 time enables forwarding and scheduling decisions for time critical 21 IoT M2M applications that need deterministic delay guarantees over 22 constrained networks and operate within time-synchronized networks. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 18, 2019. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. 6LoRHE Generic Format . . . . . . . . . . . . . . . . . . . . 3 61 4. Deadline-6LoRHE . . . . . . . . . . . . . . . . . . . . . . . 4 62 5. Deadline-6LoRHE Format . . . . . . . . . . . . . . . . . . . 6 63 6. Deadline-6LoRHE in Three Network Scenarios . . . . . . . . . 7 64 6.1. Scenario 1: Endpoints in the same DODAG (N1) . . . . . . 8 65 6.2. Scenario 2: Endpoints in Networks with Dissimilar L2 66 Technologies. . . . . . . . . . . . . . . . . . . . . . . 9 67 6.3. Scenario 3: Packet transmission across different DODAGs 68 (N1 to N2). . . . . . . . . . . . . . . . . . . . . . . . 10 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 71 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 74 10.2. Informative References . . . . . . . . . . . . . . . . . 13 75 Appendix A. Changes from revision 02 to revision 03 . . . . . . 15 76 Appendix B. Changes from revision 01 to revision 02 . . . . . . 15 77 Appendix C. Changes between earlier versions . . . . . . . . . . 15 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 80 1. Introduction 82 Low Power and Lossy Networks (LLNs) are likely to be deployed for 83 real time industrial applications requiring end-to-end delay 84 guarantees [I-D.ietf-detnet-use-cases]. A Deterministic Network 85 ("detnet") typically requires some data packets to reach their 86 receivers within strict time bounds. Intermediate nodes use the 87 deadline information to make appropriate packet forwarding and 88 scheduling decisions to meet the time bounds. 90 The draft [I-D.ietf-roll-routing-dispatch] specifies the 6LoWPAN 91 Routing Header (6LoRH), compression schemes for RPL routing (source 92 routing) operation [RFC6554], header compression of RPL Packet 93 Information [RFC6553], and IP-in-IP encapsulation. This document 94 specifies a new Deadline-6LoRHE type for the 6LoWPAN Dispatch Page 1, 95 so that the deadline time of data packets can be included within the 96 6LoWPAN routing header. This document also specifies handling of the 97 deadline time when packets traverse through time-synchronized 98 networks operating in different timezones or distinct reference 99 clocks. Time synchronization techniques need not be mandated by this 100 specificiation. There are a number of standards available for this 101 purpose, including IEEE 1588 [ieee-1588], IEEE 802.1AS [dot1AS-2011], 102 IEEE 802.15.4-2015 TSCH [dot15-tsch], and more. 104 The Deadline-6LoRHE can be used in any time synchronized 6Lo network. 105 A 6TiSCH network has been used to describe the implementation of the 106 Deadline-6LoRHE, but this does not preclude its use in scenarios 107 other than 6TiSCH. For instance, there is a growing interest in 108 using 6lo over a BLE mesh network [I-D.ietf-6lo-blemesh] in 109 industrial IoT [dotBLEMesh]. BLE mesh time synchronization is also 110 being recently explored by the Bluetooth community. There are also 111 cases under consideration in Wi-SUN [Wi-SUN_PHY], [dotWi-SUN]. 113 2. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 117 "OPTIONAL" in this document are to be interpreted as described in 118 [RFC2119] [RFC8174]. 120 This document uses terminology consistent with the terminology used 121 in [RFC6550] and [I-D.ietf-6tisch-terminology]. Also, in this 122 document, the terms "expiration time", "delivery deadline time", and 123 "deadline" are used interchangeably with the same meaning. 125 3. 6LoRHE Generic Format 127 Note: this section is not normative and is included for convenience. 128 The generic header format of the 6LoRHE is specified in 129 [I-D.ietf-roll-routing-dispatch]. Figure 1 illustrates the 6LoRHE 130 generic format. 132 0 1 133 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 135 |1|0|1| Length | Type | | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 137 <-- length --> 139 Figure 1: 6LoRHE format 141 o Length: Length of the 6LoRHE expressed in bytes, excluding the 142 first 2 bytes. This enables a node to skip a 6LoRHE if the Type 143 is not recognized/supported. 145 o Type: Type of the 6LoRHE. 147 o length: variable 149 4. Deadline-6LoRHE 151 The Deadline-6LoRHE (see Figure 3) is an elective 6LoRH (i.e., a 152 6LoRHE [RFC8138]) that provides the Deadline Time (DT) for an IPv6 153 datagram in a compressed form. Along with the deadline, the header 154 can include the packet Origination Time (OT), the time at which the 155 packet is enqueued for transmission, to enable a close estimate of 156 the total delay incurred by a packet. The OT field is initialized by 157 the sender using the current time at the outgoing network interface 158 through which the packet is forwarded. 160 The deadline field contains the value of the delivery deadline time 161 for the packet. The packet SHOULD be delivered to the Receiver 162 before this time. 164 packet_deadline_time = packet_origination_time + max_delay 166 All nodes within the network SHOULD process the Deadline-6LoRHE in 167 order to support delay-sensitive deterministic applications. The 168 packet deadline time (DT) and origination time (OT) are represented 169 in time units determined by a scaling parameter in the routing 170 header. One of the time units is the Network ASN (Absolute Slot 171 Number) which can be used in case of a time slotted synchronized 172 network (for instance a 6TiSCH network, where global time is 173 maintained in the units of slot lengths of a certain resolution). 175 The delay experienced by packets in the network is a useful metric 176 for network diagnostics and performance monitoring. Whenever the 177 packets crosses into a network using a different reference clock, the 178 Origination Time field is updated to represent the same Origination 179 Time, but expressed using the reference clock of the interface into 180 the new network. This is the same as the current time when the 181 packet is transmitted into the new network, minus the delay already 182 experienced by the packet, say 't'. In this way, within the newly 183 entered network, the packet will appear to have originated 't' time 184 units earlier with respect to the reference clock of the new network. 186 Origination Time in new network = current_time_in_new_network - 187 delay_already_experienced_in_previous_network(s) 189 The following example illustrates the origination time calculation 190 when a packet travels between three networks, each in a different 191 time zone. 'x' can be 1,2 or 3. 193 TxA : Time of arrival of packet in the network 'x' 195 TxD : Departure time of packet from the network 'x' 197 Dx : Delay experienced by the packet in the previous network(s) 199 TZx : Indicates the time zone of network 'x' 201 As an illustration, we consider a packet traversing through three 202 time synchronized networks along with numerical values as shown in 203 Figure 1. 205 TZ1 TZ2 TZ3 206 T1A=0| | | 207 |---- D1=100 | | 208 | \ | | 209 | \ | | 210 | \ T1D=100 |T2A=1000 | 211 | -------->|----- D2=400 | 212 | | \ | 213 | | \ | 214 | | \ T2D=1400 | T3A=5000 215 | | ------------------->| 216 | | | 217 v v v 219 D = 0 D = T1D-OT D = T2D-OT 220 = 100-0 = 1400 - 900 221 = 100 = 500 [= (D1 + D2)] 223 OT = T1A-D OT = T2A-D OT = T3A-D 224 = 0 = 1000-100 = 5000 - 500 225 = 900 = 4500 227 Figure 2: Origination Time update example 229 There are multiple ways that a packet can be delayed, including 230 queuing delay, MAC layer contention delay, serialization delay, and 231 propagation delays. Sometimes there are processing delays as well. 232 For the purpose of determining whether or not the deadline has 233 already passed, these various delays are not distinguished. 235 5. Deadline-6LoRHE Format 237 0 1 2 3 238 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 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 |1|0|1| Length | 6LoRH Type |O|D| DTL | OTL | TU| EXP | Rsv | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | DT (variable length) | OT(variable length)(optional) | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 Figure 3: Deadline-6LoRHE format 247 Length (5 bits): Length represents the total length of the Deadline- 248 6LoRHE type measured in octets. 250 6LoRH Type: TBD 252 O flag (1bit): Indicates the presence of Origination Time field. '1' 253 means the OT field is present, and '0' means it is absent. 255 D flag (1 bit): The 'D' flag, set by the Sender, indicates the action 256 to be taken when a 6LR detects that the deadline time has elapsed. 257 If 'D' bit is 1, then the 6LR MUST drop the packet if the deadline 258 time is elapsed. 260 If 'D' bit is 0, implies the packet MAY be forwarded on an exception 261 basis, if the forwarding node is NOT in a situation of constrained 262 resource, and if there are reasons to suspect that downstream nodes 263 might find it useful (delay measurements, interpolations, etc.). 265 DTL (3 bits): Length of DT field as an unsigned 3-bit integer, 266 encoding the length of the field in octets, minus one. 268 OTL (3 bits) : Length of OT field as an unsigned 3-bit integer, 269 encoding the length of the field in octets, minus one. 271 For example, DTL = 000 means the deadline time in the 6LoRHE is 1 272 octet (8 bits) long. Similarly, OTL = 111 means the origination 273 time is 8 octets (64 bits) long. 275 TU (2 bits) : Indicates the time units for DT and OT fields 277 00 : Time represented in microseconds 278 01 : Time represented in seconds 279 10 : Network ASN 280 11 : Reserved 282 EXP (3 bits) : Multiplication factor expressed as exponent of 10. 284 The value of the DT field is multiplied by 10 to this power, to 285 get the actual deadline time in the units represented by TU. The 286 default value of EXP is 000, so that the DT field is unaffected. 288 Rsv (3 bits) : Reserved, sent as zero and ignored on receipt 290 DT Value (8..64-bit) : An unsigned integer of DTL octets giving the 291 Deadline Time value 293 OT Value (8..64-bit) : An unsigned integer of OTL octets giving the 294 Origination Time value 296 Whenever a sender initiates the IP datagram, it includes the 297 Deadline-6LoRHE along with other 6LoRH information. 299 Example: Consider a 6TiSCH network with time-slot length of 10ms. 300 Let the current ASN when the packet is originated be 54400, and the 301 maximum allowable delay (max_delay) for the packet delivery is 1 302 second from the packet origination, then: 304 deadline_time = packet_origination_time + max_delay 305 = 55400 + 100 (in Network ASNs) 306 = 55500(Network ASNs) 308 Deadline-6LoRHE encoding with 'O' flag and 'D' flag set to 1: 310 DTL = 001, OTL = 001, TU = '10', EXP = 2, DT = 0x22B, OT = 0x22A 312 6. Deadline-6LoRHE in Three Network Scenarios 314 In this section, Deadline-6LoRHE operation is described for 3 network 315 scenarios. Figure 4 depicts a constrained time-synchronized LLN that 316 has two subnets N1 and N2, connected through LBRs 317 [I-D.ietf-6lo-backbone-router] with different reference clock times 318 T1 and T2. 320 +-------------------+ 321 | Time Synchronized | 322 | Network | 323 +---------+---------+ 324 | 325 | 326 | 327 +--------------+--------------+ 328 | | 329 +-----+ +-----+ 330 | | Backbone | | Backbone 331 o | | router | | router 332 +-----+ +-----+ 333 o o o 334 o o o o o o o o o 335 o LLN o o LLN o o 336 o o o o o o o o o 337 6LoWPAN Network (subnet N1) 6LoWPAN Network (subnet N2) 339 Figure 4: Intra-network Timezone Scenario 341 6.1. Scenario 1: Endpoints in the same DODAG (N1) 343 In scenario 1, shown in Figure 5, the Sender 'S' has an IP datagram 344 to be routed to a Receiver 'R' within the same DODAG. For the route 345 segment from Sender to 6LBR, the Sender includes a Deadline-6LoRHE by 346 encoding the deadline time contained in the packet. Subsequently, 347 each 6LR will perform hop-by-hop routing to forward the packet 348 towards the 6LBR. Once 6LBR receives the IP datagram, it sends the 349 packet downstream towards 'R'. 351 In case of a network running RPL non-storing mode, the 6LBR generates 352 a IPv6-in-IPv6 encapsulated packet when sending the packet downwards 353 to the Receiver [I-D.ietf-roll-useofrplinfo]. The 6LBR copies the 354 Deadline-6LoRHE from the Sender originated IP header to the outer IP 355 header. The Deadline-6LoRHE contained in the inner IP header is 356 removed. 358 +-------+ 359 ^ | 6LBR | | 360 | | | | 361 | +-------+ | 362 Upward | (F)/ /| \ | Downward 363 routing | / \ / | \ | routing 364 | / \ (C) | (D) | 365 | (A) (B) / | / |\ | 366 | /|\ |\: (E) : R | 367 S : : : / \ v 369 Figure 5: End points within same DODAG (subnet N1) 371 At the tunnel endpoint of the IPv6-in-IPv6 encapsulation, the 372 Deadline-6LoRHE is copied back from the outer header to inner header, 373 and the inner IP packet is delivered to 'R'. 375 6.2. Scenario 2: Endpoints in Networks with Dissimilar L2 Technologies. 377 In scenario 2, shown in Figure 6, the Sender 'S' (belonging to DODAG 378 1) has IP datagram to be routed to a Receiver 'R' over a time- 379 synchronized IPv6 network. For the route segment from 'S' to 6LBR, 380 'S' includes a Deadline-6LoRHE. Subsequently, each 6LR will perform 381 hop-by-hop routing to forward the packet towards the 6LBR. Once the 382 Deadline Time information reaches the border router, the packet will 383 be encoded according to the mechanism prescribed in the other time- 384 synchronized network depicted as "Time Synchronized Network" in the 385 figure 6. The specific data encapsulation mechanisms followed in the 386 new network are beyond the scope of this document. 388 +----------------+ 389 | Time | 390 | Synchronized |------R 391 | Network | 392 +----------------+ 393 | 394 | 395 ----------+----------- 396 ^ | 397 | +---+---+ 398 | | 6LBR | 399 Upward | | | 400 routing | +------++ 401 | (F)/ /| \ 402 | / \ / | \ 403 | / \ (C) | (D) 404 : (A) (B) / | / |\ 405 /|\ |\: (E) :: 406 S : : : / \ 407 : : 409 Figure 6: Packet transmission in Dissimilar L2 Technologies or 410 Internet 412 For instance, the IP datagram could be routed to another time 413 synchronized deterministic network using the mechanism specified in 414 the In-band OAM [I-D.ietf-ippm-ioam-data], and then the deadline time 415 would be updated according to the measurement of the current time in 416 the new network. 418 6.3. Scenario 3: Packet transmission across different DODAGs (N1 to 419 N2). 421 Consider the scenario depicted in Figure 7, in which the Sender 'S' 422 (belonging to DODAG 1) has an IP datagram to be sent to Receiver 'R' 423 belonging to another DODAG (DODAG 2). The operation of this scenario 424 can be decomposed into combination of case 1 and case 2 scenarios. 425 For the route segment from 'S' to 6LBR1, 'S' includes the Deadline- 426 6LoRHE. Subsequently, each 6LR will perform hop-by-hop operation to 427 forward the packet towards the 6LBR1. Once the IP datagram reaches 428 6LBR1 of DODAG1, it applies the same rule as described in Case 2 429 while routing the packet to 6LBR2 over a (likely) time synchronized 430 wired backhaul. The wired side of 6LBR2 can be mapped to receiver of 431 Case 2. Once the packet reaches 6LBR2, it updates the Deadline- 432 6LoRHE by adding or subtracting the difference of time of DODAG2 and 433 sends the packet downstream towards 'R'. 435 Time Synchronized Network 436 -+---------------------------+- 437 | | 438 DODAG1 +---+---+ +---+---+ DODAG2 439 | 6LBR1 | | 6LBR2 | 440 | | | | 441 +-------+ +-------+ 442 (F)/ /| \ (F)/ /| \ 443 / \ / | \ / \ / | \ 444 / \ (C) | (D) / \ (C) | (D) 445 (A) (B) / | / |\ (A) (B) / | / |\ 446 /|\ |\: (E) : : /|\ |\: (E) : : 447 S : : : / \ : : : : / \ 448 : : : R 449 Network N1, time zone T1 Network N2, time zone T2 451 Figure 7: Packet transmission in different DODAGs(N1 to N2) 453 Consider an example of a 6TiSCH network in which S in DODAG1 454 generates the packet at ASN 20000 to R in DODAG2. Let the maximum 455 allowable delay be 1 second. The time-slot length in DODAG1 and 456 DODAG2 is assumed to be 10ms. Once the deadline time is encoded in 457 Deadline-6LoRHE, the packet is forwarded to 6LBR of DODAG1. Suppose 458 the packet reaches 6LBR of DODAG1 at ASN 20030. 460 current_time = ASN at LBR * slot_length_value 462 remaining_time = deadline_time - current_time 463 = ((packet_origination_time + max_delay) - current time) 464 = (20000 + 100) - 20030 465 = 30 (in Network ASNs) 466 = 30 * 10^3 milliseconds. 468 Once the Deadline Time information reaches the border router, the 469 packet will be encoded accoding to the mechanism prescribed in the 470 other time-synchronized network. 472 7. IANA Considerations 474 This document defines a new Elective 6LoWPAN Routing Header Type, and 475 IANA is requested to assign a value (TBD) from the 6LoWPAN Dispatch 476 Page1 number space for this purpose. 478 Elective 6LoRH Type Value 479 +----------------------+--------+ 480 | Deadline-6LoRHE | TBD | 481 +----------------------+--------+ 483 Figure 8: Deadline-6LoRHE type 485 8. Security Considerations 487 The security considerations of [RFC4944], [RFC6282] and [RFC6553] 488 apply. Using a compressed format as opposed to the full in-line 489 format is logically equivalent and does not create an opening for a 490 new threat when compared to [RFC6550], [RFC6553] and [RFC6554]. 492 9. Acknowledgements 494 The authors thank Pascal Thubert for suggesting the idea and 495 encouraging the work. Thanks to Shwetha Bhandari's suggestions which 496 were instrumental in extending the timing information to 497 heterogeneous networks. The authors acknowledge the 6TiSCH WG 498 members for their inputs on the mailing list. Special thanks to 499 Jerry Daniel, Seema Kumar, Avinash Mohan, Shalu Rajendran and Anita 500 Varghese for their support and valuable feedback. 502 10. References 504 10.1. Normative References 506 [I-D.ietf-6tisch-terminology] 507 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 508 "Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e", 509 draft-ietf-6tisch-terminology-10 (work in progress), March 510 2018. 512 [I-D.ietf-roll-routing-dispatch] 513 Thubert, P., Bormann, C., Toutain, L., and R. Cragie, 514 "6LoWPAN Routing Header", draft-ietf-roll-routing- 515 dispatch-05 (work in progress), October 2016. 517 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 518 Requirement Levels", BCP 14, RFC 2119, 519 DOI 10.17487/RFC2119, March 1997, 520 . 522 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 523 "Transmission of IPv6 Packets over IEEE 802.15.4 524 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 525 . 527 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 528 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 529 DOI 10.17487/RFC6282, September 2011, 530 . 532 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 533 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 534 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 535 Low-Power and Lossy Networks", RFC 6550, 536 DOI 10.17487/RFC6550, March 2012, 537 . 539 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 540 Power and Lossy Networks (RPL) Option for Carrying RPL 541 Information in Data-Plane Datagrams", RFC 6553, 542 DOI 10.17487/RFC6553, March 2012, 543 . 545 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 546 Routing Header for Source Routes with the Routing Protocol 547 for Low-Power and Lossy Networks (RPL)", RFC 6554, 548 DOI 10.17487/RFC6554, March 2012, 549 . 551 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 552 "IPv6 over Low-Power Wireless Personal Area Network 553 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 554 April 2017, . 556 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 557 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 558 May 2017, . 560 10.2. Informative References 562 [dot15-tsch] 563 P802.11, "IEEE Standard for Low-Rate Wireless Networks, 564 Part 15.4, IEEE Std 802.15.4-2015", April 2016. 566 [dot1AS-2011] 567 IEEE 802.1AS Working Group, "IEEE Standard for Local and 568 Metropolitan Area Networks - Timing and Synchronization 569 for Time-Sensitive Applications in Bridged Local Area 570 Networks", March 2011. 572 [dotBLEMesh] 573 Luca Leonardi, Gaetano Pattim, and Lucia Lo Bello, "Multi- 574 Hop Real-Time Communications Over Bluetooth Low Energy 575 Industrial Wireless Mesh Networks", IEEE Access Vol 6, 576 26505-26519, May 2018. 578 [dotWi-SUN] 579 Hiroshi Harada, Keiichi Mizutani, Jun Fujiwara, Kentaro 580 Mochizuki, Kentaro Obata, and Okumura, Ryota, "IEEE 581 802.15.4g Based Wi-SUN Communication Systems", IEICE 582 Transactions on Communications volume E100.B, Jan 2017. 584 [I-D.ietf-6lo-backbone-router] 585 Thubert, P. and C. Perkins, "IPv6 Backbone Router", draft- 586 ietf-6lo-backbone-router-07 (work in progress), September 587 2018. 589 [I-D.ietf-6lo-blemesh] 590 Gomez, C., Darroudi, S., Savolainen, T., and M. Spoerk, 591 "IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP", 592 draft-ietf-6lo-blemesh-03 (work in progress), July 2018. 594 [I-D.ietf-detnet-use-cases] 595 Grossman, E., "Deterministic Networking Use Cases", draft- 596 ietf-detnet-use-cases-19 (work in progress), October 2018. 598 [I-D.ietf-ippm-ioam-data] 599 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 600 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 601 P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, 602 "Data Fields for In-situ OAM", draft-ietf-ippm-ioam- 603 data-03 (work in progress), June 2018. 605 [I-D.ietf-roll-useofrplinfo] 606 Robles, I., Richardson, M., and P. Thubert, "When to use 607 RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll- 608 useofrplinfo-23 (work in progress), May 2018. 610 [ieee-1588] 611 Precise Time and Time Interval Working Group, "IEEE Std 612 1588-2008 Standard for a Precision Clock Synchronization 613 Protocol for Networked Measurement and Control Systems", 614 July 2008. 616 [Wi-SUN_PHY] 617 Wi-SUN Alliance, "Wi-SUN PHY Specification V1.0", March 618 2016. 620 Appendix A. Changes from revision 02 to revision 03 622 This section lists the changes between draft-ietf-6lo-deadline-time 623 revisions ...-02.txt and ...-03.txt. 625 o Added non-normative 6LoRHE description, citing RFC 8138. 627 o Specified that the Origination Time (OT) is the time that packet 628 is enqueued for transmission. 630 o Mentioned more sources of packet delay. 632 o Clarified reasons that packet MAY be forwarded if 'D' bit is 0. 634 o Clarified that DT, OT, DTL and OTL are unsigned integers. 636 o Updated bibliographic citations, including BLEmesh and Wi-SUN. 638 Appendix B. Changes from revision 01 to revision 02 640 This section lists the changes between draft-ietf-6lo-deadline-time 641 revisions ...-01.txt and ...-02.txt. 643 o Replaced 6LoRHE description by reference to RFC 8138. 645 o Added figure to illustrate change to Origination Time when a 646 packet crosses timezone boundaries. 648 o Clarified that use of 6tisch networks is descriptive, not 649 normative. 651 o Clarified that In-Band OAM is used as an example and is not 652 normative. 654 o Updated bibliographic citations. 656 o Alphabetized contributor names. 658 Appendix C. Changes between earlier versions 660 This section lists the changes between draft-ietf-6lo-deadline-time 661 revisions ...-00.txt and ...-01.txt. 663 o Changed "SHOULD drop" to "MUST drop" a packet if the deadline is 664 passed (see Section 5). 666 o Added explanatory text about how packet delays might arise. (see 667 Section 4). 669 o Mentioned availability of time-synchronization protocols (see 670 Section 1). 672 o Updated bibliographic citations. 674 o Alphabetized contributor names. 676 o Added this section. 678 Authors' Addresses 680 Lijo Thomas 681 C-DAC 682 Centre for Development of Advanced Computing (C-DAC), Vellayambalam 683 Trivandrum 695033 684 India 686 Email: lijo@cdac.in 688 Satish Anamalamudi 689 SRM University-AP 690 Amaravati Campus 691 Amaravati, Andhra Pradesh 522 502 692 India 694 Email: satishnaidu80@gmail.com 696 S.V.R Anand 697 Indian Institute of Science 698 Bangalore 560012 699 India 701 Email: anand@ece.iisc.ernet.in 703 Malati Hegde 704 Indian Institute of Science 705 Bangalore 560012 706 India 708 Email: malati@ece.iisc.ernet.in 709 Charles E. Perkins 710 Futurewei 711 2330 Central Expressway 712 Santa Clara 95050 713 Unites States 715 Email: charliep@computer.org