rfc9034v6.txt | rfc9034.txt | |||
---|---|---|---|---|
Internet Engineering Task Force (IETF) L. Thomas | Internet Engineering Task Force (IETF) L. Thomas | |||
Request for Comments: 9034 C-DAC | Request for Comments: 9034 C-DAC | |||
Category: Standards Track S. Anamalamudi | Category: Standards Track S. Anamalamudi | |||
ISSN: 2070-1721 SRM University-AP | ISSN: 2070-1721 SRM University-AP | |||
S.V.R. Anand | S.V.R. Anand | |||
M. Hegde | M. Hegde | |||
Indian Institute of Science | Indian Institute of Science | |||
C. Perkins | C. Perkins | |||
Lupin Lodge | Lupin Lodge | |||
May 2021 | June 2021 | |||
Packet Delivery Deadline Time in the Routing Header for IPv6 over Low- | Packet Delivery Deadline Time in the Routing Header for IPv6 over Low- | |||
Power Wireless Personal Area Networks (6LoWPANs) | Power Wireless Personal Area Networks (6LoWPANs) | |||
Abstract | Abstract | |||
This document specifies a new type for the 6LoWPAN routing header | This document specifies a new type for the 6LoWPAN routing header | |||
containing the deadline time for data packets, designed for use over | containing the deadline time for data packets, designed for use over | |||
constrained networks. The deadline time enables forwarding and | constrained networks. The deadline time enables forwarding and | |||
scheduling decisions for time-critical machine-to-machine (M2M) | scheduling decisions for time-critical machine-to-machine (M2M) | |||
skipping to change at line 443 ¶ | skipping to change at line 443 ¶ | |||
Then, the Deadline-6LoRHE encoding with nonzero OTL is: | Then, the Deadline-6LoRHE encoding with nonzero OTL is: | |||
DTL = 3, OTL = 2, TU = 0b10, BinaryPt = 8, DT = 0xD4E4, | DTL = 3, OTL = 2, TU = 0b10, BinaryPt = 8, DT = 0xD4E4, | |||
OTD = 0x64 | OTD = 0x64 | |||
6. Deadline-6LoRHE in Three Network Scenarios | 6. Deadline-6LoRHE in Three Network Scenarios | |||
In this section, the Deadline-6LoRHE operation is described for three | In this section, the Deadline-6LoRHE operation is described for three | |||
network scenarios. Figure 4 depicts a constrained time-synchronized | network scenarios. Figure 4 depicts a constrained time-synchronized | |||
LLN that has two subnets, N1 and N2, connected through 6LowPAN Border | LLN that has two subnets, N1 and N2, connected through 6LoWPAN Border | |||
Routers (6LBRs) [RFC8929] with different reference clock times, T1 | Routers (6LBRs) [RFC8929] with different reference clock times, T1 | |||
and T2. | and T2. | |||
+-------------------+ | +-------------------+ | |||
| Time-Synchronized | | | Time-Synchronized | | |||
| Network | | | Network | | |||
+---------+---------+ | +---------+---------+ | |||
| | | | |||
| | | | |||
| | | | |||
skipping to change at line 615 ¶ | skipping to change at line 615 ¶ | |||
This document defines a new Elective 6LoWPAN Routing Header Type, and | This document defines a new Elective 6LoWPAN Routing Header Type, and | |||
IANA has assigned the value 7 from the 6LoWPAN Dispatch Page 1 number | IANA has assigned the value 7 from the 6LoWPAN Dispatch Page 1 number | |||
space for this purpose. | space for this purpose. | |||
+=======+=================+===========+ | +=======+=================+===========+ | |||
| Value | Description | Reference | | | Value | Description | Reference | | |||
+=======+=================+===========+ | +=======+=================+===========+ | |||
| 7 | Deadline-6LoRHE | RFC 9034 | | | 7 | Deadline-6LoRHE | RFC 9034 | | |||
+-------+-----------------+-----------+ | +-------+-----------------+-----------+ | |||
Table 1: Entry in the Elective | Table 1: Entry in the "Elective | |||
6LoWPAN Routing Header Type | 6LoWPAN Routing Header Type" | |||
Registry | Registry | |||
8. Synchronization Aspects | 8. Synchronization Aspects | |||
The document supports time representation of the deadline and | The document supports time representation of the deadline and | |||
origination times carried in the packets traversing networks of | origination times carried in the packets traversing networks of | |||
different time zones having different time-synchronization | different time zones having different time-synchronization | |||
mechanisms. For instance, in a 6TiSCH network where the time is | mechanisms. For instance, in a 6TiSCH network where the time is | |||
maintained as ASN time slots, the time synchronization is achieved | maintained as ASN time slots, the time synchronization is achieved | |||
through beaconing among the nodes as described in [RFC7554]. There | through beaconing among the nodes as described in [RFC7554]. There | |||
skipping to change at line 822 ¶ | skipping to change at line 822 ¶ | |||
<https://ieeexplore.ieee.org/document/7460875>. | <https://ieeexplore.ieee.org/document/7460875>. | |||
[IEEE.802.1AS.2011] | [IEEE.802.1AS.2011] | |||
IEEE, "IEEE Standard for Local and Metropolitan Area | IEEE, "IEEE Standard for Local and Metropolitan Area | |||
Networks - Timing and Synchronization for Time-Sensitive | Networks - Timing and Synchronization for Time-Sensitive | |||
Applications in Bridged Local Area Networks", IEEE Std | Applications in Bridged Local Area Networks", IEEE Std | |||
802.1AS-2011, DOI 10.1109/IEEESTD.2011.5741898, March | 802.1AS-2011, DOI 10.1109/IEEESTD.2011.5741898, March | |||
2011, <https://doi.org/10.1109/IEEESTD.2011.5741898>. | 2011, <https://doi.org/10.1109/IEEESTD.2011.5741898>. | |||
[IOAM-DATA] | [IOAM-DATA] | |||
Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields | Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi, | |||
for In-situ OAM", Work in Progress, Internet-Draft, draft- | Ed., "Data Fields for In-situ OAM", Work in Progress, | |||
ietf-ippm-ioam-data-12, 21 February 2021, | Internet-Draft, draft-ietf-ippm-ioam-data-12, 21 February | |||
<https://tools.ietf.org/html/draft-ietf-ippm-ioam-data- | 2021, <https://tools.ietf.org/html/draft-ietf-ippm-ioam- | |||
12>. | data-12>. | |||
[PHY-SPEC] Wi-SUN Alliance, "Wi-SUN PHY Specification V1.0", March | [PHY-SPEC] Wi-SUN Alliance, "Wi-SUN PHY Specification V1.0", March | |||
2016, <http://wi-sun.org>. | 2016, <http://wi-sun.org>. | |||
[RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", | [RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", | |||
RFC 8578, DOI 10.17487/RFC8578, May 2019, | RFC 8578, DOI 10.17487/RFC8578, May 2019, | |||
<https://www.rfc-editor.org/info/rfc8578>. | <https://www.rfc-editor.org/info/rfc8578>. | |||
[RFC8929] Thubert, P., Ed., Perkins, C.E., and E. Levy-Abegnoli, | [RFC8929] Thubert, P., Ed., Perkins, C.E., and E. Levy-Abegnoli, | |||
"IPv6 Backbone Router", RFC 8929, DOI 10.17487/RFC8929, | "IPv6 Backbone Router", RFC 8929, DOI 10.17487/RFC8929, | |||
skipping to change at line 904 ¶ | skipping to change at line 904 ¶ | |||
similarly for DT_abs - CT_abs. | similarly for DT_abs - CT_abs. | |||
As time proceeds, DT_abs - CT_abs gets smaller. When the deadline | As time proceeds, DT_abs - CT_abs gets smaller. When the deadline | |||
time expires, DT_abs - CT_abs begins to grow negative. A proper | time expires, DT_abs - CT_abs begins to grow negative. A proper | |||
selection for SAFETY_FACTOR allows it to go _slightly negative_ but | selection for SAFETY_FACTOR allows it to go _slightly negative_ but | |||
for an intermediate point to _detect_ that it has gone negative. | for an intermediate point to _detect_ that it has gone negative. | |||
Note that in modular arithmetic, "slightly negative" means _exactly_ | Note that in modular arithmetic, "slightly negative" means _exactly_ | |||
the same as "almost as large as the modulus (i.e., 2^N)". Now | 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. | consider the test condition ((CT - DT) mod 2^N) > SAFETY_FACTOR*2^N. | |||
(DT_abs - OT_abs) < 2^N*(1-SAFETY_FACTOR) satifies the test condition | (DT_abs - OT_abs) < 2^N*(1-SAFETY_FACTOR) satisfies the test | |||
when CT_abs == OT_abs (i.e., when the packet is launched). In | condition when CT_abs == OT_abs (i.e., when the packet is launched). | |||
modular arithmetic, 2^N*(1-SAFETY_FACTOR) == 2^N - 2^N*SAFETY_FACTOR | In modular arithmetic, 2^N*(1-SAFETY_FACTOR) == 2^N - | |||
== -2^N*(SAFETY_FACTOR). Then DT_abs - OT_abs < | 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). 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), and thus at launch CT_abs - DT_abs > | |||
2^N*(1-SAFETY_FACTOR). | 2^N*(1-SAFETY_FACTOR). | |||
As CT_abs grows larger, CT_abs - DT_abs gets LARGER in (non-negative) | 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 | modular arithmetic until the time at which CT_ABS == DT_ABS, and | |||
suddenly CT_ABS - DT_abs becomes zero. Also suddenly, the test | suddenly CT_ABS - DT_abs becomes zero. Also suddenly, the test | |||
condition is no longer fulfilled. | condition is no longer fulfilled. | |||
As CT_abs grows still larger, CT_abs > DT_abs, and we need to detect | As CT_abs grows still larger, CT_abs > DT_abs, and we need to detect | |||
End of changes. 5 change blocks. | ||||
13 lines changed or deleted | 13 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |