RFC 9034

Packet Delivery Deadline Time in the Routing Header for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)

📅 published June 2021, from ietf

📬 RFC 9034: Packet Delivery Deadline Time in the Routing Header for IPv6 over 6LoWPANs 💖

okay bestie, this one is about giving packets a deadline 😭⏰. The header info is:

  • RFC number: 9034
  • Title: Packet Delivery Deadline Time in the Routing Header for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)
  • Authors: L. Thomas (C-DAC), S. Anamalamudi (SRM University-AP), S.V.R. Anand and M. Hegde (Indian Institute of Science), and C. Perkins (Lupin Lodge)
  • Category: Standards Track, so it's an Internet Standards Track document 🎀
  • ISSN: 2070-1721
  • Date: June 2021
  • Obsoletes / Updates: the header doesn't list any, so this doc doesn't obsolete or update anything 🌸

Abstract ✨

this doc specs a brand new type for the 6LoWPAN routing header that carries the deadline time for data packets 🕰️. it's built for constrained networks, so it's lowkey perfect for tiny devices. the deadline time helps with forwarding and scheduling decisions for time-critical machine-to-machine (M2M) apps running on internet-enabled devices inside time-synchronized networks 🤖💅. it also defines a way to represent those deadline time values in these networks 🦋.

Status of This Memo

this is an Internet Standards Track document 🎀.

it's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community 🫶. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG) ✅. if you want more on Internet Standards, check out Section 2 of RFC 7841 📚.

for info on the current status, errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc9034 💌.

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. ©️🌈

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication. please actually read these, bestie, because they explain your rights and restrictions for this doc 🙈. code components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License 📜.

Table of Contents 🧚

   1.  Introduction
   2.  Terminology
   3.  6LoRHE Generic Format
   4.  Deadline-6LoRHE
   5.  Deadline-6LoRHE Format
   6.  Deadline-6LoRHE in Three Network Scenarios
     6.1.  Scenario 1: Endpoints in the Same DODAG (N1)
     6.2.  Scenario 2: Endpoints in Networks with Dissimilar L2
           Technologies
     6.3.  Scenario 3: Packet Transmission across Different DODAGs (N1
           to N2)
   7.  IANA Considerations
   8.  Synchronization Aspects
   9.  Security Considerations
   10. References
     10.1.  Normative References
     10.2.  Informative References
   Appendix A.  Modular Arithmetic Considerations
   Acknowledgments
   Authors' Addresses

1. Introduction 🌸

Low-Power and Lossy Networks (LLNs) are likely to get deployed for real-time industrial apps that need end-to-end delay guarantees [RFC8578] 🏭. a Deterministic Network ("DetNet") usually needs some packets to reach their receivers within strict time bounds ⏱️. intermediate nodes use the deadline info to make the right forwarding and scheduling choices so they can hit those time bounds 💅.

this doc specs a new type for the Elective 6LoWPAN Routing Header (6LoRHE), called Deadline-6LoRHE 🎀. this way the deadline time (basically, the time of latest acceptable delivery) for data packets can be put inside the 6LoRHE ✨. [RFC8138] specs the 6LoWPAN Routing Header (6LoRH), compression schemes for RPL (Routing Protocol for Low-Power and Lossy Networks) source routing [RFC6554], header compression of RPL packet information [RFC6553], and IP-in-IP encapsulation 📦. this doc also covers how the deadline time is handled when packets go through time-synchronized networks that run in different time zones or use different reference clocks 🌍. time-synchronization techniques themselves are outside the scope of this doc 🙃. there are a bunch of standards for that, including IEEE 1588 [IEEE.1588.2008], IEEE 802.1AS [IEEE.802.1AS.2011], IEEE 802.15.4-2015 Time-Slotted Channel Hopping (TSCH) [IEEE.802.15.4], 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 how the Deadline-6LoRHE gets implemented, but that doesn't stop it from being used in other scenarios besides 6TiSCH 🦋. for example, there's growing interest in using 6LoWPAN over a Bluetooth Low Energy (BLE) mesh network [6LO-BLEMESH] in industrial IoT (Internet of Things) [IEEE-BLE-MESH] 🏭💜. the Bluetooth community is also exploring BLE mesh time synchronization 👀. there are cases under consideration in Wi-SUN too [PHY-SPEC] [Wi-SUN] 🌈.

