<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. --> encoding="UTF-8"?>

<!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-considerations-rfc2434bis.xml">

]>
<?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 --> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
     submissionType="IETF"
     category="std"
     consensus="true"
     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=1426658395147
	        ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN"
     they will automatically be output with "(if approved)" -->
     number="9034"
     ipr="trust200902"
     obsoletes=""
     updates=""
     xml:lang="en"
     tocInclude="true"
     tocDepth="2"
     symRefs="true"
     sortRefs="true"
     version="3">

  <!-- ***** FRONT MATTER ***** xml2rfc v2v3 conversion 2.47.0 -->

<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">
	Packet Delivery Deadline time Time in 6LoWPAN the Routing Header </title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor --> IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)</title>
	<seriesInfo name="RFC" value="9034"/>

   <author fullname="Lijo Thomas" initials="" surname="Lijo Thomas">
      <organization>C-DAC</organization>
      <address>
        <postal>
        <street>Centre initials="L." surname="Thomas">
      <organization abbrev="C-DAC">Centre for Development of Advanced Computing (C-DAC),
	      Vellayambalam</street>
          <!-- Reorder these if your country does things differently --> Computing</organization>
      <address>
        <postal>
          <street>Vellayambalam</street>
          <city>Trivandrum</city>
          <region/>
          <code>695033</code>
          <country>India</country>
        </postal>
        <phone/>
        <email>lijo@cdac.in</email>
        <!-- uri and facsimile elements may also be added -->

      </address>
    </author>
    <author fullname="Satish Anamalamudi" initials="S." surname="Anamalamudi">
      <organization>SRM University-AP</organization>
      <address>
        <postal>
          <street>Amaravati Campus</street>
          <!-- Reorder these if your country does things differently -->
          <city>Amaravati, Andhra Pradesh</city>
          <region/>
          <code>522 502</code>
          <country>India</country>
        </postal>
        <phone/>
        <email>satishnaidu80@gmail.com</email>
        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>
   <author fullname="S.V.R fullname="S.V.R. Anand" initials="" surname="S.V.R.Anand"> initials="S.V.R." surname="Anand">
      <organization>Indian Institute of Science</organization>
      <address>
        <postal>
          <street></street>
          <!-- Reorder these if your country does things differently -->
          <city>Bangalore</city>
          <region/>
          <code>560012</code>
          <country>India</country>
        </postal>
        <phone/>
        <email>anand@ece.iisc.ernet.in</email>
        <!-- uri and facsimile elements may also be added -->
        <email>anandsvr@iisc.ac.in</email>

      </address>
    </author>
   <author fullname="Malati Hegde" initials="" surname="Malati Hegde"> initials="M." surname="Hegde">
      <organization>Indian Institute of Science</organization>
      <address>
        <postal>
          <street></street>
          <!-- Reorder these if your country does things differently -->
          <city>Bangalore</city>
          <region/>
          <code>560012</code>
          <country>India</country>
        </postal>
        <phone/>
        <email>malati@ece.iisc.ernet.in</email>
        <!-- uri and facsimile elements may also be added -->
        <email>malati@iisc.ac.in</email>
      </address>
    </author>

    <author fullname="Charles E. Perkins" initials="C.E." initials="C." surname="Perkins">
      <organization>Futurewei</organization>
      <organization>Lupin Lodge</organization>
      <address>
        <postal>
          <street>2330 Central Expressway</street>
          <!-- Reorder these if your country does things differently -->
          <city>Santa Clara</city>
          <region/>
          <code>95050</code>
          <country>Unites States</country>
          <street>20600 Aldercroft Heights Rd.</street>
          <city>Los Gatos</city>
          <region>CA</region>
          <code>95033</code>
          <country>United States of America</country>
        </postal>
        <phone/>
        <email>charliep@computer.org</email>
        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>
    <date year="2021" month="June" />

    <!-- 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>

    <workgroup>6lo</workgroup>

    <!-- WG name at the upperleft corner of the doc;
         IETF is fine for individual submissions.  If this element is not
         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>
    <t>
	This document specifies a new type for

    <area>Internet</area>
    <workgroup>6lo</workgroup>

    <keyword>Routing header</keyword>
    <keyword>Timestamp</keyword>

    <abstract>

      <t>
	This document specifies a new type for the 6LoWPAN routing header
	containing the deadline time for data packets, designed for use over
	constrained networks. The deadline time enables forwarding and
	scheduling decisions for time critical IoT machine to machine time-critical machine-to-machine (M2M)
	applications that operate within time-synchronized networks that agree running on the meaning of the time representations used for the deadline
	time values.
    </t>
<!--  Lijo : Eric Vyncke Comment:  "Last sentence needs to be parsed as it very long" -->
<!--  Lijo : Suggested Change : "that Internet-enabled devices that operate within
	time-synchronized networks. his This document also specifies the time a
	representation -->
<!--                       that needs to be followed by such networks for the deadline time values.. " -->
<!--  Lijo : @Charlie : Should we expand M2M based on eric comment ?--> values in such networks.
      </t>

    </abstract>
  </front>
  <middle>
    <section title="Introduction" anchor="Intro"> anchor="Intro" numbered="true" toc="default">
      <name>Introduction</name>
      <t>
	Low Power
	Low-Power and Lossy Networks (LLNs) are likely to be deployed for
	real time
	real-time industrial applications requiring end-to-end
	delay guarantees <xref target="I-D.ietf-detnet-use-cases"/>. target="RFC8578" format="default"/>.
	A Deterministic Network ("detnet") ("DetNet") typically requires some data packets
	to reach their receivers within strict time bounds.
	Intermediate nodes use the deadline information to make
        appropriate packet forwarding and scheduling decisions to meet the
        time bounds.
      </t>
      <t>
	This document specifies a new type for the Elective 6LoWPAN Routing
	Header (6LoRHE), Deadline-6LoRHE, so that the deadline time (i.e., the time of latest
	acceptable delivery) of data
	packets can be included within the 6LoWPAN routing header. 6LoRHE.
	<xref target="RFC8138"/> target="RFC8138" format="default"/> specifies the 6LoWPAN Routing Header (6LoRH),
	compression schemes for RPL (Routing Protocol for Low-Power and Lossy Networks) source routing (source routing) operation <xref target="RFC6554"/>, target="RFC6554" format="default"/>, header compression of RPL Packet
	Information packet
	information <xref target="RFC6553"/>, target="RFC6553" format="default"/>, and IP-in-IP encapsulation.
	This document also specifies the handling of the deadline
	time when packets traverse between time-synchronized networks
	operating in different timezones time zones or distinct reference clocks.
	Time synchronization
	Time-synchronization techniques are outside the scope of this
	document.  There are a number of standards available for this
	purpose, including IEEE 1588 <xref target="ieee-1588"/>, target="IEEE.1588.2008" format="default"/>,
	IEEE 802.1AS <xref target="dot1AS-2011"/>, target="IEEE.802.1AS.2011" format="default"/>,
	IEEE 802.15.4-2015 TSCH Time-Slotted Channel Hopping (TSCH) <xref target="dot15-tsch"/>, target="IEEE.802.15.4" format="default"/>, and more.
      </t>
	<!--  Lijo : Eric Vyncke Comment:  "does 'time zone' in this document does not refer to EST.." -->
	<!--  Lijo :suggestion:  "time-synchronized networks operating over distinct reference clocks resulting in different timezones." -->
    <t>
	The Deadline-6LoRHE can be used in any time synchronized 6Lo time-synchronized 6LoWPAN network.
	A 6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4) network is used to describe the implementation of the
	Deadline-6LoRHE, but this does not preclude its use in scenarios other
	than 6TiSCH.  For instance, there is a growing interest in using 6lo 6LoWPAN
	over a BLE Bluetooth Low Energy (BLE) mesh network <xref target="I-D.ietf-6lo-blemesh"/> target="I-D.ietf-6lo-blemesh" format="default"/> in
	industrial IoT (Internet of Things) <xref target="dotBLEMesh"/>. target="IEEE-BLE-MESH" format="default"/>. BLE mesh time
	synchronization is being explored by the Bluetooth
	community.  There are also cases under consideration in Wi-SUN
	<xref target="Wi-SUN_PHY"/>, target="PHY-SPEC" format="default"/> <xref target="dotWi-SUN"/>. target="Wi-SUN" format="default"/>.
      </t>
    </section>	<!-- End of section "Introduction" -->

