📄 rfc1769.txt
字号:
specification.Mills [Page 5]RFC 1769 SNTP March 1995 Following is a description of the SNTP message format, which follows the IP and UDP headers. The SNTP message format is identical to the NTP format described in RFC-1305, with the exception that some of the data fields are "canned," that is, initialized to pre-specified values. The format of the NTP message is shown below. 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) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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.Mills [Page 6]RFC 1769 SNTP March 1995 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 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) Version Number (VN): This is a three-bit integer indicating the NTP version number, currently 3. Mode: This is a three-bit integer indicating the mode, with values defined as follows: 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 In unicast mode the client sets this field to 3 (client) in the request and the server sets it to 4 (server) in the reply. In broadcast mode the server sets this field to 5 (broadcast). Stratum: This is a eight-bit unsigned integer indicating the stratum level of the local clock, with values defined as follows: Stratum Meaning ---------------------------------------------- 0 unspecified or unavailable 1 primary reference (e.g., radio clock) 2-15 secondary reference (via NTP or SNTP) 16-255 reserved 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).Mills [Page 7]RFC 1769 SNTP March 1995 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. 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. 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. Reference Clock Identifier: This is a 32-bit code identifying the particular reference source. In the case of stratum 0 (unspecified) or stratum 1 (primary reference), this is a four-octet, left- justified, 0-padded ASCII string. While not enumerated as part of the NTP specification, the following are representative ASCII identifiers: Stratum Code Meaning ---------------------------------------------------------------- 1 pps precision calibrated source, such as ATOM (atomic clock), PPS (precision pulse-per-second source), etc. 1 service generic time service other than NTP, such as ACTS (Automated Computer Time Service), TIME (UDP/Time Protocol), TSP (Unix Time Service Protocol), DTSS (Digital Time Synchronization Service), etc. 1 radio Generic radio service, with callsigns such as CHU, DCF77, MSF, TDF, WWV, WWVB, WWVH, etc. 1 nav radionavigation system, such as OMEG (OMEGA), LORC (LORAN-C), etc. 1 satellite generic satellite service, such as GOES (Geostationary Orbit Environment Satellite, GPS (Global Positioning Service), etc. 2 address secondary reference (four-octet Internet address of the NTP server)Mills [Page 8]RFC 1769 SNTP March 1995 Reference Timestamp: This is the time at which the local clock was last set or corrected, in 64-bit timestamp format. Originate Timestamp: This is the time at which the request departed the client for the server, in 64-bit timestamp format. Receive Timestamp: This is the time at which the request arrived at the server, in 64-bit timestamp format. Transmit Timestamp: This is the time at which the reply departed the server for the client, in 64-bit timestamp format. 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.5. SNTP Client Operations The model for n SNTP client operating with either a NTP or SNTP server is a RPC client with no persistent state. In unicast mode, the client sends a client request (mode 3) to the server and expects a server reply (mode 4). In broadcast mode, the client sends no request and waits for a broadcast message (mode 5) from one or more servers, depending on configuration. Unicast client and broadcast server messages are normally sent at periods from 64 s to 1024 s, depending on the client and server configurations. A unicast client initializes the SNTP message header, sends the message to the server and strips the time of day from the reply. For this purpose all of the message-header fields shown above are set to 0, except the first octet. In this octet the LI field is set to 0 (no warning) and the Mode field is set to 3 (client). The VN field must agree with the software version of the NTP or SNTP server; however, NTP Version 3 (RFC-1305) servers will also accept Version 2 (RFC- 1119) and Version 1 (RFC-1059) messages, while NTP Version 2 servers will also accept NTP Version 1 messages. Version 0 (RFC-959) messages are no longer supported. Since there are NTP servers of all three versions interoperating in the Internet of today, it is recommended that the VN field be set to 1. In both unicast and broadcast modes, the unicast server reply or broadcast message includes all the fields described above; however, in SNTP only the Transmit Timestamp has explicit meaning and then only if nonzero. The integer part of this field contains the server time of day in the same format as the UDP/TIME Protocol [POS83]. While the fraction part of this field will usually be valid, the accuracy achieved with SNTP may justify its use only to a significantMills [Page 9]RFC 1769 SNTP March 1995 fraction of a second. If the Transmit Timestamp field is 0, the message should be disregarded. In broadcast mode, a client has no additional information to calculate the propagation delay between the server and client, as the Transmit Timestamp and Receive Timestamp fields have no meaning in this mode. Even in unicast mode, most clients will probably elect to ignore the Originate Timestamp and Receive Timestamp fields anyway. However, in unicast mode a simple calculation can be used to provide the roundtrip delay d and local clock offset t relative to the server, generally to within a few tens of milliseconds. To do this, the client sets the Originate Timestamp in the request to the time of day according to its local clock converted to NTP timestamp format. When the reply is received, the client determines a Destination Timestamp as the time of arrival according to its local clock converted to NTP timestamp format. The following table summarizes the
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -