rfc1769.txt

来自「RFC 的详细文档!」· 文本 代码 · 共 788 行 · 第 1/3 页

TXT
788
字号
   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

⌨️ 快捷键说明

复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?