"Lijo Thomas" <[email protected]> writes:
> But I foresee an interesting problem when we include the packet
> origination time. While it is straightforward when the source and
> destination belong to the same time zone, it is tricky if they belong
> to different time zones, as the origination time will be invalid once
> the packet crosses over to network segments with different time
> zones. For instance, when the packet traverses across 2 LBRs
> belonging to different 6TiSCH networks due to different ASN time
> spaces. We plan to discuss our resolution to such scenarios in our
> draft.
One general question which is not clear to me is whether this draft only
applies to 6tisch networks, or whether it applies to a broader class of
networks but is used in 6tisch networks slilghtly differently than in
other networks. (I realize that this may be clear to everyone else from
context, but I am new to the WG. But I think this point may trip up
inexperienced readers.)
--
What you say above is true, but the -00 version proposes to have the
header contain the expiration time, measured in microseconds after
ASN=0, which has the same difficulty -- if the packet is forwarded to a
different zone, the expiration time must be recalculated and stated
relative to a different epoch. And -00 describes these recalculations
in the example Case 3 in section 5. Or at least, Case 3 describes a
version of these calculations, as that text seems to assume that the
header contains a count of time until expiration, not the expiration
time relative to an epoch.
--
Though I believe that there is a lack of clarity in section 4 related to
the fact that the header contains an expiration time relative to an
epoch. The header is named "Timestamp", which is a term usually used to
describe time-of-origin. An alternative would be "Expiration", but that
word often means that the packet MUST be dropped at the indicated time.
A word I like is "Deadline", which implies that the network is required
to deliver the packet by the indicated time.
The last two sentences of the first paragraph in section 4 are
In this specification, the packet origination time is
represented in microseconds. In the case of 6tisch networks which is
explained below, the origination time is the current ASN
[I-D.vilajosana-6tisch-minimal] converted into microseconds.
This is correct, but not fundamentally important, since origination time
is not carried in the header. I wonder if you meant to say
In this specification, the packet expiration time is
represented in microseconds. In the case of 6tisch networks which is
explained below, the expiration time is the current ASN
[I-D.vilajosana-6tisch-minimal] converted into microseconds.
or maybe better
... the expiration time is measured in microseconds from ASN=0.
The following text in section 4 is correct but seems to me to not
emphasize the correct aspects of the situation
Since the maximum allowable
transmission delay is specific to each application, the expiration
time is of variable length.
Example: In a 6TiSCH network let the time-slot length be 10ms. If
the packet_origination_time = Current ASN is 200, and the
max_allowable_delay is 1 second, then:
expiration_time = packet_origination_time + max_allowable_delay
= 200*10ms + 1 second
= 3 * 10^6 microseconds
This expiration time requires 22 bits, or 3 octets, in length. The
Size is represented as x0011.
The length of the expiration time field is more affected by the ASN than
by the max_allowable_delay. More realistic is to say
Since the magnitude of ASN is variable, the expiration time is of
variable length.
Example: In a 6TiSCH network let the time-slot length be 10ms. If
the network has been operational for 2 years, the
packet_origination_time = Current ASN is 6,307,200,000, and the
max_allowable_delay is 1 second, then:
expiration_time = packet_origination_time + max_allowable_delay
= 6,307,200,000*10 ms + 1 second
= 63,072,001,000,000 microseconds
This expiration time requires 46 bits, or 6 octets, to express. The
Size is represented as x0100.
--
Section 4 describes the header as an elective 6LoRH header. As such,
the IANA Considerations should allocate a 6LoRH Type from the Elective
6LoWPAN Routing Header Type registry
(draft-ietf-roll-routing-dispatch-05, section 10.1), not the 6LoWPAN
Dispatch Page1 number space as stated in section 6.
--
In section 3, the description of the TSE field (bits 3 to 7 of the first
byte) does not agree with the description in
draft-ietf-roll-routing-dispatch-05, which specifies that these bits
must be the length of the header. Technologically, the length of the
expiration time header must be encoded in a way independent of the
header type, as the header is elective and nodes that do not understand
it must be able to ignore it.
--
In section 1, "RPI" is used in one place where "RPL" seems to be intended.
Dale
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
