Packet Delivery Deadline time in 6LoWPAN Routing Header
draft-ietf-6lo-deadline-time-05

Document Type Active Internet-Draft (6lo WG)
Last updated 2019-10-31 (latest revision 2019-07-08)
Stream IETF
Intended RFC status Proposed Standard
Formats plain text xml pdf htmlized bibtex
Reviews
Stream WG state Submitted to IESG for Publication
Document shepherd Shwetha Bhandari
Shepherd write-up Show (last changed 2018-09-03)
IESG IESG state RFC Ed Queue
Consensus Boilerplate Yes
Telechat date
Responsible AD Suresh Krishnan
Send notices to Samita Chakrabarti <samitac.ietf@gmail.com>, Shwetha Bhandari <shwethab@cisco.com>
IANA IANA review state Version Changed - Review Needed
IANA action state RFC-Ed-Ack
RFC Editor RFC Editor state MISSREF
6lo                                                          Lijo Thomas
Internet-Draft                                                     C-DAC
Intended status: Standards Track                          S. Anamalamudi
Expires: January 9, 2020                               SRM University-AP
                                                             S.V.R.Anand
                                                            Malati Hegde
                                             Indian Institute of Science
                                                              C. Perkins
                                                               Futurewei
                                                            July 8, 2019

        Packet Delivery Deadline time in 6LoWPAN Routing Header
                    draft-ietf-6lo-deadline-time-05

Abstract

   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 (M2M)
   applications that operate within time-synchronized networks that
   agree on the meaning of the time representations used for the
   deadline time values.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 9, 2020.

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Lijo Thomas, et al.      Expires January 9, 2020                [Page 1]
Internet-Draft         6lo Delivery Deadline Time              July 2019

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  6LoRHE Generic Format . . . . . . . . . . . . . . . . . . . .   3
   4.  Deadline-6LoRHE . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Deadline-6LoRHE Format  . . . . . . . . . . . . . . . . . . .   6
   6.  Deadline-6LoRHE in Three Network Scenarios  . . . . . . . . .   8
     6.1.  Scenario 1: Endpoints in the same DODAG (N1)  . . . . . .   9
     6.2.  Scenario 2: Endpoints in Networks with Dissimilar L2
           Technologies. . . . . . . . . . . . . . . . . . . . . . .  10
     6.3.  Scenario 3: Packet transmission across different DODAGs
           (N1 to N2). . . . . . . . . . . . . . . . . . . . . . . .  11
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   8.  Synchronization Aspects . . . . . . . . . . . . . . . . . . .  13
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  15
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     11.2.  Informative References . . . . . . . . . . . . . . . . .  17
   Appendix A.  Changes from revision 04 to revision 05  . . . . . .  18
   Appendix B.  Changes from revision 03 to revision 04  . . . . . .  18
   Appendix C.  Changes from revision 02 to revision 03  . . . . . .  19
   Appendix D.  Changes from revision 01 to revision 02  . . . . . .  19
   Appendix E.  Changes between earlier versions . . . . . . . . . .  20
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20

