RFC 1361 (rfc1361) - Page 2 of 10

Simple Network Time Protocol (SNTP)

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