]> C-DAC

Centre for Development of Advanced Computing (C-DAC), Vellayambalam Trivandrum 695033 India lijo@cdac.in

SRM University-AP

Amaravati Campus Amaravati, Andhra Pradesh 522 502 India satishnaidu80@gmail.com

Indian Institute of Science

Bangalore 560012 India anand@ece.iisc.ernet.in

Indian Institute of Science

Bangalore 560012 India malati@ece.iisc.ernet.in

Futurewei

2330 Central Expressway Santa Clara 95050 Unites States charliep@computer.org

Internet 6lo Routing header, Timestamp 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 machine to machine (M2M) applications that operate within time-synchronized networks that agree on the meaning of the time representations used for the deadline time values.

Low Power and Lossy Networks (LLNs) are likely to be deployed for real time industrial applications requiring end-to-end delay guarantees . 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. specifies the 6LoWPAN Routing Header (6LoRH), compression schemes for RPL routing (source routing) operation , header compression of RPL Packet Information , 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 802.1AS , IEEE 802.15.4-2015 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 in industrial IoT . BLE mesh time synchronization is being explored by the Bluetooth community. There are also cases under consideration in Wi-SUN , .

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 . This document uses the terminology defined in and .

Note: this section is not normative and is included for convenience. The generic header format of the 6LoRHE is specified in . illustrates the 6LoRHE generic format.

]]>

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. Type (variable length): Type of the 6LoRHE (see )

The Deadline-6LoRHE (see ) is an elective 6LoRH (i.e., a 6LoRHE ) 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 -- in other words, the time by which the application expects the packet to be delivered to the Receiver. packet_deadline_time = packet_origination_time + max_delay In order to support delay-sensitive deterministic applications, all nodes within the network should process the Deadline-6LoRHE. The packet deadline time (DT) and origination time (OTD) are represented in time units determined by a scaling parameter in the routing header. The Network ASN (Absolute Slot Number) can be used as a time unit in 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 'current_dly'. In this way, within the newly entered network, the packet will appear to have originated 'current_dly' time units earlier with respect to the reference clock of the new network. new_network_origin_time = time_now_in_new_network - current_dly 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 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. uses the following abbreviations: TxA : Time of arrival of packet in the network 'x' TxD : Departure time of packet from the network 'x' dlyx : Delay experienced by the packet in the previous network(s) TZx : The time zone of network 'x'

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

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.