1.  Introduction

   Low Power and Lossy Networks (LLNs) are likely to be deployed for
   real time industrial applications requiring end-to-end delay
   guarantees [I-D.ietf-detnet-use-cases].  A Deterministic Network
   ("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.

Lijo Thomas, et al.      Expires January 9, 2020                [Page 2]
Internet-Draft         6lo Delivery Deadline Time              July 2019

   This document specifies a new type for the Elective 6LoWPAN Routing
   Header (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.  [RFC8138] specifies the 6LoWPAN Routing
   Header (6LoRH), compression schemes for RPL routing (source routing)
   operation [RFC6554], header compression of RPL Packet Information
   [RFC6553], and IP-in-IP encapsulation.  This document also specifies
   handling of the deadline time when packets traverse between time-
   synchronized networks operating in different timezones or distinct
   reference clocks.  Time synchronization techniques are outside the
   scope of this document.  There are a number of standards available
   for this purpose, including IEEE 1588 [ieee-1588], IEEE 802.1AS
   [dot1AS-2011], IEEE 802.15.4-2015 TSCH [dot15-tsch], and more.

   The Deadline-6LoRHE can be used in any time synchronized 6Lo network.
   A 6TiSCH 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 over a BLE mesh network [I-D.ietf-6lo-blemesh] in
   industrial IoT [dotBLEMesh].  BLE mesh time synchronization is being
   explored by the Bluetooth community.  There are also cases under
   consideration in Wi-SUN [Wi-SUN_PHY], [dotWi-SUN].

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119] [RFC8174].

   This document uses the terminology defined in [RFC6550] and
   [I-D.ietf-6tisch-terminology].

3.  6LoRHE Generic Format

   Note: this section is not normative and is included for convenience.
   The generic header format of the 6LoRHE is specified in
   [I-D.ietf-roll-routing-dispatch].  Figure 1 illustrates the 6LoRHE
   generic format.

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

                          Figure 1: 6LoRHE format

Lijo Thomas, et al.      Expires January 9, 2020                [Page 3]
Internet-Draft         6lo Delivery Deadline Time              July 2019

   o  Length: Length of the 6LoRHE expressed in bytes, excluding the
      first 2 bytes.  This enables a node to skip a 6LoRHE if the Type
      is not recognized/supported.

   o  Type (variable length): Type of the 6LoRHE (see Section 7)

4.  Deadline-6LoRHE

   The Deadline-6LoRHE (see Figure 3) is an elective 6LoRH (i.e., a
   6LoRHE [RFC8138]) that provides the Deadline Time (DT) for an IPv6
   datagram in a compressed form.  Along with the deadline, the header
   can include the packet Origination Time Delta (OTD), the time at
   which the packet is 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).

   The deadline 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.

      packet_deadline_time = packet_origination_time + max_delay

   In order to support delay-sensitive deterministic applications, all
   nodes within the network should process the Deadline-6LoRHE.  The
   packet deadline time (DT) and origination time (OTD) are represented
   in time units determined by a scaling parameter in the routing
   header.  The Network ASN (Absolute Slot Number) can be used as a time
   unit in a time slotted synchronized network (for instance a 6TiSCH
   network, where global time is maintained in the units of slot lengths
   of a certain resolution).

   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 field is updated to represent the same Destination
   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.

   new_network_origin_time = time_now_in_new_network - current_dly

Lijo Thomas, et al.      Expires January 9, 2020                [Page 4]
Internet-Draft         6lo Delivery Deadline Time              July 2019

   The following example illustrates these calculations 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 as measured in
   timezone 1 is 1050 and the origination time is 50.  Suppose that the
   difference between TZ2 and TZ1 is 900, and the difference between TZ3
   and TZ3 is 3600.  In the figure, OT is the origination time as
   measured in the current timezone, and is equal to DT - OTD, that is,
   DT - 1000.  Figure 2 uses the following abbreviations:

      TxA : Time of arrival of packet in the network 'x'

      TxD : Departure time of packet from the network 'x'

      dlyx : Delay experienced by the packet in the previous network(s)

      TZx : The time zone of network 'x'

               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

                 Figure 2: Destination Time Update example

   There are multiple ways that a packet can be delayed, including
   queuing delay, MAC layer contention delay, serialization delay, and
   propagation delays.  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.

Lijo Thomas, et al.      Expires January 9, 2020                [Page 5]
Internet-Draft         6lo Delivery Deadline Time              July 2019

