RFC958 日本語訳

Network Working Group                                         D.L. Mills
Request for Comments: 958                               M/A-COM Linkabit
                                                          September 1985

L.工場がコメントのために要求するワーキンググループD.をネットワークでつないでください: 1985年9月の1COM Linkabitの958M/

                      Network Time Protocol (NTP)

ネットワーク時間プロトコル(NTP)

Status of this Memo

このMemoの状態

   This RFC suggests a proposed protocol for the ARPA-Internet
   community, and requests discussion and suggestions for improvements.
   Distribution of this memo is unlimited.

このRFCは改良のためにARPA-インターネットコミュニティ、要求議論、および提案のための提案されたプロトコルを勧めます。 このメモの分配は無制限です。

Table of Contents

目次

   1.      Introduction
   2.      Service Model
   3.      Protocol Overview
   4.      State Variables and Formats
   5.      Protocol Operation
   5.1.    Protocol Modes
   5.2.    Message Processing
   5.3.    Network Considerations
   5.4.    Leap Seconds
   6.      References
   Appendix A. UDP Header Format
   Appendix B. NTP Data Format

1. 序論2。 モデル3にサービスを提供してください。 概要4について議定書の中で述べてください。 変数と書式5を述べてください。 操作5.1について議定書の中で述べてください。 モード5.2を議定書の中で述べてください。 メッセージ処理5.3。 問題5.4をネットワークでつないでください。 飛躍秒6。 参照付録A.UDPヘッダー形式付録B.NTPデータの形式

1.  Introduction

1. 序論

   This document describes the Network Time Protocol (NTP), a protocol
   for synchronizing a set of network clocks using a set of distributed
   clients and servers.  NTP is built on the User Datagram Protocol
   (UDP) [13], which provides a connectionless transport mechanism.  It
   is evolved from the Time Protocol [7] and the ICMP Timestamp message
   [6] and is a suitable replacement for both.

このドキュメントはNetwork Timeプロトコル(NTP)(1セットの分配されたクライアントとサーバを使用することで1セットのネットワーク時計を連動させるためのプロトコル)について説明します。 NTPはユーザー・データグラム・プロトコル(UDP)[13]に造られます。([13]はコネクションレスな移送機構を提供します)。 それは、Timeプロトコル[7]とICMP Timestampメッセージ[6]から発展されて、両方への適当な交換です。

   NTP provides the protocol mechanisms to synchronize time in principle
   to precisions in the order of nanoseconds while preserving a
   non-ambiguous date, at least for this century.  The protocol includes
   provisions to specify the precision and estimated error of the local
   clock and the characteristics of the reference clock to which it may
   be synchronized.  However, the protocol itself specifies only the
   data representation and message formats and does not specify the
   synchronizing algorithms or filtering mechanisms.

NTPは非あいまいな期日を保持している間、原則として数ナノ秒の注文における確度への時間を同期させるようにプロトコルメカニズムを提供します、少なくとも今世紀に。 プロトコルは、地方の時計の精度とおよそ誤りとそれが連動するかもしれない基準クロックの特性を指定するために条項を含んでいます。 しかしながら、プロトコル自体は、データ表現とメッセージ・フォーマットだけを指定して、連動アルゴリズムかフィルタリングメカニズムは指定しません。

   Other mechanisms have been specified in the Internet protocol suite
   to record and transmit the time at which an event takes place,
   including the Daytime protocol [8] and IP Timestamp option [9].  The
   NTP is not meant to displace either of these mechanisms.  Additional
   information on network time synchronization can be found in the

他のメカニズムはイベントが行われる時を記録して、伝えるためにインターネット・プロトコル群で指定されました、Daytimeプロトコル[8]とIP Timestampオプション[9]を含んでいて。 NTPは. ネットワーク時間同期化に関する追加情報を見つけることができるこれらのどちらのメカニズムも置き換えることになっていません。

Mills                                                           [Page 1]

工場[1ページ]

RFC 958                                                        September
Network Time Protocol

RFC958 9月のネットワーク時間プロトコル

   References at the end of this document.  An earlier synchronization
   protocol is discussed in [3] and synchronization algorithms in [2],
   [5], [10] and [12]. Experimental results on measured roundtrip delays
   and clock offsets in the Internet are discussed in [4] and [11].  A
   comprehensive mathematical treatment of clock synchronization can be
   found in [1].

このドキュメントの端での参照。 [2]、[5]、[10]、および[12]で[3]と同期アルゴリズムで以前の同期プロトコルについて議論します。 [4]と[11]で測定往復の遅れの実験結果とインターネットでの時計オフセットについて議論します。 [1]で時計同期の包括的な数学の処理を見つけることができます。

2.  Service Model

2. サービスモデル

   The intent of the service for which this protocol is designed is to
   connect a few primary reference clocks, synchronized by wire or radio
   to national standards, to centrally accessable resources such as
   gateways. These gateways would use NTP between them to cross-check
   the primary clocks and mitigate errors due to equipment or
   propagation failures. Some number of local-net hosts, serving as
   secondary reference clocks, would run NTP with one or more of these
   gateways.  In order to reduce the protocol overhead, these hosts
   would redistribute time to the remaining local-net hosts.  In the
   interest of reliability selected hosts might be equipped with less
   accurate but less expensive radio clocks and used for backup in case
   of failure of the primary and/or secondary clocks or communication
   paths between them.

このプロトコルが設計されているサービスの意図はワイヤかラジオによって国家規格に連動させられるいくつかのプライマリ基準クロックをゲートウェイなどの中心でアクセス可能なリソースに接続することです。 これらのゲートウェイは、プライマリ時計にクロスチェックして、設備による誤りか伝播失敗を緩和するのにそれらの間でNTPを使用するでしょう。 セカンダリ参照が時間を計るので役立って、何らかの数の地方にネットのホストがこれらのゲートウェイの1つ以上があるNTPを実行するでしょう。 プロトコルオーバーヘッドを下げるために、これらのホストは残っている地方にネットのホストに時間を再配付するでしょう。 信頼性のために、選択されたホストは、それほど正確でない、しかし、それほど高価でないラジオ時計を備えて、それらの間のプライマリの、そして/または、セカンダリの時計か通信路の失敗の場合にバックアップに使用されるかもしれません。

   In the normal configuration a subnetwork of primary and secondary
   clocks will assume a hierarchical organization with the more accurate
   clocks near the top and the less accurate below.  NTP provides
   information that can be used to organize this hierarchy on the basis
   of precision or estimated error and even to serve as a rudimentary
   routing algorithm to organize the subnetwork itself.  However, the
   NTP protocol does not include a specification of the algorithms for
   doing this, which is left as a topic for further study.

正常な構成では、より正確な時計が先端の近くにあって、それほど正確でないのが以下にある状態で、プライマリの、そして、セカンダリの時計のサブネットワークは階層的な組織を仮定するでしょう。 NTPは精度かおよそ誤りに基づいてこの階層構造を組織化して、組織化する初歩的なルーティング・アルゴリズムとして機能するのさえ使用できる情報にサブネットワーク自体を提供します。 しかしながら、NTPプロトコルはこれをするためのアルゴリズムの仕様を含んでいません。(それは、さらなる研究への話題として残されます)。

3.  Protocol Overview

3. プロトコル概要

   There is no provision for peer discovery, acquisition, or
   authentication in NTP.  Data integrity is provided by the IP and UDP
   checksums.  No reachability, circuit-management, duplicate-detection
   or retransmission facilities are provided or necessary.  The service
   can operate in a symmetric mode, in which servers and clients are
   indistinguishable yet maintain a small amount of state information,
   or in an unsymmetric mode in which servers need maintain no client
   state other than that contained in the client request.  Moreover,
   only a single NTP message format is necessary, which simplifies
   implementation and can be used in a variety of solicited or
   unsolicited polling mechanisms.

同輩発見、獲得、または認証への支給が全くNTPにありません。 IPとUDPチェックサムはデータの保全を提供します。どんな可到達性、回路管理、写し検出または「再-トランスミッション」施設は、提供していなくて、また必要ではありません。 サービスは左右対称のモードかクライアント要求に含まれているのを除いて、サーバが属国を全く維持する必要はないunsymmetricモードで作動できます。(サーバとクライアントは、それで区別がつかないのですが、少量の州の情報を保守します)。 そのうえ、ただ一つのNTPメッセージ・フォーマットだけが必要です、そして、(実装を簡素化します)さまざまな請求されたか求められていない世論調査メカニズムで使用できます。

   In what may be the most common (unsymmetric) mode a client sends an

クライアントが送る中で最も一般的な(「非-左右対称」の)モードであるかもしれないこと

Mills                                                           [Page 2]

工場[2ページ]

RFC 958                                                        September
Network Time Protocol

RFC958 9月のネットワーク時間プロトコル

   NTP message to one or more servers and processes the replies as
   received.  The server interchanges addresses and ports, fills in or
   overwrites certain fields in the message, recalculates the checksum
   and returns it immediately.  Information included in the NTP message
   allows each client/server peer to determine the timekeeping
   characteristics of its other peers, including the expected accuracies
   of their clocks. Using this information each peer is able to select
   the best time from possibly several other clocks, update the local
   clock and estimate its accuracy.

NTPは受け取るように1つ以上のサーバとプロセスへ回答を通信させます。 サーバは、アドレスとポートを交換するか、中でいっぱいになるか、メッセージのある一定の分野を上書きして、チェックサムについて再計算して、またはすぐに、それを返します。 それぞれのクライアント/サーバ同輩はNTPメッセージに情報を含んでいるのに他の同輩の時間保持の特性を決定できます、それらの時計の予想された精度を含んでいて。 この情報を使用して、それぞれの同輩は、他のことによると数個の時計からの最も良い時間を選択して、地方の時計をアップデートして、精度を見積もることができます。

   It should be recognized that clock synchronization requires by its
   nature long periods and multiple comparisons in order to maintain
   accurate timekeeping.  While only a few comparisons are usually
   adequate to maintain local time to within a second, primarily to
   protect against broken hardware or synchronization failure, periods
   of hours or days and tens or hundreds of comparisons are required to
   maintain local time to within a few tens of milliseconds.
   Fortunately, the frequency of comparisons can be quite small and
   almost always non-intrusive to normal network operations.

時計同期が正確な時間保持を維持するために本質的に長い期間と複数の比較を必要とすると認められるべきです。 通常、ほんのいくつかの比較が1秒まで現地時間に維持するために適切である間、主として失敗、何時間もの何日もの10の期間または何百もの比較が必要である壊れているハードウェアか同期から守るには、いくつかへの何十人ものミリセカンドをも現地時間に維持してください。 幸い、比較の頻度は、通常のネットワーク操作にかなりわずかであって、ほとんどいつも非押しつけがましい場合があります。

4.  State Variables and Formats

4. 州の変数と形式

   NTP timestamps are represented as a 64-bit fixed-point number, in
   seconds relative to 0000 UT on 1 January 1900.  The integer part is
   in the first 32 bits and the fraction part in the last 32 bits, as
   shown in the following diagram.

NTPタイムスタンプは秒に64ビットの固定小数点数として1900年1月1日世界時0000に比例して表されます。 最初の32ビットと最後の32ビットの小数部には整数部があります、以下のダイヤグラムで示されるように。

       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 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Integer Part                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Fraction Part                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 整数部| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 小数部| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This format allows convenient multiple-precision arithmetic and
   conversion to Time Protocol representation (seconds), but does
   complicate the conversion to ICMP Timestamp message representation
   (milliseconds).  The low-order fraction bit increments at about
   0.2-nanosecond intervals, so a free-running one-millisecond clock
   will be in error only a small fraction of one part per million, or
   less than a second per year.

この形式は、Timeプロトコル表現(秒)に便利な複数の精度演算と変換を許しますが、ICMP Timestampメッセージ表現(ミリセカンド)に変換を複雑にします。 およそ0.2ナノ秒の間隔における下位の断片の噛み付いている増分によって、自由な稼働の1ミリセカンドの時計は100万あたりの一部、または1年あたり1秒未満でわずかな断片だけに間違うでしょう。

   In some cases a particular timestamp may not be available, such as
   when the protocol first starts up.  In these cases the 64-bit field
   is set to zero, indicating the value is invalid or undefined.

いくつかの場合、プロトコルが最初に始まる時のように、特定のタイムスタンプは、利用可能であって、上がっていないかもしれません。 合わせてください64ビットの分野が設定されるゼロこれらの場合では、値を示すのは、無効であるか、または未定義です。

Mills                                                           [Page 3]

工場[3ページ]

RFC 958                                                        September
Network Time Protocol

RFC958 9月のネットワーク時間プロトコル

   Following is a description of the various data items used in the
   protocol.  Details of packet formats are presented in the Appendices.

以下に、プロトコルに使用される様々なデータ項目の記述があります。 パケット・フォーマットの詳細はAppendicesに提示されます。

   Leap Indicator

インディケータを跳ねさせてください。

      This is a two-bit code warning of an impending leap-second to be
      inserted in the internationally coordinated Standard Time
      broadcasts.  A leap-second is occasionally added or subtracted
      from Standard Time, which is based on atomic clocks, to maintain
      agreement with Earth rotation.  When necessary, the corrections
      are notified in advance and executed at the end of the last day of
      the month in which notified, usually June or December.  When a
      correction is executed the first minute of the following day will
      have either 59 or 61 seconds.

これは差し迫っている閏秒が国際的に連携しているStandard Time放送に挿入されるという安っぽいコード警告です。 閏秒は、Standard Timeから時折加えられるか、または引き算されます。(Standard Timeは、地球回転との協定を維持するために原子時計に基づいています)。 通常どれに通知したか、そして、6月か12月に月の最後の日の終わりに必要であるときに、修正は、あらかじめ、通知されて、実行されます。 修正が実行されるとき、翌日の最初の分には、59秒か61秒があるでしょう。

   Status

状態

      This is a six-bit code indicating the status of the local clock.
      Values are assigned to indicate whether it is operating correctly
      or in one of several error states.

これは地方の時計の状態を示す6ビットのコードです。 値は、それが正しいかいくつかの誤り州の1つで作動しているかどうかを示すために割り当てられます。

   Reference Clock Type

基準クロックタイプ

      This is an eight-bit code identifying the type of reference clock
      used to set the local clock.  Values are assigned for primary
      clocks (locally synchronized to Standard Time), secondary clocks
      (remotely synchronized via various network protocols) and even
      eyeball-and-wristwatch.

これは地方の時計を設定するのに使用される基準クロックのタイプを特定する8ビットのコードです。 値はプライマリ時計(局所的に、Standard Timeに連動する)、セカンダリ時計(様々なネットワーク・プロトコルで離れて連動する)、眼球、および腕時計のためにさえ割り当てられます。

   Precision

精度

      This is a 16-bit signed integer indicating the precision of the
      local clock, in seconds to the nearest power of two.  For
      instance, a 60-Hz line-frequency clock would be assigned the value
      -6, while a 1000-Hz crystal clock would be assigned the value -10.

これは地方の時計の精度を示す16ビットの署名している整数です、2の最も近いパワーへの秒に。 例えば、値-6は60Hzの回線周波数時計に割り当てられるでしょう、値-10は1000Hzの水晶時計に割り当てられるでしょうが。

   Estimated Error

誤りであると見積もられています。

      This is a 32-bit fixed-point number indicating the estimated error
      of the local clock at the time last set.  The value is in seconds,
      with fraction point between bits 15 and 16, and is computed by the
      sender based on the reported error of the reference clock, the
      precision and drift rate of the local clock and the time the local
      clock was last set.  For statistical purposes this quantity can be
      assumed equal to the estimated or computed standard deviation, as
      described in [12].

これは最後に設定されるとき地方の時計のおよそ誤りを示す32ビットの固定小数点数です。 値は、秒に、ビット15と16の間には、断片ポイントがある状態でいて、基準クロックの報告された誤り、地方の時計の精度とドリフト項、および地方の時計が最後に設定された時に基づく送付者によって計算されます。 統計的な目的のために、[12]で説明されるように概算の、または、計算された標準偏差と等しいとこの量を思うことができます。

Mills                                                           [Page 4]

工場[4ページ]

RFC 958                                                        September
Network Time Protocol

RFC958 9月のネットワーク時間プロトコル

   Estimated Drift Rate

ドリフト項であると見積もられています。

      This is a 32-bit signed fixed-point number indicating the
      estimated drift rate of the local clock.  The value is
      dimensionless, with fraction point to the left of the high-order
      bit.  While for most purposes this value can be estimated based on
      the hardware characteristics, it is possible to compute it quite
      accurately, as described in [12].

これは地方の時計のおよそドリフト項を示す32ビットの署名している固定小数点数です。 値は断片ポイントで高位のビットの左に点です。 ハードウェアの特性に基づいてほとんどの目的のためにこの値を見積もることができますが、全く正確にそれを計算するのは可能です、[12]で説明されるように。

   Reference Clock Identifier

基準クロック識別子

      This is a 32-bit code identifying the particular reference clock.
      The interpretation of its value depends on value of Reference
      Clock Type.  In the case of a primary clock locally synchronized
      to Standard Time (type 1), the value is an ASCII string
      identifying the clock.  In the case of a secondary clock remotely
      synchronized to an Internet host via NTP (type 2), the value is
      the 32-bit Internet address of that host.  In other cases the
      value is undefined.

これは特定の基準クロックを特定する32ビットのコードです。 価値の解釈はReference Clock Typeの値に依存します。 局所的にStandard Time(1をタイプする)に連動するプライマリ時計の場合では、値は時計を特定するASCIIストリングです。 NTP(2をタイプする)を通してインターネット・ホストに離れて連動するセカンダリ時計の場合では、値はそのホストの32ビットのインターネット・アドレスです。 他の場合では、値は未定義です。

   Reference Timestamp

参照タイムスタンプ

      This is a 64-bit timestamp established by the server or client
      host as the timestamp (presumably obtained from a reference clock)
      most recently used to update the local clock.  If the local clock
      has never been synchronized, the value is zero.

これはタイムスタンプ(おそらく、基準クロックから、得る)がごく最近以前はよく地方の時計をアップデートしていたのでサーバかクライアントホストによって確立された64ビットのタイムスタンプです。 地方の時計が一度も連動したことがないなら、値はゼロです。

   Originate Timestamp

タイムスタンプを溯源してください。

      This is a 64-bit timestamp established by the client host and
      specifying the local time at which the request departed for the
      service host.  It will always have a nonzero value.

これはクライアントホストによって確立された64ビットのタイムスタンプであり、指定は要求がサービス・ホストに出発した現地時間です。 それには、非ゼロ値がいつもあるでしょう。

   Receive Timestamp

タイムスタンプを受け取ってください。

      This is a 64-bit timestamp established by the server host and
      specifying the local time at which the request arrived from the
      client host.  If no request has ever arrived from the client the
      value is zero.

これはサーバー・ホストによって確立された64ビットのタイムスタンプであり、指定は要求がクライアントホストから到着した現地時間です。 要求が全く今までにクライアントから到着したことがないなら、値はゼロです。

   Transmit Timestamp

タイムスタンプを伝えてください。

      This is a 64-bit timestamp established by the server host and
      specifying the local time at which the reply departed for the
      client host.  If no request has ever arrived from the client the
      value is zero.

これはサーバー・ホストによって確立された64ビットのタイムスタンプであり、指定は回答がクライアントホストに出発した現地時間です。 要求が全く今までにクライアントから到着したことがないなら、値はゼロです。

Mills                                                           [Page 5]

工場[5ページ]

RFC 958                                                        September
Network Time Protocol

RFC958 9月のネットワーク時間プロトコル

5.  Protocol Operation

5. プロトコル操作

   The intent of this document is to specify a standard for data
   representation and message format which can be used for a variety of
   synchronizing algorithms and filtering mechanisms.  Accordingly, the
   information in this section should be considered a guide, rather than
   a concise specification.  Nevertheless, it is expected that a
   standard Internet distributed timekeeping protocol with concisely
   specified synchronizing and filtering algorithms can be evolved from
   the information in this section.

このドキュメントの意図はさまざまな連動アルゴリズムに使用されて、メカニズムをフィルターにかけることができるデータ表現とメッセージ・フォーマットの規格を指定することです。それに従って、このセクションの情報は簡潔な仕様よりむしろガイドであると考えられるべきです。 それにもかかわらず、このセクションの情報から簡潔に指定された連動とアルゴリズムをフィルターにかける標準のインターネット分配された時間保持プロトコルを発展できると予想されます。

   5.1.  Protocol Modes

5.1. プロトコルモード

      The distinction between client and server is significant only in
      the way they interact in the request/response interchange.  The
      same NTP message format is used by each peer and contains the same
      data relative to the other peer.  In the unsymmetric mode the
      client periodically sends an NTP message to the server, which then
      responds within some interval.  Usually, the server simply
      interchanges addresses and ports, fills in the required
      information and sends the message right back. Servers operating in
      the unsymmetric mode then need retain no state information between
      client requests.

クライアントとサーバの区別は要求/応答置き換えで相互作用する方法だけで重要です。 同じNTPメッセージ・フォーマットは、各同輩によって使用されて、もう片方の同輩に比例して同じデータを含んでいます。 unsymmetricモードで、クライアントはNTPメッセージをサーバに定期的に送ります。(それは、いくつかの間隔以内にその時、反応します)。 通常、サーバは、単にアドレスとポートを交換して、必須情報に記入して、メッセージ右を返送します。 その時unsymmetricモードで作動するサーバはクライアント要求の間で州の情報を全く保有する必要はありません。

      In the symmetric mode the client/server distinction disappears.
      Each peer maintains a table with as many entries as active peers,
      each entry including a code uniquely identifying the peer (e.g.
      Internet address), together with status information and a copy of
      the Originate Timestamp and Receive Timestamp values last received
      from that peer. The peer periodically sends an NTP message to each
      of these peers including the latest copy of these timestamps.  The
      interval between sending NTP messages is managed solely by the
      sending peer and is unaffected by the arrival of NTP messages from
      other peers.

左右対称のモードで、クライアント/サーバ区別は見えなくなります。 各同輩は、同じくらい多くのエントリーが活発のテーブルが同輩、状態情報と共に同輩(例えば、インターネット・アドレス)を唯一、特定するコードと値が最後にその同輩から受けたOriginate TimestampとReceive Timestampのコピーを含む各エントリーであると主張します。 同輩は定期的にこれらのタイムスタンプの最新のコピーを含むこれらの同輩各人にNTPメッセージを送ります。 送付NTPメッセージの間隔は、唯一送付同輩によって管理されて、他の同輩からのNTPメッセージの到着で影響を受けないです。

      The mode assumed by a peer can be determined by inspection of the
      UDP Source Port and Destination Port fields (see Appendix A).  If
      both of these fields contain the NTP service-port number 123, the
      peer is operating in symmetric mode.  If they are different and
      the Destination Port field contains 123, this is a client request
      and the receiver is expected to reply in the manner described
      above.  If they are different and the Source Port field contains
      123, this is a server reply to a previously sent client request.

同輩によって想定されたモードはUDP Source PortとDestination Port分野の点検で決定できます(Appendix Aを見てください)。 これらの分野の両方がNTPサービスポートナンバー123を含んでいるなら、同輩は左右対称のモードで働いています。 それらが異なっていて、Destination Port分野が123を含んでいるなら、これはクライアント要求です、そして、受信機が上で説明された方法で返答すると予想されます。 それらが異なっていて、Source Port分野が123を含んでいるなら、これは以前に送られたクライアント要求に関するサーバ回答です。

Mills                                                           [Page 6]

工場[6ページ]

RFC 958                                                        September
Network Time Protocol

RFC958 9月のネットワーク時間プロトコル

   5.2.  Message Processing

5.2. メッセージ処理

      The significant events of interest in NTP occur usually near the
      times the NTP messages depart and arrive the client/server.  In
      order to maintain the highest accuracy it is important that the
      timestamps associated with these events be computed as close as
      possible to the hardware or software driver associated with the
      communications link and, in particular, that departure timestamps
      be recomputed for each retransmission, if used at the link level.

これらのイベントに関連しているタイムスタンプができるだけ各「再-トランスミッション」のために再計算されるコミュニケーションリンクとその特に出発タイムスタンプに関連づけられたハードウェアかソフトウェアドライバーの近くで計算されるのは、最も高い精度を維持するために重要です、リンク・レベルに使用されるなら。NTPで興味がある重大な行事は起こります。通常、NTPが通信させる回の近くでは、クライアント/サーバは、出発して、到着しています。

      An NTP message is constructed as follows (see Appendix B).  The
      source peer constructs the UDP header and the LI, Status,
      Reference Clock Type and Precision fields in the NTP data portion.
      Next, it determines the current synchronizing source and
      constructs the Type and Reference Clock Identifier fields.  From
      its timekeeping algorithm (see [12] for examples) it determines
      the Reference Timestamp, Estimated Error and Estimated Drift Rate
      fields.  Then it copies into the Receive Timestamp and Transmit
      Timestamp fields the data saved from the latest message received
      from the destination peer and, finally, computes the Originate
      Timestamp field.

NTPメッセージは以下の通り構成されます(Appendix Bを見てください)。 ソース同輩はNTPデータ部でUDPヘッダー、LI、Status、Reference Clock Type、およびPrecision分野を構成します。 次に、それは、現在の連動しているソースを決定して、TypeとReference Clock Identifier分野を構成します。 時間保持アルゴリズム(例のための[12]を見る)から、それはReference Timestamp、Estimated Error、およびEstimated Drift Rate分野を決定します。 次に、それは、目的地同輩から受け取られた最新のメッセージから保存されたデータをReceive TimestampとTransmit Timestamp分野にコピーして、最終的にOriginate Timestamp分野を計算します。

      The destination peer calculates the roundtrip delay and clock
      offset relative to the source peer as follows.  Let t1, t2 and t3
      represent the contents of the Originate Timestamp, Receive
      Timestamp and Transmit Timestamp fields and t4 the local time the
      NTP message is received.  Then the roundtrip delay d and clock
      offset c is:

目的地同輩は以下のソース同輩に比例して相殺された往復の遅れと時計について計算します。 t1、t2、およびt3にNTPメッセージが受信されている現地時間にOriginate Timestamp、Receive Timestamp、Transmit Timestamp分野、およびt4のコンテンツを表させてください。 そして、往復の遅れdと時計オフセットcは以下の通りです。

         d = (t4 - t1) - (t3 - t2)  and  c = (t2 - t1 + t3 - t4)/2 .

d=(t4--t1)--(t3--t2) そして、c=(t2--t1+t3--t4)/2。

      The implicit assumption in the above is that the one-way delay is
      statistically half the roundtrip delay and that the intrinsic
      drift rates of both the client and server clocks are small and
      close to the same value.

上記の暗黙の仮定は一方向遅れが小ささと同じ値の近くに統計的に、クライアントとサーバの両方の本質的なドリフト項が時間を計る往復の遅れとそれの半分があるということであるということです。

   5.3.  Network Considerations

5.3. ネットワーク問題

      The client/server peers have an opportunity to learn a good deal
      about each other in the NTP message exchange.  For instance, each
      can learn about the characteristics of the other clocks and select
      among them the most accurate to use as reference clock, compute
      the estimated error and drift rate and use this information to
      manage the dynamics of the subnetwork of clocks.  An outline of a
      suggested mechanism is as follows:

クライアント/サーバ同輩には、互いに関してNTP交換処理で非常に学ぶ機会があります。 例えば、それぞれが、他の時計の特性に関して学んで、基準クロックとしてそれらの中で使用に最も正確であるのを選定して、およそ誤りとドリフト項を計算して、時計のサブネットワークの力学を管理するのにこの情報を使用できます。 提案されたメカニズムのアウトラインは以下の通りです:

      Included in the table of timestamps for each peer are state

各同輩へのタイムスタンプのテーブルに含まれているのは、状態です。

Mills                                                           [Page 7]

工場[7ページ]

RFC 958                                                        September
Network Time Protocol

RFC958 9月のネットワーク時間プロトコル

      variables to indicate the precision, as well as the current
      estimated delay, offset, error and drift rate of its local clock.
      These variables are updated for each NTP message received from the
      peer, after which the estimated error is periodically recomputed
      on the basis of elapsed time and estimated drift rate.

地方の時計の精度、現在のおよそ遅れ、オフセット、誤り、およびドリフト項を示す変数。 およそ誤りが経過時間に基づいて定期的に再計算される同輩から受け取られて、ドリフト項であると見積もられていたそれぞれのNTPメッセージのためにこれらの変数をアップデートします。

      Assuming symmetric mode, a polling interval is established for
      each peer, depending upon its normal synchronization source,
      precision and intrinsic accuracy, which might be determined in
      advance or even as the result of observation.  The delay and
      clock-offset samples obtained can be filtered using
      maximum-likelihood techniques and algorithms described in [12].

左右対称のモードを仮定して、ポーリングインタバルは各同輩のために確立されます、普通の同期ソース、精度、および本質的な精度か観測の結果としてさえよって。精度はあらかじめ、決定しているかもしれません。 最大公算のテクニックと[12]で説明されたアルゴリズムを使用することで入手された遅れと時計オフセットのサンプルはフィルターにかけることができます。

      From time to time a local-clock correction is computed from the
      offset data accumulated as above, perhaps using algorithms
      described in [10] and [12].  The correction causes the local clock
      to run slightly fast or slow to the corrected time or to jump
      instantaneously to the correct time, depending on the magnitude of
      the correction.  See [5] and [11] for a discussion of local-clock
      implementation models and synchronizing algorithms.  Note that the
      expectation here is that all network clocks are maintained by
      these algorithms, so that manual intervention is not normally
      required.

時々、地方の時計修正は同じくらい上に蓄積されたオフセットデータから計算されます、恐らく[10]と[12]で説明されたアルゴリズムを使用して。 修正は、地方の時計が直っている時間までわずかに速いか、または遅い状態で稼働するか、または即座に正しい時間までジャンプすることを引き起こします、修正の大きさによって。 地方の時計実装モデルとアルゴリズムを同期させる議論のための[5]と[11]を見てください。ここでの期待がすべてのネットワーク時計がこれらのアルゴリズムによって維持されるということであることに注意してください、通常、手動の介入は必要でないように。

      As a byproduct of the above operations an estimate of local-clock
      error and drift rate can be computed.  Note that the magnitude of
      the error estimate must always be greater than that of the
      selected reference clock by at least the inherent precision of the
      local clock. It does not take a leap of imagination to see that
      the estimated error, delay or precision, or some combination of
      them, can be used as a metric for a simple min-hop-type routing
      algorithm to organize the subnetwork so as to provide the most
      accurate time to all peers and to provide automatic fallback to
      alternate sources in case of failures.

上の操作の副産物として、地方の時計誤りとドリフト項の見積りを計算できます。 誤り見積りの大きさが選択された基準クロックのものよりいつも少なくとも地方の時計の固有の精度で大きいに違いないことに注意してください。 簡単な分がタイプを飛び越しているルーティング・アルゴリズムが最も多くの正確な時間すべてに提供するためにサブネットワークを組織化するためにはメートル法のaがじっと見るときそれらのおよそ誤り、遅れ、精度、または何らかの組み合わせを使用できるのがわかって、失敗の場合にソースを交替するために自動後退を前提とするのに想像の飛躍を要しません。

      A variety of network configurations can be included in the above
      scenario.  In the case of networks supporting a broadcast
      function, for example, NTP messages can be broadcast from one or
      more server hosts and picked up by client hosts sharing the same
      cable.  Since typical networks of this type have a very low
      propagation delay, the roundtrip-delay calculation can be omitted
      and the clients need not broadcast in return.  Thus, the
      requirement to save per-peer timestamps is removed, so that the
      Receive Timestamp and Transmit Timestamp fields can be set to zero
      and the local-clock offset becomes simply the difference between
      the Originate Timestamp and the local time upon arrival.  In the
      case of long-delay satellite networks with broadcast capabilities,

上のシナリオにさまざまなネットワーク・コンフィギュレーションを含むことができます。 放送機能をサポートするネットワークの場合では、例えば、NTPメッセージを1人以上のサーバー・ホストから放送して、同じケーブルを共有しているクライアントホストは受信できます。 このタイプの典型的なネットワークには非常に低い伝播遅延があるので、往復の遅れ計算を省略できます、そして、クライアントは代わりに放送する必要はありません。 したがって、1同輩あたりのタイムスタンプを保存する要件は取り除かれます、Receive TimestampとTransmit Timestamp分野がゼロに用意ができることができて、地方の時計オフセットが到着のときに単にOriginate Timestampで現地時間の違いになるように。 放送能力がある長時間の遅延衛星ネットワークの場合で

Mills                                                           [Page 8]

工場[8ページ]

RFC 958                                                        September
Network Time Protocol

RFC958 9月のネットワーク時間プロトコル

      an accurate measure of roundtrip delay is usually available from
      the channel-scheduling algorithm, so the per-peer timestamps again
      can be avoided.

往復の遅れの正確な程度がチャンネルスケジューリングアルゴリズムから通常利用可能であるので、再び1同輩あたりのタイムスタンプを避けることができます。

   5.4.  Leap Seconds

5.4. 飛躍秒

      A standard mechanism to effect leap-second correction is not a
      part of this specification.  It is expected that the Leap
      Indicator bits would be set by hand in the primary reference
      clocks, then trickle down to all other clocks in the network,
      which would execute the correction at the specified time and reset
      the bits.

効果閏秒修正への標準のメカニズムはこの仕様の一部ではありません。 Leap Indicatorビットがプライマリ基準クロックが手ではめ込まれて、次に、指定された時に修正を実行して、ビットをリセットするだろうネットワークにおける他のすべての時計までしたたると予想されます。

Mills                                                           [Page 9]

工場[9ページ]

RFC 958                                                        September
Network Time Protocol

RFC958 9月のネットワーク時間プロトコル

6.  References

6. 参照

   1.  Lindsay, W.C., and A.V.  Kantak.  Network Synchronization of
       Random Signals.  IEEE Trans.  Comm.  COM-28, 8 (August 1980),
       1260-1266.

1. リンゼー、W.C.、およびA.V.Kantak。 不規則信号の同期をネットワークでつないでください。 IEEE、移- Comm。 COM-28、8(1980年8月)、1260-1266。

   2.  Mills, D.L.  Time Synchronization in DCNET Hosts.  DARPA Internet
       Project Report IEN-173, COMSAT Laboratories, February 1981.

2. 工場、DCNETホストのD.L.時間同期化。 1981年2月のDARPAインターネットプロジェクト報告IEN-173、コムサット研究所。

   3.  Mills, D.L.  DCNET Internet Clock Service.  DARPA Network Working
       Group Report RFC-778, COMSAT Laboratories, April 1981.

3. 工場、D.L.DCNETインターネットクロック・サービス。 DARPAはワーキンググループレポートRFC-778、コムサット研究所、1981年4月をネットワークでつなぎます。

   4.  Mills, D.L.  Internet Delay Experiments.  DARPA Network Working
       Group Report RFC-889, M/A-COM Linkabit, December 1983.

4. 工場、D.L.インターネット遅れ実験。 DARPAは1983年12月に1COM Linkabitである状態でワーキンググループレポートRFC-889、M/をネットワークでつなぎます。

   5.  Mills, D.L.  DCN Local-Network Protocols.  DARPA Network Working
       Group Report RFC-891, M/A-COM Linkabit, December 1983.

5. 工場、D.L.DCN企業内情報通信網プロトコル。 DARPAは1983年12月に1COM Linkabitである状態でワーキンググループレポートRFC-891、M/をネットワークでつなぎます。

   6.  Postel, J.  Internet Control Message Protocol.  DARPA Network
       Working Group Report RFC-792, USC Information Sciences Institute,
       September 1981.

6. ポステル、J.インターネット・コントロール・メッセージ・プロトコル。 DARPAはワーキンググループレポートRFC-792、科学が1981年9月に設けるUSC情報をネットワークでつなぎます。

   7.  Postel, J.  Time Protocol.  DARPA Network Working Group Report
       RFC-868, USC Information Sciences Institute, May 1983.

7. ポステル、J.時間プロトコル。 DARPAネットワークワーキンググループレポートRFC-868(科学が設けるUSC情報)は1983がそうするかもしれません。

   8.  Postel, J.  Daytime Protocol.  DARPA Network Working Group Report
       RFC-867, USC Information Sciences Institute, May 1983.

8. ポステル、J.昼間のプロトコル。 DARPAネットワークワーキンググループレポートRFC-867(科学が設けるUSC情報)は1983がそうするかもしれません。

   9.  Su, Z.  A Specification of the Internet Protocol (IP) Timestamp
       Option.  DARPA Network Working Group Report RFC-781.  SRI
       International, May 1981.

9. Z. Su、インターネットプロトコル(IP)タイムスタンプオプションの仕様。 DARPAはワーキンググループレポートRFC-781をネットワークでつなぎます。 1981年5月のSRIインターナショナル。

   10. Marzullo, K., and S.  Owicki.  Maintaining the Time in a
       Distributed System.  ACM Operating Systems Review 19, 3 (July
       1985), 44-54.

10. Marzullo、K.、およびS.Owicki。 分散システムで時間を維持します。 ACMオペレーティングシステムレビュー19、3(1985年7月)、44-54。

   11. Mills, D.L.  Experiments in Network Clock Synchronization.  DARPA
       Network Working Group Report RFC-957, M/A-COM Linkabit, August
       1985.

11. 工場、L.が実験するD.は時計同期をネットワークでつなぎます。 DARPAは1985年8月に1COM Linkabitである状態でワーキンググループレポートRFC-957、M/をネットワークでつなぎます。

   12. Mills, D.L.  Algorithms for Synchronizing Network Clocks.  DARPA
       Network Working Group Report RFC-956, M/A-COM Linkabit, September
       1985.

12. 工場、ネットワーク時計を連動させるためのD.L.アルゴリズム。 DARPAは1985年9月に1COM Linkabitである状態でワーキンググループレポートRFC-956、M/をネットワークでつなぎます。

   13. Postel, J.  User Datagram Protocol.  DARPA Network Working Group
       Report RFC-768, USC Information Sciences Institute, August 1980.

13. ポステル、J.ユーザー・データグラム・プロトコル。 DARPAはワーキンググループレポートRFC-768、科学が1980年8月に設けるUSC情報をネットワークでつなぎます。

Mills                                                          [Page 10]

工場[10ページ]

RFC 958                                                        September
Network Time Protocol

RFC958 9月のネットワーク時間プロトコル

Appendix A.  UDP Header Format

付録A.UDPヘッダー形式

   An NTP packet consists of the UDP header followed by the NTP data
   portion.  The format of the UDP header and the interpretation of its
   fields are described in [13] and are not part of the NTP
   specification.  They are shown below for completeness.

NTPパケットはNTPデータ部があとに続いたUDPヘッダーから成ります。 UDPヘッダーの形式と分野の解釈は、[13]で説明されて、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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Source Port          |       Destination Port        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Length             |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースポート| 仕向港| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Source Port

ソースポート

      UDP source port number. In the case of unsymmetric mode and a
      client request this field is assigned by the client host, while
      for a server reply it is copied from the Destination Port field of
      the client request.  In the case of symmetric mode, both the
      Source Port and Destination Port fields are assigned the NTP
      service-port number 123.

UDPソースポート番号。 unsymmetricモードとクライアントの場合では、この分野がクライアントホストによって割り当てられるよう要求してください、それはクライアント要求のDestination Port分野からサーバ回答においてコピーされますが。 左右対称のモードの場合では、NTPサービスポートナンバー123はSource PortとDestination Port分野の両方に割り当てられます。

   Destination Port

仕向港

      UDP destination port number. In the case of unsymmetric mode and a
      client request this field is assigned the NTP service-port number
      123, while for a server reply it is copied form the Source Port
      field of the client request.  In the case of symmetric mode, both
      the Source Port and Destination Port fields are assigned the NTP
      service-port number 123.

UDP目的地ポートナンバー。 unsymmetricモードとクライアントの場合では、NTPサービスポートナンバー123がこの分野に割り当てられるよう要求してください、そして、それがサーバ回答においてコピーされている間、クライアント要求のSource Port分野を形成してください。 左右対称のモードの場合では、NTPサービスポートナンバー123はSource PortとDestination Port分野の両方に割り当てられます。

   Length

長さ

      Length of the request or reply, including UDP header, in octets.

八重奏にUDPヘッダーを含む要求か回答の長さ。

   Checksum

チェックサム

      Standard UDP checksum.

標準のUDPチェックサム。

Mills                                                          [Page 11]

工場[11ページ]

RFC 958                                                        September
Network Time Protocol

RFC958 9月のネットワーク時間プロトコル

Appendix B.  NTP Data Format

付録B.NTPデータの形式

   The format of the NTP data portion, which immediately follows the UDP
   header, is shown below along with a description of its fields.

NTPデータ部の書式は分野の記述と共に以下に示されます。(データ部はすぐに、UDPヘッダーに続きます)。

    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 |   Status  |      Type     |           Precision           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Estimated Error                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Estimated Drift Rate                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Reference Clock Identifier                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                 Reference Timestamp (64 bits)                 |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                 Originate Timestamp (64 bits)                 |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                  Receive Timestamp (64 bits)                  |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                  Transmit Timestamp (64 bits)                 |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |李| 状態| タイプ| 精度| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 誤りであると見積もられています。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ドリフト項であると見積もられています。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 基準クロック識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 参照Timestamp(64ビット)| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Timestamp(64ビット)を溯源してください。| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Timestamp(64ビット)を受けてください。| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Timestamp(64ビット)を伝えてください。| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Leap Indicator (LI)

インディケータを跳ねさせてください。(李)

      Code warning of impending leap-second to be inserted at the end of
      the last day of the current month. Bits are coded as follows:

閏秒を迫らせるのが現在の月の最後の日の終わりに挿入されるという警告をコード化してください。 ビットは以下の通りコード化されます:

         00      no warning
         01      +1 second (following minute has 61 seconds)
         10      -1 second (following minute has 59 seconds)
         11      reserved for future use

00 01+1第2(次の分には、61秒があります)10 -1 2(次の分には、59秒がある)番目の11が今後の使用のために予約した警告しないこと

   Status

状態

      Code indicating status of local clock. Values are defined as
      follows:

地方の時計の表示状態をコード化してください。 値は以下の通り定義されます:

Mills                                                          [Page 12]

工場[12ページ]

RFC 958                                                        September
Network Time Protocol

RFC958 9月のネットワーク時間プロトコル

         0       clock operating correctly
         1       carrier loss
         2       synch loss
         3       format error
         4       interface (Type 1) or link (Type 2) failure
         (additional codes reserved for future use)

正しく1つのキャリヤー損失2同時性損失3形式誤り4インタフェース(1をタイプする)かリンク(2をタイプする)の故障を操作する0時計(今後の使用のために予約された追加コード)

   Reference Clock Type
   (Type)

基準クロックタイプ(タイプ)

      Code identifying the type of reference clock. Values are defined
      as follows:

基準クロックのタイプを特定するコード。 値は以下の通り定義されます:

         0       unspecified
         1       primary reference (e.g. radio clock)
         2       secondary reference using an Internet host via NTP
         3       secondary reference using some other host or protocol
         4       eyeball-and-wristwatch
         (additional codes reserved for future use)

0 プロトコル4のある他のホストを使用することでNTP3のセカンダリ参照でインターネット・ホストを使用する1つの不特定のプライマリ参照(例えば、ラジオ時計)の2のセカンダリ参照か眼球と腕時計(今後の使用のために予約された追加コード)

   Precision

精度

      Signed integer in the range +32 to -32 indicating the precision of
      the local clock, in seconds to the nearest power of two.

地方の時計の精度を示す-32への範囲+32、秒の整数であると2の最も近いパワーに署名されます。

   Estimated Error

誤りであると見積もられています。

      Fixed-point number indicating the estimated error of the local
      clock at the time last set, in seconds with fraction point between
      bits 15 and 16.

地方の時計のおよそ誤りを示す固定小数点数が最後に当時、セットしました、ビット15と16の間には、断片ポイントがある秒に。

   Estimated Drift Rate

ドリフト項であると見積もられています。

      Signed fixed-point number indicating the estimated drift rate of
      the local clock, in dimensionless units with fraction point to the
      left of the high-order bit.

署名している固定小数点数が地方の時計のおよそドリフト項を示して、断片がある点のユニットでは、高位のビットの左を示してください。

   Reference Clock
   Identifier

基準クロック識別子

      Code identifying the particular reference clock. In the case of
      type 1 (primary reference), this is a left-justified, zero-filled
      ASCII string identifying the clock, for example:

特定の基準クロックを特定するコード。 タイプ1(プライマリ参照)の場合では、これは例えば時計を特定する左で正当で、無いっぱいにされたASCIIストリングです:

         WWVB    WWVB radio clock (60 KHz)

WWVB WWVBラジオ時計(60KHz)

Mills                                                          [Page 13]

工場[13ページ]

RFC 958                                                        September
Network Time Protocol

RFC958 9月のネットワーク時間プロトコル

         GOES    GOES satellite clock (468 HMz)
         WWV     WWV radio clock (2.5/5/10/15/20 MHz)
         (and others as necessary)

ゴエスゴエス衛星時計(468HMz)WWV WWVラジオ時計(2.5/5/10/15/20MHz)(そして、必要に応じて他のもの)

      In the case of type 2 (secondary reference) this is the 32-bit
      Internet address of the reference host. In other cases this field
      is reserved for future use and should be set to zero.

タイプ2(セカンダリ参照)の場合では、これは参照ホストの32ビットのインターネット・アドレスです。 他の場合では、この分野は、今後の使用のために予約されて、ゼロに設定されるべきです。

   Reference Timestamp

参照タイムスタンプ

      Local time at which the local clock was last set or corrected.

最後に設定されたか、または修正されて、地方が時間を計るものでは、現地時間です。

   Originate Timestamp

タイムスタンプを溯源してください。

      Local time at which the request departed the client host for the
      service host.

要求がサービス・ホストのためにクライアントホストを去った現地時間。

   Receive Timestamp

タイムスタンプを受け取ってください。

      Local time at which the request arrived at the service host.

要求がサービス・ホストに到着した現地時間。

   Transmit Timestamp

タイムスタンプを伝えてください。

      Local time at which the reply departed the service host for the
      client host.

回答がクライアントホストのためにサービス・ホストを去った現地時間。

Mills                                                          [Page 14]

工場[14ページ]