Requested revision
| Standard: | IEEE802.1AS-2020 | Clause: | 10.2.5.8 |
| Clause title: | meanLinkDelay | ||
Rationale for revision
The calculation of meanLinkDelay may result in negative values if very short
cables are used and link delay compensation is not accurate, or even because of
random time stamping errors.
With existing Ethernet technologies, the delay inside of PHY chips is not
always constant and may very between link establishments.
The variable meanLinkDelay defined in clause 10.2.5.8, which is used in the
state machines, is of type UScaledNS, which is an unsigned data type.
If computePropTime (11.2.19.3.4) gives negative results, these will translate
to very large unsigned values for meanLinkDelay, which in turn may result in
the link not being as-capable, cf. 11.2.2.b). This will change the port role
and possibly trigger a reconfiguration of the synchronization tree.
The managed objects that correspond to the variable (14.8.8 and 14.16.6)
are of signed type TimeInterval (this is consistent with IEEE 1588-2019).
IEC/IEEE60802 explicitly points out that negative values for measurements of
meanLinkDelay may occur.
Even though following the reasoning set forth in the note of table 11-1, a
negative threshold is not required, it may still be worthwhile considering the
introduction of a second, negative threshold, to detect misbehaving devices. A
possible default value could be -300 ns (this is the same margin used to
determine the default value of 800ns for 100BASE-TX and 1000BASE-T links).
I discussed the topic with Geoff Garner, he suggested to submit a maintenance item:
<<<QUOTE>>>
(…), regarding the inconsistency between the managed object (TimeInterval) and
global variable (UScaledNs), in 802.1AS-2011, the corresponding variable and
managed object, neighborPropDelay, both had data type UScaledNs. This was
changed to TimeInterval for the managed object (as well as changing the name to
meanLinkDelay) in 802.1AS-2020 because it was desired to have the managed
object be of shorter length. Second, at the time the possibility of negative
values was not considered. However, when the Annex D/60802 algorithms were
later considered, it was realized that negative values can occur. At this time,
the data type for meanLinkDelay of 10.2.5.8 of 802.1AS-2020 should have been
changed to ScaledNs, in 802.1ASdm. The fact that this was not done was an
oversight. This should be corrected in the upcoming 802.1AS-2020 Revision.
To call attention to this, a maintenance item to make this change could be
submitted.
<<<END QUOTE>>>
Proposed text
In 10.2.5.8, replace "The data type for meanLinkDelay is UScaledNs"
with
"The data type for meanLinkDelay is ScaledNs"
In table 11-1:
Consequently, the value in the second row of table 11-1 should be changed to
0x7FFFFFFF, and the last sentence of the note in the table be changed to:
"In this case, meanLinkDelayThresh is set to the largest possible
positive value (i.e., in binary notation a zero followed by all 1s)."
In clause 14.8.8, 14.8.9, 14.16.6 and 14.16.7:
Remove the note.
Impact on existing networks
As the variable is not accessible from outside of an implementation,
and the managed object is already of signed type, the impact on existing
networks should be none.
Potentially, network management tools may not be ready to consider negative
values for the managed object, this is beyond the requester’s expertise.
Originator
| Name: | Martin Ostertag | Email: | martin.ostertag@zhaw.ch |
| Affiliation: | ZHAW Zurich University of Applied Sciences | ||
| Submitted: | 2024-09-16 | ||