5.  Deadline-6LoRHE Format

        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)|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 3: Deadline-6LoRHE format

   o  Length (5 bits): Length represents the total length of the
      Deadline-6LoRHE type measured in octets.
   o  6LoRH Type: TBD (see Section 7)
   o  D flag (1 bit): The 'D' flag, set by the Sender, qualifies the
      action to be taken when a 6LR detects that the deadline time has
      elapsed.  If 'D' bit is 1, then the 6LR MUST drop the packet if
      the deadline time is elapsed.  If 'D' bit is 0, the packet MAY be
      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.).
   o  TU (2 bits) : Indicates the time units for DT and OTD fields.  The
      encodings for the DT and OTD fields use the same time units and
      precision.

      *  00 : Time represented in seconds and fractional seconds
      *  01 : Reserved
      *  10 : Network ASN
      *  11 : Reserved
   o  DTL (4 bits): Length of DT field as an unsigned 4-bit integer,
      encoding the length of the field in hex digits, minus one.
   o  OTL (3 bits) : Length of OTD field as an unsigned 3-bit integer,
      encoding the length of the field in hex digits.  If OTL == 0, the
      OTD field is not present.  The value of OTL MUST NOT exceed the
      value of DTL plus one.

      *  For example, DTL = 0b0000 means the deadline time in the 6LoRHE
         is 1 hex digit (4 bits) long.  OTL = 0b111 means the
         origination time is 7 hex digits (28 bits) long.
   o  Binary Pt (6 bits) : If zero, the number of bits of the integer
      part the DT is equal to the number of bits of the fractional part
      of the DT.  if nonzero, the Binary Pt is a signed integer
      determining the position of the binary point within the value for
      the DT.

Lijo Thomas, et al.      Expires January 9, 2020                [Page 6]
Internet-Draft         6lo Delivery Deadline Time              July 2019

      *  If BinaryPt value is positive, then the number of bits for the
         integer part of the DT is increased by the value of BinaryPt,
         and the number of bits for the fractional part of the DT is
         correspondingly reduced.  This increases the range of DT.
      *  If BinaryPt value is negative, then the number of bits for the
         integer part of the DT is decreased by the value of BinaryPt,
         and the number of bits for the fractional part of the DT is
         correspondingly increased.  This increases the precision of the
         fractional seconds part of DT.
   o  DT Value (8..64-bit) : An unsigned integer of DTL+1 hex digits
      giving the Deadline Time value
   o  OTD Value (8..64-bit) : An unsigned integer of OTL hex digits
      giving the Origination Time as a negative offset from the DT value

   Whenever a sender initiates the IP datagram, it includes the
   Deadline-6LoRHE along with other 6LoRH information.  For information
   about the time synchronization requirements between sender and
   receiver see Section 8.

   For the chosen time unit, a compressed time representation is
   available as follows.  First, the application on the originating node
   has to determine how many time bits are needed to represent the
   difference between the time at which the packet is launched and the
   deadline time, including the representation of fractional time units.
   That number of bits (say, N_bits) determines DTL (the length of the
   Deadline Time (DT)) as follows:

      DTL = (N_bits mod 4)

   The number of bits determined by DTL allows counting any number of
   fractional time units in the range of interest determined by DT and
   the origination time OT.  Denote this number of fractional time units
   to be Epoch_Range(DTL) (i.e., Epoch_Range is a function of DTL).

      Epoch_Range(DTL) = (2^(4*(DTL+1))

   Each point of time between OT and DT is represented by a time unit
   and a fractional time unit; in this section, this combined
   representation is called a rational time unit (RTU).  1 RTU measures
   the smallest fractional time that can be represented between two
   points of time in the epoch (i.e., within the range of interest).

   DT - OT cannot exceed 2^(4*(DTL+1)) == 16^(DTL+1).  A low value of
   DTL leads to a small Epoch_Range; if DTL = 0, there will only be 16
   RTUs within the Epoch_Range (DTL) = 16^1 (for any time unit TU).  The
   values that can be represented in the current epoch are in the range
   [0, (Epoch_Range(DTL) - 1)].  To minimize the required DTL,

Lijo Thomas, et al.      Expires January 9, 2020                [Page 7]
Internet-Draft         6lo Delivery Deadline Time              July 2019

   wraparound is allowed but works naturally with the arithmetic modulo
   Epoch_Range.

   By default, DTL determines t_0 in the chosen RTUs as follows:

      t_0 = [current_time - (current_time mod Epoch_Range (DTL))].

   Naturally, t_0 occurs at time 0 (or time 0.0000...) in the current
   epoch.  The last possible origination time representable in the
   current epoch (counted in RTUs) is t_last = (t0 + (2^(4*(DTL+1))-1)).
   In the RTUs chosen, the current epoch resides at the underlying time
   interval [t_0, t_last].  If DT - OT is greater than t_last - OT, then
   wraparound within the Epoch_Range occurs naturally.  In all cases, OT
   is represented by the value (OT mod Epoch_Range) and DT is
   represented by the value (DT mod Epoch_Range).  All arithmetic is to
   be performed modulo (Epoch_Range(DTL)), yielding only positive values
   for DT - OT.

      Example: Consider a 6TiSCH network with time-slot length of 10ms.
      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:

         deadline_time = packet_origination_time + max_delay

            = 0xD480 + 0x64 (Network ASNs)

            = 0xD4E4 (Network ASNs)

         Then, the Deadline-6LoRHE encoding with nonzero OTL is:

            DTL = 3, OTL = 2, TU = 0b10, BinaryPt = 8, DT = 0xD4E4, OTD
            = 0x64

6.  Deadline-6LoRHE in Three Network Scenarios

   In this section, Deadline-6LoRHE operation is described for 3 network
   scenarios.  Figure 4 depicts a constrained time-synchronized LLN that
   has two subnets N1 and N2, connected through LBRs
   [I-D.ietf-6lo-backbone-router] with different reference clock times
   T1 and T2.

Lijo Thomas, et al.      Expires January 9, 2020                [Page 8]
Internet-Draft         6lo Delivery Deadline Time              July 2019

                          +-------------------+
                          | 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)

                 Figure 4: Intra-network Timezone Scenario

