idnits 2.17.00 (12 Aug 2021) /tmp/idnits14182/draft-ietf-6lo-deadline-time-01.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 4, 2018) is 1539 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-detnet-use-cases has been published as RFC 8578 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-01 == Outdated reference: draft-ietf-roll-useofrplinfo has been published as RFC 9008 Summary: 1 error (**), 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 P. Akshay 5 Expires: September 5, 2018 Smarten Spaces 6 Satish Anamalamudi 7 Huaiyin Institute of Technology 8 S.V.R.Anand 9 Malati Hegde 10 Indian Institute of Science 11 C. Perkins 12 Futurewei 13 March 4, 2018 15 Packet Delivery Deadline time in 6LoWPAN Routing Header 16 draft-ietf-6lo-deadline-time-01 18 Abstract 20 This document specifies a new type for the 6LoWPAN routing header 21 containing the delivery deadline time for data packets. The deadline 22 time enables forwarding and scheduling decisions for time critical 23 IoT M2M applications that need deterministic delay guarantees over 24 constrained networks and operate within time-synchronized networks. 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 September 5, 2018. 43 Copyright Notice 45 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . 5 65 6. Deadline-6LoRHE in Three Network Scenarios . . . . . . . . . 6 66 6.1. Scenario 1: Endpoints in the same DODAG (N1) in non- 67 storing mode. . . . . . . . . . . . . . . . . . . . . . . 7 68 6.2. Scenario 2: Endpoints in Networks with Dissimilar L2 69 Technologies. . . . . . . . . . . . . . . . . . . . . . . 8 70 6.3. Scenario 3: Packet transmission across different DODAGs 71 (N1 to N2). . . . . . . . . . . . . . . . . . . . . . . . 9 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 74 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 77 10.2. Informative References . . . . . . . . . . . . . . . . . 11 78 Appendix A. Changes Since draft-ietf-6lo-deadline-time-00 . . . 12 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 81 1. Introduction 83 Low Power and Lossy Networks (LLNs) are likely to be deployed for 84 real time industrial applications requiring end-to-end delay 85 guarantees [I-D.ietf-detnet-use-cases]. A Deterministic Network 86 ("detnet") typically requires some data packets to reach their 87 receivers within strict time bounds. Intermediate nodes use the 88 deadline information to make appropriate packet forwarding and 89 scheduling decisions to meet the time bounds. 91 The draft [I-D.ietf-roll-routing-dispatch] specifies the 6LoWPAN 92 Routing Header (6LoRH), compression schemes for RPL routing (source 93 routing) operation [RFC6554], header compression of RPL Packet 94 Information [RFC6553], and IP-in-IP encapsulation. This document 95 specifies a new Deadline-6LoRHE type for the 6LoWPAN Dispatch Page 1, 96 so that the deadline time of data packets can be included within the 97 6LoWPAN routing header. This document also specifies handling of the 98 deadline time when packets traverse through time-synchronized 99 networks operating in different timezones or distinct reference 100 clocks. Time synchronization techniques need not be mandated by this 101 specificiation. There are a number of standards available for this 102 purpose, including IEEE 1588 [ieee-1588], IEEE 802.1AS [dot1AS-2011], 103 IEEE 802.15.4-2015 TSCH [dot15-tsch], and more. 105 2. Terminology 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 109 "OPTIONAL" in this document are to be interpreted as described in 110 [RFC2119]. 112 This document uses terminology consistent with the terminology used 113 in [RFC6550] and [I-D.ietf-6tisch-terminology]. Also, in this 114 document, the terms "expiration time", "delivery deadline time", and 115 "deadline" are used interchangeably with the same meaning. 117 3. 6LoRHE Generic Format 119 Note: this section is not normative. It is included for convenience, 120 and may be deleted in a later revision of this document. The generic 121 header format of the 6LoRHE is specified in 122 [I-D.ietf-roll-routing-dispatch]. Figure 1 illustrates the 6LoRHE 123 generic format. 125 0 1 126 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 128 |1|0|1| Length | Type | | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ 130 <-- length --> 132 Figure 1: 6LoRHE format 134 o Length: Length of the 6LoRHE expressed in bytes, excluding the 135 first 2 bytes. This enables a node to skip a 6LoRHE if the Type 136 is not recognized/supported. 138 o Type: Type of the 6LoRHE. 140 o length: variable 142 4. Deadline-6LoRHE 144 The Deadline-6LoRHE (see Figure 2) is an elective 6LoRH (i.e., a 145 6loRHE) that provides the Deadline time (DT) for an IPv6 datagram in 146 a compressed form. Along with the deadline, the header can include 147 the packet Origination Time (OT), to enable a close estimate of the 148 total delay incurred by a packet. The OT field is initialized by the 149 sender using the current time at the outgoing network interface 150 through which the packet is forwarded. 152 The deadline field contains the value of the delivery deadline time 153 for the packet. The packet SHOULD be delivered to the Receiver 154 before this time. 156 packet_deadline_time = packet_origination_time + max_delay 158 All nodes within the network SHOULD process the Deadline-6LoRHE in 159 order to support delay-sensitive deterministic applications. The 160 packet deadline time (DT) and origination time (OT) are represented 161 in time units determined by a scaling parameter in the routing 162 header. One of the time units is the Network ASN (Absolute Slot 163 Number) which can be used in case of a time slotted synchronized 164 network, for instance a 6TiSCH network, where global time is 165 maintained in the units of slot lengths of a certain resolution. 167 The delay experienced by packets in the network is a useful metric 168 for network diagnostics and performance monitoring. Whenever the 169 packets crosses into a network using a different reference clock, the 170 Origination Time field is updated to represent the same Origination 171 Time as expressed using the reference clock of the outgoing interface 172 into the new network. This is the same as the current time when the 173 packet is transmitted into the new network, minus the delay already 174 experienced by the packet, say 't'. In effect, to the newly entered 175 network, the packet will appear to have originated 't' time units 176 earlier with respect to the reference clock of the new network. 178 Origination Time in new network = current_time_in_new_network - 179 delay_already_experienced_in_previous_network(s) 181 There are multiple ways that a packet can be delayed, including 182 propagation delay and queuing delays. Sometimes there are processing 183 delays as well. For the purpose of determining whether or not the 184 deadline has already passed, these various delays are not 185 distinguished. 187 5. Deadline-6LoRHE Format 189 0 1 2 3 190 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 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 |1|0|1| Length | 6LoRH Type |O|D| DTL | OTL | TU| EXP | Rsv | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | DT (variable length) | OT(variable length)(optional) | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 Figure 2: Deadline-6LoRHE format 199 Length (5 bits): Length represents the total length of the Deadline- 200 6LoRHE type measured in octets. 202 6LoRH Type: TBD 204 O flag (1bit): Indicates the presence of Origination Time field. '1' 205 means the OT field is present, and '0' means it is absent. 207 D flag (1 bit): The 'D' flag, set by the Sender, indicates the action 208 to be taken when a 6LR detects that the deadline time has elapsed. 209 If 'D' bit is 1, then the 6LR MUST drop the packet if the deadline 210 time is elapsed. If 'D' bit is 0, then the 6LR MAY ignore the 211 deadline time and forward the packet. 213 DTL (3 bits): Length of DT field. 215 OTL (3 bits) : Length of OT field. 217 For example, DTL = 000 means the deadline time in the 6LoRHE is 1 218 octet (8 bits) long. Similarly, OTL = 111 means the origination 219 time is 8 octets (64 bits) long. 221 TU (2 bits) : Indicates the time units for DT and OT fields 223 00 : Time represented in microseconds 224 01 : Time represented in seconds 225 10 : Network ASN 226 11 : Reserved 228 EXP (3 bits) : Multiplication factor expressed as exponent of 10. 230 The value of the DT field is multiplied by 10 to this power, to 231 get the actual deadline time in the units represented by TU. The 232 default value of EXP is 000, so that the DT field is unaffected. 234 Rsv (3 bits) : Reserved 235 DT Value (8..64-bit) : Deadline Time value 237 OT Value (8..64-bit) : Origination Time value 239 Whenever a sender initiates the IP datagram, it includes the 240 Deadline-6LoRHE along with other 6LoRH information. 242 Example: Consider a 6TiSCH network with time-slot length of 10ms. 243 Let the current ASN when the packet is originated be 54400, and the 244 maximum allowable delay (max_delay) for the packet delivery is 1 245 second from the packet origination, then: 247 deadline_time = packet_origination_time + max_delay 249 = 55400 + 100 (in Network ASNs) 250 = 55500(Network ASNs) 252 Deadline-6LoRHE encoding with 'O' flag set to 1 : 254 DTL = 001, OTL = 001, TU = '10', EXP = 2, DT = 0x22B, OT = 0x22A 256 6. Deadline-6LoRHE in Three Network Scenarios 258 In this section, Deadline-6LoRHE operation is described for 3 network 259 scenarios. Figure 3 depicts a constrained time-synchronized LLN that 260 has two subnets N1 and N2, connected through LBRs 261 [I-D.ietf-6lo-backbone-router] with different reference clock times 262 T1 and T2. 264 +-------------------+ 265 | Time Synchronized | 266 | Network | 267 +---------+---------+ 268 | 269 | 270 | 271 +--------------+--------------+ 272 | | 273 +-----+ +-----+ 274 | | Backbone | | Backbone 275 o | | router | | router 276 +-----+ +-----+ 277 o o o 278 o o o o o o o o o 279 o LLN o o LLN o o 280 o o o o o o o o o 281 6LoWPAN Network (subnet N1) 6LoWPAN Network (subnet N2) 283 Figure 3: Intra-network Timezone Scenario 285 6.1. Scenario 1: Endpoints in the same DODAG (N1) in non-storing mode. 287 In scenario 1, shown in Figure 4, the Sender 'S' has an IP datagram 288 to be routed to a Receiver 'R' within the same DODAG. For the route 289 segment from Sender to 6LBR, the Sender includes a Deadline-6LoRHE by 290 encoding the deadline time contained in the inband-OAM header 291 extension. Then 6LR begins hop-by-hop operation to forward the 292 packet towards the 6LBR. Once 6LBR receives the IP datagram, it 293 generates a IPv6-in-IPv6 encapsulated packet when sending the packet 294 downwards to the Receiver [I-D.ietf-roll-useofrplinfo]. The 6LBR 295 copies the Deadline-6LoRHE from the Sender originated IP header to 296 the outer IP header. The Deadline-6LoRHE contained in the inner IP 297 header is elided. 299 +-------+ 300 ^ | 6LBR | | 301 | | | | 302 | +-------+ | 303 Default | (F)/ /| \ | IP-in-IP 304 routing | / \ / | \ | Encapsulation 305 | / \ (C) | (D) | 306 | (A) (B) / | / |\ | 307 | /|\ |\: (E) : R | 308 S : : : / \ V 310 Figure 4: End points within same DODAG(subnet N1) 312 At the tunnel endpoint of IPv6-in-IPv6 encapsulation, the Deadline- 313 6LoRHE is copied back from the outer header to inner header, and the 314 inner IP packet is delivered to 'R'. 316 6.2. Scenario 2: Endpoints in Networks with Dissimilar L2 Technologies. 318 In scenario 2, shown in Figure 5, the Sender 'S' (belonging to DODAG 319 1) has IP datagram to be routed to a Receiver 'R' over a time- 320 synchronized IPv6 network. For the route segment from 'S' to 6LBR, 321 'S' includes a Deadline-6LoRHE. Subsequently, 6LR will perform hop- 322 by-hop operation to forward the packet towards the 6LBR. Once the IP 323 datagram reaches 6LBR of DODAG1, it encodes the deadline time (and, 324 if available, the origination time) into the In-band OAM header 325 extension, [I-D.ietf-ippm-ioam-data] and passes the datagram to the 326 IPv6 layer for further routing. 328 +----------------+ 329 | Time | 330 | synchronized |------R 331 | Network | 332 +----------------+ 333 | 334 | 335 ----------+----------- 336 ^ | 337 | +---+---+ 338 | | 6LBR | 339 Default | | | 340 routing | +------++ 341 | (F)/ /| \ 342 | / \ / | \ 343 | / \ (C) | (D) 344 : (A) (B) / | / |\ 345 /|\ |\: (E) : 346 S : : : / \ 347 : : 349 Figure 5: Packet transmission in Dissimilar L2 Technologies or 350 Internet 352 The IP datagram is routed to another time synchronized deterministic 353 network following its own distinct reference clock, so the deadline 354 time in In-band OAM has to be updated according to the measurement of 355 the current time in the new network. 357 6.3. Scenario 3: Packet transmission across different DODAGs (N1 to 358 N2). 360 Consider the scenario depicted in Figure 6, in which the Sender 'S' 361 (belonging to DODAG 1) has an IP datagram to be sent to Receiver 'R' 362 belonging to another DODAG (DODAG 2). The operation of this scenario 363 can be decomposed into combination of case 1 and case 2 scenarios. 364 For the route segment from 'S' to 6LBR, 'S' includes the Deadline- 365 6LoRHE. Subsequently, each 6LR will perform hop-by-hop operation to 366 forward the packet towards the 6LBR. Once the IP datagram reaches 367 6LBR1 of DODAG1, it applies the same rule as described in Case 2 368 while routing the packet to LBR2 over a (likely) time synchronized 369 wired backhaul. The wired side of LBR2 can be mapped to receiver of 370 Case 2. Once the packet reaches LBR2, it updates the Deadline-6LoRHE 371 by adding the current time of DODAG2. Further, it generates an IPv6- 372 in-IPv6 encapsulated packet when sending the packet downstream to the 373 Receiver [I-D.ietf-roll-useofrplinfo]. 375 Time Synchronized Network 376 -+---------------------------+- 377 | | 378 DODAG1 +---+---+ +---+---+ DODAG2 379 Instance 1 | 6LBR1 | | 6LBR2 | Instance 2 380 | | | | | 381 +-------+ +-------+ | 382 (F)/ /| \ (F)/ /| \ | 383 / \ / | \ / \ / | \ | 384 / \ (C) | (D) / \ (C) | (D) |IP-in-IP 385 (A) (B) / | / |\ (A) (B) / | / |\ | Encapsulation 386 /|\ |\: (E) : : /|\ |\: (E) : :| 387 S : : : / \ : : : : / \ | 388 : : : R V 389 Network N1, time zone T1 NetWork N2, time zone T2 391 Figure 6: Packet transmission in different DODAGs(N1 to N2) 393 Consider an example of a 6TiSCH network in which S in DODAG1 394 generates the packet at ASN 20000 to R in DODAG2. Let the maximum 395 allowable delay be 1 second. The time-slot length in DODAG1 and 396 DODAG2 is assumed to be 10ms. Once the deadline time is encoded in 397 Deadline-6LoRHE, the packet is forwarded to LBR of DODAG1. Suppose 398 the packet reaches LBR of DODAG1 at ASN 20050. 400 current_time = ASN at LBR * slot_length_value 402 remaining_time = deadline_time - current_time 403 = ((packet_origination_time + max_delay) - current time) 404 = (20000 + 100) - 20050 405 = 50 (in Network ASNs) 406 = 50 * 10^3 milliseconds. 408 The remaining time is encoded in In-Band OAM (see Case 2) and 409 forwarded to LBR2 over a different L2-interface, typically wired. 410 Once the packet reaches LBR2, the deadline time in Deadline-6LoRHE is 411 adjusted by adding or subtracting the difference between the 412 reference clocks of the two networks, before forwarding the packet to 413 its connected 6TiSCH network. 415 7. IANA Considerations 417 This document defines a new 6LoWPAN Timestamp Header Type, and 418 assigns a value (TBD) from the 6LoWPAN Dispatch Page1 number space. 420 6LoRH Type Value 421 +------------------+--------+ 422 | Deadline-6LoRHE | TBD | 423 +------------------+--------+ 425 Figure 7: Deadline-6LoRHE type 427 8. Security Considerations 429 The security considerations of [RFC4944], [RFC6282] and [RFC6553] 430 apply. Using a compressed format as opposed to the full in-line 431 format is logically equivalent and does not create an opening for a 432 new threat when compared to [RFC6550], [RFC6553] and [RFC6554]. 434 9. Acknowledgements 436 The authors thank Pascal Thubert for suggesting the idea and 437 encouraging the work. Thanks to Shwetha Bhandari's suggestions which 438 were instrumental in extending the timing information to 439 heterogeneous networks. The authors acknowledge the 6TiSCH WG 440 members for their inputs on the mailing list. Special thanks to 441 Jerry Daniel, Seema Kumar, Avinash Mohan, Shalu Rajendran and Anita 442 Varghese for their support and valuable feedback. 444 10. References 446 10.1. Normative References 448 [I-D.ietf-6tisch-terminology] 449 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 450 "Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e", 451 draft-ietf-6tisch-terminology-10 (work in progress), March 452 2018. 454 [I-D.ietf-roll-routing-dispatch] 455 Thubert, P., Bormann, C., Toutain, L., and R. Cragie, 456 "6LoWPAN Routing Header", draft-ietf-roll-routing- 457 dispatch-05 (work in progress), October 2016. 459 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 460 Requirement Levels", BCP 14, RFC 2119, 461 DOI 10.17487/RFC2119, March 1997, 462 . 464 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 465 "Transmission of IPv6 Packets over IEEE 802.15.4 466 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 467 . 469 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 470 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 471 DOI 10.17487/RFC6282, September 2011, 472 . 474 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 475 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 476 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 477 Low-Power and Lossy Networks", RFC 6550, 478 DOI 10.17487/RFC6550, March 2012, 479 . 481 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 482 Power and Lossy Networks (RPL) Option for Carrying RPL 483 Information in Data-Plane Datagrams", RFC 6553, 484 DOI 10.17487/RFC6553, March 2012, 485 . 487 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 488 Routing Header for Source Routes with the Routing Protocol 489 for Low-Power and Lossy Networks (RPL)", RFC 6554, 490 DOI 10.17487/RFC6554, March 2012, 491 . 493 10.2. Informative References 495 [dot15-tsch] 496 P802.11, "IEEE Standard for Low-Rate Wireless Networks, 497 Part 15.4, IEEE Std 802.15.4-2015", April 2016. 499 [dot1AS-2011] 500 IEEE 802.1AS Working Group, "IEEE Standard for Local and 501 Metropolitan Area Networks - Timing and Synchronization 502 for Time-Sensitive Applications in Bridged Local Area 503 Networks", March 2011. 505 [I-D.ietf-6lo-backbone-router] 506 Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo- 507 backbone-router-06 (work in progress), February 2018. 509 [I-D.ietf-detnet-use-cases] 510 Grossman, E., "Deterministic Networking Use Cases", draft- 511 ietf-detnet-use-cases-14 (work in progress), February 512 2018. 514 [I-D.ietf-ippm-ioam-data] 515 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 516 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 517 P., Chang, R., and d. daniel.bernier@bell.ca, "Data Fields 518 for In-situ OAM", draft-ietf-ippm-ioam-data-01 (work in 519 progress), October 2017. 521 [I-D.ietf-roll-useofrplinfo] 522 Robles, I., Richardson, M., and P. Thubert, "When to use 523 RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll- 524 useofrplinfo-22 (work in progress), March 2018. 526 [ieee-1588] 527 Precise Time and Time Interval Working Group, "IEEE Std 528 1588-2008 Standard for a Precision Clock Synchronization 529 Protocol for Networked Measurement and Control Systems", 530 July 2008. 532 Appendix A. Changes Since draft-ietf-6lo-deadline-time-00 534 This section lists the changes between draft-ietf-6lo-deadline-time 535 revisions ...-00.txt and ...-01.txt. 537 o Changed "SHOULD drop" to "MUST drop" a packet if the deadline is 538 passed (see Section 5). 540 o Added explanatory text about how packet delays might arise. (see 541 Section 4). 543 o Mentioned availability of time-synchronization protocols (see 544 Section 1). . 546 o Updated bibliographic citations. 548 o Alphabetized contributor names. 550 o Added this section. 552 Authors' Addresses 554 Lijo Thomas 555 C-DAC 556 Trivandrum 695033 557 India 559 Email: lijo@cdac.in 561 P.M. Akshay 562 Smarten Spaces 563 Bangalore 560103 564 India 566 Email: akshay.pm@smartenspaces.com 568 Satish Anamalamudi 569 Huaiyin Institute of Technology 570 No.89 North Beijing Road, Qinghe District 571 Huaian 572 China 574 Email: satishnaidu80@gmail.com 576 S.V.R Anand 577 Indian Institute of Science 578 Bangalore 560012 579 India 581 Email: anand@ece.iisc.ernet.in 583 Malati Hegde 584 Indian Institute of Science 585 Bangalore 560012 586 India 588 Email: malati@ece.iisc.ernet.in 589 Charles E. Perkins 590 Futurewei 591 2330 Central Expressway 592 Santa Clara 95050 593 Unites States 595 Email: charliep@computer.org