RFC1769 日本語訳

Network Working Group                                           D. Mills
Request for Comments: 1769                        University of Delaware
Obsoletes: 1361                                               March 1995
Category: Informational

工場がコメントのために要求するワーキンググループD.をネットワークでつないでください: 1769 デラウエア大学は以下を時代遅れにします。 1361 1995年3月のカテゴリ: 情報

                  Simple Network Time Protocol (SNTP)

簡単なネットワーク時間プロトコル(SNTP)

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Abstract

要約

   This memorandum describes the Simple Network Time Protocol (SNTP),
   which is an adaptation of the Network Time Protocol (NTP) used to
   synchronize computer clocks in the Internet. SNTP can be used when
   the ultimate performance of the full NTP implementation described in
   RFC-1305 is not needed or justified. It can operate in both unicast
   modes (point to point) and broadcast modes (point to multipoint). It
   can also operate in IP multicast mode where this service is
   available. SNTP involves no change to the current or previous NTP
   specification versions or known implementations, but rather a
   clarification of certain design features of NTP which allow operation
   in a simple, stateless remote-procedure call (RPC) mode with accuracy
   and reliability expectations similar to the UDP/TIME protocol
   described in RFC-868.

このメモはSimple Network Timeプロトコル(SNTP)について説明します。(それは、インターネットでコンピュータ時計を連動させるのに使用されるNetwork Timeプロトコル(NTP)の適合です)。 RFC-1305で説明された完全なNTP実装の究極の性能が必要でない、または正当化されないとき、SNTPを使用できます。 それはユニキャストモード(ポイント・ツー・ポイント)と放送モードの両方で作動できます(多点を示してください)。 また、それはこのサービスが利用可能であるIPマルチキャストモードで作動できます。 SNTPは現在か前のNTP仕様バージョンか知られている実装への変化に全くかかわらないで、むしろUDP/タイム誌プロトコルと同様の期待がRFC-868で説明した精度と信頼性で簡単で、状態がない遠隔手続き呼び出し(RPC)モードにおける操作を許すNTPのある設計上の特徴の明確化にかかわります。

   This memorandum obsoletes RFC-1361 of the same title. Its purpose is
   to explain the protocol model for operation in broadcast mode, to
   provide additional clarification in some places and to correct a few
   typographical errors. A working knowledge of the NTP Version 3
   specification RFC-1305 is not required for an implementation of SNTP.
   Distribution of this memorandum is unlimited.

このメモは同じタイトルのRFC-1361を時代遅れにします。 目的は、放送モードにおける操作のためにプロトコルモデルについて説明して、追加明確化を所々提供して、いくつかの誤字を修正することです。 NTPバージョン3仕様RFC-1305の実用的な知識はSNTPの実装に必要ではありません。 このメモの分配は無制限です。

1. Introduction

1. 序論

   The Network Time Protocol (NTP) specified in RFC-1305 [MIL92] is used
   to synchronize computer clocks in the global Internet. It provides
   comprehensive mechanisms to access national time and frequency
   dissemination services, organize the time-synchronization subnet and
   adjust the local clock in each participating subnet peer. In most
   places of the Internet of today, NTP provides accuracies of 1-50 ms,
   depending on the characteristics of the synchronization source and
   network paths.

RFC-1305[MIL92]で指定されたNetwork Timeプロトコル(NTP)は、世界的なインターネットでコンピュータ時計を連動させるのに使用されます。 それは、それぞれの参加しているサブネット同輩で国家の時間と頻度普及のサービスにアクセスして、時間同期化サブネットを組織化して、地方の時計を調整するために包括的メカニズムを提供します。 今日のインターネットのほとんどの場所に、NTPは1-50 msの精度を提供します、同期ソースとネットワーク経路の特性によって。

Mills                                                           [Page 1]

RFC 1769                          SNTP                       March 1995

1995年のSNTP行進のときにRFC1769を製粉します[1ページ]。

   RFC-1305 specifies the NTP protocol machine in terms of events,
   states, transition functions and actions and, in addition, optional
   algorithms to improve the timekeeping quality and mitigate among
   several, possibly faulty, synchronization sources. To achieve
   accuracies in the low milliseconds over paths spanning major portions
   of the Internet of today, these intricate algorithms, or their
   functional equivalents, are necessary. However, in many cases
   accuracies of this order are not required and something less, perhaps
   in the order of large fractions of the second, is sufficient. In such
   cases simpler protocols such as the Time Protocol [POS83], have been
   used for this purpose. These protocols usually involve an RPC
   exchange where the client requests the time of day and the server
   returns it in seconds past some known reference epoch.

RFC-1305は、時間保持品質を改良して、数個の、そして、ことによると不完全な同期の中でソースを緩和するためにイベント、州、変遷機能、動作、およびさらに、任意のアルゴリズムでNTPプロトコルマシンを指定します。 安値における精度を達成するために、今日のインターネット、これらの複雑なアルゴリズム、またはそれらの機能的な同等物の主要部にかかる経路の上のミリセカンドが必要です。 しかしながら中、恐らく秒の大きい何分の一の注文では、このオーダーの多くのケース精度は必要でなく、何かより少ないものは十分です。 Timeプロトコル[POS83]などのそのような場合より簡単なプロトコルはこのために使用されています。 クライアントが時刻を要求するところで通常、これらのプロトコルはRPC交換にかかわります、そして、サーバは秒にいつかの知られている参照時代を過ぎてそれを返します。

   NTP is designed for use by clients and servers with a wide range of
   capabilities and over a wide range of network delays and jitter
   characteristics. Most users of the Internet NTP synchronization
   subnet of today use a software package including the full suite of
   NTP options and algorithms, which are relatively complex, real-time
   applications. While the software has been ported to a wide variety of
   hardware platforms ranging from supercomputers to personal computers,
   its sheer size and complexity is not appropriate for many
   applications. Accordingly, it is useful to explore alternative access
   strategies using far simpler software appropriate for less stringent
   accuracy expectations.

NTPは使用のためにクライアントとサーバによってさまざまなさまざまな能力とネットワーク遅延とジターの特性の上について設計されます。 今日のインターネットNTP同期サブネットのほとんどのユーザが比較的複雑なNTPオプションとアルゴリズムの完全なスイートを含むソフトウェアパッケージを使用します、リアルタイムのアプリケーション。 スーパーコンピュータからパーソナルコンピュータまで及ぶさまざまなハードウェアプラットホームにソフトウェアを移植しましたが、多くのアプリケーションには、その全くのサイズと複雑さは適切ではありません。 それに従って、それほど厳しくない精度期待に、適切なはるかに簡単なソフトウェアを使用する代替のアクセス戦略を探るのは役に立ちます。

   This memorandum describes the Simple Network Time Protocol (SNTP),
   which is a simplified access strategy for servers and clients using
   NTP as now specified and deployed in the Internet. There are no
   changes to the protocol or implementations now running or likely to
   be implemented in the near future. The access paradigm is identical
   to the UDP/TIME Protocol and, in fact, it should be easily possible
   to adapt a UDP/TIME client implementation, say for a personal
   computer, to operate using SNTP. Moreover, SNTP is also designed to
   operate in a dedicated server configuration including an integrated
   radio clock. With careful design and control of the various latencies
   in the system, which is practical in a dedicated design, it is
   possible to deliver time accurate to the order of microseconds.