6.1.  Scenario 1: Endpoints in the same DODAG (N1)

   In scenario 1, shown in Figure 5, the Sender 'S' has an IP datagram
   to be routed to a Receiver 'R' within the same DODAG.  For the route
   segment from Sender to 6LBR, the 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 6LBR receives the IP datagram, it sends the
   packet downstream towards 'R'.

   In case of a network running RPL non-storing mode, the 6LBR generates
   a IPv6-in-IPv6 encapsulated packet when sending the packet downwards
   to the Receiver [I-D.ietf-roll-useofrplinfo].  The 6LBR copies the
   Deadline-6LoRHE from the Sender originated IP header to the outer IP
   header.  The Deadline-6LoRHE contained in the inner IP header is
   removed.

Lijo Thomas, et al.      Expires January 9, 2020                [Page 9]
Internet-Draft         6lo Delivery Deadline Time              July 2019

                              +-------+
                   ^          | 6LBR  |       |
                   |          |       |       |
                   |          +-------+       |
           Upward  |         /      /| \      | Downward
           routing |      (F)      / |  \     | routing
                   |     /  \    (C) |  (D)   |
                   |    /    \    |  | / |\   |
                   |  (A)    (B)  : (E)  : R  |
                   |  /|\     | \   / \       |
                   | S : :    : :  :  :       v

            Figure 5: End points within same DODAG (subnet N1)

   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'.

6.2.  Scenario 2: Endpoints in Networks with Dissimilar L2 Technologies.

   In scenario 2, shown in Figure 6, the Sender 'S' (belonging to DODAG
   1) has IP datagram to be routed to a Receiver 'R' over a time-
   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 information reaches the border router, the packet will
   be encoded according to the mechanism prescribed in the other time-
   synchronized network depicted as "Time Synchronized Network" in the
   figure 6.  The specific data encapsulation mechanisms followed in the
   new network are beyond the scope of this document.

Lijo Thomas, et al.      Expires January 9, 2020               [Page 10]
Internet-Draft         6lo Delivery Deadline Time              July 2019

                              +----------------+
                              | Time           |
                              | Synchronized   |------R
                              | Network        |
                              +----------------+
                                      |
                                      |
                            ----------+-----------
                     ^                |
                     |            +---+---+
                     |            | 6LBR  |
            Upward   |            |       |
            routing  |            +------++
                     |        (F)/      /| \
                     |       /  \      / |  \
                     |      /    \   (C) |  (D)
                     |    (A)    (B)  |  | / |\
                     |    /|\     |\  : (E)  : :
                     |   S : :    : :   / \
                                       :   :

      Figure 6: Packet transmission in Dissimilar L2 Technologies or
                                 Internet

   For instance, the IP datagram could be routed to another time
   synchronized deterministic network using the mechanism specified in
   the In-band OAM [I-D.ietf-ippm-ioam-data], and then the deadline time
   would be updated according to the measurement of the current time in
   the new network.

