6lo Lijo Thomas Internet-Draft C-DAC Intended status: Standards TrackP. Akshay Expires: September 5, 2018 Smarten Spaces SatishS. AnamalamudiHuaiyin Institute of TechnologyExpires: March 4, 2019 SRM University-AP S.V.R.Anand Malati Hegde Indian Institute of Science C. Perkins FutureweiMarch 4,August 31, 2018 Packet Delivery Deadline time in 6LoWPAN Routing Headerdraft-ietf-6lo-deadline-time-01draft-ietf-6lo-deadline-time-02 Abstract This document specifies a new type for the 6LoWPAN routing header containing the delivery deadline time for data packets. The deadline time enables forwarding and scheduling decisions for time critical IoT M2M applications that need deterministic delay guarantees over constrained networks and operate within time-synchronized networks. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire onSeptember 5, 2018.March 4, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.6LoRHE Generic Format . . . . . . . . . . . . . . . . . . . . 3 4.Deadline-6LoRHE . . . . . . . . . . . . . . . . . . . . . . .4 5.3 4. Deadline-6LoRHE Format . . . . . . . . . . . . . . . . . . . 56.5. Deadline-6LoRHE in Three Network Scenarios . . . . . . . . .6 6.1.7 5.1. Scenario 1: Endpoints in the same DODAG (N1)in non- storing mode. . . . . . . . . . . . . . . . .. . . . . . 76.2.5.2. Scenario 2: Endpoints in Networks with Dissimilar L2 Technologies. . . . . . . . . . . . . . . . . . . . . . . 86.3.5.3. Scenario 3: Packet transmission across different DODAGs (N1 to N2). . . . . . . . . . . . . . . . . . . . . . . . 97.6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 108.7. Security Considerations . . . . . . . . . . . . . . . . . . .10 9.11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . .10 10.11 9. References . . . . . . . . . . . . . . . . . . . . . . . . .10 10.1.11 9.1. Normative References . . . . . . . . . . . . . . . . . .10 10.2.11 9.2. Informative References . . . . . . . . . . . . . . . . .1112 Appendix A. ChangesSince draft-ietf-6lo-deadline-time-00after draft-ietf-6lo-deadline-time-01 . . .1213 Appendix B. Changes between earlier versions . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .1314 1. Introduction Low Power and Lossy Networks (LLNs) are likely to be deployed for real time industrial applications requiring end-to-end delay guarantees [I-D.ietf-detnet-use-cases]. A Deterministic Network ("detnet") typically requires some data packets to reach their receivers within strict time bounds. Intermediate nodes use the deadline information to make appropriate packet forwarding and scheduling decisions to meet the time bounds. The draft [I-D.ietf-roll-routing-dispatch] specifies the 6LoWPAN Routing Header (6LoRH), compression schemes for RPL routing (source routing) operation [RFC6554], header compression of RPL Packet Information [RFC6553], and IP-in-IP encapsulation. This document specifies a new Deadline-6LoRHE type for the 6LoWPAN Dispatch Page 1, so that the deadline time of data packets can be included within the 6LoWPAN routing header. This document also specifies handling of the deadline time when packets traverse through time-synchronized networks operating in different timezones or distinct reference clocks. Time synchronization techniques need not be mandated by this specificiation. There are a number of standards available for this purpose, including IEEE 1588 [ieee-1588], IEEE 802.1AS [dot1AS-2011], IEEE 802.15.4-2015 TSCH [dot15-tsch], and more. The Deadline-6LoRHE can be used in any time synchronized 6Lo network. A 6TiSCH network has been used to describe the implementation of the Deadline-6LoRHE, but this does not preclude its use in scenarios other than 6TiSCH. For instance, there is a growing interest in using 6lo over a BLE mesh network [I-D.ietf-6lo-blemesh] in industrial IoT. BLE mesh time synchronization is also being recently explored by the Bluetooth community. There are also cases under consideration in Wi-SUN. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. This document uses terminology consistent with the terminology used in [RFC6550] and [I-D.ietf-6tisch-terminology]. Also, in this document, the terms "expiration time", "delivery deadline time", and "deadline" are used interchangeably with the same meaning. 3.6LoRHE Generic Format Note: this section is not normative. It is included for convenience, and may be deleted in a later revision of this document. The generic header format of the 6LoRHE is specified in [I-D.ietf-roll-routing-dispatch]. Figure 1 illustrates the 6LoRHE generic format. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ |1|0|1| Length | Type | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ <-- length --> Figure 1: 6LoRHE format o Length: Length of the 6LoRHE expressed in bytes, excluding the first 2 bytes. This enables a node to skip a 6LoRHE if the Type is not recognized/supported. o Type: Type of the 6LoRHE. o length: variable 4.Deadline-6LoRHE The Deadline-6LoRHE (see Figure 2) is an elective 6LoRH (i.e., a6loRHE)6LoRHE [RFC8138]) that provides the DeadlinetimeTime (DT) for an IPv6 datagram in a compressed form. Along with the deadline, the header can include the packet Origination Time (OT), to enable a close estimate of the total delay incurred by a packet. The OT field is initialized by the sender using the current time at the outgoing network interface through which the packet is forwarded. The deadline field contains the value of the delivery deadline time for the packet. The packet SHOULD be delivered to the Receiver before this time. packet_deadline_time = packet_origination_time + max_delay All nodes within the network SHOULD process the Deadline-6LoRHE in order to support delay-sensitive deterministic applications. The packet deadline time (DT) and origination time (OT) are represented in time units determined by a scaling parameter in the routing header. One of the time units is the Network ASN (Absolute Slot Number) which can be used in case of a time slotted synchronizednetwork, fornetwork (for instance a 6TiSCH network, where global time is maintained in the units of slot lengths of a certainresolution.resolution). The delay experienced by packets in the network is a useful metric for network diagnostics and performance monitoring. Whenever the packets crosses into a network using a different reference clock, the Origination Time field is updated to represent the same OriginationTime asTime, but expressed using the reference clock of theoutgoinginterface into the new network. This is the same as the current time when the packet is transmitted into the new network, minus the delay already experienced by the packet, say 't'. Ineffect, to thethis way, within the newly entered network, the packet will appear to have originated 't' time units earlier with respect to the reference clock of the new network. Origination Time in new network = current_time_in_new_network - delay_already_experienced_in_previous_network(s) The following example illustrates the origination time calculation when a packet travels between three networks, each in a different time zone. 'x' can be 1,2 or 3. TxA : Time of arrival of packet in the network 'x' TxD : Departure time of packet in the network 'x' Dx : Delay experienced by the packet in the previous network(s) TZx : Indicates the time zone of network 'x' As an illustration, we consider a packet traversing through three time synchronized networks along with numerical values as shown in Figure 1. TZ1 TZ2 TZ3 T1A=0| | | |---- D1=100 | | | \ | | | \ | | | \ T1D=100 |T2A=1000 | | -------->|----- D2=400 | | | \ | | | \ | | | \ T2D=1400 | T3A=5000 | | ------------------->| | | | v v v D = 0 D = T1D-OT D = T2D-OT = 100-0 = 1400 - 900 = 100 = 500 i.e. (D1 + D2) OT = T1A-D OT = T2A-D OT = T3A-D = 0 = 1000-100 = 5000 - 500 = 900 = 4500 Figure 1: Origination Time update example There are multiple ways that a packet can be delayed, including propagation delay and queuing delays. Sometimes there are processing delays as well. For the purpose of determining whether or not the deadline has already passed, these various delays are not distinguished.5.4. Deadline-6LoRHE Format 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|1| Length | 6LoRH Type |O|D| DTL | OTL | TU| EXP | Rsv | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DT (variable length) | OT(variable length)(optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Deadline-6LoRHE format Length (5 bits): Length represents the total length of the Deadline- 6LoRHE type measured in octets. 6LoRH Type: TBD O flag (1bit): Indicates the presence of Origination Time field. '1' means the OT field is present, and '0' means it is absent. D flag (1 bit): The 'D' flag, set by the Sender, indicates the action to be taken when a 6LR detects that the deadline time has elapsed. If 'D' bit is 1, then the 6LR MUST drop the packet if the deadline time is elapsed. If 'D' bit is 0, then the 6LR MAY ignore the deadline time and forward the packet. DTL (3 bits): Length of DT field. OTL (3 bits) : Length of OT field. For example, DTL = 000 means the deadline time in the 6LoRHE is 1 octet (8 bits) long. Similarly, OTL = 111 means the origination time is 8 octets (64 bits) long. TU (2 bits) : Indicates the time units for DT and OT fields 00 : Time represented in microseconds 01 : Time represented in seconds 10 : Network ASN 11 : Reserved EXP (3 bits) : Multiplication factor expressed as exponent of 10. The value of the DT field is multiplied by 10 to this power, to get the actual deadline time in the units represented by TU. The default value of EXP is 000, so that the DT field is unaffected. Rsv (3 bits) : Reserved DT Value (8..64-bit) : Deadline Time value OT Value (8..64-bit) : Origination Time value Whenever a sender initiates the IP datagram, it includes the Deadline-6LoRHE along with other 6LoRH information. Example: Consider a 6TiSCH network with time-slot length of 10ms. Let the current ASN when the packet is originated be 54400, and the maximum allowable delay (max_delay) for the packet delivery is 1 second from the packet origination, then: deadline_time = packet_origination_time + max_delay = 55400 + 100 (in Network ASNs) = 55500(Network ASNs) Deadline-6LoRHE encoding with 'O' flag and 'D' flag set to1 :1: DTL = 001, OTL = 001, TU = '10', EXP = 2, DT = 0x22B, OT = 0x22A6.5. Deadline-6LoRHE in Three Network Scenarios In this section, Deadline-6LoRHE operation is described for 3 network scenarios. Figure 3 depicts a constrained time-synchronized LLN that has two subnets N1 and N2, connected through LBRs [I-D.ietf-6lo-backbone-router] with different reference clock times T1 and T2. +-------------------+ | Time Synchronized | | Network | +---------+---------+ | | | +--------------+--------------+ | | +-----+ +-----+ | | Backbone | | Backbone o | | router | | router +-----+ +-----+ o o o o o o o o o o o o o LLN o o LLN o o o o o o o o o o o 6LoWPAN Network (subnet N1) 6LoWPAN Network (subnet N2) Figure 3: Intra-network Timezone Scenario6.1.5.1. Scenario 1: Endpoints in the same DODAG (N1)in non-storing mode.In scenario 1, shown in Figure 4, the Sender 'S' has an IP datagram to be routed to a Receiver 'R' within the same DODAG. For the route segment from Sender to 6LBR, the Sender includes a Deadline-6LoRHE by encoding the deadline time contained in theinband-OAM header extension. Thenpacket. Subsequently, each 6LRbeginswill perform hop-by-hopoperationrouting to forward the packet towards the 6LBR. Once 6LBR receives the IP datagram, it sends the packet downstream towards 'R'. In case of a network running RPL non-storing mode, the 6LBR generates a IPv6-in-IPv6 encapsulated packet when sending the packet downwards to the Receiver [I-D.ietf-roll-useofrplinfo]. The 6LBR copies the Deadline-6LoRHE from the Sender originated IP header to the outer IP header. The Deadline-6LoRHE contained in the inner IP header is elided. +-------+ ^ | 6LBR | | | | | | | +-------+ |DefaultUpward | (F)/ /| \ |IP-in-IPDownward routing | / \ / | \ |Encapsulationrouting | / \ (C) | (D) | | (A) (B) / | / |\ | | /|\ |\: (E) : R | S : : : / \Vv Figure 4: End points within sameDODAG(subnetDODAG (subnet N1) At the tunnel endpoint of the IPv6-in-IPv6 encapsulation, theDeadline- 6LoRHEDeadline-6LoRHE is copied back from the outer header to inner header, and the inner IP packet is delivered to 'R'.6.2.5.2. Scenario 2: Endpoints in Networks with Dissimilar L2 Technologies. In scenario 2, shown in Figure 5, the Sender 'S' (belonging to DODAG 1) has IP datagram to be routed to a Receiver 'R' over a time- synchronized IPv6 network. For the route segment from 'S' to 6LBR, 'S' includes a Deadline-6LoRHE. Subsequently, each 6LR will performhop- by-hop operationhop-by-hop routing to forward the packet towards the 6LBR. Once theIP datagramDeadline Time information reaches6LBR of DODAG1, it encodesthedeadline time (and, if available,border router, theorigination time) intopacket will be encoded as per theIn-band OAM header extension, [I-D.ietf-ippm-ioam-data] and passesmechanism prescribed in thedatagram tonew time synchronized network. The specific data encapsulation mechanisms followed in theIPv6 layer for further routing.new network are beyond the scope of this document. +----------------+ | Time | |synchronizedSynchronized |------R | Network | +----------------+ | | ----------+----------- ^ | | +---+---+ | | 6LBR |DefaultUpward | | | routing | +------++ | (F)/ /| \ | / \ / | \ | / \ (C) | (D) : (A) (B) / | / |\ /|\ |\: (E)::: S : : : / \ : : Figure 5: Packet transmission in Dissimilar L2 Technologies or InternetTheFor instance, the IP datagramiscould be routed to another time synchronized deterministic networkfollowing its own distinct reference clock, sousing thedeadline timemechanism specified in the In-band OAMhas to[I-D.ietf-ippm-ioam-data], and then the deadline time would be updated according to the measurement of the current time in the new network.6.3.5.3. Scenario 3: Packet transmission across different DODAGs (N1 to N2). Consider the scenario depicted in Figure 6, in which the Sender 'S' (belonging to DODAG 1) has an IP datagram to be sent to Receiver 'R' belonging to another DODAG (DODAG 2). The operation of this scenario can be decomposed into combination of case 1 and case 2 scenarios. For the route segment from 'S' to 6LBR, 'S' includes the Deadline- 6LoRHE. Subsequently, each 6LR will perform hop-by-hop operation to forward the packet towards the 6LBR. Once the IP datagram reaches 6LBR1 of DODAG1, it applies the same rule as described in Case 2 while routing the packet toLBR26LBR2 over a (likely) time synchronized wired backhaul. The wired side ofLBR26LBR2 can be mapped to receiver of Case 2. Once the packet reachesLBR2,6LBR2, it updates theDeadline-6LoRHEDeadline- 6LoRHE by adding or subtracting thecurrentdifference of time ofDODAG2. Further, it generates an IPv6- in-IPv6 encapsulated packet when sendingDODAG2 and sends the packet downstreamto the Receiver [I-D.ietf-roll-useofrplinfo].towards 'R'. Time Synchronized Network -+---------------------------+- | | DODAG1 +---+---+ +---+---+ DODAG2Instance 1| 6LBR1 | | 6LBR2 |Instance 2 || | | | +-------+ +-------+|(F)/ /| \ (F)/ /| \|/ \ / | \ / \ / | \|/ \ (C) | (D) / \ (C) | (D)|IP-in-IP(A) (B) / | / |\ (A) (B) / | / |\| Encapsulation/|\ |\: (E) : : /|\ |\: (E) ::|: S : : : / \ : : : : / \|: : : RVNetwork N1, time zone T1NetWorkNetwork N2, time zone T2 Figure 6: Packet transmission in different DODAGs(N1 to N2) Consider an example of a 6TiSCH network in which S in DODAG1 generates the packet at ASN 20000 to R in DODAG2. Let the maximum allowable delay be 1 second. The time-slot length in DODAG1 and DODAG2 is assumed to be 10ms. Once the deadline time is encoded in Deadline-6LoRHE, the packet is forwarded toLBR6LBR of DODAG1. Suppose the packet reachesLBR6LBR of DODAG1 at ASN20050.20030. current_time = ASN at LBR * slot_length_value remaining_time = deadline_time - current_time = ((packet_origination_time + max_delay) - current time) = (20000 + 100) -2005020030 =5030 (in Network ASNs) =5030 * 10^3 milliseconds.The remaining time is encoded in In-Band OAM (see Case 2) and forwarded to LBR2 over a different L2-interface, typically wired.Once thepacketDeadline Time information reachesLBR2,thedeadline time in Deadline-6LoRHE is adjusted by adding or subtractingborder router, thedifference between the reference clocks ofpacket will be encoded as per thetwo networks, before forwardingmechanism prescribed in thepacket to its connected 6TiSCH network. 7.new time synchronized network 6. IANA Considerations This document defines a new 6LoWPAN Timestamp Header Type, and assigns a value (TBD) from the 6LoWPAN Dispatch Page1 number space. 6LoRH Type Value +------------------+--------+ | Deadline-6LoRHE | TBD | +------------------+--------+ Figure 7: Deadline-6LoRHE type8.7. Security Considerations The security considerations of [RFC4944], [RFC6282] and [RFC6553] apply. Using a compressed format as opposed to the full in-line format is logically equivalent and does not create an opening for a new threat when compared to [RFC6550], [RFC6553] and [RFC6554].9.8. Acknowledgements The authors thank Pascal Thubert for suggesting the idea and encouraging the work. Thanks to Shwetha Bhandari's suggestions which were instrumental in extending the timing information to heterogeneous networks. The authors acknowledge the 6TiSCH WG members for their inputs on the mailing list. Special thanks to Jerry Daniel, Seema Kumar, Avinash Mohan, Shalu Rajendran and Anita Varghese for their support and valuable feedback.10.9. References10.1.9.1. Normative References [I-D.ietf-6tisch-terminology] Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, "Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e", draft-ietf-6tisch-terminology-10 (work in progress), March 2018. [I-D.ietf-roll-routing-dispatch] Thubert, P., Bormann, C., Toutain, L., and R. Cragie, "6LoWPAN Routing Header", draft-ietf-roll-routing- dispatch-05 (work in progress), October 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, <https://www.rfc-editor.org/info/rfc4944>. [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011, <https://www.rfc-editor.org/info/rfc6282>. [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012, <https://www.rfc-editor.org/info/rfc6550>. [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams", RFC 6553, DOI 10.17487/RFC6553, March 2012, <https://www.rfc-editor.org/info/rfc6553>. [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6554, DOI 10.17487/RFC6554, March 2012, <https://www.rfc-editor.org/info/rfc6554>.10.2.[RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, "IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, April 2017, <https://www.rfc-editor.org/info/rfc8138>. 9.2. Informative References [dot15-tsch] P802.11, "IEEE Standard for Low-Rate Wireless Networks, Part 15.4, IEEE Std 802.15.4-2015", April 2016. [dot1AS-2011] IEEE 802.1AS Working Group, "IEEE Standard for Local and Metropolitan Area Networks - Timing and Synchronization for Time-Sensitive Applications in Bridged Local Area Networks", March 2011. [I-D.ietf-6lo-backbone-router] Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo- backbone-router-06 (work in progress), February 2018. [I-D.ietf-6lo-blemesh] Gomez, C., Darroudi, S., Savolainen, T., and M. Spoerk, "IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP", draft-ietf-6lo-blemesh-03 (work in progress), July 2018. [I-D.ietf-detnet-use-cases] Grossman, E., "Deterministic Networking Use Cases", draft-ietf-detnet-use-cases-14ietf-detnet-use-cases-17 (work in progress),FebruaryJune 2018. [I-D.ietf-ippm-ioam-data] Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, P., Chang, R.,and d.daniel.bernier@bell.ca, d., and J. Lemon, "Data Fields for In-situ OAM",draft-ietf-ippm-ioam-data-01draft-ietf-ippm-ioam- data-03 (work in progress),October 2017.June 2018. [I-D.ietf-roll-useofrplinfo] Robles, I., Richardson, M., and P. Thubert, "When to use RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll-useofrplinfo-22useofrplinfo-23 (work in progress),MarchMay 2018. [ieee-1588] Precise Time and Time Interval Working Group, "IEEE Std 1588-2008 Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", July 2008. Appendix A. ChangesSince draft-ietf-6lo-deadline-time-00after draft-ietf-6lo-deadline-time-01 This section lists the changes between draft-ietf-6lo-deadline-time revisions ...-01.txt and ...-02.txt. o Replaced 6LoRHE description by reference to RFC 8138. o Added figure to illustrate change to Origination Time when a packet crosses timezone boundaries. o Clarified that use of 6tisch networks is descriptive, not normative. o Clarified that In-Band OAM is used as an example and is not normative. o Updated bibliographic citations. o Alphabetized contributor names. Appendix B. Changes between earlier versions This section lists the changes between draft-ietf-6lo-deadline-time revisions ...-00.txt and ...-01.txt. o Changed "SHOULD drop" to "MUST drop" a packet if the deadline is passed (see Section5).4). o Added explanatory text about how packet delays might arise. (see Section4).3). o Mentioned availability of time-synchronization protocols (see Section 1). . o Updated bibliographic citations. o Alphabetized contributor names. o Added this section. Authors' Addresses Lijo Thomas C-DAC Trivandrum 695033 India Email: lijo@cdac.inP.M. Akshay Smarten Spaces Bangalore 560103 India Email: akshay.pm@smartenspaces.comSatish AnamalamudiHuaiyin Institute of Technology No.89 North Beijing Road, Qinghe District Huaian ChinaSRM University-AP Amaravati Campus Amaravati, Andhra Pradesh 522 502 India Email: satishnaidu80@gmail.com S.V.R Anand Indian Institute of Science Bangalore 560012 India Email: anand@ece.iisc.ernet.in Malati Hegde Indian Institute of Science Bangalore 560012 India Email: malati@ece.iisc.ernet.in Charles E. Perkins Futurewei 2330 Central Expressway Santa Clara 95050 Unites States Email: charliep@computer.org