draft-ietf-6lo-deadline-time-01.txt   draft-ietf-6lo-deadline-time-02.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 S. Anamalamudi
Expires: September 5, 2018 Smarten Spaces Expires: March 4, 2019 SRM University-AP
Satish Anamalamudi
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
March 4, 2018 August 31, 2018
Packet Delivery Deadline time in 6LoWPAN Routing Header Packet Delivery Deadline time in 6LoWPAN Routing Header
draft-ietf-6lo-deadline-time-01 draft-ietf-6lo-deadline-time-02
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 40
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 September 5, 2018. This Internet-Draft will expire on March 4, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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. Deadline-6LoRHE . . . . . . . . . . . . . . . . . . . . . . . 3
4. Deadline-6LoRHE . . . . . . . . . . . . . . . . . . . . . . . 4 4. Deadline-6LoRHE Format . . . . . . . . . . . . . . . . . . . 5
5. Deadline-6LoRHE Format . . . . . . . . . . . . . . . . . . . 5 5. Deadline-6LoRHE in Three Network Scenarios . . . . . . . . . 7
6. Deadline-6LoRHE in Three Network Scenarios . . . . . . . . . 6 5.1. Scenario 1: Endpoints in the same DODAG (N1) . . . . . . 7
6.1. Scenario 1: Endpoints in the same DODAG (N1) in non- 5.2. Scenario 2: Endpoints in Networks with Dissimilar L2
storing mode. . . . . . . . . . . . . . . . . . . . . . . 7
6.2. Scenario 2: Endpoints in Networks with Dissimilar L2
Technologies. . . . . . . . . . . . . . . . . . . . . . . 8 Technologies. . . . . . . . . . . . . . . . . . . . . . . 8
6.3. Scenario 3: Packet transmission across different DODAGs 5.3. Scenario 3: Packet transmission across different DODAGs
(N1 to N2). . . . . . . . . . . . . . . . . . . . . . . . 9 (N1 to N2). . . . . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Changes Since draft-ietf-6lo-deadline-time-00 . . . 12 Appendix A. Changes after draft-ietf-6lo-deadline-time-01 . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Appendix B. Changes between earlier versions . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
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.ietf-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.
skipping to change at page 3, line 13 skipping to change at page 3, line 9
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. Time synchronization techniques need not be mandated by this clocks. Time synchronization techniques need not be mandated by this
specificiation. There are a number of standards available for this specificiation. There are a number of standards available for this
purpose, including IEEE 1588 [ieee-1588], IEEE 802.1AS [dot1AS-2011], purpose, including IEEE 1588 [ieee-1588], IEEE 802.1AS [dot1AS-2011],
IEEE 802.15.4-2015 TSCH [dot15-tsch], and more. 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. BLE mesh time synchronization is also being recently
explored by the Bluetooth community. There are also cases under
consideration in Wi-SUN.
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
document, the terms "expiration time", "delivery deadline time", and document, the terms "expiration time", "delivery deadline time", and
"deadline" are used interchangeably with the same meaning. "deadline" are used interchangeably with the same meaning.
3. 6LoRHE Generic Format 3. Deadline-6LoRHE
Note: this section is not normative. It is included for convenience,
and may be deleted in a later revision of this document. 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.
o Type: Type of the 6LoRHE.
o length: variable
4. Deadline-6LoRHE
The Deadline-6LoRHE (see Figure 2) is an elective 6LoRH (i.e., a The Deadline-6LoRHE (see Figure 2) is an elective 6LoRH (i.e., a
6loRHE) that provides the Deadline time (DT) for an IPv6 datagram in 6LoRHE [RFC8138]) that provides the Deadline Time (DT) for an IPv6
a compressed form. Along with the deadline, the header can include datagram in a compressed form. Along with the deadline, the header
the packet Origination Time (OT), to enable a close estimate of the can include the packet Origination Time (OT), to enable a close
total delay incurred by a packet. The OT field is initialized by the estimate of the total delay incurred by a packet. The OT field is
sender using the current time at the outgoing network interface initialized by the sender using the current time at the outgoing
through which the packet is forwarded. network interface through which the packet is forwarded.
The deadline field contains the value of the delivery deadline time The deadline field contains the value of the delivery deadline time
for the packet. The packet SHOULD be delivered to the Receiver for the packet. The packet SHOULD be delivered to the Receiver
before this time. before this time.
packet_deadline_time = packet_origination_time + max_delay packet_deadline_time = packet_origination_time + max_delay
All nodes within the network SHOULD process the Deadline-6LoRHE in All nodes within the network SHOULD process the Deadline-6LoRHE in
order to support delay-sensitive deterministic applications. The order to support delay-sensitive deterministic applications. The
packet deadline time (DT) and origination time (OT) are represented packet deadline time (DT) and origination time (OT) are represented
in time units determined by a scaling parameter in the routing in time units determined by a scaling parameter in the routing
header. One of the time units is the Network ASN (Absolute Slot header. One of the time units is the Network ASN (Absolute Slot
Number) which can be used in case of a time slotted synchronized Number) which can be used in case of a time slotted synchronized
network, for instance a 6TiSCH network, where global time is network (for instance a 6TiSCH network, where global time is
maintained in the units of slot lengths of a certain resolution. maintained in the units of slot lengths of a certain resolution).
The delay experienced by packets in the network is a useful metric The delay experienced by packets in the network is a useful metric
for network diagnostics and performance monitoring. Whenever the for network diagnostics and performance monitoring. Whenever the
packets crosses into a network using a different reference clock, the packets crosses into a network using a different reference clock, the
Origination Time field is updated to represent the same Origination Origination Time field is updated to represent the same Origination
Time as expressed using the reference clock of the outgoing interface Time, but expressed using the reference clock of the interface into
into the new network. This is the same as the current time when the 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 this way, within the newly
network, the packet will appear to have originated 't' time units entered network, the packet will appear to have originated 't' time
earlier with respect to the reference clock of the new network. units 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)
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.
TxA : Time of arrival of packet in the network 'x'
TxD : Departure time of packet in 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 i.e. (D1 + D2)
OT = T1A-D OT = T2A-D OT = T3A-D
= 0 = 1000-100 = 5000 - 500
= 900 = 4500
Figure 1: Origination Time update example
There are multiple ways that a packet can be delayed, including There are multiple ways that a packet can be delayed, including
propagation delay and queuing delays. Sometimes there are processing propagation delay and queuing delays. Sometimes there are processing
delays as well. For the purpose of determining whether or not the delays as well. For the purpose of determining whether or not the
deadline has already passed, these various delays are not deadline has already passed, these various delays are not
distinguished. distinguished.
5. Deadline-6LoRHE Format 4. 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Deadline-6LoRHE format Figure 2: Deadline-6LoRHE format
skipping to change at page 6, line 17 skipping to change at page 6, line 49
Whenever a sender initiates the IP datagram, it includes the Whenever a sender initiates the IP datagram, it includes the
Deadline-6LoRHE along with other 6LoRH information. Deadline-6LoRHE along with other 6LoRH information.
Example: Consider a 6TiSCH network with time-slot length of 10ms. Example: Consider a 6TiSCH network with time-slot length of 10ms.
Let the current ASN when the packet is originated be 54400, and the Let the current ASN when the packet is originated be 54400, and the
maximum allowable delay (max_delay) for the packet delivery is 1 maximum allowable delay (max_delay) for the packet delivery is 1
second from the packet origination, then: second from the packet origination, then:
deadline_time = packet_origination_time + max_delay deadline_time = packet_origination_time + max_delay
= 55400 + 100 (in Network ASNs)
= 55500(Network ASNs)
= 55400 + 100 (in Network ASNs) Deadline-6LoRHE encoding with 'O' flag and 'D' flag set to 1:
= 55500(Network ASNs)
Deadline-6LoRHE encoding with 'O' flag set to 1 :
DTL = 001, OTL = 001, TU = '10', EXP = 2, DT = 0x22B, OT = 0x22A DTL = 001, OTL = 001, TU = '10', EXP = 2, DT = 0x22B, OT = 0x22A
6. Deadline-6LoRHE in Three Network Scenarios 5. Deadline-6LoRHE in Three Network Scenarios
In this section, Deadline-6LoRHE operation is described for 3 network In this section, Deadline-6LoRHE operation is described for 3 network
scenarios. Figure 3 depicts a constrained time-synchronized LLN that scenarios. Figure 3 depicts a constrained time-synchronized LLN that
has two subnets N1 and N2, connected through LBRs has two subnets N1 and N2, connected through LBRs
[I-D.ietf-6lo-backbone-router] with different reference clock times [I-D.ietf-6lo-backbone-router] with different reference clock times
T1 and T2. T1 and T2.
+-------------------+ +-------------------+
| Time Synchronized | | Time Synchronized |
| Network | | Network |
skipping to change at page 7, line 26 skipping to change at page 7, line 38
o | | router | | router o | | router | | router
+-----+ +-----+ +-----+ +-----+
o o o o o o
o o o o o o o o o o o o o o o o o o
o LLN o o LLN o o o LLN o o LLN o o
o o o o o o o o o o o o o o o o o o
6LoWPAN Network (subnet N1) 6LoWPAN Network (subnet N2) 6LoWPAN Network (subnet N1) 6LoWPAN Network (subnet N2)
Figure 3: Intra-network Timezone Scenario Figure 3: Intra-network Timezone Scenario
6.1. Scenario 1: Endpoints in the same DODAG (N1) in non-storing mode. 5.1. Scenario 1: Endpoints in the same DODAG (N1)
In scenario 1, shown in Figure 4, the Sender 'S' has an IP datagram In scenario 1, shown in Figure 4, the Sender 'S' has an IP datagram
to be routed to a Receiver 'R' within the same DODAG. For the route 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 segment from Sender to 6LBR, the Sender includes a Deadline-6LoRHE by
encoding the deadline time contained in the inband-OAM header encoding the deadline time contained in the packet. Subsequently,
extension. Then 6LR begins hop-by-hop operation to forward the each 6LR will perform hop-by-hop routing to forward the packet
packet towards the 6LBR. Once 6LBR receives the IP datagram, it towards the 6LBR. Once 6LBR receives the IP datagram, it sends the
generates a IPv6-in-IPv6 encapsulated packet when sending the packet packet downstream towards 'R'.
downwards to the Receiver [I-D.ietf-roll-useofrplinfo]. The 6LBR
copies the Deadline-6LoRHE from the Sender originated IP header to In case of a network running RPL non-storing mode, the 6LBR generates
the outer IP header. The Deadline-6LoRHE contained in the inner IP a IPv6-in-IPv6 encapsulated packet when sending the packet downwards
header is elided. 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
elided.
+-------+ +-------+
^ | 6LBR | | ^ | 6LBR | |
| | | | | | | |
| +-------+ | | +-------+ |
Default | (F)/ /| \ | IP-in-IP Upward | (F)/ /| \ | Downward
routing | / \ / | \ | Encapsulation routing | / \ / | \ | routing
| / \ (C) | (D) | | / \ (C) | (D) |
| (A) (B) / | / |\ | | (A) (B) / | / |\ |
| /|\ |\: (E) : R | | /|\ |\: (E) : R |
S : : : / \ V S : : : / \ v
Figure 4: End points within same DODAG(subnet N1) Figure 4: End points within same DODAG (subnet N1)
At the tunnel endpoint of IPv6-in-IPv6 encapsulation, the Deadline- At the tunnel endpoint of the IPv6-in-IPv6 encapsulation, the
6LoRHE is copied back from the outer header to inner header, and the Deadline-6LoRHE is copied back from the outer header to inner header,
inner IP packet is delivered to 'R'. and the inner IP packet is delivered to 'R'.
6.2. Scenario 2: Endpoints in Networks with Dissimilar L2 Technologies. 5.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, each 6LR will perform
by-hop operation to forward the packet towards the 6LBR. Once the IP hop-by-hop routing to forward the packet towards the 6LBR. Once the
datagram reaches 6LBR of DODAG1, it encodes the deadline time (and, Deadline Time information reaches the border router, the packet will
if available, the origination time) into the In-band OAM header be encoded as per the mechanism prescribed in the new time
extension, [I-D.ietf-ippm-ioam-data] and passes the datagram to the synchronized network. The specific data encapsulation mechanisms
IPv6 layer for further routing. followed in the new network are beyond the scope of this document.
+----------------+ +----------------+
| Time | | Time |
| synchronized |------R | Synchronized |------R
| Network | | Network |
+----------------+ +----------------+
| |
| |
----------+----------- ----------+-----------
^ | ^ |
| +---+---+ | +---+---+
| | 6LBR | | | 6LBR |
Default | | | Upward | | |
routing | +------++ routing | +------++
| (F)/ /| \ | (F)/ /| \
| / \ / | \ | / \ / | \
| / \ (C) | (D) | / \ (C) | (D)
: (A) (B) / | / |\ : (A) (B) / | / |\
/|\ |\: (E) : /|\ |\: (E) ::
S : : : / \ S : : : / \
: : : :
Figure 5: Packet transmission in Dissimilar L2 Technologies or Figure 5: Packet transmission in Dissimilar L2 Technologies or
Internet Internet
The IP datagram is routed to another time synchronized deterministic For instance, the IP datagram could be routed to another time
network following its own distinct reference clock, so the deadline synchronized deterministic network using the mechanism specified in
time in In-band OAM has to be updated according to the measurement of the In-band OAM [I-D.ietf-ippm-ioam-data], and then the deadline time
the current time in the new network. 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 5.3. Scenario 3: Packet transmission across different DODAGs (N1 to
N2). N2).
Consider the scenario depicted in Figure 6, in which the Sender 'S' Consider the scenario depicted in Figure 6, in which the Sender 'S'
(belonging to DODAG 1) has an IP datagram to be sent to Receiver 'R' (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 belonging to another DODAG (DODAG 2). The operation of this scenario
can be decomposed into combination of case 1 and case 2 scenarios. can be decomposed into combination of case 1 and case 2 scenarios.
For the route segment from 'S' to 6LBR, 'S' includes the Deadline- For the route segment from 'S' to 6LBR, 'S' includes the Deadline-
6LoRHE. Subsequently, each 6LR will perform hop-by-hop operation to 6LoRHE. Subsequently, each 6LR will perform hop-by-hop operation to
forward the packet towards the 6LBR. Once the IP datagram reaches forward the packet towards the 6LBR. Once the IP datagram reaches
6LBR1 of DODAG1, it applies the same rule as described in Case 2 6LBR1 of DODAG1, it applies the same rule as described in Case 2
while routing the packet to LBR2 over a (likely) time synchronized while routing the packet to 6LBR2 over a (likely) time synchronized
wired backhaul. The wired side of LBR2 can be mapped to receiver of wired backhaul. The wired side of 6LBR2 can be mapped to receiver of
Case 2. Once the packet reaches LBR2, it updates the Deadline-6LoRHE Case 2. Once the packet reaches 6LBR2, it updates the Deadline-
by adding the current time of DODAG2. Further, it generates an IPv6- 6LoRHE by adding or subtracting the difference of time of DODAG2 and
in-IPv6 encapsulated packet when sending the packet downstream to the sends the packet downstream towards 'R'.
Receiver [I-D.ietf-roll-useofrplinfo].
Time Synchronized Network Time Synchronized Network
-+---------------------------+- -+---------------------------+-
| | | |
DODAG1 +---+---+ +---+---+ DODAG2 DODAG1 +---+---+ +---+---+ DODAG2
Instance 1 | 6LBR1 | | 6LBR2 | Instance 2 | 6LBR1 | | 6LBR2 |
| | | | | | | | |
+-------+ +-------+ | +-------+ +-------+
(F)/ /| \ (F)/ /| \ | (F)/ /| \ (F)/ /| \
/ \ / | \ / \ / | \ | / \ / | \ / \ / | \
/ \ (C) | (D) / \ (C) | (D) |IP-in-IP / \ (C) | (D) / \ (C) | (D)
(A) (B) / | / |\ (A) (B) / | / |\ | Encapsulation (A) (B) / | / |\ (A) (B) / | / |\
/|\ |\: (E) : : /|\ |\: (E) : :| /|\ |\: (E) : : /|\ |\: (E) : :
S : : : / \ : : : : / \ | S : : : / \ : : : : / \
: : : R V : : : R
Network N1, time zone T1 NetWork N2, time zone T2 Network N1, time zone T1 Network N2, time zone T2
Figure 6: Packet transmission in different DODAGs(N1 to N2) Figure 6: Packet transmission in different DODAGs(N1 to N2)
Consider an example of a 6TiSCH network in which S in DODAG1 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 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 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 DODAG2 is assumed to be 10ms. Once the deadline time is encoded in
Deadline-6LoRHE, the packet is forwarded to LBR of DODAG1. Suppose Deadline-6LoRHE, the packet is forwarded to 6LBR of DODAG1. Suppose
the packet reaches LBR of DODAG1 at ASN 20050. the packet reaches 6LBR of DODAG1 at ASN 20030.
current_time = ASN at LBR * slot_length_value current_time = ASN at LBR * slot_length_value
remaining_time = deadline_time - current_time remaining_time = deadline_time - current_time
= ((packet_origination_time + max_delay) - current time) = ((packet_origination_time + max_delay) - current time)
= (20000 + 100) - 20050 = (20000 + 100) - 20030
= 50 (in Network ASNs) = 30 (in Network ASNs)
= 50 * 10^3 milliseconds. = 30 * 10^3 milliseconds.
The remaining time is encoded in In-Band OAM (see Case 2) and Once the Deadline Time information reaches the border router, the
forwarded to LBR2 over a different L2-interface, typically wired. packet will be encoded as per the mechanism prescribed in the new
Once the packet reaches LBR2, the deadline time in Deadline-6LoRHE is time synchronized network
adjusted by adding or subtracting the difference between the
reference clocks of the two networks, before forwarding the packet to
its connected 6TiSCH network.
7. IANA Considerations 6. IANA Considerations
This document defines a new 6LoWPAN Timestamp Header Type, and This document defines a new 6LoWPAN Timestamp Header Type, and
assigns a value (TBD) from the 6LoWPAN Dispatch Page1 number space. assigns a value (TBD) from the 6LoWPAN Dispatch Page1 number space.
6LoRH Type Value 6LoRH Type Value
+------------------+--------+ +------------------+--------+
| Deadline-6LoRHE | TBD | | Deadline-6LoRHE | TBD |
+------------------+--------+ +------------------+--------+
Figure 7: Deadline-6LoRHE type Figure 7: Deadline-6LoRHE type
8. Security Considerations 7. Security Considerations
The security considerations of [RFC4944], [RFC6282] and [RFC6553] The security considerations of [RFC4944], [RFC6282] and [RFC6553]
apply. Using a compressed format as opposed to the full in-line apply. Using a compressed format as opposed to the full in-line
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 8. 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, Seema Kumar, Avinash Mohan, Shalu Rajendran 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 9. References
10.1. Normative References 9.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,
"Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e", "Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e",
draft-ietf-6tisch-terminology-10 (work in progress), March draft-ietf-6tisch-terminology-10 (work in progress), March
2018. 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-
skipping to change at page 11, line 44 skipping to change at page 12, line 24
Information in Data-Plane Datagrams", RFC 6553, Information in Data-Plane Datagrams", RFC 6553,
DOI 10.17487/RFC6553, March 2012, DOI 10.17487/RFC6553, March 2012,
<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 [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>.
9.2. Informative References
[dot15-tsch] [dot15-tsch]
P802.11, "IEEE Standard for Low-Rate Wireless Networks, P802.11, "IEEE Standard for Low-Rate Wireless Networks,
Part 15.4, IEEE Std 802.15.4-2015", April 2016. Part 15.4, IEEE Std 802.15.4-2015", April 2016.
[dot1AS-2011] [dot1AS-2011]
IEEE 802.1AS Working Group, "IEEE Standard for Local and IEEE 802.1AS Working Group, "IEEE Standard for Local and
Metropolitan Area Networks - Timing and Synchronization Metropolitan Area Networks - Timing and Synchronization
for Time-Sensitive Applications in Bridged Local Area for Time-Sensitive Applications in Bridged Local Area
Networks", March 2011. 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-06 (work in progress), February 2018. backbone-router-06 (work in progress), February 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] [I-D.ietf-detnet-use-cases]
Grossman, E., "Deterministic Networking Use Cases", draft- Grossman, E., "Deterministic Networking Use Cases", draft-
ietf-detnet-use-cases-14 (work in progress), February ietf-detnet-use-cases-17 (work in progress), June 2018.
2018.
[I-D.ietf-ippm-ioam-data] [I-D.ietf-ippm-ioam-data]
Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., Brockners, F., Bhandari, S., Pignataro, C., Gredler, H.,
Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov,
P., Chang, R., and d. daniel.bernier@bell.ca, "Data Fields P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon,
for In-situ OAM", draft-ietf-ippm-ioam-data-01 (work in "Data Fields for In-situ OAM", draft-ietf-ippm-ioam-
progress), October 2017. data-03 (work in progress), June 2018.
[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-22 (work in progress), March 2018. useofrplinfo-23 (work in progress), May 2018.
[ieee-1588] [ieee-1588]
Precise Time and Time Interval Working Group, "IEEE Std Precise Time and Time Interval Working Group, "IEEE Std
1588-2008 Standard for a Precision Clock Synchronization 1588-2008 Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems", Protocol for Networked Measurement and Control Systems",
July 2008. July 2008.
Appendix A. Changes Since draft-ietf-6lo-deadline-time-00 Appendix A. Changes after draft-ietf-6lo-deadline-time-01
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 B. Changes between earlier versions
This section lists the changes between draft-ietf-6lo-deadline-time This section lists the changes between draft-ietf-6lo-deadline-time
revisions ...-00.txt and ...-01.txt. revisions ...-00.txt and ...-01.txt.
o Changed "SHOULD drop" to "MUST drop" a packet if the deadline is o Changed "SHOULD drop" to "MUST drop" a packet if the deadline is
passed (see Section 5). passed (see Section 4).
o Added explanatory text about how packet delays might arise. (see o Added explanatory text about how packet delays might arise. (see
Section 4). Section 3).
o Mentioned availability of time-synchronization protocols (see o Mentioned availability of time-synchronization protocols (see
Section 1). . Section 1). .
o Updated bibliographic citations. o Updated bibliographic citations.
o Alphabetized contributor names. o Alphabetized contributor names.
o Added this section. 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
Smarten Spaces
Bangalore 560103
India
Email: akshay.pm@smartenspaces.com
Satish Anamalamudi Satish Anamalamudi
Huaiyin Institute of Technology SRM University-AP
No.89 North Beijing Road, Qinghe District Amaravati Campus
Huaian Amaravati, Andhra Pradesh 522 502
China India
Email: satishnaidu80@gmail.com Email: satishnaidu80@gmail.com
S.V.R Anand S.V.R Anand
Indian Institute of Science Indian Institute of Science
Bangalore 560012 Bangalore 560012
India India
Email: anand@ece.iisc.ernet.in Email: anand@ece.iisc.ernet.in
 End of changes. 52 change blocks. 
155 lines changed or deleted 197 lines changed or added

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