6.3.  Scenario 3: Packet transmission across different DODAGs (N1 to
      N2).

   Consider the scenario depicted in Figure 7, 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 combination of case 1 and case 2 scenarios.
   For the route segment from 'S' to 6LBR1, 'S' includes the Deadline-
   6LoRHE.  Subsequently, each 6LR will perform hop-by-hop operation to
   forward the packet towards the 6LBR1.  Once the IP datagram reaches
   6LBR1 of DODAG1, it applies the same rule as described in Case 2
   while routing the packet to 6LBR2 over a (likely) time synchronized
   wired backhaul.  The wired side of 6LBR2 can be mapped to receiver of
   Case 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'.

Lijo Thomas, et al.      Expires January 9, 2020               [Page 11]
Internet-Draft         6lo Delivery Deadline Time              July 2019

                    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

        Figure 7: Packet transmission in different DODAGs(N1 to N2)

   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.  Once the deadline time is encoded in
   Deadline-6LoRHE, the packet is forwarded to 6LBR of DODAG1.  Suppose
   the packet reaches 6LBR of DODAG1 at ASN 20030.

      current_time = ASN at LBR * slot_length_value

      remaining_time = deadline_time - current_time
      = ((packet_origination_time + max_delay) - current time)
      = (20000 + 100) - 20030
      = 30 (in Network ASNs)
      = 30 * 10^3 milliseconds.

   Once the Deadline Time information reaches the border router, the
   packet will be encoded according to the mechanism prescribed in the
   other time-synchronized network.

7.  IANA Considerations

   This document defines a new Elective 6LoWPAN Routing Header Type, and
   IANA is requested to assign a value (TBD) from the 6LoWPAN Dispatch
   Page1 number space for this purpose.

Lijo Thomas, et al.      Expires January 9, 2020               [Page 12]
Internet-Draft         6lo Delivery Deadline Time              July 2019

                     Elective 6LoRH Type     Value
                   +----------------------+--------+
                   |   Deadline-6LoRHE    |  TBD   |
                   +----------------------+--------+

                      Figure 8: Deadline-6LoRHE type

8.  Synchronization Aspects

   The document supports time representation of the deadline and
   origination times carried in the packets traversing through networks
   of different time zones having different time synchronization
   mechanisms.  For instance, in a 6TiSCH network where the time is
   maintained as ASN time slots, the time synchronization is achieved
   through beaconing among the nodes as described in [RFC7554].  There
   could be 6lo networks that employ NTP where the nodes are
   synchronized with an external reference clock from an NTP server.
   The specification of the time synchronization method that need to be
   followed by a network is beyond the scope of the document.

   The number of hex digits chosen to represent DT, and the portion of
   that field allocated to represent integer number of seconds,
   determines the meaning of t_0, i.e., the meaning of DT == 0 in the
   chosen representation.  If DTL == 0, then there are only 4 bits that
   can be used to count the time units, so that DT == 0 can never be
   more than 16 time units (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
   requirement would be correspondingly tighter.

   A 4-bit field for DT allows up to 16 hex digits, which is 64 bits.
   That is enough to represent the NTP [RFC5905] 64-bit timestamp
   format, which is more than enough for the purposes of establishing
   deadline times.  Unless the binary point is moved, this is enough to
   represent time since year 1900.

   For example, suppose that DTL = 0b0000 and the DT bits are split
   evenly; then we can count up to 3.75 seconds by quarter-seconds.

   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).

   In all cases, t_0 is defined as specified in Section 5

      t_0 = [current_time - (current_time mod (2^(4*(DTL+1))))]

Lijo Thomas, et al.      Expires January 9, 2020               [Page 13]
Internet-Draft         6lo Delivery Deadline Time              July 2019

   regardless of the choice of TU.

   For TU = 0b00, the time units are seconds.  With DTL == 15, and
   Binary Pt == 0, the epoch is (by default) January 1, 1900 at 00:00
   UTC.  The resolution is then (2 ^ (- 32)) seconds, which is the
   maximum possible.  This time format wraps around every 2^32 seconds,
   which is roughly 136 years.

   For TU = 0b10, the time units are ASNs.  The start time is relative,
   and updated by a mechanism out of scope for this document.  With 10
   ms slots, DTL = 15, and Binary Pt == 0, it would take over a year for
   the ASN to wrap around.  Typically, the number of hex digits
   allocated for TU = 0b10 would be less than 15.