このメモはSimple Network Timeプロトコル(SNTP)について説明します。(それは、インターネットで現在指定されているとしてNTPを使用して、配布されたサーバとクライアントのための簡易型のアクセス戦略です)。 今、稼働しそうであるか、または近い将来実装しそうなプロトコルか実装への変化が全くありません。 アクセスパラダイムはUDP/タイム誌プロトコルと同じです、そして、事実上、たとえば、パーソナルコンピュータのためにUDP/タイム誌クライアント実装を適合させて、作動するのは、SNTPを使用することで容易に可能であるべきです。 そのうえ、また、SNTPは、統合ラジオ時計を含む専用サーバ構成で作動するように設計されています。 システムにおける、様々な潜在の慎重なデザインとコントロールでは、マイクロセカンドの注文に正確な時間を提供するのは可能です。(システムはひたむきなデザインで実用的です)。

   It is strongly recommended that SNTP be used only at the extremities
   of the synchronization subnet. SNTP clients should operate only at
   the leaves (highest stratum) of the subnet and in configurations
   where no NTP or SNTP client is dependent on another SNTP client for
   synchronization. SNTP servers should operate only at the root
   (stratum 1) of the subnet and then only in configurations where no
   other source of synchronization other than a reliable radio clock is
   available. The full degree of reliability ordinarily expected of
   primary servers is possible only using the redundant sources, diverse

SNTPが単に同期サブネットの窮境に使用されることが強く勧められます。 同期において、NTPかどんなSNTPクライアントも別のSNTPクライアントに依存していないところでSNTPクライアントはサブネットの葉(最も高い層)においてだけ構成で働くべきです。 高信頼のラジオ時計以外の同期の他のどんな源も利用可能でないところでSNTPサーバはサブネットの根(層1)においてそして、構成だけで作動するべきです。 通常、プライマリサーバに予想された完全な度合いの信頼性は、余分なソースと、さまざまを使用するだけであることで可能です。

Mills                                                           [Page 2]

RFC 1769                          SNTP                       March 1995

1995年のSNTP行進のときにRFC1769を製粉します[2ページ]。

   subnet paths and crafted algorithms of a full NTP implementation.
   This extends to the primary source of synchronization itself in the
   form of multiple radio clocks and backup paths to other primary
   servers should the radio clock fail or deliver incorrect time.
   Therefore, the use of SNTP rather than NTP in primary servers should
   be carefully considered.

完全なNTP実装のサブネット経路と作られたアルゴリズム。 ラジオ時計が不正確な時間を失敗するか、または提供するなら、これは複数のラジオ時計とバックアップ道の形で他のプライマリサーバに同期自体の一次資料に達します。 したがって、プライマリサーバのNTPよりむしろSNTPの使用は慎重に考えられるべきです。

2. Operating Modes and Addressing

2. オペレーティング・モードとアドレシング

   Like NTP, SNTP can operate in either unicast (point to point) or
   broadcast (point to multipoint) modes. A unicast client sends a
   request to a server and expects a reply from which it can determine
   the time and, optionally, the roundtrip delay and local clock offset
   relative to the server. A broadcast server periodically sends a
   message to a designated IP broadcast address or IP multicast group
   address and ordinarily expects no requests from clients, while a
   broadcast client listens on this address and ordinarily sends no
   requests to servers. Some broadcast servers may elect to respond to
   client requests as well as send unsolicited broadcast messages, while
   some broadcast clients may elect to send requests only in order to
   determine the network propagation delay between the server and
   client.

NTPのように、SNTPはユニキャスト(ポイント・ツー・ポイント)か放送(多点を示す)モードのどちらかで作動できます。 ユニキャストクライアントは、要求をサーバに送って、それが時間を決定できる回答を予想します、そして、任意に、往復の遅れと地方の時計はサーバに比例して相殺されます。放送サーバは、定期的に指定されたIP放送演説かIPマルチキャストグループアドレスにメッセージを送って、通常、クライアントからの要求を全く予想しません、放送クライアントは、このアドレスで聴いて、通常要求を全くサーバに送りませんが。 いくつかの放送サーバが、クライアント要求に応じて、求められていない同報メッセージを送るのを選ぶかもしれません、何人かの放送クライアントが、サーバとクライアントの間のネットワーク伝播遅延を決定するために要求だけを送るのを選ぶかもしれませんが。

   In unicast mode the client and server IP addresses are assigned
   following the usual conventions. In broadcast mode the server uses a
   designated IP broadcast address or IP multicast group address,
   together with a designated media-access broadcast address, and the
   client listens on these addresses. For this purpose, an IP broadcast
   address has scope limited to a single IP subnet, since routers do not
   propagate IP broadcast datagrams. In the case of Ethernets, for
   example, the Ethernet media-access broadcast address (all ones) is
   used with an IP address consisting of the IP subnet number in the net
   field and all ones in the host field.

ユニキャストモードで、普通のコンベンションに続いて、IPが演説するクライアントとサーバは選任されます。 放送モードで、サーバは指定されたIP放送演説かIPマルチキャストグループアドレスを使用します、指定されたメディアアクセス放送演説と共に、そして、クライアントがこれらのアドレスで聴きます。 このために、IP放送演説で範囲をただ一つのIPサブネットに制限します、ルータがIPブロードキャスト・データグラムを伝播しないので。Ethernetsの場合では、例えば、イーサネットメディアアクセス放送演説(すべてのもの)はネットの分野のIPサブネット番号とホスト分野のすべてのものから成るIPアドレスと共に使用されます。

   On the other hand, an IP multicast group address has scope extending
   to potentially the entire Internet. The actual scope, group
   membership and routing are determined by the Internet Group
   Management Protocol (IGMP) [DEE89] and various routing protocols,
   which are beyond the scope of this document. In the case of
   Ethernets, for example, the Ethernet media-access broadcast address
   (all ones) is used with the assigned IP multicast group address of
   224.0.1.1. Other than the IP addressing conventions and IGMP, there
   is no difference in server operations with either the IP broadcast
   address or IP multicast group address.

