Packet Delivery Deadline Time in the Routing Header for IPv6 over Low‑Power Wireless Personal Area Networks (6LoWPANs)Centre for Development of Advanced ComputingVellayambalamTrivandrum695033Indialijo@cdac.inSRM University-APAmaravati CampusAmaravati, Andhra Pradesh522 502Indiasatishnaidu80@gmail.comIndian Institute of ScienceBangalore560012Indiaanandsvr@iisc.ac.inIndian Institute of ScienceBangalore560012Indiamalati@iisc.ac.inLupin Lodge20600 Aldercroft Heights Rd.Los GatosCA95033United States of Americacharliep@computer.org
Internet
6loRouting headerTimestamp
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 machine-to-machine (M2M)
applications running on Internet-enabled devices that operate within
time-synchronized networks. This document also specifies a
representation for the deadline time values in such networks.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2021 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
() 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
. Introduction
. Terminology
. 6LoRHE Generic Format
. Deadline-6LoRHE
. Deadline-6LoRHE Format
. Deadline-6LoRHE in Three Network Scenarios
. Scenario 1: Endpoints in the Same DODAG (N1)
. Scenario 2: Endpoints in Networks with Dissimilar L2 Technologies
. Scenario 3: Packet Transmission across Different DODAGs (N1 to N2)
. IANA Considerations
. Synchronization Aspects
. Security Considerations
. References
. Normative References
. Informative References
. Modular Arithmetic Considerations
Acknowledgments
Authors' Addresses
Introduction
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), Deadline-6LoRHE, so that the deadline time (i.e., the time of latest
acceptable delivery) of data
packets can be included within the 6LoRHE.
specifies the 6LoWPAN Routing Header (6LoRH),
compression schemes for RPL (Routing Protocol for Low-Power and Lossy Networks) source routing , header compression of RPL packet
information , and IP-in-IP encapsulation.
This document also specifies the handling of the deadline
time when packets traverse time-synchronized networks
operating in different time zones 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 Time-Slotted Channel Hopping (TSCH) , and more.
The Deadline-6LoRHE can be used in any time-synchronized 6LoWPAN network.
A 6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4) 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 6LoWPAN
over a Bluetooth Low Energy (BLE) mesh network in
industrial IoT (Internet of Things) . BLE mesh time
synchronization is being explored by the Bluetooth
community. There are also cases under consideration in Wi-SUN
.
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 BCP 14 when, and only when, they appear in all capitals, as
shown here.
This document uses the terminology defined in
and
.
6LoRHE Generic Format
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 or supported.
Type (variable length):
Type of the 6LoRHE (see ).
Deadline-6LoRHE
The Deadline-6LoRHE (see ) is
a 6LoRHE that provides
the Deadline Time (DT) for an IPv6 datagram in a compressed form.
Along with the DT, the header can include the
Origination Time Delta (OTD) packet, which contains the time when the packet was
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 DT 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 DT and OTD packets 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 DT field is updated
to represent the same deadline 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 (TZ). 'x' can be 1, 2, or 3. Suppose that the deadline time
as measured in TZ1 is 1050, and the origination time is 50.
Suppose that the difference between TZ2 and TZ1 is 900, and the
difference between TZ2 and TZ3 is 3600. In the figure, OT
is the origination time as measured in the current time zone, 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'
There are multiple ways that a packet can be delayed, including
queuing delay, Media Access Control (MAC) layer contention delay, serialization delay, and
propagation delay. 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.
Deadline-6LoRHE Format
Length (5 bits):
Length represents the total length of the Deadline-6LoRHE Type measured in octets.
6LoRH Type:
7 (See .)
D flag (1 bit):
The 'D' flag, set by the sender, qualifies the action to be taken when a
6LoWPAN Router (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 the DT field as an unsigned 4-bit integer, encoding the length of
the field in hex digits, minus one.
OTL (3 bits):
Length of the 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 DT field in the
6LoRHE is 1 hex digit (4 bits) long. OTL = 0b111 means the
OTD field is 7 hex digits (28 bits) long.
BinaryPt (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 BinaryPt is a (2's complement) signed
integer determining the position of the binary point within the value
for the DT. This allows BinaryPt to be within the range [-32,31].
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 (4..64 bits):
An unsigned integer of DTL+1 hex digits giving the DT value.
OTD Value (4..28 bits):
If present, 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
determines
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 as follows:
DTL = ((N_bits - 1) / 4)
The number of bits determined by DTL allows the counting of any number of
fractional time units in the range of interest determined by DT and the
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) = 24*(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 24*(DTL+1) == 16DTL+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 (i.e., Epoch_Range(DTL) = 161) for any TU. The
values that can be represented in the current epoch are in the range
[0, (Epoch_Range(DTL) - 1)].
Assuming wraparound does not occur, 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.
In order to allow fine-grained control over the setting of the
deadline time, the fields for DT and OTD use fractional seconds. This is done by specifying
a binary point, which allocates some of the bits for fractional times.
Thus, all such fractions are restricted to be negative powers of 2.
Each point of time between OT and DT is then represented by a time
unit (either seconds or ASNs) and a fractional time unit.
Let OT_abs, DT_abs, and CT_abs denote the true (absolute) values (on the
synchronized timelines) for OT, DT, and
current time. Let N be the number of bits to be used to represent
the integer parts of OT_abs, DT_abs, and CT_abs:
N = {4*(DTL+1)/2} + BinaryPt
The originating node has to pick a segment size (2^N) so that
DT_abs - OT_abs < 2^N, and so that intermediate network nodes
can detect whether or not CT_abs > DT_abs.
Given a value for N, the value for DT is represented in the
deadline-time format by DT = (DT_abs mod 2^N). DT is typically
represented as a positive value (even though negative modular
values make sense). Also, let OT = OT_abs mod 2^N and
CT = CT_abs mod 2^N, where both OT and CT are also considered as
non-negative values.
When the packet is launched by the originating node,
CT_abs == OT_abs and CT == OT. Given a particular value for N,
then in order for downstream nodes to detect whether or not the
deadline has expired (i.e., whether DT_abs > CT_abs), the following is
required:
Assumption 1: DT_abs - OT_abs < 2^N.
Otherwise the ambiguity
inherent in the modulus arithmetic yielding OT and DT will cause
failure: one cannot measure time differences greater than 2^N using
numbers in a time segment of length less than 2^N.
Under Assumption 1, downstream nodes must effectively check
whether or not their current time is later than the DT -- but
the value of the DT has to be inferred from the
value of DT in the 6LoRHE, which is a number less than 2^N. This
inference cannot be expected to reliably succeed unless Assumption 1
is valid, which means that the originating node has to be careful to pick proper
values for DTL and for BinaryPt.
Since OT is not necessarily provided in the 6loRHE, there may be a
danger of ambiguity. Surely, when DT = CT, the deadline time
is expiring and the packet should be dropped. However, what if an
intermediate node measures that CT = DT+1? Was the packet
launched a short time before arrival at the intermediate node,
or has the current time wrapped around so that
CT_abs - OT_abs > 2^N?
In order to solve this problem, a safety margin has to be provided,
in addition to requiring that DT_abs - OT_abs < 2^N. The value
of this safety margin is proportional to 2^N and is determined by
a new parameter, called the "SAFETY_FACTOR". Then, for safety the
originating node MUST further ensure that
(DT_abs - OT_abs) < 2^N*(1-SAFETY_FACTOR).
Each intermediate node that receives the packet with the
Deadline-6LoRHE must determine whether
((CT - DT) mod 2^N) > SAFETY_FACTOR*2^N.
If this test condition is not satisfied, the deadline time has expired.
See for more explanation about the test
condition.
All nodes that receive a packet with a Deadline-6LoRHE included
MUST use the same value for the SAFETY_FACTOR. The SAFETY_FACTOR
is to be chosen so that a packet with the Deadline-6LoRHE included
will be tested against the current time at least once during every
subinterval of length SAFETY_FACTOR*2^N. In this way, it can be
guaranteed that the packet will be tested often enough to make
sure it can be dropped whenever CT_abs > DT_abs. The value of
SAFETY_FACTOR is specified in this document to be 20%.
Example: Consider a 6TiSCH network with time-slot length of 10 ms.
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 = 0x64Deadline-6LoRHE in Three Network Scenarios
In this section, the Deadline-6LoRHE operation is described for three
network scenarios. depicts a
constrained time-synchronized LLN that has two subnets, N1 and N2,
connected through 6LoWPAN Border Routers (6LBRs)
with different reference clock times, T1 and T2.
Scenario 1: Endpoints in the Same DODAG (N1)
In Scenario 1, shown in , the Sender 'S' has an
IP datagram to be routed to a Receiver 'R' within
the same Destination-Oriented Directed Acyclic Graph (DODAG).
For the route segment from the sender to the 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 the 6LBR receives
the IP datagram, it sends the packet downstream towards 'R'.
In the case of a network running in RPL non-storing mode, the 6LBR generates
an 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'.
Scenario 2: Endpoints in Networks with Dissimilar L2 Technologies
In Scenario 2, shown in ,
the Sender 'S' (belonging to DODAG 1) has an 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 6LBR, the packet will be encoded according to the
mechanism prescribed in the other time-synchronized network depicted
as "Time-Synchronized Network" in .
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
In-situ Operations, Administration, and Maintenance (IOAM)
, and then
the deadline time would be updated according to the measurement
of the current time in the new network.
Scenario 3: Packet Transmission across Different DODAGs (N1 to N2)
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 a combination of
Scenarios 1 and 2. For the route segment from 'S' to 6LBR1,
'S' includes the Deadline-6LoRHE. Subsequently, each 6LR will
perform hop-by-hop operations to forward the packet towards 6LBR1.
Once the IP datagram reaches 6LBR1 of DODAG1, 6LBR1 applies the same rule
as described in Scenario 2 while routing the packet to 6LBR2 over a (likely)
time-synchronized wired backhaul. The wired side of 6LBR2 can be mapped
to the receiver of Scenario 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 10 ms. Once the deadline time is encoded in
Deadline-6LoRHE, the packet is forwarded to 6LBR1 of DODAG1.
Suppose the packet reaches 6LBR1 of DODAG1 at ASN 20030.
current_time = ASN at 6LBR * slot_length_value remaining_time = deadline_time - current_time = ((packet_origination_time + max_delay) - current time) = (20000 + 100) - 20030 = 30 (in Network ASNs) = 30 * 103 milliseconds
Once the deadline time information reaches 6LBR2,
the packet will be encoded according to the mechanism prescribed
in the other time-synchronized network.
IANA Considerations
This document defines a new Elective 6LoWPAN Routing Header Type,
and IANA has assigned the value 7 from the 6LoWPAN
Dispatch Page 1 number space for this purpose.
Entry in the "Elective 6LoWPAN Routing Header Type" Registry
Value
Description
Reference
7
Deadline-6LoRHE
RFC 9034
Synchronization Aspects
The document supports time representation of the deadline and
origination times carried in the packets traversing 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 needs 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 the integer number of seconds, determines
the meaning of t0, 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, t0 is defined as specified in .
t0 = [current_time - (current_time mod (24*(DTL+1)))]
regardless of the choice of TU.
For TU = 0b00, the time units are seconds. With DTL == 15,
and BinaryPt == 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 232 seconds, which is
roughly 136 years.
For TU = 0b10, the time units are ASNs. The start time is relative,
and updated by a mechanism that is out of scope for this document.
With 10 ms slots, DTL = 15, and BinaryPt == 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.
Security Considerations
The security considerations of
,
, and
apply.
Using a compressed format as opposed to the full inline 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 Path Computation Element (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.
The identification of deadline-bearing flows on a per-flow basis
may provide attackers with additional information about the data
flows 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 .
ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Transmission of IPv6 Packets over IEEE 802.15.4 NetworksThis document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks. Additional specifications include a simple header compression scheme using shared context and provisions for packet delivery in IEEE 802.15.4 meshes. [STANDARDS-TRACK]Network Time Protocol Version 4: Protocol and Algorithms SpecificationThe Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified protocol header to accommodate the Internet Protocol version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism. [STANDARDS-TRACK]Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based NetworksThis document updates RFC 4944, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks". This document specifies an IPv6 header compression format for IPv6 packet delivery in Low Power Wireless Personal Area Networks (6LoWPANs). The compression format relies on shared context to allow compression of arbitrary prefixes. How the information is maintained in that shared context is out of scope. This document specifies compression of multicast addresses and a framework for compressing next headers. UDP header compression is specified within this framework. [STANDARDS-TRACK]RPL: IPv6 Routing Protocol for Low-Power and Lossy NetworksLow-Power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained. LLN routers typically operate with constraints on processing power, memory, and energy (battery power). Their interconnects are characterized by high loss rates, low data rates, and instability. LLNs are comprised of anything from a few dozen to thousands of routers. Supported traffic flows include point-to-point (between devices inside the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point). This document specifies the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point as well as point-to-multipoint traffic from the central control point to the devices inside the LLN are supported. Support for point-to-point traffic is also available. [STANDARDS-TRACK]The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane DatagramsThe Routing Protocol for Low-Power and Lossy Networks (RPL) includes routing information in data-plane datagrams to quickly identify inconsistencies in the routing topology. This document describes the RPL Option for use among RPL routers to include such routing information. [STANDARDS-TRACK]An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)In Low-Power and Lossy Networks (LLNs), memory constraints on routers may limit them to maintaining, at most, a few routes. In some configurations, it is necessary to use these memory-constrained routers to deliver datagrams to nodes within the LLN. The Routing Protocol for Low-Power and Lossy Networks (RPL) can be used in some deployments to store most, if not all, routes on one (e.g., the Directed Acyclic Graph (DAG) root) or a few routers and forward the IPv6 datagram using a source routing technique to avoid large routing tables on memory-constrained routers. This document specifies a new IPv6 Routing header type for delivering datagrams within a RPL routing domain. [STANDARDS-TRACK]Security Requirements of Time Protocols in Packet Switched NetworksAs time and frequency distribution protocols are becoming increasingly common and widely deployed, concern about their exposure to various security threats is increasing. This document defines a set of security requirements for time protocols, focusing on the Precision Time Protocol (PTP) and the Network Time Protocol (NTP). This document also discusses the security impacts of time protocol practices, the performance implications of external security practices on time protocols, and the dependencies between other security services and time synchronization.Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem StatementThis document describes the environment, problem statement, and goals for using the Time-Slotted Channel Hopping (TSCH) Medium Access Control (MAC) protocol of IEEE 802.14.4e in the context of Low-Power and Lossy Networks (LLNs). The set of goals enumerated in this document form an initial set only.IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing HeaderThis specification introduces a new IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) dispatch type for use in 6LoWPAN route-over topologies, which initially covers the needs of Routing Protocol for Low-Power and Lossy Networks (RPL) data packet compression (RFC 6550). Using this dispatch type, this specification defines a method to compress the RPL Option (RFC 6553) information and Routing Header type 3 (RFC 6554), an efficient IP-in-IP technique, and is extensible for more applications.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Deterministic Networking ArchitectureThis document provides the overall architecture for Deterministic Networking (DetNet), which provides a capability to carry specified unicast or multicast data flows for real-time applications with extremely low data loss rates and bounded latency within a network domain. Techniques used include 1) reserving data-plane resources for individual (or aggregated) DetNet flows in some or all of the intermediate nodes along the path of the flow, 2) providing explicit routes for DetNet flows that do not immediately change with the network topology, and 3) distributing data from DetNet flow packets over time and/or space to ensure delivery of each packet's data in spite of the loss of a path. DetNet operates at the IP layer and delivers service over lower-layer technologies such as MPLS and Time- Sensitive Networking (TSN) as defined by IEEE 802.1.An Architecture for IPv6 over the Time-Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)This document describes a network architecture that provides low-latency, low-jitter, and high-reliability packet delivery. It combines a high-speed powered backbone and subnetworks using IEEE 802.15.4 time-slotted channel hopping (TSCH) to meet the requirements of low-power wireless deterministic applications.Informative ReferencesIPv6 Mesh over BLUETOOTH(R) Low Energy using IPSPUniversitat Politecnica de CatalunyaUniversitat Politecnica de CatalunyaUnaffiliatedGraz University of Technology RFC 7668 describes the adaptation of 6LoWPAN techniques to enable
IPv6 over Bluetooth low energy networks that follow the star
topology. However, recent Bluetooth specifications allow the
formation of extended topologies as well. This document specifies
mechanisms that are needed to enable IPv6 mesh over Bluetooth Low
Energy links established by using the Bluetooth Internet Protocol
Support Profile. This document does not specify the routing protocol
to be used in an IPv6 mesh over Bluetooth LE links.
Work in ProgressMulti-Hop Real-Time Communications Over Bluetooth Low Energy Industrial Wireless Mesh NetworksIEEE Access, Vol 6, pp. 26505-26519IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control SystemsIEEEIEEE Standard for Low-Rate Wireless NetworksIEEEIEEE Standard for Local and Metropolitan Area Networks - Timing and Synchronization for Time-Sensitive Applications in Bridged Local Area NetworksIEEEIEEE Std 802.1AS-2011Data Fields for In-situ OAMCisco Systems, Inc.ThoughtspotHuaweiWork in ProgressWi-SUN PHY Specification V1.0Wi-SUN AllianceDeterministic Networking Use CasesThis document presents use cases for diverse industries that have in common a need for "deterministic flows". "Deterministic" in this context means that such flows provide guaranteed bandwidth, bounded latency, and other properties germane to the transport of time-sensitive data. These use cases differ notably in their network topologies and specific desired behavior, providing as a group broad industry context for Deterministic Networking (DetNet). For each use case, this document will identify the use case, identify representative solutions used today, and describe potential improvements that DetNet can enable.IPv6 Backbone RouterThis document updates RFCs 6775 and 8505 in order to enable proxy services for IPv6 Neighbor Discovery by Routing Registrars called "Backbone Routers". Backbone Routers are placed along the wireless edge of a backbone and federate multiple wireless links to form a single Multi-Link Subnet (MLSN).Using RPI Option Type, Routing Header for Source Routes, and IPv6-in-IPv6 Encapsulation in the RPL Data PlaneThis document looks at different data flows through Low-Power and Lossy Networks (LLN) where RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) is used to establish routing. The document enumerates the cases where RPL Packet Information (RPI) Option Type (RFC 6553), RPL Source Route Header (RFC 6554), and IPv6-in-IPv6 encapsulation are required in the data plane. This analysis provides the basis upon which to design efficient compression of these headers. This document updates RFC 6553 by adding a change to the RPI Option Type. Additionally, this document updates RFC 6550 by defining a flag in the DODAG Information Object (DIO) Configuration option to indicate this change and updates RFC 8138 as well to consider the new Option Type when the RPL Option is decompressed.IEEE 802.15.4g Based Wi-SUN Communication SystemsIEICE Transactions on CommunicationsVolume E100.B, Issue 7, pp. 1032-1043Modular Arithmetic Considerations
Graphically, one might visualize the timeline as follows:
In , the value of CT_abs is envisioned
as traveling to the right as time progresses, getting farther away
from OT_abs and getting closer to DT_abs. The timeline is considered
to be subdivided into time subintervals [i,j] starting and ending at
absolute times equal to k*(2^N), for integer values of k. Let
I_k = k*(2^N) and I_(k+1) = (k+1)*2^N. Intervals starting at I_k
and I_(k+1) may occur at various placements in the above timeline.
Even though OT_abs is always less than DT_abs, it could be that
DT < OT because of the way that DT and OT are represented within
the range [0, 2^N) and similarly for CT_abs and CT compared to OT and DT.
Representing the above situation in time segments of length 2^N
(and values OT, CT, DT) results in several cases where the deadline
time has not elapsed:
1) OT < CT < DT
(e.g., I_k < OT_abs < CT_abs < DT_abs < I_(k+1) )
2) DT < OT < CT
(e.g., I_k < OT_abs < CT_abs < I_(k+1) < DT_abs )
3) CT < DT < OT
(e.g., I_k < OT_abs < I_(k+1) < CT_abs < DT_abs )
In the following cases, the deadline time has elapsed and the
packet should be dropped.
4) DT < CT < OT
5) OT < DT < CT
6) CT < OT < DT
Again in , consider CT_abs as time
moving away from OT_abs and towards DT_abs.
For times CT_abs before the expiration of the deadline time, we also
have CT_abs - OT_abs == CT - OT mod 2^N and similarly for DT_abs -
CT_abs.
As time proceeds, DT_abs - CT_abs gets smaller. When the deadline time
expires, DT_abs - CT_abs begins to grow negative. A proper selection
for SAFETY_FACTOR allows it to go
slightly negative but for an intermediate point to detect that it
has gone negative.
Note that in modular arithmetic, "slightly negative" means exactly
the same as "almost as large as the modulus (i.e., 2^N)".
Now consider the test condition
((CT - DT) mod 2^N) > SAFETY_FACTOR*2^N.
(DT_abs - OT_abs) < 2^N*(1-SAFETY_FACTOR) satisfies the test
condition when CT_abs == OT_abs (i.e., when the packet is launched).
In modular arithmetic, 2^N*(1-SAFETY_FACTOR) ==
2^N - 2^N*SAFETY_FACTOR == -2^N*(SAFETY_FACTOR).
Then DT_abs - OT_abs < -2^N*(1-SAFETY_FACTOR).
Inverting the inequality,
OT_abs - DT_abs > 2^N*(1-SAFETY_FACTOR), and thus at
launch CT_abs - DT_abs > 2^N*(1-SAFETY_FACTOR).
As CT_abs grows larger, CT_abs - DT_abs gets LARGER in (non-negative)
modular arithmetic until the time at which CT_ABS == DT_ABS, and
suddenly CT_ABS - DT_abs becomes zero. Also suddenly, the test
condition is no longer fulfilled.
As CT_abs grows still larger, CT_abs > DT_abs, and we need to detect
this condition as soon as possible. Requiring the SAFETY_FACTOR
enables this detection until CT_abs exceeds DT_abs
by an amount equal to SAFETY_FACTOR*2^N.
A note about "inverting the inequality". Observe that a < b
implies that -a > -b on the real number line. Also,
(a - b) == -(b - a). These facts hold also for modular arithmetic.
During the times prior to the expiration of the deadline, for
Safe = 2^N*SAFETY_FACTOR we have:
(DT_abs - 2^N) < OT_abs < CT_abs < DT_abs < DT_abs+Safe
Naturally, DT_abs - 2^N == DT_abs mod 2^N == DT.
Again considering , it is easy to see
that {CT_abs - (DT_abs - 2^N)} gets larger and larger until the time
at which CT_abs = DT_abs, which is the first time at which
CT - DT == 0 mod 2^N. As CT_abs increases past the deadline time,
0 < CT_abs - DT_abs < Safe. In this range, any intermediate
node can detect that the deadline has expired. As CT_abs increases
past DT_abs+Safe, it is no longer possible for an intermediate node
to determine with certainty whether or not the deadline time has
expired. These statements
also apply when reduced to modular arithmetic in the modulus 2^N.
In particular, the test condition no longer allows
detection of deadline expiration when the current
time becomes later than (DT_abs+Safe). In order to maintain
correctness even for packets that are forwarded after expiration
(i.e., the 'D' flag), N has to be chosen to be so large that
the test condition will not fail -- i.e., that in all scenarios
of interest, the packet will be dropped before the current time
becomes equal to DT_abs+2^N*SAFETY_FACTOR.
Acknowledgments
The authors thank for suggesting the idea and
encouraging the work. Thanks to '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
,
(Routing Directorate),
(Security Directorate),
,
,
,
,
, and
(General Area Review Team (Gen-ART) review)
for their support and valuable feedback.
Authors' AddressesCentre for Development of Advanced ComputingVellayambalamTrivandrum695033Indialijo@cdac.inSRM University-APAmaravati CampusAmaravati, Andhra Pradesh522 502Indiasatishnaidu80@gmail.comIndian Institute of ScienceBangalore560012Indiaanandsvr@iisc.ac.inIndian Institute of ScienceBangalore560012Indiamalati@iisc.ac.inLupin Lodge20600 Aldercroft Heights Rd.Los GatosCA95033United States of Americacharliep@computer.org