9.  Security Considerations

   The security considerations of [RFC4944], [RFC6282] and [RFC6553]
   apply.  Using a compressed format as opposed to the full in-line
   format is logically equivalent and does not create an opening for a
   new threat when compared to [RFC6550], [RFC6553] and [RFC6554].

   The protocol elements specified in this document are designed to work
   in controlled operational environments (e.g., industrial process
   control and automation).  In order to avoid misuse of the deadline
   information that could potentially result in a Denial of Service
   (DoS) attack, proper functioning of this deadline time mechanism
   requires the provisioning and management of network resources for
   supporting traffic flows with deadlines, performance monitoring, and
   admission control policy enforcement.  The network provisioning can
   be done either centrally or in a distributed fashion.  For example,
   tracks in a 6tisch network could be established by a centralized PCE,
   as described in the 6tisch architecture
   [I-D.ietf-6tisch-architecture].

   The Security Considerations of Detnet architecture
   [I-D.ietf-detnet-architecture] mostly apply to this document as well,
   as follows.  To secure the request and control of resources allocated
   for tracks, authentication and authorization can be used for each
   device, and network controller devices.  In the case of distributed
   control protocols, security is expected to be provided by the
   security properties of the protocols in use.

   When deadline bearing flows are identified on a per-flow basis, which
   may provide attackers with additional information about the data
   flows, when compared to networks that do not include per-flow
   identification.  The security implications of disclosing that
   additional information deserve consideration when implementing this
   deadline specification.

Lijo Thomas, et al.      Expires January 9, 2020               [Page 14]
Internet-Draft         6lo Delivery Deadline Time              July 2019

   Because of the requirement of precise time synchronization, the
   accuracy, availability, and integrity of time synchronization is of
   critical importance.  Extensive discussion of this topic can be found
   in [RFC7384].

10.  Acknowledgements

   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.

11.  References

11.1.  Normative References

   [I-D.ietf-6tisch-terminology]
              Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
              "Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e",
              draft-ietf-6tisch-terminology-10 (work in progress), March
              2018.

   [I-D.ietf-detnet-architecture]
              Finn, N., Thubert, P., Varga, B., and J. Farkas,
              "Deterministic Networking Architecture", draft-ietf-
              detnet-architecture-13 (work in progress), May 2019.

   [I-D.ietf-roll-routing-dispatch]
              Thubert, P., Bormann, C., Toutain, L., and R. Cragie,
              "6LoWPAN Routing Header", draft-ietf-roll-routing-
              dispatch-05 (work in progress), October 2016.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
              "Transmission of IPv6 Packets over IEEE 802.15.4
              Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
              <https://www.rfc-editor.org/info/rfc4944>.

