RFC 1361 (rfc1361) - Page 2 of 10
Simple Network Time Protocol (SNTP)
Alternative Format: Original Text Document
RFC 1361 SNTP August 1992
in the order of one second, is sufficient. In such cases simpler
protocols such as the Time Protocol [POS83], have been used for this
purpose. These protocols usually involve a remote-procedure call
(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 members of the Internet NTP synchronization
subnet of today use software packages 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 accuracy
expectations in the order of a second.
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 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
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 become faulty. Therefore, the
use of SNTP rather than NTP in primary servers should be carefully
considered.
Mills