rfc2030.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,012 行 · 第 1/4 页


RFC 2030             SNTPv4 for IPv4, IPv6 and OSI          October 1996


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

   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 Identifier: This is a 32-bit bitstring identifying the
   particular reference source. In the case of NTP Version 3 or Version
   4 stratum-0 (unspecified) or stratum-1 (primary) servers, this is a
   four-character ASCII string, left justified and zero padded to 32
   bits. In NTP Version 3 secondary servers, this is the 32-bit IPv4
   address of the reference source. In NTP Version 4 secondary servers,
   this is the low order 32 bits of the latest transmit timestamp of the
   reference source. NTP primary (stratum 1) servers should set this
   field to a code identifying the external reference source according
   to the following list. If the external reference is one of those
   listed, the associated code should be used. Codes for sources not
   listed can be contrived as appropriate.













Mills                        Informational                     [Page 10]

RFC 2030             SNTPv4 for IPv4, IPv6 and OSI          October 1996


      Code     External Reference Source
      ----------------------------------------------------------------
      LOCL     uncalibrated local clock used as a primary reference for
               a subnet without external means of synchronization
      PPS      atomic clock or other pulse-per-second source
               individually calibrated to national standards
      ACTS     NIST dialup modem service
      USNO     USNO modem service
      PTB      PTB (Germany) modem service
      TDF      Allouis (France) Radio 164 kHz
      DCF      Mainflingen (Germany) Radio 77.5 kHz
      MSF      Rugby (UK) Radio 60 kHz
      WWV      Ft. Collins (US) Radio 2.5, 5, 10, 15, 20 MHz
      WWVB     Boulder (US) Radio 60 kHz
      WWVH     Kaui Hawaii (US) Radio 2.5, 5, 10, 15 MHz
      CHU      Ottawa (Canada) Radio 3330, 7335, 14670 kHz
      LORC     LORAN-C radionavigation system
      OMEG     OMEGA radionavigation system
      GPS      Global Positioning Service
      GOES     Geostationary Orbit Environment Satellite

   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 scheme is
   implemented, the Key Identifier and Message Digest fields contain the
   message authentication code (MAC) information defined in Appendix C
   of RFC-1305.

5. SNTP Client Operations

   A SNTP client can operate in multicast mode, unicast mode or anycast
   mode. In multicast mode, the client sends no request and waits for a
   broadcast (mode 5) from a designated multicast server. In unicast
   mode, the client sends a request (mode 3) to a designated unicast
   server and expects a reply (mode 4) from that server. In anycast
   mode, the client sends a request (mode 3) to a designated local
   broadcast or multicast group address and expects a reply (mode 4)
   from one or more anycast servers. The client uses the first reply



Mills                        Informational                     [Page 11]

RFC 2030             SNTPv4 for IPv4, IPv6 and OSI          October 1996


   received to establish the particular server for subsequent unicast
   operations. Later replies from this server (duplicates) or any other
   server are ignored. Other than the selection of address in the
   request, the operations of anycast and unicast clients are identical.
   Requests are normally sent at intervals from 64 s to 1024 s,
   depending on the frequency tolerance of the client clock and the
   required accuracy.

   A unicast or anycast client initializes the NTP message header, sends
   the request to the server and strips the time of day from the
   Transmit Timestamp field of the reply. For this purpose, all of the
   NTP header fields shown above can be set to 0, except the first octet
   and (optional) Transmit Timestamp fields. In the first 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 version number of the
   NTP/SNTP server; however, Version 4 servers will also accept previous
   versions. Version 3 (RFC-1305) and Version 2 (RFC-1119) servers
   already accept all previous versions, including Version 1 (RFC-1059).
   Note that Version 0 (RFC-959) is no longer supported by any other
   version.

   Since there will probably continue to be NTP and SNTP servers of all
   four versions interoperating in the Internet, careful consideration
   should be given to the version used by SNTP Version 4 clients. It is
   recommended that clients use the latest version known to be supported
   by the selected server in the interest of the highest accuracy and
   reliability. SNTP Version 4 clients can interoperate with all
   previous version NTP and SNTP servers, since the header fields used
   by SNTP clients are unchanged. Version 4 servers are required to
   reply in the same version as the request, so the VN field of the
   request also specifies the version of the reply.

   While not necessary in a conforming client implementation, in unicast
   and anycast modes it highly recommended that the transmit timestamp
   in the request is set to the time of day according to the client
   clock in NTP timestamp format. This allows a simple calculation to
   determine the propagation delay between the server and client and to
   align the local clock generally within a few tens of milliseconds
   relative to the server. In addition, this provides a simple method to
   verify that the server reply is in fact a legitimate response to the
   specific client request and avoid replays. In multicast mode, the
   client has no information to calculate the propagation delay or
   determine the validity of the server, unless the NTP authentication
   scheme is used.

   To calculate the roundtrip delay d and local clock offset t relative
   to the server, the client sets the transmit timestamp in the request
   to the time of day according to the client clock in NTP timestamp