Lijo Thomas, et al.      Expires January 9, 2020               [Page 15]
Internet-Draft         6lo Delivery Deadline Time              July 2019

   [RFC5905]  Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
              "Network Time Protocol Version 4: Protocol and Algorithms
              Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
              <https://www.rfc-editor.org/info/rfc5905>.

   [RFC6282]  Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
              Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
              DOI 10.17487/RFC6282, September 2011,
              <https://www.rfc-editor.org/info/rfc6282>.

   [RFC6550]  Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
              Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
              JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
              Low-Power and Lossy Networks", RFC 6550,
              DOI 10.17487/RFC6550, March 2012,
              <https://www.rfc-editor.org/info/rfc6550>.

   [RFC6553]  Hui, J. and JP. Vasseur, "The Routing Protocol for Low-
              Power and Lossy Networks (RPL) Option for Carrying RPL
              Information in Data-Plane Datagrams", RFC 6553,
              DOI 10.17487/RFC6553, March 2012,
              <https://www.rfc-editor.org/info/rfc6553>.

   [RFC6554]  Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
              Routing Header for Source Routes with the Routing Protocol
              for Low-Power and Lossy Networks (RPL)", RFC 6554,
              DOI 10.17487/RFC6554, March 2012,
              <https://www.rfc-editor.org/info/rfc6554>.

   [RFC7384]  Mizrahi, T., "Security Requirements of Time Protocols in
              Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
              October 2014, <https://www.rfc-editor.org/info/rfc7384>.

   [RFC7554]  Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using
              IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the
              Internet of Things (IoT): Problem Statement", RFC 7554,
              DOI 10.17487/RFC7554, May 2015,
              <https://www.rfc-editor.org/info/rfc7554>.

   [RFC8138]  Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,
              "IPv6 over Low-Power Wireless Personal Area Network
              (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,
              April 2017, <https://www.rfc-editor.org/info/rfc8138>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Lijo Thomas, et al.      Expires January 9, 2020               [Page 16]
Internet-Draft         6lo Delivery Deadline Time              July 2019

11.2.  Informative References

   [dot15-tsch]
              "IEEE 802 Wireless", "IEEE Standard for Low-Rate Wireless
              Networks, Part 15.4, IEEE Std 802.15.4-2015", April 2016.

   [dot1AS-2011]
              "IEEE Standards", "IEEE Standard for Local and
              Metropolitan Area Networks - Timing and Synchronization
              for Time-Sensitive Applications in Bridged Local Area
              Networks", March 2011.

   [dotBLEMesh]
              Leonardi, L., Pattim, G., and L. Lo Bello, "Multi-Hop
              Real-Time Communications Over Bluetooth Low Energy
              Industrial Wireless Mesh Networks", IEEE Access Vol 6,
              26505-26519, May 2018.

   [dotWi-SUN]
              Harada, H., Mizutani, K., Fujiwara, J., Mochizuki, K.,
              Obata, K., and R. Okumura, "IEEE 802.15.4g Based Wi-SUN
              Communication Systems", IEICE Transactions on
              Communications volume E100.B, Jan 2017.

   [I-D.ietf-6lo-backbone-router]
              Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6
              Backbone Router", draft-ietf-6lo-backbone-router-11 (work
              in progress), February 2019.

   [I-D.ietf-6lo-blemesh]
              Gomez, C., Darroudi, S., Savolainen, T., and M. Spoerk,
              "IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP",
              draft-ietf-6lo-blemesh-05 (work in progress), March 2019.

   [I-D.ietf-6tisch-architecture]
              Thubert, P., "An Architecture for IPv6 over the TSCH mode
              of IEEE 802.15.4", draft-ietf-6tisch-architecture-24 (work
              in progress), July 2019.

   [I-D.ietf-detnet-use-cases]
              Grossman, E., "Deterministic Networking Use Cases", draft-
              ietf-detnet-use-cases-20 (work in progress), December
              2018.

Lijo Thomas, et al.      Expires January 9, 2020               [Page 17]
Internet-Draft         6lo Delivery Deadline Time              July 2019

   [I-D.ietf-ippm-ioam-data]
              Brockners, F., Bhandari, S., Pignataro, C., Gredler, H.,
              Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov,
              P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon,
              "Data Fields for In-situ OAM", draft-ietf-ippm-ioam-
              data-06 (work in progress), July 2019.

   [I-D.ietf-roll-useofrplinfo]
              Robles, I., Richardson, M., and P. Thubert, "Using RPL
              Option Type, Routing Header for Source Routes and IPv6-in-
              IPv6 encapsulation in the RPL Data Plane", draft-ietf-
              roll-useofrplinfo-31 (work in progress), July 2019.

   [ieee-1588]
              "IEEE Standards", "IEEE Std 1588-2008 Standard for a
              Precision Clock Synchronization Protocol for Networked
              Measurement and Control Systems", July 2008.

   [Wi-SUN_PHY]
              Wi-SUN Alliance, "Wi-SUN PHY Specification V1.0", March
              2016.