<section anchor="acronyms_terms" title="Terminology"> numbered="true" toc="default">
      <name>Terminology</name>

        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
	"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
	"MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>.
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
        </t>

      <t>
	This document uses the terminology defined in
	<xref target="RFC6550"/> target="RFC6550" format="default"/> and
	<xref target="I-D.ietf-6tisch-terminology"/>. target="RFC9030" format="default"/>.
      </t>
    </section>	<!-- End of section "Terminology" -->

<section title="6LoRHE numbered="true" toc="default">
      <name>6LoRHE Generic Format"> Format</name>
      <t>
	Note: this section is not normative and is included for convenience.
	The generic header format of the 6LoRHE is specified in
	<xref target="I-D.ietf-roll-routing-dispatch"/>. target="RFC8138" format="default"/>.
	<xref target="fig1"/> target="fig1" format="default"/> illustrates the 6LoRHE generic format.
      </t>
      <figure anchor="fig1" title="6LoRHE format">
             <artwork><![CDATA[ anchor="fig1">
        <name>6LoRHE Format</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
   0                   1
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-        ...              -+
  |1|0|1| Length  |      Type     |        Options            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-        ...              -+
                                   <---    length         --->]]>
             </artwork>         --->
]]></artwork>
      </figure>

<!--  Lijo : Eric Vyncke Comment: Added "Options" in above figure . DONE -->
	<list style="symbols">
	<t> Length: Length

<dl>
   <dt>Length:</dt>
   <dd>Length of the 6LoRHE expressed in bytes, excluding the first 2 bytes. This
       enables a node to skip a 6LoRHE if the Type is not recognized/supported.</t>
	<t> Type recognized or supported.</dd>
   <dt>Type (variable length): Type length):</dt>
   <dd>Type of the 6LoRHE (see <xref target="iana"/>)</t>
	</list>
    </t> target="iana" format="default"/>).</dd>
</dl>

    </section>	<!-- End of section "6LoRHE Header Format" -->

