draft-ietf-6lo-deadline-time-05.original		draft-ietf-6lo-deadline-time-06-xml2-LT.txt
	6lo Lijo Thomas		6lo Lijo Thomas
	Internet-Draft C-DAC		Internet-Draft C-DAC
	Intended status: Standards Track S. Anamalamudi		Intended status: Standards Track S. Anamalamudi
	Expires: January 9, 2020 SRM University-AP		Expires: April 13, 2020 SRM University-AP
	S.V.R.Anand		S.V.R.Anand
	Malati Hegde		Malati Hegde
	Indian Institute of Science		Indian Institute of Science
	C. Perkins		C. Perkins
	Futurewei		Futurewei
	July 8, 2019		October 11, 2019
	Packet Delivery Deadline time in 6LoWPAN Routing Header		Packet Delivery Deadline time in 6LoWPAN Routing Header
	draft-ietf-6lo-deadline-time-05		draft-ietf-6lo-deadline-time-06
	Abstract		Abstract
	This document specifies a new type for the 6LoWPAN routing header		This document specifies a new type for the 6LoWPAN routing header
	containing the deadline time for data packets, designed for use over		containing the deadline time for data packets, designed for use over
	constrained networks. The deadline time enables forwarding and		constrained networks. The deadline time enables forwarding and
	scheduling decisions for time critical IoT machine to machine (M2M)		scheduling decisions for time critical IoT machine to machine (M2M)
	applications that operate within time-synchronized networks that		applications that operate within time-synchronized networks that
	agree on the meaning of the time representations used for the		agree on the meaning of the time representations used for the
	deadline time values.		deadline time values.
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 41 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on January 9, 2020.		This Internet-Draft will expire on April 13, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 35 ¶		skipping to change at page 2, line 35 ¶
	Technologies. . . . . . . . . . . . . . . . . . . . . . . 10		Technologies. . . . . . . . . . . . . . . . . . . . . . . 10
	6.3. Scenario 3: Packet transmission across different DODAGs		6.3. Scenario 3: Packet transmission across different DODAGs
	(N1 to N2). . . . . . . . . . . . . . . . . . . . . . . . 11		(N1 to N2). . . . . . . . . . . . . . . . . . . . . . . . 11
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	8. Synchronization Aspects . . . . . . . . . . . . . . . . . . . 13		8. Synchronization Aspects . . . . . . . . . . . . . . . . . . . 13
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 14		9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
	11.1. Normative References . . . . . . . . . . . . . . . . . . 15		11.1. Normative References . . . . . . . . . . . . . . . . . . 15
	11.2. Informative References . . . . . . . . . . . . . . . . . 17		11.2. Informative References . . . . . . . . . . . . . . . . . 17
	Appendix A. Changes from revision 04 to revision 05 . . . . . . 18		Appendix A. Changes from revision 05 to revision 06 . . . . . . 18
	Appendix B. Changes from revision 03 to revision 04 . . . . . . 18		Appendix B. Changes from revision 04 to revision 05 . . . . . . 18
	Appendix C. Changes from revision 02 to revision 03 . . . . . . 19		Appendix C. Changes from revision 03 to revision 04 . . . . . . 19
	Appendix D. Changes from revision 01 to revision 02 . . . . . . 19		Appendix D. Changes from revision 02 to revision 03 . . . . . . 19
	Appendix E. Changes between earlier versions . . . . . . . . . . 20		Appendix E. Changes from revision 01 to revision 02 . . . . . . 19
			Appendix F. Changes between earlier versions . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
	1. Introduction		1. Introduction
	Low Power and Lossy Networks (LLNs) are likely to be deployed for		Low Power and Lossy Networks (LLNs) are likely to be deployed for
	real time industrial applications requiring end-to-end delay		real time industrial applications requiring end-to-end delay
	guarantees [I-D.ietf-detnet-use-cases]. A Deterministic Network		guarantees [I-D.ietf-detnet-use-cases]. A Deterministic Network
	("detnet") typically requires some data packets to reach their		("detnet") typically requires some data packets to reach their
	receivers within strict time bounds. Intermediate nodes use the		receivers within strict time bounds. Intermediate nodes use the
	deadline information to make appropriate packet forwarding and		deadline information to make appropriate packet forwarding and
	skipping to change at page 3, line 36 ¶		skipping to change at page 3, line 36 ¶
	consideration in Wi-SUN [Wi-SUN_PHY], [dotWi-SUN].		consideration in Wi-SUN [Wi-SUN_PHY], [dotWi-SUN].
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	[RFC2119] [RFC8174].		[RFC2119] [RFC8174].
	This document uses the terminology defined in [RFC6550] and		This document uses the terminology defined in [RFC6550] and
	[I-D.ietf-6tisch-terminology].		[I-D.ietf-6tisch-architecture].
	3. 6LoRHE Generic Format		3. 6LoRHE Generic Format
	Note: this section is not normative and is included for convenience.		Note: this section is not normative and is included for convenience.
	The generic header format of the 6LoRHE is specified in		The generic header format of the 6LoRHE is specified in
	[I-D.ietf-roll-routing-dispatch]. Figure 1 illustrates the 6LoRHE		[I-D.ietf-roll-routing-dispatch]. Figure 1 illustrates the 6LoRHE
	generic format.		generic format.
	0 1		0 1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	skipping to change at page 7, line 16 ¶		skipping to change at page 7, line 16 ¶
	integer part of the DT is increased by the value of BinaryPt,		integer part of the DT is increased by the value of BinaryPt,
	and the number of bits for the fractional part of the DT is		and the number of bits for the fractional part of the DT is
	correspondingly reduced. This increases the range of DT.		correspondingly reduced. This increases the range of DT.
	* If BinaryPt value is negative, then the number of bits for the		* If BinaryPt value is negative, then the number of bits for the
	integer part of the DT is decreased by the value of BinaryPt,		integer part of the DT is decreased by the value of BinaryPt,
	and the number of bits for the fractional part of the DT is		and the number of bits for the fractional part of the DT is
	correspondingly increased. This increases the precision of the		correspondingly increased. This increases the precision of the
	fractional seconds part of DT.		fractional seconds part of DT.
	o DT Value (8..64-bit) : An unsigned integer of DTL+1 hex digits		o DT Value (8..64-bit) : An unsigned integer of DTL+1 hex digits
	giving the Deadline Time value		giving the Deadline Time value
	o OTD Value (8..64-bit) : An unsigned integer of OTL hex digits		o OTD Value (4..28-bit) : An unsigned integer of OTL hex digits
	giving the Origination Time as a negative offset from the DT value		giving the Origination Time as a negative offset from the DT value
	Whenever a sender initiates the IP datagram, it includes the		Whenever a sender initiates the IP datagram, it includes the
	Deadline-6LoRHE along with other 6LoRH information. For information		Deadline-6LoRHE along with other 6LoRH information. For information
	about the time synchronization requirements between sender and		about the time synchronization requirements between sender and
	receiver see Section 8.		receiver see Section 8.
	For the chosen time unit, a compressed time representation is		For the chosen time unit, a compressed time representation is
	available as follows. First, the application on the originating node		available as follows. First, the application on the originating node
	has to determine how many time bits are needed to represent the		has to determine how many time bits are needed to represent the
	difference between the time at which the packet is launched and the		difference between the time at which the packet is launched and the
	deadline time, including the representation of fractional time units.		deadline time, including the representation of fractional time units.
	That number of bits (say, N_bits) determines DTL (the length of the		That number of bits (say, N_bits) determines DTL (the length of the
	Deadline Time (DT)) as follows:		Deadline Time (DT)) as follows:
	DTL = (N_bits mod 4)		DTL = ((N_bits - 1) / 4)
	The number of bits determined by DTL allows counting any number of		The number of bits determined by DTL allows counting any number of
	fractional time units in the range of interest determined by DT and		fractional time units in the range of interest determined by DT and
	the origination time OT. Denote this number of fractional time units		the origination time OT. Denote this number of fractional time units
	to be Epoch_Range(DTL) (i.e., Epoch_Range is a function of DTL).		to be Epoch_Range(DTL) (i.e., Epoch_Range is a function of DTL).
	Epoch_Range(DTL) = (2^(4*(DTL+1))		Epoch_Range(DTL) = (2^(4*(DTL+1))
	Each point of time between OT and DT is represented by a time unit		Each point of time between OT and DT is represented by a time unit
	and a fractional time unit; in this section, this combined		and a fractional time unit; in this section, this combined
	representation is called a rational time unit (RTU). 1 RTU measures		representation is called a rational time unit (RTU). 1 RTU measures
	the smallest fractional time that can be represented between two		the smallest fractional time that can be represented between two
	points of time in the epoch (i.e., within the range of interest).		points of time in the epoch (i.e., within the range of interest).
	DT - OT cannot exceed 2^(4*(DTL+1)) == 16^(DTL+1). A low value of		DT - OT cannot exceed 2^(4*(DTL+1)) == 16^(DTL+1). A low value of
	DTL leads to a small Epoch_Range; if DTL = 0, there will only be 16		DTL leads to a small Epoch_Range; if DTL = 0, there will only be 16
	RTUs within the Epoch_Range (DTL) = 16^1 (for any time unit TU). The		RTUs within the Epoch_Range (DTL) = 16^1 (for any time unit TU). The
	values that can be represented in the current epoch are in the range		values that can be represented in the current epoch are in the range
	[0, (Epoch_Range(DTL) - 1)]. To minimize the required DTL,		[0, (Epoch_Range(DTL) - 1)].
	wraparound is allowed but works naturally with the arithmetic modulo
	Epoch_Range.
	By default, DTL determines t_0 in the chosen RTUs as follows:
	t_0 = [current_time - (current_time mod Epoch_Range (DTL))].
	Naturally, t_0 occurs at time 0 (or time 0.0000...) in the current		Assuming wraparound does not occur, OT is represented by the value
	epoch. The last possible origination time representable in the		(OT mod Epoch_Range) and DT is represented by the value (DT mod
	current epoch (counted in RTUs) is t_last = (t0 + (2^(4*(DTL+1))-1)).		Epoch_Range). All arithmetic is to be performed modulo
	In the RTUs chosen, the current epoch resides at the underlying time		(Epoch_Range(DTL)), yielding only positive values for DT - OT.
	interval [t_0, t_last]. If DT - OT is greater than t_last - OT, then
	wraparound within the Epoch_Range occurs naturally. In all cases, OT
	is represented by the value (OT mod Epoch_Range) and DT is
	represented by the value (DT mod Epoch_Range). All arithmetic is to
	be performed modulo (Epoch_Range(DTL)), yielding only positive values
	for DT - OT.
	Example: Consider a 6TiSCH network with time-slot length of 10ms.		Example: Consider a 6TiSCH network with time-slot length of 10ms.
	Let the time units be ASNs (TU == (binary)0b10). Let the current		Let the time units be ASNs (TU == (binary)0b10). Let the current
	ASN when the packet is originated be 54400, and the maximum		ASN when the packet is originated be 54400, and the maximum
	allowable delay (max_delay) for the packet delivery be 1 second		allowable delay (max_delay) for the packet delivery be 1 second
	from the packet origination, then:		from the packet origination, then:
	deadline_time = packet_origination_time + max_delay		deadline_time = packet_origination_time + max_delay
	= 0xD480 + 0x64 (Network ASNs)		= 0xD480 + 0x64 (Network ASNs)
	skipping to change at page 15, line 17 ¶		skipping to change at page 15, line 17 ¶
	critical importance. Extensive discussion of this topic can be found		critical importance. Extensive discussion of this topic can be found
	in [RFC7384].		in [RFC7384].
	10. Acknowledgements		10. Acknowledgements
	The authors thank Pascal Thubert for suggesting the idea and		The authors thank Pascal Thubert for suggesting the idea and
	encouraging the work. Thanks to Shwetha Bhandari's suggestions which		encouraging the work. Thanks to Shwetha Bhandari's suggestions which
	were instrumental in extending the timing information to		were instrumental in extending the timing information to
	heterogeneous networks. The authors acknowledge the 6TiSCH WG		heterogeneous networks. The authors acknowledge the 6TiSCH WG
	members for their inputs on the mailing list. Special thanks to		members for their inputs on the mailing list. Special thanks to
	Jerry Daniel, Dan Frost (Routing Directorate) Charlie Kaufman		Jerry Daniel, Dan Frost (Routing Directorate), Charlie Kaufman
	(Security Directorate) Seema Kumar, Tal Mizrahi Avinash Mohan, Shalu		(Security Directorate), Seema Kumar, Tal Mizrahi, Avinash Mohan,
	Rajendran, Anita Varghese, and Dale Worley (Gen-ART review) for their		Shalu Rajendran, Anita Varghese, and Dale Worley (Gen-ART review) for
	support and valuable feedback.		their support and valuable feedback.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[I-D.ietf-6tisch-terminology]		[I-D.ietf-6tisch-architecture]
	Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,		Thubert, P., "An Architecture for IPv6 over the TSCH mode
	"Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e",		of IEEE 802.15.4", draft-ietf-6tisch-architecture-26 (work
	draft-ietf-6tisch-terminology-10 (work in progress), March		in progress), August 2019.
	2018.
	[I-D.ietf-detnet-architecture]		[I-D.ietf-detnet-architecture]
	Finn, N., Thubert, P., Varga, B., and J. Farkas,		Finn, N., Thubert, P., Varga, B., and J. Farkas,
	"Deterministic Networking Architecture", draft-ietf-		"Deterministic Networking Architecture", draft-ietf-
	detnet-architecture-13 (work in progress), May 2019.		detnet-architecture-13 (work in progress), May 2019.
	[I-D.ietf-roll-routing-dispatch]		[I-D.ietf-roll-routing-dispatch]
	Thubert, P., Bormann, C., Toutain, L., and R. Cragie,		Thubert, P., Bormann, C., Toutain, L., and R. Cragie,
	"6LoWPAN Routing Header", draft-ietf-roll-routing-		"6LoWPAN Routing Header", draft-ietf-roll-routing-
	dispatch-05 (work in progress), October 2016.		dispatch-05 (work in progress), October 2016.
	skipping to change at page 17, line 31 ¶		skipping to change at page 17, line 31 ¶
	26505-26519, May 2018.		26505-26519, May 2018.
	[dotWi-SUN]		[dotWi-SUN]
	Harada, H., Mizutani, K., Fujiwara, J., Mochizuki, K.,		Harada, H., Mizutani, K., Fujiwara, J., Mochizuki, K.,
	Obata, K., and R. Okumura, "IEEE 802.15.4g Based Wi-SUN		Obata, K., and R. Okumura, "IEEE 802.15.4g Based Wi-SUN
	Communication Systems", IEICE Transactions on		Communication Systems", IEICE Transactions on
	Communications volume E100.B, Jan 2017.		Communications volume E100.B, Jan 2017.
	[I-D.ietf-6lo-backbone-router]		[I-D.ietf-6lo-backbone-router]
	Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6		Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6
	Backbone Router", draft-ietf-6lo-backbone-router-11 (work		Backbone Router", draft-ietf-6lo-backbone-router-13 (work
	in progress), February 2019.		in progress), September 2019.
	[I-D.ietf-6lo-blemesh]		[I-D.ietf-6lo-blemesh]
	Gomez, C., Darroudi, S., Savolainen, T., and M. Spoerk,		Gomez, C., Darroudi, S., Savolainen, T., and M. Spoerk,
	"IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP",		"IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP",
	draft-ietf-6lo-blemesh-05 (work in progress), March 2019.		draft-ietf-6lo-blemesh-06 (work in progress), September
			2019.
	[I-D.ietf-6tisch-architecture]
	Thubert, P., "An Architecture for IPv6 over the TSCH mode
	of IEEE 802.15.4", draft-ietf-6tisch-architecture-24 (work
	in progress), July 2019.
	[I-D.ietf-detnet-use-cases]		[I-D.ietf-detnet-use-cases]
	Grossman, E., "Deterministic Networking Use Cases", draft-		Grossman, E., "Deterministic Networking Use Cases", draft-
	ietf-detnet-use-cases-20 (work in progress), December		ietf-detnet-use-cases-20 (work in progress), December
	2018.		2018.
	[I-D.ietf-ippm-ioam-data]		[I-D.ietf-ippm-ioam-data]
	Brockners, F., Bhandari, S., Pignataro, C., Gredler, H.,		Brockners, F., Bhandari, S., Pignataro, C., Gredler, H.,
	Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov,		Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov,
	P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon,		P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon,
	"Data Fields for In-situ OAM", draft-ietf-ippm-ioam-		"Data Fields for In-situ OAM", draft-ietf-ippm-ioam-
	data-06 (work in progress), July 2019.		data-07 (work in progress), September 2019.
	[I-D.ietf-roll-useofrplinfo]		[I-D.ietf-roll-useofrplinfo]
	Robles, I., Richardson, M., and P. Thubert, "Using RPL		Robles, I., Richardson, M., and P. Thubert, "Using RPL
	Option Type, Routing Header for Source Routes and IPv6-in-		Option Type, Routing Header for Source Routes and IPv6-in-
	IPv6 encapsulation in the RPL Data Plane", draft-ietf-		IPv6 encapsulation in the RPL Data Plane", draft-ietf-
	roll-useofrplinfo-31 (work in progress), July 2019.		roll-useofrplinfo-31 (work in progress), August 2019.
	[ieee-1588]		[ieee-1588]
	"IEEE Standards", "IEEE Std 1588-2008 Standard for a		"IEEE Standards", "IEEE Std 1588-2008 Standard for a
	Precision Clock Synchronization Protocol for Networked		Precision Clock Synchronization Protocol for Networked
	Measurement and Control Systems", July 2008.		Measurement and Control Systems", July 2008.
	[Wi-SUN_PHY]		[Wi-SUN_PHY]
	Wi-SUN Alliance, "Wi-SUN PHY Specification V1.0", March		Wi-SUN Alliance, "Wi-SUN PHY Specification V1.0", March
	2016.		2016.
	Appendix A. Changes from revision 04 to revision 05		Appendix A. Changes from revision 05 to revision 06
			This section lists the changes between draft-ietf-6lo-deadline-time
			revisions ...-05.txt and ...-06.txt.
			o Fixed the error in DTL calculation.
			o Removed the text pertaining to wraparound in section 5
			o Replaced the 6tisch terminology with 6tisch architecture
			o Updated the contact information of authors
			Appendix B. Changes from revision 04 to revision 05
	This section lists the changes between draft-ietf-6lo-deadline-time		This section lists the changes between draft-ietf-6lo-deadline-time
	revisions ...-04.txt and ...-05.txt.		revisions ...-04.txt and ...-05.txt.
	o Included additional relevant material in Security Considerations		o Included additional relevant material in Security Considerations
	regarding expected deployment scenarios and the effect of		regarding expected deployment scenarios and the effect of
	disclosing additional information during the travel of a packet.		disclosing additional information during the travel of a packet.
	o Reworked the specification for using time ranges shorter than the		o Reworked the specification for using time ranges shorter than the
	maximum allowed by the choice of TU, so that fewer bits are needed		maximum allowed by the choice of TU, so that fewer bits are needed
	to represent DT and OT.		to represent DT and OT.
	o Revised the figures and examples to use new parameters		o Revised the figures and examples to use new parameters
	o Reordered the field definitions for the Deadline-6LoRHE.		o Reordered the field definitions for the Deadline-6LoRHE.
	o Responded to numerous reviewer comments to improve terminology and		o Responded to numerous reviewer comments to improve terminology and
	editorial consistency.		editorial consistency.
	Appendix B. Changes from revision 03 to revision 04		Appendix C. Changes from revision 03 to revision 04
	This section lists the changes between draft-ietf-6lo-deadline-time		This section lists the changes between draft-ietf-6lo-deadline-time
	revisions ...-03.txt and ...-04.txt.		revisions ...-03.txt and ...-04.txt.
	o Replaced OT (Origination Time) field by OTD (Origination Time		o Replaced OT (Origination Time) field by OTD (Origination Time
	Delta), allowing a more compressed representation that needs less		Delta), allowing a more compressed representation that needs less
	processing during transitions between networks.		processing during transitions between networks.
	o Changed representation for DTL, OTL, DT, OTD. Eliminated EXP in		o Changed representation for DTL, OTL, DT, OTD. Eliminated EXP in
	favor of BinaryPt.		favor of BinaryPt.
	o Revised the figures and examples to use new parameters		o Revised the figures and examples to use new parameters
	o Added new section on Synchronization Aspects to supply pertinent		o Added new section on Synchronization Aspects to supply pertinent
	information about how nodes agree on the meaning of t=0.		information about how nodes agree on the meaning of t=0.
	o Responded to numerous reviewer comments to improve editorial		o Responded to numerous reviewer comments to improve editorial
	consistency and improve terminology.		consistency and improve terminology.
	Appendix C. Changes from revision 02 to revision 03		Appendix D. Changes from revision 02 to revision 03
	This section lists the changes between draft-ietf-6lo-deadline-time		This section lists the changes between draft-ietf-6lo-deadline-time
	revisions ...-02.txt and ...-03.txt.		revisions ...-02.txt and ...-03.txt.
	o Added non-normative 6LoRHE description, citing RFC 8138.		o Added non-normative 6LoRHE description, citing RFC 8138.
	o Specified that the Origination Time (OT) is the time that packet		o Specified that the Origination Time (OT) is the time that packet
	is enqueued for transmission.		is enqueued for transmission.
	o Mentioned more sources of packet delay.		o Mentioned more sources of packet delay.
	o Clarified reasons that packet MAY be forwarded if 'D' bit is 0.		o Clarified reasons that packet MAY be forwarded if 'D' bit is 0.
	o Clarified that DT, OT, DTL and OTL are unsigned integers.		o Clarified that DT, OT, DTL and OTL are unsigned integers.
	o Updated bibliographic citations, including BLEmesh and Wi-SUN.		o Updated bibliographic citations, including BLEmesh and Wi-SUN.
	Appendix D. Changes from revision 01 to revision 02		Appendix E. Changes from revision 01 to revision 02
	This section lists the changes between draft-ietf-6lo-deadline-time		This section lists the changes between draft-ietf-6lo-deadline-time
	revisions ...-01.txt and ...-02.txt.		revisions ...-01.txt and ...-02.txt.
	o Replaced 6LoRHE description by reference to RFC 8138.		o Replaced 6LoRHE description by reference to RFC 8138.
	o Added figure to illustrate change to Origination Time when a		o Added figure to illustrate change to Origination Time when a
	packet crosses timezone boundaries.		packet crosses timezone boundaries.
	o Clarified that use of 6tisch networks is descriptive, not		o Clarified that use of 6tisch networks is descriptive, not
	normative.		normative.
	o Clarified that In-Band OAM is used as an example and is not		o Clarified that In-Band OAM is used as an example and is not
	normative.		normative.
	o Updated bibliographic citations.		o Updated bibliographic citations.
	o Alphabetized contributor names.		o Alphabetized contributor names.
	Appendix E. Changes between earlier versions		Appendix F. Changes between earlier versions
	This section lists the changes between draft-ietf-6lo-deadline-time		This section lists the changes between draft-ietf-6lo-deadline-time
	revisions ...-00.txt and ...-01.txt.		revisions ...-00.txt and ...-01.txt.
	o Changed "SHOULD drop" to "MUST drop" a packet if the deadline is		o Changed "SHOULD drop" to "MUST drop" a packet if the deadline is
	passed (see Section 5).		passed (see Section 5).
	o Added explanatory text about how packet delays might arise. (see		o Added explanatory text about how packet delays might arise. (see
	Section 4).		Section 4).
	skipping to change at page 21, line 9 ¶		skipping to change at page 21, line 9 ¶
	Amaravati Campus		Amaravati Campus
	Amaravati, Andhra Pradesh 522 502		Amaravati, Andhra Pradesh 522 502
	India		India
	Email: satishnaidu80@gmail.com		Email: satishnaidu80@gmail.com
	S.V.R Anand		S.V.R Anand
	Indian Institute of Science		Indian Institute of Science
	Bangalore 560012		Bangalore 560012
	India		India
	Email: anand@ece.iisc.ernet.in		Email: anandsvr@iisc.ac.in
	Malati Hegde		Malati Hegde
	Indian Institute of Science		Indian Institute of Science
	Bangalore 560012		Bangalore 560012
	India		India
	Email: malati@ece.iisc.ernet.in		Email: malati@iisc.ac.in
	Charles E. Perkins		Charles E. Perkins
	Futurewei		Futurewei
	2330 Central Expressway		2330 Central Expressway
	Santa Clara 95050		Santa Clara 95050
	Unites States		Unites States
	Email: charliep@computer.org		Email: charliep@computer.org
End of changes. 24 change blocks.
	56 lines changed or deleted		52 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/