Internet-Draft NTP Over PTP June 2023
Lichvar Expires 24 December 2023 [Page]
Workgroup:
Internet Engineering Task Force
Internet-Draft:
draft-ietf-ntp-over-ptp-00
Published:
Intended Status:
Standards Track
Expires:
Author:
M. Lichvar
Red Hat

NTP Over PTP

Abstract

This document specifies a transport for the Network Time Protocol (NTP) client-server and symmetric modes using the Precision Time Protocol (PTP) to enable hardware timestamping on hardware that can timestamp PTP messages but not NTP messages.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 24 December 2023.

Table of Contents

1. Introduction

The Precision Time Protocol (PTP) [IEEE1588] was designed for highly accurate synchronization of clocks in a network. It relies on hardware timestamping supported in network devices (e.g. interface controllers, switches, and routers) to eliminate the impact of processing and queueing delays on PTP measurements.

PTP was originally designed for multicast communication. Later was added a unicast mode, which can be used in larger networks with partial on-path PTP support (e.g. telecom profiles G.8265.1 and G.8275.2).

The Network Time Protocol [RFC5905] does not rely on hardware timestamping support, but implementations can use it if it is available to avoid the impact of processing and queueing delays, similarly to PTP. The client-server mode of NTP is functionally similar to the PTP unicast mode.

An issue for NTP is hardware that can specifically timestamp only PTP packets. This limitation comes from a hardware design which can provide receive timestamps only at a limited rate and not the maximum rate supported by the network interface. To avoid missing receive timestamps when the interface is receiving other traffic at a high rate, a filter needs to be implemented in the hardware to inspect each received packet and capture a timestamp only for packets that need it.

The hardware filter can be usually configured for specific PTP transport (e.g. UDPv4, UDPv6, 802.3) and sometimes even the PTP message type (e.g. sync message or delay request) to further reduce the rate of timestamps on the server or client side, but it cannot be configured to timestamp NTP messages on the UDP port 123.

This document specifies a new transport for NTP to enable the PTP-specific timestamping support. It adds a new extension field (TLV) for PTP to contain NTP messages.

NTP over PTP does not require any PTP clocks to be present in the network. It does not disrupt their operation if they are present. Hosts in the network can operate as PTP clocks and NTP servers, clients, or peers using NTP over PTP at the same time.

The specification does not take advantage of the PTP correctionField modified by PTP transparent clocks as their support for the unicast mode seems to be rare or nonexistent.

The client/server mode of NTP, even if using the PTP transport, has several advantages when compared to the PTP unicast mode:

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

2. PTP transport for NTP

A new TLV is defined for PTP to contain NTP messages in the client (3), server (4), and symmetric modes (1 and 2). Using other NTP modes in the TLV is not specified. Any transport specified for PTP that supports unicast messaging can be used for NTP over PTP, e.g. UDP on IPv4 and IPv6.

The type value of the NTP TLV is TBD. The TLV contains the whole NTP message as would normally be the UDP payload, without any modifications. The TLV does not propagate through boundary clocks.

If the UDP transport is used for PTP, the UDP source and destination port numbers MUST be the PTP event port (319). If the client implemented port randomization [RFC9109], requests and/or responses would not get a hardware receive timestamp due to the filter matching only the PTP port.

The NTP TLV MUST be included in a PTP delay request message. The originTimestamp field and all fields of the header SHOULD be zero, except:

An NTP client or peer using the PTP transport sends NTP requests contained in PTP delay requests as the NTP TLV.

An NTP server or peer receiving NTP requests over the PTP transport MUST check for the domainNumber of 123 and the NTP TLV. Its responses to these requests MUST be contained in PTP delay requests as the NTP TLV. It MUST NOT respond with PTP delay responses, or any other PTP messages.

If a PTP clock receives an NTP-over-PTP request, it will not recognize the domain number and ignore the message. If it responded to messages in the domain (e.g. due to misconfiguration), it would send a delay response (to port 320 if using the UDP transport), which would be ignored by the client.

Any authenticator fields included in the NTP messages MUST be calculated only over the NTP message following the header of the NTP TLV.

Receive and transmit timestamps contained in the NTP messages SHOULD NOT be adjusted for the beginning of the NTP data in the PTP message. They SHOULD still correspond to the ending of the reception and beginning of the transmission of the whole frame (e.g. start frame delimiter in an Ethernet frame).

Any modifications of the correctionField made by potential one-step end-to-end transparent clocks in the network SHOULD be ignored by the server and client.

3. Acknowledgements

The author would like to thank Martin Langer for his useful comments.

4. IANA Considerations

This memo includes no request to IANA.

5. Implementation Status - RFC EDITOR: REMOVE BEFORE PUBLICATION

This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in RFC 7942. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.

According to RFC 7942, "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".

5.1. chrony

chrony (https://chrony.tuxfamily.org) has experimental support for PTP-over-NTP in its development branch. As the type of the NTP TLV, it uses 0x2023 from the experimental "do not propagate" range.

It was tested on Linux with the following network controllers, which have hardware timestamping limited to PTP packets:

6. Security Considerations

The PTP transport prevents NTP clients from randomizing their source port. It has no other impact on security of NTP.

7. References

7.1. Normative References

[IEEE1588]
Institute of Electrical and Electronics Engineers, "IEEE std. 1588-2019, "IEEE Standard for a Precision Clock Synchronization for Networked Measurement and Control Systems."", , <https://www.ieee.org>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC5905]
Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, , <https://www.rfc-editor.org/info/rfc5905>.

7.2. Informative References

[RFC8915]
Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R. Sundblad, "Network Time Security for the Network Time Protocol", RFC 8915, DOI 10.17487/RFC8915, , <https://www.rfc-editor.org/info/rfc8915>.
[RFC9109]
Gont, F., Gont, G., and M. Lichvar, "Network Time Protocol Version 4: Port Randomization", RFC 9109, DOI 10.17487/RFC9109, , <https://www.rfc-editor.org/info/rfc9109>.

Author's Address

Miroslav Lichvar
Red Hat
Purkynova 115
612 00 Brno
Czech Republic