Length (5 bits): Length represents the total length of the Deadline-6LoRHE type measured in octets. 6LoRH Type: TBD (see ) D flag (1 bit): The 'D' flag, set by the Sender, qualifies the action to be taken when a 6LR detects that the deadline time has elapsed. If 'D' bit is 1, then the 6LR MUST drop the packet if the deadline time is elapsed. If 'D' bit is 0, the packet MAY be forwarded on an exception basis, if the forwarding node is NOT in a situation of constrained resource, and if there are reasons to suspect that downstream nodes might find it useful (delay measurements, interpolations, etc.). TU (2 bits) : Indicates the time units for DT and OTD fields. The encodings for the DT and OTD fields use the same time units and precision. 00 : Time represented in seconds and fractional seconds 01 : Reserved 10 : Network ASN 11 : Reserved DTL (4 bits): Length of DT field as an unsigned 4-bit integer, encoding the length of the field in hex digits, minus one. OTL (3 bits) : Length of OTD field as an unsigned 3-bit integer, encoding the length of the field in hex digits. If OTL == 0, the OTD field is not present. The value of OTL MUST NOT exceed the value of DTL plus one. For example, DTL = 0b0000 means the deadline time in the 6LoRHE is 1 hex digit (4 bits) long. OTL = 0b111 means the origination time is 7 hex digits (28 bits) long. Binary Pt (6 bits) : If zero, the number of bits of the integer part the DT is equal to the number of bits of the fractional part of the DT. if nonzero, the Binary Pt is a signed integer determining the position of the binary point within the value for the DT. If BinaryPt value is positive, then the number of bits for the integer part of the DT is increased by the value of BinaryPt, and the number of bits for the fractional part of the DT is correspondingly reduced. This increases the range of DT. If BinaryPt value is negative, then the number of bits for the integer part of the DT is decreased by the value of BinaryPt, and the number of bits for the fractional part of the DT is correspondingly increased. This increases the precision of the fractional seconds part of DT. DT Value (8..64-bit) : An unsigned integer of DTL+1 hex digits giving the Deadline Time value OTD Value (8..64-bit) : An unsigned integer of OTL hex digits giving the Origination Time as a negative offset from the DT value 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 . For the chosen time unit, a compressed time representation is available as follows. First, the application on the originating node has to determine how many time bits are needed to represent the difference between the time at which the packet is launched and the deadline time, including the representation of fractional time units. That number of bits (say, N_bits) determines DTL (the length of the Deadline Time (DT)) as follows: DTL = (N_bits mod 4) The number of bits determined by DTL allows counting any number of fractional time units in the range of interest determined by DT and the origination time OT. Denote this number of fractional time units to be Epoch_Range(DTL) (i.e., Epoch_Range is a function of DTL). Epoch_Range(DTL) = (2^(4*(DTL+1)) Each point of time between OT and DT is represented by a time unit and a fractional time unit; in this section, this combined representation is called a rational time unit (RTU). 1 RTU measures the smallest fractional time that can be represented between two points of time in the epoch (i.e., within the range of interest). DT - OT cannot exceed 2^(4*(DTL+1)) == 16^(DTL+1). A low value of DTL leads to a small Epoch_Range; if DTL = 0, there will only be 16 RTUs within the Epoch_Range (DTL) = 16^1 (for any time unit TU). The values that can be represented in the current epoch are in the range [0, (Epoch_Range(DTL) - 1)]. To minimize the required DTL, wraparound is allowed but works naturally with the arithmetic modulo Epoch_Range. By default, DTL determines t_0 in the chosen RTUs as follows: t_0 = [current_time - (current_time mod Epoch_Range (DTL))]. Naturally, t_0 occurs at time 0 (or time 0.0000...) in the current epoch. The last possible origination time representable in the current epoch (counted in RTUs) is t_last = (t0 + (2^(4*(DTL+1))-1)). In the RTUs chosen, the current epoch resides at the underlying time interval [t_0, t_last]. If DT - OT is greater than t_last - OT, then wraparound within the Epoch_Range occurs naturally. In all cases, OT is represented by the value (OT mod Epoch_Range) and DT is represented by the value (DT mod Epoch_Range). All arithmetic is to be performed modulo (Epoch_Range(DTL)), yielding only positive values for DT - OT. Example: Consider a 6TiSCH network with time-slot length of 10ms. Let the time units be ASNs (TU == (binary)0b10). Let the current ASN when the packet is originated be 54400, and the maximum allowable delay (max_delay) for the packet delivery be 1 second from the packet origination, then: deadline_time = packet_origination_time + max_delay = 0xD480 + 0x64 (Network ASNs) = 0xD4E4 (Network ASNs) Then, the Deadline-6LoRHE encoding with nonzero OTL is: DTL = 3, OTL = 2, TU = 0b10, BinaryPt = 8, DT = 0xD4E4, OTD = 0x64

In this section, Deadline-6LoRHE operation is described for 3 network scenarios. depicts a constrained time-synchronized LLN that has two subnets N1 and N2, connected through LBRs with different reference clock times T1 and T2.

In scenario 1, shown in , 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 . 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.

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

In scenario 2, shown in , 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 , and then the deadline time would be updated according to the measurement of the current time in the new network.

Consider the scenario depicted in , 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'.

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. current_time = ASN at LBR * slot_length_value remaining_time = deadline_time - current_time = ((packet_origination_time + max_delay) - current time) = (20000 + 100) - 20030 = 30 (in Network ASNs) = 30 * 10^3 milliseconds. 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.

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.

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 . 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 (or fractional time units) in the past. This then requires that the time synchronization between sender and receiver has to be tighter than 16 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 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.75 seconds by quarter-seconds. If DTL = 3 and the DT bits are again split evenly, then we can count up to 256 seconds (in steps of 1/256 of a second). In all cases, t_0 is defined as specified in t_0 = [current_time - (current_time mod (2^(4*(DTL+1))))] regardless of the choice of TU. 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 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.

The security considerations of , and 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 , and . The protocol elements specified in this document are designed to work in controlled operational environments (e.g., industrial process control and automation). In order to avoid misuse of the deadline information that could potentially result in a Denial of Service (DoS) attack, proper functioning of this deadline time mechanism requires the provisioning and management of network resources for supporting traffic flows with deadlines, performance monitoring, and admission control policy enforcement. The network provisioning can be done either centrally or in a distributed fashion. For example, tracks in a 6tisch network could be established by a centralized PCE, as described in the 6tisch architecture . The Security Considerations of Detnet architecture mostly apply to this document as well, as follows. To secure the request and control of resources allocated for tracks, authentication and authorization can be used for each device, and network controller devices. In the case of distributed control protocols, security is expected to be provided by the security properties of the protocols in use. When deadline bearing flows are identified on a per-flow basis, which may provide attackers with additional information about the data flows, when compared to networks that do not include per-flow identification. The security implications of disclosing that additional information deserve consideration when implementing this deadline specification. Because of the requirement of precise time synchronization, the accuracy, availability, and integrity of time synchronization is of critical importance. Extensive discussion of this topic can be found in .

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, Dan Frost (Routing Directorate) Charlie Kaufman (Security Directorate) Seema Kumar, Tal Mizrahi Avinash Mohan, Shalu Rajendran, Anita Varghese, and Dale Worley (Gen-ART review) for their support and valuable feedback.

"IEEE 802 Wireless"

"IEEE Standards"

"IEEE Standards"

Wi-SUN Alliance

This section lists the changes between draft-ietf-6lo-deadline-time revisions ...-04.txt and ...-05.txt. Included additional relevant material in Security Considerations regarding expected deployment scenarios and the effect of disclosing additional information during the travel of a packet. Reworked the specification for using time ranges shorter than the maximum allowed by the choice of TU, so that fewer bits are needed to represent DT and OT. Revised the figures and examples to use new parameters Reordered the field definitions for the Deadline-6LoRHE. Responded to numerous reviewer comments to improve terminology and editorial consistency.

This section lists the changes between draft-ietf-6lo-deadline-time revisions ...-03.txt and ...-04.txt. Replaced OT (Origination Time) field by OTD (Origination Time Delta), allowing a more compressed representation that needs less processing during transitions between networks. Changed representation for DTL, OTL, DT, OTD. Eliminated EXP in favor of BinaryPt. Revised the figures and examples to use new parameters Added new section on Synchronization Aspects to supply pertinent information about how nodes agree on the meaning of t=0. Responded to numerous reviewer comments to improve editorial consistency and improve terminology.

This section lists the changes between draft-ietf-6lo-deadline-time revisions ...-02.txt and ...-03.txt. Added non-normative 6LoRHE description, citing RFC 8138. Specified that the Origination Time (OT) is the time that packet is enqueued for transmission. Mentioned more sources of packet delay. Clarified reasons that packet MAY be forwarded if 'D' bit is 0. Clarified that DT, OT, DTL and OTL are unsigned integers. Updated bibliographic citations, including BLEmesh and Wi-SUN.

This section lists the changes between draft-ietf-6lo-deadline-time revisions ...-01.txt and ...-02.txt. Replaced 6LoRHE description by reference to RFC 8138. Added figure to illustrate change to Origination Time when a packet crosses timezone boundaries. Clarified that use of 6tisch networks is descriptive, not normative. Clarified that In-Band OAM is used as an example and is not normative. Updated bibliographic citations. Alphabetized contributor names.

This section lists the changes between draft-ietf-6lo-deadline-time revisions ...-00.txt and ...-01.txt. Changed "SHOULD drop" to "MUST drop" a packet if the deadline is passed (see ). Added explanatory text about how packet delays might arise. (see ). Mentioned availability of time-synchronization protocols (see ). Updated bibliographic citations. Alphabetized contributor names. Added this section.