2. Terminology 📖

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🔥. they only count as BCP 14 key words in all caps, so lowercase versions are just regular words, bestie 🙈.

this doc uses the terminology defined in [RFC6550] and [RFC9030] 📚.

3. 6LoRHE Generic Format 🧚

Note: this section is not normative and is included for convenience 💡. the generic header format of the 6LoRHE is specified in [RFC8138]. Figure 1 shows 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     |        Options            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-        ...              -+
                                   <---    length         --->

                      Figure 1: 6LoRHE Format

Length: the length of the 6LoRHE, in bytes, not counting the first 2 bytes 📏. this lets a node skip a 6LoRHE whose Type it doesn't recognize or support 🙌.

Type (variable length): the type of the 6LoRHE (see Section 7) 🏷️.

4. Deadline-6LoRHE 💖

the Deadline-6LoRHE (see Figure 3) is a 6LoRHE [RFC8138] that gives 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 holds the time the packet got enqueued for transmission (written as a value to be subtracted from DT) 🕰️. this lets you get a close estimate of the total delay a packet picked up 🔍. the sender initializes the OTD field based on the current time at the outgoing network interface the packet gets forwarded through 📤. since the OTD is a delta, the OTD field's length (OTL) needs fewer bits than the DT field's length (DTL) 🧠✨.

the DT field has the deadline time for the packet, aka the time by which the app expects the packet to reach the receiver 🎯.

     packet_deadline_time = packet_origination_time + max_delay

to support delay-sensitive, deterministic apps, all nodes in the network should process the Deadline-6LoRHE 💅. the DT and OTD packets are represented in time units set 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, like a 6TiSCH network where global time is kept in units of slot lengths at a certain resolution 🎰.

the delay packets experience in the network is a useful metric for network diagnostics and performance monitoring 📊. whenever a packet crosses into a network that uses a different reference clock, the DT field gets updated so it still represents the same deadline time, just expressed with the reference clock of the interface into the new network 🔄. the origination time is then the current time when the packet is transmitted into the new network, minus the delay the packet already experienced (called 'current_dly') 🫠. so inside the new network, the packet appears to have originated 'current_dly' time units earlier, relative to the new network's reference clock 🪄.

     new_network_origin_time = time_now_in_new_network - current_dly

the example below shows these calculations when a packet travels between three networks, each in a different time zone (TZ) 🌏. 'x' can be 1, 2, or 3 🔢. say the deadline time measured in TZ1 is 1050, and the origination time is 50 🕐. 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 measured in the current time zone, and it equals DT - OTD, which is DT - 1000 🧮. Figure 2 uses these abbreviations:

  • TxA: time of arrival of the packet in network 'x' 🛬
  • TxD: departure time of the packet from network 'x' 🛫
  • dlyx: delay the packet experienced in the previous network(s) ⏳
  • TZx: the time zone of network 'x' 🗺️
           TZ1                      TZ2                    TZ3
 T1A=50|                 |                             |
       |----  dly1=50    |                             |
       |     \           |                             |
       |      \          |                             |
       |       \ T1D=100 |T2A=1000                     |
       |        -------->|-----           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

               Figure 2: Deadline Time Update Example

there are a bunch of ways a packet can get delayed, including queuing delay, Media Access Control (MAC) layer contention delay, serialization delay, and propagation delay 🐢. sometimes processing delays happen too 🛠️. for the purpose of figuring out whether the deadline has already passed, these different delays are not told apart 🤷‍♀️✨.

to be continued, bestie! 🌈 part 2 picks up with Section 5, the Deadline-6LoRHE Format 💜🦋

5. Deadline-6LoRHE Format ✨