<section title="Deadline-6LoRHE"  anchor="Description"> anchor="Description" numbered="true" toc="default">
      <name>Deadline-6LoRHE</name>
      <t>
	    The Deadline-6LoRHE (see <xref target="fig2"/>) target="fig2" format="default"/>) is an elective
	    6LoRH (i.e.,
	    a 6LoRHE <xref target="RFC8138"/>) target="RFC8138" format="default"/> that provides
	    the Deadline Time (DT) for an IPv6 datagram in a compressed form.
	    Along with the deadline, DT, the header can include the packet
	    Origination Time Delta (OTD), (OTD) packet, which contains the time at which when the packet is was
	    enqueued for transmission (expressed as a value 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 sender
	    based on the current time at the outgoing network interface through
	    which the packet is forwarded.  Since the OTD is a delta,
	    the length of the OTD field (i.e., OTL) will require fewer
	    bits than the length of the DT field (i.e., DTL).
      </t>

<!--  Lijo : Mirja Kuhlewind Comment Changed  SHOULD to should  -->
	<t> The deadline DT field contains the value of the deadline time for the
	    packet -- in other words, the time by which the application expects
	    the packet to be delivered to the Receiver.

<?rfc subcompact="yes" ?>
	<list>
	<t> receiver.
      </t>
      <t indent="3">
        packet_deadline_time = packet_origination_time + max_delay
      </t>
	</list>
<?rfc subcompact="no" ?>
	</t>
      <t>
<!--  Lijo : Mirja Kuhlewind Comment: Change  "SHOULD" to should,  -->
	    In order to support delay-sensitive delay-sensitive, deterministic applications,
	    all nodes within the network should process the Deadline-6LoRHE.
	    The packet deadline time (DT) DT and origination time (OTD) OTD packets are
	    represented in time units determined by a scaling parameter in
	    the routing header. Routing Header.  The Network ASN (Absolute Slot Number)
	    can be used as a time unit in a time slotted time-slotted
            synchronized network (for instance instance, a 6TiSCH network, where global
	    time is maintained in the units of slot lengths of a certain
            resolution).
      </t>
      <t> The delay experienced by packets in the network is a useful
	    metric for network diagnostics and performance monitoring.
	    Whenever a packet crosses into a network using
	    a different reference clock, the Destination Time DT field is updated
	    to represent the same Destination Time, deadline time, but expressed using the
	    reference clock of the interface into the new network.  Then the
	    origination time is the same as the current time when the packet
	    is transmitted into the new network, minus the delay already
	    experienced by the packet, say 'current_dly'.  In this way, within
	    the newly entered network, the packet will appear to have
	    originated 'current_dly' time units earlier with respect
	    to the reference clock of the new network.</t>
	<t>

<t indent="3">
	 new_network_origin_time = time_now_in_new_network - current_dly
</t>
      <t>
	    The following example illustrates these calculations
	    when a packet travels between three networks, each in a different
	    time zone. zone (TZ). 'x' can be 1, 2 2, or 3.  Suppose that the deadline time
	    as measured in timezone 1 TZ1 is 1050 1050, and the origination time is 50.
	    Suppose that the difference between TZ2 and TZ1 is 900, and the
	    difference between TZ3 TZ2 and TZ3 is 3600.  In the figure, OT
	    is the origination time as measured in the current timezone, time zone, and
	    is equal to DT - OTD, that is, DT - 1000.
	    <xref target="time-update"/> target="time-update" format="default"/> uses the following abbreviations:
	    <list>
	    <t>TxA  : Time
      </t>

  <dl>
     <dt>TxA:</dt>
     <dd>Time of arrival of packet in the network 'x'</t>
	    <t>TxD  : Departure 'x' </dd>
     <dt>TxD:</dt>
     <dd>Departure time of packet from the network 'x'</t>
	    <t>dlyx : Delay 'x' </dd>
     <dt>dlyx:</dt>
     <dd>Delay experienced by the packet in the previous network(s)</t>
	    <t>TZx  : The network(s) </dd>
     <dt>TZx:</dt>
     <dd>The time zone of network 'x' </t>
	    </list>
	</t>
	<t> </dd>
  </dl>

      <figure title="Destination anchor="time-update">
        <name>Deadline Time Update example" anchor="time-update">
<artwork> <![CDATA[ Example</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
            TZ1                      TZ2                    TZ3
  T1A=50|                 |                             |
        |----  dly1=50    |                             |
        |     \           |                             |
        |      \          |                             |
        |       \ T1D=100 |T2A=1000                     |
        |        -------->|-----           dly2=450     |
        |                 |     \                       |
        |                 |      \                      |
        |                 |       \          T2D=1400   | T3A=5000
        |                 |         ------------------->|---------->
        |                 |                             |
        v                 v                             v

   dly0 = 0          dly1 = T1D-OT1      dly2 = T2D-OT2
                          = 100-50            = 1400 - 950
                          = 50                = 450

   OT1 = T1A-dly0     OT2 = T2A-dly1     OT3 = T3A-dly2
       = 50               = 1000-50          = 5000 - 450
                          = 950              = 4550
]]></artwork>
      </figure>
    </t>
      <t> There are multiple ways that a packet can be delayed, including
	queuing delay, MAC Media Access Control (MAC) layer contention delay, serialization delay, and
	propagation delays. delay.  Sometimes there are processing delays as well.
	For the purpose of determining whether or not the deadline has
	already passed, these various delays are not distinguished.
      </t>
    </section>	<!-- End of section "Deadline-6LoRHE Description" -->

<section title="Deadline-6LoRHE Format" anchor="Format">
    <t> anchor="Format" numbered="true" toc="default">
      <name>Deadline-6LoRHE Format</name>
      <figure anchor="fig2" title="Deadline-6LoRHE format">
	<artwork><![CDATA[ anchor="fig2">
        <name>Deadline-6LoRHE Format</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |1|0|1| Length  |  6LoRH Type   |D| TU|  DTL  | OTL | BinaryPt  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      DT (variable length)     | OTD(variable length)(optional)|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
        </artwork>
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        ]]></artwork>
      </figure>
    </t>

    <?rfc subcompact="yes" ?>
    <t> <list style="symbols">
    <t> Length

<dl>
<dt>Length (5 bits): Length
</dt>
<dd>Length represents the total length of the Deadline-6LoRHE type Type measured in octets.</t>
    <t> 6LoRH Type: TBD (see <xref target="iana"/>)</t>
    <t> D octets.
</dd>
<dt>6LoRH Type:</dt>
<dd>7 (See <xref target="iana" format="default"/>.)
</dd>

<dt>D flag (1 bit): The
</dt>
<dd><t>The 'D' flag, set by the Sender, sender, qualifies the action to be taken when a 6LR
6LoWPAN Router (6LR) detects that the deadline time has elapsed.
        If elapsed.</t>
<t>If 'D' bit is 1, then the 6LR MUST
<bcp14>MUST</bcp14> drop the packet if the deadline time is elapsed.
	If elapsed.</t>
<t>If 'D'
bit is 0, the packet MAY <bcp14>MAY</bcp14> 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 etc.).</t>
</dd>

<dt>TU (2 bits) : Indicates 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.
	<list>
	<t>00 : Time  </t>
          <dl spacing="compact">
            <dt>00</dt><dd>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 seconds</dd>
            <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): Length
</dt>
<dd>Length of the DT field as an unsigned 4-bit integer, encoding the length of
the field in hex digits, minus one.
    </t>

    <t> OTL
</dd>

<dt>OTL (3 bits) : Length 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 MUST NOT <bcp14>MUST NOT</bcp14> exceed the value of DTL
plus one.
	<list>
	<t> For
      </t>
            <t>For example, DTL = 0b0000 means the deadline time DT field in the
            6LoRHE is 1 hex digit (4 bits) long.  OTL = 0b111 means the origination time
            OTD field is 7 hex digits (28 bits) long.</t>
	</list></t>
    <t> Binary Pt