他方では、IPマルチキャストグループアドレスで、範囲は潜在的に全体のインターネットに広がります。 実際の範囲、グループ会員資格、およびルーティングは、インターネットGroup Managementプロトコルで断固とした(IGMP)[DEE89]と様々なルーティング・プロトコルです。(そのルーティング・プロトコルはこのドキュメントの範囲にあります)。 Ethernetsの場合では、例えば、イーサネットメディアアクセス放送演説(すべてのもの)は.1がIPマルチキャストグループが.1に224.0を扱う割り当てと共に使用されます。 コンベンションとIGMPに演説するIP以外に、IP放送演説かIPマルチキャストグループが扱うどちらかがあるサーバ操作の違いが全くありません。

   Broadcast clients listen on the designated media-access broadcast
   address, such as all ones in the case of Ethernets. In the case of IP
   broadcast addresses, no further provisions are necessary. In the case

放送クライアントはEthernetsの場合におけるすべてのものなどの指定されたメディアアクセス放送演説で聴きます。 IP放送演説の場合では、さらなるどんな条項も必要ではありません。 場合で

Mills                                                           [Page 3]

RFC 1769                          SNTP                       March 1995

1995年のSNTP行進のときにRFC1769を製粉します[3ページ]。

   of IP multicast group addresses, the host may need to implement IGMP
   in order that the local router intercepts messages to the 224.0.1.1
   multicast group. These considerations are beyond the scope of this
   document.

IPマルチキャストグループアドレスでは、ホストが、ローカルルータが224.0.1.1マルチキャストグループにメッセージを傍受するようにIGMPを実装する必要があるかもしれません。 これらの問題はこのドキュメントの範囲を超えています。

   In the case of SNTP as specified herein, there is a very real
   vulnerability that SNTP multicast clients can be disrupted by
   misbehaving or hostile SNTP or NTP multicast servers elsewhere in the
   Internet, since at present all such servers use the same IP multicast
   group address 224.0.1.1. Where necessary, access control based on the
   server source address can be used to select only those servers known
   to and trusted by the client. Alternatively, by convention and
   informal agreement, all NTP multicast servers now include an MD5-
   encrypted message digest in every message, so that clients can
   determine if the message is authentic and not modified in transit. It
   is in principle possible that SNTP clients could implement the
   necessary encryption and key-distribution schemes, but this is
   considered not likely in the simple systems for which SNTP is
   intended.

指定されるとしてのSNTPの場合には、ここに、SNTPマルチキャストクライアントがふらちな事をしながら混乱させられることができる非常に本当の脆弱性、敵軍のSNTPまたはNTPマルチキャストサーバがインターネットのほかの場所にあります、現在のところそのようなすべてのサーバが同じIPマルチキャストグループアドレスを使用するので224.0、.1、.1 必要であるところでは、クライアントによって知られていて信じられた状態でそれらのサーバだけを選択するのにサーバソースアドレスに基づくアクセスコントロールは使用できます。 あるいはまた、コンベンションと非公式協定で、すべてのNTPマルチキャストサーバが現在あらゆるメッセージにMD5暗号化メッセージダイジェストを含んでいます、クライアントが、メッセージが正統でトランジットで変更されていないかどうかと決心できるように。 SNTPクライアントが、必要な暗号化と主要な分配が体系であると実装することができたのが、原則として可能ですが、これはSNTPが意図する簡単なシステムでありそうでないと考えられます。

   While not integral to the SNTP specification, it is intended that IP
   broadcast addresses will be used primarily in IP subnets and LAN
   segments including a fully functional NTP server with a number of
   SNTP clients in the same subnet, while IP multicast group addresses
   will be used only in special cases engineered for the purpose. In
   particular, IP multicast group addresses should be used in SNTP
   servers only if the server implements the NTP authentication scheme
   described in RFC-1305, including support for the MD5 message-digest
   algorithm.

SNTP仕様に不可欠でない間、IP放送演説が主として同じサブネットに多くのSNTPクライアントとの完全に機能的なNTPサーバを含むIPサブネットとLANセグメントに使用されることを意図します、IPマルチキャストグループアドレスは目的のために設計された特別な場合だけに使用されるでしょうが。 サーバがRFC-1305で説明されたNTP認証体系を実装する場合にだけ、特に、IPマルチキャストグループアドレスはSNTPサーバに使用されるべきです、MD5メッセージダイジェストアルゴリズムのサポートを含んでいて。

3. NTP Timestamp Format

3. NTPタイムスタンプ形式

   SNTP uses the standard NTP timestamp format described in RFC-1305 and
   previous versions of that document. In conformance with standard
   Internet practice, NTP data are specified as integer or fixed-point
   quantities, with bits numbered in big-endian fashion from 0 starting
   at the left, or high-order, position. Unless specified otherwise, all
   quantities are unsigned and may occupy the full field width with an
   implied 0 preceding bit 0.

SNTPはRFC-1305とそのドキュメントの旧バージョンで説明された標準のNTPタイムスタンプ形式を使用します。 一般的なインターネット習慣に伴う順応では、NTPデータは整数か定点量として指定されます、左の、または、高いオーダーの位置の0始めからのビッグエンディアンファッションでビットが付番されている状態で。 別の方法で指定されない場合、すべての量が、未署名であり、ビット0に先行する暗示している0に全分野に及ぶ調査幅を占領するかもしれません。

   Since NTP timestamps are cherished data and, in fact, represent the
   main product of the protocol, a special timestamp format has been
   established. NTP timestamps are represented as a 64-bit unsigned
   fixed-point number, in seconds relative to 0h on 1 January 1900. The
   integer part is in the first 32 bits and the fraction part in the
   last 32 bits. In the fraction part, the non-significant low-order
   bits should be set to 0. This format allows convenient multiple-
   precision arithmetic and conversion to UDP/TIME representation

NTPタイムスタンプが大事にされたデータであり、事実上プロトコルの主産物を表すので、特別なタイムスタンプ形式は確立されました。 NTPタイムスタンプは秒に64ビットの未署名の固定小数点数として1900年1月1日の0hに比例して表されます。 最初の32ビットと最後の32ビットの小数部には整数部があります。 小数部では、非重要な下位のビットは0に設定されるべきです。 この形式は便利な複数の精度演算と変換をUDP/タイム誌の表現に許します。

Mills                                                           [Page 4]

RFC 1769                          SNTP                       March 1995

1995年のSNTP行進のときにRFC1769を製粉します[4ページ]。

   (seconds), but does complicate the conversion to ICMP Timestamp
   message representation (milliseconds). The precision of this
   representation is about 200 picoseconds, which should be adequate for
   even the most exotic requirements.

