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)     ignore6. 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, inMills                                                          [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 1995Security 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.eduMills                                                          [Page 14]