Internet Engineering Task Force (IETF) D. Arnold
Request for Comments: 9760 Meinberg-USA
Category: Standards Track H. Gerstung
ISSN: 2070-1721 Meinberg
May 2025
This document describes a Precision Time Protocol (PTP) Profile (IEEE Standard 1588-2019) for use in an IPv4 or IPv6 enterprise information system environment. The PTP Profile uses the End-to-End delay measurement mechanism, allowing both multicast and unicast Delay Request and Delay Response messages.
このドキュメントでは、IPv4またはIPv6エンタープライズ情報システム環境で使用するためのPrecision Time Protocol（PTP）プロファイル（IEEE標準1588-2019）について説明します。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.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（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/rfc9760.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9760で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 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ドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Requirements Language
3. Technical Terms
4. Problem Statement
5. Network Technology
6. Time Transfer and Delay Measurement
7. Default Message Rates
8. Requirements for TimeTransmitter Clocks
9. Requirements for TimeReceiver Clocks
10. Requirements for Transparent Clocks
11. Requirements for Boundary Clocks
12. Management and Signaling Messages
13. Forbidden PTP Options
14. Interoperation with IEEE 1588 Default Profile
15. Profile Identification
16. IANA Considerations
17. Security Considerations
18. References
18.1. Normative References
18.2. Informative References
Acknowledgements
Authors' Addresses
The Precision Time Protocol (PTP), standardized in IEEE 1588, has been designed in its first version (IEEE 1588-2002) with the goal of minimizing configuration on the participating nodes. Network communication was based solely on multicast messages, which, unlike NTP, did not require that a receiving node as discussed in IEEE 1588-2019 [IEEE1588-2019] need to know the identities of the time sources in the network. This document describes clock roles and PTP Port states using the optional alternative terms "timeTransmitter" instead of "master" and "timeReceiver" instead of "slave", as defined in the IEEE 1588g amendment [IEEE1588g] to [IEEE1588-2019].
IEEE 1588に標準化されたPrecision Timeプロトコル（PTP）は、参加ノードの構成を最小化することを目的として、最初のバージョン（IEEE 1588-2002）で設計されています。ネットワーク通信は、NTPとは異なり、IEEE 1588-2019 [IEEE1588-2019]で議論されている受信ノード[IEEE1588-2019]がネットワーク内の時間源のアイデンティティを知る必要があることを必要としなかったマルチキャストメッセージのみに基づいていました。このドキュメントでは、IEEE 1588G修正[IEEE1588G]から[IEEE1588-2019]で定義されているように、「スレーブ」の代わりに「マスター」および「タイマーサイバー」ではなく、「マスター」および「タイムレクイバー」ではなく、「マスター」および「タイムトランシバー」ではなく、オプションの代替用語「タイムトランズミッター」を使用して、時計の役割とPTPポート状態について説明します。
The "Best TimeTransmitter Clock Algorithm" ([IEEE1588-2019], Subclause 9.3), a mechanism that all participating PTP Nodes MUST follow, sets up strict rules for all members of a PTP domain to determine which node MUST be the active reference time source (Grandmaster). Although the multicast communication model has advantages in smaller networks, it complicated the application of PTP in larger networks -- for example, in environments like IP-based telecommunication networks or financial data centers. It is considered inefficient that, even if the content of a message applies only to one receiver, the message is forwarded by the underlying network (IP) to all nodes, requiring them to spend network bandwidth and other resources, such as CPU cycles, to drop it.
すべての参加PTPノードが従わなければならないメカニズムである「最高のTimeTransmitter Clockアルゴリズム」（[IEEE1588-2019]、サブクソール9.3）は、PTPドメインのすべてのメンバーの厳格なルールを設定して、どのノードがアクティブな参照時間ソースでなければならないかを決定します（Grandmaster setwed（Grandmaster）。マルチキャスト通信モデルは小規模なネットワークで利点がありますが、たとえばIPベースの通信ネットワークや財務データセンターなどの環境など、より大きなネットワークでのPTPの適用を複雑にしました。メッセージのコンテンツが1つのレシーバーのみに適用されている場合でも、メッセージは基礎となるネットワーク（IP）によってすべてのノードに転送され、ネットワーク帯域幅やCPUサイクルなどの他のリソースを使用する必要があることは非効率的であると考えられています。
The third edition of the standard (IEEE 1588-2019) defines PTPv2.1 and includes the possibility of using unicast communication between the PTP Nodes in order to overcome the limitation of using multicast messages for the bidirectional information exchange between PTP Nodes. The unicast approach avoided that. In PTP domains with a lot of nodes, devices had to throw away most of the received multicast messages because they carried information for some other node. The percent of PTP messages that are discarded as irrelevant to the receiving node can exceed 99% [Estrela_and_Bonebakker].
標準の第3版（IEEE 1588-2019）は、PTPV2.1を定義し、PTPノード間の双方向情報交換にマルチキャストメッセージを使用する制限を克服するために、PTPノード間でユニキャスト通信を使用する可能性を含んでいます。ユニキャストアプローチはそれを避けました。多くのノードを備えたPTPドメインでは、他のノードに情報を携帯していたため、デバイスは受信したマルチキャストメッセージのほとんどを捨てる必要がありました。受信ノードとは無関係であると破棄されるPTPメッセージの割合は、99％を超える可能性があります[Estrela_and_bonebakker]。
PTPv2.1 also includes PTP Profiles ([IEEE1588-2019], Subclause 20.3). These constructs allow organizations to specify selections of attribute values and optional features, simplifying the configuration of PTP Nodes for a specific application. Instead of having to go through all possible parameters and configuration options and individually set them up, selecting a PTP Profile on a PTP Node will set all the parameters that are specified in the PTP Profile to a defined value. If a PTP Profile definition allows multiple values for a parameter, selection of the PTP Profile will set the profile-specific default value for this parameter. Parameters not allowing multiple values are set to the value defined in the PTP Profile. Many PTP features and functions are optional, and a PTP Profile should also define which optional features of PTP are required, permitted, and prohibited. It is possible to extend the PTP standard with a PTP Profile by using the TLV mechanism of PTP (see [IEEE1588-2019], Subclause 13.4) or defining an optional Best TimeTransmitter Clock Algorithm, among other techniques (which are beyond the scope of this document). PTP has its own management protocol (defined in [IEEE1588-2019], Subclause 15.2) but allows a PTP Profile to specify an alternative management mechanism -- for example, the Network Configuration Protocol (NETCONF).
PTPV2.1には、PTPプロファイルも含まれています（[IEEE1588-2019]、サブクロース20.3）。これらのコンストラクトにより、組織は属性値とオプションの機能の選択を指定し、特定のアプリケーションのPTPノードの構成を簡素化できます。すべての可能なパラメーターと構成オプションを実行して個別にセットアップする代わりに、PTPノードでPTPプロファイルを選択すると、PTPプロファイルで指定されたすべてのパラメーターが定義された値に設定されます。PTPプロファイル定義がパラメーターの複数の値を許可する場合、PTPプロファイルの選択はこのパラメーターのプロファイル固有のデフォルト値を設定します。複数の値を許可しないパラメーターは、PTPプロファイルで定義された値に設定されます。多くのPTP機能と関数はオプションであり、PTPプロファイルは、PTPのオプション機能が必要で、許可され、禁止されているかを定義する必要があります。PTPのTLVメカニズム（[IEEE1588-2019]を参照、13.4を参照）を使用して、または他の技術（このドキュメントの範囲を超えている）の中でオプションの最高のTimetransmitterクロックアルゴリズムを定義することにより、PTPプロファイルを使用してPTP標準を拡張することができます。PTPには、独自の管理プロトコル（[IEEE1588-2019]、サブクロース15.2で定義されています）がありますが、PTPプロファイルは、たとえばネットワーク構成プロトコル（NetConf）などの代替管理メカニズムを指定できます。
In this document, the term "PTP Port" refers to a logical access point of a PTP instantiation for PTP communication in a network.
このドキュメントでは、「PTPポート」という用語は、ネットワーク内のPTP通信の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] で説明されているように解釈されます。
Acceptable TimeTransmitter Table:
許容可能なTimeTransmitterテーブル：
A list of timeTransmitters that may be maintained by a PTP timeReceiver Clock. The PTP timeReceiver Clock would be willing to synchronize to timeTransmitters in this list.
PTPタイムレシバークロックによって維持される可能性のあるTimeTransmitterのリスト。PTP Timereceiver Clockは、このリストのTimeTransmittersに同期することをいとわないでしょう。
Alternate timeTransmitter:
Alternate Timetransmitter：
A PTP timeTransmitter Clock that is not the Best timeTransmitter and therefore is used as an alternative clock. It may act as a timeTransmitter with the Alternate timeTransmitter flag set on the messages it sends.
最適なTimetransmitterではないため、代替クロックとして使用されるPTP Timetransmitterクロック。それは、送信するメッセージに設定された代替のTimeTransmitterフラグを備えたTimeTransmitterとして機能する場合があります。
Announce message:
メッセージを発表する：
Contains the properties of a given timeTransmitter Clock. The information is used to determine the Best timeTransmitter.
特定のTimeTransmitterクロックのプロパティが含まれています。情報は、最適なTimeTransmitterを決定するために使用されます。
Best timeTransmitter:
最高のTimetransmitter：
A clock with a PTP Port in the timeTransmitter state, operating as the Grandmaster of a PTP domain.
PTPドメインのグランドマスターとして動作するTimeTransmitter状態にPTPポートを備えた時計。
Best TimeTransmitter Clock Algorithm:
Best TimeTranSmitterクロックアルゴリズム：
A method for determining which state a PTP Port of a PTP clock should be in. The state decisions lead to the formation of a clock spanning tree for a PTP domain.
PTPクロックのPTPポートをどの状態にするかを決定する方法。状態の決定は、PTPドメインのクロックスパニングツリーの形成につながります。
Boundary Clock:
境界時計：
A device with more than one PTP Port. Generally, Boundary Clocks will have one PTP Port in the timeReceiver state to receive timing and other PTP Ports in the timeTransmitter state to redistribute the timing.
複数のPTPポートを備えたデバイス。一般に、境界クロックには、タイミングを受け取るタイミングおよびタイムトランズミット状態の他のPTPポートを受け取るために、タイミングを再分配するためのタイミングおよびその他のPTPポートが1つのPTPポートがあります。
Clock Identity:
クロックアイデンティティ：
In [IEEE1588-2019], a 64-bit number assigned to each PTP clock. This number MUST be globally unique. Often, it is derived from the Ethernet Media Access Control (MAC) address.
[IEEE1588-2019]では、各PTPクロックに割り当てられた64ビット番号。この番号はグローバルに一意でなければなりません。多くの場合、イーサネットメディアアクセス制御（MAC）アドレスから派生しています。
Domain:
ドメイン：
Treated as a separate PTP system in a network. Every PTP message contains a domain number. Clocks, however, can combine the timing information derived from multiple domains.
ネットワーク内の個別のPTPシステムとして扱われます。すべてのPTPメッセージにはドメイン番号が含まれています。ただし、クロックは、複数のドメインから派生したタイミング情報を組み合わせることができます。
End-to-End delay measurement mechanism:
エンドツーエンド遅延測定メカニズム：
A network delay measurement mechanism in PTP facilitated by an exchange of messages between a timeTransmitter Clock and a timeReceiver Clock. These messages might traverse Transparent Clocks and PTP-unaware switches. This mechanism might not work properly if the Sync and Delay Request messages traverse different network paths.
PTPにおけるネットワーク遅延測定メカニズムは、TimeTransmitterクロックとタイムレシバークロックの間のメッセージの交換によって促進されます。これらのメッセージは、透明なクロックとPTPに不名誉なスイッチを横断する可能性があります。このメカニズムは、リクエストメッセージが異なるネットワークパスを通過する場合、同期と遅延リクエストメッセージが適切に機能しない場合があります。
Grandmaster:
グランドマスター：
The timeTransmitter Clock that is currently acting as the reference time source of the PTP domain.
現在PTPドメインの参照時間ソースとして機能しているTimeTransmitterクロック。
IEEE 1588:
IEEE 1588：
The timing and synchronization standard that defines PTP and describes the node, system, and communication properties necessary to support PTP.
PTPを定義し、PTPをサポートするために必要なノード、システム、および通信プロパティを記述するタイミングおよび同期標準。
NTP:
NTP:
Network Time Protocol, defined by [RFC5905].
[RFC5905]で定義されたネットワークタイムプロトコル。
Ordinary Clock:
普通の時計：
A clock that has a single PTP Port in a domain and maintains the timescale used in the domain. It may serve as a timeTransmitter Clock or may be a timeReceiver Clock.
ドメインに単一のPTPポートがあり、ドメインで使用されるタイムスケールを維持するクロック。TimeTransmitterクロックとして機能する場合や、タイムレクバークロックになる場合があります。
Peer-to-Peer delay measurement mechanism:
ピアツーピア遅延測定メカニズム：
A network delay measurement mechanism in PTP facilitated by an exchange of messages over the link between adjacent devices in a network. This mechanism might not work properly unless all devices in the network support PTP and the Peer-to-Peer delay measurement mechanism.
ネットワーク内の隣接するデバイス間のリンクを介したメッセージの交換によって促進されるPTPのネットワーク遅延測定メカニズム。このメカニズムは、ネットワーク内のすべてのデバイスがPTPとピアツーピア遅延測定メカニズムをサポートしない限り、適切に機能しない場合があります。
Preferred timeTransmitter:
Preferred TimeTranSmitter：
A device intended to act primarily as the Grandmaster of a PTP system or as a backup to a Grandmaster.
主にPTPシステムのグランドマスターとして、またはグランドマスターへのバックアップとして機能することを目的としたデバイス。
PTP:
PTP:
The Precision Time Protocol -- the timing and synchronization protocol defined by IEEE 1588.
精密時間プロトコル - IEEE 1588で定義されたタイミングと同期プロトコル。
PTP Port:
PTPポート：
An interface of a PTP clock with the network. Note that there may be multiple PTP Ports running on one physical interface -- for example, multiple unicast timeReceivers that talk to several Grandmaster Clocks in different PTP domains.
ネットワークを使用したPTPクロックのインターフェイス。1つの物理インターフェイスで実行されている複数のPTPポートがある場合があることに注意してください。たとえば、異なるPTPドメインのいくつかのグランドマスタークロックと話す複数のユニキャストタイマーケーバーなどです。
PTP Profile:
PTPプロファイル：
A set of constraints on the options and features of PTP, designed to optimize PTP for a specific use case or industry. The profile specifies what is required, allowed, and forbidden among options and attribute values of PTP.
特定のユースケースまたは業界のPTPを最適化するように設計されたPTPのオプションと機能に関する一連の制約。プロファイルは、PTPのオプションと属性値の間で必要な、許可、および禁止されているものを指定します。
PTPv2.1:
PTPV2.1：
Refers specifically to the version of PTP defined by [IEEE1588-2019].
[IEEE1588-2019]で定義されたPTPのバージョンを特に指します。
Rogue timeTransmitter:
Rogue Timetransmitter：
A clock that has a PTP Port in the timeTransmitter state -- even though it should not be in the timeTransmitter state according to the Best TimeTransmitter Clock Algorithm -- and that does not set the Alternate timeTransmitter flag.
TimeTransmitter状態にPTPポートがあるクロックは、最適なTimetransmitter Clockアルゴリズムに従ってTimeTransmitter状態にあるはずではありませんが、代替Timetransmitterフラグを設定していません。
TimeReceiver Clock:
Timereceiver Clock：
A clock with at least one PTP Port in the timeReceiver state and no PTP Ports in the timeTransmitter state.
タイマーレシバー状態に少なくとも1つのPTPポートがあり、TimeTransmitter状態にPTPポートがないクロック。
TimeReceiver Only Clock:
Timereceiverのみの時計：
An Ordinary Clock that cannot become a timeTransmitter Clock.
TimeTransmitterクロックになることができない通常のクロック。
TimeTransmitter Clock:
TimeTransmitterクロック：
A clock with at least one PTP Port in the timeTransmitter state.
TimeTransmitter状態に少なくとも1つのPTPポートがあるクロック。
TLV:
TLV:
Type Length Value -- a mechanism for extending messages in networked communications.
タイプの長さ値 - ネットワーク化された通信にメッセージを拡張するためのメカニズム。
Transparent Clock:
透明時計：
A device that measures the time taken for a PTP event message to transit the device and then updates the message with a correction for this transit time.
PTPイベントメッセージの時間を測定してデバイスを通過し、この輸送時間の修正でメッセージを更新するデバイス。
Unicast discovery:
ユニキャストの発見：
A mechanism for PTP timeReceivers to establish a unicast communication with PTP timeTransmitters using a configured table of timeTransmitter IP addresses and unicast message negotiation.
PTPタイムレシバーが、TimeTransmitter IPアドレスとユニキャストメッセージネゴシエーションの構成テーブルを使用して、PTP TimeTransmitterとのユニキャスト通信を確立するメカニズム。
Unicast message negotiation:
ユニキャストメッセージネゴシエーション：
A mechanism in PTP for timeReceiver Clocks to negotiate unicast Sync, Announce, and Delay Request message transmission rates from timeTransmitters.
TimeTransmittersからのUnicast Syncを交渉し、発表し、リクエストメッセージ送信レートを交渉するためのTimereceiverクロックのPTPのメカニズム。
This document describes how PTP can be applied to work in large enterprise networks. Such large networks are deployed, for example, in financial corporations. It is becoming increasingly common in such networks to perform distributed time-tagged measurements, such as one-way packet latencies and cumulative delays on software systems spread across multiple computers. Furthermore, there is often a desire to check the age of information time-tagged by a different machine. To perform these measurements, it is necessary to deliver a common precise time to multiple devices on a network. Accuracy currently required in the financial industry ranges from 100 microseconds to 1 nanosecond to the Grandmaster. This PTP Profile does not specify timing performance requirements, but such requirements explain why the needs cannot always be met by NTP as commonly implemented. Such accuracy cannot usually be achieved with NTP, without adding non-standard customizations such as on-path support, similar to what is done in PTP with Transparent Clocks and Boundary Clocks. Such PTP support is commonly available in switches and routers, and many such devices have already been deployed in networks. Because PTP has a complex range of features and options, it is necessary to create a PTP Profile for enterprise networks to achieve interoperability among equipment manufactured by different vendors.
このドキュメントでは、PTPを大規模なエンタープライズネットワークで機能させるためにどのように適用できるかについて説明します。このような大規模なネットワークは、たとえば金融会社に展開されています。このようなネットワークでは、一元配置パケットレイテンシーや複数のコンピューターに広がるソフトウェアシステムの累積遅延など、分散型の時間張り付けされた測定値を実行することがますます一般的になっています。さらに、多くの場合、別のマシンで時間をタグ付けする情報の年齢を確認したいという願望があります。これらの測定を実行するには、ネットワーク上の複数のデバイスに共通の正確な時間を提供する必要があります。現在、金融業界で必要な精度は、グランドマスターまで100マイクロ秒から1ナノ秒までの範囲です。このPTPプロファイルはタイミングのパフォーマンス要件を指定しませんが、そのような要件は、一般的に実装されているようにNTPによって常にニーズを満たすことができない理由を説明しています。このような精度は、通常、透明時計や境界クロックを備えたPTPで行われるものと同様に、標準以外のカスタマイズを追加することなく、NTPでは通常NTPで達成することはできません。このようなPTPサポートは一般にスイッチとルーターで利用可能であり、そのような多くのデバイスはすでにネットワークに展開されています。PTPには複雑な範囲の機能とオプションがあるため、さまざまなベンダーが製造した機器間の相互運用性を実現するには、エンタープライズネットワーク向けのPTPプロファイルを作成する必要があります。
Although enterprise networks can be large, it is becoming increasingly common to deploy multicast protocols, even across multiple subnets. For this reason, it is desirable to make use of multicast whenever the information going to many destinations is the same. It is also advantageous to send information that is only relevant to one device as a unicast message. The latter can be essential as the number of PTP timeReceivers becomes hundreds or thousands.
エンタープライズネットワークは大きくなる可能性がありますが、複数のサブネットでもマルチキャストプロトコルを展開することがますます一般的になっています。このため、多くの目的地に行く情報が同じである場合はいつでも、マルチキャストを利用することが望ましいです。また、ユニキャストメッセージとして1つのデバイスにのみ関連する情報を送信することも有利です。後者は、PTPタイマーライバーの数が数百または数千になるため、不可欠です。
PTP devices operating in these networks need to be robust. This includes the ability to ignore PTP messages that can be identified as improper and to have redundant sources of time.
これらのネットワークで動作するPTPデバイスは堅牢である必要があります。これには、不適切であると識別できるPTPメッセージを無視し、冗長な時間源を持つ機能が含まれます。
Interoperability among independent implementations of this PTP Profile has been demonstrated at the International Symposium on Precision Clock Synchronization (ISPCS) Plugfest [ISPCS].
このPTPプロファイルの独立した実装間の相互運用性は、Precision Clock Synchronization（ISPCS）PlugFest [ISPCS]に関する国際シンポジウムで実証されています。
This PTP Profile MUST operate only in networks characterized by UDP [RFC0768] over either IPv4 [RFC0791] or IPv6 [RFC8200], as described by Annexes C and D of [IEEE1588-2019], respectively. A network node MAY include multiple PTP instances running simultaneously. IPv4 and IPv6 instances in the same network node MUST operate in different PTP domains. PTP clocks that communicate using IPv4 can transfer time to PTP clocks using IPv6, or the reverse, if and only if there is a network node that simultaneously communicates with both PTP domains in the different IP versions.
このPTPプロファイルは、それぞれ[IEEE1588-2019]の付属書CおよびDで説明されているように、IPv4 [RFC0791]またはIPv6 [RFC8200]を超えるUDP [RFC0768]を特徴とするネットワークでのみ動作する必要があります。ネットワークノードには、同時に実行される複数のPTPインスタンスが含まれる場合があります。同じネットワークノードのIPv4およびIPv6インスタンスは、異なるPTPドメインで動作する必要があります。IPv4を使用して通信するPTPクロックは、異なるIPバージョンの両方のPTPドメインと同時に通信するネットワークノードがある場合にのみ、IPv6を使用してPTPクロックに時間を転送できます。
The PTP system MAY include switches and routers. These devices MAY be Transparent Clocks, Boundary Clocks, or neither, in any combination. PTP clocks MAY be Preferred timeTransmitters, Ordinary Clocks, or Boundary Clocks. The Ordinary Clocks may be timeReceiver Only Clocks or may be timeTransmitter capable.
PTPシステムには、スイッチとルーターが含まれる場合があります。これらのデバイスは、透明なクロック、境界クロック、またはどちらの組み合わせもない場合があります。PTPクロックは、推奨されるタイムトランズミッター、通常のクロック、または境界クロックです。通常のクロックは、タイムレシバーのクロックのみであるか、ティムトランズミッター能力がある場合があります。
Note that PTP Ports will need to keep track of the Clock ID of received messages and not just the IP or Layer 2 addresses in any network that includes Transparent Clocks or that might include them in the future. This is important, since Transparent Clocks might treat PTP messages that are altered at the PTP application layer as new IP packets and new Layer 2 frames when the PTP messages are retransmitted. In IPv4 networks, some clocks might be hidden behind a NAT, which hides their IP addresses from the rest of the network. Note also that the use of NATs may place limitations on the topology of PTP Networks, depending on the port forwarding scheme employed. Details of implementing PTP with NATs are out of scope for this document.
PTPポートは、透明なクロックを含む、または将来に含まれる可能性のあるネットワーク内のIPまたはレイヤー2アドレスだけでなく、受信したメッセージのクロックIDを追跡する必要があることに注意してください。これは重要です。なぜなら、透明なクロックは、PTPアプリケーションレイヤーで変更されたPTPメッセージを新しいIPパケットとして、およびPTPメッセージを再送信するときに新しいレイヤー2フレームを処理する可能性があるためです。IPv4ネットワークでは、一部のクロックはNATの後ろに隠されている可能性があり、ネットワークの残りの部分からIPアドレスを隠しています。また、NATの使用は、採用されているポート転送スキームに応じて、PTPネットワークのトポロジーに制限を設ける可能性があることに注意してください。NATを使用したPTPの実装の詳細は、このドキュメントの範囲外です。
PTP, similar to NTP, assumes that the one-way network delay for Sync messages and Delay Response messages is the same. When this is not true, it can cause errors in the transfer of time from the timeTransmitter to the timeReceiver. It is up to the system integrator to design the network so that such effects do not prevent the PTP system from meeting the timing requirements. The details of network asymmetry are outside the scope of this document. See, for example, ITU-T G.8271 [G8271].
NTPと同様に、PTPは、同期メッセージと遅延応答メッセージの一方向ネットワーク遅延が同じであると想定しています。これが真実でない場合、TimeTransmitterからTimereceiverへの時間の転送にエラーが発生する可能性があります。このような効果がPTPシステムがタイミング要件を満たすことを妨げないように、ネットワークを設計するのはシステムインテグレーター次第です。ネットワークの非対称性の詳細は、このドキュメントの範囲外です。たとえば、ITU-T G.8271 [G8271]を参照してください。
TimeTransmitter Clocks, Transparent Clocks, and Boundary Clocks MAY be either one-step clocks or two-step clocks. TimeReceiver Clocks MUST support both behaviors. The End-to-End delay measurement method MUST be used.
TimeTransmitterクロック、透明な時計、境界クロックは、1段階の時計または2段階の時計のいずれかです。Timereceiver Clockは両方の動作をサポートする必要があります。エンドツーエンド遅延測定方法を使用する必要があります。
Note that, in IP networks, Sync messages and Delay Request messages exchanged between a timeTransmitter and timeReceiver do not necessarily traverse the same physical path. Thus, wherever possible, the network SHOULD be engineered so that the forward and reverse routes traverse the same physical path. Traffic engineering techniques for path consistency are out of scope for this document.
IPネットワークでは、TimetransmitterとTimereceiverの間で交換されたメッセージと遅延リクエストメッセージが必ずしも同じ物理パスを横断するわけではないことに注意してください。したがって、可能な限り、ネットワークをエンジニアリングして、フォワードルートとリバースルートが同じ物理パスを通過するようにする必要があります。パスの一貫性のためのトラフィックエンジニアリング手法は、このドキュメントの範囲外です。
Sync messages MUST be sent as PTP event multicast messages (UDP port 319) to the PTP primary IP address. Two-step clocks MUST send Follow-up messages as PTP general multicast messages (UDP port 320). Announce messages MUST be sent as PTP general multicast messages (UDP port 320) to the PTP primary address. The PTP primary IP address is 224.0.1.129 for IPv4 and FF0X:0:0:0:0:0:0:181 for IPv6, where "X" can be a value between 0x0 and 0xF. The different IPv6 address options are explained in [IEEE1588-2019], Annex D, Section D.3. These addresses are allotted by IANA; see the "IPv6 Multicast Address Space Registry" [IPv6Registry].
同期メッセージは、PTPイベントマルチキャストメッセージ（UDPポート319）としてPTPプライマリIPアドレスとして送信する必要があります。2段階のクロックは、PTP一般マルチキャストメッセージとしてフォローアップメッセージを送信する必要があります（UDPポート320）。アナウンスメッセージは、PTP一般マルチキャストメッセージ（UDPポート320）としてPTPプライマリアドレスに送信する必要があります。PTPプライマリIPアドレスは、IPv4およびFF0Xの場合は224.0.1.129です：0：0：0：0：0：0：0：181では、「x」は0x0から0xfの間の値になります。さまざまなIPv6アドレスオプションは、[IEEE1588-2019]、付録D、セクションD.3で説明されています。これらのアドレスはIANAによって割り当てられます。「IPv6マルチキャストアドレススペースレジストリ」[IPv6Registry]を参照してください。
Delay Request messages MAY be sent as either multicast or unicast PTP event messages. TimeTransmitter Clocks MUST respond to multicast Delay Request messages with multicast Delay Response PTP general messages. TimeTransmitter Clocks MUST respond to unicast Delay Request PTP event messages with unicast Delay Response PTP general messages. This allows for the use of Ordinary Clocks that do not support the Enterprise Profile, if they are timeReceiver Only Clocks.
遅延リクエストメッセージは、マルチキャストまたはユニキャストPTPイベントメッセージのいずれかとして送信される場合があります。TimeTransmitterクロックは、マルチキャスト遅延応答PTP一般メッセージを使用したマルチキャスト遅延リクエストメッセージに応答する必要があります。TimeTransmitterクロックは、ユニキャスト遅延応答PTP一般メッセージを使用して、ユニキャスト遅延リクエストPTPイベントメッセージに応答する必要があります。これにより、タイマーレシバーのクロックのみである場合、エンタープライズプロファイルをサポートしない通常のクロックを使用できます。
Clocks SHOULD include support for multiple domains. The purpose is to support multiple simultaneous timeTransmitters for redundancy. Leaf devices (non-forwarding devices) can use timing information from multiple timeTransmitters by combining information from multiple instantiations of a PTP stack, each operating in a different PTP domain. To check for faulty timeTransmitter Clocks, redundant sources of timing can be evaluated as an ensemble and/or compared individually. The use of multiple simultaneous timeTransmitters will help mitigate faulty timeTransmitters reporting as healthy, network delay asymmetry, and security problems. Security problems include on-path attacks such as delay attacks, packet interception attacks, and packet manipulation attacks. Assuming that the path to each timeTransmitter is different, failures -- malicious or otherwise -- would have to happen at more than one path simultaneously. Whenever feasible, the underlying network transport technology SHOULD be configured so that timing messages in different domains traverse different network paths.
クロックには、複数のドメインのサポートを含める必要があります。目的は、冗長性のために複数の同時のタイムトランズミッターをサポートすることです。Leaf Devices（非適切なデバイス）は、それぞれが異なるPTPドメインで動作するPTPスタックの複数のインスタンス化からの情報を組み合わせることにより、複数のTimeTransmitterからのタイミング情報を使用できます。障害のあるTimetransmitterクロックを確認するには、タイミングの冗長なソースをアンサンブルとして評価したり、個別に比較したりできます。複数の同時のタイムトランズミッターを使用すると、健康的な、ネットワーク遅延の非対称性、およびセキュリティの問題を報告する故障した時計装置を軽減するのに役立ちます。セキュリティの問題には、遅延攻撃、パケット傍受攻撃、パケット操作攻撃などのパス攻撃が含まれます。各タイムトランズミッターへのパスが異なると仮定すると、障害 - 悪意があるかどうかは、複数のパスで同時に発生する必要があります。実行可能なときはいつでも、異なるドメインのタイミングメッセージが異なるネットワークパスを通過するように、基礎となるネットワークトランスポートテクノロジーを構成する必要があります。
The Sync, Announce, and Delay Request default message rates MUST each be once per second. The Sync and Delay Request message rates MAY be set to other values, but not less than once every 128 seconds and not more than 128 messages per second. The Announce message rate MUST NOT be changed from the default value. The Announce Receipt Timeout Interval MUST be three Announce Intervals for Preferred timeTransmitters and four Announce Intervals for all other timeTransmitters.
同期、アナウンス、および遅延リクエストデフォルトのメッセージレートはそれぞれ1秒あたり1回でなければなりません。同期および遅延リクエストメッセージレートは、他の値に設定される場合がありますが、128秒ごとに1秒以上、1秒あたり128メッセージ以下です。アナウンスメッセージレートをデフォルト値から変更してはなりません。領収書のアナウンスタイムアウト間隔は、優先さされたタイムトランズミッターの3つのアナウンス間隔であり、他のすべてのTimeTransmitterの4つのアナウンス間隔でなければなりません。
The logMessageInterval carried in the unicast Delay Response message MAY be set to correspond to the timeTransmitter ports' preferred message period, rather than 7F, which indicates that message periods are to be negotiated. Note that negotiated message periods are not allowed; see Section 13 ("Forbidden PTP Options").
Unicast Delay Responseメッセージに掲載されたLogMessageIntervalは、7Fではなく、TimeTransmitter Portsの優先メッセージ期間に対応するように設定できます。これは、メッセージ期間が交渉されることを示しています。交渉されたメッセージ期間は許可されていないことに注意してください。セクション13（「禁止されたPTPオプション」）を参照してください。
TimeTransmitter Clocks MUST obey the standard Best TimeTransmitter Clock Algorithm as defined in [IEEE1588-2019]. PTP systems using this PTP Profile MAY support multiple simultaneous Grandmasters if each active Grandmaster is operating in a different PTP domain.
TimeTransmitterクロックは、[IEEE1588-2019]で定義されている標準的な最高のTimetransmitter Clockアルゴリズムに従う必要があります。このPTPプロファイルを使用したPTPシステムは、各アクティブなグランドマスターが別のPTPドメインで動作している場合、複数の同時のグランドマスターをサポートする場合があります。
A PTP Port of a clock MUST NOT be in the timeTransmitter state unless the clock has a current value for the number of UTC leap seconds.
クロックのPTPポートは、クロックにUTCの跳躍数の現在の値がない限り、TimeTransmitter状態にある必要があります。
If a unicast negotiation signaling message is received, it MUST be ignored.
ユニキャストネゴシエーションシグナル伝達メッセージが受信された場合、無視する必要があります。
In PTP Networks that contain Transparent Clocks, timeTransmitters might receive Delay Request messages that no longer contain the IP addresses of the timeReceivers. This is because Transparent Clocks might replace the IP address of Delay Requests with their own IP address after updating the Correction Fields. For this deployment scenario, timeTransmitters will need to have configured tables of timeReceivers' IP addresses and associated Clock Identities in order to send Delay Responses to the correct PTP Nodes.
透明なクロックを含むPTPネットワークでは、TimeTransmitterは、タイマーケーバーのIPアドレスが含まれなくなった遅延リクエストメッセージを受信する場合があります。これは、透明なクロックが、補正フィールドを更新した後、遅延要求のIPアドレスを独自のIPアドレスに置き換える可能性があるためです。この展開シナリオでは、TimeTransmitterが正しいPTPノードに遅延応答を送信するために、タイムレクバーのIPアドレスと関連するクロックIDの表を構成する必要があります。
In a network that contains multiple timeTransmitters in multiple domains, timeReceivers SHOULD make use of information from all the timeTransmitters in their clock control subsystems. TimeReceiver Clocks MUST be able to function in such networks even if they use time from only one of the domains. TimeReceiver Clocks MUST be able to operate properly in the presence of a rogue timeTransmitter. TimeReceivers SHOULD NOT synchronize to a timeTransmitter that is not the Best timeTransmitter in its domain. TimeReceivers will continue to recognize a Best timeTransmitter for the duration of the Announce Receipt Timeout Interval. TimeReceivers MAY use an Acceptable TimeTransmitter Table. If a timeTransmitter is not an Acceptable timeTransmitter, then the timeReceiver MUST NOT synchronize to it. Note that IEEE 1588-2019 requires timeReceiver Clocks to support both two-step and one-step timeTransmitter Clocks. See [IEEE1588-2019], Subclause 11.2.
複数のドメインに複数のTimeTransmitterを含むネットワークでは、タイムレシバーは、時計制御サブシステムのすべてのTimeTransmitterから情報を利用する必要があります。タイマーレシバーのクロックは、ドメインの1つだけから時間を使用しても、そのようなネットワークで機能できる必要があります。タイムレックの時計は、不正な時計装置の存在下で適切に動作できる必要があります。タイムレックは、そのドメインで最良のTimeTransmitterではないTimeTransmitterに同期しないでください。Timereceiversは、領収書タイムアウト間隔を発表する期間中、引き続き最適なTimetransmitterを認識します。タイムレックは、許容可能なTimeTransmitterテーブルを使用する場合があります。TimeTransmitterが許容可能なTimeTransmitterでない場合、タイムレシバーはそれに同期してはなりません。IEEE 1588-2019では、2段階とワンステップの両方のTimeTransmitterクロックをサポートするために、タイマーレシバークロックが必要であることに注意してください。[IEEE1588-2019]、サブクロース11.2を参照してください。
Since Announce messages are sent as multicast messages, timeReceivers can obtain the IP addresses of a timeTransmitter from the Announce messages. Note that the IP source addresses of Sync and Follow-up messages might have been replaced by the source addresses of a Transparent Clock; therefore, timeReceivers MUST send Delay Request messages to the IP address in the Announce message. Sync and Follow-up messages can be correlated with the Announce message using the Clock ID, which is never altered by Transparent Clocks in this PTP Profile.
アナウンスメッセージはマルチキャストメッセージとして送信されるため、TimereceiverはAnnounceメッセージからTimeTransmitterのIPアドレスを取得できます。同期とフォローアップメッセージのIPソースアドレスは、透明なクロックのソースアドレスに置き換えられた可能性があることに注意してください。したがって、Timereceiverは、発表メッセージのIPアドレスに遅延リクエストメッセージを送信する必要があります。同期およびフォローアップメッセージは、このPTPプロファイルの透明なクロックによって変更されることはありません。
Transparent Clocks MUST NOT change the transmission mode of an Enterprise Profile PTP message. For example, a Transparent Clock MUST NOT change a unicast message to a multicast message. Transparent Clocks that syntonize to the timeTransmitter Clock might need to maintain separate clock rate offsets for each of the supported domains.
透明なクロックは、エンタープライズプロファイルPTPメッセージの送信モードを変更してはなりません。たとえば、透明なクロックは、ユニキャストメッセージをマルチキャストメッセージに変更してはなりません。TimeTransmitterクロックにシングン化する透明なクロックは、サポートされている各ドメインの個別のクロックレートオフセットを維持する必要がある場合があります。
Boundary Clocks SHOULD support multiple simultaneous PTP domains. This will require them to maintain separate clocks for each of the domains supported, at least in software. Boundary Clocks MUST NOT combine timing information from different domains.
境界クロックは、複数の同時PTPドメインをサポートする必要があります。これには、少なくともソフトウェアでは、サポートされている各ドメインに対して個別のクロックを維持する必要があります。境界クロックは、異なるドメインからのタイミング情報を組み合わせてはなりません。
PTP management messages MAY be used. Management messages intended for a specific clock, i.e., where the targetPortIdentity.clockIdentity attribute (defined in [IEEE1588-2019]) does not have all bits set to 1, MUST be sent as a unicast message. Similarly, if any signaling messages are used, they MUST also be sent as unicast messages whenever the message is intended solely for a specific PTP Node.
PTP管理メッセージを使用できます。特定のクロックを対象とした管理メッセージ、つまり、ターゲットポートIdentity.clockidentity属性（[IEEE1588-2019]で定義）が1に設定されているわけではない場合、ユニキャストメッセージとしてすべてのビットを送信する必要があります。同様に、信号メッセージが使用される場合は、メッセージが特定のPTPノードのみを対象とする場合はいつでも、ユニキャストメッセージとして送信する必要があります。
Clocks operating in the Enterprise Profile MUST NOT use the following:
エンタープライズプロファイルで動作するクロックは、以下を使用してはなりません。
* Peer-to-Peer timing for delay measurement
* 遅延測定のためのピアツーピアタイミング
* Grandmaster Clusters
* グランドマスタークラスター
* The Alternate timeTransmitter option
* Alternate Timetransmitterオプション
* Alternate Timescales
* 代替タイムスケール
* Unicast discovery
* ユニキャストの発見
* Unicast message negotiation
* ユニキャストメッセージの交渉
Clocks operating in the Enterprise Profile MUST avoid any optional feature that requires Announce messages to be altered by Transparent Clocks, as this would require the Transparent Clock to change the source address and prevent the timeReceiver nodes from discovering the protocol address of the timeTransmitter.
エンタープライズプロファイルで動作するクロックは、透明なクロックによってメッセージを変更する必要があるオプションの機能を回避する必要があります。これには、透明なクロックがソースアドレスを変更し、タイムトラントライバーのプロトコルアドレスが発見されないようにするために透過的なクロックが必要です。
Clocks operating in the Enterprise Profile will interoperate with clocks operating in the Default Profile described in [IEEE1588-2019], Annex I.3. This variant of the Default Profile uses the End-to-End delay measurement mechanism. In addition, the Default Profile would have to operate over IPv4 or IPv6 networks and use management messages in unicast when those messages are directed at a specific clock. If neither of these requirements is met, then Enterprise Profile clocks will not interoperate with Default Profile clocks as defined in [IEEE1588-2019], Annex I.3. The Enterprise Profile will not interoperate with the variant of the Default Profile defined in [IEEE1588-2019], Annex I.4, which requires the use of the Peer-to-Peer delay measurement mechanism.
エンタープライズプロファイルで動作するクロックは、[IEEE1588-2019]で説明されているデフォルトプロファイルで動作するクロックと相互操作します。デフォルトプロファイルのこのバリアントは、エンドツーエンド遅延測定メカニズムを使用します。さらに、デフォルトのプロファイルは、IPv4またはIPv6ネットワークを介して動作し、特定のクロックに向けられている場合にユニキャストで管理メッセージを使用する必要があります。これらの要件のいずれも満たされていない場合、エンタープライズプロファイルクロックは、[IEEE1588-2019]で定義されているデフォルトのプロファイルクロックと相互運用しません。AnnexI.3。エンタープライズプロファイルは、[IEEE1588-2019]で定義されているデフォルトプロファイルのバリアントと相互運用しません。AnnexI.4は、ピアツーピア遅延測定メカニズムの使用を必要とします。
Enterprise Profile clocks will interoperate with clocks operating in other PTP Profiles if the clocks in the other PTP Profiles obey the rules of the Enterprise Profile. These rules MUST NOT be changed to achieve interoperability with other PTP Profiles.
エンタープライズプロファイルクロックは、他のPTPプロファイルのクロックがエンタープライズプロファイルのルールに従う場合、他のPTPプロファイルで動作するクロックと相互運用します。これらのルールは、他のPTPプロファイルとの相互運用性を達成するために変更してはなりません。
The IEEE 1588 standard requires that all PTP Profiles provide the following identifying information.
IEEE 1588規格では、すべてのPTPプロファイルが次の識別情報を提供することを要求しています。
PTP Profile:
PTPプロファイル：
Enterprise Profile
エンタープライズプロファイル
Profile number:
プロフィール番号：
1
1
Version:
バージョン：
1.0
1.0
Profile identifier:
プロファイル識別子：
00-00-5E-01-01-00
00-00-5E-01-01-00
This PTP Profile was specified by the IETF.
このPTPプロファイルは、IETFによって指定されました。
A copy may be obtained at <https://datatracker.ietf.org/wg/tictoc/ documents>.
コピーは、<https://datatracker.ietf.org/wg/tictoc/ documents>で取得できます。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
Protocols used to transfer time, such as PTP and NTP, can be important to security mechanisms that use time windows for keys and authorization. Passing time through the networks poses a security risk, since time can potentially be manipulated. The use of multiple simultaneous timeTransmitters, using multiple PTP domains, can mitigate problems from rogue timeTransmitters and on-path attacks. Note that Transparent Clocks alter PTP content on-path, but in a manner specified in [IEEE1588-2019] that helps with time transfer accuracy. See Sections 9 and 10. Additional security mechanisms are outside the scope of this document.
PTPやNTPなどの時間を転送するために使用されるプロトコルは、キーと承認に時間ウィンドウを使用するセキュリティメカニズムにとって重要です。ネットワークを通過すると、セキュリティリスクが発生します。これは、時間を操作できる可能性があるためです。複数のPTPドメインを使用した複数の同時のタイムトランジター機を使用すると、Rogue TimeTransmittersおよびPath攻撃からの問題を軽減できます。透明なクロックはPTPコンテンツをパス上に変更しますが、時間移動の精度に役立つ[IEEE1588-2019]で指定されている方法で注意してください。セクション9および10を参照してください。追加のセキュリティメカニズムは、このドキュメントの範囲外です。
PTP management messages SHOULD NOT be used, due to the lack of a security mechanism for this option. Secure management can be obtained using standard management mechanisms that include security -- for example, NETCONF [RFC6241].
このオプションのセキュリティメカニズムがないため、PTP管理メッセージは使用しないでください。安全な管理は、セキュリティを含む標準的な管理メカニズム（たとえば、NetConf [RFC6241]）を使用して取得できます。
General security considerations related to time protocols are discussed in [RFC7384].
時間プロトコルに関連する一般的なセキュリティ上の考慮事項は、[RFC7384]で説明されています。
[IEEE1588-2019]
IEEE, "IEEE Standard for a Precision Clock Synchronization
for Networked Measurement and Control Systems", IEEE
Std 1588-2019, DOI 10.1109/IEEESTD.2020.9120376, June
2020, <https://ieeexplore.ieee.org/document/9120376>.
[IEEE1588g]
IEEE, "IEEE Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems
Amendment 2: Master-Slave Optional Alternative
Terminology", IEEE Std 1588g-2022,
DOI 10.1109/IEEESTD.2023.10070440, March 2023,
<https://ieeexplore.ieee.org/document/10070440>.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
[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>.
[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>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[Estrela_and_Bonebakker]
Estrela, P. and L. Bonebakker, "Challenges deploying PTPv2
in a global financial company", Proceedings of the IEEE
International Symposium on Precision Clock Synchronization
for Measurement, Control and Communication, pp. 1-6,
DOI 10.1109/ISPCS.2012.6336634, September 2012,
<https://www.researchgate.net/publication/260742322_Challe
nges_deploying_PTPv2_in_a_global_financial_company>.
[G8271] ITU-T, "Time and phase synchronization aspects of
telecommunication networks", ITU-T
Recommendation G.8271/Y.1366, March 2020,
<https://www.itu.int/rec/T-REC-G.8271-202003-I/en>.
[IPv6Registry]
IANA, "IPv6 Multicast Address Space Registry",
<https://iana.org/assignments/ipv6-multicast-addresses>.
[ISPCS] Arnold, D. and K. Harris, "Plugfest", Proceedings of the
IEEE International Symposium on Precision Clock
Synchronization for Measurement, Control, and
Communication (ISPCS), August 2017,
<https://2017.ispcs.org/plugfest>.
[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>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <https://www.rfc-editor.org/info/rfc7384>.
The authors would like to thank Richard Cochran, Kevin Gross, John Fletcher, Laurent Montini, and many other members of the IETF for reviewing and providing feedback on this document.
著者は、リチャード・コクラン、ケビン・グロス、ジョン・フレッチャー、ローラン・モンティニ、およびこの文書に関するフィードバックをレビューして提供してくれたIETFの他の多くのメンバーに感謝したいと思います。
Doug Arnold
Meinberg-USA
3 Concord Rd
Shrewsbury, Massachusetts 01545
United States of America
Email: doug.arnold@meinberg-usa.com
Heiko Gerstung
Meinberg
Lange Wand 9
31812 Bad Pyrmont
Germany
Email: heiko.gerstung@meinberg.de