1595   Delay Measurment with clocks in different domains

Created: 26 Jul 2017

Status: Discussion (red)

Part: Part 9-3 (Precision Time Protocol Profile)

Links:

Page: 10

Clause: 7.5

Paragraph:

Category: Issue for edition 2 of this part

Issue

IEEE 1588 defines that transparent clocks have a primary time domain from which they draw their frequency reference (syntonization) but IEEE 1588 §10.1 opens the possibility of TCs syntonized to multiple domains, which created confusion. IEEE 1588 does not specify how TCs should behave when receiving PTP messages from different domains.

Proposal

Transparent clocks may be syntonized to several domains or to only one (IEEE Std 1588 10.1).
TCs supporting multiple domains are out-of-scope.

A transparent clock using end-to-end delay measurement shall responds to a Pdelay_Req message with a domain number with a Pdelay_Resp with the same domain number even if it is not its primary time domain.

A transparent clock shall send Pdelay_Req messages with its own primary domain number. A transparent clock shall use for the time correction in all domains the value obtained by the Pdelay exchange with its own primary domain number.

Discussion Created Status
SC65C WG15 decided that a dynamic change of syntonization (primary) domain is not needed. The network engineer must ensure that all TCs are connected to an operating domain, the clock of another domain cannot be used as a redundancy.
The requirement that a TC shall answer to a Pdelay_Req on a certain domain with a Pdelay_Resp on the same domain is already specified
in IEC 61588:2009, 11.4.3.b.5. All clock ports respond to a Pdelay_Req message with a given domainNumber with a Pdelay_Resp message with the domainNumber of the Pdelay_Req message, even if it differs from their own primary domain. This is valid for all ports, not only TCs ports.
A TC according to IEC 61588:2009 shall use the result of the link delay measurement for all domains since it has no table of domains. It is in principle not needed to specify this, as it is evident, but a reminder will be inserted. 		19 Apr 18 Ballot Period
As there is no agreement yet on a text as final proposal, this Tissue is reverted to "red".
Parts of the proposed text seem to repeat what is already specified by 1588. A new text should be proposed for discussion, covering the needed clarification and/or addition to 1588.
13 Feb 18 Discussion (red)
Yes, it is peer-to-peer.
OK we can remove the change of primary domain. 		30 Jan 18 Ballot Period
In following sentence:
“A transparent clock using end-to-end delay measurement shall responds to a Pdelay_Req message with a domain number with a Pdelay_Resp with the same domain number even if it is not its primary time domain.”

- “end-to-end delay measurement” should be replaced with “peer-to-peer delay measurement”

Discussion issue from 29 Dec 17 (Hubert Kirrmann)
?- We disagree with the proposal to dynamically adjust the TCs primary domain number based on which domain valid Sync message is detected. If valid Sync is not detected at the primary domain, we prefer an easy solution of TC acting as unsyntonized TC.
- Other proposal seem to match the IEEE 1588 standard, thus it’s not clear why they are presented as a proposal.
 30 Jan 18 Ballot Period
19 Jan 18 Ballot Period
Proposed text is:
C.7.5.2 TC with multiple domain support (for L2P2P only)
A TC port using peer-to-peer delay measurement shall
- respond to a Pdelay_Req message with a Pdelay_Resp with the domain number of the Pdelay_Req.
- send Pdelay_Req messages with its own primary domain number.
- use for the time correction in all domains the value obtained by the Pdelay exchange with its own primary domain number.
A TC that detects no Sync messages on its configured domain, but detects Sync messages on at least another domain shall set its primary domain to the detected domain that offers the best clock quality.
A TC that supports this functionality is identified by the PICS “TC_MULTIDOMAIN”
29 Dec 17 Discussion (red)
Proposed text is:
C.7.6 Multidomain TCs.
A TC port using end-to-end delay measurement shall respond to a Pdelay_Req message with a Pdelay_Resp with the domain number of the Pdelay_Req message.
A TC port shall send Pdelay_Req messages with its own primary domain number.
A TC port shall use for the time correction in all domains the value obtained by the Pdelay exchange with its own primary domain number.
A TC that detects no Sync messages on its configured domain, but detects Sync messages on at least another domain shall set its primary domain to the detected domain that offers the best clock quality. 		27 Dec 17 Discussion (red)
No change is needed because syntonization by transparent clocks is not an issue in real systems because of short residence times in 100 MB switches.

For example, if MESSAGE2 is delayed by another maximal length MESSAGE1, residence time of MESSAGE2 will be about 150 microseconds. If the syntonization error is 100 PPM (an outlandishly large value), then the residence time will be measured as 150.015 microseconds (a 15 nanosecond error) which is well within 9-3 limits. 		23 Dec 17 Triage
The second paragraph of the proposal should state "peer-to-peer" rather than "end-to-end".
14 Aug 17 Triage

 

Privacy | Contact | Disclaimer

Tissue DB v. 24.12.4.1