6lo Lijo Thomas
Internet-Draft C-DAC
Intended status: Standards Track S. Anamalamudi
Expires: September 9, 2019 SRM University-AP
Malati Hegde
Indian Institute of Science
C. Perkins
March 8, 2019

Packet Delivery Deadline time in 6LoWPAN Routing Header


This document specifies a new type for the 6LoWPAN routing header containing the deadline time for data packets, designed for use over constrained networks. The deadline time enables forwarding and scheduling decisions for time critical IoT 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 September 9, 2019.

Copyright Notice

Copyright (c) 2019 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 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

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.

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

   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

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.

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. The packet SHOULD be delivered to the Receiver before this time.

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 (OTD) 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 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 'dly'. In this way, within the newly entered network, the packet will appear to have originated 'dly' 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 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 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:

            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.

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

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.

6. Deadline-6LoRHE in Three Network Scenarios

                       | 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

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.

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.

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

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

Figure 6: Packet transmission in Dissimilar L2 Technologies or Internet

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.

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

                 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.

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

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

Figure 8: Deadline-6LoRHE type

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.

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 in the past. This then requires that the time synchronization between sender and receiver has to be tighter than 16 time 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 integer seconds. In that case t_0 would be the most recent second of the current minute that has t mod 4 == 0. In other words, t_0 could be 0, 4, 8, 12, 16, ..., 52, or 56 seconds since the start of the most recent minute. The networks have to be synchronized well enough to ensure detection of overrun, and therefore to know which of those values is the correct value for t_0. This is the hardest case.

If DT = 3 and the DT bits are again split evenly, then we can count up to 4,096 seconds. t_0 would be the start of the most recent hour.

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 other choices of DTL and the Binary Pt, the value of t_0 (i.e., the meaning of DT == 0) needs to be established by means out of scope of this document.

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

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, Seema Kumar, Avinash Mohan, Shalu Rajendran and Anita Varghese 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", Internet-Draft draft-ietf-6tisch-terminology-10, March 2018.
[I-D.ietf-roll-routing-dispatch] Thubert, P., Bormann, C., Toutain, L. and R. Cragie, "6LoWPAN Routing Header", Internet-Draft draft-ietf-roll-routing-dispatch-05, 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.
[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.
[RFC5905] Mills, D., Martin, J., Burbank, J. and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010.
[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011.
[RFC6550] Winter, T., Thubert, P., 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.
[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.
[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.
[RFC7554] Watteyne, T., 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.
[RFC8138] Thubert, P., 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.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.

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", Internet-Draft draft-ietf-6lo-backbone-router-11, 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", Internet-Draft draft-ietf-6lo-blemesh-04, January 2019.
[I-D.ietf-detnet-use-cases] Grossman, E., "Deterministic Networking Use Cases", Internet-Draft draft-ietf-detnet-use-cases-20, December 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", Internet-Draft draft-ietf-ippm-ioam-data-04, October 2018.
[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", Internet-Draft draft-ietf-roll-useofrplinfo-24, January 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 03 to revision 04

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

Appendix B. Changes from revision 03 to revision 04

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

Appendix C. Changes from revision 01 to revision 02

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

Appendix D. Changes between earlier versions

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

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
Charles E. Perkins Futurewei 2330 Central Expressway Santa Clara, 95050 Unites States EMail: charliep@computer.org