[要約] RFC 5905は、Network Time Protocol（NTP）バージョン4のプロトコルとアルゴリズムの仕様を定義しています。このRFCの目的は、正確な時刻同期を提供するためのNTPの機能と動作を明確にすることです。
Internet Engineering Task Force (IETF) D. Mills
Request for Comments: 5905 U. Delaware
Obsoletes: 1305, 4330 J. Martin, Ed.
Category: Standards Track ISC
ISSN: 2070-1721 J. Burbank
W. Kasch
JHU/APL
June 2010
Network Time Protocol Version 4: Protocol and Algorithms Specification
ネットワークタイムプロトコルバージョン4：プロトコルとアルゴリズムの仕様
Abstract
概要
The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified protocol header to accommodate the Internet Protocol version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism.
ネットワークタイムプロトコル（NTP）は、インターネットでコンピューターのクロックを同期するために広く使用されています。このドキュメントでは、RFC 1305で説明されているNTPバージョン3（NTPv3）と下位互換性のあるNTPバージョン4（NTPv4）と、プロトコルの以前のバージョンについて説明します。 NTPv4には、インターネットプロトコルバージョン6アドレスファミリに対応するために変更されたプロトコルヘッダーが含まれています。 NTPv4には、最新のワークステーションと高速LANを使用して、潜在的な精度を数十マイクロ秒に拡張する軽減および規律アルゴリズムの根本的な改善が含まれています。動的サーバー検出スキームが含まれているため、多くの場合、特定のサーバー構成は必要ありません。 NTPv3の設計と実装における特定のエラーを修正し、オプションの拡張メカニズムを含みます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5905.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc5905で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。この素材の一部で著作権を管理している人が、IETFトラストにそのような素材の変更を許可する権利を付与していない可能性がありますIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Requirements Notation ......................................5
2. Modes of Operation ..............................................6
3. Protocol Modes ..................................................6
3.1. Dynamic Server Discovery ...................................7
4. Definitions .....................................................8
5. Implementation Model ...........................................10
6. Data Types .....................................................12
7. Data Structures ................................................16
7.1. Structure Conventions .....................................16
7.2. Global Parameters .........................................16
7.3. Packet Header Variables ...................................17
7.4. The Kiss-o'-Death Packet ..................................24
7.5. NTP Extension Field Format ................................25
8. On-Wire Protocol ...............................................26
9. Peer Process ...................................................30
9.1. Peer Process Variables ....................................31
9.2. Peer Process Operations ...................................33
10. Clock Filter Algorithm ........................................37
11. System Process ................................................39
11.1. System Process Variables .................................40
11.2. System Process Operations ................................41
11.2.1. Selection Algorithm ...............................43
11.2.2. Cluster Algorithm .................................44
11.2.3. Combine Algorithm .................................45
11.3. Clock Discipline Algorithm ...............................47
12. Clock-Adjust Process ..........................................51
13. Poll Process ..................................................51
13.1. Poll Process Variables ...................................51
13.2. Poll Process Operations ..................................52
14. Simple Network Time Protocol (SNTP) ...........................54
15. Security Considerations .......................................55
16. IANA Considerations ...........................................58
17. Acknowledgements ..............................................59
18. References ....................................................59
18.1. Normative References .....................................59
18.2. Informative References ...................................59
Appendix A. Code Skeleton .......................................61
A.1. Global Definitions .......................................61
A.1.1. Definitions, Constants, Parameters .....................61
A.1.2. Packet Data Structures .................................65
A.1.3. Association Data Structures ............................66
A.1.4. System Data Structures .................................68
A.1.5. Local Clock Data Structures ............................69
A.1.6. Function Prototypes ....................................69
A.2. Main Program and Utility Routines ..........................70
A.3. Kernel Input/Output Interface ..............................73
A.4. Kernel System Clock Interface ..............................74
A.5. Peer Process ...............................................76
A.5.1. receive() ..............................................77
A.5.2. clock_filter() .........................................85
A.5.3. fast_xmit() ............................................88
A.5.4. access() ...............................................89
A.5.5. System Process .........................................90
A.5.6. Clock Adjust Process ..................................103
A.5.7. Poll Process ..........................................104
This document defines the Network Time Protocol version 4 (NTPv4), which is widely used to synchronize system clocks among a set of distributed time servers and clients. It describes the core architecture, protocol, state machines, data structures, and algorithms. NTPv4 introduces new functionality to NTPv3, as described in [RFC1305], and functionality expanded from Simple NTP version 4 (SNTPv4) as described in [RFC4330] (SNTPv4 is a subset of NTPv4). This document obsoletes [RFC1305] and [RFC4330]. While certain minor changes have been made in some protocol header fields, these do not affect the interoperability between NTPv4 and previous versions of NTP and SNTP.
このドキュメントでは、Network Time Protocolバージョン4（NTPv4）を定義しています。これは、一連の分散型タイムサーバーとクライアント間でシステムクロックを同期するために広く使用されています。コアアーキテクチャ、プロトコル、ステートマシン、データ構造、およびアルゴリズムについて説明します。 [RFC1305]で説明されているように、NTPv4はNTPv3に新しい機能を導入し、[RFC4330]で説明されているようにSimple NTPバージョン4（SNTPv4）から拡張された機能を提供します（SNTPv4はNTPv4のサブセットです）。このドキュメントは[RFC1305]と[RFC4330]を廃止しました。一部のプロトコルヘッダーフィールドで特定の小さな変更が行われましたが、これらはNTPv4と以前のバージョンのNTPおよびSNTP間の相互運用性には影響しません。
The NTP subnet model includes a number of widely accessible primary time servers synchronized by wire or radio to national standards. The purpose of the NTP protocol is to convey timekeeping information from these primary servers to secondary time servers and clients via both private networks and the public Internet. Precisely tuned algorithms mitigate errors that may result from network disruptions, server failures, and possible hostile actions. Servers and clients are configured such that values flow towards clients from the primary servers at the root via branching secondary servers.
NTPサブネットモデルには、有線または無線によって国家標準に同期された、広くアクセス可能な多数のプライマリタイムサーバーが含まれています。 NTPプロトコルの目的は、プライベートネットワークとパブリックインターネットの両方を介して、これらのプライマリサーバーからセカンダリタイムサーバーとクライアントに計時情報を伝達することです。正確に調整されたアルゴリズムは、ネットワークの中断、サーバーの障害、および起こり得る敵対的なアクションから生じる可能性のあるエラーを軽減します。サーバーとクライアントは、ルートにあるプライマリサーバーから分岐セカンダリサーバーを経由してクライアントに向かって値が流れるように構成されます。
The NTPv4 design overcomes significant shortcomings in the NTPv3 design, corrects certain bugs, and incorporates new features. In particular, expanded NTP timestamp definitions encourage the use of the floating double data type throughout the implementation. As a result, the time resolution is better than one nanosecond, and frequency resolution is less than one nanosecond per second. Additional improvements include a new clock discipline algorithm that is more responsive to system clock hardware frequency fluctuations. Typical primary servers using modern machines are precise within a few tens of microseconds. Typical secondary servers and clients on fast LANs are within a few hundred microseconds with poll intervals up to 1024 seconds, which was the maximum with NTPv3. With NTPv4, servers and clients are precise within a few tens of milliseconds with poll intervals up to 36 hours.
NTPv4デザインは、NTPv3デザインの重大な欠点を克服し、特定のバグを修正し、新しい機能を組み込んでいます。特に、拡張されたNTPタイムスタンプ定義により、実装全体で浮動doubleデータ型の使用が促進されます。その結果、時間分解能は1ナノ秒よりも優れており、周波数分解能は1ナノ秒/秒未満です。その他の改良点には、システムクロックハードウェアの周波数変動により敏感に反応する新しいクロックディシプリンアルゴリズムが含まれます。最新のマシンを使用する一般的なプライマリサーバーは、数十マイクロ秒以内で正確です。高速LAN上の一般的なセカンダリサーバーとクライアントは、数百マイクロ秒以内で、ポーリング間隔は最大1024秒で、これはNTPv3で最大でした。 NTPv4を使用すると、サーバーとクライアントは数十ミリ秒以内で正確になり、ポーリング間隔は最大36時間です。
The main body of this document describes the core protocol and data structures necessary to interoperate between conforming implementations. Appendix A contains a full-featured example in the form of a skeleton program, including data structures and code segments for the core algorithms as well as the mitigation algorithms used to enhance reliability and accuracy. While the skeleton program and other descriptions in this document apply to a particular implementation, they are not intended as the only way the required functions can be implemented. The contents of Appendix A are non-
このドキュメントの本文では、準拠する実装間で相互運用するために必要なコアプロトコルとデータ構造について説明します。付録Aには、コアアルゴリズムのデータ構造とコードセグメント、および信頼性と精度を高めるために使用される軽減アルゴリズムを含む、スケルトンプログラムの形でフル機能の例が含まれています。このドキュメントのスケルトンプログラムおよびその他の説明は特定の実装に適用されますが、必要な機能を実装できる唯一の方法として意図されたものではありません。付録Aの内容は、
normative examples designed to illustrate the protocol's operation and are not a requirement for a conforming implementation. While the NTPv3 symmetric key authentication scheme described in this document has been carried over from NTPv3, the Autokey public key authentication scheme new to NTPv4 is described in [RFC5906].
プロトコルの動作を説明するために設計された規範的な例であり、準拠する実装の要件ではありません。このドキュメントで説明されているNTPv3対称キー認証方式はNTPv3から引き継がれていますが、NTPv4の新しいAutokey公開キー認証方式は[RFC5906]で説明されています。
The NTP protocol includes modes of operation described in Section 2 using data types described in Section 6 and data structures described in Section 7. The implementation model described in Section 5 is based on a threaded, multi-process architecture, although other architectures could be used as well. The on-wire protocol described in Section 8 is based on a returnable-time design that depends only on measured clock offsets, but does not require reliable message delivery. Reliable message delivery such as TCP [RFC0793] can actually make the delivered NTP packet less reliable since retries would increase the delay value and other errors. The synchronization subnet is a self-organizing, hierarchical, master-slave network with synchronization paths determined by a shortest-path spanning tree and defined metric. While multiple masters (primary servers) may exist, there is no requirement for an election protocol.
NTPプロトコルには、セクション6で説明されているデータ型とセクション7で説明されているデータ構造を使用して、セクション2で説明されている動作モードが含まれています。セクション5で説明されている実装モデルは、スレッド化されたマルチプロセスアーキテクチャに基づいていますが、他のアーキテクチャも使用できます。同じように。セクション8で説明されているオンワイヤプロトコルは、測定されたクロックオフセットのみに依存する返却可能時間の設計に基づいていますが、信頼性の高いメッセージ配信を必要としません。 TCP [RFC0793]などの信頼性の高いメッセージ配信では、再試行によって遅延値やその他のエラーが増えるため、配信されたNTPパケットの信頼性が実際に低下する可能性があります。同期サブネットは、最短パススパニングツリーと定義されたメトリックによって決定される同期パスを持つ、自己組織化された階層的なマスタースレーブネットワークです。複数のマスター（プライマリサーバー）が存在する場合がありますが、選択プロトコルは必要ありません。
This document includes material from [ref9], which contains flow charts and equations unsuited for RFC format. There is much additional information in [ref7], including an extensive technical analysis and performance assessment of the protocol and algorithms in this document. The reference implementation is available at www.ntp.org.
このドキュメントには、[ref9]の資料が含まれており、RFC形式には適さないフローチャートと方程式が含まれています。 [ref7]には、このドキュメントのプロトコルとアルゴリズムの広範な技術分析とパフォーマンス評価を含む多くの追加情報があります。リファレンス実装は、www.ntp.orgから入手できます。
The remainder of this document contains numerous variables and mathematical expressions. Some variables take the form of Greek characters, which are spelled out by their full case-sensitive name. For example, DELTA refers to the uppercase Greek character, while delta refers to the lowercase character. Furthermore, subscripts are denoted with '_'; for example, theta_i refers to the lowercase Greek character theta with subscript i, or phonetically theta sub i. In this document, all time values are in seconds (s), and all frequencies will be specified as fractional frequency offsets (FFOs) (pure number). It is often convenient to express these FFOs in parts per million (ppm).
このドキュメントの残りの部分には、多数の変数と数式が含まれています。一部の変数はギリシャ文字の形式を取り、大文字と小文字が区別される完全な名前で綴られます。たとえば、DELTAはギリシャ語の大文字を指し、deltaは小文字を指します。さらに、添え字は「_」で示されます。たとえば、theta_iはギリシャ語の小文字thetaに下付き文字iを付けたもの、または音声学的にtheta sub iを指します。このドキュメントでは、すべての時間値は秒（s）単位であり、すべての周波数は分数周波数オフセット（FFO）（純粋な数）として指定されます。多くの場合、これらのFFOを100万分の1（ppm）で表すと便利です。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
An NTP implementation operates as a primary server, secondary server, or client. A primary server is synchronized to a reference clock directly traceable to UTC (e.g., GPS, Galileo, etc.). A client synchronizes to one or more upstream servers, but does not provide synchronization to dependent clients. A secondary server has one or more upstream servers and one or more downstream servers or clients. All servers and clients who are fully NTPv4-compliant MUST implement the entire suite of algorithms described in this document. In order to maintain stability in large NTP subnets, secondary servers SHOULD be fully NTPv4-compliant. Alternative algorithms MAY be used, but their output MUST be identical to the algorithms described in this specification.
NTP実装は、プライマリサーバー、セカンダリサーバー、またはクライアントとして動作します。プライマリサーバーは、UTCに直接追跡可能な基準クロック（GPS、Galileoなど）に同期されます。クライアントは1つ以上の上流サーバーと同期しますが、依存するクライアントには同期を提供しません。セカンダリサーバーには、1つ以上のアップストリームサーバーと1つ以上のダウンストリームサーバーまたはクライアントがあります。完全にNTPv4に準拠しているすべてのサーバーとクライアントは、このドキュメントで説明されている一連のアルゴリズム全体を実装する必要があります。大規模なNTPサブネットで安定性を維持するために、セカンダリサーバーは完全にNTPv4に準拠している必要があります。代替アルゴリズムが使用される場合がありますが、それらの出力は、この仕様で説明されているアルゴリズムと同一である必要があります。
There are three NTP protocol variants: symmetric, client/server, and broadcast. Each is associated with an association mode (a description of the relationship between two NTP speakers) as shown in Figure 1. In addition, persistent associations are mobilized upon startup and are never demobilized. Ephemeral associations are mobilized upon the arrival of a packet and are demobilized upon error or timeout.
NTPプロトコルには、対称型、クライアント/サーバー型、ブロードキャスト型の3種類があります。図1に示すように、それぞれがアソシエーションモード（2つのNTPスピーカー間の関係の説明）に関連付けられています。さらに、永続的なアソシエーションは起動時に動員され、決して動員解除されません。エフェメラルアソシエーションは、パケットの到着時にモバイル化され、エラーまたはタイムアウト時に非モバイル化されます。
+-------------------+-------------------+------------------+
| Association Mode | Assoc. Mode Value | Packet Mode Value|
+-------------------+-------------------+------------------+
| Symmetric Active | 1 | 1 or 2 |
| Symmetric Passive | 2 | 1 |
| Client | 3 | 4 |
| Server | 4 | 3 |
| Broadcast Server | 5 | 5 |
| Broadcast Client | 6 | N/A |
+-------------------+-------------------+------------------+
Figure 1: Association and Packet Modes
図1：アソシエーションとパケットモード
In the client/server variant, a persistent client sends packet mode 4 packets to a server, which returns packet mode 3 packets. Servers provide synchronization to one or more clients, but do not accept synchronization from them. A server can also be a reference clock driver that obtains time directly from a standard source such as a GPS receiver or telephone modem service. In this variant, clients pull synchronization from servers.
クライアント/サーバーバリアントでは、永続クライアントがパケットモード4パケットをサーバーに送信し、サーバーはパケットモード3パケットを返します。サーバーは1つ以上のクライアントに同期を提供しますが、クライアントからの同期は受け入れません。サーバーは、GPSレシーバーや電話モデムサービスなどの標準ソースから直接時刻を取得する基準クロックドライバーにすることもできます。このバリアントでは、クライアントはサーバーから同期をプルします。
In the symmetric variant, a peer operates as both a server and client using either a symmetric active or symmetric passive association. A persistent symmetric active association sends symmetric active (mode 1) packets to a symmetric active peer association. Alternatively, an ephemeral symmetric passive association can be mobilized upon the arrival of a symmetric active packet with no matching association. That association sends symmetric passive (mode 2) packets and persists until error or timeout. Peers both push and pull synchronization to and from each other. For the purposes of this document, a peer operates like a client, so references to client imply peer as well.
対称バリアントでは、ピアは、対称アクティブまたは対称パッシブアソシエーションを使用して、サーバーとクライアントの両方として動作します。永続的な対称アクティブアソシエーションは、対称アクティブ（モード1）パケットを対称アクティブピアアソシエーションに送信します。代わりに、エフェメラル対称パッシブアソシエーションは、一致するアソシエーションのない対称アクティブパケットの到着時にモバイル化できます。その関連付けは、対称パッシブ（モード2）パケットを送信し、エラーまたはタイムアウトになるまで持続します。ピアは、相互に同期をプッシュおよびプルします。このドキュメントでは、ピアはクライアントのように動作するため、クライアントへの参照はピアも意味します。
In the broadcast variant, a persistent broadcast server association sends periodic broadcast server (mode 5) packets that can be received by multiple clients. Upon reception of a broadcast server packet without a matching association, an ephemeral broadcast client (mode 6) association is mobilized and persists until error or timeout. It is useful to provide an initial volley where the client operating in client mode exchanges several packets with the server, so as to calibrate the propagation delay and to run the Autokey security protocol, after which the client reverts to broadcast client mode. A broadcast server pushes synchronization to clients and other servers.
ブロードキャストバリアントでは、永続的なブロードキャストサーバーアソシエーションが、複数のクライアントが受信できるブロードキャストサーバー（モード5）パケットを定期的に送信します。一致するアソシエーションのないブロードキャストサーバーパケットを受信すると、エフェメラルブロードキャストクライアント（モード6）アソシエーションが動員され、エラーまたはタイムアウトになるまで持続します。クライアントモードで動作しているクライアントがサーバーといくつかのパケットを交換する最初のボレーを提供して、伝播遅延を調整し、Autokeyセキュリティプロトコルを実行すると、クライアントはブロードキャストクライアントモードに戻ります。ブロードキャストサーバーは、クライアントと他のサーバーに同期をプッシュします。
Loosely following the conventions established by the telephone industry, the level of each server in the hierarchy is defined by a stratum number. Primary servers are assigned stratum one; secondary servers at each lower level are assigned stratum numbers one greater than the preceding level. As the stratum number increases, its accuracy degrades depending on the particular network path and system clock stability. Mean errors, measured by synchronization distances, increase approximately in proportion to stratum numbers and measured round-trip delay.
電話業界によって確立された規則に緩やかに従うと、階層内の各サーバーのレベルは階層番号によって定義されます。プライマリサーバーには層1が割り当てられます。各下位レベルのセカンダリサーバーには、前のレベルよりも1つ大きいストラタム番号が割り当てられます。ストラタム番号が増えると、特定のネットワークパスとシステムクロックの安定性に応じて、精度が低下します。同期距離で測定された平均誤差は、層数と測定された往復遅延にほぼ比例して増加します。
As a standard practice, timing network topology should be organized to avoid timing loops and minimize the synchronization distance. In NTP, the subnet topology is determined using a variant of the Bellman-Ford distributed routing algorithm, which computes the shortest-path spanning tree rooted on the primary servers. As a result of this design, the algorithm automatically reorganizes the subnet, so as to produce the most accurate and reliable time, even when there are failures in the timing network.
標準的な方法として、タイミングループを回避し、同期距離を最小化するために、タイミングネットワークトポロジを編成する必要があります。 NTPでは、サブネットトポロジはBellman-Ford分散ルーティングアルゴリズムのバリアントを使用して決定されます。これは、プライマリサーバーをルートとする最短パススパニングツリーを計算します。この設計の結果、アルゴリズムはサブネットを自動的に再編成し、タイミングネットワークに障害が発生した場合でも、最も正確で信頼できる時間を生成します。
There are two special associations, manycast client and manycast server, which provide a dynamic server discovery function. There are two types of manycast client associations: persistent and ephemeral. The persistent manycast client sends client (mode 3) packets to a designated IPv4 or IPv6 broadcast or multicast group address. Designated manycast servers within range of the time-to-live (TTL) field in the packet header listen for packets with that address. If a server is suitable for synchronization, it returns an ordinary server (mode 4) packet using the client's unicast address. Upon receiving this packet, the client mobilizes an ephemeral client (mode 3) association. The ephemeral client association persists until error or timeout.
動的サーバー検出機能を提供するメニーキャストクライアントとメニーキャストサーバーの2つの特別な関連付けがあります。メニーキャストクライアントアソシエーションには、永続的とエフェメラルの2つのタイプがあります。永続的メニーキャストクライアントは、指定されたIPv4またはIPv6ブロードキャストまたはマルチキャストグループアドレスにクライアント（モード3）パケットを送信します。パケットヘッダーの存続可能時間（TTL）フィールドの範囲内にある指定されたメニーキャストサーバーは、そのアドレスを持つパケットをリッスンします。サーバーが同期に適している場合、サーバーはクライアントのユニキャストアドレスを使用して通常のサーバー（モード4）パケットを返します。このパケットを受信すると、クライアントは一時的なクライアント（モード3）アソシエーションを動員します。エフェメラルクライアントの関連付けは、エラーまたはタイムアウトになるまで持続します。
A manycast client continues sending packets to search for a minimum number of associations. It starts with a TTL equal to one and continuously adding one to it until the minimum number of associations is made or when the TTL reaches a maximum value. If the TTL reaches its maximum value and yet not enough associations are mobilized, the client stops transmission for a time-out period to clear all associations, and then repeats the search cycle. If a minimum number of associations has been mobilized, then the client starts transmitting one packet per time-out period to maintain the associations. Field constraints limit the minimum value to 1 and the maximum to 255. These limits may be tuned for individual application needs.
メニーキャストクライアントは、最小数のアソシエーションを検索するためにパケットを送信し続けます。それは、1に等しいTTLで始まり、関連付けの最小数が作成されるか、TTLが最大値に達するまで、それに1を継続的に追加します。 TTLが最大値に達してもアソシエーションが十分に動員されない場合、クライアントはタイムアウト期間に送信を停止してすべてのアソシエーションをクリアしてから、検索サイクルを繰り返します。最小数のアソシエーションが動員された場合、クライアントはアソシエーションを維持するためにタイムアウト期間ごとに1つのパケットの送信を開始します。フィールド制約は、最小値を1に、最大値を255に制限します。これらの制限は、個々のアプリケーションのニーズに合わせて調整できます。
The ephemeral associations compete among themselves. As new ephemeral associations are mobilized, the client runs the mitigation algorithms described in Sections 10 and 11.2 for the best candidates out of the population, the remaining ephemeral associations are timed out and demobilized. In this way, the population includes only the best candidates that have most recently responded with an NTP packet to discipline the system clock.
短命の協会は彼らの間で競争します。新しい一時的な関連付けが動員されると、クライアントはセクション10と11.2で説明されている緩和アルゴリズムを実行して、母集団からの最適な候補を求めます。残りの一時的な関連付けはタイムアウトし、動員解除されます。このようにして、母集団には、システムクロックを統制するために最近NTPパケットで応答した最良の候補のみが含まれます。
A number of technical terms are defined in this section. A timescale is a frame of reference where time is expressed as the value of a monotonically increasing binary counter with an indefinite number of bits. It counts in seconds and fractions of a second, when a decimal point is employed. The Coordinated Universal Time (UTC) timescale is defined by ITU-R TF.460 [ITU-R_TF.460]. Under the auspices of the Metre Convention of 1865, in 1975 the CGPM [CGPM] strongly endorsed the use of UTC as the basis for civil time.
このセクションでは、いくつかの専門用語が定義されています。タイムスケールは、時間のフレームが不明確な単調増加するバイナリカウンターの値として表される基準のフレームです。小数点が採用されている場合は、秒単位および秒単位でカウントされます。協定世界時（UTC）タイムスケールは、ITU-R TF.460 [ITU-R_TF.460]によって定義されています。 1865年のメートル条約の後援のもと、1975年にCGPM [CGPM]は、市民時間の基盤としてのUTCの使用を強く支持しました。
The Coordinated Universal Time (UTC) timescale represents mean solar time as disseminated by national standards laboratories. The system time is represented by the system clock maintained by the hardware and operating system. The goal of the NTP algorithms is to minimize both the time difference and frequency difference between UTC and the system clock. When these differences have been reduced below nominal tolerances, the system clock is said to be synchronized to UTC.
協定世界時（UTC）タイムスケールは、国家標準研究所によって配布された平均太陽時を表します。システム時間は、ハードウェアとオペレーティングシステムによって維持されるシステムクロックによって表されます。 NTPアルゴリズムの目的は、UTCとシステムクロック間の時間差と周波数差の両方を最小限に抑えることです。これらの違いが公称許容値を下回った場合、システムクロックはUTCに同期していると言います。
The date of an event is the UTC time at which the event takes place. Dates are ephemeral values designated with uppercase T. Running time is another timescale that is coincident to the synchronization function of the NTP program.
イベントの日付は、イベントが発生するUTC時間です。日付は、大文字のTで指定された一時的な値です。実行時間は、NTPプログラムの同期機能と一致する別のタイムスケールです。
A timestamp T(t) represents either the UTC date or time offset from UTC at running time t. Which meaning is intended should be clear from the context. Let T(t) be the time offset, R(t) the frequency offset, and D(t) the aging rate (first derivative of R(t) with respect to t). Then, if T(t_0) is the UTC time offset determined at t = t_0, the UTC time offset at time t is
タイムスタンプT（t）は、実行時間tでのUTCからのUTC日付または時間オフセットのいずれかを表します。どの意味が意図されているかは、文脈から明確でなければなりません。 T（t）を時間オフセット、R（t）を周波数オフセット、D（t）をエージングレート（R（t）のtに関する1次導関数）とします。次に、T（t_0）がt = t_0で決定されたUTC時間オフセットである場合、時間tでのUTC時間オフセットは
T(t) = T(t_0) + R(t_0)(t-t_0) + 1/2 * D(t_0)(t-t_0)^2 + e,
T（t）= T（t_0）+ R（t_0）（t-t_0）+ 1/2 * D（t_0）（t-t_0）^ 2 + e、
where e is a stochastic error term discussed later in this document. While the D(t) term is important when characterizing precision oscillators, it is ordinarily neglected for computer oscillators. In this document, all time values are in seconds (s) and all frequency values are in seconds-per-second (s/s). It is sometimes convenient to express frequency offsets in parts-per-million (ppm), where 1 ppm is equal to 10^(-6) s/s.
ここで、eは、このドキュメントの後半で説明する確率誤差の項です。 D（t）項は、高精度発振器を特徴付けるときに重要ですが、通常、コンピュータ発振器では無視されます。このドキュメントでは、すべての時間の値は秒（s）であり、すべての頻度の値は秒/秒（s / s）です。周波数オフセットを100万分の1（ppm）で表すと便利な場合があります。1ppmは10 ^（-6）s / sに相当します。
It is important in computer timekeeping applications to assess the performance of the timekeeping function. The NTP performance model includes four statistics that are updated each time a client makes a measurement with a server. The offset (theta) represents the maximum-likelihood time offset of the server clock relative to the system clock. The delay (delta) represents the round-trip delay between the client and server. The dispersion (epsilon) represents the maximum error inherent in the measurement. It increases at a rate equal to the maximum disciplined system clock frequency tolerance (PHI), typically 15 ppm. The jitter (psi) is defined as the root-mean-square (RMS) average of the most recent offset differences, and it represents the nominal error in estimating the offset.
コンピュータの計時アプリケーションでは、計時機能のパフォーマンスを評価することが重要です。 NTPパフォーマンスモデルには、クライアントがサーバーで測定を行うたびに更新される4つの統計が含まれます。オフセット（theta）は、システムクロックに対するサーバークロックの最尤時間オフセットを表します。遅延（デルタ）は、クライアントとサーバー間の往復遅延を表します。分散（イプシロン）は、測定に固有の最大誤差を表します。これは、規律のある最大システムクロック周波数許容値（PHI）（通常15 ppm）に等しいレートで増加します。ジッター（psi）は、最新のオフセット差の二乗平均（RMS）平均として定義され、オフセットの推定における公称誤差を表します。
While the theta, delta, epsilon, and psi statistics represent measurements of the system clock relative to each server clock separately, the NTP protocol includes mechanisms to combine the statistics of several servers to more accurately discipline and calibrate the system clock. The system offset (THETA) represents the maximum-likelihood offset estimate for the server population. The system jitter (PSI) represents the nominal error in estimating the system offset. The delta and epsilon statistics are accumulated at each stratum level from the reference clock to produce the root delay (DELTA) and root dispersion (EPSILON) statistics. The synchronization distance (LAMBDA) equal to EPSILON + DELTA / 2 represents the maximum error due to all causes. The detailed formulations of these statistics are given in Section 11.2. They are available to the dependent applications in order to assess the performance of the synchronization function.
シータ、デルタ、イプシロン、プサイの統計は、各サーバークロックに対するシステムクロックの測定値を個別に表しますが、NTPプロトコルには、複数のサーバーの統計を組み合わせてシステムクロックをより正確に統制および調整するメカニズムが含まれています。システムオフセット（THETA）は、サーバー母集団の最尤オフセット推定値を表します。システムジッタ（PSI）は、システムオフセットの推定における公称誤差を表します。デルタおよびイプシロン統計は、基準クロックからの各階層レベルで累積され、ルート遅延（DELTA）およびルート分散（EPSILON）統計を生成します。 EPSILON + DELTA / 2に等しい同期距離（LAMBDA）は、すべての原因による最大誤差を表します。これらの統計の詳細な定式化はセクション11.2に記載されています。これらは、同期機能のパフォーマンスを評価するために、依存アプリケーションで使用できます。
Figure 2 shows the architecture of a typical, multi-threaded implementation. It includes two processes dedicated to each server, a peer process to receive messages from the server or reference clock, and a poll process to transmit messages to the server or reference clock.
図2は、典型的なマルチスレッド実装のアーキテクチャを示しています。各サーバー専用の2つのプロセス、サーバーまたは基準クロックからメッセージを受信するピアプロセス、およびサーバーまたは基準クロックにメッセージを送信するポーリングプロセスが含まれます。
.....................................................................
. Remote . Peer/Poll . System . Clock .
. Servers . Processes . Process .Discipline.
. . . . Process .
.+--------+. +-----------+. +------------+ . .
.| |->| |. | | . .
.|Server 1| |Peer/Poll 1|->| | . .
.| |<-| |. | | . .
.+--------+. +-----------+. | | . .
. . ^ . | | . .
. . | . | | . .
.+--------+. +-----------+. | | +-----------+. .
.| |->| |. | Selection |->| |. +------+ .
.|Server 2| |Peer/Poll 2|->| and | | Combine |->| Loop | .
.| |<-| |. | Cluster | | Algorithm |. |Filter| .
.+--------+. +-----------+. | Algorithms |->| |. +------+ .
. . ^ . | | +-----------+. | .
. . | . | | . | .
.+--------+. +-----------+. | | . | .
.| |->| |. | | . | .
.|Server 3| |Peer/Poll 3|->| | . | .
.| |<-| |. | | . | .
.+--------+. +-----------+. +------------+ . | .
....................^.........................................|......
| . V .
| . +-----+ .
+--------------------------------------| VFO | .
. +-----+ .
. Clock .
. Adjust .
. Process .
............
Figure 2: Implementation Model
図2：実装モデル
These processes operate on a common data structure, called an association, which contains the statistics described above along with various other data described in Section 9. A client sends packets to one or more servers and then processes returned packets when they are received. The server interchanges source and destination addresses and ports, overwrites certain fields in the packet and returns it immediately (in the client/server mode) or at some time later (in the symmetric modes). As each NTP message is received, the offset theta between the peer clock and the system clock is computed along with the associated statistics delta, epsilon, and psi.
これらのプロセスは、アソシエーションと呼ばれる共通のデータ構造で動作します。これには、セクション9で説明した他のさまざまなデータとともに上記の統計が含まれます。クライアントは1つ以上のサーバーにパケットを送信し、返されたパケットを受信すると処理します。サーバーは、送信元と宛先のアドレスとポートを交換し、パケットの特定のフィールドを上書きして、すぐに（クライアント/サーバーモードの場合）、または後で（対称モードの場合）返します。各NTPメッセージが受信されると、ピアクロックとシステムクロックの間のオフセットシータが、関連する統計デルタ、イプシロン、およびpsiとともに計算されます。
The system process includes the selection, cluster, and combine algorithms that mitigate among the various servers and reference clocks to determine the most accurate and reliable candidates to synchronize the system clock. The selection algorithm uses Byzantine fault detection principles to discard the presumably incorrect candidates called "falsetickers" from the incident population, leaving only good candidates called "truechimers". A truechimer is a clock that maintains timekeeping accuracy to a previously published and trusted standard, while a falseticker is a clock that shows misleading or inconsistent time. The cluster algorithm uses statistical principles to find the most accurate set of truechimers. The combine algorithm computes the final clock offset by statistically averaging the surviving truechimers.
システムプロセスには、システムクロックを同期するための最も正確で信頼性の高い候補を決定するために、さまざまなサーバーと基準クロックの間で軽減する選択、クラスター、および結合アルゴリズムが含まれます。選択アルゴリズムは、ビザンチン障害検出原理を使用して、「偽ティッカー」と呼ばれるおそらく正しくない候補をインシデント集団から破棄し、「真のキメラ」と呼ばれる適切な候補のみを残します。 truechimerは、以前に公開され信頼された標準に合わせて計時精度を維持する時計であり、falsetickerは、誤解を招く、または一貫性のない時間を示す時計です。クラスターアルゴリズムは、統計原理を使用して、最も正確なtruechimersのセットを見つけます。結合アルゴリズムは、残存する真のキメラを統計的に平均化することにより、最終クロックオフセットを計算します。
The clock discipline process is a system process that controls the time and frequency of the system clock, here represented as a variable frequency oscillator (VFO). Timestamps struck from the VFO close the feedback loop that maintains the system clock time. Associated with the clock discipline process is the clock-adjust process, which runs once each second to inject a computed time offset and maintain constant frequency. The RMS average of past time offset differences represents the nominal error or system clock jitter. The RMS average of past frequency offset differences represents the oscillator frequency stability or frequency wander. These terms are given precise interpretation in Section 11.3.
クロック規律プロセスは、システムクロックの時間と周波数を制御するシステムプロセスであり、ここでは可変周波数発振器（VFO）として表されます。 VFOから打たれたタイムスタンプは、システムクロック時間を維持するフィードバックループを閉じます。クロック調整プロセスに関連付けられているのはクロック調整プロセスで、毎秒1回実行され、計算された時間オフセットを注入して一定の周波数を維持します。過去の時間オフセットの差のRMS平均は、公称エラーまたはシステムクロックジッタを表します。過去の周波数オフセットの差のRMS平均は、発振器の周波数安定性または周波数ワンダーを表します。これらの用語は、セクション11.3で正確に解釈されます。
A client sends messages to each server with a poll interval of 2^tau seconds, as determined by the poll exponent tau. In NTPv4, tau ranges from 4 (16 s) to 17 (36 h). The value of tau is determined by the clock discipline algorithm to match the loop-time constant T_c = 2^tau. In client/server mode, the server responds immediately; however, in symmetric modes, each of two peers manages tau as a function of current system offset and system jitter, so they may not agree with the same value. It is important that the dynamic behavior of the clock discipline algorithm be carefully controlled in order to maintain stability in the NTP subnet at large. This requires that the peers agree on a common tau equal to the minimum poll exponent of both peers. The NTP protocol includes provisions to properly negotiate this value.
クライアントは、ポーリング指数tauによって決定される2 ^ tau秒のポーリング間隔で各サーバーにメッセージを送信します。 NTPv4では、タウの範囲は4（16秒）〜17（36時間）です。 tauの値は、ループ時定数T_c = 2 ^ tauに一致するように、クロック規律アルゴリズムによって決定されます。クライアント/サーバーモードでは、サーバーは即座に応答します。ただし、対称モードでは、2つのピアのそれぞれが現在のシステムオフセットとシステムジッタの関数としてタウを管理するため、同じ値に一致しない場合があります。 NTPサブネット全体の安定性を維持するために、クロック規律アルゴリズムの動的動作を慎重に制御することが重要です。これには、ピアが両方のピアの最小ポーリング指数に等しい共通のタウに同意する必要があります。 NTPプロトコルには、この値を適切にネゴシエートするためのプロビジョニングが含まれています。
The implementation model includes some means to set and adjust the system clock. The operating system is assumed to provide two functions: one to set the time directly, for example, the Unix settimeofday() function, and another to adjust the time in small increments advancing or retarding the time by a designated amount, for example, the Unix adjtime() function. In this and following references, parentheses following a name indicate reference to a function rather than a simple variable. In the intended design the clock discipline process uses the adjtime() function if the adjustment is less than a designated threshold, and the settimeofday() function if above the threshold. The manner in which this is done and the value of the threshold as described in Section 10.
実装モデルには、システムクロックを設定および調整する手段がいくつか含まれています。オペレーティングシステムは2つの機能を提供すると想定されます。1つは時間を直接設定するもので、たとえば、Unixのsettimeofday()関数です。もう1つは、時間を指定された量だけ少しずつ進めたり遅らせたりして、時間を調整します。たとえば、 Unix adjtime()関数。この参照および以下の参照では、名前の後の括弧は、単純な変数ではなく関数への参照を示しています。意図された設計では、クロック調整プロセスは、調整が指定されたしきい値より小さい場合はadjtime()関数を使用し、しきい値を超える場合はsettimeofday()関数を使用します。これを実行する方法と、セクション10で説明されているしきい値の値。
All NTP time values are represented in twos-complement format, with bits numbered in big-endian (as described in Appendix A of [RFC0791]) fashion from zero starting at the left, or high-order, position. There are three NTP time formats, a 128-bit date format, a 64-bit timestamp format, and a 32-bit short format, as shown in Figure 3. The 128-bit date format is used where sufficient storage and word size are available. It includes a 64-bit signed seconds field spanning 584 billion years and a 64-bit fraction field resolving .05 attosecond (i.e., 0.5e-18). For convenience in mapping between formats, the seconds field is divided into a 32-bit Era Number field and a 32-bit Era Offset field. Eras cannot be produced by NTP directly, nor is there need to do so. When necessary, they can be derived from external means, such as the filesystem or dedicated hardware.
すべてのNTP時間値は2の補数形式で表され、ビットはビッグエンディアン（[RFC0791]の付録Aで説明）のように、左から始まるゼロまたは高位の位置から番号が付けられます。図3に示すように、3つのNTP時間形式、128ビットの日付形式、64ビットのタイムスタンプ形式、および32ビットの短い形式があります。128ビットの日付形式は、十分なストレージとワードサイズがある場合に使用されます。利用可能です。これには、5,840億年にわたる64ビット符号付き秒フィールドと、.05アト秒（つまり、0.5e-18）を解決する64ビット小数フィールドが含まれます。フォーマット間のマッピングを簡単にするために、秒フィールドは32ビットの元号フィールドと32ビットの元号オフセットフィールドに分かれています。 NTPで時代を直接作成することはできません。また、作成する必要もありません。必要に応じて、ファイルシステムや専用ハードウェアなどの外部手段から派生させることができます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds | Fraction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NTP Short Format
NTPの短い形式
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fraction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NTP Timestamp Format
NTPタイムスタンプ形式
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Era Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Era Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Fraction |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NTP Date Format
NTP日付形式
Figure 3: NTP Time Formats
図3：NTP時間形式
The 64-bit timestamp format is used in packet headers and other places with limited word size. It includes a 32-bit unsigned seconds field spanning 136 years and a 32-bit fraction field resolving 232 picoseconds. The 32-bit short format is used in delay and dispersion header fields where the full resolution and range of the other formats are not justified. It includes a 16-bit unsigned seconds field and a 16-bit fraction field.
64ビットのタイムスタンプ形式は、パケットヘッダーなど、ワードサイズが制限されている場所で使用されます。これには、136年にわたる32ビットの符号なし秒フィールドと、232ピコ秒を解決する32ビットの小数フィールドが含まれます。 32ビットの短い形式は、他の形式の完全な解像度と範囲が正当化されない遅延および分散ヘッダーフィールドで使用されます。これには、16ビットの符号なし秒フィールドと16ビットの小数フィールドが含まれます。
In the date and timestamp formats, the prime epoch, or base date of era 0, is 0 h 1 January 1900 UTC, when all bits are zero. It should be noted that strictly speaking, UTC did not exist prior to 1 January 1972, but it is convenient to assume it has existed for all eternity, even if all knowledge of historic leap seconds has been lost. Dates are relative to the prime epoch; values greater than zero represent times after that date; values less than zero represent times before it. Note that the Era Offset field of the date format and the Seconds field of the timestamp format have the same interpretation.
日付とタイムスタンプの形式では、すべてのビットがゼロの場合、プライムエポック、つまり元号0の基準日は1900年1月1日0 h 1です。厳密に言うと、UTCは1972年1月1日より前には存在しませんでしたが、歴史的なうるう秒に関するすべての知識が失われたとしても、それが永遠に存在すると仮定するのが便利です。日付はプライムエポックを基準にしています。ゼロより大きい値は、その日付以降の時間を表します。ゼロ未満の値は、その前の時間を表します。日付形式の元号オフセットフィールドとタイムスタンプ形式の秒フィールドの解釈は同じであることに注意してください。
Timestamps are unsigned values, and operations on them produce a result in the same or adjacent eras. Era 0 includes dates from the prime epoch to some time in 2036, when the timestamp field wraps around and the base date for era 1 is established. In either format, a value of zero is a special case representing unknown or unsynchronized time. Figure 4 shows a number of historic NTP dates together with their corresponding Modified Julian Day (MJD), NTP era, and NTP timestamp.
タイムスタンプは符号なしの値であり、それらに対する操作は同じまたは隣接する時代の結果を生成します。時代0には、タイムスタンプフィールドが循環し、時代1の基準日が確立される、2036年のプライムエポックからある時期までの日付が含まれます。どちらの形式でも、ゼロの値は、不明な時刻または同期されていない時刻を表す特殊なケースです。図4は、いくつかの歴史的なNTP日付と、対応する修正ユリウス日（MJD）、NTP時代、およびNTPタイムスタンプを示しています。
+-------------+------------+-----+---------------+------------------+
| Date | MJD | NTP | NTP Timestamp | Epoch |
| | | Era | Era Offset | |
+-------------+------------+-----+---------------+------------------+
| 1 Jan -4712 | -2,400,001 | -49 | 1,795,583,104 | 1st day Julian |
| 1 Jan -1 | -679,306 | -14 | 139,775,744 | 2 BCE |
| 1 Jan 0 | -678,491 | -14 | 171,311,744 | 1 BCE |
| 1 Jan 1 | -678,575 | -14 | 202,939,144 | 1 CE |
| 4 Oct 1582 | -100,851 | -3 | 2,873,647,488 | Last day Julian |
| 15 Oct 1582 | -100,840 | -3 | 2,874,597,888 | First day |
| | | | | Gregorian |
| 31 Dec 1899 | 15019 | -1 | 4,294,880,896 | Last day NTP Era |
| | | | | -1 |
| 1 Jan 1900 | 15020 | 0 | 0 | First day NTP |
| | | | | Era 0 |
| 1 Jan 1970 | 40,587 | 0 | 2,208,988,800 | First day UNIX |
| 1 Jan 1972 | 41,317 | 0 | 2,272,060,800 | First day UTC |
| 31 Dec 1999 | 51,543 | 0 | 3,155,587,200 | Last day 20th |
| | | | | Century |
| 8 Feb 2036 | 64,731 | 1 | 63,104 | First day NTP |
| | | | | Era 1 |
+-------------+------------+-----+---------------+------------------+
Figure 4: Interesting Historic NTP Dates
図4：興味深い歴史的NTP日付
Let p be the number of significant bits in the second fraction. The clock resolution is defined as 2^(-p), in seconds. In order to minimize bias and help make timestamps unpredictable to an intruder, the non-significant bits should be set to an unbiased random bit string. The clock precision is defined as the running time to read the system clock, in seconds. Note that the precision defined in this way can be larger or smaller than the resolution. The term rho, representing the precision used in the protocol, is the larger of the two.
pを2番目の小数部の有効ビット数とします。クロック解像度は、秒単位の2 ^（-p）として定義されます。バイアスを最小限に抑え、侵入者がタイムスタンプを予測できないようにするには、重要でないビットを不偏のランダムビット文字列に設定する必要があります。クロック精度は、システムクロックを読み取る実行時間（秒単位）として定義されます。この方法で定義された精度は、解像度より大きくても小さくてもかまいません。プロトコルで使用される精度を表す用語rhoは、2つのうち大きい方です。
The only arithmetic operation permitted on dates and timestamps is twos-complement subtraction, yielding a 127-bit or 63-bit signed result. It is critical that the first-order differences between two dates preserve the full 128-bit precision and the first-order differences between two timestamps preserve the full 64-bit precision. However, the differences are ordinarily small compared to the seconds span, so they can be converted to floating double format for further processing and without compromising the precision.
日付とタイムスタンプで許可される唯一の算術演算は、2の補数の減算であり、127ビットまたは63ビットの符号付き結果を生成します。 2つの日付間の1次の違いが128ビットの完全な精度を維持し、2つのタイムスタンプ間の1次の違いが64ビットの完全な精度を維持することが重要です。ただし、差は通常秒スパンと比較して小さいため、精度を損なうことなく、浮動小数点ダブルフォーマットに変換してさらに処理することができます。
It is important to note that twos-complement arithmetic does not distinguish between signed and unsigned values (although comparisons can take sign into account); only the conditional branch instructions do. Thus, although the distinction is made between signed dates and unsigned timestamps, they are processed the same way. A perceived hazard with 64-bit timestamp calculations spanning an era, such as is possible in 2036, might result in over-run. In point of fact, if the client is set within 68 years of the server before the protocol is started, correct values are obtained even if the client and server are in adjacent eras.
2の補数演算では、符号付き値と符号なし値を区別しないことに注意することが重要です（ただし、比較では符号を考慮に入れることができます）。条件付き分岐命令のみが行います。したがって、署名された日付と署名されていないタイムスタンプは区別されますが、それらは同じ方法で処理されます。 2036年に可能となったような、時代をまたがる64ビットのタイムスタンプ計算で知覚されるハザードは、オーバーランを引き起こす可能性があります。実際、プロトコルが開始される前にサーバーから68年以内にクライアントが設定されている場合、クライアントとサーバーが隣接する時代にあっても正しい値が取得されます。
Some time values are represented in exponent format, including the precision, time constant, and poll interval. These are in 8-bit signed integer format in log2 (log base 2) seconds. The only arithmetic operations permitted on them are increment and decrement. For the purpose of this document and to simplify the presentation, a reference to one of these variables by name means the exponentiated value, e.g., the poll interval is 1024 s, while reference by name and exponent means the actual value, e.g., the poll exponent is 10.
一部の時間値は、精度、時定数、ポーリング間隔など、指数形式で表されます。これらは、log2（log base 2）秒の8ビット符号付き整数形式です。それらに対して許可されている唯一の算術演算は、インクリメントとデクリメントです。このドキュメントの目的と表示を簡略化するために、これらの変数の1つを名前で参照すると、指数の値（たとえば、ポーリング間隔は1024秒）を意味し、名前と指数で参照すると、実際の値（たとえば、ポーリング）を意味します。指数は10です。
To convert system time in any format to NTP date and timestamp formats requires that the number of seconds s from the prime epoch to the system time be determined. To determine the integer era and timestamp given s,
任意の形式のシステム時刻をNTP日付およびタイムスタンプ形式に変換するには、プライムエポックからシステム時刻までの秒数sを決定する必要があります。与えられたsの整数の時代とタイムスタンプを決定するには、
era = s / 2^(32) and timestamp = s - era * 2^(32),
era = s / 2 ^（32）およびtimestamp = s-era * 2 ^（32）、
which works for positive and negative dates. To determine s given the era and timestamp,
これは正の日付と負の日付で機能します。年代とタイムスタンプを指定してを決定するには、
s = era * 2^(32) + timestamp.
s = era * 2 ^（32）+タイムスタンプ。
Converting between NTP and system time can be a little messy, and is beyond the scope of this document. Note that the number of days in era 0 is one more than the number of days in most other eras, and this won't happen again until the year 2400 in era 3.
NTPとシステム時間の間の変換は少し面倒になる可能性があり、このドキュメントの範囲を超えています。時代0の日数は、他のほとんどの時代の日数よりも1多いことに注意してください。これは、時代3の2400年まで再び発生しません。
In the description of state variables to follow, explicit reference to integer type implies a 32-bit unsigned integer. This simplifies bounds checks, since only the upper limit needs to be defined. Without explicit reference, the default type is 64-bit floating double. Exceptions will be noted as necessary.
以下の状態変数の説明では、整数型への明示的な参照は、32ビットの符号なし整数を意味します。上限のみを定義する必要があるため、これにより境界チェックが簡略化されます。明示的な参照がない場合、デフォルトのタイプは64ビット浮動倍数です。例外は必要に応じて記載されます。
The NTP state machines are defined in the following sections. State variables are separated into classes according to their function in packet headers, peer and poll processes, the system process, and the clock discipline process. Packet variables represent the NTP header values in transmitted and received packets. Peer and poll variables represent the contents of the association for each server separately. System variables represent the state of the server as seen by its dependent clients. Clock discipline variables represent the internal workings of the clock discipline algorithm. An example is described in Appendix A.
NTPステートマシンは、次のセクションで定義されています。状態変数は、パケットヘッダー、ピアプロセスとポーリングプロセス、システムプロセス、およびクロック規律プロセスでの機能に応じてクラスに分けられます。パケット変数は、送受信されたパケットのNTPヘッダー値を表します。ピア変数とポーリング変数は、各サーバーの関連付けの内容を個別に表します。システム変数は、依存するクライアントから見たサーバーの状態を表します。クロック規律変数は、クロック規律アルゴリズムの内部動作を表します。例は付録Aで説明されています。
In order to distinguish between different variables of the same name but used in different processes, the naming convention summarized in Figure 5 is adopted. A receive packet variable v is a member of the packet structure r with fully qualified name r.v. In a similar manner, x.v is a transmit packet variable, p.v is a peer variable, s.v is a system variable, and c.v is a clock discipline variable. There is a set of peer variables for each association; there is only one set of system and clock variables.
同じ名前で異なるプロセスで使用される異なる変数を区別するために、図5に要約されている命名規則が採用されています。受信パケット変数vは、完全修飾名r.vを持つパケット構造rのメンバーです。同様に、x.vは送信パケット変数、p.vはピア変数、s.vはシステム変数、c.vはクロックディシプリン変数です。関連付けごとに一連のピア変数があります。システム変数とクロック変数のセットは1つだけです。
+------+---------------------------------+
| Name | Description |
+------+---------------------------------+
| r. | receive packet header variable |
| x. | transmit packet header variable |
| p. | peer/poll variable |
| s. | system variable |
| c. | clock discipline variable |
+------+---------------------------------+
Figure 5: Prefix Conventions
図5：プレフィックスの規則
In addition to the variable classes, a number of global parameters are defined in this document, including those shown with values in Figure 6.
このドキュメントでは、変数クラスに加えて、図6の値で示されているものを含め、いくつかのグローバルパラメーターが定義されています。
+-----------+-------+----------------------------------+
| Name | Value | Description |
+-----------+-------+----------------------------------+
| PORT | 123 | NTP port number |
| VERSION | 4 | NTP version number |
| TOLERANCE | 15e-6 | frequency tolerance PHI (s/s) |
| MINPOLL | 4 | minimum poll exponent (16 s) |
| MAXPOLL | 17 | maximum poll exponent (36 h) |
| MAXDISP | 16 | maximum dispersion (16 s) |
| MINDISP | .005 | minimum dispersion increment (s) |
| MAXDIST | 1 | distance threshold (1 s) |
| MAXSTRAT | 16 | maximum stratum number |
+-----------+-------+----------------------------------+
Figure 6: Global Parameters
図6：グローバルパラメータ
While these are the only global parameters needed for interoperability, a larger collection is necessary in any implementation. Appendix A.1.1 contains those used by the skeleton for the mitigation algorithms, clock discipline algorithm, and related implementation-dependent functions. Some of these parameter values are cast in stone, like the NTP port number assigned by the IANA and the version number assigned NTPv4 itself. Others, like the frequency tolerance (also called PHI), involve an assumption about the worst-case behavior of a system clock once synchronized and then allowed to drift when its sources have become unreachable. The minimum and maximum parameters define the limits of state variables as described in later sections of this document.
これらは相互運用性に必要な唯一のグローバルパラメータですが、どの実装でもより大きなコレクションが必要です。付録A.1.1には、緩和アルゴリズム、クロック調整アルゴリズム、および関連する実装依存の機能のためにスケルトンによって使用されるものが含まれています。 IANAによって割り当てられたNTPポート番号やNTPv4自体に割り当てられたバージョン番号など、これらのパラメーター値の一部は石にキャストされます。周波数許容差（PHIとも呼ばれます）など、同期されたシステムクロックの最悪の場合の動作に関する仮定を含み、ソースが到達不能になったときにドリフトすることを許可するものもあります。このドキュメントの後半のセクションで説明するように、最小パラメータと最大パラメータは状態変数の制限を定義します。
While shown with fixed values in this document, some implementations may make them variables adjustable by configuration commands. For instance, the reference implementation computes the value of PRECISION as log2 of the minimum time in several iterations to read the system clock.
このドキュメントでは固定値で示されていますが、一部の実装では、構成コマンドによって変数を調整可能にする場合があります。たとえば、リファレンス実装はPRECISIONの値を、システムクロックを読み取るための数回の反復における最小時間のlog2として計算します。
The most important state variables from an external point of view are the packet header variables described in Figure 7 and below. The NTP packet header consists of an integral number of 32-bit (4 octet) words in network byte order. The packet format consists of three components: the header itself, one or more optional extension fields, and an optional message authentication code (MAC). The header component is identical to the NTPv3 header and previous versions. The optional extension fields are used by the Autokey public key cryptographic algorithms described in [RFC5906]. The optional MAC is used by both Autokey and the symmetric key cryptographic algorithm described in this RFC.
外部の観点から最も重要な状態変数は、図7および以下で説明するパケットヘッダー変数です。 NTPパケットヘッダーは、ネットワークバイトオーダーの32ビット（4オクテット）ワードの整数で構成されます。パケット形式は、ヘッダー自体、1つ以上のオプションの拡張フィールド、およびオプションのメッセージ認証コード（MAC）の3つのコンポーネントで構成されています。ヘッダーコンポーネントは、NTPv3ヘッダーおよび以前のバージョンと同じです。オプションの拡張フィールドは、[RFC5906]で説明されているAutokey公開鍵暗号アルゴリズムによって使用されます。オプションのMACは、このRFCで説明されているAutokeyと対称キーの暗号化アルゴリズムの両方で使用されます。
+-----------+------------+-----------------------+
| Name | Formula | Description |
+-----------+------------+-----------------------+
| leap | leap | leap indicator (LI) |
| version | version | version number (VN) |
| mode | mode | mode |
| stratum | stratum | stratum |
| poll | poll | poll exponent |
| precision | rho | precision exponent |
| rootdelay | delta_r | root delay |
| rootdisp | epsilon_r | root dispersion |
| refid | refid | reference ID |
| reftime | reftime | reference timestamp |
| org | T1 | origin timestamp |
| rec | T2 | receive timestamp |
| xmt | T3 | transmit timestamp |
| dst | T4 | destination timestamp |
| keyid | keyid | key ID |
| dgst | dgst | message digest |
+-----------+------------+-----------------------+
Figure 7: Packet Header Variables
図7：パケットヘッダー変数
The NTP packet is a UDP datagram [RFC0768]. Some fields use multiple words and others are packed in smaller fields within a word. The NTP packet header shown in Figure 8 has 12 words followed by optional extension fields and finally an optional message authentication code (MAC) consisting of the Key Identifier field and Message Digest field.
NTPパケットはUDPデータグラム[RFC0768]です。複数の単語を使用するフィールドと、単語内の小さなフィールドにパックされるフィールドがあります。図8に示すNTPパケットヘッダーには12ワードがあり、その後にオプションの拡張フィールドが続き、最後にキー識別子フィールドとメッセージダイジェストフィールドで構成されるオプションのメッセージ認証コード（MAC）があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|LI | VN |Mode | Stratum | Poll | Precision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Dispersion |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Reference Timestamp (64) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Origin Timestamp (64) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Receive Timestamp (64) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Transmit Timestamp (64) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Extension Field 1 (variable) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Extension Field 2 (variable) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| dgst (128) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Packet Header Format
図8：パケットヘッダーの形式
The extension fields are used to add optional capabilities, for example, the Autokey security protocol [RFC5906]. The extension field format is presented in order for the packet to be parsed without the knowledge of the extension field functions. The MAC is used by both Autokey and the symmetric key authentication scheme.
拡張フィールドは、Autokeyセキュリティプロトコル[RFC5906]などのオプション機能を追加するために使用されます。拡張フィールドの形式は、拡張フィールドの機能を知らなくてもパケットを解析できるようにするために提示されています。 MACは、Autokeyと対称キー認証方式の両方で使用されます。
A list of the packet header variables is shown in Figure 7 and described in detail below. Except for a minor variation when using the IPv6 address family, these fields are backwards compatible with NTPv3. The packet header fields apply to both transmitted packets (x prefix) and received packets (r prefix). In Figure 8, the size of some multiple-word fields is shown in bits if not the default 32 bits. The basic header extends from the beginning of the packet to the end of the Transmit Timestamp field.
パケットヘッダー変数のリストを図7に示し、以下で詳細に説明します。 IPv6アドレスファミリを使用する場合のマイナーバリエーションを除いて、これらのフィールドはNTPv3と下位互換性があります。パケットヘッダーフィールドは、送信パケット（xプレフィックス）と受信パケット（rプレフィックス）の両方に適用されます。図8では、いくつかのマルチワードフィールドのサイズが、デフォルトの32ビットでない場合はビットで示されています。基本ヘッダーは、パケットの先頭から送信タイムスタンプフィールドの最後まで続きます。
The fields and associated packet variables (in parentheses) are interpreted as follows:
フィールドと関連するパケット変数（括弧内）は、次のように解釈されます。
LI Leap Indicator (leap): 2-bit integer warning of an impending leap second to be inserted or deleted in the last minute of the current month with values defined in Figure 9.
LIうるうインジケーター（うるう）：図9で定義されている値を使用して、当月の最後の分に挿入または削除される、差し迫ったうるう秒の2ビット整数警告。
+-------+----------------------------------------+
| Value | Meaning |
+-------+----------------------------------------+
| 0 | no warning |
| 1 | last minute of the day has 61 seconds |
| 2 | last minute of the day has 59 seconds |
| 3 | unknown (clock unsynchronized) |
+-------+----------------------------------------+
Figure 9: Leap Indicator
図9：うるうインジケータ
VN Version Number (version): 3-bit integer representing the NTP version number, currently 4.
VNバージョン番号（バージョン）：NTPバージョン番号を表す3ビットの整数、現在は4。
Mode (mode): 3-bit integer representing the mode, with values defined in Figure 10.
モード（mode）：モードを表す3ビットの整数。値は図10で定義されています。
+-------+--------------------------+
| Value | Meaning |
+-------+--------------------------+
| 0 | reserved |
| 1 | symmetric active |
| 2 | symmetric passive |
| 3 | client |
| 4 | server |
| 5 | broadcast |
| 6 | NTP control message |
| 7 | reserved for private use |
+-------+--------------------------+
Figure 10: Association Modes
図10：アソシエーションモード
Stratum (stratum): 8-bit integer representing the stratum, with values defined in Figure 11.
層（層）：層を表す8ビット整数。値は図11で定義されています。
+--------+-----------------------------------------------------+
| Value | Meaning |
+--------+-----------------------------------------------------+
| 0 | unspecified or invalid |
| 1 | primary server (e.g., equipped with a GPS receiver) |
| 2-15 | secondary server (via NTP) |
| 16 | unsynchronized |
| 17-255 | reserved |
+--------+-----------------------------------------------------+
Figure 11: Packet Stratum
図11：パケット層
It is customary to map the stratum value 0 in received packets to MAXSTRAT (16) in the peer variable p.stratum and to map p.stratum values of MAXSTRAT or greater to 0 in transmitted packets. This allows reference clocks, which normally appear at stratum 0, to be conveniently mitigated using the same clock selection algorithms used for external sources (see Appendix A.5.5.1 for an example).
受信パケットのストラタム値0をピア変数p.stratumのMAXSTRAT（16）にマップし、MAXSTRAT以上のp.stratum値を送信パケットの0にマップするのが慣例です。これにより、通常はストラタム0に現れる参照クロックを、外部ソースに使用されているのと同じクロック選択アルゴリズムを使用して軽減することができます（例については、付録A.5.5.1を参照してください）。
Poll: 8-bit signed integer representing the maximum interval between successive messages, in log2 seconds. Suggested default limits for minimum and maximum poll intervals are 6 and 10, respectively.
ポーリング：連続するメッセージ間の最大間隔を表す8ビットの符号付き整数（log2秒単位）。最小および最大ポーリング間隔の推奨デフォルト制限は、それぞれ6および10です。
Precision: 8-bit signed integer representing the precision of the system clock, in log2 seconds. For instance, a value of -18 corresponds to a precision of about one microsecond. The precision can be determined when the service first starts up as the minimum time of several iterations to read the system clock.
精度：システムクロックの精度を表す8ビットの符号付き整数（log2秒単位）。たとえば、値-18は、約1マイクロ秒の精度に対応します。精度は、サービスが最初に起動するときに、システムクロックを読み取るための数回の反復の最小時間として決定できます。
Root Delay (rootdelay): Total round-trip delay to the reference clock, in NTP short format.
Root Delay（rootdelay）：NTPショートフォーマットでの基準クロックへの総往復遅延。
Root Dispersion (rootdisp): Total dispersion to the reference clock, in NTP short format.
ルート分散（rootdisp）：NTPショートフォーマットでの、基準クロックへの総分散。
Reference ID (refid): 32-bit code identifying the particular server or reference clock. The interpretation depends on the value in the stratum field. For packet stratum 0 (unspecified or invalid), this is a four-character ASCII [RFC1345] string, called the "kiss code", used for debugging and monitoring purposes. For stratum 1 (reference clock), this is a four-octet, left-justified, zero-padded ASCII string assigned to the reference clock. The authoritative list of Reference Identifiers is maintained by IANA; however, any string beginning with the ASCII character "X" is reserved for unregistered experimentation and development. The identifiers in Figure 12 have been used as ASCII identifiers:
参照ID（refid）：特定のサーバーまたは参照クロックを識別する32ビットコード。解釈は、stratumフィールドの値によって異なります。パケットストラタム0（未指定または無効）の場合、これは「キスコード」と呼ばれる4文字のASCII [RFC1345]文字列で、デバッグと監視の目的で使用されます。ストラタム1（基準クロック）の場合、これは、基準クロックに割り当てられた、4オクテット、左寄せ、ゼロ埋め込みのASCII文字列です。参照識別子の信頼できるリストは、IANAによって管理されています。ただし、ASCII文字「X」で始まる文字列は、未登録の実験および開発用に予約されています。図12の識別子は、ASCII識別子として使用されています。
+------+----------------------------------------------------------+
| ID | Clock Source |
+------+----------------------------------------------------------+
| GOES | Geosynchronous Orbit Environment Satellite |
| GPS | Global Position System |
| GAL | Galileo Positioning System |
| PPS | Generic pulse-per-second |
| IRIG | Inter-Range Instrumentation Group |
| WWVB | LF Radio WWVB Ft. Collins, CO 60 kHz |
| DCF | LF Radio DCF77 Mainflingen, DE 77.5 kHz |
| HBG | LF Radio HBG Prangins, HB 75 kHz |
| MSF | LF Radio MSF Anthorn, UK 60 kHz |
| JJY | LF Radio JJY Fukushima, JP 40 kHz, Saga, JP 60 kHz |
| LORC | MF Radio LORAN C station, 100 kHz |
| TDF | MF Radio Allouis, FR 162 kHz |
| CHU | HF Radio CHU Ottawa, Ontario |
| WWV | HF Radio WWV Ft. Collins, CO |
| WWVH | HF Radio WWVH Kauai, HI |
| NIST | NIST telephone modem |
| ACTS | NIST telephone modem |
| USNO | USNO telephone modem |
| PTB | European telephone modem |
+------+----------------------------------------------------------+
Figure 12: Reference Identifiers
図12：参照識別子
Above stratum 1 (secondary servers and clients): this is the reference identifier of the server and can be used to detect timing loops. If using the IPv4 address family, the identifier is the four-octet IPv4 address. If using the IPv6 address family, it is the first four octets of the MD5 hash of the IPv6 address. Note that, when using the IPv6 address family on an NTPv4 server with a NTPv3 client, the Reference Identifier field appears to be a random value and a timing loop might not be detected.
上記のストラタム1（セカンダリサーバーとクライアント）：これはサーバーの参照識別子であり、タイミングループの検出に使用できます。 IPv4アドレスファミリを使用する場合、識別子は4オクテットのIPv4アドレスです。 IPv6アドレスファミリを使用する場合、これはIPv6アドレスのMD5ハッシュの最初の4オクテットです。 NTPv3クライアントを備えたNTPv4サーバーでIPv6アドレスファミリを使用する場合、参照識別子フィールドはランダムな値になり、タイミングループが検出されない場合があることに注意してください。
Reference Timestamp: Time when the system clock was last set or corrected, in NTP timestamp format.
参照タイムスタンプ：システムクロックが最後に設定または修正された時刻（NTPタイムスタンプ形式）。
Origin Timestamp (org): Time at the client when the request departed for the server, in NTP timestamp format.
Origin Timestamp（org）：リクエストがサーバーに向けて出発したときのクライアントの時刻（NTPタイムスタンプ形式）。
Receive Timestamp (rec): Time at the server when the request arrived from the client, in NTP timestamp format.
受信タイムスタンプ（rec）：NTPタイムスタンプ形式での、クライアントからリクエストが到着したサーバーでの時間。
Transmit Timestamp (xmt): Time at the server when the response left for the client, in NTP timestamp format.
送信タイムスタンプ（xmt）：NTPタイムスタンプ形式での、応答がクライアントに送信されたサーバーでの時間。
Destination Timestamp (dst): Time at the client when the reply arrived from the server, in NTP timestamp format.
宛先タイムスタンプ（dst）：NTPタイムスタンプ形式での、サーバーから応答が到着したクライアントでの時間。
Note: The Destination Timestamp field is not included as a header field; it is determined upon arrival of the packet and made available in the packet buffer data structure.
注：Destination Timestampフィールドはヘッダーフィールドとして含まれていません。パケットの到着時に決定され、パケットバッファのデータ構造で使用可能になります。
If the NTP has access to the physical layer, then the timestamps are associated with the beginning of the symbol after the start of frame. Otherwise, implementations should attempt to associate the timestamp to the earliest accessible point in the frame.
NTPが物理層にアクセスできる場合、タイムスタンプはフレームの開始後のシンボルの開始に関連付けられます。それ以外の場合、実装はタイムスタンプをフレーム内の最も早いアクセス可能なポイントに関連付けようとする必要があります。
The MAC consists of the Key Identifier followed by the Message Digest. The message digest, or cryptosum, is calculated as in [RFC1321] over all NTP-header and optional extension fields, but not the MAC itself.
MACは、キー識別子とそれに続くメッセージダイジェストで構成されます。メッセージダイジェスト、またはクリプトサムは、[RFC1321]のように、MAC自体ではなく、すべてのNTPヘッダーおよびオプションの拡張フィールドに対して計算されます。
Extension Field n: See Section 7.5 for a description of the format of this field.
拡張フィールドn：このフィールドの形式の説明については、セクション7.5を参照してください。
Key Identifier (keyid): 32-bit unsigned integer used by the client and server to designate a secret 128-bit MD5 key.
キー識別子（keyid）：クライアントとサーバーが128ビットの秘密のMD5キーを指定するために使用する32ビットの符号なし整数。
Message Digest (digest): 128-bit MD5 hash computed over the key followed by the NTP packet header and extensions fields (but not the Key Identifier or Message Digest fields).
メッセージダイジェスト（ダイジェスト）：NTPパケットヘッダーと拡張フィールドが後に続くキーで計算された128ビットのMD5ハッシュ（ただし、キー識別子またはメッセージダイジェストフィールドは除く）。
It should be noted that the MAC computation used here differs from those defined in [RFC1305] and [RFC4330] but is consistent with how existing implementations generate a MAC.
ここで使用されるMAC計算は、[RFC1305]および[RFC4330]で定義されたものとは異なりますが、既存の実装がMACを生成する方法と一致していることに注意してください。
If the Stratum field is 0, which implies unspecified or invalid, the Reference Identifier field can be used to convey messages useful for status reporting and access control. These are called Kiss-o'-Death (KoD) packets and the ASCII messages they convey are called kiss codes. The KoD packets got their name because an early use was to tell clients to stop sending packets that violate server access controls. The kiss codes can provide useful information for an intelligent client, either NTPv4 or SNTPv4. Kiss codes are encoded in four-character ASCII strings that are left justified and zero filled. The strings are designed for character displays and log files. A list of the currently defined kiss codes is given in Figure 13. Recipients of kiss codes MUST inspect them and, in the following cases, take these actions:
Stratumフィールドが0である場合、これは未指定または無効であることを意味し、参照識別子フィールドを使用して、ステータスレポートとアクセス制御に役立つメッセージを伝達できます。これらはKiss-o'-Death（KoD）パケットと呼ばれ、それらが伝えるASCIIメッセージはKissコードと呼ばれます。 KoDパケットの名前は、初期の用途がサーバーのアクセス制御に違反するパケットの送信を停止するようクライアントに指示することであったためです。キスコードは、NTPv4またはSNTPv4のインテリジェントクライアントに役立つ情報を提供します。キスコードは、4文字のASCII文字列でエンコードされ、左揃えされ、ゼロで埋められます。文字列は、文字表示とログファイル用に設計されています。現在定義されているキスコードのリストを図13に示します。キスコードの受信者はそれらを検査し、次の場合にこれらのアクションを実行する必要があります。
a. For kiss codes DENY and RSTR, the client MUST demobilize any associations to that server and stop sending packets to that server;
a. キスコードDENYおよびRSTRの場合、クライアントはそのサーバーへの関連付けを解除し、そのサーバーへのパケットの送信を停止する必要があります。
b. For kiss code RATE, the client MUST immediately reduce its polling interval to that server and continue to reduce it each time it receives a RATE kiss code.
b. キスコードRATEの場合、クライアントはそのサーバーへのポーリング間隔をすぐに減らし、レートキスコードを受け取るたびにそれを減らし続けなければなりません。
c. Kiss codes beginning with the ASCII character "X" are for unregistered experimentation and development and MUST be ignored if not recognized.
c. ASCII文字「X」で始まるキスコードは、未登録の実験および開発用であり、認識されない場合は無視する必要があります。
d. Other than the above conditions, KoD packets have no protocol significance and are discarded after inspection.
d. 上記の条件以外では、KoDパケットにはプロトコルの意味はなく、検査後に破棄されます。
+------+------------------------------------------------------------+
| Code | Meaning |
+------+------------------------------------------------------------+
| ACST | The association belongs to a unicast server. |
| AUTH | Server authentication failed. |
| AUTO | Autokey sequence failed. |
| BCST | The association belongs to a broadcast server. |
| CRYP | Cryptographic authentication or identification failed. |
| DENY | Access denied by remote server. |
| DROP | Lost peer in symmetric mode. |
| RSTR | Access denied due to local policy. |
| INIT | The association has not yet synchronized for the first |
| | time. |
| MCST | The association belongs to a dynamically discovered server.|
| NKEY | No key found. Either the key was never installed or is |
| | not trusted. |
| RATE | Rate exceeded. The server has temporarily denied access |
| | because the client exceeded the rate threshold. |
| RMOT | Alteration of association from a remote host running |
| | ntpdc. |
| STEP | A step change in system time has occurred, but the |
| | association has not yet resynchronized. |
+------+------------------------------------------------------------+
Figure 13: Kiss Codes
図13：キスコード
The Receive Timestamp and the Transmit Timestamp (set by the server) are undefined when in a KoD packet and MUST NOT be relied upon to have valid values and MUST be discarded.
受信タイムスタンプと送信タイムスタンプ（サーバーによって設定）は、KoDパケット内では未定義であり、有効な値を持つことに依存してはならず、破棄する必要があります。
In NTPv4, one or more extension fields can be inserted after the header and before the MAC, which is always present when an extension field is present. Other than defining the field format, this document makes no use of the field contents. An extension field contains a request or response message in the format shown in Figure 14.
NTPv4では、ヘッダーの後でMACの前に1つ以上の拡張フィールドを挿入できます。MACは、拡張フィールドが存在するときに常に存在します。このドキュメントでは、フィールド形式を定義する以外は、フィールドの内容を使用しません。拡張フィールドには、図14に示す形式の要求または応答メッセージが含まれます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Value .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (as needed) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Extension Field Format
図14：拡張フィールドの形式
All extension fields are zero-padded to a word (four octets) boundary. The Field Type field is specific to the defined function and is not elaborated here. While the minimum field length containing required fields is four words (16 octets), a maximum field length remains to be established.
すべての拡張フィールドは、ワード（4オクテット）境界までゼロが埋め込まれます。フィールドタイプフィールドは定義された関数に固有であり、ここでは詳しく説明しません。必要なフィールドを含む最小フィールド長は4ワード（16オクテット）ですが、最大フィールド長はまだ確立されていません。
The Length field is a 16-bit unsigned integer that indicates the length of the entire extension field in octets, including the Padding field.
長さフィールドは、パディングフィールドを含むオクテット単位の拡張フィールド全体の長さを示す16ビットの符号なし整数です。
The heart of the NTP on-wire protocol is the core mechanism that exchanges time values between servers, peers, and clients. It is inherently resistant to lost or duplicate packets. Data integrity is provided by the IP and UDP checksums. No flow control or retransmission facilities are provided or necessary. The protocol uses timestamps, which are either extracted from packet headers or struck from the system clock upon the arrival or departure of a packet. Timestamps are precision data and should be restruck in the case of link-level retransmission and corrected for the time to compute a MAC in transmit.
NTPオンワイヤプロトコルの中心は、サーバー、ピア、およびクライアント間で時間値を交換するコアメカニズムです。それは本質的にパケットの損失または重複に対して耐性があります。データの整合性は、IPおよびUDPチェックサムによって提供されます。フロー制御または再送信機能は提供されていないか、必要ありません。プロトコルはタイムスタンプを使用します。タイムスタンプは、パケットヘッダーから抽出されるか、パケットの到着時または出発時にシステムクロックから打たれます。タイムスタンプは正確なデータであり、リンクレベルの再送信の場合に再ラックし、送信でMACを計算する時間を修正する必要があります。
NTP messages make use of two different communication modes, one-to-one and one-to-many, commonly referred to as unicast and broadcast. For the purposes of this document, the term broadcast is interpreted as any available one-to-many mechanism. For IPv4, this equates to either IPv4 broadcast or IPv4 multicast. For IPv6, this equates to IPv6 multicast. For this purpose, IANA has allocated the IPv4 multicast address 224.0.1.1 and the IPv6 multicast address ending :101, with the prefix determined by scoping rules. Any other non-allocated multicast address may also be used in addition to these allocated multicast addresses.
NTPメッセージは、1対1と1対多の2つの異なる通信モードを使用します。これは、一般にユニキャストおよびブロードキャストと呼ばれます。このドキュメントでは、ブロードキャストという用語は、使用可能な1対多のメカニズムとして解釈されます。 IPv4の場合、これはIPv4ブロードキャストまたはIPv4マルチキャストのいずれかに相当します。 IPv6の場合、これはIPv6マルチキャストに相当します。この目的のために、IANAはIPv4マルチキャストアドレス224.0.1.1および末尾が：101のIPv6マルチキャストアドレスを割り当て、プレフィックスはスコープルールによって決定されます。これらの割り当てられたマルチキャストアドレスに加えて、他の割り当てられていないマルチキャストアドレスも使用できます。
The on-wire protocol uses four timestamps numbered t1 through t4 and three state variables org, rec, and xmt, as shown in Figure 15. This figure shows the most general case where each of two peers, A and B, independently measure the offset and delay relative to the other. For purposes of illustration, the packet timestamps are shown in lowercase, while the state variables are shown in uppercase. The state variables are copied from the packet timestamps upon arrival or departure of a packet.
オンワイヤプロトコルは、図15に示すように、t1からt4までの番号が付けられた4つのタイムスタンプと3つの状態変数org、rec、xmtを使用します。この図は、2つのピアAとBがそれぞれ独立してオフセットを測定する最も一般的なケースを示していますそして、他に比べて遅延。説明のために、パケットのタイムスタンプは小文字で示され、状態変数は大文字で示されています。状態変数は、パケットの到着時または出発時にパケットのタイムスタンプからコピーされます。
t2 t3 t6 t7
+---------+ +---------+ +---------+ +---------+
| 0 | | t1 | | t3 | | t5 |
+---------+ +---------+ +---------+ +---------+
| 0 | | t2 | | t4 | | t6 | Packet
+---------+ +---------+ +---------+ +---------+ Timestamps
| t1 | |t3=clock | | t5 | |t7=clock |
+---------+ +---------+ +---------+ +---------+
|t2=clock | |t6=clock |
+---------+ +---------+
Peer B
+---------+ +---------+ +---------+ +---------+
org | T1 | | T1 | | t5<>T1? | | T5 |
+---------+ +---------+ +---------+ +---------+ State
rec | T2 | | T2 | | T6 | | T6 | Variables
+---------+ +---------+ +---------+ +---------+
xmt | 0 | | T3 | | t3=T3? | | T7 |
+---------+ +---------+ +---------+ +---------+
t2 t3 t6 t7
---------------------------------------------------------
/\ \ /\ \
/ \ / \
/ \ / \
/ \/ / \/
---------------------------------------------------------
t1 t4 t5 t8
t1 t4 t5 t8
+---------+ +---------+ +---------+ +---------+
| 0 | | t1 | | t3 | | t5 |
+---------+ +---------+ +---------+ +---------+
| 0 | | t2 | | t4 | | t6 | Packet
+---------+ +---------+ +---------+ +---------+ Timestamps
|t1=clock | | t3 | |t5=clock | | t7 |
+---------+ +---------+ +---------+ +---------+
|t4=clock | |t8=clock |
+---------+ +---------+
Peer A
+---------+ +---------+ +---------+ +---------+
org | 0 | | t3<>0? | | T3 | | t7<>T3? |
+---------+ +---------+ +---------+ +---------+ State
rec | 0 | | T4 | | T4 | | T8 | Variables
+---------+ +---------+ +---------+ +---------+
xmt | T1 | | t1=T1? | | T5 | | t5=T5? |
+---------+ +---------+ +---------+ +---------+
Figure 15: On-Wire Protocol
図15：オンワイヤプロトコル
In the figure, the first packet transmitted by A contains only the origin timestamp t1, which is then copied to T1. B receives the packet at t2 and copies t1 to T1 and the receive timestamp t2 to T2. At this time or some time later at t3, B sends a packet to A containing t1 and t2 and the transmit timestamp t3. All three timestamps are copied to the corresponding state variables. A receives the packet at t4 containing the three timestamps t1, t2, and t3 and the destination timestamp t4. These four timestamps are used to compute the offset and delay of B relative to A, as described below.
この図では、Aが送信した最初のパケットには、元のタイムスタンプt1のみが含まれており、T1にコピーされます。 Bはt2でパケットを受信し、t1をT1にコピーし、受信タイムスタンプt2をT2にコピーします。この時点または少し後のt3で、Bはt1とt2および送信タイムスタンプt3を含むパケットをAに送信します。 3つのタイムスタンプはすべて、対応する状態変数にコピーされます。 Aは、3つのタイムスタンプt1、t2、およびt3と宛先タイムスタンプt4を含むパケットをt4で受信します。これらの4つのタイムスタンプは、以下で説明するように、Aに対するBのオフセットと遅延を計算するために使用されます。
Before the xmt and org state variables are updated, two sanity checks are performed in order to protect against duplicate, bogus, or replayed packets. In the exchange above, a packet is duplicate or replay if the transmit timestamp t3 in the packet matches the org state variable T3. A packet is bogus if the origin timestamp t1 in the packet does not match the xmt state variable T1. In either of these cases, the state variables are updated, then the packet is discarded. To protect against replay of the last transmitted packet, the xmt state variable is set to zero immediately after a successful bogus check.
xmtおよびorg状態変数が更新される前に、重複、偽、または再生されたパケットから保護するために、2つの正常性チェックが実行されます。上記の交換では、パケットの送信タイムスタンプt3が組織状態変数T3と一致する場合、パケットは複製または再生されます。パケットの元のタイムスタンプt1がxmt状態変数T1と一致しない場合、そのパケットは偽です。これらのいずれの場合も、状態変数が更新され、パケットは破棄されます。最後に送信されたパケットのリプレイから保護するために、偽のチェックが成功した直後に、xmt状態変数がゼロに設定されます。
The four most recent timestamps, T1 through T4, are used to compute the offset of B relative to A
最新の4つのタイムスタンプT1からT4は、Aに対するBのオフセットを計算するために使用されます。
theta = T(B) - T(A) = 1/2 * [(T2-T1) + (T3-T4)]
and the round-trip delay
往復遅延
delta = T(ABA) = (T4-T1) - (T3-T2).
Note that the quantities within parentheses are computed from 64-bit unsigned timestamps and result in signed values with 63 significant bits plus sign. These values can represent dates from 68 years in the past to 68 years in the future. However, the offset and delay are computed as sums and differences of these values, which contain 62 significant bits and two sign bits, so they can represent unambiguous values from 34 years in the past to 34 years in the future. In other words, the time of the client must be set within 34 years of the server before the service is started. This is a fundamental limitation with 64-bit integer arithmetic.
括弧内の数量は64ビットの符号なしタイムスタンプから計算され、63の有効ビットと符号が付いた符号付きの値になることに注意してください。これらの値は、過去68年から未来68年までの日付を表すことができます。ただし、オフセットと遅延は、62の有効ビットと2つの符号ビットを含むこれらの値の合計と差として計算されるため、過去34年から未来34年までのあいまいな値を表すことができます。つまり、サービスを開始する前に、クライアントの時刻をサーバーから34年以内に設定する必要があります。これは、64ビット整数演算の基本的な制限です。
In implementations where floating double arithmetic is available, the first-order differences can be converted to floating double and the second-order sums and differences computed in that arithmetic. Since the second-order terms are typically very small relative to the timestamp magnitudes, there is no loss in significance, yet the unambiguous range is restored from 34 years to 68 years.
浮動二重演算が利用可能な実装では、1次の差を浮動倍に変換し、その算術で計算された2次の和と差を計算できます。 2次項は通常、タイムスタンプの大きさに比べて非常に小さいため、有意性は失われませんが、あいまいな範囲は34年から68年に戻ります。
In some scenarios where the initial frequency offset of the client is relatively large and the actual propagation time small, it is possible for the delay computation to become negative. For instance, if the frequency difference is 100 ppm and the interval T4-T1 is 64 s, the apparent delay is -6.4 ms. Since negative values are misleading in subsequent computations, the value of delta should be clamped not less than s.rho, where s.rho is the system precision described in Section 11.1, expressed in seconds.
クライアントの初期周波数オフセットが比較的大きく、実際の伝搬時間が短いシナリオでは、遅延計算が負になる可能性があります。たとえば、周波数差が100 ppmで、間隔T4-T1が64秒の場合、見かけ上の遅延は-6.4 msです。後続の計算では負の値は誤解を招くため、deltaの値はs.rho以上にクランプする必要があります。ここで、s.rhoはセクション11.1で説明されているシステムの精度で、秒単位で表されます。
The discussion above assumes the most general case where two symmetric peers independently measure the offsets and delays between them. In the case of a stateless server, the protocol can be simplified. A stateless server copies T3 and T4 from the client packet to T1 and T2 of the server packet and tacks on the transmit timestamp T3 before sending it to the client. Additional details for filling in the remaining protocol fields are given in a Section 9 and following sections and in the appendix.
上記の説明では、2つの対称ピアがオフセットと遅延を個別に測定する最も一般的なケースを想定しています。ステートレスサーバーの場合、プロトコルを簡略化できます。ステートレスサーバーは、T3とT4をクライアントパケットからサーバーパケットのT1とT2にコピーし、送信タイムスタンプT3を付加してから、クライアントに送信します。残りのプロトコルフィールドへの入力の詳細については、セクション9以降と付録に記載されています。
Note that the on-wire protocol as described resists replay of a server response packet. However, it does not resist replay of the client request packet, which would result in a server reply packet with new values of T2 and T3 and result in incorrect offset and delay. This vulnerability can be avoided by setting the xmt state variable to zero after computing the offset and delay.
上記のオンワイヤプロトコルは、サーバー応答パケットの再生に抵抗することに注意してください。ただし、クライアント要求パケットの再生には抵抗しません。これにより、T2およびT3の新しい値を含むサーバー応答パケットが生成され、オフセットと遅延が不正確になります。この脆弱性は、オフセットと遅延の計算後にxmt状態変数をゼロに設定することで回避できます。
The process descriptions to follow include a listing of the important state variables followed by an overview of the process operations implemented as routines. Frequent reference is made to the skeleton in the appendix. The skeleton includes C-language fragments that describe the functions in more detail. It includes the parameters, variables, and declarations necessary for a conforming NTPv4 implementation. However, many additional variables and routines may be necessary in a working implementation.
以下のプロセスの説明には、重要な状態変数のリストと、その後にルーチンとして実装されたプロセス操作の概要が含まれています。付録のスケルトンが頻繁に参照されます。スケルトンには、関数をより詳細に説明するC言語のフラグメントが含まれています。これには、準拠するNTPv4実装に必要なパラメータ、変数、宣言が含まれています。ただし、実際の実装では、多くの追加の変数とルーチンが必要になる場合があります。
The peer process is called upon arrival of a server or peer packet. It runs the on-wire protocol to determine the clock offset and round-trip delay and computes statistics used by the system and poll processes. Peer variables are instantiated in the association data structure when the structure is initialized and updated by arriving packets. There is a peer process, poll process, and association process for each server.
ピアプロセスは、サーバーまたはピアパケットの到着時に呼び出されます。オンワイヤプロトコルを実行して、クロックオフセットと往復遅延を決定し、システムとポーリングプロセスで使用される統計情報を計算します。ピア変数は、構造が初期化され、到着するパケットによって更新されるときに、関連付けデータ構造でインスタンス化されます。各サーバーには、ピアプロセス、ポーリングプロセス、および関連付けプロセスがあります。
Figures 16, 17, 18, and 19 summarize the common names, formula names, and a short description of the peer variables. The common names and formula names are interchangeable; formula names are intended to increase readability of equations in this specification. Unless noted otherwise, all peer variables have assumed prefix p.
図16、17、18、および19は、一般的な名前、式の名前、およびピア変数の簡単な説明をまとめたものです。一般名と式名は交換可能です。式名は、この仕様における方程式の読みやすさを向上させることを目的としています。特に明記しない限り、すべてのピア変数は接頭辞pを想定しています。
+---------+----------+-----------------------+
| Name | Formula | Description |
+---------+----------+-----------------------+
| srcaddr | srcaddr | source address |
| srcport | srcport | source port |
| dstaddr | dstaddr | destination address |
| dstport | destport | destination port |
| keyid | keyid | key identifier key ID |
+---------+----------+-----------------------+
Figure 16: Peer Process Configuration Variables
図16：ピアプロセス構成変数
+-----------+------------+---------------------+
| Name | Formula | Description |
+-----------+------------+---------------------+
| leap | leap | leap indicator |
| version | version | version number |
| mode | mode | mode |
| stratum | stratum | stratum |
| ppoll | ppoll | peer poll exponent |
| rootdelay | delta_r | root delay |
| rootdisp | epsilon_r | root dispersion |
| refid | refid | reference ID |
| reftime | reftime | reference timestamp |
+-----------+------------+---------------------+
Figure 17: Peer Process Packet Variables
図17：ピアプロセスパケット変数
+------+---------+--------------------+
| Name | Formula | Description |
+------+---------+--------------------+
| org | T1 | origin timestamp |
| rec | T2 | receive timestamp |
| xmt | T3 | transmit timestamp |
| t | t | packet time |
+------+---------+--------------------+
Figure 18: Peer Process Timestamp Variables
図18：ピアプロセスのタイムスタンプ変数
+--------+---------+-----------------+
| Name | Formula | Description |
+--------+---------+-----------------+
| offset | theta | clock offset |
| delay | delta | round-trip delay|
| disp | epsilon | dispersion |
| jitter | psi | jitter |
| filter | filter | clock filter |
| tp | t_p | filter time |
+--------+---------+-----------------+
Figure 19: Peer Process Statistics Variables
図19：ピアプロセス統計変数
The following configuration variables are normally initialized when the association is mobilized, either from a configuration file or upon the arrival of the first packet for an unknown association.
次の構成変数は、通常、関連付けがモバイル化されたときに、構成ファイルから、または不明な関連付けの最初のパケットが到着したときに初期化されます。
srcaddr: IP address of the remote server or reference clock. This becomes the destination IP address in packets sent from this association.
srcaddr：リモートサーバーのIPアドレスまたは基準クロック。これは、この関連付けから送信されるパケットの宛先IPアドレスになります。
srcport: UDP port number of the server or reference clock. This becomes the destination port number in packets sent from this association. When operating in symmetric modes (1 and 2), this field must contain the NTP port number PORT (123) assigned by the IANA. In other modes, it can contain any number consistent with local policy.
srcport：サーバーまたは参照クロックのUDPポート番号。これは、この関連付けから送信されるパケットの宛先ポート番号になります。対称モード（1および2）で動作している場合、このフィールドには、IANAによって割り当てられたNTPポート番号PORT（123）が含まれている必要があります。他のモードでは、ローカルポリシーと一致する任意の数を含めることができます。
dstaddr: IP address of the client. This becomes the source IP address in packets sent from this association.
dstaddr：クライアントのIPアドレス。これは、この関連付けから送信されるパケットの送信元IPアドレスになります。
dstport: UDP port number of the client, ordinarily the NTP port number PORT (123) assigned by the IANA. This becomes the source port number in packets sent from this association.
dstport：クライアントのUDPポート番号、通常はIANAによって割り当てられたNTPポート番号PORT（123）。これは、この関連付けから送信されるパケットの送信元ポート番号になります。
keyid: Symmetric key ID for the 128-bit MD5 key used to generate and verify the MAC. The client and server or peer can use different values, but they must map to the same key.
keyid：MACの生成と検証に使用される128ビットMD5キーの対称キーID。クライアントとサーバーまたはピアは異なる値を使用できますが、同じキーにマップする必要があります。
The variables defined in Figure 17 are updated from the packet header as each packet arrives. They are interpreted in the same way as the packet variables of the same names. It is convenient for later processing to convert the NTP short format packet values r.rootdelay and r.rootdisp to floating doubles as peer variables.
図17で定義された変数は、各パケットが到着するときにパケットヘッダーから更新されます。それらは同じ名前のパケット変数と同じ方法で解釈されます。 NTPの短い形式のパケット値r.rootdelayおよびr.rootdispをピア変数としての浮動ダブルに変換すると、後の処理に便利です。
The variables defined in Figure 18 include the timestamps exchanged by the on-wire protocol in Section 8. The t variable is the seconds counter c.t associated with these values. The c.t variable is maintained by the clock-adjust process described in Section 12. It
図18で定義されている変数には、セクション8でオンワイヤプロトコルによって交換されたタイムスタンプが含まれます。t変数は、これらの値に関連付けられた秒数カウンターc.tです。 c.t変数は、セクション12で説明されているクロック調整プロセスによって維持されます。
counts the seconds since the service was started. The variables defined in Figure 19 include the statistics computed by the clock_filter() routine described in Section 10. The tp variable is the seconds counter associated with these values.
サービスが開始されてからの秒数をカウントします。図19で定義されている変数には、セクション10で説明されているclock_filter()ルーチンによって計算された統計が含まれています。tp変数は、これらの値に関連付けられた秒数カウンターです。
The receive routine defines the process flow upon the arrival of a packet. An example is described by the receive() routine in Appendix A.5.1. There is no specific method required for access control, although it is recommended that implementations include such a scheme, which is similar to many others now in widespread use. The access() routine in Appendix A.5.4 describes a method of implementing access restrictions using an access control list (ACL). Format checks require correct field length and alignment, acceptable version number (1-4), and correct extension field syntax, if present.
受信ルーチンは、パケットの到着時のプロセスフローを定義します。例は、付録A.5.1のreceive()ルーチンで説明されています。アクセス制御に必要な特定の方法はありませんが、実装にそのようなスキームを含めることをお勧めします。これは、現在広く使用されている他の多くのスキームと同様です。付録A.5.4のaccess()ルーチンでは、アクセス制御リスト（ACL）を使用してアクセス制限を実装する方法について説明しています。フォーマットチェックには、正しいフィールド長と配置、受け入れ可能なバージョン番号（1〜4）、および存在する場合は正しい拡張フィールド構文が必要です。
There is no specific requirement for authentication; however, if authentication is implemented, then the MD5-keyed hash algorithm described in [RFC1321] must be supported.
認証に特定の要件はありません。ただし、認証が実装されている場合は、[RFC1321]で説明されているMD5キー付きハッシュアルゴリズムがサポートされている必要があります。
Next, the association table is searched for matching source address and source port, for example, using the find_assoc() routine in Appendix A.5.1. Figure 20 is a dispatch table where the columns correspond to the packet mode and rows correspond to the association mode. The intersection of the association and packet modes dispatches processing to one of the following steps.
次に、たとえば、付録A.5.1のfind_assoc()ルーチンを使用して、関連付けテーブルで一致するソースアドレスとソースポートを検索します。図20は、列がパケットモードに対応し、行がアソシエーションモードに対応するディスパッチテーブルです。アソシエーションモードとパケットモードの共通部分により、処理が次のいずれかのステップにディスパッチされます。
+------------------+---------------------------------------+
| | Packet Mode |
+------------------+-------+-------+-------+-------+-------+
| Association Mode | 1 | 2 | 3 | 4 | 5 |
+------------------+-------+-------+-------+-------+-------+
| No Association 0 | NEWPS | DSCRD | FXMIT | MANY | NEWBC |
| Symm. Active 1 | PROC | PROC | DSCRD | DSCRD | DSCRD |
| Symm. Passive 2 | PROC | ERR | DSCRD | DSCRD | DSCRD |
| Client 3 | DSCRD | DSCRD | DSCRD | PROC | DSCRD |
| Server 4 | DSCRD | DSCRD | DSCRD | DSCRD | DSCRD |
| Broadcast 5 | DSCRD | DSCRD | DSCRD | DSCRD | DSCRD |
| Bcast Client 6 | DSCRD | DSCRD | DSCRD | DSCRD | PROC |
+------------------+-------+-------+-------+-------+-------+
Figure 20: Peer Dispatch Table
図20：ピアディスパッチテーブル
DSCRD. This indicates a non-fatal violation of protocol as the result of a programming error, long-delayed packet, or replayed packet. The peer process discards the packet and exits.
DSCRD。これは、プログラミングエラー、長い遅延パケット、または再生されたパケットの結果として、致命的ではないプロトコル違反を示しています。ピアプロセスはパケットを破棄して終了します。
ERR. This indicates a fatal violation of protocol as the result of a programming error, long-delayed packet, or replayed packet. The peer process discards the packet, demobilizes the symmetric passive association, and exits.
エラー。これは、プログラミングエラー、長時間遅延したパケット、または再生されたパケットの結果として、プロトコルが致命的に違反したことを示しています。ピアプロセスはパケットを破棄し、対称パッシブアソシエーションを解除して終了します。
FXMIT. This indicates a client (mode 3) packet matching no association (mode 0). If the destination address is not a broadcast address, the server constructs a server (mode 4) packet and returns it to the client without retaining state. The server packet header is constructed. An example is described by the fast_xmit() routine in Appendix A.5.3. The packet header is assembled from the receive packet and system variables as shown in Figure 21. If the s.rootdelay and s.rootdisp system variables are stored in floating double, they must be converted to NTP short format first.
FXMIT。これは、アソシエーションなし（モード0）に一致するクライアント（モード3）パケットを示します。宛先アドレスがブロードキャストアドレスでない場合、サーバーはサーバー（モード4）パケットを作成し、状態を保持せずにクライアントに返します。サーバーのパケットヘッダーが作成されます。例は、付録A.5.3のfast_xmit()ルーチンで説明されています。パケットヘッダーは、図21に示すように、受信パケットとシステム変数から組み立てられます。s.rootdelayおよびs.rootdispシステム変数が浮動二重に格納されている場合は、最初にNTPショートフォーマットに変換する必要があります。
+-----------------------------------+
| Packet Variable --> Variable |
+-----------------------------------+
| r.leap --> p.leap |
| r.mode --> p.mode |
| r.stratum --> p.stratum |
| r.poll --> p.ppoll |
| r.rootdelay --> p.rootdelay |
| r.rootdisp --> p.rootdisp |
| r.refid --> p.refid |
| r.reftime --> p.reftime |
| r.keyid --> p.keyid |
+-----------------------------------+
Figure 21: Receive Packet Header
図21：受信パケットヘッダー
Note that, if authentication fails, the server returns a special message called a crypto-NAK. This message includes the normal NTP header data shown in Figure 8, but with a MAC consisting of four octets of zeros. The client MAY accept or reject the data in the message. After these actions, the peer process exits.
認証が失敗した場合、サーバーはcrypto-NAKと呼ばれる特別なメッセージを返すことに注意してください。このメッセージには、図8に示されている通常のNTPヘッダーデータが含まれていますが、MACは4オクテットのゼロで構成されています。クライアントは、メッセージ内のデータを受け入れるか拒否することができます。これらのアクションの後、ピアプロセスは終了します。
If the destination address is a multicast address, the sender is operating in manycast client mode. If the packet is valid and the server stratum is less than the client stratum, the server sends an ordinary server (mode 4) packet, but one which uses its unicast destination address. A crypto-NAK is not sent if authentication fails. After these actions, the peer process exits.
宛先アドレスがマルチキャストアドレスの場合、送信者はメニーキャストクライアントモードで動作しています。パケットが有効で、サーバー層がクライアント層よりも小さい場合、サーバーは通常のサーバー（モード4）パケットを送信しますが、ユニキャスト宛先アドレスを使用します。認証が失敗した場合、crypto-NAKは送信されません。これらのアクションの後、ピアプロセスは終了します。
MANY: This indicates a server (mode 4) packet matching no association. Ordinarily, this can happen only as the result of a manycast server reply to a previously sent multicast client packet.
MANY：これは、関連付けに一致しないサーバー（モード4）パケットを示します。通常、これは、以前に送信されたマルチキャストクライアントパケットに対するメニーキャストサーバーの応答の結果としてのみ発生します。
If the packet is valid, an ordinary client (mode 3) association is mobilized and operation continues as if the association was mobilized by the configuration file.
パケットが有効である場合、通常のクライアント（モード3）アソシエーションが動員され、アソシエーションが構成ファイルによって動員されたかのように操作が続行されます。
NEWBC. This indicates a broadcast (mode 5) packet matching no association. The client mobilizes either a client (mode 3) or broadcast client (mode 6) association. Examples are shown in the mobilize() and clear() routines in Appendix A.2. Then, the packet is validated and the peer variables initialized. An example is provided by the packet() routine in Appendix A.5.1.1.
NEWBC。これは、アソシエーションに一致しないブロードキャスト（モード5）パケットを示します。クライアントは、クライアント（モード3）またはブロードキャストクライアント（モード6）アソシエーションを動員します。例は、付録A.2のmobilize()およびclear()ルーチンに示されています。次に、パケットが検証され、ピア変数が初期化されます。例は、付録A.5.1.1のpacket()ルーチンで提供されています。
If the implementation supports no additional security or calibration functions, the association mode is set to broadcast client (mode 6) and the peer process exits. Implementations supporting public key authentication MAY run the Autokey or equivalent security protocol. Implementations SHOULD set the association mode to 3 and run a short client/server exchange to determine the propagation delay. Following the exchange, the association mode is set to 6 and the peer process continues in listen-only mode. Note the distinction between a mode-6 packet, which is reserved for the NTP monitor and control functions, and a mode-6 association.
実装が追加のセキュリティまたは調整機能をサポートしない場合、アソシエーションモードはブロードキャストクライアント（モード6）に設定され、ピアプロセスは終了します。公開鍵認証をサポートする実装は、Autokeyまたは同等のセキュリティプロトコルを実行する場合があります。実装では、アソシエーションモードを3に設定し、短いクライアント/サーバー交換を実行して、伝播遅延を決定する必要があります（SHOULD）。交換後、アソシエーションモードは6に設定され、ピアプロセスはリッスン専用モードで続行されます。 NTPモニターおよび制御機能用に予約されているモード6パケットとモード6アソシエーションの違いに注意してください。
NEWPS. This indicates a symmetric active (mode 1) packet matching no association. The client mobilizes a symmetric passive (mode 2) association. An example is shown in the mobilize() and clear() routines in Appendix A.2. Processing continues in the PROC section below.
NEWPS。これは、アソシエーションに一致しない対称アクティブ（モード1）パケットを示します。クライアントは対称パッシブ（モード2）アソシエーションを動員します。例は、付録A.2のmobilize()およびclear()ルーチンに示されています。処理は、以下のPROCセクションで続行されます。
PROC. This indicates a packet matching an existing association. The packet timestamps are carefully checked to avoid invalid, duplicate, or bogus packets. Additional checks are summarized in Figure 22. Note that all packets, including a crypto-NAK, are considered valid only if they survive these tests.
手続きこれは、既存の関連付けに一致するパケットを示します。パケットのタイムスタンプは、無効なパケット、重複したパケット、または偽のパケットを回避するために慎重にチェックされます。追加のチェックを図22にまとめます。暗号NAKを含むすべてのパケットは、これらのテストに合格した場合にのみ有効と見なされることに注意してください。
+--------------------------+----------------------------------------+
| Packet Type | Description |
+--------------------------+----------------------------------------+
| 1 duplicate packet | The packet is at best an old duplicate |
| | or at worst a replay by a hacker. |
| | This can happen in symmetric modes if |
| | the poll intervals are uneven. |
| 2 bogus packet | |
| 3 invalid | One or more timestamp fields are |
| | invalid. This normally happens in |
| | symmetric modes when one peer sends |
| | the first packet to the other and |
| | before the other has received its |
| | first reply. |
| 4 access denied | The access controls have blacklisted |
| | the source. |
| 5 authentication failure | The cryptographic message digest does |
| | not match the MAC. |
| 6 unsynchronized | The server is not synchronized to a |
| | valid source. |
| 7 bad header data | One or more header fields are invalid. |
+--------------------------+----------------------------------------+
Figure 22: Packet Error Checks
図22：パケットエラーチェック
Processing continues by copying the packet variables to the peer variables as shown in Figure 21. An example is described by the packet() routine in Appendix A.5.1.1. The receive() routine implements tests 1-5 in Figure 22; the packet() routine implements tests 6-7. If errors are found, the packet is discarded and the peer process exits.
図21に示すように、パケット変数をピア変数にコピーして処理を続行します。例は、付録A.5.1.1のpacket()ルーチンで説明しています。 receive()ルーチンは、図22のテスト1〜5を実装します。 packet()ルーチンはテスト6〜7を実装します。エラーが見つかった場合、パケットは破棄され、ピアプロセスが終了します。
The on-wire protocol calculates the clock offset theta and round-trip delay delta from the four most recent timestamps as described in Section 8. While it is, in principle, possible to do all calculations except the first-order timestamp differences in fixed-point arithmetic, it is much easier to convert the first-order differences to floating doubles and do the remaining calculations in that arithmetic, and this will be assumed in the following description.
オンワイヤプロトコルは、セクション8で説明したように、最新の4つのタイムスタンプからクロックオフセットthetaと往復遅延デルタを計算します。原則として、fixed-の1次タイムスタンプの違いを除くすべての計算を実行できます。ポイント演算では、1次の差を浮動倍精度に変換し、残りの計算をその演算で実行する方がはるかに簡単です。これは、以下の説明で想定されています。
Next, the 8-bit p.reach shift register in the poll process described in Section 13 is used to determine whether the server is reachable and the data are fresh. The register is shifted left by one bit when a packet is sent and the rightmost bit is set to zero. As valid packets arrive, the rightmost bit is set to one. If the register contains any nonzero bits, the server is considered reachable; otherwise, it is unreachable. Since the peer poll interval might have changed since the last packet, the host poll interval is reviewed. An example is provided by the poll_update() routine in Appendix A.5.7.2.
次に、セクション13で説明されているポーリングプロセスの8ビットp.reachシフトレジスタを使用して、サーバーに到達可能でデータが新しいかどうかを判断します。パケットが送信され、右端のビットがゼロに設定されると、レジスタは1ビット左にシフトされます。有効なパケットが到着すると、右端のビットが1に設定されます。レジスターにゼロ以外のビットが含まれている場合、サーバーは到達可能と見なされます。それ以外の場合は到達できません。ピアのポーリング間隔が最後のパケット以降に変更された可能性があるため、ホストのポーリング間隔が確認されます。例は、付録A 5.5.7.2のpoll_update()ルーチンによって提供されます。
The dispersion statistic epsilon(t) represents the maximum error due to the frequency tolerance and time since the last packet was sent. It is initialized
分散統計値epsilon（t）は、最後のパケットが送信されてからの周波数許容誤差と時間による最大誤差を表します。初期化されます
epsilon(t_0) = r.rho + s.rho + PHI * (T4-T1)
when the measurement is made at t_0 according to the seconds counter. Here, r.rho is the packet precision described in Section 7.3 and s.rho is the system precision described in Section 11.1, both expressed in seconds. These terms are necessary to account for the uncertainty in reading the system clock in both the server and the client.
秒カウンターに従ってt_0で測定が行われたとき。ここで、r.rhoはセクション7.3で説明されているパケット精度であり、s.rhoはセクション11.1で説明されているシステム精度で、どちらも秒単位で表されます。これらの用語は、サーバーとクライアントの両方でシステムクロックを読み取る際の不確実性を説明するために必要です。
The dispersion then grows at constant rate PHI; in other words, at time t, epsilon(t) = epsilon(t_0) + PHI * (t-t_0). With the default value PHI = 15 ppm, this amounts to about 1.3 s per day. With this understanding, the argument t will be dropped and the dispersion represented simply as epsilon. The remaining statistics are computed by the clock filter algorithm described in the next section.
その後、分散は一定の速度PHIで増加します。言い換えると、時間tで、epsilon（t）= epsilon（t_0）+ PHI *（t-t_0）になります。デフォルト値PHI = 15 ppmでは、これは1日あたり約1.3秒になります。この理解により、引数tは削除され、分散は単にイプシロンとして表されます。残りの統計は、次のセクションで説明するクロックフィルターアルゴリズムによって計算されます。
The clock filter algorithm is part of the peer process. It grooms the stream of on-wire data to select the samples most likely to represent accurate time. The algorithm produces the variables shown in Figure 19, including the offset (theta), delay (delta), dispersion (epsilon), jitter (psi), and time of arrival (t). These data are used by the mitigation algorithms to determine the best and final offset used to discipline the system clock. They are also used to determine the server health and whether it is suitable for synchronization.
クロックフィルターアルゴリズムはピアプロセスの一部です。正確な時間を表す可能性が最も高いサンプルを選択するために、ネットワーク上のデータのストリームをグルーミングします。このアルゴリズムは、オフセット（theta）、遅延（delta）、分散（epsilon）、ジッター（psi）、到着時間（t）など、図19に示す変数を生成します。これらのデータは、システムクロックを統制するために使用される最適な最終オフセットを決定するために、軽減アルゴリズムによって使用されます。また、サーバーの正常性と同期に適しているかどうかを判断するためにも使用されます。
The clock filter algorithm saves the most recent sample tuples (theta, delta, epsilon, t) in the filter structure, which functions as an 8-stage shift register. The tuples are saved in the order that packets arrive. Here, t is the packet time of arrival according to the seconds counter and should not be confused with the peer variable tp.
クロックフィルターアルゴリズムは、最新のサンプルタプル（シータ、デルタ、イプシロン、t）を8段シフトレジスタとして機能するフィルター構造に保存します。タプルは、パケットが到着した順に保存されます。ここで、tは秒数カウンターによるパケットの到着時間であり、ピア変数tpと混同しないでください。
The following scheme is used to ensure sufficient samples are in the filter and that old stale data are discarded. Initially, the tuples of all stages are set to the dummy tuple (0, MAXDISP, MAXDISP, 0). As valid packets arrive, tuples are shifted into the filter causing old tuples to be discarded, so eventually only valid tuples remain.
次のスキームを使用して、十分なサンプルがフィルターにあり、古いデータが破棄されるようにします。最初は、すべてのステージのタプルがダミータプル（0、MAXDISP、MAXDISP、0）に設定されています。有効なパケットが到着すると、タプルがフィルターにシフトされ、古いタプルが破棄されるため、最終的には有効なタプルのみが残ります。
If the three low-order bits of the reach register are zero, indicating three poll intervals have expired with no valid packets received, the poll process calls the clock filter algorithm with a dummy tuple just as if the tuple had arrived from the network. If this persists for eight poll intervals, the register returns to the initial condition.
リーチレジスタの下位3ビットが0の場合、有効なパケットを受信せずに3つのポーリング間隔が終了したことを示し、ポーリングプロセスは、タプルがネットワークから到着したかのように、ダミーのタプルを使用してクロックフィルターアルゴリズムを呼び出します。これが8つのポーリング間隔の間続く場合、レジスターは初期状態に戻ります。
In the next step, the shift register stages are copied to a temporary list and the list sorted by increasing delta. Let i index the stages starting with the lowest delta. If the first tuple epoch t_0 is not later than the last valid sample epoch tp, the routine exits without affecting the current peer variables. Otherwise, let epsilon_i be the dispersion of the ith entry, then
次のステップでは、シフトレジスタステージが一時リストにコピーされ、リストはデルタの増加によってソートされます。最も低いデルタから始まるステージにインデックスを付けます。最初のタプルエポックt_0が最後の有効なサンプルエポックtpより遅くない場合、ルーチンは現在のピア変数に影響を与えずに終了します。それ以外の場合、epsilon_iをi番目のエントリの分散とすると、
i=n-1
--- epsilon_i
epsilon = \ ----------
/ (i+1)
--- 2
i=0
is the peer dispersion p.disp. Note the overload of epsilon, whether input to the clock filter or output, the meaning should be clear from context.
ピア分散p.dispです。イプシロンの過負荷に注意してください。クロックフィルターへの入力であろうと出力であろうと、その意味は文脈から明確であるべきです。
The observer should note (a) if all stages contain the dummy tuple with dispersion MAXDISP, the computed dispersion is a little less than 16 s, (b) each time a valid tuple is shifted into the register, the dispersion drops by a little less than half, depending on the valid tuples dispersion, and (c) after the fourth valid packet the dispersion is usually a little less than 1 s, which is the assumed value of the MAXDIST parameter used by the selection algorithm to determine whether or not the peer variables are acceptable.
オブザーバーは、（a）すべてのステージに分散MAXDISPのダミータプルが含まれている場合、計算された分散は16秒未満です（b）有効なタプルがレジスターにシフトされるたびに、分散は少し少なくなります有効なタプルの分散に応じて、半分よりも多く、（c）4番目の有効なパケットの後、分散は通常1秒よりわずかに少なくなります。これは、選択アルゴリズムがMAXDISTパラメータの想定値であり、ピア変数は受け入れ可能です。
Let the first stage offset in the sorted list be theta_0; then, for the other stages in any order, the jitter is the RMS average
ソートされたリストの最初のステージのオフセットをtheta_0とします。次に、任意の他のステージの場合、ジッターはRMS平均です
+----- -----+^1/2
| n-1 |
| --- |
1 | \ 2 |
psi = -------- * | / (theta_0-theta_j) |
(n-1) | --- |
| j=1 |
+----- -----+
where n is the number of valid tuples in the filter (n > 1). In order to ensure consistency and avoid divide exceptions in other computations, the psi is bounded from below by the system precision s.rho expressed in seconds. While not in general considered a major factor in ranking server quality, jitter is a valuable indicator of fundamental timekeeping performance and network congestion state. Of particular importance to the mitigation algorithms is the peer synchronization distance, which is computed from the delay and dispersion.
ここで、nはフィルター内の有効なタプルの数です（n> 1）。一貫性を確保し、他の計算での例外の分割を回避するために、psiは、秒単位で表されるシステム精度s.rhoによって下から制限されます。一般に、サーバー品質のランク付けにおける主要な要因とは見なされていませんが、ジッターは基本的な計時パフォーマンスとネットワークの輻輳状態の貴重な指標です。軽減アルゴリズムで特に重要なのは、遅延と分散から計算されるピア同期距離です。
lambda = (delta / 2) + epsilon.
Note that epsilon and therefore lambda increase at rate PHI. The lambda is not a state variable, since lambda is recalculated at each use. It is a component of the root synchronization distance used by the mitigation algorithms as a metric to evaluate the quality of time available from each server.
イプシロン、したがってラムダはレートPHIで増加することに注意してください。ラムダは使用ごとに再計算されるため、ラムダは状態変数ではありません。これは、各サーバーから利用可能な時間の質を評価するメトリックとして、軽減アルゴリズムによって使用されるルート同期距離のコンポーネントです。
It is important to note that, unlike NTPv3, NTPv4 associations do not show a timeout condition by setting the stratum to 16 and leap indicator to 3. The association variables retain the values determined upon arrival of the last packet. In NTPv4, lambda increases with time, so eventually the synchronization distance exceeds the distance threshold MAXDIST, in which case the association is considered unfit for synchronization.
NTPv3とは異なり、NTPv4アソシエーションは、ストラタムを16に設定し、リープインジケーターを3に設定しても、タイムアウト条件を示さないことに注意することが重要です。アソシエーション変数は、最後のパケットの到着時に決定された値を保持します。 NTPv4では、ラムダは時間とともに増加するため、最終的に同期距離は距離しきい値MAXDISTを超えます。この場合、関連付けは同期に適さないと見なされます。
An example implementation of the clock filter algorithm is shown in the clock_filter() routine of Appendix A.5.2.
クロックフィルターアルゴリズムの実装例は、付録A.5.2のclock_filter()ルーチンに示されています。
As each new sample (theta, delta, epsilon, jitter, t) is produced by the clock filter algorithm, all peer processes are scanned by the mitigation algorithms consisting of the selection, cluster, combine, and clock discipline algorithms in the system process. The selection algorithm scans all associations and casts off the falsetickers, which have demonstrably incorrect time, leaving the truechimers as result. In a series of rounds, the cluster algorithm discards the association statistically furthest from the centroid until a specified minimum number of survivors remain. The combine algorithm produces the best and final statistics on a weighted average basis. The final offset is passed to the clock discipline algorithm to steer the system clock to the correct time.
新しい各サンプル（シータ、デルタ、イプシロン、ジッター、t）は、クロックフィルターアルゴリズムによって生成されるため、すべてのピアプロセスは、システムプロセスの選択、クラスター、結合、およびクロック規律アルゴリズムで構成される軽減アルゴリズムによってスキャンされます。選択アルゴリズムはすべての関連付けをスキャンして、明らかに不正確な時間を持つ偽ティッカーをキャストオフし、結果としてtruechimersを残します。一連のラウンドでは、クラスターアルゴリズムは、指定された最小数の生存者が残るまで、重心から統計的に最も遠い関連付けを破棄します。結合アルゴリズムは、加重平均に基づいて最良の最終統計を生成します。最終的なオフセットは、システムクロックを正しい時間に導くために、クロックディシプリンアルゴリズムに渡されます。
The cluster algorithm selects one of the survivors as the system peer. The associated statistics (theta, delta, epsilon, jitter, t) are used to construct the system variables inherited by dependent servers and clients and made available to other applications running on the same machine.
クラスタアルゴリズムは、生存者の1つをシステムピアとして選択します。関連する統計（シータ、デルタ、イプシロン、ジッター、t）を使用して、依存サーバーとクライアントに継承され、同じマシンで実行されている他のアプリケーションで利用できるシステム変数を構築します。
Figure 23 summarizes the common names, formula names, and a short description of each system variable. Unless noted otherwise, all variables have assumed prefix s.
図23は、一般的な名前、式の名前、および各システム変数の簡単な説明をまとめたものです。特に明記しない限り、すべての変数は接頭辞sを想定しています。
+-----------+------------+------------------------+
| Name | Formula | Description |
+-----------+------------+------------------------+
| t | t | update time |
| p | p | system peer identifier |
| leap | leap | leap indicator |
| stratum | stratum | stratum |
| precision | rho | precision |
| offset | THETA | combined offset |
| jitter | PSI | combined jitter |
| rootdelay | DELTA | root delay |
| rootdisp | EPSILON | root dispersion |
| v | v | survivor list |
| refid | refid | reference ID |
| reftime | reftime | reference time |
| NMIN | 3 | minimum survivors |
| CMIN | 1 | minimum candidates |
+-----------+------------+------------------------+
Figure 23: System Process Variables
図23：システムプロセス変数
Except for the t, p, offset, and jitter variables and the NMIN and CMIN constants, the variables have the same format and interpretation as the peer variables of the same name. The NMIN and CMIN parameters are used by the selection and cluster algorithms described in the next section.
t、p、offset、jitter変数とNMINおよびCMIN定数を除いて、変数の形式と解釈は同じ名前のピア変数と同じです。 NMINパラメータとCMINパラメータは、次のセクションで説明する選択アルゴリズムとクラスタアルゴリズムで使用されます。
The t variable is the seconds counter at the time of the last update. An example is shown by the clock_update() routine in Appendix A.5.5.4. The p variable is the system peer identifier determined by the cluster() routine in Section 11.2.2. The precision variable has the same format as the packet variable of the same name. The precision is defined as the larger of the resolution and time to read the clock, in log2 units. For instance, the precision of a mains-frequency clock incrementing at 60 Hz is 16 ms, even when the system clock hardware representation is to the nanosecond.
t変数は、最後の更新時の秒数カウンターです。例は、付録A.5.5.4のclock_update()ルーチンで示されています。 p変数は、セクション11.2.2のcluster()ルーチンによって決定されるシステムピア識別子です。精度変数の形式は、同じ名前のパケット変数と同じです。精度は、log2単位で、分解能とクロックを読み取る時間の大きい方として定義されます。たとえば、システムクロックのハードウェア表現がナノ秒の場合でも、60 Hzでインクリメントする主周波数クロックの精度は16 msです。
The offset and jitter variables are determined by the combine algorithm in Section 11.2.3. These values represent the best and final offset and jitter used to discipline the system clock.
オフセットおよびジッター変数は、セクション11.2.3の結合アルゴリズムによって決定されます。これらの値は、システムクロックを統制するために使用される最適な最終オフセットとジッターを表します。
Initially, all variables are cleared to zero, then the leap is set to 3 (unsynchronized) and stratum is set to MAXSTRAT (16). Remember that MAXSTRAT is mapped to zero in the transmitted packet.
最初に、すべての変数がゼロにクリアされ、次に、跳躍は3（非同期）に設定され、層はMAXSTRAT（16）に設定されます。 MAXSTRATは送信されたパケットでゼロにマッピングされることに注意してください。
Figure 24 summarizes the system process operations performed by the clock select routine. The selection algorithm described in Section 11.2.1 produces a majority clique of presumed correct candidates (truechimers) based on agreement principles. The cluster algorithm described in Section 11.2.2 discards outliers to produce the most accurate survivors. The combine algorithm described in Section 11.2.3 provides the best and final offset for the clock discipline algorithm. An example is described in Appendix A.5.5.6. If the selection algorithm cannot produce a majority clique, or if it cannot produce at least CMIN survivors, the system process exits without disciplining the system clock. If successful, the cluster algorithm selects the statistically best candidate as the system peer and its variables are inherited as the system variables.
図24は、クロック選択ルーチンによって実行されるシステムプロセス動作をまとめたものです。セクション11.2.1で説明されている選択アルゴリズムは、合意の原則に基づいて、推定される正しい候補（truechimers）の多数派を生成します。セクション11.2.2で説明するクラスターアルゴリズムは、異常値を破棄して最も正確な生存者を生成します。セクション11.2.3で説明する結合アルゴリズムは、クロック規律アルゴリズムに最適かつ最終的なオフセットを提供します。例は、付録A.5.5.6で説明されています。選択アルゴリズムが過半数のクリークを生成できない場合、または少なくともCMINサバイバーを生成できない場合、システムプロセスはシステムクロックを調整せずに終了します。成功した場合、クラスターアルゴリズムは統計的に最適な候補をシステムピアとして選択し、その変数はシステム変数として継承されます。
+-----------------+
| clock_select() |
+-----------------+
................................|...........
. V .
. yes +---------+ +-----------------+ .
. +--| accept? | | scan candidates | .
. | +---------+ | | .
. V no | | | .
. +---------+ | | | .
. | add peer| | | | .
. +---------- | | | .
. | V | | .
. +---------->-->| | .
. | | .
. Selection Algorithm +-----------------+ .
.................................|..........
V
no +-------------------+
+-------------| survivors? |
| +-------------------+
| | yes
| V
| +-------------------+
| | Cluster Algorithm |
| +-------------------+
| |
| V
V yes +-------------------+
|<------------| n < CMIN? |
| +-------------------+
V |
+-----------------+ V no
| s.p = NULL | +-------------------+
+-----------------+ | s.p = v_0.p |
| +-------------------+
V |
+-----------------+ V
| return (UNSYNC) | +-------------------+
+-----------------+ | return (SYNC) |
+-------------------+
Figure 24: Clock Select Routine
図24：クロック選択ルーチン
Note that the selection and cluster algorithms are described separately, but combined in the code skeleton. The selection algorithm operates to find an intersection interval containing a majority clique of truechimers using Byzantine agreement principles originally proposed by Marzullo [ref6], but modified to improve accuracy. An overview of the algorithm is given below and described in the first half of the clock_select() routine in Appendix A.5.5.1.
選択アルゴリズムとクラスターアルゴリズムは個別に説明されていますが、コードスケルトンにまとめられています。選択アルゴリズムは、もともとMarzullo [ref6]によって提案されたビザンチン合意原理を使用して、真のキメラの多数派を含む交差区間を見つけるように動作しますが、精度を向上させるために変更されました。アルゴリズムの概要を以下に示し、付録A.5.5.1のclock_select()ルーチンの前半で説明します。
First, those servers that are unusable according to the rules of the protocol are detected and discarded as shown by the accept() routine in Appendix A.5.5.3. Next, a set of tuples (p, type, edge) is generated for the remaining candidates. Here, p is the association identifier and type identifies the upper (+1), middle (0), and lower (-1) endpoints of a correctness interval centered on theta for that candidate. This results in three tuples, lowpoint (p, -1, theta - lambda), midpoint (p, 0, theta), and highpoint (p, +1, theta + lambda), where lambda is the root synchronization distance. An example of this calculation is shown by the rootdist() routine in Appendix A.5.1.1. The steps of the algorithm are:
まず、付録A.5.5.3のaccept()ルーチンに示されているように、プロトコルのルールに従って使用できないサーバーが検出され、破棄されます。次に、残りの候補に対してタプルのセット（p、タイプ、エッジ）が生成されます。ここで、pは関連識別子であり、タイプは、その候補のシータを中心とする正確性区間の上限（+1）、中間（0）、および下限（-1）の端点を識別します。これにより、3つのタプル、lowpoint（p、-1、theta-lambda）、midpoint（p、0、theta）、highpoint（p、+1、theta + lambda）が生成されます。ここで、lambdaはルート同期距離です。この計算の例は、付録A.5.1.1のrootdist()ルーチンで示されています。アルゴリズムのステップは次のとおりです。
1. For each of m associations, place three tuples as defined above on the candidate list.
1. m個の関連付けのそれぞれについて、上記で定義した3つのタプルを候補リストに配置します。
2. Sort the tuples on the list by the edge component. Order the lowpoint, midpoint, and highpoint of these intervals from lowest to highest. Set the number of falsetickers f = 0.
2. リストのタプルをエッジコンポーネントで並べ替えます。これらの間隔の最低点、中点、および最高点を最低から最高の順に並べます。偽ティッカーの数をf = 0に設定します。
3. Set the number of midpoints d = 0. Set c = 0. Scan from lowest endpoint to highest. Add one to c for every lowpoint, subtract one for every highpoint, add one to d for every midpoint. If c >= m - f, stop; set l = current lowpoint.
3. 中点の数をd = 0に設定します。c= 0に設定します。最低端点から最高端までスキャンします。すべての低点に対して1をcに加算し、すべての高点に対して1を減算し、すべての中点に対して1をdに加算します。 c> = m-fの場合、停止します。 l =現在の最低点を設定します。
4. Set c = 0. Scan from highest endpoint to lowest. Add one to c for every highpoint, subtract one for every lowpoint, add one to d for every midpoint. If c >= m - f, stop; set u = current highpoint.
4. c = 0に設定します。最高のエンドポイントから最低のエンドポイントまでスキャンします。すべての高点に対してcに1を加算し、すべての低点に対して1を減算し、すべての中点に対して1をdに加算します。 c> = m-fの場合、停止します。 u =現在のハイポイントを設定します。
5. Is d = f and l < u? If yes, then follow step 5A; else, follow step 5B.
5. d = fかつl <uですか？はいの場合、ステップ5Aに従います。それ以外の場合は、ステップ5Bに従います。
5A. Success: the intersection interval is [l, u].
5A。成功：交差間隔は[l、u]です。
5B. Add one to f. Is f < (m / 2)? If yes, then go to step 3 again. If no, then go to step 6.
5B。 fに1を追加します。 f <（m / 2）ですか？ 「はい」の場合、ステップ3に再度進みます。いいえの場合は、手順6に進みます。
6. Failure; a majority clique could not be found. There are no suitable candidates to discipline the system clock.
6. 失敗;大部分のクリークは見つかりませんでした。システムクロックを統制する適切な候補はありません。
The algorithm is described in detail in Appendix A.5.5.1. Note that it starts with the assumption that there are no falsetickers (f = 0) and attempts to find a non-empty intersection interval containing the midpoints of all correct servers, i.e., truechimers. If a non-empty interval cannot be found, it increases the number of assumed falsetickers by one and tries again. If a non-empty interval is found and the number of falsetickers is less than the number of truechimers, a majority clique has been found and the midpoint of each truechimer (theta) represents the candidates available to the cluster algorithm.
このアルゴリズムについては、付録A.5.5.1で詳しく説明しています。これは、偽ティッカーがない（f = 0）との仮定から始まり、すべての正しいサーバー（つまり、truechimers）の中点を含む空でない交差区間を見つけようとすることに注意してください。空でない間隔が見つからない場合は、想定される偽ティッカーの数が1つ増え、再試行されます。空でない間隔が見つかり、偽ティッカーの数がtruechimersの数よりも少ない場合、多数派クリークが見つかり、各truechimerの中点（シータ）はクラスターアルゴリズムで使用できる候補を表します。
If a majority clique is not found, or if the number of truechimers is less than CMIN, there are insufficient candidates to discipline the system clock. CMIN defines the minimum number of servers consistent with the correctness requirements. Suspicious operators would set CMIN to ensure multiple redundant servers are available for the algorithms to mitigate properly. However, for historic reasons the default value for CMIN is one.
大多数のクリークが見つからない場合、またはtruechimersの数がCMIN未満の場合は、システムクロックを統制するための候補が不十分です。 CMINは、正確さの要件に一致するサーバーの最小数を定義します。不審なオペレーターは、CMINを設定して、アルゴリズムが適切に軽減するために複数の冗長サーバーを利用できるようにします。ただし、歴史的な理由により、CMINのデフォルト値は1です。
The candidates of the majority clique are placed on the survivor list v in the form of tuples (p, theta_p, psi_p, lambda_p), where p is an association identifier, theta_p, psi_p, and stratum_p the current offset, jitter and stratum of association p, respectively, and lambda_p is a merit factor equal to stratum_p * MAXDIST + lambda, where lambda is the root synchronization distance for association p. The list is processed by the cluster algorithm below. An example is shown by the second half of the clock_select() algorithm in Appendix A.5.5.1.
多数派クリークの候補は、タプル（p、theta_p、psi_p、lambda_p）の形式でサバイバーリストvに配置されます。ここで、pは関連識別子、theta_p、psi_p、およびstratum_pは、現在のオフセット、ジッター、関連の層です。それぞれp、およびlambda_pはstratum_p * MAXDIST + lambdaに等しいメリット係数です。ここで、lambdaは関連付けpのルート同期距離です。リストは、以下のクラスターアルゴリズムによって処理されます。例は、付録A.5.5.1のclock_select()アルゴリズムの後半に示されています。
1. Let (p, theta_p, psi_p, lambda_p) represent a survivor candidate.
1. （p、theta_p、psi_p、lambda_p）が生存者候補を表すとします。
2. Sort the candidates by increasing lambda_p. Let n be the number of candidates and NMIN the minimum required number of survivors.
2. lambda_pを増やして候補を並べ替えます。 nを候補者の数、NMINを生存者の最小必要数とする。
3. For each candidate, compute the selection jitter psi_s:
3. 候補ごとに、選択ジッターpsi_sを計算します。
+----- -----+^1/2
| n-1 |
| --- |
| 1 \ 2 |
psi_s = | ---- * / (theta_s - theta_j) |
| n-1 --- |
| j=1 |
+----- -----+
4. Select psi_max as the candidate with maximum psi_s.
4. 最大psi_sの候補としてpsi_maxを選択します。
5. Select psi_min as the candidate with minimum psi_p.
5. psi_pが最小の候補としてpsi_minを選択します。
6. Is psi_max < psi_min or n <= NMIN? If yes, follow step 6A; otherwise, follow step 6B.
6. psi_max <psi_minまたはn <= NMINですか？はいの場合、ステップ6Aに従います。それ以外の場合は、ステップ6Bに従います。
6A. Done. The remaining candidates on the survivor list are ranked in the order of preference. The first entry on the list represents the system peer; its variables are used later to update the system variables.
6A。できました。生存者リストの残りの候補者は、優先順位でランク付けされます。リストの最初のエントリはシステムピアを表しています。その変数は、システム変数を更新するために後で使用されます。
6B. Delete the outlier candidate with psi_max; reduce n by one and go back to step 3.
6B。 psi_maxで外れ値候補を削除します。 nを1つ減らし、ステップ3に戻ります。
The algorithm operates in a series of rounds where each round discards the statistical outlier with maximum selection jitter psi_s. However, if psi_s is less than the minimum peer jitter psi_p, no improvement is possible by discarding outliers. This and the minimum number of survivors represent the terminating conditions of the algorithm. Upon termination, the final value of psi_max is saved as the system selection jitter PSI_s for use later.
アルゴリズムは一連のラウンドで動作し、各ラウンドは最大選択ジッターpsi_sの統計的外れ値を破棄します。ただし、psi_sが最小ピアジッタpsi_pより小さい場合、外れ値を破棄しても改善はありません。これと生存者の最小数は、アルゴリズムの終了条件を表します。終了時に、psi_maxの最終値は、後で使用するためにシステム選択ジッタPSI_sとして保存されます。
The clock combine route processes the remaining survivors to produce the best and final data for the clock discipline algorithm. The routine processes peer offset and jitter statistics to produce the combined system offset THETA and system peer jitter PSI_p, where each server statistic is weighted by the reciprocal of the root synchronization distance and the result normalized. An example is shown by the clock_combine() routine in Appendix A.5.5.5
クロック結合ルートは、残りの生存者を処理して、クロック規律アルゴリズムに最適な最終データを生成します。このルーチンは、ピアオフセットとジッターの統計を処理して、システムオフセットTHETAとシステムピアジッタの組み合わせPSI_pを生成します。各サーバーの統計は、ルート同期距離の逆数と、正規化された結果によって重み付けされます。例は、付録A.5.5.5のclock_combine()ルーチンで示されています。
The combined THETA is passed to the clock update routine. The first candidate on the survivor list is nominated as the system peer with identifier p. The system peer jitter PSI_p is a component of the system jitter PSI. It is used along with the selection jitter PSI_s to produce the system jitter:
結合されたTHETAは、クロック更新ルーチンに渡されます。サバイバーリストの最初の候補は、識別子pのシステムピアとして指名されます。システムピアジッタPSI_pは、システムジッタPSIのコンポーネントです。これは、選択ジッタPSI_sとともに使用され、システムジッタを生成します。
PSI = [(PSI_s)^2 + (PSI_p)^2]^1/2
Each time an update is received from the system peer, the clock update routine is called. By rule, an update is discarded if its time of arrival p.t is not strictly later than the last update used s.t. The labels IGNOR, PANIC, ADJ, and STEP refer to return codes from the local clock routine described in the next section.
システムピアから更新を受信するたびに、クロック更新ルーチンが呼び出されます。原則として、到着時刻p.tがs.tで使用された最後の更新より厳密に遅い場合、更新は破棄されます。ラベルIGNOR、PANIC、ADJ、およびSTEPは、次のセクションで説明するローカルクロックルーチンからの戻りコードを参照します。
IGNORE means the update has been ignored as an outlier. PANIC means the offset is greater than the panic threshold PANICT (1000 s) and SHOULD cause the program to exit with a diagnostic message to the system log. STEP means the offset is less than the panic threshold, but greater than the step threshold STEPT (125 ms). In this case, the clock is stepped to the correct offset, but since this means all peer data have been invalidated, all associations MUST be reset and the client begins as at initial start.
IGNOREは、更新が外れ値として無視されたことを意味します。 PANICは、オフセットがパニックしきい値PANICT（1000秒）より大きいことを意味し、システムログへの診断メッセージを表示してプログラムを終了する必要があります（SHOULD）。 STEPは、オフセットがパニックしきい値よりも小さいが、ステップしきい値STEPT（125 ms）よりも大きいことを意味します。この場合、クロックは正しいオフセットにステップされますが、これはすべてのピアデータが無効化されていることを意味するため、すべての関連付けをリセットする必要があり、クライアントは最初の開始時と同じように開始します。
ADJ means the offset is less than the step threshold and thus a valid update. In this case, the system variables are updated from the peer variables as shown in Figure 25.
ADJは、オフセットがステップしきい値よりも小さいため、有効な更新であることを意味します。この場合、システム変数は、図25に示すように、ピア変数から更新されます。
+-------------------------------------------+
| System Variable <-- System Peer Variable | |
+-------------------------------------------+
| s.leap <-- p.leap |
| s.stratum <-- p.stratum + 1 |
| s.offset <-- THETA |
| s.jitter <-- PSI |
| s.rootdelay <-- p.delta_r + delta |
| s.rootdisp <-- p.epsilon_r + p.epsilon + |
| p.psi + PHI * (s.t - p.t) |
| + |THETA| |
| s.refid <-- p.refid |
| s.reftime <-- p.reftime |
| s.t <-- p.t |
+-------------------------------------------+
Figure 25: System Variables Update
図25：システム変数の更新
There is an important detail not shown. The dispersion increment (p.epsilon + p.psi + PHI * (s.t - p.t) + |THETA|) is bounded from below by MINDISP. In subnets with very fast processors and networks and very small delay and dispersion this forces a monotone-definite increase in s.rootdisp (EPSILON), which avoids loops between peers operating at the same stratum.
表示されていない重要な詳細があります。分散増分（p.epsilon + p.psi + PHI *（s.t-p.t）+ | THETA |）は、MINDISPによって下から制限されます。非常に高速なプロセッサとネットワークがあり、遅延と分散が非常に小さいサブネットでは、これによりs.rootdisp（EPSILON）が単調に増加し、同じ層で動作しているピア間のループが回避されます。
The system variables are available to dependent application programs as nominal performance statistics. The system offset THETA is the clock offset relative to the available synchronization sources. The system jitter PSI is an estimate of the error in determining this value, elsewhere called the expected error. The root delay DELTA is the total round-trip delay relative to the primary server. The root dispersion EPSILON is the dispersion accumulated over the network from the primary server. Finally, the root synchronization distance is defined as: LAMBDA = EPSILON + DELTA / 2,
システム変数は、従属アプリケーションプログラムで公称パフォーマンス統計として使用できます。システムオフセットTHETAは、使用可能な同期ソースに対するクロックオフセットです。システムジッタPSIは、この値を決定する際のエラーの推定値であり、予想されるエラーとも呼ばれます。ルート遅延DELTAは、プライマリサーバーに対する相対的な総往復遅延です。ルート分散EPSILONは、プライマリサーバーからネットワーク上に蓄積された分散です。最後に、ルート同期距離は次のように定義されます：LAMBDA = EPSILON + DELTA / 2
which represents the maximum error due all causes and is designated the root synchronization distance.
これは、すべての原因による最大エラーを表し、ルート同期距離として指定されます。
An example of the clock update routine is provided in Appendix A.5.5.4.
クロック更新ルーチンの例は、付録A.5.5.4にあります。
The NTPv4 clock discipline algorithm, shortened to discipline in the following, functions as a combination of two quite philosophically different feedback control systems. In a phase-locked loop (PLL) design, periodic phase updates at update intervals mu seconds are used directly to minimize the time error and indirectly the frequency error. In a frequency-locked loop (FLL) design, periodic frequency updates at intervals mu are used directly to minimize the frequency error and indirectly the time error. As shown in [ref7], a PLL usually works better when network jitter dominates, while an FLL works better when oscillator wander dominates. This section contains an outline of how the NTPv4 design works. An in-depth discussion of the design principles is provided in [ref7], which also includes a performance analysis.
NTPv4クロック規律アルゴリズムは、以下では規律に短縮され、2つのまったく哲学的に異なるフィードバック制御システムの組み合わせとして機能します。位相ロックループ（PLL）設計では、更新間隔mu秒で定期的な位相更新を直接使用して、時間誤差を最小化し、周波数誤差を間接的に最小化します。周波数ロックループ（FLL）設計では、間隔muで定期的な周波数更新を直接使用して、周波数誤差を最小限に抑え、間接的に時間誤差を最小限に抑えます。 [ref7]に示されているように、PLLは通常、ネットワークジッタが支配的である場合により適切に機能し、FLLは発振器ワンダーが支配的である場合により適切に機能します。このセクションには、NTPv4設計の仕組みの概要が含まれています。設計原理の詳細な説明は、[ref7]で提供され、パフォーマンス分析も含まれます。
The discipline is implemented as the feedback control system shown in Figure 26. The variable theta_r represents the combine algorithm offset (reference phase) and theta_c the VFO offset (control phase). Each update produces a signal V_d representing the instantaneous phase difference theta_r - theta_c. The clock filter for each server functions as a tapped delay line, with the output taken at the tap selected by the clock filter algorithm. The selection, cluster, and combine algorithms combine the data from multiple filters to produce the signal V_s. The loop filter, with impulse response F(t), produces the signal V_c, which controls the VFO frequency omega_c and thus the integral of the phase theta_c which closes the loop. The V_c signal is generated by the clock-adjust process in Section 12. The detailed equations that implement these functions are best presented in the routines of Appendices A.5.5.6 and A.5.6.1.
規律は、図26に示すフィードバック制御システムとして実装されます。変数theta_rは、結合アルゴリズムのオフセット（基準フェーズ）を表し、theta_cはVFOオフセット（制御フェーズ）を表します。更新ごとに、瞬時位相差theta_r-theta_cを表す信号V_dが生成されます。各サーバーのクロックフィルターはタップ付き遅延ラインとして機能し、出力はクロックフィルターアルゴリズムによって選択されたタップで取得されます。選択、クラスター化、および結合のアルゴリズムは、複数のフィルターからのデータを結合して、信号V_sを生成します。ループフィルターは、インパルス応答F（t）で、信号V_cを生成します。これは、VFO周波数omega_cを制御し、ループを閉じる位相theta_cの積分を制御します。 V_c信号は、セクション12のクロック調整プロセスによって生成されます。これらの関数を実装する詳細な方程式は、付録A.5.5.6とA.5.6.1のルーチンに最もよく示されています。
theta_r + +---------\ +----------------+
NTP --------->| Phase \ V_d | | V_s
theta_c - | Detector ------>| Clock Filter |----+
+-------->| / | | |
| +---------/ +----------------+ |
| |
----- |
/ \ |
| VFO | |
\ / |
----- ....................................... |
^ . Loop Filter . |
| . +---------+ x +-------------+ . |
| V_c . | |<-----| | . |
+------.-| Clock | y | Phase/Freq |<---------+
. | Adjust |<-----| Prediction | .
. | | | | .
. +---------+ +-------------+ .
.......................................
Figure 26: Clock Discipline Feedback Loop
図26：クロック規律フィードバックループ
Ordinarily, the pseudo-linear feedback loop described above operates to discipline the system clock. However, there are cases where a non-linear algorithm offers considerable improvement. One case is when the discipline starts without knowledge of the intrinsic clock frequency. The pseudo-linear loop takes several hours to develop an accurate measurement and during most of that time the poll interval cannot be increased. The non-linear loop described below does this in 15 minutes. Another case is when occasional bursts of large jitter are present due to congested network links. The state machine described below resists error bursts lasting less than 15 minutes.
通常、上記の疑似線形フィードバックループは、システムクロックを制御するように動作します。ただし、非線形アルゴリズムが大幅な改善をもたらす場合があります。 1つのケースは、本来のクロック周波数を知らずに規律が始まる場合です。疑似線形ループは、正確な測定を行うのに数時間かかり、その間、ポーリング間隔を長くすることはできません。以下で説明する非線形ループは、15分でこれを実行します。もう1つのケースは、ネットワークリンクの輻輳が原因で、大きなジッターが時折発生する場合です。以下で説明するステートマシンは、15分未満続くエラーバーストに抵抗します。
Figure 27 contains a summary of the variables and parameters including the variable (lowercase) or parameter (uppercase) name, formula name, and short description. Unless noted otherwise, all variables have assumed prefix c. The variables t, tc, state, hyster, and count are integers; the remaining variables are floating doubles. The function of each will be explained in the algorithm descriptions below.
図27には、変数（小文字）またはパラメーター（大文字）の名前、式の名前、短い説明など、変数とパラメーターの概要が含まれています。特に明記しない限り、すべての変数は接頭辞cを想定しています。変数t、tc、state、hyster、およびcountは整数です。残りの変数は浮動ダブルです。それぞれの機能については、以下のアルゴリズムの説明で説明します。
+--------+------------+--------------------------+
| Name | Formula | Description |
+--------+------------+--------------------------+
| t | timer | seconds counter |
| offset | theta | combined offset |
| resid | theta_r | residual offset |
| freq | phi | clock frequency |
| jitter | psi | clock offset jitter |
| wander | omega | clock frequency wander |
| tc | tau | time constant (log2) |
| state | state | state |
| adj | adj | frequency adjustment |
| hyster | hyster | hysteresis counter |
| STEPT | 125 | step threshold (.125 s) |
| WATCH | 900 | stepout thresh(s) |
| PANICT | 1000 | panic threshold (1000 s) |
| LIMIT | 30 | hysteresis limit |
| PGATE | 4 | hysteresis gate |
| TC | 16 | time constant scale |
| AVG | 8 | averaging constant |
+--------+------------+--------------------------+
Figure 27: Clock Discipline Variables and Parameters
図27：クロック分野の変数とパラメーター
The process terminates immediately if the offset is greater than the panic threshold PANICT (1000 s). The state transition function is described by the rstclock() function in Appendix A.5.5.7. Figure 28 shows the state transition function used by this routine. It has four columns showing, respectively, the state name, predicate and action if the offset theta is less than the step threshold, the predicate and actions otherwise, and finally some comments.
オフセットがパニックしきい値PANICT（1000秒）より大きい場合、プロセスはすぐに終了します。状態遷移関数は、付録A.5.5.7のrstclock()関数で説明されています。図28は、このルーチンで使用される状態遷移関数を示しています。オフセットシータがステップのしきい値よりも小さい場合は状態名、述語、アクションをそれぞれ示す4つの列があり、それ以外の場合は述語とアクション、最後にいくつかのコメントがあります。
+-------+---------------------+-------------------+--------------+
| State | theta < STEP | theta > STEP | Comments |
+-------+---------------------+-------------------+--------------+
| NSET | ->FREQ | ->FREQ | no frequency |
| | adjust time | step time | file |
+-------+---------------------+-------------------+--------------+
| FSET | ->SYNC | ->SYNC | frequency |
| | adjust time | step time | file |
+-------+---------------------+-------------------+--------------+
| SPIK | ->SYNC | if < 900 s ->SPIK | outlier |
| | adjust freq | else ->SYNC | detected |
| | adjust time | step freq | |
| | | step time | |
+-------+---------------------+-------------------+--------------+
| FREQ | if < 900 s ->FREQ | if < 900 s ->FREQ | initial |
| | else ->SYNC | else ->SYNC | frequency |
| | step freq | step freq | |
| | adjust time | adjust time | |
+-------+---------------------+-------------------+--------------+
| SYNC | ->SYNC | if < 900 s ->SPIK | normal |
| | adjust freq | else ->SYNC | operation |
| | adjust time | step freq | |
| | | step time | |
+-------+---------------------+-------------------+--------------+
Figure 28: State Transition Function
図28：状態遷移関数
In the table entries, the next state is identified by the arrow -> with the actions listed below. Actions such as adjust time and adjust frequency are implemented by the PLL/FLL feedback loop in the local_clock() routine. A step clock action is implemented by setting the clock directly, but this is done only after the stepout threshold WATCH (900 s) when the offset is more than the step threshold STEPT (.125 s). This resists clock steps under conditions of extreme network congestion.
テーブルエントリでは、次の状態は矢印で示され、次のアクションが示されます。時間の調整や周波数の調整などのアクションは、local_clock()ルーチンのPLL / FLLフィードバックループによって実装されます。ステップクロックアクションは、クロックを直接設定することで実装されますが、これは、オフセットがステップしきい値STEPT（.125 s）よりも大きい場合、ステップアウトしきい値WATCH（900 s）の後でのみ実行されます。これは、極端なネットワーク輻輳の条件下でのクロックステップに抵抗します。
The jitter (psi) and wander (omega) statistics are computed using an exponential average with weight factor AVG. The time constant exponent (tau) is determined by comparing psi with the magnitude of the current offset theta. If the offset is greater than PGATE (4) times the clock jitter, the hysteresis counter hyster is reduced by two; otherwise, it is increased by one. If hyster increases to the upper limit LIMIT (30), tau is increased by one; if it decreases to the lower limit -LIMIT (-30), tau is decreased by one. Normally, tau hovers near MAXPOLL, but quickly decreases if a temperature spike causes a frequency surge.
ジッター（psi）およびワンダー（オメガ）統計は、重み係数AVGを使用した指数平均を使用して計算されます。時定数指数（tau）は、psiと現在のオフセットシータの大きさを比較することによって決定されます。オフセットがPGATE（4）倍のクロックジッタよりも大きい場合、ヒステリシスカウンターのヒステリシスは2つ減少します。それ以外の場合は、1つ増加します。ヒスターが上限LIMIT（30）に増加すると、タウが1増加します。下限-LIMIT（-30）に減少すると、タウは1つ減少します。通常、タウはMAXPOLLの近くに移動しますが、温度スパイクによって周波数サージが発生すると急速に減少します。
The actual clock-adjust process runs at one-second intervals to add the frequency correction and a fixed percentage of the residual offset theta_r. The theta_r is, in effect, the exponential decay of the theta value produced by the loop filter at each update. The TC parameter scales the time constant to match the poll interval for convenience. Note that the dispersion EPSILON increases by PHI at each second.
実際のクロック調整プロセスは1秒間隔で実行され、周波数補正と残留オフセットtheta_rの固定パーセンテージを追加します。 theta_rは、実際には、各更新時にループフィルターによって生成されるtheta値の指数関数的減衰です。 TCパラメータは、便宜上、時定数をポーリング間隔と一致するようにスケーリングします。分散EPSILONは毎秒PHIずつ増加することに注意してください。
The clock-adjust process includes a timer interrupt facility driving the seconds counter c.t. It begins at zero when the service starts and increments once each second. At each interrupt, the clock_adjust() routine is called to incorporate the clock discipline time and frequency adjustments, then the associations are scanned to determine if the seconds counter equals or exceeds the p.next state variable defined in the next section. If so, the poll process is called to send a packet and compute the next p.next value.
クロック調整プロセスには、秒カウンターc.tを駆動するタイマー割り込み機能が含まれます。サービスが開始するとゼロから始まり、毎秒1回インクリメントします。各割り込みで、clock_adjust()ルーチンが呼び出されて、クロック規律の時間と周波数の調整が組み込まれます。次に、関連付けがスキャンされ、秒カウンタが次のセクションで定義するp.next状態変数と等しいか、それを超えているかどうかが判断されます。そうである場合、ポーリングプロセスが呼び出されてパケットが送信され、次のp.next値が計算されます。
An example of the clock-adjust process is shown by the clock_adjust() routine in Appendix A.5.6.1.
クロック調整プロセスの例は、付録A.5.6.1のclock_adjust()ルーチンで示されています。
Each association supports a poll process that runs at regular intervals to construct and send packets in symmetric, client, and broadcast server associations. It runs continuously, whether or not servers are reachable in order to manage the clock filter and reach register.
各アソシエーションは、対称、クライアント、およびブロードキャストサーバーアソシエーションでパケットを構築して送信するために定期的に実行されるポーリングプロセスをサポートします。クロックフィルターと到達レジスターを管理するためにサーバーに到達可能かどうかに関係なく、継続的に実行されます。
Figure 29 summarizes the common names, formula names, and a short description of the poll process variables (lowercase) and parameters (uppercase). Unless noted otherwise, all variables have assumed prefix p.
図29は、一般名、式名、およびポーリングプロセス変数（小文字）とパラメーター（大文字）の簡単な説明をまとめたものです。特に明記しない限り、すべての変数は接頭辞pを想定しています。
+---------+---------+--------------------+
| Name | Formula | Description |
+---------+---------+--------------------+
| hpoll | hpoll | host poll exponent |
| last | last | last poll time |
| next | next | next poll time |
| reach | reach | reach register |
| unreach | unreach | unreach counter |
| UNREACH | 24 | unreach limit |
| BCOUNT | 8 | burst count |
| BURST | flag | burst enable |
| IBURST | flag | iburst enable |
+---------+---------+--------------------+
Figure 29: Poll Process Variables and Parameters
図29：ポーリングプロセスの変数とパラメーター
The poll process variables are allocated in the association data structure along with the peer process variables. The following is a detailed description of the variables. The parameters will be called out in the following text.
ポーリングプロセス変数は、ピアプロセス変数と共に関連付けデータ構造に割り当てられます。以下は変数の詳細な説明です。次のテキストでパラメータが呼び出されます。
hpoll: signed integer representing the poll exponent, in log2 seconds
hpoll：ポーリング指数を表す符号付き整数、log2秒
last: integer representing the seconds counter when the most recent packet was sent
last：最新のパケットが送信されたときの秒数カウンターを表す整数
next: integer representing the seconds counter when the next packet is to be sent
next：次のパケットが送信されるときの秒数カウンターを表す整数
reach: 8-bit integer shift register shared by the peer and poll processes
リーチ：ピアプロセスとポーリングプロセスで共有される8ビット整数シフトレジスタ
unreach: integer representing the number of seconds the server has been unreachable
unreach：サーバーが到達不能であった秒数を表す整数
As described previously, once each second the clock-adjust process is called. This routine calls the poll routine for each association in turn. If the time for the next poll message is greater than the seconds counter, the routine returns immediately. Symmetric (modes 1, 2), client (mode 3), and broadcast server (mode 5) associations routinely send packets. A broadcast client (mode 6) association runs the routine to update the reach and unreach variables, but does not send packets. The poll process calls the transmit process to send a packet. If in a burst (burst > 0), nothing further is done except call the poll update routine to set the next poll interval.
前述のように、1秒ごとにクロック調整プロセスが呼び出されます。このルーチンは、各関連付けのポーリングルーチンを順番に呼び出します。次のポーリングメッセージの時間が秒数カウンターより大きい場合、ルーチンはすぐに戻ります。対称（モード1、2）、クライアント（モード3）、およびブロードキャストサーバー（モード5）の関連付けは、定期的にパケットを送信します。ブロードキャストクライアント（モード6）アソシエーションは、リーチ変数とアンリーチ変数を更新するルーチンを実行しますが、パケットを送信しません。ポーリングプロセスは、送信プロセスを呼び出してパケットを送信します。バースト（バースト> 0）の場合、ポーリング更新ルーチンを呼び出して次のポーリング間隔を設定する以外は何も行われません。
If not in a burst, the reach variable is shifted left by one bit, with zero replacing the rightmost bit. If the server has not been heard for the last three poll intervals, the clock filter routine is called to increase the dispersion. An example is shown in Appendix A.5.7.3.
バースト内でない場合、リーチ変数は1ビット左にシフトされ、右端のビットがゼロに置き換えられます。最後の3つのポーリング間隔でサーバーの応答がない場合は、クロックフィルタールーチンが呼び出されて分散を増やします。例を付録A.5.7.3に示します。
If the BURST flag is lit and the server is reachable and a valid source of synchronization is available, the client sends a burst of BCOUNT (8) packets at each poll interval. The interval between packets in the burst is two seconds. This is useful to accurately measure jitter with long poll intervals. If the IBURST flag is lit and this is the first packet sent when the server has been unreachable, the client sends a burst. This is useful to quickly reduce the synchronization distance below the distance threshold and synchronize the clock.
BURSTフラグが点灯し、サーバーに到達可能で、有効な同期ソースが利用可能な場合、クライアントは各ポーリング間隔でBCOUNT（8）パケットのバーストを送信します。バースト内のパケットの間隔は2秒です。これは、長いポーリング間隔でジッターを正確に測定するのに役立ちます。 IBURSTフラグが点灯していて、これがサーバーに到達できないときに送信された最初のパケットである場合、クライアントはバーストを送信します。これは、同期距離を距離しきい値未満にすばやく短縮し、クロックを同期するのに役立ちます。
If the P_MANY flag is lit in the p.flags word of the association, this is a manycast client association. Manycast client associations send client mode packets to designated multicast group addresses at MINPOLL intervals. The association starts out with a TTL of 1. If by the time of the next poll there are fewer than MINCLOCK servers have been mobilized, the ttl is increased by one. If the ttl reaches the limit TTLMAX, without finding MINCLOCK servers, the poll interval increases until reaching BEACON, when it starts over from the beginning.
アソシエーションのp.flagsワードでP_MANYフラグが点灯している場合、これはメニーキャストクライアントアソシエーションです。メニーキャストクライアントアソシエーションは、MINPOLL間隔で指定されたマルチキャストグループアドレスにクライアントモードパケットを送信します。関連付けは、TTLが1で始まります。次のポーリングの時点で、動員されているMINCLOCKサーバーよりも少ない場合、TTLは1増加します。 ttlがMINCLOCKサーバーを検出せずにTTLMAXの制限に達した場合、ポーリング間隔はBEACONに到達するまで増加し、最初からやり直します。
The poll() routine includes a feature that backs off the poll interval if the server becomes unreachable. If reach is nonzero, the server is reachable and unreach is set to zero; otherwise, unreach is incremented by one for each poll to the maximum UNREACH. Thereafter for each poll hpoll is increased by one, which doubles the poll interval up to the maximum MAXPOLL determined by the poll_update() routine. When the server again becomes reachable, unreach is set to zero, hpoll is reset to the tc system variable, and operation resumes normally.
poll()ルーチンには、サーバーが到達不能になった場合にポーリング間隔をバックオフする機能が含まれています。リーチがゼロ以外の場合、サーバーは到達可能であり、アンリーチはゼロに設定されます。それ以外の場合、到達不能はポーリングごとに1つずつ増加して最大到達不能になります。その後、ポーリングごとにhpollが1増加します。これにより、ポーリング間隔が、poll_update()ルーチンによって決定された最大MAXPOLLまで2倍になります。サーバーが再び到達可能になると、unreachはゼロに設定され、hpollはシステム変数tcにリセットされ、操作は通常どおり再開されます。
A packet is sent by the transmit process. Some header values are copied from the peer variables left by a previous packet and others from the system variables. Figure 30 shows which values are copied to each header field. In those implementations, using floating double data types for root delay and root dispersion, these must be converted to NTP short format. All other fields are either copied intact from peer and system variables or struck as a timestamp from the system clock.
送信プロセスによってパケットが送信されます。一部のヘッダー値は、前のパケットが残したピア変数からコピーされ、その他の値はシステム変数からコピーされます。図30は、各ヘッダーフィールドにコピーされる値を示しています。これらの実装では、ルート遅延とルート分散に浮動ダブルデータタイプを使用して、これらをNTPショートフォーマットに変換する必要があります。他のすべてのフィールドは、ピアおよびシステム変数からそのままコピーされるか、システムクロックからタイムスタンプとして取得されます。
+-----------------------------------+
| Packet Variable <-- Variable |
+-----------------------------------+
| x.leap <-- s.leap |
| x.version <-- s.version |
| x.mode <-- s.mode |
| x.stratum <-- s.stratum |
| x.poll <-- s.poll |
| x.precision <-- s.precision |
| x.rootdelay <-- s.rootdelay |
| x.rootdisp <-- s.rootdisp |
| x.refid <-- s.refid |
| x.reftime <-- s.reftime |
| x.org <-- p.xmt |
| x.rec <-- p.dst |
| x.xmt <-- clock |
| x.keyid <-- p.keyid |
| x.digest <-- md5 digest |
+-----------------------------------+
Figure 30: xmit_packet Packet Header
図30：xmit_packetパケットヘッダー
The poll update routine is called when a valid packet is received and immediately after a poll message has been sent. If in a burst, the poll interval is fixed at 2 s; otherwise, the host poll exponent hpoll is set to the minimum of ppoll from the last packet received and hpoll from the poll routine, but not less than MINPOLL or greater than MAXPOLL. Thus, the clock discipline can be oversampled but not undersampled. This is necessary to preserve subnet dynamic behavior and protect against protocol errors.
ポーリング更新ルーチンは、有効なパケットが受信されたとき、およびポーリングメッセージが送信された直後に呼び出されます。バーストの場合、ポーリング間隔は2秒に固定されます。それ以外の場合、ホストポーリング指数hpollは、最後に受信したパケットからのppollとポーリングルーチンからのhpollの最小値に設定されますが、MINPOLL以上またはMAXPOLLより大きくはありません。したがって、クロック規律はオーバーサンプリングできますが、アンダーサンプリングできません。これは、サブネットの動的動作を維持し、プロトコルエラーから保護するために必要です。
The poll exponent is converted to an interval, which, when added to the last poll time variable, determines the value of the next poll time variable. Finally, the last poll time variable is set to the current seconds counter.
ポーリング指数は間隔に変換され、最終ポーリング時間変数に追加されると、次のポーリング時間変数の値が決まります。最後に、最終ポーリング時間変数が現在の秒数カウンターに設定されます。
Primary servers and clients complying with a subset of NTP, called the Simple Network Time Protocol (SNTPv4) [RFC4330], do not need to implement the mitigation algorithms described in Section 9 and following sections. SNTP is intended for primary servers equipped with a single reference clock, as well as for clients with a single upstream server and no dependent clients. The fully developed NTPv4 implementation is intended for secondary servers with multiple upstream servers and multiple downstream servers or clients. Other than these considerations, NTP and SNTP servers and clients are completely interoperable and can be intermixed in NTP subnets.
NTPのサブセットに準拠するプライマリサーバーおよびクライアントは、Simple Network Time Protocol（SNTPv4）[RFC4330]と呼ばれ、セクション9以降で説明する軽減アルゴリズムを実装する必要はありません。 SNTPは、単一の基準クロックを備えたプライマリサーバーと、単一の上流サーバーを備え、依存するクライアントを持たないクライアントを対象としています。完全に開発されたNTPv4実装は、複数のアップストリームサーバーと複数のダウンストリームサーバーまたはクライアントを持つセカンダリサーバーを対象としています。これらの考慮事項以外に、NTPおよびSNTPサーバーとクライアントは完全に相互運用可能であり、NTPサブネットで混在させることができます。
An SNTP primary server implementing the on-wire protocol described in Section 8 has no upstream servers except a single reference clock. In principle, it is indistinguishable from an NTP primary server that has the mitigation algorithms and therefore capable of mitigating between multiple reference clocks.
セクション8で説明されているオンワイヤプロトコルを実装するSNTPプライマリサーバーには、単一の基準クロック以外のアップストリームサーバーはありません。原則として、軽減アルゴリズムを備えているため、複数の基準クロック間で軽減できるNTPプライマリサーバーと区別できません。
Upon receiving a client request, an SNTP primary server constructs and sends the reply packet as described in Figure 31. Note that the dispersion field in the packet header must be updated as described in Section 5.
SNTPプライマリサーバーは、クライアント要求を受信すると、図31に示すように応答パケットを作成して送信します。パケットヘッダーの分散フィールドは、セクション5で説明するように更新する必要があります。
+-----------------------------------+
| Packet Variable <-- Variable |
+-----------------------------------+
| x.leap <-- s.leap |
| x.version <-- r.version |
| x.mode <-- 4 |
| x.stratum <-- s.stratum |
| x.poll <-- r.poll |
| x.precision <-- s.precision |
| x.rootdelay <-- s.rootdelay |
| x.rootdisp <-- s.rootdisp |
| x.refid <-- s.refid |
| x.reftime <-- s.reftime |
| x.org <-- r.xmt |
| x.rec <-- r.dst |
| x.xmt <-- clock |
| x.keyid <-- r.keyid |
| x.digest <-- md5 digest |
+-----------------------------------+
Figure 31: fast_xmit Packet Header
図31：fast_xmitパケットヘッダー
An SNTP client implementing the on-wire protocol has a single server and no dependent clients. It can operate with any subset of the NTP on-wire protocol, the simplest approach using only the transmit timestamp of the server packet and ignoring all other fields. However, the additional complexity to implement the full on-wire protocol is minimal so that a full implementation is encouraged.
オンワイヤプロトコルを実装するSNTPクライアントには、単一のサーバーがあり、依存するクライアントはありません。 NTPオンワイヤプロトコルのサブセットで動作します。サーバーパケットの送信タイムスタンプのみを使用し、他のすべてのフィールドを無視する最も簡単な方法です。ただし、完全なオンワイヤプロトコルを実装するための追加の複雑さは最小限であるため、完全な実装が推奨されます。
NTP security requirements are even more stringent than most other distributed services. First, the operation of the authentication mechanism and the time synchronization mechanism are inextricably intertwined. Reliable time synchronization requires cryptographic keys that are valid only over a designated time interval; but, time intervals can be enforced only when participating servers and clients are reliably synchronized to UTC. In addition, the NTP subnet is hierarchical by nature, so time and trust flow from the primary servers at the root through secondary servers to the clients at the leaves.
NTPのセキュリティ要件は、他のほとんどの分散サービスよりもさらに厳格です。まず、認証メカニズムと時刻同期メカニズムの動作が密接に絡み合っています。信頼できる時間同期には、指定された時間間隔でのみ有効な暗号化キーが必要です。ただし、参加しているサーバーとクライアントが確実にUTCに同期している場合にのみ、時間間隔を適用できます。さらに、NTPサブネットは本質的に階層的であるため、時間と信頼はルートのプライマリサーバーからセカンダリサーバーを経由してリーフのクライアントに流れます。
An NTP client can claim to have authentic time to dependent applications only if all servers on the path to the primary servers are authenticated. In NTP each server authenticates the next lower stratum servers and authenticates by induction the lowest stratum (primary) servers. It is important to note that authentication in the context of NTP does not necessarily imply the time is correct. An NTP client mobilizes a number of concurrent associations with different servers and uses a crafted agreement algorithm to pluck truechimers from the population possibly including falsetickers.
NTPクライアントは、プライマリサーバーへのパス上のすべてのサーバーが認証されている場合にのみ、依存するアプリケーションに対して認証された時間があると主張できます。 NTPでは、各サーバーは次に低い層のサーバーを認証し、誘導によって最も下の層（プライマリ）サーバーを認証します。 NTPのコンテキストでの認証は、必ずしも時刻が正しいことを意味するわけではないことに注意することが重要です。 NTPクライアントは、さまざまなサーバーとの多数の同時アソシエーションを動員し、巧妙な合意アルゴリズムを使用して、偽ティッカーを含む可能性のある集団から真のキメラを引き抜きます。
The NTP specification assumes that the goal of the intruder is to inject false time values, disrupt the protocol, or clog the network, servers, or clients with spurious packets that exhaust resources and deny service to legitimate applications. There are a number of defense mechanisms already built in the NTP architecture, protocol, and algorithms. The on-wire timestamp exchange scheme is inherently resistant to spoofing, packet-loss, and replay attacks. The engineered clock filter, selection and clustering algorithms are designed to defend against evil cliques of Byzantine traitors. While not necessarily designed to defeat determined intruders, these algorithms and accompanying sanity checks have functioned well over the years to deflect improperly operating but presumably friendly scenarios. However, these mechanisms do not securely identify and authenticate servers to clients. Without specific further protection, an intruder can inject any or all of the following attacks:
NTP仕様では、侵入者の目標は、誤った時間値を注入し、プロトコルを混乱させ、ネットワーク、サーバー、またはクライアントに、リソースを使い果たして正規のアプリケーションへのサービスを拒否する偽のパケットで詰まることを想定しています。 NTPアーキテクチャ、プロトコル、およびアルゴリズムには、すでに多数の防御メカニズムが組み込まれています。オンタイムタイムスタンプ交換スキームは、スプーフィング、パケット損失、およびリプレイ攻撃に対して本質的に耐性があります。設計されたクロックフィルター、選択、およびクラスタリングアルゴリズムは、ビザンチンの裏切り者の邪悪な派閥から身を守るように設計されています。これらのアルゴリズムと付随する健全性チェックは、必ずしも決定的な侵入者を倒すように設計されているわけではありませんが、不適切に動作しているがおそらく友好的なシナリオを回避するために長年にわたってうまく機能しています。ただし、これらのメカニズムはサーバーをクライアントに対して安全に識別および認証しません。特別な保護がなければ、侵入者は次の攻撃の一部またはすべてを注入できます。
1. An intruder can intercept and archive packets forever, as well as all the public values ever generated and transmitted over the net.
1. 侵入者は、パケットを永久に傍受してアーカイブできるだけでなく、ネット上で生成および送信されたすべての公開値を傍受できます。
2. An intruder can generate packets faster than the server, network or client can process them, especially if they require expensive cryptographic computations.
2. 特に高価な暗号計算が必要な場合、侵入者はサーバー、ネットワーク、またはクライアントがパケットを処理するよりも速くパケットを生成できます。
3. In a wiretap attack, the intruder can intercept, modify, and replay a packet. However, it cannot permanently prevent onward transmission of the original packet; that is, it cannot break the wire, only tell lies and congest it. Generally, the modified packet cannot arrive at the victim before the original packet, nor does it have the server private keys or identity parameters.
3. 盗聴攻撃では、侵入者はパケットを傍受、変更、および再生できます。ただし、元のパケットの以降の送信を永久に防ぐことはできません。つまり、ワイヤを壊すことはできません。嘘をつき、それを混雑させるだけです。一般に、変更されたパケットは、元のパケットの前に被害者に到着することはできません。また、サーバーの秘密鍵やIDパラメータも持っていません。
4. In a middleman or masquerade attack, the intruder is positioned between the server and client, so it can intercept, modify and replay a packet and prevent onward transmission of the original packet. However, the middleman does not have the server private keys.
4. 仲介者またはマスカレード攻撃では、侵入者はサーバーとクライアントの間に配置されるため、パケットを傍受、変更、再生し、元のパケットの転送を防ぐことができます。ただし、仲介者にはサーバーの秘密鍵がありません。
The NTP security model assumes the following possible limitations:
NTPセキュリティモデルでは、次の制限が想定されています。
1. The running times for public key algorithms are relatively long and highly variable. In general, the performance of the time synchronization function is badly degraded if these algorithms must be used for every NTP packet.
1. 公開鍵アルゴリズムの実行時間は比較的長く、非常に変動します。一般に、これらのアルゴリズムをすべてのNTPパケットに使用する必要がある場合、時刻同期機能のパフォーマンスは大幅に低下します。
2. In some modes of operation, it is not feasible for a server to retain state variables for every client. It is however feasible to regenerated them for a client upon arrival of a packet from that client.
2. 一部の操作モードでは、サーバーがすべてのクライアントの状態変数を保持することはできません。ただし、クライアントからパケットが到着したときに、クライアント用に再生成することは可能です。
3. The lifetime of cryptographic values must be enforced, which requires a reliable system clock. However, the sources that synchronize the system clock must be trusted. This circular interdependence of the timekeeping and authentication functions requires special handling.
3. 暗号値の有効期間を適用する必要があります。これには、信頼性の高いシステムクロックが必要です。ただし、システムクロックを同期するソースは信頼されている必要があります。この計時機能と認証機能の循環的な相互依存には、特別な処理が必要です。
4. Client security functions must involve only public values transmitted over the net. Private values must never be disclosed beyond the machine on which they were created, except in the case of a special trusted agent (TA) assigned for this purpose.
4. クライアントのセキュリティ機能には、ネット経由で送信されるパブリックな値のみを含める必要があります。この目的のために割り当てられた特別な信頼できるエージェント（TA）の場合を除いて、プライベート値は、それらが作成されたマシンを超えて公開されてはなりません。
Unlike the Secure Shell (SSH) security model, where the client must be securely authenticated to the server, in NTP the server must be securely authenticated to the client. In SSH, each different interface address can be bound to a different name, as returned by a reverse-DNS query. In this design, separate public/private key pairs may be required for each interface address with a distinct name. A perceived advantage of this design is that the security compartment can be different for each interface. This allows a firewall, for instance, to require some interfaces to authenticate the client and others not.
Secure Shell（SSH）セキュリティモデルとは異なり、クライアントはサーバーに対して安全に認証される必要がありますが、NTPではサーバーはクライアントに対して安全に認証される必要があります。 SSHでは、リバースDNSクエリによって返されるように、それぞれの異なるインターフェイスアドレスを異なる名前にバインドできます。この設計では、異なる名前の各インターフェイスアドレスに個別の公開/秘密キーペアが必要になる場合があります。この設計の認識されている利点は、セキュリティコンパートメントがインターフェイスごとに異なる可能性があることです。これにより、たとえば、ファイアウォールがクライアントを認証するために一部のインターフェースを要求し、他のインターフェースを要求しないようにすることができます。
In the case of NTP as specified herein, NTP broadcast clients are vulnerable to disruption by misbehaving or hostile SNTP or NTP broadcast servers elsewhere in the Internet. Such disruption can be minimized by several approaches. Filtering can be employed to limit the access of NTP clients to known or trusted NTP broadcast servers. Such filtering will prevent malicious traffic from reaching the NTP clients. Cryptographic authentication at the client will only allow timing information from properly signed NTP messages to be utilized in synchronizing its clock. Higher levels of authentication may be gained by the use of the Autokey mechanism [RFC5906].
ここで指定されているNTPの場合、NTPブロードキャストクライアントは、インターネット内の別の場所にあるSNTPまたはNTPブロードキャストサーバーの誤動作または悪意による混乱に対して脆弱です。このような混乱は、いくつかの方法で最小限に抑えることができます。フィルタリングを使用して、既知または信頼されたNTPブロードキャストサーバーへのNTPクライアントのアクセスを制限できます。このようなフィルタリングは、悪意のあるトラフィックがNTPクライアントに到達するのを防ぎます。クライアントでの暗号化認証では、適切に署名されたNTPメッセージからのタイミング情報のみを使用して、そのクロックを同期できます。 Autokeyメカニズム[RFC5906]を使用すると、より高いレベルの認証を取得できます。
Section 8 describes a potential security concern with the replay of client requests. Following the recommendations in that section provides protection against such attacks.
セクション8では、クライアント要求の再生に関する潜在的なセキュリティの問題について説明します。そのセクションの推奨事項に従うと、このような攻撃に対する保護が提供されます。
It should be noted that this specification is describing an existing implementation. While the security shortfalls of the MD5 algorithm are well-known, its use in the NTP specification is consistent with widescale deployment in the Internet community.
この仕様は既存の実装を説明していることに注意してください。 MD5アルゴリズムのセキュリティ不足はよく知られていますが、NTP仕様でのその使用は、インターネットコミュニティでの大規模な展開と一致しています。
UDP/TCP Port 123 was previously assigned by IANA for this protocol. The IANA has assigned the IPv4 multicast group address 224.0.1.1 and the IPv6 multicast address ending :101 for NTP. This document introduces NTP extension fields allowing for the development of future extensions to the protocol, where a particular extension is to be identified by the Field Type sub-field within the extension field. IANA has established and will maintain a registry for Extension Field Types associated with this protocol, populating this registry with no initial entries. As future needs arise, new Extension Field Types may be defined. Following the policies outlined in [RFC5226], new values are to be defined by IETF Review.
UDP / TCPポート123は、以前このプロトコル用にIANAによって割り当てられていました。 IANAは、IPv4マルチキャストグループアドレス224.0.1.1およびNTPの末尾が：101のIPv6マルチキャストアドレスを割り当てました。このドキュメントでは、プロトコルの将来の拡張の開発を可能にするNTP拡張フィールドを紹介します。特定の拡張は、拡張フィールド内のフィールドタイプサブフィールドによって識別されます。 IANAは、このプロトコルに関連付けられた拡張フィールドタイプのレジストリを確立し、維持します。このレジストリには、初期エントリがありません。将来のニーズが発生すると、新しい拡張フィールドタイプが定義される可能性があります。 [RFC5226]で概説されているポリシーに従って、新しい値はIETFレビューによって定義されます。
The IANA has created a new registry for NTP Reference Identifier codes. This includes the current codes defined in Section 7.3, and may be extended on a First-Come-First-Serve (FCFS) basis. The format of the registry is:
IANAは、NTP参照IDコード用の新しいレジストリを作成しました。これには、セクション7.3で定義されている現在のコードが含まれており、先着順（FCFS）ベースで拡張できます。レジストリの形式は次のとおりです。
+------+----------------------------------------------------------+
| ID | Clock Source |
+------+----------------------------------------------------------+
| GOES | Geosynchronous Orbit Environment Satellite |
| GPS | Global Position System |
| ... | ... |
+------+----------------------------------------------------------+
Figure 32: Reference Identifier Codes
図32：参照識別子コード
The IANA has created a new registry for NTP Kiss-o'-Death codes. This includes the current codes defined in Section 7.4, and may be extended on a FCFS basis. The format of the registry is:
IANAは、NTP Kiss-o'-Deathコード用の新しいレジストリを作成しました。これには、セクション7.4で定義された現在のコードが含まれ、FCFSベースで拡張できます。レジストリの形式は次のとおりです。
+------+------------------------------------------------------------+
| Code | Meaning |
+------+------------------------------------------------------------+
| ACST | The association belongs to a unicast server. |
| AUTH | Server authentication failed. |
| ... | ... |
+------+------------------------------------------------------------+
Figure 33: Kiss Codes
図33：キスコード
For both Reference Identifiers and Kiss-o'-Death codes, IANA is requested to never assign a code beginning with the character "X", as this is reserved for experimentation and development.
参照識別子とKiss-o'-Deathコードの両方について、実験と開発のために予約されているため、IANAは文字「X」で始まるコードを割り当てないでください。
The editors would like to thank Karen O'Donoghue, Brian Haberman, Greg Dowd, Mark Elliot, Harlan Stenn, Yaakov Stein, Stewart Bryant, and Danny Mayer for technical reviews and specific text contributions to this document.
編集者は、このドキュメントに対する技術的なレビューと具体的なテキストの寄稿に対して、Karen O'Donoghue、Brian Haberman、Greg Dowd、Mark Elliot、Harlan Stenn、Yaakov Stein、Stewart Bryant、およびDanny Mayerに感謝します。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768] Postel、J。、「User Datagram Protocol」、STD 6、RFC 768、1980年8月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、1981年9月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321] Rivest、R。、「MD5メッセージダイジェストアルゴリズム」、RFC 1321、1992年4月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[CGPM] Bureau International des Poids et Mesures, "Comptes Rendus de la 15e CGPM", 1976.
[CGPM]国際ウェイトとメジャーの局、「Computes Rendus de la 15e CGPM」、1976年。
[ITU-R_TF.460] International Telecommunications Union, "ITU-R TF.460 Standard-frequency and time-signal emissions", February 2002.
[ITU-R_TF.460]国際電気通信連合、「ITU-R TF.460標準周波数および時間信号エミッション」、2002年2月。
[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[RFC1305] Mills、D。、「Network Time Protocol（Version 3）Specification、Implementation and Analysis」、RFC 1305、1992年3月。
[RFC1345] Simonsen, K., "Character Mnemonics and Character Sets", RFC 1345, June 1992.
[RFC1345] Simonsen、K。、「Character Nnemonics and Character Sets」、RFC 1345、1992年6月。
[RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 4330, January 2006.
[RFC4330] Mills、D。、「Simple Network Time Protocol（SNTP）Version 4 for IPv4、IPv6 and OSI」、RFC 4330、2006年1月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5906] Haberman, B., Ed. and D. Mills, "Network Time Protocol Version 4: Autokey Specification", RFC 5906, June 2010.
[RFC5906]ハーバーマン、B。、エド。 D.ミルズ、「Network Time Protocol Version 4：Autokey Specification」、RFC 5906、2010年6月。
[ref6] Marzullo and S. Owicki, "Maintaining the time in a distributed system", ACM Operating Systems Review 19, July 1985.
[ref6] MarzulloとS. Owicki、「分散システムでの時間の維持」、ACMオペレーティングシステムレビュー19、1985年7月。
[ref7] Mills, D.L., "Computer Network Time Synchronization - the Network Time Protocol", CRC Press, 304 pp, 2006.
[ref7] Mills、D.L。、「Computer Network Time Synchronization-the Network Time Protocol」、CRC Press、304 pp、2006。
[ref9] Mills, D.L., Electrical and Computer Engineering Technical Report 06-6-1, NDSS, June 2006, "Network Time Protocol Version 4 Reference and Implementation Guide", 2006.
[ref9] Mills、D.L。、電気およびコンピュータエンジニアリングテクニカルレポート06-6-1、NDSS、2006年6月、「Network Time Protocol Version 4 Reference and Implementation Guide」、2006。
This appendix is intended to describe the protocol and algorithms of an implementation in a general way using what is called a code skeleton program. This consists of a set of definitions, structures, and code fragments that illustrate the protocol operations without the complexities of an actual implementation of the protocol. This program is not an executable and is not designed to run in the ordinary sense.
この付録は、コードスケルトンプログラムと呼ばれるものを使用して、実装のプロトコルとアルゴリズムを一般的な方法で説明することを目的としています。これは、プロトコルの実際の実装の複雑さを伴わずにプロトコル操作を示す一連の定義、構造、およびコードフラグメントで構成されます。このプログラムは実行可能ではなく、通常の意味で実行するように設計されていません。
Most of the features of the reference implementation are included here, with the following exceptions: there are no provisions for reference clocks or public key (Autokey) cryptography. There is no huff-n'-puff filter, anti-clockhop hysteresis, or monitoring provisions. Many of the values that can be tinkered in the reference implementation are assumed constants here. There are only minimal provisions for the kiss-o'-death packet and no responding code.
リファレンス実装のほとんどの機能がここに含まれていますが、次の例外があります。リファレンスクロックまたは公開キー（Autokey）暗号化のプロビジョニングはありません。 huff-n'-puffフィルター、反クロックホップヒステリシス、または監視機能はありません。リファレンス実装で調整できる値の多くは、ここでは定数と見なされます。 kiss-o'-deathパケットには最小限の規定しかなく、応答コードはありません。
The program is not intended to be fast or compact, just to demonstrate the algorithms with sufficient fidelity to understand how they work. The code skeleton consists of eight segments, a header segment included by each of the other segments, plus a code segment for the main program, kernel I/O and system clock interfaces, and peer, system, clock_adjust, and poll processes. These are presented in order below along with definitions and variables specific to each process.
プログラムは、高速またはコンパクトであることを意図しておらず、アルゴリズムがどのように機能するかを理解するために十分な忠実度でアルゴリズムを実証することのみを目的としています。コードスケルトンは、8つのセグメント、他の各セグメントに含まれるヘッダーセグメント、およびメインプログラム、カーネルI / Oとシステムクロックインターフェイス、およびピア、システム、clock_adjust、およびポーリングプロセスのコードセグメントで構成されます。これらは、各プロセスに固有の定義と変数とともに以下の順序で示されます。
#include <math.h> /* avoids complaints about sqrt() */
#include <sys/time.h> /* for gettimeofday() and friends */
#include <stdlib.h> /* for malloc() and friends */
#include <string.h> /* for memset() */
/*
* Data types
*
* This program assumes the int data type is 32 bits and the long data
* type is 64 bits. The native data type used in most calculations is
* floating double. The data types used in some packet header fields
* require conversion to and from this representation. Some header
* fields involve partitioning an octet, here represented by individual
* octets.
*
* The 64-bit NTP timestamp format used in timestamp calculations is
* unsigned seconds and fraction with the decimal point to the left of
* bit 32. The only operation permitted with these values is
* subtraction, yielding a signed 31-bit difference. The 32-bit NTP
* short format used in delay and dispersion calculations is seconds and
* fraction with the decimal point to the left of bit 16. The only
* operations permitted with these values are addition and
* multiplication by a constant.
*
* The IPv4 address is 32 bits, while the IPv6 address is 128 bits. The
* message digest field is 128 bits as constructed by the MD5 algorithm.
* The precision and poll interval fields are signed log2 seconds.
*/
typedef unsigned long long tstamp; /* NTP timestamp format */
typedef unsigned int tdist; /* NTP short format */
typedef unsigned long ipaddr; /* IPv4 or IPv6 address */
typedef unsigned long digest; /* md5 digest */
typedef signed char s_char; /* precision and poll interval (log2) */
/*
* Timestamp conversion macroni
*/
#define FRIC 65536. /* 2^16 as a double */
#define D2FP(r) ((tdist)((r) * FRIC)) /* NTP short */
#define FP2D(r) ((double)(r) / FRIC)
#define FRAC 4294967296. /* 2^32 as a double */
#define D2LFP(a) ((tstamp)((a) * FRAC)) /* NTP timestamp */
#define LFP2D(a) ((double)(a) / FRAC)
#define U2LFP(a) (((unsigned long long) \
((a).tv_sec + JAN_1970) << 32) + \
(unsigned long long) \
((a).tv_usec / 1e6 * FRAC))
/*
* Arithmetic conversions
*/
#define LOG2D(a) ((a) < 0 ? 1. / (1L << -(a)) : \
1L << (a)) /* poll, etc. */
#define SQUARE(x) (x * x)
#define SQRT(x) (sqrt(x))
/*
* Global constants. Some of these might be converted to variables
* that can be tinkered by configuration or computed on-the-fly. For
* instance, the reference implementation computes PRECISION on-the-fly
* and provides performance tuning for the defines marked with % below.
*/
#define VERSION 4 /* version number */
#define MINDISP .01 /* % minimum dispersion (s) */
#define MAXDISP 16 /* maximum dispersion (s) */
#define MAXDIST 1 /* % distance threshold (s) */
#define NOSYNC 0x3 /* leap unsync */
#define MAXSTRAT 16 /* maximum stratum (infinity metric) */
#define MINPOLL 6 /* % minimum poll interval (64 s)*/
#define MAXPOLL 17 /* % maximum poll interval (36.4 h) */
#define MINCLOCK 3 /* minimum manycast survivors */
#define MAXCLOCK 10 /* maximum manycast candidates */
#define TTLMAX 8 /* max ttl manycast */
#define BEACON 15 /* max interval between beacons */
#define PHI 15e-6 /* % frequency tolerance (15 ppm) */
#define NSTAGE 8 /* clock register stages */
#define NMAX 50 /* maximum number of peers */
#define NSANE 1 /* % minimum intersection survivors */
#define NMIN 3 /* % minimum cluster survivors */
/*
* Global return values
*/
#define TRUE 1 /* boolean true */
#define FALSE 0 /* boolean false */
/*
* Local clock process return codes
*/
#define IGNORE 0 /* ignore */
#define SLEW 1 /* slew adjustment */
#define STEP 2 /* step adjustment */
#define PANIC 3 /* panic - no adjustment */
/*
* System flags
*/
#define S_FLAGS 0 /* any system flags */
#define S_BCSTENAB 0x1 /* enable broadcast client */
/*
* Peer flags
*/
#define P_FLAGS 0 /* any peer flags */
#define P_EPHEM 0x01 /* association is ephemeral */
#define P_BURST 0x02 /* burst enable */
#define P_IBURST 0x04 /* intial burst enable */
#define P_NOTRUST 0x08 /* authenticated access */
#define P_NOPEER 0x10 /* authenticated mobilization */
#define P_MANY 0x20 /* manycast client */
/*
* Authentication codes
*/
#define A_NONE 0 /* no authentication */
#define A_OK 1 /* authentication OK */
#define A_ERROR 2 /* authentication error */
#define A_CRYPTO 3 /* crypto-NAK */
/*
* Association state codes
*/
#define X_INIT 0 /* initialization */
#define X_STALE 1 /* timeout */
#define X_STEP 2 /* time step */
#define X_ERROR 3 /* authentication error */
#define X_CRYPTO 4 /* crypto-NAK received */
#define X_NKEY 5 /* untrusted key */
/*
* Protocol mode definitions
*/
#define M_RSVD 0 /* reserved */
#define M_SACT 1 /* symmetric active */
#define M_PASV 2 /* symmetric passive */
#define M_CLNT 3 /* client */
#define M_SERV 4 /* server */
#define M_BCST 5 /* broadcast server */
#define M_BCLN 6 /* broadcast client */
/*
* Clock state definitions
*/
#define NSET 0 /* clock never set */
#define FSET 1 /* frequency set from file */
#define SPIK 2 /* spike detected */
#define FREQ 3 /* frequency mode */
#define SYNC 4 /* clock synchronized */
#define min(a, b) ((a) < (b) ? (a) : (b))
#define max(a, b) ((a) < (b) ? (b) : (a))
/*
* The receive and transmit packets may contain an optional message
* authentication code (MAC) consisting of a key identifier (keyid) and
* message digest (mac in the receive structure and dgst in the transmit
* structure). NTPv4 supports optional extension fields that
* are inserted after the header and before the MAC, but these are
* not described here.
*
* Receive packet
*
* Note the dst timestamp is not part of the packet itself. It is
* captured upon arrival and returned in the receive buffer along with
* the buffer length and data. Note that some of the char fields are
* packed in the actual header, but the details are omitted here.
*/
struct r {
ipaddr srcaddr; /* source (remote) address */
ipaddr dstaddr; /* destination (local) address */
char version; /* version number */
char leap; /* leap indicator */
char mode; /* mode */
char stratum; /* stratum */
char poll; /* poll interval */
s_char precision; /* precision */
tdist rootdelay; /* root delay */
tdist rootdisp; /* root dispersion */
char refid; /* reference ID */
tstamp reftime; /* reference time */
tstamp org; /* origin timestamp */
tstamp rec; /* receive timestamp */
tstamp xmt; /* transmit timestamp */
int keyid; /* key ID */
digest mac; /* message digest */
tstamp dst; /* destination timestamp */
} r;
/*
* Transmit packet
*/
struct x {
ipaddr dstaddr; /* source (local) address */
ipaddr srcaddr; /* destination (remote) address */
char version; /* version number */
char leap; /* leap indicator */
char mode; /* mode */
char stratum; /* stratum */
char poll; /* poll interval */
s_char precision; /* precision */
tdist rootdelay; /* root delay */
tdist rootdisp; /* root dispersion */
char refid; /* reference ID */
tstamp reftime; /* reference time */
tstamp org; /* origin timestamp */
tstamp rec; /* receive timestamp */
tstamp xmt; /* transmit timestamp */
int keyid; /* key ID */
digest dgst; /* message digest */
} x;
/*
* Filter stage structure. Note the t member in this and other
* structures refers to process time, not real time. Process time
* increments by one second for every elapsed second of real time.
*/
struct f {
tstamp t; /* update time */
double offset; /* clock ofset */
double delay; /* roundtrip delay */
double disp; /* dispersion */
} f;
/*
* Association structure. This is shared between the peer process
* and poll process.
*/
struct p {
/*
* Variables set by configuration
*/
ipaddr srcaddr; /* source (remote) address */
ipaddr dstaddr; /* destination (local) address */
char version; /* version number */
char hmode; /* host mode */
int keyid; /* key identifier */
int flags; /* option flags */
/*
* Variables set by received packet
*/
char leap; /* leap indicator */
char pmode; /* peer mode */
char stratum; /* stratum */
char ppoll; /* peer poll interval */
double rootdelay; /* root delay */
double rootdisp; /* root dispersion */
char refid; /* reference ID */
tstamp reftime; /* reference time */
#define begin_clear org /* beginning of clear area */
tstamp org; /* originate timestamp */
tstamp rec; /* receive timestamp */
tstamp xmt; /* transmit timestamp */
/*
* Computed data
*/
double t; /* update time */
struct f f[NSTAGE]; /* clock filter */
double offset; /* peer offset */
double delay; /* peer delay */
double disp; /* peer dispersion */
double jitter; /* RMS jitter */
/*
* Poll process variables
*/
char hpoll; /* host poll interval */
int burst; /* burst counter */
int reach; /* reach register */
int ttl; /* ttl (manycast) */
#define end_clear unreach /* end of clear area */
int unreach; /* unreach counter */
int outdate; /* last poll time */
int nextdate; /* next poll time */
} p;
/*
* Chime list. This is used by the intersection algorithm.
*/
struct m { /* m is for Marzullo */
struct p *p; /* peer structure pointer */
int type; /* high +1, mid 0, low -1 */
double edge; /* correctness interval edge */
} m;
/*
* Survivor list. This is used by the clustering algorithm.
*/
struct v {
struct p *p; /* peer structure pointer */
double metric; /* sort metric */
} v;
/*
* System structure
*/
struct s {
tstamp t; /* update time */
char leap; /* leap indicator */
char stratum; /* stratum */
char poll; /* poll interval */
char precision; /* precision */
double rootdelay; /* root delay */
double rootdisp; /* root dispersion */
char refid; /* reference ID */
tstamp reftime; /* reference time */
struct m m[NMAX]; /* chime list */
struct v v[NMAX]; /* survivor list */
struct p *p; /* association ID */
double offset; /* combined offset */
double jitter; /* combined jitter */
int flags; /* option flags */
int n; /* number of survivors */
} s;
/*
* Local clock structure
*/
struct c {
tstamp t; /* update time */
int state; /* current state */
double offset; /* current offset */
double last; /* previous offset */
int count; /* jiggle counter */
double freq; /* frequency */
double jitter; /* RMS jitter */
double wander; /* RMS wander */
} c;
/*
* Peer process
*/
void receive(struct r *); /* receive packet */
void packet(struct p *, struct r *); /* process packet */
void clock_filter(struct p *, double, double, double); /* filter */
double root_dist(struct p *); /* calculate root distance */
int fit(struct p *); /* determine fitness of server */
void clear(struct p *, int); /* clear association */
int access(struct r *); /* determine access restrictions */
/*
* System process
*/
int main(); /* main program */
void clock_select(); /* find the best clocks */
void clock_update(struct p *); /* update the system clock */
void clock_combine(); /* combine the offsets */
/*
* Local clock process
*/
int local_clock(struct p *, double); /* clock discipline */
void rstclock(int, double, double); /* clock state transition */
/*
* Clock adjust process
*/
void clock_adjust(); /* one-second timer process */
/*
* Poll process
*/
void poll(struct p *); /* poll process */
void poll_update(struct p *, int); /* update the poll interval */
void peer_xmit(struct p *); /* transmit a packet */
void fast_xmit(struct r *, int, int); /* transmit a reply packet */
/*
* Utility routines
*/
digest md5(int); /* generate a message digest */
struct p *mobilize(ipaddr, ipaddr, int, int, int, int); /* mobilize */
struct p *find_assoc(struct r *); /* search the association table */
/*
* Kernel interface
*/
struct r *recv_packet(); /* wait for packet */
void xmit_packet(struct x *); /* send packet */
void step_time(double); /* step time */
void adjust_time(double); /* adjust (slew) time */
tstamp get_time(); /* read time */
/*
* Definitions
*/
#define PRECISION -18 /* precision (log2 s) */
#define IPADDR 0 /* any IP address */
#define MODE 0 /* any NTP mode */
#define KEYID 0 /* any key identifier */
/*
* main() - main program
*/
int
main()
{
struct p *p; /* peer structure pointer */
struct r *r; /* receive packet pointer */
/*
* Read command line options and initialize system variables.
* The reference implementation measures the precision specific
* to each machine by measuring the clock increments to read the
* system clock.
*/
memset(&s, sizeof(s), 0);
s.leap = NOSYNC;
s.stratum = MAXSTRAT;
s.poll = MINPOLL;
s.precision = PRECISION;
s.p = NULL;
/*
* Initialize local clock variables
*/
memset(&c, sizeof(c), 0);
if (/* frequency file */ 0) {
c.freq = /* freq */ 0;
rstclock(FSET, 0, 0);
} else {
rstclock(NSET, 0, 0);
}
c.jitter = LOG2D(s.precision);
/*
* Read the configuration file and mobilize persistent
* associations with specified addresses, version, mode, key ID,
* and flags.
*/
while (/* mobilize configurated associations */ 0) {
p = mobilize(IPADDR, IPADDR, VERSION, MODE, KEYID,
P_FLAGS);
}
/*
* Start the system timer, which ticks once per second. Then,
* read packets as they arrive, strike receive timestamp, and
* call the receive() routine.
*/
while (0) {
r = recv_packet();
r->dst = get_time();
receive(r);
}
return(0);
}
/*
* mobilize() - mobilize and initialize an association
*/
struct p
*mobilize(
ipaddr srcaddr, /* IP source address */
ipaddr dstaddr, /* IP destination address */
int version, /* version */
int mode, /* host mode */
int keyid, /* key identifier */
int flags /* peer flags */
)
{
struct p *p; /* peer process pointer */
/*
* Allocate and initialize association memory
*/
p = malloc(sizeof(struct p));
p->srcaddr = srcaddr;
p->dstaddr = dstaddr;
p->version = version;
p->hmode = mode;
p->keyid = keyid;
p->hpoll = MINPOLL;
clear(p, X_INIT);
p->flags = flags;
return (p);
}
/*
* find_assoc() - find a matching association
*/
struct p /* peer structure pointer or NULL */
*find_assoc(
struct r *r /* receive packet pointer */
)
{
struct p *p; /* dummy peer structure pointer */
/*
* Search association table for matching source
* address, source port and mode.
*/
while (/* all associations */ 0) {
if (r->srcaddr == p->srcaddr && r->mode == p->hmode)
return(p);
}
return (NULL);
}
/*
* md5() - compute message digest
*/
digest
md5(
int keyid /* key identifier */
)
{
/*
* Compute a keyed cryptographic message digest. The key
* identifier is associated with a key in the local key cache.
* The key is prepended to the packet header and extension fields
* and the result hashed by the MD5 algorithm as described in
* RFC 1321. Return a MAC consisting of the 32-bit key ID
* concatenated with the 128-bit digest.
*/
return (/* MD5 digest */ 0);
}
/*
* Kernel interface to transmit and receive packets. Details are
* deliberately vague and depend on the operating system.
*
* recv_packet - receive packet from network
*/
struct r /* receive packet pointer*/
*recv_packet() {
return (/* receive packet r */ 0);
}
/*
* xmit_packet - transmit packet to network
*/
void
xmit_packet(
struct x *x /* transmit packet pointer */
)
{
/* send packet x */
}
/*
* System clock utility functions
*
* There are three time formats: native (Unix), NTP, and floating
* double. The get_time() routine returns the time in NTP long format.
* The Unix routines expect arguments as a structure of two signed
* 32-bit words in seconds and microseconds (timeval) or nanoseconds
* (timespec). The step_time() and adjust_time() routines expect signed
* arguments in floating double. The simplified code shown here is for
* illustration only and has not been verified.
*/
#define JAN_1970 2208988800UL /* 1970 - 1900 in seconds */
/*
* get_time - read system time and convert to NTP format
*/
tstamp
get_time()
{
struct timeval unix_time;
/*
* There are only two calls on this routine in the program. One
* when a packet arrives from the network and the other when a
* packet is placed on the send queue. Call the kernel time of
* day routine (such as gettimeofday()) and convert to NTP
* format.
*/
gettimeofday(&unix_time, NULL);
return (U2LFP(unix_time));
}
/*
* step_time() - step system time to given offset value
*/
void
step_time(
double offset /* clock offset */
)
{
struct timeval unix_time;
tstamp ntp_time;
/*
* Convert from double to native format (signed) and add to the
* current time. Note the addition is done in native format to
* avoid overflow or loss of precision.
*/
gettimeofday(&unix_time, NULL);
ntp_time = D2LFP(offset) + U2LFP(unix_time);
unix_time.tv_sec = ntp_time >> 32;
unix_time.tv_usec = (long)(((ntp_time - unix_time.tv_sec) <<
32) / FRAC * 1e6);
settimeofday(&unix_time, NULL);
}
/*
* adjust_time() - slew system clock to given offset value
*/
void
adjust_time(
double offset /* clock offset */
)
{
struct timeval unix_time;
tstamp ntp_time;
/*
* Convert from double to native format (signed) and add to the
* current time.
*/
ntp_time = D2LFP(offset);
unix_time.tv_sec = ntp_time >> 32;
unix_time.tv_usec = (long)(((ntp_time - unix_time.tv_sec) <<
32) / FRAC * 1e6);
adjtime(&unix_time, NULL);
}
/*
* A crypto-NAK packet includes the NTP header followed by a MAC
* consisting only of the key identifier with value zero. It tells
* the receiver that a prior request could not be properly
* authenticated, but the NTP header fields are correct.
*
* A kiss-o'-death packet is an NTP header with leap 0x3 (NOSYNC) and
* stratum 16 (MAXSTRAT). It tells the receiver that something
* drastic has happened, as revealed by the kiss code in the refid
* field. The NTP header fields may or may not be correct.
*/
/*
* Peer process parameters and constants
*/
#define SGATE 3 /* spike gate (clock filter */
#define BDELAY .004 /* broadcast delay (s) */
/*
* Dispatch codes
*/
#define ERR -1 /* error */
#define DSCRD 0 /* discard packet */
#define PROC 1 /* process packet */
#define BCST 2 /* broadcast packet */
#define FXMIT 3 /* client packet */
#define MANY 4 /* manycast packet */
#define NEWPS 5 /* new symmetric passive client */
#define NEWBC 6 /* new broadcast client */
/*
* Dispatch matrix
* active passv client server bcast */
int table[7][5] = {
/* nopeer */ { NEWPS, DSCRD, FXMIT, MANY, NEWBC },
/* active */ { PROC, PROC, DSCRD, DSCRD, DSCRD },
/* passv */ { PROC, ERR, DSCRD, DSCRD, DSCRD },
/* client */ { DSCRD, DSCRD, DSCRD, PROC, DSCRD },
/* server */ { DSCRD, DSCRD, DSCRD, DSCRD, DSCRD },
/* bcast */ { DSCRD, DSCRD, DSCRD, DSCRD, DSCRD },
/* bclient */ { DSCRD, DSCRD, DSCRD, DSCRD, PROC}
};
/*
* Miscellaneous macroni
*
* This macro defines the authentication state. If x is 0,
* authentication is optional; otherwise, it is required.
*/
#define AUTH(x, y) ((x) ? (y) == A_OK : (y) == A_OK || \
(y) == A_NONE)
/*
* These are used by the clear() routine
*/
#define BEGIN_CLEAR(p) ((char *)&((p)->begin_clear))
#define END_CLEAR(p) ((char *)&((p)->end_clear))
#define LEN_CLEAR (END_CLEAR((struct p *)0) - \
BEGIN_CLEAR((struct p *)0))
/*
* receive() - receive packet and decode modes
*/
void
receive(
struct r *r /* receive packet pointer */
)
{
struct p *p; /* peer structure pointer */
int auth; /* authentication code */
int has_mac; /* size of MAC */
int synch; /* synchronized switch */
/*
* Check access control lists. The intent here is to implement
* a whitelist of those IP addresses specifically accepted
* and/or a blacklist of those IP addresses specifically
* rejected. There could be different lists for authenticated
* clients and unauthenticated clients.
*/
if (!access(r))
return; /* access denied */
/*
* The version must not be in the future. Format checks include
* packet length, MAC length and extension field lengths, if
* present.
*/
if (r->version > VERSION /* or format error */)
return; /* format error */
/*
* Authentication is conditioned by two switches that can be
* specified on a per-client basis.
*
* P_NOPEER do not mobilize an association unless
* authenticated.
* P_NOTRUST do not allow access unless authenticated
* (implies P_NOPEER).
*
* There are four outcomes:
*
* A_NONE the packet has no MAC.
* A_OK the packet has a MAC and authentication
* succeeds.
* A_ERROR the packet has a MAC and authentication fails.
* A_CRYPTO crypto-NAK. The MAC has four octets only.
*
* Note: The AUTH (x, y) macro is used to filter outcomes. If x
* is zero, acceptable outcomes of y are NONE and OK. If x is
* one, the only acceptable outcome of y is OK.
*/
has_mac = /* length of MAC field */ 0;
if (has_mac == 0) {
auth = A_NONE; /* not required */
} else if (has_mac == 4) {
auth = A_CRYPTO; /* crypto-NAK */
} else {
if (r->mac != md5(r->keyid))
auth = A_ERROR; /* auth error */
else
auth = A_OK; /* auth OK */
}
/*
* Find association and dispatch code. If there is no
* association to match, the value of p->hmode is assumed NULL.
*/
p = find_assoc(r);
switch(table[(unsigned int)(p->hmode)][(unsigned int)(r->mode)])
{
/*
* Client packet and no association. Send server reply without
* saving state.
*/
case FXMIT:
/*
* If unicast destination address, send server packet.
* If authentication fails, send a crypto-NAK packet.
*/
/* not multicast dstaddr */
if (0) {
if (AUTH(p->flags & P_NOTRUST, auth))
fast_xmit(r, M_SERV, auth);
else if (auth == A_ERROR)
fast_xmit(r, M_SERV, A_CRYPTO);
return; /* M_SERV packet sent */
}
/*
* This must be manycast. Do not respond if we are not
* synchronized or if our stratum is above the
* manycaster.
*/
if (s.leap == NOSYNC || s.stratum > r->stratum)
return;
/*
* Respond only if authentication is OK. Note that the
* unicast address is used, not the multicast.
*/
if (AUTH(p->flags & P_NOTRUST, auth))
fast_xmit(r, M_SERV, auth);
return;
/*
* New manycast client ephemeral association. It is mobilized
* in the same version as in the packet. If authentication
* fails, ignore the packet. Verify the server packet by
* comparing the r->org timestamp in the packet with the p->xmt
* timestamp in the multicast client association. If they
* match, the server packet is authentic. Details omitted.
*/
case MANY:
if (!AUTH(p->flags & (P_NOTRUST | P_NOPEER), auth))
return; /* authentication error */
p = mobilize(r->srcaddr, r->dstaddr, r->version, M_CLNT,
r->keyid, P_EPHEM);
break;
/*
* New symmetric passive association. It is mobilized in the
* same version as in the packet. If authentication fails,
* send a crypto-NAK packet. If restrict no-moblize, send a
* symmetric active packet instead.
*/
case NEWPS:
if (!AUTH(p->flags & P_NOTRUST, auth)) {
if (auth == A_ERROR)
fast_xmit(r, M_SACT, A_CRYPTO);
return; /* crypto-NAK packet sent */
}
if (!AUTH(p->flags & P_NOPEER, auth)) {
fast_xmit(r, M_SACT, auth);
return; /* M_SACT packet sent */
}
p = mobilize(r->srcaddr, r->dstaddr, r->version, M_PASV,
r->keyid, P_EPHEM);
break;
/*
* New broadcast client association. It is mobilized in the
* same version as in the packet. If authentication fails,
* ignore the packet. Note this code does not support the
* initial volley feature in the reference implementation.
*/
case NEWBC:
if (!AUTH(p->flags & (P_NOTRUST | P_NOPEER), auth))
return; /* authentication error */
if (!(s.flags & S_BCSTENAB))
return; /* broadcast not enabled */
p = mobilize(r->srcaddr, r->dstaddr, r->version, M_BCLN,
r->keyid, P_EPHEM);
break; /* processing continues */
/*
* Process packet. Placeholdler only.
*/
case PROC:
break; /* processing continues */
/*
* Invalid mode combination. We get here only in case of
* ephemeral associations, so the correct action is simply to
* toss it.
*/
case ERR:
clear(p, X_ERROR);
return; /* invalid mode combination */
/*
* No match; just discard the packet.
*/
case DSCRD:
return; /* orphan abandoned */
}
/*
* Next comes a rigorous schedule of timestamp checking. If the
* transmit timestamp is zero, the server is horribly broken.
*/
if (r->xmt == 0)
return; /* invalid timestamp */
/*
* If the transmit timestamp duplicates a previous one, the
* packet is a replay.
*/
if (r->xmt == p->xmt)
return; /* duplicate packet */
/*
* If this is a broadcast mode packet, skip further checking.
* If the origin timestamp is zero, the sender has not yet heard
* from us. Otherwise, if the origin timestamp does not match
* the transmit timestamp, the packet is bogus.
*/
synch = TRUE;
if (r->mode != M_BCST) {
if (r->org == 0)
synch = FALSE; /* unsynchronized */
else if (r->org != p->xmt)
synch = FALSE; /* bogus packet */
}
/*
* Update the origin and destination timestamps. If
* unsynchronized or bogus, abandon ship.
*/
p->org = r->xmt;
p->rec = r->dst;
if (!synch)
return; /* unsynch */
/*
* The timestamps are valid and the receive packet matches the
* last one sent. If the packet is a crypto-NAK, the server
* might have just changed keys. We demobilize the association
* and wait for better times.
*/
if (auth == A_CRYPTO) {
clear(p, X_CRYPTO);
return; /* crypto-NAK */
}
/*
* If the association is authenticated, the key ID is nonzero
* and received packets must be authenticated. This is designed
* to avoid a bait-and-switch attack, which was possible in past
* versions.
*/
if (!AUTH(p->keyid || (p->flags & P_NOTRUST), auth))
return; /* bad auth */
/*
* Everything possible has been done to validate the timestamps
* and prevent bad guys from disrupting the protocol or
* injecting bogus data. Earn some revenue.
*/
packet(p, r);
}
/*
* packet() - process packet and compute offset, delay, and
* dispersion.
*/
void
packet(
struct p *p, /* peer structure pointer */
struct r *r /* receive packet pointer */
)
{
double offset; /* sample offsset */
double delay; /* sample delay */
double disp; /* sample dispersion */
/*
* By golly the packet is valid. Light up the remaining header
* fields. Note that we map stratum 0 (unspecified) to MAXSTRAT
* to make stratum comparisons simpler and to provide a natural
* interface for radio clock drivers that operate for
* convenience at stratum 0.
*/
p->leap = r->leap;
if (r->stratum == 0)
p->stratum = MAXSTRAT;
else
p->stratum = r->stratum;
p->pmode = r->mode;
p->ppoll = r->poll;
p->rootdelay = FP2D(r->rootdelay);
p->rootdisp = FP2D(r->rootdisp);
p->refid = r->refid;
p->reftime = r->reftime;
/*
* Verify the server is synchronized with valid stratum and
* reference time not later than the transmit time.
*/
if (p->leap == NOSYNC || p->stratum >= MAXSTRAT)
return; /* unsynchronized */
/*
* Verify valid root distance.
*/
if (r->rootdelay / 2 + r->rootdisp >= MAXDISP || p->reftime >
r->xmt)
return; /* invalid header values */
poll_update(p, p->hpoll);
p->reach |= 1;
/*
* Calculate offset, delay and dispersion, then pass to the
* clock filter. Note carefully the implied processing. The
* first-order difference is done directly in 64-bit arithmetic,
* then the result is converted to floating double. All further
* processing is in floating-double arithmetic with rounding
* done by the hardware. This is necessary in order to avoid
* overflow and preserve precision.
*
* The delay calculation is a special case. In cases where the
* server and client clocks are running at different rates and
* with very fast networks, the delay can appear negative. In
* order to avoid violating the Principle of Least Astonishment,
* the delay is clamped not less than the system precision.
*/
if (p->pmode == M_BCST) {
offset = LFP2D(r->xmt - r->dst);
delay = BDELAY;
disp = LOG2D(r->precision) + LOG2D(s.precision) + PHI *
2 * BDELAY;
} else {
offset = (LFP2D(r->rec - r->org) + LFP2D(r->dst -
r->xmt)) / 2;
delay = max(LFP2D(r->dst - r->org) - LFP2D(r->rec -
r->xmt), LOG2D(s.precision));
disp = LOG2D(r->precision) + LOG2D(s.precision) + PHI *
LFP2D(r->dst - r->org);
}
clock_filter(p, offset, delay, disp);
}
/*
* clock_filter(p, offset, delay, dispersion) - select the best from the
* latest eight delay/offset samples.
*/
void
clock_filter(
struct p *p, /* peer structure pointer */
double offset, /* clock offset */
double delay, /* roundtrip delay */
double disp /* dispersion */
)
{
struct f f[NSTAGE]; /* sorted list */
double dtemp;
int i;
/*
* The clock filter contents consist of eight tuples (offset,
* delay, dispersion, time). Shift each tuple to the left,
* discarding the leftmost one. As each tuple is shifted,
* increase the dispersion since the last filter update. At the
* same time, copy each tuple to a temporary list. After this,
* place the (offset, delay, disp, time) in the vacated
* rightmost tuple.
*/
for (i = 1; i < NSTAGE; i++) {
p->f[i] = p->f[i - 1];
p->f[i].disp += PHI * (c.t - p->t);
f[i] = p->f[i];
}
p->f[0].t = c.t;
p->f[0].offset = offset;
p->f[0].delay = delay;
p->f[0].disp = disp;
f[0] = p->f[0];
/*
* Sort the temporary list of tuples by increasing f[].delay.
* The first entry on the sorted list represents the best
* sample, but it might be old.
*/
dtemp = p->offset;
p->offset = f[0].offset;
p->delay = f[0].delay;
for (i = 0; i < NSTAGE; i++) {
p->disp += f[i].disp / (2 ^ (i + 1));
p->jitter += SQUARE(f[i].offset - f[0].offset);
}
p->jitter = max(SQRT(p->jitter), LOG2D(s.precision));
/*
* Prime directive: use a sample only once and never a sample
* older than the latest one, but anything goes before first
* synchronized.
*/
if (f[0].t - p->t <= 0 && s.leap != NOSYNC)
return;
/*
* Popcorn spike suppressor. Compare the difference between the
* last and current offsets to the current jitter. If greater
* than SGATE (3) and if the interval since the last offset is
* less than twice the system poll interval, dump the spike.
* Otherwise, and if not in a burst, shake out the truechimers.
*/
if (fabs(p->offset - dtemp) > SGATE * p->jitter && (f[0].t -
p->t) < 2 * s.poll)
return;
p->t = f[0].t;
if (p->burst == 0)
clock_select();
return;
}
/*
* fit() - test if association p is acceptable for synchronization
*/
int
fit(
struct p *p /* peer structure pointer */
)
{
/*
* A stratum error occurs if (1) the server has never been
* synchronized, (2) the server stratum is invalid.
*/
if (p->leap == NOSYNC || p->stratum >= MAXSTRAT)
return (FALSE);
/*
* A distance error occurs if the root distance exceeds the
* distance threshold plus an increment equal to one poll
* interval.
*/
if (root_dist(p) > MAXDIST + PHI * LOG2D(s.poll))
return (FALSE);
/*
* A loop error occurs if the remote peer is synchronized to the
* local peer or the remote peer is synchronized to the current
* system peer. Note this is the behavior for IPv4; for IPv6
* the MD5 hash is used instead.
*/
if (p->refid == p->dstaddr || p->refid == s.refid)
return (FALSE);
/*
* An unreachable error occurs if the server is unreachable.
*/
if (p->reach == 0)
return (FALSE);
return (TRUE);
}
/*
* clear() - reinitialize for persistent association, demobilize
* for ephemeral association.
*/
void
clear(
struct p *p, /* peer structure pointer */
int kiss /* kiss code */
)
{
int i;
/*
* The first thing to do is return all resources to the bank.
* Typical resources are not detailed here, but they include
* dynamically allocated structures for keys, certificates, etc.
* If an ephemeral association and not initialization, return
* the association memory as well.
*/
/* return resources */
if (s.p == p)
s.p = NULL;
if (kiss != X_INIT && (p->flags & P_EPHEM)) {
free(p);
return;
}
/*
* Initialize the association fields for general reset.
*/
memset(BEGIN_CLEAR(p), LEN_CLEAR, 0);
p->leap = NOSYNC;
p->stratum = MAXSTRAT;
p->ppoll = MAXPOLL;
p->hpoll = MINPOLL;
p->disp = MAXDISP;
p->jitter = LOG2D(s.precision);
p->refid = kiss;
for (i = 0; i < NSTAGE; i++)
p->f[i].disp = MAXDISP;
/*
* Randomize the first poll just in case thousands of broadcast
* clients have just been stirred up after a long absence of the
* broadcast server.
*/
p->outdate = p->t = c.t;
p->nextdate = p->outdate + (random() & ((1 << MINPOLL) - 1));
}
/*
* fast_xmit() - transmit a reply packet for receive packet r
*/
void
fast_xmit(
struct r *r, /* receive packet pointer */
int mode, /* association mode */
int auth /* authentication code */
)
{
struct x x;
/*
* Initialize header and transmit timestamp. Note that the
* transmit version is copied from the receive version. This is
* for backward compatibility.
*/
x.version = r->version;
x.srcaddr = r->dstaddr;
x.dstaddr = r->srcaddr;
x.leap = s.leap;
x.mode = mode;
if (s.stratum == MAXSTRAT)
x.stratum = 0;
else
x.stratum = s.stratum;
x.poll = r->poll;
x.precision = s.precision;
x.rootdelay = D2FP(s.rootdelay);
x.rootdisp = D2FP(s.rootdisp);
x.refid = s.refid;
x.reftime = s.reftime;
x.org = r->xmt;
x.rec = r->dst;
x.xmt = get_time();
/*
* If the authentication code is A.NONE, include only the
* header; if A.CRYPTO, send a crypto-NAK; if A.OK, send a valid
* MAC. Use the key ID in the received packet and the key in
* the local key cache.
*/
if (auth != A_NONE) {
if (auth == A_CRYPTO) {
x.keyid = 0;
} else {
x.keyid = r->keyid;
x.dgst = md5(x.keyid);
}
}
xmit_packet(&x);
}
/*
* access() - determine access restrictions
*/
int
access(
struct r *r /* receive packet pointer */
)
{
/*
* The access control list is an ordered set of tuples
* consisting of an address, mask, and restrict word containing
* defined bits. The list is searched for the first match on
* the source address (r->srcaddr) and the associated restrict
* word is returned.
*/
return (/* access bits */ 0);
}
/*
* clock_select() - find the best clocks
*/
void
clock_select() {
struct p *p, *osys; /* peer structure pointers */
double low, high; /* correctness interval extents */
int allow, found, chime; /* used by intersection algorithm */
int n, i, j;
/*
* We first cull the falsetickers from the server population,
* leaving only the truechimers. The correctness interval for
* association p is the interval from offset - root_dist() to
* offset + root_dist(). The object of the game is to find a
* majority clique; that is, an intersection of correctness
* intervals numbering more than half the server population.
*
* First, construct the chime list of tuples (p, type, edge) as
* shown below, then sort the list by edge from lowest to
* highest.
*/
osys = s.p;
s.p = NULL;
n = 0;
while (fit(p)) {
s.m[n].p = p;
s.m[n].type = +1;
s.m[n].edge = p->offset + root_dist(p);
n++;
s.m[n].p = p;
s.m[n].type = 0;
s.m[n].edge = p->offset;
n++;
s.m[n].p = p;
s.m[n].type = -1;
s.m[n].edge = p->offset - root_dist(p);
n++;
}
/*
* Find the largest contiguous intersection of correctness
* intervals. Allow is the number of allowed falsetickers;
* found is the number of midpoints. Note that the edge values
* are limited to the range +-(2 ^ 30) < +-2e9 by the timestamp
* calculations.
*/
low = 2e9; high = -2e9;
for (allow = 0; 2 * allow < n; allow++) {
/*
* Scan the chime list from lowest to highest to find
* the lower endpoint.
*/
found = 0;
chime = 0;
for (i = 0; i < n; i++) {
chime -= s.m[i].type;
if (chime >= n - found) {
low = s.m[i].edge;
break;
}
if (s.m[i].type == 0)
found++;
}
/*
* Scan the chime list from highest to lowest to find
* the upper endpoint.
*/
chime = 0;
for (i = n - 1; i >= 0; i--) {
chime += s.m[i].type;
if (chime >= n - found) {
high = s.m[i].edge;
break;
}
if (s.m[i].type == 0)
found++;
}
/*
* If the number of midpoints is greater than the number
* of allowed falsetickers, the intersection contains at
* least one truechimer with no midpoint. If so,
* increment the number of allowed falsetickers and go
* around again. If not and the intersection is
* non-empty, declare success.
*/
if (found > allow)
continue;
if (high > low)
break;
}
/*
* Clustering algorithm. Construct a list of survivors (p,
* metric) from the chime list, where metric is dominated first
* by stratum and then by root distance. All other things being
* equal, this is the order of preference.
*/
s.n = 0;
for (i = 0; i < n; i++) {
if (s.m[i].edge < low || s.m[i].edge > high)
continue;
p = s.m[i].p;
s.v[n].p = p;
s.v[n].metric = MAXDIST * p->stratum + root_dist(p);
s.n++;
}
/*
* There must be at least NSANE survivors to satisfy the
* correctness assertions. Ordinarily, the Byzantine criteria
* require four survivors, but for the demonstration here, one
* is acceptable.
*/
if (s.n < NSANE)
return;
/*
* For each association p in turn, calculate the selection
* jitter p->sjitter as the square root of the sum of squares
* (p->offset - q->offset) over all q associations. The idea is
* to repeatedly discard the survivor with maximum selection
* jitter until a termination condition is met.
*/
while (1) {
struct p *p, *q, *qmax; /* peer structure pointers */
double max, min, dtemp;
max = -2e9; min = 2e9;
for (i = 0; i < s.n; i++) {
p = s.v[i].p;
if (p->jitter < min)
min = p->jitter;
dtemp = 0;
for (j = 0; j < n; j++) {
q = s.v[j].p;
dtemp += SQUARE(p->offset - q->offset);
}
dtemp = SQRT(dtemp);
if (dtemp > max) {
max = dtemp;
qmax = q;
}
}
/*
* If the maximum selection jitter is less than the
* minimum peer jitter, then tossing out more survivors
* will not lower the minimum peer jitter, so we might
* as well stop. To make sure a few survivors are left
* for the clustering algorithm to chew on, we also stop
* if the number of survivors is less than or equal to
* NMIN (3).
*/
if (max < min || n <= NMIN)
break;
/*
* Delete survivor qmax from the list and go around
* again.
*/
s.n--;
}
/*
* Pick the best clock. If the old system peer is on the list
* and at the same stratum as the first survivor on the list,
* then don't do a clock hop. Otherwise, select the first
* survivor on the list as the new system peer.
*/
if (osys->stratum == s.v[0].p->stratum)
s.p = osys;
else
s.p = s.v[0].p;
clock_update(s.p);
}
/*
* root_dist() - calculate root distance
*/
double
root_dist(
struct p *p /* peer structure pointer */
)
{
/*
* The root synchronization distance is the maximum error due to
* all causes of the local clock relative to the primary server.
* It is defined as half the total delay plus total dispersion
* plus peer jitter.
*/
return (max(MINDISP, p->rootdelay + p->delay) / 2 +
p->rootdisp + p->disp + PHI * (c.t - p->t) + p->jitter);
}
/*
* accept() - test if association p is acceptable for synchronization
*/
int
accept(
struct p *p /* peer structure pointer */
)
{
/*
* A stratum error occurs if (1) the server has never been
* synchronized, (2) the server stratum is invalid.
*/
if (p->leap == NOSYNC || p->stratum >= MAXSTRAT)
return (FALSE);
/*
* A distance error occurs if the root distance exceeds the
* distance threshold plus an increment equal to one poll
* interval.
*/
if (root_dist(p) > MAXDIST + PHI * LOG2D(s.poll))
return (FALSE);
/*
* A loop error occurs if the remote peer is synchronized to the
* local peer or the remote peer is synchronized to the current
* system peer. Note this is the behavior for IPv4; for IPv6
* the MD5 hash is used instead.
*/
if (p->refid == p->dstaddr || p->refid == s.refid)
return (FALSE);
/*
* An unreachable error occurs if the server is unreachable.
*/
if (p->reach == 0)
return (FALSE);
return (TRUE);
}
/*
* clock_update() - update the system clock
*/
void
clock_update(
struct p *p /* peer structure pointer */
)
{
double dtemp;
/*
* If this is an old update, for instance, as the result of a
* system peer change, avoid it. We never use an old sample or
* the same sample twice.
*/
if (s.t >= p->t)
return;
/*
* Combine the survivor offsets and update the system clock; the
* local_clock() routine will tell us the good or bad news.
*/
s.t = p->t;
clock_combine();
switch (local_clock(p, s.offset)) {
/*
* The offset is too large and probably bogus. Complain to the
* system log and order the operator to set the clock manually
* within PANIC range. The reference implementation includes a
* command line option to disable this check and to change the
* panic threshold from the default 1000 s as required.
*/
case PANIC:
exit (0);
/*
* The offset is more than the step threshold (0.125 s by
* default). After a step, all associations now have
* inconsistent time values, so they are reset and started
* fresh. The step threshold can be changed in the reference
* implementation in order to lessen the chance the clock might
* be stepped backwards. However, there may be serious
* consequences, as noted in the white papers at the NTP project
* site.
*/
case STEP:
while (/* all associations */ 0)
clear(p, X_STEP);
s.stratum = MAXSTRAT;
s.poll = MINPOLL;
break;
/*
* The offset was less than the step threshold, which is the
* normal case. Update the system variables from the peer
* variables. The lower clamp on the dispersion increase is to
* avoid timing loops and clockhopping when highly precise
* sources are in play. The clamp can be changed from the
* default .01 s in the reference implementation.
*/
case SLEW:
s.leap = p->leap;
s.stratum = p->stratum + 1;
s.refid = p->refid;
s.reftime = p->reftime;
s.rootdelay = p->rootdelay + p->delay;
dtemp = SQRT(SQUARE(p->jitter) + SQUARE(s.jitter));
dtemp += max(p->disp + PHI * (c.t - p->t) +
fabs(p->offset), MINDISP);
s.rootdisp = p->rootdisp + dtemp;
break;
/*
* Some samples are discarded while, for instance, a direct
* frequency measurement is being made.
*/
case IGNORE:
break;
}
}
/*
* clock_combine() - combine offsets
*/
void
clock_combine()
{
struct p *p; /* peer structure pointer */
double x, y, z, w;
int i;
/*
* Combine the offsets of the clustering algorithm survivors
* using a weighted average with weight determined by the root
* distance. Compute the selection jitter as the weighted RMS
* difference between the first survivor and the remaining
* survivors. In some cases, the inherent clock jitter can be
* reduced by not using this algorithm, especially when frequent
* clockhopping is involved. The reference implementation can
* be configured to avoid this algorithm by designating a
* preferred peer.
*/
y = z = w = 0;
for (i = 0; s.v[i].p != NULL; i++) {
p = s.v[i].p;
x = root_dist(p);
y += 1 / x;
z += p->offset / x;
w += SQUARE(p->offset - s.v[0].p->offset) / x;
}
s.offset = z / y;
s.jitter = SQRT(w / y);
}
/*
* Clock discipline parameters and constants
*/
#define STEPT .128 /* step threshold (s) */
#define WATCH 900 /* stepout threshold (s) */
#define PANICT 1000 /* panic threshold (s) */
#define PLL 65536 /* PLL loop gain */
#define FLL MAXPOLL + 1 /* FLL loop gain */
#define AVG 4 /* parameter averaging constant */
#define ALLAN 1500 /* compromise Allan intercept (s) */
#define LIMIT 30 /* poll-adjust threshold */
#define MAXFREQ 500e-6 /* frequency tolerance (500 ppm) */
#define PGATE 4 /* poll-adjust gate */
/*
* local_clock() - discipline the local clock
*/
int /* return code */
local_clock(
struct p *p, /* peer structure pointer */
double offset /* clock offset from combine() */
)
{
int state; /* clock discipline state */
double freq; /* frequency */
double mu; /* interval since last update */
int rval;
double etemp, dtemp;
/*
* If the offset is too large, give up and go home.
*/
if (fabs(offset) > PANICT)
return (PANIC);
/*
* Clock state machine transition function. This is where the
* action is and defines how the system reacts to large time
* and frequency errors. There are two main regimes: when the
* offset exceeds the step threshold and when it does not.
*/
rval = SLEW;
mu = p->t - s.t;
freq = 0;
if (fabs(offset) > STEPT) {
switch (c.state) {
/*
* In S_SYNC state, we ignore the first outlier and
* switch to S_SPIK state.
*/
case SYNC:
state = SPIK;
return (rval);
/*
* In S_FREQ state, we ignore outliers and inliers. At
* the first outlier after the stepout threshold,
* compute the apparent frequency correction and step
* the time.
*/
case FREQ:
if (mu < WATCH)
return (IGNORE);
freq = (offset - c.offset) / mu;
/* fall through to S_SPIK */
/*
* In S_SPIK state, we ignore succeeding outliers until
* either an inlier is found or the stepout threshold is
* exceeded.
*/
case SPIK:
if (mu < WATCH)
return (IGNORE);
/* fall through to default */
/*
* We get here by default in S_NSET and S_FSET states
* and from above in S_FREQ state. Step the time and
* clamp down the poll interval.
*
* In S_NSET state, an initial frequency correction is
* not available, usually because the frequency file has
* not yet been written. Since the time is outside the
* capture range, the clock is stepped. The frequency
* will be set directly following the stepout interval.
*
* In S_FSET state, the initial frequency has been set
* from the frequency file. Since the time is outside
* the capture range, the clock is stepped immediately,
* rather than after the stepout interval. Guys get
* nervous if it takes 17 minutes to set the clock for
* the first time. * * In S_SPIK state, the stepout threshold has expired * and the phase is still above the step threshold. * Note that a single spike greater than the step * threshold is always suppressed, even at the longer * poll intervals. */ default:
* 初めて。 * * S_SPIK状態で、脱調しきい値が期限切れになり、フェーズはまだステップしきい値を上回っています。 *ポーリング間隔が長くなった場合でも、*ステップのしきい値より大きい単一のスパイクが常に抑制されることに注意してください。 */ デフォルト：
/*
* This is the kernel set time function, usually
* implemented by the Unix settimeofday() system
* call.
*/
step_time(offset);
c.count = 0;
s.poll = MINPOLL;
rval = STEP;
if (state == NSET) {
rstclock(FREQ, p->t, 0);
return (rval);
}
break;
}
rstclock(SYNC, p->t, 0);
} else {
/*
* Compute the clock jitter as the RMS of exponentially
* weighted offset differences. This is used by the
* poll-adjust code.
*/
etemp = SQUARE(c.jitter);
dtemp = SQUARE(max(fabs(offset - c.last),
LOG2D(s.precision)));
c.jitter = SQRT(etemp + (dtemp - etemp) / AVG);
switch (c.state) {
/*
* In S_NSET state, this is the first update received
* and the frequency has not been initialized. The
* first thing to do is directly measure the oscillator
* frequency.
*/
case NSET:
rstclock(FREQ, p->t, offset);
return (IGNORE);
/*
* In S_FSET state, this is the first update and the
* frequency has been initialized. Adjust the phase,
* but don't adjust the frequency until the next update.
*/
case FSET:
rstclock(SYNC, p->t, offset);
break;
/*
* In S_FREQ state, ignore updates until the stepout
* threshold. After that, correct the phase and
* frequency and switch to S_SYNC state.
*/
case FREQ:
if (c.t - s.t < WATCH)
return (IGNORE);
freq = (offset - c.offset) / mu;
break;
/*
* We get here by default in S_SYNC and S_SPIK states.
* Here we compute the frequency update due to PLL and
* FLL contributions.
*/
default:
/*
* The FLL and PLL frequency gain constants
* depending on the poll interval and Allan
* intercept. The FLL is not used below one
* half the Allan intercept. Above that the
* loop gain increases in steps to 1 / AVG.
*/
if (LOG2D(s.poll) > ALLAN / 2) {
etemp = FLL - s.poll;
if (etemp < AVG)
etemp = AVG;
freq += (offset - c.offset) / (max(mu,
ALLAN) * etemp);
}
/*
* For the PLL the integration interval
* (numerator) is the minimum of the update
* interval and poll interval. This allows
* oversampling, but not undersampling.
*/
etemp = min(mu, LOG2D(s.poll));
dtemp = 4 * PLL * LOG2D(s.poll);
freq += offset * etemp / (dtemp * dtemp);
rstclock(SYNC, p->t, offset);
break;
}
}
/*
* Calculate the new frequency and frequency stability (wander).
* Compute the clock wander as the RMS of exponentially weighted
* frequency differences. This is not used directly, but can,
* along with the jitter, be a highly useful monitoring and
* debugging tool.
*/
freq += c.freq;
c.freq = max(min(MAXFREQ, freq), -MAXFREQ);
etemp = SQUARE(c.wander);
dtemp = SQUARE(freq);
c.wander = SQRT(etemp + (dtemp - etemp) / AVG);
/*
* Here we adjust the poll interval by comparing the current
* offset with the clock jitter. If the offset is less than the
* clock jitter times a constant, then the averaging interval is
* increased; otherwise, it is decreased. A bit of hysteresis
* helps calm the dance. Works best using burst mode.
*/
if (fabs(c.offset) < PGATE * c.jitter) {
c.count += s.poll;
if (c.count > LIMIT) {
c.count = LIMIT;
if (s.poll < MAXPOLL) {
c.count = 0;
s.poll++;
}
}
} else {
c.count -= s.poll << 1;
if (c.count < -LIMIT) {
c.count = -LIMIT;
if (s.poll > MINPOLL) {
c.count = 0;
s.poll--;
}
}
}
return (rval);
}
/*
* rstclock() - clock state machine
*/
void
rstclock(
int state, /* new state */
double offset, /* new offset */
double t /* new update time */
)
{
/*
* Enter new state and set state variables. Note, we use the
* time of the last clock filter sample, which must be earlier
* than the current time.
*/
c.state = state;
c.last = c.offset = offset;
s.t = t;
}
/*
* clock_adjust() - runs at one-second intervals
*/
void
clock_adjust() {
double dtemp;
/*
* Update the process time c.t. Also increase the dispersion
* since the last update. In contrast to NTPv3, NTPv4 does not
* declare unsynchronized after one day, since the dispersion
* threshold serves this function. When the dispersion exceeds
* MAXDIST (1 s), the server is considered unfit for
* synchronization.
*/
c.t++;
s.rootdisp += PHI;
/*
* Implement the phase and frequency adjustments. The gain
* factor (denominator) is not allowed to increase beyond the
* Allan intercept. It doesn't make sense to average phase
* noise beyond this point and it helps to damp residual offset
* at the longer poll intervals.
*/
dtemp = c.offset / (PLL * min(LOG2D(s.poll), ALLAN));
c.offset -= dtemp;
/*
* This is the kernel adjust time function, usually implemented
* by the Unix adjtime() system call.
*/
adjust_time(c.freq + dtemp);
/*
* Peer timer. Call the poll() routine when the poll timer
* expires.
*/
while (/* all associations */ 0) {
struct p *p; /* dummy peer structure pointer */
if (c.t >= p->nextdate)
poll(p);
}
/*
* Once per hour, write the clock frequency to a file.
*/
/*
* if (c.t % 3600 == 3599)
* write c.freq to file
*/
}
/*
* Poll process parameters and constants
*/
#define UNREACH 12 /* unreach counter threshold */
#define BCOUNT 8 /* packets in a burst */
#define BTIME 2 /* burst interval (s) */
/*
* poll() - determine when to send a packet for association p->
*/
void
poll(
struct p *p /* peer structure pointer */
)
{
int hpoll;
int oreach;
/*
* This routine is called when the current time c.t catches up
* to the next poll time p->nextdate. The value p->outdate is
* the last time this routine was executed. The poll_update()
* routine determines the next execution time p->nextdate.
*
* If broadcasting, just do it, but only if we are synchronized.
*/
hpoll = p->hpoll;
if (p->hmode == M_BCST) {
p->outdate = c.t;
if (s.p != NULL)
peer_xmit(p);
poll_update(p, hpoll);
return;
}
/*
* If manycasting, start with ttl = 1. The ttl is increased by
* one for each poll until MAXCLOCK servers have been found or
* ttl reaches TTLMAX. If reaching MAXCLOCK, stop polling until
* the number of servers falls below MINCLOCK, then start all
* over.
*/
if (p->hmode == M_CLNT && p->flags & P_MANY) {
p->outdate = c.t;
if (p->unreach > BEACON) {
p->unreach = 0;
p->ttl = 1;
peer_xmit(p);
} else if (s.n < MINCLOCK) {
if (p->ttl < TTLMAX)
p->ttl++;
peer_xmit(p);
}
p->unreach++;
poll_update(p, hpoll);
return;
}
if (p->burst == 0) {
/*
* We are not in a burst. Shift the reachability
* register to the left. Hopefully, some time before
* the next poll a packet will arrive and set the
* rightmost bit.
*/
oreach = p->reach;
p->outdate = c.t;
p->reach = p->reach << 1;
if (!(p->reach & 0x7))
clock_filter(p, 0, 0, MAXDISP);
if (!p->reach) {
/*
* The server is unreachable, so bump the
* unreach counter. If the unreach threshold
* has been reached, double the poll interval
* to minimize wasted network traffic. Send a
* burst only if enabled and the unreach
* threshold has not been reached.
*/
if (p->flags & P_IBURST && p->unreach == 0) {
p->burst = BCOUNT;
} else if (p->unreach < UNREACH)
p->unreach++;
else
hpoll++;
p->unreach++;
} else {
/*
* The server is reachable. Set the poll
* interval to the system poll interval. Send a
* burst only if enabled and the peer is fit.
*/
p->unreach = 0;
hpoll = s.poll;
if (p->flags & P_BURST && fit(p))
p->burst = BCOUNT;
}
} else {
/*
* If in a burst, count it down. When the reply comes
* back the clock_filter() routine will call
* clock_select() to process the results of the burst.
*/
p->burst--;
}
/*
* Do not transmit if in broadcast client mode.
*/
if (p->hmode != M_BCLN)
peer_xmit(p);
poll_update(p, hpoll);
}
/*
* poll_update() - update the poll interval for association p
*
* Note: This routine is called by both the packet() and poll() routine.
* Since the packet() routine is executed when a network packet arrives
* and the poll() routine is executed as the result of timeout, a
* potential race can occur, possibly causing an incorrect interval for
* the next poll. This is considered so unlikely as to be negligible.
*/
void
poll_update(
struct p *p, /* peer structure pointer */
int poll /* poll interval (log2 s) */
)
{
/*
* This routine is called by both the poll() and packet()
* routines to determine the next poll time. If within a burst
* the poll interval is two seconds. Otherwise, it is the
* minimum of the host poll interval and peer poll interval, but
* not greater than MAXPOLL and not less than MINPOLL. The
* design ensures that a longer interval can be preempted by a
* shorter one if required for rapid response.
*/
p->hpoll = max(min(MAXPOLL, poll), MINPOLL);
if (p->burst > 0) {
if (p->nextdate != c.t)
return;
else
p->nextdate += BTIME;
} else {
/*
* While not shown here, the reference implementation
* randomizes the poll interval by a small factor.
*/
p->nextdate = p->outdate + (1 << max(min(p->ppoll,
p->hpoll), MINPOLL));
}
/*
* It might happen that the due time has already passed. If so,
* make it one second in the future.
*/
if (p->nextdate <= c.t)
p->nextdate = c.t + 1;
}
/*
* transmit() - transmit a packet for association p
*/
void
peer_xmit(
struct p *p /* peer structure pointer */
)
{
struct x x; /* transmit packet */
/*
* Initialize header and transmit timestamp
*/
x.srcaddr = p->dstaddr;
x.dstaddr = p->srcaddr;
x.leap = s.leap;
x.version = p->version;
x.mode = p->hmode;
if (s.stratum == MAXSTRAT)
x.stratum = 0;
else
x.stratum = s.stratum;
x.poll = p->hpoll;
x.precision = s.precision;
x.rootdelay = D2FP(s.rootdelay);
x.rootdisp = D2FP(s.rootdisp);
x.refid = s.refid;
x.reftime = s.reftime;
x.org = p->org;
x.rec = p->rec;
x.xmt = get_time();
p->xmt = x.xmt;
/*
* If the key ID is nonzero, send a valid MAC using the key ID
* of the association and the key in the local key cache. If
* something breaks, like a missing trusted key, don't send the
* packet; just reset the association and stop until the problem
* is fixed.
*/
if (p->keyid)
if (/* p->keyid invalid */ 0) {
clear(p, X_NKEY);
return;
}
x.dgst = md5(p->keyid);
xmit_packet(&x);
}
Authors' Addresses
Dr. David L. Mills University of Delaware Newark, DE 19716 US
デビッドL.ミルズデラウェア大学ニューアーク校、DE 19716 US
Phone: +1 302 831 8247
EMail: mills@udel.edu
Jim Martin (editor) Internet Systems Consortium 950 Charter Street Redwood City, CA 94063 US
ジムマーティン（編集者）Internet Systems Consortium 950 Charter Street Redwood City、CA 94063 US
Phone: +1 650 423 1378
EMail: jrmii@isc.org
Jack Burbank The Johns Hopkins University Applied Physics Laboratory 11100 Johns Hopkins Road Laurel, MD 20723-6099 US
ジャックバーバンクジョンズホプキンス大学応用物理学研究所11100ジョンズホプキンスロードローレル、MD 20723-6099米国
Phone: +1 443 778 7127
EMail: jack.burbank@jhuapl.edu
William Kasch The Johns Hopkins University Applied Physics Laboratory 11100 Johns Hopkins Road Laurel, MD 20723-6099 US
ウィリアムカッシュジョンズホプキンス大学応用物理研究所11100ジョンズホプキンスロードローレル、MD 20723-6099米国
Phone: +1 443 778 7463
EMail: william.kasch@jhuapl.edu