idnits 2.17.1 draft-ietf-6lo-deadline-time-02.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 31, 2018) is 2064 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: A later version (-20) exists of draft-ietf-6lo-backbone-router-06 == Outdated reference: A later version (-10) exists of draft-ietf-6lo-blemesh-03 == Outdated reference: A later version (-20) exists of draft-ietf-detnet-use-cases-17 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-03 == Outdated reference: A later version (-44) exists of draft-ietf-roll-useofrplinfo-23 Summary: 2 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: March 4, 2019 SRM University-AP 6 S.V.R.Anand 7 Malati Hegde 8 Indian Institute of Science 9 C. Perkins 10 Futurewei 11 August 31, 2018 13 Packet Delivery Deadline time in 6LoWPAN Routing Header 14 draft-ietf-6lo-deadline-time-02 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 March 4, 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. Deadline-6LoRHE . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. Deadline-6LoRHE Format . . . . . . . . . . . . . . . . . . . 5 62 5. Deadline-6LoRHE in Three Network Scenarios . . . . . . . . . 7 63 5.1. Scenario 1: Endpoints in the same DODAG (N1) . . . . . . 7 64 5.2. Scenario 2: Endpoints in Networks with Dissimilar L2 65 Technologies. . . . . . . . . . . . . . . . . . . . . . . 8 66 5.3. Scenario 3: Packet transmission across different DODAGs 67 (N1 to N2). . . . . . . . . . . . . . . . . . . . . . . . 9 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 70 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 73 9.2. Informative References . . . . . . . . . . . . . . . . . 12 74 Appendix A. Changes after draft-ietf-6lo-deadline-time-01 . . . 13 75 Appendix B. Changes between earlier versions . . . . . . . . . . 13 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 78 1. Introduction 80 Low Power and Lossy Networks (LLNs) are likely to be deployed for 81 real time industrial applications requiring end-to-end delay 82 guarantees [I-D.ietf-detnet-use-cases]. A Deterministic Network 83 ("detnet") typically requires some data packets to reach their 84 receivers within strict time bounds. Intermediate nodes use the 85 deadline information to make appropriate packet forwarding and 86 scheduling decisions to meet the time bounds. 88 The draft [I-D.ietf-roll-routing-dispatch] specifies the 6LoWPAN 89 Routing Header (6LoRH), compression schemes for RPL routing (source 90 routing) operation [RFC6554], header compression of RPL Packet 91 Information [RFC6553], and IP-in-IP encapsulation. This document 92 specifies a new Deadline-6LoRHE type for the 6LoWPAN Dispatch Page 1, 93 so that the deadline time of data packets can be included within the 94 6LoWPAN routing header. This document also specifies handling of the 95 deadline time when packets traverse through time-synchronized 96 networks operating in different timezones or distinct reference 97 clocks. Time synchronization techniques need not be mandated by this 98 specificiation. There are a number of standards available for this 99 purpose, including IEEE 1588 [ieee-1588], IEEE 802.1AS [dot1AS-2011], 100 IEEE 802.15.4-2015 TSCH [dot15-tsch], and more. 102 The Deadline-6LoRHE can be used in any time synchronized 6Lo network. 103 A 6TiSCH network has been used to describe the implementation of the 104 Deadline-6LoRHE, but this does not preclude its use in scenarios 105 other than 6TiSCH. For instance, there is a growing interest in 106 using 6lo over a BLE mesh network [I-D.ietf-6lo-blemesh] in 107 industrial IoT. BLE mesh time synchronization is also being recently 108 explored by the Bluetooth community. There are also cases under 109 consideration in Wi-SUN. 111 2. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 115 "OPTIONAL" in this document are to be interpreted as described in 116 [RFC2119]. 118 This document uses terminology consistent with the terminology used 119 in [RFC6550] and [I-D.ietf-6tisch-terminology]. Also, in this 120 document, the terms "expiration time", "delivery deadline time", and 121 "deadline" are used interchangeably with the same meaning. 123 3. Deadline-6LoRHE 125 The Deadline-6LoRHE (see Figure 2) is an elective 6LoRH (i.e., a 126 6LoRHE [RFC8138]) that provides the Deadline Time (DT) for an IPv6 127 datagram in a compressed form. Along with the deadline, the header 128 can include the packet Origination Time (OT), to enable a close 129 estimate of the total delay incurred by a packet. The OT field is 130 initialized by the sender using the current time at the outgoing 131 network interface through which the packet is forwarded. 133 The deadline field contains the value of the delivery deadline time 134 for the packet. The packet SHOULD be delivered to the Receiver 135 before this time. 137 packet_deadline_time = packet_origination_time + max_delay 139 All nodes within the network SHOULD process the Deadline-6LoRHE in 140 order to support delay-sensitive deterministic applications. The 141 packet deadline time (DT) and origination time (OT) are represented 142 in time units determined by a scaling parameter in the routing 143 header. One of the time units is the Network ASN (Absolute Slot 144 Number) which can be used in case of a time slotted synchronized 145 network (for instance a 6TiSCH network, where global time is 146 maintained in the units of slot lengths of a certain resolution). 148 The delay experienced by packets in the network is a useful metric 149 for network diagnostics and performance monitoring. Whenever the 150 packets crosses into a network using a different reference clock, the 151 Origination Time field is updated to represent the same Origination 152 Time, but expressed using the reference clock of the interface into 153 the new network. This is the same as the current time when the 154 packet is transmitted into the new network, minus the delay already 155 experienced by the packet, say 't'. In this way, within the newly 156 entered network, the packet will appear to have originated 't' time 157 units earlier with respect to the reference clock of the new network. 159 Origination Time in new network = current_time_in_new_network - 160 delay_already_experienced_in_previous_network(s) 162 The following example illustrates the origination time calculation 163 when a packet travels between three networks, each in a different 164 time zone. 'x' can be 1,2 or 3. 166 TxA : Time of arrival of packet in the network 'x' 168 TxD : Departure time of packet in the network 'x' 170 Dx : Delay experienced by the packet in the previous network(s) 172 TZx : Indicates the time zone of network 'x' 174 As an illustration, we consider a packet traversing through three 175 time synchronized networks along with numerical values as shown in 176 Figure 1. 178 TZ1 TZ2 TZ3 179 T1A=0| | | 180 |---- D1=100 | | 181 | \ | | 182 | \ | | 183 | \ T1D=100 |T2A=1000 | 184 | -------->|----- D2=400 | 185 | | \ | 186 | | \ | 187 | | \ T2D=1400 | T3A=5000 188 | | ------------------->| 189 | | | 190 v v v 192 D = 0 D = T1D-OT D = T2D-OT 193 = 100-0 = 1400 - 900 194 = 100 = 500 i.e. (D1 + D2) 196 OT = T1A-D OT = T2A-D OT = T3A-D 197 = 0 = 1000-100 = 5000 - 500 198 = 900 = 4500 200 Figure 1: Origination Time update example 202 There are multiple ways that a packet can be delayed, including 203 propagation delay and queuing delays. Sometimes there are processing 204 delays as well. For the purpose of determining whether or not the 205 deadline has already passed, these various delays are not 206 distinguished. 208 4. Deadline-6LoRHE Format 210 0 1 2 3 211 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 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 |1|0|1| Length | 6LoRH Type |O|D| DTL | OTL | TU| EXP | Rsv | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | DT (variable length) | OT(variable length)(optional) | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 Figure 2: Deadline-6LoRHE format 220 Length (5 bits): Length represents the total length of the Deadline- 221 6LoRHE type measured in octets. 223 6LoRH Type: TBD 224 O flag (1bit): Indicates the presence of Origination Time field. '1' 225 means the OT field is present, and '0' means it is absent. 227 D flag (1 bit): The 'D' flag, set by the Sender, indicates the action 228 to be taken when a 6LR detects that the deadline time has elapsed. 229 If 'D' bit is 1, then the 6LR MUST drop the packet if the deadline 230 time is elapsed. If 'D' bit is 0, then the 6LR MAY ignore the 231 deadline time and forward the packet. 233 DTL (3 bits): Length of DT field. 235 OTL (3 bits) : Length of OT field. 237 For example, DTL = 000 means the deadline time in the 6LoRHE is 1 238 octet (8 bits) long. Similarly, OTL = 111 means the origination 239 time is 8 octets (64 bits) long. 241 TU (2 bits) : Indicates the time units for DT and OT fields 243 00 : Time represented in microseconds 244 01 : Time represented in seconds 245 10 : Network ASN 246 11 : Reserved 248 EXP (3 bits) : Multiplication factor expressed as exponent of 10. 250 The value of the DT field is multiplied by 10 to this power, to 251 get the actual deadline time in the units represented by TU. The 252 default value of EXP is 000, so that the DT field is unaffected. 254 Rsv (3 bits) : Reserved 256 DT Value (8..64-bit) : Deadline Time value 258 OT Value (8..64-bit) : Origination Time value 260 Whenever a sender initiates the IP datagram, it includes the 261 Deadline-6LoRHE along with other 6LoRH information. 263 Example: Consider a 6TiSCH network with time-slot length of 10ms. 264 Let the current ASN when the packet is originated be 54400, and the 265 maximum allowable delay (max_delay) for the packet delivery is 1 266 second from the packet origination, then: 268 deadline_time = packet_origination_time + max_delay 269 = 55400 + 100 (in Network ASNs) 270 = 55500(Network ASNs) 272 Deadline-6LoRHE encoding with 'O' flag and 'D' flag set to 1: 274 DTL = 001, OTL = 001, TU = '10', EXP = 2, DT = 0x22B, OT = 0x22A 276 5. Deadline-6LoRHE in Three Network Scenarios 278 In this section, Deadline-6LoRHE operation is described for 3 network 279 scenarios. Figure 3 depicts a constrained time-synchronized LLN that 280 has two subnets N1 and N2, connected through LBRs 281 [I-D.ietf-6lo-backbone-router] with different reference clock times 282 T1 and T2. 284 +-------------------+ 285 | Time Synchronized | 286 | Network | 287 +---------+---------+ 288 | 289 | 290 | 291 +--------------+--------------+ 292 | | 293 +-----+ +-----+ 294 | | Backbone | | Backbone 295 o | | router | | router 296 +-----+ +-----+ 297 o o o 298 o o o o o o o o o 299 o LLN o o LLN o o 300 o o o o o o o o o 301 6LoWPAN Network (subnet N1) 6LoWPAN Network (subnet N2) 303 Figure 3: Intra-network Timezone Scenario 305 5.1. Scenario 1: Endpoints in the same DODAG (N1) 307 In scenario 1, shown in Figure 4, the Sender 'S' has an IP datagram 308 to be routed to a Receiver 'R' within the same DODAG. For the route 309 segment from Sender to 6LBR, the Sender includes a Deadline-6LoRHE by 310 encoding the deadline time contained in the packet. Subsequently, 311 each 6LR will perform hop-by-hop routing to forward the packet 312 towards the 6LBR. Once 6LBR receives the IP datagram, it sends the 313 packet downstream towards 'R'. 315 In case of a network running RPL non-storing mode, the 6LBR generates 316 a IPv6-in-IPv6 encapsulated packet when sending the packet downwards 317 to the Receiver [I-D.ietf-roll-useofrplinfo]. The 6LBR copies the 318 Deadline-6LoRHE from the Sender originated IP header to the outer IP 319 header. The Deadline-6LoRHE contained in the inner IP header is 320 elided. 322 +-------+ 323 ^ | 6LBR | | 324 | | | | 325 | +-------+ | 326 Upward | (F)/ /| \ | Downward 327 routing | / \ / | \ | routing 328 | / \ (C) | (D) | 329 | (A) (B) / | / |\ | 330 | /|\ |\: (E) : R | 331 S : : : / \ v 333 Figure 4: End points within same DODAG (subnet N1) 335 At the tunnel endpoint of the IPv6-in-IPv6 encapsulation, the 336 Deadline-6LoRHE is copied back from the outer header to inner header, 337 and the inner IP packet is delivered to 'R'. 339 5.2. Scenario 2: Endpoints in Networks with Dissimilar L2 Technologies. 341 In scenario 2, shown in Figure 5, the Sender 'S' (belonging to DODAG 342 1) has IP datagram to be routed to a Receiver 'R' over a time- 343 synchronized IPv6 network. For the route segment from 'S' to 6LBR, 344 'S' includes a Deadline-6LoRHE. Subsequently, each 6LR will perform 345 hop-by-hop routing to forward the packet towards the 6LBR. Once the 346 Deadline Time information reaches the border router, the packet will 347 be encoded as per the mechanism prescribed in the new time 348 synchronized network. The specific data encapsulation mechanisms 349 followed in the new network are beyond the scope of this document. 351 +----------------+ 352 | Time | 353 | Synchronized |------R 354 | Network | 355 +----------------+ 356 | 357 | 358 ----------+----------- 359 ^ | 360 | +---+---+ 361 | | 6LBR | 362 Upward | | | 363 routing | +------++ 364 | (F)/ /| \ 365 | / \ / | \ 366 | / \ (C) | (D) 367 : (A) (B) / | / |\ 368 /|\ |\: (E) :: 369 S : : : / \ 370 : : 372 Figure 5: Packet transmission in Dissimilar L2 Technologies or 373 Internet 375 For instance, the IP datagram could be routed to another time 376 synchronized deterministic network using the mechanism specified in 377 the In-band OAM [I-D.ietf-ippm-ioam-data], and then the deadline time 378 would be updated according to the measurement of the current time in 379 the new network. 381 5.3. Scenario 3: Packet transmission across different DODAGs (N1 to 382 N2). 384 Consider the scenario depicted in Figure 6, in which the Sender 'S' 385 (belonging to DODAG 1) has an IP datagram to be sent to Receiver 'R' 386 belonging to another DODAG (DODAG 2). The operation of this scenario 387 can be decomposed into combination of case 1 and case 2 scenarios. 388 For the route segment from 'S' to 6LBR, 'S' includes the Deadline- 389 6LoRHE. Subsequently, each 6LR will perform hop-by-hop operation to 390 forward the packet towards the 6LBR. Once the IP datagram reaches 391 6LBR1 of DODAG1, it applies the same rule as described in Case 2 392 while routing the packet to 6LBR2 over a (likely) time synchronized 393 wired backhaul. The wired side of 6LBR2 can be mapped to receiver of 394 Case 2. Once the packet reaches 6LBR2, it updates the Deadline- 395 6LoRHE by adding or subtracting the difference of time of DODAG2 and 396 sends the packet downstream towards 'R'. 398 Time Synchronized Network 399 -+---------------------------+- 400 | | 401 DODAG1 +---+---+ +---+---+ DODAG2 402 | 6LBR1 | | 6LBR2 | 403 | | | | 404 +-------+ +-------+ 405 (F)/ /| \ (F)/ /| \ 406 / \ / | \ / \ / | \ 407 / \ (C) | (D) / \ (C) | (D) 408 (A) (B) / | / |\ (A) (B) / | / |\ 409 /|\ |\: (E) : : /|\ |\: (E) : : 410 S : : : / \ : : : : / \ 411 : : : R 412 Network N1, time zone T1 Network N2, time zone T2 414 Figure 6: Packet transmission in different DODAGs(N1 to N2) 416 Consider an example of a 6TiSCH network in which S in DODAG1 417 generates the packet at ASN 20000 to R in DODAG2. Let the maximum 418 allowable delay be 1 second. The time-slot length in DODAG1 and 419 DODAG2 is assumed to be 10ms. Once the deadline time is encoded in 420 Deadline-6LoRHE, the packet is forwarded to 6LBR of DODAG1. Suppose 421 the packet reaches 6LBR of DODAG1 at ASN 20030. 423 current_time = ASN at LBR * slot_length_value 425 remaining_time = deadline_time - current_time 426 = ((packet_origination_time + max_delay) - current time) 427 = (20000 + 100) - 20030 428 = 30 (in Network ASNs) 429 = 30 * 10^3 milliseconds. 431 Once the Deadline Time information reaches the border router, the 432 packet will be encoded as per the mechanism prescribed in the new 433 time synchronized network 435 6. IANA Considerations 437 This document defines a new 6LoWPAN Timestamp Header Type, and 438 assigns a value (TBD) from the 6LoWPAN Dispatch Page1 number space. 440 6LoRH Type Value 441 +------------------+--------+ 442 | Deadline-6LoRHE | TBD | 443 +------------------+--------+ 445 Figure 7: Deadline-6LoRHE type 447 7. Security Considerations 449 The security considerations of [RFC4944], [RFC6282] and [RFC6553] 450 apply. Using a compressed format as opposed to the full in-line 451 format is logically equivalent and does not create an opening for a 452 new threat when compared to [RFC6550], [RFC6553] and [RFC6554]. 454 8. Acknowledgements 456 The authors thank Pascal Thubert for suggesting the idea and 457 encouraging the work. Thanks to Shwetha Bhandari's suggestions which 458 were instrumental in extending the timing information to 459 heterogeneous networks. The authors acknowledge the 6TiSCH WG 460 members for their inputs on the mailing list. Special thanks to 461 Jerry Daniel, Seema Kumar, Avinash Mohan, Shalu Rajendran and Anita 462 Varghese for their support and valuable feedback. 464 9. References 466 9.1. Normative References 468 [I-D.ietf-6tisch-terminology] 469 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 470 "Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e", 471 draft-ietf-6tisch-terminology-10 (work in progress), March 472 2018. 474 [I-D.ietf-roll-routing-dispatch] 475 Thubert, P., Bormann, C., Toutain, L., and R. Cragie, 476 "6LoWPAN Routing Header", draft-ietf-roll-routing- 477 dispatch-05 (work in progress), October 2016. 479 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 480 Requirement Levels", BCP 14, RFC 2119, 481 DOI 10.17487/RFC2119, March 1997, 482 . 484 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 485 "Transmission of IPv6 Packets over IEEE 802.15.4 486 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 487 . 489 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 490 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 491 DOI 10.17487/RFC6282, September 2011, 492 . 494 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 495 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 496 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 497 Low-Power and Lossy Networks", RFC 6550, 498 DOI 10.17487/RFC6550, March 2012, 499 . 501 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 502 Power and Lossy Networks (RPL) Option for Carrying RPL 503 Information in Data-Plane Datagrams", RFC 6553, 504 DOI 10.17487/RFC6553, March 2012, 505 . 507 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 508 Routing Header for Source Routes with the Routing Protocol 509 for Low-Power and Lossy Networks (RPL)", RFC 6554, 510 DOI 10.17487/RFC6554, March 2012, 511 . 513 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 514 "IPv6 over Low-Power Wireless Personal Area Network 515 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 516 April 2017, . 518 9.2. Informative References 520 [dot15-tsch] 521 P802.11, "IEEE Standard for Low-Rate Wireless Networks, 522 Part 15.4, IEEE Std 802.15.4-2015", April 2016. 524 [dot1AS-2011] 525 IEEE 802.1AS Working Group, "IEEE Standard for Local and 526 Metropolitan Area Networks - Timing and Synchronization 527 for Time-Sensitive Applications in Bridged Local Area 528 Networks", March 2011. 530 [I-D.ietf-6lo-backbone-router] 531 Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo- 532 backbone-router-06 (work in progress), February 2018. 534 [I-D.ietf-6lo-blemesh] 535 Gomez, C., Darroudi, S., Savolainen, T., and M. Spoerk, 536 "IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP", 537 draft-ietf-6lo-blemesh-03 (work in progress), July 2018. 539 [I-D.ietf-detnet-use-cases] 540 Grossman, E., "Deterministic Networking Use Cases", draft- 541 ietf-detnet-use-cases-17 (work in progress), June 2018. 543 [I-D.ietf-ippm-ioam-data] 544 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 545 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 546 P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, 547 "Data Fields for In-situ OAM", draft-ietf-ippm-ioam- 548 data-03 (work in progress), June 2018. 550 [I-D.ietf-roll-useofrplinfo] 551 Robles, I., Richardson, M., and P. Thubert, "When to use 552 RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll- 553 useofrplinfo-23 (work in progress), May 2018. 555 [ieee-1588] 556 Precise Time and Time Interval Working Group, "IEEE Std 557 1588-2008 Standard for a Precision Clock Synchronization 558 Protocol for Networked Measurement and Control Systems", 559 July 2008. 561 Appendix A. Changes after draft-ietf-6lo-deadline-time-01 563 This section lists the changes between draft-ietf-6lo-deadline-time 564 revisions ...-01.txt and ...-02.txt. 566 o Replaced 6LoRHE description by reference to RFC 8138. 568 o Added figure to illustrate change to Origination Time when a 569 packet crosses timezone boundaries. 571 o Clarified that use of 6tisch networks is descriptive, not 572 normative. 574 o Clarified that In-Band OAM is used as an example and is not 575 normative. 577 o Updated bibliographic citations. 579 o Alphabetized contributor names. 581 Appendix B. Changes between earlier versions 583 This section lists the changes between draft-ietf-6lo-deadline-time 584 revisions ...-00.txt and ...-01.txt. 586 o Changed "SHOULD drop" to "MUST drop" a packet if the deadline is 587 passed (see Section 4). 589 o Added explanatory text about how packet delays might arise. (see 590 Section 3). 592 o Mentioned availability of time-synchronization protocols (see 593 Section 1). . 595 o Updated bibliographic citations. 597 o Alphabetized contributor names. 599 o Added this section. 601 Authors' Addresses 603 Lijo Thomas 604 C-DAC 605 Trivandrum 695033 606 India 608 Email: lijo@cdac.in 610 Satish Anamalamudi 611 SRM University-AP 612 Amaravati Campus 613 Amaravati, Andhra Pradesh 522 502 614 India 616 Email: satishnaidu80@gmail.com 618 S.V.R Anand 619 Indian Institute of Science 620 Bangalore 560012 621 India 623 Email: anand@ece.iisc.ernet.in 625 Malati Hegde 626 Indian Institute of Science 627 Bangalore 560012 628 India 630 Email: malati@ece.iisc.ernet.in 631 Charles E. Perkins 632 Futurewei 633 2330 Central Expressway 634 Santa Clara 95050 635 Unites States 637 Email: charliep@computer.org