[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

6lo                                                          Lijo Thomas
Internet-Draft                                                     C-DAC
Intended status: Standards Track                          S. Anamalamudi
Expires: April 18, 2019                                SRM University-AP
                                                             S.V.R.Anand
                                                            Malati Hegde
                                             Indian Institute of Science
                                                              C. Perkins
                                                               Futurewei
                                                        October 15, 2018


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

Abstract

   This document specifies a new type for the 6LoWPAN routing header
   containing the delivery deadline time for data packets.  The deadline
   time enables forwarding and scheduling decisions for time critical
   IoT M2M applications that need deterministic delay guarantees over
   constrained networks and operate within time-synchronized networks.

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 April 18, 2019.

Copyright Notice

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

   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



Lijo Thomas, et al.      Expires April 18, 2019                 [Page 1]


Internet-Draft         6lo Delivery Deadline Time           October 2018


   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  . . . . . . . . .   7
     6.1.  Scenario 1: Endpoints in the same DODAG (N1)  . . . . . .   8
     6.2.  Scenario 2: Endpoints in Networks with Dissimilar L2
           Technologies. . . . . . . . . . . . . . . . . . . . . . .   9
     6.3.  Scenario 3: Packet transmission across different DODAGs
           (N1 to N2). . . . . . . . . . . . . . . . . . . . . . . .  10
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  12
     10.2.  Informative References . . . . . . . . . . . . . . . . .  13
   Appendix A.  Changes from revision 02 to revision 03  . . . . . .  15
   Appendix B.  Changes from revision 01 to revision 02  . . . . . .  15
   Appendix C.  Changes between earlier versions . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

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.

   The draft [I-D.ietf-roll-routing-dispatch] 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
   specifies a new Deadline-6LoRHE type for the 6LoWPAN Dispatch Page 1,
   so that the deadline time of data packets can be included within the
   6LoWPAN routing header.  This document also specifies handling of the



Lijo Thomas, et al.      Expires April 18, 2019                 [Page 2]


Internet-Draft         6lo Delivery Deadline Time           October 2018


   deadline time when packets traverse through time-synchronized
   networks operating in different timezones or distinct reference
   clocks.  Time synchronization techniques need not be mandated by this
   specificiation.  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 has been 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 also
   being recently 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 terminology consistent with the terminology used
   in [RFC6550] and [I-D.ietf-6tisch-terminology].  Also, in this
   document, the terms "expiration time", "delivery deadline time", and
   "deadline" are used interchangeably with the same meaning.

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     |                                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-             ...               -+
                                      <--          length           -->

                          Figure 1: 6LoRHE format

   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.




Lijo Thomas, et al.      Expires April 18, 2019                 [Page 3]


Internet-Draft         6lo Delivery Deadline Time           October 2018


   o  Type: Type of the 6LoRHE.

   o  length: variable

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 (OT), the time at which the
   packet is enqueued for transmission, to enable a close estimate of
   the total delay incurred by a packet.  The OT field is initialized by
   the sender using the current time at the outgoing network interface
   through which the packet is forwarded.

   The deadline field contains the value of the delivery deadline time
   for the packet.  The packet SHOULD be delivered to the Receiver
   before this time.

      packet_deadline_time = packet_origination_time + max_delay

   All nodes within the network SHOULD process the Deadline-6LoRHE in
   order to support delay-sensitive deterministic applications.  The
   packet deadline time (DT) and origination time (OT) are represented
   in time units determined by a scaling parameter in the routing
   header.  One of the time units is the Network ASN (Absolute Slot
   Number) which can be used in case of 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 the
   packets crosses into a network using a different reference clock, the
   Origination Time field is updated to represent the same Origination
   Time, but expressed using the reference clock of the interface into
   the new network.  This 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 't'.  In this way, within the newly
   entered network, the packet will appear to have originated 't' time
   units earlier with respect to the reference clock of the new network.

   Origination Time in new network = current_time_in_new_network -
                  delay_already_experienced_in_previous_network(s)

   The following example illustrates the origination time calculation
   when a packet travels between three networks, each in a different
   time zone. 'x' can be 1,2 or 3.




Lijo Thomas, et al.      Expires April 18, 2019                 [Page 4]


Internet-Draft         6lo Delivery Deadline Time           October 2018


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

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

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

      TZx : Indicates the time zone of network 'x'

   As an illustration, we consider a packet traversing through three
   time synchronized networks along with numerical values as shown in
   Figure 1.


               TZ1                      TZ2                    TZ3
      T1A=0|                 |                             |
           |----    D1=100   |                             |
           |     \           |                             |
           |      \          |                             |
           |       \ T1D=100 |T2A=1000                     |
           |        -------->|-----             D2=400     |
           |                 |     \                       |
           |                 |      \                      |
           |                 |       \          T2D=1400   | T3A=5000
           |                 |         ------------------->|
           |                 |                             |
           v                 v                             v

         D = 0            D  = T1D-OT            D = T2D-OT
                             = 100-0               = 1400 - 900
                             = 100                 = 500 [= (D1 + D2)]


       OT = T1A-D        OT  = T2A-D           OT  = T3A-D
          = 0                = 1000-100            = 5000 - 500
                             = 900                 = 4500

                 Figure 2: Origination 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 April 18, 2019                 [Page 5]


Internet-Draft         6lo Delivery Deadline Time           October 2018


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   |O|D| DTL | OTL | TU| EXP | Rsv |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      DT (variable length)     | OT(variable length)(optional) |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 3: Deadline-6LoRHE format

   Length (5 bits): Length represents the total length of the Deadline-
   6LoRHE type measured in octets.

   6LoRH Type: TBD

   O flag (1bit): Indicates the presence of Origination Time field.  '1'
   means the OT field is present, and '0' means it is absent.

   D flag (1 bit): The 'D' flag, set by the Sender, indicates 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, implies 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.).

   DTL (3 bits): Length of DT field as an unsigned 3-bit integer,
   encoding the length of the field in octets, minus one.

   OTL (3 bits) : Length of OT field as an unsigned 3-bit integer,
   encoding the length of the field in octets, minus one.

      For example, DTL = 000 means the deadline time in the 6LoRHE is 1
      octet (8 bits) long.  Similarly, OTL = 111 means the origination
      time is 8 octets (64 bits) long.

   TU (2 bits) : Indicates the time units for DT and OT fields

      00 : Time represented in microseconds
      01 : Time represented in seconds
      10 : Network ASN
      11 : Reserved

   EXP (3 bits) : Multiplication factor expressed as exponent of 10.