</dd>
<dt>BinaryPt (6 bits) : If 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.  if  If nonzero, the Binary Pt BinaryPt is a (2's complement) signed
	integer determining the position of the binary point within the value
	for the DT.
        <list style="symbols">
	<t>  This allows BinaryPt to be within the range [-32,31].</t>
<ul>
            <li> If BinaryPt value is positive, then the number of bits for
            the integer part of the DT is increased by the value of BinaryPt,
            and the number of bits for the fractional part of the DT is
            correspondingly reduced.  This increases the range of DT.</t>
	<t> DT.</li>
            <li> If BinaryPt value is negative, then the number of bits for
            the integer part of the DT is decreased by the value of BinaryPt,
            and the number of bits for the fractional part of the DT is
            correspondingly increased.  This increases the precision of the
            fractional seconds part of DT.</t>

<!--  Lijo : Alexey Melnikov Comment:  "It would be good if you specified how negative values are represented -->
<!--                                    and the range for positive and negative values" -->

	</list> </t>
    <t> DT DT.</li>
</ul>
</dd>

<dt>DT Value (8..64-bit) : An (4..64 bits):
</dt>
<dd>An unsigned integer of DTL+1 hex digits giving the Deadline Time value  </t>
    <t> OTD DT value.
</dd>

<dt>OTD Value (8..64-bit) : An (4..28 bits):
</dt>
<dd>If present, an unsigned integer of OTL hex digits giving the Origination Time origination time as a
negative offset from the DT value </t>
    </list> </t>

    <?rfc subcompact="no" ?> value.
</dd>

</dl>

  <t> Whenever a sender initiates the IP datagram, it includes the
  Deadline-6LoRHE along with other 6LoRH information.  For information about
  the time synchronization time-synchronization requirements between sender and
	receiver receiver, see <xref target="sync"/>.
  target="sync" format="default"/>.
      </t>
      <t>
<!--  CEP: Wraparound, revisited...  -->

	For the chosen time unit, a compressed time representation is
	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
	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:
    		<list>
        		<t>
      </t>
      <t indent="3">
        DTL = (N_bits mod ((N_bits - 1) / 4)
      </t>
		</list>
      <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
	origination time
	OT.  Denote this number of fractional time units to
	be Epoch_Range(DTL) (i.e., Epoch_Range is a function of DTL).
    		<list>
        		<t> DTL):
      </t>
      <t indent="3">
        Epoch_Range(DTL) = (2^(4*(DTL+1)) 2<sup>4*(DTL+1)</sup>
      </t>
		</list>
      <t>
	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).
      </t>
      <t>
	DT - OT cannot exceed 2^(4*(DTL+1)) 2<sup>4*(DTL+1)</sup> == 16^(DTL+1). 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
	within the Epoch_Range (DTL) (i.e., Epoch_Range(DTL) = 16^1 (for 16<sup>1</sup>) for any time unit TU). 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, 1)].</t>
    <t>
        Assuming wraparound
	is allowed but works naturally with the arithmetic modulo Epoch_Range.
    </t>
    <t>
	By default, DTL determines t_0 in the chosen RTUs as follows:
	<list>
       	<t> t_0 = [current_time - (current_time mod Epoch_Range (DTL))].</t>
	</list>

	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, does not occur, OT is represented by the value (OT mod Epoch_Range) 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>
    <list>
        <t> Example: Consider a 6TiSCH network with time-slot length of 10ms.
	    Let
        In order to allow fine-grained control over the time units be ASNs (TU == (binary)0b10).  Let setting of the
	    current ASN when
    deadline time, the packet fields for DT and OTD use fractional seconds. This is originated done by specifying
	a binary point, which allocates some of the bits for fractional times.
	Thus, all such fractions are restricted to be 54400, 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>
        Let OT_abs, DT_abs, and CT_abs denote the
            maximum allowable delay (max_delay) true (absolute) values (on the
	synchronized timelines) for OT, DT, and
	current time.  Let N be the packet delivery number of bits to be 1
	    second from used to represent
	the packet origination, then:
	    <list>
	        <t> deadline_time = packet_origination_time + max_delay
		    <list>
			<t> integer parts of OT_abs, DT_abs, and CT_abs:
    </t>
         <t indent="6">N = 0xD480 {4*(DTL+1)/2} + 0x64 (Network ASNs) BinaryPt </t>
    <t> = 0xD4E4 (Network ASNs) </t>
		    </list>
	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> Then,
	Given a value for N, the Deadline-6LoRHE encoding with nonzero OTL is:
		    <list>
			<t> DTL = 3, OTL = 2, TU = 0b10, BinaryPt = 8, value for DT is represented in the
	deadline-time format by DT = 0xD4E4, OTD (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 = 0x64</t>
		    </list> CT_abs mod 2^N, where both OT and CT are also considered as
	non-negative values.
    </t>
	    </list>
    <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> <!--  Put another example here.  --></t>
    </list>
        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>

    <?rfc subcompact="no" ?>
</section>	<!-- End
    <t>
	Under <xref target="assumption" format="none">Assumption 1</xref>, downstream nodes must effectively check
	whether or not their current time is later than the DT -- but
	the value of section "Deadline-6LoRHE" --> 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="assumption" 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>

    <t>
	Since OT is not necessarily provided in the 6loRHE, there may be a
	danger of ambiguity.  Surely, when DT = CT, the deadline time
	is expiring and the packet should be dropped. However, what if an
	intermediate node measures that CT = DT+1?  Was the packet
	launched a short time before arrival at the intermediate node,
	or has the current time wrapped around so that
	CT_abs - OT_abs &gt; 2^N?
    </t>

    <t>
	In order to solve this problem, a safety margin has to be provided,
	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
	    current ASN when the packet is originated be 54400, and the
            maximum allowable delay (max_delay) for the packet delivery be 1
	    second from the packet origination, then:
          </t>
          <t indent="6"> deadline_time = packet_origination_time + max_delay</t>
             <t indent="9"> = 0xD480 + 0x64 (Network ASNs) </t>
             <t indent="9"> = 0xD4E4 (Network ASNs) </t>

          <t indent="6"> Then, the Deadline-6LoRHE encoding with nonzero OTL is:</t>
             <t indent="9"> DTL = 3, OTL = 2, TU = 0b10, BinaryPt = 8, DT = 0xD4E4, OTD&nbsp;=&nbsp;0x64</t>

    </section>

<section title="Deadline-6LoRHE numbered="true" toc="default">
      <name>Deadline-6LoRHE in Three Network Scenarios"> Scenarios</name>
      <t>
	In this section, the Deadline-6LoRHE operation is described for 3 three
	network scenarios.  <xref target="fig3"/> target="fig3" format="default"/> depicts a
	constrained time-synchronized LLN that has two subnets subnets, N1 and N2,
	connected through LBRs 6LoWPAN Border Routers (6LBRs) <xref target="I-D.ietf-6lo-backbone-router"/> target="RFC8929" format="default"/>
	with different reference clock times times, T1 and T2.
      </t>
      <figure anchor="fig3" title=" Intra-network Timezone Scenario">
	<artwork><![CDATA[ anchor="fig3">
        <name>Intra-Network Time Zone Scenario</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
                       +-------------------+
                       | Time Synchronized Time-Synchronized |
                       |      Network      |
                       +---------+---------+
                                 |
                                 |
                                 |
                  +--------------+--------------+
                  |                             |
               +-----+                       +-----+
               |     | Backbone              |     | Backbone
          o    |     | router                |     | router
               +-----+                       +-----+
          o                  o               o
              o    o   o               o  o   o  o   o  o
         o      LLN    o                 o  LLN   o  o
            o   o    o      o             o o o     o  o
      6LoWPAN Network (subnet N1)   6LoWPAN Network (subnet N2)
                   ]]></artwork>
      </figure>
    </t>
      <section
   title="Scenario numbered="true" toc="default">
        <name>Scenario 1: Endpoints in the same Same DODAG (N1)"> (N1)</name>
        <t>
	In scenario Scenario 1, shown in <xref target="fig4"/>, target="fig4" format="default"/>, the Sender 'S' has an
	IP datagram to be routed to a Receiver 'R' within
	the same DODAG. Destination-Oriented Directed Acyclic Graph (DODAG).
        For the route segment from Sender the sender to the 6LBR, the Sender sender
	includes a Deadline-6LoRHE by encoding the deadline time
	contained in the packet. Subsequently, each 6LR will perform hop-by-hop
	routing to forward the packet towards the 6LBR.  Once the 6LBR receives
	the IP datagram, it sends the packet downstream towards 'R'.
        </t>
        <t>
	In the case of a network running in RPL non-storing mode, the 6LBR generates
	a
	an IPv6-in-IPv6 encapsulated packet when sending the packet downwards
	to the Receiver receiver <xref target="I-D.ietf-roll-useofrplinfo"/>. target="RFC9008" format="default"/>.
	The 6LBR copies the Deadline-6LoRHE from the Sender originated sender-originated IP
	header to the outer IP header. The Deadline-6LoRHE contained in
	the inner IP header is removed.
        </t>
    <t>
        <figure anchor="fig4" title="End points anchor="fig4">
          <name>Endpoints within same the Same DODAG (subnet N1)">
	<artwork><![CDATA[ (Subnet N1)</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
                           +-------+
                ^          | 6LBR  |       |
                |          |       |       |
                |          +-------+       |
        Upward  |         /      /| \      | Downward
        routing |      (F)      / |  \     | routing
                |     /  \    (C) |  (D)   |
                |    /    \    |  | / |\   |
                |  (A)    (B)  : (E)  : R  |
                |  /|\     | \   / \       |
                | S : :    : :  :  :       v ]]></artwork>
        </figure>
    </t>
        <t>
	At the tunnel endpoint of the encapsulation, the
	Deadline-6LoRHE is copied back from the outer header to inner
	header, and the inner IP packet is delivered to 'R'.
        </t>
      </section>	<!-- End of section "Scenario 1: Endpoints in the same ..." -->

<section
   title="Scenario numbered="true" toc="default">
        <name>Scenario 2: Endpoints in Networks with Dissimilar L2 Technologies."> Technologies</name>
        <t>
	In scenario Scenario 2, shown in <xref target="fig5"/>, 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
	segment from 'S' to 6LBR, 'S' includes a Deadline-6LoRHE.
	Subsequently, each 6LR will perform hop-by-hop routing to forward the
	packet towards the 6LBR.  Once the Deadline Time deadline time information reaches
	the border router, 6LBR, the packet will be encoded according to the
	mechanism prescribed in the other time-synchronized network depicted
	as "Time Synchronized "Time-Synchronized Network" in the figure 6. <xref target="fig5" format="default"/>.
 	The specific data encapsulation mechanisms followed in the new network
	are beyond the scope of this document.
        </t>
        <figure anchor="fig5"
         title="Packet transmission anchor="fig5">
          <name>Packet Transmission in Dissimilar L2 Technologies or Internet">
    <artwork><![CDATA[ Internet</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
                           +----------------+
                           | Time Time-          |
                           | Synchronized   |------R
                           | Network        |
                           +----------------+
                                   |
                                   |
                         ----------+-----------
                  ^                |
                  |            +---+---+
                  |            | 6LBR  |
         Upward   |            |       |
         routing  |            +------++
                  |        (F)/      /| \
                  |       /  \      / |  \
                  |      /    \   (C) |  (D)
                  |    (A)    (B)  |  | / |\
                  |    /|\     |\  : (E)  : :
                  |   S : :    : :   / \
                                    :   :]]>
        </artwork>   :
        ]]></artwork>
        </figure>

    </t>
        <t>
	For instance, the IP datagram could be routed to another time
	synchronized time-synchronized,
        deterministic network using the mechanism specified in
	the In-band OAM
	In-situ Operations, Administration, and Maintenance (IOAM)
        <xref target="I-D.ietf-ippm-ioam-data"/>, target="I-D.ietf-ippm-ioam-data" format="default"/>, and then
	the deadline time would be updated according to the measurement
	of the current time in the new network.
        </t>
      </section>	<!-- End of section "Scenario 2: Packet transmission in ..." -->

