    Network Working Group                                           D. Mills
    Request for Comments: 1769                        University of Delaware
    Obsoletes: 1361                                               March 1995
    Category: Informational

                      Simple Network Time Protocol (SNTP)

    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),
       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. It can operate in both unicast
       modes (point to point) and broadcast modes (point to multipoint). It
       can also operate in IP multicast mode where this service is
       available. SNTP involves no change to the current or previous NTP
       specification versions 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.

       This memorandum obsoletes RFC-1361 of the same title. Its purpose is
       to explain the protocol model for operation in broadcast mode, to
       provide additional clarification in some places and to correct a few
       typographical errors. A working knowledge of the NTP Version 3
       specification RFC-1305 is not required for an implementation of SNTP.
       Distribution of this memorandum is unlimited.

    1. Introduction

       The Network Time Protocol (NTP) specified in RFC-1305 [MIL92] is 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.

    Mills                                                           [Page 1]

    RFC 1769                          SNTP                       March 1995

       RFC-1305 specifies the NTP protocol machine in terms of events,
       states, transition functions and actions and, in addition, optional
       algorithms to improve the timekeeping quality and mitigate among
       several, possibly faulty, synchronization sources. 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 of this order are not required and something less, perhaps
       in the order of large fractions of the second, is sufficient. 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. 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 less stringent
       accuracy expectations.

       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 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 clock is
       available. The full degree of reliability ordinarily expected of
       primary servers is possible only using the redundant sources, diverse

    Mills                                                           [Page 2]

    RFC 1769                          SNTP                       March 1995

       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 deliver incorrect time.
       Therefore, the use of SNTP rather than NTP in primary servers should
       be carefully considered.

    2. Operating Modes and Addressing

       Like NTP, SNTP can operate in either unicast (point to point) or
       broadcast (point to multipoint) modes. A unicast client sends a
       request to a server 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 broadcast server periodically sends a
       message to a designated IP broadcast address or IP multicast group
       address and ordinarily expects no requests from clients, while a
       broadcast client listens on this address and ordinarily sends no
       requests to servers. Some broadcast servers may elect to respond to
       client requests as well as send unsolicited broadcast messages, while
       some broadcast clients may elect to send requests only in order to
       determine the network propagation delay between the server and
       client.

       In unicast mode the client and server IP addresses are assigned
       following the usual conventions. In broadcast mode the server uses a
       designated IP broadcast address or IP multicast group address,
       together with a designated media-access broadcast address, and the
       client listens on these addresses. For this purpose, an IP broadcast
       address has scope limited to a single IP subnet, since routers do not
       propagate IP broadcast datagrams. In the case of Ethernets, for
       example, the Ethernet media-access broadcast address (all ones) is
       used with an IP address consisting of the IP subnet number in the net
       field and all ones in the host field.

       On the other hand, an IP multicast group address has scope extending
       to potentially the entire Internet. The actual scope, group
       membership and routing are determined by the Internet Group
       Management Protocol (IGMP) [DEE89] and various routing protocols,
       which are beyond the scope of this document. In the case of
       Ethernets, for example, the Ethernet media-access broadcast address
       (all ones) is used with the assigned IP multicast group address of
       224.0.1.1. Other than the IP addressing conventions and IGMP, there
       is no difference in server operations with either the IP broadcast
       address or IP multicast group address.

       Broadcast clients listen on the designated media-access broadcast
       address, such as all ones in the case of Ethernets. In the case of IP
       broadcast addresses, no further provisions are necessary. In the case

    Mills                                                           [Page 3]

    RFC 1769                          SNTP                       March 1995

       of IP multicast group addresses, the host may need to implement IGMP
       in order that the local router intercepts messages to the 224.0.1.1
       multicast group. These considerations are beyond the scope of this
       document.

       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 IP multicast
       group address 224.0.1.1. Where necessary, access control based on the
       server source address can be used to select only those servers known
       to and trusted by the client. Alternatively, by convention and
       informal agreement, all NTP multicast servers now include an MD5-
       encrypted message digest in every message, so that clients can
       determine if the message is authentic and not modified in transit. It
       is in principle possible that SNTP clients could implement the
       necessary encryption and key-distribution schemes, but this is
       considered not likely in the simple systems for which SNTP is
       intended.

       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
       SNTP clients in the same subnet, while IP multicast group addresses
       will be used only in special cases engineered for the purpose. In
       particular, IP multicast group addresses should be used in SNTP
       servers only if the server implements the NTP authentication scheme
       described in RFC-1305, including support for the MD5 message-digest
       algorithm.

    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
       bits should be set to 0. This format allows convenient multiple-
       precision arithmetic and conversion to UDP/TIME representation

    Mills                                                           [Page 4]

    RFC 1769                          SNTP                       March 1995

       (seconds), but does complicate the conversion to ICMP Timestamp
       message representation (milliseconds). The precision of this
       representation is 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 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. 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).
       Timestamped data requiring such qualification will be so precious
       that appropriate means should be readily available. 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.

    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 described 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.

    Mills                                                           [Page 5]

    RFC 1769                          SNTP                       March 1995

       Following is a description of the SNTP message format, which follows
       the IP and UDP headers. The SNTP message format is identical to the
       NTP format described in RFC-1305, with the exception that some of the
       data fields are "canned," that is, initialized to pre-specified
       values. The format of the NTP message is shown below.

                               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)                    |
          |                                                               |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |                                                               |
          |                                                               |
          |                  Authenticator (optional) (96)                |
          |                                                               |
          |                                                               |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       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.

    Mills                                                           [Page 6]

    RFC 1769                          SNTP                       March 1995

       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
       version number, currently 3.

       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 mode the client sets this field to 3 (client) in the
       request and the server sets it to 4 (server) in the reply. In
       broadcast 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).

    Mills                                                           [Page 7]

    RFC 1769                          SNTP                       March 1995

       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 Clock Identifier: This is a 32-bit code identifying the
       particular reference source. In the case of stratum 0 (unspecified)
       or stratum 1 (primary reference), this is a four-octet, left-
       justified, 0-padded ASCII string. While not enumerated as part of the
       NTP specification, the following are representative ASCII
       identifiers:

          Stratum Code  Meaning
          ----------------------------------------------------------------
          1   pps       precision calibrated source, such as ATOM (atomic
                        clock), PPS (precision pulse-per-second source),
                        etc.
          1   service   generic time service other than NTP, such as ACTS
                        (Automated Computer Time Service), TIME (UDP/Time
                        Protocol), TSP (Unix Time Service Protocol), DTSS
                        (Digital Time Synchronization Service), etc.
          1   radio     Generic radio service, with callsigns such as CHU,
                        DCF77, MSF, TDF, WWV, WWVB, WWVH, etc.
          1   nav       radionavigation system, such as OMEG (OMEGA), LORC
                        (LORAN-C), etc.
          1   satellite generic satellite service, such as GOES
                        (Geostationary Orbit Environment Satellite, GPS
                        (Global Positioning Service), etc.
          2   address   secondary reference (four-octet Internet address of
                        the NTP server)

    Mills                                                           [Page 8]

    RFC 1769                          SNTP                       March 1995

       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 mechanism is
       implemented, this contains the authenticator information defined in
       Appendix C of RFC-1305. In SNTP this field is ignored for incoming
       messages and is not generated for outgoing messages.

    5. SNTP Client Operations

       The model for n SNTP client operating with either a NTP or SNTP
       server is a RPC client with no persistent state. In unicast mode, the
       client sends a client request (mode 3) to the server and expects a
       server reply (mode 4). In broadcast mode, the client sends no request
       and waits for a broadcast message (mode 5) from one or more servers,
       depending on configuration. Unicast client and broadcast server
       messages are normally sent at periods from 64 s to 1024 s, depending
       on the client and server configurations.

       A unicast client initializes the SNTP message header, sends the
       message to the server and strips the time of day from the reply. For
       this purpose all of the message-header fields shown above are set to
       0, except the first octet. In this 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 software version of the NTP or SNTP server; however,
       NTP Version 3 (RFC-1305) servers will also accept Version 2 (RFC-
       1119) and Version 1 (RFC-1059) messages, while NTP Version 2 servers
       will also accept NTP Version 1 messages. Version 0 (RFC-959) messages
       are no longer supported. Since there are NTP servers of all three
       versions interoperating in the Internet of today, it is recommended
       that the VN field be set to 1.

       In both unicast and broadcast modes, the unicast server reply or
       broadcast message includes all the fields described above; however,
       in SNTP only the Transmit Timestamp has explicit meaning and then
       only if nonzero. The integer part of this field contains the server
       time of day in the same format as the UDP/TIME Protocol [POS83].
       While the fraction part of this field will usually be valid, the
       accuracy achieved with SNTP may justify its use only to a significant

    Mills                                                           [Page 9]

    RFC 1769                          SNTP                       March 1995

       fraction of a second. If the Transmit Timestamp field is 0, the
       message should be disregarded.

       In broadcast mode, a client has no additional information to
       calculate the propagation delay between the server and client, as the
       Transmit Timestamp and Receive Timestamp fields have no meaning in
       this mode. Even in unicast mode, most clients will probably elect to
       ignore the Originate Timestamp and Receive Timestamp fields anyway.
       However, in unicast mode a simple calculation can be used to provide
       the roundtrip delay d and local clock offset t relative to the
       server, generally to within a few tens of milliseconds. To do this,
       the client sets the Originate Timestamp in the request to the time of
       day according to its local clock converted to NTP timestamp format.
       When the reply is received, the client determines a Destination
       Timestamp as the time of arrival according to its local clock
       converted to 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 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: (302) 831-8247
       EMail: mills@udel.edu

    Mills                                                          [Page 14]