Internet Engineering Task Force (IETF) M. Lichvar
Request for Comments: 10030 Red Hat
Category: Standards Track August 2026
ISSN: 2070-1721
This document specifies a transport for the client-server and symmetric modes of the Network Time Protocol (NTP) that encapsulates NTP messages in messages of the Precision Time Protocol (PTP). This transport enables hardware timestamping in network interface controllers (NICs) that can timestamp only PTP messages and delay corrections in PTP transparent clocks.
この文書は、NTP メッセージを PTP (Precision Time Protocol) のメッセージにカプセル化する、ネットワーク タイム プロトコル (NTP) のクライアント/サーバーおよび対称モードのトランスポートを指定します。このトランスポートにより、ネットワーク インターフェイス コントローラー (NIC) でのハードウェア タイムスタンプが有効になり、PTP メッセージのみにタイムスタンプを設定し、PTP 透過クロックでの修正を遅延させることができます。
This is an Internet Standards Track document.
これはインターネット標準化トラックの文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準の詳細については、RFC 7841 のセクション 2 を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc10030.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc10030 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。この文書から抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
1.1. Comparison with PTP
1.2. Requirements Language
2. PTP Transport for NTP
3. Network Correction Extension Field
4. IANA Considerations
4.1. New IANA PTP TLV Subtypes Registry
4.2. NTP Extension Field Registration
5. Security Considerations
6. References
6.1. Normative References
6.2. Informative References
Acknowledgements
Author's Address
The Precision Time Protocol (PTP) [IEEE1588-2019] was designed for highly accurate synchronization of clocks in local networks. It relies on hardware timestamping support in all network devices involved in the synchronization (e.g., network interface controllers (NICs), switches, and routers) to eliminate the impact of software, processing, and queueing delays on the accuracy of offset and delay measurements.
Precision Time Protocol (PTP) [IEEE1588-2019] は、ローカル ネットワークにおけるクロックの高精度な同期を目的として設計されました。これは、同期に関与するすべてのネットワーク デバイス (ネットワーク インターフェイス コントローラー (NIC)、スイッチ、ルーターなど) でのハードウェア タイムスタンプのサポートに依存し、ソフトウェア、処理、およびキュー遅延がオフセットと遅延の測定の精度に及ぼす影響を排除します。
PTP was originally designed for multicast communication. Later, support for unicast messaging was added, which is useful in larger networks with partial on-path PTP support (e.g., telecom profiles G.8265.1 [G8265-1] and G.8275.2 [G8275-2]).
PTP はもともとマルチキャスト通信用に設計されました。その後、ユニキャスト メッセージングのサポートが追加されました。これは、部分的なオンパス PTP サポート (電気通信プロファイル G.8265.1 [G8265-1] および G.8275.2 [G8275-2]) を備えた大規模ネットワークで役立ちます。
The Network Time Protocol (NTP) [RFC5905] does not rely on hardware timestamping support, but implementations can use it if it is available to avoid the impact of software, processing, and queueing delays, similarly to PTP. When comparing PTP with the timing modes of NTP, PTP is functionally closest to the NTP broadcast mode.
Network Time Protocol (NTP) [RFC5905] はハードウェアのタイムスタンプのサポートに依存しませんが、PTP と同様に、ソフトウェア、処理、およびキューの遅延の影響を回避するために、利用可能な場合は実装でそれを使用できます。PTP と NTP のタイミング モードを比較すると、PTP は機能的に NTP ブロードキャスト モードに最も近くなります。
An issue for NTP is hardware that can specifically timestamp only PTP packets. This limitation comes from a hardware design that can provide receive timestamps only at a limited rate instead of the maximum rate possible at the network link speed. To avoid missing receive timestamps when the interface is receiving other traffic at a high rate, a filter is implemented in the hardware to inspect each received packet and capture a timestamp only for packets that need it.
NTP の問題は、PTP パケットのみに特別にタイムスタンプを付けることができるハードウェアです。この制限は、ネットワーク リンク速度で可能な最大レートではなく、限られたレートでのみ受信タイムスタンプを提供できるハードウェア設計に起因します。インターフェイスが他のトラフィックを高速で受信しているときに受信タイムスタンプの欠落を避けるために、各受信パケットを検査し、必要なパケットのみのタイムスタンプをキャプチャするフィルターがハードウェアに実装されています。
The hardware filter can be usually configured for specific PTP transports (e.g., UDP over IPv4, UDP over IPv6, and 802.3) and sometimes even the PTP message type (e.g., sync message or delay request) to further reduce the timestamping rate on the server or client side in the case of multicast messaging, but it typically cannot be configured to timestamp NTP messages sent to the UDP port 123.
ハードウェア フィルタは、通常、特定の PTP トランスポート (IPv4 上の UDP、IPv6 上の UDP、802.3 など) に対して構成でき、マルチキャスト メッセージングの場合にサーバーまたはクライアント側でのタイムスタンプ レートをさらに下げるために、PTP メッセージ タイプ (同期メッセージや遅延要求など) に対しても構成できますが、通常は、UDP ポート 123 に送信される NTP メッセージにタイムスタンプを付けるように構成することはできません。
Another issue for NTP is missing hardware support in network switches and routers. With PTP, the devices operate as either boundary clocks or transparent clocks. Boundary clocks are analogous to NTP clients that work also as servers for other clients. Transparent clocks are much simpler. They only measure the delay in the forwarding of PTP packets and write this delay to the correction field of either the packet itself (one-step mode) or a later packet in the PTP exchange (two-step mode). Transparent clocks are specific to the PTP delay mechanism used in the network, either end to end (E2E) or peer to peer (P2P).
NTP のもう 1 つの問題は、ネットワーク スイッチやルーターでハードウェア サポートが欠落していることです。PTP を使用すると、デバイスは境界クロックまたは透過クロックとして動作します。境界クロックは、他のクライアントのサーバーとしても機能する NTP クライアントに似ています。透明な時計ははるかにシンプルです。PTP パケットの転送における遅延のみを測定し、この遅延をパケット自体 (1 ステップ モード) または PTP 交換内の後のパケット (2 ステップ モード) のいずれかの修正フィールドに書き込みます。透過クロックは、エンドツーエンド (E2E) またはピアツーピア (P2P) のいずれかのネットワークで使用される PTP 遅延メカニズムに固有です。
This document specifies a new transport for NTP to enable hardware timestamping on NICs that can timestamp only PTP messages and to take advantage of one-step E2E PTP unicast transparent clocks. It adds a new type-length-value (TLV) for PTP to contain NTP messages and a new extension field for NTP to provide clients and peers with the correction of their NTP requests from transparent clocks. The NTP broadcast mode is not supported.
この文書では、PTP メッセージのみをタイムスタンプできる NIC 上でハードウェア タイムスタンプを有効にし、ワンステップ E2E PTP ユニキャスト トランスペアレント クロックを利用できるようにするための、NTP の新しいトランスポートを指定します。これは、NTP メッセージを含めるための PTP の新しいタイプ-長さ-値 (TLV) と、クライアントとピアに透過的なクロックからの NTP 要求の修正を提供するための NTP の新しい拡張フィールドを追加します。NTP ブロードキャスト モードはサポートされていません。
The use of PTP messages requires that protocol rules of IEEE 1588 [IEEE1588-2019] be followed. NTP over PTP does not require other PTP clocks to be present in the network. It does not disrupt their operation if they are present. If the network uses one-step E2E transparent clocks, NTP clients and peers using PTP for transport can reach the same or better accuracy as PTP clocks using PTP for synchronization. Hosts in a network can use PTP for synchronization in one domain and transport of NTP messages in another domain at the same time.
PTP メッセージを使用するには、IEEE 1588 [IEEE1588-2019] のプロトコル規則に従う必要があります。NTP over PTP では、ネットワーク内に他の PTP クロックが存在する必要はありません。それらが存在しても、その動作は中断されません。ネットワークがワンステップ E2E トランスペアレント クロックを使用している場合、トランスポートに PTP を使用する NTP クライアントおよびピアは、同期に PTP を使用する PTP クロックと同等以上の精度を達成できます。ネットワーク内のホストは、PTP を使用して、あるドメインでの同期と別のドメインでの NTP メッセージのトランスポートを同時に行うことができます。
The client-server mode of NTP, even with the PTP transport, has multiple advantages over PTP using multicast or unicast messaging:
NTP のクライアント/サーバー モードには、PTP トランスポートを使用する場合でも、マルチキャストまたはユニキャスト メッセージングを使用する PTP に比べて複数の利点があります。
* NTP is more secure. Existing security mechanisms specified for NTP such as Network Time Security [RFC8915] still work over the PTP transport. It is more difficult to secure PTP against delay attacks because the sync message is not an immediate response to a client request. The PTP unicast mode allows an almost-infinite traffic amplification, which can be exploited for denial-of-service attacks and can only be limited by security mechanisms requiring client authentication.
* NTP の方が安全です。Network Time Security [RFC8915] など、NTP に指定されている既存のセキュリティ メカニズムは、PTP トランスポート上でも引き続き機能します。同期メッセージはクライアント要求に対する即時の応答ではないため、遅延攻撃から PTP を保護することはさらに困難です。PTP ユニキャスト モードでは、ほぼ無限のトラフィック増幅が可能ですが、これはサービス拒否攻撃に悪用される可能性があり、クライアント認証を必要とするセキュリティ メカニズムによってのみ制限できます。
* NTP is more resilient to failures. Each client can use multiple servers and detect failed sources in its source selection. In PTP, a single hardware or software failure can disrupt the whole PTP domain. Multiple independent domains have to be used to handle any failure.
* NTP は障害に対する回復力が高くなります。各クライアントは複数のサーバーを使用し、ソース選択で失敗したソースを検出できます。PTP では、単一のハードウェアまたはソフトウェアの障害により、PTP ドメイン全体が中断される可能性があります。障害を処理するには、複数の独立したドメインを使用する必要があります。
* NTP is better suited for synchronization in networks that do not have full on-path PTP support or where timestamping errors do not have a symmetric distribution (e.g., due to sensitivity to the network load). NTP does not assume network delay is constant and the rate of measurements in opposite directions is symmetric. It can filter the measurements more effectively and is not sensitive to asymmetrically distributed network delays and timestamping errors. PTP has to measure the offset and delay separately to enable multicast messaging, which is needed to reduce the transmit timestamping rate.
* NTP は、オンパス PTP を完全にサポートしていないネットワークや、タイムスタンプ エラーが対称的に分布していないネットワーク (ネットワーク負荷の影響を受けやすいためなど) での同期に適しています。NTP は、ネットワーク遅延が一定であり、反対方向の測定レートが対称であることを前提としていません。測定値をより効果的にフィルタリングでき、非対称に分散されたネットワーク遅延やタイムスタンプエラーの影響を受けません。PTP は、送信タイムスタンプ レートを下げるために必要なマルチキャスト メッセージングを有効にするために、オフセットと遅延を個別に測定する必要があります。
* NTP needs fewer messages to get the same number of timestamps. It uses less network bandwidth than PTP using unicast messaging.
* NTP は、同じ数のタイムスタンプを取得するために必要なメッセージの数を減らします。ユニキャスト メッセージングを使用する PTP よりも使用するネットワーク帯域幅が少なくなります。
* NTP provides clients with an estimate of the maximum error of the clock (root distance).
* NTP はクライアントにクロックの最大誤差 (ルート距離) の推定値を提供します。
The disadvantage of NTP is that the transmit timestamping rate increases as the number of clients grows. A server that is limited by the hardware timestamping rate cannot provide a highly accurate time service to the same number of clients as with PTP using multicast messaging.
NTP の欠点は、クライアントの数が増えると送信タイムスタンプ レートが増加することです。ハードウェアのタイムスタンプ レートによって制限されているサーバーは、マルチキャスト メッセージングを使用する PTP の場合と同じ数のクライアントに高精度のタイム サービスを提供できません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
A new TLV is defined for PTP to contain NTP messages in the NTP client (3), server (4), and symmetric modes (1 and 2) (see [RFC5905]). Using other NTP modes in the TLV is not specified. Any transport specified for PTP that supports unicast messaging, and an IPv4 or IPv6 mapping, can be used for NTP over PTP.
新しい TLV は、NTP クライアント (3)、サーバー (4)、および対称モード (1 および 2) の NTP メッセージを含めるために PTP 用に定義されています ([RFC5905] を参照)。TLV で他の NTP モードを使用することは指定されていません。ユニキャスト メッセージングと IPv4 または IPv6 マッピングをサポートする PTP 用に指定されたトランスポートはすべて、NTP over PTP に使用できます。
The NTP TLV MUST be included in a unicast PTP event message. An event message is required to enable the PTP-specific hardware timestamping and corrections of transparent clocks. The PTP message MUST conform to PTP version 2 [IEEE1588-2008], PTP version 2.1 [IEEE1588-2019], or any future version of the PTP specification that allows the NTP TLV to be included as an organization-specific TLV.
NTP TLV はユニキャスト PTP イベント メッセージに含めなければなりません (MUST)。PTP 固有のハードウェア タイムスタンプと透過クロックの修正を有効にするには、イベント メッセージが必要です。PTP メッセージは、PTP バージョン 2 [IEEE1588-2008]、PTP バージョン 2.1 [IEEE1588-2019]、または NTP TLV を組織固有の TLV として含めることを許可する PTP 仕様の将来のバージョンに準拠しなければなりません (MUST)。
The NTP TLV is an organization-specific TLV having the following fields (with octets in network order):
NTP TLV は、次のフィールドを持つ組織固有の TLV です (オクテットはネットワーク順)。
* type is 0x8000 (ORGANIZATION_EXTENSION_DO_NOT_PROPAGATE) in PTP version 2.1 or 0x0003 (ORGANIZATION_EXTENSION) in PTP version 2
* タイプは、PTP バージョン 2.1 では 0x8000 (ORGANIZATION_EXTENSION_DO_NOT_PROPAGATE)、PTP バージョン 2 では 0x0003 (ORGANIZATION_EXTENSION) です。
* lengthField is 8 + length of the NTP message
* lengthField は 8 + NTP メッセージの長さです
* organizationId is 00-00-5E (the Organizationally Unique Identifier (OUI) is assigned to IANA by the IEEE Registration Authority)
* OrganizationId は 00-00-5E (組織固有識別子 (OUI) は IEEE 登録局によって IANA に割り当てられます)
* organizationSubType is 0x1
* 組織のサブタイプは 0x1 です
* dataField contains two zero octets for 32-bit alignment followed by the NTP message, which would normally be the UDP payload
* dataField には、32 ビット アライメント用の 2 つのゼロ オクテットが含まれ、その後に NTP メッセージが続きます。これは通常 UDP ペイロードになります
An NTP client or peer using the PTP transport sends NTP requests contained as the NTP TLV in PTP messages.
PTP トランスポートを使用する NTP クライアントまたはピアは、PTP メッセージに NTP TLV として含まれる NTP 要求を送信します。
An NTP server or peer responding to an NTP request received over the PTP transport MUST form its response as the NTP TLV using the same PTP transport. To avoid traffic amplification, the server or peer MUST NOT send the response if the PTP message containing the NTP response is longer than the PTP message containing the NTP request. This requirement impacts Autokey [RFC5906], where some responses are longer than the requests (e.g., during certificate exchange). The request SHOULD be padded with the PTP PAD TLV (type 0x8008) to the maximum expected length of the response to enable the transmission of the response.
PTP トランスポート経由で受信した NTP リクエストに応答する NTP サーバーまたはピアは、同じ PTP トランスポートを使用して NTP TLV として応答を形成しなければなりません (MUST)。トラフィックの増幅を避けるために、NTP 応答を含む PTP メッセージが NTP 要求を含む PTP メッセージより長い場合、サーバーまたはピアは応答を送信してはなりません (MUST NOT)。この要件は Autokey [RFC5906] に影響し、一部の応答は要求よりも長くなります (証明書交換中など)。応答の送信を可能にするために、要求には、応答の予想される最大長まで PTP PAD TLV (タイプ 0x8008) を埋め込む必要があります (SHOULD)。
If the NTP response is expected to be used for synchronization (e.g., it is not an error message), the PTP message containing the NTP response SHOULD have the same length as the PTP message containing the NTP request, using the PTP PAD TLV if needed, to avoid an asymmetric delay in networks without full on-path PTP support.
NTP 応答が同期に使用されることが予想される場合 (エラー メッセージではないなど)、完全なオンパス PTP サポートがないネットワークでの非対称遅延を回避するために、NTP 応答を含む PTP メッセージは、必要に応じて PTP PAD TLV を使用して、NTP 要求を含む PTP メッセージと同じ長さである必要があります (SHOULD)。
The PTP version 2.1 [IEEE1588-2019] specification states the following:
PTP バージョン 2.1 [IEEE1588-2019] 仕様には次のように記載されています。
A domain shall define the scope of PTP message communication, state, operations, data sets, and timescale. Within a PTP Network, a domain is identified by two attributes: domainNumber and sdoId.
ドメインは、PTP メッセージ通信の範囲、状態、操作、データ セット、およびタイムスケールを定義します。PTP ネットワーク内では、ドメインは、domainNumber と sdoId という 2 つの属性によって識別されます。
In the context of NTP over PTP version 2.1, this means that the NTP servers, clients, and peers MUST verify that received PTP messages have the domainNumber and sdoId that are expected to be used by NTP over PTP in the network. The domainNumber SHOULD be 123 by default, and sdoId SHOULD be 0. The domainNumber 123 is not commonly used by PTP profiles, so it is less likely to interfere with any other PTP operation that might be running in the network. The domainNumber SHOULD be configurable to allow moving NTP over PTP to another domain if a conflict with a PTP profile using this domainNumber and sdoId needs to be avoided. However, all servers, clients, and peers using NTP over PTP in the network need to use the same domainNumber and sdoId to be able to communicate with each other.
NTP over PTP バージョン 2.1 のコンテキストでは、これは、NTP サーバー、クライアント、およびピアが、受信した PTP メッセージに、ネットワーク内の NTP over PTP によって使用されると予想されるドメイン番号と sdoId が含まれていることを確認しなければならないことを意味します。デフォルトでは、domainNumber は 123 である必要があり、sdoId は 0 である必要があります。domainNumber 123 は、PTP プロファイルでは一般的に使用されないため、ネットワーク内で実行されている可能性のある他の PTP 操作に干渉する可能性は低くなります。このdomainNumberとsdoIdを使用するPTPプロファイルとの競合を回避する必要がある場合、domainNumberはPTP経由で別のドメインにNTPを移動できるように構成可能である必要があります(SHOULD)。ただし、ネットワーク内で NTP over PTP を使用するすべてのサーバー、クライアント、ピアが相互に通信できるようにするには、同じドメイン番号と sdoId を使用する必要があります。
If the UDP transport is used for PTP, the UDP source and destination port numbers SHOULD 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 hardware filter matching only the PTP event port.
UDP トランスポートが PTP に使用される場合、UDP 送信元ポート番号と宛先ポート番号は PTP イベント ポート (319) である必要があります。クライアントがポートのランダム化 [RFC9109] を実装した場合、ハードウェア フィルターが PTP イベント ポートのみに一致するため、リクエストおよび/または応答はハードウェア受信タイムスタンプを取得できません。
Any authenticator fields included in the NTP messages MUST be calculated only over the NTP message following the header of the NTP TLV. Other data in the PTP message (outside of the NTP TLV) are not protected. With the exception of the PTP correction field requiring special handling as described in the following section, the other PTP fields are used only for the transport of the NTP message and have no impact on the security of NTP, similarly to the IP and UDP headers.
NTP メッセージに含まれる認証フィールドは、NTP TLV ヘッダーに続く NTP メッセージ上でのみ計算されなければなりません (MUST)。PTP メッセージ内の他のデータ (NTP TLV の外部) は保護されません。次のセクションで説明する特別な処理が必要な PTP 修正フィールドを除き、他の PTP フィールドは NTP メッセージのトランスポートにのみ使用され、IP ヘッダーや UDP ヘッダーと同様に NTP のセキュリティに影響を与えません。
Receive and transmit timestamps contained in the NTP messages SHOULD NOT be adjusted for the beginning of the NTP data in the PTP message. To minimize the impact of different link speeds on accuracy in networks without full on-path PTP support, the transmit timestamp SHOULD correspond to the PTP message timestamp point (i.e., the beginning of the first symbol after the Ethernet start of frame delimiter), and the receive timestamp SHOULD be transposed from the PTP message timestamp point to the ending of the reception (e.g., the ending of the last symbol of the Ethernet frame check sequence).
NTP メッセージに含まれる受信および送信のタイムスタンプは、PTP メッセージ内の NTP データの先頭に合わせて調整すべきではありません (SHOULD NOT)。完全なオンパス PTP サポートのないネットワークでの精度に対する異なるリンク速度の影響を最小限に抑えるために、送信タイムスタンプは PTP メッセージのタイムスタンプ ポイント (つまり、イーサネット フレーム開始デリミタの後の最初のシンボルの始まり) に対応する必要があり (SHOULD)、受信タイムスタンプは PTP メッセージのタイムスタンプ ポイントから受信の終わり (例: イーサネット フレーム チェック シーケンスの最後のシンボルの終わり) に置き換えられるべきです (SHOULD)。
One-step E2E PTP transparent clocks modify the correction field in the header of the PTP event messages containing NTP messages. To be able to verify and apply the corrections to an NTP measurement, the client or peer needs to know the correction of both the request and response. The correction of the response is in the PTP header of the message itself. The correction of the request is provided by the server or other peer in a new NTP extension field included in the response.
ワンステップ E2E PTP 透過クロックは、NTP メッセージを含む PTP イベント メッセージのヘッダー内の修正フィールドを変更します。NTP 測定値を検証して修正を適用できるようにするには、クライアントまたはピアはリクエストと応答の両方の修正を知っている必要があります。応答の修正は、メッセージ自体の PTP ヘッダーにあります。要求の修正は、応答に含まれる新しい NTP 拡張フィールドでサーバーまたは他のピアによって提供されます。
The format of the Network Correction Extension Field is shown in Figure 1.
ネットワーク修正拡張フィールドのフォーマットを図 1 に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x010A | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Network Correction (64 bits) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Padding .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format of Network Correction Extension Field
図 1: ネットワーク修正拡張フィールドのフォーマット
The length of the padding is the minimum required to make a valid extension field in the used version of NTP. In NTPv4, it is 16 octets to get a 28-octet extension field conforming to [RFC7822].
パディングの長さは、使用されているバージョンの NTP で有効な拡張フィールドを作成するために最低限必要な長さです。NTPv4 では、[RFC7822] に準拠した 28 オクテットの拡張フィールドを取得するには 16 オクテットが必要です。
The Network Correction field in the extension field uses the 64-bit NTP timestamp format (with resolution of about 1/4th of a nanosecond). The correction field in the PTP header has a different format (64-bit nanoseconds + 16-bit fraction).
拡張フィールドのネットワーク修正フィールドは、64 ビット NTP タイムスタンプ形式 (解像度はナノ秒の約 1/4) を使用します。PTP ヘッダーの修正フィールドの形式は異なります (64 ビット ナノ秒 + 16 ビットの小数部)。
The value of the NTP network correction is the sum of PTP corrections provided by transparent clocks and the time it takes to receive the packet (i.e., packet length including the frame check sequence divided by the link speed).
NTP ネットワーク補正の値は、トランスペアレント クロックによって提供される PTP 補正とパケットの受信にかかる時間 (つまり、フレーム チェック シーケンスを含むパケット長をリンク速度で割ったもの) の合計です。
The reason for not using the PTP correction alone is to avoid an asymmetric correction when the server and client, or peers, are connected to the network with different link speeds. The receive duration included in the NTP correction cancels out the transposition from the PTP receive timestamp (which corresponds to the beginning of the reception) to NTP receive timestamp (which corresponds to the end of the reception).
PTP 補正を単独で使用しない理由は、サーバーとクライアント、またはピアが異なるリンク速度でネットワークに接続されている場合の非対称補正を避けるためです。NTP 補正に含まれる受信期間により、PTP 受信タイムスタンプ (受信の開始に対応) から NTP 受信タイムスタンプ (受信の終了に対応) への転置が相殺されます。
The Figure 2 shows the NTP timestamps, transmit/receive durations, and processing and queuing delays included in PTP corrections for an NTP exchange made over two PTP transparent clocks. The link speed is increasing on the network path from the client to the server. The propagation delays in cables are not shown.
図 2 は、2 つの PTP 透過クロック上で行われた NTP 交換の PTP 修正に含まれる NTP タイムスタンプ、送信/受信期間、処理およびキュー遅延を示しています。クライアントからサーバーへのネットワーク パス上のリンク速度が増加しています。ケーブル内の伝播遅延は示されていません。
NTP server T2 T3
--------------------|==|----|==|--------------------
PTP TC #2 |~| |~|
|====| |====|
PTP TC #1 |~| |~|
--|========|----------------------------|========|--
NTP client T1 T4
PTP correction |========|~|====|~| |==|~|====|~|
NTP correction |========|~|====|~|==| |==|~|====|~|========|
Figure 2: PTP Versus NTP Correction
図 2: PTP と NTP の補正
When an NTP server that supports the PTP transport receives an NTP request containing the Network Correction Extension Field, it SHOULD respond with the extension field providing the network correction of the client's request. The server MUST ignore the value of the network correction in the request.
PTP トランスポートをサポートする NTP サーバーが、ネットワーク修正拡張フィールドを含む NTP リクエストを受信した場合、クライアントのリクエストのネットワーク修正を提供する拡張フィールドで応答する必要があります (SHOULD)。サーバーは、リクエスト内のネットワーク修正の値を無視しなければなりません (MUST)。
An NTP client or peer that supports the PTP transport and is configured to use the network correction for the association SHOULD include the extension field in its NTP requests. In the case of a client, the correction value in the extension field SHOULD be always zero.
PTP トランスポートをサポートし、アソシエーションにネットワーク修正を使用するように設定されている NTP クライアントまたはピアは、NTP リクエストに拡張フィールドを含めるべきです(SHOULD)。クライアントの場合、拡張フィールドの補正値は常にゼロであるべきです(SHOULD)。
When the client or peer has the network correction of both the request and response, it can correct the measured NTP peer delay and offset:
クライアントまたはピアが要求と応答の両方のネットワーク修正を行っている場合、測定された NTP ピアの遅延とオフセットを修正できます。
* delta_c = delta - (nc_rs + nc_rq - dur_rs - dur_rq) * (1 - freq_tc)
* delta_c = デルタ - (nc_rs + nc_rq - dur_rs - dur_rq) * (1 - freq_tc)
* theta_c = theta + (nc_rs - nc_rq) / 2
* theta_c = シータ + (nc_rs - nc_rq) / 2
where
ただし
* delta is the NTP peer delay from [RFC5905]
* デルタは、[RFC5905] による NTP ピア遅延です。
* theta is the NTP offset from [RFC5905]
* theta は [RFC5905] からの NTP オフセットです。
* nc_rq is the network correction of the request
* nc_rq はリクエストのネットワーク修正です
* nc_rs is the network correction of the response
* nc_rs は応答のネットワーク修正です。
* dur_rq is the transmit duration of the request
* dur_rq はリクエストの送信期間です。
* dur_rs is the receive duration of the response
* dur_rs は応答の受信期間です。
* freq_tc is the maximum assumed frequency error of transparent clocks
* freq_tc は、トランスペアレント クロックの想定される最大周波数誤差です。
The corrected delay (delta_c) and offset (theta_c) MUST NOT be accepted for synchronization if any of delta_c, nc_rs, and nc_rq is negative. This requirement limits the error caused by faulty transparent clocks and on-path attackers.
delta_c、nc_rs、nc_rq のいずれかが負の場合、修正された遅延 (delta_c) とオフセット (theta_c) を同期のために受け入れてはなりません (MUST NOT)。この要件により、トランスペアレント クロックの欠陥やパス上の攻撃者によって引き起こされるエラーが制限されます。
Root delay (DELTA) MUST NOT be corrected to ensure that the maximum assumed error (root distance) remains independent of network corrections.
想定される最大誤差 (ルート距離) がネットワーク修正から独立したままであることを保証するために、ルート遅延 (DELTA) を修正してはなりません (MUST NOT)。
The scaling by the freq_tc constant (e.g., 100 parts per million (ppm)) is needed to make room for errors in corrections made by transparent clocks running faster than true time and to avoid samples with larger corrections from getting a shorter delay than samples with smaller corrections, which would negatively impact their filtering and weighting.
freq_tc 定数によるスケーリング (たとえば、100 パーツ・パー・ミリオン (ppm)) は、実際の時間よりも高速に実行される透過クロックによって行われる補正の誤差の余地を確保し、補正が大きいサンプルが補正が小さいサンプルよりも遅延が短くなり、フィルター処理や重み付けに悪影響を及ぼすことを避けるために必要です。
The dur_rq and dur_rs values make the corrected peer delay correspond to a direct connection to the server. If they were not used, a perfectly corrected delay on a short network path would be too close to zero and frequently negative due to frequency offset between the client and server. Note that NTP peers and PTP clocks using the E2E delay mechanism are more sensitive to frequency offsets due to longer measurement intervals. If dur_rq is unknown, it MAY be assumed to be equal to dur_rs.
dur_rq および dur_rs の値により、修正されたピア遅延がサーバーへの直接接続に対応します。これらを使用しない場合、短いネットワーク パス上で完全に補正された遅延はゼロに近づきすぎ、クライアントとサーバー間の周波数オフセットによりマイナスになることがよくあります。E2E 遅延メカニズムを使用する NTP ピアと PTP クロックは、測定間隔が長いため、周波数オフセットの影響をより受けやすいことに注意してください。dur_rq が不明な場合は、dur_rs と等しいと仮定してもよい(MAY)。
IANA has created the "IANA PTP TLV Subtypes" registry under the "IANA OUI Ethernet Numbers" registry group for organizationSubType values of PTP TLVs using 00-00-5E as the organizationId (i.e., the OUI assigned to IANA by the IEEE Registration Authority).
IANA は、organizationId (つまり、IEEE 登録局によって IANA に割り当てられた OUI) として 00-00-5E を使用する PTP TLV の OrganizationSubType 値用に、「IANA OUI Ethernet Numbers」レジストリ グループの下に「IANA PTP TLV Subtypes」レジストリを作成しました。
The entries in the registry have the following fields, which are REQUIRED:
レジストリ内のエントリには次のフィールドがあり、これらは必須です。
Subtype:
サブタイプ:
An integer in the range 0-0xFFFFFF
0 ～ 0xFFFFFF の範囲の整数
Description:
説明：
A short text description
短いテキストによる説明
Reference:
参照：
A reference to a document describing the IANA PTP TLV
IANA PTP TLV を説明する文書への参照
The subtype range is split into the following three ranges with different allocation policies:
サブタイプ範囲は、異なる割り当てポリシーを持つ次の 3 つの範囲に分割されます。
0-0xFFFF:
0-0xFFFF:
IETF Review
IETFレビュー
0x10000-0x7FFFFF:
0x10000-0x7FFFFF:
Specification Required
必要な仕様
0x800000-0xFFFFFE:
0x800000-0xFFFFFE:
Experimental and Private Use
実験的および私的使用
The initial contents of the registry are as follows:
レジストリの初期内容は次のとおりです。
+===================+===============================+===========+
| Subtype | Description | Reference |
+===================+===============================+===========+
| 0x0 | Reserved | RFC 10030 |
+-------------------+-------------------------------+-----------+
| 0x1 | Network Time Protocol Message | RFC 10030 |
+-------------------+-------------------------------+-----------+
| 0x2-0x7FFFFF | Unassigned | |
+-------------------+-------------------------------+-----------+
| 0x800000-0xFFFFFE | Reserved for Experimental and | RFC 10030 |
| | Private Use | |
+-------------------+-------------------------------+-----------+
| 0xFFFFFF | Reserved | RFC 10030 |
+-------------------+-------------------------------+-----------+
Table 1
Changes in the Specification Required range are approved by a designated expert (DE). The DE should be familiar with [RFC8126] (particularly Section 5 of [RFC8126]) and the current PTP specifications. The DE should verify that the specification of the organization-specific TLV identified by the assigned subtype exists and is publicly available. The purpose and use of the TLV should be sufficiently clear to enable interoperating implementations, without harming the protocol or the ecosystem.
仕様要求範囲の変更は、指定された専門家 (DE) によって承認されます。DE は [RFC8126] (特に [RFC8126] のセクション 5) と現在の PTP 仕様に精通している必要があります。DE は、割り当てられたサブタイプによって識別される組織固有の TLV の仕様が存在し、公開されているかどうかを検証する必要があります。TLV の目的と用途は、プロトコルやエコシステムを損なうことなく相互運用実装を可能にするために十分に明確である必要があります。
IANA has allocated the following field in the "NTP Extension Field Types" registry <https://www.iana.org/assignments/ntp-parameters/> defined by [RFC5905]:
IANA は、[RFC5905] で定義されている「NTP Extension Field Types」レジストリ <https://www.iana.org/assignments/ntp-parameters/> に次のフィールドを割り当てました。
+============+====================+===========+
| Field Type | Meaning | Reference |
+============+====================+===========+
| 0x010A | Network Correction | RFC 10030 |
+------------+--------------------+-----------+
Table 2
PTP transport prevents NTP clients from randomizing their source port as described in [RFC9109] because both requests and responses need to be sent to the PTP port in order to get a hardware receive timestamp and corrections from PTP transparent clocks.
PTP トランスポートは、ハードウェア受信タイムスタンプと PTP 透過クロックからの修正を取得するために要求と応答の両方を PTP ポートに送信する必要があるため、[RFC9109] で説明されているように NTP クライアントが送信元ポートをランダム化することを防ぎます。
The corrections provided by PTP transparent clocks cannot be authenticated. On-path attackers can modify the correction field, but only corrections smaller than the measured delay are accepted by clients. The impact is comparable to the impact of delaying unmodified NTP messages.
PTP 透過クロックによって提供される修正は認証できません。パス上の攻撃者は修正フィールドを変更できますが、クライアントは測定された遅延よりも小さい修正のみを受け入れます。この影響は、未変更の NTP メッセージの遅延による影響に匹敵します。
[IEEE1588-2019]
IEEE, "IEEE Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems",
IEEE Std 1588-2019, DOI 10.1109/IEEESTD.2020.9120376, June
2020, <https://ieeexplore.ieee.org/document/9120376>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<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, June 2010,
<https://www.rfc-editor.org/info/rfc5905>.
[RFC7822] Mizrahi, T. and D. Mayer, "Network Time Protocol Version 4
(NTPv4) Extension Fields", RFC 7822, DOI 10.17487/RFC7822,
March 2016, <https://www.rfc-editor.org/info/rfc7822>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[G8265-1] ITU-T, "Precision time protocol telecom profile for
frequency synchronization", ITU-T Recommendation G.8265.1/
Y.1365.1, November 2022,
<https://www.itu.int/rec/T-REC-G.8265.1-202211-I/en>.
[G8275-2] ITU-T, "Precision time protocol telecom profile for phase/
time synchronization with partial timing support from the
network", ITU-T Recommendation G.8275.2/Y.1369.2, November
2022,
<https://www.itu.int/rec/T-REC-G.8275.2-202211-I/en>.
[IEEE1588-2008]
IEEE, "IEEE Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems",
IEEE Std 1588-2008, DOI 10.1109/IEEESTD.2008.4579760, July
2008, <https://ieeexplore.ieee.org/document/4579760>.
[RFC5906] Haberman, B., Ed. and D. Mills, "Network Time Protocol
Version 4: Autokey Specification", RFC 5906,
DOI 10.17487/RFC5906, June 2010,
<https://www.rfc-editor.org/info/rfc5906>.
[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, September 2020,
<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, August 2021,
<https://www.rfc-editor.org/info/rfc9109>.
The author would like to thank Doug Arnold, Rodney Cummings, Martin Langer, and Robert Sparks for their comments and suggestions.
著者は、コメントと提案をくださった Doug Arnold、Rodney Cummings、Martin Langer、Robert Sparks に感謝の意を表します。
Miroslav Lichvar
Red Hat
Email: mlichvar@redhat.com