< draft-ietf-6lo-deadline-time-04.txt   draft-ietf-6lo-deadline-time-05.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: September 9, 2019 SRM University-AP Expires: January 9, 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
March 8, 2019 July 8, 2019
Packet Delivery Deadline time in 6LoWPAN Routing Header Packet Delivery Deadline time in 6LoWPAN Routing Header
draft-ietf-6lo-deadline-time-04 draft-ietf-6lo-deadline-time-05
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 M2M applications that scheduling decisions for time critical IoT machine to machine (M2M)
operate within time-synchronized networks that agree on the meaning applications that operate within time-synchronized networks that
of the time representations used for the deadline time values. 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 September 9, 2019. This Internet-Draft will expire on January 9, 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 19 skipping to change at page 2, line 22
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . 8
6.1. Scenario 1: Endpoints in the same DODAG (N1) . . . . . . 8 6.1. Scenario 1: Endpoints in the same DODAG (N1) . . . . . . 9
6.2. Scenario 2: Endpoints in Networks with Dissimilar L2 6.2. Scenario 2: Endpoints in Networks with Dissimilar L2
Technologies. . . . . . . . . . . . . . . . . . . . . . . 9 Technologies. . . . . . . . . . . . . . . . . . . . . . . 10
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). . . . . . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Synchronization Aspects . . . . . . . . . . . . . . . . . . . 12 8. Synchronization Aspects . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Changes from revision 03 to revision 04 . . . . . . 16 Appendix A. Changes from revision 04 to revision 05 . . . . . . 18
Appendix B. Changes from revision 03 to revision 04 . . . . . . 16 Appendix B. Changes from revision 03 to revision 04 . . . . . . 18
Appendix C. Changes from revision 01 to revision 02 . . . . . . 17 Appendix C. Changes from revision 02 to revision 03 . . . . . . 19
Appendix D. Changes between earlier versions . . . . . . . . . . 17 Appendix D. Changes from revision 01 to revision 02 . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Appendix E. Changes between earlier versions . . . . . . . . . . 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
scheduling decisions to meet the time bounds. scheduling decisions to meet the time bounds.
skipping to change at page 3, line 42 skipping to change at page 3, line 47
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
|1|0|1| Length | Type | | |1|0|1| Length | Type | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
<-- 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 (variable length): Type of the 6LoRHE (see Section 7) o Type (variable length): Type of the 6LoRHE (see Section 7)
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 Delta (OTD), the time at can include the packet Origination Time Delta (OTD), the time at
which the packet is enqueued for transmission (expressed as a value which the packet is enqueued for transmission (expressed as a value
to be subtracted from DT); this enables a close estimate of the total to be subtracted from DT); this enables a close estimate of the total
delay incurred by a packet. The OTD field is initialized by the delay incurred by a packet. The OTD field is initialized by the
sender based on the current time at the outgoing network interface sender based on the current time at the outgoing network interface
through which the packet is forwarded. Since the OTD is a delta the 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 OTD field (i.e., OTL) will require fewer bits than the
length of the DT field (i.e., DTL). length of the DT field (i.e., DTL).
The deadline field contains the value of the deadline time for the The deadline field contains the value of the deadline time for the
packet. The packet SHOULD be delivered to the Receiver before this packet -- in other words, the time by which the application expects
time. the packet to be delivered to the Receiver.
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 In order to support delay-sensitive deterministic applications, all
order to support delay-sensitive deterministic applications. The nodes within the network should process the Deadline-6LoRHE. The
packet deadline time (DT) and origination time (OTD) 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. The Network ASN (Absolute Slot Number) can be used as a time
Number) which can be used in case of a time slotted synchronized unit in a time slotted synchronized network (for instance a 6TiSCH
network (for instance a 6TiSCH network, where global time is network, where global time is maintained in the units of slot lengths
maintained in the units of slot lengths of a certain resolution). 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
Destination Time field is updated to represent the same Destination 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. Then the origination time is the same as the the new network. Then the origination time is the same as the
current time when the packet is transmitted into the new network, current time when the packet is transmitted into the new network,
minus the delay already experienced by the packet, say 'dly'. In minus the delay already experienced by the packet, say 'current_dly'.
this way, within the newly entered network, the packet will appear to In this way, within the newly entered network, the packet will appear
have originated 'dly' time units earlier with respect to the to have originated 'current_dly' time units earlier with respect to
reference clock of the new network. the reference clock of the new network.
origination time in new network = current_time_in_new_network -
delay_already_experienced_in_previous_network(s)
new_network_origin_time = time_now_in_new_network - current_dly
The following example illustrates these calculations when a packet The following example illustrates these calculations when a packet
travels between three networks, each in a different time zone. 'x' travels between three networks, each in a different time zone. 'x'
can be 1, 2 or 3. Suppose that the deadline time as measured in 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 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 difference between TZ2 and TZ1 is 900, and the difference between TZ3
TZ3 and TZ3 is 3600. In the figure, OT is the origination time as 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, measured in the current timezone, and is equal to DT - OTD, that is,
DT - 1000. Figure 2 uses the following abbreviations: 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'
dlyx : Delay experienced by the packet in the previous network(s) dlyx : Delay experienced by the packet in the previous network(s)
TZx : The time zone of network 'x' TZx : The time zone of network 'x'
skipping to change at page 6, line 28 skipping to change at page 6, line 28
Deadline-6LoRHE type measured in octets. Deadline-6LoRHE type measured in octets.
o 6LoRH Type: TBD (see Section 7) o 6LoRH Type: TBD (see Section 7)
o D flag (1 bit): The 'D' flag, set by the Sender, qualifies the 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 action to be taken when a 6LR detects that the deadline time has
elapsed. If 'D' bit is 1, then the 6LR MUST drop the packet if elapsed. If 'D' bit is 1, then the 6LR MUST drop the packet if
the deadline time is elapsed. If 'D' bit is 0, the packet MAY be 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 forwarded on an exception basis, if the forwarding node is NOT in
a situation of constrained resource, and if there are reasons to a situation of constrained resource, and if there are reasons to
suspect that downstream nodes might find it useful (delay suspect that downstream nodes might find it useful (delay
measurements, interpolations, etc.). measurements, interpolations, etc.).
o TU (2 bits) : Indicates the time units for DT and OTD fields. The
encodings for the DT and OTD fields use the same time units and
precision.
* 00 : Time represented in seconds and fractional seconds
* 01 : Reserved
* 10 : Network ASN
* 11 : Reserved
o DTL (4 bits): Length of DT field as an unsigned 4-bit integer, 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. encoding the length of the field in hex digits, minus one.
o OTL (3 bits) : Length of OTD field as an unsigned 3-bit integer, o OTL (3 bits) : Length of OTD field as an unsigned 3-bit integer,
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 deadline time in the 6LoRHE * For example, DTL = 0b0000 means the deadline time in the 6LoRHE
is 1 hex digit (4 bits) long. OTL = 0b111 means the is 1 hex digit (4 bits) long. OTL = 0b111 means the
origination time is 7 hex digits (28 bits) long. 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.
* 00 : Time represented in seconds and fractional seconds
* 01 : Reserved
* 10 : Network ASN
* 11 : Reserved
o Binary Pt (6 bits) : If zero, the number of bits of the integer 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 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 of the DT. if nonzero, the Binary Pt is a signed integer
determining the position of the binary point within the value for determining the position of the binary point within the value for
the DT. the DT.
* 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.
skipping to change at page 7, line 24 skipping to change at page 7, line 24
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 (8..64-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
available as follows. First, the application on the originating node
has to determine how many time bits are needed to represent the
difference between the time at which the packet is launched and the
deadline time, including the representation of fractional time units.
That number of bits (say, N_bits) determines DTL (the length of the
Deadline Time (DT)) as follows:
DTL = (N_bits mod 4)
The number of bits determined by DTL allows counting any number of
fractional time units in the range of interest determined by DT and
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).
Epoch_Range(DTL) = (2^(4*(DTL+1))
Each point of time between OT and DT is represented by a time unit
and a fractional time unit; in this section, this combined
representation is called a rational time unit (RTU). 1 RTU measures
the smallest fractional time that can be represented between two
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
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
values that can be represented in the current epoch are in the range
[0, (Epoch_Range(DTL) - 1)]. To minimize the required DTL,
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
epoch. The last possible origination time representable in the
current epoch (counted in RTUs) is t_last = (t0 + (2^(4*(DTL+1))-1)).
In the RTUs chosen, the current epoch resides at the underlying time
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 12, line 30 skipping to change at page 13, line 30
could be 6lo networks that employ NTP where the nodes are could be 6lo networks that employ NTP where the nodes are
synchronized with an external reference clock from an NTP server. synchronized with an external reference clock from an NTP server.
The specification of the time synchronization method that need to be The specification of the time synchronization method that need to be
followed by a network is beyond the scope of the document. followed by a network is beyond the scope of the document.
The number of hex digits chosen to represent DT, and the portion of The number of hex digits chosen to represent DT, and the portion of
that field allocated to represent integer number of seconds, that field allocated to represent integer number of seconds,
determines the meaning of t_0, i.e., the meaning of DT == 0 in the 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 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 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 more than 16 time units (or fractional time units) in the past. This
time synchronization between sender and receiver has to be tighter then requires that the time synchronization between sender and
than 16 time units. If the binary point were moved so that all the receiver has to be tighter than 16 units. If the binary point were
bits were used for fractional time units (e.g., fractional seconds or moved so that all the bits were used for fractional time units (e.g.,
fractional ASNs), the time synchronization requirement would be fractional seconds or fractional ASNs), the time synchronization
correspondingly tighter. requirement would be correspondingly tighter.
A 4-bit field for DT allows up to 16 hex digits, which is 64 bits. 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 That is enough to represent the NTP [RFC5905] 64-bit timestamp
format, which is more than enough for the purposes of establishing format, which is more than enough for the purposes of establishing
deadline times. Unless the binary point is moved, this is enough to deadline times. Unless the binary point is moved, this is enough to
represent time since year 1900. represent time since year 1900.
For example, suppose that DTL = 0b0000 and the DT bits are split 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 evenly; then we can count up to 3.75 seconds by quarter-seconds.
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 If DTL = 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. up to 256 seconds (in steps of 1/256 of a second).
In all cases, t_0 is defined as specified in Section 5
t_0 = [current_time - (current_time mod (2^(4*(DTL+1))))]
regardless of the choice of TU.
For TU = 0b00, the time units are seconds. With DTL == 15, and 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 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 UTC. The resolution is then (2 ^ (- 32)) seconds, which is the
maximum possible. This time format wraps around every 2^32 seconds, maximum possible. This time format wraps around every 2^32 seconds,
which is roughly 136 years. For other choices of DTL and the Binary which is roughly 136 years.
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, 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 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 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 the ASN to wrap around. Typically, the number of hex digits
allocated for TU = 0b10 would be less than 15. allocated for TU = 0b10 would be less than 15.
9. Security Considerations 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].
The protocol elements specified in this document are designed to work
in controlled operational environments (e.g., industrial process
control and automation). In order to avoid misuse of the deadline
information that could potentially result in a Denial of Service
(DoS) attack, proper functioning of this deadline time mechanism
requires the provisioning and management of network resources for
supporting traffic flows with deadlines, performance monitoring, and
admission control policy enforcement. The network provisioning can
be done either centrally or in a distributed fashion. For example,
tracks in a 6tisch network could be established by a centralized PCE,
as described in the 6tisch architecture
[I-D.ietf-6tisch-architecture].
The Security Considerations of Detnet architecture
[I-D.ietf-detnet-architecture] mostly apply to this document as well,
as follows. To secure the request and control of resources allocated
for tracks, authentication and authorization can be used for each
device, and network controller devices. In the case of distributed
control protocols, security is expected to be provided by the
security properties of the protocols in use.
When deadline bearing flows are identified on a per-flow basis, which
may provide attackers with additional information about the data
flows, when compared to networks that do not include per-flow
identification. The security implications of disclosing that
additional information deserve consideration when implementing this
deadline specification.
Because of the requirement of precise time synchronization, the
accuracy, availability, and integrity of time synchronization is of
critical importance. Extensive discussion of this topic can be found
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, Seema Kumar, Avinash Mohan, Shalu Rajendran and Anita Jerry Daniel, Dan Frost (Routing Directorate) Charlie Kaufman
Varghese for their support and valuable feedback. (Security Directorate) Seema Kumar, Tal Mizrahi Avinash Mohan, Shalu
Rajendran, Anita Varghese, and Dale Worley (Gen-ART review) for 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-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-detnet-architecture]
Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", draft-ietf-
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.
[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>.
skipping to change at page 14, line 44 skipping to change at page 16, line 34
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>.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <https://www.rfc-editor.org/info/rfc7384>.
[RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using
IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the
Internet of Things (IoT): Problem Statement", RFC 7554, Internet of Things (IoT): Problem Statement", RFC 7554,
DOI 10.17487/RFC7554, May 2015, DOI 10.17487/RFC7554, May 2015,
<https://www.rfc-editor.org/info/rfc7554>. <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>.
skipping to change at page 15, line 46 skipping to change at page 17, line 37
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-11 (work
in progress), February 2019. 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-04 (work in progress), January draft-ietf-6lo-blemesh-05 (work in progress), March 2019.
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-04 (work in progress), October 2018. data-06 (work in progress), July 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-24 (work in progress), January 2019. roll-useofrplinfo-31 (work in progress), July 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 03 to revision 04 Appendix A. Changes from revision 04 to revision 05
This section lists the changes between draft-ietf-6lo-deadline-time
revisions ...-04.txt and ...-05.txt.
o Included additional relevant material in Security Considerations
regarding expected deployment scenarios and the effect of
disclosing additional information during the travel of a packet.
o Reworked the specification for using time ranges shorter than the
maximum allowed by the choice of TU, so that fewer bits are needed
to represent DT and OT.
o Revised the figures and examples to use new parameters
o Reordered the field definitions for the Deadline-6LoRHE.
o Responded to numerous reviewer comments to improve terminology and
editorial consistency.
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 ...-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 B. Changes from revision 03 to revision 04 Appendix C. 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 C. Changes from revision 01 to revision 02 Appendix D. 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 D. Changes between earlier versions Appendix E. 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. 34 change blocks. 
81 lines changed or deleted 193 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/