RFC2030 日本語訳
2030 Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 andOSI. D. Mills. October 1996. (Format: TXT=48620 bytes) (Obsoletes RFC1769) (Obsoleted by RFC4330) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. Mills Request for Comments: 2030 University of Delaware Obsoletes: 1769 October 1996 Category: Informational
工場がコメントのために要求するワーキンググループD.をネットワークでつないでください: 2030 デラウエア大学は以下を時代遅れにします。 1769 1996年10月のカテゴリ: 情報
Simple Network Time Protocol (SNTP) Version 4
for IPv4, IPv6 and OSI
IPv4、IPv6、およびOSIのための簡単なネットワーク時間プロトコル(SNTP)バージョン4
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) Version 4, 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. When operating with current and previous NTP and SNTP versions, SNTP Version 4 involves no changes to the NTP specification 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)バージョン4について説明します。(それは、インターネットでコンピュータ時計を連動させるのに使用されるNetwork Timeプロトコル(NTP)の適合です)。 RFC-1305で説明された完全なNTP実装の究極の性能が必要でない、または正当化されないとき、SNTPを使用できます。 現在で前のNTPとSNTPバージョンで作動するとき、SNTPバージョン4は、NTP仕様か知られている実装への変化に全くかかわらないで、むしろUDP/タイム誌プロトコルと同様の期待がRFC-868で説明した精度と信頼性で簡単で、状態がない遠隔手続き呼び出し(RPC)モードにおける操作を許すNTPのある設計上の特徴の明確化にかかわります。
The only significant protocol change in SNTP Version 4 over previous versions of NTP and SNTP is a modified header interpretation to accommodate Internet Protocol Version 6 (IPv6) [DEE96] and OSI [COL94] addressing. However, SNTP Version 4 includes certain optional extensions to the basic Version 3 model, including an anycast mode and an authentication scheme designed specifically for multicast and anycast modes. While the anycast mode extension is described in this document, the authentication scheme extension will be described in another document to be published later. Until such time that a definitive specification is published, these extensions should be considered provisional.
NTPとSNTPの旧バージョンの上のSNTPバージョン4における唯一の重要なプロトコル変化がインターネットプロトコルバージョン6(IPv6)[DEE96]とOSI[COL94]アドレシングに対応する変更されたヘッダー解釈です。 しかしながら、SNTPバージョン4は基本的なバージョン3モデルに、ある任意の拡大を含んでいます、特にマルチキャストとanycastモードのために設計されたanycastモードと認証体系を含んでいて。 anycastモード拡張子が本書では説明されている間、認証体系拡大は、後で発行されるために別のドキュメントで説明されるでしょう。 決定的な仕様が発表されるくらいの時間まで、これらの拡大は暫定的であると考えられるべきです。
This memorandum obsoletes RFC-1769, which describes SNTP Version 3. Its purpose is to correct certain inconsistencies in the previous document and to clarify header formats and protocol operations for current NTP Version 3 (IPv4) and proposed NTP Version 4 (IPv6 and OSI), which are also used for SNTP. A working knowledge of the NTP Version 3 specification RFC-1305 is not required for an implementation of SNTP.
このメモはRFC-1769を時代遅れにします。(RFC-1769はSNTPバージョン3について説明します)。 目的は、前のドキュメントにおける、ある矛盾を修正して、現在のNTPバージョン3(IPv4)と提案されたNTPバージョン4(IPv6とOSI)のためのヘッダー形式とプロトコル操作をはっきりさせることです。(また、バージョンはSNTPに使用されます)。 NTPバージョン3仕様RFC-1305の実用的な知識はSNTPの実装に必要ではありません。
Mills Informational [Page 1] RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
1996年10月にIPv4、IPv6、およびOSIのために情報[1ページ]のRFC2030SNTPv4を製粉します。
1. Introduction
1. 序論
The Network Time Protocol (NTP) Version 3 specified in RFC-1305 [MIL92] is widely 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)バージョン3は、世界的なインターネットでコンピュータ時計を連動させるのに広く使用されます。 それは、国家の時間と頻度普及のサービスにアクセスして、時間同期サブネットを組織化して、それぞれの参加しているサブネット同輩で地方の時計を調整するために包括的メカニズムを提供します。 今日のインターネットのほとんどの場所に、NTPは1-50 msの精度を提供します、同期ソースとネットワーク経路の特性によって。
RFC-1305 specifies the NTP Version 3 protocol machine in terms of events, states, transition functions and actions and, in addition, engineered algorithms to improve the timekeeping quality and mitigate among several synchronization sources, some of which may be faulty. 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 in the order of significant fractions of a second are acceptable. 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はバージョン3プロトコルがイベント、州、変遷機能、動作、および時間保持品質を改良するさらに、設計されたアルゴリズムで機械加工して、それの或るものが不完全であるかもしれないいくつかの同期ソースの中で緩和するNTPを指定します。 安値における精度を達成するために、今日のインターネット、これらの複雑なアルゴリズム、またはそれらの機能的な同等物の主要部にかかる経路の上のミリセカンドが必要です。 しかしながら、多くの場合、1秒の重要な何分の一の注文における精度は許容できます。 そのような場合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 (see http://www.eecis.udel.edu/~ntp). While the software has been ported to a wide variety of hardware platforms ranging from personal computers to supercomputers, its sheer size and complexity is not appropriate for many applications. Accordingly, it is useful to explore alternative access strategies using simpler software appropriate for less stringent accuracy expectations.
NTPは使用のためにクライアントとサーバによってさまざまなさまざまな能力とネットワーク遅延とジターの特性の上について設計されます。 今日のインターネットNTP同期サブネットのほとんどのユーザが比較的複雑なNTPオプションとアルゴリズムの完全なスイートを含むソフトウェアパッケージを使用します、リアルタイムのアプリケーション( http://www.eecis.udel.edu/~ntp を見てください)。 パーソナルコンピュータからスーパーコンピュータまで及ぶさまざまなハードウェアプラットホームにソフトウェアを移植しましたが、多くのアプリケーションには、その全くのサイズと複雑さは適切ではありません。 それに従って、それほど厳しくない精度期待に、適切なより簡単なソフトウェアを使用する代替のアクセス戦略を探るのは役に立ちます。
This document describes the Simple Network Time Protocol (SNTP) Version 4, which is a simplified access strategy for servers and clients using NTP Version 3 as now specified and deployed in the Internet, as well as NTP Version 4 now under development. 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
このドキュメントはSimple Network Timeプロトコル(SNTP)バージョン4について説明します、現在開発中のNTPバージョン4と同様に。(バージョンはインターネットで現在指定されているとしてNTPバージョン3を使用して、配布されたサーバとクライアントのための簡易型のアクセス戦略です)。 アクセスパラダイムはUDP/タイム誌プロトコルと同じです、そして、事実上、たとえば、パーソナルコンピュータのためにUDP/タイム誌クライアント実装を適合させて、作動するのは、SNTPを使用することで容易に可能であるべきです。 そのうえ、また、SNTPは、統合ラジオ時計を含む専用サーバ構成で作動するように設計されています。 システムにおける、様々な潜在の慎重なデザインとコントロールで、正確な状態で調節してください。(それは、ひたむきなデザインで実用的です、配送するのが可能であるということです)。
Mills Informational [Page 2] RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
1996年10月にIPv4、IPv6、およびOSIのために情報[2ページ]のRFC2030SNTPv4を製粉します。
order of microseconds.
マイクロセカンドの注文。
SNTP Version 4 is designed to coexist with existing NTP and SNTP Version 3 clients and servers, as well as proposed Version 4 clients and servers. When operating with current and previous versions of NTP and SNTP, SNTP Version 4 requires no changes to the protocol or implementations now running or likely to be implemented specifically for NTP ir SNTP Version 4. To a NTP or SNTP server, NTP and SNTP clients are undistinguishable; to a NTP or SNTP client, NTP and SNTP servers are undistinguishable. Like NTP servers operating in non- symmetric modes, SNTP servers are stateless and can support large numbers of clients; however, unlike most NTP clients, SNTP clients normally operate with only a single server. NTP and SNTP Version 3 servers can operate in unicast and multicast modes. In addition, SNTP Version 4 clients and servers can implement extensions to operate in anycast mode.
SNTPバージョン4は既存のNTPとSNTPバージョン3クライアントとサーバと共存するように設計されています、提案されたバージョン4クライアントとサーバと同様に。 NTPとSNTPの現在で前のバージョンで作動するとき、SNTPバージョン4は今、稼働しそうであるか、または特にNTP不-SNTPバージョン4のために実装しそうなプロトコルか実装への変化を全く必要としません。 NTPかSNTPサーバに、NTPとSNTPクライアントは「非-区別可能」です。 NTPかSNTPクライアントにとって、NTPとSNTPサーバは「非-区別可能」です。 非左右対称のモードで作動するNTPサーバのように、SNTPサーバは、状態がなく、多くのクライアントをサポートすることができます。 しかしながら、通常、ほとんどのNTPクライアントと異なって、SNTPクライアントはただ一つのサーバだけで働いています。NTPとSNTPバージョン3つのサーバがユニキャストとマルチキャストモードで働くことができます。 さらに、SNTPバージョン4クライアントとサーバは、anycastモードで作動するために拡大を実装することができます。
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 or modem time service 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 or modem sources and backup paths to other primary servers should all sources fail or the majority deliver incorrect time. Therefore, the use of SNTP rather than NTP in primary servers should be carefully considered.
SNTPが単に同期サブネットの窮境に使用されることが強く勧められます。 同期において、NTPかどんなSNTPクライアントも別のSNTPクライアントに依存していないところでSNTPクライアントはサブネットの葉(最も高い層)においてだけ構成で働くべきです。 高信頼のラジオかモデム時間指定サービス以外の同期の他のどんな源も利用可能でないところでSNTPサーバはサブネットの根(層1)においてそして、構成だけで作動するべきです。 通常、プライマリサーバに予想された完全な度合いの信頼性は、完全なNTP実装の余分なソース、さまざまのサブネット経路、および作られたアルゴリズムを使用するだけであることで可能です。 これは複数のラジオの形で同期自体の一次資料に達するべきですか、または他のプライマリサーバへのモデムソースとバックアップ道はソースが失敗するか、または大部分が不正確な時間を提供するすべてに達するべきです。 したがって、プライマリサーバのNTPよりむしろSNTPの使用は慎重に考えられるべきです。
An important provision in this document is the reinterpretation of certain NTP Versino 4 header fields which provide for IPv6 and OSI addressing and optional anycast extensions designed specifically for multicast service. These additions are in conjunction with the proposed NTP Version 4 specification, which will appear as a separate document. The only difference between the current NTP Version 3 and proposed NTP Version 4 header formats is the interpretation of the four-octet Reference Identifier field, which is used primarily to detect and avoid synchronization loops. In Version 3 and Version 4 primary (stratum-1) servers, this field contains the four-character ASCII reference identifier defined later in this document. In Version 3 secondary servers and clients, it contains the 32-bit IPv4 address of the synchronization source. In Version 4 secondary servers and clients, it contains the low order 32 bits of the last transmit timestamp received from the synchronization source.
重要な支給は本書では特にマルチキャストサービスのために設計されたIPv6に備えるあるNTP Versino4ヘッダーフィールド、OSIアドレシング、および任意のanycast拡張子の「再-解釈」です。 これらの追加は提案されたNTPバージョン4仕様に関連しています。仕様は別々のドキュメントとして現れるでしょう。 現在のNTPバージョン3と提案されたNTPバージョン4ヘッダー形式の唯一の違いが4八重奏のReference Identifier分野の解釈です。(それは、主として同期輪を検出して、避けるのに使用されます)。 バージョン3とバージョン4のプライマリ(層-1)のサーバでは、この分野は後で本書では定義された4キャラクタのASCII参照識別子を含んでいます。 バージョン3セカンダリサーバとクライアントでは、それは同期ソースの32ビットのIPv4アドレスを含んでいます。 バージョン4セカンダリサーバとクライアントでは、それは同期ソースからタイムスタンプ受け取られていた状態で最終32ビットが伝える下位を含んでいます。
Mills Informational [Page 3] RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
1996年10月にIPv4、IPv6、およびOSIのために情報[3ページ]のRFC2030SNTPv4を製粉します。
In the case of OSI, the Connectionless Transport Service (CLTS) is used [ISO86]. Each SNTP packet is transmitted as tht TS-Userdata parameter of a T-UNITDATA Request primitive. Alternately, the header can be encapsulated in a TPDU which itself is transported using UDP [DOB91]. It is not advised that NTP be operated at the upper layers of the OSI stack, such as might be inferred from [FUR94], as this could seriously degrade accuracy. With the header formats defined in this document, it is in principle possible to interwork between servers and clients of one protocol family and another, although the practical difficulties may make this inadvisable.
OSIの場合Connectionless Transport Service(CLTS)は使用されています[ISO86]。 それぞれのSNTPパケットはT-UNITDATA Requestのtht TS-Userdataパラメタとして原始的に伝えられます。 交互に、UDP[DOB91]を使用することでそれ自体で輸送されるTPDUでヘッダーをカプセルに入れることができます。 NTPが[FUR94]から推論されるかもしれないようなOSIスタックの上側の層で操作されると忠告されません、これが真剣に精度を下げることができたとき。 ヘッダー形式が本書では定義されている状態で、それは原則として1つのプロトコルファミリーと別のもののサーバとクライアントの間で織り込むのにおいて可能です、これは実用的な困難で勧められなくなるかもしれませんが。
In the following, indented paragraphs such as this one contain
information not required by the formal protocol specification, but
considered good practice in protocol implementations.
以下では、あるものが正式なプロトコル仕様によって必要とされなかった情報を含みましたが、良い習慣を考えたこれなどの入り込まれたパラグラフは実装について議定書の中で述べます。
2. Operating Modes and Addressing
2. オペレーティング・モードとアドレシング
SNTP Version 4 can operate in either unicast (point to point), multicast (point to multipoint) or anycast (multipoint to point) modes. A unicast client sends a request to a designated server at its unicast address 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 multicast server periodically sends a unsolicited message to a designated IPv4 or IPv6 local broadcast address or multicast group address and ordinarily expects no requests from clients. A multicast client listens on this address and ordinarily sends no requests. An anycast client sends a request to a designated IPv4 or IPv6 local broadcast address or multicast group address. One or more anycast servers reply with their individual unicast addresses. The client binds to the first one received, then continues operation in unicast mode.
SNTPバージョン4はどちらのユニキャスト(ポイント・ツー・ポイント)(マルチキャスト(多点を示す)かanycast(示す多点)モード)でも作動できます。 ユニキャストクライアントは、ユニキャストアドレスの指定されたサーバに要求を送って、それが時間を決定できる回答を予想します、そして、任意に、往復の遅れと地方の時計はサーバに比例して相殺されます。マルチキャストサーバは、定期的に指定されたIPv4、IPv6のローカルの放送演説またはマルチキャストグループアドレスにお節介なメッセージを送って、通常、クライアントからの要求を全く予想しません。 マルチキャストクライアントは、このアドレスで聴いて、通常、要求を全く送りません。 anycastクライアントは指定されたIPv4、IPv6のローカルの放送演説またはマルチキャストグループアドレスに要求を送ります。 1つ以上のanycastサーバがそれらの個々のユニキャストアドレスで返答します。 最初のものへのクライアントひもは受信されて、ユニキャストモードにおける操作はその時、続きます。
Multicast servers should respond to client unicast requests, as
well as send unsolicited multicast messages. Multicast clients may
send unicast requests in order to determine the network
propagation delay between the server and client and then continue
operation in multicast mode.
マルチキャストサーバは、クライアントユニキャスト要求に応じて、求められていないマルチキャストメッセージを送るべきです。 マルチキャストクライアントは、サーバとクライアントの間でネットワーク伝播遅延を決定して、次に、マルチキャストモードで操作を続けるためにユニキャスト要求を送るかもしれません。
In unicast mode, the client and server end-system addresses are assigned following the usual IPv4, IPv6 or OSI conventions. In multicast mode, the server uses a designated local broadcast address or multicast group address. An IP local broadcast address has scope limited to a single IP subnet, since routers do not propagate IP broadcast datagrams. On the other hand, an IP multicast group address has scope extending to potentially the entire Internet. The scoping, routing and group membership procedures are determined by considerations beyond the scope of this document. For IPv4, the IANA has assigned the multicast group address 224.0.1.1 for NTP, which is
ユニキャストモードで、普通のIPv4、IPv6またはOSIコンベンションに続いて、クライアントとサーバエンドシステムアドレスは選任されます。 マルチキャストモードで、サーバは指定されたローカル放送アドレスかマルチキャストグループアドレスを使用します。 IPローカル放送アドレスで範囲をただ一つのIPサブネットに制限します、ルータがIPブロードキャスト・データグラムを伝播しないので。他方では、IPマルチキャストグループアドレスで、範囲は潜在的に全体のインターネットに広がります。 見る、ルーティング、およびグループ会員資格手順はこのドキュメントの範囲を超えた問題で決定します。 IPv4に関しては、IANAはNTPのためにマルチキャストグループアドレス224.0.1.1を割り当てて、どれがありますか?
Mills Informational [Page 4] RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
1996年10月にIPv4、IPv6、およびOSIのために情報[4ページ]のRFC2030SNTPv4を製粉します。
used both by multicast servers and anycast clients. NTP multicast addresses for IPv6 and OSI have yet to be determined.
マルチキャストサーバとanycastクライアントによって使用されます。 IPv6とOSIのためのNTPマルチキャストアドレスはまだ決定していません。
Multicast clients listen on the designated local broadcast address or multicast group address. In the case of local broadcast addresses, no further provisions are necessary. In the case of IP multicast addresses, the multicast client and anycast server must implement the Internet Group Management Protocol (IGMP) [DEE89], in order that the local router joins the multicast group and relays messages to the IPv4 or IPv6 multicast group addresses assigned by the IANA. Other than the IP addressing conventions and IGMP, there is no difference in server or client operations with either the local broadcast address or multicast group address.
マルチキャストクライアントは指定されたローカル放送アドレスかマルチキャストグループアドレスで聴きます。 ローカル放送アドレスの場合では、さらなるどんな条項も必要ではありません。 IPマルチキャストアドレスの場合では、マルチキャストクライアントとanycastサーバは、インターネットがGroup Managementプロトコル(IGMP)[DEE89]であると実装しなければなりません、ローカルルータがアドレスがIANAで割り当てたIPv4かIPv6マルチキャストグループにマルチキャストグループに加わって、メッセージをリレーするように。 コンベンションとIGMPに演説するIP以外に、ローカル放送アドレスかマルチキャストグループが扱うどちらかがあるサーバかクライアント操作の違いが全くありません。
It is important to adjust the time-to-live (TTL) field in the IP
header of multicast messages to a reasonable value, in order to
limit the network resources used by this (and any other) multicast
service. Only multicast clients in scope will receive multicast
server messages. Only cooperating anycast servers in scope will
reply to a client request. The engineering principles which
determine the proper value to be used are beyond the scope of this
document.
マルチキャストメッセージのIPヘッダーの生きる時間(TTL)分野を適正価値に調整するのは重要です、この(そして、いかなる他の)マルチキャストサービスで使用されるネットワーク資源を制限するために。 範囲のマルチキャストクライアントだけがマルチキャストサーバメッセージを受け取るでしょう。 協力するだけであって、範囲のanycastサーバはクライアント要求に答えるでしょう。 固有値が使用されることを決定する工学原理はこのドキュメントの範囲を超えています。
Anycast mode is designed for use with a set of cooperating servers whose addresses are not known beforehand by the client. An anycast client sends a request to the designated local broadcast or multicast group address as described below. For this purpose, the NTP multicast group address assigned by the IANA is used. One or more anycast servers listen on the designated local broadcast address or multicast group address. Each anycast server, upon receiving a request, sends a unicast reply message to the originating client. The client then binds to the first such message received and continues operation in unicast mode. Subsequent replies from other anycast servers are ignored.
Anycastモードは使用のためにアドレスがあらかじめクライアントによって知られていない1セットの協力サーバで設計されています。 anycastクライアントは以下で説明されるように指定されたローカル放送かマルチキャストグループアドレスに要求を送ります。 このために、IANAによって割り当てられたNTPマルチキャストグループアドレスは使用されています。 1つ以上のanycastサーバが指定されたローカル放送アドレスかマルチキャストグループアドレスで聴かれます。 要求を受け取るとき、それぞれのanycastサーバはユニキャスト応答メッセージを起因しているクライアントに送ります。 クライアントは、次に、そのようなメッセージが受け取った1日に付いて、ユニキャストモードで操作を続けています。 他のanycastサーバからのその後の回答は無視されます。
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 IPv4
multicast group address assigned by the IANA. Where necessary,
access control based on the server source address can be used to
select only the designated server known to and trusted by the
client. The use of cryptographic authentication scheme defined in
RFC-1305 is optional; however, implementors should be advised that
extensions to this scheme are planned specifically for NTP
multicast and anycast modes.
指定されるとしてのSNTPの場合には、ここに、SNTPマルチキャストクライアントがふらちな事をしながら混乱させられることができる非常に本当の脆弱性、敵軍のSNTPまたはNTPマルチキャストサーバがインターネットのほかの場所にあります、現在のところそのようなすべてのサーバがIANAによって割り当てられた同じIPv4マルチキャストグループアドレスを使用するので。 必要であるところでは、クライアントによって知られていて信じられた状態で指定されたサーバだけを選択するのにサーバソースアドレスに基づくアクセスコントロールは使用できます。 RFC-1305で定義された暗号の認証体系の使用は任意です。 しかしながら、作成者はこの体系への拡大が特にNTPマルチキャストとanycastモードのために計画されていると忠告されるべきです。
Mills Informational [Page 5] RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
1996年10月にIPv4、IPv6、およびOSIのために情報[5ページ]のRFC2030SNTPv4を製粉します。
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 dependent SNTP multicast clients on the same subnet, while IP
multicast group addresses will be used only in cases where the TTL
is engineered specifically for each service domain.
SNTP仕様に不可欠でない間、IP放送演説が同じサブネットの多くの依存するSNTPマルチキャストクライアントと共に主として完全に機能的なNTPサーバを含むIPサブネットとLANセグメントに使用されることを意図します、IPマルチキャストグループアドレスはTTLが特にそれぞれのサービスドメインに設計される場合だけに使用されるでしょうが。
In NTP Version 3, the reference identifier was often used to
walk-back the synchronization subnet to the root (primary server)
for management purposes. In NTP Version 4, this feature is not
available, since the addresses are longer than 32 bits. However,
the intent in the protocol design was to provide a way to detect
and avoid loops. A peer could determine that a loop was possible
by comparing the contents of this field with the IPv4 destination
address in the same packet. A NTP Version 4 server can accomplish
the same thing by comparing the contents of this field with the
low order 32 bits of the originate timestamp in the same packet.
There is a small possibility of false alarm in this scheme, but
the false alarm rate can be minimized by randomizing the low order
unused bits of the transmit timestamp.
NTPバージョン3参照識別子は管理目的のために根(プライマリサーバ)に同期サブネットを歩いて帰らせるのにおいてしばしば使用されていました。 NTPバージョン4では、アドレスが32ビットより長いので、この特徴は利用可能ではありません。 しかしながら、プロトコルデザインにおける意図は輪を検出して、避ける方法を提供することでした。 同輩は、輪が同じパケットでIPv4送付先アドレスとこの分野のコンテンツを比べることによって可能であったと決心できました。 NTPバージョン4サーバが安値があるこの分野の内容が32ビットを配置する比較するのによる同じものを達成できる、同じパケットでタイムスタンプを溯源してください。 この体系における、間違い警報のa小さい可能性がありますが、安値が未使用のビットを配置するランダム化で間違い警報レートを最小にすることができる、タイムスタンプを伝えてください。
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 can be set to 0.
NTPタイムスタンプが大事にされたデータであり、事実上プロトコルの主産物を表すので、特別なタイムスタンプ形式は確立されました。 NTPタイムスタンプは秒に64ビットの未署名の固定小数点数として1900年1月1日の0hに比例して表されます。 最初の32ビットと最後の32ビットの小数部には整数部があります。 小数部では、非重要な下位を0に設定できます。
It is advisable to fill the non-significant low order bits of the
timestamp with a random, unbiased bitstring, both to avoid
systematic roundoff errors and as a means of loop detection and
replay detection (see below). One way of doing this is to generate
a random bitstring in a 64-bit word, then perform an arithmetic
right shift a number of bits equal to the number of significant
bits of the timestamp, then add the result to the original
timestamp.
ともに無作為の、そして、不遍のbitstringでタイムスタンプの非重要な下位のビットをいっぱいにして、系統的なロンダード誤りと輪の手段として検出を避けて、検出を再演するのは賢明です(以下を見てください)。 これをする1つの方法は、64ビットの単語における無作為のbitstringを生成して、次に、多くのビットがタイムスタンプの重要なビットの数と等しい正しい算数のシフトを実行して、次に、オリジナルのタイムスタンプに結果を追加することです。
Mills Informational [Page 6] RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
1996年10月にIPv4、IPv6、およびOSIのために情報[6ページ]のRFC2030SNTPv4を製粉します。
This format allows convenient multiple-precision arithmetic and conversion to UDP/TIME representation (seconds), but does complicate the conversion to ICMP Timestamp message representation, which is in milliseconds. The maximum number that can be represented is 4,294,967,295 seconds with a precision of about 200 picoseconds, which should be adequate for even the most exotic requirements.
ICMP Timestampメッセージ表現(ミリセカンドである)に変換を複雑にするのを除いて、この形式はUDP/タイム誌の表現(秒)に便利な複数の精度演算と変換を許します。 およそ200のピコセコンドの精度に従って、表すことができる最大数は42億9496万7295秒です。(最もエキゾチックな要件にさえ、ピコセコンドは適切であるべきです)。
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 (second 2,147,483,648) 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 (second 4,294,967,296). 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). 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年(2番目の21億4748万3648)に、最も重要なビット(整数部のビット0)が設定されて、64ビットの分野が2036年(2番目の42億9496万7296)にいつかあふれるいつかの時間以来それに注意してください。 NTPかSNTPが2036年に使用中であるなら、いくつかの外部の手段が、2036(そして、136年の他の倍数)に比例して1900に比例した時間と時間に資格を与えるために必要になるでしょう。 64ビットの分野が0になるときの今後は136年毎に無視された無効の、または、入手できないタイムスタンプとしてコンベンションによって解釈される200ピコセコンドの間隔は存在するでしょう。
As the NTP timestamp format has been in use for the last 17 years,
it remains a possibility that it will be in use 40 years from now
when the seconds field overflows. As it is probably inappropriate
to archive NTP timestamps before bit 0 was set in 1968, a
convenient way to extend the useful life of NTP timestamps is the
following convention: If bit 0 is set, the UTC time is in the
range 1968-2036 and UTC time is reckoned from 0h 0m 0s UTC on 1
January 1900. If bit 0 is not set, the time is in the range 2036-
2104 and UTC time is reckoned from 6h 28m 16s UTC on 7 February
2036. Note that when calculating the correspondence, 2000 is not a
leap year. Note also that leap seconds are not counted in the
reckoning.
NTPタイムスタンプ形式がここ17年間使用中であるときに、現在から40年間使用中になる可能性のままで、秒分野がいつあふれるかは残っています。 ビット0が1968年に設定される前にNTPタイムスタンプを格納するのがたぶん不適当であるので、NTPタイムスタンプの役に立つ寿命を伸ばす便利な方法は以下のコンベンションです: ビット0が設定されるなら、UTC時間が範囲1968-2036にあります、そして、UTC時間は1900年1月1日に0mの0h0UTCから数えられます。 ビット0が設定されないなら、時間が範囲2036- 2104にあります、そして、UTC時間は2036年2月7日に28mの6h16年代のUTCから数えられます。 通信について計算するとき、2000がうるう年でないことに注意してください。 また、飛躍秒が計算で数えられないことに注意してください。
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 detailed 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 Informational [Page 7] RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
1996年10月にIPv4、IPv6、およびOSIのために情報[7ページ]のRFC2030SNTPv4を製粉します。
Below is a description of the NTP/SNTP Version 4 message format, which follows the IP and UDP headers. This format is identical to that described in RFC-1305, with the exception of the contents of the reference identifier field. The header fields are defined as follows:
以下に、NTP/SNTPバージョン4メッセージ・フォーマットの記述があります。(メッセージ・フォーマットはIPとUDPヘッダーに続きます)。 この形式は参照識別子分野のコンテンツを除いて、RFC-1305で説明されたそれと同じです。 ヘッダーフィールドは以下の通り定義されます:
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) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Identifier (optional) (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Message Digest (optional) (128) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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)を伝えてください。| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 主要な識別子(任意の)(32)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | メッセージダイジェスト(任意の)(128)| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Informational [Page 8] RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
1996年10月にIPv4、IPv6、およびOSIのために情報[8ページ]のRFC2030SNTPv4を製粉します。
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/SNTP version number. The version number is 3 for Version 3 (IPv4 only) and 4 for Version 4 (IPv4, IPv6 and OSI). If necessary to distinguish between IPv4, IPv6 and OSI, the encapsulating context must be inspected.
バージョン数の(vn): これはNTP/SNTPバージョン番号を示す3ビットの整数です。 バージョン番号は、バージョン3のための3(IPv4専用)とバージョン4のための4(IPv4、IPv6、およびOSI)です。 必要なら、IPv4、IPv6、およびOSIを見分けるために、要約文脈を点検しなければなりません。
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 and anycast modes, the client sets this field to 3 (client) in the request and the server sets it to 4 (server) in the reply. In multicast mode, the server sets this field to 5 (broadcast).
ユニキャストとanycastモードで、クライアントは要求における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つの入手できないプライマリ参照(例えば、ラジオ時計)
Mills Informational [Page 9] RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
1996年10月にIPv4、IPv6、およびOSIのために情報[9ページ]のRFC2030SNTPv4を製粉します。
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秒間)だけを使用します。
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 Identifier: This is a 32-bit bitstring identifying the particular reference source. In the case of NTP Version 3 or Version 4 stratum-0 (unspecified) or stratum-1 (primary) servers, this is a four-character ASCII string, left justified and zero padded to 32 bits. In NTP Version 3 secondary servers, this is the 32-bit IPv4 address of the reference source. In NTP Version 4 secondary servers, this is the low order 32 bits of the latest transmit timestamp of the reference source. NTP primary (stratum 1) servers should set this field to a code identifying the external reference source according to the following list. If the external reference is one of those listed, the associated code should be used. Codes for sources not listed can be contrived as appropriate.
参照識別子: これは特定の照合線源を特定しながらbitstringされる32ビットです。 NTPバージョン3かバージョン4層-0(不特定の)か層-1の(プライマリ)のサーバの場合では、これは正当化されるように残っている4キャラクタのASCIIストリングです、そして、ゼロは32ビットにそっと歩きました。 NTPバージョン3セカンダリサーバでは、これは照合線源の32ビットのIPv4アドレスです。 NTPバージョン4セカンダリサーバでは、これは照合線源のタイムスタンプを伝える安値が、最新のものの32ビットを配置することです。 NTPのプライマリ(層1)のサーバは以下のリストによると、外部参照ソースを特定するコードにこの分野を設定するべきです。 外部参照が記載されたものの1つであるなら、関連コードは使用されるべきです。 情報筋が記載しなかったので、適宜コードを案出できます。
Mills Informational [Page 10] RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
1996年10月にIPv4、IPv6、およびOSIのために情報[10ページ]のRFC2030SNTPv4を製粉します。
Code External Reference Source
----------------------------------------------------------------
LOCL uncalibrated local clock used as a primary reference for
a subnet without external means of synchronization
PPS atomic clock or other pulse-per-second source
individually calibrated to national standards
ACTS NIST dialup modem service
USNO USNO modem service
PTB PTB (Germany) modem service
TDF Allouis (France) Radio 164 kHz
DCF Mainflingen (Germany) Radio 77.5 kHz
MSF Rugby (UK) Radio 60 kHz
WWV Ft. Collins (US) Radio 2.5, 5, 10, 15, 20 MHz
WWVB Boulder (US) Radio 60 kHz
WWVH Kaui Hawaii (US) Radio 2.5, 5, 10, 15 MHz
CHU Ottawa (Canada) Radio 3330, 7335, 14670 kHz
LORC LORAN-C radionavigation system
OMEG OMEGA radionavigation system
GPS Global Positioning Service
GOES Geostationary Orbit Environment Satellite
コード外部参照ソース---------------------------------------------------------------- サブネットのプライマリ参照として同期PPS原子時計の外部の手段なしで使用されるLOCL uncalibratedの地方の時計か他の1セカンドソースあたりのパルスが個別にMSF Rugby(イギリス)ラジオ60kHz WWV Ftを国家規格ACTS NISTダイアルアップモデムサービスUSNO USNOモデムサービスPTB PTB(ドイツ)モデムサービスTDF Allouis(フランス)ラジオ164kHz DCF Mainflingen(ドイツ)ラジオ77.5kHzまで較正しました。 2.5、5、10、15MHzの2.5、5、10、15、20MHzのコリンズ(米国)・ラジオWWVBボウルダー(米国)60kHzのラジオWWVH Kauiハワイ(米国)ラジオCHUオタワ(カナダ)ラジオ3330、7335、14670kHz LORC LORAN-C無線航法システムOMEG OMEGA無線航法システムGPS Global Positioning ServiceゴエスGeostationary Orbit Environment Satellite
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 scheme is implemented, the Key Identifier and Message Digest fields contain the message authentication code (MAC) information defined in Appendix C of RFC-1305.
固有識別文字(任意の): NTP認証体系が実装されるとき、Key IdentifierとMessage Digest分野はRFC-1305のAppendix Cで定義されたメッセージ確認コード(MAC)情報を含んでいます。
5. SNTP Client Operations
5. SNTPクライアント操作
A SNTP client can operate in multicast mode, unicast mode or anycast mode. In multicast mode, the client sends no request and waits for a broadcast (mode 5) from a designated multicast server. In unicast mode, the client sends a request (mode 3) to a designated unicast server and expects a reply (mode 4) from that server. In anycast mode, the client sends a request (mode 3) to a designated local broadcast or multicast group address and expects a reply (mode 4) from one or more anycast servers. The client uses the first reply
SNTPクライアントはマルチキャストモード、ユニキャストモードまたはanycastモードで働くことができます。 マルチキャストモードで、クライアントは、要求を全く送らないで、指定されたマルチキャストサーバから放送(モード5)を待ちます。クライアントは、ユニキャストモードで、要求(モード3)を指定されたユニキャストサーバに送って、そのサーバから回答(モード4)を予想します。anycastモードで、クライアントは、要求(モード3)を指定されたローカル放送かマルチキャストグループアドレスに送って、1つ以上のanycastサーバから回答(モード4)を予想します。 クライアントは最初の回答を使用します。
Mills Informational [Page 11] RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
1996年10月にIPv4、IPv6、およびOSIのために情報[11ページ]のRFC2030SNTPv4を製粉します。
received to establish the particular server for subsequent unicast operations. Later replies from this server (duplicates) or any other server are ignored. Other than the selection of address in the request, the operations of anycast and unicast clients are identical. Requests are normally sent at intervals from 64 s to 1024 s, depending on the frequency tolerance of the client clock and the required accuracy.
その後のユニキャスト操作のための特定のサーバを証明するために、受け取ります。 その後、このサーバ(写し)からの回答かいかなる他のサーバも無視されます。 要求における、アドレスの選択を除いて、anycastとユニキャストクライアントの操作は同じです。 64秒間から1024秒間までの間隔を置いて、通常、要求を送ります、クライアント時計と必要な精度の周波数公差によって。
A unicast or anycast client initializes the NTP message header, sends the request to the server and strips the time of day from the Transmit Timestamp field of the reply. For this purpose, all of the NTP header fields shown above can be set to 0, except the first octet and (optional) Transmit Timestamp fields. In the first 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 version number of the NTP/SNTP server; however, Version 4 servers will also accept previous versions. Version 3 (RFC-1305) and Version 2 (RFC-1119) servers already accept all previous versions, including Version 1 (RFC-1059). Note that Version 0 (RFC-959) is no longer supported by any other version.
ユニキャストかanycastクライアントが、NTPメッセージヘッダーを初期化して、要求をサーバに送って、Transmit Timestamp分野からの時刻から回答を奪い取ります。 このために、上に示されたNTPヘッダーフィールドのすべてが、最初の八重奏を除いて、0に設定されて、Timestamp野原を伝えることができます(任意の)。 最初の八重奏では、LI分野は0(警告しない)に設定されます、そして、Mode分野は3(クライアント)に設定されます。 VN分野はNTP/SNTPサーバのバージョン番号に同意しなければなりません。 しかしながら、また、バージョン4サーバは旧バージョンを受け入れるでしょう。 バージョン3(RFC-1305)とバージョン2(RFC-1119)サーバは既にバージョン1(RFC-1059)を含むすべての旧バージョンを受け入れます。 バージョン0(RFC-959)がもういかなる他のバージョンによってもサポートされないことに注意してください。
Since there will probably continue to be NTP and SNTP servers of all four versions interoperating in the Internet, careful consideration should be given to the version used by SNTP Version 4 clients. It is recommended that clients use the latest version known to be supported by the selected server in the interest of the highest accuracy and reliability. SNTP Version 4 clients can interoperate with all previous version NTP and SNTP servers, since the header fields used by SNTP clients are unchanged. Version 4 servers are required to reply in the same version as the request, so the VN field of the request also specifies the version of the reply.
たぶん続くので、NTPとインターネットに共同利用するすべての4つのバージョンのSNTPサーバ、熟慮をバージョンに与えるべきであるということであることはSNTPバージョンで4人のクライアントを使用しました。 クライアントが最も高い精度と信頼性のために選択されたサーバによってサポートされるのが知られている最新版を使用するのは、お勧めです。 4人のクライアントがすべての旧バージョンNTPとSNTPサーバで共同利用できるSNTPバージョン、SNTPによって使用されたヘッダーフィールド以来、クライアントは変わりがありません。 要求と同じバージョンで返答する4つのサーバが必要であるバージョンによって、また、要求のVN分野は回答のバージョンを指定します。
While not necessary in a conforming client implementation, in unicast and anycast modes it highly recommended that the transmit timestamp in the request is set to the time of day according to the client clock in NTP timestamp format. This allows a simple calculation to determine the propagation delay between the server and client and to align the local clock generally within a few tens of milliseconds relative to the server. In addition, this provides a simple method to verify that the server reply is in fact a legitimate response to the specific client request and avoid replays. In multicast mode, the client has no information to calculate the propagation delay or determine the validity of the server, unless the NTP authentication scheme is used.
タイムスタンプを伝えてください。従っているクライアント実装では必要ではありませんが、ユニキャストとanycastモードで、それを強く推薦した、要求に、NTPタイムスタンプ形式におけるクライアント時計に従った時刻へのセットがあります。 これで、簡単な計算は、サーバとクライアントの間の伝播遅延を決定して、サーバに比例して一般にいくつかの中の地方の時計を何十ミリセカンドもと同じくらい並べます。さらに、事実上、サーバ回答が特定のクライアント要求への正統の応答であることを確かめて、再生を避ける簡単なメソッドを前提とします。 クライアントには、マルチキャストモードで、伝播遅延について計算するか、またはサーバの正当性を決定する情報が全くありません、NTP認証体系が使用されていない場合。
To calculate the roundtrip delay d and local clock offset t relative to the server, the client sets the transmit timestamp in the request to the time of day according to the client clock in NTP timestamp
往復の遅れdと地方の時計について計算するのはサーバに比例してtを相殺しました、クライアントセット、NTPタイムスタンプのクライアント時計に従って、要求におけるタイムスタンプを時刻に伝えてください。
Mills Informational [Page 12] RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
1996年10月にIPv4、IPv6、およびOSIのために情報[12ページ]のRFC2030SNTPv4を製粉します。
format. The server copies this field to the originate timestamp in the reply and sets the receive timestamp and transmit timestamp to the time of day according to the server clock in NTP timestamp format.
形式。 サーバがこの分野をコピーする、回答とセットでタイムスタンプを溯源してください、タイムスタンプを受け取ってください、そして、サーバ時計に従って、NTPタイムスタンプ形式でタイムスタンプを時刻に伝えてください。
When the server reply is received, the client determines a Destination Timestamp variable as the time of arrival according to its clock in NTP timestamp format. The following table summarizes the four timestamps.
サーバ回答が受け取られているとき、時計に従って、クライアントは到着時刻としてNTPタイムスタンプ形式でDestination Timestamp変数を決定します。 以下のテーブルは4つのタイムスタンプをまとめます。
Timestamp Name ID When Generated
------------------------------------------------------------
Originate Timestamp T1 time request sent by client
Receive Timestamp T2 time request received by server
Transmit Timestamp T3 time reply sent by server
Destination Timestamp T4 time reply received by 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 summarizes the SNTP client operations in unicast, anycast and multicast modes. The recommended error checks are shown in the Reply and Multicast columns in the table. The message should be considered valid only if all the fields shown contain values in the respective ranges. Whether to believe the message if one or more of the fields marked "ignore" contain invalid values is at the discretion of the implementation.
以下のテーブルはユニキャスト、anycast、およびマルチキャストモードにおけるSNTPクライアント操作をまとめます。 お勧めのエラーチェックはテーブルのReplyとMulticastコラムに示されます。 示されたすべての分野がそれぞれの範囲に値を保管している場合にだけ、メッセージは有効であると考えられるべきです。 「無視」であることが示される分野の1つ以上が無効の値を含んでいるなら実装の裁量にはメッセージがあると信じるのであるかどうか
Field Name Unicast/Anycast Multicast
Request Reply
----------------------------------------------------------
LI 0 0-2 0-2
VN 1-4 copied from 1-4
request
Mode 3 4 5
Stratum 0 1-14 1-14
Poll 0 ignore ignore
Precision 0 ignore ignore
Root Delay 0 ignore ignore
Root Dispersion 0 ignore ignore
Reference Identifier 0 ignore ignore
Reference Timestamp 0 ignore ignore
Originate Timestamp 0 (see text) ignore
Receive Timestamp 0 (see text) ignore
Transmit Timestamp (see text) nonzero nonzero
Authenticator optional optional optional
フィールド名ユニキャスト/Anycastマルチキャスト要求回答---------------------------------------------------------- 無視する1-4からコピーされた無視する無視する無視する1-14 Poll0がPrecision0を無視するStratum0 1-14がRoot Delay0を無視する要求Mode3 4 5が0が無視するRootディアスポラを無視するVN1-4が、無視するReference Identifier0がReference Timestampを無視するLI0 0-2 0-2がOriginate Timestamp0を無視する、(テキストを見てください)0が、無視する無視、Receive Timestamp0(テキストを見ます)が任意の状態でTransmit Timestamp(テキストを見る)非零非零Authenticatorを無視する、任意である、任意
Mills Informational [Page 13] RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
1996年10月にIPv4、IPv6、およびOSIのために情報[13ページ]のRFC2030SNTPv4を製粉します。
6. SNTP Server Operations
6. SNTPサーバ操作
A SNTP Version 4 server operating with either a NTP or SNTP client of the same or previous versions retains 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, a SNTP server should be operated only in conjunction with a source of external synchronization, such as a reliable radio clock or telephone modem. In this case it always operates as a primary (stratum 1) server.
同じくらいのNTPかSNTPクライアントかバージョンのどちらかで前の作動するSNTPバージョン4サーバはどんな永続的な状態も保有しません。 SNTPサーバが通常余分な同輩とさまざまのネットワーク経路をサポートすることを意図するNTPアルゴリズムのフルセットを実装しないので、SNTPサーバは外部同期の源に関連してだけ操作されるべきです、高信頼のラジオ時計や電話モデムのように。 この場合、それはプライマリ(層1)のサーバとしていつも作動します。
A SNTP server can operate in unicast mode, anycast mode, multicast mode or any combination of these modes. In unicast and anycast modes, the server receives a request (mode 3), modifies certain fields in the NTP header, and sends a reply (mode 4), possibly using the same message buffer as the request. In anycast mode, the server listens on the designated local broadcast or multicast group address assigned by the IANA, but uses its own unicast address in the source address field of the reply. Other than the selection of address in the reply, the operations of anycast and unicast servers are identical. Multicast messages are normally sent at poll intervals from 64 s to 1024 s, depending on the expected frequency tolerance of the client clocks and the required accuracy.
SNTPサーバはこれらのモードのユニキャストモード、anycastモード、マルチキャストモードまたはどんな組み合わせでも作動できます。 ユニキャストとanycastモードで、サーバは、要求(モード3)を受け取って、NTPヘッダーのある一定の分野を変更して、返信します(モード4)、ことによると要求と同じメッセージ・バッファを使用して。 anycastモードで、サーバは、IANAによって割り当てられた指定されたローカル放送かマルチキャストグループアドレスで聴きますが、回答のソースアドレス・フィールドでそれ自身のユニキャストアドレスを使用します。 回答における、アドレスの選択を除いて、anycastとユニキャストサーバの操作は同じです。 64秒間から1024秒間までの投票間隔を置いて、通常、マルチキャストメッセージを送ります、クライアント時計と必要な精度の期待度数寛容によって。
In unicast and anycast modes, 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. This allows clients configured in symmetric active (mode 1) to interoperate successfully, even if configured in possibly suboptimal ways. In multicast (unsolicited) mode, the VN field is set to 4, the Mode field is set to 5 (broadcast), and the Poll field set to the nearest integer base-2 logarithm of the poll interval.
ユニキャストとanycastモードで、要求のVNとPoll分野は回答に完全な状態でコピーされます。 要求のMode分野が3(クライアント)であるなら、それは回答で4(サーバ)に設定されます。 さもなければ、この分野は、NTP仕様に従うために2(左右対称の受動態)に設定されます。 ことによると準最適の方法で構成されても、これは首尾よく共同利用するためにアクティブな状態で(モード1)左右対称で構成されたクライアントを許容します。 マルチキャストの(求められていません)のモードで、VN分野は4に設定されました、そして、Mode分野は5に設定されました、そして、(放送してください)Poll分野は投票間隔の最も近い整数ベース-2対数にセットしました。
Note that it is highly desirable that, if a server supports
multicast mode, it also supports unicast mode. This is so a
potential multicast client can calculate the propagation delay
using a client/server exchange prior to regular operation using
only multicast mode. If the server supports anycast mode, then it
must support unicast mode. There does not seem to be a great
advantage to operate both multicast and anycast modes at the same
time, although the protocol specification does not forbid it.
また、サーバがマルチキャストモードをサポートするならユニキャストモードをサポートするのが、非常に望ましいことに注意してください。 これは、潜在的マルチキャストクライアントが正常な操業の前にマルチキャストモードだけを使用することでクライアント/サーバ交換を使用することで伝播遅延について計算できるようにそうです。 サーバが、anycastがモードであるとサポートするなら、それはユニキャストモードをサポートしなければなりません。 同時にマルチキャストとanycastモードの両方を操作するかなりの利点はあるように思えません、プロトコル仕様がそれを禁じませんが。
In unicast and anycast modes, 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 multicast mode, the server sends broadcasts only if synchronized to a correctly
ユニキャストとanycastモードで、正しく稼働しているラジオ時計に連動しないなら、サーバは反応するかもしれませんが、都合のよいオプションは応じることです、これが、可到達性が同期状態にかかわらず決定しているのを許容するので。 マルチキャストモードで、正しくaに連動する場合にだけ、サーバは放送を送ります。
Mills Informational [Page 14] RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
1996年10月にIPv4、IPv6、およびOSIのために情報[14ページ]のRFC2030SNTPv4を製粉します。
operating reference clock.
基準クロックを操作します。
The remaining fields of the NTP header are set in the following way. Assuming the server is synchronized to a radio clock or other primary reference source and operating correctly, the LI field is set to 0 and the Stratum field is set to 1 (primary server); 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 of Section 5 of this document.
NTPヘッダーの残っているフィールドは以下の方法で設定されます。 サーバを仮定するのはラジオ時計か他のプライマリ照合線源と正しく作動すると連動します、そして、LI分野は0に設定されます、そして、Stratum分野は1(プライマリサーバ)に設定されます。 そうでなければ、Stratum分野は0に設定されます、そして、LI分野は3に設定されます。 Precision分野が地方の時計の最大の読み込み誤りを反映するように設定されます。 すべての実用的なケースにおいて、それは重要なビットの数の否定的としてNTPタイムスタンプ形式で小数点の右に計算されます。 Root DelayとRootディアスポラ分野はプライマリサーバのために0に用意ができています。 任意に、ラジオ時計自体の最大の期待誤差に対応する値にRootディアスポラ分野を設定できます。 Reference Identifierはプライマリ照合線源を任命するように用意ができています、このドキュメントのセクション5のテーブルにみられるように。
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 modem. In unicast and anycast modes, the Receive Timestamp and Transmit Timestamp fields are set to the time of day when the message is sent and 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 avoid replays. In multicast mode, the Originate Timestamp and Receive Timestamp fields are set to 0 and the Transmit Timestamp field is set to the time of day when the message is sent. The following table summarizes these actions.
タイムスタンプ分野は以下の通り設定されます。 サーバが非連動するか、または最初に来るなら、すべてのタイムスタンプ分野がゼロに設定されます。 連動するなら、Reference Timestampはアップデートがラジオ時計かモデムから受けられた時に用意ができています。 メッセージを送って、要求のTransmit Timestamp分野から変わりがない状態でOriginate Timestamp分野をコピーするとき、ユニキャストとanycastモードで、Receive TimestampとTransmit Timestamp分野は時刻に用意ができています。 NTPクライアントが再生を避けるのにそれを使用するのでこの分野が完全な状態でコピーされるのは、重要です。 マルチキャストモードで、Originate TimestampとReceive Timestamp分野は0に用意ができています、そして、メッセージを送るとき、Transmit Timestamp分野を時刻に設定します。 以下のテーブルはこれらの動作をまとめます。
Field Name Unicast/Anycast Multicast
Request Reply
----------------------------------------------------------
LI ignore 0 or 3 0 or 3
VN 1-4 copied from 4
request
Mode 3 2 or 4 5
Stratum ignore 1 1
Poll ignore copied from log2 poll
request interval
Precision ignore -log2 server -log2 server
significant significant
bits bits
Root Delay ignore 0 0
Root Dispersion ignore 0 0
Reference Identifier ignore source ident source ident
Reference Timestamp ignore time of last time of last
radio update radio update
フィールド名ユニキャスト/Anycastマルチキャスト要求回答---------------------------------------------------------- LIが4要求Mode3 2からコピーされた0か3 0か3VN1-4を無視するか、またはStratumが無視する4 5はPrecisionがソースのidentソースident Reference Timestampが調節するのを0 0Reference Identifierが、無視する0 0Rootディアスポラが、無視するビットRoot Delayが、無視する無視する最近のラジオアップデートラジオアップデートの最後の時間の-log2サーバ-log2サーバ重要な重要なビットを無視するlog2投票要求間隔からコピーされました1 1Pollが、無視する。
Mills Informational [Page 15] RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
1996年10月にIPv4、IPv6、およびOSIのために情報[15ページ]のRFC2030SNTPv4を製粉します。
Originate Timestamp ignore copied from 0
transmit
timestamp
Receive Timestamp ignore time of day 0
Transmit Timestamp (see text) time of day time of day
Authenticator optional optional optional
起因する、0からコピーする、Timestampが、無視する伝える、タイムスタンプReceive Timestampが時刻に、時刻に、時刻に、Authenticator任意の状態で0Transmit Timestamp(テキストを見る)を無視する、任意である、任意
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. Configuration and Management
7. 構成と管理
Initial setup for SNTP servers and clients can be done using a configuration file if a file system is available, or a serial port if not. It is intended that in-service management of NTP and SNTP Version 4 servers and clients be performed using SNMP and a suitable MIB to be published later. Ordinarily, SNTP servers and clients are expected to operate with little or no site-specific configuration, other than specifying the IP address and subnet mask or OSI NSAP address.
そうでなければ、ファイルシステムが利用可能であるなら構成ファイルを使用するか、またはシリアルポートがSNTPサーバとクライアントのための初期のセットアップにできます。 NTPとSNTPバージョン4サーバとクライアントの稼働中の管理が後で発行されるのにSNMPと適当なMIBを使用することで実行されることを意図します。 通常、SNTPサーバとクライアントがサイト特有の構成でまず作動しないと予想されます、IPアドレスとサブネットマスクかOSI NSAPアドレスを指定するのを除いて。
Unicast clients must be provided with the designated server name or address. If a server name is used, the address of one of more DNS servers must be provided. Multicast servers and anycast clients must be provided with the TTL and local broadcast or multicast group address. Anycast servers and multicast clients may be configured with a list of address-mask pairs for access control, so that only those clients or servers known to be trusted will be used. These servers and clients must implement the IGMP protocol and be provided with the local broadcast or multicast group address as well. The configuration data for cryptographic authentication is beyond the scope of this document.
指定されたサーバー名かアドレスをユニキャストクライアントに提供しなければなりません。 サーバー名が使用されているなら、より多くのDNSサーバの1つのアドレスを提供しなければなりません。 TTLとローカル放送かマルチキャストグループアドレスをマルチキャストサーバとanycastクライアントに提供しなければなりません。 Anycastサーバとマルチキャストクライアントはアクセスコントロールのためにアドレスマスク組のリストによって構成されるかもしれません、信じられるのが知られているそれらのクライアントかサーバだけが使用されるように。 これらのサーバとクライアントは、IGMPプロトコルを実装して、また、ローカル放送かマルチキャストグループアドレスを提供しなければなりません。 暗号の認証のためのコンフィギュレーション・データはこのドキュメントの範囲を超えています。
There are several scenarios which provide automatic server discovery and selection for SNTP clients with no pre-specified configuration, other than the IP address and subnet mask or OSI NSAP address. For a IP subnet or LAN segment including a fully functional NTP server, the clients can be configured for multicast mode using the local broadcast address. The same approach can be used with other servers using the multicast group address. In both cases, provision of an access control list is a good way to insure only trusted sources can be used to set the local clock.
IPアドレスとサブネットマスクかOSI NSAPアドレス以外のあらかじめ指定された構成がないと共に自動サーバー発見と選択をSNTPクライアントに提供するいくつかのシナリオがあります。 完全に機能的なNTPサーバを含むIPサブネットかLANセグメントにおいて、マルチキャストモードのためにローカル放送アドレスを使用することでクライアントを構成できます。 マルチキャストグループアドレスを使用する他のサーバと共に同じアプローチを使用できます。 どちらの場合も、アクセスコントロールリストの支給は地方の時計を設定するのに信頼できるソースしか使用できないのを保障する早道です。
Mills Informational [Page 16] RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
1996年10月にIPv4、IPv6、およびOSIのために情報[16ページ]のRFC2030SNTPv4を製粉します。
In another scenario suitable for an extended network with significant network propagation delays, clients can be configured for anycast mode, both upon initial startup and after some period when the currently selected unicast source has not been heard. Following the defined protocol, the client binds to the first reply heard and continues operation in unicast mode. In this mode the local clock can be automatically adjusted to compensate for the propagation delay.
重要なネットワーク伝播遅延によって拡大ネットワークに適した別のシナリオでは、anycastモード(初期の始動と現在選択されたユニキャストソースが聞かれていないいつかの期間の後の両方)のためにクライアントを構成できます。 定義されたプロトコルに従って、クライアントは、聞かれた最初の回答に付いて、ユニキャストモードで操作を続けています。 このモードで、伝播遅延を補うように自動的に地方の時計を調整できます。
In still another scenario suitable for any network and where multicast service is not available, the DNS can be set up with a common CNAME, like time.domain.net, and a list of address records for NTP servers in the same domain. Upon resolving time.domain.net and obtaining the list, the client selects a server at random and begins operation in unicast mode with that server. Many variations on this theme are possible.
何かネットワークに適したまだ別のシナリオであってマルチキャストサービスがどこで入手できないかで、一般的なCNAMEと共にDNSをセットアップできます、time.domain.net、および同じドメインのNTPサーバのためのアドレス記録のリストのように。 time.domain.netを決議して、リストを得ると、クライアントは、無作為にサーバを選択して、そのサーバでユニキャストモードで活動を開始します。このテーマの多くの変化が可能です。
8. Acknowledgements
8. 承認
Jeff Learman was helpful in developing the OSI model for this protocol. Ajit Thyagarajan provided valuable suggestions and corrections.
ジェフLearmanはこのプロトコルのためにOSIモデルを開発する際に役立っていました。 Ajit Thyagarajanは貴重な提案と修正を提供しました。
9. References
9. 参照
[COL94] Colella, R., R. Callon, E. Gardner, Y. Rekhter, "Guidelines for OSI NSAP allocation in the Internet", RFC 1629, NIST, May 1994.
[COL94] Colella、R.、R.Callon、E.ガードナー、Y.Rekhter、「インターネットでのOSI NSAP配分のためのガイドライン」、RFC1629、NIST(1994年5月)。
[DAR81] Postel, J., "Internet Protocol", STD 5, RFC 791, USC Information Sciences Institute, September 1981.
[DAR81] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、科学が1981年9月に設けるUSC情報。
[DEE89] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, Stanford University, August 1989.
[DEE89] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、スタンフォード大学、1989年8月。
[DEE96] Deering, S., R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, Xerox and Ipsilon, January 1996.
[DEE96] デアリングとS.とR.Hindenと「インターネットプロトコル、バージョン6(IPv6)仕様」とRFC1883とゼロックスとIpsilon、1996年1月。
[DOB91] Dobbins, K, W. Haggerty, C. Shue, "OSI connectionless transport services on top of UDP - Version: 1", RFC 1240, Open Software Foundation, June 1991.
[DOB91]ドビンズ、K、W.ハガティ、C.シュー、「UDPの上のOSIのコネクションレスな輸送サービス--、バージョン:、」 1インチ、RFC1240、オープン・ソフトウェア協議会、1991年6月。
[EAS95] Eastlake, D., 3rd., and C. Kaufman, "Domain Name System Security Extensions", Work in Progress.
[EAS95]イーストレーク、D.、3番目、そして、コーフマン、「ドメインネームシステムセキュリティ拡大」が進行中で扱うC.。
[FUR94] Furniss, P., "Octet sequences for upper-layer OSI to support basic communications applications", RFC 1698, Consultant, October 1994.
[FUR94] ファーニス、P.、「サポートの基本的なコミュニケーションアプリケーションへの上側の層のOSIのための八重奏系列」、RFC1698、Consultant、1994年10月。
Mills Informational [Page 17] RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996
1996年10月にIPv4、IPv6、およびOSIのために情報[17ページ]のRFC2030SNTPv4を製粉します。
[HIN96] Hinden, R., and S. Deering, "IP Version 6 addressing Architecture", RFC 1884, Ipsilon and Xerox, January 1996.
[HIN96]Hinden、R.、およびS.デアリング、「IPバージョン6アドレシングArchitecture」RFC1884とIpsilonとゼロックス、1996年1月。
[ISO86] International Standards 8602 - Information Processing Systems - OSI: Connectionless Transport Protocol Specification. International Standards Organization, December 1986.
[ISO86]世界規格8602--情報処理システム--OSI: コネクションレスな輸送プロトコル仕様。 1986年12月の世界規格組織。
[MIL92] Mills, D., "Network Time Protocol (Version 3) specification, implementation and analysis", RFC 1305, University of Delaware, March 1992.
[MIL92]工場(D.)が「Timeプロトコル(バージョン3)仕様、実装、および分析をネットワークでつなぐ」、RFC1305、デラウエア大学、3月1992
[PAR93] Partridge, C., T. Mendez and W. Milliken, "Host anycasting service", RFC 1546, Bolt Beranek Newman, November 1993.
[PAR93] ヤマウズラとC.とT.メンデスとW.ミリケン、「サービスをanycastingするホスト」、RFC1546、Bolt Beranekニューマン、1993年11月。
[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., "Time Protocol", STD 26, RFC 868, USC Information Sciences Institute, May 1983.
[POS83]ポステル(J.、「時間プロトコル」、STD26、RFC868、科学が設けるUSC情報)は1983がそうするかもしれません。
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
Mills Informational [Page 18]
ミルズInformationalです。[18ページ]
一覧
スポンサーリンク