okay bestie, this is where the Deadline-6LoRHE gets its outfit 💅 Here's the layout, and yes, the bit numbers matter so don't skip this figure 🎀

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |1|0|1| Length  |  6LoRH Type   |D| TU|  DTL  | OTL | BinaryPt  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      DT (variable length)     | OTD(variable length)(optional)|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: Deadline-6LoRHE Format

Here's the field-by-field breakdown, no cap 🧚

  • Length (5 bits): Length is the total length of the Deadline-6LoRHE Type, measured in octets. Lowkey the most important number to get right 🌸
  • 6LoRH Type: 7 (see Section 7). 💜
  • D flag (1 bit): The D flag is set by the sender, and it decides what happens when a 6LoWPAN Router (6LR) notices the deadline time has already passed. 🦋
    • If D is 1, the 6LR MUST drop the packet once the deadline time has elapsed. Bye bye packet 💀
    • If D is 0, the packet MAY be forwarded on an exception basis, but only if the forwarding node is NOT in a situation of constrained resource, and only if there are reasons to suspect that downstream nodes might find it useful (delay measurements, interpolations, etc.). It's giving "maybe, if you've got the room" 🫶
  • TU (2 bits): This tells you the time units for the DT and OTD fields. Both fields use the same time units and precision. The encodings are:
    • 00: time represented in seconds and fractional seconds 🕰️
    • 01: Reserved
    • 10: Network ASN ⭐
    • 11: Reserved
  • DTL (4 bits): The length of the DT field, as an unsigned 4-bit integer. It encodes the field length in hex digits, minus one. Yes, minus one, don't ask me why, it's the vibe 🙈
  • OTL (3 bits): The length of the OTD field, as an unsigned 3-bit integer. It encodes the field length 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. Main character rule: no going over the limit 👑
    • For example, DTL = 0b0000 means the DT field in the 6LoRHE is 1 hex digit (4 bits) long. And OTL = 0b111 means the OTD field is 7 hex digits (28 bits) long. 🍓
  • BinaryPt (6 bits): If it's zero, the number of bits for the integer part of the DT equals the number of bits for its fractional part. If it's nonzero, BinaryPt is a (2's complement) signed integer that sets where the binary point sits inside the DT value. That lets BinaryPt range over [-32,31]. 🌈
    • If BinaryPt is positive, the integer part of DT gets that many extra bits, and the fractional part gets correspondingly fewer. That boosts the range of DT 📈
    • If BinaryPt is negative, the integer part of DT loses that many bits, and the fractional part gains them. That boosts the precision of the fractional seconds in DT 🔬
  • DT Value (4..64 bits): An unsigned integer of DTL+1 hex digits, giving the DT value. ⏰
  • OTD Value (4..28 bits): If it's present, this is an unsigned integer of OTL hex digits, giving the origination time as a negative offset from the DT value. 🕊️

Whenever a sender starts up the IP datagram, it includes the Deadline-6LoRHE along with its other 6LoRH information. For what the time-synchronization requirements between sender and receiver look like, check out Section 8 🫶

Next up, the compressed time representation. For the chosen time unit, the originating application figures out how many time bits it needs to show the gap between the moment the packet launches and the deadline time, fractional units included. Call that number N_bits. It sets DTL like this: DTL = ((N_bits - 1) / 4) ✨

The bits picked by DTL can count any number of fractional time units inside the range of interest set by DT and OT. Let's call that count Epoch_Range(DTL), where Epoch_Range is a function of DTL: Epoch_Range(DTL) = 2^(4*(DTL+1)) 🧠

Every point in time between OT and DT gets written as a time unit plus a fractional time unit. In this section, that combo is called a rational time unit (RTU). 1 RTU is the smallest fractional time you can show between two points in the epoch (so, inside the range of interest). 🎀

DT - OT can't go past 2^(4*(DTL+1)) == 16^(DTL+1). A low DTL means a tiny Epoch_Range. If DTL = 0, you only get 16 RTUs inside the Epoch_Range (Epoch_Range(DTL) = 16^1) for any TU. The values you can show in the current epoch sit in the range [0, (Epoch_Range(DTL) - 1)]. 🍓

If wraparound doesn't happen, OT is represented by (OT mod Epoch_Range), and DT is represented by (DT mod Epoch_Range). All the arithmetic is done modulo Epoch_Range(DTL), which means DT - OT always comes out positive 💖

Now for fine-grained control over the deadline time. The DT and OTD fields use fractional seconds. A binary point decides how many bits go to the fractional part, so every fraction has to be a negative power of 2. Each point of time between OT and DT is then a time unit (seconds or ASNs) plus a fractional time unit. 🦋

Let OT_abs, DT_abs, and CT_abs be the true (absolute) values of OT, DT, and the current time, all on the synchronized timelines. Let N be the number of bits used for 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 tell whether CT_abs > DT_abs. 🔥

Once you have N, the DT value in the deadline-time format is DT = (DT_abs mod 2^N). DT is usually written as a positive value, even though negative modular values make sense too. Also, OT = OT_abs mod 2^N and CT = CT_abs mod 2^N, and both OT and CT are treated as non-negative. 🌸

When the originating node launches the packet, CT_abs == OT_abs and CT == OT. For a given N, downstream nodes can only tell whether the deadline has expired (that is, whether DT_abs > CT_abs) if this holds:

Assumption 1: DT_abs - OT_abs < 2^N.

If that breaks, the ambiguity in the modulus math that produces OT and DT will cause failure, because you can't measure time differences bigger than 2^N using numbers from a time segment shorter than 2^N. Yikes 😭

When Assumption 1 holds, downstream nodes have to check whether their current time is later than DT. But DT has to be inferred from the DT in the 6LoRHE, which is a number less than 2^N. That inference can't be counted on to work reliably unless Assumption 1 is valid, which means the originating node has to be careful to pick proper values for DTL and BinaryPt. Choose wisely, bestie 🙈

OT isn't always provided in the 6loRHE, so there's a possible ambiguity. When DT = CT, the deadline time is expiring and the packet should be dropped, no debate. But what if an intermediate node measures CT = DT+1? Did the packet launch just a short time before it arrived at that node, or did the current time wrap around so that CT_abs - OT_abs > 2^N? That's the plot twist 😱

To solve this, a safety margin has to be provided, on top of requiring DT_abs - OT_abs < 2^N. The size of this margin is proportional to 2^N and is set by a new parameter called the "SAFETY_FACTOR". So, for safety, the originating node MUST further ensure that (DT_abs - OT_abs) < 2^N*(1-SAFETY_FACTOR). Safety first, always 🛡️

Each intermediate node that receives a packet with the Deadline-6LoRHE must determine whether ((CT - DT) mod 2^N) > SAFETY_FACTOR*2^N. If that test condition is not satisfied, the deadline time has expired. Appendix A has more explanation about the test condition if you want the deep dive 🧚 All nodes that receive a packet with a Deadline-6LoRHE included MUST use the same value for the SAFETY_FACTOR. No mixing and matching, periodt 💅 The SAFETY_FACTOR is chosen so that a packet with the Deadline-6LoRHE included gets tested against the current time at least once during every subinterval of length SAFETY_FACTOR*2^N. That way, it's guaranteed that the packet gets tested often enough to be dropped whenever CT_abs > DT_abs. The value of SAFETY_FACTOR is specified in this document to be 20% ✨

Here's an example to make it click 🎀

      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 = 0x64

6. Deadline-6LoRHE in Three Network Scenarios 🧚

okay so in this section we look at how the Deadline-6LoRHE works in three network scenarios. Let's start with the first one, a constrained time-synchronized LLN that has two subnets, N1 and N2. They're connected through 6LoWPAN Border Routers (6LBRs) [RFC8929] and run on different reference clock times, T1 and T2. Picture it like this 🌈

                          +-------------------+
                          | 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 4: Intra-Network Time Zone Scenario

6.1. Scenario 1: Endpoints in the Same DODAG (N1) 🦋

Okay so Scenario 1 (see Figure 5) is when the Sender 'S' has an IP datagram to send to a Receiver 'R' inside the same DODAG (Destination-Oriented Directed Acyclic Graph) 🌸. 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 ⏰. After that, each 6LR does hop-by-hop routing to forward the packet toward the 6LBR. Once the 6LBR gets the IP datagram, it sends the packet downstream toward '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 [RFC9008] 🧚. 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 ✂️.

                              +-------+
                   ^          | 6LBR  |       |
                   |          |       |       |
                   |          +-------+       |
           Upward  |         /      /| \      | Downward
           routing |      (F)      / |  \     | routing
                   |     /  \    (C) |  (D)   |
                   |    /    \    |  | / |\   |
                   |  (A)    (B)  : (E)  : R  |
                   |  /|\     | \   / \       |
                   | S : :    : :  :  :       v

           Figure 5: Endpoints within the Same DODAG (Subnet N1)

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

6.2. Scenario 2: Endpoints in Networks with Dissimilar L2 Technologies ✨

In Scenario 2 (see Figure 6), 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. Then each 6LR does hop-by-hop routing to forward the packet toward the 6LBR. Once the deadline time information reaches the 6LBR, the packet gets encoded according to the mechanism prescribed in the other time-synchronized network, which is depicted as "Time-Synchronized Network" in Figure 6 🦋. The specific data encapsulation mechanisms followed in the new network are beyond the scope of this document 🙈.

                              +----------------+
                              | Time-          |
                              | Synchronized   |------R
                              | Network        |
                              +----------------+
                                      |
                                      |
                            ----------+-----------
                     ^                |
                     |            +---+---+
                     |            | 6LBR  |
            Upward   |            |       |
            routing  |            +------++
                     |        (F)/      /| \
                     |       /  \      / |  \
                     |      /    \   (C) |  (D)
                     |    (A)    (B)  |  | / |\
                     |    /|\     |\  : (E)  : :
                     |   S : :    : :   / \
                                       :   :

       Figure 6: Packet Transmission in Dissimilar L2 Technologies or
                                  Internet

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) [IOAM-DATA]. After that, the deadline time 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 N2) 💜

Let's look at the scenario in Figure 7, where the Sender 'S' (belonging to DODAG 1) has an IP datagram to send to Receiver 'R', who belongs to another DODAG (DODAG 2) 👯. This scenario can be broken down into a combination of Scenarios 1 and 2, so it's giving building blocks 🧱. For the route segment from 'S' to 6LBR1, 'S' includes the Deadline-6LoRHE. Then each 6LR does hop-by-hop operations to forward the packet toward 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 toward 'R' 🚀.

                    Time-Synchronized Network
                  -+---------------------------+-
                   |                           |
      DODAG1   +---+---+                   +---+---+   DODAG2
               | 6LBR1 |                   | 6LBR2 |
               |       |                   |       |
               +-------+                   +-------+
           (F)/      /| \              (F)/      /| \
          /  \      / |  \            /  \      / |  \
         /    \   (C) |  (D)         /    \   (C) |  (D)
       (A)    (B)  |  | / |\       (A)    (B)  |  |   |\
       /|\     |\  : (E)  : :      /|\     |\  : (E)  : :
      S : :    : :   / \          : : :    : :   / \
                    :   :                       :   R
   Network N1, time zone T1      Network N2, time zone T2

        Figure 7: Packet Transmission in Different DODAGs (N1 to N2)

Let's do an example 🍓. Picture a 6TiSCH network where 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. Here's the math:

      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 * 10^3 milliseconds

Once the deadline time information reaches 6LBR2, the packet gets encoded according to the mechanism prescribed in the other time-synchronized network 💖.

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

                  +=======+=================+===========+
                  | Value | Description     | Reference |
                  +=======+=================+===========+
                  | 7     | Deadline-6LoRHE | RFC 9034  |
                  +-------+-----------------+-----------+

                      Table 1: Entry in the "Elective
                        6LoWPAN Routing Header Type"
                                  Registry

8. Synchronization Aspects ⏱️

The document supports time representation of the deadline and origination times carried in the packets traversing networks of different time zones, which have 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 [RFC7554] 🐝. 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 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 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 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 [RFC5905], 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 Section 5 👑.

      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 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 2^32 seconds, which is roughly 136 years 🕰️.

For TU = 0b10, the time units are ASNs. The start time is relative, and it's 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 🥹.

9. Security Considerations ✨

okay bestie, the security section is SERIOUS and I'm here for it 🔒💅 Honestly, the security stuff for this one is mostly "go read the security sections of the RFCs we're built on," because 6LoRHE doesn't invent a brand-new threat. Like, the compressed format is logically the same as the full inline format, so it does not open a new door for attackers compared to [RFC6550], [RFC6553], and [RFC6554]. Lowkey iconic that it just inherits everything. 🫶

