Network Working Group
Request for Comments: 2030
Obsoletes: 1769
Category: Informational
D. Mills
University of Delaware
October 1996
Simple Network Time Protocol (SNTP)
Version 4
for IPv4, IPv6 and OSI
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) 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.
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.
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.
1. Introduction
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 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.
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.
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 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 in 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.
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.
An important provision in this document is the reinterpretation of certain NTP Version 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.
In the case of OSI, the Connectionless Transport Service (CLTS) is used [ISO86]. Each SNTP packet is transmitted as the 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.
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
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.
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 used both by multicast servers and anycast clients. NTP multicast addresses for IPv6 and OSI have yet to be determined.
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.
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.
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.
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.
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.
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.
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
can be set to 0.
It is advisable to fill the non-significant low order bits of the timestamp with a random, unbiased bit string, 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 bit string 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.
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.
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 (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.
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.
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 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.
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:
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) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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/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.
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 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).
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).
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 Identifier: This is a 32-bit string 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.
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
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 scheme is implemented, the Key Identifier and Message Digest fields contain the
message authentication code (MAC) information defined in Appendix C of RFC-1305.
5. SNTP Client Operations
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 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.
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.
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.
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.
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 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.
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.
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
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 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.
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
6. SNTP Server Operations
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.
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.
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.
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.
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 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.
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.
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
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
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. Configuration and Management
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.
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.
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.
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.
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.
8. Acknowledgements
Jeff Learman was helpful in developing the OSI model for this protocol. Ajit Thyagarajan provided valuable suggestions and
corrections.
9. References
[COL94] Colella, R., R. Callon, E. Gardner, Y. Rekhter, "Guidelines for OSI NSAP allocation in the Internet", RFC 1629, NIST, May
1994.
[DAR81] Postel, J., "Internet Protocol", STD 5, RFC 791, USC Information Sciences Institute, September 1981.
[DEE89] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, Stanford University, August 1989.
[DEE96] Deering, S., R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, Xerox and Ipsilon, January 1996.
[DOB91] Dobbins, K, W. Haggerty, C. Shue, "OSI connectionless transport services on top of UDP - Version: 1", RFC 1240, Open Software
Foundation, June 1991.
[EAS95] Eastlake, D., 3rd., and C. Kaufman, "Domain Name System Security Extensions", Work in Progress.
[FUR94] Furniss, P., "Octet sequences for upper-layer OSI to support basic communications applications", RFC 1698, Consultant, October
1994.
[HIN96] Hinden, R., and S. Deering, "IP Version 6 addressing Architecture", RFC 1884, Ipsilon and Xerox, January 1996.
[ISO86] International Standards 8602 - Information Processing Systems - OSI: Connectionless Transport Protocol Specification.
International Standards Organization, December 1986.
[MIL92] Mills, D., "Network Time Protocol (Version 3) specification, implementation and analysis", RFC 1305, University of Delaware,
March 1992.
[PAR93] Partridge, C., T. Mendez and W. Milliken, "Host anycasting service", RFC 1546, Bolt Beranek Newman, November 1993.
[POS80] Postel, J., "User Datagram Protocol", STD 6, RFC 768, USC Information Sciences Institute, August 1980.
[POS83] Postel, J., "Time Protocol", STD 26, RFC 868, USC Information Sciences Institute, May 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
Phone: (302) 831-8247
|