rfc1769.txt
来自「RFC 的详细文档!」· 文本 代码 · 共 788 行 · 第 1/3 页
TXT
788 行
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 significant
Mills [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 + =
减小字号Ctrl + -
显示快捷键?