< draft-ietf-6lo-deadline-time-00.txt   draft-ietf-6lo-deadline-time-01.txt >
6lo Lijo Thomas 6lo Lijo Thomas
Internet-Draft C-DAC Internet-Draft C-DAC
Intended status: Standards Track P. Akshay Intended status: Standards Track P. Akshay
Expires: May 17, 2018 Indian Institute of Science Expires: September 5, 2018 Smarten Spaces
Satish Anamalamudi Satish Anamalamudi
Huaiyin Institute of Technology Huaiyin Institute of Technology
S.V.R.Anand S.V.R.Anand
Malati Hegde Malati Hegde
Indian Institute of Science Indian Institute of Science
C. Perkins C. Perkins
Futurewei Futurewei
November 13, 2017 March 4, 2018
Packet Delivery Deadline time in 6LoWPAN Routing Header Packet Delivery Deadline time in 6LoWPAN Routing Header
draft-ietf-6lo-deadline-time-00 draft-ietf-6lo-deadline-time-01
Abstract Abstract
This document specifies a new type for the 6LoWPAN routing header This document specifies a new type for the 6LoWPAN routing header
containing the delivery deadline time for data packets. The deadline containing the delivery deadline time for data packets. The deadline
time enables forwarding and scheduling decisions for time critical time enables forwarding and scheduling decisions for time critical
IoT M2M applications that need deterministic delay guarantees over IoT M2M applications that need deterministic delay guarantees over
constrained networks and operate within time-synchronized networks. constrained networks and operate within time-synchronized networks.
Status of This Memo Status of This Memo
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 17, 2018. This Internet-Draft will expire on September 5, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. 6LoRHE Generic Format . . . . . . . . . . . . . . . . . . . . 3 3. 6LoRHE Generic Format . . . . . . . . . . . . . . . . . . . . 3
4. Deadline-6LoRHE . . . . . . . . . . . . . . . . . . . . . . . 3 4. Deadline-6LoRHE . . . . . . . . . . . . . . . . . . . . . . . 4
5. Deadline-6LoRHE Format . . . . . . . . . . . . . . . . . . . 4 5. Deadline-6LoRHE Format . . . . . . . . . . . . . . . . . . . 5
6. Deadline-6LoRHE in Three Network Scenarios . . . . . . . . . 6 6. Deadline-6LoRHE in Three Network Scenarios . . . . . . . . . 6
6.1. Scenario 1: Endpoints in the same DODAG (N1) in non- 6.1. Scenario 1: Endpoints in the same DODAG (N1) in non-
storing mode. . . . . . . . . . . . . . . . . . . . . . . 6 storing mode. . . . . . . . . . . . . . . . . . . . . . . 7
6.2. Scenario 2: Endpoints in Networks with Dissimilar L2 6.2. Scenario 2: Endpoints in Networks with Dissimilar L2
Technologies. . . . . . . . . . . . . . . . . . . . . . . 7 Technologies. . . . . . . . . . . . . . . . . . . . . . . 8
6.3. Scenario 3: Packet transmission across different DODAGs 6.3. Scenario 3: Packet transmission across different DODAGs
(N1 to N2). . . . . . . . . . . . . . . . . . . . . . . . 8 (N1 to N2). . . . . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Appendix A. Changes Since draft-ietf-6lo-deadline-time-00 . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Low Power and Lossy Networks (LLNs) are likely to be deployed for Low Power and Lossy Networks (LLNs) are likely to be deployed for
real time industrial applications requiring end-to-end delay real time industrial applications requiring end-to-end delay
guarantees [I-D.grossman-detnet-use-cases]. A Deterministic Network guarantees [I-D.ietf-detnet-use-cases]. A Deterministic Network
("detnet") typically requires some data packets to reach their ("detnet") typically requires some data packets to reach their
receivers within strict time bounds. Intermediate nodes use the receivers within strict time bounds. Intermediate nodes use the
deadline information to make appropriate packet forwarding and deadline information to make appropriate packet forwarding and
scheduling decisions to meet the time bounds. scheduling decisions to meet the time bounds.
The draft [I-D.ietf-roll-routing-dispatch] specifies the 6LoWPAN The draft [I-D.ietf-roll-routing-dispatch] specifies the 6LoWPAN
Routing Header (6LoRH), compression schemes for RPL routing (source Routing Header (6LoRH), compression schemes for RPL routing (source
routing) operation [RFC6554], header compression of RPL Packet routing) operation [RFC6554], header compression of RPL Packet
Information [RFC6553], and IP-in-IP encapsulation. This document Information [RFC6553], and IP-in-IP encapsulation. This document
specifies a new Deadline-6LoRHE type for the 6LoWPAN Dispatch Page 1, 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 so that the deadline time of data packets can be included within the
6LoWPAN routing header. This document also specifies handling of the 6LoWPAN routing header. This document also specifies handling of the
deadline time when packets traverse through time-synchronized deadline time when packets traverse through time-synchronized
networks operating in different timezones or distinct reference networks operating in different timezones or distinct reference
clocks. 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.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
This document uses terminology consistent with the terminology used This document uses terminology consistent with the terminology used
in [RFC6550] and [I-D.ietf-6tisch-terminology]. Also, in this in [RFC6550] and [I-D.ietf-6tisch-terminology]. Also, in this
skipping to change at page 4, line 37 skipping to change at page 4, line 44
Time as expressed using the reference clock of the outgoing interface Time as expressed using the reference clock of the outgoing interface
into the new network. This is the same as the current time when the 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 packet is transmitted into the new network, minus the delay already
experienced by the packet, say 't'. In effect, to the newly entered experienced by the packet, say 't'. In effect, to the newly entered
network, the packet will appear to have originated 't' time units network, the packet will appear to have originated 't' time units
earlier with respect to the reference clock of the new network. earlier with respect to the reference clock of the new network.
Origination Time in new network = current_time_in_new_network - Origination Time in new network = current_time_in_new_network -
delay_already_experienced_in_previous_network(s) delay_already_experienced_in_previous_network(s)
There are multiple ways that a packet can be delayed, including
propagation delay and queuing 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 5. Deadline-6LoRHE Format
0 1 2 3 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 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 | |1|0|1| Length | 6LoRH Type |O|D| DTL | OTL | TU| EXP | Rsv |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DT (variable length) | OT(variable length)(optional) | | DT (variable length) | OT(variable length)(optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 5, line 12 skipping to change at page 5, line 27
Length (5 bits): Length represents the total length of the Deadline- Length (5 bits): Length represents the total length of the Deadline-
6LoRHE type measured in octets. 6LoRHE type measured in octets.
6LoRH Type: TBD 6LoRH Type: TBD
O flag (1bit): Indicates the presence of Origination Time field. '1' O flag (1bit): Indicates the presence of Origination Time field. '1'
means the OT field is present, and '0' means it is absent. 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 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. to be taken when a 6LR detects that the deadline time has elapsed.
If 'D' bit is 1, then the 6LR SHOULD drop the packet if the deadline If 'D' bit is 1, then the 6LR MUST drop the packet if the deadline
time is elapsed. If 'D' bit is 0, then the 6LR MAY ignore the time is elapsed. If 'D' bit is 0, then the 6LR MAY ignore the
deadline time and forward the packet. deadline time and forward the packet.
DTL (3 bits): Length of DT field. DTL (3 bits): Length of DT field.
OTL (3 bits) : Length of OT field. OTL (3 bits) : Length of OT field.
For example, DTL = 000 means the deadline time in the 6LoRHE is 1 For example, DTL = 000 means the deadline time in the 6LoRHE is 1
octet (8 bits) long. Similarly, OTL = 111 means the origination octet (8 bits) long. Similarly, OTL = 111 means the origination
time is 8 octets (64 bits) long. time is 8 octets (64 bits) long.
skipping to change at page 7, line 33 skipping to change at page 8, line 18
6.2. Scenario 2: Endpoints in Networks with Dissimilar L2 Technologies. 6.2. Scenario 2: Endpoints in Networks with Dissimilar L2 Technologies.
In scenario 2, shown in Figure 5, the Sender 'S' (belonging to DODAG In scenario 2, shown in Figure 5, the Sender 'S' (belonging to DODAG
1) has IP datagram to be routed to a Receiver 'R' over a time- 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, synchronized IPv6 network. For the route segment from 'S' to 6LBR,
'S' includes a Deadline-6LoRHE. Subsequently, 6LR will perform hop- 'S' includes a Deadline-6LoRHE. Subsequently, 6LR will perform hop-
by-hop operation to forward the packet towards the 6LBR. Once the IP by-hop operation to forward the packet towards the 6LBR. Once the IP
datagram reaches 6LBR of DODAG1, it encodes the deadline time (and, datagram reaches 6LBR of DODAG1, it encodes the deadline time (and,
if available, the origination time) into the In-band OAM header if available, the origination time) into the In-band OAM header
extension, [I-D.brockners-inband-oam-data] and passes the datagram to extension, [I-D.ietf-ippm-ioam-data] and passes the datagram to the
the IPv6 layer for further routing. IPv6 layer for further routing.
+----------------+ +----------------+
| Time | | Time |
| synchronized |------R | synchronized |------R
| Network | | Network |
+----------------+ +----------------+
| |
| |
----------+----------- ----------+-----------
^ | ^ |
skipping to change at page 10, line 26 skipping to change at page 10, line 40
format is logically equivalent and does not create an opening for a format is logically equivalent and does not create an opening for a
new threat when compared to [RFC6550], [RFC6553] and [RFC6554]. new threat when compared to [RFC6550], [RFC6553] and [RFC6554].
9. Acknowledgements 9. Acknowledgements
The authors thank Pascal Thubert for suggesting the idea and The authors thank Pascal Thubert for suggesting the idea and
encouraging the work. Thanks to Shwetha Bhandari's suggestions which encouraging the work. Thanks to Shwetha Bhandari's suggestions which
were instrumental in extending the timing information to were instrumental in extending the timing information to
heterogeneous networks. The authors acknowledge the 6TiSCH WG heterogeneous networks. The authors acknowledge the 6TiSCH WG
members for their inputs on the mailing list. Special thanks to members for their inputs on the mailing list. Special thanks to
Jerry Daniel,Shalu Rajendran, Seema Kumar, Avinash Mohan and Anita Jerry Daniel, Seema Kumar, Avinash Mohan, Shalu Rajendran and Anita
Varghese for their support and valuable feedback. Varghese for their support and valuable feedback.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-6tisch-terminology] [I-D.ietf-6tisch-terminology]
Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
"Terminology in IPv6 over the TSCH mode of IEEE "Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e",
802.15.4e", draft-ietf-6tisch-terminology-09 (work in draft-ietf-6tisch-terminology-10 (work in progress), March
progress), June 2017. 2018.
[I-D.ietf-roll-routing-dispatch] [I-D.ietf-roll-routing-dispatch]
Thubert, P., Bormann, C., Toutain, L., and R. Cragie, Thubert, P., Bormann, C., Toutain, L., and R. Cragie,
"6LoWPAN Routing Header", draft-ietf-roll-routing- "6LoWPAN Routing Header", draft-ietf-roll-routing-
dispatch-05 (work in progress), October 2016. dispatch-05 (work in progress), October 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 11, line 31 skipping to change at page 11, line 46
<https://www.rfc-editor.org/info/rfc6553>. <https://www.rfc-editor.org/info/rfc6553>.
[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
Routing Header for Source Routes with the Routing Protocol Routing Header for Source Routes with the Routing Protocol
for Low-Power and Lossy Networks (RPL)", RFC 6554, for Low-Power and Lossy Networks (RPL)", RFC 6554,
DOI 10.17487/RFC6554, March 2012, DOI 10.17487/RFC6554, March 2012,
<https://www.rfc-editor.org/info/rfc6554>. <https://www.rfc-editor.org/info/rfc6554>.
10.2. Informative References 10.2. Informative References
[I-D.brockners-inband-oam-data] [dot15-tsch]
Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., P802.11, "IEEE Standard for Low-Rate Wireless Networks,
Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, Part 15.4, IEEE Std 802.15.4-2015", April 2016.
P., Chang, R., and d. daniel.bernier@bell.ca, "Data Fields
for In-situ OAM", draft-brockners-inband-oam-data-07 (work
in progress), July 2017.
[I-D.grossman-detnet-use-cases] [dot1AS-2011]
Grossman, E., Gunther, C., Thubert, P., Wetterwald, P., IEEE 802.1AS Working Group, "IEEE Standard for Local and
Raymond, J., Korhonen, J., Kaneko, Y., Das, S., and Y. Metropolitan Area Networks - Timing and Synchronization
Zha, "Deterministic Networking Use Cases", draft-grossman- for Time-Sensitive Applications in Bridged Local Area
detnet-use-cases-01 (work in progress), November 2015. Networks", March 2011.
[I-D.ietf-6lo-backbone-router] [I-D.ietf-6lo-backbone-router]
Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo- Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo-
backbone-router-04 (work in progress), July 2017. backbone-router-06 (work in progress), February 2018.
[I-D.ietf-detnet-use-cases]
Grossman, E., "Deterministic Networking Use Cases", draft-
ietf-detnet-use-cases-14 (work in progress), February
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., and d. daniel.bernier@bell.ca, "Data Fields
for In-situ OAM", draft-ietf-ippm-ioam-data-01 (work in
progress), October 2017.
[I-D.ietf-roll-useofrplinfo] [I-D.ietf-roll-useofrplinfo]
Robles, I., Richardson, M., and P. Thubert, "When to use Robles, I., Richardson, M., and P. Thubert, "When to use
RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll- RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll-
useofrplinfo-19 (work in progress), October 2017. useofrplinfo-22 (work in progress), March 2018.
[I-D.vilajosana-6tisch-minimal] [ieee-1588]
Vilajosana, X. and K. Pister, "Minimal 6TiSCH Precise Time and Time Interval Working Group, "IEEE Std
Configuration", draft-vilajosana-6tisch-minimal-00 (work 1588-2008 Standard for a Precision Clock Synchronization
in progress), October 2013. Protocol for Networked Measurement and Control Systems",
July 2008.
Appendix A. Changes Since draft-ietf-6lo-deadline-time-00
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 Authors' Addresses
Lijo Thomas Lijo Thomas
C-DAC C-DAC
Trivandrum 695033 Trivandrum 695033
India India
Email: lijo@cdac.in Email: lijo@cdac.in
P.M. Akshay P.M. Akshay
Indian Institute of Science Smarten Spaces
Bangalore 560012 Bangalore 560103
India India
Email: akshaypm@ece.iisc.ernet.in Email: akshay.pm@smartenspaces.com
Satish Anamalamudi Satish Anamalamudi
Huaiyin Institute of Technology Huaiyin Institute of Technology
No.89 North Beijing Road, Qinghe District No.89 North Beijing Road, Qinghe District
Huaian Huaian
China China
Email: satishnaidu80@gmail.com Email: satishnaidu80@gmail.com
S.V.R Anand S.V.R Anand
 End of changes. 24 change blocks. 
41 lines changed or deleted 81 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/