< draft-ietf-6lo-deadline-time-05.txt | draft-ietf-6lo-deadline-time-06f.txt > | |||
---|---|---|---|---|
6lo Lijo Thomas | 6lo Lijo Thomas | |||
Internet-Draft C-DAC | Internet-Draft C-DAC | |||
Intended status: Standards Track S. Anamalamudi | Intended status: Standards Track S. Anamalamudi | |||
Expires: January 9, 2020 SRM University-AP | Expires: April 30, 2020 SRM University-AP | |||
S.V.R.Anand | S.V.R.Anand | |||
Malati Hegde | Malati Hegde | |||
Indian Institute of Science | Indian Institute of Science | |||
C. Perkins | C. Perkins | |||
Futurewei | Blue Meadow Networking | |||
July 8, 2019 | October 28, 2019 | |||
Packet Delivery Deadline time in 6LoWPAN Routing Header | Packet Delivery Deadline time in 6LoWPAN Routing Header | |||
draft-ietf-6lo-deadline-time-05 | draft-ietf-6lo-deadline-time-06 | |||
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 IoT machine to machine (M2M) | scheduling decisions for time critical IoT machine to machine (M2M) | |||
applications that operate within time-synchronized networks that | applications that operate within time-synchronized networks. This | |||
agree on the meaning of the time representations used for the | document also specifies a representation for the deadline time values | |||
deadline time values. | in such networks. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on January 9, 2020. | This Internet-Draft will expire on April 30, 2020. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2019 IETF Trust and the persons identified as the | Copyright (c) 2019 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 22 ¶ | skipping to change at page 2, line 22 ¶ | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
3. 6LoRHE Generic Format . . . . . . . . . . . . . . . . . . . . 3 | 3. 6LoRHE Generic Format . . . . . . . . . . . . . . . . . . . . 3 | |||
4. Deadline-6LoRHE . . . . . . . . . . . . . . . . . . . . . . . 4 | 4. Deadline-6LoRHE . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
5. Deadline-6LoRHE Format . . . . . . . . . . . . . . . . . . . 6 | 5. Deadline-6LoRHE Format . . . . . . . . . . . . . . . . . . . 6 | |||
6. Deadline-6LoRHE in Three Network Scenarios . . . . . . . . . 8 | 6. Deadline-6LoRHE in Three Network Scenarios . . . . . . . . . 9 | |||
6.1. Scenario 1: Endpoints in the same DODAG (N1) . . . . . . 9 | 6.1. Scenario 1: Endpoints in the same DODAG (N1) . . . . . . 10 | |||
6.2. Scenario 2: Endpoints in Networks with Dissimilar L2 | 6.2. Scenario 2: Endpoints in Networks with Dissimilar L2 | |||
Technologies. . . . . . . . . . . . . . . . . . . . . . . 10 | Technologies. . . . . . . . . . . . . . . . . . . . . . . 11 | |||
6.3. Scenario 3: Packet transmission across different DODAGs | 6.3. Scenario 3: Packet transmission across different DODAGs | |||
(N1 to N2). . . . . . . . . . . . . . . . . . . . . . . . 11 | (N1 to N2). . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | |||
8. Synchronization Aspects . . . . . . . . . . . . . . . . . . . 13 | 8. Synchronization Aspects . . . . . . . . . . . . . . . . . . . 14 | |||
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 | |||
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 | 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 | |||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
11.1. Normative References . . . . . . . . . . . . . . . . . . 15 | 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 | |||
11.2. Informative References . . . . . . . . . . . . . . . . . 17 | 11.2. Informative References . . . . . . . . . . . . . . . . . 18 | |||
Appendix A. Changes from revision 04 to revision 05 . . . . . . 18 | Appendix A. Changes from revision 05 to revision 06 . . . . . . 19 | |||
Appendix B. Changes from revision 03 to revision 04 . . . . . . 18 | Appendix B. Changes from revision 04 to revision 05 . . . . . . 19 | |||
Appendix C. Changes from revision 02 to revision 03 . . . . . . 19 | Appendix C. Changes from revision 03 to revision 04 . . . . . . 20 | |||
Appendix D. Changes from revision 01 to revision 02 . . . . . . 19 | Appendix D. Changes from revision 02 to revision 03 . . . . . . 20 | |||
Appendix E. Changes between earlier versions . . . . . . . . . . 20 | Appendix E. Changes from revision 01 to revision 02 . . . . . . 21 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 | Appendix F. Changes between earlier versions . . . . . . . . . . 21 | |||
Appendix G. Modular Arithmetic Considerations . . . . . . . . . 21 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 | ||||
1. Introduction | 1. Introduction | |||
Low Power and Lossy Networks (LLNs) are likely to be deployed for | Low Power and Lossy Networks (LLNs) are likely to be deployed for | |||
real time industrial applications requiring end-to-end delay | real time industrial applications requiring end-to-end delay | |||
guarantees [I-D.ietf-detnet-use-cases]. A Deterministic Network | guarantees [I-D.ietf-detnet-use-cases]. A Deterministic Network | |||
("detnet") typically requires some data packets to reach their | ("detnet") typically requires some data packets to reach their | |||
receivers within strict time bounds. Intermediate nodes use the | receivers within strict time bounds. Intermediate nodes use the | |||
deadline information to make appropriate packet forwarding and | deadline information to make appropriate packet forwarding and | |||
scheduling decisions to meet the time bounds. | scheduling decisions to meet the time bounds. | |||
skipping to change at page 3, line 23 ¶ | skipping to change at page 3, line 23 ¶ | |||
synchronized networks operating in different timezones or distinct | synchronized networks operating in different timezones or distinct | |||
reference clocks. Time synchronization techniques are outside the | reference clocks. Time synchronization techniques are outside the | |||
scope of this document. There are a number of standards available | scope of this document. There are a number of standards available | |||
for this purpose, including IEEE 1588 [ieee-1588], IEEE 802.1AS | for this purpose, including IEEE 1588 [ieee-1588], IEEE 802.1AS | |||
[dot1AS-2011], IEEE 802.15.4-2015 TSCH [dot15-tsch], and more. | [dot1AS-2011], IEEE 802.15.4-2015 TSCH [dot15-tsch], and more. | |||
The Deadline-6LoRHE can be used in any time synchronized 6Lo network. | The Deadline-6LoRHE can be used in any time synchronized 6Lo network. | |||
A 6TiSCH network is used to describe the implementation of the | A 6TiSCH network is used to describe the implementation of the | |||
Deadline-6LoRHE, but this does not preclude its use in scenarios | Deadline-6LoRHE, but this does not preclude its use in scenarios | |||
other than 6TiSCH. For instance, there is a growing interest in | other than 6TiSCH. For instance, there is a growing interest in | |||
using 6lo over a BLE mesh network [I-D.ietf-6lo-blemesh] in | using 6lo over a Bluetooth Low Energy (BLE) mesh network | |||
industrial IoT [dotBLEMesh]. BLE mesh time synchronization is being | [I-D.ietf-6lo-blemesh] in industrial IoT [dotBLEMesh]. BLE mesh time | |||
explored by the Bluetooth community. There are also cases under | synchronization is being explored by the Bluetooth community. There | |||
consideration in Wi-SUN [Wi-SUN_PHY], [dotWi-SUN]. | are also cases under consideration in Wi-SUN [Wi-SUN_PHY], | |||
[dotWi-SUN]. | ||||
2. Terminology | 2. Terminology | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
[RFC2119] [RFC8174]. | 14 [RFC2119] [RFC8174]. | |||
This document uses the terminology defined in [RFC6550] and | This document uses the terminology defined in [RFC6550] and | |||
[I-D.ietf-6tisch-terminology]. | [I-D.ietf-6tisch-architecture]. | |||
3. 6LoRHE Generic Format | 3. 6LoRHE Generic Format | |||
Note: this section is not normative and is included for convenience. | Note: this section is not normative and is included for convenience. | |||
The generic header format of the 6LoRHE is specified in | The generic header format of the 6LoRHE is specified in | |||
[I-D.ietf-roll-routing-dispatch]. Figure 1 illustrates the 6LoRHE | [I-D.ietf-roll-routing-dispatch]. Figure 1 illustrates the 6LoRHE | |||
generic format. | generic format. | |||
0 1 | 0 1 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 | |||
skipping to change at page 4, line 43 ¶ | skipping to change at page 4, line 52 ¶ | |||
packet deadline time (DT) and origination time (OTD) are represented | packet deadline time (DT) and origination time (OTD) are represented | |||
in time units determined by a scaling parameter in the routing | in time units determined by a scaling parameter in the routing | |||
header. The Network ASN (Absolute Slot Number) can be used as a time | header. The Network ASN (Absolute Slot Number) can be used as a time | |||
unit in a time slotted synchronized network (for instance a 6TiSCH | unit in a time slotted synchronized network (for instance a 6TiSCH | |||
network, where global time is maintained in the units of slot lengths | network, where global time is maintained in the units of slot lengths | |||
of a certain resolution). | of a certain resolution). | |||
The delay experienced by packets in the network is a useful metric | The delay experienced by packets in the network is a useful metric | |||
for network diagnostics and performance monitoring. Whenever a | for network diagnostics and performance monitoring. Whenever a | |||
packet crosses into a network using a different reference clock, the | packet crosses into a network using a different reference clock, the | |||
Destination Time field is updated to represent the same Destination | Deadline Time field is updated to represent the same Deadline Time, | |||
Time, but expressed using the reference clock of the interface into | but expressed using the reference clock of the interface into the new | |||
the new network. Then the origination time is the same as the | network. Then the origination time is the same as the current time | |||
current time when the packet is transmitted into the new network, | when the packet is transmitted into the new network, minus the delay | |||
minus the delay already experienced by the packet, say 'current_dly'. | already experienced by the packet, say 'current_dly'. In this way, | |||
In this way, within the newly entered network, the packet will appear | within the newly entered network, the packet will appear to have | |||
to have originated 'current_dly' time units earlier with respect to | originated 'current_dly' time units earlier with respect to the | |||
the reference clock of the new network. | reference clock of the new network. | |||
new_network_origin_time = time_now_in_new_network - current_dly | new_network_origin_time = time_now_in_new_network - current_dly | |||
The following example illustrates these calculations when a packet | The following example illustrates these calculations when a packet | |||
travels between three networks, each in a different time zone. 'x' | 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 | 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 | 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 | 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 | 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, | measured in the current timezone, and is equal to DT - OTD, that is, | |||
DT - 1000. Figure 2 uses the following abbreviations: | DT - 1000. Figure 2 uses the following abbreviations: | |||
TxA : Time of arrival of packet in the network 'x' | TxA : Time of arrival of packet in the network 'x' | |||
skipping to change at page 5, line 43 ¶ | skipping to change at page 6, line 26 ¶ | |||
v v v | v v v | |||
dly0 = 0 dly1 = T1D-OT1 dly2 = T2D-OT2 | dly0 = 0 dly1 = T1D-OT1 dly2 = T2D-OT2 | |||
= 100-50 = 1400 - 950 | = 100-50 = 1400 - 950 | |||
= 50 = 450 | = 50 = 450 | |||
OT1 = T1A-dly0 OT2 = T2A-dly1 OT3 = T3A-dly2 | OT1 = T1A-dly0 OT2 = T2A-dly1 OT3 = T3A-dly2 | |||
= 50 = 1000-50 = 5000 - 450 | = 50 = 1000-50 = 5000 - 450 | |||
= 950 = 4550 | = 950 = 4550 | |||
Figure 2: Destination Time Update example | Figure 2: Deadline Time Update example | |||
There are multiple ways that a packet can be delayed, including | There are multiple ways that a packet can be delayed, including | |||
queuing delay, MAC layer contention delay, serialization delay, and | queuing delay, MAC layer contention delay, serialization delay, and | |||
propagation delays. Sometimes there are processing delays as well. | propagation delays. Sometimes there are processing delays as well. | |||
For the purpose of determining whether or not the deadline has | For the purpose of determining whether or not the deadline has | |||
already passed, these various delays are not distinguished. | already passed, these various delays are not distinguished. | |||
5. Deadline-6LoRHE Format | 5. Deadline-6LoRHE Format | |||
0 1 2 3 | 0 1 2 3 | |||
skipping to change at page 6, line 27 ¶ | skipping to change at page 7, line 8 ¶ | |||
o Length (5 bits): Length represents the total length of the | o Length (5 bits): Length represents the total length of the | |||
Deadline-6LoRHE type measured in octets. | Deadline-6LoRHE type measured in octets. | |||
o 6LoRH Type: TBD (see Section 7) | o 6LoRH Type: TBD (see Section 7) | |||
o D flag (1 bit): The 'D' flag, set by the Sender, qualifies the | o 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 | 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 | 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 | 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 | forwarded on an exception basis, if the forwarding node is NOT in | |||
a situation of constrained resource, and if there are reasons to | a situation of constrained resource, and if there are reasons to | |||
suspect that downstream nodes might find it useful (delay | suspect that downstream nodes might find it useful (delay | |||
measurements, interpolations, etc.). | measurements, interpolations, etc.). In this circumstance, more | |||
bits are sometimes required to represent DT; see Appendix G. | ||||
o TU (2 bits) : Indicates the time units for DT and OTD fields. The | o 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 | encodings for the DT and OTD fields use the same time units and | |||
precision. | precision. | |||
* 00 : Time represented in seconds and fractional seconds | * 00 : Time represented in seconds and fractional seconds | |||
* 01 : Reserved | * 01 : Reserved | |||
* 10 : Network ASN | * 10 : Network ASN | |||
* 11 : Reserved | * 11 : Reserved | |||
o DTL (4 bits): Length of DT field as an unsigned 4-bit integer, | o DTL (4 bits): Length of DT field as an unsigned 4-bit integer, | |||
encoding the length of the field in hex digits, minus one. | encoding the length of the field in hex digits, minus one. | |||
o OTL (3 bits) : Length of OTD field as an unsigned 3-bit integer, | o 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 | 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 | OTD field is not present. The value of OTL MUST NOT exceed the | |||
value of DTL plus one. | value of DTL plus one. | |||
* For example, DTL = 0b0000 means the deadline time in the 6LoRHE | * For example, DTL = 0b0000 means the deadline time in the 6LoRHE | |||
is 1 hex digit (4 bits) long. OTL = 0b111 means the | is 1 hex digit (4 bits) long. OTL = 0b111 means the | |||
origination time is 7 hex digits (28 bits) long. | origination time is 7 hex digits (28 bits) long. | |||
o Binary Pt (6 bits) : If zero, the number of bits of the integer | o 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 | 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 | of the DT. If nonzero, the BinaryPt is a (2's complement) signed | |||
determining the position of the binary point within the value for | integer determining the position of the binary point within the | |||
the DT. | 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 | * If BinaryPt value is positive, then the number of bits for the | |||
integer part of the DT is increased by the value of BinaryPt, | 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 | and the number of bits for the fractional part of the DT is | |||
correspondingly reduced. This increases the range of DT. | correspondingly reduced. This increases the range of DT. | |||
* If BinaryPt value is negative, then the number of bits for the | * If BinaryPt value is negative, then the number of bits for the | |||
integer part of the DT is decreased by the value of BinaryPt, | 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 | and the number of bits for the fractional part of the DT is | |||
correspondingly increased. This increases the precision of the | correspondingly increased. This increases the precision of the | |||
fractional seconds part of DT. | fractional seconds part of DT. | |||
o DT Value (8..64-bit) : An unsigned integer of DTL+1 hex digits | o DT Value (4..64-bit): An unsigned integer of DTL+1 hex digits | |||
giving the Deadline Time value | giving the Deadline Time value | |||
o OTD Value (8..64-bit) : An unsigned integer of OTL hex digits | o OTD Value (4..28-bit): If present, an unsigned integer of OTL hex | |||
giving the Origination Time as a negative offset from the DT value | digits giving the Origination Time as a negative offset from the | |||
DT value | ||||
Whenever a sender initiates the IP datagram, it includes the | Whenever a sender initiates the IP datagram, it includes the | |||
Deadline-6LoRHE along with other 6LoRH information. For information | Deadline-6LoRHE along with other 6LoRH information. For information | |||
about the time synchronization requirements between sender and | about the time synchronization requirements between sender and | |||
receiver see Section 8. | receiver see Section 8. | |||
For the chosen time unit, a compressed time representation is | In order to allow fine-grained control over the setting of the | |||
available as follows. First, the application on the originating node | deadline time, it is required to allow fractional seconds to be used | |||
has to determine how many time bits are needed to represent the | in the fields for DT and OTD. This is done by specifying a binary | |||
difference between the time at which the packet is launched and the | point which allocates some of the bits for fractional times. Thus, | |||
deadline time, including the representation of fractional time units. | all such fractions are restricted to be negative powers of 2. Each | |||
That number of bits (say, N_bits) determines DTL (the length of the | point of time between OT and DT is then represented by a time unit | |||
Deadline Time (DT)) as follows: | (either seconds or ASNs) and a fractional time unit. | |||
DTL = (N_bits mod 4) | Let OT_abs, DT_abs, and CT_abs denote the true (absolute) values (on | |||
the synchronized timelines) for Origination Time and Deadline Time, | ||||
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; | ||||
The number of bits determined by DTL allows counting any number of | N = {4*(DTL+1)/2} + BinaryPt | |||
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)) | 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. | ||||
Each point of time between OT and DT is represented by a time unit | Given a value for N, the value for DT is represented in the deadline- | |||
and a fractional time unit; in this section, this combined | time format is by DT = (DT_abs mod 2^N). DT is typically represented | |||
representation is called a rational time unit (RTU). 1 RTU measures | as a positive value (even though negative modular values make sense). | |||
the smallest fractional time that can be represented between two | Also, let OT = OT_abs mod 2^N and CT = CT_abs mod 2^N, both OT and CT | |||
points of time in the epoch (i.e., within the range of interest). | also considered as non-negative values. | |||
DT - OT cannot exceed 2^(4*(DTL+1)) == 16^(DTL+1). A low value of | When the packet is launched by the originating node (Orig_Node), | |||
DTL leads to a small Epoch_Range; if DTL = 0, there will only be 16 | CT_abs == OT_abs and CT == OT. Given a particular value for N, then | |||
RTUs within the Epoch_Range (DTL) = 16^1 (for any time unit TU). The | in order for downstream nodes to detect whether or not the deadline | |||
values that can be represented in the current epoch are in the range | has expired (i.e., whether DT_abs > CT_abs), it is required that | |||
[0, (Epoch_Range(DTL) - 1)]. To minimize the required DTL, | (***) DT_abs - OT_abs < 2^N. Otherwise the ambiguity inherent in the | |||
wraparound is allowed but works naturally with the arithmetic modulo | modulus arithmetic yielding OT and DT will cause failure: one cannot | |||
Epoch_Range. | measure time differences greater than 2^N using numbers in a time | |||
segment of length less than 2^N. | ||||
By default, DTL determines t_0 in the chosen RTUs as follows: | Under the assumption (***), downstream nodes must effectively check | |||
whether or not their Current Time is later than the Deadline Time -- | ||||
but the value of the Deadline Time 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 (***) is | ||||
valid, which means that Orig_Node has to be careful to pick proper | ||||
values for DTL and for BinaryPt. | ||||
t_0 = [current_time - (current_time mod Epoch_Range (DTL))]. | 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. But 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? | ||||
Naturally, t_0 occurs at time 0 (or time 0.0000...) in the current | In order to solve this problem, a safety margin has to be provided, | |||
epoch. The last possible origination time representable in the | in addition to requiring that DT_abs - OT_abs < 2^N. The value of | |||
current epoch (counted in RTUs) is t_last = (t0 + (2^(4*(DTL+1))-1)). | this safety margin is proportional to 2^N and is determined by a new | |||
In the RTUs chosen, the current epoch resides at the underlying time | parameter, called the "SAFETY_FACTOR". Then, for safety the | |||
interval [t_0, t_last]. If DT - OT is greater than t_last - OT, then | originating node (Orig_Node) MUST further ensure that (DT_abs - | |||
wraparound within the Epoch_Range occurs naturally. In all cases, OT | OT_abs) < 2^N*(1-SAFETY_FACTOR). | |||
is represented by the value (OT mod Epoch_Range) and DT is | ||||
represented by the value (DT mod Epoch_Range). All arithmetic is to | Each intermediate node that receives the packet with the Deadline- | |||
be performed modulo (Epoch_Range(DTL)), yielding only positive values | 6LoRHE must determine whether ((CT - DT) mod 2^N) > | |||
for DT - OT. | SAFETY_FACTOR*2^N. If this test condition is not satisfied, the | |||
deadline time has expired. See Appendix G 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 10ms. | Example: Consider a 6TiSCH network with time-slot length of 10ms. | |||
Let the time units be ASNs (TU == (binary)0b10). Let the current | Let the time units be ASNs (TU == (binary)0b10). Let the current | |||
ASN when the packet is originated be 54400, and the maximum | ASN when the packet is originated be 54400, and the maximum | |||
allowable delay (max_delay) for the packet delivery be 1 second | allowable delay (max_delay) for the packet delivery be 1 second | |||
from the packet origination, then: | from the packet origination, then: | |||
deadline_time = packet_origination_time + max_delay | deadline_time = packet_origination_time + max_delay | |||
= 0xD480 + 0x64 (Network ASNs) | = 0xD480 + 0x64 (Network ASNs) | |||
skipping to change at page 14, line 8 ¶ | skipping to change at page 15, line 8 ¶ | |||
If DTL = 3 and the DT bits are again split evenly, then we can count | 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). | up to 256 seconds (in steps of 1/256 of a second). | |||
In all cases, t_0 is defined as specified in Section 5 | In all cases, t_0 is defined as specified in Section 5 | |||
t_0 = [current_time - (current_time mod (2^(4*(DTL+1))))] | t_0 = [current_time - (current_time mod (2^(4*(DTL+1))))] | |||
regardless of the choice of TU. | regardless of the choice of TU. | |||
For TU = 0b00, the time units are seconds. With DTL == 15, and | 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 | BinaryPt == 0, the epoch is (by default) January 1, 1900 at 00:00 | |||
UTC. The resolution is then (2 ^ (- 32)) seconds, which is the | UTC. The resolution is then (2 ^ (- 32)) seconds, which is the | |||
maximum possible. This time format wraps around every 2^32 seconds, | maximum possible. This time format wraps around every 2^32 seconds, | |||
which is roughly 136 years. | which is roughly 136 years. | |||
For TU = 0b10, the time units are ASNs. The start time is relative, | 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 | 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 | 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 | the ASN to wrap around. Typically, the number of hex digits | |||
allocated for TU = 0b10 would be less than 15. | allocated for TU = 0b10 would be less than 15. | |||
9. Security Considerations | 9. Security Considerations | |||
The security considerations of [RFC4944], [RFC6282] and [RFC6553] | The security considerations of [RFC4944], [RFC6282] and [RFC6553] | |||
apply. Using a compressed format as opposed to the full in-line | apply. Using a compressed format as opposed to the full in-line | |||
format is logically equivalent and does not create an opening for a | format is logically equivalent and does not create an opening for a | |||
new threat when compared to [RFC6550], [RFC6553] and [RFC6554]. | new threat when compared to [RFC6550], [RFC6553] and [RFC6554]. | |||
skipping to change at page 15, line 17 ¶ | skipping to change at page 16, line 17 ¶ | |||
critical importance. Extensive discussion of this topic can be found | critical importance. Extensive discussion of this topic can be found | |||
in [RFC7384]. | in [RFC7384]. | |||
10. Acknowledgements | 10. Acknowledgements | |||
The authors thank Pascal Thubert for suggesting the idea and | The authors thank Pascal Thubert for suggesting the idea and | |||
encouraging the work. Thanks to Shwetha Bhandari's suggestions which | encouraging the work. Thanks to Shwetha Bhandari's suggestions which | |||
were instrumental in extending the timing information to | were instrumental in extending the timing information to | |||
heterogeneous networks. The authors acknowledge the 6TiSCH WG | heterogeneous networks. The authors acknowledge the 6TiSCH WG | |||
members for their inputs on the mailing list. Special thanks to | members for their inputs on the mailing list. Special thanks to | |||
Jerry Daniel, Dan Frost (Routing Directorate) Charlie Kaufman | Jerry Daniel, Dan Frost (Routing Directorate), Charlie Kaufman | |||
(Security Directorate) Seema Kumar, Tal Mizrahi Avinash Mohan, Shalu | (Security Directorate), Seema Kumar, Tal Mizrahi, Avinash Mohan, | |||
Rajendran, Anita Varghese, and Dale Worley (Gen-ART review) for their | Shalu Rajendran, Anita Varghese, and Dale Worley (Gen-ART review) for | |||
support and valuable feedback. | their support and valuable feedback. | |||
11. References | 11. References | |||
11.1. Normative References | 11.1. Normative References | |||
[I-D.ietf-6tisch-terminology] | [I-D.ietf-6tisch-architecture] | |||
Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, | Thubert, P., "An Architecture for IPv6 over the TSCH mode | |||
"Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e", | of IEEE 802.15.4", draft-ietf-6tisch-architecture-27 (work | |||
draft-ietf-6tisch-terminology-10 (work in progress), March | in progress), October 2019. | |||
2018. | ||||
[I-D.ietf-detnet-architecture] | [I-D.ietf-detnet-architecture] | |||
Finn, N., Thubert, P., Varga, B., and J. Farkas, | Finn, N., Thubert, P., Varga, B., and J. Farkas, | |||
"Deterministic Networking Architecture", draft-ietf- | "Deterministic Networking Architecture", draft-ietf- | |||
detnet-architecture-13 (work in progress), May 2019. | detnet-architecture-13 (work in progress), May 2019. | |||
[I-D.ietf-roll-routing-dispatch] | [I-D.ietf-roll-routing-dispatch] | |||
Thubert, P., Bormann, C., Toutain, L., and R. Cragie, | Thubert, P., Bormann, C., Toutain, L., and R. Cragie, | |||
"6LoWPAN Routing Header", draft-ietf-roll-routing- | "6LoWPAN Routing Header", draft-ietf-roll-routing- | |||
dispatch-05 (work in progress), October 2016. | dispatch-05 (work in progress), October 2016. | |||
skipping to change at page 17, line 31 ¶ | skipping to change at page 18, line 31 ¶ | |||
26505-26519, May 2018. | 26505-26519, May 2018. | |||
[dotWi-SUN] | [dotWi-SUN] | |||
Harada, H., Mizutani, K., Fujiwara, J., Mochizuki, K., | Harada, H., Mizutani, K., Fujiwara, J., Mochizuki, K., | |||
Obata, K., and R. Okumura, "IEEE 802.15.4g Based Wi-SUN | Obata, K., and R. Okumura, "IEEE 802.15.4g Based Wi-SUN | |||
Communication Systems", IEICE Transactions on | Communication Systems", IEICE Transactions on | |||
Communications volume E100.B, Jan 2017. | Communications volume E100.B, Jan 2017. | |||
[I-D.ietf-6lo-backbone-router] | [I-D.ietf-6lo-backbone-router] | |||
Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 | Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 | |||
Backbone Router", draft-ietf-6lo-backbone-router-11 (work | Backbone Router", draft-ietf-6lo-backbone-router-13 (work | |||
in progress), February 2019. | in progress), September 2019. | |||
[I-D.ietf-6lo-blemesh] | [I-D.ietf-6lo-blemesh] | |||
Gomez, C., Darroudi, S., Savolainen, T., and M. Spoerk, | Gomez, C., Darroudi, S., Savolainen, T., and M. Spoerk, | |||
"IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP", | "IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP", | |||
draft-ietf-6lo-blemesh-05 (work in progress), March 2019. | draft-ietf-6lo-blemesh-06 (work in progress), September | |||
2019. | ||||
[I-D.ietf-6tisch-architecture] | ||||
Thubert, P., "An Architecture for IPv6 over the TSCH mode | ||||
of IEEE 802.15.4", draft-ietf-6tisch-architecture-24 (work | ||||
in progress), July 2019. | ||||
[I-D.ietf-detnet-use-cases] | [I-D.ietf-detnet-use-cases] | |||
Grossman, E., "Deterministic Networking Use Cases", draft- | Grossman, E., "Deterministic Networking Use Cases", draft- | |||
ietf-detnet-use-cases-20 (work in progress), December | ietf-detnet-use-cases-20 (work in progress), December | |||
2018. | 2018. | |||
[I-D.ietf-ippm-ioam-data] | [I-D.ietf-ippm-ioam-data] | |||
Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., | Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., | |||
Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, | Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, | |||
P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, | P., remy@barefootnetworks.com, r., daniel.bernier@bell.ca, | |||
"Data Fields for In-situ OAM", draft-ietf-ippm-ioam- | d., and J. Lemon, "Data Fields for In-situ OAM", draft- | |||
data-06 (work in progress), July 2019. | ietf-ippm-ioam-data-08 (work in progress), October 2019. | |||
[I-D.ietf-roll-useofrplinfo] | [I-D.ietf-roll-useofrplinfo] | |||
Robles, I., Richardson, M., and P. Thubert, "Using RPL | Robles, I., Richardson, M., and P. Thubert, "Using RPL | |||
Option Type, Routing Header for Source Routes and IPv6-in- | Option Type, Routing Header for Source Routes and IPv6-in- | |||
IPv6 encapsulation in the RPL Data Plane", draft-ietf- | IPv6 encapsulation in the RPL Data Plane", draft-ietf- | |||
roll-useofrplinfo-31 (work in progress), July 2019. | roll-useofrplinfo-31 (work in progress), August 2019. | |||
[ieee-1588] | [ieee-1588] | |||
"IEEE Standards", "IEEE Std 1588-2008 Standard for a | "IEEE Standards", "IEEE Std 1588-2008 Standard for a | |||
Precision Clock Synchronization Protocol for Networked | Precision Clock Synchronization Protocol for Networked | |||
Measurement and Control Systems", July 2008. | Measurement and Control Systems", July 2008. | |||
[Wi-SUN_PHY] | [Wi-SUN_PHY] | |||
Wi-SUN Alliance, "Wi-SUN PHY Specification V1.0", March | Wi-SUN Alliance, "Wi-SUN PHY Specification V1.0", March | |||
2016. | 2016. | |||
Appendix A. Changes from revision 04 to revision 05 | Appendix A. Changes from revision 05 to revision 06 | |||
This section lists the changes between draft-ietf-6lo-deadline-time | ||||
revisions ...-05.txt and ...-06.txt. | ||||
o Fixed the error in the test condition to determine whether or not | ||||
the deadline time has expired. | ||||
o Introduced a SAFETY_FACTOR to allow more practical determination | ||||
by intermediate nodes about whether the deadline time has expired. | ||||
o Fixed the error in DTL calculation. | ||||
o Various editorial improvements and corrections. | ||||
o Reformulated the text pertaining to wraparound in section 5 | ||||
o Added Appendix G to explain in detail the derivation of the test | ||||
condition. | ||||
o Replaced the 6tisch terminology with 6tisch architecture | ||||
o Updated the contact information of authors. | ||||
Appendix B. Changes from revision 04 to revision 05 | ||||
This section lists the changes between draft-ietf-6lo-deadline-time | This section lists the changes between draft-ietf-6lo-deadline-time | |||
revisions ...-04.txt and ...-05.txt. | revisions ...-04.txt and ...-05.txt. | |||
o Included additional relevant material in Security Considerations | o Included additional relevant material in Security Considerations | |||
regarding expected deployment scenarios and the effect of | regarding expected deployment scenarios and the effect of | |||
disclosing additional information during the travel of a packet. | disclosing additional information during the travel of a packet. | |||
o Reworked the specification for using time ranges shorter than the | o Reworked the specification for using time ranges shorter than the | |||
maximum allowed by the choice of TU, so that fewer bits are needed | maximum allowed by the choice of TU, so that fewer bits are needed | |||
to represent DT and OT. | to represent DT and OT. | |||
o Revised the figures and examples to use new parameters | o Revised the figures and examples to use new parameters | |||
o Reordered the field definitions for the Deadline-6LoRHE. | o Reordered the field definitions for the Deadline-6LoRHE. | |||
o Responded to numerous reviewer comments to improve terminology and | o Responded to numerous reviewer comments to improve terminology and | |||
editorial consistency. | editorial consistency. | |||
Appendix B. Changes from revision 03 to revision 04 | Appendix C. Changes from revision 03 to revision 04 | |||
This section lists the changes between draft-ietf-6lo-deadline-time | This section lists the changes between draft-ietf-6lo-deadline-time | |||
revisions ...-03.txt and ...-04.txt. | revisions ...-03.txt and ...-04.txt. | |||
o Replaced OT (Origination Time) field by OTD (Origination Time | o Replaced OT (Origination Time) field by OTD (Origination Time | |||
Delta), allowing a more compressed representation that needs less | Delta), allowing a more compressed representation that needs less | |||
processing during transitions between networks. | processing during transitions between networks. | |||
o Changed representation for DTL, OTL, DT, OTD. Eliminated EXP in | o Changed representation for DTL, OTL, DT, OTD. Eliminated EXP in | |||
favor of BinaryPt. | favor of BinaryPt. | |||
o Revised the figures and examples to use new parameters | o Revised the figures and examples to use new parameters | |||
o Added new section on Synchronization Aspects to supply pertinent | o Added new section on Synchronization Aspects to supply pertinent | |||
information about how nodes agree on the meaning of t=0. | information about how nodes agree on the meaning of t=0. | |||
o Responded to numerous reviewer comments to improve editorial | o Responded to numerous reviewer comments to improve editorial | |||
consistency and improve terminology. | consistency and improve terminology. | |||
Appendix C. Changes from revision 02 to revision 03 | Appendix D. Changes from revision 02 to revision 03 | |||
This section lists the changes between draft-ietf-6lo-deadline-time | This section lists the changes between draft-ietf-6lo-deadline-time | |||
revisions ...-02.txt and ...-03.txt. | revisions ...-02.txt and ...-03.txt. | |||
o Added non-normative 6LoRHE description, citing RFC 8138. | o Added non-normative 6LoRHE description, citing RFC 8138. | |||
o Specified that the Origination Time (OT) is the time that packet | o Specified that the Origination Time (OT) is the time that packet | |||
is enqueued for transmission. | is enqueued for transmission. | |||
o Mentioned more sources of packet delay. | o Mentioned more sources of packet delay. | |||
o Clarified reasons that packet MAY be forwarded if 'D' bit is 0. | o Clarified reasons that packet MAY be forwarded if 'D' bit is 0. | |||
o Clarified that DT, OT, DTL and OTL are unsigned integers. | o Clarified that DT, OT, DTL and OTL are unsigned integers. | |||
o Updated bibliographic citations, including BLEmesh and Wi-SUN. | o Updated bibliographic citations, including BLEmesh and Wi-SUN. | |||
Appendix D. Changes from revision 01 to revision 02 | Appendix E. Changes from revision 01 to revision 02 | |||
This section lists the changes between draft-ietf-6lo-deadline-time | This section lists the changes between draft-ietf-6lo-deadline-time | |||
revisions ...-01.txt and ...-02.txt. | revisions ...-01.txt and ...-02.txt. | |||
o Replaced 6LoRHE description by reference to RFC 8138. | o Replaced 6LoRHE description by reference to RFC 8138. | |||
o Added figure to illustrate change to Origination Time when a | o Added figure to illustrate change to Origination Time when a | |||
packet crosses timezone boundaries. | packet crosses timezone boundaries. | |||
o Clarified that use of 6tisch networks is descriptive, not | o Clarified that use of 6tisch networks is descriptive, not | |||
normative. | normative. | |||
o Clarified that In-Band OAM is used as an example and is not | o Clarified that In-Band OAM is used as an example and is not | |||
normative. | normative. | |||
o Updated bibliographic citations. | o Updated bibliographic citations. | |||
o Alphabetized contributor names. | o Alphabetized contributor names. | |||
Appendix E. Changes between earlier versions | Appendix F. Changes between earlier versions | |||
This section lists the changes between draft-ietf-6lo-deadline-time | This section lists the changes between draft-ietf-6lo-deadline-time | |||
revisions ...-00.txt and ...-01.txt. | revisions ...-00.txt and ...-01.txt. | |||
o Changed "SHOULD drop" to "MUST drop" a packet if the deadline is | o Changed "SHOULD drop" to "MUST drop" a packet if the deadline is | |||
passed (see Section 5). | passed (see Section 5). | |||
o Added explanatory text about how packet delays might arise. (see | o Added explanatory text about how packet delays might arise. (see | |||
Section 4). | Section 4). | |||
o Mentioned availability of time-synchronization protocols (see | o Mentioned availability of time-synchronization protocols (see | |||
Section 1). | Section 1). | |||
o Updated bibliographic citations. | o Updated bibliographic citations. | |||
o Alphabetized contributor names. | o Alphabetized contributor names. | |||
o Added this section. | o Added this section. | |||
Authors' Addresses | Appendix G. Modular Arithmetic Considerations | |||
Graphically, one might visualize the timeline as follows: | ||||
OT_abs CT_abs DT_abs | ||||
-------|-------------|-------------|------------------> | ||||
Figure 9: Absolute time line representation | ||||
In Figure 9, 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). 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 Figure 9, 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) satifies the test condition | ||||
when CT_abs == OT_abs (i.e., when the packet it 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. And, 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 9, 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. | ||||
Authors' Addresses | ||||
Lijo Thomas | Lijo Thomas | |||
C-DAC | C-DAC | |||
Centre for Development of Advanced Computing (C-DAC), Vellayambalam | Centre for Development of Advanced Computing (C-DAC), Vellayambalam | |||
Trivandrum 695033 | Trivandrum 695033 | |||
India | India | |||
Email: lijo@cdac.in | Email: lijo@cdac.in | |||
Satish Anamalamudi | Satish Anamalamudi | |||
SRM University-AP | SRM University-AP | |||
skipping to change at page 21, line 4 ¶ | skipping to change at page 24, line 19 ¶ | |||
Email: lijo@cdac.in | Email: lijo@cdac.in | |||
Satish Anamalamudi | Satish Anamalamudi | |||
SRM University-AP | SRM University-AP | |||
Amaravati Campus | Amaravati Campus | |||
Amaravati, Andhra Pradesh 522 502 | Amaravati, Andhra Pradesh 522 502 | |||
India | India | |||
Email: satishnaidu80@gmail.com | Email: satishnaidu80@gmail.com | |||
S.V.R Anand | S.V.R Anand | |||
Indian Institute of Science | Indian Institute of Science | |||
Bangalore 560012 | Bangalore 560012 | |||
India | India | |||
Email: anand@ece.iisc.ernet.in | Email: anandsvr@iisc.ac.in | |||
Malati Hegde | Malati Hegde | |||
Indian Institute of Science | Indian Institute of Science | |||
Bangalore 560012 | Bangalore 560012 | |||
India | India | |||
Email: malati@ece.iisc.ernet.in | Email: malati@iisc.ac.in | |||
Charles E. Perkins | Charles E. Perkins | |||
Futurewei | Blue Meadow Networking | |||
2330 Central Expressway | Saratoga 95070 | |||
Santa Clara 95050 | United States | |||
Unites States | ||||
Email: charliep@computer.org | Email: charliep@computer.org | |||
End of changes. 47 change blocks. | ||||
121 lines changed or deleted | 268 lines changed or added | |||
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |