rfc1769.txt

一个开源的NTP客户端程序

   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: [phone]
   EMail: [e-mail]






































Mills                                                          [Page 14]