rfc1361.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                           D. Mills
Request for Comments: 1361                        University of Delaware
                                                             August 1992


                  Simple Network Time Protocol (SNTP)

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  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 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 RPC mode
   with accuracy and reliability expectations similar to the UDP/TIME
   protocol described in RFC-868.

   This memorandum does not obsolete or update any RFC. A working
   knowledge of RFC-1305 is not required for an implementation of SNTP.

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 jitter characteristics of the synchronization source
   and network paths.

   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



Mills                                                           [Page 1]

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                                                           [Page 2]

RFC 1361                          SNTP                       August 1992


2. 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 zero
   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 zero preceding bit zero.

   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. This format allows convenient multiple-precision
   arithmetic and conversion to Time Protocol representation (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.

   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 zero, which by convention is interpreted as
   an invalid timestamp.

3. NTP Message Format

   Both NTP and SNTP are clients of the User Datagram Protocol (UDP)
   [POS83], which itself is a client of the Internet Protocol (IP)
   [DAR81]. The structure of the IP and UDP headers is described in the
   relevant specification documents and will not be described further in
   this memorandum. 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 prespecified values. The format of the NTP message
   data area, which immediately follows the UDP header, is shown below.






Mills                                                           [Page 3]

RFC 1361                          SNTP                       August 1992


                           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 prespecified data. For completeness, the function of
   each field is briefly summarized below.

   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)



Mills                                                           [Page 4]

RFC 1361                          SNTP                       August 1992


   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

   The use of this field will be discussed in the next section.

   Stratum: This is a eight-bit 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 normally appear in this field
   range from 6 to 10, inclusive.

   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 -18 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 errors. The values that normally appear
   in this field range from negative values of a few milliseconds to
   positive values of several hundred milliseconds.




Mills                                                           [Page 5]