<section
   title="Scenario numbered="true" toc="default">
        <name>Scenario 3: Packet transmission Transmission across different Different DODAGs (N1 to N2)."> N2)</name>
        <t>
	Consider the scenario depicted in <xref target="fig6"/>, target="fig6" format="default"/>, in which
	the Sender 'S' (belonging to DODAG 1) has an IP datagram to be
	sent to Receiver 'R' belonging to another DODAG (DODAG 2).  The
	operation of this scenario can be decomposed into a combination of case
	Scenarios 1 and case 2 scenarios. 2. For the route segment from 'S' to 6LBR1,
	'S' includes the Deadline-6LoRHE.  Subsequently, each 6LR will
	perform hop-by-hop operation operations to forward the packet towards the 6LBR1.
	Once the IP datagram reaches 6LBR1 of DODAG1, it 6LBR1 applies the same rule
	as described in Case Scenario 2 while routing the packet to 6LBR2 over a (likely)
	time synchronized
	time-synchronized wired backhaul.  The wired side of 6LBR2 can be mapped
	to the receiver of Case Scenario 2. Once the packet reaches 6LBR2, it updates the
	Deadline-6LoRHE by adding or subtracting the difference of time of
	DODAG2 and sends the packet downstream towards 'R'.
        </t>
        <figure anchor="fig6"
		title="Packet transmission anchor="fig6">
          <name>Packet Transmission in different DODAGs(N1 Different DODAGs (N1 to N2)">
    <artwork><![CDATA[
                 Time Synchronized N2)</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
                 Time-Synchronized Network
               -+---------------------------+-
                |                           |
   DODAG1   +---+---+                   +---+---+   DODAG2
            | 6LBR1 |                   | 6LBR2 |
            |       |                   |       |
            +-------+                   +-------+
        (F)/      /| \              (F)/      /| \
       /  \      / |  \            /  \      / |  \
      /    \   (C) |  (D)         /    \   (C) |  (D)
    (A)    (B)  |  | / |\       (A)    (B)  |  |   |\
    /|\     |\  : (E)  : :      /|\     |\  : (E)  : :
   S : :    : :   / \          : : :    : :   / \
                 :   :                       :   R
Network N1, time zone T1      Network N2, time zone T2]]>
    </artwork> T2
    ]]></artwork>
        </figure>
        <t>
	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
	allowable delay be 1 second. The time-slot length in DODAG1 and DODAG2
	is assumed to be 10ms. 10 ms.  Once the deadline time is encoded in
	Deadline-6LoRHE, the packet is forwarded to 6LBR 6LBR1 of DODAG1.
	Suppose the packet reaches 6LBR 6LBR1 of DODAG1 at ASN 20030.
        </t>
	<t>
<?rfc subcompact="yes" ?>
	<list>
    <t>
          <t indent="3"> current_time = ASN at LBR 6LBR * slot_length_value</t>
	<t></t>
    <t> slot_length_value </t>
          <t indent="3"> remaining_time = deadline_time - current_time</t>
	<t>
             <t indent="6"> = ((packet_origination_time + max_delay) - current time)</t>
	<t>
             <t indent="6"> = (20000 + 100) - 20030 </t>
	<t>
             <t indent="6"> = 30 (in Network ASNs)</t>
	<t>
             <t indent="6"> = 30 * 10^3 milliseconds. </t>
	</list>