Mills                        Informational                     [Page 12]

RFC 2030             SNTPv4 for IPv4, IPv6 and OSI          October 1996


   format. The server copies this field to the originate timestamp in
   the reply and sets the receive timestamp and transmit timestamp to
   the time of day according to the server clock in NTP timestamp
   format.

   When the server reply is received, the client determines a
   Destination Timestamp variable as the time of arrival according to
   its clock in 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 by server
      Transmit Timestamp      T3   time reply sent by server
      Destination Timestamp   T4   time reply received by 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 summarizes the SNTP client operations in unicast,
   anycast and multicast modes. The recommended error checks are shown
   in the Reply and Multicast columns in the table. The message should
   be considered valid only if all the fields shown contain values in
   the respective ranges. Whether to believe the message if one or more
   of the fields marked "ignore" contain invalid values is at the
   discretion of the implementation.

      Field Name              Unicast/Anycast          Multicast
                              Request    Reply
      ----------------------------------------------------------
      LI                      0          0-2           0-2
      VN                      1-4        copied from   1-4
                                         request
      Mode                    3          4             5
      Stratum                 0          1-14          1-14
      Poll                    0          ignore        ignore
      Precision               0          ignore        ignore
      Root Delay              0          ignore        ignore
      Root Dispersion         0          ignore        ignore
      Reference Identifier    0          ignore        ignore
      Reference Timestamp     0          ignore        ignore
      Originate Timestamp     0          (see text)    ignore
      Receive Timestamp       0          (see text)    ignore
      Transmit Timestamp      (see text) nonzero       nonzero
      Authenticator           optional   optional      optional




Mills                        Informational                     [Page 13]

RFC 2030             SNTPv4 for IPv4, IPv6 and OSI          October 1996


6. SNTP Server Operations

   A SNTP Version 4 server operating with either a NTP or SNTP client of
   the same or previous versions retains 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, a SNTP server should be operated only in conjunction with a
   source of external synchronization, such as a reliable radio clock or
   telephone modem. In this case it always operates as a primary
   (stratum 1) server.

   A SNTP server can operate in unicast mode, anycast mode, multicast
   mode or any combination of these modes. In unicast and anycast modes,
   the server receives a request (mode 3), modifies certain fields in
   the NTP header, and sends a reply (mode 4), possibly using the same
   message buffer as the request. In anycast mode, the server listens on
   the designated local broadcast or multicast group address assigned by
   the IANA, but uses its own unicast address in the source address
   field of the reply. Other than the selection of address in the reply,
   the operations of anycast and unicast servers are identical.
   Multicast messages are normally sent at poll intervals from 64 s to
   1024 s, depending on the expected frequency tolerance of the client
   clocks and the required accuracy.

   In unicast and anycast modes, the VN and Poll fields of the request