788 lines
34 KiB
Plaintext
788 lines
34 KiB
Plaintext
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Network Working Group D. Mills
|
|||
|
Request for Comments: 1769 University of Delaware
|
|||
|
Obsoletes: 1361 March 1995
|
|||
|
Category: Informational
|
|||
|
|
|||
|
|
|||
|
Simple Network Time Protocol (SNTP)
|
|||
|
|
|||
|
Status of this Memo
|
|||
|
|
|||
|
This memo provides information for the Internet community. This memo
|
|||
|
does not specify an Internet standard of any kind. Distribution of
|
|||
|
this memo is unlimited.
|
|||
|
|
|||
|
Abstract
|
|||
|
|
|||
|
This memorandum describes the Simple Network Time Protocol (SNTP),
|
|||
|
which is an adaptation of the Network Time Protocol (NTP) used to
|
|||
|
synchronize computer clocks in the Internet. SNTP can be used when
|
|||
|
the ultimate performance of the full NTP implementation described in
|
|||
|
RFC-1305 is not needed or justified. It can operate in both unicast
|
|||
|
modes (point to point) and broadcast modes (point to multipoint). It
|
|||
|
can also operate in IP multicast mode where this service is
|
|||
|
available. SNTP involves no change to the current or previous NTP
|
|||
|
specification versions or known implementations, but rather a
|
|||
|
clarification of certain design features of NTP which allow operation
|
|||
|
in a simple, stateless remote-procedure call (RPC) mode with accuracy
|
|||
|
and reliability expectations similar to the UDP/TIME protocol
|
|||
|
described in RFC-868.
|
|||
|
|
|||
|
This memorandum obsoletes RFC-1361 of the same title. Its purpose is
|
|||
|
to explain the protocol model for operation in broadcast mode, to
|
|||
|
provide additional clarification in some places and to correct a few
|
|||
|
typographical errors. A working knowledge of the NTP Version 3
|
|||
|
specification RFC-1305 is not required for an implementation of SNTP.
|
|||
|
Distribution of this memorandum is unlimited.
|
|||
|
|
|||
|
1. Introduction
|
|||
|
|
|||
|
The Network Time Protocol (NTP) specified in RFC-1305 [MIL92] is used
|
|||
|
to synchronize computer clocks in the global Internet. It provides
|
|||
|
comprehensive mechanisms to access national time and frequency
|
|||
|
dissemination services, organize the time-synchronization subnet and
|
|||
|
adjust the local clock in each participating subnet peer. In most
|
|||
|
places of the Internet of today, NTP provides accuracies of 1-50 ms,
|
|||
|
depending on the characteristics of the synchronization source and
|
|||
|
network paths.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Mills [Page 1]
|
|||
|
|
|||
|
RFC 1769 SNTP March 1995
|
|||
|
|
|||
|
|
|||
|
RFC-1305 specifies the NTP protocol machine in terms of events,
|
|||
|
states, transition functions and actions and, in addition, optional
|
|||
|
algorithms to improve the timekeeping quality and mitigate among
|
|||
|
several, possibly faulty, synchronization sources. To achieve
|
|||
|
accuracies in the low milliseconds over paths spanning major portions
|
|||
|
of the Internet of today, these intricate algorithms, or their
|
|||
|
functional equivalents, are necessary. However, in many cases
|
|||
|
accuracies of this order are not required and something less, perhaps
|
|||
|
in the order of large fractions of the second, is sufficient. In such
|
|||
|
cases simpler protocols such as the Time Protocol [POS83], have been
|
|||
|
used for this purpose. These protocols usually involve an RPC
|
|||
|
exchange where the client requests the time of day and the server
|
|||
|
returns it in seconds past some known reference epoch.
|
|||
|
|
|||
|
NTP is designed for use by clients and servers with a wide range of
|
|||
|
capabilities and over a wide range of network delays and jitter
|
|||
|
characteristics. Most users of the Internet NTP synchronization
|
|||
|
subnet of today use a software package including the full suite of
|
|||
|
NTP options and algorithms, which are relatively complex, real-time
|
|||
|
applications. While the software has been ported to a wide variety of
|
|||
|
hardware platforms ranging from supercomputers to personal computers,
|
|||
|
its sheer size and complexity is not appropriate for many
|
|||
|
applications. Accordingly, it is useful to explore alternative access
|
|||
|
strategies using far simpler software appropriate for less stringent
|
|||
|
accuracy expectations.
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
It is strongly recommended that SNTP be used only at the extremities
|
|||
|
of the synchronization subnet. SNTP clients should operate only at
|
|||
|
the leaves (highest stratum) of the subnet and in configurations
|
|||
|
where no NTP or SNTP client is dependent on another SNTP client for
|
|||
|
synchronization. SNTP servers should operate only at the root
|
|||
|
(stratum 1) of the subnet and then only in configurations where no
|
|||
|
other source of synchronization other than a reliable radio clock is
|
|||
|
available. The full degree of reliability ordinarily expected of
|
|||
|
primary servers is possible only using the redundant sources, diverse
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Mills [Page 2]
|
|||
|
|
|||
|
RFC 1769 SNTP March 1995
|
|||
|
|
|||
|
|
|||
|
subnet paths and crafted algorithms of a full NTP implementation.
|
|||
|
This extends to the primary source of synchronization itself in the
|
|||
|
form of multiple radio clocks and backup paths to other primary
|
|||
|
servers should the radio clock fail or deliver incorrect time.
|
|||
|
Therefore, the use of SNTP rather than NTP in primary servers should
|
|||
|
be carefully considered.
|
|||
|
|
|||
|
2. Operating Modes and Addressing
|
|||
|
|
|||
|
Like NTP, SNTP can operate in either unicast (point to point) or
|
|||
|
broadcast (point to multipoint) modes. A unicast client sends a
|
|||
|
request to a server and expects a reply from which it can determine
|
|||
|
the time and, optionally, the roundtrip delay and local clock offset
|
|||
|
relative to the server. A broadcast server periodically sends a
|
|||
|
message to a designated IP broadcast address or IP multicast group
|
|||
|
address and ordinarily expects no requests from clients, while a
|
|||
|
broadcast client listens on this address and ordinarily sends no
|
|||
|
requests to servers. Some broadcast servers may elect to respond to
|
|||
|
client requests as well as send unsolicited broadcast messages, while
|
|||
|
some broadcast clients may elect to send requests only in order to
|
|||
|
determine the network propagation delay between the server and
|
|||
|
client.
|
|||
|
|
|||
|
In unicast mode the client and server IP addresses are assigned
|
|||
|
following the usual conventions. In broadcast mode the server uses a
|
|||
|
designated IP broadcast address or IP multicast group address,
|
|||
|
together with a designated media-access broadcast address, and the
|
|||
|
client listens on these addresses. For this purpose, an IP broadcast
|
|||
|
address has scope limited to a single IP subnet, since routers do not
|
|||
|
propagate IP broadcast datagrams. In the case of Ethernets, for
|
|||
|
example, the Ethernet media-access broadcast address (all ones) is
|
|||
|
used with an IP address consisting of the IP subnet number in the net
|
|||
|
field and all ones in the host field.
|
|||
|
|
|||
|
On the other hand, an IP multicast group address has scope extending
|
|||
|
to potentially the entire Internet. The actual scope, group
|
|||
|
membership and routing are determined by the Internet Group
|
|||
|
Management Protocol (IGMP) [DEE89] and various routing protocols,
|
|||
|
which are beyond the scope of this document. In the case of
|
|||
|
Ethernets, for example, the Ethernet media-access broadcast address
|
|||
|
(all ones) is used with the assigned IP multicast group address of
|
|||
|
224.0.1.1. Other than the IP addressing conventions and IGMP, there
|
|||
|
is no difference in server operations with either the IP broadcast
|
|||
|
address or IP multicast group address.
|
|||
|
|
|||
|
Broadcast clients listen on the designated media-access broadcast
|
|||
|
address, such as all ones in the case of Ethernets. In the case of IP
|
|||
|
broadcast addresses, no further provisions are necessary. In the case
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Mills [Page 3]
|
|||
|
|
|||
|
RFC 1769 SNTP March 1995
|
|||
|
|
|||
|
|
|||
|
of IP multicast group addresses, the host may need to implement IGMP
|
|||
|
in order that the local router intercepts messages to the 224.0.1.1
|
|||
|
multicast group. These considerations are beyond the scope of this
|
|||
|
document.
|
|||
|
|
|||
|
In the case of SNTP as specified herein, there is a very real
|
|||
|
vulnerability that SNTP multicast clients can be disrupted by
|
|||
|
misbehaving or hostile SNTP or NTP multicast servers elsewhere in the
|
|||
|
Internet, since at present all such servers use the same IP multicast
|
|||
|
group address 224.0.1.1. Where necessary, access control based on the
|
|||
|
server source address can be used to select only those servers known
|
|||
|
to and trusted by the client. Alternatively, by convention and
|
|||
|
informal agreement, all NTP multicast servers now include an MD5-
|
|||
|
encrypted message digest in every message, so that clients can
|
|||
|
determine if the message is authentic and not modified in transit. It
|
|||
|
is in principle possible that SNTP clients could implement the
|
|||
|
necessary encryption and key-distribution schemes, but this is
|
|||
|
considered not likely in the simple systems for which SNTP is
|
|||
|
intended.
|
|||
|
|
|||
|
While not integral to the SNTP specification, it is intended that IP
|
|||
|
broadcast addresses will be used primarily in IP subnets and LAN
|
|||
|
segments including a fully functional NTP server with a number of
|
|||
|
SNTP clients in the same subnet, while IP multicast group addresses
|
|||
|
will be used only in special cases engineered for the purpose. In
|
|||
|
particular, IP multicast group addresses should be used in SNTP
|
|||
|
servers only if the server implements the NTP authentication scheme
|
|||
|
described in RFC-1305, including support for the MD5 message-digest
|
|||
|
algorithm.
|
|||
|
|
|||
|
3. NTP Timestamp Format
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
Since NTP timestamps are cherished data and, in fact, represent the
|
|||
|
main product of the protocol, a special timestamp format has been
|
|||
|
established. NTP timestamps are represented as a 64-bit unsigned
|
|||
|
fixed-point number, in seconds relative to 0h on 1 January 1900. The
|
|||
|
integer part is in the first 32 bits and the fraction part in the
|
|||
|
last 32 bits. In the fraction part, the non-significant low-order
|
|||
|
bits should be set to 0. This format allows convenient multiple-
|
|||
|
precision arithmetic and conversion to UDP/TIME representation
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Mills [Page 4]
|
|||
|
|
|||
|
RFC 1769 SNTP March 1995
|
|||
|
|
|||
|
|
|||
|
(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.
|
|||
|
|
|||
|
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) |
|
|||
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|||
|
|
|||
|
Note that, since some time in 1968 the most significant bit (bit 0 of
|
|||
|
the integer part) has been set and that the 64-bit field will
|
|||
|
overflow some time in 2036. Should NTP or SNTP be in use in 2036,
|
|||
|
some external means will be necessary to qualify time relative to
|
|||
|
1900 and time relative to 2036 (and other multiples of 136 years).
|
|||
|
Timestamped data requiring such qualification will be so precious
|
|||
|
that appropriate means should be readily available. There will exist
|
|||
|
a 200-picosecond interval, henceforth ignored, every 136 years when
|
|||
|
the 64-bit field will be 0, which by convention is interpreted as an
|
|||
|
invalid or unavailable timestamp.
|
|||
|
|
|||
|
4. NTP Message Format
|
|||
|
|
|||
|
Both NTP and SNTP are clients of the User Datagram Protocol (UDP)
|
|||
|
[POS80], which itself is a client of the Internet Protocol (IP)
|
|||
|
[DAR81]. The structure of the IP and UDP headers is described in the
|
|||
|
cited specification documents and will not be described further here.
|
|||
|
The UDP port number assigned to NTP is 123, which should be used in
|
|||
|
both the Source Port and Destination Port fields in the UDP header.
|
|||
|
The remaining UDP header fields should be set as described in the
|
|||
|
specification.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
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
|
|||
|
four timestamps.
|
|||
|
|
|||
|
Timestamp Name ID When Generated
|
|||
|
------------------------------------------------------------
|
|||
|
Originate Timestamp T1 time request sent by client
|
|||
|
Receive Timestamp T2 time request received at server
|
|||
|
Transmit Timestamp T3 time reply sent by server
|
|||
|
Destination Timestamp T4 time reply received at client
|
|||
|
|
|||
|
The roundtrip delay d and local clock offset t are defined as
|
|||
|
|
|||
|
d = (T4 - T1) - (T2 - T3)
|
|||
|
t = ((T2 - T1) + (T3 - T4)) / 2.
|
|||
|
|
|||
|
The following table is a summary of the SNTP client operations. There
|
|||
|
are two recommended error checks shown in the table. In all NTP
|
|||
|
versions, if the LI field is 3, or the Stratum field is not in the
|
|||
|
range 1-15, or the Transmit Timestamp is 0, the server has never
|
|||
|
synchronized or not synchronized to a valid timing source within the
|
|||
|
last 24 hours. At the client discretion, the values of the remaining
|
|||
|
fields can be checked as well. Whether to believe the transmit
|
|||
|
timestamp or not in case one or more of these fields appears invalid
|
|||
|
is at the discretion of the implementation.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Mills [Page 10]
|
|||
|
|
|||
|
RFC 1769 SNTP March 1995
|
|||
|
|
|||
|
|
|||
|
Field Name Request Reply
|
|||
|
-------------------------------------------------------------
|
|||
|
LI 0 leap indicator; if 3
|
|||
|
(unsynchronized), disregard
|
|||
|
message
|
|||
|
VN 1 (see text) ignore
|
|||
|
Mode 3 (client) ignore
|
|||
|
Stratum 0 ignore
|
|||
|
Poll 0 ignore
|
|||
|
Precision 0 ignore
|
|||
|
Root Delay 0 ignore
|
|||
|
Root Dispersion 0 ignore
|
|||
|
Reference Identifier 0 ignore
|
|||
|
Reference Timestamp 0 ignore
|
|||
|
Originate Timestamp 0 (see text) ignore (see text)
|
|||
|
Receive Timestamp 0 ignore (see text)
|
|||
|
Transmit Timestamp 0 time of day; if 0
|
|||
|
(unsynchronized), disregard
|
|||
|
message
|
|||
|
Authenticator (not used) ignore
|
|||
|
|
|||
|
6. SNTP Server Operations
|
|||
|
|
|||
|
The model for a SNTP server operating with either a NTP or SNTP
|
|||
|
client is an RPC server with no persistent state. Since a SNTP server
|
|||
|
ordinarily does not implement the full set of NTP algorithms intended
|
|||
|
to support redundant peers and diverse network paths, it is
|
|||
|
recommended that a SNTP server be operated only in conjunction with a
|
|||
|
source of external synchronization, such as a reliable radio clock.
|
|||
|
In this case the server always operates at stratum 1.
|
|||
|
|
|||
|
A server can operate in unicast mode, broadcast mode or both at the
|
|||
|
same time. In unicast mode the server receives a request message,
|
|||
|
modifies certain fields in the NTP or SNTP header, and returns the
|
|||
|
message to the sender, possibly using the same message buffer as the
|
|||
|
request. The server may or may not respond if not synchronized to a
|
|||
|
correctly operating radio clock, but the preferred option is to
|
|||
|
respond, since this allows reachability to be determined regardless
|
|||
|
of synchronization state. In unicast mode, the VN and Poll fields of
|
|||
|
the request are copied intact to the reply. If the Mode field of the
|
|||
|
request is 3 (client), it is set to 4 (server) in the reply;
|
|||
|
otherwise, this field is set to 2 (symmetric passive) in order to
|
|||
|
conform to the NTP specification.
|
|||
|
|
|||
|
In broadcast mode, the server sends messages only if synchronized to
|
|||
|
a correctly operating reference clock. In this mode, the VN field is
|
|||
|
set to 3 (for the current SNTP version), and the Mode field to 5
|
|||
|
(broadcast). The Poll field is set to the server poll interval, in
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Mills [Page 11]
|
|||
|
|
|||
|
RFC 1769 SNTP March 1995
|
|||
|
|
|||
|
|
|||
|
seconds to the nearest power of two. It is highly desirable that, if
|
|||
|
a server supports broadcast mode, it also supports unicast mode. This
|
|||
|
is necessary so a potential broadcast client can calculate the
|
|||
|
propagation delay using client/server messages prior to regular
|
|||
|
operation using only broadcast messages.
|
|||
|
|
|||
|
The remaining fields are set in the same way in both unicast and
|
|||
|
broadcast modes. Assuming the server is synchronized to a radio clock
|
|||
|
or other primary reference source and operating correctly, the
|
|||
|
Stratum field is set to 1 (primary server) and the LI field is set to
|
|||
|
0; if not, the Stratum field is set to 0 and the LI field is set to
|
|||
|
3. The Precision field is set to reflect the maximum reading error of
|
|||
|
the local clock. For all practical cases it is computed as the
|
|||
|
negative of the number of significant bits to the right of the
|
|||
|
decimal point in the NTP timestamp format. The Root Delay and Root
|
|||
|
Dispersion fields are set to 0 for a primary server; optionally, the
|
|||
|
Root Dispersion field can be set to a value corresponding to the
|
|||
|
maximum expected error of the radio clock itself. The Reference
|
|||
|
Identifier is set to designate the primary reference source, as
|
|||
|
indicated in the table above.
|
|||
|
|
|||
|
The timestamp fields are set as follows. If the server is
|
|||
|
unsynchronized or first coming up, all timestamp fields are set to
|
|||
|
zero. If synchronized, the Reference Timestamp is set to the time the
|
|||
|
last update was received from the radio clock or, if unavailable, to
|
|||
|
the time of day when the message is sent. The Receive Timestamp and
|
|||
|
Transmit Timestamp fields are set to the time of day when the message
|
|||
|
is sent. In unicast mode, the Originate Timestamp field is copied
|
|||
|
unchanged from the Transmit Timestamp field of the request. It is
|
|||
|
important that this field be copied intact, as a NTP client uses it
|
|||
|
to check for replays. In broadcast mode, this field is set to the
|
|||
|
time of day when the message is sent. The following table summarizes
|
|||
|
these actions.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Mills [Page 12]
|
|||
|
|
|||
|
RFC 1769 SNTP March 1995
|
|||
|
|
|||
|
|
|||
|
Field Name Request Reply
|
|||
|
----------------------------------------------------------
|
|||
|
LI ignore 0 (normal), 3
|
|||
|
(unsynchronized)
|
|||
|
VN 1, 2 or 3 3 or copied from request
|
|||
|
Mode 3 (see text) 2, 4 or 5 (see text)
|
|||
|
Stratum ignore 1 server stratum
|
|||
|
Poll ignore copied from request
|
|||
|
Precision ignore server precision
|
|||
|
Root Delay ignore 0
|
|||
|
Root Dispersion ignore 0 (see text)
|
|||
|
Reference Identifier ignore source identifier
|
|||
|
Reference Timestamp ignore 0 or time of day
|
|||
|
Originate Timestamp ignore 0 or time of day or copied
|
|||
|
from Transmit Timestamp of
|
|||
|
request
|
|||
|
Receive Timestamp ignore 0 or time of day
|
|||
|
Transmit Timestamp (see text) 0 or time of day
|
|||
|
Authenticator ignore (not used)
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
7. References
|
|||
|
|
|||
|
[DAR81] Postel, J., "Internet Protocol - DARPA Internet Program
|
|||
|
Protocol Specification", STD 5, RFC 791, DARPA, September 1981.
|
|||
|
|
|||
|
[DEE89] Deering, S., "Host Extensions for IP Multicasting. STD 5,
|
|||
|
RFC 1112, Stanford University, August 1989.
|
|||
|
|
|||
|
[MIL92] Mills, D., "Network Time Protocol (Version 3) Specification,
|
|||
|
Implementation and Analysis. RFC 1305, University of Delaware,
|
|||
|
March 1992.
|
|||
|
|
|||
|
[POS80] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
|
|||
|
USC/Information Sciences Institute, August 1980.
|
|||
|
|
|||
|
[POS83] Postel, J., and K. Harrenstien, "Time Protocol", STD 26,
|
|||
|
RFC 868, USC/Information Sciences Institute, SRI, May 1983.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Mills [Page 13]
|
|||
|
|
|||
|
RFC 1769 SNTP March 1995
|
|||
|
|
|||
|
|
|||
|
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
|
|||
|
|
|||
|
Phone: (302) 831-8247
|
|||
|
EMail: mills@udel.edu
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Mills [Page 14]
|
|||
|
|