Skip to main content

Packet expiration time in 6LoWPAN Routing Header
draft-lijo-6lo-expiration-time-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Lijo Thomas , P.M. Akshay , Satish Anamalamudi , S.V.R Anand , Malati Hegde , Charles E. Perkins
Last updated 2016-10-28
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-lijo-6lo-expiration-time-00
6lo                                                          Lijo Thomas
Internet-Draft                                                     C-DAC
Intended status: Standards Track                               P. Akshay
Expires: May 1, 2017                         Indian Institute of Science
                                                      Satish Anamalamudi
                                                  Individual Contributor
                                                             S.V.R.Anand
                                                            Malati Hegde
                                             Indian Institute of Science
                                                              C. Perkins
                                                               Futurewei
                                                        October 28, 2016

            Packet expiration time in 6LoWPAN Routing Header
                   draft-lijo-6lo-expiration-time-00

Abstract

   This document specifies a new type to the 6LoWPAN Dispatch Page 1
   [I-D.ietf-roll-routing-dispatch] for carrying the expiration time of
   data packets within the 6LoWPAN routing header.  The expiration time
   is useful in making 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 http://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 May 1, 2017.

Lijo Thomas, et al.        Expires May 1, 2017                  [Page 1]
Internet-Draft       draft-lijo-6lo-expiration-time-        October 2016

Copyright Notice

   Copyright (c) 2016 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
   (http://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.  6LoRHC Header Format  . . . . . . . . . . . . . . . . . . . .   3
   4.  Timestamp-6LoRH header  . . . . . . . . . . . . . . . . . . .   3
   5.  Timestamp-6LoRH Header in Heterogeneous Network Scenarios . .   5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   Low Power and Lossy Networks (LLNs) could be employed for
   implementing real time industrial applications that require end-to-
   end delay guarantees [I-D.grossman-detnet-use-cases].  The
   Deterministic Network requires that data packets generated by the
   senders have to reach the receivers within strict time bounds.
   Including an expiration time information in the packets enables
   intermediate nodes to make appropriate packet forwarding and
   scheduling decisions to meet this requirement.

   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 RPI field
   [RFC6553], and IP-in-IP encapsulation.  This document specifies a new
   Timestamp-6LoRH type to the 6LoWPAN Dispatch Page 1 for including the
   expiration time of data packets within the 6LoWPAN routing header.
   In addition, this specification specifies handling of the expiration

Lijo Thomas, et al.        Expires May 1, 2017                  [Page 2]
Internet-Draft       draft-lijo-6lo-expiration-time-        October 2016

   time when packets traverse through time-synchronized networks
   operating in different timezones and distinct reference clocks.

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

3.  6LoRHC Header Format

   The generic header format of the 6LoRHC header is specified in
   [I-D.ietf-roll-routing-dispatch].  Figure 1 describes the generic
   header format for the 6LoRHC header.

      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-             ...               -+
     |1|0|X|   TSE   |      Type     |                                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-             ...               -+
                                      <-- Length implied by Type/TSE -->

                      Figure 1: 6LoRHC header format

   1.  X bit: In Figure 1, if 'X' is 0 then it is a critical header.  If
       'X' is 1, then it is a elective header.

   2.  TSE: Type Specific Extension.  The meaning depends on the Type,
       which must be known to all the nodes.  The interpretation of the
       TSE depends on the Type field that follows.  For instance, it may
       be used to transport control bits, the number of elements in an
       array, or the length of the remainder of 6LoRHC expressed in a
       unit other than bytes.

   3.  Type: Type of the 6LoRHC.

   4.  Length: variable

4.  Timestamp-6LoRH header

   The Timestamp-6LoRH header (see Figure 2) is an elective 6LoRH header
   that provides a compressed form of expiration time for an IPv6
   datagram.  All nodes within the network SHOULD support the Timestamp-
   6LoRH header in order to support delay-sensitive deterministic
   applications.  In this specification, the packet origination time is
   represented in microseconds.  In the case of 6tisch networks which is

Lijo Thomas, et al.        Expires May 1, 2017                  [Page 3]
Internet-Draft       draft-lijo-6lo-expiration-time-        October 2016

   explained below, the origination time is the current ASN
   [I-D.vilajosana-6tisch-minimal] converted into microseconds.

        0               1
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-  -+-    -+ ... +- ... ...-+
       |1|0|1|D| Size  |6LoRH Type TBD |Expiration time in microsec |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-  -+-    -+ ... +-  .. .. -+

                  Figure 2: Timestamp-6LoRH header format

   D flag (1 bit): The 'D' flag, set by the Sender, indicates the action
   that needs to be taken when an 6LR detects expiration time is
   elapsed.  If 'D' bit is 1, then the 6LR SHOULD drop the packet if the
   expiration time is elapsed.  If 'D' bit is 0, then the 6LR can choose
   to ignore the expiration time and forward it.

   Size (4 bits): Size represents the total length of expiration time
   measured in octets.  In this specification, the maximum length of the
   expiration time is 8 octets (64 bits).

   For example, Size = 0001 means the expiration time in the 6LoRHC
   timestamp header is 1 octet (8 bits) long.  Likewise, Size = 1000
   means the expiration time in the 6LoRHC timestamp header is 8 octet
   (64 bits) long.

   6LoRH Type: In this specification, Type value for the Timestamp-6LoRH
   is TBD.

   Expiration time: This field describes the time limit before which the
   packet SHOULD be delivered to the Receiver:

      expiration_time = packet_origination_time +
      max_allowable_transmission_delay.

   Whenever the Sender initiates the IP datagram, it includes the
   Timestamp-6LoRH header along with other 6LoRH routing header
   information.  The 6LoRH timestamp contains the expiration time as
   given in the above expression.  Since the maximum allowable
   transmission delay is specific to each application, the expiration
   time is of variable length.

   Example: In a 6TiSCH network let the time-slot length be 10ms.  If
   the packet_origination_time = Current ASN is 200, and the
   max_allowable_delay is 1 second, then:

      expiration_time = packet_origination_time + max_allowable_delay
      = 200*10ms + 1 second

Lijo Thomas, et al.        Expires May 1, 2017                  [Page 4]
Internet-Draft       draft-lijo-6lo-expiration-time-        October 2016

      = 3 * 10^6 microseconds

   This expiration time requires 22 bits, or 3 octets, in length.  The
   Size is represented as x0011.

5.  Timestamp-6LoRH Header in Heterogeneous Network Scenarios

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

                          +-------------------+
                          | 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 (N1 sub-net)   6LoWPAN Network (N2 sub-net)

                 Figure 3: Intra-network Timezone Scenario

   Case 1: Endpoints in the same DODAG(N1 sub-net) in non-storing mode.

   Let us consider the scenario, as shown in Figure 4, where 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 Timestamp-6LoRH header.  Subsequently, 6LR will perform
   hop-by-hop operation to forward the packet towards the 6LBR.  Once
   the IP datagram reaches 6LBR, it generates IPv6-in-IPv6 encapsulated
   packet when sending the packet downwards to the Receiver
   [I-D.ietf-roll-useofrplinfo].  The 6LBR copies the Timestamp-6LoRH
   header from the Sender originated IP header to the outer IP header.
   The Timestamp-6LoRH header contained in the inner IP header is
   elided.

Lijo Thomas, et al.        Expires May 1, 2017                  [Page 5]
Internet-Draft       draft-lijo-6lo-expiration-time-        October 2016

   At the tunnel endpoint of IPv6-in-IPv6 encapsulation, the Timestamp-
   6LoRH header is copied back from the outer header to inner header,
   and the inner IP packet is handed over to 'R'.

                              +-------+
                   ^          | 6LBR  |       |
                   |          |       |       |
                   |          +-------+       |
           Default |      (F)/      /| \      | IP-in-IP
           routing |     /  \      / |  \     |      Encapsulation
                   |    /    \   (C) |  (D)   |
                   |  (A)    (B) /   | / |\   |
                   |  /|\     |\:   (E)  : R  |
                     S : :    :     / \       V

            Figure 4: End points within same DODAG(N1 sub-net)

   Case 2: Packet transmission in Heterogeneous Deterministic Networks
   (Heterogeneous L2 Technologies)

   Let us consider the scenario, as shown in Figure 5, where 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 Timestamp-6LoRH header.

                           +----------------+
                           | Time           |
                           | synchronized   |------R
                           | network        |
                           |----------------+
                                   |
                                   |
                         ----------+-----------
                  ^                |
                  |            +---+---+
                  |            | 6LBR  |
         Default  |            |       |
          routing |            +-------+
                  |        (F)/      /| \
                  |       /  \      / |  \
                  |      /    \   (C) |  (D)
                    :  (A)    (B) /   | / |\
                       /|\     |\:   (E)  :
                      S : :    :     / \
                                    :   :

   Figure 5: Packet transmission in different Deterministic Networks or
                                 Internet

Lijo Thomas, et al.        Expires May 1, 2017                  [Page 6]
Internet-Draft       draft-lijo-6lo-expiration-time-        October 2016

   Subsequently, 6LR will perform hop-by-hop operation to forward the
   packet towards the 6LBR.  Once the IP datagram reaches 6LBR of
   DODAG1, it performs the following operation.  It computes the
   remaining time by subtracting the elapsed time from the expiration
   time.  The Timestamp-6LoRH header is updated with the remaining time.
   This value can then be encoded into In-band OAM Edge to Edge option
   [I-D.brockners-inband-oam-data] and handed over to IPv6 layer for
   further routing.  Since the IP datagram is routed to another time
   synchronized deterministic network following its own distinct
   reference clock, the expiration time in In-band OAM is updated by
   adding the remaining time to the current time according to the time
   synchronization of the network of the outgoing interface.

   Case 3: Packet transmission across different DODAGs (N1 to N2)

   Let us consider the scenario, as shown in Figure 6, where the Sender
   'S' (belonging to DODAG 1) has an IP datagram to be sent to Receiver
   'R' belonging to another DODAG (DODAG 2).  For the route segment from
   'S' to 6LBR, 'S' includes the Timestamp-6LoRH header.  Subsequently,
   each 6LR will perform hop-by-hop operation to forward the packet
   towards the 6LBR.  Once the IP datagram reaches 6LBR of DODAG1, it
   performs the following operation.  It computes the remaining time by
   subtracting the elapsed time from the expiration time.  The
   expiration time in the Timestamp-6LoRH header is updated with the
   remaining time.  It will then forward the packet to 6LBR of DODAG2.
   Once the IP datagram reaches 6LBR of DODAG2, it updates the
   Timestamp-6LoRH header by adding the current time of DODAG2.
   Further, it generates IPv6-in-IPv6 encapsulated packet when sending
   the packet downwards to the Receiver [I-D.ietf-roll-useofrplinfo].

                     Time synchronized network
                  -+---------------------------+-
                   |                           |
      DODAG1   +---+---+                   +---+---+   DODAG2
    Instance 1 | 6LBR  |                   | 6LBR  | Instance 2
               |       |                   |       |     |
               +-------+                   +-------+     |
           (F)/      /| \              (F)/      /| \    |
          /  \      / |  \            /  \      / |  \   |
         /    \   (C) |  (D)         /    \   (C) |  (D) |IP-in-IP
       (A)    (B) /   | / |\       (A)    (B) /   | / |\ | Encapsulation
       /|\     |\:   (E)  : :      /|\     |\:   (E)  : :|
      S : :    :     / \          : : :    :     / \     |
                    :   :                       :   R    V
   Network N1, time zone T1      NetWork N2, time zone T2

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

Lijo Thomas, et al.        Expires May 1, 2017                  [Page 7]
Internet-Draft       draft-lijo-6lo-expiration-time-        October 2016

   Let us consider an example of a 6TiSCH network where S in DODAG1
   generates the packet at ASN 200 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 expiration time is encoded in
   Timestamp-6LoRH header, the packet is forwarded to LBR of DODAG1.
   Let us say the packet reaches LBR of DODAG1 at ASN 250.

   current_time = ASN at LBR * slot_length_value.

   remaining_time = expiration_time - current_time.

   = ((packet_origination_time + max_allowable_transmission_delay) -
   current time)

      = (200*10 ms + 1 second) - 2.5 seconds
      = 0.5 second
      = 5 * 10^5 microseconds.

   The remaining time is encoded in In-Band OAM (see Case 2) and
   forwarded to LBR2 over a different L2-interface, typically wired.
   Once the packet reaches LBR2, the expiration time in Timestamp-6LoRH
   header is re-calculated by adding to it the current ASN, before
   forwarding the packet to its connected 6TiSCH network.

6.  IANA Considerations

   This document defines a new 6LoWPAN Timestamp Header Type, and
   assigned a value of TBD from the 6LoWPAN Dispatch Page1 number space.

                        6LoRH Type      Value
                   +------------------+--------+
                   | Timestamp-6LoRH  | TBD    |
                   +------------------+--------+

                   Figure 7: Timestamp-6LoRH header type

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

Lijo Thomas, et al.        Expires May 1, 2017                  [Page 8]
Internet-Draft       draft-lijo-6lo-expiration-time-        October 2016

8.  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 J for his support and valuable feedback.

9.  References

9.1.  Normative References

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

   [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,
              <http://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,
              <http://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,
              <http://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,
              <http://www.rfc-editor.org/info/rfc6554>.

Lijo Thomas, et al.        Expires May 1, 2017                  [Page 9]
Internet-Draft       draft-lijo-6lo-expiration-time-        October 2016

9.2.  Informative References

   [I-D.brockners-inband-oam-data]
              Brockners, F., Bhandari, S., Pignataro, C., Gredler, H.,
              Leddy, J., and S. Youell, "Data Formats for In-band OAM",
              draft-brockners-inband-oam-data-01 (work in progress),
              July 2016.

   [I-D.grossman-detnet-use-cases]
              Grossman, E., Gunther, C., Thubert, P., Wetterwald, P.,
              Raymond, J., Korhonen, J., Kaneko, Y., Das, S., and Y.
              Zha, "Deterministic Networking Use Cases", draft-grossman-
              detnet-use-cases-01 (work in progress), November 2015.

   [I-D.ietf-6lo-backbone-router]
              Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo-
              backbone-router-02 (work in progress), September 2016.

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

   [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-09 (work in progress), October 2016.

   [I-D.vilajosana-6tisch-minimal]
              Vilajosana, X. and K. Pister, "Minimal 6TiSCH
              Configuration", draft-vilajosana-6tisch-minimal-00 (work
              in progress), October 2013.

Authors' Addresses

   Lijo Thomas
   C-DAC
   Trivandrum  695033
   India

   Email: lijo@cdac.in

Lijo Thomas, et al.        Expires May 1, 2017                 [Page 10]
Internet-Draft       draft-lijo-6lo-expiration-time-        October 2016

   P.M. Akshay
   Indian Institute of Science
   Bangalore  560012
   India

   Email: akshaypm@ece.iisc.ernet.in

   Satish Anamalamudi
   Individual Contributor

   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

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

   Email: charliep@computer.org

Lijo Thomas, et al.        Expires May 1, 2017                 [Page 11]