[Ntp] ntp over ptp

[Doug Arnold <[e-mail]>]

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.

This is actually very clever.  However, IEEE 1588-2019, subclause 7.3.1,  has this to say about unicast ptp:


"Although the standard is written based on the multicast model, an implementation may be created based on

a unicast model, or on a mixed multicast/unicast model, provided that the behavior of the protocol is

preserved.


Unless otherwise specified in this standard, the specifications for unicast communication are the same as

the specifications for multicast communication."


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.


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
  *   Which of the configuration management mechanisms (see 8.1.4.3) is to be implemented

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

  *   (see 11.4) is to be implemented

  *   The range and default values of all PTP configurable attributes and data set members subject to the

  *   restrictions of 8.1.2.1.3

  *   The transport mechanisms required, permitted, or prohibited

  *   The PTP Instance types required, permitted, or prohibited

  *   The options required, permitted, or prohibited, and any parameter values associated with these

  *   options

  *   Uncertainty specifications appropriate to the evaluation of whether traceability (see 3.1.80), to a

  *   primary reference is achieved for time (see 8.2.4.6) and for frequency (see 8.2.4.7)

  *   The value of the observation interval (tau) used for variance measurement (see 7.6.3.2)


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"

Regards,
Doug