Appendix A.  Changes from revision 04 to revision 05

   This section lists the changes between draft-ietf-6lo-deadline-time
   revisions ...-04.txt and ...-05.txt.

   o  Included additional relevant material in Security Considerations
      regarding expected deployment scenarios and the effect of
      disclosing additional information during the travel of a packet.

   o  Reworked the specification for using time ranges shorter than the
      maximum allowed by the choice of TU, so that fewer bits are needed
      to represent DT and OT.

   o  Revised the figures and examples to use new parameters

   o  Reordered the field definitions for the Deadline-6LoRHE.

   o  Responded to numerous reviewer comments to improve terminology and
      editorial consistency.

Appendix B.  Changes from revision 03 to revision 04

   This section lists the changes between draft-ietf-6lo-deadline-time
   revisions ...-03.txt and ...-04.txt.

Lijo Thomas, et al.      Expires January 9, 2020               [Page 18]
Internet-Draft         6lo Delivery Deadline Time              July 2019

   o  Replaced OT (Origination Time) field by OTD (Origination Time
      Delta), allowing a more compressed representation that needs less
      processing during transitions between networks.

   o  Changed representation for DTL, OTL, DT, OTD.  Eliminated EXP in
      favor of BinaryPt.

   o  Revised the figures and examples to use new parameters

   o  Added new section on Synchronization Aspects to supply pertinent
      information about how nodes agree on the meaning of t=0.

   o  Responded to numerous reviewer comments to improve editorial
      consistency and improve terminology.

Appendix C.  Changes from revision 02 to revision 03

   This section lists the changes between draft-ietf-6lo-deadline-time
   revisions ...-02.txt and ...-03.txt.

   o  Added non-normative 6LoRHE description, citing RFC 8138.

   o  Specified that the Origination Time (OT) is the time that packet
      is enqueued for transmission.

   o  Mentioned more sources of packet delay.

   o  Clarified reasons that packet MAY be forwarded if 'D' bit is 0.

   o  Clarified that DT, OT, DTL and OTL are unsigned integers.

   o  Updated bibliographic citations, including BLEmesh and Wi-SUN.

Appendix D.  Changes from revision 01 to revision 02

   This section lists the changes between draft-ietf-6lo-deadline-time
   revisions ...-01.txt and ...-02.txt.

   o  Replaced 6LoRHE description by reference to RFC 8138.

   o  Added figure to illustrate change to Origination Time when a
      packet crosses timezone boundaries.

   o  Clarified that use of 6tisch networks is descriptive, not
      normative.

   o  Clarified that In-Band OAM is used as an example and is not
      normative.

Lijo Thomas, et al.      Expires January 9, 2020               [Page 19]
Internet-Draft         6lo Delivery Deadline Time              July 2019

   o  Updated bibliographic citations.

   o  Alphabetized contributor names.

Appendix E.  Changes between earlier versions

   This section lists the changes between draft-ietf-6lo-deadline-time
   revisions ...-00.txt and ...-01.txt.

   o  Changed "SHOULD drop" to "MUST drop" a packet if the deadline is
      passed (see Section 5).

   o  Added explanatory text about how packet delays might arise.  (see
      Section 4).

   o  Mentioned availability of time-synchronization protocols (see
      Section 1).

   o  Updated bibliographic citations.

   o  Alphabetized contributor names.

   o  Added this section.

Authors' Addresses

   Lijo Thomas
   C-DAC
   Centre for Development of Advanced Computing (C-DAC), Vellayambalam
   Trivandrum  695033
   India

   Email: lijo@cdac.in

   Satish Anamalamudi
   SRM University-AP
   Amaravati Campus
   Amaravati, Andhra Pradesh  522 502
   India

   Email: satishnaidu80@gmail.com

Lijo Thomas, et al.      Expires January 9, 2020               [Page 20]
Internet-Draft         6lo Delivery Deadline Time              July 2019

   S.V.R Anand
   Indian Institute of Science
   Bangalore  560012
   India

   Email: anand@ece.iisc.ernet.in

   Malati Hegde
   Indian Institute of Science
   Bangalore  560012
   India

   Email: malati@ece.iisc.ernet.in

   Charles E. Perkins
   Futurewei
   2330 Central Expressway
   Santa Clara  95050
   Unites States

   Email: charliep@computer.org

Lijo Thomas, et al.      Expires January 9, 2020               [Page 21]