The security considerations of [RFC4944] (Section 13), [RFC6282] (Section 6), and [RFC6553] (Section 5) apply. ✨

Now the vibe check: this stuff is designed for controlled operational environments, like industrial process control and automation 🏭. Because deadline info could be misused to launch a Denial of Service (DoS) attack 😭, the deadline time mechanism only works properly if the network resources are provisioned and managed. That means setting aside resources for traffic flows with deadlines, doing performance monitoring, and enforcing admission control policy. This provisioning can be centralized or distributed, totally your call 💜. For example, tracks in a 6TiSCH network could be set up by a centralized Path Computation Element (PCE), as described in the 6TiSCH architecture [RFC9030]. 🌸

The security considerations of DetNet architecture [RFC8655] (Section 5) mostly apply here too 🦋. To secure the request and control of resources allocated for tracks, you can use authentication and authorization for each device and for the network controller devices. With distributed control protocols, security is expected to come from the security properties of the protocols in use. 🔐

Also, identifying deadline-bearing flows on a per-flow basis may give attackers extra information about the data flows, compared to networks that don't do per-flow identification 👀. The security implications of disclosing that extra information deserve consideration when you implement this deadline specification. Not me overthinking this, but it's important! 🙈

Last but DEFINITELY not least: because the protocol needs precise time synchronization, the accuracy, availability, and integrity of time synchronization is of critical importance 🚨⏰. There's an extensive discussion of this topic in [RFC7384]. Go read it, periodt. 💖

10. References ⭐

10.1. Normative References 🌟

10.2. Informative References 📚

Appendix A. Modular Arithmetic Considerations 🧮✨

okay bestie, this appendix is where the timing math gets so deep, and I'm obsessed. 😭🎀 Let's go through it together.

Graphically, one might visualize the timeline as follows: 🦋

          OT_abs        CT_abs        DT_abs
     -------|-------------|-------------|------------------>

             Figure 8: Absolute Timeline Representation

In Figure 8, 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. 🌀 wild, right? the wrapping is literally the whole plot. 💅

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. 🙈 no thank you, bye packet.

  1. DT < CT < OT
  2. OT < DT < CT
  3. CT < OT < DT

Again in Figure 8, 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). 🧠💖 okay this part is a little spicy, but the vibes are that at launch you're safely on the good side.

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 Figure 8, 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. 💅⚠️ this is the part where you really don't want to mess up the sizing, bestie.

Acknowledgments 🫶🌟

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 (General Area Review Team (Gen-ART) review) for their support and valuable feedback. 💖 the whole squad got a shoutout, iconic.

Authors' Addresses 🎀

Lijo Thomas Centre for Development of Advanced Computing Vellayambalam Trivandrum 695033 India

Email: lijo@cdac.in

Satish Anamalamudi SRM University-AP Amaravati Campus Amaravati, Andhra Pradesh 522 502 India

Email: satishnaidu80@gmail.com

S.V.R. Anand Indian Institute of Science Bangalore 560012 India

Email: anandsvr@iisc.ac.in

Malati Hegde Indian Institute of Science Bangalore 560012 India

Email: malati@iisc.ac.in

Charles E. Perkins Lupin Lodge 20600 Aldercroft Heights Rd. Los Gatos, CA 95033 United States of America

Email: charliep@computer.org

that's the whole thing, bestie! the squad that wrote this is literally legends 🌈👑✨

📦 where this page comes from