Lijo Thomas, et al.      Expires April 18, 2019                 [Page 6]


Internet-Draft         6lo Delivery Deadline Time           October 2018


      The value of the DT field is multiplied by 10 to this power, to
      get the actual deadline time in the units represented by TU.  The
      default value of EXP is 000, so that the DT field is unaffected.

   Rsv (3 bits) : Reserved, sent as zero and ignored on receipt

   DT Value (8..64-bit) : An unsigned integer of DTL octets giving the
   Deadline Time value

   OT Value (8..64-bit) : An unsigned integer of OTL octets giving the
   Origination Time value

   Whenever a sender initiates the IP datagram, it includes the
   Deadline-6LoRHE along with other 6LoRH information.

   Example: Consider a 6TiSCH network with time-slot length of 10ms.
   Let the current ASN when the packet is originated be 54400, and the
   maximum allowable delay (max_delay) for the packet delivery is 1
   second from the packet origination, then:

      deadline_time = packet_origination_time + max_delay
      = 55400 + 100 (in Network ASNs)
      = 55500(Network ASNs)

   Deadline-6LoRHE encoding with 'O' flag and 'D' flag set to 1:

      DTL = 001, OTL = 001, TU = '10', EXP = 2, DT = 0x22B, OT = 0x22A

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 April 18, 2019                 [Page 7]


Internet-Draft         6lo Delivery Deadline Time           October 2018


                          +-------------------+
                          | 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 April 18, 2019                 [Page 8]


Internet-Draft         6lo Delivery Deadline Time           October 2018


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

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

   At the tunnel endpoint of the IPv6-in-IPv6 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 April 18, 2019                 [Page 9]


Internet-Draft         6lo Delivery Deadline Time           October 2018


                              +----------------+
                              | 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 April 18, 2019                [Page 10]


Internet-Draft         6lo Delivery Deadline Time           October 2018


                    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 accoding 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 April 18, 2019                [Page 11]


Internet-Draft         6lo Delivery Deadline Time           October 2018


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

                      Figure 8: Deadline-6LoRHE type

8.  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].

9.  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, Seema Kumar, Avinash Mohan, Shalu Rajendran and Anita
   Varghese for their support and valuable feedback.

10.  References

10.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-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 April 18, 2019                [Page 12]


Internet-Draft         6lo Delivery Deadline Time           October 2018


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

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

10.2.  Informative References

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

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







Lijo Thomas, et al.      Expires April 18, 2019                [Page 13]


Internet-Draft         6lo Delivery Deadline Time           October 2018


   [dotBLEMesh]
              Luca Leonardi, Gaetano Pattim, and Lucia 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]
              Hiroshi Harada, Keiichi Mizutani, Jun Fujiwara, Kentaro
              Mochizuki, Kentaro Obata, and Okumura, Ryota, "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. and C. Perkins, "IPv6 Backbone Router", draft-
              ietf-6lo-backbone-router-07 (work in progress), September
              2018.

   [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-03 (work in progress), July 2018.

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

   [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-03 (work in progress), June 2018.

   [I-D.ietf-roll-useofrplinfo]
              Robles, I., Richardson, M., and P. Thubert, "When to use
              RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll-
              useofrplinfo-23 (work in progress), May 2018.

   [ieee-1588]
              Precise Time and Time Interval Working Group, "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.




Lijo Thomas, et al.      Expires April 18, 2019                [Page 14]


Internet-Draft         6lo Delivery Deadline Time           October 2018


Appendix A.  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 B.  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.

   o  Updated bibliographic citations.

   o  Alphabetized contributor names.

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



Lijo Thomas, et al.      Expires April 18, 2019                [Page 15]


Internet-Draft         6lo Delivery Deadline Time           October 2018


   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


   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








Lijo Thomas, et al.      Expires April 18, 2019                [Page 16]


Internet-Draft         6lo Delivery Deadline Time           October 2018


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

   Email: charliep@computer.org












































Lijo Thomas, et al.      Expires April 18, 2019                [Page 17]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/