RFC1361 日本語訳
1361 Simple Network Time Protocol (SNTP). D. Mills. August 1992. (Format: TXT=23812 bytes) (Obsoleted by RFC1769) (Also RFC1305) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. Mills
Request for Comments: 1361 University of Delaware
August 1992
工場がコメントのために要求するワーキンググループD.をネットワークでつないでください: 1361 デラウエア大学1992年8月
Simple Network Time Protocol (SNTP)
簡単なネットワーク時間プロトコル(SNTP)
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard. 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 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 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を使用できます。 それは、現在か前のNTP仕様バージョンか知られている実装への変化に全くかかわらないで、むしろUDP/タイム誌プロトコルと同様の期待がRFC-868で説明した精度と信頼性で簡単で、状態がないRPCモードにおける操作を許すNTPのある設計上の特徴の明確化にかかわります。
This memorandum does not obsolete or update any RFC. A working knowledge of RFC-1305 is not required for an implementation of SNTP.
このメモは、少しのRFCも時代遅れにもしませんし、アップデートもしません。 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 jitter characteristics of the synchronization source and network paths.
RFC-1305[MIL92]で指定されたNetwork Timeプロトコル(NTP)は、世界的なインターネットでコンピュータ時計を連動させるのに使用されます。 それは、それぞれの参加しているサブネット同輩で国家の時間と頻度普及のサービスにアクセスして、時間同期化サブネットを組織化して、地方の時計を調整するために包括的メカニズムを提供します。 今日のインターネットのほとんどの場所に、NTPは1-50 msの精度を提供します、同期ソースとネットワーク経路のジターの特性によって。
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
RFC-1305は、時間保持品質を改良して、数個の、そして、ことによると不完全な同期の中でソースを緩和するためにイベント、州、変遷機能、動作、およびさらに、任意のアルゴリズムでNTPプロトコルマシンを指定します。 安値における精度を達成するために、今日のインターネット、これらの複雑なアルゴリズム、またはそれらの機能的な同等物の主要部にかかる経路の上のミリセカンドが必要です。 しかしながら、多くの場合、このオーダーの精度は必要でなく、ものが何かより少ない、恐らく。
Mills [Page 1] RFC 1361 SNTP August 1992
SNTP1992年8月にRFC1361を製粉します[1ページ]。
in the order of one second, is sufficient. In such cases simpler protocols such as the Time Protocol [POS83], have been used for this purpose. These protocols usually involve a remote-procedure call (RPC) exchange where the client requests the time of day and the server returns it in seconds past some known reference epoch.
1の注文では、第2は十分です。 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 members of the Internet NTP synchronization subnet of today use software packages 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 accuracy expectations in the order of a second.
NTPは使用のためにクライアントとサーバによってさまざまなさまざまな能力とネットワーク遅延とジターの特性の上について設計されます。 今日のインターネットNTP同期サブネットのほとんどのメンバーが比較的複雑なNTPオプションとアルゴリズムの完全なスイートを含むソフトウェアパッケージを使用します、リアルタイムのアプリケーション。 スーパーコンピュータからパーソナルコンピュータまで及ぶさまざまなハードウェアプラットホームにソフトウェアを移植しましたが、多くのアプリケーションには、その全くのサイズと複雑さは適切ではありません。 それに従って、代替のアクセス戦略を探るのは、1秒の注文における精度期待に、適切なはるかに簡単なソフトウェアを使用することで役に立ちます。
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 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 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 become faulty. Therefore, the use of SNTP rather than NTP in primary servers should be carefully considered.
SNTPが単に同期サブネットの窮境に使用されることが強く勧められます。 同期において、どんなSNTPクライアントも別のSNTPクライアントに依存していないところでSNTPクライアントはサブネットの葉(最も高い層)においてだけ構成で働くべきです。 高信頼のラジオ時計以外の同期の他のどんな源も利用可能でないところでSNTPサーバはサブネットの根(層1)においてそして、構成だけで作動するべきです。 通常、プライマリサーバに予想された完全な度合いの信頼性は、完全なNTP実装の余分なソース、さまざまのサブネット経路、および作られたアルゴリズムを使用するだけであることで可能です。 ラジオ時計が失敗するはずであるか、または不完全になるはずであるなら、これは複数のラジオ時計とバックアップ道の形で他のプライマリサーバに同期自体の一次資料に達します。 したがって、プライマリサーバのNTPよりむしろSNTPの使用は慎重に考えられるべきです。
Mills [Page 2] RFC 1361 SNTP August 1992
SNTP1992年8月にRFC1361を製粉します[2ページ]。
2. NTP Timestamp Format
2. 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 zero 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 zero preceding bit zero.
SNTPはRFC-1305とそのドキュメントの旧バージョンで説明された標準のNTPタイムスタンプ形式を使用します。 一般的なインターネット習慣に伴う順応では、NTPデータは整数か定点量として指定されます、ゼロからの左の、または、高いオーダーの位置で始まるビッグエンディアンファッションでビットが付番されている状態で。 別の方法で指定されない場合、すべての量が、未署名であり、ビットゼロに先行する暗示しているゼロに全分野に及ぶ調査幅を占領するかもしれません。
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. 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 precision of this representation is about 200 picoseconds, which should be adequate for even the most exotic requirements.
NTPタイムスタンプが大事にされたデータであり、事実上プロトコルの主産物を表すので、特別なタイムスタンプ形式は確立されました。 NTPタイムスタンプは秒に64ビットの未署名の固定小数点数として1900年1月1日の0hに比例して表されます。 最初の32ビットと最後の32ビットの小数部には整数部があります。 この形式は、Timeプロトコル表現(秒)に便利な複数の精度演算と変換を許しますが、ICMP Timestampメッセージ表現(ミリセカンド)に変換を複雑にします。 この表現の精度はおよそ200のピコセコンドです。(最もエキゾチックな要件にさえ、そのピコセコンドは適切であるべきです)。
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 zero, which by convention is interpreted as an invalid timestamp.
1968のいつかの時間以来、最も重要なビット(整数部のビット0)が設定されていて、64ビットの分野が2036年にいつかあふれることに注意してください。 NTPかSNTPが2036年に使用中であるなら、いくつかの外部の手段が、2036(そして、136年の他の倍数)に比例して1900に比例した時間と時間に資格を与えるために必要になるでしょう。 そのような資格を必要とするTimestampedデータが非常に貴重になるので、適切な手段は容易に利用可能であるべきです。 64ビットの分野がコンベンションによって解釈されるゼロになる136年あたり1回の200ピコセコンドの今後は無視された間隔の間、無効のタイムスタンプは存在するでしょう。
3. NTP Message Format
3. NTPメッセージ・フォーマット
Both NTP and SNTP are clients of the User Datagram Protocol (UDP) [POS83], which itself is a client of the Internet Protocol (IP) [DAR81]. The structure of the IP and UDP headers is described in the relevant specification documents and will not be described further in this memorandum. 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 prespecified values. The format of the NTP message data area, which immediately follows the UDP header, is shown below.
NTPとSNTPの両方がユーザー・データグラム・プロトコル(UDP)[POS83]のクライアントです。(それ自体で、それは、インターネットプロトコル(IP)[DAR81]のクライアントです)。 IPとUDPヘッダーの構造は、関連仕様ドキュメントで説明されて、このメモで、より詳しく説明されないでしょう。 以下に、SNTPメッセージ・フォーマットの記述があります。(メッセージ・フォーマットはIPとUDPヘッダーに続きます)。 形式がNTP形式と同じであるというSNTPメッセージは、例外があるRFC-1305でデータ・フィールドのいくつかが前指定された値に「缶詰」で、すなわち、初期化されていると説明しました。 NTPメッセージデータ領域の書式は以下に示されます。(データ領域はすぐに、UDPヘッダーに続きます)。
Mills [Page 3] RFC 1361 SNTP August 1992
SNTP1992年8月にRFC1361を製粉します[3ページ]。
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 prespecified data. For completeness, the function of each field is briefly summarized below.
次のセクションで説明されるSNTPでは、これらの分野の大部分は前指定されたデータで初期化されます。 完全性において、それぞれの分野の関数は以下へ簡潔にまとめられます。
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アラーム状態(連動しない時計)
Mills [Page 4] RFC 1361 SNTP August 1992
SNTP1992年8月にRFC1361を製粉します[4ページ]。
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
The use of this field will be discussed in the next section.
次のセクションでこの分野の使用について議論するでしょう。
Stratum: This is a eight-bit 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 normally appear in this field range from 6 to 10, inclusive.
間隔に投票してください: これは秒の連続したメッセージの最大の間隔の間の2の最も近いパワーへの整数表示に署名する8ビットです。 通常、この分野に現れる値は6〜10まで包括的に及びます。
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 -18 for microsecond clocks found in some workstations.
精度: これは地方の時計の精度を示す8ビットの署名している整数です、2の最も近いパワーへの秒に。 通常、この分野に現れる値はメイン頻度時計のための-6から時計がいくつかのワークステーションで当たったマイクロセカンドのための-18に変化します。
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 errors. 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ミリセカンドの正の数まで及びます。
Mills [Page 5] RFC 1361 SNTP August 1992
SNTP1992年8月にRFC1361を製粉します[5ページ]。
Root Dispersion: This is a 32-bit unsigned fixed-point number indicating the maximum 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 zero to several hundred milliseconds.
ディアスポラを根づかせてください: これはプライマリ照合線源に比例して最大の誤りを示す32ビットの未署名の固定小数点数です、ビット15と16の間には、断片ポイントがある秒に。 通常、この分野に現れる値はゼロから数100ミリセカンドに変化します。
Reference Clock Identifier: This is a 32-bit code identifying the particular reference clock. In the case of stratum 0 (unspecified) or stratum 1 (primary reference), this is a four-octet, left-justified, zero-padded ASCII string. While not enumerated as part of the NTP specification, the following are representative ASCII identifiers:
基準クロック識別子: これは特定の基準クロックを特定する32ビットのコードです。 層0(不特定の)か層1(プライマリ参照)の場合では、これは4八重奏の、そして、左で正当で、無そっと歩いているASCIIストリングです。 NTP仕様の一部として列挙されない間、↓これは代表しているASCII識別子です:
Stratum Code Meaning
------------------------------------------------------------
0 ascii generic time service other than NTP, such as ACTS
(Automated Computer Time Service), TIME (UDP/Time
Protocol), TSP (TSP Unix time protocol), DTSS
(Digital Time Synchronization Service), etc.
1 ATOM calibrated atomic clock
1 VLF VLF radio (OMEGA, etc.)
1 callsign Generic radio
1 LORC LORAN-C radionavigation system
1 GOES Geostationary Operational Environmental Satellite
1 GPS Global Positioning Service
2 address secondary reference (four-octet Internet address of
the NTP server)
層のコード意味------------------------------------------------------------ 0 条例(自動化されたコンピュータTime Service)、タイム誌(UDP/時間プロトコル)、TSP(TSP Unix時間プロトコル)、DTSSなどのNTP(デジタルTime Synchronization Service)以外のASCIIジェネリック時間指定サービスなど 1 ATOMは原子時計の1VLF VLFのラジオ(オメガなど)を較正しました。 1 callsign Generic1LORC LORAN-Cの1つのラジオ無線航法システムゴエスGeostationary静止実用環境衛星1GPS Global Positioning Service2はセカンダリ参照を扱います。(NTPサーバの4八重奏のインターネット・アドレス)
Reference Timestamp: This is the local time at which the local clock was last set or corrected, in 64-bit timestamp format.
参照タイムスタンプ: これは地方の時計が64ビットのタイムスタンプ形式で最後に設定されたか、または修正された現地時間です。
Originate Timestamp: This is the local time at which the request departed the client for the server, in 64-bit timestamp format.
タイムスタンプを溯源してください: これは要求がサーバのために64ビットのタイムスタンプ形式でクライアントを去った現地時間です。
Receive Timestamp: This is the local time at which the request arrived at the server, in 64-bit timestamp format.
タイムスタンプを受け取ってください: これは要求が64ビットのタイムスタンプ形式でサーバに到着した現地時間です。
Transmit Timestamp: This is the local 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では、この分野は、入力メッセージのために無視されて、送信されるメッセージのために生成されません。
Mills [Page 6] RFC 1361 SNTP August 1992
SNTP1992年8月にRFC1361を製粉します[6ページ]。
4. SNTP Client Operations
4. SNTPクライアント操作
The model for an SNTP client operating with either an NTP or SNTP server is a RPC client with no persistent state. The 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 zero, except the first octet. In this octet the Leap Indicator is set to zero (no warning) and the Mode to 3 (client). The Version Number 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 (original NTP described in RFC-959) messages are no longer supported. Since there are NTP servers of all three versions operating in the Internet of today, it is recommended that the Version Number field be set to one.
どちらかでNTPかSNTPサーバを操作しているSNTPクライアントのためのモデルは永続的な状態がなければRPCクライアントです。 クライアントは、SNTPメッセージヘッダーを初期化して、メッセージをサーバに送って、回答から時刻を剥取ります。 最初の八重奏を除いて、このために上に示されたメッセージヘッダーフィールドのすべてがゼロに設定されます。 この八重奏では、Leap Indicatorは(警告しないこと)とModeのゼロを3(クライアント)に合わせるように用意ができています。 バージョンNumberはNTPかSNTPサーバのソフトウェアバージョンに同意しなければなりません。 しかしながら、また、NTPバージョン3(RFC-1305)サーバはバージョン2(RFC-1119)とバージョン1(RFC-1059)メッセージを受け入れるでしょう、また、NTPバージョン2サーバはNTPバージョン1メッセージを受け入れるでしょうが。 バージョン0(RFC-959で説明されたオリジナルのNTP)メッセージはもうサポートされません。 今日のインターネットで作動するすべての3つのバージョンのNTPサーバがあるので、バージョンNumber分野が1つに設定されるのは、お勧めです。
The server reply includes all the fields described above; however, in SNTP only the Transmit Timestamp has explicit meaning. The integer part of this field contains the server time of day in the same format as the Time Protocol. While the fraction part of this field will usually be valid, the accuracy achieved with the SNTP mode of access probably does not justify its use.
サーバ回答は上で説明されたすべての分野を含んでいます。 しかしながら、SNTPだけでは、Transmit Timestampは明白な意味を持っています。 この分野の整数部はTimeプロトコルと同じ形式に時刻にサーバを含んでいます。 通常、この分野の小数部が有効になる間、アクセスのSNTPモードで達成された精度はたぶん使用を正当化しません。
The following table is a summary of the SNTP client operations. There are three recommended error checks shown in the table. In all NTP versions, if the Leap Indicator field is 3 or the Transmit Timestamp is zero (unsynchronized), the server has never synchronized or not synchronized to a valid timing source within the last 24 hours. If the Stratum field is 0 (unspecified or unavailable), the server has never synchronized, has lost reachability with all timing sources or is synchronized by some protocol other than NTP. Whether to believe the transmit timestamp or not in this case is at the discretion of the client implementation.
以下のテーブルはSNTPクライアント操作の概要です。 テーブルに示された3つのお勧めのエラーチェックがあります。 すべてのNTPバージョンでは、サーバは、Leap Indicator分野が3であるかTransmit Timestampがゼロ(非連動した)であるなら、連動したことがなくはありませんし、ここ24時間以内に有効なタイミングソースと一度も同期したことがなくはありません。 Stratum分野が0(不特定の、または、入手できない)であるなら、サーバは、一度も連動したことがないか、すべてのタイミングソースに可到達性を失うか、またはNTP以外の何らかのプロトコルによって同期させられました。 信じているかどうか、タイムスタンプを伝えてください。さもないと、クライアントの裁量には実装がこの場合ありません。
Mills [Page 7] RFC 1361 SNTP August 1992
SNTP1992年8月にRFC1361を製粉します[7ページ]。
Field Name Request Reply
-------------------------------------------------------------
Leap Indicator (LI) 0 if 3 (unsynchronized),
disregard
Version Number (VN) (see text) ignore
Mode 3 (client) ignore
Stratum 0 if 0 (unspecified),
disregard
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 ignore
Receive Timestamp 0 ignore
Transmit Timestamp 0 time of day (seconds only);
if 0 (unsynchronized),
disregard
Authenticator (not used) ignore
フィールド名要求回答------------------------------------------------------------- 3(非連動した)であるならIndicator(LI)0を跳ねさせてください、と無視バージョンNumber(VN)(テキストを見る)は無視します。Originate Timestamp0はReceive Timestamp0を無視します。Mode3(クライアント)が0(不特定の)であるならStratum0を無視する、無視Poll0がPrecision0を無視する、無視、Root Delay0が0が無視するRootディアスポラを無視する、Reference Identifier0がReference Timestamp0を無視する、無視、Transmit Timestamp0時刻(秒専用)を無視してください。 0(非連動した)、Authenticator(使用されない)が無視する無視
5. SNTP Server Operations
5. SNTPサーバ操作
The model for an SNTP server operating with either an NTP or SNTP client is an RPC server with no persistent state. The SNTP server ignores all header fields except the first octet, modifies certain fields and returns the message to the sender. Since an SNTP server ordinarily does not implement the full set of NTP algorithms intended to support the highest quality service, it is recommended that an SNTP server be operated only in conjunction with a source of outside synchronization, such as a radio clock. In this case the server always operates at stratum 1.
どちらかでNTPかSNTPクライアントを手術するSNTPサーバのためのモデルは永続的な状態がなければRPCサーバです。 SNTPサーバは、送付者に最初の八重奏を除いて、すべてのヘッダーフィールドを無視して、ある一定の分野を変更して、メッセージを返します。 SNTPサーバが通常最も高い質の高いサービスをサポートすることを意図するNTPアルゴリズムのフルセットを実装しないので、SNTPサーバが外の同期の源に関連してだけ操作されるのは、お勧めです、ラジオ時計のように。 この場合、サーバは層1でいつも作動します。
The first octet is interpreted as follows. The Leap Indicator and Version Number fields are ignored. Optionally, messages with version numbers other than 1, 2, or 3 can be discarded. For primary servers connected to a functioning radio clock, the Leap Indicator field is set to zero and the Stratum field is set to one in the reply. otherwise, these fields are set to 3 and zero, respectively. In any case the Version Number and Poll fields are copied intact to the reply message header. If The Mode field is set to 3 (client), it is changed to 4 (server) in the reply; otherwise, this field is set to 2 (symmetric passive).
最初の八重奏は以下の通り解釈されます。 Leap IndicatorとバージョンNumber分野は無視されます。 任意に、1以外のバージョン番号があるメッセージであり、2、または3を捨てることができます。 機能しているラジオ時計に接続されたプライマリサーバにおいてLeap Indicator分野はゼロに設定されます、そして、Stratum分野は回答で1つに設定されます。さもなければ、これらの分野はそれぞれ3とゼロに設定されます。 どのような場合でも、バージョンNumberとPoll分野は応答メッセージヘッダーに完全な状態でコピーされます。 Mode分野が3(クライアント)に設定されるなら、回答で4(サーバ)に変わります。 さもなければ、この分野は2(左右対称の受動態)に設定されます。
The Stratum 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
Stratum分野が地方の時計の最大の読み込み誤りを反映するように設定されます。 すべての実用的なケースにおいて、それは重要なビットの数の否定的としてNTPタイムスタンプ形式で小数点の右に計算されます。 根の遅れと根のディアスポラ
Mills [Page 8] RFC 1361 SNTP August 1992
SNTP1992年8月にRFC1361を製粉します[8ページ]。
fields are set to zero for a primary server; optionally, the Root Dispersion can be set to a value corresponding to the expected (constant) maximum expected error of the primary reference source. The Reference Identifier is set to designate the primary reference source, as indicated in the table above. If this information is unspecified or unavailable, the field is set to zero.
分野はプライマリサーバのためにゼロに設定されます。 任意に、プライマリ照合線源の予想された(一定の)最大の期待誤差に対応する値にRootディアスポラを設定できます。 Reference Identifierは上のテーブルにみられるようにプライマリ照合線源を任命するように用意ができています。 この情報が不特定であるか、または入手できないなら、分野はゼロに設定されます。
The timestamp fields are set as follows. The Reference Timestamp, Receive Timestamp and Transmit Timestamp fields are set to the time of day at the server. The Originate Timestamp field is copied unchanged from the request. The following table summarizes these actions.
タイムスタンプ分野は以下の通り設定されます。 Reference Timestamp、Receive Timestamp、およびTransmit Timestamp分野はサーバで時刻に用意ができています。Originate Timestamp分野は要求によって変わりがない状態でコピーされます。 以下のテーブルはこれらの動作をまとめます。
Field Name Request Reply
----------------------------------------------------------
Leap Indicator (LI) ignore 0 (normal), 3
(unsynchronized)
Version Number (VN) ignore copied from request
Mode (see text) (see text)
Stratum ignore server stratum (1)
Poll ignore copied from request
Precision ignore server precision
Root Delay ignore 0
Root Dispersion ignore 0 (see text)
Reference Identifier ignore source identifier or 0
Reference Timestamp ignore time of day or 0
Originate Timestamp ignore copied from request
Receive Timestamp ignore time of day or 0
Transmit Timestamp ignore time of day or 0
Authenticator ignore (not used)
フィールド名要求回答---------------------------------------------------------- 飛躍Indicator(LI)は0(正常な)を無視します; Number(VN)が無視するMode(テキストを見ます)(テキストを見る)層が(1)投票が無視するサーバ層を無視するという要求からコピーされたPrecisionがRoot Delayが無視するサーバ精度を無視するという要求からコピーされた3(非連動した)バージョンはReceive Timestampが時刻に無視する要求、Transmit Timestampが時刻に無視する0またはAuthenticatorが無視する0からコピーされましたソース識別子、Reference Timestampが時刻に無視する0または0Originate Timestampが、無視する0(テキストを見る)参照Identifierが、無視する0Rootディアスポラが、無視する。(中古でない)です。
6. References
6. 参照
[DAR81] Postel, J., "Internet Protocol - DARPA Internet Program Protocol Specification", RFC 791, DARPA, September 1981.
[DAR81] ポステル、J.、「インターネットは議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」RFC791、DARPA、1981年9月。
[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", RFC 768, USC/Information Sciences Institute, August 1980.
[POS80] ポステル、J.、「ユーザー・データグラム・プロトコル」、RFC768、科学が1980年8月に設けるUSC/情報。
[POS83] Postel, J., and K. Harrenstien, "Time Protocol", RFC 868, USC/Information Sciences Institute, SRI, May 1983.
[POS83] ポステル、J.、およびK.Harrenstien、「時間プロトコル」、RFC868、科学が設けるUSC/情報(様)は1983がそうするかもしれません。
Mills [Page 9] RFC 1361 SNTP August 1992
SNTP1992年8月にRFC1361を製粉します[9ページ]。
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
以下に電話をしてください。 (302) 831-8247
EMail: mills@udel.edu
メール: mills@udel.edu
Mills [Page 10]
工場[10ページ]
一覧
スポンサーリンク
