rfc9034xml2.original.xml   rfc9034.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerat
ions-rfc2434bis.xml">
]> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most
I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std"
docName="draft-ietf-6lo-deadline-time-05" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
http://umeeting.huawei.com/Portal/business.action?BMECID=1474233&BMETimestamp=1
426658395147
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
submissionType="IETF"
category="std"
consensus="true"
docName="draft-ietf-6lo-deadline-time-05"
number="9034"
ipr="trust200902"
obsoletes=""
updates=""
xml:lang="en"
tocInclude="true"
tocDepth="2"
symRefs="true"
sortRefs="true"
version="3">
<!-- xml2rfc v2v3 conversion 2.47.0 -->
<front> <front>
<!-- The abbreviated title is used in the page header - it is only
necessary if the full title is longer than 39 characters -->
<title abbrev="6lo Delivery Deadline Time"> <title abbrev="6lo Delivery Deadline Time">
Packet Delivery Deadline time in 6LoWPAN Routing Header </title> Packet Delivery Deadline Time in the Routing Header for IPv6 over Low-Pow
er Wireless Personal Area Networks (6LoWPANs)</title>
<!-- add 'role="editor"' below for the editors if appropriate --> <seriesInfo name="RFC" value="9034"/>
<!-- Another author who claims to be an editor -->
<author fullname="Lijo Thomas" initials="" surname="Lijo Thomas"> <author fullname="Lijo Thomas" initials="L." surname="Thomas">
<organization>C-DAC</organization> <organization abbrev="C-DAC">Centre for Development of Advanced Computing<
/organization>
<address> <address>
<postal> <postal>
<street>Centre for Development of Advanced Computing (C-DAC), <street>Vellayambalam</street>
Vellayambalam</street>
<!-- Reorder these if your country does things differently -->
<city>Trivandrum</city> <city>Trivandrum</city>
<region/>
<code>695033</code> <code>695033</code>
<country>India</country> <country>India</country>
</postal> </postal>
<phone/>
<email>lijo@cdac.in</email> <email>lijo@cdac.in</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Satish Anamalamudi" initials="S." surname="Anamalamudi"> </address>
</author>
<author fullname="Satish Anamalamudi" initials="S." surname="Anamalamudi">
<organization>SRM University-AP</organization> <organization>SRM University-AP</organization>
<address> <address>
<postal> <postal>
<street>Amaravati Campus</street> <street>Amaravati Campus</street>
<!-- Reorder these if your country does things differently -->
<city>Amaravati, Andhra Pradesh</city> <city>Amaravati, Andhra Pradesh</city>
<region/>
<code>522 502</code> <code>522 502</code>
<country>India</country> <country>India</country>
</postal> </postal>
<phone/>
<email>satishnaidu80@gmail.com</email> <email>satishnaidu80@gmail.com</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="S.V.R. Anand" initials="S.V.R." surname="Anand">
<author fullname="S.V.R Anand" initials="" surname="S.V.R.Anand">
<organization>Indian Institute of Science</organization> <organization>Indian Institute of Science</organization>
<address> <address>
<postal> <postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city>Bangalore</city> <city>Bangalore</city>
<region/>
<code>560012</code> <code>560012</code>
<country>India</country> <country>India</country>
</postal> </postal>
<phone/> <email>anandsvr@iisc.ac.in</email>
<email>anand@ece.iisc.ernet.in</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Malati Hegde" initials="M." surname="Hegde">
<author fullname="Malati Hegde" initials="" surname="Malati Hegde">
<organization>Indian Institute of Science</organization> <organization>Indian Institute of Science</organization>
<address> <address>
<postal> <postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city>Bangalore</city> <city>Bangalore</city>
<region/>
<code>560012</code> <code>560012</code>
<country>India</country> <country>India</country>
</postal> </postal>
<phone/> <email>malati@iisc.ac.in</email>
<email>malati@ece.iisc.ernet.in</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Charles E. Perkins" initials="C.E." surname="Perkins"> <author fullname="Charles E. Perkins" initials="C." surname="Perkins">
<organization>Futurewei</organization> <organization>Lupin Lodge</organization>
<address> <address>
<postal> <postal>
<street>2330 Central Expressway</street> <street>20600 Aldercroft Heights Rd.</street>
<!-- Reorder these if your country does things differently --> <city>Los Gatos</city>
<city>Santa Clara</city> <region>CA</region>
<region/> <code>95033</code>
<code>95050</code> <country>United States of America</country>
<country>Unites States</country>
</postal> </postal>
<phone/>
<email>charliep@computer.org</email> <email>charliep@computer.org</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<date year="2021" month="June" />
<date />
<!-- If the month and year are both specified and are the current ones,
xml2rfc will fill in the current day for you. If only the current
year is specified, xml2rfc will fill in the current day and month for
you. If the year is not the current one, it is necessary to specify
at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally
sufficient to specify just the year. -->
<!-- Meta-data Declarations -->
<area>Internet</area> <area>Internet</area>
<workgroup>6lo</workgroup> <workgroup>6lo</workgroup>
<!-- WG name at the upperleft corner of the doc; <keyword>Routing header</keyword>
IETF is fine for individual submissions. If this element is not <keyword>Timestamp</keyword>
present, the default is "Network Working Group", which is used by
the RFC Editor as a nod to the history of the IETF. -->
<keyword>Routing header, Timestamp</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract> <abstract>
<t>
<t>
This document specifies a new type for the 6LoWPAN routing header This document specifies a new type for the 6LoWPAN routing header
containing the deadline time for data packets, designed for use over containing the deadline time for data packets, designed for use over
constrained networks. The deadline time enables forwarding and constrained networks. The deadline time enables forwarding and
scheduling decisions for time critical IoT machine to machine (M2M) scheduling decisions for time-critical machine-to-machine (M2M)
applications that operate within time-synchronized networks that agree applications running on Internet-enabled devices that operate within
on the meaning of the time representations used for the deadline time-synchronized networks. This document also specifies a
time values. representation for the deadline time values in such networks.
</t> </t>
<!-- Lijo : Eric Vyncke Comment: "Last sentence needs to be parsed as it very
long" -->
<!-- Lijo : Suggested Change : "that operate within time-synchronized networks.
his document specifies the time representation -->
<!-- that needs to be followed by such networks for the de
adline time values.. " -->
<!-- Lijo : @Charlie : Should we expand M2M based on eric comment ?-->
</abstract>
</front>
<middle> </abstract>
<section title="Introduction" anchor="Intro"> </front>
<t> <middle>
Low Power and Lossy Networks (LLNs) are likely to be deployed for <section anchor="Intro" numbered="true" toc="default">
real time industrial applications requiring end-to-end <name>Introduction</name>
delay guarantees <xref target="I-D.ietf-detnet-use-cases"/>. <t>
A Deterministic Network ("detnet") typically requires some data packets Low-Power and Lossy Networks (LLNs) are likely to be deployed for
real-time industrial applications requiring end-to-end
delay guarantees <xref target="RFC8578" format="default"/>.
A Deterministic Network ("DetNet") typically requires some data packets
to reach their receivers within strict time bounds. to reach their receivers within strict time bounds.
Intermediate nodes use the deadline information to make Intermediate nodes use the deadline information to make
appropriate packet forwarding and scheduling decisions to meet the appropriate packet forwarding and scheduling decisions to meet the
time bounds. time bounds.
</t> </t>
<t> <t>
This document specifies a new type for the Elective 6LoWPAN Routing This document specifies a new type for the Elective 6LoWPAN Routing
Header (6LoRHE), so that the deadline time (i.e., the time of latest Header (6LoRHE), Deadline-6LoRHE, so that the deadline time (i.e., the ti me of latest
acceptable delivery) of data acceptable delivery) of data
packets can be included within the 6LoWPAN routing header. packets can be included within the 6LoRHE.
<xref target="RFC8138"/> specifies the 6LoWPAN Routing Header (6LoRH), <xref target="RFC8138" format="default"/> specifies the 6LoWPAN Routing H
compression schemes for RPL routing (source routing) operation eader (6LoRH),
<xref target="RFC6554"/>, header compression of RPL Packet compression schemes for RPL (Routing Protocol for Low-Power and Lossy Net
Information <xref target="RFC6553"/>, and IP-in-IP encapsulation. works) source routing <xref target="RFC6554" format="default"/>, header compress
This document also specifies handling of the deadline ion of RPL packet
time when packets traverse between time-synchronized networks information <xref target="RFC6553" format="default"/>, and IP-in-IP encap
operating in different timezones or distinct reference clocks. sulation.
Time synchronization techniques are outside the scope of this This document also specifies the handling of the deadline
time when packets traverse time-synchronized networks
operating in different time zones or distinct reference clocks.
Time-synchronization techniques are outside the scope of this
document. There are a number of standards available for this document. There are a number of standards available for this
purpose, including IEEE 1588 <xref target="ieee-1588"/>, purpose, including IEEE 1588 <xref target="IEEE.1588.2008" format="defaul
IEEE 802.1AS <xref target="dot1AS-2011"/>, t"/>,
IEEE 802.15.4-2015 TSCH <xref target="dot15-tsch"/>, and more. IEEE 802.1AS <xref target="IEEE.802.1AS.2011" format="default"/>,
</t> IEEE 802.15.4-2015 Time-Slotted Channel Hopping (TSCH) <xref target="IEEE
<!-- Lijo : Eric Vyncke Comment: "does 'time zone' in this document doe .802.15.4" format="default"/>, and more.
s not refer to EST.." --> </t>
<!-- Lijo :suggestion: "time-synchronized networks operating over disti
nct reference clocks resulting in different timezones." -->
<t> <t>
The Deadline-6LoRHE can be used in any time synchronized 6Lo network. The Deadline-6LoRHE can be used in any time-synchronized 6LoWPAN network.
A 6TiSCH network is used to describe the implementation of the A 6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4) network is used to de
scribe the implementation of the
Deadline-6LoRHE, but this does not preclude its use in scenarios other Deadline-6LoRHE, but this does not preclude its use in scenarios other
than 6TiSCH. For instance, there is a growing interest in using 6lo than 6TiSCH. For instance, there is a growing interest in using 6LoWPAN
over a BLE mesh network <xref target="I-D.ietf-6lo-blemesh"/> in over a Bluetooth Low Energy (BLE) mesh network <xref target="I-D.ietf-6lo
industrial IoT <xref target="dotBLEMesh"/>. BLE mesh time -blemesh" format="default"/> in
industrial IoT (Internet of Things) <xref target="IEEE-BLE-MESH" format="
default"/>. BLE mesh time
synchronization is being explored by the Bluetooth synchronization is being explored by the Bluetooth
community. There are also cases under consideration in Wi-SUN community. There are also cases under consideration in Wi-SUN
<xref target="Wi-SUN_PHY"/>, <xref target="dotWi-SUN"/>. <xref target="PHY-SPEC" format="default"/> <xref target="Wi-SUN" format="
</t> default"/>.
</section> <!-- End of section "Introduction" --> </t>
</section>
<section anchor="acronyms_terms" title="Terminology"> <section anchor="acronyms_terms" numbered="true" toc="default">
<name>Terminology</name>
<t> <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
"MAY", and "OPTIONAL" in this document are to be interpreted as ",
described in <xref target="RFC2119"/> <xref target="RFC8174"/>. "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
</t> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
<t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
This document uses the terminology defined in be
<xref target="RFC6550"/> and interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
<xref target="I-D.ietf-6tisch-terminology"/>. target="RFC8174"/> when, and only when, they appear in all capitals, as
</t> shown here.
</section> <!-- End of section "Terminology" --> </t>
<section title="6LoRHE Generic Format"> <t>
This document uses the terminology defined in
<xref target="RFC6550" format="default"/> and
<xref target="RFC9030" format="default"/>.
</t>
</section>
<t> <section numbered="true" toc="default">
<name>6LoRHE Generic Format</name>
<t>
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
<xref target="I-D.ietf-roll-routing-dispatch"/>. <xref target="RFC8138" format="default"/>.
<xref target="fig1"/> illustrates the 6LoRHE generic format. <xref target="fig1" format="default"/> illustrates the 6LoRHE generic for
<figure anchor="fig1" title="6LoRHE format"> mat.
<artwork><![CDATA[ </t>
<figure anchor="fig1">
<name>6LoRHE Format</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
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 | Options | |1|0|1| Length | Type | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
<--- length --->]]> <--- length --->
</artwork> ]]></artwork>
</figure> </figure>
<!-- Lijo : Eric Vyncke Comment: Added "Options" in above figure . DONE --> <dl>
<list style="symbols"> <dt>Length:</dt>
<t> Length: Length of the 6LoRHE expressed <dd>Length of the 6LoRHE expressed in bytes, excluding the first 2 bytes. Thi
in bytes, excluding the first 2 bytes. This enables a node to s
skip a 6LoRHE if the Type is not recognized/supported.</t> enables a node to skip a 6LoRHE if the Type is not recognized or supporte
<t> Type (variable length): Type of the 6LoRHE d.</dd>
(see <xref target="iana"/>)</t> <dt>Type (variable length):</dt>
</list> <dd>Type of the 6LoRHE (see <xref target="iana" format="default"/>).</dd>
</t> </dl>
</section> <!-- End of section "6LoRHE Header Format" -->
<section title="Deadline-6LoRHE" anchor="Description"> </section>
<t>
The Deadline-6LoRHE (see <xref target="fig2"/>) is an elective <section anchor="Description" numbered="true" toc="default">
6LoRH (i.e., a 6LoRHE <xref target="RFC8138"/>) that provides <name>Deadline-6LoRHE</name>
<t>
The Deadline-6LoRHE (see <xref target="fig2" format="default"/>) is
a 6LoRHE <xref target="RFC8138" format="default"/> that provides
the Deadline Time (DT) for an IPv6 datagram in a compressed form. the Deadline Time (DT) for an IPv6 datagram in a compressed form.
Along with the deadline, the header can include the packet Along with the DT, the header can include the
Origination Time Delta (OTD), the time at which the packet is Origination Time Delta (OTD) packet, which contains the time when the
packet was
enqueued for transmission (expressed as a value to be subtracted enqueued for transmission (expressed as a value to be subtracted
from DT); this enables a close estimate of the total delay from DT); this enables a close estimate of the total delay
incurred by a packet. The OTD field is initialized by the sender incurred by a packet. The OTD field is initialized by the sender
based on the current time at the outgoing network interface through based on the current time at the outgoing network interface through
which the packet is forwarded. Since the OTD is a delta, which the packet is forwarded. Since the OTD is a delta,
the length of the OTD field (i.e., OTL) will require fewer the length of the OTD field (i.e., OTL) will require fewer
bits than the length of the DT field (i.e., DTL). bits than the length of the DT field (i.e., DTL).
</t>
</t> <t> The DT field contains the value of the deadline time for the
<!-- Lijo : Mirja Kuhlewind Comment Changed SHOULD to should -->
<t> The deadline field contains the value of the deadline time for the
packet -- in other words, the time by which the application expects packet -- in other words, the time by which the application expects
the packet to be delivered to the Receiver. the packet to be delivered to the receiver.
</t>
<?rfc subcompact="yes" ?> <t indent="3">
<list> packet_deadline_time = packet_origination_time + max_delay
<t> packet_deadline_time = packet_origination_time + max_delay </t> </t>
</list> <t>
<?rfc subcompact="no" ?> In order to support delay-sensitive, deterministic applications,
</t>
<t>
<!-- Lijo : Mirja Kuhlewind Comment: Change "SHOULD" to should, -->
In order to support delay-sensitive deterministic applications,
all nodes within the network should process the Deadline-6LoRHE. all nodes within the network should process the Deadline-6LoRHE.
The packet deadline time (DT) and origination time (OTD) are The DT and OTD packets are
represented in time units determined by a scaling parameter in represented in time units determined by a scaling parameter in
the routing header. The Network ASN (Absolute Slot Number) the Routing Header. The Network ASN (Absolute Slot Number)
can be used as a time unit in a time slotted can be used as a time unit in a time-slotted
synchronized network (for instance a 6TiSCH network, where global synchronized network (for instance, a 6TiSCH network, where global
time is maintained in the units of slot lengths of a certain time is maintained in the units of slot lengths of a certain
resolution). resolution).
</t> </t>
<t> The delay experienced by packets in the network is a useful
<t> The delay experienced by packets in the network is a useful
metric for network diagnostics and performance monitoring. metric for network diagnostics and performance monitoring.
Whenever a packet crosses into a network using Whenever a packet crosses into a network using
a different reference clock, the Destination Time field is updated a different reference clock, the DT field is updated
to represent the same Destination Time, but expressed using the to represent the same deadline time, but expressed using the
reference clock of the interface into the new network. Then the reference clock of the interface into the new network. Then the
origination time is the same as the current time when the packet origination time is the same as the current time when the packet
is transmitted into the new network, minus the delay already is transmitted into the new network, minus the delay already
experienced by the packet, say 'current_dly'. In this way, within experienced by the packet, say 'current_dly'. In this way, within
the newly entered network, the packet will appear to have the newly entered network, the packet will appear to have
originated 'current_dly' time units earlier with respect originated 'current_dly' time units earlier with respect
to the reference clock of the new network.</t> to the reference clock of the new network.</t>
<t>
new_network_origin_time = time_now_in_new_network - current_dly <t indent="3">
</t> new_network_origin_time = time_now_in_new_network - current_dly
<t> </t>
<t>
The following example illustrates these calculations The following example illustrates these calculations
when a packet travels between three networks, each in a different when a packet travels between three networks, each in a different
time zone. 'x' can be 1, 2 or 3. Suppose that the deadline time time zone (TZ). 'x' can be 1, 2, or 3. Suppose that the deadline tim
as measured in timezone 1 is 1050 and the origination time is 50. e
as measured in TZ1 is 1050, and the origination time is 50.
Suppose that the difference between TZ2 and TZ1 is 900, and the Suppose that the difference between TZ2 and TZ1 is 900, and the
difference between TZ3 and TZ3 is 3600. In the figure, OT difference between TZ2 and TZ3 is 3600. In the figure, OT
is the origination time as measured in the current timezone, and is the origination time as measured in the current time zone, and
is equal to DT - OTD, that is, DT - 1000. is equal to DT - OTD, that is, DT - 1000.
<xref target="time-update"/> uses the following abbreviations: <xref target="time-update" format="default"/> uses the following abbr
<list> eviations:
<t>TxA : Time of arrival of packet in the network 'x'</t> </t>
<t>TxD : Departure time of packet from the network 'x'</t>
<t>dlyx : Delay experienced by the packet in the <dl>
previous network(s)</t> <dt>TxA:</dt>
<t>TZx : The time zone of network 'x' </t> <dd>Time of arrival of packet in the network 'x' </dd>
</list> <dt>TxD:</dt>
</t> <dd>Departure time of packet from the network 'x' </dd>
<t> <dt>dlyx:</dt>
<figure title="Destination Time Update example" anchor="time-update"> <dd>Delay experienced by the packet in the previous network(s) </dd>
<artwork> <![CDATA[ <dt>TZx:</dt>
<dd>The time zone of network 'x' </dd>
</dl>
<figure anchor="time-update">
<name>Deadline Time Update Example</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
TZ1 TZ2 TZ3 TZ1 TZ2 TZ3
T1A=50| | | T1A=50| | |
|---- dly1=50 | | |---- dly1=50 | |
| \ | | | \ | |
| \ | | | \ | |
| \ T1D=100 |T2A=1000 | | \ T1D=100 |T2A=1000 |
| -------->|----- dly2=450 | | -------->|----- dly2=450 |
| | \ | | | \ |
| | \ | | | \ |
| | \ T2D=1400 | T3A=5000 | | \ T2D=1400 | T3A=5000
skipping to change at line 385 skipping to change at line 304
| | | | | |
v v v v v v
dly0 = 0 dly1 = T1D-OT1 dly2 = T2D-OT2 dly0 = 0 dly1 = T1D-OT1 dly2 = T2D-OT2
= 100-50 = 1400 - 950 = 100-50 = 1400 - 950
= 50 = 450 = 50 = 450
OT1 = T1A-dly0 OT2 = T2A-dly1 OT3 = T3A-dly2 OT1 = T1A-dly0 OT2 = T2A-dly1 OT3 = T3A-dly2
= 50 = 1000-50 = 5000 - 450 = 50 = 1000-50 = 5000 - 450
= 950 = 4550 = 950 = 4550
]]></artwork> </figure> ]]></artwork>
</t> </figure>
<t> There are multiple ways that a packet can be delayed, including <t> There are multiple ways that a packet can be delayed, including
queuing delay, MAC layer contention delay, serialization delay, and queuing delay, Media Access Control (MAC) layer contention delay, seriali
propagation delays. Sometimes there are processing delays as well. zation delay, and
propagation delay. 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.
</t> </t>
</section> <!-- End of section "Deadline-6LoRHE Description" --> </section>
<section title="Deadline-6LoRHE Format" anchor="Format"> <section anchor="Format" numbered="true" toc="default">
<t> <name>Deadline-6LoRHE Format</name>
<figure anchor="fig2" title="Deadline-6LoRHE format"> <figure anchor="fig2">
<artwork><![CDATA[ <name>Deadline-6LoRHE Format</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
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 |D| TU| DTL | OTL | BinaryPt | |1|0|1| Length | 6LoRH Type |D| TU| DTL | OTL | BinaryPt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DT (variable length) | OTD(variable length)(optional)| | DT (variable length) | OTD(variable length)(optional)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork> ]]></artwork>
</figure> </figure>
</t>
<?rfc subcompact="yes" ?> <dl>
<t> <list style="symbols"> <dt>Length (5 bits):
<t> Length (5 bits): Length represents the total length of the </dt>
Deadline-6LoRHE type measured in octets.</t> <dd>Length represents the total length of the Deadline-6LoRHE Type measured in o
<t> 6LoRH Type: TBD (see <xref target="iana"/>)</t> ctets.
<t> D flag (1 bit): The 'D' flag, set by the Sender, qualifies the action </dd>
to be taken when a 6LR detects that the deadline time has elapsed. <dt>6LoRH Type:</dt>
If 'D' bit is 1, then the 6LR MUST drop the packet if the <dd>7 (See <xref target="iana" format="default"/>.)
deadline time is elapsed. </dd>
If 'D' bit is 0, the packet MAY be forwarded on an exception
basis, if the forwarding node is NOT in a situation of constrained
resource, and if there are reasons to suspect that downstream nodes
might find it useful (delay measurements, interpolations, etc.).
</t>
<t> 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.
<list>
<t>00 : Time represented in seconds and fractional seconds</t>
<t>01 : Reserved</t>
<t>10 : Network ASN</t>
<t>11 : Reserved</t>
</list>
</t>
<t> DTL (4 bits): Length of DT field as an unsigned 4-bit integer,
encoding the length of the field in hex digits, minus one.
</t>
<t> OTL (3 bits) : Length of OTD field as an unsigned 3-bit integer, <dt>D flag (1 bit):
encoding the length of the field in hex digits. If OTL == 0, the </dt>
OTD field is not present. The value of OTL MUST NOT exceed the <dd><t>The 'D' flag, set by the sender, qualifies the action to be taken when a
value of DTL plus one. 6LoWPAN Router (6LR) detects that the deadline time has elapsed.</t>
<list> <t>If 'D' bit is 1, then the 6LR
<t> For example, DTL = 0b0000 means the deadline time in the 6LoRHE is <bcp14>MUST</bcp14> drop the packet if the deadline time is elapsed.</t>
1 hex digit (4 bits) long. OTL = 0b111 means the origination time <t>If 'D'
is 7 hex digits (28 bits) long.</t> bit is 0, the packet <bcp14>MAY</bcp14> be forwarded on an exception basis, if
</list></t> the forwarding node is NOT in a situation of constrained resource, and if
<t> Binary Pt (6 bits) : If zero, the number of bits of the integer part there are reasons to suspect that downstream nodes might find it useful (delay
measurements, interpolations, etc.).</t>
</dd>
<dt>TU (2 bits):
</dt>
<dd>
<t>Indicates the time units for DT and OTD fields. The encodings for the
DT and OTD fields use the same time units and precision. </t>
<dl spacing="compact">
<dt>00</dt><dd>Time represented in seconds and fractional seconds</d
d>
<dt>01</dt><dd>Reserved</dd>
<dt>10</dt><dd>Network ASN</dd>
<dt>11</dt><dd>Reserved</dd>
</dl>
</dd>
<dt>DTL (4 bits):
</dt>
<dd>Length of the DT field as an unsigned 4-bit integer, encoding the length of
the field in hex digits, minus one.
</dd>
<dt>OTL (3 bits):
</dt>
<dd><t>Length of the OTD field as an unsigned 3-bit integer,
encoding the length of the field in hex digits. If OTL == 0, the OTD field is
not present. The value of OTL <bcp14>MUST NOT</bcp14> exceed the value of DTL
plus one.
</t>
<t>For example, DTL = 0b0000 means the DT field in the
6LoRHE is 1 hex digit (4 bits) long. OTL = 0b111 means the
OTD field is 7 hex digits (28 bits) long.</t>
</dd>
<dt>BinaryPt (6 bits):
</dt>
<dd><t>If zero, the number of bits of the integer part
the DT is equal to the number of bits of the fractional part of the DT is equal to the number of bits of the fractional part of
the DT. if nonzero, the Binary Pt is a signed integer determining the DT. If nonzero, the BinaryPt is a (2's complement) signed
the position of the binary point within the value for the DT. integer determining the position of the binary point within the value
<list style="symbols"> for the DT. This allows BinaryPt to be within the range [-32,31].</t>
<t> If BinaryPt value is positive, then the number of bits for the <ul>
integer part of the DT is increased by the value of BinaryPt, <li> If BinaryPt value is positive, then the number of bits for
and the number of bits for the fractional part of the DT is the integer part of the DT is increased by the value of BinaryPt,
correspondingly reduced. This increases the range of DT.</t> and the number of bits for the fractional part of the DT is
<t> If BinaryPt value is negative, then the number of bits for the correspondingly reduced. This increases the range of DT.</li>
integer part of the DT is decreased by the value of BinaryPt, <li> If BinaryPt value is negative, then the number of bits for
and the number of bits for the fractional part of the DT is the integer part of the DT is decreased by the value of BinaryPt,
correspondingly increased. This increases the precision and the number of bits for the fractional part of the DT is
of the fractional seconds part of DT.</t> correspondingly increased. This increases the precision of the
fractional seconds part of DT.</li>
</ul>
</dd>
<!-- Lijo : Alexey Melnikov Comment: "It would be good if you specified how ne <dt>DT Value (4..64 bits):
gative values are represented --> </dt>
<!-- and the range for positive and negative <dd>An unsigned integer of DTL+1 hex digits giving the DT value.
values" --> </dd>
</list> </t> <dt>OTD Value (4..28 bits):
<t> DT Value (8..64-bit) : An unsigned integer of DTL+1 hex digits </dt>
giving the Deadline Time value </t> <dd>If present, an unsigned integer of OTL hex digits giving the origination tim
<t> OTD Value (8..64-bit) : An unsigned integer of OTL hex digits giving e as a
the Origination Time as a negative offset from the DT value </t> negative offset from the DT value.
</list> </t> </dd>
<?rfc subcompact="no" ?> </dl>
<t> Whenever a sender initiates the IP datagram, it includes the
Deadline-6LoRHE along with other 6LoRH information. For information <t> Whenever a sender initiates the IP datagram, it includes the
about the time synchronization requirements between sender and Deadline-6LoRHE along with other 6LoRH information. For information about
receiver see <xref target="sync"/>. the time-synchronization requirements between sender and receiver, see <xref
</t> target="sync" format="default"/>.
</t>
<t>
<t>
<!-- CEP: Wraparound, revisited... -->
For the chosen time unit, a compressed time representation is For the chosen time unit, a compressed time representation is
available as follows. First, the application on the originating node available as follows. First, the application on the originating node
has to determine determines
how many time bits are needed to represent the difference between the how many time bits are needed to represent the difference between the
time at which the packet is launched and the deadline time, including time at which the packet is launched and the deadline time, including
the representation of fractional time units. That number of bits the representation of fractional time units. That number of bits
(say, N_bits) determines DTL (the length of the Deadline Time (DT)) (say, N_bits) determines DTL as follows:
as follows: </t>
<list> <t indent="3">
<t> DTL = (N_bits mod 4) </t> DTL = ((N_bits - 1) / 4)
</list> </t>
The number of bits determined by DTL allows counting any number of <t>
The number of bits determined by DTL allows the counting of any number of
fractional time units in the range of interest determined by DT and the fractional time units in the range of interest determined by DT and the
origination time OT. Denote this number of fractional time units to OT. Denote this number of fractional time units to
be Epoch_Range(DTL) (i.e., Epoch_Range is a function of DTL). be Epoch_Range(DTL) (i.e., Epoch_Range is a function of DTL):
<list> </t>
<t> Epoch_Range(DTL) = (2^(4*(DTL+1)) </t> <t indent="3">
</list> Epoch_Range(DTL) = 2<sup>4*(DTL+1)</sup>
</t>
<t>
Each point of time between OT and DT is represented by a time unit and 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 a fractional time unit; in this section, this combined representation
is called a rational time unit (RTU). 1 RTU measures the smallest is called a rational time unit (RTU). 1 RTU measures the smallest
fractional time that can be represented between two points of time fractional time that can be represented between two points of time
in the epoch (i.e., within the range of interest). in the epoch (i.e., within the range of interest).
</t> </t>
<t> <t>
DT - OT cannot exceed 2^(4*(DTL+1)) == 16^(DTL+1). A low value of DTL DT - OT cannot exceed 2<sup>4*(DTL+1)</sup> == 16<sup>DTL+1</sup>. A low
value of DTL
leads to a small Epoch_Range; if DTL = 0, there will only be 16 RTUs 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 within the Epoch_Range (i.e., Epoch_Range(DTL) = 16<sup>1</sup>) for any TU. The
values that can be represented in the current epoch are in the range values that can be represented in the current epoch are in the range
[0, (Epoch_Range(DTL) - 1)]. To minimize the required DTL, wraparound [0, (Epoch_Range(DTL) - 1)].</t>
is allowed but works naturally with the arithmetic modulo Epoch_Range. <t>
Assuming wraparound does not occur, OT is represented by the value (OT m
od 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.
</t>
<t>
In order to allow fine-grained control over the setting of the
deadline time, the fields for DT and OTD use fractional seconds. This is don
e by specifying
a binary point, which allocates some of the bits for fractional times.
Thus, all such fractions are restricted to be negative powers of 2.
Each point of time between OT and DT is then represented by a time
unit (either seconds or ASNs) and a fractional time unit.
</t> </t>
<t> <t>
By default, DTL determines t_0 in the chosen RTUs as follows: Let OT_abs, DT_abs, and CT_abs denote the true (absolute) values (on the
<list> synchronized timelines) for OT, DT, and
<t> t_0 = [current_time - (current_time mod Epoch_Range (DTL))].< current time. Let N be the number of bits to be used to represent
/t> the integer parts of OT_abs, DT_abs, and CT_abs:
</list> </t>
<t indent="6">N = {4*(DTL+1)/2} + BinaryPt </t>
<t>
The originating node has to pick a segment size (2^N) so that
DT_abs - OT_abs &lt; 2^N, and so that intermediate network nodes
can detect whether or not CT_abs &gt; DT_abs.
</t>
<t>
Given a value for N, the value for DT is represented in the
deadline-time format by DT = (DT_abs mod 2^N). DT is typically
represented as a positive value (even though negative modular
values make sense). Also, let OT = OT_abs mod 2^N and
CT = CT_abs mod 2^N, where both OT and CT are also considered as
non-negative values.
</t>
<t>
When the packet is launched by the originating node,
CT_abs == OT_abs and CT == OT. Given a particular value for N,
then in order for downstream nodes to detect whether or not the
deadline has expired (i.e., whether DT_abs > CT_abs), the following is
required:
</t>
<t indent="6" anchor="assumption">Assumption 1: DT_abs - OT_abs &lt; 2^N.</t
>
<t>
Otherwise the ambiguity
inherent in the modulus arithmetic yielding OT and DT will cause
failure: one cannot measure time differences greater than 2^N using
numbers in a time segment of length less than 2^N.
</t>
<t>
Under <xref target="assumption" format="none">Assumption 1</xref>, downst
ream nodes must effectively check
whether or not their current time is later than the DT -- but
the value of the DT has to be inferred from the
value of DT in the 6LoRHE, which is a number less than 2^N. This
inference cannot be expected to reliably succeed unless <xref target="ass
umption" format="none">Assumption 1</xref>
is valid, which means that the originating node has to be careful to pick
proper
values for DTL and for BinaryPt.
</t>
Naturally, t_0 occurs at time 0 (or time 0.0000...) in the current <t>
epoch. The last possible origination time representable in the current Since OT is not necessarily provided in the 6loRHE, there may be a
epoch (counted in RTUs) is t_last = (t0 + (2^(4*(DTL+1))-1)). In the danger of ambiguity. Surely, when DT = CT, the deadline time
RTUs chosen, the current epoch resides at the underlying time is expiring and the packet should be dropped. However, what if an
interval [t_0, t_last]. If DT - OT is greater than t_last - OT, then intermediate node measures that CT = DT+1? Was the packet
wraparound within the Epoch_Range occurs naturally. In all cases, launched a short time before arrival at the intermediate node,
OT is represented by the value (OT mod Epoch_Range) and DT is or has the current time wrapped around so that
represented by the value (DT mod Epoch_Range). All arithmetic is CT_abs - OT_abs &gt; 2^N?
to be performed modulo (Epoch_Range(DTL)), yielding only positive
values for DT - OT.
</t> </t>
<t> <t>
<list> In order to solve this problem, a safety margin has to be provided,
<t> Example: Consider a 6TiSCH network with time-slot length of 10ms. in addition to requiring that DT_abs - OT_abs &lt; 2^N. The value
of this safety margin is proportional to 2^N and is determined by
a new parameter, called the "SAFETY_FACTOR". Then, for safety the
originating node MUST further ensure that
(DT_abs - OT_abs) &lt; 2^N*(1-SAFETY_FACTOR).
</t>
<t>
Each intermediate node that receives the packet with the
Deadline-6LoRHE must determine whether
((CT - DT) mod 2^N) &gt; SAFETY_FACTOR*2^N.
If this test condition is not satisfied, the deadline time has expired.
See <xref target="modular"/> for more explanation about the test
condition.
All nodes that receive a packet with a Deadline-6LoRHE included
MUST use the same value for the SAFETY_FACTOR. The SAFETY_FACTOR
is to be chosen so that a packet with the Deadline-6LoRHE included
will be tested against the current time at least once during every
subinterval of length SAFETY_FACTOR*2^N. In this way, it can be
guaranteed that the packet will be tested often enough to make
sure it can be dropped whenever CT_abs &gt; DT_abs. The value of
SAFETY_FACTOR is specified in this document to be 20%.
</t>
<t indent="3">Example: Consider a 6TiSCH network with time-slot length
of 10 ms.
Let the time units be ASNs (TU == (binary)0b10). Let the Let the time units be ASNs (TU == (binary)0b10). Let the
current ASN when the packet is originated be 54400, and the current ASN when the packet is originated be 54400, and the
maximum allowable delay (max_delay) for the packet delivery be 1 maximum allowable delay (max_delay) for the packet delivery be 1
second from the packet origination, then: second from the packet origination, then:
<list> </t>
<t> deadline_time = packet_origination_time + max_delay <t indent="6"> deadline_time = packet_origination_time + max_delay</t>
<list> <t indent="9"> = 0xD480 + 0x64 (Network ASNs) </t>
<t> = 0xD480 + 0x64 (Network ASNs) </t> <t indent="9"> = 0xD4E4 (Network ASNs) </t>
<t> = 0xD4E4 (Network ASNs) </t>
</list>
</t>
<t> Then, the Deadline-6LoRHE encoding with nonzero OTL is:
<list>
<t> DTL = 3, OTL = 2, TU = 0b10, BinaryPt = 8,
DT = 0xD4E4, OTD = 0x64</t>
</list>
</t>
</list>
</t>
<t> <!-- Put another example here. --></t>
</list> </t>
<?rfc subcompact="no" ?> <t indent="6"> Then, the Deadline-6LoRHE encoding with nonzero OTL is:
</section> <!-- End of section "Deadline-6LoRHE" --> </t>
<t indent="9"> DTL = 3, OTL = 2, TU = 0b10, BinaryPt = 8, DT = 0xD4
E4, OTD&nbsp;=&nbsp;0x64</t>
<section title="Deadline-6LoRHE in Three Network Scenarios"> </section>
<t>
In this section, Deadline-6LoRHE operation is described for 3 <section numbered="true" toc="default">
network scenarios. <xref target="fig3"/> depicts a <name>Deadline-6LoRHE in Three Network Scenarios</name>
constrained time-synchronized LLN that has two subnets N1 and N2, <t>
connected through LBRs <xref target="I-D.ietf-6lo-backbone-router"/> In this section, the Deadline-6LoRHE operation is described for three
with different reference clock times T1 and T2. network scenarios. <xref target="fig3" format="default"/> depicts a
<figure anchor="fig3" title=" Intra-network Timezone Scenario"> constrained time-synchronized LLN that has two subnets, N1 and N2,
<artwork><![CDATA[ connected through 6LoWPAN Border Routers (6LBRs) <xref target="RFC8929" f
ormat="default"/>
with different reference clock times, T1 and T2.
</t>
<figure anchor="fig3">
<name>Intra-Network Time Zone Scenario</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+-------------------+ +-------------------+
| Time Synchronized | | Time-Synchronized |
| Network | | Network |
+---------+---------+ +---------+---------+
| |
| |
| |
+--------------+--------------+ +--------------+--------------+
| | | |
+-----+ +-----+ +-----+ +-----+
| | Backbone | | Backbone | | Backbone | | Backbone
o | | router | | router o | | router | | router
+-----+ +-----+ +-----+ +-----+
o o o o o o
o o o o o o o o o o o o o o o o o o
o LLN o o LLN o o o LLN o o LLN o o
o o o o o o o o o o o o o o o o o o
6LoWPAN Network (subnet N1) 6LoWPAN Network (subnet N2) 6LoWPAN Network (subnet N1) 6LoWPAN Network (subnet N2)
]]></artwork> ]]></artwork>
</figure> </figure>
</t> <section numbered="true" toc="default">
<name>Scenario 1: Endpoints in the Same DODAG (N1)</name>
<section <t>
title="Scenario 1: Endpoints in the same DODAG (N1)"> In Scenario 1, shown in <xref target="fig4" format="default"/>, the Sende
<t> r 'S' has an
In scenario 1, shown in <xref target="fig4"/>, the Sender 'S' has an
IP datagram to be routed to a Receiver 'R' within IP datagram to be routed to a Receiver 'R' within
the same DODAG. For the route segment from Sender to 6LBR, the Sender the same Destination-Oriented Directed Acyclic Graph (DODAG).
For the route segment from the sender to the 6LBR, the sender
includes a Deadline-6LoRHE by encoding the deadline time includes a Deadline-6LoRHE by encoding the deadline time
contained in the packet. Subsequently, each 6LR will perform hop-by-hop contained in the packet. Subsequently, each 6LR will perform hop-by-hop
routing to forward the packet towards the 6LBR. Once 6LBR receives routing to forward the packet towards the 6LBR. Once the 6LBR receives
the IP datagram, it sends the packet downstream towards 'R'. the IP datagram, it sends the packet downstream towards 'R'.
</t> </t>
<t> <t>
In case of a network running RPL non-storing mode, the 6LBR generates In the case of a network running in RPL non-storing mode, the 6LBR genera
a IPv6-in-IPv6 encapsulated packet when sending the packet downwards tes
to the Receiver <xref target="I-D.ietf-roll-useofrplinfo"/>. an IPv6-in-IPv6 encapsulated packet when sending the packet downwards
The 6LBR copies the Deadline-6LoRHE from the Sender originated IP to the receiver <xref target="RFC9008" format="default"/>.
The 6LBR copies the Deadline-6LoRHE from the sender-originated IP
header to the outer IP header. The Deadline-6LoRHE contained in header to the outer IP header. The Deadline-6LoRHE contained in
the inner IP header is removed. the inner IP header is removed.
</t> </t>
<t> <figure anchor="fig4">
<figure anchor="fig4" title="End points within same DODAG (subnet N1)"> <name>Endpoints within the Same DODAG (Subnet N1)</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+-------+ +-------+
^ | 6LBR | | ^ | 6LBR | |
| | | | | | | |
| +-------+ | | +-------+ |
Upward | / /| \ | Downward Upward | / /| \ | Downward
routing | (F) / | \ | routing routing | (F) / | \ | routing
| / \ (C) | (D) | | / \ (C) | (D) |
| / \ | | / |\ | | / \ | | / |\ |
| (A) (B) : (E) : R | | (A) (B) : (E) : R |
| /|\ | \ / \ | | /|\ | \ / \ |
| S : : : : : : v ]]></artwork> | S : : : : : : v ]]></artwork>
</figure> </figure>
</t> <t>
<t>
At the tunnel endpoint of the encapsulation, the At the tunnel endpoint of the encapsulation, the
Deadline-6LoRHE is copied back from the outer header to inner Deadline-6LoRHE is copied back from the outer header to inner
header, and the inner IP packet is delivered to 'R'. header, and the inner IP packet is delivered to 'R'.
</t> </t>
</section> <!-- End of section "Scenario 1: Endpoints in the same ..." --> </section>
<section <section numbered="true" toc="default">
title="Scenario 2: Endpoints in Networks with Dissimilar L2 Technologies."> <name>Scenario 2: Endpoints in Networks with Dissimilar L2 Technologies<
<t> /name>
In scenario 2, shown in <xref target="fig5"/>, <t>
the Sender 'S' (belonging to DODAG 1) has IP datagram to be routed to In Scenario 2, shown in <xref target="fig5" format="default"/>,
the Sender 'S' (belonging to DODAG 1) has an IP datagram to be routed to
a Receiver 'R' over a time-synchronized IPv6 network. For the route a Receiver 'R' over a time-synchronized IPv6 network. For the route
segment from 'S' to 6LBR, 'S' includes a Deadline-6LoRHE. segment from 'S' to 6LBR, 'S' includes a Deadline-6LoRHE.
Subsequently, each 6LR will perform hop-by-hop routing to forward the Subsequently, each 6LR will perform hop-by-hop routing to forward the
packet towards the 6LBR. Once the Deadline Time information reaches packet towards the 6LBR. Once the deadline time information reaches
the border router, the packet will be encoded according to the the 6LBR, the packet will be encoded according to the
mechanism prescribed in the other time-synchronized network depicted mechanism prescribed in the other time-synchronized network depicted
as "Time Synchronized Network" in the figure 6. as "Time-Synchronized Network" in <xref target="fig5" format="default"/>.
The specific data encapsulation mechanisms followed in the new network The specific data encapsulation mechanisms followed in the new network
are beyond the scope of this document. are beyond the scope of this document.
<figure anchor="fig5" </t>
title="Packet transmission in Dissimilar L2 Technologies or Internet"> <figure anchor="fig5">
<artwork><![CDATA[ <name>Packet Transmission in Dissimilar L2 Technologies or Internet</n
ame>
<artwork name="" type="" align="left" alt=""><![CDATA[
+----------------+ +----------------+
| Time | | Time- |
| Synchronized |------R | Synchronized |------R
| Network | | Network |
+----------------+ +----------------+
| |
| |
----------+----------- ----------+-----------
^ | ^ |
| +---+---+ | +---+---+
| | 6LBR | | | 6LBR |
Upward | | | Upward | | |
routing | +------++ routing | +------++
| (F)/ /| \ | (F)/ /| \
| / \ / | \ | / \ / | \
| / \ (C) | (D) | / \ (C) | (D)
| (A) (B) | | / |\ | (A) (B) | | / |\
| /|\ |\ : (E) : : | /|\ |\ : (E) : :
| S : : : : / \ | S : : : : / \
: :]]> : :
</artwork> ]]></artwork>
</figure> </figure>
<t>
</t> For instance, the IP datagram could be routed to another time-synchronize
d,
<t> deterministic network using the mechanism specified in
For instance, the IP datagram could be routed to another time In-situ Operations, Administration, and Maintenance (IOAM)
synchronized deterministic network using the mechanism specified in <xref target="I-D.ietf-ippm-ioam-data" format="default"/>, and then
the In-band OAM <xref target="I-D.ietf-ippm-ioam-data"/>, and then
the deadline time would be updated according to the measurement the deadline time would be updated according to the measurement
of the current time in the new network. of the current time in the new network.
</t> </t>
</section> <!-- End of section "Scenario 2: Packet transmission in ..." --> </section>
<section <section numbered="true" toc="default">
title="Scenario 3: Packet transmission across different DODAGs (N1 to N2)."> <name>Scenario 3: Packet Transmission across Different DODAGs (N1 to N2)
<t> </name>
Consider the scenario depicted in <xref target="fig6"/>, in which <t>
Consider the scenario depicted in <xref target="fig6" format="default"/>,
in which
the Sender 'S' (belonging to DODAG 1) has an IP datagram to be the Sender 'S' (belonging to DODAG 1) has an IP datagram to be
sent to Receiver 'R' belonging to another DODAG (DODAG 2). The sent to Receiver 'R' belonging to another DODAG (DODAG 2). The
operation of this scenario can be decomposed into combination of case operation of this scenario can be decomposed into a combination of
1 and case 2 scenarios. For the route segment from 'S' to 6LBR1, Scenarios 1 and 2. For the route segment from 'S' to 6LBR1,
'S' includes the Deadline-6LoRHE. Subsequently, each 6LR will 'S' includes the Deadline-6LoRHE. Subsequently, each 6LR will
perform hop-by-hop operation to forward the packet towards the 6LBR1. perform hop-by-hop operations to forward the packet towards 6LBR1.
Once the IP datagram reaches 6LBR1 of DODAG1, it applies the same rule Once the IP datagram reaches 6LBR1 of DODAG1, 6LBR1 applies the same rule
as described in Case 2 while routing the packet to 6LBR2 over a (likely) as described in Scenario 2 while routing the packet to 6LBR2 over a (like
time synchronized wired backhaul. The wired side of 6LBR2 can be mapped ly)
to receiver of Case 2. Once the packet reaches 6LBR2, it updates the time-synchronized wired backhaul. The wired side of 6LBR2 can be mapped
to the receiver of Scenario 2. Once the packet reaches 6LBR2, it updates
the
Deadline-6LoRHE by adding or subtracting the difference of time of Deadline-6LoRHE by adding or subtracting the difference of time of
DODAG2 and sends the packet downstream towards 'R'. DODAG2 and sends the packet downstream towards 'R'.
</t> </t>
<figure anchor="fig6" <figure anchor="fig6">
title="Packet transmission in different DODAGs(N1 to N2)"> <name>Packet Transmission in Different DODAGs (N1 to N2)</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
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
</artwork> ]]></artwork>
</figure> </figure>
<t> <t>
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 DODAG2 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 is assumed to be 10 ms. Once the deadline time is encoded in
Deadline-6LoRHE, the packet is forwarded to 6LBR of DODAG1. Deadline-6LoRHE, the packet is forwarded to 6LBR1 of DODAG1.
Suppose the packet reaches 6LBR of DODAG1 at ASN 20030. Suppose the packet reaches 6LBR1 of DODAG1 at ASN 20030.
</t> </t>
<t> <t indent="3"> current_time = ASN at 6LBR * slot_length_value </t>
<?rfc subcompact="yes" ?> <t indent="3"> remaining_time = deadline_time - current_time</t>
<list> <t indent="6"> = ((packet_origination_time + max_delay) - current t
<t> current_time = ASN at LBR * slot_length_value</t> ime)</t>
<t></t> <t indent="6"> = (20000 + 100) - 20030 </t>
<t> remaining_time = deadline_time - current_time</t> <t indent="6"> = 30 (in Network ASNs)</t>
<t> = ((packet_origination_time + max_delay) - current time)</t> <t indent="6"> = 30 * 10<sup>3</sup> milliseconds </t>
<t> = (20000 + 100) - 20030 </t>
<t> = 30 (in Network ASNs)</t> <t>
<t> = 30 * 10^3 milliseconds. </t> Once the deadline time information reaches 6LBR2,
</list>
<?rfc subcompact="no" ?>
</t>
<t>
Once the Deadline Time information reaches the border router,
the packet will be encoded according to the mechanism prescribed the packet will be encoded according to the mechanism prescribed
in the other time-synchronized network. in the other time-synchronized network.
</t> </t>
</section> <!-- End of section "Scenario 3: Packet transmission across ..." --> </section>
</section> <!-- End of section "Deadline-6LoRHE </section>
in different network scenarios" -->
<section title="IANA Considerations" anchor="iana"> <section anchor="iana" numbered="true" toc="default">
<t> <name>IANA Considerations</name>
<t>
This document defines a new Elective 6LoWPAN Routing Header Type, This document defines a new Elective 6LoWPAN Routing Header Type,
and IANA is requested to assign a value (TBD) from the 6LoWPAN and IANA has assigned the value 7 from the 6LoWPAN
Dispatch Page1 number space for this purpose. Dispatch Page 1 number space for this purpose.
<!-- New: Donald E. Eastlake comments -> Modified writings . --> </t>
<figure anchor="fig8" title="Deadline-6LoRHE type"> <table anchor="iana_reg">
<artwork><![CDATA[ <name>Entry in the "Elective 6LoWPAN Routing Header Type" Registry</name>
Elective 6LoRH Type Value <thead>
+----------------------+--------+ <tr>
| Deadline-6LoRHE | TBD | <th>Value</th>
+----------------------+--------+]]> <th>Description</th>
</artwork> <th>Reference</th>
</figure> </tr>
</t> </thead>
</section> <!-- End of section "IANA Considerations" --> <tbody>
<tr>
<td>7</td>
<td>Deadline-6LoRHE</td>
<td>RFC 9034</td>
</tr>
</tbody>
</table>
</section>
<section title="Synchronization Aspects" anchor="sync"> <section anchor="sync" numbered="true" toc="default">
<t> <name>Synchronization Aspects</name>
<t>
The document supports time representation of the deadline and The document supports time representation of the deadline and
origination times carried in the packets traversing through networks origination times carried in the packets traversing networks
of different time zones having different time synchronization of different time zones having different time-synchronization
mechanisms. For instance, in a 6TiSCH network where the time is mechanisms. For instance, in a 6TiSCH network where the time is
maintained as ASN time slots, the time synchronization is achieved maintained as ASN time slots, the time synchronization is achieved
through beaconing among the nodes as described in through beaconing among the nodes as described in
<xref target="RFC7554"/>. <xref target="RFC7554" format="default"/>.
There could be 6lo networks that employ NTP where the nodes are There 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 The specification of the time-synchronization method that needs to
be followed by a network is beyond the scope of the document. be followed by a network is beyond the scope of the document.
</t> </t>
<!--
Lijo : Needs to work on the syncronization aspect,
@ Charlie, Kindly put your comments.
-->
<t> <t>
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, determines that field allocated to represent the integer number of seconds, determin
the meaning of t_0, i.e., the meaning of DT == 0 in the chosen es
the meaning of t<sub>0</sub>, i.e., the meaning of DT == 0 in the chosen
representation. If DTL == 0, then there are only 4 bits that can 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 be used to count the time units, so that DT == 0 can never be more
than 16 time units (or fractional time units) in the past. This then than 16 time units (or fractional time units) in the past. This then
requires that the time requires that the time
synchronization between sender and receiver has to be tighter than synchronization between sender and receiver has to be tighter than
16 units. If the binary point were moved so that all the bits 16 units. If the binary point were moved so that all the bits
were used for fractional time units (e.g., fractional seconds or were used for fractional time units (e.g., fractional seconds or
fractional ASNs), the time synchronization requirement would be fractional ASNs), the time-synchronization requirement would be
correspondingly tighter. correspondingly tighter.
</t> </t>
<t> <t>
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 <xref target="RFC5905"/> That is enough to represent the NTP 64-bit timestamp format <xref target=
64-bit timestamp format, which is more than enough for the purposes "RFC5905" format="default"/>,
which is more than enough for the purposes
of establishing deadline times. Unless the binary point is moved, of establishing deadline times. Unless the binary point is moved,
this is enough to represent time since year 1900. this is enough to represent time since year 1900.
</t> </t>
<t> <t>
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.75 seconds by quarter-seconds. evenly; then we can count up to 3.75 seconds by quarter-seconds.
<!-- CEP: Deleted in favor of a more rigid mechanism, easier to specify and </t>
implement. <t>
In that case t_0 would be
the most recent second of the current minute that has
t&nbsp;mod&nbsp;4&nbsp;==&nbsp;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.
-->
</t>
<t>
If DTL = 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 256 seconds (in steps of 1/256 of a second). up to 256 seconds (in steps of 1/256 of a second).
</t> </t>
<t> <t>
In all cases, t_0 is defined as specified in <xref target="Format"/> In all cases, t<sub>0</sub> is defined as specified in <xref target="Form
<list> at" format="default"/>.
<t> t_0 = [current_time - (current_time mod (2^(4*(DTL+1))))] </t </t>
>
</list> <t indent="3">t<sub>0</sub> = [current_time - (current_time mod (2<sup>4
*(DTL+1)</sup>))] </t>
<t>
regardless of the choice of TU. regardless of the choice of TU.
</t> </t>
<t> <t>
<!--
The ability to move the binary point doesn't affect the meaning of t_0.
The meaning of t_0 is determined by the range of the integer number of seconds (
in the chosen precision for the DT field).
-->
For TU = 0b00, the time units are seconds. With DTL == 15, For TU = 0b00, the time units are seconds. With DTL == 15,
and Binary Pt == 0, the epoch is (by default) January 1, and BinaryPt == 0, the epoch is (by default) January 1,
1900 at 00:00 UTC. The resolution is then (2 ^ (- 32)) seconds, 1900, at 00:00 UTC. The resolution is then 2<sup>-32</sup> seconds,
which is the maximum possible. which is the maximum possible.
This time format wraps around every 2^32 seconds, which is This time format wraps around every 2<sup>32</sup> seconds, which is
roughly 136 years. roughly 136 years.
</t> </t>
<t> <t>
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. and updated by a mechanism that is out of scope for this document.
With 10 ms slots, DTL = 15, and Binary Pt == 0, it would take over With 10 ms slots, DTL = 15, and BinaryPt == 0, it would take over
a year for the ASN to wrap around. a year for the ASN to wrap around. Typically, the number of hex
<!-- CEP: The number of years is 4294967296 / 3155760000 -->
Typically, the number of hex
digits allocated for TU = 0b10 would be less than 15. digits allocated for TU = 0b10 would be less than 15.
</t> </t>
</section> <!-- End of section "Synchronization Aspects" --> </section>
<section title="Security Considerations"> <section numbered="true" toc="default">
<t> <name>Security Considerations</name>
The security considerations of <xref target="RFC4944"/>, <t>
<xref target="RFC6282"/> and <xref target="RFC6553"/> apply. The security considerations of
Using a compressed format as opposed to the full in-line format is <xref target="RFC4944" section="13" sectionFormat="parens" format="defau
lt"/>,
<xref target="RFC6282" section="6" sectionFormat="parens" format="default
"/>, and
<xref target="RFC6553" section="5" sectionFormat="parens" format="defaul
t"/> apply.
Using a compressed format as opposed to the full inline format is
logically equivalent and does not create an opening for a new threat logically equivalent and does not create an opening for a new threat
when compared to <xref target="RFC6550"/>, <xref target="RFC6553"/> when compared to <xref target="RFC6550" format="default"/>, <xref target=
and <xref target="RFC6554"/>. "RFC6553" format="default"/>,
</t> and <xref target="RFC6554" format="default"/>.
<t> </t>
<t>
The protocol elements specified in this document are designed to work The protocol elements specified in this document are designed to work
in controlled operational environments (e.g., industrial process in controlled operational environments (e.g., industrial process
control and automation). In order to avoid misuse of the deadline control and automation). In order to avoid misuse of the deadline
information that could potentially result in a Denial of Service (DoS) information that could potentially result in a Denial of Service (DoS)
attack, proper functioning of this deadline time mechanism requires attack, proper functioning of this deadline time mechanism requires
the provisioning and management of network resources for supporting the provisioning and management of network resources for supporting
traffic flows with deadlines, performance monitoring, and admission traffic flows with deadlines, performance monitoring, and admission
control policy enforcement. The network provisioning can be done control policy enforcement. The network provisioning can be done
either centrally or in a distributed fashion. For example, tracks in either centrally or in a distributed fashion. For example, tracks in
a 6tisch network could be established by a centralized PCE, as a 6TiSCH network could be established by a centralized Path Computation E
described in the 6tisch architecture lement (PCE), as
<xref target="I-D.ietf-6tisch-architecture"/>. described in the 6TiSCH architecture
</t> <xref target="RFC9030" format="default"/>.
<t> </t>
The Security Considerations of Detnet architecture <t>
<xref target="I-D.ietf-detnet-architecture"/> mostly apply to The security considerations of DetNet architecture
<xref target="RFC8655" section="5" sectionFormat="parens" format="default
"/> mostly apply to
this document as well, as follows. To secure the request and control this document as well, as follows. To secure the request and control
of resources allocated for tracks, authentication and authorization of resources allocated for tracks, authentication and authorization
can be used for each device, and network controller devices. can be used for each device and network controller devices.
In the case of distributed control protocols, security is expected In the case of distributed control protocols, security is expected
to be provided by the security properties of the protocols in use. to be provided by the security properties of the protocols in use.
</t> </t>
<t> <t>
When deadline bearing flows are identified on a per-flow basis, which The identification of deadline-bearing flows on a per-flow basis
may provide attackers with additional information about the data flows, may provide attackers with additional information about the data
when compared to networks that do not include per-flow identification. flows compared to networks that do not include per-flow
The security implications of disclosing that additional information identification. The security implications of disclosing that additiona
deserve consideration when implementing this deadline specification. l
</t> information deserve consideration when implementing this deadline
<t> specification.
</t>
<t>
Because of the requirement of precise time synchronization, the Because of the requirement of precise time synchronization, the
accuracy, availability, and integrity of time synchronization is of accuracy, availability, and integrity of time synchronization is of
critical importance. Extensive discussion of this topic can be found critical importance. Extensive discussion of this topic can be found
in <xref target="RFC7384"/>. in <xref target="RFC7384" format="default"/>.
</t> </t>
<!--
Lijo : Added above paragraphs
-->
</section> <!-- End of section "Security Considerations" -->
<section title="Acknowledgements"> </section>
<t>
The authors thank Pascal Thubert for suggesting the idea and
encouraging the work. Thanks to Shwetha Bhandari's suggestions which
were instrumental in extending the timing information to heterogeneous
networks. The authors acknowledge the 6TiSCH WG members for their
inputs on the mailing list. Special thanks to
Jerry Daniel,
Dan Frost (Routing Directorate)
Charlie Kaufman (Security Directorate)
Seema Kumar,
Tal Mizrahi
Avinash Mohan,
Shalu Rajendran,
Anita Varghese,
and Dale Worley (Gen-ART review)
for their support and valuable feedback.
</t>
</section> <!-- End of section "Acknowledgements" -->
</middle> </middle>
<back>
<back> <!-- *****BACK MATTER ***** --> <displayreference target="I-D.ietf-ippm-ioam-data" to="IOAM-DATA"/>
<!-- References split into informative and normative --> <displayreference target="I-D.ietf-6lo-blemesh" to="6LO-BLEMESH"/>
<!-- There are 2 ways to insert reference entries from the citation
libraries:
1. define an ENTITY at the top, and use "ampersand character" RFC2629;
here (as shown)
2. simply use a PI "less than character"?rfc
include="reference.RFC.2119.xml"?> here
(for I-Ds:
include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included
files in the same directory as the including file. You can also define
the XML_LIBRARY environment variable with a value containing a set of
directories to search. These can be either in the local filing system
or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<?rfc include="reference.I-D.ietf-6tisch-terminology" ?>
<?rfc include="reference.I-D.ietf-roll-routing-dispatch" ?>
<?rfc include="reference.I-D.ietf-detnet-architecture" ?>
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.4944'?>
<?rfc include='reference.RFC.5905'?>
<?rfc include='reference.RFC.6282'?>
<?rfc include='reference.RFC.6550'?>
<?rfc include='reference.RFC.6553'?>
<?rfc include='reference.RFC.6554'?>
<?rfc include='reference.RFC.7384'?>
<?rfc include='reference.RFC.7554'?>
<?rfc include='reference.RFC.8138'?>
<?rfc include='reference.RFC.8174'?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.ietf-6tisch-architecture" ?>
<!-- <references>
- IEEE Standard for Local and metropolitan area networks - Part 15.4, - <name>References</name>
IEEE Std 802.15.42015, 2015. <references>
<name>Normative References</name>
IEEE Standard for Low-Rate Wireless Networks," in IEEE Std 802.15.4-2015 (Revisi <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
on of IEEE Std 802.15.4-2011) , vol., no., pp.1-709, April 22 2016 ence.RFC.9030.xml"/>
doi: 10.1109/IEEESTD.2016.7460875 <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
--> ence.RFC.8655.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4944.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5905.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6282.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6550.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6553.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6554.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7384.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7554.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8138.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8174.xml"/>
</references>
<references>
<name>Informative References</name>
<reference anchor="dot15-tsch"> <reference anchor="IEEE.802.15.4"
target="https://ieeexplore.ieee.org/document/7460875">
<front> <front>
<title>IEEE Standard for Low-Rate Wireless Networks, <title>IEEE Standard for Low-Rate Wireless Networks</title>
Part 15.4, IEEE Std 802.15.4-2015</title> <author>
<author surname="P802.11"> <organization>IEEE</organization>
<organization>"IEEE 802 Wireless"</organization> </author>
<date month="April" year="2016"/>
<address>
</address>
</author>
<date month="April" year="2016"/>
</front> </front>
<seriesInfo name="IEEE Standard" value="802.15.4-2015"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2016.7460875"/>
</reference> </reference>
<!-- <reference anchor="IEEE.1588.2008">
@INPROCEEDINGS{Lee02ieee-1588standard, <front>
author = {Kang Lee and John Eidson}, <title>IEEE Standard for a Precision Clock
title = {IEEE-1588 Standard for a Precision Clock Synchronization Protocol f
or Networked Measurement and Control Systems},
booktitle = {In 34 th Annual Precise Time and Time Interval (PTTI) Meeting},
year = {2002},
pages = {98 thru 105}
}
-->
<reference anchor="ieee-1588">
<front>
<title>IEEE Std 1588-2008 Standard for a Precision Clock
Synchronization Synchronization
Protocol for Networked Measurement and Control Systems</title> Protocol for Networked Measurement and Control Systems</title>
<author>
<organization>IEEE</organization>
</author>
<date month="July" year="2008"/>
</front>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2008.4579760"/>
</reference>
<author surname="Precise Time and Time Interval Working Group"> <reference anchor="IEEE-BLE-MESH">
<organization>"IEEE Standards"</organization> <front>
<title>
<address>
</address>
</author>
<date month="July" year="2008"/>
</front>
</reference>
<!-- New: Donald E. Eastlake comments -> dotBLEMesh . -->
<!-- Lijo : Is this reference, Okay -->
<reference anchor="dotBLEMesh">
<front>
<title>
Multi-Hop Real-Time Communications Over Bluetooth Low Energy Multi-Hop Real-Time Communications Over Bluetooth Low Energy
Industrial Wireless Mesh Networks Industrial Wireless Mesh Networks
</title> </title>
<author fullname="Luca Leonardi" initials="L." surname="Leonardi">
<author fullname="Luca Leonardi" initials="L." surname="Leonardi"> <organization> </organization>
<organization> </organization> </author>
<address> <author fullname="Gaetano Patti" initials="G." surname="Patti">
</address> <organization> </organization>
</author> </author>
<author fullname="Lucia Lo Bello" initials="L." surname="Lo Bello">
<author fullname="Gaetano Pattim" initials="G." surname="Pattim"> <organization> </organization>
<organization> </organization> </author>
<address> <date month="May" year="2018"/>
</address> </front>
</author> <refcontent>IEEE Access, Vol 6, pp. 26505-26519</refcontent>
<seriesInfo name="DOI" value="10.1109/ACCESS.2018.2834479"/>
<author fullname="Lucia Lo Bello" initials="L." surname="Lo Bello"> </reference>
<organization> </organization>
<address>
</address>
</author>
<date month="May" year="2018" />
</front>
<seriesInfo name="IEEE Access"
value="Vol 6, 26505-26519"/>
</reference>
<reference anchor="dot1AS-2011"> <reference anchor="IEEE.802.1AS.2011">
<front> <front>
<title>IEEE Standard for Local and Metropolitan Area Networks - <title>IEEE Standard for Local and Metropolitan Area Networks -
Timing and Synchronization for Time-Sensitive Applications Timing and Synchronization for Time-Sensitive Applications
in Bridged Local Area Networks in Bridged Local Area Networks
</title> </title>
<author surname="IEEE 802.1AS Working Group"> <author surname="IEEE 802.1AS Working Group">
<organization>"IEEE Standards"</organization> <organization>IEEE</organization>
</author>
<address> <date month="March" year="2011"/>
</address> </front>
</author> <refcontent>IEEE Std 802.1AS-2011</refcontent>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2011.5741898"/>
<date month="March" year="2011"/> </reference>
</front>
</reference>
<reference anchor="Wi-SUN_PHY">
<front>
<title>Wi-SUN PHY Specification V1.0</title>
<author>
<organization>Wi-SUN Alliance</organization>
</author>
<date month="March" year="2016"></date>
</front>
</reference>
<!--
<title> Wi-SUN is a wireless communication technology designed for Uti
lities, Smart Cities and IoT. Wi-SUN is based on various IEEE, IETF, and NSI/TI
A standards supporting low power and lossy networks.</title>
-->
<!--
Hiroshi Harada et al,
"IEEE 802.15.4g Based Wi-SUN Communication Systems",
IEICE Transactions on Communications.
@article{article,
author = {Harada, Hiroshi and Mizutani, Keiichi and FUJIWARA, Jun and MOCHIZUKI,
Kentaro and OBATA, Kentaro and Okumura, Ryota},
year = {2017},
month = {01},
pages = {},
title = {IEEE 802.15.4g based Wi-SUN communication systems},
volume = {E100.B},
booktitle = {IEICE Transactions on Communications}
}
<author fullname="Luca Leonardi" initials="L." surname="Leonardi">
-->
<reference anchor="dotWi-SUN">
<front>
<title>IEEE 802.15.4g Based Wi-SUN Communication Systems</title>
<author fullname="Hiroshi Harada" initials="H." surname="Harada">
<organization> </organization>
<address>
</address>
</author>
<author fullname="Keiichi Mizutani" initials="K." surname="Mizutani">
<organization> </organization>
<address>
</address>
</author>
<author fullname="Jun Fujiwara" initials="J." surname="Fujiwara">
<organization> </organization>
<address>
</address>
</author>
<author fullname="Kentaro Mochizuki" initials="K."
surname="Mochizuki">
<organization> </organization>
<address>
</address>
</author>
<author fullname="Kentaro Obata" initials="K." surname="Obata">
<organization> </organization>
<address>
</address>
</author>
<author fullname="Ryota Okumura" initials="R." surname="Okumura">
<organization> </organization>
<address>
</address>
</author>
<date month="Jan" year="2017"/> <reference anchor="PHY-SPEC" target="http://wi-sun.org">
</front> <front>
<seriesInfo name="IEICE Transactions on Communications" <title>Wi-SUN PHY Specification V1.0</title>
value="volume E100.B"/> <author>
</reference> <organization>Wi-SUN Alliance</organization>
</author>
<date month="March" year="2016"/>
</front>
</reference>
<?rfc include="reference.I-D.ietf-ippm-ioam-data" ?> <reference anchor="Wi-SUN">
<?rfc include="reference.I-D.ietf-detnet-use-cases" ?> <front>
<?rfc include="reference.I-D.ietf-6lo-backbone-router" ?> <title>IEEE 802.15.4g Based Wi-SUN Communication Systems</title>
<?rfc include="reference.I-D.ietf-roll-useofrplinfo" ?> <author fullname="Hiroshi Harada" initials="H." surname="Harada">
<?rfc include="reference.I-D.ietf-6lo-blemesh" ?> <organization> </organization>
</references> </author>
<author fullname="Keiichi Mizutani" initials="K." surname="Mizutani"
>
<organization> </organization>
</author>
<author fullname="Jun Fujiwara" initials="J." surname="Fujiwara">
<organization> </organization>
</author>
<author fullname="Kentaro Mochizuki" initials="K." surname="Mochizuk
i">
<organization> </organization>
</author>
<author fullname="Kentaro Obata" initials="K." surname="Obata">
<organization> </organization>
</author>
<author fullname="Ryota Okumura" initials="R." surname="Okumura">
<organization> </organization>
</author>
<date month="January" year="2017"/>
</front>
<refcontent>IEICE Transactions on Communications</refcontent>
<refcontent>Volume E100.B, Issue 7, pp. 1032-1043</refcontent>
<seriesInfo name="DOI" value="10.1587/transcom.2016SCI0002"/>
</reference>
<section title="Changes from revision 04 to revision 05" <reference anchor="I-D.ietf-ippm-ioam-data">
anchor="changes_04_05"> <front>
<t> <title>Data Fields for In-situ OAM</title>
This section lists the changes between draft-ietf-6lo-deadline-time <author initials="F." surname="Brockners" fullname="Frank Brockners" role="edito
revisions ...-04.txt and ...-05.txt. r">
<list style="symbols"> <organization>Cisco Systems, Inc.</organization>
<t> </author>
Included additional relevant material in Security Considerations <author initials="S." surname="Bhandari" fullname="Shwetha Bhandari" role="edit
regarding expected deployment scenarios and the effect of or">
disclosing additional information during the travel of a packet. <organization>Thoughtspot</organization>
</t> </author>
<t> <author initials="T." surname="Mizrahi" fullname="Tal Mizrahi" role="editor">
Reworked the specification for using time ranges shorter than the <organization>Huawei</organization>
maximum allowed by the choice of TU, so that fewer bits are needed </author>
to represent DT and OT. <date month="February" day="21" year="2021"/>
</t> </front>
<t> <seriesInfo name="Internet-Draft" value="draft-ietf-ippm-ioam-data-12"/>
Revised the figures and examples to use new parameters <format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-ippm-ioam-
</t> data-12.txt"/>
<t> </reference>
Reordered the field definitions for the Deadline-6LoRHE.
</t>
<t>
Responded to numerous reviewer comments to improve terminology
and editorial consistency.
</t>
</list></t>
</section> <!-- End of section "Changes from revision 04 to revision 05" -->
<section title="Changes from revision 03 to revision 04" <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
anchor="changes_03_04"> ence.RFC.8578.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8929.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.9008.xml"/>
<t> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
This section lists the changes between draft-ietf-6lo-deadline-time .ietf-6lo-blemesh-10.xml"/>
revisions ...-03.txt and ...-04.txt.
<list style="symbols">
<t>
Replaced OT (Origination Time) field by OTD (Origination Time
Delta), allowing a more compressed representation that needs
less processing during transitions between networks.
</t>
<t>
Changed representation for DTL, OTL, DT, OTD. Eliminated
EXP in favor of BinaryPt.
</t>
<t>
Revised the figures and examples to use new parameters
</t>
<t>
Added new section on Synchronization Aspects to supply pertinent
information about how nodes agree on the meaning of t=0.
</t>
<t>
Responded to numerous reviewer comments to improve editorial
consistency and improve terminology.
</t>
</list></t>
</section> <!-- End of section "Changes from revision 03 to revision 04" -->
<section title="Changes from revision 02 to revision 03" </references>
anchor="changes_02_03"> </references>
<t> <section anchor="modular" title="Modular Arithmetic Considerations">
This section lists the changes between draft-ietf-6lo-deadline-time
revisions ...-02.txt and ...-03.txt.
<list style="symbols">
<t>
Added non-normative 6LoRHE description, citing RFC 8138.
</t>
<t>
Specified that the Origination Time (OT) is the time that packet
is enqueued for transmission.
</t>
<t>
Mentioned more sources of packet delay.
</t>
<t> <t>
Clarified reasons that packet MAY be forwarded if 'D' bit is 0. Graphically, one might visualize the timeline as follows:
</t> </t>
<figure anchor="fig7" title="Absolute Timeline Representation">
<artwork><![CDATA[
OT_abs CT_abs DT_abs
-------|-------------|-------------|------------------>]]>
</artwork>
</figure>
<t> <t>
Clarified that DT, OT, DTL and OTL are unsigned integers. In <xref target="fig7"/>, the value of CT_abs is envisioned
as traveling to the right as time progresses, getting farther away
from OT_abs and getting closer to DT_abs. The timeline is considered
to be subdivided into time subintervals [i,j] starting and ending at
absolute times equal to k*(2^N), for integer values of k. Let
I_k = k*(2^N) and I_(k+1) = (k+1)*2^N. Intervals starting at I_k
and I_(k+1) may occur at various placements in the above timeline.
Even though OT_abs is <em>always</em> less than DT_abs, it could be that
DT &lt; OT because of the way that DT and OT are represented within
the range [0, 2^N) and similarly for CT_abs and CT compared to OT and DT.
</t> </t>
<t> <t>
Updated bibliographic citations, including BLEmesh and Wi-SUN. Representing the above situation in time segments of length 2^N
(and values OT, CT, DT) results in several cases where the deadline
time has not elapsed:
</t> </t>
</list></t> <dl>
</section> <!-- End of section "Changes from revision 02 to revision 03" --> <dt> 1) OT &lt; CT &lt; DT </dt>
<dd> (e.g., I_k &lt; OT_abs &lt; CT_abs &lt; DT_abs &lt; I_(k+1) )
</dd>
<section title="Changes from revision 01 to revision 02" <dt> 2) DT &lt; OT &lt; CT </dt> <dd>(e.g., I_k &lt; OT_abs &lt; CT_abs
anchor="changes_01_02"> &lt; I_(k+1) &lt; DT_abs ) </dd>
<dt> 3) CT &lt; DT &lt; OT </dt> <dd> (e.g., I_k &lt; OT_abs &lt; I_(k+1
) &lt; CT_abs &lt; DT_abs ) </dd>
</dl>
<t>
In the following cases, the deadline time has elapsed and the
packet should be dropped.
</t>
<dl>
<dt> 4) DT &lt; CT &lt; OT </dt> <dd></dd>
<dt> 5) OT &lt; DT &lt; CT </dt> <dd></dd>
<dt> 6) CT &lt; OT &lt; DT </dt> <dd></dd>
</dl>
<t>
This section lists the changes between draft-ietf-6lo-deadline-time
revisions ...-01.txt and ...-02.txt.
<list style="symbols">
<t> <t>
Replaced 6LoRHE description by reference to RFC 8138. Again in <xref target="fig7"/>, consider CT_abs as time
moving away from OT_abs and towards DT_abs.
For times CT_abs before the expiration of the deadline time, we also
have CT_abs - OT_abs == CT - OT mod 2^N and similarly for DT_abs -
CT_abs.
</t> </t>
<t> <t>
Added figure to illustrate change to Origination Time when a As time proceeds, DT_abs - CT_abs gets smaller. When the deadline time
packet crosses timezone boundaries. expires, DT_abs - CT_abs begins to grow negative. A proper selection
for SAFETY_FACTOR allows it to go
<em>slightly negative</em> but for an intermediate point to <em>detect</e
m> that it
has gone negative.
Note that in modular arithmetic, "slightly negative" means <em>exactly</e
m>
the same as "almost as large as the modulus (i.e., 2^N)".
Now consider the test condition
((CT - DT) mod 2^N) > SAFETY_FACTOR*2^N.
</t> </t>
<t> <t>
Clarified that use of 6tisch networks is descriptive, not normative. (DT_abs - OT_abs) &lt; 2^N*(1-SAFETY_FACTOR) satisfies the test
condition when CT_abs == OT_abs (i.e., when the packet is launched).
In modular arithmetic, 2^N*(1-SAFETY_FACTOR) ==
2^N - 2^N*SAFETY_FACTOR == -2^N*(SAFETY_FACTOR).
Then DT_abs - OT_abs &lt; -2^N*(1-SAFETY_FACTOR).
Inverting the inequality,
OT_abs - DT_abs > 2^N*(1-SAFETY_FACTOR), and thus at
launch CT_abs - DT_abs > 2^N*(1-SAFETY_FACTOR).
</t> </t>
<t> <t>
Clarified that In-Band OAM is used as an example and is not normative. As CT_abs grows larger, CT_abs - DT_abs gets LARGER in (non-negative)
modular arithmetic until the time at which CT_ABS == DT_ABS, and
suddenly CT_ABS - DT_abs becomes zero. Also suddenly, the test
condition is no longer fulfilled.
</t> </t>
<t> <t>
Updated bibliographic citations. As CT_abs grows still larger, CT_abs > DT_abs, and we need to detect
this condition as soon as possible. Requiring the SAFETY_FACTOR
enables this detection until CT_abs exceeds DT_abs
by an amount equal to SAFETY_FACTOR*2^N.
</t> </t>
<t> <t>
Alphabetized contributor names. A note about "inverting the inequality". Observe that a &lt; b
implies that -a > -b on the real number line. Also,
(a - b) == -(b - a). These facts hold also for modular arithmetic.
</t> </t>
</list></t>
</section> <!-- End of section "Changes from revision 01 to revision 02" -->
<section title="Changes between earlier versions"
anchor="older_changes">
<t>
This section lists the changes between draft-ietf-6lo-deadline-time
revisions ...-00.txt and ...-01.txt.
<list style="symbols">
<t> <t>
Changed "SHOULD drop" to "MUST drop" a packet if the deadline is During the times prior to the expiration of the deadline, for
passed (see <xref target="Format"/>). Safe = 2^N*SAFETY_FACTOR we have:
</t> </t>
<t> <t indent="6">
Added explanatory text about how packet delays might arise. (DT_abs - 2^N) &lt; OT_abs &lt; CT_abs &lt; DT_abs &lt; DT_abs+Safe
(see <xref target="Description"/>).
</t> </t>
<t> <t>
Mentioned availability of time-synchronization protocols Naturally, DT_abs - 2^N == DT_abs mod 2^N == DT.
(see <xref target="Intro"/>).
</t> </t>
<t> <t>
Updated bibliographic citations. Again considering <xref target="fig7"/>, it is easy to see
that {CT_abs - (DT_abs - 2^N)} gets larger and larger until the time
at which CT_abs = DT_abs, which is the first time at which
CT - DT == 0 mod 2^N. As CT_abs increases past the deadline time,
0 &lt; CT_abs - DT_abs &lt; Safe. In this range, any intermediate
node can detect that the deadline has expired. As CT_abs increases
past DT_abs+Safe, it is no longer possible for an intermediate node
to determine with certainty whether or not the deadline time has
expired. These statements
also apply when reduced to modular arithmetic in the modulus 2^N.
</t> </t>
<t> <t>
Alphabetized contributor names. In particular, the test condition no longer allows
detection of deadline expiration when the current
time becomes later than (DT_abs+Safe). In order to maintain
correctness even for packets that are forwarded after expiration
(i.e., the 'D' flag), N has to be chosen to be so large that
the test condition will not fail -- i.e., that in all scenarios
of interest, the packet will be dropped before the current time
becomes equal to DT_abs+2^N*SAFETY_FACTOR.
</t> </t>
<t> </section>
Added this section.
</t>
</list></t> <section numbered="false" toc="default">
</section> <name>Acknowledgments</name>
<t>
The authors thank <contact fullname="Pascal Thubert"/> for suggesting the
idea and
encouraging the work. Thanks to <contact fullname="Shwetha Bhandari"/>'s
suggestions, which
were instrumental in extending the timing information to heterogeneous
networks. The authors acknowledge the 6TiSCH WG members for their
inputs on the mailing list. Special thanks to
<contact fullname="Jerry Daniel"/>,
<contact fullname="Dan Frost"/> (Routing Directorate),
<contact fullname="Charlie Kaufman"/> (Security Directorate),
<contact fullname="Seema Kumar"/>,
<contact fullname="Tal Mizrahi"/>,
<contact fullname="Avinash Mohan"/>,
<contact fullname="Shalu Rajendran"/>,
<contact fullname="Anita Varghese"/>, and
<contact fullname="Dale Worley"/> (General Area Review Team (Gen
-ART) review)
for their support and valuable feedback.
</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 177 change blocks. 
947 lines changed or deleted 914 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/