< draft-ietf-6lo-deadline-time-03.txt   draft-ietf-6lo-deadline-time-04.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: April 18, 2019 SRM University-AP Expires: September 9, 2019 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
October 15, 2018 March 8, 2019
Packet Delivery Deadline time in 6LoWPAN Routing Header Packet Delivery Deadline time in 6LoWPAN Routing Header
draft-ietf-6lo-deadline-time-03 draft-ietf-6lo-deadline-time-04
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 delivery deadline time for data packets. The deadline containing the deadline time for data packets, designed for use over
time enables forwarding and scheduling decisions for time critical constrained networks. The deadline time enables forwarding and
IoT M2M applications that need deterministic delay guarantees over scheduling decisions for time critical IoT M2M applications that
constrained networks and operate within time-synchronized networks. operate within time-synchronized networks that agree on the meaning
of the time representations used for the deadline time values.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 April 18, 2019. This Internet-Draft will expire on September 9, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 25 skipping to change at page 2, line 26
3. 6LoRHE Generic Format . . . . . . . . . . . . . . . . . . . . 3 3. 6LoRHE Generic Format . . . . . . . . . . . . . . . . . . . . 3
4. Deadline-6LoRHE . . . . . . . . . . . . . . . . . . . . . . . 4 4. Deadline-6LoRHE . . . . . . . . . . . . . . . . . . . . . . . 4
5. Deadline-6LoRHE Format . . . . . . . . . . . . . . . . . . . 6 5. Deadline-6LoRHE Format . . . . . . . . . . . . . . . . . . . 6
6. Deadline-6LoRHE in Three Network Scenarios . . . . . . . . . 7 6. Deadline-6LoRHE in Three Network Scenarios . . . . . . . . . 7
6.1. Scenario 1: Endpoints in the same DODAG (N1) . . . . . . 8 6.1. Scenario 1: Endpoints in the same DODAG (N1) . . . . . . 8
6.2. Scenario 2: Endpoints in Networks with Dissimilar L2 6.2. Scenario 2: Endpoints in Networks with Dissimilar L2
Technologies. . . . . . . . . . . . . . . . . . . . . . . 9 Technologies. . . . . . . . . . . . . . . . . . . . . . . 9
6.3. Scenario 3: Packet transmission across different DODAGs 6.3. Scenario 3: Packet transmission across different DODAGs
(N1 to N2). . . . . . . . . . . . . . . . . . . . . . . . 10 (N1 to N2). . . . . . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Synchronization Aspects . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Changes from revision 02 to revision 03 . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix B. Changes from revision 01 to revision 02 . . . . . . 15 Appendix A. Changes from revision 03 to revision 04 . . . . . . 16
Appendix C. Changes between earlier versions . . . . . . . . . . 15 Appendix B. Changes from revision 03 to revision 04 . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Appendix C. Changes from revision 01 to revision 02 . . . . . . 17
Appendix D. Changes between earlier versions . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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
scheduling decisions to meet the time bounds. scheduling decisions to meet the time bounds.
The draft [I-D.ietf-roll-routing-dispatch] specifies the 6LoWPAN This document specifies a new type for the Elective 6LoWPAN Routing
Routing Header (6LoRH), compression schemes for RPL routing (source Header (6LoRHE), so that the deadline time (i.e., the time of latest
routing) operation [RFC6554], header compression of RPL Packet acceptable delivery) of data packets can be included within the
Information [RFC6553], and IP-in-IP encapsulation. This document 6LoWPAN routing header. [RFC8138] specifies the 6LoWPAN Routing
specifies a new Deadline-6LoRHE type for the 6LoWPAN Dispatch Page 1, Header (6LoRH), compression schemes for RPL routing (source routing)
so that the deadline time of data packets can be included within the operation [RFC6554], header compression of RPL Packet Information
6LoWPAN routing header. This document also specifies handling of the [RFC6553], and IP-in-IP encapsulation. This document also specifies
deadline time when packets traverse through time-synchronized handling of the deadline time when packets traverse between time-
networks operating in different timezones or distinct reference synchronized networks operating in different timezones or distinct
clocks. Time synchronization techniques need not be mandated by this reference clocks. Time synchronization techniques are outside the
specificiation. There are a number of standards available for this scope of this document. There are a number of standards available
purpose, including IEEE 1588 [ieee-1588], IEEE 802.1AS [dot1AS-2011], for this purpose, including IEEE 1588 [ieee-1588], IEEE 802.1AS
IEEE 802.15.4-2015 TSCH [dot15-tsch], and more. [dot1AS-2011], IEEE 802.15.4-2015 TSCH [dot15-tsch], and more.
The Deadline-6LoRHE can be used in any time synchronized 6Lo network. The Deadline-6LoRHE can be used in any time synchronized 6Lo network.
A 6TiSCH network has been used to describe the implementation of the A 6TiSCH network is used to describe the implementation of the
Deadline-6LoRHE, but this does not preclude its use in scenarios Deadline-6LoRHE, but this does not preclude its use in scenarios
other than 6TiSCH. For instance, there is a growing interest in other than 6TiSCH. For instance, there is a growing interest in
using 6lo over a BLE mesh network [I-D.ietf-6lo-blemesh] in using 6lo over a BLE mesh network [I-D.ietf-6lo-blemesh] in
industrial IoT [dotBLEMesh]. BLE mesh time synchronization is also industrial IoT [dotBLEMesh]. BLE mesh time synchronization is being
being recently explored by the Bluetooth community. There are also explored by the Bluetooth community. There are also cases under
cases under 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 terminology consistent with the terminology used This document uses the terminology defined in [RFC6550] and
in [RFC6550] and [I-D.ietf-6tisch-terminology]. Also, in this [I-D.ietf-6tisch-terminology].
document, the terms "expiration time", "delivery deadline time", and
"deadline" are used interchangeably with the same meaning.
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 4, line 5 skipping to change at page 4, line 5
|1|0|1| Length | Type | | |1|0|1| Length | Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
<-- length --> <-- length -->
Figure 1: 6LoRHE format Figure 1: 6LoRHE format
o Length: Length of the 6LoRHE expressed in bytes, excluding the 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 first 2 bytes. This enables a node to skip a 6LoRHE if the Type
is not recognized/supported. is not recognized/supported.
o Type: Type of the 6LoRHE. o Type (variable length): Type of the 6LoRHE (see Section 7)
o length: variable
4. Deadline-6LoRHE 4. Deadline-6LoRHE
The Deadline-6LoRHE (see Figure 3) is an elective 6LoRH (i.e., a The Deadline-6LoRHE (see Figure 3) is an elective 6LoRH (i.e., a
6LoRHE [RFC8138]) that provides the Deadline Time (DT) for an IPv6 6LoRHE [RFC8138]) that provides the Deadline Time (DT) for an IPv6
datagram in a compressed form. Along with the deadline, the header datagram in a compressed form. Along with the deadline, the header
can include the packet Origination Time (OT), the time at which the can include the packet Origination Time Delta (OTD), the time at
packet is enqueued for transmission, to enable a close estimate of which the packet is enqueued for transmission (expressed as a value
the total delay incurred by a packet. The OT field is initialized by to be subtracted from DT); this enables a close estimate of the total
the sender using the current time at the outgoing network interface delay incurred by a packet. The OTD field is initialized by the
through which the packet is forwarded. sender based on the current time at the outgoing network interface
through which the packet is forwarded. Since the OTD is a delta the
length of the OTD field (i.e., OTL) will require fewer bits than the
length of the DT field (i.e., DTL).
The deadline field contains the value of the delivery deadline time The deadline field contains the value of the deadline time for the
for the packet. The packet SHOULD be delivered to the Receiver packet. The packet SHOULD be delivered to the Receiver before this
before this time. time.
packet_deadline_time = packet_origination_time + max_delay packet_deadline_time = packet_origination_time + max_delay
All nodes within the network SHOULD process the Deadline-6LoRHE in All nodes within the network SHOULD process the Deadline-6LoRHE in
order to support delay-sensitive deterministic applications. The order to support delay-sensitive deterministic applications. The
packet deadline time (DT) and origination time (OT) are represented packet deadline time (DT) and origination time (OTD) are represented
in time units determined by a scaling parameter in the routing in time units determined by a scaling parameter in the routing
header. One of the time units is the Network ASN (Absolute Slot header. One of the time units is the Network ASN (Absolute Slot
Number) which can be used in case of a time slotted synchronized Number) which can be used in case of 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 the for network diagnostics and performance monitoring. Whenever a
packets crosses into a network using a different reference clock, the packet crosses into a network using a different reference clock, the
Origination Time field is updated to represent the same Origination Destination Time field is updated to represent the same Destination
Time, but expressed using the reference clock of the interface into Time, but expressed using the reference clock of the interface into
the new network. This is the same as the current time when the the new network. Then the origination time is the same as the
packet is transmitted into the new network, minus the delay already current time when the packet is transmitted into the new network,
experienced by the packet, say 't'. In this way, within the newly minus the delay already experienced by the packet, say 'dly'. In
entered network, the packet will appear to have originated 't' time this way, within the newly entered network, the packet will appear to
units earlier with respect to the reference clock of the new network. have originated 'dly' time units earlier with respect to the
reference clock of the new network.
Origination Time in new network = current_time_in_new_network - origination time in new network = current_time_in_new_network -
delay_already_experienced_in_previous_network(s) delay_already_experienced_in_previous_network(s)
The following example illustrates the origination time calculation The following example illustrates these calculations when a packet
when a packet travels between three networks, each in a different travels between three networks, each in a different time zone. 'x'
time zone. 'x' can be 1,2 or 3. can be 1, 2 or 3. Suppose that the deadline time as measured in
timezone 1 is 1050 and the origination time is 50. Suppose that the
difference between TZ2 and TZ1 is 900, and the the difference between
TZ3 and TZ3 is 3600. In the figure, OT is the origination time as
measured in the current timezone, and is equal to DT - OTD, that is,
DT - 1000. Figure 2 uses the following abbreviations:
TxA : Time of arrival of packet in the network 'x' TxA : Time of arrival of packet in the network 'x'
TxD : Departure time of packet from the network 'x' TxD : Departure time of packet from the network 'x'
Dx : Delay experienced by the packet in the previous network(s) dlyx : 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 TZx : The time zone of network 'x'
time synchronized networks along with numerical values as shown in
Figure 1.
TZ1 TZ2 TZ3 TZ1 TZ2 TZ3
T1A=0| | | T1A=50| | |
|---- D1=100 | | |---- dly1=50 | |
| \ | | | \ | |
| \ | | | \ | |
| \ T1D=100 |T2A=1000 | | \ T1D=100 |T2A=1000 |
| -------->|----- D2=400 | | -------->|----- dly2=450 |
| | \ | | | \ |
| | \ | | | \ |
| | \ T2D=1400 | T3A=5000 | | \ T2D=1400 | T3A=5000
| | ------------------->| | | ------------------->|---------->
| | | | | |
v v v v v v
D = 0 D = T1D-OT D = T2D-OT dly0 = 0 dly1 = T1D-OT1 dly2 = T2D-OT2
= 100-0 = 1400 - 900 = 100-50 = 1400 - 950
= 100 = 500 [= (D1 + D2)] = 50 = 450
OT = T1A-D OT = T2A-D OT = T3A-D OT1 = T1A-dly0 OT2 = T2A-dly1 OT3 = T3A-dly2
= 0 = 1000-100 = 5000 - 500 = 50 = 1000-50 = 5000 - 450
= 900 = 4500 = 950 = 4550
Figure 2: Origination Time update example Figure 2: Destination 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, MAC layer contention delay, serialization delay, and queuing delay, MAC layer contention delay, serialization delay, and
propagation delays. Sometimes there are processing delays as well. propagation delays. Sometimes there are processing delays as well.
For the purpose of determining whether or not the deadline has For the purpose of determining whether or not the deadline has
already passed, these various delays are not distinguished. already passed, these various delays are not distinguished.
5. Deadline-6LoRHE Format 5. Deadline-6LoRHE Format
0 1 2 3 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 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 | |1|0|1| Length | 6LoRH Type |D| TU| DTL | OTL | BinaryPt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DT (variable length) | OT(variable length)(optional) | | DT (variable length) | OTD(variable length)(optional)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Deadline-6LoRHE format Figure 3: Deadline-6LoRHE format
Length (5 bits): Length represents the total length of the Deadline- o Length (5 bits): Length represents the total length of the
6LoRHE type measured in octets. Deadline-6LoRHE type measured in octets.
o 6LoRH Type: TBD (see Section 7)
6LoRH Type: TBD o D flag (1 bit): The 'D' flag, set by the Sender, qualifies the
action to be taken when a 6LR detects that the deadline time has
O flag (1bit): Indicates the presence of Origination Time field. '1' elapsed. If 'D' bit is 1, then the 6LR MUST drop the packet if
means the OT field is present, and '0' means it is absent. the deadline time is elapsed. If 'D' bit is 0, the packet MAY be
forwarded on an exception basis, if the forwarding node is NOT in
D flag (1 bit): The 'D' flag, set by the Sender, indicates the action a situation of constrained resource, and if there are reasons to
to be taken when a 6LR detects that the deadline time has elapsed. suspect that downstream nodes might find it useful (delay
If 'D' bit is 1, then the 6LR MUST drop the packet if the deadline measurements, interpolations, etc.).
time is elapsed. o DTL (4 bits): Length of DT field as an unsigned 4-bit integer,
encoding the length of the field in hex digits, minus one.
If 'D' bit is 0, implies the packet MAY be forwarded on an exception o OTL (3 bits) : Length of OTD field as an unsigned 3-bit integer,
basis, if the forwarding node is NOT in a situation of constrained encoding the length of the field in hex digits. If OTL == 0, the
resource, and if there are reasons to suspect that downstream nodes OTD field is not present. The value of OTL MUST NOT exceed the
might find it useful (delay measurements, interpolations, etc.). value of DTL plus one.
DTL (3 bits): Length of DT field as an unsigned 3-bit integer,
encoding the length of the field in octets, minus one.
OTL (3 bits) : Length of OT field as an unsigned 3-bit integer,
encoding the length of the field in octets, minus one.
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. * For example, DTL = 0b0000 means the deadline time in the 6LoRHE
is 1 hex digit (4 bits) long. OTL = 0b111 means the
origination time is 7 hex digits (28 bits) long.
o TU (2 bits) : Indicates the time units for DT and OTD fields. The
encoding for the DT and OTD fields MUST always use the same time
units and precision.
The value of the DT field is multiplied by 10 to this power, to * 00 : Time represented in seconds and fractional seconds
get the actual deadline time in the units represented by TU. The * 01 : Reserved
default value of EXP is 000, so that the DT field is unaffected. * 10 : Network ASN
* 11 : Reserved
o Binary Pt (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. if nonzero, the Binary Pt is a signed integer
determining the position of the binary point within the value for
the DT.
Rsv (3 bits) : Reserved, sent as zero and ignored on receipt * If BinaryPt value is positive, then the number of bits for the
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
correspondingly reduced. This increases the range of DT.
* If BinaryPt value is negative, then the number of bits for the
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
correspondingly increased. This increases the precision of the
fractional seconds part of DT.
o DT Value (8..64-bit) : An unsigned integer of DTL+1 hex digits
giving the Deadline Time value
o OTD Value (8..64-bit) : An unsigned integer of OTL hex digits
giving the Origination Time as a negative offset from the DT value
DT Value (8..64-bit) : An unsigned integer of DTL octets giving the Whenever a sender initiates the IP datagram, it includes the
Deadline Time value Deadline-6LoRHE along with other 6LoRH information. For information
about the time synchronization requirements between sender and
receiver see Section 8.
OT Value (8..64-bit) : An unsigned integer of OTL octets giving the Example: Consider a 6TiSCH network with time-slot length of 10ms.
Origination Time value Let the time units be ASNs (TU == (binary)0b10). Let the current
ASN when the packet is originated be 54400, and the maximum
allowable delay (max_delay) for the packet delivery be 1 second
from the packet origination, then:
Whenever a sender initiates the IP datagram, it includes the deadline_time = packet_origination_time + max_delay
Deadline-6LoRHE along with other 6LoRH information.
Example: Consider a 6TiSCH network with time-slot length of 10ms. = 0xD480 + 0x64 (Network ASNs)
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 = 0xD4E4 (Network ASNs)
= 55400 + 100 (in Network ASNs)
= 55500(Network ASNs)
Deadline-6LoRHE encoding with 'O' flag and 'D' flag set to 1: Then, the Deadline-6LoRHE encoding with nonzero OTL is:
DTL = 001, OTL = 001, TU = '10', EXP = 2, DT = 0x22B, OT = 0x22A DTL = 3, OTL = 2, TU = 0b10, BinaryPt = 8, DT = 0xD4E4, OTD
= 0x64
6. Deadline-6LoRHE in Three Network Scenarios 6. Deadline-6LoRHE in Three Network Scenarios
In this section, Deadline-6LoRHE operation is described for 3 network In this section, Deadline-6LoRHE operation is described for 3 network
scenarios. Figure 4 depicts a constrained time-synchronized LLN that scenarios. Figure 4 depicts a constrained time-synchronized LLN that
has two subnets N1 and N2, connected through LBRs has two subnets N1 and N2, connected through LBRs
[I-D.ietf-6lo-backbone-router] with different reference clock times [I-D.ietf-6lo-backbone-router] with different reference clock times
T1 and T2. T1 and T2.
+-------------------+ +-------------------+
skipping to change at page 9, line 9 skipping to change at page 9, line 9
a IPv6-in-IPv6 encapsulated packet when sending the packet downwards a IPv6-in-IPv6 encapsulated packet when sending the packet downwards
to the Receiver [I-D.ietf-roll-useofrplinfo]. The 6LBR copies the to the Receiver [I-D.ietf-roll-useofrplinfo]. The 6LBR copies the
Deadline-6LoRHE from the Sender originated IP header to the outer IP Deadline-6LoRHE from the Sender originated IP header to the outer IP
header. The Deadline-6LoRHE contained in the inner IP header is header. The Deadline-6LoRHE contained in the inner IP header is
removed. removed.
+-------+ +-------+
^ | 6LBR | | ^ | 6LBR | |
| | | | | | | |
| +-------+ | | +-------+ |
Upward | (F)/ /| \ | Downward Upward | / /| \ | Downward
routing | / \ / | \ | routing routing | (F) / | \ | routing
| / \ (C) | (D) | | / \ (C) | (D) |
| (A) (B) / | / |\ | | / \ | | / |\ |
| /|\ |\: (E) : R | | (A) (B) : (E) : R |
S : : : / \ v | /|\ | \ / \ |
| S : : : : : : v
Figure 5: End points within same DODAG (subnet N1) Figure 5: End points within same DODAG (subnet N1)
At the tunnel endpoint of the IPv6-in-IPv6 encapsulation, the At the tunnel endpoint of the encapsulation, the Deadline-6LoRHE is
Deadline-6LoRHE is copied back from the outer header to inner header, copied back from the outer header to inner header, and the inner IP
and the inner IP packet is delivered to 'R'. packet is delivered to 'R'.
6.2. Scenario 2: Endpoints in Networks with Dissimilar L2 Technologies. 6.2. Scenario 2: Endpoints in Networks with Dissimilar L2 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 IP datagram to be routed to a Receiver 'R' over a time- 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, 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 border router, the packet will Deadline Time information reaches the border router, the packet will
be encoded according to the mechanism prescribed in the other time- be encoded according to the mechanism prescribed in the other time-
skipping to change at page 10, line 21 skipping to change at page 10, line 21
| |
----------+----------- ----------+-----------
^ | ^ |
| +---+---+ | +---+---+
| | 6LBR | | | 6LBR |
Upward | | | Upward | | |
routing | +------++ routing | +------++
| (F)/ /| \ | (F)/ /| \
| / \ / | \ | / \ / | \
| / \ (C) | (D) | / \ (C) | (D)
: (A) (B) / | / |\ | (A) (B) | | / |\
/|\ |\: (E) :: | /|\ |\ : (E) : :
S : : : / \ | S : : : : / \
: : : :
Figure 6: Packet transmission in Dissimilar L2 Technologies or Figure 6: Packet transmission in Dissimilar L2 Technologies 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
the In-band OAM [I-D.ietf-ippm-ioam-data], and then the deadline time the In-band OAM [I-D.ietf-ippm-ioam-data], and then the deadline time
would be updated according to the measurement of the current time in would be updated according to the measurement of the current time in
the new network. the new network.
skipping to change at page 11, line 15 skipping to change at page 11, line 15
Time Synchronized Network Time Synchronized Network
-+---------------------------+- -+---------------------------+-
| | | |
DODAG1 +---+---+ +---+---+ DODAG2 DODAG1 +---+---+ +---+---+ DODAG2
| 6LBR1 | | 6LBR2 | | 6LBR1 | | 6LBR2 |
| | | | | | | |
+-------+ +-------+ +-------+ +-------+
(F)/ /| \ (F)/ /| \ (F)/ /| \ (F)/ /| \
/ \ / | \ / \ / | \ / \ / | \ / \ / | \
/ \ (C) | (D) / \ (C) | (D) / \ (C) | (D) / \ (C) | (D)
(A) (B) / | / |\ (A) (B) / | / |\ (A) (B) | | / |\ (A) (B) | | |\
/|\ |\: (E) : : /|\ |\: (E) : : /|\ |\ : (E) : : /|\ |\ : (E) : :
S : : : / \ : : : : / \ S : : : : / \ : : : : : / \
: : : R : : : R
Network N1, time zone T1 Network N2, time zone T2 Network N1, time zone T1 Network N2, time zone T2
Figure 7: Packet transmission in different DODAGs(N1 to N2) Figure 7: Packet transmission in different DODAGs(N1 to N2)
Consider an example of a 6TiSCH network in which S in DODAG1 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 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 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 DODAG2 is assumed to be 10ms. Once the deadline time is encoded in
Deadline-6LoRHE, the packet is forwarded to 6LBR of DODAG1. Suppose Deadline-6LoRHE, the packet is forwarded to 6LBR of DODAG1. Suppose
skipping to change at page 11, line 39 skipping to change at page 11, line 39
current_time = ASN at LBR * slot_length_value current_time = ASN at LBR * slot_length_value
remaining_time = deadline_time - current_time remaining_time = deadline_time - current_time
= ((packet_origination_time + max_delay) - current time) = ((packet_origination_time + max_delay) - current time)
= (20000 + 100) - 20030 = (20000 + 100) - 20030
= 30 (in Network ASNs) = 30 (in Network ASNs)
= 30 * 10^3 milliseconds. = 30 * 10^3 milliseconds.
Once the Deadline Time information reaches the border router, the Once the Deadline Time information reaches the border router, the
packet will be encoded accoding to the mechanism prescribed in the packet will be encoded according to the mechanism prescribed in the
other time-synchronized network. other time-synchronized network.
7. IANA Considerations 7. IANA Considerations
This document defines a new Elective 6LoWPAN Routing Header Type, and This document defines a new Elective 6LoWPAN Routing Header Type, and
IANA is requested to assign a value (TBD) from the 6LoWPAN Dispatch IANA is requested to assign a value (TBD) from the 6LoWPAN Dispatch
Page1 number space for this purpose. Page1 number space for this purpose.
Elective 6LoRH Type Value Elective 6LoRH Type Value
+----------------------+--------+ +----------------------+--------+
| Deadline-6LoRHE | TBD | | Deadline-6LoRHE | TBD |
+----------------------+--------+ +----------------------+--------+
Figure 8: Deadline-6LoRHE type Figure 8: Deadline-6LoRHE type
8. Security Considerations 8. Synchronization Aspects
The document supports time representation of the deadline and
origination times carried in the packets traversing through networks
of different time zones having different time synchronization
mechanisms. For instance, in a 6TiSCH network where the time is
maintained as ASN time slots, the time synchronization is achieved
through beaconing among the nodes as described in [RFC7554]. There
could be 6lo networks that employ NTP where the nodes are
synchronized with an external reference clock from an NTP server.
The specification of the time synchronization method that need to be
followed by a network is beyond the scope of the document.
The number of hex digits chosen to represent DT, and the portion of
that field allocated to represent integer number of seconds,
determines the meaning of t_0, i.e., the meaning of DT == 0 in the
chosen representation. If DTL == 0, then there are only 4 bits that
can be used to count the time units, so that DT == 0 can never be
more than 16 time units in the past. This then requires that the
time synchronization between sender and receiver has to be tighter
than 16 time units. If the binary point were moved so that all the
bits were used for fractional time units (e.g., fractional seconds or
fractional ASNs), the time synchronization requirement would be
correspondingly tighter.
A 4-bit field for DT allows up to 16 hex digits, which is 64 bits.
That is enough to represent the NTP [RFC5905] 64-bit timestamp
format, which is more than enough for the purposes of establishing
deadline times. Unless the binary point is moved, this is enough to
represent time since year 1900.
For example, suppose that DTL = 0b0000 and the DT bits are split
evenly; then we can count up to 3 integer seconds. In that case t_0
would be the most recent second of the current minute that has
t mod 4 == 0. In other words, t_0 could be 0, 4, 8, 12, 16, ..., 52,
or 56 seconds since the start of the most recent minute. The
networks have to be synchronized well enough to ensure detection of
overrun, and therefore to know which of those values is the correct
value for t_0. This is the hardest case.
If DT = 3 and the DT bits are again split evenly, then we can count
up to 4,096 seconds. t_0 would be the start of the most recent hour.
For TU = 0b00, the time units are seconds. With DTL == 15, and
Binary Pt == 0, the epoch is (by default) January 1, 1900 at 00:00
UTC. The resolution is then (2 ^ (- 32)) seconds, which is the
maximum possible. This time format wraps around every 2^32 seconds,
which is roughly 136 years. For other choices of DTL and the Binary
Pt, the value of t_0 (i.e., the meaning of DT == 0) needs to be
established by means out of scope of this document.
For TU = 0b10, the time units are ASNs. The start time is relative,
and updated by a mechanism out of scope for this document. With 10
ms slots, DTL = 15, and Binary Pt == 0, it would take over a year for
the ASN to wrap around. Typically, the number of hex digits
allocated for TU = 0b10 would be less than 15.
9. Security Considerations
The security considerations of [RFC4944], [RFC6282] and [RFC6553] The security considerations of [RFC4944], [RFC6282] and [RFC6553]
apply. Using a compressed format as opposed to the full in-line apply. Using a compressed format as opposed to the full in-line
format is logically equivalent and does not create an opening for a format is logically equivalent and does not create an opening for a
new threat when compared to [RFC6550], [RFC6553] and [RFC6554]. new threat when compared to [RFC6550], [RFC6553] and [RFC6554].
9. 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, Seema Kumar, Avinash Mohan, Shalu Rajendran and Anita Jerry Daniel, Seema Kumar, Avinash Mohan, Shalu Rajendran and Anita
Varghese for their support and valuable feedback. Varghese for their support and valuable feedback.
10. References 11. References
10.1. Normative References 11.1. Normative References
[I-D.ietf-6tisch-terminology] [I-D.ietf-6tisch-terminology]
Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
"Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e", "Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e",
draft-ietf-6tisch-terminology-10 (work in progress), March draft-ietf-6tisch-terminology-10 (work in progress), March
2018. 2018.
[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-
skipping to change at page 13, line 5 skipping to change at page 14, line 15
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<https://www.rfc-editor.org/info/rfc4944>. <https://www.rfc-editor.org/info/rfc4944>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011, DOI 10.17487/RFC6282, September 2011,
<https://www.rfc-editor.org/info/rfc6282>. <https://www.rfc-editor.org/info/rfc6282>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550, Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012, DOI 10.17487/RFC6550, March 2012,
skipping to change at page 13, line 29 skipping to change at page 14, line 44
Information in Data-Plane Datagrams", RFC 6553, Information in Data-Plane Datagrams", RFC 6553,
DOI 10.17487/RFC6553, March 2012, DOI 10.17487/RFC6553, March 2012,
<https://www.rfc-editor.org/info/rfc6553>. <https://www.rfc-editor.org/info/rfc6553>.
[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
Routing Header for Source Routes with the Routing Protocol Routing Header for Source Routes with the Routing Protocol
for Low-Power and Lossy Networks (RPL)", RFC 6554, for Low-Power and Lossy Networks (RPL)", RFC 6554,
DOI 10.17487/RFC6554, March 2012, DOI 10.17487/RFC6554, March 2012,
<https://www.rfc-editor.org/info/rfc6554>. <https://www.rfc-editor.org/info/rfc6554>.
[RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using
IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the
Internet of Things (IoT): Problem Statement", RFC 7554,
DOI 10.17487/RFC7554, May 2015,
<https://www.rfc-editor.org/info/rfc7554>.
[RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,
"IPv6 over Low-Power Wireless Personal Area Network "IPv6 over Low-Power Wireless Personal Area Network
(6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,
April 2017, <https://www.rfc-editor.org/info/rfc8138>. April 2017, <https://www.rfc-editor.org/info/rfc8138>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
10.2. Informative References 11.2. Informative References
[dot15-tsch] [dot15-tsch]
P802.11, "IEEE Standard for Low-Rate Wireless Networks, "IEEE 802 Wireless", "IEEE Standard for Low-Rate Wireless
Part 15.4, IEEE Std 802.15.4-2015", April 2016. Networks, Part 15.4, IEEE Std 802.15.4-2015", April 2016.
[dot1AS-2011] [dot1AS-2011]
IEEE 802.1AS Working Group, "IEEE Standard for Local and "IEEE Standards", "IEEE Standard for Local and
Metropolitan Area Networks - Timing and Synchronization Metropolitan Area Networks - Timing and Synchronization
for Time-Sensitive Applications in Bridged Local Area for Time-Sensitive Applications in Bridged Local Area
Networks", March 2011. Networks", March 2011.
[dotBLEMesh] [dotBLEMesh]
Luca Leonardi, Gaetano Pattim, and Lucia Lo Bello, "Multi- Leonardi, L., Pattim, G., and L. Lo Bello, "Multi-Hop
Hop Real-Time Communications Over Bluetooth Low Energy Real-Time Communications Over Bluetooth Low Energy
Industrial Wireless Mesh Networks", IEEE Access Vol 6, Industrial Wireless Mesh Networks", IEEE Access Vol 6,
26505-26519, May 2018. 26505-26519, May 2018.
[dotWi-SUN] [dotWi-SUN]
Hiroshi Harada, Keiichi Mizutani, Jun Fujiwara, Kentaro Harada, H., Mizutani, K., Fujiwara, J., Mochizuki, K.,
Mochizuki, Kentaro Obata, and Okumura, Ryota, "IEEE Obata, K., and R. Okumura, "IEEE 802.15.4g Based Wi-SUN
802.15.4g Based Wi-SUN Communication Systems", IEICE Communication Systems", IEICE Transactions on
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. and C. Perkins, "IPv6 Backbone Router", draft- Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6
ietf-6lo-backbone-router-07 (work in progress), September Backbone Router", draft-ietf-6lo-backbone-router-11 (work
2018. in progress), February 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-03 (work in progress), July 2018. draft-ietf-6lo-blemesh-04 (work in progress), January
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-19 (work in progress), October 2018. ietf-detnet-use-cases-20 (work in progress), December
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-03 (work in progress), June 2018. data-04 (work in progress), October 2018.
[I-D.ietf-roll-useofrplinfo] [I-D.ietf-roll-useofrplinfo]
Robles, I., Richardson, M., and P. Thubert, "When to use Robles, I., Richardson, M., and P. Thubert, "Using RPL
RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll- Option Type, Routing Header for Source Routes and IPv6-in-
useofrplinfo-23 (work in progress), May 2018. IPv6 encapsulation in the RPL Data Plane", draft-ietf-
roll-useofrplinfo-24 (work in progress), January 2019.
[ieee-1588] [ieee-1588]
Precise Time and Time Interval Working Group, "IEEE Std "IEEE Standards", "IEEE Std 1588-2008 Standard for a
1588-2008 Standard for a Precision Clock Synchronization Precision Clock Synchronization Protocol for Networked
Protocol for Networked Measurement and Control Systems", Measurement and Control Systems", July 2008.
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 02 to revision 03 Appendix A. Changes from revision 03 to revision 04
This section lists the changes between draft-ietf-6lo-deadline-time
revisions ...-03.txt and ...-04.txt.
o Replaced OT (Origination Time) field by OTD (Origination Time
Delta), allowing a more compressed representation that needs less
processing during transitions between networks.
o Changed representation for DTL, OTL, DT, OTD. Eliminated EXP in
favor of BinaryPt.
o Revised the figures and examples to use new parameters
o Added new section on Synchronization Aspects to supply pertinent
information about how nodes agree on the meaning of t=0.
o Responded to numerous reviewer comments to improve editorial
consistency and improve terminology.
Appendix B. 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 ...-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 B. Changes from revision 01 to revision 02 Appendix C. 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 C. Changes between earlier versions Appendix D. 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).
 End of changes. 65 change blocks. 
183 lines changed or deleted 284 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/