Re: [Ntp] ntp over ptp

[Doug Arnold <[e-mail]>]

Now that there is a fair number of switches and routers that support PTP, several standards organizations have specified or proposed specifications for timing protocols that use PTP messages, including the PTP reserved EtherType, for new timing protocols that are not PTP.  The IEEE 1588 Working Group has had several discussions about this and there is a great deal of concern that the behavior of PTP capable equipment receiving messages from quasi PTP protocols is uncertain, and therefore makes PTP less reliable.

I have no objection to people defining new timing protocols, or to people copying aspects of PTP, but they should not use the reserved PTP EtherType in their new protocol.  The EtherType is the one thing that PTP implementations should be able to count on.

Doug


________________________________
From: Miroslav Lichvar <[e-mail]>
Sent: Tuesday, March 12, 2024 11:43 AM
To: Doug Arnold <[e-mail]>
Cc: NTP WG <[e-mail]>; Rodney Cummings <[e-mail]>
Subject: Re: [Ntp] ntp over ptp

On Mon, Mar 11, 2024 at 11:20:42PM +0000, Doug Arnold wrote:
> The document draft-ietf-ntp-over-ptp-02 describes a mechanism to allow ntp to take advantage of PTP only hardware timestamping ability.  The mechanism uses only the (unicast versions of) Delay Request and Delay Response messages to transport the ntp request and response messages respectively.

NTP over PTP uses only the delay request message type. Delay responses
are not event messages, so they wouldn't trigger a hardware timestamp.
PTPv2.0 is used for better compatibility as PTPv2.1 is not recognized
by some hardware, e.g. the Broadcom NIC on Raspberry Pi CM4.

> The behavior of the protocol is that nodes in the TimeTransmitter state shall send Sync and Announce messages as well as answering delay response messages.  I believe that the document should be expanded to describe this requirement.  It would also be good to point out that the external port configuration option of subclause 17.6 is being used, as well as the end-to-end delay measurement mechanism.

PTP is used just as a transport for NTP. Valid PTP messages are
formed, but the hosts don't follow the E2E delay mechanism. There are
no announce messages or sync messages, no PTP states or any
interaction with real PTP clocks. It's strictly unicast messaging.
PTP and NTP-over-PTP can coexist in the same network each doing its
own thing. A single host can support both as long as different domain
numbers are used.

> This is starting to sound like a PTP profile needs to be defined to list these requirements.  The  rules for that are found in subclause 20.3 and states:
>
>
> "A PTP Profile should define the following:
>
>   *   Which of the best master clock algorithm options (see 9.3.1) is to be implemented

There is no BCMA. None doesn't look like an option that would meet the
requirements specified in that section.

>   *   Which of the configuration management mechanisms (see 8.1.4.3) is to be implemented

There is no PTP state to be managed.

>   *   Which of the path delay mechanisms, delay request-response (see 11.3) or peer-to-peer delay

None of the two. It's a custom delay mechanism which measures both
delay and offset in one exchange.

> A PTP Profile shall extend the standard only in the following ways:
>
>   *   a) The use of the TLV mechanism of 14.3
>
>   *   b) The specification of an optional best master clock algorithm (see 9.3.1)
>
>   *   c) The specification of an optional management mechanism (see 8.1.4.3)
>
>   *   d) The provisions of 20.2.2
>
>   *   e) The provisions of 7.3"

None of those seem to apply to NTP over PTP if I'm reading that right.

--
Miroslav Lichvar