Packet expiration time in 6LoWPAN Routing Header
draft-lijo-6lo-expiration-time-01
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 | 2017-03-13 (Latest revision 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-01
6lo Lijo Thomas
Internet-Draft C-DAC
Intended status: Standards Track P. Akshay
Expires: September 14, 2017 Indian Institute of Science
Satish Anamalamudi
Huaiyin Institute of Technology
S.V.R.Anand
Malati Hegde
Indian Institute of Science
C. Perkins
Futurewei
March 13, 2017
Packet expiration time in 6LoWPAN Routing Header
draft-lijo-6lo-expiration-time-01
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 September 14, 2017.
Lijo Thomas, et al. Expires September 14, 2017 [Page 1]
Internet-Draft 6lo Expiration Time March 2017
Copyright Notice
Copyright (c) 2017 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. 6LoRHE Generic Format . . . . . . . . . . . . . . . . . . . . 3
4. Deadline-6LoRH Description . . . . . . . . . . . . . . . . . 3
5. Deadline-6LoRH Format . . . . . . . . . . . . . . . . . . . . 4
6. Deadline-6LoRH in Three Network Scenarios . . . . . . . . . . 6
6.1. Scenario 1: Endpoints in the same DODAG (N1) in non-
storing mode. . . . . . . . . . . . . . . . . . . . . . . 7
6.2. Scenario 2: Endpoints in Networks with Dissimilar L2
Technologies. . . . . . . . . . . . . . . . . . . . . . . 8
6.3. Scenario 3: Packet transmission across different DODAGs
(N1 to N2). . . . . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
Low Power and Lossy Networks (LLNs) are likely to be employed for
implementing real time industrial applications that require end-to-
end delay guarantees [I-D.grossman-detnet-use-cases]. A
Deterministic Network typically requires that data packets generated
by the senders have to reach the receivers within strict time bounds.
Intermediate nodes use the expiration time information to make
appropriate packet forwarding and scheduling decisions to meet the
time bounds.
Lijo Thomas, et al. Expires September 14, 2017 [Page 2]
Internet-Draft 6lo Expiration Time March 2017
The draft [I-D.ietf-roll-routing-dispatch] specifies the 6LoWPAN
Routing Header (6LoRH), compression schemes for RPL routing (source
routing) operation [RFC6554], header compression of RPL Packet
Information [RFC6553], and IP-in-IP encapsulation. This document
specifies a new Deadline-6LoRH type to the 6LoWPAN Dispatch Page 1,
so that the expiration time of data packets can be included within
the 6LoWPAN routing header. In addition, this specification
specifies handling of the expiration time when packets traverse
through time-synchronized networks operating in different timezones
or 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. 6LoRHE Generic Format
The generic header format of the 6LoRHE is specified in
[I-D.ietf-roll-routing-dispatch]. Figure 1 describes 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
1. Length: In Figure 1, Length of the 6LoRHE expressed in bytes,
excluding the first 2 bytes. This enables a node to skip a
6LoRHE that it does not support and/or cannot parse, for instance
if the Type is not recognized.
2. Type: Type of the 6LoRHE.
3. Length: variable
4. Deadline-6LoRH Description
The Deadline-6LoRH (see Figure 2) is an elective 6LoRH that provides
a compressed form of expiration time for an IPv6 datagram. Along
with the expiration timer, the header can include the packet
Lijo Thomas, et al. Expires September 14, 2017 [Page 3]
Internet-Draft 6lo Expiration Time March 2017
origination time, to enable a close estimate of the total delay
incurred by a packet.
The packet expiration time field contains the value of the packet
expiration time. The packet SHOULD be delivered to the Receiver
before this time.
packet_expiration_time = packet_origination_time + max_delay
All nodes within the network SHOULD process the Deadline-6LoRH in
order to support delay-sensitive deterministic applications.In this
specification, the packet origination time is represented in
microseconds. In the case of a time slotted synchronized network
where a global time is maintained in the units of slot lengths of
certain resolution, the origination time is converted from the
current time into microseconds. A 6tisch minimal network
[I-D.vilajosana-6tisch-minimal] is such a network, where the slot
duration is typically 10msec, and the global time is given as ASN
(Absolute Slot Number).
The delay experienced by packets in the network is a useful metric
for network diagnostics and performance monitoring. To support this
feature, the specification provides an optional packet Origination
Time field as part of the header which is initialized by the sender
using the current clock time of the outgoing network interface
through which the packet is forwarded. Whenever the packets crosses
over to a network using a different reference clock, the Origination
Time field is updated to represent the same Origination Time but
using the reference clock of the outgoing interface into the new
network. This is the same as the current time when the packet is
transmitted into the new network, minus the delay already experienced
by the packet, say 't'. In effect, to the newly entered network, the
packet will appear to have originated 't' time units earlier with
respect to the reference clock of the new network.
Origination Time in new network = current_time_in_new_network -
delay_already_experienced_in_previous_network(s)
5. Deadline-6LoRH Format
Lijo Thomas, et al. Expires September 14, 2017 [Page 4]
Internet-Draft 6lo Expiration Time March 2017
0 1 2
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| ER|ETL| OR| OTL |Rsv| EXP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ET (variable length) | OT(variable length)(optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Deadline-6LoRH format
Length (5 bits): Length represents the total length of the Expiration
Time type measured in octets.
6LoRH Type: TBD
O flag (1bit): Indicates the presence of Origination Time field. '1'
means the Origination Time is present, and '0' means it is absent.
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 MAY ignore
the Expiration Time and forward it.
ER (2 bits) Indicates time units for packet expiration time field:
00 : Expiration time represented in microseconds
01 : Expiration time represented in milliseconds
10 : Expiration time represented in seconds
11 : User defined
ETL (3 bits): Length of Expiration Time field.
For example, if the expiration time is represented in microseconds
ETL = 000 means the expiration time in the 6LoRHE is 1 octet (8 bits)
long. Similarly, Length = 111 means the expiration time is 8 octets
(64 bits) long.
OR (2 bits) : Indicates time units for Packet Origination Time:
00 : Expiration time represented in microseconds
01 : Expiration time represented in milliseconds
10 : Expiration time represented in seconds
11 : User defined
OTL (3 bits) : Length of Origination Time field.
Rsv (2 bits) : Reserved
Lijo Thomas, et al. Expires September 14, 2017 [Page 5]
Internet-Draft 6lo Expiration Time March 2017
EXP (3 bits) : Multiplication factor expressed as exponent of 2.
The value of the ET field is multiplied by 2 to this power, to get
the actual expiration time in the units represented by ER. The
default value of EXP is 000, so that the ET field is unaffected.
ET Value (0..64-bit) : Expiration Time value
OT Value (0..64-bit) : Origination Time value
Whenever the Sender initiates the IP datagram, it includes the
Deadline-6LoRH along with other 6LoRH information.
Example: consider a 6TiSCH network with time-slot length of 10ms.
Let the current ASN when the packet is originated be 200, and the
maximum allowable delay (max_delay) for the packet delivery is 1
second from the packet origination, then:
expiration_time = packet_origination_time + max_delay
= 200*10ms + 1 second
= 3 * 10^6 microseconds
This expiration time requires 22 bits in the worst case, or 3 octets.
Better compression can be achieved by using a combination of OR and
EXP bit fields.
6. Deadline-6LoRH in Three Network Scenarios
In this section, Deadline-6LoRH operation is described for 3 network
scenarios. Figure 3 depicts a constrained time-synchronized LLN that
has two subnets N1 and N2, connected through LBRs
[I-D.ietf-6lo-backbone-router] with different reference clock times
T1 and T2.
Lijo Thomas, et al. Expires September 14, 2017 [Page 6]
Internet-Draft 6lo Expiration Time March 2017
+-------------------+
| 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 3: Intra-network Timezone Scenario
6.1. Scenario 1: Endpoints in the same DODAG (N1) in non-storing mode.
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
segment from Sender to 6LBR, the Sender includes a Deadline-6LoRH by
encoding the expiration time contained in the inband-OAM header
extension. Then 6LR begins hop-by-hop operation to forward the
packet towards the 6LBR. Once 6LBR receives the IP datagram, it
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-6LoRH from the Sender originated IP header to the
outer IP header. The Deadline-6LoRH contained in the inner IP header
is elided.
+-------+
^ | 6LBR | |
| | | |
| +-------+ |
Default | (F)/ /| \ | IP-in-IP
routing | / \ / | \ | Encapsulation
| / \ (C) | (D) |
| (A) (B) / | / |\ |
| /|\ |\: (E) : R |
S : : : / \ V
Figure 4: End points within same DODAG(subnet N1)
Lijo Thomas, et al. Expires September 14, 2017 [Page 7]
Internet-Draft 6lo Expiration Time March 2017
At the tunnel endpoint of IPv6-in-IPv6 encapsulation, the Deadline-
6LoRH is copied back from the outer header to inner header, and the
inner IP packet is delivered to 'R'.
6.2. Scenario 2: Endpoints in Networks with Dissimilar L2 Technologies.
In scenario 2, shown in Figure 5, 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-6LoRH. Subsequently, 6LR will perform hop-
by-hop operation to forward the packet towards the 6LBR. Once the IP
datagram reaches 6LBR of DODAG1, it encodes the expiration time (and,
if available, the origination time) into the In-band OAM header
extension, [I-D.brockners-inband-oam-data] and passes the datagram to
the IPv6 layer for further routing.
+----------------+
| Time |
| synchronized |------R
| Network |
+----------------+
|
|
----------+-----------
^ |
| +---+---+
| | 6LBR |
Default | | |
routing | +------++
| (F)/ /| \
| / \ / | \
| / \ (C) | (D)
: (A) (B) / | / |\
/|\ |\: (E) :
S : : : / \
: :
Figure 5: Packet transmission in Dissimilar L2 Technologies or
Internet
The IP datagram is routed to another time synchronized deterministic
network following its own distinct reference clock, so the expiration
time in In-band OAM has to be updated according to the measurement of
the current time in the new network.
Lijo Thomas, et al. Expires September 14, 2017 [Page 8]
Internet-Draft 6lo Expiration Time March 2017
6.3. Scenario 3: Packet transmission across different DODAGs (N1 to
N2).
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 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 6LBR, 'S' includes the Deadline-
6LoRH. Subsequently, each 6LR will perform hop-by-hop operation to
forward the packet towards the 6LBR. Once the IP datagram reaches
6LBR1 of DODAG1, it applies the same rule as described in Case 2
while routing the packet to LBR2 over a (likely) time synchronized
wired backhaul. The wired side of LBR2 can be mapped to receiver of
Case 2. Once the packet reaches LBR2, it updates the Deadline-6LoRH
by adding the current time of DODAG2. Further, it generates an IPv6-
in-IPv6 encapsulated packet when sending the packet downstream to the
Receiver [I-D.ietf-roll-useofrplinfo].
Time Synchronized Network
-+---------------------------+-
| |
DODAG1 +---+---+ +---+---+ DODAG2
Instance 1 | 6LBR1 | | 6LBR2 | 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)
Consider an example of a 6TiSCH network in which 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
Deadline-6LoRH, the packet is forwarded to LBR of DODAG1. Suppose
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_delay) - current time)
Lijo Thomas, et al. Expires September 14, 2017 [Page 9]
Internet-Draft 6lo Expiration Time March 2017
= (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 Deadline-6LoRH
is 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
This document defines a new 6LoWPAN Timestamp Header Type, and
assigns a value (TBD) from the 6LoWPAN Dispatch Page1 number space.
6LoRH Type Value
+------------------+--------+
| Deadline-6LoRH | TBD |
+------------------+--------+
Figure 7: Deadline-6LoRH type
8. Security Considerations
The security considerations of [RFC4944], [RFC6282] and [RFC6553]
apply. Using a compressed format as opposed to the full in-line
format is logically equivalent and does not create an opening for a
new threat when compared to [RFC6550], [RFC6553] and [RFC6554].
9. Acknowledgements
The authors thank Pascal Thubert for suggesting the idea and
encouraging the work. Thanks to Shwetha Bhandari's suggestions which
were instrumental in extending the timing information to
heterogeneous networks. The authors acknowledge the 6TiSCH WG
members for their inputs on the mailing list. Special thanks to
Jerry Daniel,Shalu Rajendran, Seema Kumar, Avinash Mohan and Anita
Varghese for their support and valuable feedback.
10. References
10.1. Normative References
[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.
Lijo Thomas, et al. Expires September 14, 2017 [Page 10]
Internet-Draft 6lo Expiration Time March 2017
[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>.
10.2. Informative References
[I-D.brockners-inband-oam-data]
Brockners, F., Bhandari, S., Pignataro, C., Gredler, H.,
Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov,
P., and R. <>, "Data Formats for In-situ OAM", draft-
brockners-inband-oam-data-02 (work in progress), October
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.
Lijo Thomas, et al. Expires September 14, 2017 [Page 11]
Internet-Draft 6lo Expiration Time March 2017
[I-D.ietf-6lo-backbone-router]
Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo-
backbone-router-03 (work in progress), January 2017.
[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-11 (work in progress), March 2017.
[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
P.M. Akshay
Indian Institute of Science
Bangalore 560012
India
Email: akshaypm@ece.iisc.ernet.in
Satish Anamalamudi
Huaiyin Institute of Technology
No.89 North Beijing Road, Qinghe District
Huaian
China
Email: satishnaidu80@gmail.com
S.V.R Anand
Indian Institute of Science
Bangalore 560012
India
Email: anand@ece.iisc.ernet.in
Lijo Thomas, et al. Expires September 14, 2017 [Page 12]
Internet-Draft 6lo Expiration Time March 2017
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 September 14, 2017 [Page 13]