<?rfc subcompact="no" ?> 10<sup>3</sup> milliseconds </t>

        <t>
	Once the Deadline Time deadline time information reaches the border router, 6LBR2,
	the packet will be encoded according to the mechanism prescribed
	in the other time-synchronized network.
        </t>
      </section> <!-- End of section "Scenario 3: Packet transmission across ..." -->
</section>	<!-- End of section "Deadline-6LoRHE
			in different network scenarios" -->

<section title="IANA Considerations" anchor="iana"> anchor="iana" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
	This document defines a new Elective 6LoWPAN Routing Header Type,
	and IANA is requested to assign a has assigned the value (TBD) 7 from the 6LoWPAN
	Dispatch Page1 Page 1 number space for this purpose.

	<!--  New: Donald E. Eastlake comments -> Modified writings  . -->

	<figure anchor="fig8" title="Deadline-6LoRHE type">
	<artwork><![CDATA[
                  Elective 6LoRH Type     Value
                +----------------------+--------+
                |   Deadline-6LoRHE    |  TBD   |
                +----------------------+--------+]]>
        </artwork>
	</figure>

      </t>

<table anchor="iana_reg">
  <name>Entry in the "Elective 6LoWPAN Routing Header Type" Registry</name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>7</td>
      <td>Deadline-6LoRHE</td>
      <td>RFC 9034</td>
    </tr>
  </tbody>
</table>
    </section>	<!-- End of section "IANA Considerations" -->

<section title="Synchronization Aspects" anchor="sync"> anchor="sync" numbered="true" toc="default">
      <name>Synchronization Aspects</name>
      <t>
	The document supports time representation of the deadline and
	origination times carried in the packets traversing through networks
	of different time zones having different time synchronization time-synchronization
	mechanisms. For instance, in a 6TiSCH network where the time is
	maintained as ASN time slots, the time synchronization is achieved
	through beaconing among the nodes as described in
	<xref target="RFC7554"/>. target="RFC7554" format="default"/>.
	There could be 6lo networks that employ NTP where the nodes are
	synchronized with an external reference clock from an NTP server.
	The specification of the time synchronization time-synchronization method that need needs to
	be followed by a network is beyond the scope of the document.
      </t>
	<!--
	Lijo : Needs to work on the syncronization aspect,
		  @ Charlie, Kindly put your comments.
    -->

    <t>
	The number of hex digits chosen to represent DT, and the portion of
	that field allocated to represent the integer number of seconds, determines
	the meaning of t_0, 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
	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
	requires that the time
	synchronization between sender and receiver has to be tighter than
	16 units.  If the binary point were moved so that all the bits
	were used for fractional time units (e.g., fractional seconds or
	fractional ASNs), the time synchronization time-synchronization requirement would be
	correspondingly tighter.
      </t>
      <t>
	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"/> 64-bit timestamp format, format <xref target="RFC5905" format="default"/>,
	which is more than enough for the purposes
	of establishing deadline times.  Unless the binary point is moved,
	this is enough to represent time since year 1900.
      </t>
      <t>
	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.

<!--  CEP: Deleted in favor of a more rigid mechanism, easier to specify and
      	   implement.
					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
	up to 256 seconds (in steps of 1/256 of a second).
      </t>
      <t>
	In all cases, t_0 t<sub>0</sub> is defined as specified in <xref target="Format"/>
	<list>
       	<t> t_0 = [current_time - (current_time mod (2^(4*(DTL+1))))] </t>
	</list>
	regardless of the choice of TU.
    </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 specified in <xref target="Format" format="default"/>.
      </t>

        <t indent="3">t<sub>0</sub> = [current_time - (current_time mod (2<sup>4*(DTL+1)</sup>))] </t>

      <t>
	regardless of the integer number choice of seconds (in the chosen precision for the DT field).
  --> TU.
      </t>
      <t>

	For TU = 0b00, the time units are seconds.  With DTL == 15,
	and Binary Pt BinaryPt == 0, the epoch is (by default) January 1,
	1900
	1900, at 00:00 UTC.  The resolution is then (2 ^ (- 32)) 2<sup>-32</sup> seconds,
	which is the maximum possible.
	This time format wraps around every 2^32 2<sup>32</sup> seconds, which is
	roughly 136 years.
      </t>
      <t>
	For TU = 0b10, the time units are ASNs.  The start time is relative,
	and updated by a mechanism that is out of scope for this document.
	With 10 ms slots, DTL = 15, and Binary Pt BinaryPt == 0, it would take over
	a year for the ASN to wrap around.
<!--  CEP: The number of years is 4294967296 / 3155760000 -->  Typically, the number of hex
	digits allocated for TU = 0b10 would be less than 15.
      </t>
    </section>	<!-- End of section "Synchronization Aspects" -->

<section title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
	The security considerations of
        <xref target="RFC4944"/>,
	<xref target="RFC6282"/> target="RFC4944" section="13" sectionFormat="parens" format="default"/>,
	<xref target="RFC6282" section="6" sectionFormat="parens" format="default"/>, and
        <xref target="RFC6553"/> target="RFC6553" section="5" sectionFormat="parens" format="default"/> apply.
	Using a compressed format as opposed to the full in-line inline format is
	logically equivalent and does not create an opening for a new threat
	when compared to <xref target="RFC6550"/>, target="RFC6550" format="default"/>, <xref target="RFC6553"/> target="RFC6553" format="default"/>,
	and <xref target="RFC6554"/>. target="RFC6554" format="default"/>.
      </t>
      <t>
	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 6TiSCH network could be established by a centralized PCE, Path Computation Element (PCE), as
	described in the 6tisch 6TiSCH architecture
	<xref target="I-D.ietf-6tisch-architecture"/>. target="RFC9030" format="default"/>.
      </t>
      <t>
	The Security Considerations security considerations of Detnet DetNet architecture
	<xref target="I-D.ietf-detnet-architecture"/> target="RFC8655" section="5" sectionFormat="parens" format="default"/> 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, 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.
      </t>
      <t>
	When deadline bearing
          The identification of deadline-bearing flows are identified on a per-flow basis, which basis
          may provide attackers with additional information about the data flows,
	when
          flows 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.
      </t>
      <t>
	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 <xref target="RFC7384"/>.
    </t>
	<!--
	Lijo : Added above paragraphs
    -->
</section>	<!-- End of section "Security Considerations" -->

<section title="Acknowledgements">
    <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. target="RFC7384" format="default"/>.
      </t>

</section>	<!-- End of section "Acknowledgements" -->

</middle>
  <back>		<!--  *****BACK MATTER ***** -->
    <!-- References split into informative and normative -->

    <!-- 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'?>

<displayreference target="I-D.ietf-ippm-ioam-data" to="IOAM-DATA"/>
<displayreference target="I-D.ietf-6lo-blemesh" to="6LO-BLEMESH"/>

<references>
      <name>References</name>
      <references>
        <name>Normative References</name>

        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9030.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8655.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4944.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5905.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6282.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6550.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6553.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6554.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7384.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7554.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8138.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      </references>

