The link delay that media converters and hubs introduce is measured by their two neighbors with a peer delay data exchange.
This method assumes that the link delay is symmetrical and does not vary in function of the event message transmitted. This is usually the case with cut-through media converters.
However, media converters and hubs that use store-and-forward would delay Sync and Pdelay_Req/Pdelay_Resp messages differently since the Sync messages are shorter by 10 octets than the Pdelay_Req/Pdelay_Resp.
Therefore, the neighbors of the media converter calculate the link delay with an error of 800 ns at 100 Mbit/s.
The peers cannot know that a media converter exists in the middle and therefore cannot compensate for the delay, which is in addition dependent on the line speed.
Proposal
Media converters shall delay all event messages (Sync, Pdelay_Req and Pdelay_Resp by the same amount of time, with an inaccuracy of less than 50 ns and an asymmetry of less than 25 ns.
Media converters that operate with store-and-forward shall append to Sync messages that have a messageLengh of 44 a 10 octet TLV so that they receive the same messageLength=54 as Pdelay_Req or Pdelay_Resp messages.
The format of this TLV is (experimentally):
1) tlvType: 2 octets (to be allocated by IEEE-RA)
2) lengthField: 2 octets = 6
3) accVariance: 2 octets
4) accMeanError: 2 octets
5) hopCount: 1 octet
6: reserved: 1 octet
Discussion
Created
Status
The padding TLV is under discussion in P1588. Until the IEEE 1588:201x is published, this Tissue is put "on hold".
12 Mar 18
Future Improvement
As there is no agreed text yet under "final proposal", this Tissue is reverted to "red".
Why should the padding TLV be optional in IEC/IEEE 61850-9-3?
It appears that IEEE 1588-201x says "When the peer-to-peer delay mechanism is used, a PAD TLV of length 10 shall be appended to Sync messages". Thus, making this optional in 9-3 would not be compliant to 1588-201x, would it?
13 Feb 18
Discussion (red)
Receivers of sync messages (for example slave-only devices) cannot be expected to read the PICS of the upstream device. The PAD TLV described in the 23-January-2018 discussion SHALL be appended to the SYNC message from any device accepts any store-and-forward media converters in the link path. All receivers of SYNC message must allow for the PAD TLV to exist.
24 Jan 18
Ballot Period
IEEE 1588-201x D1.2 §16.13 2) says:
When the peer-to-peer delay mechanism is used, a PAD TLV of length 10 shall be appended to Sync messages. No adjustment of Pdelay_Req or Pdelay_Resp message lengths shall be made. The result is
that the messageLength attribute for Sync, Pdelay_Req, and Pdelay_Resp messages have the same value.
The PAD TLV is defined in:
IEEE 1588-201x D1.2 § 14.3 PAD TLV (optional)
14.3.1 General
The PAD TLV should be used whenever a PTP Profile specifies an increase of the length of any PTP message beyond the length of the PTP message specified in clause 13. The minimum length increment is 4 octets which occurs with a pad length of 0 octets.
Each of the N pad octets shall have the value 0x00. The pad octets shall not be used for any purpose other than increasing the length of the PTP message to which the PAD TLV is attached.
The TlvType shall be (PAD) = 000C.
So, in IEC/IEEE 61850-9-3, the padding TLV should be optional and indicated in the PICS. I guess all GM manufacturers will introduce it so after a while network engineers can count on it and it can become mandatory at the next maintenance cycle.
Especially, if a large time error takes place at insertion, the network engineer should check media converters as a possible cause.
In addition, this raises the question on how a clock shall be certifed when it depends for operation on components that are not part of the testing. For instance, the certificate could be issued under the condition that a media converter of a certified type shall be used.
If there is a need to transport useful data, then another 10-octet TLV could be used, but it cannot be a profile-specific TLV since the minimum length of such specific TLV is 10 octets, there is no useful data.
23 Jan 18
Ballot Period
It is not possible to disallow store-and-forward media converters since this is the standard method of 1 Gbit/s to 100 Mbit/s adaptation.
Not allowing this means that one cannot use Ethernet adapters such as SFP.
This has already been changed in IEEE 1588- 201x.
19 Jan 18
Ballot Period
The proposal is needlessly complex. I propose to dis-allow any store-and-forward device unless it implements the peer-to-peer transparent clock mechanism. In other words, if residence time is significant then the "normal" compensation mechanism shall be used.
31 Dec 17
Discussion (red)
IEEE P1588 accepted the proposal but with an all zero content for the PAD_TLV.
It is not the media converter that has to pad the TLV, but the master port.
No proposal has been received how to use the contents of the PAD_TLV.
Proposed text:
C.7.9.2 Alignment of event message length (L2P2P only)
A master port using peer-to-peer should send Sync messages with the same length as the previously received Pdelay_Req from the peer. If needed, the Sync messages may be extended by the PAD_TLV specified in IEC 61588:2018.
NOTE: The calculation of the peer link delay assumes that the Sync, Pdelay_Req and Pdelay_Resp messages are delayed by the same amount. To ensure this in the presence of media converters operating with store-and-forward, all event messages should have the same size. However, according to IEC 61588:2009, Sync messages are shorter than Pdelay_Req/Pdelay_Resp messages by 10 octets, so padding is required to align their sizes. IEC 62439-3:2016 does not prohibit appending other TLVs after Sync or Pdelay_Req/Pdelay_Resp, e.g. for security.
Clocks that align the length of event messages are identified in their PICS by SYNC_ALIGNED, True/False, optional.