ICMP Timestampメッセージ表現(ミリセカンド)に変換を複雑にするのを除いた(秒。) この表現の精度はおよそ200のピコセコンドです。(最もエキゾチックな要件にさえ、そのピコセコンドは適切であるべきです)。

                           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                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Seconds Fraction (0-padded)                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 秒| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 秒断片(0でそっと歩いている)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Note that, since some time in 1968 the most significant bit (bit 0 of
   the integer part) has been set and that the 64-bit field will
   overflow some time in 2036. Should NTP or SNTP be in use in 2036,
   some external means will be necessary to qualify time relative to
   1900 and time relative to 2036 (and other multiples of 136 years).
   Timestamped data requiring such qualification will be so precious
   that appropriate means should be readily available. There will exist
   a 200-picosecond interval, henceforth ignored, every 136 years when
   the 64-bit field will be 0, which by convention is interpreted as an
   invalid or unavailable timestamp.

1968年に、最も重要なビット(整数部のビット0)が設定されて、64ビットの分野が2036年にいつかあふれるいつかの時間以来それに注意してください。 NTPかSNTPが2036年に使用中であるなら、いくつかの外部の手段が、2036(そして、136年の他の倍数)に比例して1900に比例した時間と時間に資格を与えるために必要になるでしょう。 そのような資格を必要とするTimestampedデータが非常に貴重になるので、適切な手段は容易に利用可能であるべきです。 64ビットの分野が0になるときの今後は136年毎に無視された無効の、または、入手できないタイムスタンプとしてコンベンションによって解釈される200ピコセコンドの間隔は存在するでしょう。

4. NTP Message Format

4. NTPメッセージ・フォーマット

   Both NTP and SNTP are clients of the User Datagram Protocol (UDP)
   [POS80], which itself is a client of the Internet Protocol (IP)
   [DAR81]. The structure of the IP and UDP headers is described in the
   cited specification documents and will not be described further here.
   The UDP port number assigned to NTP is 123, which should be used in
   both the Source Port and Destination Port fields in the UDP header.
   The remaining UDP header fields should be set as described in the
   specification.

NTPとSNTPの両方がユーザー・データグラム・プロトコル(UDP)[POS80]のクライアントです。(それ自体で、それは、インターネットプロトコル(IP)[DAR81]のクライアントです)。 IPとUDPヘッダーの構造は、引用された仕様ドキュメントで説明されて、ここでさらに説明されないでしょう。 NTPに割り当てられたUDPポートナンバーは123です。(その123はUDPヘッダーでSource PortとDestination Port分野の両方で使用されるべきです)。 残っているUDPヘッダーフィールドは仕様で説明されるように設定されるべきです。

Mills                                                           [Page 5]

RFC 1769                          SNTP                       March 1995

1995年のSNTP行進のときにRFC1769を製粉します[5ページ]。

   Following is a description of the SNTP message format, which follows
   the IP and UDP headers. The SNTP message format is identical to the
   NTP format described in RFC-1305, with the exception that some of the
   data fields are "canned," that is, initialized to pre-specified
   values. The format of the NTP message is shown below.

以下に、SNTPメッセージ・フォーマットの記述があります。(メッセージ・フォーマットはIPとUDPヘッダーに続きます)。 形式がNTP形式と同じであるというSNTPメッセージは、例外があるRFC-1305でデータ・フィールドのいくつかがプレ規定値に「缶詰」で、すなわち、初期化されていると説明しました。 NTPメッセージの書式は以下に示されます。

                           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 Identifier                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                   Reference Timestamp (64)                    |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                   Originate Timestamp (64)                    |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                    Receive Timestamp (64)                     |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                    Transmit Timestamp (64)                    |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                                                               |
      |                  Authenticator (optional) (96)                |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |李| VN|モード| 層| 投票| 精度| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 根の遅れ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 根のディアスポラ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 参照識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 参照タイムスタンプ(64)| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | タイムスタンプ(64)を溯源してください。| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | タイムスタンプ(64)を受け取ってください。| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | タイムスタンプ(64)を伝えてください。| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | 固有識別文字(任意の)(96)| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   As described in the next section, in SNTP most of these fields are
   initialized with pre-specified data. For completeness, the function
   of each field is briefly summarized below.

次のセクションで説明されるSNTPでは、これらの分野の大部分はあらかじめ指定されたデータで初期化されます。 完全性において、それぞれの分野の関数は以下へ簡潔にまとめられます。

Mills                                                           [Page 6]

RFC 1769                          SNTP                       March 1995

1995年のSNTP行進のときにRFC1769を製粉します[6ページ]。

   Leap Indicator (LI): This is a two-bit code warning of an impending
   leap second to be inserted/deleted in the last minute of the current
   day, with bit 0 and bit 1, respectively, coded as follows:

インディケータ(LI)を跳ねさせてください: これは差し迫っている閏秒が現在の日の土壇場で挿入されるか、または削除されるという安っぽいコード警告です、以下の通りそれぞれコード化されたビット0とビット1で:

      LI       Value     Meaning
      -------------------------------------------------------
      00       0         no warning
      01       1         last minute has 61 seconds
      10       2         last minute has 59 seconds)
      11       3         alarm condition (clock not synchronized)

LI値の意味------------------------------------------------------- 0ノー、が10 2土壇場が59秒持っている61秒を持っていると01 1土壇場に警告する人00) 11 3アラーム状態(連動しない時計)

   Version Number (VN): This is a three-bit integer indicating the NTP
   version number, currently 3.

バージョン数の(vn): これはNTPバージョン番号、現在の3を示す3ビットの整数です。

   Mode: This is a three-bit integer indicating the mode, with values
   defined as follows:

モード: これは値が以下の通り定義されている状態でモードを示す3ビットの整数です:

      Mode     Meaning
      ------------------------------------
      0        reserved
      1        symmetric active
      2        symmetric passive
      3        client
      4        server
      5        broadcast
      6        reserved for NTP control message
      7        reserved for private use

モード意味------------------------------------ 0 私的使用目的で予約されたNTPコントロールメッセージ7のために控えられた1つの予約された左右対称の活発な左右対称の受け身の2のクライアント4サーバ5 3放送6

   In unicast mode the client sets this field to 3 (client) in the
   request and the server sets it to 4 (server) in the reply. In
   broadcast mode the server sets this field to 5 (broadcast).

ユニキャストモードで、クライアントは要求における3(クライアント)にこの分野を設定します、そして、サーバは回答で4(サーバ)にそれを設定します。 放送モードで、サーバはこの分野を5に設定します(放送してください)。

   Stratum: This is a eight-bit unsigned integer indicating the stratum
   level of the local clock, with values defined as follows:

層: これは値が以下の通り定義されている状態で地方の時計の層のレベルを示す8ビットの符号のない整数です:

      Stratum  Meaning
      ----------------------------------------------
      0        unspecified or unavailable
      1        primary reference (e.g., radio clock)
      2-15     secondary reference (via NTP or SNTP)
      16-255   reserved

層の意味---------------------------------------------- 2-15のセカンダリ参照(NTPかSNTPを通した)16-255が控えた0つの不特定の参照か1つの入手できないプライマリ参照(例えば、ラジオ時計)

   Poll Interval: This is an eight-bit signed integer indicating the
   maximum interval between successive messages, in seconds to the
   nearest power of two. The values that can appear in this field
   presently range from 4 (16 s) to 14 (16284 s); however, most
   applications use only the sub-range 6 (64 s) to 10 (1024 s).

間隔に投票してください: これは秒の連続したメッセージの最大の間隔の間の2の最も近いパワーへの整数表示に署名する8ビットです。 現在この分野に現れることができる値は4(16秒間)から14(16284秒間)に変化します。 しかしながら、ほとんどのアプリケーションがサブ範囲6対10(64秒間)(1024秒間)だけを使用します。

Mills                                                           [Page 7]

RFC 1769                          SNTP                       March 1995

1995年のSNTP行進のときにRFC1769を製粉します[7ページ]。

   Precision: This is an eight-bit signed integer indicating the
   precision of the local clock, in seconds to the nearest power of two.
   The values that normally appear in this field range from -6 for
   mains-frequency clocks to -20 for microsecond clocks found in some
   workstations.

精度: これは地方の時計の精度を示す8ビットの署名している整数です、2の最も近いパワーへの秒に。 通常、この分野に現れる値はメイン頻度時計のための-6から時計がいくつかのワークステーションで当たったマイクロセカンドのための-20に変化します。

   Root Delay: This is a 32-bit signed fixed-point number indicating the
   total roundtrip delay to the primary reference source, in seconds
   with fraction point between bits 15 and 16. Note that this variable
   can take on both positive and negative values, depending on the
   relative time and frequency offsets. The values that normally appear
   in this field range from negative values of a few milliseconds to
   positive values of several hundred milliseconds.

遅れを根づかせてください: これは総往復の遅れをプライマリ照合線源まで示す32ビットの署名している固定小数点数です、ビット15と16の間には、断片ポイントがある秒に。 相対的な時間と頻度オフセットによって、この変数が積極的なものと同様に否定的な値を呈することができることに注意してください。 通常、この分野に現れる値は数ミリセカンドの負の数から数100ミリセカンドの正の数まで及びます。

   Root Dispersion: This is a 32-bit unsigned fixed-point number
   indicating the nominal error relative to the primary reference
   source, in seconds with fraction point between bits 15 and 16. The
   values that normally appear in this field range from 0 to several
   hundred milliseconds.

ディアスポラを根づかせてください: これはプライマリ照合線源に比例して名目上の誤りを示す32ビットの未署名の固定小数点数です、ビット15と16の間には、断片ポイントがある秒に。 通常、この分野に現れる値は0〜数100ミリセカンドに及びます。

   Reference Clock Identifier: This is a 32-bit code identifying the
   particular reference source. In the case of stratum 0 (unspecified)
   or stratum 1 (primary reference), this is a four-octet, left-
   justified, 0-padded ASCII string. While not enumerated as part of the
   NTP specification, the following are representative ASCII
   identifiers:

基準クロック識別子: これは特定の照合線源を特定する32ビットのコードです。 層0(不特定の)か層1(プライマリ参照)の場合では、これは4八重奏と、左の正当で、0でそっと歩いているASCIIストリングです。 NTP仕様の一部として列挙されない間、↓これは代表しているASCII識別子です:

      Stratum Code  Meaning
      ----------------------------------------------------------------
      1   pps       precision calibrated source, such as ATOM (atomic
                    clock), PPS (precision pulse-per-second source),
                    etc.
      1   service   generic time service other than NTP, such as ACTS
                    (Automated Computer Time Service), TIME (UDP/Time
                    Protocol), TSP (Unix Time Service Protocol), DTSS
                    (Digital Time Synchronization Service), etc.
      1   radio     Generic radio service, with callsigns such as CHU,
                    DCF77, MSF, TDF, WWV, WWVB, WWVH, etc.
      1   nav       radionavigation system, such as OMEG (OMEGA), LORC
                    (LORAN-C), etc.
      1   satellite generic satellite service, such as GOES
                    (Geostationary Orbit Environment Satellite, GPS
                    (Global Positioning Service), etc.
      2   address   secondary reference (four-octet Internet address of
                    the NTP server)

層のコード意味---------------------------------------------------------------- 1 pps精度はATOM(原子時計)などの源、PPS(1セカンドソースあたりの精度パルス)などを較正しました。 1 条例(自動化されたコンピュータTime Service)、タイム誌(UDP/時間プロトコル)、TSP(unix Time Serviceプロトコル)、DTSSなどのNTP(デジタルTime Synchronization Service)以外のサービスジェネリック時間指定サービスなど 1 チュウ、DCF77、MSF、TDF、WWV、WWVB、WWVHなどのcallsignsとのラジオGenericラジオサービス OMEG(オメガ)、LORC(LORAN-C)などの1台のnav無線航法システム ゴエスなどの1つの衛星ジェネリック衛星サービス、(静止Orbit Environment Satellite、GPS2など(グローバルなPositioning Service)はセカンダリ参照を扱います。(NTPサーバの4八重奏のインターネット・アドレス)

Mills                                                           [Page 8]

RFC 1769                          SNTP                       March 1995

1995年のSNTP行進のときにRFC1769を製粉します[8ページ]。

   Reference Timestamp: This is the time at which the local clock was
   last set or corrected, in 64-bit timestamp format.

参照タイムスタンプ: ここで、地方の時計は、64ビットのタイムスタンプ形式で最後に設定されたか、または修正されました。

   Originate Timestamp: This is the time at which the request departed
   the client for the server, in 64-bit timestamp format.

タイムスタンプを溯源してください: ここで、要求はサーバのために64ビットのタイムスタンプ形式でクライアントを去りました。

   Receive Timestamp: This is the time at which the request arrived at
   the server, in 64-bit timestamp format.

タイムスタンプを受け取ってください: ここで、要求は64ビットのタイムスタンプ形式でサーバに到着しました。

   Transmit Timestamp: This is the time at which the reply departed the
   server for the client, in 64-bit timestamp format.

タイムスタンプを伝えてください: ここで、回答はクライアントのために64ビットのタイムスタンプ形式でサーバを去りました。

   Authenticator (optional): When the NTP authentication mechanism is
   implemented, this contains the authenticator information defined in
   Appendix C of RFC-1305. In SNTP this field is ignored for incoming
   messages and is not generated for outgoing messages.

固有識別文字(任意の): NTP認証機構が実装されるとき、これはRFC-1305のAppendix Cで定義された固有識別文字情報を含んでいます。 SNTPでは、この分野は、入力メッセージのために無視されて、送信されるメッセージのために生成されません。

5. SNTP Client Operations

5. SNTPクライアント操作

   The model for n SNTP client operating with either a NTP or SNTP
   server is a RPC client with no persistent state. In unicast mode, the
   client sends a client request (mode 3) to the server and expects a
   server reply (mode 4). In broadcast mode, the client sends no request
   and waits for a broadcast message (mode 5) from one or more servers,
   depending on configuration. Unicast client and broadcast server
   messages are normally sent at periods from 64 s to 1024 s, depending
   on the client and server configurations.

NTPかSNTPサーバのどちらかによるn SNTPクライアント操作のためのモデルは永続的な状態がなければRPCクライアントです。 ユニキャストモードで、クライアントは、クライアント要求(モード3)をサーバに送って、サーバ回答(モード4)を予想します。 放送モードで、クライアントは、要求を全く送らないで、1つ以上のサーバからの同報メッセージ(モード5)を待ちます、構成によって。 通常、64秒間から1024秒間までの期間にユニキャストクライアントと放送サーバメッセージを送ります、クライアントとサーバ構成に頼っていて。

   A unicast client initializes the SNTP message header, sends the
   message to the server and strips the time of day from the reply. For
   this purpose all of the message-header fields shown above are set to
   0, except the first octet. In this octet the LI field is set to 0 (no
   warning) and the Mode field is set to 3 (client). The VN field must
   agree with the software version of the NTP or SNTP server; however,
   NTP Version 3 (RFC-1305) servers will also accept Version 2 (RFC-
   1119) and Version 1 (RFC-1059) messages, while NTP Version 2 servers
   will also accept NTP Version 1 messages. Version 0 (RFC-959) messages
   are no longer supported. Since there are NTP servers of all three
   versions interoperating in the Internet of today, it is recommended
   that the VN field be set to 1.

ユニキャストクライアントは、SNTPメッセージヘッダーを初期化して、メッセージをサーバに送って、回答から時刻を剥取ります。 最初の八重奏を除いて、このために上に示されたメッセージヘッダーフィールドのすべてが0に設定されます。 この八重奏では、LI分野は0(警告しない)に設定されます、そして、Mode分野は3(クライアント)に設定されます。 VN分野はNTPかSNTPサーバのソフトウェアバージョンに同意しなければなりません。 しかしながら、また、NTPバージョン3(RFC-1305)サーバはバージョン2(RFC1119)とバージョン1(RFC-1059)メッセージを受け入れるでしょう、また、NTPバージョン2サーバはNTPバージョン1メッセージを受け入れるでしょうが。 バージョン0(RFC-959)メッセージはもうサポートされません。 今日のインターネットに共同利用するすべての3つのバージョンのNTPサーバがあるので、VN分野が1に設定されるのは、お勧めです。

   In both unicast and broadcast modes, the unicast server reply or
   broadcast message includes all the fields described above; however,
   in SNTP only the Transmit Timestamp has explicit meaning and then
   only if nonzero. The integer part of this field contains the server
   time of day in the same format as the UDP/TIME Protocol [POS83].
   While the fraction part of this field will usually be valid, the
   accuracy achieved with SNTP may justify its use only to a significant

ユニキャストと放送モードの両方では、ユニキャストサーバ回答か同報メッセージが上で説明されたすべての分野を含んでいます。 しかしながら、SNTPだけでは、Transmit Timestampは非零である場合にだけ明白な意味とその時を持っています。 この分野の整数部はUDP/タイム誌プロトコル[POS83]と同じ形式に時刻にサーバを含んでいます。 通常、この分野の小数部が有効になる間、SNTPと共に達成された精度はaだけに重要な状態で使用を正当化するかもしれません。

Mills                                                           [Page 9]

RFC 1769                          SNTP                       March 1995

1995年のSNTP行進のときにRFC1769を製粉します[9ページ]。

   fraction of a second. If the Transmit Timestamp field is 0, the
   message should be disregarded.

1秒の何分の一。 Transmit Timestamp分野が0であるなら、メッセージは無視されるべきです。

   In broadcast mode, a client has no additional information to
   calculate the propagation delay between the server and client, as the
   Transmit Timestamp and Receive Timestamp fields have no meaning in
   this mode. Even in unicast mode, most clients will probably elect to
   ignore the Originate Timestamp and Receive Timestamp fields anyway.
   However, in unicast mode a simple calculation can be used to provide
   the roundtrip delay d and local clock offset t relative to the
   server, generally to within a few tens of milliseconds. To do this,
   the client sets the Originate Timestamp in the request to the time of
   day according to its local clock converted to NTP timestamp format.
   When the reply is received, the client determines a Destination
   Timestamp as the time of arrival according to its local clock
   converted to NTP timestamp format. The following table summarizes the
   four timestamps.

クライアントには、放送モードで、サーバとクライアントの間で伝播遅延について計算する追加情報が全くありません、Transmit TimestampとReceive Timestamp分野にこのモードによる意味でないのがあるとき。 ユニキャストモードでさえ、ほとんどのクライアントが、とにかくOriginate TimestampとReceive Timestamp分野を無視するのをたぶん選ぶでしょう。 しかしながら、ユニキャストモードで、サーバに比例して往復の遅れdと地方の時計オフセットtを一般にいくつかに何十ミリセカンドもと同じくらい提供するのに簡単な計算を使用できます。 これをするために、NTPタイムスタンプ形式に変換された地方の時計に従って、クライアントは時刻への要求にOriginate Timestampをはめ込みます。 回答が受け取られているとき、地方の時計に従った到着時刻がNTPタイムスタンプ形式に変えたので、クライアントはDestination Timestampを決定します。 以下のテーブルは4つのタイムスタンプをまとめます。

      Timestamp Name          ID   When Generated
      ------------------------------------------------------------
      Originate Timestamp     T1   time request sent by client
      Receive Timestamp       T2   time request received at server
      Transmit Timestamp      T3   time reply sent by server
      Destination Timestamp   T4   time reply received at client

生成されると、タイムスタンプはIDを命名します。------------------------------------------------------------ クライアントに受け取られたサーバDestination Timestamp T4時間回答で送られたサーバTransmit Timestamp T3時間回答で受け取られたクライアントReceive Timestamp T2時間要求で送られたTimestamp T1時間要求を溯源してください。

   The roundtrip delay d and local clock offset t are defined as

dと地方の時計オフセットtが定義される往復の遅れ

                       d = (T4 - T1) - (T2 - T3)
                    t = ((T2 - T1) + (T3 - T4)) / 2.

d=(T4--T1)--(T2--T3) tは/2と等しいです((T2--T1)+(T3--T4))。

   The following table is a summary of the SNTP client operations. There
   are two recommended error checks shown in the table. In all NTP
   versions, if the LI field is 3, or the Stratum field is not in the
   range 1-15, or the Transmit Timestamp is 0, the server has never
   synchronized or not synchronized to a valid timing source within the
   last 24 hours. At the client discretion, the values of the remaining
   fields can be checked as well. Whether to believe the transmit
   timestamp or not in case one or more of these fields appears invalid
   is at the discretion of the implementation.

以下のテーブルはSNTPクライアント操作の概要です。 テーブルに示された2つのお勧めのエラーチェックがあります。 すべてのNTPバージョンでは、サーバは、LI分野が3であるかStratum分野が範囲1-15にないか、Transmit Timestampが0歳であるなら、連動したことがなくはありませんし、ここ24時間以内に有効なタイミングソースと一度も同期したことがなくはありません。 また、クライアント裁量では、残っているフィールドの値をチェックできます。 信じているかどうか、これらの分野の1つ以上が現れないといけないので、タイムスタンプを伝えてください。さもないと、実装の裁量には病人がいます。

Mills                                                          [Page 10]

RFC 1769                          SNTP                       March 1995

1995年のSNTP行進のときにRFC1769を製粉します[10ページ]。

      Field Name              Request        Reply
      -------------------------------------------------------------
      LI                      0              leap indicator; if 3
                                             (unsynchronized), disregard
                                             message
      VN                      1 (see text)   ignore
      Mode                    3 (client)     ignore
      Stratum                 0              ignore
      Poll                    0              ignore
      Precision               0              ignore
      Root Delay              0              ignore
      Root Dispersion         0              ignore
      Reference Identifier    0              ignore
      Reference Timestamp     0              ignore
      Originate Timestamp     0 (see text)   ignore (see text)
      Receive Timestamp       0              ignore (see text)
      Transmit Timestamp      0              time of day; if 0
                                             (unsynchronized), disregard
                                             message
      Authenticator           (not used)     ignore

フィールド名要求回答------------------------------------------------------------- LI0はインディケータを跳ねさせます。 3(非連動した)であるなら、VN1(テキストを見ます)がOriginate Timestamp0(テキストを見ます)が受信するのをReference Timestamp0が、無視するReference Identifier0が、無視するRootディアスポラ0が、無視するRoot Delay0が、無視するPrecision0が、無視するPoll0が、無視するStratum0が、無視する(クライアント)が、無視する無視する(テキストを見ます)Mode3を無視するというTimestamp0がTimestampを伝えるのを無視する(テキストを見ます)メッセージを無視してください、0時刻。 0(非連動した)であるなら、Authenticator(使用されない)が無視するメッセージを無視してください。

6. SNTP Server Operations

6. SNTPサーバ操作

   The model for a SNTP server operating with either a NTP or SNTP
   client is an RPC server with no persistent state. Since a SNTP server
   ordinarily does not implement the full set of NTP algorithms intended
   to support redundant peers and diverse network paths, it is
   recommended that a SNTP server be operated only in conjunction with a
   source of external synchronization, such as a reliable radio clock.
   In this case the server always operates at stratum 1.

どちらかでNTPかSNTPクライアントを手術するSNTPサーバのためのモデルは永続的な状態がなければRPCサーバです。 SNTPサーバが通常余分な同輩とさまざまのネットワーク経路をサポートすることを意図するNTPアルゴリズムのフルセットを実装しないので、SNTPサーバが外部同期の源に関連してだけ操作されるのは、お勧めです、高信頼のラジオ時計のように。 この場合、サーバは層1でいつも作動します。

   A server can operate in unicast mode, broadcast mode or both at the
   same time. In unicast mode the server receives a request message,
   modifies certain fields in the NTP or SNTP header, and returns the
   message to the sender, possibly using the same message buffer as the
   request. The server may or may not respond if not synchronized to a
   correctly operating radio clock, but the preferred option is to
   respond, since this allows reachability to be determined regardless
   of synchronization state. In unicast mode, the VN and Poll fields of
   the request are copied intact to the reply. If the Mode field of the
   request is 3 (client), it is set to 4 (server) in the reply;
   otherwise, this field is set to 2 (symmetric passive) in order to
   conform to the NTP specification.

サーバは同時に、ユニキャストモード、放送モードまたは両方で作動できます。 ユニキャストモードで、サーバは、要求メッセージを受け取って、NTPかSNTPヘッダーで、ある一定の分野を変更して、メッセージを送付者に返します、ことによると要求と同じメッセージ・バッファを使用して。 正しく稼働しているラジオ時計に連動しないなら、サーバは反応するかもしれませんが、都合のよいオプションは応じることです、これが、可到達性が同期状態にかかわらず決定しているのを許容するので。 ユニキャストモードで、要求のVNとPoll分野は回答に完全な状態でコピーされます。 要求のMode分野が3(クライアント)であるなら、それは回答で4(サーバ)に設定されます。 さもなければ、この分野は、NTP仕様に従うために2(左右対称の受動態)に設定されます。

   In broadcast mode, the server sends messages only if synchronized to
   a correctly operating reference clock. In this mode, the VN field is
   set to 3 (for the current SNTP version), and the Mode field to 5
   (broadcast). The Poll field is set to the server poll interval, in

放送モードで、正しく稼働している基準クロックに連動する場合にだけ、サーバはメッセージを送ります。 このモードで、VN分野は3(現在のSNTPバージョンのための)、および5へのMode分野に設定されます(放送してください)。 Poll分野は中にサーバ投票間隔に設定されます。

Mills                                                          [Page 11]

RFC 1769                          SNTP                       March 1995

1995年のSNTP行進のときにRFC1769を製粉します[11ページ]。

   seconds to the nearest power of two. It is highly desirable that, if
   a server supports broadcast mode, it also supports unicast mode. This
   is necessary so a potential broadcast client can calculate the
   propagation delay using client/server messages prior to regular
   operation using only broadcast messages.

2の最も近いパワーへの秒。 また、サーバが放送モードをサポートするならユニキャストモードをサポートするのは、非常に望ましいです。 潜在的放送クライアントが正常な操業の前に同報メッセージだけを使用することでクライアント/サーバメッセージを使用することで伝播遅延について計算できるように、これが必要です。

   The remaining fields are set in the same way in both unicast and
   broadcast modes. Assuming the server is synchronized to a radio clock
   or other primary reference source and operating correctly, the
   Stratum field is set to 1 (primary server) and the LI field is set to
   0; if not, the Stratum field is set to 0 and the LI field is set to
   3. The Precision field is set to reflect the maximum reading error of
   the local clock. For all practical cases it is computed as the
   negative of the number of significant bits to the right of the
   decimal point in the NTP timestamp format. The Root Delay and Root
   Dispersion fields are set to 0 for a primary server; optionally, the
   Root Dispersion field can be set to a value corresponding to the
   maximum expected error of the radio clock itself. The Reference
   Identifier is set to designate the primary reference source, as
   indicated in the table above.

同様に、ユニキャストと放送モードの両方が残っているフィールドにはめ込まれます。 サーバを仮定するのはラジオ時計か他のプライマリ照合線源と正しく作動すると連動します、そして、Stratum分野は1(プライマリサーバ)に設定されます、そして、LI分野は0に設定されます。 そうでなければ、Stratum分野は0に設定されます、そして、LI分野は3に設定されます。 Precision分野が地方の時計の最大の読み込み誤りを反映するように設定されます。 すべての実用的なケースにおいて、それは重要なビットの数の否定的としてNTPタイムスタンプ形式で小数点の右に計算されます。 Root DelayとRootディアスポラ分野はプライマリサーバのために0に用意ができています。 任意に、ラジオ時計自体の最大の期待誤差に対応する値にRootディアスポラ分野を設定できます。 Reference Identifierは上のテーブルにみられるようにプライマリ照合線源を任命するように用意ができています。

   The timestamp fields are set as follows. If the server is
   unsynchronized or first coming up, all timestamp fields are set to
   zero. If synchronized, the Reference Timestamp is set to the time the
   last update was received from the radio clock or, if unavailable, to
   the time of day when the message is sent. The Receive Timestamp and
   Transmit Timestamp fields are set to the time of day when the message
   is sent. In unicast mode, the Originate Timestamp field is copied
   unchanged from the Transmit Timestamp field of the request. It is
   important that this field be copied intact, as a NTP client uses it
   to check for replays. In broadcast mode, this field is set to the
   time of day when the message is sent. The following table summarizes
   these actions.

タイムスタンプ分野は以下の通り設定されます。 サーバが非連動するか、または最初に来るなら、すべてのタイムスタンプ分野がゼロに設定されます。 または、連動するなら、Reference Timestampがアップデートがラジオ時計から受けられた時に用意ができている、メッセージを送ると時刻を入手できないなら。 メッセージを送るとき、Receive TimestampとTransmit Timestamp分野は時刻に用意ができています。 ユニキャストモードで、Originate Timestamp分野は要求のTransmit Timestamp分野から変わりがない状態でコピーされます。 NTPクライアントが再生がないかどうかチェックするのにそれを使用するのでこの分野が完全な状態でコピーされるのは、重要です。 メッセージを送るとき、放送モードで、この分野を時刻に設定します。 以下のテーブルはこれらの動作をまとめます。

Mills                                                          [Page 12]

RFC 1769                          SNTP                       March 1995

1995年のSNTP行進のときにRFC1769を製粉します[12ページ]。

      Field Name              Request        Reply
      ----------------------------------------------------------
      LI                      ignore         0 (normal), 3
                                             (unsynchronized)
      VN                      1, 2 or 3      3 or copied from request
      Mode                    3 (see text)   2, 4 or 5 (see text)
      Stratum                 ignore         1 server stratum
      Poll                    ignore         copied from request
      Precision               ignore         server precision
      Root Delay              ignore         0
      Root Dispersion         ignore         0 (see text)
      Reference Identifier    ignore         source identifier
      Reference Timestamp     ignore         0 or time of day
      Originate Timestamp     ignore         0 or time of day or copied
                                             from Transmit Timestamp of
                                             request
      Receive Timestamp       ignore         0 or time of day
      Transmit Timestamp      (see text)     0 or time of day
      Authenticator           ignore         (not used)

フィールド名要求回答---------------------------------------------------------- LIは3(非連動した)VN1、2または3 3の、または、要求Mode3(テキストを見ます)2からコピーされた0(標準)を無視します; 4か5(テキストを見る)層が無視する、Pollが無視するPrecisionが0(テキストを見る)参照Identifierが識別子Reference Timestampの出典を明示するのを0Rootディアスポラが、無視するRoot Delayが、無視する無視するサーバ精度を無視するという要求からコピーされた1つのサーバ層が0を無視するか、または時刻に、要求Receive TimestampのTransmit Timestampから0か時刻を無視するか、またはコピーされたOriginate TimestampはTransmit Timestamp(テキストを見る)0か時刻Authenticatorが無視する0か時刻を無視します。(中古でない)です。

   There is some latitude on the part of most clients to forgive invalid
   timestamps, such as might occur when first coming up or during
   periods when the primary reference source is inoperative. The most
   important indicator of an unhealthy server is the LI field, in which
   a value of 3 indicates an unsynchronized condition. When this value
   is displayed, clients should discard the server message, regardless
   of the contents of other fields.

無効のタイムスタンプを許すために、何らかの緯度がほとんどのクライアント側のあります。(プライマリ照合線源であるときに、期間の上、または、期間間の最初の来るのが効力がないときに、タイムスタンプは現れるかもしれません)。 不健康なサーバの最も重要なインディケータはLI分野です。(そこで、3の値は非連動している状態を示します)。 この値を表示するとき、クライアントは他の分野のコンテンツにかかわらずサーバメッセージを捨てるべきです。

7. References

7. 参照

   [DAR81] Postel, J., "Internet Protocol - DARPA Internet Program
   Protocol Specification", STD 5, RFC 791, DARPA, September 1981.

[DAR81] ポステル、J.、「インターネットは議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」STD5、RFC791、DARPA、1981年9月。

   [DEE89] Deering, S., "Host Extensions for IP Multicasting. STD 5,
   RFC 1112, Stanford University, August 1989.

[DEE89] デアリング、S.、「IPマルチキャスティングのためのホスト拡大。」 STD5、RFC1112、スタンフォード大学、1989年8月。

   [MIL92] Mills, D., "Network Time Protocol (Version 3) Specification,
   Implementation and Analysis. RFC 1305, University of Delaware,
   March 1992.

[MIL92]工場(D.)は「時間プロトコル(バージョン3)仕様、実装、および分析をネットワークでつなぎます」。 RFC1305、デラウエア大学、1992年3月。

   [POS80] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
   USC/Information Sciences Institute, August 1980.

[POS80] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、科学が1980年8月に設けるUSC/情報。

   [POS83] Postel, J., and K. Harrenstien, "Time Protocol", STD 26,
   RFC 868, USC/Information Sciences Institute, SRI, May 1983.

[POS83] ポステル、J.、およびK.Harrenstien、「時間プロトコル」、STD26、RFC868、科学が設けるUSC/情報(様)は1983がそうするかもしれません。

Mills                                                          [Page 13]

RFC 1769                          SNTP                       March 1995

1995年のSNTP行進のときにRFC1769を製粉します[13ページ]。

Security Considerations

セキュリティ問題

   Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

Author's Address

作者のアドレス

   David L. Mills
   Electrical Engineering Department
   University of Delaware
   Newark, DE 19716

デヴィッドL.はデラウエア大学ニューアーク、電気工学部のDE 19716を製粉します。

   Phone: (302) 831-8247
   EMail: mills@udel.edu

以下に電話をしてください。 (302) 831-8247 メールしてください: mills@udel.edu

Mills                                                          [Page 14]

工場[14ページ]