<references title="Informative References">
	<?rfc include="reference.I-D.ietf-6tisch-architecture" ?>

<!--
- IEEE Standard for Local and metropolitan area networks - Part 15.4, -
IEEE Std 802.15.42015, 2015.

IEEE Standard for Low-Rate Wireless Networks," in IEEE Std 802.15.4-2015 (Revision of IEEE Std 802.15.4-2011) , vol., no., pp.1-709, April 22 2016
doi: 10.1109/IEEESTD.2016.7460875
  -->
      <references>
        <name>Informative References</name>

      <reference anchor="dot15-tsch"> anchor="IEEE.802.15.4"
target="https://ieeexplore.ieee.org/document/7460875">
        <front>
          <title>IEEE Standard for Low-Rate Wireless Networks,
		Part 15.4, IEEE Std 802.15.4-2015</title>
          <author surname="P802.11">
            <organization>"IEEE 802 Wireless"</organization>

            <address>
            </address>
          </author>

          <date month="April" year="2016"/>
        </front>
      </reference>

<!--
     @INPROCEEDINGS{Lee02ieee-1588standard,
    author = {Kang Lee and John Eidson},
    title = {IEEE-1588 Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems},
    booktitle = {In 34 th Annual Precise Time and Time Interval (PTTI) Meeting},
    year = {2002},
    pages = {98 thru 105}
}
  -->
            <title>IEEE Standard for Low-Rate Wireless Networks</title>
            <author>
              <organization>IEEE</organization>
            </author>
            <date month="April" year="2016"/>
        </front>
        <seriesInfo name="IEEE Standard" value="802.15.4-2015"/>
        <seriesInfo name="DOI" value="10.1109/IEEESTD.2016.7460875"/>
      </reference>

      <reference anchor="ieee-1588"> anchor="IEEE.1588.2008">
          <front>
            <title>IEEE Std 1588-2008 Standard for a Precision Clock
		Synchronization
		Protocol for Networked Measurement and Control Systems</title>

          <author surname="Precise Time and Time Interval Working Group">
            <organization>"IEEE Standards"</organization>

            <address>
            </address>
            <author>
              <organization>IEEE</organization>
            </author>
            <date month="July" year="2008"/>
          </front>
          <seriesInfo name="DOI" value="10.1109/IEEESTD.2008.4579760"/>
        </reference>

	<!--  New: Donald E. Eastlake comments -> dotBLEMesh  . -->
	<!--  Lijo : Is this reference, Okay -->

      <reference anchor="dotBLEMesh"> anchor="IEEE-BLE-MESH">
          <front>
            <title>
		Multi-Hop Real-Time Communications Over Bluetooth Low Energy
		Industrial Wireless Mesh Networks
            </title>
            <author fullname="Luca Leonardi" initials="L." surname="Leonardi">
              <organization> </organization>
            <address>
	    </address>
            </author>
            <author fullname="Gaetano Pattim" Patti" initials="G." surname="Pattim"> surname="Patti">
              <organization> </organization>
            <address>
	    </address>
            </author>
            <author fullname="Lucia Lo Bello" initials="L." surname="Lo Bello">
              <organization> </organization>
            <address>
	    </address>
            </author>
            <date month="May" year="2018" /> year="2018"/>
          </front>
        <seriesInfo name="IEEE Access"
			value="Vol
          <refcontent>IEEE Access, Vol 6, 26505-26519"/> pp. 26505-26519</refcontent>
          <seriesInfo name="DOI" value="10.1109/ACCESS.2018.2834479"/>
        </reference>

        <reference anchor="dot1AS-2011"> anchor="IEEE.802.1AS.2011">
          <front>
            <title>IEEE Standard for Local and Metropolitan Area Networks -
		Timing and Synchronization for Time-Sensitive Applications
		in Bridged Local Area Networks
            </title>
            <author surname="IEEE 802.1AS Working Group">
            <organization>"IEEE Standards"</organization>

            <address>
            </address>
              <organization>IEEE</organization>
            </author>
            <date month="March" year="2011"/>
          </front>
          <refcontent>IEEE Std 802.1AS-2011</refcontent>
          <seriesInfo name="DOI" value="10.1109/IEEESTD.2011.5741898"/>
        </reference>

        <reference anchor="Wi-SUN_PHY"> anchor="PHY-SPEC" target="http://wi-sun.org">
          <front>
            <title>Wi-SUN PHY Specification V1.0</title>
            <author>
              <organization>Wi-SUN Alliance</organization>
            </author>
            <date month="March" year="2016"></date> year="2016"/>
          </front>
        </reference>

<!--
          <title> Wi-SUN is a wireless communication technology designed for Utilities, Smart Cities and IoT.  Wi-SUN is based on various IEEE, IETF, and NSI/TIA 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"> anchor="Wi-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" month="January" year="2017"/>
          </front>
        <seriesInfo name="IEICE
          <refcontent>IEICE Transactions on Communications"
			value="volume E100.B"/> Communications</refcontent>
          <refcontent>Volume E100.B, Issue 7, pp. 1032-1043</refcontent>
          <seriesInfo name="DOI" value="10.1587/transcom.2016SCI0002"/>
        </reference>

	<?rfc include="reference.I-D.ietf-ippm-ioam-data" ?>
	<?rfc include="reference.I-D.ietf-detnet-use-cases" ?>
	<?rfc include="reference.I-D.ietf-6lo-backbone-router" ?>
	<?rfc include="reference.I-D.ietf-roll-useofrplinfo" ?>
	<?rfc include="reference.I-D.ietf-6lo-blemesh" ?>

<reference anchor="I-D.ietf-ippm-ioam-data">
<front>
<title>Data Fields for In-situ OAM</title>
<author initials="F." surname="Brockners" fullname="Frank Brockners" role="editor">
<organization>Cisco Systems, Inc.</organization>
</author>
<author initials="S." surname="Bhandari" fullname="Shwetha Bhandari"  role="editor">
<organization>Thoughtspot</organization>
</author>
<author initials="T." surname="Mizrahi" fullname="Tal Mizrahi"  role="editor">
<organization>Huawei</organization>
</author>
<date month="February" day="21" year="2021"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-ippm-ioam-data-12"/>
<format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-ippm-ioam-data-12.txt"/>
</reference>

        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8578.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8929.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9008.xml"/>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-6lo-blemesh-10.xml"/>

      </references>
    </references>

