rfc9034v1.txt		rfc9034.txt
	Internet Engineering Task Force (IETF) L. Thomas		Internet Engineering Task Force (IETF) L. Thomas
	Request for Comments: 9034 C-DAC		Request for Comments: 9034 C-DAC
	Category: Standards Track S. Anamalamudi		Category: Standards Track S. Anamalamudi
	ISSN: 2070-1721 SRM University-AP		ISSN: 2070-1721 SRM University-AP
	S.V.R. Anand		S.V.R. Anand
	M. Hegde		M. Hegde
	Indian Institute of Science		Indian Institute of Science
	C. Perkins		C. Perkins
	Futurewei		Lupin Lodge
	May 2021		May 2021
	Packet Delivery Deadline Time in the Routing Header for IPv6 over Low-		Packet Delivery Deadline Time in the Routing Header for IPv6 over Low-
	Power Wireless Personal Area Networks (6LoWPANs)		Power Wireless Personal Area Networks (6LoWPANs)
	Abstract		Abstract
	This document specifies a new Type for the Elective 6LoWPAN Routing		This document specifies a new type for the 6LoWPAN routing header
	Header (6LoRHE) that contains the deadline time for data packets and		containing the deadline time for data packets, designed for use over
	is designed for use over constrained networks. The deadline time		constrained networks. The deadline time enables forwarding and
	enables forwarding and scheduling decisions for time-critical		scheduling decisions for time-critical machine-to-machine (M2M)
	Internet of Things (IoT) machine-to-machine (M2M) applications that		applications running on Internet-enabled devices that operate within
	operate within time-synchronized networks that agree on the meaning		time-synchronized networks. This document also specifies a
	of the time representations used for the deadline time values.		representation for the deadline time values in such networks.
	Status of This Memo		Status of This Memo
	This is an Internet Standards Track document.		This is an Internet Standards Track document.
	This document is a product of the Internet Engineering Task Force		This document is a product of the Internet Engineering Task Force
	(IETF). It represents the consensus of the IETF community. It has		(IETF). It represents the consensus of the IETF community. It has
	received public review and has been approved for publication by the		received public review and has been approved for publication by the
	Internet Engineering Steering Group (IESG). Further information on		Internet Engineering Steering Group (IESG). Further information on
	Internet Standards is available in Section 2 of RFC 7841.		Internet Standards is available in Section 2 of RFC 7841.
	skipping to change at line 64 ¶		skipping to change at line 64 ¶
	Table of Contents		Table of Contents
	1. Introduction		1. Introduction
	2. Terminology		2. Terminology
	3. 6LoRHE Generic Format		3. 6LoRHE Generic Format
	4. Deadline-6LoRHE		4. Deadline-6LoRHE
	5. Deadline-6LoRHE Format		5. Deadline-6LoRHE Format
	6. Deadline-6LoRHE in Three Network Scenarios		6. Deadline-6LoRHE in Three Network Scenarios
	6.1. Scenario 1: Endpoints in the Same DODAG (N1)		6.1. Scenario 1: Endpoints in the Same DODAG (N1)
	6.2. Scenario 2: Endpoints in Networks with Dissimilar Layer 2		6.2. Scenario 2: Endpoints in Networks with Dissimilar L2
	Technologies		Technologies
	6.3. Scenario 3: Packet Transmission across Different DODAGs (N1		6.3. Scenario 3: Packet Transmission across Different DODAGs (N1
	to N2)		to N2)
	7. IANA Considerations		7. IANA Considerations
	8. Synchronization Aspects		8. Synchronization Aspects
	9. Security Considerations		9. Security Considerations
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	10.2. Informative References		10.2. Informative References
			Appendix A. Modular Arithmetic Considerations
	Acknowledgments		Acknowledgments
	Authors' Addresses		Authors' Addresses
	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 [RFC8578]. A Deterministic Network ("DetNet") typically		guarantees [RFC8578]. A Deterministic Network ("DetNet") typically
	requires some data packets to reach their receivers within strict		requires some data packets to reach their receivers within strict
	time bounds. Intermediate nodes use the deadline information to make		time bounds. Intermediate nodes use the deadline information to make
	appropriate packet forwarding and scheduling decisions to meet the		appropriate packet forwarding and scheduling decisions to meet the
	time bounds.		time bounds.
	This document specifies a new Type for the Elective 6LoWPAN Routing		This document specifies a new type for the Elective 6LoWPAN Routing
	Header (6LoRHE), Deadline-6LoRHE, so that the deadline time (i.e.,		Header (6LoRHE), Deadline-6LoRHE, so that the deadline time (i.e.,
	the time of latest acceptable delivery) of data packets can be		the time of latest acceptable delivery) of data packets can be
	included within the 6LoRHE. [RFC8138] specifies the 6LoWPAN Routing		included within the 6LoRHE. [RFC8138] specifies the 6LoWPAN Routing
	Header (6LoRH), compression schemes for RPL (Routing Protocol for		Header (6LoRH), compression schemes for RPL (Routing Protocol for
	Low-Power and Lossy Networks) routing (source routing) operation		Low-Power and Lossy Networks) source routing [RFC6554], header
	[RFC6554], header compression of RPL packet information [RFC6553],		compression of RPL packet information [RFC6553], and IP-in-IP
	and IP-in-IP encapsulation. This document also specifies the		encapsulation. This document also specifies the handling of the
	handling of the deadline time when packets traverse time-synchronized		deadline time when packets traverse time-synchronized networks
	networks operating in different time zones or distinct reference		operating in different time zones or distinct reference clocks.
	clocks. Time-synchronization techniques are outside the scope of		Time-synchronization techniques are outside the scope of this
	this document. There are a number of standards available for this		document. There are a number of standards available for this
	purpose, including IEEE 1588 [IEEE.1588.2008], IEEE 802.1AS		purpose, including IEEE 1588 [IEEE.1588.2008], IEEE 802.1AS
	[IEEE.802.1AS.2011], IEEE 802.15.4-2015 Time-Slotted Channel Hopping		[IEEE.802.1AS.2011], IEEE 802.15.4-2015 Time-Slotted Channel Hopping
	(TSCH) [IEEE.802.15.4], and more.		(TSCH) [IEEE.802.15.4], and more.
	The Deadline-6LoRHE can be used in any time-synchronized 6lo (IPv6		The Deadline-6LoRHE can be used in any time-synchronized 6LoWPAN
	over Networks of Resource-constrained Nodes) network. A 6TiSCH (IPv6		network. A 6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4) network
	over the TSCH mode of IEEE 802.15.4) network is used to describe the		is used to describe the implementation of the Deadline-6LoRHE, but
	implementation of the Deadline-6LoRHE, but this does not preclude its		this does not preclude its use in scenarios other than 6TiSCH. For
	use in scenarios other than 6TiSCH. For instance, there is a growing		instance, there is a growing interest in using 6LoWPAN over a
	interest in using 6lo over a Bluetooth Low Energy (BLE) mesh network		Bluetooth Low Energy (BLE) mesh network [6LO-BLEMESH] in industrial
	[6LO-BLEMESH] in industrial IoT [IEEE-BLE-MESH]. BLE mesh time		IoT (Internet of Things) [IEEE-BLE-MESH]. BLE mesh time
	synchronization is being explored by the Bluetooth community. There		synchronization is being explored by the Bluetooth community. There
	are also cases under consideration in Wi-SUN [PHY-SPEC] [Wi-SUN].		are also cases under consideration in Wi-SUN [PHY-SPEC] [Wi-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
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	skipping to change at line 176 ¶		skipping to change at line 177 ¶
	nodes within the network should process the Deadline-6LoRHE. The DT		nodes within the network should process the Deadline-6LoRHE. The DT
	and OTD packets are represented in time units determined by a scaling		and OTD packets are represented in time units determined by a scaling
	parameter in the Routing Header. The Network ASN (Absolute Slot		parameter in the Routing Header. The Network ASN (Absolute Slot
	Number) can be used as a time unit in a time-slotted synchronized		Number) can be used as a time unit in a time-slotted synchronized
	network (for instance, a 6TiSCH network, where global time is		network (for instance, a 6TiSCH network, where global time is
	maintained in the units of slot lengths of a certain resolution).		maintained in the units of slot lengths of a certain resolution).
	The delay experienced by packets in the network is a useful metric		The delay experienced by packets in the network is a useful metric
	for network diagnostics and performance monitoring. Whenever a		for network diagnostics and performance monitoring. Whenever a
	packet crosses into a network using a different reference clock, the		packet crosses into a network using a different reference clock, the
	DT field is updated to represent the same destination time, but		DT field is updated to represent the same deadline time, but
	expressed using the reference clock of the interface into the new		expressed using the reference clock of the interface into the new
	network. Then the origination time is the same as the current time		network. Then the origination time is the same as the current time
	when the packet is transmitted into the new network, minus the delay		when the packet is transmitted into the new network, minus the delay
	already experienced by the packet, say 'current_dly'. In this way,		already experienced by the packet, say 'current_dly'. In this way,
	within the newly entered network, the packet will appear to have		within the newly entered network, the packet will appear to have
	originated 'current_dly' time units earlier with respect to the		originated 'current_dly' time units earlier with respect to the
	reference clock of the new network.		reference clock of the new network.
	new_network_origin_time = time_now_in_new_network - current_dly		new_network_origin_time = time_now_in_new_network - current_dly
	skipping to change at line 226 ¶		skipping to change at line 227 ¶
	v v v		v v v
	dly0 = 0 dly1 = T1D-OT1 dly2 = T2D-OT2		dly0 = 0 dly1 = T1D-OT1 dly2 = T2D-OT2
	= 100-50 = 1400 - 950		= 100-50 = 1400 - 950
	= 50 = 450		= 50 = 450
	OT1 = T1A-dly0 OT2 = T2A-dly1 OT3 = T3A-dly2		OT1 = T1A-dly0 OT2 = T2A-dly1 OT3 = T3A-dly2
	= 50 = 1000-50 = 5000 - 450		= 50 = 1000-50 = 5000 - 450
	= 950 = 4550		= 950 = 4550
	Figure 2: Destination Time Update Example		Figure 2: Deadline Time Update Example
	There are multiple ways that a packet can be delayed, including		There are multiple ways that a packet can be delayed, including
	queuing delay, Media Access Control (MAC) layer contention delay,		queuing delay, Media Access Control (MAC) layer contention delay,
	serialization delay, and propagation delay. Sometimes there are		serialization delay, and propagation delay. Sometimes there are
	processing delays as well. For the purpose of determining whether or		processing delays as well. For the purpose of determining whether or
	not the deadline has already passed, these various delays are not		not the deadline has already passed, these various delays are not
	distinguished.		distinguished.
	5. Deadline-6LoRHE Format		5. Deadline-6LoRHE Format
	skipping to change at line 288 ¶		skipping to change at line 289 ¶
	encoding the length of the field in hex digits. If OTL == 0, the		encoding the length of the field in hex digits. If OTL == 0, the
	OTD field is not present. The value of OTL MUST NOT exceed the		OTD field is not present. The value of OTL MUST NOT exceed the
	value of DTL plus one.		value of DTL plus one.
	For example, DTL = 0b0000 means the DT field in the 6LoRHE is 1		For example, DTL = 0b0000 means the DT field in the 6LoRHE is 1
	hex digit (4 bits) long. OTL = 0b111 means the OTD field is 7 hex		hex digit (4 bits) long. OTL = 0b111 means the OTD field is 7 hex
	digits (28 bits) long.		digits (28 bits) long.
	BinaryPt (6 bits): If zero, the number of bits of the integer part		BinaryPt (6 bits): If zero, the number of bits of the integer part
	the DT is equal to the number of bits of the fractional part of		the DT is equal to the number of bits of the fractional part of
	the DT. If nonzero, the BinaryPt is a signed integer determining		the DT. If nonzero, the BinaryPt is a (2's complement) signed
	the position of the binary point within the value for the DT:		integer determining the position of the binary point within the
			value for the DT. This allows BinaryPt to be within the range
			[-32,31].
	* If BinaryPt value is positive, then the number of bits for the		* If BinaryPt value is positive, then the number of bits for the
	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.
	DT Value (8..64 bits): An unsigned integer of DTL+1 hex digits		DT Value (4..64 bits): An unsigned integer of DTL+1 hex digits
	giving the deadline time value.		giving the DT value.
	OTD Value (4..28 bits): An unsigned integer of OTL hex digits giving		OTD Value (4..28 bits): If present, an unsigned integer of OTL hex
	the Origination Time as a negative offset from the DT value.		digits 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
	determines how many time bits are needed to represent the difference		determines how many time bits are needed to represent the difference
	between the time at which the packet is launched and the deadline		between the time at which the packet is launched and the deadline
	skipping to change at line 346 ¶		skipping to change at line 350 ¶
	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 (i.e., Epoch_Range(DTL) = 16^1) for any		RTUs within the Epoch_Range (i.e., Epoch_Range(DTL) = 16^1) for any
	TU. The values that can be represented in the current epoch are in		TU. The values that can be represented in the current epoch are in
	the range [0, (Epoch_Range(DTL) - 1)].		the range [0, (Epoch_Range(DTL) - 1)].
	Assuming wraparound does not occur, OT is represented by the value		Assuming wraparound does not occur, OT is represented by the value
	(OT mod Epoch_Range), and DT is represented by the value (DT mod		(OT mod Epoch_Range), and DT is represented by the value (DT mod
	Epoch_Range). All arithmetic is to be performed modulo		Epoch_Range). All arithmetic is to be performed modulo
	(Epoch_Range(DTL)), yielding only positive values for DT - OT.		(Epoch_Range(DTL)), yielding only positive values for DT - OT.
			In order to allow fine-grained control over the setting of the
			deadline time, the fields for DT and OTD use fractional seconds.
			This is done by specifying a binary point, which allocates some of
			the bits for fractional times. Thus, all such fractions are
			restricted to be negative powers of 2. Each point of time between OT
			and DT is then represented by a time unit (either seconds or ASNs)
			and a fractional time unit.
			Let OT_abs, DT_abs, and CT_abs denote the true (absolute) values (on
			the synchronized timelines) for OT, DT, and current time. Let N be
			the number of bits to be used to represent the integer parts of
			OT_abs, DT_abs, and CT_abs:
			N = {4*(DTL+1)/2} + BinaryPt
			The originating node has to pick a segment size (2^N) so that DT_abs
			- OT_abs < 2^N, and so that intermediate network nodes can detect
			whether or not CT_abs > DT_abs.
			Given a value for N, the value for DT is represented in the deadline-
			time format by DT = (DT_abs mod 2^N). DT is typically represented as
			a positive value (even though negative modular values make sense).
			Also, let OT = OT_abs mod 2^N and CT = CT_abs mod 2^N, where both OT
			and CT are also considered as non-negative values.
			When the packet is launched by the originating node, CT_abs == OT_abs
			and CT == OT. Given a particular value for N, then in order for
			downstream nodes to detect whether or not the deadline has expired
			(i.e., whether DT_abs > CT_abs), the following is required:
			Assumption 1: DT_abs - OT_abs < 2^N.
			Otherwise the ambiguity inherent in the modulus arithmetic yielding
			OT and DT will cause failure: one cannot measure time differences
			greater than 2^N using numbers in a time segment of length less than
			2^N.
			Under Assumption 1, downstream nodes must effectively check whether
			or not their current time is later than the DT -- but the value of
			the DT has to be inferred from the value of DT in the 6LoRHE, which
			is a number less than 2^N. This inference cannot be expected to
			reliably succeed unless Assumption 1 is valid, which means that the
			originating node has to be careful to pick proper values for DTL and
			for BinaryPt.
			Since OT is not necessarily provided in the 6loRHE, there may be a
			danger of ambiguity. Surely, when DT = CT, the deadline time is
			expiring and the packet should be dropped. However, what if an
			intermediate node measures that CT = DT+1? Was the packet launched a
			short time before arrival at the intermediate node, or has the
			current time wrapped around so that CT_abs - OT_abs > 2^N?
			In order to solve this problem, a safety margin has to be provided,
			in addition to requiring that DT_abs - OT_abs < 2^N. The value of
			this safety margin is proportional to 2^N and is determined by a new
			parameter, called the "SAFETY_FACTOR". Then, for safety the
			originating node MUST further ensure that (DT_abs - OT_abs) <
			2^N*(1-SAFETY_FACTOR).
			Each intermediate node that receives the packet with the Deadline-
			6LoRHE must determine whether ((CT - DT) mod 2^N) >
			SAFETY_FACTOR*2^N. If this test condition is not satisfied, the
			deadline time has expired. See Appendix A for more explanation about
			the test condition. All nodes that receive a packet with a Deadline-
			6LoRHE included MUST use the same value for the SAFETY_FACTOR. The
			SAFETY_FACTOR is to be chosen so that a packet with the Deadline-
			6LoRHE included will be tested against the current time at least once
			during every subinterval of length SAFETY_FACTOR*2^N. In this way,
			it can be guaranteed that the packet will be tested often enough to
			make sure it can be dropped whenever CT_abs > DT_abs. The value of
			SAFETY_FACTOR is specified in this document to be 20%.
	Example: Consider a 6TiSCH network with time-slot length of 10 ms.		Example: Consider a 6TiSCH network with time-slot length of 10 ms.
	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 line 427 ¶		skipping to change at line 503 ¶
	| (A) (B) : (E) : R |		| (A) (B) : (E) : R |
	| /|\ | \ / \ |		| /|\ | \ / \ |
	| S : : : : : : v		| S : : : : : : v
	Figure 5: Endpoints within the Same DODAG (Subnet N1)		Figure 5: Endpoints within the Same DODAG (Subnet N1)
	At the tunnel endpoint of the encapsulation, the Deadline-6LoRHE is		At the tunnel endpoint of the encapsulation, the Deadline-6LoRHE is
	copied back from the outer header to inner header, and the inner IP		copied back from the outer header to inner header, and the inner IP
	packet is delivered to 'R'.		packet is delivered to 'R'.
	6.2. Scenario 2: Endpoints in Networks with Dissimilar Layer 2		6.2. Scenario 2: Endpoints in Networks with Dissimilar L2 Technologies
	Technologies
	In Scenario 2, shown in Figure 6, the Sender 'S' (belonging to DODAG		In Scenario 2, shown in Figure 6, the Sender 'S' (belonging to DODAG
	1) has an IP datagram to be routed to a Receiver 'R' over a time-		1) has an IP datagram to be routed to a Receiver 'R' over a time-
	synchronized IPv6 network. For the route segment from 'S' to 6LBR,		synchronized IPv6 network. For the route segment from 'S' to 6LBR,
	'S' includes a Deadline-6LoRHE. Subsequently, each 6LR will perform		'S' includes a Deadline-6LoRHE. Subsequently, each 6LR will perform
	hop-by-hop routing to forward the packet towards the 6LBR. Once the		hop-by-hop routing to forward the packet towards the 6LBR. Once the
	deadline time information reaches the 6LBR, the packet will be		deadline time information reaches the 6LBR, the packet will be
	encoded according to the mechanism prescribed in the other time-		encoded according to the mechanism prescribed in the other time-
	synchronized network depicted as "Time-Synchronized Network" in		synchronized network depicted as "Time-Synchronized Network" in
	Figure 6. The specific data encapsulation mechanisms followed in the		Figure 6. The specific data encapsulation mechanisms followed in the
	skipping to change at line 462 ¶		skipping to change at line 537 ¶
	Upward | | |		Upward | | |
	routing | +------++		routing | +------++
	| (F)/ /| \		| (F)/ /| \
	| / \ / | \		| / \ / | \
	| / \ (C) | (D)		| / \ (C) | (D)
	| (A) (B) | | / |\		| (A) (B) | | / |\
	| /|\ |\ : (E) : :		| /|\ |\ : (E) : :
	| S : : : : / \		| S : : : : / \
	: :		: :
	Figure 6: Packet Transmission in Dissimilar Layer 2 Technologies		Figure 6: Packet Transmission in Dissimilar L2 Technologies or
	or Internet		Internet
	For instance, the IP datagram could be routed to another time-		For instance, the IP datagram could be routed to another time-
	synchronized, deterministic network using the mechanism specified in		synchronized, deterministic network using the mechanism specified in
	In-situ Operations, Administration, and Maintenance (IOAM)		In-situ Operations, Administration, and Maintenance (IOAM)
	[IOAM-DATA], and then the deadline time would be updated according to		[IOAM-DATA], and then the deadline time would be updated according to
	the measurement of the current time in the new network.		the measurement of the current time in the new network.
	6.3. Scenario 3: Packet Transmission across Different DODAGs (N1 to N2)		6.3. Scenario 3: Packet Transmission across Different DODAGs (N1 to N2)
	Consider the scenario depicted in Figure 7, in which the Sender 'S'		Consider the scenario depicted in Figure 7, in which the Sender 'S'
	skipping to change at line 628 ¶		skipping to change at line 703 ¶
	[RFC9030].		[RFC9030].
	The security considerations of DetNet architecture [RFC8655]		The security considerations of DetNet architecture [RFC8655]
	(Section 5) mostly apply to this document as well, as follows. To		(Section 5) mostly apply to this document as well, as follows. To
	secure the request and control of resources allocated for tracks,		secure the request and control of resources allocated for tracks,
	authentication and authorization can be used for each device and		authentication and authorization can be used for each device and
	network controller devices. In the case of distributed control		network controller devices. In the case of distributed control
	protocols, security is expected to be provided by the security		protocols, security is expected to be provided by the security
	properties of the protocols in use.		properties of the protocols in use.
	When deadline-bearing flows are identified on a per-flow basis, which		The identification of deadline-bearing flows on a per-flow basis may
	may provide attackers with additional information about the data		provide attackers with additional information about the data flows
	flows, when compared to networks that do not include per-flow		compared to networks that do not include per-flow identification.
	identification. The security implications of disclosing that		The security implications of disclosing that additional information
	additional information deserve consideration when implementing this		deserve consideration when implementing this deadline specification.
	deadline specification.
	Because of the requirement of precise time synchronization, the		Because of the requirement of precise time synchronization, the
	accuracy, availability, and integrity of time synchronization is of		accuracy, availability, and integrity of time synchronization is of
	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. References		10. References
	10.1. Normative References		10.1. Normative References
	skipping to change at line 755 ¶		skipping to change at line 829 ¶
	2011, <https://doi.org/10.1109/IEEESTD.2011.5741898>.		2011, <https://doi.org/10.1109/IEEESTD.2011.5741898>.
	[IOAM-DATA]		[IOAM-DATA]
	Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields		Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields
	for In-situ OAM", Work in Progress, Internet-Draft, draft-		for In-situ OAM", Work in Progress, Internet-Draft, draft-
	ietf-ippm-ioam-data-12, 21 February 2021,		ietf-ippm-ioam-data-12, 21 February 2021,
	<https://tools.ietf.org/html/draft-ietf-ippm-ioam-data-		<https://tools.ietf.org/html/draft-ietf-ippm-ioam-data-
	12>.		12>.
	[PHY-SPEC] Wi-SUN Alliance, "Wi-SUN PHY Specification V1.0", March		[PHY-SPEC] Wi-SUN Alliance, "Wi-SUN PHY Specification V1.0", March
	2016.		2016, <http://wi-sun.org>.
	[RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases",		[RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases",
	RFC 8578, DOI 10.17487/RFC8578, May 2019,		RFC 8578, DOI 10.17487/RFC8578, May 2019,
	<https://www.rfc-editor.org/info/rfc8578>.		<https://www.rfc-editor.org/info/rfc8578>.
	[RFC8929] Thubert, P., Ed., Perkins, C.E., and E. Levy-Abegnoli,		[RFC8929] Thubert, P., Ed., Perkins, C.E., and E. Levy-Abegnoli,
	"IPv6 Backbone Router", RFC 8929, DOI 10.17487/RFC8929,		"IPv6 Backbone Router", RFC 8929, DOI 10.17487/RFC8929,
	November 2020, <https://www.rfc-editor.org/info/rfc8929>.		November 2020, <https://www.rfc-editor.org/info/rfc8929>.
	[RFC9008] Robles, M.I., Richardson, M., and P. Thubert, "Using RPI		[RFC9008] Robles, M.I., Richardson, M., and P. Thubert, "Using RPI
	skipping to change at line 778 ¶		skipping to change at line 852 ¶
	DOI 10.17487/RFC9008, April 2021,		DOI 10.17487/RFC9008, April 2021,
	<https://www.rfc-editor.org/info/rfc9008>.		<https://www.rfc-editor.org/info/rfc9008>.
	[Wi-SUN] Harada, H., Mizutani, K., Fujiwara, J., Mochizuki, K.,		[Wi-SUN] 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, Issue 7, pp. 1032-1043,		Communications, Volume E100.B, Issue 7, pp. 1032-1043,
	DOI 10.1587/transcom.2016SCI0002, January 2017,		DOI 10.1587/transcom.2016SCI0002, January 2017,
	<https://doi.org/10.1587/transcom.2016SCI0002>.		<https://doi.org/10.1587/transcom.2016SCI0002>.
			Appendix A. Modular Arithmetic Considerations
			Graphically, one might visualize the timeline as follows:
			OT_abs CT_abs DT_abs
			-------|-------------|-------------|------------------>
			Figure 8: Absolute Timeline Representation
			In Figure 8, the value of CT_abs is envisioned as traveling to the
			right as time progresses, getting farther away from OT_abs and
			getting closer to DT_abs. The timeline is considered to be
			subdivided into time subintervals [i,j] starting and ending at
			absolute times equal to k*(2^N), for integer values of k. Let I_k =
			k*(2^N) and I_(k+1) = (k+1)*2^N. Intervals starting at I_k and
			I_(k+1) may occur at various placements in the above timeline. Even
			though OT_abs is _always_ less than DT_abs, it could be that DT < OT
			because of the way that DT and OT are represented within the range
			[0, 2^N) and similarly for CT_abs and CT compared to OT and DT.
			Representing the above situation in time segments of length 2^N (and
			values OT, CT, DT) results in several cases where the deadline time
			has not elapsed:
			1) OT < CT < DT (e.g., I_k < OT_abs < CT_abs < DT_abs < I_(k+1) )
			2) DT < OT < CT (e.g., I_k < OT_abs < CT_abs < I_(k+1) < DT_abs )
			3) CT < DT < OT (e.g., I_k < OT_abs < I_(k+1) < CT_abs < DT_abs )
			In the following cases, the deadline time has elapsed and the packet
			should be dropped.
			4) DT < CT < OT
			5) OT < DT < CT
			6) CT < OT < DT
			Again in Figure 8, consider CT_abs as time moving away from OT_abs
			and towards DT_abs. For times CT_abs before the expiration of the
			deadline time, we also have CT_abs - OT_abs == CT - OT mod 2^N and
			similarly for DT_abs - CT_abs.
			As time proceeds, DT_abs - CT_abs gets smaller. When the deadline
			time expires, DT_abs - CT_abs begins to grow negative. A proper
			selection for SAFETY_FACTOR allows it to go _slightly negative_ but
			for an intermediate point to _detect_ that it has gone negative.
			Note that in modular arithmetic, "slightly negative" means _exactly_
			the same as "almost as large as the modulus (i.e., 2^N)". Now
			consider the test condition ((CT - DT) mod 2^N) > SAFETY_FACTOR*2^N.
			(DT_abs - OT_abs) < 2^N*(1-SAFETY_FACTOR) satifies the test condition
			when CT_abs == OT_abs (i.e., when the packet is launched). In
			modular arithmetic, 2^N*(1-SAFETY_FACTOR) == 2^N - 2^N*SAFETY_FACTOR
			== -2^N*(SAFETY_FACTOR). Then DT_abs - OT_abs <
			-2^N*(1-SAFETY_FACTOR). Inverting the inequality, OT_abs - DT_abs >
			2^N*(1-SAFETY_FACTOR), and thus at launch CT_abs - DT_abs >
			2^N*(1-SAFETY_FACTOR).
			As CT_abs grows larger, CT_abs - DT_abs gets LARGER in (non-negative)
			modular arithmetic until the time at which CT_ABS == DT_ABS, and
			suddenly CT_ABS - DT_abs becomes zero. Also suddenly, the test
			condition is no longer fulfilled.
			As CT_abs grows still larger, CT_abs > DT_abs, and we need to detect
			this condition as soon as possible. Requiring the SAFETY_FACTOR
			enables this detection until CT_abs exceeds DT_abs by an amount equal
			to SAFETY_FACTOR*2^N.
			A note about "inverting the inequality". Observe that a < b implies
			that -a > -b on the real number line. Also, (a - b) == -(b - a).
			These facts hold also for modular arithmetic.
			During the times prior to the expiration of the deadline, for Safe =
			2^N*SAFETY_FACTOR we have:
			(DT_abs - 2^N) < OT_abs < CT_abs < DT_abs < DT_abs+Safe
			Naturally, DT_abs - 2^N == DT_abs mod 2^N == DT.
			Again considering Figure 8, it is easy to see that {CT_abs - (DT_abs
			- 2^N)} gets larger and larger until the time at which CT_abs =
			DT_abs, which is the first time at which CT - DT == 0 mod 2^N. As
			CT_abs increases past the deadline time, 0 < CT_abs - DT_abs < Safe.
			In this range, any intermediate node can detect that the deadline has
			expired. As CT_abs increases past DT_abs+Safe, it is no longer
			possible for an intermediate node to determine with certainty whether
			or not the deadline time has expired. These statements also apply
			when reduced to modular arithmetic in the modulus 2^N.
			In particular, the test condition no longer allows detection of
			deadline expiration when the current time becomes later than
			(DT_abs+Safe). In order to maintain correctness even for packets
			that are forwarded after expiration (i.e., the 'D' flag), N has to be
			chosen to be so large that the test condition will not fail -- i.e.,
			that in all scenarios of interest, the packet will be dropped before
			the current time becomes equal to DT_abs+2^N*SAFETY_FACTOR.
	Acknowledgments		Acknowledgments
	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,		encouraging the work. Thanks to Shwetha Bhandari's suggestions,
	which were instrumental in extending the timing information to		which 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,		(Security Directorate), Seema Kumar, Tal Mizrahi, Avinash Mohan,
	Shalu Rajendran, Anita Varghese, and Dale Worley (General Area Review		Shalu Rajendran, Anita Varghese, and Dale Worley (General Area Review
	skipping to change at line 813 ¶		skipping to change at line 986 ¶
	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.ac.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.ac.in		Email: malati@iisc.ac.in
	Charles E. Perkins		Charles E. Perkins
	Futurewei		Lupin Lodge
	2330 Central Expressway		20600 Aldercroft Heights Rd.
	Santa Clara, CA 95050		Los Gatos, CA 95033
	United States of America		United States of America
	Email: charliep@computer.org		Email: charliep@computer.org
End of changes. 22 change blocks.
	49 lines changed or deleted		222 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/