<section title="Changes anchor="modular" title="Modular Arithmetic Considerations">
    <t>
	Graphically, one might visualize the timeline as follows:
    </t>
	<figure anchor="fig7" title="Absolute Timeline Representation">
	<artwork><![CDATA[
           OT_abs        CT_abs        DT_abs
      -------|-------------|-------------|------------------>]]>
        </artwork>
	</figure>
    <t>
	In <xref target="fig7"/>, the value of CT_abs is envisioned
	as traveling to the right as time progresses, getting farther away
	from revision 04 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 revision 05"
	anchor="changes_04_05"> OT and DT.
    </t>
    <t>
    This section lists
	Representing the changes between draft-ietf-6lo-deadline-time
	revisions ...-04.txt and ...-05.txt.
    <list style="symbols"> 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>
	 <dl>
	 <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>

	 <dt> 2) DT &lt; OT &lt; CT </dt> <dd>(e.g., I_k &lt; OT_abs &lt; CT_abs  &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>
	Included additional relevant material
	Again in Security Considerations
	regarding expected deployment scenarios <xref target="fig7"/>, consider CT_abs as time
	moving away from OT_abs and towards DT_abs.
	For times CT_abs before the effect expiration of
	disclosing additional information during the travel of a packet. deadline time, we also
	have CT_abs - OT_abs == CT - OT mod 2^N and similarly for DT_abs -
	CT_abs.
    </t>

    <t>
	Reworked
	As time proceeds, DT_abs - CT_abs gets smaller.  When the specification for using deadline time ranges shorter than
	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</em> that it
	has gone negative.
	Note that in modular arithmetic, "slightly negative" means <em>exactly</em>
	the
	maximum allowed by same as "almost as large as the choice of TU, so that fewer bits are needed
	to represent DT and OT. modulus (i.e., 2^N)".
	Now consider the test condition
	((CT - DT) mod 2^N) > SAFETY_FACTOR*2^N.
    </t>

    <t>
	Revised
	(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 figures inequality,
	OT_abs - DT_abs > 2^N*(1-SAFETY_FACTOR), and examples to use new parameters thus at
	launch CT_abs - DT_abs > 2^N*(1-SAFETY_FACTOR).
    </t>

    <t>
	Reordered
	As CT_abs grows larger, CT_abs - DT_abs gets LARGER in (non-negative)
	modular arithmetic until the field definitions for time at which CT_ABS == DT_ABS, and
	suddenly CT_ABS - DT_abs becomes zero.  Also suddenly, the Deadline-6LoRHE. test
	condition is no longer fulfilled.
    </t>

    <t>
	Responded to numerous reviewer comments to improve terminology
	As CT_abs grows still larger, CT_abs > DT_abs, and editorial consistency.
    </t>
  </list></t>
</section>  <!-- End of section "Changes from revision 04 we need to revision 05" -->

<section title="Changes from revision 03 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 revision 04"
	anchor="changes_03_04"> SAFETY_FACTOR*2^N.
    </t>

    <t>
    This section lists
	A note about "inverting the changes between draft-ietf-6lo-deadline-time
	revisions ...-03.txt and ...-04.txt.
    <list style="symbols">
    <t>
	Replaced OT (Origination Time) field by OTD (Origination Time
	Delta), allowing inequality".  Observe that a more compressed representation &lt; b
	implies that needs
	less processing during transitions between networks.
    </t>
    <t>
        Changed representation -a > -b on the real number line.  Also,
	(a - b) == -(b - a).  These facts hold also for DTL, OTL, DT, OTD.  Eliminated
	EXP in favor of BinaryPt. modular arithmetic.
    </t>

    <t>
	Revised
	During the figures and examples times prior to use new parameters the expiration of the deadline, for
	Safe = 2^N*SAFETY_FACTOR we have:
    </t>

    <t indent="6">
(DT_abs - 2^N)  &lt; OT_abs  &lt;  CT_abs  &lt;  DT_abs  &lt;  DT_abs+Safe
    </t>

    <t>
	Added new section on Synchronization Aspects
	Naturally, DT_abs - 2^N  ==  DT_abs mod 2^N == DT.
    </t>

    <t>
	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 supply pertinent
	information about how nodes agree on determine with certainty whether or not 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 deadline time has
	expired.  These statements
	also apply when reduced to revision 03"
	anchor="changes_02_03">

  <t>
    This section lists modular arithmetic in 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. modulus 2^N.
    </t>

    <t>
        Specified that
	In particular, the Origination Time (OT) is test condition no longer allows
	detection of deadline expiration when the current
	time that packet
	is enqueued becomes later than (DT_abs+Safe).  In order to maintain
	correctness even for transmission.
    </t>
    <t>
        Mentioned more sources of packet delay.
    </t>
    <t>
        Clarified reasons that packet MAY be forwarded if 'D' bit is 0.
    </t>
    <t>
        Clarified packets that DT, OT, DTL and OTL are unsigned integers.
    </t>
    <t>
        Updated bibliographic citations, including BLEmesh and Wi-SUN.
    </t>
  </list></t>
</section>  <!-- End of section "Changes from revision 02 to revision 03" -->

<section title="Changes from revision 01 to revision 02"
	anchor="changes_01_02">

  <t>
    This section lists forwarded after expiration
	(i.e., the changes between draft-ietf-6lo-deadline-time
	revisions ...-01.txt and ...-02.txt.
    <list style="symbols">
    <t>
        Replaced 6LoRHE description by reference to RFC 8138.
    </t>

    <t>
        Added figure 'D' flag), N has to illustrate change be chosen to Origination Time when a
	packet crosses timezone boundaries.
    </t>

    <t>
        Clarified be so large that use of 6tisch networks is descriptive,
	the test condition will not normative.
    </t>

    <t>
        Clarified fail -- i.e., that In-Band OAM is used as an example and is not normative.
    </t>

    <t>
        Updated bibliographic citations.
    </t>

    <t>
        Alphabetized contributor names.
    </t>

  </list></t>
</section>  <!-- End in all scenarios
	of section "Changes from revision 01 interest, the packet will be dropped before the current time
	becomes equal to revision 02" --> DT_abs+2^N*SAFETY_FACTOR.
    </t>

	</section>

<section title="Changes between earlier versions"
	anchor="older_changes"> numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>
      This section lists
	The authors thank <contact fullname="Pascal Thubert"/> for suggesting the changes between draft-ietf-6lo-deadline-time
	revisions ...-00.txt and ...-01.txt.
    <list style="symbols">
    <t>
        Changed "SHOULD drop" idea and
	encouraging the work. Thanks to "MUST drop" a packet if <contact fullname="Shwetha Bhandari"/>'s suggestions, which
	were instrumental in extending the deadline is
	passed (see <xref target="Format"/>).
    </t>

    <t>
        Added explanatory text about how packet delays might arise.
	(see <xref target="Description"/>).
    </t>

    <t>
        Mentioned availability of time-synchronization protocols
	(see <xref target="Intro"/>).
    </t>

    <t>
        Updated bibliographic citations.
    </t>

    <t>
        Alphabetized contributor names.
    </t>

    <t>
        Added this section. 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>

  </list></t>
    </section>

  </back>
</rfc>